Pry’s namesake ability to “pry” open an object is not limited to debugging use. It’s actually a really straightforward way to build any kind of domain specific REPL. I think I just coined that term but it fits well and you’ll soon see why.

The Backstory

When I working at NOWBOX I spent a lot of time hitting our API during ad-hoc testing. I was doing enough of this that just using curl wasn’t cutting it.

Don’t get me wrong, curl is awesome and super useful. But it lacks a few niceties. Chief among them curl, like HTTP, is stateless without the use of cookie files and given that we were using a token-based authentication system, simulating device-API interaction using exclusively curl was neither fun nor easy.

During this time, we were also using Rack::Test, which I really like. It’s a solid and purposeful DSL and great at what it does. What it isn’t good at is being interactive. I’d get colourful explosions(stacktraces) whenever I tried to pry into and look at a test using Rack::Test.

We already had the awesome Faraday included in our project, so I hacked together a quick rake task that would set up a Faraday::Connection and pry into it. What did this get me? I now had my interactive Rack::Test.

Cage Version -1

1
2
3
4
5
6
7
8
9
10
11
12
13

task :client_console do
  require "faraday"
  require "pry"
  uri = case ENV["target"]
        when "production"
          "http://api.superawesomepage.com/1/"
        when "staging"
          "http://api.staging.superawesomepage.com/1/"
        else
          "http://localhost:3000/1/"
        end
  Faraday::Connection.new(uri).pry
end

Building the Gem

Pry made this really easy. So easy that later on, when I wanted to rewrite the above code and turn it into a reusable gem I kept the same strategy.

I build my DSL class, Cage::Console, which also handles all the initialization such as config file loading and default values for variables. It also overloads some of Pry’s settings to get a more interesting prompt string and suppressing they default ~/.pryrc config file loading.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Cage::Console
  def initialize config_file = nil
    configure_pry
    read_config_file File.expand_path config_file if config_file
    default_to_rubygems
    reinitialize_connection
  end

  ## The rest of the show
  ## ...
  ## The party starter
  def self.start! *args
    new(*args).pry
  end
end

The rest of the class is the domain specific stuff that deals with delegating to the Faraday connection object and building the response object. I built my own wrapper around Faraday’s response so I could improve how they are displayed as return values.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Cage::Response
  ## Delegating code
  ## ...
  ## Prettification code
  def inspect
    <<-PRETTY
Status: #{status}

Headers:
#{headers.map { |k, v| "  #{k}: #{v}" }.join "\n"}

Body:
  #{body}

#<Cage::Response:(#{url})>
      PRETTY
    end
  end
end

It’s certainly verbose but the primary function is to show you the complete result of an HTTP request, which it does.

Concluding

That’s basically all there is to it. This feature of Pry that’s mainly advertised as a way to get hands-on with your objects for debugging is also a great way to build a domain specific or domain focused interactive environment. Depending on how much you want to customize Pry’s interface you don’t even need a thorough understanding of Pry’s internals. If you’re more interested in the features of Cage than the mechanics of its construction you can install it from RubyGems using gem install cage or check out its project page. The complete source for Cage is on GitHub. I hope you use Pry and Cage to build awesome stuff!

The Mayor Learns to Program

His opening remarks jab at the Mayor of New York’s supposed new year’s resolution to learn to code suggesting we’d end up with

1
2

10 PRINT "I AM MAYOR"
20 GOTO 10

If Mayor Bloomberg gets that far, it would actually be awesome. I’m not suggesting he spend his mayoral days learning Javascript but everyone has nights, weekends, and hobbies. I’m sure the mayor of New York can afford to have quite a few.

Mr. Atwood, I don’t want everyone to become a crack Java developer. I wouldn’t wish that on my worst nemesis. What I want is for anyone with even a passing interest in how computer software works to have access to tools and materials they need to learn more about it as they please. And we don’t have that yet. CodeAcademy is doing an excellent job getting us closer and should be applauded for doing so.

Programming as a Life Skill

It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion?

Here you’re comparing big things (reading, writing, and mathematics) to little things (variables, pointers, and functions). The individual concepts are of little importance the same way homophones and perfect grammar are of little importance. But how deeply can you trust a politician’s reasoning about software and technology if they lack even a basic understanding about how that computer works. There’s a startling lack of digital literacy among people outside of software engineering and there are people trying to break down those barriers and get the interesting and relevant information out there in understandable ways.

Programming is absolutely not on the same level as reading or arithmetic however, does your argument for not teaching it in schools then extend to arts and music? Surely they are not as basic a skill as reading and arithmetic yet we still perceive some value in teaching them to children.

You said yourself that a software developer’s job is to solve problems. Well what is a JavaScript interpreter but an abstract problem solving sandbox? Is there a specific reason you don’t want problem solving to be a general skill? Are you frightened of our field losing status as the only problem solvers?

The critical thinking skills that I started developing when I started learning to code are what sustain me both physically and mentally. I would love to be teaching these skills in elementary school for that reason alone. Programming is engaging, and while it won’t engage everyone, we should at least be providing the same opportunities we used to afford music, art, and wood shop. How many people who took wood shop in high school went on to become carpenters? Probably not many. But how many gained some level of appreciation for the craft? I’m sure that number is far higher. I didn’t have wood shop at my high school, but I was fortunate in that my father, uncle, and grandfather all work with wood in various capacities and that allowed me to see how enjoyable and creative the process is.

In Which We are Likened to Plumbers

I can also recognize plumbing problems when I see them without any particular training in the area.

Yes, it doesn’t take a plumber to notice a clogged toilet. Just like it doesn’t take a web developer to recognize that 404 Not Found or 500 Internal Server Error means something went wrong but can you do anything about that clog without a plunger? And where did you learn to use it? Unless you were born with the knowledge of the existence and use of plungers, someone showed you how to use it. That’s all I’m advocating here. Teach everyone to use the plungers of coding. It’s interesting to remark however, that there is very little someone with a programming plunger can fix. It takes so much more to get any real work done. So why bother? A little bit of understanding never killed anyone and you’ll have at least some basic understanding of what your programmer is doing for you if you know how tough it is to

Wrapping Up

I’m about to arrive in my last operating systems class of the year, so I need to go and I want to publish this while I’m still caffeinated and disappointed enough to go head-on against one of the authors and developers whom I deeply respect. Much of your argument is extremely valid and the “everyone should learn programming” {initiative,movement,meme} should accept this criticism, which I do, and synthesize it so that we can better reach our goal.

However, you’ve thrown the baby out with the bathwater in your haste to put a stop to misinformation and are losing a really powerful way to engage inquiring minds of all ages with a deeply interesting and modern art, computer programming.

There’s something odd about people who pay attention to the points rather than what they learned. I will be the first to jump in and bitch about how much I pay for tuition but also freely admit that I pay far less than an out-of-state or private school student. School is fucking expensive. So why? Why why why why why? would you haggle over how many points you “earned”, when you can and should be figuring out what you didn’t learn which cost you those points. On tests where I do poorly, I often spend about as much time trying to figure out what I did wrong as I did taking the test in the first place. I’m also a really shitty student. I elect not to take notes and I am presently writing the first draft of this post in class while something I already know is being reviewed.

Situations like this one baffle me, but also emphasizes that there’s no metric I can use other than day-to-day individual progress to represent the achievements of my students lest they (or I) become fixated on the metric. I keep incredibly detailed notes about the individual skills and weak points of anyone who I regularly teach or mentor, but I neither have nor will try to grade or rate them. Why fixate on numerals when you could fixate on learning new stuff?

The vocabulary choices of this student remind me of something my seventh grade history teacher talked about on the first day of school. Which is the subtle and subconscious vocabulary choices of students when discussing grades. “I got an A. I got an A. He gave me an F.” It’s only human to want to take credit for our achievements while marginalizing our failures. I have certainly been guilty of this in the past. I have been given achieved three failing grades in my life, two in high school and one in college.

