November 21, 2004
You've not been there
Everytime I hear another PHP Bozo drool about how strict encapsulation, database abstraction and other academic fooling would only keep them from "getting the job done", I feel this irrestible urge to beat them senseless. Not out of maliciousness, but to protect them from the damage they are going to inflict on themselves should they continue on their misguided path.
I'm talking about the magnitude of pain I'm feeling right now, having to maintain a monstrosity I created back when I was still into the "no-nonsense" method of software development. My life is currently devoid of all joy. It's so bad that at the end of the day I'm ready to cut myself and headbutt the sidewalk just to check if I can still feel.
Clearly, we have a duty to prevent innocent minds from coding their way into the trap I find myself caught in. A first step in that process would be to skin and burn alive every person who ever published a tutorial titled "OMG PHP database in 5 minutes r0x0rz" or something equivalent. After we have thus made our point clear, we would announce a two-years grace period in which everyone would receive a final chance to learn how to code themselves out of a brown paperbag.
When after that term someone still thinks that people embracing proper OOP simply need a good spanking to get down to earth again, they may be neutered as to prevent further pollution of the human gene pool.
Further suggestions would be greatly appreciated.
November 17, 2004
Namespaces in Javascript
Naming clashes have always been one of my main concerns when writing Javascript. It is no longer. Stuart Langridge (of sorttable fame) has come up with an elegant solution that uses hashmaps to emulate something like namespace functionality in Javascript:
var Util = {
foo: function() {
alert("This is foo!");
},
bar: function() {
alert("This is bar!");
}
}
// In a nearby piece of code...
Util.foo();
Util.bar();
Having done a lot of Javascript lately, believe me when I tell you to forget everything you think you know about it from 1998. These days Javascript has lots of goodness to offer, including but not limited to function pointers, event handlers and native regular expressions. Manipulating an HTML document through the DOM works like a charm, and actually operates flawlessly and rock solid throughout all browsers.
Update: I haven't actually tried it out, but apparently it is also possible to emulate namespaces by creating a new Object() for each namespace you need and adding your functions as methods to these objects. And again I'm stunned how all of this has been dangling in front of my nose for ages.
November 16, 2004
Don't rewrite software
Aristotle writes:
Why does everyone boast about their new release being “a complete rewrite”? To me, all that says is “we want to stumble over the many fringe conditions already handled by the last codebase all over again”
I'm in the process of maintaining an application I basically wrote in an embryonic state of programming knowledge. Words cannot describe the code I grinded out at that time. After a first review of the codebase I found myself crying "MUST! REWRITE!" with bloodshot eyes and foam coming out of my mouth, but in the end I managed to suppress my cravings and take a sober look at my options.
Reality is that a full rewrite is pretty much the most stupid thing you can ever do. We're quick to underestimate the value of a codebase that had every breed of user and millions of transaction thrown against it and is still standing upright.
November 15, 2004
Dependency Injection minus the overhead
Dependency Injection or Inversion Of Control has changed the way I think about software design, but the extra layer of wiring required has often kept me from realizing its full potential. Now Dave Thomas has come up with a neat way to do Dependency Injection in Rails without any of the overhead that usually comes with it. Even if you're not into Rails or Ruby you ought to read what Dave has to say.
The idea: Since all your classes in Rails descend from a framework class anyway, we might as well let the framework handle the wiring for us. So somewhere we have a Service Locator which knows which implementations are going to be used for which service, like
:student => 'mock_student.rb'
Now instead of using a concrete implementation for a Student interface by saying:
require 'mock_student.rb'
...we simply state which service we are planning to use and let the framework use the Service Locator to wire up the implementation at runtime:
model :student
After that statement we may use the Student interface as if it was a concrete class, and do things like Student.new('Amy') instead of MockStudent.new('Amy') or even StudentFactory.createStudent('Amy').
The beauty of this approach is not merely its unobtrusiveness, but also that you can practically add Dependency Injection as an afterthought. David Heinemeier Hansson raves:
It's basically business as usual with DI for free. So you wouldn't even have to choose whether to do DI or not up front. Just as soon as you're feeling the pain, you start injecting.
Neat.
November 12, 2004
State of the art (You are going to need it)
There is a design principle for software development called You Aren't Going To Need It, or YAGNI. It postulates that your design should focus on the task at hand, and that your implementation shouldn't contain functionality that might only be needed for a future revision.
The cases for and against YAGNI are plenty, and I'm not going to argue for either side today. What worries me instead are the frequent encounters I have with people who distort YAGNI to a point where it serves as an excuse for a job done poorly.
Like with most things, there is a state of the art for IT projects. The state of the art is a set of best practices that have proven themselves and are generally considered a good idea. Your clients have a right to demand no less than the state of the art from you. If, in 2004, you deliver a website with splashes of presentation spilled throughout your content, you are not delivering state of the art. If, in 2004, your software project hatches as an untiered mess of procedures, you are not delivering state of the art.
The world is a difficult and flawed place. Sure enough mapping it onto a piece of software while staying committed to a certain standard is no trivial task. This doesn't make me any more susceptible to your lame excuses why you're not even trying.
November 10, 2004
Buy my book... or take another course
I will try to not cite any names in this entry. Those involved will know.
In every computer science course I ever attended, the lecturer provided his students with presentation slides or lecture notes. Sometimes we were given a password to access the directory containing the slides, or were asked for a small fee to cover the cost for printing and binding the lecture notes. In any case it had always been easy and cheap to get hold of required learning material.
This semester I'm taking a course where the professor is "gently persuading" the students to buy his own €55 book to be able to study for the exam. He does so by offering no slides, no notes and spends most of the lecture reading out his own, six-years old book. (See update below)
Maybe I'm spoilt in this respect, but I don't appreciate spending €55 on an outdated book that got a rather luke-warm reception from the Amazon reader reviews.
Since the subject matter is not quite rocket science, I figured I could maybe do without the book. At least that was what I thought until I tried to work on our latest assignment. Given a number of database tables, the task was:
Given these tables, calculate the result of query 3 from chapter 3.1.2 from <my book>.
Now, I'm certain the effort required to insert that stupid query into the assignment notes would have exhausted their resources.
All this makes me very sad, as I had always felt that computer science was promoting and rewarding self-motivated learning and the use of freely available learning material like few other disciplines.
Update: I found out that some lecture notes have been published on the course's website after all. To do your homework assignment, you still need the book though.
