A few weeks ago, when I was in San Francisco, my good friend @mikeal asked me to sit down with him and do an informal interview by the bay. When he asked me, “What’s the hardest part about moving from the position of being a developer to being a CTO and a manager?” this was my response:

At this point I’ve been “managing people” at Paperless Post for more than three years. We’ve grown from a team of 5 to almost 55 as of writing this, and my team, the Dev Team, makes up half of that. The act of working with people takes up a large majority of my time. In the early days it was hard to reconcile my own desire for productivity with that of my team, and I’m not going to lie that I still have days where I want to just put on my headphones, and write some fucking code and not talk to people. In the past year or so, I realized that I was always searching for big challenges, and there in front of me was the biggest challenge of all, People.

People suck, it’s true. I don’t want to hide the fact that a lot of people in this world, this country, this city, are not really pleasant and wether or not their good people or not, I don’t really want to deal with them. I also want to be clear, that while I consider the people I work with some of the best people on Earth, they can still be cruel, annoying, and downright difficult sometimes. I’ve started to believe that managing people isn’t trying to change them into better people, or even try to mold them to some ideal “EMPLOYEE” – managing people is the art of dealing with the fact that every single person is a special snowflake and helping them work efficiently within the confines of who they are.

This is fundamentally different then how I thought about this in the beginning. When I left my first job, where at the end I was “managing a small team”, I was shooting like an arrow aimed at doing the opposite of everything I thought my former bosses did wrong. The one thing I didn’t see as wrong, though, was this idea that People are “Resources”. This in some way implies that different developers, designers, etc, are interchangeable – wether or not they are capable of all doing the same thing you can shuffle them until they fit. While this is a lovely idea, it’s truly fantasy, a vision that a manager at a nice desk dreamed up so many years ago. When you’re working with people who spend their entire days thinking, its beyond just fitting a square peg in a round hole – its trying to shove a thinking human being in a hole of any size – it simply won’t work. The symptoms of this are people who are tasked with the wrong work, spend a lot of time fighting back, and are generally just not getting much done.

At this realization my work changed into “So if they don’t fit without shoving, how can I change my approach to guide them into the right place?”. Ah, the classic art of Inception. This works, sometimes. You’re not changing People, you’re still thinking of them as Resources, as puzzle pieces. However, the approach is different. You subtly direct and assist people into position. It takes a large amount of effort from the manager side, as you spend a most of your time planting ideas, checking in, and generally making gentle pushes in the right direction. This worked for me. For the most part, it worked for our team, too. People were convinced that they were working on the right things, we became generally more efficient, and we were able to grow. There were still outliers, though. People who, no matter how gently we nudged, they were just not getting things done.

Every 6 months, at Paperless Post we go through an internal review process where peers write reviews of peers, managers, and themselves, and then managers have one-on-one meetings with the people they manage. For me, this is a lot of people. This round (which is taking place this week, which is most definitely why this topic is on my mind) I’m meeting with 18 people. It’s a lot of talking, and for me is very emotionally draining. At its core, It’s because I care a lot about these people that I’m responsible for, and want to see them succeed. I’m lucky in that most of these conversations are very easy. Every round though, there are at least a couple hard conversations.

What I’ve realized now, in dealing with these wonderful human beings, is that there is a clear limit to inception, and when as a wrangler, you’ve reached that limit, its important to be decisive. For me the challenge is being firm in what needs to happen next, but the options are clear: Either this person is in the wrong role and there is a better place for them inside the company; They are having difficulty working with people and need direct feedback that they need to try another approach; or sadly, theres not a place for them in the current company. This is hard for me, because I want to believe that good people can work on any problem, but in the end of the day, the company has a goal and a vision and if they can’t help achieve that in the current set up, then it’s best to be clear about that, and make the break.

The point of all this, is to treat people like people. People are so much more complicated then any other person can actually reason about, and teams of people just multiply the variables. Then work and projects and the pressure that comes along with that, just adds another huge set of factors. I’ve learned a ton being a manager the past couple of years. It’s still very challenging and there are new wonderful and crazy things every day. I get to see young developers grow into seasoned pros and feel like I had a part in it. I get to see them mentor someone else, and get to feel it doubly. And its because I’ve spent the time to know these people, to help them, to push them, that I get to really take any credit for their and this company’s success. In this world the only way to work with others is to know them, try not to assume anything, give them feedback, and figure out how you, as two special snowflakes can be a team.

Hey Paperless Family

There have been little bits of information floating around and I wanted to finally come out and announce my intentions in my own words. Over the next couple of months I am moving back to my birthplace and the home of Paperless Post, New York City.

To give some background to people who joined since I’ve been away, a little over two years ago, I moved all of my stuff and my cats to the San Francisco Bay Area so that my wife, Kat, could follow her dreams and get her MFA at Mills College. She has completed classes and is now working on her final thesis project (which will be on display in Oakland in February).

Over the past two and a half years I’ve travelled over 263,000 miles to be alternately with her and with you, my other family. Being a remote CTO has not been very easy, but I’ve really tried my best. Despite everyone’s effort to make the best of a hard situation, it more often than not felt like Cat Stevens’ “Cat’s Cradle” instead of Journey’s “Don’t Stop Believin”. Which is to say, I’ve felt more like an estranged parent watching my little dev team grow up without me than a small town boy going anywhere. I couldnt hold on to that feeling.

