Mmm … Powerbook.

Thursday, August 18th, 2005

Wow. I am back in Mac land, which I left in 1996 when I started my career at IBM and turned into a PC drone. Now, after four days of pure Mac joy, it feels like I am never going back.

This also goes to show what a cool company Valtech is. I mentioned this to Jon who got really jealous. Apparently the Thoughtworkers get company issued Dells and all Mac stuff is paid for by themselves.

Widgets monitoring automated builds

Friday, June 3rd, 2005

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

The Mac CC Widget

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.

lbapplet-0.0.1

Hackers & Painters

Monday, April 11th, 2005

Like so many others, I have read Hackers and Painters by Paul Graham. And, surprise, I find it highly recommendable, like everybody else. The following are a few thoughts about I jotted down while reading:

  • Why, oh why, in the name of mad page flipping are the footnotes placed in the back?
  • I am surprised that Pete McBreen of Software Craftmanship fame is not mentioned - in my opinion they are making the same case against “Computer Science”
  • Contrary to common XP belief Paul Graham favors code ownership. Quite unusual in this day and age, and interesting - I need to reflect on it more.
  • His thoughts on developers needing empathy are spot on. Not only for the end users but also for the later developers. It is also better to tell a developer to see things from somebody elses view and document accordingly instead of having him follow the RUP Deliverable Tablets of Stone without reflection.
  • Hosting your own web application - I wish. Companies today still see the intranet as something that should be inside their own, very physical, walls. And I can’t blame them - at Lecando we run our own JIRA, Confluence, SugarCRM etcetera in house. It hit me though when thinking about this - what would we choose if Atlassian offered a hosted JIRA at a competitive price? What if that was the only way they offered their solution? Would JIRA be developed faster since they did not have to worry about releases and customers maintenance problems, or would they spend that time managing the server park?
  • Paul Graham makes a very strong case for capitalism. Whatever your view on politics - I believe that the starting part of the Wealth chapter describing the difference between wealth and money should be taught to all.
  • The parts about Lisp are quite tiresome. And regarding Perl as a higher level language than Java? Please.
  • With “Partisans of permissive languages ridiculing the other [preventive languages such as Java - my note] as “B&D” (bondage and discipline) languages” Paul Graham wonders what “prevent”-style people say of Perl? At Lecando we normally just say “Perl …” and shake our heads.
  • Paul Graham has a slightly dismissive tone when talking about stuff like object orientation, static typing etcetera which can get on your nerves if you are a Java head.
  • I get the feeling that he sees Java people the way Java people see VB people. Prejudice! :)
  • He suggests that pointy-haired bosses select Java for programming projects. Since I would select Java for many programming project, would that make me pointy-haired?
  • He does explain, perhaps unintentionally, Javas success by emphasizing the importance of existing libraries for a programming language to succeed. Hibernate, Lucene et cetera anyone?.
  • When he mentions the importance of efficiency and the ability to rewrite code I believe he is right. But, I can be dead wrong, I imagine Paul being a Emacs hacker, and if you still only use Emacs, it is sure easier to write code in Python, Ruby etc. But in Java land there is this neat thing called refactoring IDE’s - Eclipse, IDEA and the lot. My problem is that it is hard returning to Emacs after using a code-completing, refactoring IDE like IDEA.
  • I guess I have to learn Lisp to see what the fuss is all about

Edit: Fixed typos

Saying hello to our old friend Ant

Friday, February 11th, 2005

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.

Gnome 2.8

Tuesday, November 23rd, 2004

I have been using Gnome 2.8 for a couple of weeks now, and I must say that it is getting really good. Gnome was the first window manager I used when I started using Linux, but I soon became hooked on more lightweight alternatives such as Fluxbox and XFce4, as I did not think that Gnome offered that much to compensate for its relative slowness.

But since I got my laptop, I have grown tired of having to do everything manually whenever the environment changes. And with the advent of Ubuntu it is really a snap.

I honestly do think that it is a way better working environment than Windows. It still has a lot to do to catch up with Mac OSX, but when I look at what is happening over at Planet Gnome I strongly believe that they will eventually get there.

