blogZero

For someone with many moons of writing code in C and C-like languages, making the transition to Python was indeed a paradigm shift. But we're only human and as humans it's natural to be resistant to change. For instance, when I first started to study Python in earnest I found the notion of indentation as syntax rather odd. And where oh where are my parenthesis? What's this, no line termination semicolons? No curly braces around blocks of code? This is insanity!

A Bit of History

Of the five programming languages I refer to most often, Python stands out as being unique in many regards. It's interesting to compare and contrast the why and the how they were developed—and by whom.

• C (and its descendants) ca. 1970 — the oldest of the four, developed by computer scientists at Bell Labs during the early stages of the evolution of Unix
• Perl ca. 1986 — developed by a lingust turned system administrator (now a researcher and developer at O'Reilly).
• Python ca. 1990 — developed by a mathematician turned programmer (now working at Google).
• PHP ca. 1995 — developed by a systems design engineer turned programmer (now an infrastructure architecture engineer at Yahoo!).
• JavaScript ca. 1995 — developed by a programmer turned CTO at Mozilla.

Sitting on the Fence

Last month brought Python developers a step closer to the up-and-coming version 3.0, with the final production-ready release of Python 2.6. It adds plenty of new features, modules, improvements and bug fixes. For the Python 2.6 and 3.0 release schedule, visit PEP 361.

So what's the big deal? Developers are both excited and concerned—3.0 promises to bring great things—but Guido has made it clear that the new version will likely break some older scripts. It reminds me of PHP 4.x to 5, although, at least for me, the impact was minimal. And version 5, once it stabilized, was a big improvement in terms of OOP.

By adding compatibility functions in the future_builtins module, and a -3 switch which warns about usages that will become obsolete, Python 2.6 should mitigate the migration to version 3.0.

Related Reading

• Why Python 2.6 and 3.0 compatibility would be a Very Good Thing (Lennart Regebro)
• Python 2.6 to Smooth the Way for 3.0, Coming Next Month (Slashdot)
• Python language slithers into the future with 2.6 release (Ars Technica)
• Python 3.0 makes a big break (Linux.com)

No sooner had I added Dave Shea's (of CSS Zen Garden and mezzoblue fame) excellent (if somewhat dated) CSS Sprites ALA article to my CSS resources category, then what does he go and do?

Too Late Again

You guessed it, he publishes a follow-up article. The reason I went looking for it in the first place, or rather found it to be the best write-up on the topic, was not so much the how, but the why of using this technique. But he kind of missed the point. Sure, he explains the ins and outs and a bit of the history of sprites, but for my money the single best reason to consider using the technique is a huge reduction in the number of HTTP requests you serve up when storing a bunch of similar iconic images from one master file. Better still, once the browser downloads the aggregate file and caches it, it's a simple matter of some integer offset math to display only that portion you need as a background image in your documents.

Sprites in a Nutshell

Basically, the technique involves creating one or more fixed-sized, block-level elements with ids or classes to be used as selectors in your stylesheet, set the display property to absolute, but relative to some other containing element, say a <ul> with <li> descendants, and then use the top, right, bottom and left values of the background-position property as needed to offset that portion of the image you want revealed. Kind of like a peephole onto a larger canvas. The nice thing is you can move the canvas (the parent element) around with margins or other positioning methods, and the child elements follow right along like a duck and her little ducklings.

CSS Sprites Redux

The latest version of the article takes the technique a step further by introducing some animation effects via John Resig's outstanding jQuery JavaScript library. But Dave misses the original point again, which I found ironic after he warns his audience that using jQuery imparts a certain overhead when downloading the library for the first time.

Ajax Libraries API

However, I did learn something very interesting—Google Code is now hosting jQuery as part of their Ajax Libraries API project—allowing you to link to the library without having to host it yourself. This has two benefits: it saves you a little bandwidth, but more importantly, if enough developers are doing this then chances are your visitors already have a copy of jQuery cached locally. You can also take advantage of the Google CDN if you're using Prototype, script.aculo.us, MooTools/moo.fx, or Dojo. It would be really sweet if Google started hosting some of the more popular jQuery plugins.

google.load()

Personally, I don't understand the advantage of using the google.load() method unless your project involves using their Maps, Search, or Ajax Feed APIs. Why not just load the library and start using jQuery (or whatever) like you normally would?

<script type="text/javascript"
         src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
// when the DOM is ready
$(function() {
 // fire away
 $('#selector').method({
  // ...
 });
 // ...
});
</script>

Related Reading

• High Performance Web Sites
• Announcing Ajax Libraries API: Speed up your Ajax apps with Google’s infrastructure
• Speed up access to your favorite frameworks via the Ajax Libraries API
• jQuery Hosting With Google Ajax Libraries API

There used to be a lot of talk about browser wars (both old ones and new), but now days it seems the race is on to see who can develop the fastest JavaScript engine. Not surprising given the explosive growth in front-end development, and JavaScript frameworks and effects libraries. Oh, and a little thing called Ajax. So I spent some time researching and evaluating the current, and future, state of JavaScript implementations and these are my findings.

Evaluation Parameters

Before I get into what's on the horizon, I took the time to evaluate the relative performance of JavaScript in four current browsers. I'll be using the WebKit SunSpider JavaScript benchmarking tool on my Dell XP Pro laptop with the latest Service Packs installed. Internet Explorer is not in the mix because, first of all I can't stand the browser, but mostly because it would likely be crushed by the other competitors—listed below by product, version, vendor, and JavaScript engine:

• Firefox v3.0.3 (Mozilla) (SpiderMonkey)
• Safari v3.1.2 (Apple) (SquirrelFish)
• Chrome v0.3.154.9 (beta) (Google) (V8)
• Opera v9.62 (Opera) (Presto)

To level the playing field, each test was performed after a fresh restart with no other foreground applications running. Of the four, Firefox was the most heavily loaded, at least in terms of the number of extensions/plugins installed. I'm not sure if that would have an impact on the results or not. In all cases there were no other tabs open to skew the results (Google mail leaps to mind).

Firefox

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 6506.0ms +/- 1.1%
-------------------------------------------------

 3d:                    693.6ms +/- 2.0%
   cube:                264.2ms +/- 3.6%
   morph:               200.0ms +/- 2.6%
   raytrace:            229.4ms +/- 1.6%

 access:                997.4ms +/- 1.2%
   binary-trees:        152.2ms +/- 3.0%
   fannkuch:            473.4ms +/- 0.6%
   nbody:               236.8ms +/- 3.3%
   nsieve:              135.0ms +/- 4.5%

 bitops:                789.8ms +/- 3.2%
   3bit-bits-in-byte:   186.4ms +/- 4.5%
   bits-in-byte:        212.0ms +/- 0.6%
   bitwise-and:         151.0ms +/- 0.8%
   nsieve-bits:         240.4ms +/- 7.6%

 controlflow:           166.6ms +/- 6.5%
   recursive:           166.6ms +/- 6.5%

 crypto:                494.8ms +/- 1.7%
   aes:                 174.2ms +/- 1.3%
   md5:                 160.2ms +/- 2.1%
   sha1:                160.4ms +/- 3.1%

 date:                  571.4ms +/- 4.5%
   format-tofte:        357.4ms +/- 6.6%
   format-xparb:        214.0ms +/- 7.8%

 math:                  742.0ms +/- 1.9%
   cordic:              351.2ms +/- 1.8%
   partial-sums:        218.4ms +/- 5.5%
   spectral-norm:       172.4ms +/- 1.1%

 regexp:                508.6ms +/- 7.1%
   dna:                 508.6ms +/- 7.1%

 string:               1541.8ms +/- 0.4%
   base64:              176.4ms +/- 3.5%
   fasta:               381.6ms +/- 1.6%
   tagcloud:            296.0ms +/- 3.4%
   unpack-code:         476.0ms +/- 1.3%
   validate-input:      211.8ms +/- 4.8%

Safari

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 6428.2ms +/- 1.1%
-------------------------------------------------

 3d:                    745.0ms +/- 1.9%
   cube:                240.2ms +/- 3.7%
   morph:               258.4ms +/- 3.9%
   raytrace:            246.4ms +/- 2.7%

 access:                977.0ms +/- 2.1%
   binary-trees:        132.0ms +/- 4.2%
   fannkuch:            474.8ms +/- 2.4%
   nbody:               242.2ms +/- 5.6%
   nsieve:              128.0ms +/- 8.1%

 bitops:                782.8ms +/- 2.1%
   3bit-bits-in-byte:   120.0ms +/- 0.0%
   bits-in-byte:        176.0ms +/- 3.9%
   bitwise-and:         292.4ms +/- 3.6%
   nsieve-bits:         194.4ms +/- 3.6%

 controlflow:           154.2ms +/- 4.3%
   recursive:           154.2ms +/- 4.3%

 crypto:                442.8ms +/- 3.0%
   aes:                 164.2ms +/- 6.7%
   md5:                 136.2ms +/- 5.2%
   sha1:                142.4ms +/- 4.2%

 date:                  624.8ms +/- 1.1%
   format-tofte:        262.0ms +/- 2.1%
   format-xparb:        362.8ms +/- 1.6%

 math:                  811.4ms +/- 2.9%
   cordic:              322.6ms +/- 3.3%
   partial-sums:        330.2ms +/- 4.5%
   spectral-norm:       158.6ms +/- 3.8%

 regexp:                520.8ms +/- 0.1%
   dna:                 520.8ms +/- 0.1%

 string:               1369.4ms +/- 6.9%
   base64:              184.0ms +/- 3.7%
   fasta:               328.2ms +/- 3.1%
   tagcloud:            314.4ms +/- 30.2%
   unpack-code:         268.6ms +/- 4.0%
   validate-input:      274.2ms +/- 2.4%

Chrome

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                2697.4ms +/- 2.6%
-------------------------------------------------
 3d:                   237.8ms +/- 12.9%
   cube:                53.8ms +/- 9.3%
   morph:              120.6ms +/- 24.5%
   raytrace:            63.4ms +/- 3.0%

 access:               154.6ms +/- 6.0%
   binary-trees:        10.8ms +/- 18.9%
   fannkuch:            54.4ms +/- 3.5%
   nbody:               54.0ms +/- 9.4%
   nsieve:              35.4ms +/- 7.7%

 bitops:               119.8ms +/- 5.6%
   3bit-bits-in-byte:    9.8ms +/- 5.7%
   bits-in-byte:        18.8ms +/- 7.2%
   bitwise-and:         37.4ms +/- 3.8%
   nsieve-bits:         53.8ms +/- 11.1%

 controlflow:            6.8ms +/- 8.2%
   recursive:            6.8ms +/- 8.2%

 crypto:                96.8ms +/- 4.4%
   aes:                 33.8ms +/- 9.9%
   md5:                 32.4ms +/- 3.4%
   sha1:                30.6ms +/- 2.2%

 date:                 621.6ms +/- 2.7%
   format-tofte:       264.8ms +/- 6.5%
   format-xparb:       356.8ms +/- 1.8%

 math:                 198.4ms +/- 5.3%
   cordic:             105.2ms +/- 10.6%
   partial-sums:        67.2ms +/- 5.1%
   spectral-norm:       26.0ms +/- 3.4%

 regexp:               547.4ms +/- 1.7%
   dna:                547.4ms +/- 1.7%

 string:               714.2ms +/- 2.2%
   base64:              73.0ms +/- 13.6%
   fasta:               99.8ms +/- 2.8%
   tagcloud:           188.0ms +/- 3.7%
   unpack-code:        246.0ms +/- 1.2%
   validate-input:     107.4ms +/- 3.0%

Opera

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 7536.2ms +/- 1.2%
-------------------------------------------------
 3d:                    815.6ms +/- 2.7%
   cube:                254.4ms +/- 2.5%
   morph:               302.6ms +/- 5.5%
   raytrace:            258.6ms +/- 2.3%

 access:               1160.4ms +/- 0.8%
   binary-trees:         82.4ms +/- 7.3%
   fannkuch:            568.8ms +/- 1.0%
   nbody:               314.6ms +/- 1.9%
   nsieve:              194.6ms +/- 3.5%

 bitops:                987.2ms +/- 10.8%
   3bit-bits-in-byte:   116.2ms +/- 5.6%
   bits-in-byte:        238.2ms +/- 44.3%
   bitwise-and:         378.6ms +/- 1.4%
   nsieve-bits:         254.2ms +/- 2.6%

 controlflow:            98.2ms +/- 10.3%
   recursive:            98.2ms +/- 10.3%

 crypto:                454.6ms +/- 2.8%
   aes:                 214.2ms +/- 5.5%
   md5:                 120.2ms +/- 0.5%
   sha1:                120.2ms +/- 0.5%

 date:                  551.0ms +/- 2.9%
   format-tofte:        290.6ms +/- 5.3%
   format-xparb:        260.4ms +/- 0.3%

 math:                  638.6ms +/- 3.1%
   cordic:              278.2ms +/- 5.8%
   partial-sums:        206.2ms +/- 3.4%
   spectral-norm:       154.2ms +/- 4.3%

 regexp:                871.6ms +/- 2.5%
   dna:                 871.6ms +/- 2.5%

 string:               1959.0ms +/- 1.0%
   base64:              200.4ms +/- 0.3%
   fasta:               392.6ms +/- 1.3%
   tagcloud:            390.6ms +/- 2.4%
   unpack-code:         765.0ms +/- 0.9%
   validate-input:      210.4ms +/- 4.2%

Findings

Ranked from fastest to slowest overall:

1. Chrome — 2697.4ms
2. Safari — 6428.2ms
3. Firefox — 6506.0ms
4. Opera — 7536.2ms

Now I'm not a statistician, but Safari and Firefox yielded very similar results in the middle ground, while Chrome was the clear winner with Opera at the bottom (surprising, given the browser's reputation for performance). SunSpider has a nice feature that allows you to compare two result sets. The difference from fastest to slowest was a staggering 279% speed increase in Chrome over Opera. Of course a lot depends on what you're using JavaScript for, hence the breakdown into categories and different operations within those categories. If you enjoy pouring over raw data, by all means have at it.

