Friday, February 13, 2009

InfoQ: Craftsmanship and Ethics

This is a fabulous video on good practices as a software developer and as a software development organization.  It  highlights a number of Do’s and Don’ts that all developers should follow.

If you are a developer, you need to watch this.

The video discusses concepts such as Discipline in software development such as:

  • Short Iterations; design-build-refactor-repeat
  • Don’t Wait for Definition; be part of the requirements definition by releasing executable code
  • Abstract away Volatility; separate things that are likely to change from things that are not likely to change
  • Decouple; build interfaces and build to the interfaces
  • Find ways around Blocks; continuously remove impediments
  • Keep architectures simple; I had to look up what ‘turgid viscous’ meant, but make architectures solve problems that are within the scope of the present project.
  • Improve Incrementally; fix problems a little at a time.
  • Avoid Grand Re-designs; don’t confuse this with incremental improvement, this just means that you leverage old product to make new product.
  • Progressive Widening & Progressive Deepening; I love these two terms.  Widening is creating fully functioning features one at a time and deepening is a form of refactoring to add the layers required to limit dependencies. “First make it work, then make it right, then make it fast.”
  • Don’t write bad code; take the time to get the code right, don’t speed through to make a release.
  • Clean your code; messy code exists over a long term and causes problems with people working on it later and causes productivity to drop. “Every line of Code is what you expect it to be.”  Keep functions small and simple, name things well, use proper formatting, etc.
  • Test Driven Development; three rules (1) Don’t write any production code until you’ve written a test for it, (2) don’t write any more test than is likely to fail, (3) then don’t write any more code than what would pass the test.  This cycle ensures that you’ve always got testable code.
  • QA Should not find anything; don’t use QA to find our defects.
  • 100% code coverage; make sure all code is considered tested.
  • Avoid debugging; using test driven development helps this, debugging is a way of helping you understand how your own code works.  Using a test to do this is a better and more persistent method of doing this.
  • Manual Test Scripts are Immoral; Automate test scripts and make them part of the deliverable.
  • Define Done; Make sure software id done at the end of an iteration.  Use “all tests pass” as a default definition.
  • Test Through the right Interface; Make sure that you don’t need the GUI to test your application.
  • Apprenticeship; make sure new programmers are not left to develop their own bad habits.
  • Use Good Tools; this goes without saying.  If you’ve ever done any woodworking you know that good tools make all the difference in the final product.

InfoQ: Craftsmanship and Ethics

Wednesday, February 11, 2009

Web Security via web.xml

I think web.xml is often overlooked for a great many configuration options.  Personally, I’m guilty of limiting my use of the deployment descriptor to servlet, filter and tag configuration.  I don’t like to see the file get messy I guess.

This article talks about the authentication configuration options that can be used in web.xml.  This was something that I usually took care of in the web server configuration, not so much in the application server layer…but it looks like there are quite a few options here.

Understanding Web Security Using web.xml Via Use Cases | Javalobby

Tuesday, February 3, 2009

Using HttpClient with Unique SSL Requirements

In looking at the HtmlUnit library as a means to do headless front end testing as part of our build process.  I quickly ran into to very large problems that I had to overcome.

Firstly, the default HttpClient behaviour when dealing with un-trusted server certificates is to throw an exception when connecting.  Since our development server doesn’t have a trusted certificate and its a waste to buy one for development, I needed a way to be able to get my build server to trust my homemade server certificate.  Luckily, I can tell the webclient to use insecure ssl, but I thought perhaps that this might be a little shot-gunnish.

Secondly, many of our modules require a client side certificate to be able to connect from the web browser…another behaviour which isn’t the default from the HttpClient.

After a little hunting, I found the SSL guide on the HttpClient project site…(image finding it there of all places).  I found that the explanation wasn’t so good on the page except it links to the source file of an that made things quite a bit clearer.  Allow me to explain.

HtmlUnit uses the commons HttpClient to download pages.  The client uses the Protocol class when making connections to servers.  In order for me to be able to change the behavior of a connection, the easiest way to do this is to supply the client with an alternate protocol class to use when connecting with a server…this is a lot easier to do than you think.

I basically replicated the AuthSSLProtocolSocketFactory class mentioned earlier and then I used it to construct an instance of a Protocol class.  Then I registered my new Protocol to handle “https” requests.  I had a bit of trouble using the java keystore for my client certificate, so I had to add a small change to allow me to handle PKCS12 keystore instead, which works just fine.

Once you have the socket factory created, then all you do is create a ‘new’ protocol to handle https and register it with the framework:

  1: final Protocol authhttps = new Protocol(
  2:     "https", 
  3:     new AuthSSLProtocolSocketFactory(
  4:         keystoreUrl,
  5:         "password",
  6:         truststoreUrl,
  7:         "password"), 
  8:     443);
 10: Protocol.registerProtocol("https", authhttps);

Once this is done, you simply code your unit test.  See the ‘Getting Started’ link at

HttpClient - HttpClient SSL Guide