This is nothing to do with javascript but I am on a holiday, after all…

Bit gutted to find that my otherwise excellent Newport Sandals by Keen have started to pack it in after 2 seasons of tear and wear – it seems they were not as water resistant as I was initially led to believe. Nasty side effect – the leather now stinks so bad (due to getting wet a few times) I cannot wear them inside my car. Such a shame, I really really really liked them…

What to buy now or do I just order another pair? Hrm…

I never like having iframes in production sites source codes so when management decided to add the ‘facebook like’ widget thing, I decided to move it outside of the source and into a javascript abstraction. Easiest and most convenient way to do so is via extending the Element prototype in mootools (via Element.implement()):

Element.implement({
    facebookLike: function(url, options) {
        var options = $merge({
            show_faces: "false",
            layout: "standard",
            width: 450,
            action: "like",
            font: "lucida grande",
            colorscheme: "light",
            height: 30,
            href: url
        }, options);

        var src= "http://www.facebook.com/plugins/like.php?href={href}&layout={layout}&show_faces={show_faces}&width={width}&action={action}&font={font}&colorscheme={colorscheme}&height={height}".substitute(options);
        return this.adopt(new Element("iframe", {
            styles: {
                border: "none",
                overflow: "hidden",
                width: options.width,
                height: options.height
            },
            id: "FBFrame",
            frameborder: 0,
            allowTransparency: "true",
            scrolling: "no",
            src: src
        }));
    }
});

// exmaple use:
document.id("like").facebookLike("http://fragged.org/", {
    width: 400,
    height: 30
});

Why would you want to do that instead of the default interface? Because it will speed up page load and abstract this into domready / onload events. It also allows you to produce multiples very easily via a a selector, eg,

// if in your markup you have a number of
anchor text

// then target them, get the link's href and apply the like button instead
document.getElements("div.like").each(function(el) {
    var urlToLike = el.getFirst().get("href");
    el.empty().faceboookLike(urlToLike);
});

All of the facebook options like button plugin are “supported” – you can find the list here

Finally, here’s what it looks like:

Play with it some more on the jsfiddle: click here

In what promises to be the most significant update thus far (well, perhaps the mootools 1.11 to 1.2 is still worth mentioning as a milestone), the mootools team have finally released a public beta.

Why is it significant? You can read the blog post but here is the short summary: in addition to being set as the groundwork for the transition to mootools 2.0, here are the most significant changes I have found out about (list will expand as I find out more):

• The introduction of slick (new css pseudo selector engine) – awesome news for DOM manipulation speeds
• Move away from `Native` to `Type` (semantics) – internal change mostly, unless you hack into Natives
• Move away from $names – all things like $chk, $type, $A and so forth are now being renamed to plain function names that make more sense and look more javascript-y.
• Move away from feature detection where possible and a larger reliance on UA parsing instead – not sure I appreciate this as I do not trust UA strings at all, not least of all due to the fact that I often browse with the googlebot UA string when chasing SEO issues around our competitors. There was a nasty post by slicknet a while back in which he ripped into mootools for still using feature detection but I fail to see his point (just as many others do). Both are somewhat unreliable but one does not allow for the user to directly interfere with the framework behaviour.

Additionally, it seems as if the framework has been largely rewritten – most of the source code is totally new to me and it will take me some time to get a better understanding on how it works. Thus far, there’s been no mootools-more 1.3 so I suppose Aaron Newton will be working hard on releasing it soon.

The new documentation is live (courtesy of fakedarren) here: http://mootools.fakedarren.com/docs/core

P.S. Oskar reported earlier via twitter that JS Fiddle has updated and included the beta as framework option so you can play with it.

The

This time I found a fun javascript test on StackOverflow on the PerfectionKills blog: Javascript Quiz, once again it has been suggested to use through the interview process for a javascript / front-end engineer role.

Good luck and have fun (as they say…)

A great new test through javascript.ru (an incredible resource, even if in Russian). Dmitry Soshnikov has created a new fun javascript quiz you can test your knowledge against. The difference is that he’s tried to abstract real world problems, collected from various mailing lists or problems of his own doing. Worth 10 mins for sure.

Around Christmas we tend to get a LOT of web traffic at work, so much so that we exceed our agreed bandwith a allocation with RackSpace and end up having to pay huge excess fees. Not wanting to be caught out for a second year in a row, I had a look at various ways of conserving bandwith and alleviating from the CPU load on the webserver. This is when I noticed something odd–there was a lot of traffic we were being charged for that was not showing up through the Apache logs. After a lot of head scratching and many coffees later, it hit me: cookies. Consider this: an average user on our site has something between 300bytes and 1k in cookie data (a lot, I know). The cookies are being sent alongside with every resource that the client browser requests, be it a HTML file, an image, a CSS stylesheet or a .js file. I did some rough maths and it transpired we waste between 10 and 20GB of traffic each month in cookies alone!

