The Pragmatic Programmer / Tip 7

Eliminate Effects between Unrelated Things
Design components that are self-contained, independent, and have a single, well-defined purpose.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 6

DRY - Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 5

Critically Analyze what You Read and Hear
Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 4

Make Quality a Requirements Issue
Involve your users in determining the project's real quality requirements.

More at the pragmatic programmer list of tips.

Origins Of The Spring Framework

The Spring Framework has gained a lot of momentum in the last one or two years. When I first heard about it back in 2004, I hastily appraised it as just another J2EE framework. The J2EE stack in general had been quite OK for me, and while I did not necessarily like EJBs, I kind of accepted them the way they were (after all, not worse than COM+ components ;-) ). So I was reluctant to jump on what looked like the next bandwagon of technology hype. Some comments from luminaries such as Don Box and Ted Neward seemed to support my ad-hoc assumption (see Rod Johnson's reply).

But when I finally found the time to dig a little bit more into Spring, I noticed it included several very appealing approaches. To sum it up in two sentences, Spring is a non-invasive Java infrastructure framework complementing J2EE (but not necessarily bound to J2EE exclusively). Architecturally based on the Inversion-Of-Control pattern (AKA Dependency Injection), it provides developers with an easy-to-understand programming model (based on POJOs, as opposed to EJBs for example). Dependency injection opens a whole range of possibilities, such a lose coupling, unit testing, declarative transactions and AOP in general. For more details, you might want to have a look at the article "Introduction to the Spring Framework".

Rod Johnson of course is the original creator of Spring, and what I didn't know before is that all of this dates back to some web framework components he introduced in his 2002 book "Expert One-on-One J2EE Design and Development". Several readers then convinced him to open-source his framework, and went to work on it under its new label "Spring Framework". I actually had "Expert One-on-One J2EE Design and Development" at home for a year or so not knowing that it already described back then what Spring is all about today.

As another side note, one of Spring's main contributors, namely Juergen Hoeller, used to study computer science at the University of Linz, Austria at the same time as I did. He is Spring lead developer today, and co-founded Interface21, a Spring consulting company, together with Rod Johnson. Congratulations guys, great job!

Scott McNealy Resigns, Jonathan Schwartz New Sun CEO

Top news of the day: Scott McNealy resigned as Sun Microsystem's CEO after spending 22 years at the company's top position. Sun's board of directors chose Jonathan Schwartz as his successor.

The Pragmatic Programmer / Tip 3

Be a Catalyst for Change
You can't force change on people. Instead, show them how the future might be and help them participate in creating it.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 2

Provide Options, Don't Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done; explain what can be done.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 1

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

More at the pragmatic programmer list of tips.

Software Development Podcasts

I must be subscribed to 50+ podcasts right now, so I am kind of losing track, but what I can say for sure is that the following podcasts on software development resp. computer science are of excellent quality. For my part, I try not to miss a single episode of those.

• The Java Posse


• .NET Rocks


• IT Conversations - Programming


• Channel 9 ARCast


• The Polymorphic Podcast


• Berkeley Webcast - CS 162 Operating Systems and System Programming (introductorily but nevertheless interesting - and there are more Berkeley CompSci webcasts available)


• The Software Engineering Radio
  

Generics In Java 5 And .NET 2.0

Two days ago I attended a presentation of .NET CLR lead architect Jim Miller from Microsoft. During his talk he told the story of how generics made their way into .NET 2.0 in great detail. Surprisingly there was an original design goal to keep the bytecode compatible, so that older .NET runtimes would be able to handle generics-comprised code as well. As we all know today, they had to give up that objective. Java 5 on the other hand stayed bytecode-compatible with older versions due to its approach of type erasure - generic classes don't contain type information, so a List is represented as a List of objects in bytecode. This of course introduces some drawbacks as well, e.g. there is no way to find out the underlying generic type at runtime using reflection (a feature important for RAD tools and others), or the need for casting resp. boxing/unboxing in case of primitive types.

It's interesting to note that in .NET's case, work on generics started as a research project back in 1999, long before the first .NET 1.0 beta had even been published. On the Java frontier, JSR 14 "Adding Generics to the JavaTM Programming Language" was initiated in 1999 as well (actually Java generics are based on the even older project Pizza/GJ). Six years in the making, in both cases. Amazing.

More on generics in Java 5 and .NET 2.0 can be found in this transcript of an interview with Anders Hejlsberg (talking with Bill Venners and Bruce Eckel) and Gilad Bracha's Java generics tutorial.

Web Applications Vs. Desktop Applications

Clearly for software and service vendors responsible for distributing applications to several thousand clients, web applications must have seemed like a gift from heaven. No more installation wizards crashing, no COM registration, no DLL hell, no reboot, no desperate customer calls on the service hotline. And the same is true for regular software patches - updating a web application happens once on the server and that's it. Many CTOs even favor web applications for intranet scenarios just because of this single reason. When they have to decide between a thin and a rich client approach, it's quite clear which direction new projects tend to go...

The thing is, those folks succumb a fatal misconception. They are just so accustomed to the way traditional client software deployment has looked like for the last 15 years, that they lost track of what is possible today. There is absolutely no technical reason why a desktop application couldn't be installed and updated in a completely transparent manner as well. Off-the-shelf solutions like Sun's Java Web Start or Microsoft's ClickOnce (formerly known as NoTouch-Deployment) have been around for several years, and even if they weren't, there is no obstacle to a proprietary approach - just let your application check it's version number against a central service, and trigger an update if needed.

Now I am not proposing that eBay or Amazon should go for a rich client ;-) But I have watched a lot of intranet systems fail when it comes to usability, just because they were forced to go the HTML way (Ajax and Web 2.0 might improve the situation here, but the base principle still stands). Desktop applications can offer a much more sophisticated user experience, as well as taking advantage of the local machine's CPU power and offline capabilities. And on the intranet it's perfectly appropriate to communicate with an application server using DCOM or IIOP. When HTTP is a must, we still have webservices.

