I only mentioned it briefly here, but this spring I wrote and released the book Everyday Rails with RSpec. You can buy it right now, if you’d like, for only nine bucks through Leanpub. This post isn’t about marketing the book, though; it’s about the experience I had (or have had, I should say; it’s ongoing) with putting together the book, getting it out the door, things I think went well, and things I’d do differently next time.

The idea for the book sprouted from a few places. Coming into Rails from a very unstructured form of programming, it took me a little time to fully appreciate automated testing. The resources I originally learned from didn’t help. They either glossed over the subject or focused so much on testing ideologies that the practicality was lost in the theory. In the meantime I’d cobbled together my own system from what I’d picked up and internalized, but I didn’t get the whole picture until I got a better handle on a couple of specific tools (first, Factory Girl; later, Capybara). Noel Rappin’s Rails Test Prescriptions remains a favorite book on the topic. Of course, the Railscasts series also taught me a great deal, especially the episode in which Ryan Bates walks through his approach to test-driven development. Watching over an expert’s shoulder, albeit virtually, was a great help.

I began writing a series of blog posts in Everyday Rails on how I learned to test. The one sentence summary of these posts may be learn to test your models, learn to test your controllers, learn to test integration, then flip it all around. A couple of posts into the series I realized they were getting some pretty good traction, even though I hadn’t done much to promote the posts. I decided to expand the original blog posts into an actual book, and actually see if I could make a buck or two on the exercise.

I started out using Scrivener to convert the blog content (currently in Textile format) into something more nicely formatted. I quickly realized that Scrivener, while very powerful, wasn’t a good fit for what I wanted to do. I was getting bogged down in formatting and organization way too early. At the same time, I hadn’t yet decided how I was going to actually sell the book. My original plan was to deal with all the rendering myself, set up an online storefront somewhere, and make it available that way. I wasn’t crazy about that plan, but it seemed like that’s how most of the self-published authors I’d read in the past handled it. Then I stumbled across Leanpub.

For the unfamiliar, Leanpub is a small operation out of Vancouver, BC, that makes it easy for writers to get content out the door and get paid for it, adopting the Lean Startup approach to publishing. The basic idea is if you can get content into the hands of readers early you’ll get a better sense of the book you need to write (this was definitely the case for me; more on that in a few moments). Leanpub has a very generous royalty mechanism and will even facilitate getting finished books into the likes of Amazon and Apple’s iBookstore. I was and am more than happy to pay someone else to take care of this infrastructure stuff for me, so I signed up.

Going with Leanpub also solved my writing tool dilemma. Leanpub uses an automated Dropbox-based mechanism to receive content from authors and return the formatted results in ePub, Mobi, and PDF formats. Authors may use whatever writing tool they’d like, but the system expects content to eventually be in Markdown format. This was perfect for me–since I was writing a programming book, this meant I could put it together using the same tools I use to write code. In my case, that’s Textmate with a Markdown bundle. After some conversion from Textile to Markdown I was up and running pretty quickly. I already had about 30 pages of content from the original blog posts and some additional stuff I’d already written, but I still needed to come up with a cover and price.

I spent a lot of time agonizing over a cover. Too much, probably. That process could probably be a blog post of its own, but eventually I narrowed my focus to red vehicles—not to pun on test-driven, but to play off of the red of Ruby and to have something to use as a theme for possible future books. After multiple scours of iStockphoto I found a shot of an old-but-reliable red pickup. It was perfect for what I wanted to espouse in my book–a test you can trust is far more important than a test that runs fast but breaks down regularly.

I wish I’d spent a little more time thinking about pricing. At the time I wasn’t sure how long the book would be, but I was shooting for about 100 pages. I also didn’t know what the market would be for a book written by a very minor Rails blogger, based on content that was already available for free. I set it at nine bucks, figuring I might adjust it when the book was done. In retrospect I might have been able to go for 12 dollars; maybe even 15. Using Leanpub’s sliding pay system, I’ve had a few people pay as much as $25. If and when the book hits non-Leanpub shelves I will likely adjust the price.