Which brings me to now. I want to see this company really, truly succeed. I know this company can. We are already succeeding in so many ways, and I am coming back with a mission to make this the best company in NYC. I know we can do it.

This trip brings me to the crossroads: from now on I will be spending more time in NYC than in SF, spending 9 of the next 12 weeks here, ultimately moving back for good in the begining of December.

I am looking forward to not missing any more beer o’ clocks, doing tons of movie nights, and more than anything participating actively and face to face in the daily goings-on of this team.

I can’t wait.

You can watch the full talk here:

There is no BEST

I think the thing that had bothered me the most was that people kept wanting to elect the ‘BEST’ framework, like that was a prize to be won. It just made so little sense to me. The concept of best is so silly in the development world. Not only do standards and best practices change constantly (much faster than frameworks can or do) but the idea that there is a single library or system that could satisfy the needs of a majority of projects is just absurd. Some apps are structured around pages, some around events; some are simple single page information holders, some are complex intertwined real-time emotion recorders. Any level of complexity in a framework is going to make it not useful for a majority of cases and any level of simplicity is going to make the framework not that helpful. The fact that someone would go into a project with the goal of using a specific framework seems so backwards.

Obviously, different applications/sites/businesses have different goals, but for 99% of them that goal has very little to do with the technology used, especially the technology chosen to power the client side.

Sammy lost

To the outside world, though, Sammy lost this war to be the best. The funny thing to me is that I was never trying to fight. Over and over again, people tried to pull me into the battle of “What’s better, Sammy or X?” and I refused to answer. Not only was trying to defend something that I wrote for myself and gave to the community as a gift, just straight exhausting, it was futile. Sammy isn't the best. It is good for a number of use cases and not very good at all for others. It’s an idea and a tool, not a religion, and definitely not a messiah. The smart people out there should look up and realize that niether is any other framework.

It’s fucking JavaScript

In the client side especially, the fact is that however complex your app is and how fully featured your framework is, you’re going to be writing JavaScript. JavaScript is a constrained and pretty crazy language running in a wacky ever changing environment. If you expect your framework to hold your hand through the battle field, you’re going to end up hitting a mine at some point and if you don’t understand or know how to write vanilla JavaScript, you will never escape.

I really, really love JavaScript (especially in the browser). It’s bizzare but it’s powerful. I created a framework to help me have a basic layer on which to build JavaScript applications, that fit the style of applications I wanted to and was building. Its goal was to help me ship interesting things faster, and it definitely succeeds in that. In all of those applications though, Sammy was maybe 5% of the final application. The rest - it was just fucking JavaScript.

Where to

Sammy.js quietly turned 3 years old in May of this year. It was a moment that passed without fanfare or celebrations. I reflected on what I’d accomplished since then, and though Sammy has changed a lot since the begining I know for a fact that the JS world has changed more around it. It will continue to change and whatever is hot now, will look like the stupidest idea ever very soon. Thats the nature of this crazy world we work in.

I’ve stepped back a lot from maintaining Sammy day to day and Frank Prößdorf aka endor has been doing a great job pushing the project forward.

Sammy is still here, and will still be here. Whether or not the actual code is still in use, the ideas live on in a ton of other projects and frameworks and that I can certainly be happy about.

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.

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.

Open source in itself is in some ways for other people. It’s one of the things that got me into OSS in the first place. Other people in this context means a community of people looking to solve a collection of problems. When you release an OSS project you’re gifting it to these other people and hopefully they’ll return the favor at some point by allowing you to be the other people side of this equation. That’s not always true or possible, though, and thats OK. It’s part of the OSS contract that its a community, and you should try, but aren’t required to always give back to the people and projects that help you.

A while ago, GitHub allowed an option on projects to allow for creating a pledgie per-project. The idea being that people could donate a couple bucks to a project and its creator so they could buy themselves a beer. Just a little way of saying thank you. I think it wasnt that succesfull, maybe because remote beer buying just isnt there yet. Or maybe because its a question of what you’re actually buying? I never did this on Sammy.js or any of my other projects because, really, I don’t need the $5 for beer (thats not to say I wont take a free beer if you want to meet up at a conference or meetup and buy me one ). I just didnt see the point. Save your money, I thought, I’m doing this for the community.

Heres the new idea – I will take your money. In fact, I really, really want to take your money. Not for me. For other people. I’m starting a rotating Code for Other People fund. Every time we hit $500, well donate the money and rotate to a new charity. I’m very open to suggestions on that front as well. For example the first charity is the Anita Borg Organization. I’ve worked with them before, and they are consistently doing awesome things for women and diversity in the tech community. Other charities on the horizon are DonorsChoose and the Gary Greenberg Fund.

If you have an open source project, consider linking to this fund or promoting it on your blog or site. Your work on Open Source can not only help people in the OSS community, but help raise money for causes that need and appreciate it.

If you’re a developer or a user of other people’s code, consider donating some of your (probably healthy) paycheck – even a single dollar – to the fund. It shows your support for the different projects you use and also shows the communities commitment to the greater good.

I have $220 dollars of surplus from the recently awesome CodeFoodBar x JSConf Dinner. that I’m donating to kick off the fund.

Now when I release or work on an open source project, I’ll be working for something bigger – for other people.

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.

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.