Harry Shearer

Check out the latest MyDamnChannel video "935 Lies" from Harry's forthcoming record Songs of the Bushmen, available soon via digital download only.

Not only do these guys push the standard on what beautiful, agile, maintainable code should look like, but they continue to impress me with their pursuit of the best balance of form and function within a css based xhtml design. Recently 37signals pushed out an update to Basecamp, a tool I rely on daily, and I am pleased with the results thus far.

I feel they have done an awesome job of visually calling out the things that matter on the page, without cluttering things up with too many icons, dividers, or graphics. Score uber cool points for using colors to group conceptional elements. Also score points for not deviating from the current UI too much… I felt right at home with the changes, they were subtle enough that I failed to notice many of them right away.

Ok… fan boy rant over. =)

I recently started reading up on Erlang, trying to decide if I should invest some time into learning it. This was mainly in response to some of Ruby’s shortcomings, as I was knee deep in writing some drb (distributed ruby) code over the last couple of weeks and really resented that fact. This resentment stemmed from the fact that I built something fairly simple, expected it to work, and it exploded with every approach I had tried so far. One of the (what I felt were) ‘simple’ things it did involved using curl to ping a few sites, when a user changed a Rails object. The Rails page didn’t need a response back from the ping, just spin off the process to ping the site. The processes are not terribly long running, and it seemed to make a lot a sense to just fork off a few threads during a rails response/request cycle… if that worked. But alas, Ruby is not thread safe. Trying even simple forks off Rails to the OS threads caused much bad juju, often not showing up until testing it in production environments.

I looked around to see if other dynamic languages have this problem with threading. It seems that some do support threading, or are currently working towards solutions, that are not the ‘green thread’ solution that Ruby currently provides (Ruby will have native threads in 2.0). I had been hearing a teeny tiny amount of buzz about Erlang, especially regarding to threading questions and also reading about how one might approach coding really high load server software in a dynamic language.

From In a nutshell, what is Erlang?

Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson. The most popular implementation of Erlang is available as open source from the open source Erlang site. The goal of Erlectricity is two-fold: expose ruby code to Erlang, such that Erlang applications can take advantage of the breadth of ruby libraries, and secondly, expose the OTP to ruby such that fault-tolerant distributed systems will be easier to develop.

So, learning Erlang here and seemed like something to spend time on. Its highly functional syntax is really appealing to me, even if it is much less ‘pretty’ then ruby. The concurrency and threading support are also big bonus. Even with these appealing features, I found myself floundering on starting to learn Erlang, as I couldn’t really think of any project that I could use Erlang for. I like to start a new language with some problem to solve, nothing too trivial, nothing that couldn’t be done in a weekend. It helps me conceptualize things easier when I have a goal in mind. I couldn’t think of anything to do with Erlang though, till I ran into this project that should be fun to play with. It is called ‘Erlectricity’, and it’s purpose is to provide an Erlang / Ruby Bridge.

From Erlectricity: Hi Ruby, I’m Erlang.

The goal of Erlectricity is two-fold: expose ruby code to Erlang, such that Erlang applications can take advantage of the breadth of ruby libraries, and secondly, expose the OTP to ruby such that fault-tolerant distributed systems will be easier to develop.

Neat. In its current implementation the stated goals are not 100% complete, but I am looking forward to playing around with what is currently working.