Show and Tell of expensive toys could sum this evening up.
There were only seven developers among the seventy or so attendees. The phrases
Compact Framework or even .Net were not mentioned once!
Still it was a fun evening, I got to live vicariously through other people’s high dollar purchases (like I’d blow $800 on a PDA, do you know what kind of wheels $800 would buy? Nice ones).
Unbelievably some rivaled Michael Earls on the amount-of-tech-in-your-everyday-life front. It seemed like everyone there had Bluetooth capable devices which talked to their car audio
system + GPS receiver.
Obviously there is quite lot to learn about mobile devices apart from just programming them; my favorite was the new nickname for the BlackBerry: CrackBerry – apparently checking Email becomes an addiction creating a Pavlovian response from its incoming email alert. For you single guys: If you fly often it appears a BlackBerry will pick up more chicks than a PocketPC equivalent. My $200 Dell Axim probably means Jocks will be stand in line to kick my nerdy ass.
The main speaker was Dale Coffing, he showed off some cool products including a pair of khakis that I’ll be buying. The SCOTTeVEST pants have eleven hidden pockets and compartments – ideal for stowing a PDA and blunt metal objects discretely (in case of attack by Jocks in Airport lounges). SCOTTeVEST also sell Jackets… get ready to salivate… Their jackets have up to 42 hidden pockets all begging to contain an expensive gadget, the jacket even has hidden cable routing to link any oh-that’s-so-90’s wired gadgets together. And just think of the new people you’ll meet at Airport security. The Jackets are here:
If anyone knows of an Atlanta based Compact Framework
Support User Group please let me know.
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.
If you only buy one programming book in your life, buy this one.
Many of you will have heard me rave about Code Complete and Rapid Development. These are both by Steve McConnell and my successful programming career owes an enormous debt to them, most of my ideas on projects seeded from these books.
Back in 1997 the first revision took me over three hard months to read. Much of the material was new to me, and it really took time to sink in – some of it never clicked. Fast forward to June 2004; The Second Edition grew about two hundred pages to incorporate new fashions on the block like xp, refactoring and design patterns. I ordered it ASAP but only just found the time to read it.
Despite ten years having passed since the first edition, many fundamentals have stayed the same, and it looks like some chapters were only lightly updated. This is proof of how good the first edition was. Personally I read the first edition about four years after completing a post-grad degree in Comp Sci. As I said there were many sections that I just did not understand fully. It is now eleven years since the degree, and the book was a total pleasure to read. So many partially illuminated light bulbs are now glowing brightly.
Yes everything in the book is pretty basic stuff. The Design Patterns/ Extreme Programming/ XAML/ Avalon/ only-in-pre-Alpha release crowd will not be impressed, there are few new buzzwords to impress people with. IMO it is far more important to have good grasp of the basics before we go out looking for new hammers to use on our next project. How many of us have seen a Design Pattern used inappropriately, just because a developer happened to read about it lately?
The book is only $34 from Amazon and Steve has made some chapters available for free.
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.