tell, don't ask? try 'read xor write'

I am currently reading this book. Many excellent Java programmers think the tell, don't ask approach is the best way to program. I can see their point, but, having dabbled in functional programming, I am amused at what is considered 'good practice' in different contexts.

In the functional programming world, functions (should) avoid side-effects unless all other options have been exhausted. Thus, it is good practice to combine many 'getter' methods together, operating on lists of lists to derive new values or get something done.

I suppose the key is be consistent: either avoid side-effects, mainly ask and have one function that combines everything together into a process/task (doing something) or follow the 'tell, don't ask' style for separation/decoupling. At the end of the day, it comes down to roles/responsibilities. An object/function/process/piece of code should be expected to either provide information or alter it in any way it sees fit. In fact, good style is probably knowing when to expose data and not. Easily done when each class is tagged as 'read' xor 'write' for a given task.

One way of promoting this is defaulting to immutable, ala Scala (val, collections etc.)


I was browsing a "SQL cookbook" to get some inspiration for SQL exercises when I came across a chapter on p*vot tables. The terror...

Apparently, you may want to get from this:

java developernick
java developerjenny

to this:

java developerdbaanalyst
jenny george

Well, don't! The first table represents a relation, the second doesn't. A relation is a set of tuples -- what sort of tuple does {nick, michael, beatrice} represent?

At best, the second table is some sort of report. SQL is not a language for producing reports. Create your report in something else: a script, a spreadsheet, a word processor. Use simple SELECT ... WHERE job = ... to fetch the appropriate data for each case.

devops kill

I'm reading Paul Graham's "Hackers & Painters" and I have singled out this paragraph because it expresses my pain. Software development requires a totally different mindset to administration and operations. They are all hard and context-switching between them is a major pain. I suppose I go looking for trouble by choosing to write my own tools, but #devops people beware!

The worst thing is not the hours but the responsibility. Programmers and system administrators traditionally each have their own separate worries. Programmers have to worry about bugs, and system administrators have to worry about infrastructure. Programmers may spend a long day up to their elbows in source code, but at some point they get to go home and forget about it. System administrators never quite leave the job behind, but when they do get paged at 4:00 AM, they don't usually have to do anything very complicated. With Web-based applications, these two kinds of stress get combined. The programmers become system administrators, but without the sharply defined limits that ordinarily make the job bearable.

The rest of this (prophetic) essay is available online here:

erlang for data ops

I gave this short presentation at the London Erlang User Group meetup yesterday.


Erlang's influence reigns supreme :-) Looks like I might be able to reuse some erl skills on the JVM.

A supervisor is a regular Actor that is responsible for starting, stopping and monitoring its child Actors. The basic idea of a supervisor is that it should keep its child Actors alive by restarting them when necessary. This makes for a completely different view on how to write fault-tolerant servers. Instead of trying all things possible to prevent an error from happening, this approach embraces failure. It shifts the view to look at errors as something natural and something that will happen and instead of trying to prevent it; embrace it. Just “let it crash” and reset the service to a stable state through restart.