The interface is fairly intuitive – just three panes for HTML, JavaScript, and CSS, and an output pane that displays your rendered content. It also has support for a number of JavaScript frameworks (jQuery, MooTools, etc), and a number of addons for those frameworks. It’s also setup as a collaborative tool – by default, your ‘Fiddles’ are public and accessible by URL. As a quick test of the tool, I ported the code I wrote for my ‘:between‘ jQuery selector – check out the demo here: http://jsfiddle.net/jneal/WmnNJ/.

You can even embed your Fiddles on other websites. Next time I write a post on a coding technique, I’m planning on setting up some examples through jsFiddle. Hopefully it turns out well!

First, I don’t think infect is a very good strategy in triple MBS. The infect cards are spread out across too many colors, so getting a deck together is tough. Second, the best infect cards are also the best cards against infect. Blight Widow and Priests of Norn will be highly picked by everyone, so you’ll end up with the drecks, like Flensermite. Third, infect is a popular (but bad) strategy, so the cards will be that much harder to come by.

Fangren Marauder is first-pickable. I’ve not had any trouble picking up a full playset of these in most of my drafts, and I’ll always splash green to play them. They are the nuts against non-infect decks, and they are even great against infect. Next, anything that gives a -1/-1 counter or does one damage is playable, and probably will be awesome in your deck. Any guaranteed 2-for-1 is playable (even Myr Sire). Sword of Feast and Famine isn’t nearly as threatening as you think – it’s a mana sink in the early turns, and every deck should have an answer to it (maindecked, none the less). There are far fewer mana fixing cards to make splashing three colors easy in triple MBS than there are in Scars (no mana Myrs), so Sphere of the Suns is a great pickup, as well as Viridian Emissary.

So, what do I think is the most playable strategy in this format? Red-Green artifact sacrifice. The core of this deck is anything that works with artifact sacrfice – Fangren Marauder, Gnathosaur, Ichor Wellspring, Myr Sire, Kutholda Flamefiend, Myr Turbine, Spine of Ish Sah, and such. Red in general has powerful cards all along the curve, and the synergy that can be put together in with this core of cards is amazing. In general, I’m very open to also splashing white in these colors, for things like Master’s Call, Divine Offering, Priests of Norn, and Choking Fumes. If you happen to open a Spine of Ish Sah, try your hardest to get a Treasure Mage, and pick Gnathosaur high.

I highly recommend triple MBS drafting to anyone that has such an inclination. It’s a great format that won’t be around for long, so enjoy it while you can!

The one thing that has been bugging me lately is how to bridge the gap between my friends who know how to play Magic, but aren’t into playing competitively like I am. To some extent, I’m sure I could convince a few friends to get together and draft, but nothing more than that, and even then on rare occasions. As a group, we are far more likely to play a good game of Smallworld, Power Grid, or any other board game than we are to do anything Magic-related. Being the problem-solver I am, I decided fairly recently to create a Cube.

Cube is an informal Magic format that is similar to Draft. Essentially, you create ‘packs’ of fifteen cards out of an available pool of 500 or so cards, and you hold a draft tournament using those cards. I won’t go into the specifics of drafting, but essentially all the cards you need to play are going to be provided to you at the outset, though winning requires a fair amount of skill and familiarity with the rules of Magic.

Creating a cube is a very time consuming effort. I’m currently in the acquisition stage of my cube – I still can’t play with my cube, though it is roughly half-complete. Having a theme for your cube is somewhat essential in creating it – in my case, I’ve decided upon a hybrid of a powerful-game-state cube and a good-limited-cards cube. This means that I want to add to my cube some of the most powerful cards available in Magic, as well as to add cards that are particularly powerful in draft format. I’ve been tracking my progress in a Google Docs spreadsheet. I’ve picked out a good portion of the cards I want in the cube, though I haven’t acquired them all to this point. My one additional caveat to this story is that I want my cube to be primarily foil cards (say 95%+ foil, and almost no non-foil-non-promo cards – if I have to put a non-foil Primeval Titan into my cube I will, but not without some regret).

