So 2012 is here, and I’ve run out of excuses to be terrible at cooking. So I purchased a book or two (the how to cook everything iPad app, and I’m looking at Cooking for Geeks) and went to town in the spices/baking aisles at Stop & Shop. Well, tonight, I made my first dinner, and it didn’t turn out quite as well as I would have liked. This is probably not what omelettes are supposed to look like. Good news is, there’s nowhere to go but up.

If you’d like to get together and cook with me sometime, let me know, as cooking is a lot more fun as a social thing, and I won’t have to eat all of my mistakes by myself.

I got into Rails in the late summer of 2006. It was a pretty wild ride: Rails 2.0 was still over a year away, Github didn’t exist, we were installing plugins (not gems) by finding them on technoweenie’s SVN repository, and best practices/libraries hadn’t really congealed yet. Everybody was more or less making their own way. This was somewhat restrictive, in the sense that we didn’t have the same communication tools, documentation resources, and software libraries we have today; but also extremely productive, as it forced the community to come up with creative solutions that would build on top of each other and create a best of breed. This is standard in any evolutionary process, and Node.js proves to be no exception.

Node.js is in a similar state at the moment, where best practices, documentation resources, and best-of-breed software libraries are still congealing, and at an extremely rapid pace. The community has plenty of really creative and intelligent thinkers who are writing some great code. The Node.js revolution may have a leg or two up on the Rails revolution, however. For one, it can draw upon the wide array of JavaScript programmers who have a decade or more of experience. For another, I think the Node community has been able to learn from the Rails community (of which there will surely be some overlap) about coding practices, deployment practices, and what it means to develop for a niche web platform.

I’ve been playing with my own Node.js app for a few days, and I’ve learned a few things. Number 1, everything you heard about code reuse between the server and the client is true. Using browserify, I was able to expose some server-side CoffeeScript as client-side JavaScript without having to have to do too much. Very cool. Number 2, library development is going quickly, and a lot of it is being sponsored. Whereas Rails was presented as a full stack and Rack only came after other Ruby frameworks started to pop up, Node.js is pretty low-level, and is being added to from the ground up. Sencha Labs (perhaps best known for Sencha Touch) sponsored Tim Caswell and TJ Holowaychuk to create the connect middleware, and Holowaychuk is taking this further with Express, which is Node’s equivalent of Sinatra. LearnBoost has sponsored Guillermo Rauch to create Socket.io socket transport layer, on top of which DNode and Juggernaut can build RPC and pubsub libraries. (Even these libraries, as well as Express, have formed as a base for other libraries to be built on top.)

Just as Rails was to me 5 years ago, Node.js is providing an exciting landscape.### but what am I doing with Node? Well, I’m glad you asked. A friend of mine once taught me this Chess variation called Kriegspiel, where you can see your pieces but not those of your opponent’s. Through trial and error, you have to build an understanding of where your opponent’s pieces are, while they’re trying to do the same regarding your pieces. It’s a very challenging game, and I thought it’d be a great experiment for Node’s asynchronous nature. Also, my friend has been living overseas for the past few years, so it’s probably the only way we’d actually be able to play again. Enter Kriegspiel.js.

There are a few problems with the game right now… for one, you actually see both white and black pieces, and for another, it doesn’t actually work. But most of the pieces behave properly, and most of the captures work appropriately. Check, mate, en passant, and castling rules haven’t been implemented yet. But it’s coming along. And maybe one day you’ll be playing a game. Go ahead and try it out.

I’m starting to be swayed by JavaScript as a language I should start using more often… we’ll see where this takes me.

In a recent HTML5 class, I got to play around with some cool new technologies, including canvas, geolocation, html5 forms/markup, and others. Here’s one little thing I created.

RecordPlayStop/Rewind

It uses processing.js to do the actual canvas drawing, local storage to manage the recording/playback, the new ‘number’ HTML5 input type, and some jQuery/math to glue it all together.

You can use the input to increase/decrease the number of bars attached to the cross, and you can use the mousewheel to make it grow or shrink.

In the beginning, dhh taught us how to build a blog in 15 minutes. A few years ago, I was frustrated with the current toolset for creating a blog in Ruby on Rails, and so I decided to build a pluggable blogging system. That’s when I ran into some Rails 2 monkey-patching issues and never got off the ground. Rails 3, however, allows me to do some seriously cool stuff, and I’ve retooled my previous effort to create Governor. Named after everybody’s favorite governor, Rod Blagojevich.

Governor by itself is very bare: all it lets you do is post articles. Where it starts to get cool is when you start adding plugins. At the moment, there are 9 plugins to choose from, giving you the ability to add an ATOM feed, comments, tags, draft/published states, or even announce your article to twitter, as you post it. (That twitter plugin is built on top of a middle-tier governor_background plugin, which sends your post to twitter outside of your regular request cycle. It can sit on top of either delayed_job or resque.)

Governor will work with most authentication frameworks out of the box, including Devise, Authlogic, and Clearance. If you have different needs, just call rails generate governor:configure, and you can redefine how authentication and authorization will work for your app.

This is my first foray into framework development, so I’m learning a lot. (If you see any issues or anti-patterns, please let me know!) There are a few plugins and features I’d like to implement in the future: better URLs for articles, a better system for blog administration, better asset management, better forms markup, better i18n support, and testing add-ons that can be reused across plugins. But one of the nice things about a pluggable open-source is that, if this is a pain point for someone else, they can extend it. If you end up using this or building on top of this, or if you run up against an issue or would like a feature, please let me know.

governor on github