Four odes to Amazon Prime

Cat in a box

I have a somewhat irrational “thing” for Amazon Prime. So much so that I’m a little surprised that I have such an affinity for what is in some ways simply the act of prepaying for shipping. But that’s understating what Amazon Prime is.

Prime is a fine example of physical computing. I click a button on my computer. Electrons fly all over the place. Database records are created, messages are sent. Pedestrian. But at some point a TV comes off a shelf and is loaded on a truck. Less than forty-eight hours later, it appears on my porch. Maybe not as nifty as an Arduino robot that mixes drinks, but just as physical and slightly more practical.

Prime is what Amazon should have patented (if they could have waited). “Method for buying something with one click” isn’t so impressive sounding. “Method for integrating e-commerce, logistics, and shipping systems so that things magically appear at my house at my whimsy”, now that’s a good title for a patent.

Amazon Prime has a transformative effect on how I consume. There are all sorts of things that I just kind of languish without because I never remember to buy them when I’m at the right store. If it’s not food, I buy it on Amazon now.

Today I decided I should buy more undershirts. Five minutes later, they’re on their way to my house. Because I’m paying a fixed rate for shipping every year, I don’t worry about batching up my shopping. I just go buy things when I realize I need them. Potentially costly, yes. But now I’ll have a proper supply of undershirts.

Prime, coupled with Amazon’s recommendations, is eerily effective. Years and years ago, when I started using Amazon, the first thing I added to my wish list was first three seasons of Bosom Buddies on VHS (yes, that long ago). Amazon promptly recommend I look into other movies feature men dressed as women (good call, I find this amusing) and serious movies with Tom Hanks (not as amusing).
Fast forward ten years, and Amazon gives me humorous, but much more useful, recommendations. I bought three things I’d been meaning to pick up but had forgotten about due to recommendations. I’m a little surprised the streak ended at three. I’m sure there are legions lazy people like myself improving those recommendations right this moment.

Prime makes all sorts of transactions much more fluid for me. I spend less time in shopping centers and have a pretty great choice of products; in exchange, money departs my bank account more fluidly. When economists talk of the incredible complexity of markets, free market acolytes proclaim that truly free markets can route around inefficiences, and globalizationists trumpet the benefits of low-friction trade, they’re talking about Amazon Prime. It’s a service that could only exist in our current age of networks, connectedness, and impatience.

Groove failure and reacquisition

Into every creator’s life, a few non-creative events must fall. Sometimes its meetings, maybe it’s a bunch of business-related emails, or a bunch of support tasks have piled up and it comes time to empty the queue. Whatever the cause, the result is often the same: my day is robbed of chunks of time that are sufficient for tackling the code I wanted to work on. Total Groove Failure.

Going with the assumption that eliminating Total Groove Failure and its causes is impractical, I’m left with the question of how to recover from these sorts of days. I asked about this the other day. I got two sorts of responses.

On the one hand, you can withdraw. Get away from the computer, maybe get some sleep or enjoy an adult beverage. One the other hand, you can take action. Get outside, go for a walk or exercise. Maybe work on a side project. Start some code and leave it for the next morning to finish. These are some of my Groove Reacquisition Tools.

Discovering a new Groove Reacquisition Tool is a wonderful thing. None of them are silver bullets, but each one is little slice of confidence that, even if I get derailed, I can get back on the productivity train.

Whether through action or inaction, it’s important to get away from the computer and/or that which sliced your day into fragments. From there, I’ve often found it helpful to consider what it is that’s stealing my focus and react appropriately. Some days I know that diving into some open source work will do the trick. Others, I need a nap, to exercise, or to wrap myself in a book.

The crucial bit is to realize I’ve lost my groove. Not every interruption leads to Total Groove Failure. There are days where I respond to a few emails in the morning and quickly get into my coding happy place. But if I find myself frustrated at every turn, I resort to one of my Groove Reacquisition Tools.

A language experiment writ large

A wall painted with squares

For the past year, the Java ecosystem has seen interesting evolution. Java the language continues take its place as the new safety scissors of programming, but the pieces around it are getting better. The JVM is now acknowledged inside and outside of the Java community as really good stuff. Really interesting software like Hadoop and Cassandra are built on top of Java. Integration with languages like Ruby and Python is getting pretty good.

What’s most interesting to me is that there’s a competition going on for the hearts and minds of those developers who don’t like using safety scissors. This competition is a great experiment into what developers really want in a programming language. For a language nerd such as myself, observing this experiment is a lot of fun.

On one side you’ve got Scala. Scala looks a lot like Java. But on top of that it adds shorthands and pleasantries from Ruby, a really good type system reminiscent of Haskell, and other handy functional features. When you build up a hybrid language like this you, two things happen. First, a lot of people who look at their checklist, find everything they need and decide. Second, you get a pretty complex language.

Clojure, however, looks nothing like Java. It’s a Lisp, it simply can’t. Clojure borrows from Haskell too, this time borrowing ideas about state and how to avoid it and concurrency (notably software transactional memory). Clojure is a funny looking language at first, but there are some great ideas within it. Plus, it’s a relatively small language; it’s just that it’s a different kind of simple and almost every concept is new to many developers.

Both these languages are building up strong communities. Both are full of great people with energy and ideas. It’s quite possible that a winner-take-all situation won’t occur. I’d like that.

What’s most interesting to me is to see how people take to the languages. Will they go for the familiarity of Scala and deal with the complexity? Will they learn the simplicities of Clojure and rewire their brains? Will they prove the common wisdom wrong and learn both?

I’m watching with great interest.

Bundler, not as bad as they say

