Development (General)

Atlanta’s Java User Group

Atlanta’s Java User Group is excellent. Tonight Justin Gehtland talked about his new book Better, Faster, Lighter Java. It was a thoroughly enjoyable evening, even with the numerous (and almost all inaccurate) .Net jibes.

Prior to the main event Burr Sutter (who I already knew) led a great discussion with the audience on a raft of subjects. Our .Net groups are missing someone with his panache to work the crowd; he is at least a DCC level speaker.

A fundamental subject of the book is Why Do Many Java Project Fail? As a former Java developer I agreed with many of the assertions including:

. Complexity – Java people love buzzwords and apply any they know anywhere!

. Taking things too far – e.g. Layering everything

. EJB misuse – Been there personally!

. Peer Pressure to write ‘smart’ code

It was also interesting to see just how fragmented the Java tools/ platform extensions market has become since I booted the JVM out of my career (March 2001). The number of commercial-quality Open Source tools available is amazing. In fact commercial companies are now viewing projects like Hibernate as serious competition. In my view this fragmentation lowers each tool’s user base and hence their quality. Why is the CLR, .Net Framework and VS.Net so stable? Because a massive number of sales means Microsoft can afford serious development and gargantuan testing efforts. Java EJB Servers cost around $100K and are apparently as stable Scott McNealy’s career. Without the effort of a Microsoft style Product Development Lifecycle you just cannot create Microsoft quality products. I would love to yatter on about the evening but no one reads long blog entries, so watch this space for news from future Java meetings.

Defensive Programming

GIGO, Garbage In, Garbage Out; Even before my first high school Computer Class back in 1982 this term was well known to me and my few programmer friends. It is up there with Goto considered harmful. This blog tries to explain the why GIGO is no excuse for failure in your own code:

Recently, while on a group cycle ride a fellow rider’s lack of experience/ judgment in jumping a road hazard led to reasonably serious injuries on my part. Was it my fault? Well, he lost control while jumping falling on my bike and taking it down. Still I partially blame myself; I had never seen this guy cycle before, and just assumed he knew how to hop a bike over obstacles. In future when such an obstacle arises, I’ll be very alert for problems and maintain a good distance from unknown cyclists when potential danger arises.

We can do the same in programming. The recent Fail-Fast post highlights one such technique. In Code Complete 2 Steve McConnell collectively groups such techniques as Defensive Programming. This chapter should be read by anyone who writes code for a living. He correctly points out that a fail-fast technique is not always the correct action. Over the last eleven years I have exclusively written serious business applications that often work with financial data. In these cases if an error occurs we would rather fail in a hard manner than have the code work in an inconsistent state:

“A dead program normally does a lot less damage than a crippled one”

But, what if you are writing a video game, or the error happens in simply rendering data to the screen. In such cases a graceful recovery option may be better. Would you rather have Windows crash, or show a desktop icon using the wrong colors?

The chapter is too long to do justice in a blog post. It covers sub-topics including Assertions, Barricades, Graceful Recovery options, Robustness v’s Correctness and Exceptions. At the bare minimum skim-read all the sections (although the Exception section is pretty weak IMHO).

Certainly one project I participated on in 1997 suffered politically because it was the GUI to a lousy messaging system, which feed the GUI with bad data. My manager’s defense was ‘Garbage In, Garbage Out’, and it fell on death ears. With the hindsight of Steve McConnell’s wisdom, if we had Barricaded our code from bad data then fighting politics would have been much easier. The manager could have attended meetings with
the log from the Barricade Layer, proving in black and white where the problems lay. Both teams would then have been able to solve the problems much quicker, without escalating it up the management chain.

ASP.Net Cross Application Cookie Sharing

Several companies running ASP.Net experience this problem. They have several web applications and need common authentication. Out of the box ASP.Net makes the user login in to each different application. I know of several organizations where this was a frustration to hundreds if not thousands of user.

Luckily the fix is trivial. Open up machine.config (beg, grovel, kiss the feet of your sys-admin if necessary) and make this change:

Original machine.config entry:

<machineKey validationKey=”AutoGenerate,IsolateApps” decryptionKey=”AutoGenerate” validation=”SHA1″/>

To enable sharing of cookie authentication:

<machineKey validationKey=”AutoGenerate” decryptionKey=”AutoGenerate” validation=”SHA1″/>

>>Totally trivial change that took under five minutes of searching documentation but I bet many organizations are struggling with separate logins even today. All the more reason to hire a Microsoft Certified .Net consultant [shameless plug!].