Whatever the dollar amount, I wanted readers to get their money’s worth. That meant doing something I don’t do in the blog: Providing a complete code sample. The original plan was to provide a single final version, but as I wrote and revised I realized that an incremental approach was a better way to go. This didn’t turn out to be a whole lot more work, but I did have to keep an eye on some additional detail. Git helped out a great deal here–I built up an untested Rails application in my master branch, then incrementally tested it in branches. To generate the code for download I then just made a copy of the code base for each chapter, switched each to its respective branch, and deleted the git internals from that copy. I made a conscious decision to not publicly post the link to the code. It’s only in the book. It’s against convention, but since this is an exercise in good ol’ capitalism and I’d already shared a great deal in the blog, I figured I would try this approach.

I also stated up front that I would release a free update of the book when Rails 4 hits the streets and RSpec and company are all compatible. To be honest I regret making this decision, for a few reasons. First, I think Rails 4 may not be released as soon as I was thinking then. Second, it will be a lot of work and I’m not sure how much it will be appreciated (see the pricing paragraph above). Finally, it leaves the sense in me that the book still isn’t done. It’s at 1.0, so to speak, but I know that 1.1 is coming. This also hampers getting it listed outside of Leanpub, since Amazon and Apple aren’t suited for releasing updates like Leanpub is. So I wait.

As I write this, the book has 540 readers. (You can do the math yourself to figure out roughly how much I’ve made in royalties.) I did very little marketing myself to get to this point. In fact, I can point to one thing I did to drive the most interest: A quick post on Rubyflow, which led to a mention in the very popular Ruby Weekly email newsletter, which led to some viral traffic. To be honest, aside from a little Twittering and some extra linking from the blog itself, I’ve done nothing more to promote it. I know I should; I just haven’t had the time for the additional customer support it might lead to.

Not to say customer support has been too difficult. For the most part the messages I’ve gotten have been in the form of useful feedback or intelligent questions which, in the spirit of lean, helped me pivot (cough) the book. The aforementioned approach to code samples resulted from a conversation I had over email with one reader. How the chapters on controller specs wound up being broken down and essentially rewritten from the original blog content was also based on processing reader feedback. In fact, I think I only had one person come out and say he (or she; anonymous) didn’t like the book. I’m sure there are others who may have taken issue with something in it, but I haven’t heard from them. The general challenge was doing my best to accommodate a relatively wide spectrum of Rails developers. I’ve been pretty straightforward from the start that the book is not for total beginners, and it’s not for people who already know how to test, but that didn’t keep people from either end of that spectrum from buying it anyway. To accommodate I tried to provide a lot of references to other works. I’ll tell you what you need to have in your Gemfile to get everything up and running, but I’m not going to give you a Bundler tutorial. And I’ll mention that it’s possible to run an RSpec test suite without waiting for your Rails application to load, but I’m not going to go into detail because it’s really advanced and it’s not a practice I follow (it deviates too far from Rails convention in my opinion).

I guess one other customer support issue that came up a few times centered around the notion of lean publishing itself, and confusion about buying something before it was done. The question becomes how lean is too lean? I released the first version with entire chapters missing, and the chapters that did exist were mostly reprints of existing blog material. The end product, though, had roughly three times the amount of content I started with, and was almost entirely rewritten–all for the better, in my opinion. If I’d written the whole thing and released it as a final product it would have been a different book. And it wouldn’t have been as good. For the most part I think people are getting more comfortable with buying something on faith, but I understand the position of those who chose to wait (and hopefully aren’t still waiting).

So will I do it again? I need a break from writing about code. I’ve got plans for another book, but it’s on a decidedly different topic. If I ever do another book on programming I’m going to take a different approach, and ideally select a more focused topic. Writing about RSpec meant dealing with a lot of moving parts–the Factory Girl API changed between the original blog post and the first release of the book, and about a week after I went on record as saying the book was finished some pretty big changes to RSpec syntax were announced. I updated the former but have made the decision to hold off on the latter for version 1.1 of the book. I had to demarcate between book-style writing and blog-style writing, you know? I will also do more to market the next book, and will likely charge a little more for it.

So should you do it? Yes. (Notice the lack of hesitation in saying that.) Chances are you know something others would like to know, or have a unique perspective on a topic, or have experienced something fantastic, or all of the above. You don’t need a publisher’s approval or a fancy setup–just an idea and an audience. The tools are all in place. Spend a few minutes to learn Markdown syntax, set up an account with Leanpub, and get your message out there.