Some additions to my holiday reading list:

• John Backus's Turing Award Lecture from 1977, Can Programming be Liberated from the Von Neumann Style? (via)
• Science is linguistic as well as numerical (just ask Larry Wall!)
• 10 Habits of Highly Effective Brains

I'm a little disappointed the last didn't explicitly require Chess since Kath gave me an awesome Kasparov Chess set for Christmas :)

Perl hacker Schlomi Fish recently published an article about the need for accessible Spam, "Spam for Everyone" - The International Campaign for Accessible Spam

The "Spam-for-Everyone" campaign aims to convince spammers that they shouldn't send spam that makes it harder or impossible for disabled people to understand it

Brilliant!

I have a few flights and trips over the Christmas week, so I thought I'd compile some reading material for those spare hours. If you're looking for some light ;) reading I thought you might be interested also:

• Gödel, Nagel, minds and machines
• Engineering Software Correctness
• User-Level Transactional Programming in Haskell
• Expression and Loop Libraries for High-Performance Code Synthesis
• It's Time to Stop Calling Circuits "Hardware"

Well it's the 20th anniversary of when Larry Wall first released Perl to the world and to celebrate the Perl community has announced the release of perl 5.10, the biggest new perl release in 5 years.

May we happily program so pragmatically for another 20 :)

Outside of work, SMS and instant messaging are fast becoming the writing tools of choice. Indeed, South Korea - that crystal ball of all our digital tomorrows - has even seen a report that many teenagers have stopped using email altogether. "It's for old people," they say.

...

According to the poll, mobile texting, instant messaging and the perception that email is "a lot of bother" are all contributing to the end of the email era. Other factors, say the report, are the difficulty of ascertaining if an email has arrived and the lack of immediate response. One young Korean said that texting felt like a ping-pong game and that email was more "like doing homework".

Source: Sydney Morning Herald

There's an opportunity in here somewhere - it shouldn't be too hard to merge IM, SMS and email into one seamless communication. Unfortunately Facebook/Cyworld etc. are always going to be a proprietary impediment.

While reading the erlang mailing list I came across a (fairly) new module plists containing parallel versions of the erlang lists module and a few throwins (like a mapreduce implementation). The functions operated just like the standard variants plus an optional parameter that allows you to tune how many parallel processes are run and whether to use remote nodes or not.

plists is a drop-in replacement for the Erlang module lists, making most list operations parallel. It can operate on each element in parallel, for IO-bound operations, on sublists in parallel, for taking advantage of multi-core machines with CPU-bound operations, and across erlang nodes, for parallizing inside a cluster. It handles errors and node failures. It can be configured, tuned, and tweaked to get optimal performance while minimizing overhead.

...

This module also include a simple mapreduce implementation, and the function runmany. All the other functions are implemented with runmany, which is as a generalization of parallel list operations.

Nice.

I wanted to serve compressed static js and css content from an Apache server. I also wanted to pre-compress the files to save time/cpu, and the particular Apache 2 instance had no mod_deflate or mod_gzip installed (dynamic content was being compressed at the application layer).

Serving pre-compressed content turned out to be incredibly easy using mod_rewrite*:

1. Create a compressed copy of each .js & .css file with a .jsgz/.cssgz extension
   

   find . -name '*.js' -or -name '*.css' -exec sh -c 'gzip -c {} > {}gz' \;
   

2. Add the following to a relevant part of your Apache config file:
   

   RewriteEngine on
   RewriteCond %{HTTP:Accept-Encoding} gzip
   RewriteRule (.*)\.css$ $1\.cssgz [L]
   
   AddType "text/css;charset=UTF-8" .cssgz
   AddEncoding gzip .cssgz
   
   RewriteCond %{HTTP:Accept-Encoding} gzip
   RewriteRule (.*)\.js$ $1\.jsgz [L]
   
   AddType "text/javascript;charset=UTF-8" .jsgz
   AddEncoding gzip .jsgz

3. Test & reload your apache config
   

   httpd -t
   httpd -k graceful

Voila, correctly served pre-compressed static files. Just be sure to update your compressed versions whenever you update the content.

I took part in my first ever podcast last week on a panel discussing the Australian IT job market. Mark Jones hosts the weekly MIS Australia podcast for the AFR and invited me to represent the IT candidate market.

Also on the panel was Jane Bianchini, COO of Candle ICT (which seems to have changed it's name to Clarius in the last week - Moof ;), Carl Sjogreen, senior product manager at Google Australia and Peter Sheahan, an entrepreneur and author about Gen Y.

It was a good experience - I did just manage to get a few words in edgewise!

Use the embedded player or why not visit The Scoop and enjoy weekly panels talking about issues affecting the Australian IT industry.

Of course super-light threads for parallel programming is Erlang's killer feature, so let's apply that to a simple merge sort. Erlang's spawning and message passing interface is fairly straightforward, but a lot of parallel tasks are simple start -> process -> return type tasks, so we can simplify our syntax even further by using some nice helper functions such as Joe Armstrong's parallel map pmap or Anonymous Matthew's parallel eval pareval (via Philip Robinson's blog).

Parallel map makes light work of a massively parallel merge sort:

-module(mergesort).
-export([msort/1]).

%% terminal cases for list of less than 2 entries

msort([]) ->
    [];
msort([A]) ->
    [A];

% split list into 2 & mergesort them

msort(L) ->
    Mid = trunc(length(L) / 2),
    {A, B} = lists:split(Mid, L),
    lists:umerge( pmap(fun(I) -> msort(I) end, [A, B]) ).

This gets really interesting in certain cases eg. where acquisition of the data is expensive but randomly accessible.

Instead of passing in a simple list, our sort function could accept a future that would promise to return any requested linear subset of the data. Assuming we know the total length of the source list, no data is needed until we reach the merge phase at the bottom of the recursion stack, and incrementally more data is required as we bubble back up to the final result.

In this example we are doing our network retrieval in parallel with our sorting (which itself is happening in parallel). If the remote data comes from multiple hosts we could parallelise the retrieval by using multiple port instances.