In my experience, developing a certain featureset for a thin client also tends to take more time than for a rich client and is associated with larger technical risks due to increased complexity (caused by the statelessness of HTTP or issues like server scalability).

Don't get me wrong, I like using and developing web applications - I worked on an internet banking solution for about four years, and enjoyed every minute of it. At the same time we implemented an enterprise banking system for corporate customers, where we went with a rich client. Both approaches were well-suited for each task and each particular end user group.

I am just afraid that unless decision makers learn about the real pros and cons of rich and thin clients, we will continue to see corporate intranet web applications spring up like mushrooms when desktop applications would have been much more appropriate.

Top Ten Tips On How To Become A Rock Star Programmer (NOT)

Mikael Grev's JavaLobby article about the "Top Ten Tips on how to become a Rock Star Programmer" has gained quite some publicity lately. I first heard about it on the Java Posse podcast, and now Jeff Atwood posted a response on his weblog as well.

Like some other commentators so far I also tend to disagree with several of Mikael's statements, for example:

#2 Use a big TFT screen
I still have tube monitors both at work and at home, and my code looks pretty much the same as if I would be sitting in front of a TFT ;-) Besides, my email client at work will backfire on any attempt of running in dual screen mode (yes, it's Lotus Notes...)

#4 Don't learn APIs too well
Do you want people having to look up the documentation at each second line? I code most API-calls "blindfolded", I rarely consult the JDK or .NET Framework documentation. IntelliSense helps, but only as long as I type in component or method names which I am familiar with already. And I have met one or two guys who "didn't learn APIs too well". They implemented their own version of String.indexOf() - need to say more?

#7 Go back and enhance your old code
Now, my old code might not be pretty, but it works. I know what I would do differently today, but that knowledge stems from somewhere else. And if I know how to do it now, why bother and execute that change on an otherwise perfectly running system - it might break just for the beauty of a new approach. I'd rather apply what I have learned on current projects than on old ones.

#9 Don't ask people for advice
From personal experience, I have benefited most by working with and learning from great developers. I never hesitated to ask them for advice. And when in exchange someone requests help from me, I will be happy to assist. Mikael recommends googling instead. Google is great to look things up, but I wouldn't rely on it exclusively.

Summing up, my recommendations on how to become a Rock Star Programmer would go into a slightly different direction:

#1 Get substantiated education. It's not that everyone needs a PhD in computer science, but your local "how-to-become-a-web-developer-in-six-weeks"-course won't make you a real programmer either.

#2 Never stop learning. Read books and magazine articles, check developer weblogs and listen to technology podcasts, go to industry conferences, take each training opportunity your employer offers, etc.

#3 Work as a developer already during education, at least part-time. This allows you to combine theory and practice. Also, try to find a pet project you can pursue in sparetime, in an area apart from your daily field of work.

#4 Go sure you truly understand why things work the way they do (or why they don't). Don't second-guess. If this library operates fine in debug mode, but breaks in release mode, go and figure out where that flawed memory access happens.

#5 Observe how great developers are doing it. Look at their code and ask them when in doubt. And don't forget to transfer the knowledge you gained to the next one in line.

#6 Eat your own dog food (I agree with Mikael Grev on this one). Don't stay in an ivory tower designing stuff that might not be very useful to others.

#7 Use the best tools you can get, as this will prevent you from wasting your time on mundane tasks.

#8 Be self-critical. Seek perfection, but also be conscious you will never reach it. At the same time, stay humble - application programming isn't rocket science. Making mistakes is only human, just go sure you don't neglect the possibility that your code contains errors, and act accordingly.

#9 Be curious. Enquire what goes on under the hoods, decompile stuff you are interested in, have a look at the memory image in your debugger, use code analysis and profiling tools (like Purify, Boundschecker, OptimizeIt and Lint), or check at which rate your application opens and closes database connections, things like that.

#10 And finally: Have passion for your domain of work.

"Vanilla DAL" Sample Screenshots Available

Sourceforge embraces the use of screenshots even for component libraries. What you normally end up doing is capturing some configuration file content, or an IDE screenshot of some lines of code invoking the library's API. So here are some screenshots depicting a simple Vanilla DAL application.

The First Item Ever Sold On EBay

Legend has it that the first item ever sold on eBay was a PEZ candy dispenser. The story goes that eBay-founder Pierre Omidyar cobbled together the first version of his "AuctionWeb"-site (which was hosted on http://www.ebay.com/aw and later became eBay) in order to help his fiancee to trade the PEZ dispensers that she was collecting. This version has been told over and over again, and at the foyer of the german eBay subsidiary in Berlin there is a showcase full of PEZ dispensers seemingly supporting the tale. Another time, eBay CEO Meg Whitman even posed for a photo with lined-up PEZ dispensers.



Truth is that the PEZ story is an invention of eBay's first public relation manager, Mary Lou Song. Back in 1997, Song was facing some difficulties attracting media attention for eBay's online auction efforts. When she met Pam Wesley, Omidyar's fiancee, Wesley told her about her hobby of collecting PEZ dispensers. So Song literally made up eBay's founding story, and the journalists loved it.

Adam Cohen revealed what really happened in his book "The perfect store", and this has since been confirmed by eBay.

Actually the first item that Pierre Omidyar ever sold on eBay was his broken laser pointer. It went away for 14 dollars.

BTW, my latest eBay purchase just arrived yesterday: a Magnavox Odyssey 2 video game console (known in Europe as the Philips Videopac G7000).