Since I now have a continuously-running media center at home and a 20/3Mbit cable connection, I decided to revive this website. Don’t know for how long, but I got regular requests especially for the Yashica/Contax content so I thought it worth the half hour effort to restore a backup and tweak the media center’s Apache config.

I sorta had it with running my own server, my own site, hunting down spammers on my wikis all over the place, etcetera. I got better things to do. So, please expect this site to go away or at least turn into some static content hosted on a free server.

In the meantime, I won’t stop blogging especially not about my craft, software hacking. Bill Venners was so nice to setup a weblog on Artima for me, so if you want to follow what I’m doing, please bookmark that place!

Yeah. I know. This is the umptieth article on this topic. But this one is mine, ok?

I’m busy with a redesign of the site. One of the things is that I want to be more flexible in redesigning the site so I started looking for boxes (with or without rounded corners) that were robust, flexible, and require a minimal amount of markup. Preferrably one that can underlay a single image so that I don’t have to cut up stuff in the Gimp.

So, what do you do? Search the web. And find half a million solutions for CSS boxes. I settled on one and started reworking it for my own needs - and of course, as you have it with CSS, it kept breaking. Either in Firefox, or in IE, or in both. And it was never clear why it broke.

Here I am - 20 years professional experience, an expert in more programming languages than I care to remember, I worked with raw TeX and LaTeX for years so I should know a bit about styling and layout, and I don’t understand what is going on! The box markup is a strange collection of DIV tags, needed for the CSS to attach the various underlay images to, it looks counterintuitive, and - there’s the cincher - where is “semantic markup” in a bunch of extra DIVs that are just there for layout reasons? Here, semantic markup in 2008:

<div class="dialog">
 <div class="content">
  <div class="t"></div>
  <!-- Your content goes here -->
 </div>
 <div class="b"><div></div></div>
</div>

You can call that “semantic markup”, but I wouldn’t do it if Knuth or Lamport are around. I call it “trash”. And this is one of the cleaner and more robust solutions that I have found. Why would it be that there are a gazillion ways to do this with CSS, but only a couple of straightforward ones to do this with table tags?

Here’s what 20 years of software engineering experience tell me: all CSS box solutions are hammers on a hunt for nails.

Don’t misunderstand me - CSS is nice (not great, just nice, ok?). It helps in separating content and design, can greatly help in increasing site speed, but it is not a panacea. No single CSS-only solution is as robust and understandable (read: maintainable) as a well-chosen mix of CSS and table-based layout. A good craftsman knows the difference between a hammer and a screwdriver and also knows which one to apply when.

Bottom line: my site will use tables for boxes. Later this week, I’ll share how I keep the markup trivial nevertheless - turns out that semantic markup aided by some Javascript goes a long way into solving this problem.

Well, the OLPC project finally has some production hardware to show. And - frankly, it gets me more drooling than yet another sleek Apple design. It’s quirky (that always scores brownie points with me), it’s cool (what is cooler than connecting kids), and running a simulation under VMware shows something that is, well… different in an extremely interesting way.

Call me a naive idealist, but this is the sort of hardware that gets me excited - it serves a purpose, and every bit of its design serves that purpose. And it’s for real now - starting yesterday, a 2 week program called Give One, Get One allows you to give someone a laptop and get one yourself. Alas, only when you live in the US or Canada (mostly due to pending safety approvals in the rest of the world), so unless someone gets triggered by this post to send me one , I’ll have to stick with the VMware image a bit…

Give one and get one, is my advice. At worst, it’s a tax deductible toy. At best, you’ll hold a piece of history.

1. Do not show people designs in the pub
While I was doing that, someone passed a basket of chicken wings over my keyboard. Nothing bad, except for the fact that the bowl with sauce in the basked wasn’t level and thus leaked over the wings and, through the basket, on my keyboard. Result: a very sticky keyboard.

