Head On

Jonathan Ive on understanding customers: “‘We don’t have to take this great intuitive leap to understand the mythical concerns of our users, because we are the users.’”

That sure helps.

There is an iPhone for sale on the swedish site Blocket:

Funny part translated from swedish: “… I can include the telephone number to my friend who helped me unlock it”

I am following the keynote via IRC and MacRumoursLive. Why am I like so many others totally intrigued by this? I suppose a lot of people would say that it is the gadget freak in me who wants to own everything coming out of Cupertino. But to me, this is not about the gadgets per se. It is about seeing progress being made, Others make progress as well, but nobody packages it as well as Apple does.

This tutorial on RubyOSA is great. I have never got around to learn AppleScript, and now it seems like I never will.

I was listening to the podcast of the interview with Steve Jobs and Bill Gates, and this one thing struck me. When asked to predict the future, Bill Gates provided some insightful guesses, while Steve Jobs simply answered “I don’t know”. Twice. Steve’s explanation was that five years ago he would not have predicted what we have today, so therefore he does not trust himself to say what the next five years will look like.

I have previously spotted Apple to be early agilists, and Steve’s position here enforces my claim.

One important aspect of grasping agile in my mind is to accept the fact that you cannot predict the unpredictable. Instead of making detailed plans to support the illusion that you know what is going to happen, you say “I don’t know”, but then let that knowledge, that you actually do not know be the base for how you approach your work.

I have many times been faced with the quest of predicting the future, “how long will it take?”. As I have become more experienced I have learned to say “I don’t know”, of course at the same time offering an alternative iterative approach that will eventually provide knowledge for better estimation. Sometimes that is not a popular answer, and the question is forwarded to someone who will answer it. Of course, they do not know, but the illusion of control is very powerful, so their answer is better received.

I guess that many CEO are pressed to predict the future, by employees, share holders etc. And many times they probably provide an answer that they themselves do not believe in. It appears to me that Steve Jobs does not fall into that category.

This is written on a spanking new MacBook Pro, the 2.33 GHz, 2GB version. Company issued, mind you. Now if that is not a good reason to work for Valtech, I do not know what is.

The main reason I upgraded from my trusty 1.67 GHz G4 PowerBook was not speed, it was the possibilities of Parallels. I do quite a bit of evaluating and demoing of server configurations, and having it all available locally is a complete killer.

The first virtual install was Buildix to convince a customer that Subversion and Trac is a viable platform.

But of course it is wroooom-fast. Extremely responsive, and not hot. I currently have it in my lap - no problems what so ever.

I switch browsers like others switch … something they switch very often. Why does it have to be so hard? All I want is a browser that:

• Is small and nimble
• Feels like a Mac application
• Has good ad blocking support
• Handles Flash on demand

Safari locks up too often, and a number of sites do not work with it. Shiira is small and nice, but has no decent ad blocking. Firefox has lousy Mac integration and eats memory like there is no tomorrow. Flock just does not feel ready yet. OmniWeb has clunky ad blocking and is not worth the money.

My current choice is Camino. It is lightweight and Macish but has terrible, CSS-based, out-of-the-box adblocking. But with the help of CamiTools that can be fixed and you also get the flash handled.

Who knows, I might even be using next week.

I am seeing signs in the sky that Sun is making a comeback.

• Textdrive is switching from FreeBSD to Solaris
• Rumors that ZFS might be ported to Mac OS X
• Tim Brays presence and statements on the RoR podcast from Canada on Rails
• Sun makes smart moves like supporting PostgreSQL

And not one of them is related to Java.

After getting the PowerBook, I’ve made quite a few additional switches in my digital life:

• Mac Mini instead of a PC with Ubuntu Linux at home. After a few weeks with a Mac at work, I could no longer live without one at home, so whoops, there it is: a Mac Mini. It is oh so quiet.
• NetNewsWire instead of Bloglines. I have not visited my previous darling Bloglines once since I started using NetNewsWire
• TextMate instead if JEdit, Vi, Emacs … it rocks.
• iTunes and iPod instead of rsync and iRiver. I’m not addicted - right

I’ve created a Gnome Panel Applet to monitor Luntbuild builds. This is basically a spike to try out the Ruby-GTK2 library and the Luntbuild API but it works so I might as well release it.

Download

Mike Clark at Pragmatic Automation blogs about a new CruiseControl widget to monitor CruiseControl Builds by using the new Tiger widget thingys.

Funny enough that I’ve spent some time meddling with something similar for Luntbuild and Gnome. But I have to say, that as far as graphics go, I have some catching up to do.

