Agile methods

Another interesting article by Martin Fowler: The New Methodology (and again I’m several months late). The predecessor of this article in 2000 was equally interesting. In fact it still is. If you have the time, read both of them.

Martin Fowler, Kent Beck, Erich Gamma and other people of that generation have greatly influenced the way I think about software engineering. I’ve been a scholar in software engineering and currently my work at Nokia also involves a great deal of software engineering research. I see these guys as the pragmatic force driving the industry forward. While we scholars are babbling about Model Driven Architectures, Architecture Description Languages, our ivory towers, these guys are all “stuff and no fluff”. It’s a good thing to once in a while consider that many of the software engineering research community ideas and concepts in the past have done and continue to do a lot of damage. For example, the waterfall model (the mother of all software development methodology) is still being taught in universities. Out of touch SE teachers still teach their students to do things one after the other (instead of iteratively).

The original papers on the waterfall model, iterative development and related methodology from the seventies are an interesting read. Their authors had a lot more vision than past and present proponents of these methods. But they are just that: the vision of software developers coming out of the cold in the seventies. We’ve learned a lot since.

If there’s one thing you can learn from Martin Fowler, Kent Beck or Alistair Cockburn, it is that you should never ever implement their methodology to the letter. If you are doing so, you didn’t get it. Agile is all about change, including changing the way you work on permanent basis. The article I’m citing presently argues this in Martin Fowler’s usual clear fashion. Go read it already.

Intentional Software

From a very interesting article by Martin Fowler:

I’ve had the opportunity to spend a little time with Intentional Software and several of my colleagues at ThoughtWorks have worked closely with Intentional over the last year or so. As a result I’ve had the opportunity to peek behind the Intentional curtain – although I’m restricted in how much I can say about what I saw there. Fortunately they intend to start opening up about their work over the next year or so.

Whoohoo! I’ve been following the developments around this company for a few years now. Charles Simonyi is mostly known for being one of the influential architects at Microsoft responsible for creating and popularizing such things as WYSIWYG editing, Excell and the Hungarian notation. Simply put, the guy is brilliant. A brilliant guy with a vision: intentional programming/software. Working for Microsoft from the beginning, he is one of their richer Microsoft millionnaires/billionaires ™. A few years ago he quit his job at Microsoft to start his own company called Intentional Software. Before that he published a few articles on intentional programming which, frankly, include some ideas that are way beyond the imagination of the average C/C++/Java/C#/whatever programmer. While these guys fight over such petty things as syntax, he made it a first class entity in his programming environment. Intentional programming is all about translating intentions to working code. If doing C++ style templates is your intention, define them in the core constructs provided by the intentional programming environment and write them.
But what am I doing, trying to summarize Martin Fowler’s excellent article into one paragraph. Go read his article. It will take you some time but it will be time well spent.

I’ve been a long time fan of Martin Fowler. I should check his site more often.

Netbeans 5.0 first impressions

With much fanfare (at least on the various Java news sites), Sun has launched its latest edition of netbeans. Netbeans 5.0 is a significant improvement over 4.x. 4.x basically improved the UI to the point where it was reasonably fast and usable. 5.x consolidates the improvements by adding (a lot of) depth to the featurework in 4.x. A new component that is mentioned in every review is Mattisse, the GUI builder. I had a brief session with this thing with one of the betas a few weeks ago. It’s definately a very nice tool. Unlike most GUI builders (including most previous generations of netbeans and the eclipse GUI builder) this one doesn’t suck, most of the time. I’ve had too much exposure to Swing over the past decade to not code my GUIs manually but for someone not so familiar with Swing this is actually quite usable.
Last week I downloaded and installed the release at work. Since I now work for Nokia I, decided to give the mobility pack a spin. The rest of this review is about my impressions using this part of netbeans. The mobility pack basically includes sun’s toolkit (libraries, emulator) and integrates this into netbeans. Overall it is a pretty impressive thing. I have had exactly 0 experience with building J2ME stuff. Just to see where I would end up I started a hello world mobile project.

I was positively surprised at the level of usability the mobile pack offers. The project setup generates a build file for you that basically does all the difficult stuff (like creating a deployable jar that you can install on midp phone). Buildfiles in general are well integrated into netbeans (unlike eclipse). Basically building your project means calling the appropriate ant target. You can do this by selecting the option from the menu, right clicking on your project, etc.

After completing the new project wizard, netbeans had generated a nice Visual Midp class for me. The word visual means that you can edit the midp client in a visual environment. This environment is pretty powerful and will probably suit most basic needs. Essentially you drag and drop a various types of screens in a flow. Then you add actions to each of the screens and finally draw some arrows between the screens. At this point you can actually run the application in the emulator (or a real phone) and you will be able to navigate through the screens that were just defined. For the record, you don’t need to write any code to get to this point.

The flow view has a nice other use: it is a perfect companion to a functional specification. Just add a little information on the semantics of all the actions and you’re basically done (with the functional spec). It’s also great for prototyping. You can just click a bunch of screens together and have a live demo on a mobile phone in no time.

