I guess I've been living under the proverbial rock for the past two years because I didn't know about JUnit 4.x till yesterday. If you already know JUnit 3.8.x and are an intermediate or above developer, the best tutorial is cited below.
JUnit 4.x is definitely better than its predecessor, but then again there's also TestNG. I've cited a comparison between the two that favors TestNG.
Citation: DevX.com tutorial on JUnit 4 by Antonio Goncalves
Citation: IBM DeveloperWorks article on JUnit 4 vs. TestNG
Thursday, February 19, 2009
Wednesday, February 11, 2009
C# MVP For You and Me - Part 2 - Jeremy D. Miller Leads Me Out of the Wilderness
Patterns are necessary for any maintainable, testable, well-architected GUI. This is especially true for a C# WinForms GUI, for all the reasons discussed in the previous series post.
Even Microsoft itself realized this and has, over the years, promoted a succession of pattern sets for .NET GUIs. These include the Composite UI Application Block (CAB), the Smart Client Software Factory, something called Acropolis, and finally something else called Prism. All but Prism appear defunct, and Prism seems geared primarily toward WPF, which I am not using (see previous series post.) More importantly, all including Prism are tremendously complex. Each one is a skill set in itself, like learning a whole new language. They're better than the Visual Studio approach of automatically generating two-tiered client/server apps, but are overkill for small projects like mine.
The .NET developer Jeremy D. Miller would agree with me. He wrote a series of blog posts, Build Your Own CAB, that describe a light-weight methodology for architecting C# WinForms GUIs. This methodology has enough structure to alleviate the dangers and shortcomings of the VS code generation approach, but is not so complex that people write books, teach training courses, and hold conventions to discuss it.
Miller's methodology is based on the Model-View-Presenter (MVP) pattern. MVP is kind of like the classic Model-View-Controller (MVC) pattern. The differences are so subtle that I will avoid discussing them. If you like, you can read about them here.
Once I finished reading the Build Your Own CAB series, I built the first screens of my app in a matter of days, and had an architecture that continues to carry me forward today. The screens more than met the standards I had set for myself. The code was testable, maintainable, and readable. There was not a line of business logic or service layer access in the actual GUI code. Miller helped me reach my main goal - that a brand new team member could read my code and understand it within minutes.
What I will describe in the next post is partly a summary of Miller's approach, and partly a description of how I implemented it. I have made additions and changes to his methodology, and I will state clearly where I've done so. No matter what you get from my reports, I strongly encourage you to read Jeremy's entire series. It has become my bible of .NET GUI development. Jeremy is a very smart and practical software engineer. I wrote my project based on his work, and will continue to do so until I switch to WPF. Once again, the link to his excellent series is here.
Even Microsoft itself realized this and has, over the years, promoted a succession of pattern sets for .NET GUIs. These include the Composite UI Application Block (CAB), the Smart Client Software Factory, something called Acropolis, and finally something else called Prism. All but Prism appear defunct, and Prism seems geared primarily toward WPF, which I am not using (see previous series post.) More importantly, all including Prism are tremendously complex. Each one is a skill set in itself, like learning a whole new language. They're better than the Visual Studio approach of automatically generating two-tiered client/server apps, but are overkill for small projects like mine.
The .NET developer Jeremy D. Miller would agree with me. He wrote a series of blog posts, Build Your Own CAB, that describe a light-weight methodology for architecting C# WinForms GUIs. This methodology has enough structure to alleviate the dangers and shortcomings of the VS code generation approach, but is not so complex that people write books, teach training courses, and hold conventions to discuss it.
Miller's methodology is based on the Model-View-Presenter (MVP) pattern. MVP is kind of like the classic Model-View-Controller (MVC) pattern. The differences are so subtle that I will avoid discussing them. If you like, you can read about them here.
Once I finished reading the Build Your Own CAB series, I built the first screens of my app in a matter of days, and had an architecture that continues to carry me forward today. The screens more than met the standards I had set for myself. The code was testable, maintainable, and readable. There was not a line of business logic or service layer access in the actual GUI code. Miller helped me reach my main goal - that a brand new team member could read my code and understand it within minutes.
What I will describe in the next post is partly a summary of Miller's approach, and partly a description of how I implemented it. I have made additions and changes to his methodology, and I will state clearly where I've done so. No matter what you get from my reports, I strongly encourage you to read Jeremy's entire series. It has become my bible of .NET GUI development. Jeremy is a very smart and practical software engineer. I wrote my project based on his work, and will continue to do so until I switch to WPF. Once again, the link to his excellent series is here.
Shoutouts - First Edition
I'm taking a quick break from the MVP series to post my first edition of "Shoutouts." This series aims to acknowledge, summarize, and cite technical blog posts that have helped me solve extremely specific low-level tech problems. With the right descriptive keywords, I hope to make it that much easier for you to Google these than it was for me.
Posting Source Code on Blogger, Especially XML
A meta-Shoutout: the post you are now reading would not be possible without this guy's help.
Citation: Please Make A Note
Spring Web Services - Generating WSDL
To get the WSDL generator to include the hostname and full URL in your <soap:address location="">, add this to your web.xml file:
<init-param>
<param-name>transformWsdlLocations</param-name>
<param-value>true</param-value>
</init-param>
This tidbit was missing from the Spring WS Tutorial, and it cost me half a day. I don't know why transformWsdlLocations=true isn't just the default setting when configuring the dispatcher servlet, and I made this known in a comment to the cited blog replete with late-night histrionics.
Citation: Phill's J2EE Blog
Also: Mike's Blog
Spring Web Servies - AbstractStaxStreamPayloadEndpoint Sample
This is the only sample code I found for the AbstractStaxStreamPayloadEndpoint. There isn't even an example in the actual Spring-WS distribution. Using STAX is crucial for dealing with large XML requests and replies. You want to stream things whenever possible, rather than materializing giant DOMs.
Citation: Pascal's Blog
Tomcat, Log4J, Spring - Error: java.lang.IllegalStateException: Web app root system property already set to different value
It's quite likely that you'll use these three frameworks together. It's also quite likely you'll get this error message if you do. To fix it, add this to your web.xml:
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>uniqueAppRootNamee</param-value>
</context-param>
To find out why, read the citation. It's Tomcat's fault. I love Tomcat but there is no earthly reason why this had to happen.
Citation: Glennn's Stuff
Maven Profile Activation
Discussion of the subtleties of Maven profile activation, including what <activeByDefault> really means. The word "subtleties" and the words "Maven profile activation" do not belong in the same sentence. This has made me want to back off of my use of Maven profiles, and I'm posting a comment to the cited blog asking what alternatives I can use to accomplish what I want.
Citation: James Lorenzen's Blog
Maven Jetty Plugin Configuration
The Maven Jetty Plugin saves tons of time when doing web app development. Unfortunately, its documentation page is incomplete, and does not fully specify how to change things as basic as the port number. Luckily, I found a blog post that does - see the citation.
Citation: aminal
Posting Source Code on Blogger, Especially XML
A meta-Shoutout: the post you are now reading would not be possible without this guy's help.
Citation: Please Make A Note
Spring Web Services - Generating WSDL
To get the WSDL generator to include the hostname and full URL in your <soap:address location="">, add this to your web.xml file:
<init-param>
<param-name>transformWsdlLocations</param-name>
<param-value>true</param-value>
</init-param>
This tidbit was missing from the Spring WS Tutorial, and it cost me half a day. I don't know why transformWsdlLocations=true isn't just the default setting when configuring the dispatcher servlet, and I made this known in a comment to the cited blog replete with late-night histrionics.
Citation: Phill's J2EE Blog
Also: Mike's Blog
Spring Web Servies - AbstractStaxStreamPayloadEndpoint Sample
This is the only sample code I found for the AbstractStaxStreamPayloadEndpoint. There isn't even an example in the actual Spring-WS distribution. Using STAX is crucial for dealing with large XML requests and replies. You want to stream things whenever possible, rather than materializing giant DOMs.
Citation: Pascal's Blog
Tomcat, Log4J, Spring - Error: java.lang.IllegalStateException: Web app root system property already set to different value
It's quite likely that you'll use these three frameworks together. It's also quite likely you'll get this error message if you do. To fix it, add this to your web.xml:
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>uniqueAppRootNamee</param-value>
</context-param>
To find out why, read the citation. It's Tomcat's fault. I love Tomcat but there is no earthly reason why this had to happen.
Citation: Glennn's Stuff
Maven Profile Activation
Discussion of the subtleties of Maven profile activation, including what <activeByDefault> really means. The word "subtleties" and the words "Maven profile activation" do not belong in the same sentence. This has made me want to back off of my use of Maven profiles, and I'm posting a comment to the cited blog asking what alternatives I can use to accomplish what I want.
Citation: James Lorenzen's Blog
Maven Jetty Plugin Configuration
The Maven Jetty Plugin saves tons of time when doing web app development. Unfortunately, its documentation page is incomplete, and does not fully specify how to change things as basic as the port number. Luckily, I found a blog post that does - see the citation.
Citation: aminal
Subscribe to:
Posts (Atom)
Posts
