Art is passion

Technique alone is never enough. You have to have passion. Technique alone is just an embroidered pot holder.
—Raymond Chandler

Programming and web development is often a cold silent world. We sit in front of ever larger screens, growing ever more quiet as we move all our conversations, all our lives even, on to a souless ‘cloud’ of information. It can be pretty bleak. The push towards this empty void is accelerated by some constant code mantras. Often progress means faster; it means raw numbers and a race towards small benchmarkable improvements. Its a society of technique, of sharpening blades and micro-optimizations. For me, at least, theres something missing. It’s what Raymond Chandler points to above. Passion here is the difference between Technique and Craft, between Hacking and Art.

Hacking is so 1998

I want to retire the word hacking.

I’m sick of it. It implies the completely wrong metality that I would aspire to. hacking conveys butchery, it suggests unproffesionalism. Most of all it suggests a ‘git it done’ attitude that is pretty opposite the idea of making art. Is code art? I’m not going to go in to the ‘what is art?’ circle – its a trap. The art is almost irrelevant, it is the act thats import. The act of creating.

I don’t want to be hacking – I want to be creating.

Art is balance

The more I think about it, life itself is really about balance – or at least the pursuit there of. Not to get all Geoge Lucas – but there are a lot of forces at work and in ourselves that drive what our lives – our art, our work – are about. Here, I believe that the artist, above all, is able to stradle the line between these powers and emotions.

As a programmer here are some of the tightropes you’ll have to walk:

• Pride vs Humility: Taking pride in your craft while being humble about its origins. We’re all just re-formulating old ideas.
• Winning vs Respect: The drive to win and be the best is productive until it means sacrificing knowledge you can gain from your competitora
• Shipping vs Perfection: This is also similar to Quality vs Speed. The need to get something out often is more important then the need to atain perfection in your work. Artists face this every day and the knowledge of self in this respect is often what create uniquness. Jackson Pollock once famously said, when asked about when he knew one of his iconic paintings was ‘finished’ – “how do you know when you’re finished making love?”. Artists rely on thier insticts, not their critics for “shipping”.

Striving

To be an artist is to make art. Where hacking is an act, art is a lifelong goal.

I’m not an artist, but I’d like to think I’m trying.

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.

Here are some of the things I’m hoping to accomplish (in no particular order):

• New Sammy.js Site and updated documentation
• Updated and additional Sammy.js Tutorials
• A soca screencast and tutorial
• Updates to jim and writing about the typical workflow

If you have other suggestions or places in some of my libraries that you’d like to see updated, let me know! Keep an eye here for the latest, starting tomorrow.

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!

When I saw that tweet this weekend it dredged up a bunch of thoughts and experiences that I’ve been wanting to put down on paper for a very long time. Why not now?

Over the past 6 years I’ve worked with 8 different startups in different capacities and pitched or met with countless others. I’ve been a founder; I’ve worked for equity; I’ve been a consultant getting paid cold-hard-cash; I’ve built prototypes, full products, and everything in between. I know there are a lot of more experienced developers out there, but even so, I think I have some things to share, and lessons I’ve learned from the good, bad and ugly of being a developer in a startup.

Startups aren’t for everyone

Every company is different, and from what I’ve experienced so far, the mindset and attitude of the bay area is different in a lot of ways from the NY tech scene. At the same rate, though, there are a lot of common things between most startups. In general the environment and process is much different from a large established company, especially in the early days. This means if you need rock solid stability of schedule, work cycle, direction, space, pretty much anything, startup life might not be for you. There is one constant in being involved with a startup and that is change. If you’re just a developer along for the ride, or a co-founder, change should be something you take in stride. A lot of this has to do with trust. Do you trust the people guiding this ship? Obviously this applies to any job, but is amplified when your livelihood is directly tied to the people you work with.

Don’t invest in an idea you don’t believe in