Then  we come to library dependencies. Basically any java project will end up using several external libraries. In eclipse they have to be in your project and then you can add them to the classpatth, alternatively you can define external libraries. In Netbeans there’s the library manager where you define libraries. A library may be a project (in which case netbeans automatically figures out that it should use the jar in the dist dir) or a jar file you downloaded. You can also associate source folders and javadoc with the library. Once you have libraries defined, you can edit the project properties and add library dependencies. That’s it. If you do a build of your (mobile) project, netbeans will automagically pull together all libraries and generate one big jar file with everything in it. It will even build projects if the source code is newer than the library. Nice. Eclipse sort of has the same functionality but the netbeans UI for this is simply much better and usable.
So far, I really like Netbeans 5.0. Now we come to the parts that are not so fun. Coding. The code editor in netbeans still sucks. Sure, it has been improved over netbeans 4.x. It is noticably faster with things like autocompletion. The problem is that it is pretty stupid compared to what I am used to: eclipse. Eclipse has whole bunch of editor features that are simply missing from netbeans. You can’t do the “extract local expression” refactoring (alt+shift+l) which means that you have to do that manually (which I never ever do in eclipse). This probably my number 1 missing feature. Several other refactorings are missing. Then there are no quick fixes. So if you write some code that throws an exception you cannot add a catchblock to the try catch you already have. Neither can you add a throws clause. These are just two of the many quickfixes that eclipse has. Templates are implemented but much less functional. I just love typing for and then ctrl + space to generate a foreach for some collection (or select alternative means to iterate over whatever is iteratable in your code). It’s just not there. It will generate a for loop but you still have to fill everything in yourself. There are lots of other features that anyone familiar with eclipse will miss.
In short if your primary task is writing code, stick to eclipse. If you need wizards (mobile and supposedly the J2EE stuff is excellent as well), netbeans may be a better option. You’ll be spending much more time on your code but may still be more productive due to all the convenient stuff that netbeans does for you.

Personally, I’m still in the eclipse camp. It’s just that I am working on this toy midp client at work so I prefer netbeans for this project. For netbeans to win me over permanently they will basically have to add tons of features to the code editor. This being said, the improvements in netbeans are worth some attention from any java developer. It’s nice to see some stuff working that is basically broken (or unsuable, which is the same thing practically) in eclipse. Both projects still have a lot to learn from each other.

more on opera mini

The reason my previous blog post was rather short was that I was running into the maximum amount of character limit imposed by opera mini. I think it’s a bit odd to have this limit for a textarea but I suppose there’s a reason for it.

Anyway, I really like this browser. It’s good enough that you can actually load the wordpress userinterface in it. It’s even usable! Though navigating it is a bit hard because opera mini basically transforms the page into a one column layout intended for small screens. So that means that all the controls are on a separate row. This works best for pages that are accessible and have the important content before the navigation. Of course the content of the wordpress userinterface is the various controls and there are a lot of those (30+)!

Other sites I tried were the new york times, slashdot,,,,, (some of these sites are dutch). They all rendered fine and very fast compared to the native browser of my phone (renders the full page). Whatever opera is doing is working really well. Of course some sites have poor accessibility. For example, the nyt frontpage is a mess of advertisements, links and two line page introductions. When you squeeze that into opera mobile the result is not pretty and it is pretty hard to find your way through this mess.

The message is simple: if you want your websites to be usable on the soon to explode mobile internet market (and why wouldn’t you want that?) you will have to adopt xhtml  non table based layouts and conform to accessibility guidelines. Incidentally, this will also boost your google ranking. Basically google can be compared to a screenreader. Compared to a blind person using a screenreader it is actually pretty stupid. You need to point out what is important by using semantic html rather than font tags. If everything is a div or plain text in table cells decorated with css or font tags then you have no semantic information in the page. This will make it hard for google to separate the relevant information (like the title header of your page, important keywords in the text that you bothered to highlight) from the irrelevant stuff (navigation, footer, etc.). It will also make it hard for screenreaders to transform it into something readable and it will be totally unusable on hundreds of millions of mobile phones.
Of the sites listed above opera mini did a reasonable job. It did as much as can reasonably expected of it. I’ve used opera’s full mobile browser as well, it does a slightly better job. Opera mini does most of the processing serverside however. This has two important advantages: less content is sent to the phone and the phone spends less time rendering. Both these things save a lot of time. Using opera mini was the first time I had an acceptable browsing experience on a mobile phone. Pages download in seconds instead of minutes. The back button actually works pretty well. So does the cache (so you can go back and forth between the frontpage and articles linked on the frontpage) in a reasonable timeframe.

The user interface is pretty good (though clearly not designed for the nokia 9300 which has a widescreen (half vga) with the navigation buttons on the side instead of the usual narrow screen on most phones. The formfactor is actually really good for browsing and reading websites. A particular problem was that the menu button on the phone was not integrated with the browser menu. So there are two different application menus one activated with one of the navigation keys and one activated with the menu key. Also some of the keys have an unexpected result. The full keyboard features an escape button which usually can be used as cancel button. Using it when entering a url it actually behaves like an OK button.

Despite these minor annoyances, I intend to keep this browser. I like it.

opera mini

i am trying out the mini opera browser right now. as in posting this from my nokia 9300. excuses for the la.k of capitals, pressing shift an another key is a bit difficult on this keyboard. anyway, opera mini is the first usable, mobile browser i have encountered. It consists of a server that optizes the page for mobile viewing and a midp browser that displays it.