The reason for this is that you must use the Alt-key to get a bracket [, and apparently Command-Alt-[ is already taken by toggling zoom on/off.

To make tab-indenting work in Coda, open System Preferences, Keyboard, click Keyboard Shortcuts tab, select Universal Access and finally uncheck the box for Turn zoom on or off.

The presentation is basically a quick high-level overview of some of the main points I’ve encountered after several workshops at different clients wanting to take the step from a legacy server centric web site architecture to a modern rich client side implementation.

Slides are available as PDF here (this is an english version of what was presented).

The demo I did of the Friendly Iframe ad-loading optimization by Tobias Järlund at Aftonbladet is available at the Aftonbladet dev blog (swedish).

One way to describe this book, in a somewhat generalized way, is to say “Old people talking about when they were programmers”. The book is a collection of transcript style interviews with some of the most protruding people in the history of computer programming. 15 interviews in all, from Jamie Zawinski of Netscape fame (the young one of the lot, thereby the “old people” tongue-in-cheek reference) to Donald Knuth.

Each interview is prefaced with a short introduction of the interviewee, followed by a discussion around a number of topics; how did you learn to program, how do you prefer to read code, hardest bug you tracked down, do you think of yourself as a scientist, engineer, artist or craftsman, what do you think of formal proofs, have you used literate programming, how do you interview candidates for employment, and more.

The author, Peter Seibel, is himself an experienced programmer resulting in insightful questions that only someone with great knowledge about programming may ask, making the interviews more free and targeted towards the interest of the particular person. It also makes the discussion feel more genuine and honest, rather than a set of questions and answers following a strict agenda.

The focus of the interviews are not technology, but the person being interviewed and how they look back on their career. The technical discussions typically centers on systems like PDP and programming in LISP. Although most issues are still relevant today in some way or another, the context is usually not on today’s technology (you do not program using punch cards, do you?).

That means that this book is not for someone looking at quick technical tips to apply in their current programming language of choice. But for those genuinely interested in the craft of software development this book is inspiring and gives insight into the people who were significant in some way bringing the industry into what it is today.

The book really does not analyze the answers in the interviews to a greater extent, leaving that to the reader. But to mention a few reoccurring themes there seems to be a consensus that programming is harder today (mostly because of parallelization) and C++ (and especially pointers) is crap.

Notable famous people missing from the list are Linus Torvalds (Linux) and John Carmack (Doom/Quake). Both were contacted by author Peter Seibel but he never got an answer. Additionally, most of the interviewees look back at the time when they were programming as their main profession, this is not a list of the superstar programmers of today (which would make a great follow up book).

All in all, if you are interested in the people, how they are and what their thoughts and experiences are like, then this book is for you – you’ll likely find it both inspiring as well as entertaining as I did. If you want source code listings, look elsewhere.

Here is the HTML:

<input type="radio" name="myoptions" value="one"> First
<input type="radio" name="myoptions" value="two"> Second
<input type="radio" name="myoptions" value="three"> Third

Get the currently selected value using only one line of code:

var value = Y.one('[name=myoptions]:checked').get('value');

Unfortunately, this does not work in Internet Explorer, so another (not as tight) approach is:

function getRadioSelectedValue(selector) {
    var tmpValue= false;
    Y.all(selector).each(function(node) {
        if (node.get('checked') tmpValue = node.get('value');
    });
    return tmpValue;
}
var value = getRadioSelectedValue('.myRadioGroupClass'); // this assumes you've set appropriate class to radio elements

The typical way modules are used is within the use() statement:

YUI().use('node', 'event', function(Y) {
    // your stuff here
});

In the above example the modules node and event are loaded. Let’s see how custom modules may be included in the same way.

To define a new module the add() statement is used (note that it is a class and not instance method of the YUI object):

YUI.add('my_module', function(Y) {
    Y.myFunction = function() {
        var privateFunc = function() {
            // ...
        };

        return {
            publicFunc: function() {
                // ...
            }
        }
    }();
}, '0.0.1', { requires: ['node'] });

A common way to share functionality among different YUI instances is to use the YUI namespace when assigning the function. If you do not recognize the structure of the above function definition you may find out more by reading about the module pattern.

If the file containing the custom module code is loaded, the custom module may be used in any use() statements as normal YUI modules, i.e. use(‘my_module’, …).

To leverage the power of the YUI loader to dynamically load the custom module a configuration object may be created.

YUI({
    modules: {
       'my_module': {
           fullpath: "http://mydomain.com/js/my_module.js",
           requires: ['node']
       }
    }
}).use('node', 'my_module, function(Y) {
    // access functionality of custom module
    Y.myFunction.publicFunc();
});

One thing to note is that YUI currently only makes one request to fetch dependencies. That is why the module’s requires array must be specified in the configuration object as well, in addition to what is in the last parameter of the add() statement.

Note that this post is about YUI 3 and not YUI 2.

However, the current YUI 3 documentation does really only get into how to add a plugin to a current instance. What about adding functionality to the class level so all instances of the same type of objects automatically get it?

First an example of how a simple plugin may look like:

NodePlugin = function(config) {
    this._node = config.host;
}

NodePlugin.NS = 'vis';
NodePlugin.NAME = 'NodeVisibiltyPlugin';

NodePlugin.prototype = {
    show: function() {
        this._node.setStyle('display', 'block');
        return this_node;
    },

    hide: function() {
        this._node.setStyle('display', 'none');
        return this_node;
    }
};

What this plugin does it to add hide() and show() functions to the vis namespace (as specified in the code) of Y.Node.

This plugin would typically be used like this:

var node = Y.one('#myElement');
node.plug(NodePlugin); // add plugin functionality
node.vis.hide();

If you would like to use the plugin functionality for all node objects it would be somewhat tedious to invoke plug() for each and every instance. The way to get around this, which is not really documented except in the API reference, is to use the static method Y.Plugin.Host.plug.

Y.Plugin.Host.plug(Y.Node, NodePlugin); // plug once ...

var node = Y.one('#myElement');
node.vis.hide(); // ... use anywhere

Now any new instances of Y.node have access to the plugin methods through the specified namespace. I also discovered that in order for this to work the static NAME property must be defined in the plugin object.

The fundamental concept of progressive enhancements are that anyone may use the functionality, but a more enhanced version is available for those with more advanced browsers.

Having a complex feature with pixel perfect appearance and functionality in all browsers usually means that you implement it on standard compliant browsers, and then provide workarounds to make it work in Internet Explorer (usually a significant amount of work). The key to reduce this waste of time is not to skip IE6 entirely (which may not be an option), but to let go of having everything exactly the same in all browser. Instead, provide the basic functionality to IE6 but add the shinyness and bling to newer browsers.

The old approach

About a year ago I did a JavaScript map implementation (similar to Google Maps) and it had an info box popup that could contain additional information. The original requirements were that it should have rounded corners and a pointer that depending on position could point in four directions (flipping when the map moved). In addition the dimensions should automatically size to the content unless a fixed width and/or height were set.

Old (complex) InfoBox implementation

And it should look exactly the same in all browsers. This single line of requirement resulted in the implementation becoming one of the largest and most complex modules in the whole mapping application. Using css sprites for the corners, off-screen rendering to estimate size, lots of IE workarounds and so on… probably 60% of the development time were spent on compatibility issues.

The modern way

I recently had the opportunity to rewrite the info box implementation, using a much smarter approach. The key was that the basic functionality should work in IE6, but it shouldn’t necessary look the same.

This resulted in an implementation that was 1/5 of the number of lines of the original, didn’t require additional images for the corners (reducing number of HTTP requests), no IE hacks and was a lot more flexible.

By using border-radius and box-shadow available in CSS3 the implementation was very simple, and we even got a drop shadow for free.

InfoBox in modern browsers

Using an old or non-standard browser like Internet Explorer resulted in the following look.

InfoBox in Internet Explorer

Still functional and useful, but without the extra visual appearance. However, instead the development time was dramatically reduced and the implementation dead easy instead of very complex.

The challenge

This is all pretty straightforward, why do it any other way? Usually the challenge is not technical, but rather to communicate this to the stakeholder. Most organizations simply state “Support IE6+, FF2+, …” implicitly resulting in requirements demanding exactly the same functionality pixel by pixel between the supported browsers.

This is where it gets wrong and the challenge is to change it! It is not about being supported or not supported – it is about to what extent should a browser be supported! IE6 may be supported in a way that the core functionality is useful, but it may look less attractive and some fancy (but non critical) features may be removed.

To what extent each browser should be supported should be a conscious and strategical choice! The benefits are huge with productivity gains, less complex code and faster time-to-market. And it is up to you, as a developer, to communicate this and make it happen!

Presentations available here and a report from the evening at iphone24.se (in Swedish).

To fix this, execute the following (everything in one line) in a terminal to create a softlink for 3.0.1 to 3.0:
ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0\ \(7A341\) /Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1

For more information, see the iPhone OS 3.0.1 Advisory available at the bottom of the iPhone SDK page (in the downloads section).