I stumbled across an old article on coding horror about how people are having to make job applicants sit a simple filter test.
The article is here.
The test is of course fizzbuzz. Its super simple to explain (but i wont) and only takes a handful of lines of code to solve, even in the most verbose languages.

At first I couldn’t believe the stats presented in the article.
Surely their resume would filter out the people that cant program?
Surely you can tell a programmer within 5 seconds of a phone interview?
Surely theres no need for such a simple test?
But then one of my minions went for a job interview at some place and they actually gave him the fizzbuzz test.
One of the local game company CEOs also says that 30% of the programmers they get in to interview cannot program to save themselves.

Then a workmate sent me an amusing fizzbuzz solution: Enterprize Fizzbuzz
This cheered me up. Its good to see people can take a light hearted view on this sorry state of affairs.

So I decided to do some ridiculous solutions to fizzbuzz as a bit of fun.
Ive put them on github, and will add to them as I think up more ways to mess up fizzbuzz.
My current favorite is the template meta-programming version. Its succinct and quite beautiful, but a complete waste of time.

What other ways can we over-engineer fizzbuzz? Maybe a webmachine web service that streams the results back…
or using llvm to generate a machine “optimized” [1] solution at runtime.

Aside: One thing I like doing when interviewing people is getting them to show me code from their own projects, and then asking them if there is anything that they would change or improve.
It tells you a lot about the sort of programmer they are.
It would be interesting to do this with peoples fizzbuzz solutions. Sadistic maybe. But interesting.

[1] which will still be dominated by IO, hence the quotes around “optimized”.

Using Zlib in Erlang

The simplest way to compress and decompress binaries in Erlang is zlib:compress and zlib:decompress.
This works great for large data and on unreliable media.
However for small data the headers and checksum take a relatively large size, which is often unneeded when the media is reliable.
The zlib library supports removing the header and checksum information.
Erlang exposes this through the zlib:zip and zlib:unzip functions.

But if you’re use case is a lot of small documents you can do better using the API:

compress(Data,Dict) ->
	zlib:deflateInit(Z, best_compression,deflated, -15, 9, default),
	zlib:deflateSetDictionary(Z, Dictionary),
	B1 = zlib:deflate(Z, Data),
	B2 = zlib:deflate(Z, <<>>, finish),
	list_to_binary([B1, B2]).

uncompress(Data,Dict) ->
	zlib:inflateInit(Z, -15),
	zlib:inflateSetDictionary(Z, Dict),
	B1 = zlib:inflate(Z, Data),

For long documents; specifying a dictionary doesn’t make a huge difference, but if you are storing/transmitting a lot of short XML/JSON snippets it can make a difference.
If you don’t know what dictionary to use just specify an empty binary to get default behavior.

The zlib docs say this about specifying a dictionary:

The dictionary should consist of strings (byte sequences) that are likely to be encountered later in the data to be compressed, with the most commonly used strings preferably put towards the end of the dictionary. Using a dictionary is most useful when the data to be compressed is short and can be predicted with good accuracy; the data can then be compressed better than with the default empty dictionary.