QOTD – about dwarfs

July 31, 2008

Being considered the best speaker in a computer science department is like being known as the tallest of the Seven Dwarfs.

This is from Randy Pausch The Last Lecture book, I got it yesterday and find it really hard to put it down.



Why I love unixish configs

June 30, 2008

I wrote this today while discussing configuration mechanisms with my colleagues.

I love the unixish way of configurating things because the configs are:

Discoverable
With find, xargs and grep I can (very often) find out where something
is configured in my unixish system, with minimal initial knowledge.
Commentable
It is easy to add comments to configuration items in a text-based
config, and comments are not mangled when that config is later
modified from a GUI, if that’s available.

Cloneable
Copying the right config files from one system to another allows
configs to be cloned.

Traceable
By putting my configs under subversion control, I know what happened to them.
Documentable
Processing my configs with simple tools allows me to create reports or
dashboards easily.

The opposite of this is the M$ hell of opaque configurations managed by (sometimes even more opaque) GUIs, and unfortunately Sling leans more towards that opposite at the moment. We’ll have to fix this.


Give us today our daily social network invitation

May 22, 2008

I’ve been getting at least one, if not several invitations for new social networks every day lately.

So, please don’t feel offended if I ignore them, it is sometimes hard to select between timewasters and…more timewasters ;-)

(seriously: some of this stuff is very useful, but as with any new tool it looks like we’re in the explosion of new offerings phase right now).


QOTD: Albert Einstein on the teaching power of examples

May 19, 2008

Example isn’t another way to teach, it is the only way to teach (Albert Einstein).

Sounds so obvious…you don’t teach babies to speak by explaining how to move all the organs involved in speech: you start by talking to them, and once they get the basics you explain a bit and move to the next stage of examples.


Automated tests == reference documentation

March 13, 2008

Someone was asking about ujax:redirect in Sling. We have no docs on that yet, but how about some (readable) automated test code?

Using automated tests as reference documentation means that the docs will always be in sync with the code – assuming you’re using continuous integration to run those tests often.

People might object to having to read source code, so maybe creating a filter that presents the code in a nicer way would help?

Literate programming for test cases…the idea sounds worth pursuing.


Suggestion to podcast interviewers: record both sides!

February 22, 2008

I’ve been listening to a few podcasts recently, which were obviously recorded using Skpye or another VoIP technology. Probably Skype, judging from the bad voice quality – my SIP phone sounds much better than that, but of course SIP is not always practical.

The problem is that it’s usually the interviewer who records the conversation, so it’s the interviewee’s voice quality that suffers, although it is in most cases the one that we want to hear.

How about recording both side’s voices locally, and mixing the two at post-production time? That’s a bit more work, but aligning the two tracks on an initial pulse or beep should make it easy to get the timing right, and depending if the recordings can be reasonably isolated, not much more processing would be needed. Worst case, you’d have to adjust each track’s volume according to who is speaking.

That wouldn’t work for interviewing people who don’t have a clue how to record their own voice, but geeks should manage ;-)


Developer Usability

February 19, 2008

dials.jpgReflecting on my activities in the last few months (especially around Sling and how we use it), I notice that Developer Usability is often my concern.

How do we make our software more understandable, transparent, efficient and generally usable by developers? Good designs should be self-explaining, but in a complex system that’s easier said than done.

There are many small things that influence this, as well as architectural decisions where one might trade off other criteria for developer usability.

I find it captivating to try and improve things so that people understand them better – I’ll try to find out more about what makes the difference here, but for now I’ve made a few suggestions related to documenting Sling, which would hopefully apply to other projects as well.

(Update: see the next post for a more general view on those suggestions).

I’m starting to think that documentation is like code comments: if you need lots of it, that’s a bad sign.

Feedback is welcome.

Picture by agathabrown, under morguefile license.