This should go without saying, but you’d be surprised when people don’t really understand what taking equity or options really mean. When you take equity as a developer (especially as a non-founder) what you’re actually doing is investing in the company in exchange for your skills/work. This isn’t something to be taken lightly – even if it’s a tiny piece. Take yourself out of the position of making the exchange for work. Assuming you had the money and opportunity too, would you give this company you’re money in exchange for equity. This goes beyond trust into the realm of belief. Do you believe that the startup you are investing in will actually be successful and provide a return on your investment? If you don’t believe that or have any doubts then as a developer you’re probably not going to work hard to achieve that goal.

This isn’t just about actualization, it’s about making good investments. Whatever you charge for your time, putting stake in something you don’t think is going to be successful is basically taking whatever money you would have made for that time and flushing it.

Get paid

If you’re a developer working for a startup theres no reason you shouldn’t be getting paid, even if you’re developer numero uno. Perhaps this means taking a slight pay cut from what you would be making at an established company in exchange for some ownership, but the general rule is you should be making more then enough to cover your life costs and at least enough that you’re not bitter towards those paying you.

I’ve done pure equity in the past and have pretty much completely sworn off of it. Unless you’re a co-founder, it’s going to be a very rare case to be committed enough to go the long haul without getting paid. And even if you are a co-founder, you should have enough savings to pay yourself, or think about raising some capital so you can.

If you’re approached by a startup to build their prototype or work on their app and all they have is an idea, they should pay you for your services. If this is the founders ‘side-project’ and/or they haven’t raised or put in any capital, thats a definite sign that you should get paid. Think about it – if they’re not willing to invest the capital to pay you, why should you invest?

Retainers Rule

Going along with the rule that change is one of the biggest aspects of being part of a startup, if you’re working as a freelance developer you need to structure your contract so it accounts for this. If the startup is small or just starting, working on a project basis is a bad idea as a rule. If you’re working to a fixed scope like “Working prototype of myawesomestartup.com”, even if the details are very well defined, what happens when the entire goal of the startup changes? Do you scrap your work? Do you ask for a ‘change-order’? Do you have to just suck it up and forget about getting paid for the extra time you put in? If you don’t assume this scenario from the start, it’s often awkward and painful to try to negotiate this post-change.

At the end of my last round of freelancing, almost all the projects I was working on were set up on some sort of retainer. This was great for me, because I had a definite amount of work and dollars coming in every month. It was great for the startup because they didn’t have to worry about getting charged extra or haggling over money every time they changed their minds.

I pitched every new job and potential client like this, and in the end it worked out great. If the client thought this was a bad idea or was so sure that they had everything ready from the start, I made sure to put in a clause or section that defined exactly what would happen and how much it would cost when they did want something different. (it always happened).

Get the position and job you want

This all comes down to the final point, that as a skilled developer the ball is really in your court. The key is to not abuse that advantage, but definitely make use of it to get the job that you want. The reason I hadn’t settled down into a full time job was really because it took this long to find exactly what I wanted. Paperless Post finally met my criteria:

• Great people
• Clear direction and strong motivation
• A real business plan with actual revenue
• Willingness to pay and reward good work
• Dedication to Open source

It really shouldn’t be so rare to find this, but it really is from my experience. Your requirements might be different, but if you’re ready to take the plunge of investing a lot of time in a product or team it should always be doing the best to meet these goals. As a quick aside, Paperless Post is currently hiring in both NY and SF feel free to mention this post.

Working for and with startups has been uniquely rewarding for me, not just because I’m ballin’ but because I’ve learned more in the past couple of years then I ever could have hoped otherwise.

After freelancing (or hustlin’ – as I called it) for the past year and more, I’m finally settling down. As of last week, I’m now the CTO of Paperless Post. Though I truly loved working with a number of the clients I helped out over the past year, Paperless Post made me an offer I couldn’t refuse – not just monetarily. The team they’ve assembled is not only extremely talented, but is a pleasure to work with and constantly challenging each other to do great work. It would take nothing less to get me to commit to a project full time. That’s not all, though. For my friends and followers in the open source community, you’ll be happy to know that at PP we’re already using a number of my projects including Sammy.js. I actually worked to get into my contract that my responsibilities as a member of the community and a maintainer of these and new projects is part of my job. This means that I should actually get some dedicated time to work on Sammy and hopefully extract some of the cool ideas that we’re working on and get to share them with the community.

