Short Review of "The Productive Programmer"

I have just finished reading the book "The Productive Programmer" by Neal Ford. For those it may concern; this is a short review of this book.

The first thing that struck me is that the book was not very thick. In my eyes this is a good thing. I have seen to many bloated books, that does have a problem to focus on the subject at hand. It appears that the book is inspired by the excellent book "The Pragmatic Programmer" by Andy Hunt & Dave Thomas. In fact it is recommended by Neal Ford.

The book consists of two parts; "Mechanics" & "Practice". The "Mechanics" part is about the tools you should use, and some tips & tricks on how to use them. For example, there are examples on how you could use Ant for more than building your software. The section "Focus" is the most interesting section. This is where you learn how to kill distractions, something along the lines of "Gettings Things Done" by David Allen.

The "Practice" part contains some best practices that Neal consider important to know, like Test Driven Design. I really like the YAGNI section, where YAGNI stands for "You Ain't Going To Need It". This part is all about a problem that many developers has encountered, namely speculative programming. For example, a class that contains "good to have"-methods, that is there to be future proof. The leason is; do not add anything that you do not need because "You Ain't Going To Need It". This is not something new, but it is still a common problem. Another section of the "Practice" part is the "Ancient Philosopheres". Neal uses ancient knowledge and adopts it software development. This is an unusual approach that I really liked.

If you want to be a more productive programmer, this is a good start. The book is short and easy to read. No fluff, just stuff kind of book.

Öredev 2008: Android, Blackberry & Clean Code

The last day of Öredev 2008 started with a keynote by Robert C Martin (the picture above). It feels hard for me to reproduce the content of the keynote. His session about "Clean Code" was a little bit more tangible. He showed an example on how to simplify a method, and decompose into several small methods. The final example was very, very simple. The session gave me a new perspective on how to write good code. Maybe it is time to clean up some of my code?

I have never tried to develop for a BlackBerry device. The primary reason is that BlackBerry devices are not very common here in Sweden. Anyhow I thought it would be interesting to know a little bit more about the BlackBerry development. One thing that impressed me was that how Java friendly the device is. Every "native" application is written in Java. As a consequence all the APIs are written in Java. If you were to develop a Java application for a Symbian device you would be limited when writing your application in Java ME, since not all the APIs are reachable from Java. On many mobile devices the Java applications are hidden somewhere deep inside some strange folder. This means that your Java ME applications are some kind of "second class citizen". On a BlackBerry on the other hand, the Java ME applications that you write is as important as the pre-loaded applications. Really nice! If there is a new feature, like GPS, it is immediately available for you as a developer. That is not the case when developing for a lot of other mobile devices. The development environment seems to be pretty mature, including such stuff as memory statistics and a profiler.

A new kid on the block in Java world is the Android Open Source platform. For those of you that have not heard of it; it is a new mobile platform. It is developed by the Open Handset Alliance, which consists of many mobile operators, mobile manufacturers and software companies. The most famous company of this bunch is probably Google Inc. As mentioned it is Open Source, which gives a lot of new possibilities. For example, it could be possible to port it to any kind of embedded device. The Android platform is based on a Linux kernel. On top of that we have a Dalvik VM. You develop your application in Java and compiles to a Dalvik executable. Although it is not considered as Java by definition, you as a Java developer hardly notice any difference. The API is based in Java v1.5, with some unwanted APIs removed. As of today there are not many Android devices available, but inevitably there will be some more devices real soon. The Androiod platform seems to be targeted at the smartphone segment.

Before the last session it was time to attend a lottery draw. To be a part of the lottery you would have to solve a developer scrabble, which I did. Believe it or not, I won a brand new Eee PC 901. A real nice piece of equipment, although I have not tried it extensively. I guess it is nice to have when you are on the road.

Here are the rest of the photos from day 3 at Öredev 2008:

The Android session was pretty cool.

This shows how wrong it can get when a critical application fails. From the presentation by Kevlin Henney.

Kevlin Henney in action.

Öredev 2008: Agile, Scrum & Boom Chicago

The 2nd day of Öredev was very long and thrilling. As a change I attended a lot of non-technical sessions. The first session was called "Scrum @ Yahoo" held by Gabrielle Benefield. She presented her own story about the introduction of Scrum within Yahoo. The story was presented in a funny and intense way. One thing that struck me was that the managers was afraid to loose their jobs when introducing Scrum. As she pointed out correctly; Scrum is very developer centric. For some reason I have never done this reflection. The same concern was also raised by Allan Kelly. But they seemed to have the same opinion; the managers should not be afraid of loosing their jobs. The most funny slide from Gabrielles session was the one above. This tells a lot about the power of Scrum.