Normally, a cube is actually surprisingly cheap to put together – were it not for the foil cards restriction I’ve self-imposed, I would be fairly near completion of my cube. I’ve been trading and buying cards at a pretty furious pace in order to get where I am now, which is about 180 cards in, with an additional 100 or so picked out but not yet acquired. Feel free to comment on my pics if you so desire, and by all means, challenge me to a cube draft when I’m complete. I’m very energized to complete this project, so I can play with some of these amazing new cards that I’ve acquired over the preceding few months!

There is a solution, of course – just like almost every part of jQuery, the Sizzle selector engine is extensible. That’s right – you can implement your own selectors that you can then use just like native selectors (big props to Ben Nadel for demonstrating this technique). One of my first needs in this realm was to create a ‘between’ selector – give me all the elements ‘between’ selectors for element A and element B. Here’s an example of what we want the syntax to look like:

var rowsBetween = $('tr:between(tr:contains(Start), tr:contains(End))');

Given the selector above, we would expect it to return the following table rows:

In order to implement this selector, we’re going to make a few assumptions in order to get it to work. First, we’re going to assume that both the inside selectors resolve to a single element (actually, they can resolve to any number of elements, we will just use only the first match). Next, we are going to assume that the first element actually occurs before the last element. These assumptions obviously make for a buggy implementation of a real selector, but they are perfectly acceptable for a user-driven project.
So, down to it. The first thing we are going to do is setup the jQuery selector engine extension method:

$.expr[':'].between = function(
    objNode,
    intStackIndex,
    arrProperties,
    arrNodeStack)
{
	// Placeholder logic...
	return false;
};

Ben Nadel has an excellent writeup on the selector engine interface in his article http://www.bennadel.com/blog/1457-How-To-Build-A-Custom-jQuery-Selector.htm, so no need to cover it again. Now, our next task is to write the guts of our selector. Here’s the algorithm we are going to be implementing:

1. Split the arguments by ‘,’ (comma), so that we have the start and end selectors.
2. Find the start and end elements that correspond to the start and end selectors.
3. Is the element we are currently testing between the start and end elements?
   1. Yes -> return true
   2. No -> return false

This is a relatively easy algorithm to implement. First, let’s do the chopping:

    var args = arrProperties[3].split(",");
    var startSelector = args[0];
    var endSelector = args[1];

Now that we have the ‘between’ selector values, let’s get the corresponding elements from the element collection.

 var startIndex = -1;
    var endIndex = -1;

    // Find the start and end indexes.
    for (var index = 0; index < arrNodeStack.length; index++)
    {
        if ($(arrNodeStack[index]).is(startSelector) && startIndex < 0)
            startIndex = index;
        else if ($(arrNodeStack[index]).is(endSelector) && endIndex < 0)
            endIndex = index;
    }

$(arrNodeStack[index]) gives us the element that we are currently iterating over. In order to see if it matches our start/end selector, we use the jQuery is() method. We have a little handling here to keep from overwriting our values if we’ve already found a match, but it’s all pretty self-explanatory.

Our last task is to check to see if our selected element is between the start and end elements, and return the appropriate value. That again is pretty straightforward:

    if (startIndex >= 0 &&
        endIndex > 0 &&
        intStackIndex > startIndex &&
        intStackIndex < endIndex)
        return true;
    else
        return false;

Putting this all together, we get the following:

$.expr[':'].between = function(
    objNode,
    intStackIndex,
    arrProperties,
    arrNodeStack)
{
    var args = arrProperties[3].split(",");
    var startSelector = args[0];
    var endSelector = args[1];

    var startIndex = -1;
    var endIndex = -1;

    // Find the start and end indexes.
    for (var index = 0; index < arrNodeStack.length; index++)
    {
        if ($(arrNodeStack[index]).is(startSelector) && startIndex < 0)
            startIndex = index;
        else if ($(arrNodeStack[index]).is(endSelector) && endIndex < 0)
            endIndex = index;
    }

    if (startIndex >= 0 &&
        endIndex > 0 &&
        intStackIndex > startIndex &&
        intStackIndex < endIndex)
        return true;
    else
        return false;
};

That’s it! We’ve now got the ability to use the ‘between’ selector just like any other jQuery selector. Pretty simple, no? From not knowing a thing about selector engine extension to a finished product, this was only a few hours of work (mostly research, too). If you’re looking for an opportunity to try implementing a custom selector, try that ‘previous adjacent’ selector I talked about in the opening paragraph – it should be pretty easy to implement.

