Driven to drawing monsters

From my notebook:

Monster
I don't recall what I was working on the time, but it seems that the interaction between many Gowalla models loading from cache via a get class method and something about memcached was causing enough trouble to drive me to draw a little monster.

Clips from unfinished pieces

On the crux of America's challenges:

Part of the American experiment is answering the question, "how can we best take advantage of abundance?" Beginning with manifest destiny and evident in the machinations of Wall Street, one of the story lines of America is the quest to make sure resources of all kind are abundant and generating wealth. But we're arguably at a pivot point. Our money and energy don't go as far as they used to.

How do we make the transition from resource abundance to resource scarcity?

On helping people troubleshoot the Gowalla API:

While this level of self-documentation is quite helpful, sometimes people have questions on the developer list. For this, I've found that asking people to show me whatever it is they're trying to do using curl is invaluable. It's a win-win situation. Often, dropping down to a lower-level tool like curl helps to focus your thinking and makes silly error obvious. If it doesn't become obvious to the API developer, they mail the list with the command they think should work. At that point its either obvious to me and I tell them what to change, or I have a nice, isolated test case from which I can easily try to reproduce their problem.

Who gets screwed when a borrower declares bankrupcty?

Is it possible that bankruptcy-declaring-borrowers are screwing lenders in aggregate? I find it really hard to believe that the banking industry, with its legion of lobbyists and regulatory capture, that any group of uncoordinated individuals could screw the banks.

On the other hand, there was lots of screwing on the part of the banks that led to the financial crisis. Whether it was predatory lending, relying on moral hazard to double down on terrible bets, or asinine compensation structures, the financial industry did something very human. They violated social norms. Except, corporations of this size don't have social norms. They have only market incentives; when the executives, board members, and majority shareholders look at the books, the numbers devoted to "doing the right thing" are probably a rounding error.

On tail recursion and compilers:

Fact of life: modern processors don't execute your code in the order the compiler spits it out.

If your code has, for instance, two adds followed by an if statement, it's pretty likely that second add is going to be executed concurrently or after the conditional. In the world of computer architecture, they call this out-of-order execution, and it's just another service your hard working processor offers to make sure your code runs faster than you ever intended it to.

On shorter cycles of production and the need to get past perfectionism:

Our modes of production are causing us to change how we produce. More and more mediums, be it journalism or software, are produced on shorter timelines. This is leading us to optimize production such that we can bang the content or code that matters into templates that mostly work, but have a tolerance for the rough edges where things don't work.

On Barack Obama's 2010 State of the Union speech that preceeded the health care debate:

Just for grins, I went and read the GOP response to the State of the Union. While they had some vague counterpoints policy-wise, it read mostly as subtle and useless jabs combined with carefully-constructed language to console their base. The GOP is a cynical, gutless organization.

On refactoring and deleting code:

People often say that they would miss having a refactoring browser in languages like Ruby, JavaScript, or anything that is reasonably dynamic. My glib response to this sort of comment is invariably "well, the best refactoring I know is to select the code to modify, hit delete, and start over." Let's take that apart.

I've observed that, despite our best intentions, we are often loathe to change code that we suspect is working, or that we suspect we don't know why it's there. And so, like the planet on which we live, applications accrete into Katamari balls of overly-coupled code that is bound only by locality. Cutting this Gordian knot is often the first step in reclaiming a project.

Deleting code is the knife with which we can attack this problem. Many will acknowledge the goodness of deleting code; it is, quite nearly, a virtue unto itself. I've observed that some of the best developers I know are always on the lookout for ways they can obviate code. So, by way of a strawman, I hope you see that I'm quite correct in this regard.

Focus, momentum, and accomplishment

Lately, I’m a little fascinated by the interplay between focus, momentum, and accomplishment. Focus is the feeling of flow, the world around you fading away. Momentum is the feeling that you’re moving things along, getting stuff done. Accomplishment is stepping back, looking at what you’ve done, and feeling like you did something good. These factors play out differently in the three activities to which I decide much of my time.

When I’m building software, I’ve found that momentum leads to focus, accomplishments yield momentum, but focus does not necessarily yield accomplishments. Yet, the most exciting moments seem to come when I’m focused and building momentum. Those times when my attention is fragmented but I’m working through a list of stuff that needs to get done doesn’t feel like accomplishment, but it does seem to get the job done.

