How to use the FuncUnit web application testing framework with cloud-based Selenium service Sauce Labs
Functional web application testing with FuncUnit
We’ve recently started using the FuncUnit automated web application testing framework where I work. It is built on top of Selenium, but adds a lot of value as it uses jQuery’s selector syntax, which is much easier to work with than Selenium’s XPath selectors.
FuncUnit also provides many helper functions for waiting until elements exist on the page. This is invaluable if you are doing a lot of DOM manipulation in your application, which we certainly are.
Cross-browser testing with Sauce Labs
Something we wanted to do with our functional testing was run the tests in different browser environments using the cloud-based cross-browser testing service Sauce Labs, as this would save us from having to install older versions of various browsers. I wasn’t sure if this was going to be possible, but with some advice from Brian Moschel I was able to get it working.
How to combine the two
FuncUnit loads its Selenium settings from a file named settings.js which should be located in the same directory as your FuncUnit test page. In order to use Sauce Labs as your Selenium server when running FuncUnit, you need the following code in your settings.js:
You will of course have to sign up for a free account with Sauce Labs to obtain a username and access-key, and make your application publicly available.
If you now run the HTML page that contains your FuncUnit tests like so:
The settings in settings.js will be loaded and the tests will be run on Sauce Labs’ machines, not yours. As long as you open your pages in your tests using S.open('//index.html') the jmvcRoot will be applied and you will be able to test locally as well as with Sauce Labs.
Something to note
I wouldn’t recommend running tests on Sauce Labs very often, as it is much slower than running locally, and isn’t possible to debug.
The best way to run tests during development is to open your funcunit.html page in the browser you want to test in, the tests will then execute very quickly in a pop-up window.
Some settings for the Emacs Ibuffer mode, vital for managing large numbers of buffers.
I’ve found that one of the most useful features of Emacs is also one of the most sparsely documented: Ibuffer. It provides a way of filtering and then grouping the list of buffers that you currently have open, and greatly improves Emacs’ usability.
First of all, rebind the standard buffer list key binding C-x C-b to use Ibuffer:
(global-set-key (kbd "C-x C-b") 'ibuffer) ;; Use Ibuffer for Buffer List
Once you’ve used Ibuffer you won’t be going back so you should put this in your .emacs.
Defining your filter groups
You can define your filters and groups in the buffer list itself, but I find that it is easier to specify them in my .emacs:
I actually have different filter groups for work and home, and load them according to a global location variable.
Other useful options
There are a few other useful options that I didn’t find out about until I looked through the source:
Unless you turn this variable on you will be prompted every time you want to delete a buffer, even unmodified ones, which is way too cautious for most people. You’ll still be prompted for confirmation when deleting modified buffers after the option has been turned off.
(setq ibuffer-expert t)
Turning off ibuffer-show-empty-filter-groups is particularly useful, because the empty filter groups can really clutter things up.
(setq ibuffer-show-empty-filter-groups nil)
ibuffer-auto-mode is a minor mode that automatically keeps the buffer list up to date. I turn it on in my ibuffer-mode-hook:
This is something I had a problem with when I upgraded to Emacs 23.1. The latest version of Ibuffer doesn’t filter Dired buffers by the filename of the directory. This isn’t what I want – if I specify I filename filter I want any buffer with that filename to appear.
Rather than doing diffs against the 22.3 versions of the Ibuffer files to determine the changes (and possibly undo them) I’ve just copied the old versions from the ‘lisp’ directory of Emacs 22.3 To a ‘vendor’ directory in my .emacs.d and loaded that.
If I find a better way to solve this problem I’ll post an update.
Getting to know Mozilla's impressive new Ubiquity Firefox extension, and my experiences of working on a command for it.
I took a look at Mozilla Ubiquity recently, which is best described as an attempt at a natural language launcher for web services. It reminds me of the Mac launcher app Quicksilver. For example, if you type “weather liverpool” into it, you get the weather for Liverpool.
I personally really like this kind of thing because it means that I don’t have to use the mouse.
The built-in commands
Ubiquity comes with a number of built-in commands which I’m sure you can imagine:
imdb star wars will take you to the Star Wars page on the IMDB.
lookup gandhi will take you to the Gandhi entry of Wikipedia.
tweet The text of a Tweet will post a Tweet.
map 10 downing street london will get you a Google Map of the British Prime Minister’s house.
translate english spanish will Google Translate the selected text from English to Spanish.
Playing with a command
Soon after installing Ubiquity and playing with the built-in commands, I found a BBC iPlayer command that needed upgrading to the latest language API. I found this to be quite difficult, because there isn’t a great deal of support for debugging Ubiquity commands at the moment.
If you’re going to try to develop commands, I’d suggest using the CmdUtils.log() utility function to write debug messages to the console log in Firebug. The messages will only appear if you have turned on “Show Chrome Messages” on the Console menu.
I eventually got the command working and the changes were merged into the master branch.
UPDATE 2010/03: Ubiquity has now been put on the back-burner by Mozilla, in favour of Jetpack. As the developers found it quite difficult to upgrade the latest version to work with Firefox 3.6, only the earlier 0.1 version of the extension has been upgraded to work with it.
How the Compass CSS “Meta-Framework” has taken the pain out of my stylesheets. Something for which I am eternally grateful.
CSS and Me
For years I’ve been on the lookout for things that simplify the process of writing CSS because, as I’m a programmer, I suck at it. I’ve tried many times in the past to persevere with my own designs, and although I know how the whole HTML/CSS thing hangs together, I always end up going with a template lifted from the web, with some of my own minor tweaks.
This is probably because I lack the tools to build layouts, as like most non-designers, I don’t want to fork out a Photoshop licence fee. So I’m always keen to try out open source tools that make my CSS easier.
CSS for Programmers
The first time I used SASS I was quite impressed, particularly with the ability to define variables, as it meant that I wouldn’t have to use Find and Replace every two minutes. But I still saw it as a second-class offshoot of HAML. Now that I’ve got to know it I think of it as the preprocessor that CSS has needed for so long.
Greater than the sum of its parts
At the same time as I was initially playing with HAML and SASS, I also came across Blueprint and thought that it was the answer to my CSS prayers. But after a while I realised that something was still missing. Then I found Compass.
Compass calls itself a “Meta-Framework”, a term I can’t resist (we’ve reached the point where we have frameworks of frameworks, which makes me chuckle.) It combines the various CSS frameworks (Blueprint, Yahoo! UI, 960 Grid System) with SASS to create something that is much better than the sum of its parts.
By default it uses Blueprint to provide a grid system and baseline. It provides SASS mixins (which you can think of as CSS macros) which allow you to define your grid in SASS without modifiying the HTML. I like this as it keeps the layout in the CSS where it belongs.
Good with colours
Compass also features SASS mixins for manipulating colours, via a module named compass-colors. The module allows you to lighten and darken colours, and even adjust the hue and saturation:
My only complaint with SASS is that the syntax seems a little unnatural. Mixins are prefixed with a “+” and variables are prefixed with a “!”, which I don’t like because it makes conditional statements look a little strange:
Which to me reads as “if bold is false, set the font-weight to bold” when in fact it means the opposite. A more standard variable prefix like “$” would have seemed more natural.
But that’s just me nit-picking. I love the project after all. If you’re a programmer who hates CSS, you really should give SASS and Compass a try.
My experiences of blogging with the Webby static site generator, and not looking back.
I very rarely blog. I’ve posted a total of three times in the past eighteen months. Even when I have things to blog about, and I even start a post, other things get in the way and the posts get left on the shelf. I’ve decided that this is due to two things:
I don’t feel like anyone will want to read a post unless I’ve spent hours crafting it, and…
Editing posts in Wordpress is a chore.
When I see someone struggling with Word I know their life would be so much easier if they just spent an hour (if that) learning Textile and used it for formatting their documents. In the past I have written Ruby code to generate HTML documentation from a Textile source in order to avoid using Word. The documentation was much the better for it. (I plan to upload this to GitHub some day, under the name “Word Must Die.”)
And so I discovered Webby. This isn’t the first static site generator written in Ruby that I’ve played with (StaticMatic and Jekyll being the others) but it is the one I’ve got along with most easily. I was very close to going with Jekyll, but I didn’t like the lack of support for HAML and didn’t want to use a fork.
I’m also using Ultraviolet with for syntax highlighting, which uses Textmate bundles to support every language I could ever imagine blogging about.
My setup isn’t perfect yet, but with help from existing Webby users (notably Aaron Qian) and Disqus for comments, I’m hoping to have something which rivals my old Wordpress install.
The 5 things I like most about Git, Linus Torvalds' distributed version system.
I’ve been using Git for quite a while now, so here are my top five favourite things about it.
5. Only one .git directory and .gitignore file
A minor irritation with Subversion and CVS is that each checked out directory contains a “.svn” metadata directory. If you want to get a copy of the code without the metadata, you have to check it out with the special “export” command. Git keeps all of its metadata in a .git folder at the top level of the cloned repository. This means you simply delete the .git folder to remove all traces of “gitness”.
Files to be ignored can also be specified in one .gitignore file at the top level, and that file is committed like any other. This is something that requires editing the “svn:ignore” property in Subversion, which seems unnecessary when you could edit a single config file instead.
4. Branching is easier
I create branches more liberally in Git than I do in Subversion, because they are easier to create and merge. I can just hide a temp change on a branch and try code with or without it.
I often have experimental branches in Subversion, but they never stray far from the trunk, because otherwise merging would be too much of a pain. This is because Subversion branches are snapshots, and once the trunk moves on, the branch is left behind until you start to manually merge all those changes back. Git’s merging is much more sophisticated.
In Linus’ Google Tech Talk on Git he argues that Subversion’s boast that it makes branching cheap is concentrating on the wrong problem. Branching is easy. Merging is hard. Git focuses on merging more than Subversion does.
With Subversion I also feel like I need to tidy up my working copy before I create a branch in it, but with Git I can hack away, suddenly decide that what I’m doing should really be in a branch, type git checkout -b new-trunk and the code is now on a branch!
I consider git stash to be a part of Git’s branching features. It allows you to stash away changes for later. I use it if I want to split some changes off but not create a new branch. It’s also useful if you want to quickly tidy up the working copy without committing your work or throwing it away.
3. The Index
Commits in Git are a two-stage process: first you “add” your changes to a staging area know as “the index” and only when you’re happy with everything in the index do you commit it.
This is very useful if you are make a lot of changes and then realise that you want to commit them separately. When this happens in Subversion I have no choice but to manually copy files out of my working copy and pick the individual changes out. Git automates this process really well, particularly if you use the git add --patch command.
git add —patch
This is a contender for the best Git command, and I was amazed when I first used it. git add --patch allows you to interactively refine what you’re adding to the index by looking through the diffs in a file and choosing which ones to add. So if you were working on one change and left work in the evening only to start a new change in the same working copy the next morning, Git allows you to view each diff that you made and add them to a commit individually.
If you’re using a front-end to Git, you’ll be able to scroll through the diffs of a file, and decide which ones to stage, one at a time.
This feature is very useful if you are working on big files can change in different areas for different reasons e.g. CSS files. If you want to experiment with a particular style but want to keep it separate from other style changes, you can use add —patch to commit those changes separately.
A downside to this feature is that you can end up spending too much time refining commits, time you should be spending writing code! After a while with Git you should be able to reach a balance.
2. Local commits
What is not to like about local commits? You can commit while disconnected, and it lowers the barrier to entry for every open source project that uses it. Anyone can develop their own Linux or Ruby on Rails. You even get the whole history of a project when you clone it!
Martin Fowler suggests refactoring a project in order to get to know it, and local commits allow you to commit refactorings of a major project without interfering with the master branch. You may never use those refactorings, but the process will have accelerated your learning.
Many clones means many backups
I’ve never experienced the horror of a lost or corrupt source code repository, but I can imagine how painful it must be. With a distributed version control system like Git every clone is a full copy of the repository, so if the original is lost then the bulk of the history will still be there in one of the clones.
You can amend your local commits
Part of the local commit functionality is the git reset command which allows you to undo commits, without losing the changes (if you use the “soft” reset option they will remain staged in the index.) If you’ve done something you really shouldn’t have, or just screwed up a commit message, this is very useful.
This isn’t a feature of Git, but it was my primary motivation for getting to know it. It’s an amazing piece of work – like a wonderful blend of Sourceforge and Twitter. It’s very well designed and a joy to browse. When you compare it to Microsoft’s open source project hosting effort CodePlex, you can see just how much they are playing catch-up in this area.
I don’t even think the code you push to GitHub even needs to be anything special. None of the things that I’ve pushed are fully-fledged open source projects. Here’s someone who pushed everything they had (30 projects). And why not?
GitHub also features Gist, a pastie site for posting code that isn’t significant enough to warrant its own repo.
The way the site (and Git itself) is designed encourages collaboration on projects. People can fork projects and then request that the owner takes a look at their efforts, and they can even go as far as to comment on commits. Here’s a funny example of people arguing over a Ruby on Rails commit.
Some tips for learning Git
I’m not ashamed to say that Git took a while to get my head around, the fact that I don’t use it day-to-day in work probably didn’t help. Some pointers that I think apply to learning Git are:
Be sure to use the repository visualization tool “gitk” from the off, or some other graphical tool. It makes things eveything much clearer than the command line tools.
Practice on a non-public remote repository, or at least an unpopular one. Git allows you to undo commits, but you won’t want to undo a commit that you have pushed.
Try to empty your mind of Subversion while using Git, the two systems are more different than you initially think. A Git checkout is not the same a Subversion checkout!
You don’t need to use the full SHA-1 when refering to commits. In Subversion it’s easy to look through a log and find the revision you want by a simple revision number. Git replaces this with a terrifying 40 character SHA-1 ID, which would take you a while to shout across the office. You only actually need to use the first 6 characters of the ID.
Don’t be afraid to open up the “.git” directory and look around (assuming you’ve pushed it to a remote first!) The key to understanding Git is understanding the objects that comprise a Git repository
That last suggestion accelerated my learning more than anything else. The structure of a Git repository is simpler than a Subversion one, and all the command line tools do is modify them. Scott Chacon’s Git Internals PDF at Peepcode helped me a great deal in understanding the file system. I think a lot of that content is now available in The Git Community Book which was also written by Scott (he’s a GitHub employee.) The Git Parable by Tom Preston-Werner, a GitHub co-founder, takes a different approach to the same subject matter.
My account of the Howduino Arduino hacking event in Liverpool in May 2009.
If you haven’t seen one yet, the Arduino microcontroller is the cutest piece of hardware since WALL-E, if you think circuits are cute that is. Like my first iPod, every time I see it I am surprised by how small it is. The hardware is pretty simple, just an ATmega168 microcontroller and some inputs/outputs, meaning that they’re pretty cheap too.
I’d known about them for a while (and had attended Adrian McEwen’s talk at the Liverpool BarCamp back in December) but had put off buying one because I’ve always been under the impression that hardware is much harder to debug than software, and I pictured myself spending hours of my precious free time trying to detect an elusive problem. So it wasn’t until Adrian and Thom Shannon organised the inaugural Howduino event in Liverpool that I finally got an excuse to buy one.
When I finally took the plunge, I bought an Ethernet shield along with the Ardunino itself, partly because it looked like tinker.it would sell out before the event, but also because I thought that whatever project I did would have to involve the internet.
Preparing for the event – My first project
So upon receiving my Arduino I set about getting an LED to blink (the “Hello World” of Arduino development). That was easy, so the next step meant an excuse to use the Ethernet shield – controlling an LED via the web. This turned out to be suprisingly simple thanks to an open source library named Webduino.
Webduino is a small HTTP server for the Arduino, and handles GET requests, including parsing query string parameters. That was all I needed to start receiving HTTP requests on the Arduino. So with a simple web page which contained 4 checkboxes and a submit button, I was able to turn 4 LEDs on or off depending on the value of their checkboxes.
This was very encouraging, as although lighting up LEDs isn’t very useful, the implications of being able to control something physical via a web page was quite exciting, especially considering that I’d only spent a few hours getting it to work. I was an Arduino fan already.
At the Howduino event, I decided that I would try to race remote controlled cars based on how well certain search terms were doing on Twitter. I would generate a two timelines, and trigger the forward motors of the cars according to their timelines.
Getting the timeline data
When I initially conceived of the idea I had been intending to use the ethernet shield to access the Twitter API in real time, but it soon became obvious that the ethernet shield would be unnecessary. I could get all of the data I needed before the start of the race using a Ruby script, and then send it to the Arduino in a stream of serial bytes via the Arduino IDE. Each car would have a character in the stream, and when that character appeared it would move a little (more on this later).
A snippet of a timeline with a 0 representing one car and a 1 the other would look like this:
0 0 1
The 9 is a null, meaning that neither car moves for that step.
I wrote a simple program in Processing for simulating the timelines to see which races would be most exciting in terms of a close race, so that I could choose which races to show to people.
Cheap Remote Control Cars
I bought two similar remote control cars that operated on different frequencies. My plan was that I could simplify the project by just connecting the remote controls to the Arduino rather than trying to control the motors of the cars themselves. I planned to connect the forward switch on the remote control and trigger it whenever the car appeared in the timeline.
I had written the Ruby timeline processing code before the day of Howduino, so I was pretty confident that I would be able to have some exciting Twitter races on the day. Unfortunately, two problems meant that the races didn’t quite go to plan…
Getting ahead of myself
Before the event, I started to get clever, thinking that this was too simple and needed a bit more control. I’d bought an analogue slider, so I thought I would use it to control the speed of the race. My intentions were good – while testing with the Processing simulation I had found that some races were very fast and some were very slow, depending on the participants of the race.
For example a race between the finalists on American Idol during the final itself would be very fast as hundreds of Tweets occur each second, but two more obscure topics would be much slower as their Tweets trickled in over months.
I later found that adding the slider actually meant that I couldn’t limit the rate of the serial bytes to the Arduino, and it ended up being flooded. The end result of this was that the race would be over before it began, and the cars would just stutter a little and then stop. I didn’t actually realise this until after Howduino.
Survival of the fittest
Something else I discovered after the event when I started running a control race – both cars being sent the exact same timeline – was that one car (the blue) was much less powerful than the other. This was a big setback, because without adding a handicap in the code the race could never be fair.
Maybe I should have bought more expensive cars!
The future of Twitter Racing
I learnt a lot from my couple of days of Twitter Racing, but haven’t played with it since. If I attend another Arduino hacking event I’m sure I’ll revisit it and make it much more of a success!
The Twitter Racing code is available on GitHub. It’s pretty rough and needs refactoring, particularly the Processing code as it was my first attempt at Processing.
My round-up of the first two-day BarCamp in Liverpool, United Kingdom.
It seemed like every major city in England except Liverpool had had a Barcamp until the first Saturday in December, when Katie Lips and friends arranged for a weekend of talks at the Novas Contemporary Urban Centre. It was a full two-day BarCamp, and there were about eight slots each day, so I saw a lot of stuff. Here's what I saw, and what I made of it:
Lateral Visions 3D Web - Stephen Clibbery
I started off with Lateral Vision's 3D Web demo. This is an attempt to give web developers and designers the option of 3D worlds rather than text-based web pages, viewable via the browser using a rich content plugin developed by Lateral Visions. It has an advantage over existing 3D worlds such as Second Life as it can be run inside the browser (once you've actually installed their plugin.)
The technology doesn't seem to be intended to replace traditional speedy point-and-click web browsing, but to be applied in certain situations which suit it. The use in online shopping was illustrated with a mock-up Apple store which you could walk around and view products. The application to viewing property online was obvious, although I don't know if many estate agents have training with 3D Studio Max. Microsoft Photosynth is probably a better option for that, as you can build a half-decent 3D world out of a series of photos.
I know things like this have been around for a while (VRML has been around since the start of the web) but it's definitely a problem worth working on.
Dave gave tips for would-be iPhone developers (although a show of hands indicated that nobody was planning on writing an iPhone app) and showed off his Charades app which he has released just in time for family get togethers at Christmas.
The key points I picked up were:
Registering as a company in the US so that you can get your application on the App Store is a major PITA.
Your application needs to look nice. "Apply polish liberally" is how I think Dave put it.
I'm afraid I didn't make any notes about this talk, which I feel terrible about because Dave is such a nice bloke!
This is a talk that I knew about before the schedule was put together and looked forward to a lot as I've been meaning to play with an Arduino for a long time but just haven't got around to it. Adrian had dismantled a simple toy gun and attached the Arduino to the switch. The Arduino was waiting for a Perl script to notify it that someone had posted a #bcliverpool tag on Twitter, and would turn on the toy gun. Adrian had also put together a similar device that blew a bubble whenever the tag appeared:
Don makes a living out of producing screencasts, usually about Mac software, and gave a lot of good advice on making screencasts of your own.
His recommendation for screencast recording software on the Mac was ScreenFlow. Snapz Pro X was popular a few years ago, and iShowU is good if you don't want to spend too much money. He uses Final Cut Pro for post-production.
Cristiano has developed Facebook applications for Nudge London, and talked us through what he has learnt. The main tip was to start at the Facebook Developers Wiki and not to start from scratch - use one of the Facebook API libraries that are available for your langauge of choice. His slides are available in his blog post.
Microsoft kindly paid for the beer at the after-party at the end of the Saturday night, and there was lots available. I know I didn't run out of drinks vouchers.
There was also a Startup Stars pitching event organised by Katie Lips. I couldn't hear exactly what was going on because I was at the back of the room, but it appears that Adrian McEwen won it.
I spent most of the night talking to Chris Alcock whose daily .NET news blog is becoming very popular. Award winning blogger, Microsoft employee, and ex-Liverpudlian Steve Clayton was also around, but I didn't get to speak to him!
This was an art project which proposed a law that would make it illegal for anyone to eat meat unless they had killed an animal and got their "meat licence." It was a good presentation, and I could see the twisted logic behind it, but I still can't see any government going for it!
The highlight of the talk was when John mentioned that the red "Something is wrong with your Drupal installation." message on his website for the project had eventually become reassuring, because if any content was appearing then that was better than nothing. I've spent some time with Drupal, and can totally understand what he means.
This presentation was about a proposed wiki of scraping code. The code will be executed via the site, and will regularly collect data that can then be used in mashups. An example of a scraper that Julian showed collected entries in Merseyside Police Force Helicopter logs. The data will end up in a simple database table with columns such as (Summary, Time, Post Code, Northing, Easting etc.)
There was a lot of interest from the crowd, but I don't know if Julian and Aidan managed to grab many contact details. The Codewiki isn't public yet, but I promised Aidan I'd write some scraping code. It will probably be in Ruby with hpricot, I assume Julian has been using Python. I'll be sure to update this post when the codewiki is live!
UPDATE: The Codewiki project is now live as ScraperWiki.
This wasn't a talk, but was one of the highlights of the BarCamp nonetheless. Thom, the organiser of the Liverpool GeekUps, put together a multi-touch screen using a row of LEDs, a piece of perpex, some cardboard, some tracing paper, an old webcam, his laptop, and a multitouch framework (I didn't ask which one, but I assume it's WPF based.) It worked very well considering what it was made of!
I'm afraid I didn't see anything more on the Sunday, because I had made plans to see Zack and Miri Make a Porno (not exactly worth leaving for I know.) I sincerely regret leaving because I missed out on the game of Werewolf.
I think Liverpool's first Barcamp can be considered a runaway success, and all of the organisers, speakers, sponsors, and attendees should be applauded!
I gave another talk at Liverpool GeekUp, a shorter one this time on Erlang, Ericsson’s programming language and application platform which is being applied in back-end web projects at places such as Amazon and Facebook (SimpleDB and Facebook Chat respectively). It was a follow on from both Chris Alcock’s F# talk at the Liverpool .NET User Group and my own Comet talk the month before (as Erlang is used as the back-end of Facebook’s new chat Comet implementation.)
I didn’t want to just post the slides as the talk was intentionally short and there are a number of great links (some that I’ve only discovered since the talk) that I have to point people towards. I also wanted to make a few points about what Erlang is and what it isn’t. For one thing, it is certainly…
…Not Just Another Programming Language
I’ve got the feeling from people who have heard about Erlang but not looked into it that they’re expecting it to be the new Java/C#/PHP/Ruby (insert language of choice) and they’ll just use it for the same standard everyday tasks that they use language X for. Unless you spend your days writing servers (of whatever description) then that is unlikely to be the case. Yariv Sadan is working hard to persuade people that Erlang is a great platform for writing web apps, but I’m not convinced, at least not for the front-end.
A few years ago Steve Yegge blogged at Amazon (skip down to Syntax for distributed computing) about a language called Erlang that had special syntax designed specifically for its problem domain:
So Ericsson engineers decided to solve our problem, the one we’re talking about hurling J2EE books at in the hopes of stunning it, with a new programming language made just for distributed computing. They cleverly called it “Ericsson Language”, or Erlang for short.
They created syntax for the network calls, for running distributed processes, for doing peer reelections, restarting processes, for doing asynchronous event-based messaging, for doing exponential backoff and retry, all kinds o’ stuff.
Rumor has it that they’ve built themselves one of the largest real-time, transactional distributed systems in the world, using only about a million lines of Erlang code, which they estimate would be about 20 million lines of buggy C/C++ code.
Steve has made the point (read the entire post for a more in-depth view) that language matters and some problems are so hard to solve that they need a language that is designed specifically for solving them. The problem in this case is writing software that can run on a number of different CPUs (distributed or otherwise) in such a way that those CPUs block each other as little as possible. As the amount of speed that can be wrung out of a single CPU has peaked, Erlang’s approach to software has attracted attention.
So why is Erlang so well equipped for parallelism? Simple…
Single Assignment Semantics
I grumbled at Chris’ talk that F# seemed too imperative and that I thought Erlang justified its use of functional language features better. My main gripe was the lack of single-assignment semantics. To me SAS is Erlang’s killer feature, and the reason people are seeing it as a solution to programming for multi-core processors. If shared variables can’t be reassigned, then you avoid all of the headaches associated with traditional thread-based concurrency. It also does away with locks completely, meaning that processes are much less likely to wait on each other, and linear speed-ups on multi-core machines become much more likely.
Erlang is very strict on immutability – once a variable has been assigned then it can’t be reassigned. Seriously. Kiss goodbye to reassignment while you’re working with Erlang, even with local variables. If you really want to do it you just have to create a new variable:
It may seem too strict to restrict the reassignment of local variables. I found an excellent post by Luke Hoersten Why Make Erlang a Functional Language? in which he argues that extending SAS to local variables adds efficiencies to the language which compensate for the overheads of message passing. Whether you agree with that argument or not, you’ll find that while working with Erlang you’ll rarely need to reassign a variable, precisely because of Erlang’s functional language features. Here’s a quick length() example:
The function uses recursion to iterate over the list and increment a counter without reassigning any local variables. Therefore Erlang justifies its use of functional programming features. Hence my talk.
Here are some Erlang links that I think are worth checking out:
Planet Erlang is a Digg-style site for Erlang content, it’s down at the time of writing, I assume it’ll be back up soon.
The aforementioned Luke Hoersten has written a tutorial about developing Scalable Web Apps with Erlang & Python. Like I said, Erlang is really a back-end language – there are better choices for front-end code, but there is no reason why they can’t work together.
There’s also an unintentionally funny promotional film that Ericsson made about Erlang. I deliberately avoided embedding it here, because you would probably have just skipped to it and got quite a bad impression of the language!
Links on the subject of Comet, and the talk I gave at Liverpool GeekUp on it.
I’m due to give a talk on Comet at Liverpool GeekUp tomorrow, and the slides should surface here at some point. In the meantime, I’ll provide the links that furnished me with so much inspiration. Start with the ones at the top first: