Although the presentation was a bit messy (the room's technician hijacked my laptop for a couple of minutes to fix an issue with one of the screens), the framework seemed to struck a chord with many developers. Afterwards it was made very clear by some of them that I should get it out in the open as soon as possible. I specifically asked them "how?" and it was unanimously decided it should definitely be on GitHub. So there you go.

Unfortunately, from the San Francisco hotel I'm currently staying in, I can't seem to get a good enough connection to this site's FTP server or otherwise I would have put up a demo and made my slides available. That will have to wait until I get back to The Netherlands. I will try to start adding some useful documentation as well.

I really hope some people in the jQuery community will pick up this ball and start running with it. Several people at the conference said it could be a useful tool including some jQuery and jQuery UI team members. If you like it, please send some love in eBuddy's direction since they were the ones who allowed me to develop and release it in the first place.

I would like to thank the jQuery team and all the other speakers having me there and making this weekend an unforgettable experience. Hopefully, I can meet you all at another conference in the near future. Perhaps jQuery Amsterdam 2010?

P.S. Ralph Whitbeck and Rey Bango of the official jQuery podcast interviewed me right after the presentation and put up the video as well and I put up the slides as well.

Even though eBuddy's current web messenger is an awesome product and – with over 2,5 million users daily – the most popular multi-network IM client on the web, it definitely has its shortcomings, both for users as well as for the developers working on it. The new messenger has been designed from the ground up to overcome these shortcomings, creating a product that is both easier to work with as well as to work on.

In the future, I'd like to tell you about some of the technical improvements we've made, such as the publish/subscribe based architecture and the custom made automated GUI testsuite. For now, I'll just point you straight towards web.ebuddy.com and hope you'll have a great chat experience. If you have any remarks, don't hesitate to contact me via the link below or click the "Feedback" button at the top of the messenger.

Click inside the square on the right to see the plasma effect in action. Click again to stop the animation.

First a little disclaimer: usually, these effects are coded by very smart, very math-savvy programmers that know their target system inside and out. None of these attributes apply to me so I just brute-forced my way through the implementation making convenient choices whereever possible:

1. The canvas is 32 units wide and 32 units high.
2. One such unit is an 8 by 8 pixed div element, making the total width and height 256 pixels.
3. The color pallette will consist of 256 colors.

After some research I found that the principle behind the effect is really simple. The base is any function f(x, y, t) = n where x and y are the coordinates in the canvas, t is the time and n is an integer between 0-256, representing a color in the palette. When we have such a function we initiate by drawing the canvas for t=0 after which we redraw the canvas periodically for new values of t, which generates the 'flowing' colors. The next step was to find such a function.

The first function

Remember that the output of the function should stay in the 0-256 range. The easiest way to guarantee this is to base our functions on sin and cos, since their result is always between -1 and 1. For clarity I will not discuss the normalization from floats between -1 and 1 to integers between 0 and 256 here so we can suffice with f being in the -1 to 1 range.

A simple example of the type of function we're looking for is then: f(x) = sin(x / 40.74). The 40.74 is to make our sin have a period of about 256. If we then map the output to a greyscale palette where 0 is black and 255 is white we get something like the picture on the right.

The second function

Looks nice, but it doesn't resemble a plasma effect, so let's investigate a little further for a nice function. Something that's used often in this effect is the sinus of a distance to a certain point in the canvas. Here's such a function: f(x, y) = sin(distance(x, y, 128, 256) / 40.74), where distance(x1, y1, x2, y2) is the distance between (x1, y1) and (x2, y2). In our case we're measuring the distance to the center of the bottom edge. Mapping this to our palette we'd get something like the picture on the right again.

Combining two functions

The last picture already looked a bit more like a good base for a plasma effect. The interesting stuff happens if we combine the two functions and average their results. As you can see in the picture on the right, this is getting pretty close to the effect we're looking for: flowing, asymmetrical blobs of color. Two things remain: finding a nicer palette of colors to map and adding in some animation.

Animation

Adding animation is reasonably straightforward. We just introduce a variable t in a strategic place to our functions which we continuously increment. Usually for these effects t starts at 0 and is incremented by 1 each step. In my experience floating point arithmetic isn't particularly slower than integer arithmetic in JavaScript so I chose to increment by 0.1 because it was more convenient. Here's an example of the 2 previous functions with the added t variable:

1. f(x, t) = sin(x / 40.74 + t) - which gives the effect of the first pattern moving to the left.
2. f(x, y, t) = sin(distance(x, y, (128 * sin(-t) + 128), (128 * cos(-t) + 128)) / 40.74) - which gives the effect of the second pattern rotating around the center of the canvas.

Colors

Believe it or not, we're not completely done with sinus and cosinus yet. The nicest effects are achieved with palettes that smoothly 'wrap around'. These types of palettes are usually generated with mathematical functions. Here's a few examples where for each palette we iterate i from 0-256 and the red, green and blue values are normalized to 0-256 integers again:

red(i) = sin(π * i / 32)
green(i) = sin(π * i / 64)
blue(i) = sin(π * i / 128)

red(i) = 0
green(i) = cos(π * i / 128)
blue(i) = sin(π * i / 128)

red(i) = cos(π * i / 128)
green(i) = sin(π * i / 128)
blue(i) = 0

Combining all this: the functions, the animation, the palette I ended up with the plasma effect shown above. It should be clear right now that there is an endless range of possibilities for variations on this theme. Like so many things I write about this started of as a little 'how does that work?'-experiment. This is how I think it works but if you're reading this and have a better idea, don't hesitate and let me know!

Flexible panels

The ideal I'm trying to achieve is to have a viewport-filling layout with flexible and fixed panels combined. A common example is what I usually refer to as the "Outlook layout". Here's a more complex example.

The hard part here is to have flexible panels that fill whatever space isn't taken up by other (fixed) panels. Ideally you'd be able to write something like this:

.contentPanel {
    width: calc(100% - 200px);
    height: calc(100% - 400px);
}

...which in CSS3, you will be able to. However, we're not going to wait for that, so we're going to use an often-ignored feature of CSS: if you have an absolutely positioned element and you specify left and right but not width, the width becomes flexible: the edges stick to their coordinates. The same goes for height if you spefify top and bottom. Using this technique, we can get what we want:

.contentPanel {
    position: absolute;
    left: 200px;
    right: 0;
    top: 400px;
    bottom:0;
}

But the story doesn't end here. Although this technique runs fine in (standards mode) IE7, IE6 does not support it. For this browser, we will use an even rarer technique: [removed]).

[removed]) is an IE-only CSS statement that works a lot like calc() mentioned above. With it, you can assign the result of a JScript expression to a CSS property. In our case:

.contentPanel {
    width: [removed]this[removed].clientWidth - 200 + 'px');
    height: [removed]this[removed].clientHeight - 400 + 'px');
}

An example

Let's create an example to illustrate the two techniques and how to combine them. Here's a set of three panels, the top one fixed height, the left one fixed width, the remaining one flexible:

As you can see, #panelRight fills up whatever space remains. Its CSS is very simple:

#panelRight {
    top:20px;
    left:100px;
    right:0;
    bottom:0;
    width:[removed]this[removed].clientWidth - 100 + 'px');
    height:[removed]this[removed].clientHeight - 20 + 'px');
    background:#F7CCF7;
}

Issues

expression Is of course a non-standard CSS property that will invalidate your CSS file. Browsers that don't support it will gracefully ignore it (as they should) but the W3C CSS validator will not. There are several ways to hide the code from validators (i.e. conditional comments) so if you care about validating your CSS you should take some extra steps there.

Another issue is that I haven't found a way yet to combine multiple flexible panels horizontally or vertically. The method works beautifully, however, in my experience and makes it really easy to define flexible page layouts with just a few lines of CSS and the most basic HTML.

Another method

A reader called Fabrice pointed out another way to get the same results using bitmasks. For example, when you want to get all the combinations of items from [0,1,2] you create a list binary representations of the numbers 1 to (2³-1):

1. 001
2. 010
3. 011
4. 100
5. 101
6. 110
7. 111

Applying each of these numbers as a mask to the original array gives us all the combinations:

1. 001 × [0,1,2] = [2]
2. 010 × [0,1,2] = [1]
3. 011 × [0,1,2] = [1,2]
4. 100 × [0,1,2] = [0]
5. 101 × [0,1,2] = [0,2]
6. 110 × [0,1,2] = [0,1]
7. 111 × [0,1,2] = [0,1,2]

It's a very simple algorithm to understand and to implement. Since this returns all possible combinations the only thing left is filtering for results of a certain length. Here's an implementation in JavaScript as an extension on the array prototype:

Array.prototype.combinate2 = function( length ) {
    var result = [];
    // iterate from 1 to 2n
    for (var i = 1; i < Math.pow(2, this.length) - 1; i++) {
         var combination = [];
         // For each value of i, check the individual 'bits' (powers of 2
         // components). If 2m is a component of i then this[m] is a
         // part of this combination
         for (var j = 0; j < i; j++) {
             var mask = Math.pow(2,j);
             if (i & mask) {
                 combination.push(this[j]);
             }
         }
         if (combination.length === length) {
             result.push(combination);
         }
    }
    
    return result;
}

Performance problems

Unfortunately, the simplicity of the algorithm comes with a price: the time it takes to execute increases much more quickly with the length of the array than the other one. If I knew something about big O-notation I could probably write something profound about why this is the case. It's a shame I don't because I feel it would really help understanding stuff like this. On the other hand, after having taken another look at the code from the original post I now fully understand what it does. Perhaps I will dedicate another post to that subject.

Peter Paul Koch (Quirksmode)

First up, at 9:30 AM, was PPK with a presentation on cross-browser JavaScript event handling. Most people were in on time, for a change and there were an amazingly little amount of laptops being opened by attendees. (something that usually annoys me alot) PPK, obviously no stranger to presenting delivered a flawless and technically very deep presentation about the differences between the W3C's events spec and the real world as implemented by Safari, IE, Opera and Firefox. Quote of the day: "I think I'll start looking into this Firebug thing, I hear it's pretty good."

Folke Lemaitre (Netlog)

Next up, was Folke who presented on the scaling of Netlog's back-end architecture. As a front-end developer, most of that stuff was somewhat over my head but interesting nonetheless. I know my eBuddy colleagues who deal with the scaling of our own platform were listening attentively :)

Mark Birbeck (W3C)

After the morning break, Mark Birbeck took the stage with a presentation about markup languages that I'm sure was not to everybody's tastes. I found it to be the most interesting talk of the day because he concluded that markup languages like XForms and SMIL are an excellent way to abstract the complexity of JavaScript away. That's something that I've been preaching since the early days of Backbase (and by the way, my subject of the presentation I gave at XTech 2006). Later on, I realized why Mark's name was so familiar. He was once responsible for building a plugin for IE that added XForms support.

Nate Abele (CakePHP)

Lots of controversy ensued when the first Nate took the mic. After a brief introduction about what frameworks are and why and when you should use one, he proceeded to rip apart some well-known competitors of his CakePHP framework: Zend, CodeIgniter (on which this blog is built) and Rails. It was quite funny actually and I found him to be refreshingly honest. A welcome change from the let's-pet-each-other-on-the-back- syndrome.

Nate Koechley (Yahoo!)

Unfortunately I had to miss this one, as I had to be someplace else. I heard it was really good though; a very comprehensive presentation about startup performance, even though a lot of the material was well-known to the crowd.

Open Source Pitches

As I still had to prepare some slides for my presentation I decided to miss out on these. I heard there was a lot of disappointment that the 5-minute Phusion Passenger pitch was spent on promoting Rails, in stead of Passenger.

Menno van Slooten (eBuddy)

I didn't see this one, but I heard it was pretty good ;) In all seriousness, I was really bloody nervous but luckily it was a very friendly crowd with lots of my old friends and colleagues. The presentation itself went pretty smooth in my experience with only a few hickups. If there's a next time I'll cover a more technical subject since I feel more at ease with that than with yesterday's subject matter: a look into the future of front-end developers. Here's a picture of me during the presentation.

John Resig (jQuery)

John absolutely blazed through a presentation that was obviously normally delivered in a much bigger timeslot. He took the big 4 in the world of Open Source JavaScript frameworks: jQuery, YUI, Dojo and Prototype and compared them on various levels, from unit test coverage to CSS selector speed. It was very, very interesting, but I think the crowd would have appreciated a more spicy presentation (for instance about processing.js) a bit more. At the end of his presentation he mentioned he was working on a new DOM CSS selector module (I believe he called it Sizzle) and showed a table with some query benchmarks that looked very impressive. I hope to see more of that soon.

Drinks at 11

Luckily my bosses were willing to be the main sponsor for the drinks afterwards in the excellent Club 11. The atmosphere was good, with the DJ playing some nice Motown soul & R&B tracks. People were stopping me to tell me what they thought of my presentation and the worst criticism I received was "I liked your presentation but I don't agree with what you said." I can certainly live with that.

Overall