2. Do not clean with a moist cloth
So I hibernated the thing at home, sprayed some all-round cleaner on a moist cloth, and carefully wiped away the sauce. Wiped dry, and then left the notebook dry for an hour more. However, “moist” is probably too wet for modern notebook keyboards (damn… where’s the time you had German-built Cherry keyboards you could hose down and then throw into the laundry dryer…), so after resuming Windows, most keys fired off double key events.

3. Last, but not least, do not dry in the oven
So I carefully put the keyboard on top of a towel in the oven, put the oven on a mere 90 degrees, and went on working with a USB keyboard connected to the notebook. Well… it seems they have invented plastics that *do* melt below water’s boiling point (beats me why…). Picture below, ’nuff said…

Update: of course, there are always people who outdo me )

Just a quick post - we’re still looking for very skilled developers to join our teams in Amsterdam and Emmeloord. Look at our local jobs page for details. It’s a great team, we’ve got some very fun challenges to chew on in the coming time, and you really can do worse than working for eBay .

If you have any questions, please don’t hesitate to contact me.

In PHPDBUnit - Testing DB interaction with PHPUnit - Digital Sandwich, Mike Lively announces a port of Java’s DBUnit to PHP. I gave a short(ish) reply on the blog but after posting it I realized I wanted to expand on the topic a bit .

Let me start by quoting my reply on his site. It’s Sunday morning and I am lazy -

Might be nice for acceptance testing, but I don’t see why you would want to talk to a real db during unit testing. It’s just too slow, and if you need anything resembling a biggish dataset for a *unit* test, your unit tests aren’t fine-grained enough.

Mocking the database is really where you want to go. Redirect the connection logic to give a mock connection object back that basically does string compares to pick which of a handful of precooked result sets (in-memory arrays) to return. It’ll cost you an hour or so to rig up some baseclasses, and keeping everything in memory (and not having to truncate tables) makes sure that your unit tests keep flying. Also, having your datasets in the code will force you to think about your unit tests once they get large - usually that’s a refactoring smell

I used database-based unit testing once, when I just started with XP 10 years ago, and I’ll never go back there.

If you check the original post, the example he gives would be exceedlingly simple to write a unit test for that doesn’t use a database. Roughly it goes like:

    function testDelete() {
        $pdo = new MockPDO(/* callback = */ $this);
        $this->seenDelete = false;
        $foo = new Foo($pdo);
        $foo->deleteByCol1('value1');
        $this->assertTrue($this->seenDelete);
    }
    function pdoCallback($query) {
        if ($query == "DELETE FROM foo WHERE col1 = 'value1'") {
            $this->seenDelete = true;
        }
        return null; // no resultset needed
    }

Look, Ma - no Database! This is a Unit Test. It tests a Unit of code. Not a whole stack of it.

Think of using a real live database as a very strong refactoring smell because you are having a lot of test coverage duplication - every test you do using DBUnit activates the same bits of code - like MySQL drivers, etcetera - that hopefully should be tested elsewhere. I assume that when I feed the above query to MySQL, it will do what I told it. When writing the test, I might even copy and paste it to the MySQL command line to make sure that the query I am comparing against works, and in real life you probably want a “sloppy compare” that ignores whitespace and character case.

By the way - this code has one callback per test class. This was the simplest thing when we started using it at work, but what also might work is a callback per test, especially using the quite cool mock class generation facilities of SimpleTest (which is what we use at the moment). However, we don’t tend to do a lot of database testing anyway: most CRUD code is generated, so we have a single test set to test the generator and exercise what the generated code is spitting out; live classes just get the additional (hand-coded) methods tested.

If you wonder why I am so adamant against using something like DBUnit in a unit test set (that is, unless you are actually developing the database code - then it will be very useful indeed), apart from the somewhat academic argument about test coverage, a very big issue is performance. Unit tests become more valuable the faster they run, and ideally you want them so fast that every time you press “save”, they run and you don’t even notice the lag (I have seen that demoed once and it was quite cool). As I said, it is sunday morning and I am lazy so I am going to guess that setting up the database will take you something like 250ms. A hundred database tests later just the overhead of setting up the database is 25 seconds. In that 25 seconds, I could have run an additional thousand or so “fast” unit tests. If your test suite gets slow enough that you get up for a coffee after pushing the “run all tests” button, you will not run them often enough - it becomes a ritual to execute before, say, committing your code instead of a friend that helps you guide you along every step of that big refactoring you were tasked with.