Eclipse is the new Emacs

Sunday, February 8th, 2004

It was my colleague H?kan R?berg who coined this the other day. Quite insightful I think. I mean, you can play Tetris in them both.

Unit Testing Performance

Tuesday, January 13th, 2004

Yesterday we discovered a small but annoying performance bug: when getting a list of languages from the JVM we did not cache them but kept on retrieving them, which turned out to be quite slow.

So, like the good guys we are we wanted to have a test that ensured that the error was not reintroduced. We looked at JUnitPerf which seemed to be appropriate - it decorates a unit test and times it. The only problem here was that we were talking about that good performance was 800 ms, and bad performance was 1800 ms. Such timings can randomly fail on a slower computer or a computer that was busy doing something else. We do not like that kind of tests.

So instead my colleague Jimmy came up with a much better idea: Make the test a Runnable, and run it a large number of times. In our case the good performance was 800 ms the first time and virtually nothing after, but the initial bad performance was 1800 ms every time. Then we set the timeout to 5 seconds, giving enough slack for slow, bogged down test machines, but still catching the bug if reintroduced. Good stuff indeedy.

Functional Test Updated

Thursday, September 25th, 2003

After evaluating the previous named contenders for webtest tools, the winner was … none of them.

It dawned upon us that the MaxQ way of doing this, ie. recording tests, really is not the way to go, ever. What you’re really doing is testing the server from a HTTP perspective, without testing button clicking and stuff. For example, all hidden fields must be specified at every request. If you have anything Javascript based you still have no clue if this works after having these funtional tests.

On the other hand, using anything based on HttpUnit actually mimics a webbrowser, so you can click buttons and not have to worry about hidden fields. And yes, Javascript is handled.

jWebUnit is based on HttpUnit, but it has a rather limited API, for example you cannot find a button by its name to click it. We came to the conclusion that it was easier to build our own API on top of HttpUnit.

We also decided to implement the same API in a mock implementation ? la the way it is described in “Testing XP”. This way functional tests can be run very quickly on development machines and the more time consuming remote HTTP tests are done on the integration machines (Yes, we have several, one for every deployment OS).

Client OS

Saturday, November 9th, 2002

I looked at the logs for freeroller and realized that 75% of client OS's accessing it was Windows. This is of course a lower percentage than would be expected from a more generic set of computer users (I assume we're all geeks here, right :-), but still, 75%.

I most certainly don't want to start another Windozesuckslinuxisugly debate, but I was thinking that most sites accessed on freeroller have a strong connection to Java, and often business system Java - as opposed to embedded etc.

The main competitor to Java as business systems go is of course .NET. How come that 75% of the programmers who have made the Java their choice of programming language use Windows as their operating system? Why are they not preferring .NET?

Is it that they consider Windows a superior client os, but want the freedom of choice on the server? That they love the Java syntax? Someone else made the choice? Is this a small indication that .NET is a failure? Just curious.

Up until two years ago I also used Windows as my client os for programming. But then Sun started releasing the JDK's for Linux at the same time as for Windows and Solaris. I made the switch and never looked back.

For the sake of it, I'm writing this using Phoenix on Windows on my home machine, which dual boots Win XP and Red Hat 8. I strongly prefer RH8, my wife Windows.

RedHat 8

Wednesday, October 2nd, 2002

Har precis fått in RH8 hemma, och det ser helt enligt ryktena riktigt bra ut. De antialiasade fonterna blir riktigt bra, synd bara att de inte funkar i alla program. Däremot blir det lite antigeek varning på att det inte finns en konsol-knapp default i menyraden.

Inte heller denna varsion är en Windows-killer, men om de får fortsätta lite så kan det nog bli något riktigt bra. Personligen blir jag glad den dag jag slipper Windows helt och hållet. Idag använder jag det för spel och musik. Spel kan med fördel spelas på ett TV-spel och musik skulle jag gärna ha en Mac för. Med det skulle jag kunna slippa MS helt och hållet - toppen.