&yet

Our filmmaker friend Melani Brown made a cool short film about our month-long adventure working from a castle in Italy.

In case you missed it, here’s the original blog post.

You have a dream.

So, just like every single one of us, you ask, “Do I have what it takes?”

The answer is yes. Every other answer is a lie, an excuse or a distraction. The call itself is enough of an answer.

I consider myself good at a few things, passable at many, and passionate about more. What I’m capable of is completely irrelevant. I’m likely the worst to judge that anyway.

Template languages: a densely populated land, where not even angels fear to tread.

Let's rush right in.

Mail merge for web developers.

A template language is mail merge for web developers.

At &yet, we're always fighting to get ourselves to log hours. We recently came up with a method inspired by Fitt's Law that's proven quite effective.

Fitt's Law, as it applies to interface design, essentially says the smaller and further away a target is, the harder it is to hit.

That's why we get Apple positioning the OS X menu at the very top of our workspace and the Dock at the bottom. The edge of the screen can be said to have infinite width in the direction the mouse hits it, making it an easy target.

I've been playing a lot with advanced pseudo-classes and pseudo-elements for a project Aaron and I have been working on.

Originally, I was just going to share it as a blog post, but instead, Aaron and I hacked together as a generator you can use to make a purely CSS3 progress bar, like this:

Here's how we did it.

As application developers, we persist data in tables which are constantly updated, leaving most of the application’s components and user-interface in the dark until it asks for the data.

[Movie trailer voice] Imagine a world where these tables push change-events to any piece of your application stack, in diverse languages and on multiple servers.[/Movie trailer voice]

Enter Thoonk.

Clustering Node.js instances, communicating between service components in different languages and on different machines, forking off asynchronous jobs for reliability and queuing of work, communicating between APIs and views, and sending events to real-time webapps are all problems that can be solved with messaging.

In support of an upcoming &yet product (ssssssh!), I was asked to create a JavaScript wrapper around a REST-based API we're using from node.js.

If you've been there, you might know how it goes: guess which API features the current project actually needs, make up some sort of "native" object representation, implement some bridge code that kinda works, and as a finishing touch, slap a link to the service's real documentation atop the code you left stubbed out for later.

Or, you find someone else's wrapper library. They took the time to implement most features, and even wrote their own version of the documentation — but the project they needed it for was cancelled years ago, so their native library still wraps the previous version of the server API, without the new features you need.

FACTS

The Four-Hour Workweek irked me before I decided to read it and blew my mind once I chose to.

Not only that, I blame that book for the fact that our company and our families are now days from packing up our office and moving to Europe for a month to work from a castle on Italy's Adriatic coast.

Seriously.

Quick intro, the hype and awesomeness that is Node

Node.js is pretty freakin' awesome, yes. But it's also been hyped up more than an Apple gadget. As pointed out by Eric Florenzano on his blog a LOT of the original excitement of server-side JS was due to the ability to share code between client and server. However, instead, the first thing everybody did is start porting all the existing tools and frameworks to node. Faster and better, perhaps, but it's still largely the same 'ol thing. Where's the paradigm shift? Where's the code reuse?!

Basically, Node.js runs V8, the same JS engine as Chrome, and as such, it has fairly decent ECMA Script 5 support. Some of the stuff in "5" is super handy, such as all the iterator stuff forEach, map, etc. But – and it's a big "but" indeed – if you use those methods you're no longer able to use ANY of your code in older browsers, (read "IE").

So, that is what makes underscore.js so magical. It gives you simple JS fallbacks for non-supported ECMA Script 5 stuff. Which means, that if you use it in node (or a modern browser), it will still use the faster native stuff, if available, but if you use it in a browser that doesn't support that stuff your code will still work. Code REUSE FTW!

If you'd asked most developers 5 years ago, most of them would have said: "Why would anyone want to write JS on the server?!" The luddites still do.

But we, at &yet, have fallen in love with node. Our particular schtick is the real-time web (see our podcast). We've been building real-time web apps for a while, mostly with XMPP and Strophe.js. Recently, however we've started using node + socket.io.

Frankly, we couldn't be happier and can't wait to see what the future holds as these technologies continue to mature.