During the day I had the privilege to meet up with Terrence Barr in person. He is a Sun Evangelist and Ambassador for the Mobile and Embedded Community. We had some interesting discussions about Microlog, the Mobile and Embedded Community and about the Java ME Open Source community in general.

We ended of the evening with some refreshing drinks and snacks. The improvisation group Boom Chicago entertained us with an funny interactive show. After the show I was pretty tired and got home rather early.

Here are the rest of the photos from day 2 at Öredev 2008:


Terrence Barr and me at the Öredev entrance.

Learn the Scrum way from Gabrielle Benefields presentation. Note; this is not the way Scrum should be introduced.

The keynote speaker of the 2nd day; James Bach.

James Bach showing a photo of where his laptop last was seen, namely the the central station in Stockholm, Sweden. He was a little bit disappointed that there was no swedish polices at the station on a Sunday afternoon.

The Boom Chicago group entertaining us.

"Mick Jagger" and "Amy Winehouse".

Öredev 2008: Sun SPOT, Buglabs, Sun Java ME SDK , Benefits of Open Source Development etc

The first day of Öredev 2008 is over. It has been an interesting day, with many new impressions. There are a lot of exciting things happening within the Java ME community right now. The Java ME platform is becoming available on a numerous platforms and in different flavors. I really liked the Sun SPOT device when it was announced at JavaOne 2006, and the BUG demonstration today was impressive. Both these devices triggers a real "must have now" feeling. If you ever had the opportunity to try out the Sun SPOT, you know what I mean.

Sun SPOT in action at the Waygroup stand. The robot is about to knock down the Jayway mug.

I must remind you all that Microlog works on Sun SPOT out-of-the-box, and has some special classes for Sun SPOT development. These classes are merged from the Microlog4SPOT project.

Another new attention-grabbing technology is the JavaFX framework. Before the presentation I did not have deep knowledge of what it was, but now I think that I have grasped the vital parts of JavaFX. It could be seen as a new Java platform that is put on top of the existing Java platform. It is kind of write once, run everywhere but with a new twist. Looking forward to try it out.

A tool I would like to try out is the new Sun Java ME SDK. It is available as an early access release today. According to the people from Sun the 1.0 release should be available in the beginning of 2009. The new Java ME SDK is a combination of the Sun Wireless Toolkit and the CDC Toolkit. It has been re-worked and uses the Netbeans framework as its foundation. The aim is to have a tool that is useful for all Java ME development. As such it has support for Blu-ray development.

There was also a session about LWUIT, the new UI Toolkit from Sun. It could be used as a better version of the LCDUI. It is inspired by the Swing toolkit, but for Java ME. Please take a look at my article about the LWUIT Makeover demo. I believe there will be reasons to watch out for LWUIT.

Here are some additional pictures from Öredev 2008:

A couple of minutes before the first keynote speech with Ted Neward from ThoughtWorks.

The official Microlog t-shirt. This is a limited edition only used by a couple of developers in the world.

All the mugs knocked out. Again we see the Sun SPOT in action.

A LEGO Mindstorm NXT waiting for some action.

Some advantages of Open Source Software in development.

Some more advantages of Open Source Software in development.

Improving your Java Source Code with Open Source Code Analysis Tools; FindBugs, Lint4j & CheckStyle

One of the best way to improve your own code is by looking at other peoples code. Another way to be a world class programmer is to use a source code analysis tool, like FindBugs, Lint4j, CheckStyle. Here is a short & compendious summary of these tools.

FindBugs

This is my favorite source code analyzer, simply because it tends to find the most horribly, awful bugs. FindBugs is based on the concept of bug patterns. A bug pattern is a pattern in your code that implies a bug. The FindBugs tool is initially developed at The University of Maryland. According to Professor William Pugh, "Students are good bug generators". As such many of the students mistakes has generated a new bug detector implementation. One might think that these are mistakes only made by beginners, but as it turns out many of these problems are also part of production code. For example, the FindBugs tool was used on the Sun JDK and it found some serious bugs.

The FindBugs tool is available as a stand-alone GUI, Ant, Eclipse and Maven plugins. During development I prefer to use a plugin in my IDE, which in my case is Eclipse. The source code analyzer should also be a part of the build process.

For all the newcomers to Eclipse, this is how you install the FindBugs plugin from the update site:

1. Select menu "Help" -> "Software Updates" -> "Find and Install..."
2. Select "Search for new features to install" and press the "Next" button.
3. Press the "New Remote Site..." button.
4. Enter your name for the update site, for example "FindBugs Update Site", and enter the following into the URL field: http://findbugs.cs.umd.edu/eclipse
   Press the "OK" button
