Review: Pragmatic Clojure Studio

Executive Summary: If you are a developer looking to get into Clojure programming, attend this studio.

Executive Summary (for executives): If a developer who reports to you wants to attend this studio -- let him.

Even if you're at a shop that doesn't allow development in anything as exotic as Clojure -- yet -- you will benefit from this view of a language that embraces the JVM-as-a-platform as richly and effectively as Clojure does. You will learn what Java-the-language could (should?) have been capable of. You will even learn what Java-the-language actually *is* capable of. Much of Clojure is implemented in Clojure itself (homoiconicity FTW!), but a good chunk of it is implemented in Java.

The value of this studio is not the standard nuts-'n'-bolts / grammar / syntax / now-do-some-labs dance of most technical training. The value of this studio is that it's co-taught by Rich Hickey, the creator of Clojure. You will get to hear him talk about the design decisions he made in the evolution of Clojure. More importantly, you will get to hear him talk about the design decisions he *avoided*. You may not agree with all of those decisions, but you have to respect the man's process. Language philosophy aside, Rich's talks on "State and Identity", "Modeling State and Time", and "Protocols, Reify, and Datatypes" will blow your mind, and cause you to think differently about the act of programming whether or not you ever write a line of Clojure outside the studio.

Other not-quite-as-mind-blowing-but-still-pretty-cool topics include functional programming, web development with Compojure, Java interoperability, macros, and method dispatch.

And it's not just Rich who is fun to watch. The studio is co-taught by Stuart Halloway, owner of Relevance, LLC -- a working Clojure shop -- and author of the Pragmatic Programmers' "Programming Clojure". The two complement each other nicely. Stuart is very impassioned, a bundle of energy when it's his turn at the projector. Rich is much more laid back (though still impassioned), and expresses volumes with the arch of an eyebrow or a quirky half-smile at Stuart's antics. Both are eminently accessible and happy to answer questions and interact with students during breaks.

Remember Java in 1995? Ruby in 2005? I went into this studio a skeptic, and I came out convinced that Clojure is going to have a place -- and ultimately a prominent one -- in the landscape of our profession.

Go to this studio. Spend a few days learning from the masters. You'll be glad you did.

Why Should You Want To Work For ThoughtWorks?

Note to self: the next time you're watching Roy (Roy Singham, the founder of ThoughtWorks) give his "How I Founded ThoughtWorks" pep talk to a batch of candidates, stand far off to the side and far enough away that he can't read your name tag.

What brings this up?

I spent a couple days in Chicago this past weekend helping out with our Super Saturday hiring event. And I watched Roy give his pep talk too closely and too directly in his line of sight. Because in mid pep talk he looked straight at me and said, "David, you're a ThoughtWorker, what do you want to add? Why should these people want to work for ThoughtWorks?"

Umm...

I managed to blurt out an impromptu, off-the-cuff, early draft of something like what follows.

Here, after time to think and embellish and re-word and clarify, is the full response I wish I'd given:

Why should you want to work for ThoughtWorks?

If you're like me, you've spent a fair amount of time (over 20 years, in my case) developing software for 'The Man' -- a series of nameless, faceless, soulless corporations. You've worked primarily for managers who fear what they don't understand, and what they don't understand is primarily two things: software development, and you.

At each of the places you've worked, you were led to your cube; isolated, walled off -- but not so much that The Man and his lieutenants can't walk by and easily keep tabs on you. Penned up so that human interaction happens on The Man's terms, not nature's. Guaranteed that every human interaction will require a hard context-switch in interface from keyboard and mouse to whiteboard and mouth.

And you're told 'you're Just a Java Developer'. By which The Man means: don't hassle me with your Ruby, or your Clojure, or your [cool technology here] that you've actually spent some time on your own learning about that could make a difference.

The Man doesn't want you to make a difference. The Man wants you to sit in your cube and write code. It doesn't even have to be working code; at least not at first. The QAs will figure out whether it works in due time. You're Just a Developer. And The Man has a whole raft of inefficient and degrading processes to manage the interactions between the QAs and the Developers.

When you chafe at being Just a Java Developer and you advocate for making a difference -- using force multipliers like Ruby, and Pair Programming, and Test Driven Development -- you're branded a troublemaker. And the guard on your cube doubles. And the degrading processes get more degrading, especially for you.