Anecodotally, it seems that, by definition, Monday is the day of the week that lacks focus but still possesses some form of accomplishment. It’s the sacrificial lamb of the work week.

When I’m reading, writing, and organizing information, I’ve found that momentum is not much of a factor. It’s all about focus. Stick my head into a cluster of ideas, focus on what I’m reading, how I’m thinking about it, or how I’m writing it back out. Keep the problem state in my head, admitting as few distractions as possible. Come up for air periodically, review my progress, and decide to either continue or move on to other things.

Of these three activities, I’ve found that I’m most methodical about how I use momentum when I’m thinking. It’s sort of a rate limiter; after I’ve read something particularly dense, I’ll immediately do something banal like catch up on social medias. Not sure if this tendency is enhancing or diminishing my thinking.

I spend several hours a week training. The coffee shop (thinking) and the gym (training) are my third place(s). Recently, it feels like I’ve leveled up. I had a few consecutive workouts where I was more focused than I’ve ever been whilst exercising; no worries about my breathing, or if I was pushing myself too little or too much. From this focus I found momentum. A couple minutes on the treadmill would turn into tens of minutes, then a half hour. One set of strength exercises would blend into the next. I was able to push myself to higher levels of accomplishments. It felt awesome.

Interestingly enough, I’ve found that I need a day off from each of these activities. As awesome as it sounds to have the kind of intensity that lets one make awesome things every day of the week, I’ve found it necessary to relax and take time away from coding, thinking, and training. As it turns out relaxation is an important part of a balanced diet of focus, momentum, and accomplishment.

A conversation between fictional engineers in a fictional world

A hypothetical conversation that may have occurred between two non-existent engineers working on the second Death Star in the completely fictional Star Wars universe.

Engineer #1: Hey Bob, I was perusing the blueprints for this “Second Deathstar” this morning. Pretty impressive stuff.

Engineer #2: Thanks Hank. I’m pretty proud of it.

Engineer #1: And you should be! Had one question though. There was something in the request-for-proposals that mentioned some flaw in the previous one where a snub fighter could drop a torpedo through a vent and blow the whole thing up, yeah?

Engineer #2: Yep! Don’t you feel bad for the poor schmuck who made that decision?

Engineer #1: Haha, that’s a good one Bob. So you fixed that right?

Engineer #2: Oh, definitely. All the exhaust ports are small enough the only thing falling in there is a grain of sand.

Engineer #1: Nice thinking! So, my real question is, what’s this giant opening you can fly a large freighter through? And why does it lead right to the station’s giant fusion reactor that sits in a room big enough to fly in circles in said large freighter?

Engineer #2: Oh, that? Well, the passage from that room to the surface is where I’m going to run all the pipes and wiring that I forget about until the last second. I figure once I’m done patching everything together, no pilot would be able to fly through there, even in a snub fighter.

Engineer #1: And the giant room?

Engineer #2: Oh, you know clients. Always deciding they want something really impressive at the last minute. I figured I’d just leave a little extra room in case they come up with something at the last minute.

Engineer #1: Haha, right again Bob. Clients are such idiots.

Simple Ruby pleasures

I think I first discovered the joy of take and drop in my journeys through Haskell. But it appears that, since 2008 at least, we have had the pleasure of using them in Ruby too.

Need the first or last N elements from an Enumerable. Easy!

[sourcecode language=“ruby” light=“true”] ary = (1..100).to_a ary.take(5) # => [1, 2, 3, 4, 5] ary.drop(95) # => [96, 97, 98, 99, 100]

range = (1..100) range.take(5) # => [1, 2, 3, 4, 5] range.drop(95) # => [96, 97, 98, 99, 100]

hsh = {:foo => 1, :bar => 2, :baz => 3} hsh.take(1) # => [[:bar, 2]] hsh.drop(2) # => [[:foo, 1]] [/sourcecode]

The real magic is when you use take along with other Enumerable goodies like select and map. Here’s one of my personal favorites amongst the code I wrote in 2010:

[sourcecode language=“ruby” light=“true” highlight=“12,13,14”] class QueryTracer < ActiveSupport::LogSubscriber

ACCEPT = %r{^(app|config|lib)}.freeze FRAMES = 5 THRESHOLD = 300 # In ms

def sql(event) return unless event.duration > THRESHOLD callers = Rails. backtrace_cleaner. clean(caller). select { |f| f =~ ACCEPT }. take(FRAMES). map { |f| f.split(":").take(2).join(":") }. join(" | ")