I have nothing but good words for the organisation and the visiting crowd. The whole event was flawlessly orchestrated and the atmosphere was extremely enjoyable. I heard the coffee wasn't that good, but that's about it. In the end, I only regret not taking more time to talk JavaScript with Resig, PPK and Koechley. So thanks to Sander and the rest of the crew and I hope I can be a part of future events as well.

What they both do

I can make this a very technical post about the ins and outs of these methods or I can just summarize by writing the following: apply() and call() allow you to specify what this will refer to inside that function, even when that function is a method on another object. An example:

var someObject = {
    myProperty : 'Foo',
    myMethod : function() {
        alert(this.myProperty);
    }
};
someObject.myMethod(); // alerts 'Foo'

var someOtherObject  = {
    myProperty : 'Bar'
};
someObject.myMethod.call(someOtherObject); // alerts 'Bar'
someObject.myMethod.apply(someOtherObject); // alerts 'Bar'

As you can see, even thought it is someObject's method that is executed, call() and apply() allows me to specify that the keyword this refers to someOtherObject.

The difference

The difference between these methods is in the way you can pass arguments to the original function. Let's extend the example to include arguments:

var someObject = {
    myProperty : 'Foo',
    myMethod : function(prefix, postfix) {
        alert(prefix + this.myProperty + postfix);
    }
};
someObject.myMethod('<', '>'); // alerts '<Foo>'

var someOtherObject  = {
    myProperty : 'Bar'
};
someObject.myMethod.call(someOtherObject, '<', '>'); // alerts '<Bar>'
someObject.myMethod.apply(someOtherObject, ['<', '>']); // alerts '<Bar>'

Obviously, the difference is this: If you want to pass arguments to the function apply() needs an array and call() needs a list of arguments. That's it! Ridiculously hard to remember, I know.

New design

First of all, I'm really happy with the new looks. For me, one of the most important attributes of the design is that I tried to combine vertical baseline rhythm with horizontal grid design. Like Khoi Vinh, I used a background image on the body to guide me with the grid. Unlike Khoi, I incorporated the vertical rhythm in the image as well. You can view the grid I used on any page of this site by holding SHIFT+ALT and clicking anywhere in the body.

Baseline rhythm & horizontal grid

In short, a baseline rhythm should make reading easier on the eyes by making sure all lines of text fall on a series of (invisible) evenly spaced horizontal lines. The baseline rhythm I decided on using is 18px. This is set on the body like this:

body {
    font-size:12px;
    line-height:1.5em; /* 1.5 * 12 = 18px */
}

Every other dimension (including font sizes) on every other element is from then on defined in em units. Keeping the rhythm in line vertically is just a matter of making sure the line height of every element plus top/bottom borders, margin and padding add up to a whole number of ems. For example, the title of this article is an <h2> element and has the following style:

h2 {
    font-size:3em; /* 3 * 12 = 36px */
    line-height:1em; /* = 36px */
    padding:.5em 0 .5em 0; /* vertical padding: 36px */
}

Obviously, no matter how many lines of text this element will have, the total height will always be a multiple of 18 thus preserving the vertical rhythm. This technique also ensures that the site layout has the same proportions for visitors with different font sizes. You can verify this yourself by pressing CTRL+PLUS or CTRL+MINUS.

Don't feed the animals

My Atom feeds were broken and they must've been for quite a while I think. My apologies for that. They should work fine now.

No comment

This is something I had some second thoughts about but I removed all commenting possibilities from this weblog. I just didn't feel it added much to the content of the site and it sure added a whole lot of overhead to the code. Not to mention the amount of work needed to keep the site comment-spam free. Akismet stopped most of it but I still had to spend too much time on removing links to porn, casino's and drugs.

Drop me a line

On the upside there is now a new contact page where you can reach me. You can use the contact link in the main menu or, if you want to respond to a specific blog posting, there's a link at the bottom of every post like this one right here:.

The original trick was this:

var args = [].splice.call(arguments,0);

But unfortunately this doesn't work in Safari, the variable args just becomes an empty array. At first I thought the principle of calling an array method on arguments just didn't work but when a co-worker suggested trying the join() method that turned out to actually work. After a bit of experimenting I finally settled on the following snippet:

var args = [].slice.call(arguments,0);

Looks remarkably similar, doesn't it? The difference is just one letter: I call the slice method, in stead of the splice method. The slice method is very similar to splice in it's core functionality with one major difference: splice modifies the original array where slice doesn't. This, I believe is the problem for Safari when calling splice on arguments: this object is not modifiable. None of the other browsers seem to mind, though.