Instead of upgrading to the iPhone 4, I decided to get a Nexus One from Google. I’ve had it about a week so far and I’m happy with it.. Some friends and colleagues have asked for my impressions, so here is a brain-dump of the highlights so far:
All that being said, I love my iPad and if I didn’t have it I might not have been able to so easily let go of the last remaining Apple mobile device I had available to me. If anyone wants to send me an Android tablet I’d gladly evaluate and review it.
Since finishing The Passionate Programmer I’ve been putting a lot of thought into how to package the advice from the book into something more structured, serial, and prescriptive.
The Amazon reviews for the book are almost all glowingly positive with the occasional piece of constructive criticism. Here’s one such excerpt from an otherwise positive review by Ira Laefksy which I agreed with and took to heart:
Ira and I have the same idea. What I think we’re both looking for is a career development methodology.
As an example methodology pulled from the software field, Extreme Programming has always been codified as a set of distinct practices, all of which can be beneficially understood and adopted on their own. But, as the famous flowchart shows, XP doesn’t just give you a bunch of great ideas about how to develop software. It tells you what to do when you get to work each morning.
The idea of following a software development methodology is nothing new to any of us in the field. It’s common practice. Software projects are expensive, complex and (sometimes) important. Letting them chaotically emerge isn’t a reasonable approach for a professional to take.
So why should our careers be any different?
Mike Swaine recently approached me about writing an article for the Pragmatic Bookshelf’s PragPub issue #3. I decided to use this as an opportunity to explore some of the ideas I’ve had about crystalizing the advice from The Passionate Programmer into a prescriptive career development methodology.
I think I’m onto something, but I’d like feedback. The article, titled “Clone Yourself – Destroy Your Job Through Automation and Outsourcing”, contains just the beginnings of what I have in mind. Please go read it and let me know what you think.
Yesterday I asked on Twitter whether anyone was successfully using is_paranoid in a Rails application, because I had confused myself into thinking it couldn’t possibly work.
The problem I was having wasn’t is_paranoid’s fault, but it turns out it actually can’t do what I wanted it to do in its native state. The explanation of why is something I thought a number of Rubyists might benefit from hearing, so here it is.
Briefly, an explanation of is_paranoid: if you declare an ActiveRecord model to be paranoid, whenever you attempt to delete that model, is_paranoid will instead set a flag which indicates that the record is deleted. is_paranoid uses default_scope to filter out soft-deleted records in your queries. So you can act as if records are deleted without actually removing the rows. If is_paranoid is new to you but sounds familiar, you might be thinking of acts_as_paranoid, which is Rick Olson’s original implementation of this idea.
What I wanted to do for the specific application I’m working on is to declare that every model should inherit the is_paranoid behavior. Easy enough, I thought, given the way these things typically work in Rails’ inheritable accessor setup:
But when I tried to destroy an instance of (for example) Person, the regular ActiveRecord destroy code was invoked and the records were being actually destroyed. Bummer.
So I cracked open the code to is_paranoid and found this perfectly reasonable idiom:
At this point, after pretending I was an idiot for a few minutes, I realized that this code was indeed incapable of doing what I wanted it to do.
Some of you already know why. For the rest of you, let’s talk about how Ruby’s mixins fit into its inheritance mechanism.
Maybe it’s just me, but when I think of something getting “mixed in” to something else, I imagine the two things becoming intertwined. So, the natural assumption when mixing a module into a Ruby class would be that the methods of the module get intertwined with the Ruby class. And for the HelloWorld of mixins, that indeed appears to be the case:
But if you start mixing modules that implement methods the class also implements in, things don’t go quite as smoothly:
Instead of “Overridden do_something” as some might expect, this code prints “Doing something in Thing”.
Why?
Because when we mix a module into a Ruby class, we’re not actually intermingling the methods of the module and the class. Instead we’re inserting the module into the class’s inheritance hierarchy. A good way to see how this works is by using the “ancestors” method:
When a method is called on an instance of SubThing, you can see that it is looked up first in SubThing’s class, then Thing’s class, then in IneffectiveOverride, and so on.
(I used yuml to generate this. Cool site!)
To further demonstrate that mixins don’t really get “mixed in”, notice what happens when you try to include a module at multiple points in the inheritance hierarchy:
If a module is already present at a higher point in the hierarchy, it won’t be mixed in again.
So is_paranoid was apparently built without the goal of being able to mix it into ActiveRecord::Base. Sounds reasonable to me.
As a young self-taught software developer, one of the first books I remember reading was Steve McConnell’s Software Project Survival Guide: How to Be Sure Your First Important Project Isn’t Your Last. Who knows why I picked that one of all the possible books but I somehow knew I wanted to learn something about the broad practice of software development instead of just focusing on how to make specific widgets appear on the screen in Delphi or VB or how to automate the shell on our VAX cluster. I probably happened upon the book while aimlessly thumbing through spines in the local book store and was drawn to the snazzy cover.
And so it was that one of my first experiences in learning software became project-focused. “How to be sure your first important project isn’t your last” indeed. This thing called software development was apparently all about doing projects.
I was not alone in this understanding of how software development worked. Most of the people I encountered in my professional life approached software work this way. When something needs to get done, the first step is to name it—sometimes with a silly code name and sometimes with a generic name like “the HR system project” and the next step is to start planning the project.
I’ve started to notice a bad habit. Whenever I need to do something I don’t want to do. Or, worse, something that I want to do but I am prone to procrastinate (according to The War of Art procrastinating something is a sign that it’s important). The bad habit is this: I turn it into a project.
Projects are lovely for procrastinators. As soon as you call something a project, you give it permission to not be completed right now.
Events such as the Rails Rumble have shown that it’s possible to finish software projects in two days that might take a corporate development team weeks or months in a normal project scenario. What’s the difference? Do the Rails Rumble participants throw quality out the window? Do their apps suck? Do they avoid testing and cut corners? Yea, sometimes. But so do most corporate development groups. That’s how things are.
I’ve learned over the course of my career that the amount of time I spend on something doesn’t positively correlate to its value or quality when finished. In other words, if I do something really quickly, it’s not likely to be less valuable than something that takes me a long time to do. Within obvious limits.
So if you want something to take a long time, call it a project. If you want it to get done, just get it done.
For the first several years of my career in IT, I spent a lot of time thinking about what I’d rather be doing while at work. I might be in a meeting, talking about how to improve the uptime of a billing system. Or putting together time cards for a weekly report. Or programming in a language I knew wasn’t as good as the one I used at home when I was free.
I was frustrated. Not extremely frustrated most of the time. Just a little frustrated. Because there was always something I’d rather be doing than the job I spent the majority of my waking time on.
For me, the question of what I’d rather have been doing was answered roughly as such: working with people smarter than me using the best tools available to build something that solves real problems well. In my spare time, I worked on Open Source code in Ruby and collaborated with some of the smartest developers I’ve met. At work, I wished I was doing what I did in my spare time.
Within the structure of my job, there was yet another telling question with a telling answer. What job would I have rather been doing? For me and most of my co-workers, there was always that next job we were after. Someone was doing it and doing it poorly, and we wanted a chance. That’s how humans think, I guess.
So with these goals in sight, I made daily choices that were usually geared toward driving me toward achieving them. I wanted to work with Ruby, so I spent my free time learning Ruby from top to bottom. I read and tinkered with the interpreter source and experimented (and failed sometimes) with different styles of Ruby development, testing, an what-not. I wanted to work in a team that understood software development processes, so I practiced XP practices when possible and immersed myself in development practices such as Test Driven Development. I wanted to work with people smarter than me, so I befriended and collaborated with as many as I could—-again in free time until I could find the right opportunity to do it for work.
These investments paid off. In 2005, I moved out of the upwardly mobile corporate management job I was in and into a development position on a small, talented team of Ruby developers. I’ve gone from that to independent consulting to training and book writing to working with the team at InfoEther (led by Rich Kilmer, one of those smarter-than-me people I mentioned earlier).
This month, as the expanded and renamed second edition of my first book is released, I find myself returning to the primary question that drove me to where I am today: What would I rather be doing? It’s weird, but for the first time I don’t know.
The title of the new book is The Passionate Programmer: Creating a Remarkable Career in Software Development. The book covers the approach I and others who have inspired me have taken in creating a remarkable and satisfying career. It’s an expanded version of the first edition with not only new and revised content by me but essays by software developers who have inspired me throughout my career and a foreword by David Heinemeier Hansson.
I believe strongly that passion is the most important ingredient for creating a remarkable career and doing excellent work. That’s easy to say and probably not too hard to agree with, but it begs the question of what you should do if you’re not passionate about what you’re doing. How can you find your passion? What advice can I give to someone who hasn’t found it but wants to?
Again, I don’t know. But I think a good first step is to ask yourself the question: “What would I rather be doing right now?” And then, “Why is that not what I’m doing?”
Continuing my series of RailsConf Speaker Interviews we have Neal Ford and Paul Gross of ThoughtWorks.
Neal and Paul have been working on some huge Rails applications at ThoughtWorks and will be talking about how they do it in the session, Rails in the Large:How We’re Developing the Largest Rails Project in the World, at RailsConf.
Neal: I think the opposite is true: Java is good for small applications and Ruby is better for large, strategic projects. For small Java projects, there are tons of libraries and frameworks available to kick-start the project. The inherent limitations of Java don’t bite you as much because you’re building a small, simple thing. For large projects, you need a powerful language that doesn’t get in your way at every turn, and you need a framework that allows graceful extension. In fact, for large projects like this, the purposefully leaky abstraction of AciveRecord allows for smarter tuning.
If you pull the string on the back of my neck, I’ll say “Scaling is hard”—no matter what technology you choose. For our current project, we would be able to get better raw execution speed from using Java, but that’s only a small part of what needs to happen to build scalable systems. Lots of things go into building scalable systems, they are just different things depending on technology.
Paul: I actually think Rails is better for both small and large projects. It is incredibly easy to spin up a small Rails project and get going. We have had teams release Rails sites into production in only a couple of weeks. On the other end of the spectrum, the flexibility of Ruby and Rails means that the framework stays out of your way. When Rails is doing something that we don’t want, we can easily extend to get new behavior. For example, we work around ActiveRecord to write better SQL, we work around the MVC pattern to write Presenters when the display logic is sufficiently complex, and we even wrote our test runner to distribute work to make our test suites faster.
In general, however, many of the problems are the same on a massive project, regardless of Java or Rails. For example, we have to constantly strive to keep build times low, database performance high, and consistent patterns throughout the codebase with 20 developers hacking away.
Neal: When we first started recommending Rails to clients, we had to bring it up. Now, we have companies that ask us to do Rails projects. As for the types of companies, it’s all over the map: trading firms, auction sites, insurance, even a touch-screen jukebox! I don’t think that the type of company makes any difference, it’s their attitude about their software development. Companies that view software as an important strategic advantage tend to be closer to the cutting edge, and are more tolerant of innovative solutions. Companies that view software as purely overhead always stick with the status quo.
As an example of this, we have one client who created a “standard” Java-based stack for all their software. After spending 1.1 million dollars building a huge Portlet, EJB, Spring, Hibernate, Cocoon, XSLT, etc. application to service 5 users, they realized the unsustainability of that model. That company has since changed their “standard”: all applications must be written in Rails unless suitable justification exists for a different solution.
Paul: Ditto Neal.
Neal:It depends (hey, I’m a consultant!). Really crazily scalable sites (ala Amazon) would be difficult to build in Rails; a lot of attention would have to be paid to lots of things to get it right. We have chosen not to use Rails on some projects where it was on the table, but it was for sites like media sites, with huge numbers of concurrent users, streaming media, and other characteristics. We try hard to ThoughtWorks to not become religious about tools. Some tools are better suited to some jobs.
However, having said this, based on my experience on multiple Rails projects, I have expanded my ideas on where it would be suitable. I’m quite impressed at how linearly Rails can scale up to large-scale projects, as long as you have technical leadership that knows that they are doing.
Paul: For me, the biggest factor against Rails would be the corporate environment. If the company has a policy that everything must be deployed on IIS and use MS SQL Server, perhaps Rails isn’t the best choice. If the company has teams of Java developers who aren’t willing to learn a new language, it is probably best to stick with Java.
Neal: Beyond measure. The only way our code base maintains sanity is through rigorous testing. In fact, this project has spawned several open source testing tools in the Rails community: dust, Selenium Grid, and deep test. Testing is ultra important, and the tech leads on this project have created a really nice workflow around tests. We want unit tests to run really fast, so we use dust and forbid database access during unit tests (we use mocks instead). For functional tests, we enforce the rule that tests do hit the database and you can’t mock anything. For a long time, all the pairs on this project were using Mac Minis, which are underpowered for running lots of tests, which spawned the birth of Deep Test. Deep Test allows you to spawn multiple remote threads to run functional tests. Because our functional tests run inside of a transaction, all our tests are completely orthogonal to one another. When the functional tests start, it spawns multiple processes on several BAMs (Bad-ass Machines) to run the tests. Recently, the whole project was upgraded to 8-core Mac Pros, and we switched Deep Test to use the local processors. Instead of taxing one processor, it pegs all 8, running the entire suite of tests in about 6 minutes.
You have to have testing on all code bases. Period. But it’s even more important in dynamic languages, and especially as you scale up the size of the code base. Insanity would ensue if this code base had no tests; it would collapse in a matter of weeks of trying to maintain it.
Paul: In addition to what Neal said, we use tests to enforce processes that would be forgotten otherwise. For example, if someone forgets to add a translation to a set of files, we have a test that will fail. If someone accidentally creates some bad HTML, we have a test that will fail. Furthermore, on a large team with a large codebase, developers come across code on a daily basis that they know nothing about. Tests act a description of what the code should do and why. It’s a living piece of documentation.
Neal: Convention over configuration is one of the “obvious in hindsight” features in Rails that has really impacted the whole industry. How many frameworks now brag about this feature? In the Java world, we went down kind of a bad path for a while, where we came just short of building configuration entries for what planet the code was written on. We still use convention over configuration heavily, and not just the Rails version. As much as possible, we try to create everything with sensible, overridable defaults. I don’t really see any end to how much this particular aspect of Rails will scale.
Paul: The obvious answer is sometimes :). One of the great things about Rails is that when the opinions do not scale, they are easily worked around. We can use plugins and gems to radically alter the behavior of Rails, or just do it ourselves.
For example, one opinion of Rails is that all tests hit the database. This opinion does not scale well to the size of our test suite, so we use gems like UnitRecord to cut off the database for unit testing. Another opinion of Rails is to split up tests by models/controllers/etc. We wanted a further split of test type (unit/functional/externals/acceptance). To accomplish this, we simply made our own test folder hierarchy and reworked the standard rake tasks. It was not difficult.
Yesterday, I asked Twitter:
Rails programmers: what's an example of one thing you find in other people's Rails
code that you (almost) always consider to be wrong?Quite a few people responded, and several asked if I’d post the aggregated answers. Here’s an attempt. I don’t necessarily agree with everything here. I’d love to hear more of these in the comments.
@briandoll’s response was particularly interesting:
extensive logic in views. If the erb would be ugly and harder to pull off in
haml, it's likely a code smellThis is something I always liked in Java about XMLC:http://www.enhydra.org/tech/xmlc/index.html. It was really hard to end up with a mess of co-mingling code and views, because you would have to work harder in XMLC to even make that possible. Amrita used to have that same characteristic, but I’m not sure it still does (or if it is even maintained).
I’ve been resistant to HAML but maybe it’s time to give it another look.
Also, as @mbleigh points out, any code in views is suspect. CSS should be in CSS files. Javascript should be in Javascript files.
Enough said.
@seancribbs singles out auto-generated tests. I’ll have to agree with him.
@alancfrancis says simply “rspec”. Certainly not a religious topic. I’m sure if you could somehow see in the code which editor someone used, we’d see a lot of TextMate, vi, and emacs in the responses.
@brendanbaldwin says “I’ve seen Polymorphic Associations and Single Table Inheritance abused to absurdity.”
As have I. I’ve also abused them to absurdity myself. The storage of a column called “type” which holds a class name is a pretty good indicator that something fishy is going on. It’s fishy but not always bad. I think, though, that any time you use it you should ask yourself more than once if it’s the right solution. Databases don’t do what they do best as well when you have lots of STI and polymorphic associations.
I once had to debug a problem with a commercial, Java-based portal product. The mail module was failing, saying it couldn’t connect to the mail server. In fact, what was happening was my login credentials were incorrect. Guess what the offending JSP looked like (pseudo-code)?
try {
// do everything here
} catch (Exception e) {
out.println("Unable to connect to the mail server") ;
}Exceptions are one of the only places in Ruby where you rely on checking the classes of objects to do useful and interesting things. Never rescue Exception unless it’s at the end of a stanza in which you’ve already handled one or more other exception types.
UPDATE: from the comments, Phil didn’t mean what I typed here:
That’s not actually what I meant. Never rescue Exception unless you’re working with code that abuses the
exception hierarchy. In normal circumstances you should be rescuing StandardError instead. If you rescue
Exception, you won’t even be able to ctrl-c your way out of your code(!) among other problemsMore info on his weblog here
class Potato
attr_accessor :size
end
potato = Potato.new
potato.instance_eval do
size = 123
end
p potato.size
# => nil
Ruby’s assignment to method-call syntax sugar only works when there’s an explicit receiver (such as self.size = 123)
Always run with -w. Fix any warnings you see. A good place to see them is when running your application’s comprehensive test suite.
RJS, render, nested named routes, and ERb are the targets of these criticisms.
validates_uniqueness_of is a strange critter. It’s so easy to use, that it’s tempting to slap it into your code and consider it good enough. But even the documentation for it warns you:
Using this validation method in conjunction with ActiveRecord::Base#save
does not guarantee the absence of duplicate record insertions, because
uniqueness checks on the application level are inherently prone to race
conditions.Here are some rules of thumb:
If you create your own configuration file and have to check RAILS_ENV, you’re not using a built-in facility of Rails.
OK, so this isn’t really what he meant. But it’s a good thing to think about. If you find yourself writing a lot of code to do something simple, you might be missing something Rails (or a plugin) provides. I’ve seen a whole lot of wheels re-invented inside models, controllers, and helpers. Part of Rails mastery is learning to ask yourself, “Shouldn’t somebody have already done this for me by now?”
Seems like if you find yourself manipulating Ruby’s load path in your Rails code, you’re doing something strange. If you don’t know you’re doing something strange, then you’re probably doing something wrong.
As Dave Thomas likes to say “Don’t not use positive logic” (or something like that).
Can someone tell me where the use of ”!!true” crept into the Ruby vernacular? Sure, it’s syntactically valid to do:
!!!!!!!!!!!!!!!!!!ok?
But why?
It’s April 1st, so my mind wanders to the hypothesis that someone introduced this and started spreading it as an elaborate joke. If so, well played. Is there a good use of this idiom I’m missing?
ActiveRecord migrations define a simple API/DSL for doing schema manipulation. But when they run, they’re just Ruby classes and methods executing within the Rails environment. So you can do anything you like in that context.
Sometimes people use migrations to load seed data. Pratik doesn’t like this.
I’m on the fence on this one. In small doses it doesn’t strike me as a horrible practice. That being said, I don’t tend to do it. I’d be interested in hearing opinions.
I guess it depends on what you’re doing with the parameters. Sometimes long parameter lists on GET requests are a sign that there are two actions’ worth of work happening in a single action. Or that you’re doing something that belongs behind a POST or PUT. This one doesn’t bother me as much as it does @Adkron.
if foo.save && bar.save
if bar fails to save, foo doesn’t. Oops. I’ve seen this more than once in the wild.
Obtrusive Javascript and RJS are the themes here.
What’s the worst use of RJS you’ve seen? I love RJS. I may be one of the offenders. Doesn’t feel like it (usually) though.
Smalltalk people, as a collective culture, seem to get this right. Kent Beck documents a simple pattern in his Smalltalk Best Practice Patterns called “Compose Method”. He says that one way to determine whether a new method is required is whether all of the code in a given method operates at the same level of abstraction. That’s a simple but powerful rule. Think about it next time you’re coding and I think you’ll agree.
I agree with Mike on this one. I don’t tend to write any comments, so I may be on the anti-comment side to a fault. My goal is always to write code that is clear enough that comments don’t add anything. If you name everything well and keep your classes, modules, and methods short, you’re already going to make comments redundant in a lot of cases.
Whenever I see a comment inside a method definition, I consider it a bad sign. In most cases, whenever you encounter a comment inside a method, it’s a marker for where code should be extracted into a new method.
If you’re writing a framework, the rules are different. But most of the time as a Rails developer, you shouldn’t be writing a framework.
Twitter is an excellent service for allowing people to vent. I’d guess a large percentage of the messages that pump through the site are complaints about something (technology, airlines, restaurants, etc.). I know I’ve posted my share of complaints.
A couple of days ago, Chris Wanstrath linked to one of his Twitter complaints from a year and a half ago:
failed at setting up a public git repo with working push. giving up for tonight, working on something else.This was probably the first seed that led to the birth of the extremely popular GitHub.
I’m hoping to remember this every time I type in a whiny tweet about something I have the power to fix. Complaining and being critical is great as long as you’re willing to do something about the problem when you can. And, maybe if it’s annoying enough for you to type it into Twitter to share with your followers, it’s annoying enough that a solution could be your next big thing.
I used to think I would end up as a composer of classical music. I studied with one of my favorite composers, Kamran Ince.
The process of composing music is very similar to the process of writing software. In fact, my brain has trouble distinguishing between the two disciplines sometimes. One thing that’s very similar between the two is that they are both abstract and in both cases you start with a blank page (though the “page” for software is typically in an editor on your computer screen).
More than once in my careers (music and software), this has led me to a dilemma: I get stuck because I’m overwhelmed by the limitless possibilities.
This happened to me once as a composer. I was experiencing a sort of writer’s block. So Kamran suggested something bizarre: write a short piece in Sonata Allegro form.
While Sonata Allegro form is an often-used structure for compositions, there aren’t many living composers who use it. It’s old fashioned. So writing New Music in this form is a strange proposition. Kamran framed it as a one-week exercise to stop the writer’s block, and I figured writing something would be better than writing nothing, so I went with it.
What flowed from there was a 25 minute piece for violin, cello, clarinet, and piano (the same instrumentation as Messiaen’s Quartet for the End of Time, which was also an inspiration for the piece) in five movements. As a young composer, this was pretty epic. It was by far the best and most inspired piece of music I had written to date. The whole thing wasn’t in Sonata Allegro, of course. Just one movement (actually just the beginning of the movement). But the constraint had seeded my creativity (how to make it interesting while working in an outdated framework) and had, best of all, removed any fear I had about starting.
I’ve done similar things with software since then. It works just as well.
I was reminded of this today while chatting with Alan Francis, when he mentioned writing Java code with the rule that you can use no braces except where Java forces you to for class and method definitions.
The interesting thing here is that not only does this constraint help to solve the “too abstract” problem but it (arguably) leads to interesting (and maybe better) design choices.
Kelly and I went to The Afterthought in Little Rock last night for the Monday night jazz show. They’ve been running Monday night jazz at The Afterthought for 14 years now. Before that it was at a place called The Oyster Bar (that was when I lived in Little Rock and briefly played jazz music here).
The same people were there that were there last time. They had more gray in their hair, but it was a familiar scene.
The striking familiarity wasn’t the people, though. It was the structure of the event. I never noticed it before (maybe a case of not seeing the forest for the trees), but jazz gigs typically follow a common structure and share a set of common traits:
That’s a whole lot of ritual. And the funny thing is that I bet none of the band members enjoy most of it and I know the audience doesn’t care about any of it. The whole routine is constrained by a set of rules that aren’t done in the name of either the customer (audience) or the supplier (musician). They’re done for no one.
I have done all of these things countless times and I have not ever enjoyed the constraints. It’s only now that I’ve been away from it that I realize the constraints even exist.
I wonder what sort of things I do now that hindsight will reveal to be pointless ritual.
I’ve recently been revisiting my musical roots. I recently visited the home of my dormant music career (Memphis, TN) and spent time former band-mates and collaborators. I’ve been also been dipping back into the jazz and classical composition worlds, learning who’s new on the scene and rediscovering old favorites.
Something has stood out as I’ve been browsing through online material connecting the dots again. It’s a part of the culture I took for granted as a musician but which now feels sort of foreign. Musicians often talk about each other (and even themselves) in terms of their influences.
An example:
Among Dolphy's early influences were Charlie Parker and the sounds of nature.It’s also common to talk about who taught you as a musician. Here’s a snippet from my college roommate/bandmate’s bio:
Chris Parker was born in North Little Rock, Arkansas. He first learned from local Arkansas musicians, most notably: Charles Thomas, Art Porter, Sr., Bob Steele, Lee Tomboulian, and Michael Bates. Chris moved to Memphis, TN in 1991. There he received his BA degree from the University of Memphis and learned from/ studied with musicians including Gene Rush, James Williams, Herman Green, Fred Ford, Calvin Newborn, Bill Mobley, Alvin Fielder, Kidd Jordan, Joe Jennings, and Vernel Fournier.
This creates a strong emphasis on creating a tradition which is carried forward and evolve generationally. Jazz is a fairly new genre but here’s an example “family tree” of jazz: Lester Young was influenced early on by Frankie Trambauer. Dexter Gordon was heavily influenced by Lester Young. Dexter Gordon was in turn the biggest influence on a young Virginia Mayhew.
So we have Frankie -> Lester -> Dexter -> Virginia -> ???
This visible passing on of tradition not only conveys a pride in the craft, but it gives listeners an understanding of what to expect when approaching a new artist. Not a completely road map but at least some clues.
In My Job Went to India I wrote about standing on the shoulders of giants in our industry. Musicians make explicit which giants they’re standing on the shoulders of. It strikes me as a bit of a shame that we don’t do that as programmers.
Not that it should be too surprising to me, but (even as a long time Rubyist) I’m finding the Haskell posts on Slick or Slack to be the most beautiful so far. When I took my first look at Haskell years ago, I thought it was ugly. Every progressive year it strikes me as more and more beautiful.
Why am I not a Haskell programmer, then? More on this in an upcoming post.
In my previous post, I asked for examples of great Ruby code. I got emails, comments, instant messages, and twitter messages with suggestions. I’d still like more.
But one really cool suggestion came from an idea Bil Kleb and Peter Provost had. They proposed a Hot or Not -like site for code.
I thought that would be fun, so Bruce and I whipped something up in a couple of hours over the weekend: Slick or Slack?.
It’s not done yet, but we deployed it anyway. My experience helping Ze Frank with Color Wars 2008 has convinced me that deploying things that aren’t done is more often a good idea than not. If for nothing else that for mental health reasons.
What we want to do now is to start collecting potentially “Slick” code snippets. This could mean beautiful code, clever code, code which does something awesome, or whatever. You can also post code that sucks. We just need code to start the tallies running.
When you visit the site, you’ll be presented with two code samples, probably doing totally different things. They might even be in different languages. Your job is to choose the better of the two. If you can’t make up your mind, just hit refresh.
I doubt this is going to unearth great code in the same way that I doubt Hot or Not unearths great people. But I hope it will be fun to play with. It will probably be broken and we know it’s lacking some necessary features to make it more useful and/or fun. Suggestions are welcome. Just don’t take it too seriously.
It’s fun to watch the rush to be first to market with a new piece of open source functionality. You probably already know that Amazon released their SimpleDB this week. I was thinking we might whip up a Ruby wrapper but I knew if I just waited a day or so there would already be libraries available. Tonight I checked RubyForge and the three most recent projects are all SimpleDB wrappers:
It will be fun to see which one (or more?) of these gains and keeps mind share. Competition among open source projects is an interesting topic given the abstract nature of the stakes.
In the comment thread of a previous post on this site, Chris Taggart made an interesting criticism of my Facebooker Facebook API. It seems that, on a high level review of the code, he found it to be well-craft and well-tested. His criticism was that, unlike in RFacebook, I chose to implement a concrete set of Ruby classes to abstract the underlying workings of the Facebook XML API away from Facebooker’s users. RFacebook, on the other hands, employs a trick using Ruby’s method_missing, to catch undefined method calls and to transform those method calls into HTTP posts which conform to Facebook’s HTTP/XML endpoints. Here’s what an RFacebook call might look like (from the RFacebook Web site):
friendUIDs = fbsession.friends_get.uid_listfriendNames = []
friendsInfo = fbsession.users_getInfo(:uids => friendUIDs, :fields => ["first_name", "last_name"])
friendsInfo.user_list.each do |userInfo|
friendNames << userInfo.first_name + " " + userInfo.last_name
endThis results in two Facebook XML API calls. The two method calls on the fbsession object are undefined, so fbsession converts them to HTTP posts to the Facebook XML API methods called “facebook.friends.get” and “facebook.users.getInfo” respectively. Furthermore, when “uid_list”, “user_list”, “first_name”, and “last_name” are called, RFacebook again employs a method_missing trick to generate an XPath expression searching for the requested data in an HPricot DOM.
Here’s the equivalent Facebooker code:
friend_names = session.user.friends!(:first_name, :last_name).map do |friend|
"#{friend.first_name} #{friend.last_name}"
endIn this code, the same API calls happen as in the RFacebook example, only we don’t explicitly invoke them.
Chris’s (albeit tentative) concern was that, since Facebooker implements objects and their methods as first-class Ruby constructs, the API would somehow be more brittle and less resilient to potential future Facebook XML API changes.
I found it especially interesting that Chris chose this as his only point of criticism, since RFacebook’s method_missing trick and return of an HPricot XML parser object from each API call were two of the key reasons we decided to scrap RFacebook after writing an application with it and implement our own Facebook wrapper library.
As I started to formulate a response, instead of taking my own motivations for granted, I decided to take some time to question my own assumptions. This all led me to question (and to answer for myself) why we write this sort of wrapper library to begin with. What follows are my answers.
Perhaps the primary reason for building a concrete layer on top of a low-level API like Facebook’s is to make the code which uses it less brittle. The scenario Chris was concerned with was that Facebook might change their API, requiring Facebooker to be changed to match it. My point exactly, Chris. If Facebooker didn’t hide the implementation details of the XML API from its end-users, a change in the XML API would require every application which uses Facebooker to change. Magic missing method calls would have to be renamed or changed. If “facebook.users.getInfo” were to be changed to “facebook.user_info”, the calls to “session.users_getInfo()” would need to be changed to “session.user_info()”.
Sure, you could hack the API so that “users_getInfo()” and its parameters were munged into Facebook’s hypothetical new format, but then our API would pretend to be low-level and direct, which would lead to some opaque application code.
When I’m writing a Rails application controller or the controller for a desktop application (both of which I have been doing with Facebooker), I want to think in terms of the domain I’m modeling. In a Rails application, it’s commonly accepted that fat models and skinny controllers lead to well-factored, expressive, and maintainable code.
This is partially because, in the controller layer of an application like this, the code’s job is to (as Marcel Molina said to me recently) codify a dialogue between the domain objects in a system. In other words, when you’re developing an application about users, their friends, their affiliations, and the groups they belong to, the controller should deal with those concepts. It doesn’t make sense to deal with, say, a user, a database connection, the user’s friends, their XML representation, a shared photo album, and HTTP connectivity issues all in the same code.
My brain doesn’t want to jumble all of that together. When I’m trying to look at XML parsing code, domain logic gets in the way. When I’m trying to see how users and their friends interact, XPath is line noise.
Kent Beck refers to this in his Smalltalk Best Practice Patterns as a guiding principle of good API design, specifically having to do with how to decompose your code into methods. His rule of thumb is that one way you know it’s time to create a new method is when the code in one method mixes two or more levels of abstraction.
By abstracting the implementation details of XML and HTTP away from the high level of the API, code becomes more testable. In this case, it’s true for Facebooker itself, but more importantly, the applications that use Facebooker are more testable with a layer of abstraction between them and the XML and HTTP calls which are going on under the covers.
When you’re trying to test a Rails action, it’s much easier to create a User object and set its attributes (first_name, last_name, etc.) than to generate a DOM of sample data. Sure, Ruby being as dynamic as it is, you could create a stub at runtime and forego dealing with the library’s implementation of User altogether. But you shouldn’t have to.
It may seem like a nitpick, but as a Ruby programmer I want to use APIs that look like Ruby code. “fbsession.users_getInfo()” looks like PHP code to my eyes. It’s no surprise. Facebook is written in PHP, and its HTTP/XML API was designed by the same PHP programmers that created Facebook. Wrapping the Facebook API allows me to isolate and hide the PHP idioms, such that the code I use reads like “normal” Ruby code. You could argue that this is not a technical issue, and you’d be right. But I believe in the power of both consonance and dissonance in software development. Dissonant code stands out and alerts the reader that something strange and exceptional is taking place. Sometimes that strange and exceptional thing is just bad code. Sometimes it’s an unusual technique that should be highlighted.
When I see non-idiomatic Ruby code, it tells me one of two things. The first assumption I make is that whoever wrote the code is not a Ruby programmer. That’s usually the case. The second is that the programmer is employing a new or unusual technique to accomplish something which is difficult to do without that technique.
Having implemented a wrapper for the Facebook API, I don’t think there’s a need for dissonance. There’s nothing difficult or unusual going on at any level of Facebooker, so it stands to reason that there should be no dissonant section of the library and that it should all read as idiomatic Ruby code.
I love the tricks you can do with Ruby. method_missing, const_missing, autoloading, and their friends make really powerful things possible.
But they do so at a price. When something goes wrong in a piece of code that relies heavily on one of these tricks, it can be much much harder to track down. So the decision to use such a tool shouldn’t be taken lightly. These are power tools. Used effectively, really cool things can happen. Used incorrectly, you can easily find yourself limb-less and bloody. So when you decide to use one of these power tools, you have to ask yourself: is it worth the risk?
Where possible, especially in a library already dealing with something abstract and out of our control (e.g. someone else’s XML API running on their own HTTP servers of which we have no direct visibility), explicit and concrete are much better attributes than abstract and fuzzy. If you run into a problem or question with part of a library for which you have the source code, explicit method definitions and concrete APIs under the covers are much easier to navigate than parsed method names magically constructing arguments to HTTP posts.
In general, if you’re dealing with code which is out of your control, implicit and hidden from view, it’s helpful if the code which surrounds it balances the abstractness with a nice concrete anchor.
This is a summary of many of the usually-abstract ideas that go through my head when I’m creating APIs that wrap other APIs. I’ve been designing wrapper APIs like this for ages, so it’s been helpful for me to convert intuition into a set of hints. I hope these ideas are helpful to others. If nothing else, if you ever have to use an API I’ve written, you’ll at least know why it’s written the way it is.