# Shamelessly stolen from ActiveRecord::LogSubscriber
warning = color(&quot;SLOW QUERY&quot;, RED, true)
name = '%s (%.1fms)' % [event.payload[:name], event.duration]
sql  = event.payload[:sql].squeeze(' ')

warn &quot;  #{warning}&quot;
warn &quot;    #{name} #{sql}&quot;
warn &quot;    Trace: #{callers}&quot;

end

end

QueryTracer.attach_to :active_record [/sourcecode]

This little ditty is awesome because:

  • It's super-practical. Drop this in your Rails 3 app, tail your production log, see the slow queries, go to the method in your app calling it, and fix it. Easy.
  • It only activates itself when it's needed. Queries that execute quickly return immediately.
  • No framework spelunking required. Rails 3's notification system handles all of it. Rails' backtace cleaner gizmo even makes the backtraces much nicer to read.
  • It chains methods to make something that reads like a nice, concise functional program.
For more Enumerable joy, read up on each_cons.

The political empathy gap

The structural problems in American political discourse are legion. Polarized interests, corporate and special interests, the news/hype cycle, and pundits who serve no real political purpose but exist only as media entities. All of it conspires to misdirect discussions of where our country is, where it needs to go, and how to get there.

Underlying all that is a serious problem. There are two sides to every issue (or so we’re told), and they cannot fathom each other’s position. Empathy is not a characteristic of American politics.

This manifests itself everywhere. Dismissive rhetoric, talking past each other, insulting jabs, moral grandstanding, dehumanizing the other side, binary reasoning, and violent propaganda. Were it the case that conservatives and progressives could understand each others goals, fears, and dreams, these problems would exist on the fringe rather than the mainstream.

Intellectual empathy is a hard thing to come by. We all want to be winners, firmly on the side of the virtuous good. To accept that there is something valid in one’s debate opponent is challenging. To go further and accept ambiguity and uncertainty is even more difficult. It would seem that a majority would prefer comfort in wrongness rather than face up to a world where their side is not that of the virtuous good.

I’m not sure how one learns these things other than seeking out new ideas and opinions. Even then, there’s the intuition to sort the wheat from the chaff, the practice from the principle, the solid thinkers from the eccentrics. Political empathy is perhaps (but hopefully not) the endpoint on an intellectual journey that a pop culture is ill suited to embark upon.

I can’t say that my grasp on the problem is good enough to suggest solutions. Perhaps humor, perhaps better education, perhaps breaking bread, perhaps more journalists growing a spine. I should hope it happens soon, because I’m getting pretty tired of how cynical I am of what politics has become.

Now witness the power of this fully functional domicile!

About a year ago, our garage door was not feeling well. It wouldn’t go down on it’s own. To close it required my loving embrace. Specifically, I had to lean against it as the door goes down the tracks. I’m sure I looked like the “mystic” trope in the “action” movie who, at a crucial moment in the action, resurrects the hero so he can go whoop the bad guy.

This is the part about home ownership that sucks the most. I had a strong suspicion this would work out one of two ways. The repair person will come out, look at it for two minutes, bang on something with a hammer a few times and everything works. Easy, cheap. Or, the repair person will look at it, tinker with it, and pronounce the motor dead, to the tune of a few hundred dollars. It ended up being somewhere in between; I think some kind of specialized garage door grease was involved.

I avoid these things because, through hundreds of logical and unintended decisions, I have chosen the life of an extremely specialized knowledge worker. I enjoy making sense of complicated systems that involve people, computers, and uncertainty. I am nearly useless with everything else.

Luckily, ours is an age where that specialization works out pretty well. I am fortunate that I can pay others to worry about typical “male” tasks like changing the oil on our cars or painting the bedroom (cue applause from the economists in the audience). That said, sometimes the interactions with those folks feels a little odd. I usually have to prefix them with the disclaimer that I am “the least handy dude on the planet”; it’s important to set expectations.

Another thing I’ve learned about home ownership is that repairing my garage door will almost certainly be worth every penny I pay for it. I know this because some time ago, we got around to having someone fix our toilet. It would run for quite some time after you flush it. At least thirty minutes. I let this linger because it was easier to not think about spending money on it that it was to do something about it. But, for not too much money, a professional (read: not me) fixed everything. The toilet flushed and stopped running mere moments later.

The psychological release this brought me was incredible. I found myself noticeably happier that our house was less broken. It was like I got a new toy. And exciting, rejuvenated, toilet toy!

…and that’s the worst part about home ownership. That you can sit down and write more than five hundred words on the joy of home repairs. I’ve been working with some folks that are several years younger than I am. These events are interesting to me, but I know that if I were to breach the topic with them, it would confirm to them that I am indeed the lamest trigenarian they’ve ever met. I know this because in college, I worked with older dudes and the summer I spent listening to them talking about the pH balance of their pools was notably tedious.

So here we are, five hundred words later, telling the whole internet I’m the lamest trigenarian they may ever meet. The good news is, everything in my house works. We got it inspected, and we know this with certainty. I highly recommend it if you have the means.

The ear is connected to the brain

Some measure their work in tomatoes. I measure mine in albums and songs.

When it comes time to get stuff done, I match my ambitions to my energy level. Big, uncertain things when I’m full of spark and optimism. Tiny, predictable things when I’m sapped and ready to check out. The coherence, duration, and novelty of what I’m listening to takes me in a different creative directions. I use Pandora, my own iTunes library, and Rdio to match my creative mood to a musical mood.

Sometimes, I don’t know where I’m going. I may not even know where I am. At best, I know how I feel. This is when Pandora shines. If I feel funky, I go with a Billy Preston or Meters mix. If I’m feeling peppy, I go with RJD2 or Steely Dan. If I’m feeling brooding, it’s DJ Shadow or Explosions in the Sky. Pandora finds my way musically, I find my way creatively. Teamwork.

I’m an album guy. I like to queue up a coherent piece of music and listen to it all the way through, in order. A good album rewards this. It starts with a bang, proceeds through a middle section where things might get slow, take on minor key, or both. Things clear up, maybe with a light and organized middle piece. The finale brings it all together and ends with something that sticks in my head.

Ideally, I’d create this way too. Start at the beginning. Find the crux of the problem space, explore some solutions. Work to some kind of apex where I’ve got all the problems solved and all my ducks in a row. Clean up the rough edges, tidy everything up, and ship it as the finale.

Duration is important. A short album (Treats by Sleigh Bells, 32 min.; Beethoven’s 5th Symphony, 31 min.) is great for tackling a compact but rewarding task in a small timeframe. A medium length album (The Suburbs by Arcade Fire, 60 min.; Game Theory by The Roots, 51 min.) is good when I’m starting to feel my groove. When I’m feeling more ambitious, a double album is in order (The Beatles White Album, 96 min., Mahler’s 5th Symphony, 72 min.).

My wildcard is Rdio. Rdio is a blessing for me as a music service. It is very much based on systemic album listening, as opposed to Pandora’s serendipitous song discovery. I turn to Rdio when I know I want to focus, but feel uncertain about where my creative travels will take me. Rdio’s full of music I think I might like, but I’m not yet sure if I really want to make it part of my collection. When I’m listening to Rdio, I’m tinkering with ideas, seeing if I want to own them now or stow them away for later.

Music is important to my craft, even though it’s not a touch point. I bought almost twice as much music in 2010 as I did in 2009. I started paying for both Rdio and Pandora. Text editors (I spent significant time in three of them last year), notebooks (I finished two and started a third), and various arcane tools are important to my work making code, organizing ideas, and shipping useful software. Getting my music right is perhaps just as crucial.

Four odes to Amazon Prime

twitter.com/therealad…

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

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.

Language and brains, an update

Does Your Language Shape How You Think? An update on the current thinking around the Sapir-Whorf hypothesis, the one about language and the words therein shaping the thoughts you can and cannot form.

Using Rails 3.0&#039;s notification system

How to use Rails 3.0's new notification system to inject custom log events. Ever wondered what the notification/subscription stuff in Rails 3 is? Wonder no more! I just used this to add performance logging around some Cassandra stuff in our Rails 3 app. Once you get the hang of it, this is really rad stuff.

Computers should do the boring bits

Future-proofing, Uniform Access, and Masquerades:

Boring work should be a cardinal sin in programming: it indicates something that the computer should be doing but isn’t.

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" => "http://therealadam.com"
}

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
end

Its even more delightful to use:

user = User.new(hash)
user.name # => "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 = Struct.new(:name, :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 < Struct.new(:name, :age, :url)
  # Behavior goes here
