Archive for the 'Programming' Category

Rendering Rails Reuseless??

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.

2006-01-21. 2 responses.

The Project is Dead, Long Live the Project

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!

2006-01-18. One response.

In Search of Ruby’s Sweet Spot

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.

2006-01-13. No responses.

Closure Time for Java

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.

2006-01-09. 17 responses.

The Answers to All Your Questions

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 »

2006-01-07. 2 responses.

Using Sections in Java Classes

In last month’s discussion started by Martin Fowler’s article on humane interfaces, some people mentioned Smalltalk’s method categories. These categories supposedly serve to bring order to classes containing large number of methods. I wonder if something like that would work for Java. (Personally, I wouldn’t call them ‘categories’, as categories imply that you can assign multiple categories to a method as well as multiple methods to a category.) For example, you could have:

public class String {

    section getters {
        public char charAt(int index) {
            // ...
        }
        // ...
    }

    section testers {
        public int compareTo(String anotherString) {
            // ...
        }
        // ...
    }

    section mutators {
        public String replace(char oldChar, char newChar) {
            // ...
        }
        // ...
    }

    section finders {
        public int indexOf(String str) {
            // ...
        }
        // ...
    }

    // ...

}

The section names would not be used anywhere else in the code, so you don’t use "text".finders.indexOf("e"). Their use would be limited to sorting method names in IDEs, JavaDoc etc. So it would make sense to add JavaDoc to the sections, like this:

public class String {

    /**
     * Groups methods retrieving parts of the String object
     * or its attributes.
     */
    section getters {
        public char charAt(int index) {
            // ...
        }
        // ...
    }

One possible functional use for sections would be to allow access modifiers to sections, so you could have a public section businessMethods and a private section privateMethods.

There would have to be additional rules about inheriting sections in subclasses, using sections in interfaces, having methods outside sections, naming standards for recurring types of sections and such things.

The question is: does Java need something like this? The String class isn’t that huge, doesn’t have hundreds of methods like Smalltalk classes seem to have (note to self: read Smalltalk primer). I was triggered, actually, by a comment earlier on this blog, about the DefaultOWLIndividual class. It’s an example of a Java class that does have 300+ methods. A class like that would certainly benefit from (inherited!) class sections. I’m sure there are many more examples of large classes like this one.

But even if a class is not that humongous, even if it only has 10 or 20 methods; wouldn’t it still make the interface design more clear and structured if it had sections? It could also show better the intended use of the methods in the class (business methods vs. private methods). So I think sections could be a useful addition to the Java syntax.

2006-01-02. 3 responses.

BEA WebLogic Ready for Ruby?

BEA’s Bill Roth (vp of the BEA Workshop Business Unit) hinted at JavaPolis and later in his blog and a LogicCMG blog at the possibility of WebLogic server supporting other languages than Java, like PHP or Ruby. I think this is an interesting idea. If, for instance, Ruby or Rails applications could be deployed to a WebLogic server, maybe you could use data sources or JMS queues from within Ruby code, or even call EJBs. You could profit from WebLogic’s scalability. Another advantage I see is that with BEA ‘supporting’ Ruby, it would be much easier to use Ruby in a corporate environment (that is, if they use BEA in the first place). BEA, bring it on!

(Note that I’m silently ignoring the mention of PHP here. Mentioning PHP and Ruby together does not do justice to Ruby; too many people I speak already think Ruby is just another PHP variant. I think BEA would actually lose credibility if they were to support PHP.)

2005-12-20. No responses.

Final Thoughts on JavaPolis 2005, Part 2: Is JavaPolis the European JavaOne?

In Thursday’s keynote, JavaPolis founder Stephan Janssen asked whether JavaPolis should grow even bigger, and because of that, move to a bigger location. According to the official site this year over 2100 people attended the conference. I don’t think there’s a clear answer to Stephan’s question. JavaPolis had a very friendly, cosy atmosphere; I never had the feeling there were 2100 people around. All the stands were well accessible, there was always a seat left even in the most popular sessions. Maybe 2100 is just right. On the other hand, if JavaPolis really wants to be ‘the European JavaOne’ (as I’ve heard people say more than once) I think it’s not nearly big enough. I would expect much more sessions, high-quality sessions even on Friday (see below), more big names in the speakers department and a bigger exposition room with more companies and bigger stands. I wouldn’t mind paying a little more either if it were that big.
Continue Reading »

2005-12-20. No responses.

Final Thoughts on JavaPolis 2005, Part 1

Not being able to blog live during JavaPolis 2005 leaves me with several pages filled with scribbled notes on the various presentations. I’m glad that JavaPolis 2006 is said to feature free on-site WiFi access (you read it here first!). But even so, I’m not sure how easy it is to blog live on the spot. My laptop is rather big and heavy to carry around, it always finds a way to play the Windows welcome jingle when it boots up, no matter what settings I tweak, and it’s actually difficult to focus on the presentation and write a cohesive, intelligible blog entry.
So, about these notes. Thursday I saw…
Continue Reading »

2005-12-19. No responses.

On the Rails Again

Back from JavaPolis, and seeing the Rails book lying where I’ve left it last Tuesday, made me pick it up and continue reading — instead of looking into GlassFish, the new persistency API, JSF and all the other new stuff I’ve seen in Antwerpen. It’s all alpha, beta, preview releases; and even if it isn’t it’s still so far away: Jeroen (colleague also attending JavaPolis) and I figured we’re lucky if we’ll be able to use Java SE 5 in our daily work (read: in BEA WebLogic) by the end of 2006 (when Mustang, Java 6 is already out), and Java EE 5 by the end of 2007 (when Dolphin, Java 7 is out). Two years and two more Java versions before we can use the technology we’ve been presented this week! So I’ve more or less lost interest momentarily and gone back on track with Rails.

There was very little mention of Ruby at JavaPolis. None of the people I spoke with had actually done anything with Ruby. What I did see:
Continue Reading »

2005-12-17. 8 responses.

« Prev - Next »