Category Archives: Projects

Introducing Juniper: The Annotated Web App

Web apps don’t have to suck. Here’s proof. And here’s the annotated source.

Q Branch’s Vesper is a beautiful, simple, functional note-taking app, with design and attention to detail like I want every app to have. So, obviously, I decided to port it to SproutCore.

Two reasons. First, I wanted to combat the widespread notion that web apps are fundamentally crappy. There are loads of terrible ones, but they’re not bad because JavaScript is (undeniably) slow: most apps don’t need the full computational power of a C-level language. With the right toolkit, web apps can hold their own against most native apps, even and especially those like Vesper whose power is in beautiful design and sterling execution. Bad web apps are bad because they were built badly, with the wrong toolkits. SproutCore is the right toolkit.

Similarly, I wanted to show how great an experience developing with SproutCore can be. The learning curve is definitely steep – it’s a completely different way to write code than that jQuery plugin you put on GitHub. But that jQuery plugin you put on GitHub isn’t a native-caliber application, so that’s a good thing, and once you’re up the curve, SproutCore is tremendously enabling: I built this from sc-init to a fully armed and operational note-taking app in fewer than a hundred hours.

It’s not feature-complete – no image attachments, no dedicated large-screen interface, and of course no back end or sync. But the transitions are smooth and the data persists. It feels like a world-class app and it works like a world-class app, but it’s in your browser.

Second reason. There’s a complete lack of any really complete, open SproutCore codebases. Developers learn best reading code next to running code, to poke at one and dig into the other, but until now there hasn’t been any place to do that.

With this project, I’ve opened the source and written a companion guide, available in the GitHub repo’s README. If you’re learning, or thinking you might want to learn, then fire up the app and dive into the guide. It’s not a flawless codebase – see the above note about a hundred hours – but it embodies a lot of the best practices I’ve picked up over the years. I’ll also highlight some specific features in upcoming posts.

So check out Juniper here; the heavily-annotated source is here. Poke around, and if you want to see how it’s done, now you can dig deeper. If you have any questions or run into any issues, well, there you go.

If you like Juniper and want to try the real thing, just mix in some vodka and Lillet Blanc, head over to the App Store, and try Vesper. Tell ’em the web sent you.

The World’s Heaviest Business Card

Four and a half thousand lines of code. Three tangential open-sourced repos. A spaghetti mess of oversized and underdeveloped ideas. And one sexy, modern, interactive business card. TL;DR: it’s at the bottom.

The consultant’s life has a lot to recommend it, but it comes at the cost of stability. Over the winter of 2012-13, I had my first serious drought: for three months, nobody called. It turned out to be the natural ebb and flow, and when work returned in February it returned with a vengeance. But for the darkest months of the year I had nothing to do, and no established coping mechanisms to fall back on. So I fell into node.

The stated goal was a personal website, including standard fare: an About Me section, a blog, some other things. This was in the days before Ghost though, and anyway I was in it to learn, so I bullheadedly started from scratch. I learned the ins and outs of not only node, but mid-decadal CSS3, and web development outside of the rigid strictures of SproutCore, and every social networking API I could get my hands on. (I also taught my dog to follow her leash the right way around trees and signposts, which stands as my proudest accomplishment in life.)

It turns out that, absent rigid strictures, I invent my own, and the project soon swelled to an untenable scale: Before I knew it, each page was a dynamic web app, loaded and launched lazily, aggressively optimized with cacheable parts and preloaded data, full of realtime coordination between the client and the server, and with hooks that suggested the dashed-off, unstable outlines of a platform.

Then February hit, and clients materialized, and 80-hour weeks became normal. The website, half-built, overweight and very much between stable builds, faded.

This winter’s slowdown was less drastic than last, but it did happen. I put some effort into a project (stay tuned) which justified the creation of an honest-to-functional personal website – WordPress this time, like a normal person. I showed the previous winter’s Ozymandian wreckage to a friend over beers, and he suggested wisely that the About section – essentially complete, though ragged and out of date – might be worth salvaging as a standalone widget, embeddable and linkable.

So with the wife out of town and the dog asleep after a long day of tensely staring at squirrels, I set about hiding the unnecessary elements, all of the tentacles of scope blowout, leaving just a modern, interactive business card.

Here it is! (It’s real, you can click on it.)

(If you’re on an iPad, standard weirdnesses with scrolling in iframes apply. For example, if I tap and drag sideways, it scrolls up and down, and why do we even have rules, and Daisy Daisy give me your answer do.)

Here it is. (You can view an embedded version on a larger screen.)

Maybe only a couple thousand lines of code in evidence, but I’m pretty happy with how it came out, all embeddable and linkable and things. Even if there’s no formalized control flow to speak of, even if I only managed a half-baked twitter card (twitter card is now fully-baked!), even if I ran out of steam on the LinkedIn card and just slapped in a base prefab embed.

Along with formalizing and publishing any smaller standalone spinoffs, the plan was always to open the source, because why not, and because I write better code when I think I’m being watched. So, for your amusement, it’s up – minus API keys, and minus Mongo, into whom I got around to transitioning the bare minimum of content – on GitHub. A few things might even be generalizable: once properly scalpelled out, the Ken Burns card should respond to any Instagram API key… the GitHub card will display information for any user and any set of public repos, that is once you get the prerequisites installed, and track down the private environmental variables, and decode the mongoose schema… and… um… look upon my works!….