5. Press the "Finish" button. Eclipse will now contact the update site and check for the latest version.
6. After a while you will get a list with the features that are available to you. Press the "Next" button until you get to the "Install" page. Press the "Finish" button.
   
7. When you get to the "Verification" page, press the "Install" button.
8. Eclipse will now run the "Update Manager" and download the plugin.
9. When everything is finished, you will be prompted to restart Eclipse. Please press "Yes" and Eclipse will be restarted.

When you have installed it, you will have an extra context menu like this;


Select this menu and within seconds you will have a list of potential problems in your code. These are all gathered together with the compiler warnings. When you click on a warning, your code will be displayed with a bug:


Double-click on the bug and you get an explanation on what the warning really means:


Now you could start figuring out what to do with the warnings. Hopefully FindBugs has found some bugs for you.

Here is where you find more information about FindBugs:

• FindBugs homepage
  
• The FindBugs Eclipse update site
  
• FindBugs Blog

CheckStyle

As the name implies, CheckStyle check the style of code. For example, it can check if you follow the Sun Java Code Convention. But CheckStyle can find more than this. It contains a multitude of rules that are considered bad programming practices. Some are very common, and others are a little bit more doubtful. In other words CheckStyle is not really in the same category as FindBugs, but I find it a tool that is worth having in your Java programmer toolbox. Installation of the CheckStyle Eclipse plugin is made the same way as with FindBugs, but you use another link (found below).

Here is where you find more information about CheckStyle:

• CheckStyle homepage
• The Eclipse CheckStyle plugin (that I use)

Lint4j

The Lint4j tool is a tool that is similar to the famous lint tool for the C programming language. I have not used it very much, but it have found some code that smelled badly. When I have used it for a while I will communicate my opinions to you.

Here is where you find more information about Lint4j:

• Lint4j
  

Some Final Words

Here are some final words of advice

• Use it from the start of your project. Otherwise you could be overwhelmed by the enormous pile of things that you should correct.
• Do not use full checking from the beginning, start by using the default settings. When you have checked your code you could add the checks that you find useful.
• Do not check in your code without running your source code analyzer.
  
• Add code checking as part of your continuous build process. Your build should not fail when it detects some problem(s). The reports could be used to ensure that nobody check in code that is bad.
  
• Use common sense, you should not obey the tool relentlessly without questioning. The FindBugs tools is the most effective, but sometime it indicates things that are not really a bug. Use the filtering capabilities found in the tools to filter out what is not relevant. This let you focus on the real bugs.
  
• A source code analysis tool should not replace other good practices like unit testing and code reviews. These are all complementary tools to make your code close to perfect, and avoid those nasty bugs.
  

I hope these tips will help you to improve your code, and will make you a better programmer.

Happy bug hunting!

Yet Another Microlog 1.1.0 Snapshot is Available for Download

I have released yet another 1.1.0 snapshot release of Microlog. It contains very few, but important changes. To ease you from the pain of using the source repository, I prefer to make snapshot releases as often as possible.

Important changes:

• Performance improvements: the Microlog core has been optimized for speed.
• The level checking code was not working correct. This is now corrected.

Please download the snapshot release.

Using Eclipse MTJ for Java ME (J2ME) Development

A while ago I was experiencing pre-verification problems with EclipseME. Rather annoying I must say. I spent several useless hours before getting it right. This is when I decided to upgrade to Eclipse Mobile Tools for Java (MTJ), even though it has not reached v1.0.

Eclipse MTJ is the official Eclipse plugin for Java ME (J2ME) development. I was started several years ago, but did for some unknown reason never took off. On the other hand, EclipseME, developed by Craig Setera, was actively developed. I must say that I am impressed by the work Craig has done with EclipseME. Fortunately foundation did something about the situation with Eclipse MTJ; they started "from scratch" with the source code. They imported the EclipseME code into the Eclipse MTJ project, which replaced the old code.

You might wonder what are the reasons for using the Eclipse MTJ. First of all I have not had any problems with the pre-verification since I upgraded, which save me a lot of time. There are numerous bugs that has been removed, and the environment feels more stable. Another reason is that all of the Java ME specific menus is easier to access. For example; the Java ME project wizard is accessible at the same level a standard Java project. I believe that it is important to support great open source project like this. One of the best way to do so, is by using it and providing feedback.

For those of you that already have EclipseME installed I recommend the article "Converting to Eclipse Mobile Tools for Java". The rest of the bunch could use the same article, but skip the migration part.

How I Created the Microsuite Website with Google Sites

I have been thinking about creating the Microsuite website for a long time. In fact it was several months ago that I registered the domain microsuite.org. The thing is that it does not amuse me very much to create websites. The latest couple of months has been filled with a lot of more interesting stuff. It has been very hard for me to prioritize between all the projects that I am involved in. There are still a lot of work with Microlog, there are many ideas that I want to try out for Microinstall, and I also want to be an active part of the Voxtr project. So on, and so fourth.

