DZone offers free RefCardz (cheatsheets)

The Dzone community portal offers fantastic cheatcheats for different technologies (They call them actually RefCardz). These short 1 to 5 page printouts are loaded with information on a specific technology, or a part of technology , such as Ajax, Spring configuration, EJB3 DI etc..

The best part is that they add a new RefCard every week!

Google App Engine

Google released a new service a few weekss ago, the Google App Engine. At a first glance it seems to be a very interesting service, which they call an alternative to the LAMP stack. It offers a server environment for your code, persistent storage and integration to other Google’s services, plus the runtime environment (Python). And of course all of this is free.

• 500Mb of storage for scalable applications
• Persistent storage (Sort of a database)
• Python environment for dynamic web applications
• Application framework (However you can use your web-framework of choice)
• Integration to Google services (User authentication, Datastore, Email, URL Fetch API)
• A development server to emulate live Google services

I signed for a free account today, but unfortunately it looks like a few others have signed in as well. At the moment they don’t offer accounts any more. Perhaps the service was more popular than they expected. Anyways, I can always develop my services on my local environment, and upload them when I get the server storage.

We’ll have to wait and see does this mean a growing number of interesting web applications in the coming months. At least you can’t blame it on the missing infrastructure anymore, can you.

QCon and JAOO conferences

A personal note: QCon conferences seem to have interesting topics and presentations. Not just vendor specific stuff like BeaWorld, but platform independent presentations from developers view point in the spirit “For developers, by developers”. Should try to attend either one of these next year..

For starters, check out the slides from JAOO at London. One of my favorites is Linda Risings presentation on efficent working, and I can personally agree on many of the notes.

TDD over 30 year old concept – Dijksta on TDD back in 1972?

TDD, Test-Driven Development has been here for a while since XP introduced it in the late 90’s. However, the concept is not that new. The great Edsger W. Dijkstra has written a few words on TDD as well, and it dates back to 1972 an his article “The Humble Programmer”.

“Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following” observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.

I’m not sure did the big D mean the unit-testing approach of today, or theoretical proofing of algorithm’s correctness. Nevertheless, the idea took 30 years to really get ground in the mids of programming professionals. Kudos for Dijkstra anyway!!

By the way, really should read more these oldies but goldies from the history of computing.

Bug fixes – A great place to start for new team members

A few days ago I read Martin Fowler’s article on using Agile software process with offshore development and one particular comment was so true that I have to mention it here. ThoughtWorks, the company Fowler works for introduces new team members to a codebase by making them fix bugs before starting to implement new functionality. I’ve experienced the benefit of such approach myself a few times.

First clear benefit is, that you really get to know the design and architecture when you must read and most importantly understand the code around the bug. After understanding the code around the bug, you can fix it without breaking something else. It really is the best way to understand the system behind the use case as a whole.  Reading some out-of date design/architecture documentation just doesn’t tell the same story as the code does.

Second benefit is that when you have fixed some bugs, you start to get familiar with the patterns and style that other developers have used through out the code.

Finally, when it is time to add new functionality, you a) know how to fit it into the system, and b) your fellow coders understand what you wrote, because the style (hopefully is similar)