Archive for January, 2006

Ceci n’est pas un sherry

Sherry has never been my favorite drink. Not only does it have unpleasant connotations: of England, the 1950s, Agatha Christie, brown, dull, mouldy; or worse, in Holland: where in the 1970s desperate housewives got drunk on cheap supermarket sherry — but also I just never liked the taste of it very much.

The last time M. and I bought a bottle of sherry was to cook Delia Smith’s recipe of chicken in sherry (a chopped up chicken braised for 45 minutes in half a liter of sherry and sherry vinegar, with lots of whole shallots and garlics and tarragon). Per Delia’s instructions we asked the shopkeeper for amontillado sherry. The shopkeeper looked at us in awe; it seemed we had instantly become connoisseurs to him. With great care he unlocked a special cabinet behind him and took a dusty bottle out of it which he put on the counter. I was expecting an equally special price, so I was surprised when it only cost about 15 guilders (8 dollars), which only confirmed our prejudice that sherry is nothing but a cheap way to get drunk. We didn’t dare to break the spell and tell him we were going to use it for cooking. Of course we did taste it before pouring it into the pan, but fortunately it tasted a lot better after 45 minutes of cooking with the tarragon.

So I wasn’t too eager when my dad, the last time we visited him, suggested we drink a glass of sherry with the Coulommiers cheese and goat’s Brie we were about to eat. “No, no, this is special, you’ll like this,” he said; and I know by now I should trust him in these matters. He’s been cooking most of his life, professionally for part of it, and is currently working as a culinary consultant. He taught me long ago to always taste everything, before deciding if I like it or not. And so I trusted him and agreed to try a glass. With great care he brought a dusty bottle out of his wine cellar and put it on the table, just slightly hesitating before opening it, showing that it really was a special bottle. I tasted. He watched me closely. This was not sherry! It had all the sweet and subtle taste of sherry, but without any of the sharp vileness of alcohol that I was afraid to find. It was served cold and fresh, and tasted more of an aromatic dessert wine; a wonderful combination with the salty cheeses. He told me the sherry is made by constantly mixing in older sherry through an elaborative system, the details of which I cannot remember very clearly for some reason. The end result is that every bottle of this sherry contains a tiny amount of very, very old sherry (up to 60 years, the average age is 25 years).

After he saw I really liked it, my dad brought up another bottle as a parting gift (we were leaving the next morning). That bottle is now safely tucked away in our own little wine rack (they don’t build cellars anymore), waiting to be opened, for a special occasion, or just because we feel like tasting that exquisite flavor again. We won’t be cooking chicken in it for sure; we’ll buy a bottle of real sherry for that.

2006-01-29. 3 responses.

Ruby’s Exclamations: A Dream Come True

After writing the post about exclamation mark methods in Ruby yesterday evening, I couldn’t get to sleep (lesson learned: don’t go straight to bed after blogging). My mind was still churning away over the whole issue. And just before I fell asleep, in the short period of time when a lucid state of geniality bordering on insanity sometimes befalls you, when either the greatest ideas or the worst flops come to you — I dreamed up this code.

srand Time.now.to_i

class Ruby
    S = ['yes', 'no', 'absolutely not',
        'of course', 'you already know', 'of course not',
        'who knows?', 'I guess so...', 'I guess not...',
        'maybe', 'perhaps', 'certainly not',
        'positively so', 'try google', 'who cares?',
        'why not?', 'the answer is in your heart',
        'we may never know for sure']
    def self.exclamation_mark!
        @@r = rand
        Ruby
    end
    def self.is_redundant?
        q = @@r * S.size
        S[q]
    end
end

puts Ruby.exclamation_mark!.is_redundant?

2006-01-23. No responses.

Ruby’s Redundant Exclamation Marks

When I first read (in Why’s (Poignant) Guide to Ruby) about Ruby having ‘destructive’ methods, I couldn’t think why such a redundancy would be necessary in a language. Destructive methods are those ending with an exclamation mark; they are called destructive because they may change the instance its operating on. Take for example the String#gsub method. In its non-destructive form it returns the substitution you ask it to perform:

irb(main):001:0> s = "abcde"
=> "abcde"
irb(main):002:0> s.gsub(/bcd/, 'thlet')
=> "athlete"
irb(main):003:0> s
=> "abcde"

As you can see, the object s remains unchanged after the gsub. If you do the same thing with the destructive variant, s will be changed:

irb(main):003:0> s
=> "abcde"
irb(main):004:0> s.gsub!(/bcd/, 'thlet')
=> "athlete"
irb(main):005:0> s
=> "athlete"

Redundant, because you could also have used the non-destructive gsub and assigned its result back to s. Sure, it’s shorter; but only by two characters in the source code; and I don’t believe it’s a DRY violation to write s = s.gsub(...).
Since then, however, I have come to believe there may be good uses of the destructive method construct. For example when you’re writing a business method that needs to alter the object it’s operating on. In that case, using an exclamation mark notation will alert you about the method’s ‘destructive’ behaviour.

My friendly Ruby guru took an altogether different approach to all this, when he wanted destructive variants of methods he’d already written. Obviously, he didn’t want to duplicate the code; but he also didn’t want to write a wrapper for every destructive variant. So he used meta programming to write a def_variants method that can be used to add a destructive variant, and — as a bonus — a class method with the same name. The gsub! method can now be written as def_variants :gsub. (Well, not quite, but you’d have to read the entire post. Which is, unfortunately, in Dutch. The code samples aren’t though, and if you send Remco an email he might consider an English translation.)
I’m still not sure though if his solution put an end to this redundancy, or introduced even more redundancy…

2006-01-22. 3 responses.

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.

Running WordPress 2.0

It just took me less than half an hour to upgrade to WordPress 2.0, the latest version of the blogging software I’m using. I’m impressed with backwards compatibility. Unfortunately, the Textile plugin (which enables you to format text without HTML tags) does not seem to work properly anymore, so mosts of my previous posts are now somewhat malformed. Also I had to switch off the visual editor; my code samples came out looking pretty bad. My modified version of the Now Reading plugin (including a Favorite books section) still works, as you can see. I had hoped for a lot more options to configure and checkboxes to click on and so on, but the administration screens haven’t changed that much, apart from a visual update. Okay, back to blogging!

2006-01-10. 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.

On Cheese: A Story of Love and Hate

As a child, I was first introduced to French cheese by the man behind the counter in our local grocery store. He offered my mom and me a slice of Brie on a cracker. It wasn’t the best of acquaintances. I wasn’t a big fan of (Dutch) cheese to begin with, and this was just more smelly and more gooey.
Some years later in life, I got a proper introduction by the woman who is still my cheese guru. She could happily have dinner eating nothing but bread, some salad, and loads of cheese. Foul, smelly, stinking cheese — that more and more often began to taste not so bad, actually. I never saw her eat Brie. (Last time we met her she served us goat’s Brie but I don’t think that counts. After tasting it I realized that I’m still far from being a fearless cheese eater.)
The best tip she gave us recently, was to buy Coulommiers cheese. She did say to buy it at the market in the village nearby where she lives (in France); but during our last visit to France, we weren’t there on market day, so we skipped and bought some in the supermarché to take home. Bringing cheese home from France is another mixed pleasure. Every time I open the fridge, a horrible stench gusts out, best resembling the smell of fresh manure. For some reason, cheese bought here in Holland never smells that bad. Maybe that’s why it doesn’t taste as good, either.
The Coulommiers tastes like Brie with a fierce kick (it’s actually from the Brie region, so technically it is a Brie). I like it best straight from the fridge, that’s soft enough for me — but my cheese guru will disapprove. According to her, cheese should be taken out of the fridge at least an hour before eating it. I guess I still have issues with gooey things…

A picture of the Coulommiers still left in our fridge. You can almost smell it. Note the ‘au lait cru’ sign on the package; unless you’re pregnant, don’t buy cheese without it, or it will (usually) taste as bad as it smells.

2006-01-06. One response.

Next »