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.

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?

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…

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!