On the Horizon

Over the past several months we've seen all manner of announcements and articles about JavaScript performance improvements and what to expect when this research and development makes its way into the mainstream. We've learned about trace trees, JIT compilers, direct-threaded, bytecode optimizers, and so on. Mozilla, for example, plans to roll out it's TraceMonkey engine with the release of Firefox 3.1. For the impatient, you can grab a copy of the 3.1 nightly builds and enable TraceMonkey now if you want to play with it or do your own testing. One can only speculate on how Google and Opera will respond to these latest developments.

Related Reading

• TraceMonkey Update (Brendan Eich)
• The Birth of a Faster Monkey (Mike Shaver)
• TraceMonkey (John Resig)
• Extreme JavaScript Performance (Ars Technica)
• SquirrelFish has Landed (Cameron Zwarich)

Joe Hewitt may be a lesser known member of the original three Firefox cast, but among DOM and JavaScript developers, his work is legendary. In a later Power Tools installment, I will cover in more detail the DOM Inspector, for which he is perhaps better known. At least until recently. This article focuses on FireBug, which Joe has been working on continuously of late (among other endeavors) and what he ultimately considers to be a DOM Inspector replacement.

The latest version of FireBug was released September 12th, 2008.

What in the hell is a FireBug?

I won't get into entomology—which ironically in Greek means "that which is cut in pieces"—although there really is such a thing as a firebug. The extension, on the other hand, is designed to make the Web developer's job a whole lot more productive. With it you can inspect and debug your markup, stylesheets, JavaScript, and even keep an eye on asynchronous XHR object calls back to your server.