Of all the new moving parts in Rails 3, the one I see the most grousing over is Bundler. This is not surprising, as its a big part of how your application works and it’s right up front in the process of porting or building Rails 3 apps.Bundler: As Simple as What You Did Before:

Bundler has a lot of advanced features, and it’s definitely possible to model fairly complex workflows. However, we designed the simple case to be extremely simple, and to usually be even less work than what you did before. The problem often comes when trying to handle a slightly off-the-path problem, and using a much more complex solution than you need to. This can make everything much more complicated than it needs to be.

I haven’t run into anything with Bundler that I couldn’t solve with a little critical thinking and maybe a little searching. On the other hand, Bundler has made getting dependencies straight amongst team members and deploying them to production servers far easier than it was before. I’m very glad that while it’s not strictly part of the scope of Rails, that Bundler is now part of it.

An ode to Hashie

I was building an API wrapper this weekend. As is common when writing these sorts of things, I found myself needing something that takes semi-structured data (hashes parsed from JSON) and yields Ruby objects that are easy to work with. I’ve always found myself hacking these sorts of things together on a somewhat ad-hoc basis. It’s a fun, but a bit of a yak-shave.

This time around, I decided to see if the state of the art has advanced in this realm. Luckily, I reviewed Wynn Netherland’s slides from Lone Star Ruby Conference and found exactly what I needed.

Where have you been all my life?

Intridea’s Hashie is a library built on the notion of making hash-like data structures act a little more like objects and a little easier to work with. I have literally wanted something like this for years!

Suppose you have a hash like the following:

hash = {
  "name" => "Adam",
  "age" => 31,
  "url" => ""

Coding up an object to store that isn’t too hard, but writing the code that pulls values out of the Hash and tucks them away in the right attribute on the object gets tedious quickly. Hashie’s Dash class makes this trivial.

class User >Hashie::Dashie
  property :name
  property :age
  property :url

Its even more delightful to use:

user = # => "Adam"

Tons of boilerplate code, eliminated. My life is instantly better.

A great use of inheritance

It’s been pointed out that ActiveRecord’s use of inheritance is somewhat specious. To argue that “user is-a ActiveRecord::Base” takes a bit of hand-waving. So lately, you’ll find lots of libraries insinuate themselves into classes as a mixin, rather than as a parent class. This is a little bit of you-say-potato-I-say-potato, but whatever.

In Hashie’s case, I think that inheritance is being used correctly. All of the classes that Hashie provides (Mash, Dash, Trash and Clash) inherit from Hash. So the is-a relationship holds.

Sugary data structures taste great

While I’m going on about inheritance, here’s how I used to create these sorts of wrapper classes:

User =, :age, :url)

For creating simple objects that just need to hold onto some data, I really like this approach. If they end up needing data, it can easily grow up:

class User <, :age, :url)
  # Behavior goes here

I like what Hashie is doing even more though. Its enhancing a core class in a largely unobtrusive way, and doing so from the confines of a library that only those who need it can pull from.

I’d love to see more libraries like this that add extra sass to Ruby core library. An Array that pages values out to disk on an LRU-basis perhaps, or a bloom-filter based Set, perhaps?

I’m excited about languages like Erlang, Haskell, Scala, and Clojure and what they can bring to the adventurous developer. Despite that, I feel strongly that Ruby still has plenty of really nifty tricks up its sleeve.

Examining software principles

There are too many good things to say about the Design Principles
Behind Smalltalk
. A few of my favorites:

Scope: The design of a language for using computers must deal with internal
models, external media, and the interaction between these in both
the human and the computer.

This one is really obvious until you get to the last four words. The
human and the computer. Luckily we’re starting to take for granted
the primacy of human communication in programming lately (mostly), but
when Smalltalk was created, I’m sure its designers received no
shortage of grief when they steered towards humane optimizations.

Uniform metaphor: A language should be designed around a powerful
metaphor that can be uniformly applied in all areas.

Smalltalk is largely objects and messages. Lisp is largely lists and
functions. Erlang is largely pattern matching, functions, and
actors. These aren’t perfect languages, but once you deeply
understand, really grasp the core concepts, you have the whole
language at your command.

Operating System: An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.

The first sentence is a great principle when considering what should
go in the core of a system and what should go in the surrounding
ecosystem of libraries. The second sentence is wonderfully bold, in
that it cuts against what nearly every successful system has done
since Smalltalk was prominent and in that it contradicts the first
sentence. I’m not sure what practical use to make of this principle;
its density of intrigue is that keeps me coming back to it.

Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones.

I stopped worrying about what might supplant Ruby a long time
ago. Someday, it will happen. And when it does, whatever succeeds Ruby
will have to be really awesome to fill its shoes. I’m looking
forward to seeing what that is. But the same goes for any technology;
they are often replaced with something wholly awesomer than the

I’ve never done it, but it seems like it would be intriguing and
vastly informative to sit down with one of the systems I work on daily
and try to extract these principles post-hoc. What values and
principles are embedded in the system? What does that say about the
team and why the system is the way it is? What principles are enablers
and what bad habits should the team work to correct?

Making the complicated seem simple

Don Norman, Simplicity Is Not the Answer:

We want devices that do a lot, but that do not confuse, do not lead to frustration. Ahah! This is not about simplicity: it is about frustration. The entire debate is being framed incorrectly. Features is not the same as capability. Simplicity is not the same as usability. Simplicity is not the answer.

Norman goes on to explain how you can take a confusing mass of features and turn it into something less frustrating:

  • Modularize into understandable clusters
  • Map clearly from actions to results
  • Model the ideas and actions cohesively

The article is about interaction design, but it fits just as well in designing programming languages and software.