Paperless Post isn’t what you’d think of as a typical web startup. Sure, theres funding, competitors, crazy deploys, late night coding. However, they’ve actual made a business and the world outside of silicon alley has already noticed Its not a twitter mashup or a buzz word filled rails app with some missing vowels in the name. Our goal is not to constantly push the envelope, its to do a couple things really well and with style. I can’t tell you how excited I am to be helping to shape the future of this product.

The past couple of weeks has been a serious roller coaster of emotions but somehow thanks to my wife and friends I’ve landed on my feet and I’m better for it. Thanks especially to my former clients for being so supportive during this crazy transition.

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).

I realize its already half way through the month, but I needed to get the obligatory year in review out. I had to bother. Why? Because last year was BIG. I ended 2008 leaving my former job to pursue greater things. My big goal for the year was to do awesome work, start building a reputation, and give back to the community. I’m very proud to say I accomplished all of those. I did so by working my ass off. Straight hustling.

Highlights:

• Getting married!
• Speaking at 4 technical conferences including ones in Japan and Scotland.
• Starting a fund that raised ~$1000 for RailsBridge and the Anita Borg Foundation.
• Releasing Sammy.js and seeing a number of large organizations and companies use it in production.
• Contributing to, releasing, and maintaining over 40 open source projects.
• Working with a number of really awesome companies with very talented individuals including Paperless Post and Wejetset
• Traveling a lot: Japan, Scotland, 3 trips to the West Coast, Boston, Philly, Virginia.

I can’t really complain. I’ve set some new big goals for this year. The biggest is bit of a step backwards. Last year, I worked a lot. A little too much if you ask my wife and some of my friends. So this year is the year of accomplishing a lot while working less. As much as I love coding, there are other things I love more. Namely, my wife. In an attempt to break it down into actual achievable goals:

• Only work with clients that I want to work with. A side luxury of working my ass off is that I’ve been offered a bit more work then I can feasibly do myself. Which puts me almost exactly where I want to be – being able to work on projects I genuinely find fun and interesting. Lucky me!
• Take it down a notch with the open source shenanigans. This is slightly unfortunate, but I’m almost as overwhelmed with open source projects as I am with client work. I’m not going to dump or stop supporting the popular highly used projects, like Sammy or qadmin, but some of the lesser known used ones are going to become unsupported and I’m going to try to slow down with creating new ones. Try.
• Cook more, write more, read more, learn more, see more people. My new meetup/idea code should address some of these. Very excited for the first meeting next week. Buying a kindle has actually made me read way more. I’m trying to spend more time on actual dedicated learning.

At the end of 2010 I want to look back and think about how much fun I had and how much I learned. So, friends and colleagues, heres to those goals and a great new year.

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.

Highlights included:

• Going to RubyConf without actually going.
• Eating and drinking fine food and wine in Napa/Sonoma for 4 days non-stop. (Full list of vineyards and restaurants with menus on request).
• Spending time with my lovely wife.
• Seeing friends I don’t get to see enough.

Though this blog may tell a different story, I actually have been writing a lot of code as well:

• Most notably, the production, public-facing Sammy.js application I’ve been working so diligently on finally launched: Wejetset City Notes Interactive. I learned a ton writing and deploying it, and I promise to share a bunch of those lessons, soon.
• With the help of the amazing rvm I’ve started getting all my gems tested and working on Ruby 1.9. I think everyone should be doing the same, so if people are interested in my approach, maybe I’ll write a tutorial.
• I’ve even been porting other peoples gems to 1.9. Specifically I have a fork of the oauth gem that works on Ruby 1.9.1 without any dependencies. It should be merged and released to the master oauth gem shortly.
• It’s been a long time coming, but I’ve been working on a big rewrite of qadmin thats being used in production in a couple places. Its a lot easier to configure and extend and really just needs to have its documentation thoroughly updated before I can do a real release.
• I’ve also updated my portfolio to include links to my talks and some other new projects.

