Noel Rappin Writes Here


Announcing Ember! Master Space and Time With JavaScript Book 4

JavaScript, Self PublishingNoel Rappin6 Comments

You have no idea how happy I am to announce that Book 4 of Master Space and Time with JavaScript: Ember is now on sale. You can buy it at /mstwjs

It’s not done, of course. But it’s off to a good start, and I think it’s going to be great. Here’s the state of the world:

  • Release 1 of the Ember book is $7, just like its recent siblings. The four book bundle is still $15.

  • Release 1 is about 20 pages of content (plus the same intro, acknowledgments, and so on). It covers setting up the Time Travel app with an Ember front end, then the basic concepts involved in getting data from the server, displaying it to the browser and responding to actions. We basically end at a chapter break, so it’s a contained example, though obviously the rest of the book will take it farther.

  • The code is written against Ember 1.0pre4, which means its current as of yesterday.

  • Unlike some of the other betas, this one has been reviewed by a few people, including people who know more about Ember than I do, so I’m pretty happy with how it’s going so far.

  • We don’t cover testing yet (in part because the framework does so much that there isn’t much logic to test yet). It’s coming, though. Trust me.

  • The plan is for basically weekly releases until done.

  • I don’t know how long this is going to get — to some extent it’s going to depend on the reception, more sales = more encouragement to write. It will be at least in the 100is page range as the previous books. If it gets much longer than that, I may raise the price at that time.

That’s the scoop. Buy it: /mstwjs, enjoy it, spread the word.


Functions that return functions are the luckiest functions in the world

JavaScriptNoel RappinComment

Here’s some JavaScript:

var foo = function(a, b) { return a * b };