Unlike the DOM Inspector, FireBug normally runs in a horizontal console (although you can open it in a separate browser window) underneath the document's rendered view. A statusbar icon indicates if there are any problems with the current page, which can indicate any number of conditions including errors, warnings and results from:

• JavaScript
• CSS
• XML
• XMLHttpRequest (aka XHR or Ajax)
• Chrome

and even problems encountered from remote domains—which can be the source of massive numbers of errors (I'll leave it to Joe to name names). Thankfully you can suppress these messages, or disable FireBug entirely for certain domains, through the options menu.

Almost every object in the FireBug interface is actually a hyperlink. Elements in the source view can be expanded or collapsed and your current XPath is displayed as you explore the document structure. Like the browser itself, views are toggled through a tabbed interface, which include Console, HTML, CSS, Script, DOM, and Net. Each tab has one or more sub-functions associated with that feature.

By using FireBug, you will quickly learn just how much is going on behind the scenes of even the simplest Web page.

Power Tools

• console.log()

Forget about using alert() to test or debug your scripts. By adding console object logging to your code you can pinpoint exactly what is going on, and even restrict messages according to different levels of severity including: informative, debug, warnings, or errors.

The console object also allows you to make assertions to more deeply test your code as well as performing stack traces, time sections of code, and log the number of times a function is called and has been executed.

All of the console logging methods can format strings using patterns similar to the C stdio printf() family of functions.

Command Line Functions

For command line junkies like me, console mode gives you access to a wealth of query and history/editing features you're probably already familiar with. Even more powerful are the following predefined shorthand functions:

• $("id") - A shortcut for document.getElementById().
• $$("css") - Returns an array of elements that match a CSS selector.
• $x("xpath") - Returns an array of elements that match an XPath selector.
• $0 - Variable containing the most recently inspected object.
• $1 - Variable containing the next most recently inspected object.
• $n(N) - Returns the Nth most recently inspected object.
• inspect(object) - Displays an object in the DOM Inspector.
• dir(object) - Returns an array of property/method names on an object (Python anyone?)
• clear() - Clears the console.

>>> inspect(document)

is a good place to get started.

CSS Quick Search

While in Inspect mode, you can use the quick search box to locate any element by entering a CSS selector. FireBug will display all matching elements in the console view, which you can then expand to view more details or switch tabs to explore the stylesheet that defines the rules for each element, the computed propeties and layout/display attributes, JavaScript events that are attached to the element, and even the gory details of DOM for the selected item.

You can also use quick search to match JavaScript events.

In the future, Joe plans on adding XPath search as well as plain text. For those in a hurry, you can try the getElementsBySelector() JavaScript function, which uses the Firefox XPath API to translate CSS selectors to XPath making them a lot faster than searching the DOM directly.

FireBug 1.2

Some of this material is a bit dated. For the latest on FireBug, visit the new Get FireBug Web site and in particular the "Learn more" feature links on the home page and the documentation section.

Wow, talk about a hiatus. Looking down at the previous post it's been over a year since the last time my shadow has darkened this doorway. Below are a few recent items of interest regarding development and the Web in general. To me at least. But who am I kidding? I must be the only person left who actually still reads this blog.

jQuery I spent a lot of time evaluating the myriad of JavaScript libraries out there and I've settled on a favorite. jQuery is compact, fast, powerful, easy to use, and extensible. If you haven't tried it, do yourself a favor and do so.

Chrome The long-awaited browser from Google, in beta naturally, has arrived for Windows XP and Vista. Versions for Linux and Mac are on the way. Built from WebCore (the rendering engine that forms half of Apple's open-source WebKit project), Mozilla's Firefox and V8, the open-source JavaScript engine from Google. Although you'd think they would come up with a more original name, one intriguing feature are tabs that sit externally at the top of the browser window and each one runs in its own virtual space, so one misbehaved Web application won't crash the entire browser. You can also monitor the amount of memory taken up, the amount of CPU used, and the network activity for each tab via the Task Manager.

Google Turns 10 Has it really been that long? Actually, Larry and Sergey first met in 1995 at Stanford where Larry was considering going to grad school and Sergey was assigned to show him around. The rest, as they say, is history. To the best of my knowledge, the magic 9-27-1998 date is when Google was officially incorporated.

Also long overdue, last month's DC PHP Developers Group (now located at the DC Greenpeace office) featured a presentation on the CodeIgniter open-source PHP Web application framework, by Oscar Merida and Matt Gibbs of Forum One. Next month will feature Barry Austin on MySQL Optimization for Developers.

Stay tuned, I may just be back sooner than 12 months. In fact, you can count on it.

Prototype version 1.5 has just been released and includes many enhancements and bug fixes. Best of all, excellent online API documentation. For more information on the latest version, visit the Prototype blog.

Joe Hewitt has announced the final release of FireBug 1.0. Rather than go into all the details about new features and enhancements here, I'm going to refer you to the Yahoo! User Interface Blog where you can view a lengthy video featuring Joe as he demos the new version. Joe has put an enormous amount of work into this extension, if you use it regularly and it saves you time and frustration, then consider helping out with a donation.

JavaScript development just keeps getting more efficient and powerful!

In my second visit to the DC PHP Developers group meeting I joined yet another over-crowded room of local programmers for this month's presentation. I really appreciate Robyn Wyrick's efforts to put these meetings together, but it's becoming clear that the venues provided by the National Press Building are faltering—a testament to the growing popularity of the group.

Jonathan Modell was tonight's presenter. A DC local, recently returning from a 10 year stint in Colorado (my home state, or more accurately I was born in Durango and then lived in Boulder for a year), Jon has extensive experience in many aspects of Web development.

His presentation focused on how he learned to integrate Ajax technology within a core PHP system. Obviously this is a hot topic, if somewhat too hot in my opinion. In a nutshell, Ajax allows you to create an HTTP request back to a server-side script, and then dynamically insert the results into your page via the DOM—all without having to POST or GET a new page (something most PHP programmers are well versed in).

Web-based applications that quietly introduced this technique are most famously associated with Google. First was "suggest" a sort of search as you type, and then Gmail and many others that began to reinvent how Web pages could improve interactivity. In truth, it was Microsoft (circa 2000) who first implemented the XMLHttpRequest (XHR) object in their version of JavaScript (jscript). Later browsers (Firefox, Safari, et al.) followed suit.

As the function implies, the traditional payload of a server-side script called by an XHR request is XML. I know of very few people that continue to do this. By far the simplest method of dynamically insterting results into your page is to use a element with a unique id, initially hidden via CSS, then grab the data returned as normal markup (for instance a set of unordered list elements), then use innerHTML to update the DOM, and finally "unhide" the element (typically a <div>). This technique is sometimes referred to as AHAH.

JSON is another lightweight technique for returning data to the requestor. It's basically serialized JavaScript in the form of name/value pairs that you eval() on the client-side for parsing and insertion into your page. In addition to JSON, the Yahoo! Developer Network set of Web services are able to return serialized PHP. Although not as applicable to an Ajax implementation, it is none-the-less an interesting method worth investigating. If there is such a beast as a JavaScript unserialize PHP function or class out there, by all means drop me a comment. For PHP developers interested in available packages for encoding and decoding JSON data, visit this comparison of PHP libraries. As of PHP version 5.2.0, JSON support is native.

In the early stages of his presentation, Jon confessed to having tested many of the Ajax JavaScript libraries that are floating around out there, and then spoke highly of his choice to use Sam Stephenson's Prototype. He is not alone, not by a long shot. There are a number of frameworks that are built on top of Prototype: RoR, Rico, and "effects" libraries that include script.aculo.us and moo.fx. PHP frameworks with built-in Ajax support include CakePHP and ModX.

If you are doing this sort of development work, I cannot emphasize enough how much Joe Hewitt's fantastic FireBug Firefox extension will save you hours of headaches.

To conclude his presentation, Jon demoed a social networking application that displays a calendar of events and the members who are attending, locations, dates, and so on. I came away with the feeling that traditionalists in the audience were impressed how the page would update without the need to refresh it. But keep in mind that is the nature of asynchronous requests. There is nothing particularly new going on here, these are normal HTTP requests, they just happen to occur in the background via JavaScript and a little DOM magic to alter the page on the fly.

Yahoo! has just upgraded their Maps Beta product. For end-users, you now have Satellite and Hybrid views. A major complaint from many users to date has been the lack of maps outside the US. They are now rolling out coverage across the globe, although from my tests the results are still pretty limited. For a couple of examples, check out:

• Hong Kong
• Stuttgart

For developers, several of the Map APIs have also been upgraded to Version 3. These include:

• Ajax Getting Started Guide
• ActionScript/Flash API Guide

Why it's taking so long for a killer mashup that integrates geotagged Flickr photos with Yahoo! Maps Beta is a mystery to me, although I can guess who is working on it. To stay up to date on the latest development news, join the Yahoo! Maps Developer Community.

There is never any need to get lost.