In my Ruby style guide, I mention the preference for using Ruby’s tap:
When you must mutate an object before returning it, avoid creating intermediate objects and use tap:
I thought it might be interesting to expand on this.
Was reading the slides from Aaron Patterson’s Magma Rails talk and noticed some pretty innocuous Rails code that, upon further reflection is the beginning of disaster for a growing application. As many other Rubyists are beginning to realize, spreading your application logic across only models and controllers leads to a mess. Let’s look at the code, understand why it’s bad, and create a better version.
Yesterday, I tweeted:
x = Hash.new { |_,_|lambda {}}.tap { |hash|hash[:key] = lambda {}}x[attr].callFilthy?I kinda like it
— ❺➠ David Copeland (@davetron5000) May 15, 2012
This may seem crazy, but it’s a really just an enhanced use of what Steve McConnell, in “Code Complete”, describes as
Table-Driven Methods. Let’s see what that has to do with my crazy Hash construct.
I wrote an article in the latest PragPub magazine called What Makes an Awesome Command-line Application?. Check it out! If you want a more code-focused and detailed version, see The Nine Facets of an Awesome Command-Line App and, of course, my book.
I really enjoyed reading Jesse Storimer’s recent post, 4 Months of ebook Sales, about the sales of his book “Working with Unix Processes”. His feelings echo my own regarding my book, “Build Awesome Command-Line Applications in Ruby”:
I’m ecstatic with the results so far, but I have no idea how they compare.
Our books complement each other quite well, and came out around the same time. He wrote his largely on his own, going the self-publishing route, while I wrote mine with the Pragmatic Programmers. I thought I’d write a similar piece from my experience going the “traditional” route.
Methadone is the ultimate command-line library for Ruby apps. All the power of OptionParser, none of the verbosity, with a smattering of tools to help you write amazing apps right from the get-go. In seconds, you have a fully functioning skeleton of an app, with integration and unit test coverage, documentation, and in-line help. I created most of it while writing [my book][clibook], and have been feverishly polishing it since the book came out.
Today is its first official release at 1.0. Woot!
I’ve also released a tutorial as an “enhanced” iBook, available now from the iBookstore as a free download. This isn’t just a big ream of code and text, but a step-by-step walkthrough, with screencasts, on how to use Methadone, along with some detailed discussion on some of Methadone’s more useful features. It’s all presented beautifully as a “textbook”-style iBook that looks great on an iPad 1 and stunning on the new iPad, thanks to iBooks Author and the retina display.
Read the tutorial, read the RDoc, install the library, and feel free to submit patches.
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: