Michael Käsers Weblog

Today we tried to optimize the loading times of the local.ch pages that use Google Maps by (among other ideas) making the JavaScript loadings non-blocking. To see if our changes actually made a difference, I wanted to measure the time between opening the page and seeing the first output of the browser.

I evaluated a number of tools but none of them was able to give me the number I actually wanted. I tried:

• FireBug, which has an excellent Net tab but doesn’t show any information about rendering
• Hammerhead, which only measured the time until the page is fully loaded, so that it didn’t matter if the map was loaded after the first rendering or before
• Page Speed Activity, which shows information about the rendering but doesn’t make it easy to get raw numbers

I then stumbled upon the MozAfterPaint event and decided to write a short script myself that can be added on top of the HTML page that you want to analyze. It outputs the number of milliseconds between Firefox receiving the page and displaying the first element into the Firebug console. With this number, we were easily able to show the benefits of each optimization, and it also was nicely in agreement with how the browsing on the optimized pages actually felt.

    (function() {
        var log = function() {
            console.log("Painted after " + (now() - start) + "ms");
            window.removeEventListener("MozAfterPaint", log, false);
        };
        var now = function() {
            return (new Date()).getTime();
        }

        var start = now();
        window.addEventListener("MozAfterPaint", log, false);
    })();

Today I participated in a rather special hack day at the local.ch offices. The topic was JavaScript, and all engineers that were already fairly knowledgeable in it picked a topic and presented it in 15 minutes. Additionally, they created a “mission”, which was a short exercise that should be solved in pair programming and that required using the techniques that were presented.

At the end of the day, after we already went through tools, communities and various good and bad parts of JavaScript, I finished with a much shorter version of my talk about node.js from the last webtuesday. For the mission, I tried to create something that is easy, fun, and highlights the ideas behind node well.

The task was creating a small asynchronous web application where engineers can register themselves for Foosball, and then get immediately alerted when there are enough players. I provided a skeleton that already does nearly everything and only needs about 10 lines of code to be finished – but these lines require you to think a bit about asynchronous programming, events, closures and the concepts behind node.js.

The target time was 20 minutes and there were quite a few pairs that finished it faster, and that included compiling! Shows how easy it is to get started in node.js, and (of course!) what a clever bunch of engineers work at local.ch. I also had the feeling that they found it quite interesting.

If you are interested, you can download the mission for yourself here (nodemission.tar.gz) and give it a try. It includes the skeleton and a manual containing a longer description of the task and some hints. Feel free to contact me when you have any questions.

This week I was invited to give a talk about node.js at the Webtuesday in Zurich, which is a monthly meeting of web developers of various companies that are located in the city. The format is usually a semi-formal talk for about an hour, and then some drinks sponsored by the company that is hosting the event (which was ad novum this time – many thanks!).

node.js is an interesting project that I’m following since a few months. In those few months, I found myself using it several times to solve some small problems quickly. I’m also working on a side project that uses it, but that’s not yet ready for presentation.

I think the presentation went really well and I was able to make the point I wanted to, which is showing what event driven servers are about, in what kind of tasks they excel and how it can fit into an existing architecture for a web application. I didn’t show too much of the API itself, as that’s useless as long as the documentation still can be printed to 10 pages.

You can find the slides I used on slides.liip.ch or directly embedded here:

As some of my non-existing readers might know, I like to play Savage 2 in my spare time. Lately the game has had some problems with the stability of it’s authentification and master servers. To find out how bad the situation is, I decided to set up some monitoring. After comparing a few of the available open source monitoring tools, I decided to use Munin because it does what I need and is very easy to set up.

To get the data for the graphs, I had to write a few custom plugins. I chose PHP as programming language because the master server which I’m querying uses serialized PHP data as input and output format. I don’t think that the actual plugins are too interesting, but I decided to share my general layout for a Munin plugin in PHP here as I was unable to find one anywhere else on the internet.

#!/usr/bin/php
<?php
if ($argv[1] == "config") {
  // Important settings so Munin knows where to display the graph
  print "graph_title Title of your graph\n";
  print "graph_category Category\n";
  // Add additional parameters here (see munin documentation)
  print "graph_args --base 1000 -l 0\n";
  print "graph_vlabel players\n";
  print "graph_scale no\n";
  // Labels that you want to graph
  print "label1.label name\n";
  print "label2.label name\n";
} else {
  // Output your actual data here
  print "label1.value 123\n";
  print "label2.value 345\n";
}

For a private project I’m working on at the moment, I wanted to integrate Facebook Connect into my favourite web framework Django.

After some research, I found two applications that can do this job:

• django-fbconnect
• django-facebookconnect

I tested both applications, but was unable to set up django-fbconnect successfully due to its very limited documentation. The second app on the other hand looked much more stable and had at least installation instructions. It also has simple caching which is helpful because Facebook does not allow you to save user information for longer than 24 hours.

While I was able to login to my site with my normal Facebook account, which is a few years old, I got an error when trying it with a completly new account. The problem is that new accounts seem to have an ID which does not find into a normal integer field, so that the app cannot correctly save the mapping between local and Facebook accounts. I submitted an issue to the django-facebookconnect project and included a patch which fixes the problem.

Another thing which I don’t really like is that the app invokes the Facebook API method getLoggedInUser on each page request to check if the user has logged out of facebook in the background. This slows down the site tremendously and will probably not scale well. Facebook itself recommends caching the result of this call for the active session. A much nicer solution would be:

• Use the ifUserConnected and ifUserNotConnected callbacks on the client side
• Explicitly check the login status on the server for POST requests for security reasons

I will write another blog post when I tried this out.