I’m hoping to get some more blogging done and OSS releases out in the next couple of days so stay tuned!

Let’s just say it was a crazy October, and we’ll leave it at that. There are big things afoot for November, though. I’m headed west for a multi-stop tour of Northern California with my wife from Nov 12-23. It’s going to be part business/part pleasure, but every time I’ve gone in recent years theres been no shortage of fun. Though I wont be attending RubyConf, I’ll be in San Francisco during and around it Nov 19-23.

First, If any dev shops/teams/meetup groups want to hear me talk/present about Sammy.js or any other projects I’m involved in I’d be happy to come by and drop some knowledge.

Second, I would greatly appreciate anybody willing to let me office-crash and hang out with them in their workplaces.

Finally, I would love to meet up with fellow Rubyists, Javascripters and foodies to do any one (or many) of the following things:

• eat delicious food
• write fun code
• talk about the future of the web
• drink and sing karaoke

If you’re interested, just hit me up on twitter or email me at aaron at this domain.

I’m very happy to announce the next major release of Sammy.js. I’ve been working on this for over a month and the result has been a lot more changes then I expected but over all a smaller, cleaner core code base. Here’s a quick run through of the biggest changes. See HISTORY or the Commits for a full list and more detail.

Plugins

The biggest change, that resulted in a lot of little changes is Sammy.Application#use() which allows you to package and resuse application level code into ‘Plugins’. See the documentation on plugins for more detail. This also marks the start of an official selection of plugins, with two as part of this release and more on the way.

The default template system that used $.srender internally has been extracted out into a plugin. To enable almost the exact same functionality:

// somewhere in your HTML (after sammy.js): 
// <script src="plugins/sammy.template.js" type="text/javascript"></script>
$.sammy(function() {
  // include the Sammy.Template plugin
  this.use(Sammy.Template);
  
});

Events

Sammy.Application’s bind() and trigger() methods now use jQuery’s namespacing to bind to Events. This means that Sammy.Application can now easily catch events that bubble to it like ‘click’ or ‘focus’. The big awesomeness is that the callbacks for these bind() methods are always evaluated within a Sammy.EventContext so that even events triggered from outside the app can be handled in the same way as internal events.

var app = $.sammy(function() {

    this.bind('custom-event', function() {
      // this == Sammy.EventContext
      alert('Custom Event' + this.params['wha']);
    });

  });

  // the app is by default bound to 'body'
  $('body').trigger('custom-event', {wha: 'ZUH?!'});
  //=> system alert ZUH?!
  

Cleanup

With the advent of plugins, Sammy Core is now even smaller (8.9k minified). This is also possible because I’ve removed the former ‘classical’ inheritence code in favor of prototypal inheritence, which is a big win in terms of cleanlieness and global scope leakage.

See Also

I mentioned this on twitter, but I’m working on some new tutorials and screencasts about Sammy. If you have ideas/suggestions, dont hesitate to let me know. The first one should be up next week. I’m going to try to do them bi-weekly, we’ll see how that goes

Again, I’ve tried to be as thorough with inline API docs as I could so any changes should be in the clear. Thanks again to everyone who helped with this release and has supported Sammy recently!

I’ll be honest. When I created Sammy.js, It was more of an academic exercise then a means to an end. I had ideas for how it could be useful, and had some immediate uses for it, but the initial thought was ‘recreating Sinatra’s API in JavaScript’. Little did I know – with a little introduction and the work of some clever individuals, its real value would be revealed.