Additionally, the CPU usage was abnormally high and no amount of MySQL tweaking was cutting the load times enough to make a sizeable difference. The sheer amount of files accessed and served was taking its toll and limited CSS spriting was just not going to fix that. The clincher came from Google who announced that site speed is to be playing a role in the search engine results pages from 2010–it was time to introduce a content delivery network (CDN) and fix things.

I had a look around at what CDN providers were around but since we are a relatively small and lean startup, we could not justify the expense of signing up for a enterprise scale solution just yet and yet we needed real-time updates. We elected to just get a cheap collocation server instead with no bandwith quota and setup a sub-domain cdn.ourdomain.com which was to remain cookieless. I then reconfigured the site templates to always reference images, css and js through the CDN URL instead and setup an rsync partnership with the new box. And boy, did that make a difference!

First thing you notice now is how much more responsive the site is, how quick it loads and how much faster the browser renders the content due to the increased threading capability. The CPU load times dropped from an average of 1.40 to 0.30. Out bandwith use subsided from well in excess of 200GB a month to a little over 100GB, well within our quota. And that’s through a ‘pseudo’ CDN, or should I call it a CDB (content delivery box). I imagine the user experience will improve even further when we can roll out a proper solution in the near future, one that will use CDN zoning to provide the fastest download speed to clients through geolocation.

In the meanwhile, I was approached by the folks at MaxCDN who kindly offered to sponsor my blog and provide it with a CDN. I thought, what better chance to test the experience and find out about what’s on offer than to try it for free…

I was uncertain as to how easy it would be to implement within WordPress but it turned out to be a walk in the park through the plug-in W3 Total Cache that they provide and support. The whole setup involved all of 5 minutes of work and no changes to my template files (so long as they all reference the native WP functions for URLs). The plugin takes care of sync and you really have nothing to do than to worry about caching. I am still getting to grips with the options here and weighing in what further bits can be exported to maxcdn in addition to my static content. Other than that, it’s been a breeze and has probably sped up my blog a fair bit too. It’s also surprisingly affordable, especially when you consider what Akamai, EdgeCast or Limelight tend to charge. Even cheaper than CacheFly for the basic package without rsync functionality. MaxCDN’s site, control panel and support are also nothing but excellent.

All-in-all, I am a happy chappy and would recommend CDN use as it’s become a lot more accessible (to my surprise).

A nice blog post that samples 35 great fonts free to download, some are actually rather good. Head to Instant Shift to check them out.

There are probably as many ways of looping an array in javascript as there are phrases that are synonymous for masturbation. So, what are they and how fast do they perform? Head over to this test @ a blog on Sun which sports no less than 17 different loops to get a fair indication of how fast things work in today’s browsers.

Disappointingly, the native array.forEach in my firefox 2.5 seems to be one of the worst results. while(length–) { … } ftw!

Only 2 weeks late, which by software development standards is ‘dead on’, mootools 1.2.4 and 1.1.2 are officially released.

Amongst the more-exciting changes for me (aside from the the many fixes and additions to -more), JSON.stringify and JSON.parse native methods and DomReady always firing before load event (this had been plaguing me for a while on IE).

And, last but not least, a Depender class for lazy-loading of required components that can get your class working. Brilliant – on-demand javascript. All-in-all, a very nice and worthwhile drop-in replacement and enhancement over the old 1.2s.

Just a word of mention, 1.1.2 is a fix in the mootools 1.11 branch that will enable IE8 and gecko (firefox) detection. Not bad…

This is not a tool you can rely on for customer-facing development, but I found it invaluable nevertheless. jsPrintSetup is a small fireFox add-on that hands you a controlling object in javascript. You get FULL access to any print-related function you could think of: list printers, select default printers, print silently, control spool, headers… There’s just too much to mention. Very useful when coding a CMS that needs to print specific things to specific printers (for example, invoices on printer #1 and labels on printer #2).

Here is an example that fetches a list of printers and remembers the user’s preference for future use:

// only do something if the plugin is live
if ($type(jsPrintSetup)) {
    var printers = jsPrintSetup.getPrintersList().split(","); // get a list of installed printers

    // no print dialogue boxes needed
    jsPrintSetup.setSilentPrint(true);

    // create a dropdown
    var printList = new Element("select", {
        id: "printerList",
        events: {
            change: function() {
                Cookie.write("defaultPrinter", this.get("value"), {
                    path: "/admin/",
                    duration: 365
                });

                // save the new printer selection
                jsPrintSetup.setPrinter(this.get("value"));
            }
        }
    }).injectTop($("printSetup"));

    // get default by preference if any
    var defaultPrinter = Cookie.read("defaultPrinter");

    printers.each(function(el) {
        new Element("option", {
            value: el,
            text: el,
            selected: (defaultPrinter == el) ? "selected" : false
        }).inject(printList);

    });

    // attach an event that prints from an element called goPrint
    $("goPrint").addEvents({
        click: function() {
            jsPrintSetup.print();
        }
    });
}