• I earned an F in second semester Geometry because I failed to find the subject interesting and couldn’t be arsed to do the homework or get up before 7AM to get to class on time.

• I earned an F in second semester American History because I elected to take no notes in spite of the fact that our notebooks were going to be collected and graded.

• Incidentally, the one college course I failed was an online Jazz History course during a winter session. I failed because I completely forgot I registered. I never signed in or even thought about it until it showed up on my transcript.

I don’t look too far down on this guy though. When I was taking the very same Data Structures class, albeit with a different professor, we were required to submit our assignments online to a system which auto-grades our programming assignments by running our own JUnit tests, and analyzing them for coverage. As well as JUnit tests written by our professor on our code. One thing the system did that I absolutely hated was run Checkstyle with the official SJSU Java Style guidelines encoded in XML. Well, this style guide was written before Java had Generics and had never been updated. So Checkstyle threw a fit when I had Node<E> instead of Node < E >. In order to get it to shut up (and claim the final five points on the assignment) I had to ruin my code with this offensively spaced style.

I mentioned this to the professor and he suggested that it was always an option to sacrifice those points in the name of doing things right and grades be damned. Since then, I’ve submitted plenty of assignments that don’t precisely meet specification. Mostly I get docked because I don’t include Eclipse project files with my source code which means the professors have to find the command line and run Ant (I also provide Makefiles). In any case, it was eye opening to hear a professor give me permission to get a less-than-optimal score simply because something else is more important.

So stop counting your points and start making sure you learn. Besides, learning is more fun.

That is all

Recently I’ve read two really excellent books. The Developer’s Code by Ka Wai Cheung, and Code Simplicity by Max Kanat-Alexander. I should start off by saying that they were both great (and short!) reads and I’d recommend either of them to anyone. Particularly young developers still getting their first five years’ experience(1). Though I’ve been reading a fair few books in between these two, something about them struck me as similar. Given that it’s been months since I read The Developer’s Code and no review materialized, I figured I’d give some brief words about each book now.

The Developer’s Code

This book is aimed at younger developers, or even folks who haven’t yet decided to become software developers. It gives a pretty good overview of the industry in which we work and how it’s perceived. The author seems utterly enamored with code generation and found a way to bring it up in nearly every chapter. I’m not really a fan of it at all unless it’s the runtime kind of code generation. However, it’s largely incidental to the work as a whole. Lastly, chapter 6 discusses teaching and every single one of you must read it now. It’s not even eight pages and yet he collects a handful of techniques it has taken me more seven years of instructing(2) to be able to put to words. The book was worth the full price to see these words written in front of me. If you need to borrow it, let me know. @sgharms has my copy right now.

Code Simplicity

I will admit to buying this book as an impulse buy because the ebook was half-off on O’Reilly.com. I’m ever so glad I did though as it’s been a very easy and enjoyable read. At first I felt the method of describing the author’s observations as Laws was considerably presumptive behavior. However, like the laws of gravity and motion in the physics world, the precise wordings have genericity(3) and a timeless quality. One of the stand-out aspects of this book to my mind was the complete absence of software testing until the very last law of the book. I was impressed by this because as I’ve written before, testing is not itself an end, it is a means to the end of successful, quality software that performs its duty of helping people. Throughout the book there is discussion of evidence and verification, from which testing should arise naturally. While I respect the author’s desire to add a specific law of software testing, I think it could be omitted as a duplicate in a George Carlin-esque fashion.

Thanks for your eyes,

Steven!

(1) I’m talking real experience. Not LOL I was writing C64 machine language in the womb by tugging on the umbilical cord in binary Morse code.

(2) When I was sixteen, I was reassigned from lifeguarding to teaching photography at the boy scout camp where I was working. I had no idea at the time, but the shake-up resulted in the discovery of two of the great passions in my life, photography and teaching. I went on in subsequent years to teach lifeguarding, teach teaching lifeguarding, and now teach programming and software development to whomever I can.

(3) Using the mathematical definition of “nearly always holds true.”

My question: Why are we still typing rake db:migrate instead of rails db:migrate?

Before you scoff and walk away. Hear me out. I get that Rake is a more general tool than Rails and we can use it to automate all sorts of cool tasks. In fact I’ve been using Rake to do all kinds of bonkers stuff in my projects since I first started learning Ruby. Teaching at RailsBridge this weekend, I had a surprisingly high number of students ask “What is rake?”. I was really happy when I got this question so much because it means that they’re actually thinking about what they’re typing, which is hugely important. Each time it was asked, my smile quickly faded. What should I tell them. “Rake is Ruby’s Make, It’s like make but in Ruby.” would work for anyone who has been using or programming UNIX for any significant amount of time, but for many Railsbridge students (and many people learning Rails), Ruby is what will expose them to all of that, so we can’t use it as the base of our teaching metaphor(1).

I settled for “Rake is a tool for automating common tasks in a project. The name comes from a program called make, but since Rake is written in Ruby, it’s Rake.”

While my students seemed satisfied with that answer, I sure wasn’t. The whole purpose of Railsbridge is to demystify programming and software development. We’re not trying to build an army of new software developers (but I’d love to), just trying to grant people some basic coding literacy and comfort. Trying to do this in an environment where some commands start with rake (assets:precompile is another culprit) and others with rails and the only way to know which is to be in the club already or have someone tell you is suboptimal.

So, developers, why are Rails’s built in Rake tasks still Rake tasks and should we start the discussion of baking them into the Rails command for Rails 4.0? Without a better answer than “it’s always been that way”, I think we should.

(1) More information and musings on them forthcoming.

Yesterday I had the pleasure of teaching two fantastic burgeoning developers the concept of method composition in Ruby. For experienced developers, it is as natural as breathing, but too often our memories of our early programming experiences are clouded over with the same terror we see in the eyes of our students.

At almost every stage there were simple questions, questions it would have taken me seconds to address had I given a direct answer. But learning to program (or do much else) needs to go deeper than just assembling facts. In order to do well, we have to have our own mental interpreters and compilers and process the code in our minds. The sooner we start developing this trait in new programmers, the better off they’ll be. So my general answer was

“Well, what do you think will happen?”

Queue audience groan. By asking this ad nauseum and forcing them to give me an answer before hitting enter, I’m contributing in a real way to building their mind’s Ruby interpreter.

If this sounds eerily like the scientific method, that’s because it is! We just condensed it for tiny, one or two line experiments in Ruby!

Not Just for N00bs

I’ve finally started reading SICP and one of the very first exercises revealed one of my achilles’ heels.

I was asked to give the value of the evaluated expression below:

1

(- 9 1)

I can never remember what this shakes out to. Is it 9 - 1 = 8 or 1 - 9 = -8? I didn’t know off the top of my head. But before I fired up Racket to see what the answer was, I forced myself to make a guess. Would it be 8, or -8? My guess was 8.

Only after forming that hypothesis did I throw that expression into an interpreter.

As it turns out, it does evaluate to 8. Assumption Verified! A winner is me! Would it have mattered if I’d been wrong? Not really, I would have learned the same lesson.

The rise of Test Driven Development is actually the rise of the application (in a very minor and partial way) of the scientific method in Software Engineering. We’re making assumptions about the goals (end-to-end tests) and design (unit tests) of our software and codifying them in form of our tests. These get challenged and verified or refuted whenever we run our tests. As our software changes, so do our hypotheses around it.

So regardless of whether you’re writing code for the first time, or a veteran software developer, take the advice of John and John of They Might Be Giants, you need a test.

For others, is anyone interested in attending a South Bay Area Swarm Coding night once every couple of weeks or so? Since I’m the one putting it forward, I suggest we go somewhere in Santa Clara (I have a number of ideas as to where) but I’m also open to other areas so long as they don’t crawl too far North. It’s not that I don’t love San Francisco but it’s hard to get up there with school.

If anyone is interested, I’m attempting to schedule the first one for some night the week of April 1st through 7th. If you’re not sure what Swarm Coding is, check out Phil’s slides (pdf) from Clojure/west. In short, everyone logs into a shared tmux session running either Vim or Emacs and all collaborate on a project.