var bar = function(func) {
  return function() {
    return func.apply(this, arguments)

baz = bar(foo);
console.log(baz(2, 3));

What we have here is a function, bar, that both takes a function as an argument and returns a function as it’s result. It’s transforming the function passed to it into a different function.

Okay, that’s cool in kind of an abstract way, but so what? Let’s play around with function that take and return functions to show off some potentially useful tricks.

I’ll note right here up top, that there are more complex, fully featured, and robust versions of all the things I’m showing here. I’m just playing with functions.

We can add diagnostics.

var foo = function(a, b) { return a * b };

var trace = function(func) {
  return function() {
    console.log("calling " + func);
    console.log(new Error("normal trace").stack);
    return func.apply(this, arguments)

foo = trace(foo);
console.log(foo(2, 3));

All the trace function is doing here is logging a couple of things before actually calling the function — namely, it’s printing the function body (JavaScript doesn’t have a consistent way to get the function’s name), and a stack trace. The console output is:

calling function (a, b) { return a * b }
Error: normal trace
  at file:///Users/nrappin/Dropbox/coderx/blog/functions.html:8:17
  at file:///Users/nrappin/Dropbox/coderx/blog/functions.html:15:13

Okay, that’s kind of neat. You can also tweak it to do something like a Jasmine spy object, but it takes some object manipulation. Here we really start to take advantage of the fact that JavaScript functions are basically just JavaScript objects.

var foo = function(a, b) { return a * b };

var spy = function(func) {
  var returnFunc = function() {
    returnFunc.timesCalled += 1;
    return func.apply(this, arguments);
  returnFunc.timesCalled = 0;
  returnFunc.args = [];
  return returnFunc;

foo = spy(foo);

console.log(foo(2, 3));

Same basic idea here, except we’re doing some dancing with scope to make sure we have access to all the variables we want to, when we want them. Specifically, rather than just returning an anonymous function, we’re giving it the name returnFunc. Inside the funtion body of returnFunc, we’re accessing properties of the returnFunc functional object itself. Specifically we’re incrementing a counter and adding to a list of called arguments.

After we define the function, we initialize the timesCalled and args properties, and return our functional object. This works because we can access properties of the functional object inside the function itself, which seems weird, but makes more sense if you think of it just as an ordinary object accessing other properties of the same object.

Here’s a related example — in this case, our function object has its own methods.

var benchmark = function(func) {
  var returnFunc = function() {
    returnFunc.startDate =;
    result = func.apply(this, arguments);
    returnFunc.endDate =;
    return result
  returnFunc.elapsedTime = function() {
    return returnFunc.endDate - returnFunc.startDate;
  return returnFunc;

foo = benchmark(foo);
console.log(foo(2, 3));

In this one, we’re running the inner function surrounded by time stamps, and we’re adding a function to the function object, which again, seems weird. At the end, we can query a benchmarked function as to how long it takes. (Yes, I realize that the dev tools allow you to do this.)

Here’s one that might be more practical. Memoizing is the act of caching the results of function calls so that you don’t need to re-evaluate an expensive computation.

var memoize = function(func) {
  var returnFunc = function() {
    argsToCheck = (JSON.stringify(arguments));
    if (returnFunc.cache[argsToCheck]) {
      return returnFunc.cache[argsToCheck];
    } else {
      result = func.apply(this, arguments);
      returnFunc.cache[argsToCheck] = result;
       return result;
  returnFunc.cache = {};
  return returnFunc;

foo = memoize(foo);
console.log(foo(2, 3));

In this case, we hold on to the functional argument as before, but when we call the memoized function, we first compare the argument list against a cache. We’re using the JSON string version of the argument list, so we do have that conversion overhead. If this particular argument list has already been called, then we return the result of the previous call without recalculating. If not, we calculate the function, and place the result in the cache. So, our first call to foo in the example places (2, 3) in the cache, but the second call would retrieve it, to avoid that very expensive multiplication.

This is the beginning of manipulating functions in JavaScript — functional programming in general is a big topic, but worth looking at. Adapting a functional style where side effects and mutable state are downplayed in favor of manipulating functions, can really pay off in less complexity in your code.

Like this? You might like my book Master Time and Space With JavaScript, free sample available, and $15 for the whole thing.

Depending on jQuery and Perspective

JavaScriptNoel RappinComment

The reported errata for Master Time and Space With JavaScript (buy it here) has been pretty light so far. A bunch of typos, some setup weirdness.

And one interesting issue worth exploring. What is a dependency, and maybe more to the point, where is a dependency?

This issue was raised by a reviewer whose name I’m not going to mention — that’s not a reflection on the reviewer, but rather a reflection on the fact that I’m going to put words in his mouth to expand on his brief comment on the issue, so my interpretation of his position may not actually be his position.

Anyway the reviewer had a comment about when to convert to and from jQuery objects. He raised it in the context of the autocomplete example from the please-go-pay-for-it Book 2, but it also applies to the toggler example in just-for-free Book 1, and really, in any case where you have a JavaScript object which uses a data type that is a jQuery object.

Here’s the deal. I have an object — in this case it’s my autocomplete selector, but I’ll pretend it’s a generic widget because the exact object doesn’t matter — which is being initialized via a function call like so.

    widget = new Widget({parentSelector: "#autodiv"});

The key point here being the parentSelector: "#autodiv" option. In the eventual constructor, that #autodiv is immediately converted to a jQuery object (The example in the book is more elaborate, I’m simplifying to focus on the issue at hand…)

    var Widget = function(options) {
        this.$domParent = $(options.parentSelector);

The reviewer’s point was that he’d rather convert the selector to jQuery in the call to Widget and pass the argument to Widget already converted to a jQuery object, rather than have the Widget constructor do the conversion:

    widget = new Widget({domParent: $("#autodiv")});

    var Widget = function(options) {
        this.$domParent = options.domParent;

I’m not convinced yet that one way is better than the other — I haven’t changed the book code, but I certainly respect this reviewer’s opinion on how to structure JavaScript. But I do think that the two options make different assumptions about the structure of the application that are worth teasing out.

In my structure, jQuery is treated as an implementation detail of the Widget. Since jQuery is an implementation detail, outside code wouldn’t be expected to know about it, so outside code communicates to the Widget via a selector. Now, I grant that there’s a little bit of fiction there, since the selector syntax is (somewhat) jQuery specific. If I really wanted to isolate jQuery, then the calling argument should just be the DOM ID, and the Widget would also be responsible for converting the DOM ID to a jQuery object, with the intermediate step of building a jQuery selector string:

    widget = new Widget({parentId: "autodiv"});

    var Widget = function(options) {
        this.$domParent = $("#" + options.parentId);

The advantage of treating jQuery as an implementation detail of my widget is that the rest of my code does not need to know or care about it, and I can presumably even test other parts of my code without jQuery even being around. Also, if I choose to swap jQuery out for some reason, the rest of my code doesn’t need to know, only my widget needs to be changed. I would consider the conceptual point about jQuery being an implementation detail of the widget to be important even if I find it exceptionally unlikely that I would swap out jQuery. (For one thing, it also protects me against jQuery itself changing).

In my reviewer’s structure jQuery is a dependency of the application as a whole. Looked at from that perspective, it makes sense to convert everything to jQuery objects as early as possible, to maintain consistency of representation across the entire application. The code as a whole may be easier to read, since we aren’t continually having to worry about whether an object is a jQuery object or just some kind of DOM identification. If multiple widgets are all using the same jQuery object, then we might prevent some duplicate conversion to jQuery objects. This probably simplifies the internal code at the cost of making us more dependent on jQuery itself. As a practical matter, that tradeoff might be worth it — once we’ve decided to use jQuery, changing it is probably unlikely.

Essentially, it’s a question of where you draw your boundaries. I’m not sure there’s a long-term practical difference between these two structures, in that I don’t think one of them necessarily leads to better or more flexible code over time, especially given even rudimentary attention to practical details. But I do think you should be clear about which structure you are using — mixing the two by treating jQuery as a specific dependency of some parts of the code but a general dependency of other parts would probably lead to confusion later on.


A reddit commenter asked why I wasn’t passing a DOM element into the Widget, as in:

new Widget({parentSelector: document.getElementBy("autodiv")});

My response: I have nothing really against passing in a DOM element beyond it being a little verbose and an old-timey superstition against using getElementBy. Using a DOM element still keeps the dependency in the widget.

Like this? Go ahead and read Master Time and Space With JavaScript

May 9, 2012: The Random Link Post Returns

JavaScript, Music, RSpec, Ruby, Self PublishingNoel RappinComment

And now, the return of the semi-occasional link post. I’m going to try to do this at least once a week, but who knows.

If you are writing JavaScript, you should be looking at Justin Searls and his JavaScript testing tools. Justin posted the slides for what looks like a great talk on JavaScript testing. These slides made me happy.

In random media sales, the audio book of World War Z is on sale for a mere six bucks.

A couple of Ruby posts. Steve Klabnik argues that merely splitting code into modules doesn’t reduce complexity. Instead he argues that you need encapsulation. I think splitting code is probably better than nothing, but not a lot better.

Meanwhile, Avdi Grimm describes the Ruby idiom for type conversion which I have to admit, I never thought of as an idiom before.

In a story that I think of as a cautionary tale about pricing and value, the LA Times writes about the history of American Airlines customers who bought unlimited tickets. And then, you know, they used them, unlimitedly.

I always like to see plucky programmers trying to self-publish books about testing. So I’m glad that Aaron Sumner is LeanPubbing a book on testing Rails and RSpec. Good luck, Aaron!

Pretty much everybody who blogs or writes or tries to explain things to people should read this XKCD

Finally, a random music recommendation. I don’t recommend music much, but I do have a weakness for lyric-heavy, earnest, catchy music. Which brings me to the Lisps and their recent musical project Futurity. The musical is a Steampunky kind of thing that concerns a Civil War vet who tries to build a “Steam Brain” with the help of Ada Lovelace. It’s clever and I like it. Album Link. On a similar vein, their song Singluarity from their previous album Are We At The Movies.

Master Space And Time With JavaScript Status 5-08

JavaScript, mstjsNoel RappinComment

Now that the new book is public, I’m going to start doing more frequent status updates. It’s going to be weird for me, after keeping the project under wraps for so long, but I’m sure we will all get by.

When the book, shall we say, reverted back to me, I had two immediate questions: what to write, and how to deliver it to a (hopefully) desiring public. Let’s talk about the content first, though in practice, I needed to make sure I had a tool chain I liked before proceeding.

At peak length, the manuscript was about 150 PDF pages, give or take, comprising something like 60% of my outline. Great! Ready to start selling. Except for a few things:

  • Because the last few months consisted of a few different writing experiments on different parts of the book, the pages that I have aren’t consistent.
  • Some of the text was started but not finished once review became more important… There is a chapter or two that I haven’t even read in months.
  • Plus, life marches on. Ember.js wasn’t even a thing when I started, now I’m increasingly feeling like I need to cover it.
  • The existing code is in an XML-esque format, and my preferred toolchain starts with Markdown.

Those points are all annoyances. The real problem is harder to articulate. Maybe the best way to put it is that the review process made me kind of cautious when writing, and that the book needs to be bolder and more sure of itself in order to succeed.

So the content part of the last week has involved writing a new, short introduction, I think I’ll probably revisit that once I have more of the rest of the book in place. I’ve also started transporting the first real chapter, but it’s more of a re-imagining than a copy and paste.

The way the book is set up, it uses the Time Travel Travel Agency example I’ve used in a couple of workshops — hence, the name — and you are contacted by a possibly time-traveling client who asks you to continually make JavaScript changes to his application. It’s a little silly, but I like it, and it keeps some focus on writing JavaScript in a real, if smallish, application. I’m refocusing the content on teaching good BDD practices, part of what I’m doing right now is trying to balance learning BDD with learning the JavaScript.

And that’s where I am. I’ll keep updating status regularly. If this interests you, remember to sign up.


JavaScript, Me, self promotionNoel RappinComment

Here’s what I’ve got.

2 chapters introducing jQuery and Jasmine via a walkthrough of a simple piece of JavaScript functionality.

1 need to convert all my text from its current proprietary format to something more Markdown based.

1 genuinely silly conceit tying together the application that gets built in the book. And I mean that in the best way. It should be silly, there’s no reason not to be bold. There is even a twist ending. I think.

1 slightly dusty self-publishing tool chain that converts a directory of markdown files into HTML, with syntax colored code. It’s possible that there’s a better library for some of the features these days.

1 chapter on converting that simple piece of jQuery into various patterns of JavaScript object. I quite like this one, actually.

1 website, which is currently hosted by WordPress – at one point, I had to abandon the site that actually sold stuff, and WordPress was easy. I think I’ll need to upgrade that a bit.

1 Intro chapter covering JavaScript basics and the Chrome developer tools. Not sure if this is at the right level for the audience I expect.

1 Prince XML license for converting said HTML files into PDF. No idea if that’s still the best tool for the job. Or even if my license is current.

1 chapter on building a marginally complex auto complete widget in jQuery and Jasmine. I like this example.

1 copy of most of the book’s JavaScript code in CoffeeScript. Not sure when I thought this was the right idea for the book, beyond an excuse to use CoffeeScript.

1 chapter on jQuery and Ajax.

0 toolchains for generating epub and mobi files. I know I can find this.

1 case of impostor’s syndrome, not helped by rereading the harsh review of Rails Test Prescriptions on Amazon. That was dumb, why would I do that?

1 chapter on using JSON. As far as I can remember, this chapter never went to edit.

3 people who mentioned on Twitter that they’d buy a self-published book. Don’t worry, I won’t hold you to it.

1 plan for writing 2 or three chapters on Backbone.js

5 people who reviewed the last version who I feel should get free copies when this comes out. It’s not their fault.

4 viewings of Ze Frank’s “Invocation for Beginnings”

So. Ready to go. Watch this space.

A Brief Announcement About A Book

JavaScript, Me, self promotionNoel RappinComment

So… The JavaScript book that I had contracted to do with Pragmatic will no longer be published by them.

I need to be careful as I write about this. I don’t want to be defensive – I’m proud of the work I did, and I like the book I was working on. But I don’t want to be negative either. Everybody that I worked with at Pragmatic was generous with their time and sincere in their enthusiasm for the project. Sometimes it doesn’t work out, despite the best intentions.

I haven’t spoken about this project publicly in a while because it was so up in the air. And also because I’m not sure what to say about it without sounding whiny or mean. And also because I was afraid of jinxing things, which is obviously less of an issue now.

Since November, the book has been in review and I’ve gone through a few cycles with Pragmatic trying to get things just right. The issues had more to do with the structure and presentation of the material then of the content or writing itself. I’m not completely sure what happened, but I think it’s fair to say that the book I was writing did not match the book they wanted in some way or another.

Anyway, that’s all water under the bridge. I have full rights to the text I’ve already produced. Self-publishing is clearly an option, though the phrase “sunk costs” keeps echoing in my head. It’s hard to resist the irony of starting with a Pragmatic contract and moving to self-publishing after having done it the other way around with Rails Test Prescriptions. I’m hoping to blog more – in addition to being a time sink, not being able to write about this book was kind of getting in my head about any blogging.

Thanks for listening, and watch this space for further announcements. I was excited about this project, and while this is disappointing, I’ll be excited about it again in a few days. Thanks to the people I worked with at Pragmatic for the shot, and thanks to all the people who have been supportive of this project.

Coming Soon: Getting Things Done In JavaScript

Books, Jasmine, JavaScript, MeNoel Rappin5 Comments

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.

August 26, 2010: Some New Stuff

JavaScript, Ruby, WindyCityRails, Yehuda, rvmNoel RappinComment

Book Status

RSpec chapter draft handed in to edit. It's going to need a better conclusion. A lot changed in this one, relative to the Lulu version -- this is probably the chapter most affected by my own personal experience since it's original version.


Haven't done a link set in a while, this is going to be kind of random.

Still seats available for both WindyCityRails in general, and for my tutorial in specific. But the sponsor list has filled up.

Motorola bought 280 North, best known for their Cappuccino JavaScript framework, and the 280 Slides application. Apparently, Motorola plans to use them to make web apps aimed at Android devices. Should be an interesting culture clash.

I've been looking through the Rails 3 unobtrusive JavaScript stuff trying to figure out new practices. The Trevor Turk blog has a code snippet for setting up a form that submits when a checkbox is clicked. Like it. Love to see more examples like this, it really shows how clean the Rails 3 structures will be.

Ever wish the Ruby Date and DateTime classes were faster? Course you have. Here's home_run, a C implementation of the Date and DateTime classes that claims a 20 - 200 time speedup. The Readme page shows how to use the home_run classes instead of the standard ones, if you are feeling adventurous.

I love stories of tracking down obscure bugs, and Yehuda Katz has a great one about bundler, rvm, and various shell interactions. Debugging is maybe the important skill, so watch an expert's process at work.

Speaking of rvm and it's awesomeness, here's a quick guide to putting rvm, bundler, and passenger together on a Rails deploy.

Here's a little test snippet to solve the problem of how to test an abstract controller by adding a small controller in the test page and creating a route for it.

July 8, 2010: Who Needs a Hero?

Clojure, Hiring, JavaScriptNoel RappinComment

Book Status

Beta 4 should be going out Real Soon Now. As far as I know everything is ready and we're just waiting for it to actually be generated.

Still working on legacy coding chapter.


A couple of links about hiring today. One debate is between Ben Orenstein and Brian Liles about whether you can get a Rails job without experience. Somewhat weirdly, both of them seem to be arguing the same side, which is to go out and get some experience. Open source projects are a great idea, which was also the topic of Blake Smith's talk at Chicago Ruby this week.

Speaking as somebody who has been on the hiring side of the equation, I actually like Joel Spolsky's formula of "smart and gets things done". Experience is sometimes a proxy for "get things done", but often isn't. Contributing significantly to an open source project would be a good way to show getting things done (though I don't have a tremendous open source portfolio myself). I've definitely hired and recommended people with less experience if they had a portfolio of some code and came off as really great in the interview. A lot of Rails shops are including long pairing sessions as part of the hiring process -- it's hard to hide during that.

On another angle, Trotter Cashion and Gregory Brown have a little mini-debate on what kind of developers to hire for a startup, generalists or specialists. Again, they are agreeing on a lot here. Brown is suggesting that contractors can help scale a startup early on. I think that hiring all specialists can become a real problem, if the team gets siloed that makes scheduling and planning more difficult. Also, you can't every say enough that hiring cowboys and heroes is just not sustainable. It may seem sustainable for a while, but then all your heroes burn out and leave, or they burn out and stay, which can be even worse.

Hey, another one from Jay Fields, this one is about experiences using Clojure to do high-level testing of a Java app, by which I assume Fields means integration or acceptance testing. Interesting points, especially since it seems like his team didn't go in knowing Clojure. Back in the day, we hoped that Jython would become popular for this kind of thing -- Fields even mentions having a REPL terminal in Clojure, and the Jython book has a longish example of this kind of think, if I remember correctly.

This just came over the wire from Corey Haines twitter feed -- Ben Cherry gives some good advice on writing testable JavaScript. This is great advice about how to keep untestable dependencies and state out of some basic JavaScript constructs.

July 2, 2010: Cease and or desist

Jasmine, JavaScript, RSpecNoel Rappin1 Comment

Book Status

And now I turn my lonely eyes to the chapter on testing legacy code. I liked this chapter in the original book, and it's something I get asked about pretty consistently, so I really want to make it great.


I'm personally going to spend a lot of time with David Chelimsky's post about RSpec 2 docs. It's the best listing I've seen so far about changes between RSpec 1 and RSpec 2. In particular, the Cucumber features are outstanding -- the best example of tests as documentation I have ever seen.

Corey Haines has an article on testing JavaScript via Jasmine in this months jsmag -- not a free article, just so you know. I've heard Corey present on this topic, and he's great.

In a related story, Kristian Mandrup has a fork of the BlueRidge JavaScript/Rails test framework that makes the generators compatible with Rails 3.

Adam Wiggens describes Clockwork, a Ruby alternative to Cron.

Multiple sources report that the Lemmings game port for iOS that I reported on a few days back was immediately slapped with a cease and desist order from Sony. Ouch.

And if you haven't read the message from the CEO of Woot to his employees on the occasion of being acquired by Amazon, well, it's worth five minutes of your time.


One year ago this weekend, Gregg Pollack was nice enough to give the Lulu version of Rails Test Prescriptions a big shout-out on the official Ruby on Rails Weblog. This was part of what drove me to submit the book to Pragmatic, so this is another thank you to Gregg for the kind words and the push forward.

May 3, 2010: Hi, I'm Back

Cucumber, JavaScript, Obtiva, Peanuts, Podcasts, Rails 3, RailsRx, Teaching, cheat sheets, testingNoel RappinComment

Hey, where were you?

Sorry about that, I spent most of last week running the Obtiva Ruby/Rails/TDD 4-day boot camp training, and I didn't have time to do this daily catchup. Hey, if you think you need me or somebody like me to come to your company and blather about Ruby and Rails for a few days, contact us at It's fun.

Book Status

Rails test prescriptions: still on sale. Please do go to the forum to talk about what's there and what's not there.

Lulu raffle: still open, I think for another day or two.

Meantime, I've been working through the Cucumber chapter, and also proofing the mock article that will be in the May Pragazine.

Tab Dump

Several days worth of stuff.

Cucumber 7 is out of beta and in the wild. I'm hoping this doesn't mean too much updating of the chapter I'm in the middle of editing. The big change is a new parser advertised as 50-100 times faster. Which sounds like an outstanding change.

This week in Rails Dispatch, an article outlining the new ActiveRelation/Arel implementation of ActiveRecord for Rails 3

Thinking in Rails has a nice list of Ruby and Rails podcasts.

This is exactly what I want from a Rails plugin in: short, sweet, and solves a problem. In this case, from Ryan Bigg, finding database records by partial date.

I think I'll probably use this one: a detailed cheat sheet for all things Rails Migration.

A very detailed article on unobtrusive JavaScript that I really need to read more carefully.

The Thoughtbot team shows a nice design retrospective, walking through their process.

A couple of test links:

José Valim gives out some awards for best test suite features.

Will Leinweber tells you what the winning integration test stack looks like.

Bryan Liles at the Smarticus blog also responds to the question of whether you need unit tests and provides a good overview of the TDD process. I think he's got this right.


Apparently the Peanuts brand is still worth something, even without daily content, as an 80% stake in the brand rights for Peanuts just sold for $175 million. And if you want a sense of exactly where the pecking order is here, the article casually mentions in the next-to-last paragraph that the rights to Dilbert are also included...