Alef Arendsen ponders on whether to switch from Ant to a Ruby build tool. At Lecando we just this week finished migrating away from a Ruby based build system we called Raven. Our former employee HÃ¥kan speaks in his blog entry from way back then about the enthusiasm we shared. Of course, HÃ¥kan speaks of our migration from Maven, the build tool from hell of which one should not speak.

So we’ve now gone full circle - Ant - Maven - Raven - Ant. So what happened and why?

Our build.xml used to be a trillion lines long and quite unmaintainable. When we first saw Maven we thought “Easy targets due to standard directory organization, automatic dependency downloads and we will probably read that really nice webpage thingy very often. Way cool, we want that”. Since we never have hesitated to throw new fun explosive stuff onto our e-learning fire we pushed all our directories around, picked up the ball and ran with it.

I looked at our old project.xml file today. Man, that thing is ugly. As Cedric points out, Maven is really four languages, and Jelly is one of them. Ouch.

At that time we were bitten by the Ruby bug due to a number of reasons, two of them being Jon, head chef of Damage Control who had just left us for new frontiers, and Anders Bengtsson who used to work for us but is still a good friend of some of the guys. This combined with our craving for a shiny new build system made us roll up our sleeves and start to build our own build system in Ruby, Raven.

When you start to build a new file system you most probably start with the easy pieces. “Let’s see … compile? That’s good - we need to compile in our projects. And we can set our classpath in a really non-obtrusive way. Oh, this feels so good, I’m glad we’re doing this. And next … Test? Awesome, we’ll be done in no time.”

… A little later …

“OK. it is not a good as in the beginning but we’ll refactor it. Now we just need to build the docbook docs, package the war, pack it up in a ear, zip that up with all external docs and whatnots and we’re done.”

Spoiler: The resulting build was as hard to maintain as the previous ones had been, albeit in a prettier syntax.

I believe it is exactly the same thing as when you start out with your Ant build file. As long as you’re setting up the compile and test part everything is really clean, but when you get into the specifics that is needed for your app like for example signing an applet - we used to do that - things get dirty. And it does not matter what language you do it in, it is complicated even in plain English, or Swedish. (”Take those files and sign them with that certificate file over there to produce an applet as a jar for Netscape, and when your done you take the same files and sign them again, but this time with that certificate file over there for Explorer, and, oh yeah, make it a CAB file. Don’t mess up or the browser barfs”)

While we were doing this, things happened in Ant land. Imports and Macrodefs solved a lot of problems, making build files readable. IDEA even provides code completion and refactoring support for Ant. As you might suspect, we did not have that for Raven. We slowly accepted fate and began the walk back into XML. However, among the brackets are a few goodies in addition to the ones above.

Ants platform independency is king. Visar, our designer guy, can run the app from his Windows box as well as we do on our Linux ones. I know, Ruby is supposed to be platform independent, but unfortunately it works in the same way Python does it - almost.

We have even rolled our own CruiseControl in Ruby. We really did not like CruiseControl two years ago so we might not use it now either, but at least now we have the choice. I’ve read a lot of good things about it recently and if it is good enough for Mike Clark it must be good enough for us as well.

To sum it up, Ant is a standard which in itself might not be the best thing at all, but with all the support for it it certainly comes out on top for us.

Bernard replies to my reply:

[Me]My thoughts were that it is easier to transform bare data as it is less to transform. You take the old data and insert it into the new code, which is all you need because you don't want the old implementation anyway.

[Bernard]I guess you are somehow comparing apples and oranges. If you want to compare data storage then instead of storing Java objects with data and business logic, just store some objects having data only.

Sure, if you store objects with only data you are quite close to the tabular data model. But remember, I only want to be able to “offer” it for OLAP purposes and for upgrades, if then.

I don't want to degrade my business objects, I want them to carry as much info as possible. This to ensure that the state is all set and verified before the Command executes, as discussed on the Prevayler site.

To sum up the upgrade story: when moving an application between version, the persistent state needs to be transformed. The less info in the persistent model, the less to transform. That is why I, initially, believe that the tabular data model is good for upgrades. But as mentioned, I'm intrigued by the XSL approach, and we will most certainly try it out.

[Me]However, we may have to provide a tabular data model for analysis purposes outside the scope of our application. The standard way to access this is using SQL. This is the only reason I want it.

[Bernard]At least if your external application could use JCA you could think of a JCA implementation for Prevayler.

Very nice thought. We want to provide as a broad support for data extraction as possible which probably would make a connector a good choice.

[me]This morning Jon had a good way of formulating what I wrote on the two persistence needs: “RDBMS do two things: OnLine Transaction Processing and OnLine Analysis Processing. After Prevayler we only need OLAP.”

Agree. This is an empty room for Prevayler. We might have a look at some integration with Mondrian which is rougly a Java OLAP implementation working in-memory.

Mondrian looks way cool. Will look into it more.