Don’t be disuaded if you’ve never programmed in Clojure before, it’s actually a really fun way to learn no matter what your initial skill level is. If there’s a quorum of newcomers, we can also do a session on tooling before diving into the code.

Does this sound like the best idea? I haven’t bothered to set up a mailing list or anything so if you’re interested hit me up on Identi.ca, Twitter, or good old email and let me know which day of the week works best for you. Then I’ll cast the information back out to everyone.

Come on out and have fun making Clojure stuff!

Furthermore, Clojure/west’s website lists the official guide from the city of San Jose, which includes a lot of duds and places far away from the conference venue. There’s not much I like about Downtown San José but the few things I do enjoy are places to eat and drink.

For the impatient, here’s the map of everything.

As a student at San José State, I spend a lot of time in this part of town and have compiled a short list of places to eat and drink while you’re in town for the conference. If you’re venturing further afield than downtown or just want to hang out. I exist on the Twitters as @nuclearsandwich

I’ve included below a description of my usual haunts and a like to Google’s walking directions from the conference hotel.

Good Karma

To my mind, Good Karma is the best food in Downtown San José. Yes it’s a vegan restaurant but the food is stellar. They have a selection of entrées such as Spicy Basil Tofu and Chana Masala which they serve on a plate with brown rice and house gravy, or in a wrap. The spicy basil tofu and Pra-Ram are my favorites at the moment. The other best thing about Good Karma is their amazing beer selection. Even if you don’t make it out for the food, treat yourself to a good beer. I wrote most of this article from Good Karma. If you’re an IPA fan, Good Karma currently has a host of exceptional IPAs including Russian River’s Pliny the Elder, one of my favorites in the genre.

La Lune Sucrée

La Lune Sucrée only opened up recently. It’s above average for a student’s lunch and I generally consider coming here a treat. They have a number of French staples such as croque-monsieur which I cannot speak toward, but their Apple and Brie (with ham if you want it) sandwich has walnuts and cranberries and is quite yummy as is the vegetable quiche. They also have one of my favorite ginger ales but it comes in massive one liter bottles.

Single Barrel

Single Barrel is cocktail heaven. Your first drink here, you’re not allowed to order from the menu and you’ll probably never want to. Instead your bartender is going to ask you what sort of flavors you enjoy and through a serious of questions, arrive at a cocktail that suits you well. Come in the mood to relax and take your time with the drinks here as they aren’t cheap. Also be warned that they don’t take groups larger than six since it is a speakeasy in a low-ceilinged basement. They have chess, checkers, Connect Four, and Scrabble so long as you keep the volume down.

Tandoori Oven

Tandori Oven is mostly here because some of you won’t want to eat at Good Karma for every meal. I’ve eaten here once or twice and never been disappointed, but there’s better Indian closer to where I live so this restaurant is not in my regular rotation.

Satori Tea Bar

Satori Tea Bar isn’t a place to eat lunch or dinner and the hours are quite restricted. However, if you need to take a break and go somewhere quiet and contemplative where you can drink delicious oolongs and rare greens or try the delicious guayusa, which is similar to yerba mate but sweeter.

A quick stop at Satori for tea to go would also be nice walking back from the Mmmoon

The Mmmoon

Despite its silly name, The Mmmoon makes really delicious empanadas both sweet and savory. The sauce they use is quite unique and although I’ve seen it in a number of other empanada restaurants throughout the Bay Area, this is the best one I’ve had. Lunch here can be cheap and filling. They also deliver within five miles of their location which includes the conference venue.

Grande Pizzeria

I’ve only eaten at Grande because the school regularly hosts mixers with IBM, Cisco, and NetApp here. The pizza is alright and they have a few “good enough” beers and an inexpensive happy hour that coincides with the dinner break.

La Victoria

This is the quintessential college eatery. The food here won’t be great, but when you’re starving at 2AM it will be a feast. Their orange salsa is also raved about but I don’t think much of it. I tend to avoid La Vic because the food is only “vegetarian” if you’re willing to apply large double quotes to the term. It made the list because you’ve not properly been to Downtown San José until you’ve been to La Victoria.

What is Sightreading?

I’ve been listening to a ton of Ruby Rogues, so let’s begin with a definition.

From Wikipedia,

Sightreading is the reading and performing of a piece of written music, specifically when the performer has not seen it before.

Musicians are always evaluated on their ability to read and interpret musical scores on command, a musician’s time isn’t cheap and rehearsing a specific piece of music is a privilege reserved often reserved for school ensembles and AAA film score recordings. I exaggerate a little, but honestly, professional musicians are not afforded a lot of rehearsal time. They are instead expected to walk up to a piece, play their bit expressively while fitting in with the rest of the ensemble perfectly, sometimes without ever hearing them.

If you’re wondering how on Earth this could possibly relate to software, look no further than your first day on your current project. Most software developers don’t have the privilege of starting from scratch when they begin a new job or contract. Instead we are thrown into an existing one and expected to decrease the bug count. Some people might say that’s an unfair expectation, but it is, in fact, no different from expecting a professional musician to walk into the studio, read your score, play their piece once or twice, then collect their check and leave.

Western music has a complex but accepted system of notation that all musicians and composers are expected to be familiar with. On top of this base language there are sets of idioms particular to certain genres. By writing works in this language and leveraging (often subconsciously) these idioms composers create music that musicians can read and follow and interpret even as they play.

In the case of software development, the language and idioms are still present, but they are the languages and idioms of computer programs rather than those of western music.

Sightreading Code

So what’s the point of sightreading code? Here’s three scenarios from every stage of one’s career.

1. You’re fresh out of University and in a technical interview. You’ve been asked to find and fix the two known bugs in a text formatting program.
2. You’ve just started your first day at a new job and you’ve been tasked with extending an existing project with new features.
3. You’re a super celebrity master contractor and people pay you way too much money. You walk up to code you’ve never seen before and need to make magic happen in order to justify your absurd cost.

In each case your value hinges on picking up a brand new codebase and running with it. Since you can’t control the quality of code you didn’t write you can’t make any excuses regarding what’s already written. At this point you have two options. Skim the code, or read it all.

I will tell you right now, skimming doesn’t work. You can’t read every other line or seek for specific variable names and actually follow what is going on. When you do so, you screw it up.

Disclaimer: Slight boorishness follows

If you ask me a question about my code, I’m going to assume you’ve read every relevant line.

Relevant lines are tough to pin down, but at the very least the entire method in question is a good start. When you haven’t done so, it’s plain disrespectful and arrogant on your part, especially when your question is answered (or nullified) by something directly in that body of code. By skimming and then bringing up something you saw during the skim, you waste your time and mine.

Everyone who has taught me up until a year ago will roll their eyes at me for this because I was the best at skimming (meaning I was the worst reader/pupil) I actively avoid jumping to conclusions about what I read and take a concerted effort to answer as much as I can on my own before escalating a problem. Furthermore, when I do I often have a much better handle on what question I am asking than I would otherwise have had.

In all seriousness, when you do this I start to think about spending less time with you. I warn everyone I’m comfortable warning not to skim ever. Including you, dear reader.

Since skimming code doesn’t work, our only remaining option is to actually read the code completely. This probably sounds like a lot of work, that’s because it is, but so is reading and performing an entire ten minute piece in half an hour and musicians still manage to get it done.

In order to determine how we can become more effective code sightreaders, we again look to our musician friends who have been doing this for some time. Musicians who want to improve their sightreading do the following things.

Musicians Know and Practice Scales

Musicians who practice their scales are the ones with the best technical chops, their fingers are the most agile, their articulation superb and they’re comfortable with any given set of notes.