We’re at the dawn of a new age on the web, or maybe or horizon, or a precipice; the metaphor doesn’t matter, the point is, things are changing. Specifically, as browsers become more and more powerful, as developers we’re given new opportunities to rethink how we architect web applications. Whether or not some of the predictions of ‘the death of the traditional desktop’ are correct – whether or not the near future desktop is just the browser – we now have the power, without proprietary technologies (flash, etc) to create truly desktop like experiences on the web. Thats nothing mind-blowing, we’ve seen it coming for a little while now.

Ok, then: let me blow your mind.

Because of the great power that modern browsers provide us as Javascript developers a new paradigm of web development is arising. Lets take a look at the current/traditional model:

Here we have a traditional stack. The ‘power’ of the application lies on the server: our development platform of choice (Rails, PHP, etc) sits on top of our database of choice (probably relational, probably SQL). This server platform renders finished HTML and maybe decorates those pages with the use of our JS library and our application specific code (Your $(hit)). In this model we’re using probably at least 3 different programming languages and almost fully on the speed and reliability of our servers for getting data to the user. There’s probably also at least 3 steps in either direction between data and the user:

• User clicks a link on a page or follows a URL
• The request is sent to the server
• App receives request passes it on to Model/ORM layer
• ORM requests the data from the Database
• Database returns the data to the ORM
• ORM returns the data in a parse-able form to the App
• App converts it into user-readable format and displays it to user

Obviously, Rails and most other languages frameworks abstract a lot of this away, so we don’t really have to think in all these steps. They’re there, though.

Welcome to the new world. HTTP Databases and JSON Storage. The simple act of making the database and the browser more powerful on either end has destroyed the need for the middle tier. In the new architecture, Our database (JSON/HTTP based: CouchDB, Cloudkit) serves data as JSON directly to the browser. On the browser side we create a much smaller/tighter ‘controller’ layer with JavaScript. This handles the directing of the user to the right place, the displaying of the data to the user, and the conversion of user interaction into state + data. This middle piece is jQuery + Sammy.js.

In my presentation at jQuery Conf this past weekend (slides available here) I demonstrated this concept in a rather meta-tastic way. The presentation tool I used was called Swinger and it was written using CouchDB, CouchApp, and Sammy.js. The application logic was contained in a single JS file that used a Sammy application to do all the routing, getting data in and out of CouchDB and displaying it in a particularly pretty way. The coolest part about this whole thing is that even beyond taking out the middle layer, this implementation removes the traditional static file serving model, too. With the power of CouchApp and _attachments, the javascript and HTML files needed to serve the application are served directly out of the database. Its like CouchDB and Sammy.js were made for each other. Think about the new steps for this architecture:

• User clicks a link on the page or follows a URL
• Data is requested via AJAX from the server
• The server proxies to the database or processes the request directly
• The data is returned to Sammy.js as JSON
• Sammy.js uses the data it needs and displays it to the user

There are a number really amazing and exciting things to note here. First, notice how the application is written in JavaScript AND the data is JavaScript. The JSON store might actually be written in another language (CouchDB is Erlang, Cloudkit is Ruby) but we don’t really ever have to touch those. Personally, I really like JavaScript. Sure, I miss some of Ruby’s syntax and niceties, but I’ll give that up pretty quickly for something that still shares some of the similar good features (closures, loose typing) and has a ubiquitous deployment environment (the browser). Second, the end result is probably similar if not better to the end user, as we eliminate the need to reload the page at every request, resulting in a better perceived speed.

One of the provisions I gave for my talk is that “I’m less concerned with speed than awesomeness”. That rings pretty true here. I don’t have an architecture like this running in production and getting hit like twitter. I can’t really speak yet to how well it ‘scales’ or how it preforms under load. I CAN tell you about how awesome it is and how easy and fun it was to develop swinger with Sammy. That’s really all I need to know right now.

I think my talk was pretty successful and besides not getting through all my slides, it seems like I got a lot of people excited about CouchDB and Sammy.js. I’m going to write a pretty in-depth recap of the talk and post it soon.

Also, It sounds like there will be a lot more jQuery and JavaScript conferences in the near future. I can’t wait.