And then you find out that ThoughtWorks is hiring, and that we need smart people. People who voluntarily spend their free time getting better at what they do, looking for ways to make a difference. People who understand that there is more to software development than Just Java and The Man's inefficient and degrading processes.

And you realize that it's a win-win -- if you work for ThoughtWorks, ThoughtWorks gets another smart person, you get to be that smart person, and The Man fills your pen with a willing sheep and has one less troublemaker to guard.

If you take the plunge and apply, you get a chance to convince us that you can make a difference. And when I say 'us' I mean ThoughtWorkers, people who do what we would be hiring you to do. Not ThoughtWorks HR. Not ThoughtWorks Management. The very same ThoughtWorkers who will be your co-ThoughtWorkers if you're hired. We are not easily convinced. But we are aching to be convinced.

And if you make it through the gauntlet of code samples and assessment tests and ThoughtWorkers, within a couple days of signing the paperwork your butt is in a chair at a client site and you're pairing full-time, ten hours a day, four days a week, writing mission-critical code with people who are smarter than you ever will be.

And here's the coolest part. Not only do you *get* to make a difference (you do). Not only are you *required* to make a difference (you are).

The coolest part is this: you're *expected* to make a difference.

Because you're a ThoughtWorker.

That's why you should want to work for ThoughtWorks.

Learning Japanese, I Think I'm Learning Japanese ...

The gauntlet is thrown.

In my prior blog post about the disappointing contents of some of the sessions at day one of RubyConf 2009 (which is a great conference overall, btw; try to go next year!), I mentioned that some of the presentations were below a standard that I would have expected at the premier international conference for this language/community. As it happens, all of the presenters of the sessions I called out speak English as a second language, and they are all in fact Japanese.

In my defense, I was not talking about the presenters' English skills. Lord knows their English is better than my (heretofore non-existent) Japanese. As an American who has made a point of learning and trying to function in the native language of the countries I've visited (Germany, France, and Italy to-date), I have nothing but respect for anyone brave enough to go anywhere and speak in a non-native tongue to an audience of native speakers.

That's why I've accepted John Mettraux's gentle challenge to gain full perspective by submitting a proposal to RubyKaigi 2010, Japan's version of RubyConf. John assures me that I would not be expected to present in Japanese, but that strikes me as being less than "full perspective". So I'm going to try to learn enough Japanese to not make a total fool of myself (assuming my proposal is accepted). If any of the three of you reading this blog (hi, Mom!) has any ideas for good learning resources, please do let me know.

Ah, but a man's reach should exceed his grasp, Or what's a heaven for? -- Robert Browning

RubyConf Day Two: I Have Seen The Future, And It Is ...

MacRuby.

So day two of RubyConf went much better for me, content-wise. Caleb Clausen gave a subdued, but very interesting, presentation on Ocelot, his version of a Ruby compiler. Yehuda Katz brought down the house with his presentation "Polishing Rubygems", which was primarily about his project, Bundler. Andy Keep had a different take on the topic of partial evaluation to make Ruby more amenable to compiling. And Charlie Nutter was very engaging in his presentation with Thomas Enebo on the status of JRuby, including a cool demo of jirb running on an Android phone (simulator).

But my favorite talk by far was Laurent Sansonetti of Apple, talking about MacRuby. Laurent, who is clearly not a native English speaker -- are you reading this, jmettraux? -- gave a professional, content-laden presentation on MacRuby, which is pretty much his baby at Apple. He had some cool demos -- one of which was nearly thwarted by the hotel's abyssmal internet setup -- of MacRuby's integration with Cocoa/Objective-C, which also demonstrated that MacRuby has already solved the problem of compiling Ruby. XCode will build executables with the MacRuby framework embedded, and it will ship the MacRuby code as binary .rbo files, not Ruby source files. No need to obfuscate or simply give your code away; MacRuby takes care of it all.

Now if only we could get Apple to open up the iPhone to this. Or perhaps build a tablet of some sort ...

RubyConf 2009: Day One

In a word: disappointing.

Oh, the venue (the Embassy Suites at the San Francisco Airport) is nice enough. And yes, there are problems finding power and getting on the internet, but that's to be expected. Anyone who attends a gathering of more than about ten people and actually believes the claims of abundant power and speedy WiFi for all is asking for a let-down. So it's not that.

