Normally I prefer trying to write an original text of my own; but in this case I can’t help but pass the word. This post thought the words out loud right out of my mouth: Reuse is vastly overrated, by Rails creator David Heinemeier Hansson. Quote:

Reuse only works well when the particular instances are so similar that you’re willing to trade the small differences for the increased productivity. That’s often the case for infrastructure, such as Rails, but rarely the case for business logic […]

I agree so wholeheartedly because I’ve seen so many counter-efficient examples of reuse in applications. Done by programmers twisting and tweaking their code to make reuse possible in the first place, and endlessly after to keep all the dependant code working when changes have to be made. Pray that the reusable code has been thoroughly documented if you are the one having to maintain it. You wouldn’t be the first to realize that rewriting might be faster than reinventing the reasoning behind the reusable code.

In our current (Java) project, we quickly found out that we were going to need a similar search popup throughout the application. Users wanted to search for different types of relations (clients, companies, partner companies, intermediaries, etcetera) in different usecases. So we made one generic, reusable popup that could find them all. Generic, because the search and result fields are parameterizable; only the calls to the backend business methods (that are not so generic) differ.
This setup worked fine until in one usecase an extra requirement was added for a two-level search: search a client, than select one of his insurance policies. We couldn’t “trade the differences for increased productivity”: the client usually gets what the client wants. We didn’t want to make such a large extension to the original popup code, because several usecases using that had already been tested and marked complete. So it was decided that we would pop out a new popup, which could still benefit from the original popup: much of the code could be ‘reused’, as in ‘duplicated’. After that, more specialized popups were soon to follow.
We still have a lot of uses for the original popup though, where the basic functionality is sufficient for that particular usecase. I guess it’s a case of knowing when to stop trying to be reusable and not be too afraid to duplicate some code if you have to. In a sense, rewriting sped up by duplicating existing code is just another form of code reuse.

I’m not so good at saying goodbyes, so the end of a long term project always brings me mixed feelings: I’m eager to take on something new, start afresh, meet new people, tackle new problems — but I hate saying goodbye to the team of people I’ve been working with so closely, people I’ve seen every working day of the week for so long. And as it happens, the project I’ve been on for the past twelve months is coming to a close ten days from now.

At one of the larger Dutch health insurance companies, we built, from scratch, a combined web/mainframe application for the new Dutch national health system (“basisverzekering” or basic insurance) that was introduced on January 1st. People were skeptic about our chances, but the project manager kept the faith and we pulled it off in time. Right now, when I walk past some call center employees (they’ve been cramped everywhere in the building, there’s so many calls coming in about the basisverzekering), it’s very satisfying to see them on the phone with actual clients, using the very application I helped build. So even though I’m happy to leave, I’m really not. I’m saying goodbyes.

Goodbye to the 8th floor where we sat, a huge empty office floor housing 80 people, all working on this project.
Goodbye to Chris, I really hope to see him back. He was our senior team member, who came from the UK to live in Holland some 25 years ago; still eager to do and learn new things at the age of 57. He was sadly diagnosed with cancer last September and had to leave the project early to be hospitalized. I wish him all the best, but he could probably use a miracle right now.
Goodbye to the girl with the blue sports car that she parked next to my car every morning at the train station; we never spoke because I was always running to catch my train, but I liked her car.
Goodbye to the mainframe and to Tuxedo and OptimalJ, all technical stuff to help the application store its data in a database; all those extra layers make it a lot more complex and more error-prone while developing, but it was also an extra challenge, it gave an edge to the project. I’ll be happy to use ‘just’ Oracle again in my next project.
Goodbye to the guys (and Kate) at Social Ground at the Amersfoort train station, where I bought a grande latte every morning; still the best coffee I can find. I hope they’ll open up another shop at my side of the country (East).
Goodbye to Remco, another member of the team, aka the friendly Ruby guru; he pointed me at Ruby among so much other things: del.icio.us, Bloglines, dEUS to name just a few. I’m on my own now, preaching Ruby to the Java people in my own office. I’ve already begun by bombarding my account manager with useful info about Ruby, like Obie Fernandez’ post on Productivity Arbitrage. He’s listening.
Goodbye to all the other members on the team. I learned a lot from you; that’s why I like doing projects like these.

I’m ready for the next project. Bring it on!

02-02-2007 UPDATE: Last night, I was finally able to say goodbye to Chris. I dreamed that the project was still running, everyone was there (not Remco of course, who’d left early to become a Rails programmer). We all had to work late to finish the release. Except Chris, who had already finished his part. It happened to be his last day on the project, so we all said goodbye to him. Someone convinced him to give a demo of what he had built. So he proudly showed us an oversized pocket calculator with a matrix printer built in, which could be used as a portable device to print invoices for clients on-site. It looked impressive. He pushed a few buttons and an invoice slip slowly rolled out. As he was walking to the door, a big grin on his face, I discovered that an entire group of line items was missing from the printed invoice. I wanted to call him back, but at that moment I woke up.

He must have reached his final destination by now.
Bye Chris!

In a recent post, Stuart Halloway wrote that his company bids up to 50% lower for projects done with Rails, compared to similar Java projects. For applications ‘nowhere near the Rails sweet spot’ they still bid 10% lower. So the question arises: what is that sweet spot? For what projects would you rather choose Rails (over Java or PHP or .Net or…)? These are my suggestions:

• To start with, the project must be about building a web application (as we’re talking about Rails, not Ruby). But, with Profict, my employer, being specialized in EAI, I’m also interested in using Rails and Ruby for integration projects. I’m guessing Ruby can be used mostly for point-to-point integration (I’ve worked with BEA WebLogic Integration, at the other end of the spectrum, featuring a complete workflow engine and ready-made connectors to all sorts of data sources and applications); but point-to-point might be all you need sometimes. Needless to say I’m waiting for the release of Enterprise Integration with Ruby, a new Pragmatic Programmer book.
• The existing PHP codebase may hold a useful indication. There’s a wealth of web application software available, written in PHP: content management systems, wikis, groupware, contact/communication software, host management software, blog software… In my opinion, anything to be coded in PHP can also be done in Rails, probably better, faster, more maintainable. Like PHP, Rails applications will be cheaper to host (either by yourself or by a third party) then Java/J2EE.
• If you’re building a presentation web site (a site meant for web presence only) that has very little code, you would, up till now, probably have used PHP for the scripting. Maybe the site has a contact form that must be stored in a database, or it should run the odd database query and present the results to the visitor. I don’t think I would use Rails here, that would be overdoing it; but you could do the scripting in Ruby. (Of course, Flash might be considered for these kinds of sites).
• Applications that do not come with clearly outlined specifications and requirements, clients that are not yet completely sure what they want, but they do want something fast: these situations call for prototyping, rapid development, the ability to change direction easily; these are projects where Rails would have a clear advantage.
• I would hesitate to choose Rails if the project requires a large number of developers, simply because there don’t seem to be many experienced Ruby developers around yet. But this might be a local (Dutch) issue.
• There would have to be no need for using heavyweight J2EE(-like) features like messaging, distributed transactions, connecting to ERP systems etcetera. I know, there’s a Ruby library available for everything; but if you’re going to need things like these, you’re probably (working for) a large enterprise doing an Important Project where Things Should Never Go Wrong. Let them pay for BEA, IBM or Oracle support (or Microsoft, sorry) to help out when things do go wrong, usually somewhere deep inside the application server.

It might again be a local thing, but I think a company that has chosen Java as their development platform, have done so not too long ago, and will not be particularly happy to switch to something like Ruby. Not even if the project costs them less. For them, Java is a project requirement. Also, they can afford to use Java and they’ve invested in it; I mean, Java is difficult and expensive to host, and Java development isn’t cheap either.
Clients who could be interested in Rails might not even be using Java right now — PHP might be a better guess. Those clients could well benefit from a framework that delivers faster, has a better architecture and is easier to maintain. Compared to PHP, I think Rails is one enormous sweet spot.

Someone on our (Java) project team has so fallen for Ruby that he is now trying to force the Java code into Rubyesque patterns. He has found an ally for this in the Commons Collections Closure interface. What he seems to want to do in Java is the equivalent of:

sum = 0
list.each { |item| sum += item.amount; }

The Commons Collections Closure class looks like it will help out here, but it won’t. The following code will not compile, because sum must be declared final; and if you do that, you may no longer modify it inside the closure:

CollectionUtils.forAllDo(items, new Closure() {
    public void execute(Object o) {
        Item item = (Item) o;
        sum += item.amount;
    }
});

But then, Closure was defined with a restriction to begin with. If you add the ability to receive parameters beforehand, like this:

public abstract class MyClosure {
    public Object[] params;
    public MyClosure(Object... params) {
        this.params = params;
    }
    public abstract void execute(Object o);
}

then you can send the ‘outside’ variable, sum, to the closure constructor; so it can be used inside the closure:

Object[] result = forAllDo(items, new MyClosure(sum) {
    public void execute(Object o) {
        Item item = (Item) o;
        params[0] = ((Double) params[0]) + item.amount;
    }
});
sum = (Double) result[0];

The new forAllDo needs to return the closure’s parameters after looping, but is rather straightforward for the rest.

Of course, it’s still a long way from Ruby’s simple syntax. Also I wonder how much patience constructs like these will require from the people that will be maintaining this code. After all, the usual way of doing this in Java is just iterating over the collection’s items. But I guess it’s good to look at your coding habits from another point of view now and then.

Beginning bloggers can often be recognized by their fixation on web server statistics. I don’t mind admitting that I’m no exception. It’s just as satisfying to see that people read my ramblings, as it is to see people use a computer program that I wrote. Besides, the stats can show you some very interesting information, like which posts are popular, and what other sites refer people to this blog. But what’s most intriguing, is the search words some people used that lead them here. With some search words I really wonder how they could have led here, and if the posts here ever gave people the answers they were looking for. (Then again, I guess that’s the beauty of the web: you usually find what you’re looking for, but more often you find ten other things you weren’t after but are still interesting enough to look into.)

For example, how about the person that asked his search engine of choice, literally, “did sauerkraut come from switzerland?” Why did they want to know? Was the answer ever found? Does it really matter where it comes from? Personally, I would say straight away: sauerkraut comes from the Alsace region in France. The best sauerkraut I’ve ever tasted, anyway. But sauerkraut is eaten in many places, and many varieties. In Holland it’s usually mashed with potatoes, baked lardons mixed in, and served with smoked sausage. We had braised cabbage in Slovenia, which looked a lot like sauerkraut but wasn’t sour at all. According to Wikipedia, sauerkraut originated in China. Strange, it’s never on the menu at the Chinese takeaway’s…

Sauerkraut-like cabbage on the Ljubljana market

Continue Reading »