SPDY (pronounced ‘speedy’) is designed as an adjunct to the http protocol, which has been around for nearly twenty years now. SPDY was designed to run atop of tcp/ip, which is the place in the networking stack that the browser talks to the web server. Hence, to be able to utilize SPDY, both the browser and the web server need to understand the protocol. However, the router need not change at all, which will greatly aid in implementation, if it’s standardized as a protocol.

So what are the features of the SPDY protocol? First, it’s faster than standard HTTP through a number of mechanisms. By default, it gzips it’s headers (and all content), making the packets more lightweight. It only needs one channel for data transfer (it multiplexes requests through the channel, which functions as a stream), so there’s a tremendous amount of connection overhead reduction versus standard-fare HTTP. The connection is designed to remain open as long as the client wants, which means that new content can be pushed from the server to the client. Packet prioritization is built into the protocol as well.

The nicest part of SPDY, in my opinion, is that it requires the use of SSL by default. This means that every packet sent over the wire is encrypted. Deep packet injection and packet sniffing are realities in the world, so a switch to secure communication is long overdue.

The roadmap for SPDY seems pretty straightforward. It’s not finished yet, but being an open source effort, a standard could be developed in a few years. Browsers and web servers can build in protocol support as the standard is still being developed. Browsers and can try to handshake in SPDY with a web server, then default back to HTTP if necessary. There aren’t many competing protocols out there, especially ones that don’t require any router firmware updates (which would take a decade to roll out, at least). Even if the web doesn’t decide to run on SPDY, the only reason for that would be someone came up with an even better idea in the meantime. A new protocol is definitely in store for the future of the web.

Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

Here’s a 3D CSS Animated Image Carousel that I created while I was learning about 3D CSS animation. Watch the video above to see the technique in action. If you’re on a 3D CSS animation capable browser (currently a non-production version of MAC Safari and mobile Safari in the iPhone and iPod Touch), go ahead and check it out. The video was shot with my XBOX360 webcam, of all things.

Here’s a GeoLocator example I put together that showcases two popular GeoLocation techniques – IP lookup and using the GeoLocation API – in order to both demonstrate the techniques as well as to show the issues with each.

In HTML, there are a few ways of determining the location of a user. Traditionally, this has always been accomplished by IP lookup – a lookup is performed with your IP against a database of known IP locations. This technique leaves a lot to be desired, but it’s been all that’s been available for a very long time.

In HTML5, however, there’s a new Geolocation API. The gist of this feature is that instead of relying on IP address lookup, the browser will instead interrogate the device for this information. This allows devices that have native geolocation hardware (GPS receivers and Wifi antennas, for example) to be able to pass their known location to the browser. Many web-enabled devices of today already provide support for this feature, including the iPhone, the Palm Pre, Android phones, and some netbooks.

The problem with all these methods, however, is that none of them just work on all devices. IP lookup works best in the workplace, but it doesn’t work as well for home users and doesn’t work at all for mobile users, as it pretty much requires a stationary device (amongst other things). The Geolocation API is not supported in all browsers yet (with the major notable holdout being all versions of Internet Explorer), and it tends not to work well on devices that don’t have built-in GPS capabilities (which the bulk of desktop and laptop devices still aren’t equipped with).

Worse yet, when location is returned via any technique, it is often inaccurate. In my case, IP lookup and Geolocation lookup provide locations that are over 10 miles away from each other! That’s not a discrepancy that can be resolved in many cases.

In the longer term, the Geolocation API is almost certainly the way to go. When it is fully supported, it is the most accurate method available. Today, though, the landscape is still fractured and implementing accurate geolocation is not trivial on the web.

I’ve created my first jQuery plugin this week – it’s an image overlay plugin (the static pic above doesn’t do the plugin justice, so click through to see it in action).

Creating a jQuery plugin isn’t that big a stretch for a competent JavaScript developer. There are quite a few tutorials out there where you can grab a template and start working very quickly. In addition to writing my plugin, I also made sure that it supported the metadata plugin, so that you can dynamically change properties on individual galleries and images, which should go a long way towards usefulness.

If you end up using this plugin, drop a line in the comments with a link so we can check out your work. Hope you enjoy!