Maybe it was just my bad luck in the sessions I chose to attend. I was very much looking forward to hearing some of the Ruby core team speak, so I made sure to catch Matz's keynote, "East meets West", and "Hacking parse.y", the latter being interesting to me in its own right since it was about Ruby implementation internals.

Matz has decent presence as a speaker, and the crowd dutifully laughed at all his good-natured, pro-forma digs at other languages' foibles (Java is lame. Lisp has too many parentheses. Et cetera.). But he didn't have anything particularly new or interesting to say about Ruby or language design, just that there can be no "one true" programming language, that the best we can hope for is one that's "close enough", and in his opinion Ruby is currently the best candidate. Go figure. Still and all, the man did invent the language that I currently use to make a living, so major props to him.

The other two were just not up to any reasonable standard for a conference at this level.

Look -- I know the Ruby community prides itself on being edgy. I get that RubyConf is deliberately kept small and scruffy and non-RailsConf-y. But is it really asking so much that the people who present talks at The Premier Conference for their language/community have some basic skill in the art of talking to an audience?

I did find the talk on using Ruby to write DSLs and code generation tools for hybrid systems simulation and scientific computing pretty interesting. And tomorrow's schedule looks good on paper.

Here's hoping it goes better than today.

Dear RVM: It's Not Me. It's You.

Dear Ruby Version Manager,

It's over. I tried. But I just can't do it any more. I though I could let you back into my life after that unfortunate 'sudo gem install rvm' spat we had on our first date. That's on me. But even after I moved you into my home directory, you still couldn't make it work.

I wanted it to work. Really, I did. I mean, a chance to have an open relationship with multiple Ruby's, all painlessly and seamlessly installed and switchable through you? Who wouldn't want that?

But you just couldn't handle my prior relationship with my self-compiled, self-installed /usr/local/bin/ruby, could you? I mean, you ... you ... it hurts just to type it ... you hijacked my $PATH, RVM! You locked me out of my gems! I mean, they weren't all switchable and fancy and all, they were just plain gems, but they were my gems, you know? How was I supposed to trust you after that?

Was it jealousy? Was it ignorance? I guess I'll never really know.

But -- for now at least -- I have to give you up. I have to lash myself to the mast of my virtual Argo, and forego your sweet, seductive siren song.

It's a pity. We could've been something, you and me.

Ruby's inject(): Putting the 'Fun' in 'Functional Programming' Since ... Oh, About 4:15 This Morning

Yesterday at work, I ran across the need to convert a number of seconds into its equivalent in days, hours, minutes, and seconds. The canonical imperative way to do this is something like:

seconds = 356521
days = seconds / (24 * 60 * 60)
seconds = seconds % (24 * 60 * 60)
hours = seconds / (60 * 60)
seconds = seconds % (60 * 60)
minutes = seconds / 60
seconds = seconds % 60

N.B.: This relies on Ruby's integer division -- dividing an integer by an integer results in an integer, with any fractional remainder discarded.

My pair and I ended up implementing something very much like this, but it left a bad taste in my mouth. I mean, it works and all, but it feels kind of ... non-functional. Ya know?

So, after much fretting and sleeplessness last night ... behold:

seconds = 356521

days, hours, minutes, seconds = 
  [1.day, 1.hour, 1.minute, 1.second].inject([]) do |acc, unit|
    quotient, seconds = seconds.divmod unit
    acc << quotient
  end

This version needs to be run in a Rails script/console rather than irb, because it makes use of the Rails shortcut definitions of the number of seconds in various units of time. You could easily convert to plain irb-able Ruby by replacing 1.day et al above with their numeric equivalents.

The resulting code is both (more) functional, and more quintessentially Ruby-ish. divmod and multiple assignment let us figure out the quotient and the remainder of the division in one go, and inject lets us accumulate the results and ultimately multiply assign them to their respective units.

Neato.

I'm a little bummed, though, that this version has the side effect of destroying the original contents of seconds, as well as requiring seconds to be defined outside the scope of the inject. What would be really cool would be to have a version of inject that allowed for multiple accumulators (or, really, a 'decumulator' in this case) such that all side effects could be contained within the inject.