Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Category Archives: Books

Coming Soon: Getting Things Done In JavaScript

Okay, the blog has been very quiet for the last month or so. Please be polite and pretend you noticed. I’ve alluded online to a new book one or two places and now I think it’s far enough along that I can mention it in public without being too scared.

Let’s do this Q&A style, call it an infrequently asked question list…

Q: What’s the new book?

A: Great question. The working title is Getting Things Done In JavaScript. That may not be the final title. My proposed titles, Enough JavaScript to Get By and JavaScript for People who Hate JavaScript were (rightly) deemed unsuitable.

Q: Okay. That’s the title. What’s the book?

A: Here are some excerpts from my proposal:

  • The intended audience are developers used to doing back-end development, probably but not necessarily in Rails, who are increasingly asked to move functionality to the client, and are not familiar with the best JavaScript tools available for the job.

  • This book is aimed at developers who are explicitly working on front ends for web applications and looking for guidance on how to approach the simple parts first and the complex parts as needed. In my head, this is triangulated with three non-JavaScript books that I think are around that level: Beck’s Smalltalk Best Practice Patterns, Olsen’s Eloquent Ruby, and Valim’s Crafting Rails Applications.

  • Everything is test-driven. This book will contain more Jasmine than a Disney princess convention.

Does that help? Put another way, it’s the JavaScript book I wanted to hand our last apprentice when he asked for a good guide to JavaScript. Another way I’ve described the audience is people who have poked at JavaScript a few years ago, just got back into it, and aren’t quite sure why everything is an anonymous function these days. I’ve also called it JavaScript: An Idiosyncratic Guide, as in the thing you use after you have the information in the definitive guide.

Q: Why a book on JavaScript?

A: Because I was a guy who poked at JavaScript a few years ago, just got back into it, and wasn’t quite sure why everything is an anonymous function these days…

Well, that’s part of it. I felt like it was an area where I had something to offer, and where I could leverage the time that I had spent getting back into the latest and greatest JavaScript tools and make it easier for others to do the same.

Q: When can I buy it?

A: The initial draft is maybe 1/3 done. Ish. The hope is to get it available in beta sometime in November, and given the schedule that Pragmatic likes for books these days, to have the final come out something like January. That’s still an aggressive schedule, and I’m probably just a smidge behind, but I have a decent idea where I want it to go, and I’m making steady progress.

Q: What’s actually in the book?

A: The outline is still a bit in flux, but the basic idea is to take a pure server-side application and bit-by-bit move features to the client-side in a slow and not-even-a-single-tiny-bit-contrived way. The JavaScript topics are largely focused on creating what passes for objects, so there’s discussion of the object model, functions and scope, and the like – it’s not (at least at the moment) a tutorial on the basics of JavaScript. There’s a lot of jQuery, and a lot of Jasmine, and there will also be jQuery UI, jQuery Mobile, and Backbone.

That’s the story. Coming soon to a theater near you. Hope you like it.

Advertisements

Bill James, Sabermetrics, and You, or At Least Me

I was a nerdy kid.

I suppose that isn’t much of a surprise, given how I turned out. But in those pre-computer days, I was nerdy about math and baseball. I was the kind of kid that kept a daily log of my batting statistics in the recess kickball games.

So you can imagine my surprise and happiness when this image appeared in Sports Illustrated, in May 1981. I was ten:

Bill James in Sports Illustrated

The man in the foreground is Bill James, who would soon go on to be one of the most influential baseball writers of the last thirty years. At the time, though, he was self-publishing his baseball book to a small but fiercely loyal group of fans, one of whom actually wrote the SI article.

In the background, on the scoreboard, was one of James’ inventions – a formula called Runs Created that purported to be the most accurate way to measure a baseball player’s contributions.

Okay, I’m getting carried away. The relevant point is that I was dazzled enough by the original article to start looking for James’ annual book once he started getting published and distributed nationally. As I said, I was young, and the books cost like seven dollars of my own money, so this was kind of a big deal.

I got lucky in my choice of baseball writers. Not only was James iconoclastic and funny, but he was very good at explaining his methods. And I don’t mean that he was good at explaining the math – James is the first to admit that he is no mathematician (admittedly joking, he once described the “standard deviation” of batting average as “about what your standard deviant would hit”). James’ skill was in explaining why he did his experiments in a particular way. In a very real way, the most important things I learned about how science works were from reading Bill James.

In, I think, the first book of James’ that I read, he responds to criticism of earlier work:

“Journalists start with the answer… [Sabermetrics] starts with the question”

Sabermetrics, by the way, was the word that James coined for the search for objective knowledge about baseball – “saber” from SABR, the Society for American Baseball Research".

In other words, where a journalist would start with “Derek Jeter should be in the Hall of Fame”, James would start with “Should Derek Jeter be in the Hall of Fame?”, and not in the lazy-local-news-headline way where you know from the question where the answer is. More likely, James would start with “What kind of player is in the Hall of Fame? Does Derek Jeter meet that standard?”

I suspect that this distinction is obvious to most of you reading this (though it’s easy to find places in our public discourse where nobody seems to understand it.) But it was a big deal to 12-year-old me.

Later, I remember an epic dismantling of the phrase “Pitching is 75% of Baseball”, starting with wondering what that even meant, and then going one by one through the things that would be implied of that statement was true, determining that none of them actually were, and eventually concluding that even the baseball traditionalists who were fondest of the claim didn’t act in any way consistent with actually believing it. I can still quote large chunks of that one.

Some quotes didn’t really become meaningful to me until I started writing myself:

“One of the operating assumptions of this book is that you either own McMillan’s Baseball Encyclopedia or don’t care what it has to say. In either case, you don’t need me to tell you what an outfielder’s assist totals are”

I’ve used some variant of that comment for every book I’ve written (though it didn’t always make into the final version). I’ve also used in when reviewing books. It’s a really useful way to think about your audience, to realize that you can assume knowledge of or disinterest in certain information.

Another quote that was big with me when I used to read academic papers all the time, but that I also keep in mind when I write.

“This isn’t a bull session, this is science. I only write like it’s a bull session because I don’t like how scientists write”

James is always been a little cranky on the subjects of professionalism and expertise, which he sees as often being used as nothing barriers to keep out the riff-raff.

“When you write something it is either true or false and being an expert or not being an expert has nothing to do with it”

What’s really stuck with me, though is the way James went about seeking more objective knowledge. The process was simple.

  • Ask a question.
  • Determine something that is observable that would be true if the answer to the question is true.
  • Use small, empirical measurements. James is the king of quick-and-dirty measurements that favor ease of calculation and understanding over multi-digit precision.
  • Compare similar items that differ in one aspect. In the mid 80-s James was more excited about a method to measure how similar two players were than almost anything else, because it allowed him to create controlled studies.
  • Follow the data. You probably won’t learn what you expect. Respect the data and respect its limitations.

If you are interested in James’ baseball work, the best introduction right now is probably the Historical Baseball Abstract, which is an overview of both his statistical methods and his historical interests. A more biographical look at his effects can be found in Moneyball, by Michael Lewis, which is about how the Oakland A’s applied James-style methods to actually win games. It’s a great non-fiction narrative, and Lewis is, as far as I can tell, unusually factually accurate.

James’ most recent book is Popular Crime, which is not about baseball, but rather a historical overview of crime stories that become pop-culture touchstones, and also the books that have been written about them. It’s cranky, scattershot, obsessive, and hard to put down.

June 21, 2011: In Brightest Day

I’d like to pretend there was some thread connecting these things, but you and I both know there just isn’t…

1. Actual News: Cucumber 1.0

Starting with something approaching a real news story, Cucumber 1.0 was released today. According to that post from Aslak Hellesøy, the project has had nearly 750,000 downloads. Oh, and there’s a native JavaScript port in progress. I didn’t know that.

Anyway, Cucumber 1.0 adds Rake 1.9.2 support. Recent changes you may not know about include a -l and --lines command line switch as in RSpec’s and a new transform syntax that allows you to factor out duplicated parts of step definitions. Haven’t seen official docs on this, but it looks like it allows you to capture bits of step definition and run a block against it. The code example within the Cucumber tests looks like this:

Transform(/a Person aged (\d+)/) do |age| 
  Person.new(age.to_i) 
end

Given /^(a Person aged \d+) with blonde hair$/ do |person|
  puts "#{person} and I have blonde hair"
end

In other words, the snippet a Person aged \d+ is captured and transformed and the result of that transform block is what is passed to the step definition block.

Interesting. I wonder if people will use it?

2. The End of the World As We Know It

This post from the Armed and Dangerous blog tries to imagine a world without the web. The general idea is that if Congress had understood what DARPA was up to in the early 80’s, then funding would have been cut, and TCP/IP would not have been developed and popularized.

It’s an interesting argument, and as much as I’d like to believe it’s to dark, the examples of the cable and cell phone industries are eloquent. (I’ll grant that the author is probably trying to make a libertarian point I wouldn’t agree with in general…)

3. Books: Fuzzy Nation

Continuing playing catch-up with brief book reviews, Fuzzy Nation by John Scalzi. Fuzzy Nation is something odd — a genuine remake of a beloved SF classic (well, beloved by some, I’ve never read it), namely Little Fuzzy by H. Beam Piper. Scalzi has taken the basic elements — a guy who encounters small, sentient aliens who are, wait for it, Fuzzy — and wound his own story around them.

Fuzzy Nation is pretty much purely entertaining, fun, well structured, fast paced. It’s not as much interested in the existential questions around alien intelligence as the practical question of protecting them from a corporation that wants to strip-mine their planet. (Subtle, it’s not.) It’s one of those books that isn’t interested in re-defining the genre as much as telling a good story inside the existing boundaries.

4. Moving Beyond Thin Controllers To The Downright Emaciated

Gary Bernhardt over at the Destroy All Software blog posts some suggestions about using routing or routing-like structures to effectively remove controllers from the system. The theory is that if controllers just exist to dispatch to a specific method someplace else in the system, and Rails manages all the other connections, then why not route directly to that method with some declarative or rules-based logic to handle things like security logic, exceptional conditions, or other high-level logic.

It’s interesting, and probably could be built within Rails 3. I suspect most systems aren’t pure enough in the controllers to take advantage of it, which I guess is the point, and I wonder if the gain is worth breaking the default linkage between URL and controller/action pairs, but I’d be curious to try it.

5. In Brightest Day, In Blackest Night

Finally, I haven’t seen the Green Lantern movie yet, but I’ve been telling anybody who will listen that I’ve been waiting 30 years to be disappointed by it. Thanks to io9 for reminding me why be recapping an awesomely over-the-top Green Lantern comic from 1980 that I owned, loved, and could still quote alongside the recap. Watch GL stagger through the Arctic wilderness without his ring set upon by polar bears and wolves.