So, unit testing must be fast (err… well, relatively fast. Nothing is absolutely fast in PHP, alas). The best way to ensure this is to identify just what code you want to test, and then sandwich it: on the top, there’s the unit test, on the bottom, there is probably mock code, and in between just the code that you scrutinize. Keep the sandwich model in mind and you’ll find that you will write cleaner code (because all your code becomes “pluggable” in a sense, in order to accommodate it being able to run in the test sandwich as well as in the real environment), and your unit tests stay focused and fast. Focused unit tests also means that if you change one thing, only one unit test breaks - clearly that’s a win too.

At our office, I thought it’d be a nice challenge to run a computer Go tournament - individuals could submit their computer Go program, and the best program’s author gets a big prize and gets to explain how he did it (sorry, only male hackers around so far). Apart from a bit of an exercise in AI, one of the fun aspects is that each can use his own programming language because interfacing is trivial through the Go Text Protocol.

Anyway, we need a tournament and practice server, so I set up NNGS on my box to act as one. It is accessible at the usual ports, like here, and feel free to use it if you want to play a game with a mate or test drive your own Go programs (two instances of Gnu Go, one at the default level, one at level 1, are usually attached to the server so you can play against a computer opponent at any time). qGo is a nice client for the server.

Under the title “writing a Go program or how to embarrass yourself in public” (I don’t know anything about this sort of stuff so I’m going to make lots of dumb mistakes) I hope to keep you posted about my competition entry, which will be done in Smalltalk of course (Squeak initially because I like the environment better but I may switch to VisualWorks for performance reasons later on).

And, yes, I do know that Go is a hard problem to knack, even with our simple tournament rules (9×9 board and 5 minutes thinking time). What’s a tournament without a bit of challenge, eh?

Take a cucumber, some tomatos, and a capsicum from the fridge (the veggies must be cold). Go to your garden/balcony[1] and cut a nice handful of herbs (basil, thyme, coriander/cilantro and marjoran formed my catch). Cut the lot, add olive oil, balsamico, a bit of honey or sugar and some salt and pepper. Blend so that it becomes fluid but still is chunky.

Put in bowl. Add spoon. Go wild and sprinkle some more herbs over it, or some coarse sea salt, or some croutons, or some parmigiano, or all of it.

Enjoy

(enjoy even more with a nice white - I had a Tokay Pinot Gris d’Alsace open which did the job quite nicely)

No herbs? Shame on you!

One of the podcasts I subscribe to is The Agile Toolkit by Bob Payne. It mostly consists of him interviewing interesting people at conferences, and invariably I pick up interesting snippets of thought and/or knowledge.

Last weeks’ podcast contains a presentation by Pollyana Pixton, Veep of the Agile Project Leadership Network. She shares some great insights into how to introduce agile/lean into the enterprise, and gives one extremely interesting business case of a Brazilian company gone to the agile extreme - and seeing business booming against the background of a struggling economy. Very recommended talk.

On a related note, I found this nugget from an eBay colleague. He may sound evangelical to an outsider when discussing what is on his badge, but I’m sorry to say - so far my conclusion is that he’s right on the money when he talks about the company’s dealing with the Values and Behaviors. I’d really like to find more people at eBay like him and help getting the shop leaner and meaner .

BTW - I took some time to dig up references about the business case. The guy is named Ricardo Semler and you’ll find plenty of references to him and his business, Semco, plastered all over the web. I’m surely going to check out his book, “the seven-day weekend” (Chapter One here courtesy of Inc).

Also found a lecture at MIT/Sloan by him.