end

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 incumbent.

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.

Form: follow your influences

Now that I've sort of ranted about tinkering with software and how it is less important than writing, let's talk about form.

I've found new energy in writing here of late. Part of that, I think, comes from thinking about a handful of weblogs that I really enjoy and figuring out how to emulate them on my own terms. What I find most intriguing and energizing to study is the framework within each author writes.

Shawn Blanc is a tasteful writer and curator. His site brings me interesting insight into design, aesthetic, and interface. I like his even-handed mix of original and linked content, his in-depth pieces, and his dedication to words over imagery. You can tell I'm thinking of Shawn when I write lengthy pieces examining an idea from all sides or when I post shorter links with a few sentences on how the linked article fits into a larger idea or aesthetic I find intriguing.

Tim Bray has his hands on many of the technologies and ideas I use on a regular basis. On his own weblog, he often goes off into the weeds of an idea, documenting an intellectual journey of trying to understand a topic that is new or interesting to him. I don't always agree, and even find some of his stuff boring, but love it when he grabs hold of an idea and works on it. You can tell when I'm wearing my Tim hat (not literally) when I write a serial, a bunch of posts tied together by some idea, trying to figure out where the idea leads and how it fits into the bigger picture of an intellectual journey.

Jason Kottke is sort of the original gangster of curation. He is at his best and prolific when he is pulling together ideas, finding the unique and wonderful stuff. But more importantly, his erudition puts a lot of ideas and topics together I don't normally come across. Sometimes I post things that aren't really on topic for this weblog, but I do so because I think they represent the "cult of personality" of what I find interesting or exciting; this is me playing the Jason Kottke card.

Rafe Coburn is also a curator, but his topics-of-interest go a bit deeper, a little nerdier. Rafe's at his strongest when he's pulling together ideas about psychology, economics, science, and history. He uses these ideas to explain the political and technological world we live in. He does so in an opinionated way, but one I find easy to read and non-offensive, even when I disagree with him. I've yet to master his tone and the skill by which he brings ideas together, but if you see me posting on topics that are a little boring on their surface, its me trying to make sense of the world in the way that Rafe does.

Matt Webb is the island and the bridges between thinkers, dreamers, and makers. For years, I've followed his work, delighting in how he brings science, futurism, technology, and materials into wonderful and contemporary ideas. Even better, in his company's recent work, he makes these futuristic ideas happen. Should you ever find me wandering into oddly disparate ideas, trying to pull them together into something wonderful, it's likely I'm doing my own faint impersonation of Mr. Webb.

So that's who I'm influenced the most by lately. The writers whose form, style, and excellence I strive to emulate, whose work I most enjoy. Yours are probably different. But the formula is the same: figure out whose work you aspire to the most, write a post about why you admire their work, and then get to work living up to the bar you've set.

Adam&#039;s guide to switching weblogs

Over the past few years of writing on this weblog, I can't tell you how many times I've convinced myself that now is the time to move my stuff to new software. Oh, the shiny and wondrous things that must be on that grass that is so much greener on the other side. This, despite having written at least once before on whether one should implement their own blogging app.

Consider this my yearly devotion to not rejiggering things.

WHEN SHOULD I REWRITE/SWITCH/REDESIGN MY WEBLOG, ADAM?

If your weblog software is so broken you can't post, get some new software that you can post to and port all your old content to it, taking care to preserve links and such (so much as possible; don't worry about boiling the ocean).

If you make your monies blogging, follow your needs; actually you should largely disregard anything I say.

If you're a designer by trade, I'll allow that it's often good for your cred to pop a hot new design a couple times a year; just make sure that only one in ten of your posts are about your fresh new redesign.

ADAM, YOU HAVENT MENTIONED ME YET, I'M CONFUSED.

I'm getting to you!

  • If you're a writer, just WRITE
  • If you're a coder, just CODE

BUT BUT BUT!!!!!!!

No, really. The important thing about a weblog is that you put your ideas and experiences down in writing. You work through your thoughts. You put them out there for people to ignore, criticize, or praise.

You may have a lovely thing where you post links, images, funny videos, etc. Great, me too! But I'm not talking about that. I'm talking about banging two hundred words or more together into a cohesive, intriguing idea.

MAKE WORDS, NOT MARGINALLY USEFUL SOFTWARE SHUFFLING.