Just the other day I ran across Google Sites. It is a service that is built on top of a wiki software, formerly known as JotSpot. But you do not need to know any HTML at all :) At least that is what they claim on the Google site information pages. So this seemed like a perfect choice for me. I already knew what information I wanted to put on the site, so it was merely some hard work that was ahead of me. My experience it that computer related stuff does not always takes the time you wish it would do. Most of the time it takes much longer than expected, at least when you try something new. To my surprise this was an exception. I spent only one evening creating the first version. Rather nice!

For those of you that has not visited the Microsuite website, I can tell you a little bit about what it is. The Microsuite is a collection of the Micro projects that I am involved in. To this date they are; Microlog, Microinstall & Microproperties. Microlog is a logging tool for Java ME developers. Microinstall consists of some small classes that makes it easy to distribute your MIDlet(s). The Microproperties project has not yet delivered any code, but the intention is to create a good properties framework for Java ME. The plan is to create the code from scratch, with some inspiration from the properties classes found in Microlog. Please visit the Microsuite website to find out more about the different projects that are part of Microsuite.

Blog Post on Mobile & Embedded Community

I am proud and happy to announce that my blog post "Upgrading Voxtr with Microlog" has been featured on the Mobile and Embedded Community.

The Mobile and Embedded Community is a Java ME community for us developers. It consists of forums, blogs, some interesting podcasts etc. There is also a lot of open source projects. I regularly visit the forums and the blogs.

LWUIT Makeover demo

Ever since I heard about LWUIT for the first time, I have been following its progress. The LWUIT toolkit is an alternative to LCDUI. It is inspired by Swing, but is not a port of Swing. If you are looking for a port of Swing, take a look at JSR-209 "Advanced Graphics and User Interface Optional Package for J2ME Platform". I have not heard of any phone that implements JSR-209, but the SavaJE phone, which is not in production. But LWUIT is reality today. Since I consider myself as a fluent writer in Swing-lish, it was easy for me to get started with LWUIT. But I must admit that I have not done any real projects with LWUIT yet, but I have tried it out. It looks rather promising. Today I noticed a new LWUIT demo that was rather impressive.

What do you think about LWUIT?

Upgrading Voxtr with Microlog

What a sin! I am involved in the Voxtr open source project. The initial code was not made by me, so I found those awful System.out.println() statements. But fear no more; The Voxtr has been upgraded with Microlog.

I would like to take the opportunity to describe how simple it is to use Microlog. First of all you must download Microlog. Next up is to unzip the file that you downloaded. The included microlog.jar must be copied to your project and added to your buildpath. How this is done, depends on your development enviroment.

The second step is to setup Microlog. I prefer to use a properties file. The biggest advantage is that you do not need to change any code when you want to change your Microlog settings. Use the supplied file that is called microlog.properties. Copy this to the source root of your project or to your resource folder if you have one. To configure Microlog using the properties file you add the following code to your main class, which in most cases is the MIDlet class. The setup code looks like this:

Properties properties = new Properties();
log.configure(properties);

Microlog is now configured according to the settings in your microlog.properties file. In each class that you like to do some logging, you add the following code:

private final static Logger log = Logger.getLogger();

public void someMethod(){
// Do the actual logging
log.debug("MicroLog is working!");
}

That is it! Insert logging statements where you would normally put System.out.println() statements.

What good is all the logging if you do not know how to view the log? In this example, the logging is done in two destinations. The ConsoleAppender outputs to the same place all your System.out.println() would go. If you run your MIDlet in the emulator, the output is shown in some kind of console. In Eclipse, this is the "Console" view. The second output destination is the recordstore. To view it you use the RecordStoreLogViewer. Add the RecordStoreLogViewer MIDlet to the JAD file. When you have executed your main MIDlet, it is just a matter of switching to the RecordStoreLogViewer MIDlet. Select the "Load" item in the menu and the log is loaded on the screen. The image below shows the RecordStoreLogViewer with Voxtr log data.

What I have shown here is the setup that I recommend that you start with. The ConsoleAppender is good when using the emulator, and the RecordStoreAppender is good when executing on the target device. This is the default settings in the supplied microlog.properties file. When it is time to do field test, or similar, it is recommended that you start using one of the off-device appenders, for example the MMSAppender. The MMSAppender could be used to send MMS and/or e-mails to the addresses of your choice. Other choices are the Amazon S3 appenders which I have blogged about earlier. I will not go into more details about the off-device appenders right now, I will save it for later. Stay tuned!