Jesse Wolgamott has launched a training course called Ruby Off Rails, which is geared toward helping existing programmers learn Ruby first, and not Rails.
I heartily endorse this and highly recommend this approach if you want to “get into Rails”.
Anyone have a (formal / step-by-step) protocol for code reviews?
Yes, I do. At Opower, we were pretty serious about code reviews. We didn’t review every commit, but we did review a lot, and, after a while, fell into a pretty decent routine. This is an adaptation of that that I think is pretty decent.
When creating the outline for my book (now officially published and in print!), I decided to organize it around the nine facets of an awesome command-line app. Each chapter focuses on one of these facets. They state that an awesome command-line app should:
In this post, I’ll illustrate each of these facets (along with a test of the tenth chapter on color and formatting), via a code walkthrough of a simple command-line app I created for work.
Here’s a link to download from my talk on JRuby and Threads.
If you just want the “exercises”, here they are:
The trailer for my book, check it out:
It’s a nonsensical journey through the computer, ending on the command-line. It’s got drama, special effects, and a stern soundtrack :)
When mocking and dynamic typing travel in the same cart, the riders believe nothing can stand in their way. Their movements become headlong - faster and faster and faster. They put aside all thoughts of obstacles and forget the precipice does not show itself to the man in a blind rush until it’s to late.
Apple has just announced Mountain Lion, the next version of OS X, due out in the summer. Although it’s more of an incremental upgrade than Lion was1, one of the most interesting features is Gatekeeper. Gatekeeper, in brief, prevents unsigned code from running on OS X. Although it can be disabled, it’s on by default, and many feel this is the beginning of the end for users having full control of their computers. I feel the opposite: it’s not a slippery slope, and it’s actually a great feature.
In the last two posts about “clean tests”, we talked about the structure of a test, how to eliminate duplication, and how to make intent clear when using mocks. We left off with a question of magic values: Why do we seem to use them in our tests, when we know they are wrong in production code? Let’s explore that and see how to eliminate their use in our tests without making the tests hard to understand.
Hopefully you’ve read Steve Yegge’s excellent kingdom of nouns essay, in which he bemoans a pattern that exists in a lot of Java-base systems. The tell-tale sign is a class named ThingDoer with a single method doThing(). Systems like this don’t arise simply because Java is the way it is, but when you follow SOLID principles (particularly the single responsibility and dependency inversion principles), your code ends up with lots of small classes that do one thing only.
In Java, you are basically stuck with this, but in Ruby (or any OO language that supports closures/blocks/functions), we can fight this by using Procs instead of classes.