Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Category Archives: JavaScript

Self-assessment

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 railsrx.com 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

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

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

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.

Links

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?

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.

Links

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

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.

Links

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.

Finally

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

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 http://www.obtiva.com. 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.

Finally

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…