Programming Posts

Pattern Vision Redux

A couple years ago I read an article DHH had posted to 37Signals’ “Signal vs. Noise” blog called Pattern Vision. I love that article not because it is at all profound. It isn’t. Kind of the opposite. I love it because I could have written it. The ways of thinking described in it are overwhelmingly common in the work I come across and live with day to day. Every new codebase I encounter seems to carry some new dubiously-applied patterns, some new collection of less-than-idiomatic directories, modules and classes for me to discover nested within “/app”.

In Praise of the Humble Website

The other day I had an informal talk with a friend about a project we had been offered. I can’t divulge much about the project but I can say that it has, structurally, a lot in common with an ecommerce app. Users shop a class of product and check out. Work has already been done on this app. The “MVP” that has been built has a wholly decoupled “thick client” browser-based UI built in AngularJS. I have a decent amount of experience with AngularJS as well as the other, similarly popular (possibly moreso) javascript MVC framework Ember.js.

I have seen a trend firsthand in the last several projects I have been offered – and a couple that I have taken on – toward the use of these javascript frameworks and decoupled, thick client architectures. Stunningly, in every one of these cases, the architecture is unambiguously more burden than benefit (much more, in fact) in respect of both development load and user experience.

Russian Doll Caching in Rails 4

Russian Doll Caching in Rails 4

Rails 4 nudges developers toward more pervasive use of fragment caching (and the so-called “russian doll caching” strategy of deeply nesting fragment caches) with the introduction of ActionView::Digestor and on-by-default appending of template digests to fragment cache keys. Though actually pretty simple in its implementation, this feature (paired with correct use of ActiveRecord’s “touch” relation option) solves most of the formerly enormous headaches you’d encounter (and still do today with pretty much every other framework) trying to implement an advanced caching strategy with largely dynamic content. I’ve been working with this technique for more than half a year now (initially using the Rails 3 “cache_digests” gem , which implemented the same functionality now available through ActionView::Digestor in Rails 4).

Back to The Future: Encrypt Emails the Old Fashioned Way – With PGP!

Back to The Future: Encrypt Emails the Old Fashioned Way – With PGP!

Since we now know that we can’t reasonably expect the emails we exchange with friends and colleagues to not be warehoused and read without our knowledge (and without a subpoena, warrant, or similar from the reading party), I want to shine a spotlight on one of the still-effective techniques available for restoring some privacy (with caveats) to personal email. This strategy is not new. In fact, it’s quite old. I’m talking about GnuGP(GPG), a FOSS implementation of the OpenPGP encryption standard, and GPGMail, an awesome plugin for the native Mac Mail client.

First Impressions of Digital Ocean

First Impressions of Digital Ocean

Digital Ocean is a relatively young VPS provider with servers in New York, the Netherlands and San Francisco. My first introduction to them was working on a web app called RapPad which helps people write and share rap lyrics and which I started contributing to a few months ago after it caught my eye on Hacker News.

RapPad’s owner, Amir, had it up on a VPS with Digital Ocean, which I was only vaguely aware of. I was pretty blown away with the slickness of our deploys (typical Rails deployment bottlenecks like asset compilation were carried out with literally 4x the speed of on my EC2 instance) and the speed with which I could traverse the file system, install packages and do various administrative tasks.