For programmers who wish to improve sightreading, there’s simple no replacement for knowing the language you’re in. If you’ve never looked at C before, you’ll spend 20 minutes figuring out what int main() { is, or spend that time figuring out the precise semantics of a line ending conditional in Ruby.

If you don’t know the language, you’ll spend time figuring out what the language is doing instead of what the program is doing. Know your language.

Musicians Study Music Theory

Every musician who works with written music needs at least a basic understanding of music theory. Without it, reading music, let alone interpretting it, is impossible. Over time many musicians gain an intuitive understanding of theory. They realize all major scales are the same but starting from a different note, then slowly absorb more as they go. But some of the best musicians actively learn theory as theory and can leverage that to do amazing things as Jazz improvisers, composers, and virtuosos.

As computer scientists, we need to know the design patterns used in our field. Decorators, strategies, delegation, they all need to be second nature if we intend to approach a new body of code and immediately see what’s going on. Additionally, these patterns establish a common vocabulary you can use to discuss code with other programmers regardless of their language and experience. If you both know the patterns, they can add precision and expressiveness to your non-executable communication.

Knowing patterns allows you to see and apply them instantly when you enter a new codebase or team. Use them as a common vocabulary.

Musicians Sightread During Practice

Lastly, and hopefully most obviously, musicians practice the act of sightreading during their own self-directed practice. My high school band director, once said to our ensemble that if you do something for the first time during the show, you’re practicing in front of a live audience, not performing.

Likewise, don’t assume that if you know your languange and some patterns you’ll be an extraordinary sightreader. You need to apply that knowledge frequently if you want to temper it into skill. Trust me, you do not want to do it on the job your first few times. If you do, you’ll likely feel rushed and sink back into skimming. So find an open source library you use, pop into it’s source code and get reading.

Don’t do your practicing in front of a live audience. Read open source code in order to get better at sightreading.

Wrapping Up

Thus far I’ve made the assumption that you will have no control over the codebases that you sightread. While this is often the case when starting out, we often spend a significant amount of time with one codebase and start to grow into and learn it. While this certainly helps, one of the main differences between musical scores and software projects is that individual scores seldom change between performances whereas software is in constant flux. If you wrote it a week ago you’ll be sightreading it again next week. If you wrote it a month ago, how many hands have been at it since you last looked at it? Sightreading is a constant and ongoing process in software.

As a writer of software, you can and should take steps to make your software more sightreadable but I’ve throw a big wall of text at everyone so I think I’ll tackle that subject at a later date.

Basically I am not anybody. I’m a student of Computer Science and Mathematics at San José State University. I have been fiddling with computers my whole life but would say that the decision to embrace quality software design only happened about a year and a half ago. My entire formal education save for one functional programming class which I only had last semester has been Java but for a token course each in C, C++, and Assembly taught by a professor who had to mentally translate everything into Java and then translate it back to answer questions. As a result, I’m really behind in a lot of stuff I shouldn’t be behind in.

In the past two years I’ve found myself making money doing things in Ruby. The best thing about Ruby is that it’s fun to do things right, compared to Java where you are actively punished for trying to do so. I have made it my business to be a good Rubyist and live up to those who inspired me to learn the language and participate in the community. As part of this process I’ve read voraciously on Ruby and software craftmanship, lurked in IRC, and made a nuisance of myself at conferences and Ruby meetups. The process has made me a lot of new friends, at times both inflated and deflated my ego, and overall given me a much grander perspective on what the important things are in life and in software development.

Because it’s rather difficult to code in 90 minute spats with shoddy internet, the great majority (read: all but school related) of my projects are in-progress and incomplete. I despise this about myself. One of the main things I still suck at is cranking out a project in a weekend. And since most of my projects are started to apply a specific bit of knowledge or insight, or leverage a specific language or language feature I wish to do more with, I tend to start a new one more often than continue work on the old ones. While I don’t think it too much of a problem, it’d definitely feel better to have one or two completed works in my portfolio that aren’t a top-down recursive descent parser, of which I have three with a fourth (Clojure, this time) in progress.

Just where is he going with this..?

Well now, I’m working as a Ruby developer, I’ve finally made it to a Railsbridge workshop and absolutely love teaching there. More to the credit of Steve’s open commit policy than to my own artistry I am a contributor to Hackety-Hack.com

I’ve just decided to apply to January’s Ruby Mendicant University session though the upcoming weeks are going to be maddeningly busy for me and I may have to hold off until the next one comes around. I had the pleasure of taking Peter Cooper’s Ruby Reloaded course which I highly recommend for those who learned just enough Ruby to be potent with Rails but still aren’t sure what’s going on in some cases.

I’ve picked up Clojure and and revisited Haskell and am loving both. I’ve got a few ideas in mind for beginning Clojure projects and am preparing for a return to Archlinux as my primary OS as I simply can’t tolerate OS X any longer.

I want to start being the type of programmer that inspired me to get as far as I’ve had the privilege of getting thus far and I’ll do it one application, library, and blog article at a time. Starting…

now.

Isolated Tests

I recently had to completely justify my desire to add and grow isolated tests for production code. The argument against doing so was simply that if the whole point of isolated tests is to know when something breaks in the future, an integrated test suite will pick up those failures just as well. Therefore isolated tests are a waste of time and engineering effort.

This argument is correct, provided the only thing you use your isolated tests for is protection from regressions. However, doing so leaves out what is to my mind the greatest and most profound advantage of isolated testing, which is immediate, focused feedback. I definitely think I’m inventing terms here so please indulge me while I clarify them.

• Immediate: The result (success or failure) can be observed right away.
• Focused: The cause of any failure is known to be within the system under test.

Anyone who has worked in software for a substantial amount of time knows that we are each our own worst enemy and the temptation to add unnecessary complexity is a constant bother. How many of us have added arguments to methods only to use the default value every time. I call these bullshit arguments, because they piss me off when I have to put up with them. The joy in a test with truly immediate feedback is the laser focus that they give you when working on a system. You’re literally doing one thing at a time and checking that you get the expected result even when it isn’t success. When you get the failure you expect, you simply move on, and when you get an unexpected failure it causes you to identify the disparity between your mental model of the system and the computer model and correct it. Since these tests are isolated and generally run in less than a second, there is essentially no penalty for running the tests with monstrous frequency. When you do have to stop, it is to make a correction, even if it is just a mental correction. The time you save fixing it early is more than enough to justify the low cost of running the test.

One of the downsides of this type of testing is that you are treating anything which isn’t the system under test as an external service and therefore stubbing the interactions with it. This works great for fast, clean-room tests but it means that the burden of ensuring that the assumptions you make in one test are validated in the respective tests for your other systems is entirely on the programmer and since programmers are human, this will eventually lead to mistakes.

My personal favorite aspect of isolated tests is how informative they can be about your system. It’s pretty common knowledge that if your tests are a pain in the ass to write, it’s a good indication that your code is too-tightly coupled and refactoring to follow the Law of Demeter and SOLID design principles is a good idea.

Integrated Tests

One of the scariest things that happened to me in recent memory was discovering that people were surprised when after arguing in favor of getting higher quality unit tests I was still unsatisfied because our integrated tests also needed attention and improvement. I found this a little disturbing (okay, I found this really disturbing) because I can’t imagine how long it would take to manually verify that I didn’t overlook anything in the major refactoring or feature addition I just performed. I certainly don’t budget the time to manually test every resource and parameter combination by hand. I might do so initially because a major disadvantage to integrated tests is in the difficulty of doing exploratory testing at this level. As a result, when writing integrated tests, I tend to rely on manual experimentation to determine how my system behaves in undefined situations, make a decision on the appropriateness of that behavior and then solidify that set of interactions into a group of tests. One of the nice things about integrated tests is that once written, they tend not to change unless your expected end-user behavior changes. This is afforded by the “bigger picture” nature of integrated tests where you are less concerned with the exact behavior of any one unit and instead are validating the result of system-wide operation and interaction. Thus, integrated tests are largely immune to internal refactoring.

As one can imagine, the strengths of isolated tests are the weaknesses of integrated tests. When something is wrong, particularly in a complex interaction that touches many parts of the system, it can be unclear exactly where the problem in the codebase is when an integrated test fails. If you get an actual exception, you’ll have a stacktrace to guide you, but those tend to be unhelpful errors like an unexpected nil and rarely is it obvious at what level the nil was assigned and how long it had been propagated upward until the failure. So it can be said that integrated tests are not focused since there is no indication of precisely where in the system the failure has occurred. Additionally, integrated tests mandate that you test your full software stack. Any persistence layers, external services, background tasks, and other specific tools you’re using should be tested during this phase. As you can imagine testing all of these things takes time and computing power. It is not feasible to expect even a subset of an integrated test suite to run in the same magnitude of time as isolated tests, what this means is the tests are no longer immediate. Thus, they are not suitable for running at every pass of your TDD cycle. Only when you believe the feature to be complete.

Conclusions

So if isolated tests don’t identify incongruities between subsystems and integrated tests are too slow to run during an immediate feedback TDD cycle, which do you use? As you may have surmised from the title, the answer is… both.

The Cucumber Book suggests that “It’s sometimes said that unit tests ensure you ‘build the thing right’, while acceptance tests ensure you ‘build the right thing’.” I also like Avdi Grim’s simile of mocks being like hydrogen peroxide in that they both fizz up around problems.

With our twin goals of systematic coverage and focus during development in mind, let’s recap how each set of tests is used.

When you know what you you’re building but not how, reach for the integrated tests. Define the desired outcome at the high level and then run that test again when you think you’ve got it down. Start thinking about the different aspects of that problem and decomposing them. Then devise a system of smaller tests mirroring the smaller objects and functions you’ll use to accomplish that goal. Isolated tests are there once you’re ready to do exactly that. There to aid you in that mission and guide you toward good design decisions. “I’ll do what the tests tell me” is not an uncommon phrase from me.

Isolated regression tests are a side effect of good TDD, they’re more important during the process than after.

Integrated tests are the ones you bring home and show your mother. The ones you can be proud of at the end of the day.

Ruby’s case-when is an expression

However, there are a number of things that make Ruby’s case-when special. The first comes from Ruby’s functional roots. It’s powerful but deceptively simple. Ruby’s case-when construct is an expression. Which means, among other things, it returns a value.

In a traditional imperative style a case statement might look like:

1
2
3
4
5
6
7

conditional_variable = :some_default_value
case our_condition
when :first
  conditional_variable = :one_thing
when :then
  conditional_variable = :another
end

The that isn’t ideal for a number of reasons. conditional_variable is set visibly three times which as any freshman can tell you is frowned upon. Academics have stuffier reasons for it but the most important is that it decreases readability because we aren’t sure what the value will be after execution. Setting it so many times is also a code duplication, albeit a small one. We can take advantage of Ruby’s case-when expression with this code:

1
2
3
4
5
6
7
8

conditional_variable = case our_condition
                       when :first
                         :one_thing
                       when :then
                         :another
                       else
                         :some_default_value
                       end

Doesn’t that look nicer? conditional_variable is only set once and the intent is clear, we want the value to depend on our_condition.

case-when uses triple equals for comparison

This got me good this morning and spawned this article. If you’re not familiar with === in Ruby then the best explanation comes from _why’s Poignant Guide to Ruby which really is worth reading. I’ve referred back to it multiple times to help myself and those around me fully understand basic Ruby concepts like nil, truthiness and falsiness, and, fanfare please, double equals versus triple equals.

The double equals gives the appearance of a short link of ropes, right along the sides of a red carpet where only true can be admitted.

1
2
3

if approaching_guy == true
  puts "That necklace is classic"
end

… [This case-when statement]

1
2
3
4
5
6
7
8

case year
when 1894
  "Born."
when (1895..1913)
  "Childhood in Lousville, Winston Co., Mississippi."
else
  "No information about this year."
end

is identical to

1
2
3
4
5
6
7

if 1894 === year
  "Born."
elsif (1895..1913) === year
  "Childhood in Lousville, Winston Co., Mississippi."
else
  "No information about this year."
end

The triple equals is a length of velvet rope, checking values much like the double equals. It’s just: the triple equals is a longer rope and it sags a bit in the middle. It’s not as strict, it’s a bit more flexible. Take the Ranges above. (1895..1913) isn’t at all equal to 1905.

No, the Range (1895..1913) is only truly equal to any other Range (1895..1913). In the case of a Range, the triple equals cuts you a break and lets the Integer 1905 in, because even though it’s not equal to the Range, it’s included in the set of Integers represented by the Range. Which is good enough in some cases, such as the timeline I put together earlier.

My Mistake

This is what I did which caused me to write this as penance.

1
2
3
4
5
6
7
8
9
10
11
12

def local_tweet_object input
  tweet_hash = case input.class # the screw-up
  when String
    MultiJson.decode input
  when Hash
    input
  else
    fail ArgumentError.new(
      "Cannot process #{input.class} only String or Hash")
  end
  LocalTweet.new tweet_hash
end

This code was raising the following error.

ArgumentError: I don't want Hash give me only String or Hash … huh?

At first glance it looked fine, but then we remember that case-when uses ===. Again, we think “this shouldn’t be an issue, if it’s good enough for == it should be fine for ===.” But === behaves specially for certain types in Ruby such as Classes, Arrays, and as we saw before, Ranges.

For simple scalar values === acts like you expect.

1
2
3
4
5

12 === 12 #=> true
12 === 13 #=> false
:rats === :rats #=> true
"pens" === "pens" #=> true
"space" === "fact" #=> false

And we know how === treats ranges

1

(8..64) === 32 #=> true

But note that

1

(8..64) === (8..64) #=> false

Suddenly!

1

Integer === 12 #=> true!

waitaminute.. what?

So Ruby can tell that 12 is a type of Integer and thus === can be described partially as an includes and typeof operator. But there are some further gotchas.

1
2
3
4
5
6

[ 1, 2, 3 ] === 1#=> true
[ 1, 2, 3 ] === [ 1, 2, 3 ]                         #=> true
[ 1, 2, 3 ] === [ 1, 2 ]                            #=> false
{ :foo => :bar } === { :foo => :bar }               #=> true
{ :foo => :bar } === :foo                           #=> false
{ :foo => :bar, :baz => :qux } === { :foo => :bar } #=> false

===’s behavior isn’t completely intuitive even within Ruby’s standard Classes. Which brings us (finally) back around to my original error. Hash === Hash #=> false

The fix is simple, just change

1

case input.class

to

1

case input

I posted on identi.ca a friendly notice about this easy mistake and was asked to provide clarification. So here, just over 24 hours late, it is. The full source code is provided here

Well, not quite. It is the first post with the new blogging engine Octopress I was having a lot of trouble with Posterous’s post by email and their antiquated markdown version. So here I am, on this shiny new, happily Vim-able platform.

The joy begins.

UPDATE: Or as Steve Klabnik puts it more precisely and politely:

factories are integration tests by definition, because they do not exercise a single unit.

The Ruby community isn’t unique in its tendency for celebrating rockstar developers but after examining the communities history it would seem that we burn them out bright and fast.

When I first became involved in the community I had heard of almost no one. My first hero is my friend Erik Ostrom to whom I owe a great deal for my first and second introductions to Ruby. Without you Erik I would be missing out on the most fun, passionate, and rewarding hacking I have ever done. I have you to thank for my introductions to rhe MVC pattern, idiomatic programming, and the process of developing software. I also owe you a big thanks for pointing me to _why’s (Poignant) Guide to Ruby.

Which leads nicely into my second hero why the lucky stiff. The Guide when I first read it was the most refreshing and maddeningly beautiful piece of technical literature I had ever encountered and remains so to this day. Never before had I seen a language presented side by side with English hold its expressiveness the way Ruby did. It took me three tries to finish the Guide but I have read over its pages many times reminding myself to “use what Ruby gives [me]” and it is still my goto for explaining nil, truthiness, and falsiness in Ruby. If I were to teach programming in an art department, The Guide would be my textbook. But why gave me more than the guide. Through Camping I was able to study “magic” and be exposed to the raw untamed power of metaprogramming in Ruby. Even though I had missed the whole hullabaloo surrounding _why’s exit from the community by a matter of weeks his work has had a lasting and profound effect on me and I thank him.

Like many developers my first full application in Ruby and real test of what I learned was using Ruby on Rails. Rails 2.3.5 to be precise. This marks me as a new kid on the block I know, but let’s face it, I am. I have been living with Ruby for little more than two years. But that’s the evolution of community without new blood it dries out. Anyway through this early stage I had a collection of mentors. The most prolific of which wasn’t even aware of it at the time.

Ryan Bates, your Railscasts helped guide me not only on specific challenges I was facing building my first production app but also provided my first exposure to lots of quality Ruby code and process. One thing the Ruby community gets on a fundamental level is that process matters and you were my first big introduction to that. You also introduced me to rvm and by extension my next hero.

Wayne Seguin, rvm is a colossal undertaking. Managing development environments has always been a pain and you shaved one of the biggest, hairiest yaks ever to stand in the middle of the room. MixedMetaphorException: “Yaks aren’t elephants.”

You are also a fabulous example of a project maintainer I don’t have a specific IRC story of my own but that only speaks to the quality of your work. You’re also a wonderful example of a polyglot Rubyist and really show what can happen when Rubyists take their knowledge and experience and apply it to funny little languages like bash.

Last April I had the pleasure of meeting Steve Klabnik at the very first CodeConf. One of the coolest things about you Steve is that you’re pretty much my age. It was so inspiring to see you, such an obviously accepted member of the Ruby community, so close to my own age. You indirectly informed me that the amount of effort required to really get involved and make a difference wasn’t in the depressingly distant future and this has motivated me substantially in my efforts to give back even as I receive.

Thanks man, you rock

Lately I have been reading a lot of stuff from Avdi Grimm. You’re style is so refined and decisive. Few people think about the meaning and reason behind their code and design decisions as you clearly do. Lately I have been turning to your writings when I find myself wondering about the best way to do something.

So my journey through Ruby has brought me across the paths of these heroes and so many more. But what motivates me to think of these fine folks this way even when they may not want the attention. How many feel overly pressured by or undeserving of their status. When thinking on this, I am reminded of Firefly. (If you haven’t seen it, seriously do yourself a favor and watch it.)

Specifically the Hero of Canton episode in which Jayne, the least noble of the protagonists, is remembered as a folk hero on a backwater mining colony for accidentally dropping crates of money over the mining camps. At the end Jayne can’t understand what they see in him when dropping the money at all was simply a dishonest mistake as the episode wraps up he’s told that the statue in his honor isn’t for him, it is for the miners. We build heroes out of you because we see qualities in you we hope to someday find in ourselves. So please, whether you’re a Jayne Cobb or Malcom Reynolds, if someone thinks of you as their hero, just be proud that you’ve done something extraordinary and they hope to follow suit.

Happy _whyday, Steven!

Firstly, if you’re unfamiliar with CoffeeScript, I recommend reading elsewhere for a proper overview and introduction. The CoffeeScript homepage and the Introductory Chapter of The Litte CoffeeScript Book are good resources for that. If you’re really impatient CoffeeScript is in the author’s own words “JavaScript’s less ostentatious kid brother.” I’ve also heard it called “Javascript for Ruby and Python programmers” and “What Javascript should have been” by several of my peers. It also seems that it could’ve been called CilantroScript1 as it seems to have an instantly polarizing effect on people in online communities such as Reddit and the Ruby on Rails community.

So why did I start working with CoffeeScript? A number of reasons.

I am a backend developer and want to grow my frontend skills. 1. I’m starting to experiment with Node.js on the server. 2. Jeremy Ashkenas’s talk at CodeConf on literate programming blew my mind. 3.I know Ruby, so I should enjoy a “Javascript for Rubyists”, right? 4. It is going to be a Ruby on Rails default soon so I might as well check it out now. 5. I like new and shiny things.

One of the quandries I faced when deciding to learn CoffeeScript was the fact that I don’t know JavaScript. I spent 6 months noodling with Ruby before picking up Rails and am still getting my feet wet with Python before taking Django for a spin. So why on Earth would someone with my MO pick up CoffeeScript without first becoming proficient with javascript? (Aside: I’m tired of the CamelCasing) The answer comes from the first sentence (topic sentence, for those still in Jr. High School) in the second paragraph of the coffeescript home page.

The golden rule of CoffeeScript is: “It’s just JavaScript”.

As it turns out that isn’t entirely true since coffeescript is a class based object oriented language and javascript is prototype based. This was actually a mark against coffeescript for me since part of my desire to learn javascript was to dally in prototype based OOP. (Luckily there’s still Io for that.) But for the most part Coffee really is just javascript.

EDIT: Jeremy Ashkenas has kindly clarified this point for me.

CoffeeScript is prototype based to the precise same extent that JavaScript is. The “class” keyword is just sugar for JavaScript’s constructor function + prototype chain combination. To mangle Shakespeare:

What’s in a name? That which we call a class by any other name would smell as sweet. Call it a prototype if you like — it’s the same thing in code.

Thanks Jeremy, apologies for misapprehending.

So why the bother?

A while back I invested some of my hard-earned and short-in-supply cash to pick up a ten-pack of PeepCode tokens. I have to say, I’ve derived an intense amount of value from PeepCode but more on that later. I started with PeepCode’s Meet CoffeeScript, had they produced a Meet JavaScript I would have started there, but they didn’t. It took around six hours to watch the three and a half hour video. Almost immediately after, I started PeepCode’s Meet Node.js screencast and attempted to do it in javascript for about eight minutes. The appeal of coffeescript was immediately clear.

In JavaScript, I have to worry about whether or not every line ends in a semicolon, that there are no extraneous commas, yet commas where necessary, and that I’ve remembered the var keyword on all my local variables. All that stuff is important in JavaScript it doesn’t actually effect my application in any way. In CoffeeScript, I can focus on the behavior of my code rather than the presentation of it. Instead of scrutinizing each line for a semicolon and each block for matching curly braces. I’m affirming that all my variables are scoped properly and that my code does what I want it to do. It doesn’t add much to javascript but rather, reduces the amount of worry and focus on what is at the end of the day arbitrary stuff.

Sure, I have Vim configured with the fantastic Synastic plugin and I get notified when I drop a semicolon or have an unmatched brace but what’s the point? Basic sanity checking is all it can really do. Why even waste the time to go back and insert those in the first place?

Conclusion

I’m still continuing my education in JavaScript, CoffeeScript, jQuery, Node.js, and prototype-based OOP. I’m armed with the beta copy of the CoffeeScript book by Trevor Burnham from Pragmatic Programmers. I fully intend to use CoffeeScript for all of my development in Javascript environments, server- and client-side, work and play, for the foreseeable future.

My CoffeeScript Resources

1. The CoffeeScript Website and Documentation
2. Meet CoffeeScript
3. CoffeeScript: Accelerated JavaScript Development by Trevor Burnham
4. The Annotated CoffeeScript Source
5. The Little CoffeeScript Book
6. Javascript: The Good Parts by Douglas Crockford
7. Eloquent Javascript by Marjin Haverbeke
8. Smooth CoffeeScript by autotelicum via @Raynos2

1. Cilantro (or Coriander) is an herb which to some people tastes pleasantly citrus-like and to others is rank and revolting or soapy. As a result many people either love it or hate it. Few are ambivalent about Cilantro. The same is true of CoffeeScript in my observation.

Recently, Nowmov has started using Heroku for application deployment. In the past I’ve always been hesitant toward “hosted solutions” but a combination of focusing my time and the flexibility and power of Heroku’s Celadon Cedar stack has brought me into contact with one such solution.

One of the first peculiarities/gotchas/side-effects of many of these hosted solutions is that they don’t provide shell or ftp access. Nor can you write to the file system from your application. This caused us some interesting problems during the migration.

1. Rails convention dictates that config/settings.yml, config/database.yml and friends not be stored in source control and that we should store template files instead so developers are aware of setup specific configuration details. However, our inability to push files not in source control to Heroku leaves us unable to use the standard convention for configuration details. The way Heroku bypasses this leads to the next hurdle.

2. The whole point of Heroku is that you don’t deal with IT, just your code. This means that you don’t really care where your PostgreSQL database is or what port you use to connect to your Redis instance. But you still need to connect to those things! So what does Heroku do? They give you environment variables. heroku run 'echo $DATABASE_URL' returns a big long uri corresponding to your app’s database. With this specific config variable, Heroku is kind enough to render a database.yml from it using erb. But it only works ActiveRecord compatible database.ymls, which is not all of them, believe it or not. (I’m looking at you Sequel) Inspect your Heroku config variables by running heroku config from an app directory. The amount of scary looking crap in there might surprise you!

You can even add your own config variables such as MR_FANCY_PANTS=the_worlds_best_pants with heroku config:add MR_FANCY_PANTS=sad_deep_inside ARTIST="Jonathan Coulton" this command will expose both your variables to your code using Ruby’s ENV hash.

In your code you’d get to it like this:

1
2
3
4
5
6

#!ruby
def controller_action
  if ENV['ARTIST'] == "Jonathan Coulton"
    @still_alive = true
  end
end

But then this also has to work locally! So you need to do somethig like this:

1
2
3
4
5
6

#!ruby
def controller_action
  if (ENV['ARTIST'] || SETTINGS[:artist]) == "Jonathan Coulton"
    @still_alive = true
  end
end

Alternatively, you could set up all these environment variables using a rake or thor task before launching your app but who wants to deal with that? My favorite solution to a problem is a coding solution.

And you have to do that everywhere you want to use a situation specific configuration. I don’t know about you but that seems hacky, error prone, and repetitive to me. Smelly code, in other words. In working on my recent projects I’ve been studying a large number of small Ruby applications. Mostly Sinatra but some in Rails and Padrino as well. In all those apps, I never found a ubiquitously deployed solution for the configuration situation in a Heroku-style environment so I left it to simmer a few days and dealt with ENV[:KEY] || SETTINGS['key'] all over my app. Then, over too much cold brew coffee I came up with a workable solution. While this is the very first time I’ve seen this solution in a web application. It actually comes from messing around in irb earlier in the week trying to alter prompt strings for vanity’s sake.

Everyone open irb right now! Just go to a terminal and do it! Got it? Okay

> IRB.conf

You’ll see how this inspired my solution later on. Or perhaps I’m not as brilliant as I think I am and it’s obvious to you already (likely).

So let’s say we’re working on a lightweight Sinatra application and we know that it’ll start simple and grow in complexity later on. Since we’re smart we’re going to namespace the whole thing under a module. Namely Saneconf Our skeleton looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!ruby
require 'rubygems' # Only needed for Ruby 1.8
require 'bundler'
# After this line, I shouldn't even have to *think* about dependencies.
Bundler.require

# This is the initilization file for the Saneconf API. All set up, library
# loading and application level settings are done here.
module Saneconf
  # If there's a better/safer way to do this generically do let me know.
  # I haven't encountered a setup where this didn't work.
  def Saneconf.root; Dir.pwd; end

  # This one is important so we set it early and use a constant.
  # Set Rack environment if not specified.
  RACK_ENV = ENV['RACK_ENV'] || "development"

  # Create an accessor to a module attribute which defaults to a
  def Saneconf.conf; @conf_hash ||= Hash.new; end

  # Handles initialization and preprocessing of application settings be they
  # from Heroku's Environment or a local `settings.yml`.
  require_relative 'config/setup.rb'

  class App < Sinatra::Base
    get '/' do
      "<h1>So nice to be sane again, eh? #{conf['ARTIST']}?</h1>"
    end
  end
end

That looks cool and all, but what the hell is config/setup.rb? Answer: It’s where the magic happens, let’s go take a look:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

#!ruby
if File.exists? "config/settings.yml"
  Saneconf.conf.merge!(
    YAML.load_file("config/settings.yml")[Saneconf::RACK_ENV])
    Saneconf.conf['RESQUE_SCHEDULE'] =
      YAML.load_file("config/resque_schedule.yml")
else
  Saneconf.conf.merge!(ENV)
end

db = URI Saneconf.conf['DATABASE_URL']
redis = URI Saneconf.conf['REDISTOGO_URL']
# Parse Postgres connection settings.
Saneconf.conf['DATABASE'] = {
  :adapter => "#{db.scheme}ql", # Add a 'ql' cause ActiveRecord is stupid.
  :host => db.host,
  :port => db.port,
  :database => db.path[1..-1],
  :username => db.user,
  :password => db.password
}

# Parse Redis connection settings.
Saneconf.conf['REDIS'] = {
  :host => redis.host,
  :port => redis.port,
  :password => redis.password,
  :db => redis.path[1..-1]
}

# Parse Resque Schedule YAML.
if Saneconf.conf['RESQUE_SCHEDULE'].class == String
  Saneconf.conf['RESQUE_SCHEDULE'] = YAML.load Saneconf.conf['RESQUE_SCHEDULE']
end

Saneconf.conf.freeze

All this does is check for the existence of a settings.yml and load it’s values into our (currently) empty configuration hash using an in-place #merge!. The reason we do this is because we very purposefully didn’t supply a mutator Saneconf.conf= for our config hash. We don’t want it to be overwritten later on. For the moment though we can change existing keys and add new ones. Next we handle all non-scalar configuration by parsing some of the scalar ones into hashes. Arrays or any other Ruby object could be placed in the conf hash. It just happens that Hashes are commonly used by libraries like ActiveRecord and the Ruby Redis interface for initialization. The reason I expand those here and not in place at point-of-use is mostly personal preference. All I ever want to see in the app is conf['VARIABLE'] and I shouldn’t have to think about it and whatever I’m trying to accomplish at that point in our app. Lastly, we call #freeze on the conf hash. This is a method every Ruby object has which makes it immutable, throwing an exception if an attempt is made to change it. This way, any of your fellow developers will know that whatever they’re doing belongs in your application initialization code and not in the middle of your important code. Hopefully this proves helpful, the example code is available on GitHub.

Good hunting, Steven!

Firstly, I’d like to thank Engine Yard for knowing that geeks tend to be inter-disciplinary and enjoy geeky discussion of things other than code! They also made an excellent choice in inviting Craig because he’s clearly one of the biggest geeks on the planet… in the field of Scotch Whisky. Since the Whisky dinner was at Engine Yard’s office a group from the Convore chat for the conference decided to meet at and walk from the hotel. I had to run back to the Nowmov office to grab the rest of my stuff since I was intending to take the train home directly from dinner. So myself, Steve Klabnik, Tom Preston-Werner and his wife, and a bunch of other folks from the conference all walked down over together. About three blocks from the hotel, I found $20. I’m not lying, nor am I lying when I say that that was without a doubt the worst part of my evening. The rest was just that awesome. Upon arrival we were told to snag t-shirts, which were created specially for the evening and parodied GitHub’s “Fork You” shirts, which you can customize with your GitHub handle by placing your name on the back in the blank after http://github.com/________, in case you haven’t seen them yet.

After snagging a shirt, we were directed toward the “soft drinks” which consisted of Guinness, Stella Artois, and Lagunitas IPA. It was hard not to notice the sea of clear plastic cups all around us, each filled with a small measure of brown liquid. I had a beer or two over good conversation while Craig and Randall were finishing up. I have to admin, I was a little anxious to get started as I noticed that on the last table was a bottle marked Lagavulin, which is a distillery which comes highly recommended by @vanden and @mcnalu on Identi.ca, but which I haven’t been able to try yet. Add to that, the fact that it is getting on toward 8:25 and the last train home for the night departs at 9:15 and is a ten minute walk away. Things finally start up and Randall introduces Craig, who is very tall and has been wandering around enigmatically the whole time. After a brief introduction by Randall, Craig tells us a little about his history and current job:

The only difference between myself and an alcoholic is I get paid.

He launches into the official definition of Scotch Malt Whisky which is any spirit which meets the following criteria:

1. It is made using malted barley from Scotland exclusively.
2. It is distilled in Scotland.
3. It is aged in oak barrels for a minimum of three years.

That’s it, that’s all that you need! Once everyone is on the same page, he introduces us to the first whisky of the night.

Johnnie Walker Black Label

The Johnnie Walker, he explains, is significant because it sells. And provides jobs for a vast number of people relative to the other distilleries. Economic reasoning aside. We also discuss the very quick finish of the Johnnie Walker which attempts to make up for some of the sweetness, whilst simultaneously letting you get another glass without delay.

Glenfiddich 12 Year

Throughout the night, Craig’s explanations of the different whiskies was both narrative and informative. Even if you didn’t care a hoot about the history of Scotch whisky, he carried you forward with the story of it. I certainly saw more faces in rapt attention than lost in smartphones. The Glenfiddich itself was as smooth as I remember it being when I sampled some at Christmas, it lacked the complexity of some of the ones we had later that night but I’ll definitely consider it as a potential light whisky, or breakfast whisky, as Craig called it.

Aberlour 12 Year

The Aberlour was the first of these that really got my attention, it was complex yet smooth and had a much stronger oaky aroma than the others. Not much was said about the Aberlour distillery itself though the transition topic between the Aberlour and the Macallan discussed the difference between Scotches from the Highlands, Speyside, and Islay. The gist of which was that they have historically produced whiskies with certain characteristics but that the region is no surefire indication of the actual product.

The Macallan 12 Year

I found the Macallan to be a little underwhelming, considering it’s such a high profile Scotch. It certainly wasn’t bad, mind you, but it’s priced much higher than Glenfiddich and has a very similar flavor profile. Though, I may have to revisit it as I drank it rather hurriedly in order to get to the first of the peated Islay whiskies.

Caol Ila 12 Year

Wow, just, wow. This was the stand-out Scotch of the evening for me. Tremendously oak aroma which was also present, though subtler, in the taste. The Caol Ila did not taste as peated as the Lagavulin or many of the whiskies later enjoyed in the smoking room but it really made up for it with the great oak flavor. I’m just raving at this point so I’ll say no more about it.

Lagavulin 16 Year

Before the Lavagulin we were treated to a brief and somewhat premature announcement regarding the Fandabbydozy and the difficulty getting it into the country, but more on that later. The Lagavulin has been recommended to me by @vanden for some time. Basically since I asked the internet for Scotch recommendations. Sadly I was never able to locate any. But Craig provided I actually recall feeling a little underwhelmed by it, but I expect that’s because I was so keen on the Caol Ila. This is another one I want to try again a little earlier in the evening.

Non-Smoking Room

After the Lagavulin we were released into the wild to to visit the three rooms which had been mysteriously marked Smoking Room, Non-Smoking Room, and Exam Room since our arrival. Those who were familiar with certain properties of Scotch like myself probably guessed at the difference between the two rooms and were correct. The Non-Smoking room held the unpeated whiskies. In here I tried things like the Macallan Cask Strength and the Clynelish 14 year, which was my favorite of the non-smoking room. There was a third bottle in here but I can’t recall what it was as there was no room for it on the back of my shirt.

Smoking Room

This is the room for me I knew it’d be awesome, what I didn’t know was just how awesome it would be. My notes rapidly begin to decline in quality in this room. So I know the scotches were excellent. In here was an Ardbeg 12 Year, the Laphroaig Murray McDavid, and again, a third which I cannot recall because I ran out of room on the shirt.

Exam Room

When he introduced the other two rooms, Randall also introduced the exam room. In this room there were a number of cups containing an unnamed spirit. Our goal was to try some and identify in as much detail as we could, using the techniques we learned from Craig, the spirit in the cups. Everyone would pitch their card with their guess written on it into the pile and the winner would get a bottle of something wonderful to bring home. I was one of the last people in the room and submitted my scrawled flavor notes just as they were getting ready to pick the winner. What I wrote follows:

• Cardamom, floral, juniper
• Almost like a genever
• no peat
• 47% - 55% a.b.v.

The instructions were to put as much detail as you could, so I rather hubristically attempted to add some technical details in the hopes that it would set me above the competition. It also proves I was pretty well into it that evening. As it turns out, the exam room contained a gin rather than a whisky, which had been aged in oak barrels. It was really good and I’ve been informed that it’s available at Bi-Rite in San Francisco and intend to make my way down there to get a bottle for myself as in addition to my newly acquired scotch habit I’m also a gin drinker. So I wasn’t all that far from the mark and I have to confirm with Randall but I’m pretty sure the alcohol content conforms to my guess as well. However I didn’t take first place since a gentleman from Engine Yard had received a bottle of the very same gin for his birthday and had sampled it the previous night. There are two possible reasons for the events which followed. Either everyone else was way more drunk than I was, or I have an incredibly silver-tongued alter ego when drunk. I managed to convince Randall that A: The guy from Engine Yard kinda sorta cheated by having had some the previous night, and B: There should really be a runner-up prize anyway. By the strangest of coincidences I just so happened to be the runner-up. Fancy that!

At the end of the night, they found an untouched bottle of the Murray McDavid to award me with and I have been saving it for the launch of my side project which I will talk about in a later post when it’s closer to being done. Right now the powers that be (school) have conspired to take all of my free time and replace it with homework. If there’s any justice I should have it up and running by the end of May, but Tanj!

Fandabbydozy

What can I say about it… well, the Fandabbydozy was brought from Scotland under unusual circumstances but we drank all the evidence of it away so it should be fine to discuss. It was excellent. Certainly the first time I’d had a single cask whisky. I didn’t pick up as many of the flavors described on the bottle but I certainly did enjoy my first, and second, and third drams of this bottle. (Randall was very generous with it though I tried to protest and let other people enjoy it.)

Photo credit goes to Jacob Helwig.The originals are [here][1]

In the End

All in all, it was a great night, I took home a bottle of Laphroaig for my fanatical devotion to flavor and by the time I left I was sober enough that I got back to Union Square without getting lost. Thanks again to everyone at GitHub and Engine Yard, the CodeConf speakers, fellow volunteers and attendees, and in particular to Tom and Theresa Preston-Werner, Jacob Helwig, Steve Klabnick, and Chris Bertels, all of whom were a source of excellent conversation throughout the weekend. It turns out Chris and I work in the same office suite, with different folks and in opposite corners so I’ll likely be pestering him about Fancy for some time. And lastly, a HUUUGE thanks to Craig for his fantastic presentation and excellent conversation. I look forward to having a few drinks with you next time you’re in San Francisco. If anyone would like more detail on the scotches or topics I wrote up here, I urge them to ping @whiskycraig on Twitter.

Complete List of Drinks

• “Soft” Drinks
  • Lagunitas IPA
  • Stella Artois
  • Guinness
• Main Stage
  • Johnnie Walker
  • Glenfiddich 12 Year
  • Aberlour 12 Year
  • The Macallan 12 Year
  • Caol Ila 12 Year
  • Lavavulin 16 Year
• Non-Smoking Room
  • Macallan Cask Strength
  • Glengyle
  • Clynelish 14 Year
• Smoking Room
  • Ardbeg 12 Year
  • Murray McDavid
• Exam Room
  • Ransom Old Tom Gin
• Special Appearance
  • Fandabbydozy Single Cask

• Set aside 10 minutes.
• Get good speakers or good headphones.
• Set aside ten minutes to play both these videos at once.
• Open both these videos at the same time in tabs. They are both sound only. http://www.youtube.com/watch?v=sXU3RfB7308 with http://www.youtube.com/watch?v=IkmwzG7cB_U

You are listening to James Earl Jones (voice of Darth Vader) reading Edgar Allen Poe’s ‘The Raven’ with Claude Debussy’s ‘Nuages’ playing in the background. You may need to turn Vader down so the music can come out.

This is fucking cool.