Another long time in the making, Sammy 0.7 is here and its sexy. Check out the HISTORY and the full Changes to get the full details. The Boy of “Boy meets Girl” is Sammy, and the Girl is HTML5.

Download it!

It’s probably seemed like Sammy development had stopped a while ago. With all the other similar frameworks bouncing around these days, I’ll admit there were some dark days of doubt leading up to this release. In fact, most of the code that comprises Sammy 0.7 has been in the master branch for over 4 months. However, development and my belief in this project hasn’t wained, its more just that I’ve been completely consumed by my work at Paperless Post (and in a very good way). One of the benefits of leading the team there has been the ability to push the boundaries of what we can do with our code and our libraries. We use Sammy extensively at PP and I was super excited to have a use case and a way to develop and test this latest version and all its power. The big addition of HTML5 History support has made the big new app we’ve been working on for the past 6 months seamlessly deep-link between full urls and hash urls between multiple browsers. We’re pretty psyched about it.

History is History

Despite which side you fell in on in the Great hashchange debacle of '11 you can’t argue with the pure fact that regular URI paths are just better than hash (#) paths. The makers of the great browsers of the world and the HTML5 History spec have a solution that attempts to appeal to everyone. The premise is simple – create a JS API for manipulating the full path of the current browsers location without forcing a page reload. Meaning, you can tell the url to change from http://www.example.org/one to http://www.example.org/two without having to reload the window, and allowing you to then manipulate the state of the page. Seems sort of like a dream, doesn’t it? Not only that but it really is a perfect fit for the way Sammy manages state and how Sammy applications are already built around routes and paths. I knew this was the case the first time I saw it, but I was unsure how to mix it with the existing hash based routing that works (and would have to persist) across every browser, not just the latest and greatest.

I believe Sammy 0.7 presents a pretty solid solution. Now, instead of routing on paths that look like #/mypath you just route on paths that look like a server side path /mypath

var Sammy('#container', function() {

  this.use('Mustache');



  this.get('/', function() {

    this.partial('templates/index.mustache'); 

  });



  this.get('/:user', function() {

    this.load('users/'  this.params.user  '.json')

        .partial('user.mustache');

  });



});

The beauty and magic of above is a those routes will match both quirkey.com/#!/aq and quirkey.com/aq and execute the user route as expected. I’ve created a simple working example for you to play with at http://pushstate.quirkey.com/ (source here). We’ve been using and testing this for the past months and I can say its pretty solid (and pretty awesome).

There are some known caveats:

• History only works in latest and greatest browsers (Chrome, FF5, Safari 4) but support for it is growing. Ben Cherry and the team at twitter also found some issues with certain versions of webkit and URLs getting out of sync (though its been resolved
• Your server side needs to be able to handle whatever urls you’re changing to. This means that if you route/redirect to something like /path/one/two in Sammy, the server better be able to handle that url as well and point you in the right direction. Otherwise, refreshing the browser will lead users to a 404 or worse. The sammy-pushstate example has a pretty clever way of dealing with this in couchapps. It uses CouchDB rewrite rules to route any url request (minus the key files) to the index.html page (and hence allows sammy to handle the routing).
• Currently, mobile webkit (aka Mobile Safari and the Android browser) report support for pushState/History when in fact they don’t have it. Since I’ve tried to keep browser sniffing out of the core Sammy repo, it currently doesn’t detect for this. You can manually disable push state per application, though, and do the browser sniff yourself if you plan to use your app on mobile.
• This causes some possible breaking changes for upgrading Sammy apps. If you previously did any routing (or path checking) the path reported in a route (EventContext.prototype.path) is now the full path starting at / not just the path beyond the hash. Also HashLocationProxy was renamed to DefaultLocationProxy.

That being said, its a pretty awesome feature and it makes writing Sammy apps really powerful when exposed to the full path. Theres more information in the API docs here.

Templating engines are so 2010

One thing thats frustrated a number of Sammy users is that previously all the template plugins (aka Sammy.Mustache, Sammy.Handlebars, etc) included the source for the engine in the plugin. In the beginning, I thought this was a great idea because it reduced the number of potential headaches and complaints of ‘Mustache isn’t working (because I didn’t include the source)’. However, what turned out to be a bigger issue was keeping up with all the plugins and their individual rapid development cycles. Because of this, all templating plugins (with the exception of Sammy.Template and Sammy.Meld) are now just simple wrappers and expect you to include the respective templating library in your own source. This also makes the case of using Mustache outside of Sammy in the same source/app as a Sammy.Mustache application a lot easier. For the sake of making the transition easier, the latest version of all of the engines is included in the repo (in vendor/templating).

More!

Those are certainly the biggest things with this release but its also not the whole deal. There were 12 other changes, bug fixes, and new plugins written by 10 different contributors! I can’t thank the people who use and contribute patches and ideas back to Sammy, enough. You guys rock.

Thanks to the awesome folks at stickermule I now have a big stack of Sammy.js stickers I want to share with all you fine folks. There are a couple ways to get them:

• I’ll be at JSConf (duh) and a bunch of other meetups and get togethers until then, so just harass me for one when you see me.
• If you live outside of NYC or the Bay Area, just send a self-addressed stamped envelope (MAIL – I KNOW CRAZY) to:

Sammy.js Stickers
c/o Paperless Post
3130 24th St, Unit C
San Francisco, CA 94110

I’ll send you more than one, and you can sport it on your laptop like yours truly:

I’ve been around the block when it comes to web development and I’ve witnessed this sea change first hand. I’m not going to go in and recount war stories, but I’ve had my ups and downs working with Flash and Flash developers. I can’t really pinpoint a specific moment when people started to question it, but I remember working on a site for a high end fashion client and seeing early versions of script.aculo.us and just being blown away. It seemed so simple: this animated dropdown menu didnt need to be designed and compiled in an entirely different environment! It could all be one thing. Sure the animation was pretty chunky and yeah it might have crashed the occasional Firefox, but it seemed like magic – and I wanted more. It took some convincing, but we started to build out more and more outside of Flash and it felt great. Then there was the iPhone, and soon enough it all seemed so repulsive. You mean, I can’t see what kind of noodles this Thai Fusion place sells!? argh. I dont know how Apple did it, but wow, what a spin. Instead of blaming the device, or even better, the authors of these restaurant’s websites – we all started blaming Flash itself. FLASH SUCKS became the new mantra and we all went along with it. Like an angry mob with iPitchforks we stormed Flash’s castle.

The result of all this yelling and vigorous finger pointing is in some ways what we all call HTML5. This glory train of hope, a beacon from a distant land where everything is a standard and you can order thai food from your phone. The hilarious thing however, is that as JavaScript developers the joke is on us.

Why People Hate Flash

Beyond the pure cargo-culting and the flash-blockers, some people at the heart of the argument do have their reasons. Lets take a brief detour from the main story to examine some of them.

It’s a proprietery product with a single owner

This is the con that most open source developers take issue with and something that hurts somewhere deep inside. As a very active open source developer, not only on my own projects, but as part of the community at large, I really don’t want to work on closed platforms. Since my first experience with open source and my first experience reporting, finding and fixing a bug, I haven’t turned back. Ruby, Rails, jQuery, etc. the benefits of open source are more than I can extol here. As a user, though, the core of OSS is transparency. It’s discovering a nasty bug and being able to effect change. This factor is obviously a range between projects but at some level, even if you don’t report a bug, it’s just knowing it’s there. It’s the knowledge that a community of people is willing and able to fix things. The lack of this is what instills fear in me when using software these days. As part of a team we’ve experienced bugs in Flash and reported them, and waited for a fix. When it’s something critical, sometimes you just want to be able to poke at the source. Even if it’s just to leave and say not my problem. I get this, it is a problem. I can’t really excuse this, other than saying that this same problem exists with most software and tools people use on a daily basis. Open Source is the exception, not the rule. Apple and the iPhone SDK is as much of a problem in this regard as Flash. Steve Jobs’ saying that they’re commited to open source and standards by supporting Mobile Safari and Webkit doesnt mean that the SDK or the tools to compile iPhone apps are going to be open source any time soon.

It doesn’t work on my iPhone

This is true, it doesnt and that’s a problem. In Steve Jobs’ angry missive he blamed unreliable performance and battery draining as well as other things in their lack of support for Flash. I have an Android these days, and it is slow, but at the same time, it’s pretty useful to have Flash running on the device. Does it drain battery? Probably? No more than watching a video or checking Twitter every 20 seconds. Clearly there were other factors at work there, and I’m not blaming Apple really. It is annoying that a lot of sites rely on Flash at their core (in part Paperless Post is not exempt) but really that’s an issue with developement practices, not with Flash or the device.

With or without Flash mobile is really a seperate concern. On mobile devices making something interactive, fast, and compatible is really the challenge.
(In fact Interactive, Fast, Compatible is really the CAP of mobile applications). Unfortunately the promise of HTML5 only sort of solves this at this point. Have you used canvas on an iPad? It feels like you’re running Flash in IE6 on a Pentium II. SLOW. Sure, there’s CSS Animation, but that really only takes you so far. I guarantee this will change in the next short while (years not months), but we’re talking about now.

It’s not crawlable by search engines

At its core this is true, but its just as true as with AJAX applications, as can be seen by the recent hash-bang hubub. With Flash or JS you have the same challenges and roughly the same solutions. The most complete solution at this point is just to make a mobile or JS and Flash-free version that the more interactive version is a layer on top of. The fact that your restaurant’s website doesnt have an HTML menu is not Flash’s fault, its the developer’s fault for not making it accessible.

Its slow and crashy and makes my fans turn on

Yes, there are slow and buggy sites out there. Yes a lot of them have .swfs on them. Is Flash as a tool and platform really at fault here? Flash openened up the web to interactivity, high quality streaming video, and robust applications. As a tool it’s very very powerful. With great power comes great responsibility. It’s pretty easy to invoke a memory leak in Flash and it’s up to the developers to contain and optimize their apps. Again, this is really a problem of education and the development community at large. The most common target of this complaint are Flash based advertisements and banners. So an ad for body spray takes over your page, and seems to slow your whole computer down. Thats pretty annoying. Well just wait for DOM/canvas based ads. They’re coming, and they’re manipulating your entire page and breaking your JS. Just you wait.

A couple of reasons to love Flash

At the same time, and despite all the yelling, there are some clear reasons to still love Flash. It was the first to do a lot of these things we now call HTML5 on the web. In many and maybe most cases it’s still better at doing them. In particular, while HTML5 video works pretty well on certain devices and browsers, it’s pretty far behind its Flash counterpart in terms of speed and general functionality. Fonts as well. One of the sticking points we’ve had at Paperless Post is the lack of detailed font controls and especially interactivity with fonts. Sure @font-face is nice, but it has its limitations and compatibility issues when it comes to pixel perfect rendering. Canvas fonts are even worse.

Flash is also pretty much everywhere. Besides the iThings, Android, your browser (every browser) its there and works almost exactly the same. That’s pretty sweet. It was one of Flash’s original promises and it still rings true (with one major exception). The proprietary thing also comes in handy in this respect, too. I’m not agreeing with it, but when a bug is fixed or a security hole is patched, updates come rather quickly to your end users. This is as compared to the wide range of browser release cycles.

From a development standpoint, ActionScript is close to something we know and love (presumably): ECMAScript. Newer versions have added more Java-like package management but a lot of the syntax (; and {}) et al will be very familiar. If you have only ever programmed on the Flash timeline, you would also know that most ActionScript apps are coded in a normal editor of your choosing and compiled on the command line. In fact, there’s a pretty cool project generation and build tool for ActionScript in Ruby called sproutes. Its syntax tends to lean more towards the Java and less towards the script, but it’s still very easy to pick up. In fact, I jumped in to one of our projects at Paperless recently and was able to code up a bunch of a module in a single day with only passing help from our resident AS3 expert.

There is hope: quit being an asshole.

That all is great, but it misses the biggest and best thing that Flash has – a thriving community of extremely talented developers. Its not uncommon to find a Flash developer at this point with > 10 years experience coding in Flash for the web. 10+ years! How many years have you been programming JavaScript professionally? For how many years has it been your primary focus? How many large scale interactive applications have you built? My guess is that the average Flash developer has built 20 times that. For good reasons. Not only have they had better tools for most of that time, but they’ve also been in heavy demand for that whole time, and building applications non-stop. Many of the challenges that JS and HTML5 developers are facing when building these large scale interactive apps, the Flash developers have already solved. They have those algorithms, that knowledge of 3D, that ability to turn code into motion and excitement.

As a talented Flash developer, you’re probably starting to explore the world of HTML5 and canvas and in some cases Cocoa and Objective-C. You’re starting to learn how to adapt your Flash expertise to this brave new world. In some cases you’re pretty put-off by the attitude of the JS community and its blind hatred of a tool and framework that you’ve devoted a portion of your career to up to this point. Understandably. A lot of these people are being assholes. If you devoted a lot of your waking hours to Java, it was and is really hard to want to ease into Ruby due to the bile and anti-you sentiment coming from the Ruby community. Over time, Ruby has adapted to its community and its forebearers (see JRuby).

As a JavaScript developer, it’s now your responsibility to stop the hate and welcome these super smart developers with open arms. Ask them questions, lean on them for advice, for hacks, for problem-solving. Hire them, even! They will appreciate it and they will blow your socks off. The best Flash developers aren’t tied to a language or technology, they’re just really interested in making awesome, boundary-pushing applications for the web. The fact is that they’re moving this way with or without you. If you help them, and respect them, and learn from them, your app and eventually the entire web will be a better place. If you shun them, they’ll just do what you do, but do it better. They’ve already done all the things that you’re trying to accomplish.

Flash isn’t going anywhere for a little while, and complaining about it doesn’t help. Instead let’s all quit being assholes and work together to push the open web and open standards. Most importantly, let’s learn from all our mistakes and triumphs and hacks and continue to make the now web more fun.

Deep Linking

Let’s take a little trip down memory lane, shall we? My first interaction with the ‘#’ as a method for getting at specific content (not as an anchor tag) was working in the ad/interactive space and with a lot of Flash developers. On every proposal or statement of work was a line about ‘Deep Linking’. In this case it meant plugging in swfaddress and wiring it up to your fancy Flash slideshow or fashion showcase. The point of this all was that when you clicked on the 8pt text in the menu that said ‘MENS BLOUSES’ you would be taken to the photo of a puffy shirt and the url would change to ‘#/items/puffy-shirt’. When you refreshed the page, or sent the link to your friend you would be taken immediately to the puffy shirt and be able to bask in its frilly glory without navigating through the 8pt menu again.

This was a big thing! Big, as in exciting and awesome, because it meant you could build relatively complex Flash applications, felt ‘stateful’ somehow. You would navigate somewhere and you’d be there, not in the middle of nowhere.

An important thing to note here is that this was not for Google. It was Flash. Google can’t crawl Flash. The point was allowing people to ‘Skip intro’ and have them feeling that this crazy interactive experience wasn’t all that different from there normal browsing. For crawling and SEO there were a host of other strategies – META tags, ‘ghost’ static HTML sites, etc. – and these were deployed alongside ‘Deep Linking’ as two different strategies trying to accomplish different things.

AJAX FOR THE PEOPLE

We’ve moved on (sort of) from the days of 8pt menus and pixel fonts. The old problem is new all over again. Now we’ve built these applications that rely on JavaScript being enabled to construct our site and fetch our data and animate our menus. Awesome! Its HTML5-tastic. At some point, we discovered the same problems that we had with Flash. Namely, when you’re loading all your content with AJAX and loading it onto the page based on clicks, you get lost in a sea of asynchronicity. What state are you in? Clearly, there’s an easy way to solve this – use the ‘#’ to route URLs without reloading the page and Deep Linking directly into content. I created and continue to work on Sammy.js, partly, as a solution to this problem. You want your application to feel interactive and fluid, you want to avoid page reloads, but when the user does reload, or copy the link, they should be taken back to the same place.

Then, confusion sets in. In a world where the only way people get to Facebook is by Googling Facebook you want your site to be ‘googleable’. This presents a problem: your application is dependent on javascript and ‘#’ and google don’t know about those. Well then, brotha, Google’s got your back. All you have to do is put a little ! after your # and tell google where to fetch your content and it’s like BLAM: SEO.

Except, no.

This is the part where I want to shake everyone. Like physically shake and be like “YOU! YOU’RE MISSING THE POINT”.

There are two different things. Crawlability and Deep Linking are two different things. For different reasons and different goals, and conflating them not only makes it hard on users, but also makes it hard on developers. You end up doing neither of them right.

I’ve been asked about a million times now, “How do you do SEO with Sammy?”. The answer is never simple, because its the wrong question. The question should really be – “If I’m really concerned about SEO, the crawlability of my site, and the persitance of my links should I use Sammy?”. The answer without a doubt is No. I’ll be the first one to say that Sammy and other similar frameworks are not for every site. Period. Theres no reason that your blog or your news site needs to load all its content with AJAX or needs to use ‘#’ to route for state. An important disctinction in what I’m trying to say is that its “you shouldnt have to” not “you never should”. If you’re building a site like Gizmodo you should pretty much always at least START with good ol’ semi-static pages that dont require JavaScript and load at old-fashioned URLs. This is not to say that you can’t build an application on top of these static pages that is more dynamic and interactive and relies on JavaScript.

Sammy and the ‘#’ are for applications. It provides a way to maintain state in a world where you can require JavaScript and even require the presence of certain browsers. If you’re an application, that requires login/signup you can make a number of demands of your users. You also probably dont even want the crawlability. You’re using ‘#’ to maintain state for a specific user in a specific session.

Outside of the world of the ‘application’ you really, really shouldn’t rely on JavaScript being there for your site to work (at least at a basic level). Jen Lukas has already talked really eloquently about why thats the case. I believe that this is where a lot of the recent frustration has come from, and really it should be directed at the use case, not the overall usage of ‘#’ for state. There have been some fingers pointed at Google for making this conflation possible, and I tend to agree.

How to do this right

I’m not going to go into detail about what framework you should use or how to lay out your app. Those are fairly complicated and my opinions could take up a couple blog posts. However, the basics are straightforward.

First, you need to determine some things about the structure of what you’re building and what your content is. Are you building an ‘application’ or a site? Does your content need to be searchable and reachable by the entire web? Do your links require true permanance and will changing them in the future “break” traffic to your site?

If you need searchability and permancance and you’re not building an application, the real best way to approach is to build your site as if JavaScript doesn’t exist. The fact is that there’s still a chunk of users for which that will be true. Not only because they’re using old browsers, but they’re on phones, or they’re on assistive devices or they just turn JavaScript off for ‘security’ reasons. If your site works this way and looks pretty decent (meaning its readable and the content is accessible) then basically you’re good. Golden. Your site works as expected, but maybe not all AJAAAAZZAY. It’s at this point that it’s acceptable to build a layer on top of your existing site, sprinkle the magic dust.

Twitter is an interesting example here because they took what was at its core really an information site, not all that different from a blog and turned it into an application. The questions of URL permanence are really gray here but I dont find myself hating it at all.

Web standards are at the core of this debate. Many make a strong argument that concept of the URL and HTTP is here for a reason, that URLs have worked and continue to work. I think instead of fueling FUD, we should get back to the work of building a better standard and a better web.

A brief epilogue on pushState/HTML5 History

A lot of people are pointing to the new HTML5 History API as a much better solution to this problem. I agree with reservations. First, the browser support for this currently isn’t very wide, and certain browsers that do support it have buggy/broken implementations. The bottom line is that it will work in some places, but not most, and this will probably be the case for years to come. That said, it is really exciting and I’m working on built in support for it in the next version of Sammy.js. I have other reservations, too – namely I think that not all hashes are created equal and in some cases the state you want to represent is really the state of a specific page not a seperate page that really requires a fully seperate URL.

Sammy.js is finally official because now we have a real dedicated website: http://sammyjs.org. It only took two years.

Along with the website the logo I designed before JSConf.eu last year now has an official place to proudly be displayed. Since we’re a REAL project now, we’re also starting up the SWAG train, so logo stickers are on their way.

The biggest change with the new site is the API documentation has been significantly cleaned up. The text is still being generated from the code itself, but now we have easier navigation, the ability to keep multiple versions of the docs (generated per release) and probably the most fun – method level comments powered by Sammy users and contributors, DISQUS. I’ve made good use of the method level comments featured in sites like apidock so I’m very excited to see if the community participates here.

Sammy.js is growing up and its been so much fun to see how and where people use it. I don’t see that many big changes in the future for it before we push a real 1.0 (See a brief roadmap on the mailing list) and a big goal is to get push the big one oh before this year’s JSConf in Portland.

A question came up on the mailing list recently about overriding previously defined routes after struggling thinking of how to do this with the current codebase, the answer was simple: Use helpers!

Coming from Sinatra or Rails the idea of helpers might be associated with just “view helpers” – methods added to the controller which are passed down to the view to help refactor/encapsulate common view logic. In Sammy.js helpers are really a way of refactoring common logic out of routes and into a reusable named method.

Refactorin’

In any app you’ll have startup code or code that needs to be run for every or multiple pages (routes). In Sammy this might looks like:

$.sammy(function() {

  

  this.get('#/', function() {

    if (this.params.grid) {

      this.$element().addClass('grid');

    } else {

      this.$element().removeClass('grid');

    }

    this.partial('index.html');

  });

  

  this.get('#/user', function() {

    if (this.params.grid) {

      this.$element().addClass('grid');

    } else {

      this.$element().removeClass('grid');

    }

    this.partial('user.html');

  });

  

})

A contrived example, but you can tell we’re doing almost the exactly same thing in each of the routes. A common JS convention and something you could do pretty easily here, would just be to extract the functionality out into a closure/function and call it for each route.

$.sammy(function() {

  

  var displayGrid = function($element, display) {

    if (display) {

      $element.addClass('grid');

    } else {

      $element.removeClass('grid');

    }

  };

  

  this.get('#/', function() {

    displayGrid(this.$element(), this.params.grid);

    this.partial('index.html');

  });

  

  this.get('#/user', function() {

    displayGrid(this.$element(), this.params.grid);

    this.partial('user.html');

  });

  

})

This works, it prevents global leakage by declaring it inside the app, and it gets rid of a number of lines of repetitive code. However, we’re still passing a bunch of route attributes into the closure. This is where helpers can shine.

$.sammy(function() {

  

  this.helpers({

    displayGrid: function() {

      if (this.params.grid) {

        this.$element().addClass('grid');

      } else {

        this.$element().removeClass('grid');

      }

  });

  

  this.get('#/', function() {

    this.displayGrid();

    this.partial('index.html');

  });

  

  this.get('#/user', function() {

    this.displayGrid();

    this.partial('user.html');

  });

  

});

This looks a lot cleaner to me. You might not love this but it makes some things really magical. By making displayGrid a helper it automagically has access to the context of the current route. That means that just like the route’s callback, it has access to everything in the EventContext including params, redirect, render and other helpers. This is important, because it basically allows you to extract common code from routes into helpers and then refactor those helpers even further into other helpers.

stOOPid inheritance and mixins

Helpers are actually just methods on the app’s EventContext prototype, and event though there’s no classical inheritance with super’s and all that jazz we can do some fun OOP-like magic.

In the example from the mailing list, we wanted to override an application’s existing route with a new route. Though the way routes are stored and handled makes it difficult on the app level, doing it on the helper level is EZ:

// initializing a new app

var app = $.sammy(function() {

  

  this.helpers({

    // define a helper to load the index as the default behavior

    loadIndex: function() {

      this.partial('index.html');

    }

  });

  

  this.get('#/', function() {

    this.loadIndex();

  });

});



// override the specific helper, and hence the index route

// we can also do this by calling `helpers()`

app.helper('loadIndex', function() {

  this.partial('specialindex.html');

});

use() is how Sammy includes a plugin in an app. A plugin is really just another app function, though, that get’s evaluated at the time you use() it. In fact, when you call $.sammy() you’re just creating a new instance of Sammy.Application and then calling use() on it with the app function. This is a simple way of doing “mixin” style inheritance. A plugin can do anything an app can, including and especially helpers. So with multiple apps we be all like tag team: OOP there it is

$.sammy('#hiphop', function() {

  this.helpers({

    playCatchPhrase: $.noop

    // noop there it is 

    // this is sort of like an abstract method

  });

  

  this.get('#/catchphrase', function() {

    this.playCatchPhrase();

  })

});



var atlanta = function() {

  this.helper('playCatchPhrase', function() {

    alert('whoomp there it is!');

  });

};



var la = function() {

  this.helper('playCatchPhrase', function() {

    alert('do the hump!');

  });

};



$.sammy('#hiphop').use(la);

// get '#/catchphrase' //=> 'do the hump!'

Thats still pretty simple, though combining these ideas is actually pretty powerful. Almost all of Sammy’s existing plugins are based on this simple approach. I’m hoping soon, it can get even more abstract and complex. Why not a Sammy.Auth that handles displaying/posting/and doing all the basic authentication? You could use helpers for most of the dirty work and then one could just override the defaults in their specific apps. You could even create another set of plugins that were different displays or authentication systems that override the simple base methods. Do it! ( so I dont have to )

I’ve been thinking about part III and beyond as well, but thats for another day. I hope at least this fixes a lot of the confusion for people delving into Sammy for the first time.

Check out the new tutorials here.

It’s a couple months in the making, but I’m happy to say that Sammy.js 0.6 is finally here. Check out the HISTORY and the Changes. I’m calling this release the California Suite in honor of my move to the West Coast and the fact that I did most of this coding on the plane back and forth. There are some awesome big new features that I’ve been using for a little while now and I can say are a big improvement over previous releases.

Download it!

Before I get to that, I want to mention that work is in full swing on a new Sammy.js website with more documentation and other great stuff. I even have a real logo which I hope to share soon (stickers, anyone?). Before the site launches, though, I set up a new GitHub wiki so that sammy.js users and developers can share projects and code that they’ve been working on.

On to the features!

Context! Context! Context!

The biggest complaint and frustration that I heard from people working with Sammy was about dealing with rendering complex views on the client. If you’re doing full client side applications or any amount of client side templating you’ve felt the pain of deeply nested callbacks and complex workarounds for interpolating data in an asynchronous environment. It’s all like, render this template, wait, first I need the data, hold up, I cant even render that yet I need to get this other template first. Here’s a common example of what I’m talking about:

this.get('#/', function() {

  this.partial('index.mustache', function(html) {

    $('#main').html(html);

    $.getJSON('items.json', function(items) {

      this.partial('item.mustache', items, function(item, i) {

        $('#main ul').append(item);

      });

    });

  ));

});

It’s not just nested callback’s that are the pain – its the knowing (or not knowing) when a template will be there or not. It’s also trying to deal with fetching data and fetching templates within the same context without a unified API. After kind of examining how other people are doing this, I took some queues from jQuery’s API as well as ‘promise’ style programming and Sexy.js. The result is Sammy.RenderContext. You create a RenderContext by calling one of three methods within a route/EventContext – load() render() or partial(). Once you have a every method you chain to it is guaranteed to execute in the order that you chain it regardless of it synchronicity. This means that you can put an appendTo() after a load() and the content won’t be appended until its fetched asynchronously from a remote location. The content from the previous method in the chain is also passed along so you don’t have to constantly pull out references. The code above, translated to the new way looks like:

this.get('#/', function() {

  this.render('index.mustache')

      .replace('#main')

      .render('items.json')

      .renderEach('item.mustache')

      .appendTo('#main ul');

});

A wee bit nicer. Not only does it improve readability but it makes it much easier to do longer more involved client side templating without getting lost in a mire of order and context passing. RenderContext’s can also be invoked side by side in a single route for parallel execution of chains. Each chain is its own object and keeps its own state. I tried to keep the API concise but with just a few methods, I think most situations are covered:

then(function(content, previous) {})

next(content);

wait();

// Loading local or remote content

load('item.template')

load($('.item'))

// rendering templates

interpolate('item.template', {})

interpolate($('.item'), {})

render('item.template', {})

partial('item.template', {})

collect(items, function(item, i) {})

renderEach('item.template', items)

// DOM Manipulation

swap()

appendTo($(element))

prependTo($(element))

replace($(element))

// Events

trigger('name', {})

Along with the readability improvements, the RenderContext (specifically load()) allows for DOM style or pre-embedded templating. Meaning, templates don’t have to come from files, they can be DOM elements and embedded into <script> or hidden tags. This goes along with the two new templating engines added as well . . .

Alchemy

I thought I had this really novel idea. Why not use classes or other attributes of DOM elements to define how they’re tied to a JSON object? I worked on some prototypes and finally found a name and wrote some real code. It turns out, it was a pretty good idea, but also one that had been done before. 0.6 includes plugins for my own Sammy.Meld and the existing and by default more popular pure.js.

The basic idea of both of these engines is that you take some data like this:

{

  "post": {

    "title": "My Post",

    "body": "Lorem ipsum dolor sit amet.",

    "tags": ["one", "two", "three"],

    "meta": {

      "comments": 5,

      "time": "Yesterday"

    }

  }

}

And some HTML like this:

<div class="post">

  <h2 class="title"></h2>

  <div class="body"></div>

  <span class="tags"></span>

  <ul class="meta">

    <li>Comments Count: <span class="comments"></span></li>

    <li>Posted: <span class="time"></span></li>

  </ul>

</div>

Meld them together and you should get something like:

<div class="post">

  <h2 class="title">My Post</h2>

  <div class="body">Lorem ipsum dolor sit amet.</div>

  <span class="tags">one</span>

  <span class="tags">two</span>

  <span class="tags">three</span>

  <ul class="meta">

    <li>Comments Count: <span class="comments">5</span></li>

    <li>Posted: <span class="time">Yesterday</span></li>

  </ul>

</div>

There are some clear benefits to this over traditional tag style (mustache, ejs) style templating. Namely, its just HTML. This means that you can include it in the DOM on the initial render and not have to go fetch it from the server. It also means that a designer can just design it and even use lorem ipsum if you want, and you don’t have to go through and add the templating language. There are some downsides, too. DOM manipulation even with jQuery’s speed is pretty much always going to be slower then just text interpolation. I’m working on improving the speed of Meld though caching and faster manipulations, but it ain’t easy. The other big downside is that complicated iteration or template logic is pretty hard to do in this style. Pure tries to get around this by using a third element called directives which are further instructions on how to meld the data and the markup. I forgo this extra ability to configure in Meld in favor of very simple transformations (ul,ol = lists) and a much smaller file size (uncompressed meld is only 4K). I’ve been using Meld on some personal projects and hope to test its worth in a real production environment very soon. You can see more examples of it’s power in the tests

What’s next?

I’m still pushing to get Sammy.js to 1.0 in the very near future. I really don’t think theres that much between here and there. I’ll mention that I’ve finally been seriously coding with node and server side js and I’m not that happy with the current state of routing libs there. Server side sammy? Maybe.

More

There were a lot of smaller bug fixes and improvements beyond Meld and the RenderContext so I definitely encourage checking out the full list and making the upgrade soon. Big thanks as always to everyone who helped with the release. Go out and make some apps!

More interesting, I was interviewed by The Changelog Show. Wynn and Adam are awesome hosts, and we talked about a lot of fun things including a good deal about Sammy and JSConf. Since I didnt really get to talk too much about Sammy at JSConf, it was a great way to share my current thoughts and some stories of the origins of Sammy.js. This also lead into a nice mention on The Dev Show yesterday.

I haven’t mentioned it here either, but I’ve also been making some major upgrades to my Sammy presentation app, Swinger. I added slide sorting, incremental lists, and a ton more. This also includes having a fully useable hosted version for people to play with at http://swinger.quirkey.com/

I’m very excited about where Sammy is going and even more excited as I’m using it almost every day and getting to contribute back to the project and think about the stumbling blocks as I use it.

I already have a basic plan laid out for the next release which is mainly focused on re-writing the partial() and template handling to make chaining multiple templates much much easier. You can follow the work I’m doing on it on github. The current status is that it works and passes the basic tests, but theres still a bit to go in terms of API and usability. I’m going to write a more detailed post about it very soon.

Making Bacon / Making Code

So the story goes that over a couple drinks after an NYC.js meetup, I got into a little yelling match with Chris which ended in him saying “If you make bacon on stage at JSConf, I will make you the keynote.” Later that week I submitted this proposal (in JSON):

{
  "name": "Aaron \"Fuck that, you don't know me\" Quint",
  "email": "aaron\@quirkey.com",
  "twitter": "aq",
  "location": "B-to-the-K-to-the-L-Y-N",
  "topic_title": "MAKING BACON <=> MAKING CODE",
  "topic_description": "For all the Cookbooks we have, and all we talk about bacon,  you'd think we could actually _make_ something. Its all BS. Have you ever taken a pork belly, trimmed it, salted it, let it cure and then smoked it.  Have you ever _made_ bacon? I have. I'll show you how. I'm no bacon expert and I'm no expert chef. I'm also no coding genius or javascript prodigy. I'm probably a better cook then you, and I probably have written some half-decent code. I probably can draw some sort of analogy between writing code and making bacon. Watch me try.",
  "claim_to_fame": "I'm not famous, I just do a couple things better then you do."
}

The dare turned into a reality. Somehow we were able to keep the fact that I wouldn’t be talking about Sammy.js a secret for over 3 months. I just kept telling people “its a suprise” Though I would have loved to have told everyone how awesome Sammy is, in the end, I think I managed to pack some good messages into this talk. After the rush of doing the talk, and getting a some laughs, I got the best feedback I could have asked for: A ton of people came to me afterwords and said “I’m going to make bacon now.” That makes me feel all warm and fuzzy inside. If you are one of those people, and you do end up making bacon, send me some pictures and I’ll link to them here. I also promised I’d link up a list of resources for those ready to plunge into the world of home made charcuterie.

My Talk

• Slides
• The Making Bacon Video

Books

• Charcuterie: The Craft of Salting, Smoking, and Curing by Michael Ruhlman (the source of the recipe)
• On Food and Cooking: The Science and Lore of the Kitchen by Harold McGee (the source of ultimate food science knowledge)
• Salt: A World History by Mark Kurlansky (awesome historical facts about salt curing)
• The Omnivore’s Dilemma: A Natural History of Four Meals by Michael Pollan (the history of industrial food)

Sources

• Butcher/Packer Pink Salt!
• The Sausage Maker.com For pink salt, meat hooks, sausage casings, etc.
• Los Paisanos My butcher in Brooklyn.

On the web

• Ruhlman’s blog
• @Ruhlman on twitter
• Dan barber at Ted

I really hope people actually do go ahead with this. It’s fun and very rewarding. For nerds of any kind, making artisanal foods from scratch provides another way for us to “take things apart”. Really, we’re just refactoring our food chain.

I’m pleased to announce the next major release of Sammy.js, 0.5.0. I’ll go over what I think are the most import changes, but you can check out the HISTORY or just cut to the chase and download it.

jQuery 1.4.1

One of the big events I was waiting for in order to release this new version was the release of jQuery 1.4.1. Besides being a good leap and jump faster then previous versions, the latest jQuery added support for cross-browser bubbling of the submit event. This might not sound like a big deal, but Sammy handles post/put/delete routes by binding to forms and their submit events. In previous versions of Sammy, if a form was dynamically added to the page (i.e. by a partial or get route), you (or the app) would fire a changed event, which would tell the app to search for all newly added forms and bind to their submit events. Using the power of jQuery 1.4.1, Sammy can now just listen for submit events that will bubble up to the applications element and from their dispatch the route. In general this is a lot cleaner and will make it easier for beginners as it just works.

Chain of fools

From user requests, and to fulfill my own desires, I’ve tried make Sammy more adaptable to different styles of coding/app creation. The first thing I realized why not make Sammy app definitions chain-able? It’s a style of development that jQuery developers are already used to, and it looks pretty swanky, too. With 0.5, all the app modifying methods are now chain-able:

  



// classic style:

$.sammy(function() {

  this.use(Sammy.Mustache);

  this.use(Sammy.Session);

  

  this.before(function() {

    // …

  });

  

  this.get('#/', function() {

    // …

  });

  

  this.bind('run', function() {

    // …

  });

  

})



// New chain style:

$.sammy()

  .use(Sammy.Mustache)

  .use(Sammy.Session)

  .before(function() { 

    // .

  })

  .get('#/', function() {

    // …

  })

  .bind('run', function() {

    // …

  });

    

Sammy()

Once just a namespace, Sammy() is now a function (and its aliased to $.sammy). The Sammy() method provides access to the new Sammy.apps object and hence allows you to access the different Sammy applications you’ve added to the page without having to define additional global vars. Finding and extending is all based on @element_selector@s so those should be unique per-application. It also provides a quicker syntax for defining an app bound to an element_selector.

// Old way

// we're forced to make app a global so we can access it 

// outside of this closure

app = $.sammy(function() {

  this.element_selector = '#myapp';

  //…

})

// equivalent to

app = new Sammy.Application(function() {

  this.element_selector = '#myapp';

  //…

});



// NEW WAY

$.sammy('#myapp', function() {

  //…

});

// equivalent to Sammy('#myapp', function() {})



// No need to assign it, the app can be looked up by element selector

$.sammy('#myapp') //=> Sammy.Application

There are some cool use-cases for this, including being able to iterate over all the Sammy apps in play and extend them.

any way you want it

Sammy 0.5 adds the new any pseudo-verb which allows you to easily add a route that will match against any verb:

  

$.sammy(function() {

  

  this.any('#/', function() {

    this.log("I'm up for anything");

  });

  

  // also equivalent

  this.route('#/', function() {});

  

});

This was actually the first step of another way to define Sammy applications. The new mapRoutes() method allows you to define any number of routes as 2D Array.

$.sammy(function() {

  

  this.runIndex = function() {

    this.partial('index.template');

  };

  

  this.mapRoutes([

    // each element in the array represents the arguments sent to route()

    ['get', '#/user', function() {

      this.partial('user.template');

    }],

    // leaving out the verb assumes the verb is 'any'

    [/\/alert$/, function() {

      alert(this.params['alert']);

    }],

    // passing a string instead of a callback assigns the method with that

    // name from the application.

    ['get', '#/', 'runIndex']

  ]);

  

});

I personally like the method syntax better, but there are some cool uses for this – You could even load your routes from multiple files and add them to the application using JSON.

Filters

before filters are very useful for extracting common functionality out of your routes. However, I’ve found myself writing this pretty often:

$.sammy(function() {

  

  this.before(function() {

    // only run if the path is not the index

    if (this.path != '#/') {

      //… do something

    }

  })

  

});

Taking some hints from Rails, I’ve added options to before filters. The above example could be rewritten:

$.sammy(function() {

  

  this.before({except: '#/'}, function() {

    //… do something

  })

  

});

The filters can match against path (as a string or RegExp) and verb and you can define them in the positive (only) or negative (except). The method that does the matching is exposed as contextMatchesOptions so you can use it outside of before()

I’ve also found myself doing a lot of wrapping entire route callbacks in an asynchronous check for something (usually a login). The new around filters make this easy. around takes a single argument which is a neatly packed function that contains the full execution path of the route being accessed. This includes additional filters and the route callback itself. This also means you can entirely halt the execution by never running the passed callback.

$.sammy(function() {

  

  this.around(function(callback) {

    // `this` here is the Sammy.EventContext

    // just like before, etc

    $.get('/session', function() {

      callback();

    });

  });



})

Lots more

Theres actually a fair amount more to cover in Sammy 0.5, but I think I’ll be doing more short ‘Whats new’ posts soon. Check the HISTORY for a full rundown of changes.

Thanks

Special thanks goes out to everyone who helped with ideas, commits and testing for this release including Lena Herrmann, Jinzhu, dpree, Jeff O’Connell, Todd Willey, Tim Caswell, and Frank Prößdorf (endor).

Second, I’m headed back to Edinburgh to speak at the Scottish Ruby Conference. I love this city, and the conference last year was very much above par. I’m excited to say I’ll be talking about JavaScript at a Ruby Conference. I’ve been working this talk out in my head for a long time, through lessons learned and taught to my colleagues and clients. There are also a lot of other great looking talks, including Tim Bray, Alexander Lang, Scott Chacon. Actually, the whole conference looks pretty incredible. I guarantee fun. As of writing this, there are still tickets available, so register now.

Third, and possibly most exciting, I’m very proud to be chosen to speak at JSConf 2010. I heard nothing but “AWESOME” about last years event, and I kept hitting myself for missing it. This year the esteemed Chris Williams is putting together what promises to be the best techincal conference ever. I can’t even say how excited I am to be a part of it. The status is that the conference is already sold out, but I would follow @jsconf with a watchful eye to see if there are any announcements. Chris is also a lover of beer, so I cant promise anything, but some very very rare bottles might sway his favor.

There are some other proposals out there as well, but these two confs were all I did this year, I’d be pretty happy.

I’ll swing through some of the biggest changes and new hotness – see the HISTORY or the Commits for a full list and more detail.

LocationProxy

I’ve always thought the poller implementation that monitors the hash/location for changes was a little bit of a hack. CodeOfficer also had brought up the pain of having a poller per-app when you have multiple or many Sammy applications on a single page. As more browser’s support it I also wanted to make use of the native ‘onhashchange’ event which when bound to, completely eliminates the need for polling. I attempted to do this all in one fell swoop, by decoupling the location monitoring into an entirely separate object: Sammy.HashLocationProxy. The HashLocationProxy is setup for each app by default. It tries to make use of the ‘onhashchange’ event where available, and where it isn’t it gracefully falls back to ol’ fashioned polling. The big difference, however, is there is only a single global poller per page no matter how many apps you have.

The HashLocationProxy also defines a spec for other location proxies to be created. There’s also a DataLocationProxy which derives its location from a jQuery.data attribute.

Storage and Session

The newest and most visibly awesome part of the new release is a new suite of plugins and prototypes: Sammy.Store, Sammy.Storage and Sammy.Session. As part of 0.3 I introduced Sammy.Cache which was really a first attempt at what Sammy.Storage does. Sammy.Store is an single access point and API for all the various browser based storage methods, including HTML5 DOM Storage and Cookies. It provides a unified way of dealing with these as Key/Value stores. As an extra bonus, it also conforms to Key Value Observing, triggering jQuery events when values change. Heres a little example:

// Cookies

var cookie = new Sammy.Store({name: 'mycookie', type: 'cookie'});

cookie.set('foo', 'bar'); //=> "bar"

cookie.get('foo'); //=> "bar"

cookie.keys(); //=> ["foo"]

// HTML5 localStorage (only works in certain browsers)

var local = new Sammy.Store({name: 'mylocal', type: 'local'});

local.fetch('foo', function() {

  return 'bar';

}); //=> "bar"

// Only sets if not set.

local.fetch('foo', function() {

  return 'baz!';

}); //=> "bar"

The latest chapter of the Sammy tutorial also covers Sammy.Session

More Plugins

There are also a number of other less glamorous but new and awesome plugins.

• Sammy.Mustache Provides support for the Mustache templating framework, thanks to Mustache.js
• Sammy.JSON is a simple wrapper around json2.js
• Sammy.NestedParams: Adds full [tested!] support for Rails/Rack style nested params to Sammy form handling. (Even though this was part of the 0.3.1 release, I never mentioned it here)

Thanks

Thanks to everyone who helped with this release through testing, ideas, or putting Sammy in production and telling me what’s wrong with it.

Last week I had the pleasure of launching a big new feature set into production for one of my favorite clients, Wejetset. The excitement was greatly enhanced by the fact that City Notes Interactive makes full use of my own special framework, Sammy.js.

City Notes and the other features deployed were an almost ideal project. The design and direction was an awesome back-and-forth collaboration between myself, Tom Ran of The Scout fame, and the face and brains behind Wejetset, Taj Reid. I could probably talk forever about how much fun it is to work with those guys, but in this post I’d rather dive deeper into the challenges and takeaways in the actual code.

I knew right from the beginning that Sammy would be a good fit for this. The question was how. Sammy let me think about the construction of the app in terms of routes and instantly gave me a way to create perma-links to specific notes and even specific filters.

Templating

One of the first decisions I made was to go with server-side templating. As much as I am and have been a proponent of pushing everything client-side, for this specific app it made much less sense. Specifically, there are other places throughout the site where I’m using the same templates and the benefits of re-using them were just too strong. Also, this gives the extra bonus of making the site a little more google friendly. In fact, without JavaScript the most recent notes still display and can link to the right destinations.

Forms

One thing that I wanted to streamline as much as possible is handling forms – posting them to the server and handling the responses without leaving the page. I came up with a useful method – postFormDirectly() – that handles the post route and submits it directly to the server, handling the response and sending it back to a callback.

Heres an example call, for positing the form to create city notes.

this.postFormDirectly('/city_notes', function(response) { 

  if (response.status == 'success') {

    this.redirect('#/');

  }

});

Instantly, you can tell that a lot is abstracted and changed from a traditional route. Here we’re routing on an actual URI as opposed to just an anchor. This has the added benefit of allowing the form to work without JS. (As an aside, I’ve personally found a key to making degradable and unit testable sites is to first make the process work (albeit without any flair) without JS and then add the code to push the interactions and the single page-ness.)

To give a little more insight, heres the implementation:

this.postFormDirectly = function(path, callback) {

  var app = this;

  app.post(path, function(context) {

    var context = this,

        post_path = this.path, 

        wrapped_callback = function(response) {

          WJS.handleResponse(response, context.params, function(r) {

            if ($.isFunction(callback)) {

              callback.apply(context, [r]);

            }

          });

        };

    if (!post_path.match(/js$/)) { post_path = post_path + '?format=js'; }

    this.params['$form'].find(':input').trigger('clear-errors');

    this.params['$form'].ajaxSubmit({

      url: post_path,

      dataType: 'json',

      success: wrapped_callback,

      error: wrapped_callback

    }).trigger('show-loading');

  });

};

Lets take a little walk through. First and formost, we’re just adding a post route to our Sammy app. The contents of this route allow us to use jquery.form’s nifty ajaxSubmit to send the form to the server without reloading the page. We’re creating a response callback for the ajax request called wrapped_callback which takes the response from the server, passes it to handleResponse which then in turn calls our passed callback if it exists. handleResponse does a lot, too, but I’m not going to post the contents here (though I might make it into a plugin …). All you need to know is that the response from the server is JSON and looks something like:

{"status": "success", "message": "You're note was posted successfuly."}

handleResponse displays the little flash message and also highlights the form if there are errors. I use this pattern on a number of projects and it seems to work pretty well.

One neat Sammy tidbit you might not have known about, in post & put routes, there is always a ‘$form’ param which is a jQuery object containing the HTML form that submitted to the route. Very useful for cases like above.

Modals

If you play around with the app, you’ll notice that we make pretty good use of modal windows for actions (submit/share/email to friend). The cool thing about using Sammy for this is they’re just routes, so refreshing the page or linking jumps directly to them. I also wrote a little jQuery extension that I found extremely useful for them:

$.fn.findOrAppend = function(selector, element) {

  var $this = $(this), 

      $el = $this.find(selector);

  if ($el.length > 0) return $el; 

  // el doesnt exist so lets make it

  if (typeof element == 'undefined') {

    // figure out how to build the element from the selector

    var parts = selector.split(' ');

    $el = $("<div>");

    if (parts.length == 1) {

      // single selector so just added

      $el.addSelector(selector);

    } else {

      // selector with multiple depth so we just want the last selector

      $el.addSelector(parts.pop());

      // find this down the parts

      $this = $this.findOrAppend(parts.join(' '));

    }

  } else {

    // we provided a specific element

    $el = $(element);

  }

  // append it

  $this.append($el);

  // return it

  return $el;

};

findOrAppend() takes a selector (I used it mostly with #ids) and creates a series of nested divs (if needed) that matches that selector.

For example, given HTML:

<div id="container">

  <div id="main"></div>

</div>

And we wanted to replace the contents of an element #submit_modal inside of it:

var $modal = $('body').findOrAppend('#main #submit_modal');

The first time its called, it actually creates the neccesary #submit_modal div and returns it. However, if it exists already, it will just find it using $.fn.find() and return it.

For modals, this allows me to ensure that the container exists first, then replace it with the contents of the modal that I’m fetching from the server.

this.helpers({

  // …

  showModal: function(path, selector, callback) {

    var context = this;

    this.showLoading();

    this.loadNotesInBackground();

    this.partial(path, function(form) {

      var $el = context.$element()

                .findOrAppend(selector);

      var $close = $('<img src="/images/button_remove.gif" alt="close" class="close_modal" />');                    

      $el.hide().html(form);

      $close.prependTo($el).click(function() {

        $el.slideUp(200);

        context.redirect('#', context.conditionsToURL());

      });

      if (callback) { callback.apply(context, [$el]); }

      // bind error handlers

      context.bindFormErrorHandlers();

      context.hideLoading();

      $el.slideDown();

      $('#main').slideTo();

    });

  }

  //…

});

Here I have a helper that fetches the view/template from the server using partial() and then situates its content using findOrAppend(). It also does me the favor of adding the little close icon in the upper right corner. A typical use is for the login screen:

this.get('#/login', function(context) {

 this.showModal('/account/login', '#main #login_signup.modal')

});

Analytics

It has to be said as well that I’m really excited about the burgeoning Sammy.js community. I’m lucky enough to have some other really smart individuals working on Sammy projects and sharing some of their code through plugins. Thanks to Brit Gardner and his Sammy.GoogleAnalytics plugin, adding analytics to the app was as easy as dropping in the file and adding one line to my app. That felt really really good. I hope more people will start sharing some plugins soon.

A lot more

There were a lot more discoveries over the months building this app then I can really share in a little blog post but needless to say, I’m going to try to bring the usefull and reusable stuff back into Sammy and plugins for everyone to use. If you want to hear more about it or have specific questions, dont hesitate to ping me on IRC or twitter or email the Sammy mailing list.

Quick note, I decided to use github pages instead of this here blog to post the tutorials. In the end, its just easier to post lots of inline code AND it will be easier to maintain with updates as the Sammy API changes.

I hope you enjoy it! I’m always appreciative of feedback and constructive criticism, so fire away.