In celebration of the awesomeness that was ClojureConj The First, I just submitted my first patch to the Clojure core codebase! Still waiting for the Lumbering Wheels of Bureaucracy to turn the Massive Gears of Pending Assembla Membership to open the Gates to the Kingdom of Those Who Have Had a Patch Accepted. But the hardest part is done!
I'm just giddy with excitement. Or sleep deprivation. Or both. Probably both.
Monday, October 25, 2010
Sunday, May 02, 2010
Using Haml with Rails 3.0
One of the things I [heart] about being a Ruby/Rails developer for ThoughtWorks is that I occasionally get asked to do something really cool on the side, like being a technical reviewer for an upcoming book on Rails 3.0.
In this particular book, the author uses Haml instead of Erb for templating views in the sample code. When I'm reviewing a book, I like to actually exercise as much of the sample code as I reasonably can, as it tends to be among the hardest stuff to get right, and among the easiest ways to discourage a reader when it's not right. But Rails defaults to Erb for templating, and I'm not exactly Haml-enabled.
What's a geek to do?
Well, my friend Google had a thing or two to suggest, but the process is slightly non-trivial so I thought I'd collate it here, thusly:
That last bit is particularly important for allowing Rails' scaffold generators to Do The Haml Thang(TM) when generating view templates.
Now back to my regularly scheduled tech review ...
P.S.: The book is going to be awesome. Reserve your copy now!
In this particular book, the author uses Haml instead of Erb for templating views in the sample code. When I'm reviewing a book, I like to actually exercise as much of the sample code as I reasonably can, as it tends to be among the hardest stuff to get right, and among the easiest ways to discourage a reader when it's not right. But Rails defaults to Erb for templating, and I'm not exactly Haml-enabled.
What's a geek to do?
Well, my friend Google had a thing or two to suggest, but the process is slightly non-trivial so I thought I'd collate it here, thusly:
- NB: All commands are entered from your Rails 3.0 application's root directory.
- Edit
[your_app]/Gemfile, and add the linegem 'haml'somewhere convenient. - Edit
[your_app]/config/application.rb, and add the lineg.template_engine :hamlto theconfig.generatorsblock (uncommenting the block if necessary). gem install hamlbundle installhaml --rails .git clone git://github.com/psynix/rails3_haml_scaffold_generator.git lib/generators/haml
That last bit is particularly important for allowing Rails' scaffold generators to Do The Haml Thang(TM) when generating view templates.
Now back to my regularly scheduled tech review ...
P.S.: The book is going to be awesome. Reserve your copy now!
Saturday, May 01, 2010
Enter the Lich!
So I've finally spent a little bit of time unpacking and bookshelving my trove of geek books from my move last summer. Among many that I want/need to read Real Soon Now (TM), the book "Lisp in Small Pieces" by Christian Queinnec caught my eye and reminded me that I need to actually do something about learning Clojure.
So I've set out to implement Lisp in Clojure, following Queinnec's book. I've put the shell of the project -- featuring 100% test coverage; go me! -- on GitHub, at http://github.com/davidrupp/lich. For some reason I haven't taken the time to obsess about (yet),
This should be fun ...
So I've set out to implement Lisp in Clojure, following Queinnec's book. I've put the shell of the project -- featuring 100% test coverage; go me! -- on GitHub, at http://github.com/davidrupp/lich. For some reason I haven't taken the time to obsess about (yet),
lein repl doesn't include the project's src directory on the CLASSPATH, so you can't really require your code and play with it in the REPL. So I've included my own in script/repl. I suspect that once I really get the hang of unit testing I won't need/want to rely on it so much, but at least it's there for now.This should be fun ...
Sunday, March 21, 2010
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.
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.
Monday, January 18, 2010
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.
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.
Subscribe to:
Posts (Atom)