Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Category Archives: eBooks

In Which I Blather About Self-Publishing

So I tend to keep an eye on interesting things in the Ruby self-published technical book space.

This isn’t exactly recent, but I did want to mention and endorse Avdi Grimm’s Exceptional Ruby. This is exactly the kind of thing that should be happening in the self-publishing space. It’s a brief, thorough exploration of a very specific topic, in this case error and exception handling in Ruby. You may think you understand Ruby’s error mechanisms, but I’m pretty sure that unless you are actually Avdi, you will learn something both about the mechanics or Ruby’s exception handling and how best to robustly integrate error management into your code.

The book is clear and authoritative, not least because Avdi is up front about certain code patterns that he is presenting but has not had wild amounts of experience with. I like when a technical author is comfortable enough to admit less than perfect omnipotence.

Anyway, it’s $15 dollars at both exceptionalruby.com and at Pragmatic – Avdi worked out a deal where Pragmatic is co-distributing the book. Unlike what I did with Rails Test Pescriptions, Exceptional Ruby is just being distributed by Pragmatic – it didn’t go through Prag design or edits, and Avdi also sells it on his own. This strikes me as a very interesting experiment, and I hope it works out for both sides.

Which brings me to the latest from Thoughtbot, namely a new ebook on Backbone.js and Rails.

I need to start with a disclaimer – there’s a sense in which this book partially competes with my Not Completely Announced JavaScript book. Also, I haven’t read what they have yet, although quibbles aside, there’s a good chance that I’ll buy it. Also, I use all kinds of Thoughtbot tools and I have a lot of respect for them as a team.

Okay, we clear?

Thoughtbot is producing a new ebook – apparently as a group, because they aren’t listing specific authors. (As a matter of marketing, and consumer confidence, I really recommend that they list the authors…). They have an extensive outline on the site, although they don’t estimate the final page count. The distribution model is interesting – when you pay, you get access to a github repo containing up to the moment source code that can be converted to a variety of formats. (Though it is unclear if any format other than HTML is supported immediately). The outline appears to be solid, can’t quibble with any of that yet.

Now how much would you pay?

It’s $39. Until August 1, when it goes up to $49.

That is a bold pricing strategy.

Which doesn’t mean it won’t work out fine for Thoughtbot.

To put that $49 in context, that’s more than double most Pragmatic ebooks. It’s almost triple what O’Reilly sells their new jQuery Mobile book for, which would seem to be a reasonable comparison, topic size wise. And, of course, it’s five times what I self-published for a few years ago. More on that in a second.

Offhand, I can think of three reasons why they might try that pricing strategy:

  • Value pricing: if this book saves you an hour of research or coding, then that easily covers the price for most purchasers. Which is true, if not exactly how the market prices technical books. But if you look at it as a fraction of what a typical training course costs, then it makes more sense.

  • Profit pricing: Thoughtbot may have decided they need to price at this level to make the cost in time spent on the book worthwhile to them.

  • Boutique pricing: Thoughtbot may want to place a marker down as experts in this space, but limit their customers to people who are seriously interested in both the subject and the somewhat interactive model they have chosen for creating the book.

All these arguments seem valid, or at least defensible, and I have no idea what Thoughtbot’s strategy actually is. I’m really curious to see what happens, though. I’ll report back after I buy it and they get some time to put content in place.

It seems to me like part of the marketing side self publishing a book is giving potential readers as few reasons as possible to not buy the book. Right now, there are a lot of reasons here – the price, the lack of a sample, the lack of an author or publisher who might have a track record (although obviously Thoughtbot itself has a great reputation, and this will be more meaningful to some people than others). Some of this will correct itself over time – if things are good, they’ll get some word of mouth – testimonials would be a great thing on their website.

Which is a roundabout way to say a couple of things about self-publishing based on my own experience.

First is that it’s wildly clear that I chickened out on the pricing. (Rails Test Prescriptions was $9 when I self published it.) I could make up something about how I was pursuing a mass-marketing strategy and blah, blah, but the simple fact was I was petrified that nobody would see value in it if I went above $9. In retrospect, I probably could have gotten away with a higher price.

The other mistake I made – or what could potentially have been a mistake – was to not set a finite goal. Avdi, I think, has this exactly right. He took a specified chunk, wrote about it, and called it a day. When I first started with RTP, I said a lot of things about how I would keep the book updated. It didn’t occur to me until after I started selling that I was setting myself up for an infinitely long task. Again, though, I was afraid that there would be a lack of perceived value in a book that ended, and obviously one of the potential advantages of an ebook is ease of updating.

One thing the Thoughtbot team has right, though, is an easy way of updating – their book will be a git repo. I hope, though, that they’ll separate in-progress from edited and reviewed by putting them on separate branches. I messed this up a bit by assuming that my distribution channel could handle it and then having to come up with a stopgap fairly quickly.

I will say, though, that publishers and editors are somewhat like the government in that when they do their jobs well, you don’t realize how much value they can add. There’s a process for doing things that the author might not want to be involved in – design, indexing, distribution.

I don’t have a grand conclusion here – I’m very interested to see all kinds of experiments with self-publishing, I don’t think anybody really knows how things will play out.

A tribute to the humble page number

I’ve been doing a lot more reading on eBooks since I got the iPad. For the most part, I really like it.
I’ve been using three different eReader programs: Apple’s iBooks, the Amazon Kindle, and the Barnes & Noble Nook. You’d think that an eReader would be basically similar between apps, but there are definitely differences in how the apps feel.

Here’s one little example: how does each reader app marks your progress in the book? Physical books have this nice technology called the “page number”, which, when coupled with “seeing how thick the book is on both the left and right side” gives you a good sense of how much you have to go before you have to find another book to read.

EBooks of course, don’t have pages or thickness (though, for some reason, when I hold my iPad as a reader, I put my finger between the iPad and the Apple case flap, as though I was folding over a paperback book.) Each eReader that I use has a different metaphor for progress. And I’m not sure which I like best. It fascinates me that three different teams looked at this issue, which would not seem from the outside to be that complicated, and came up with three different answers.

The Kindle uses what they call “locations”, which are basically virtual page numbers placed at (I assume) regular intervals in the text. The Kindle tells you what location you are at (well, it tells you what locations are currently displayed on the screen, there is usually more than one at a time), and it tells you what percentage of the book you have completed.


There are a couple of advantages to this setup. The biggest is that the locations are stable if you change the font size, so location “2345” always refers to the same place in the book. Because of that, I assume you could actually use a Kindle location in a citation, if you were so inclined. (Okay, you probably don’t care. But if you were a student, being able to cite based on an eBook seems increasingly important…) The percentage progress through the book is a reasonably user-friendly way to go. The downside, obviously, is nobody knows what the hell a location is, so saying that you are on “location 2345” has relatively little actual meaning.

Apple’s iBooks app went a different way. iBooks takes the nuts-and-bolts approach that a screen’s worth of text is a page and will tell you that you are on “page 45 of 456”, along with a set of dots that shows progress through the book.


The nice part about this approach is that it is concrete and directly related to the device you are using. You know exactly how many screen taps there are — iBooks also tells you how many pages are left in the current chapter, which is a genuinely useful piece of information. The problem is the flipside of the Kindle setup — the page numbers are dependent on font size and device screen. If you change the font, then iBooks recalculates the page you are on. (It also takes a noticeable amount of time to calculate when you open a new book.) You can’t use the page number to reference a permanent part of the book. Still, for casual reading, it’s hard to deny that the page number that iBooks presents is the most relevant and useful information. Although, strictly aesthetically, I don’t love the row of dots, it doesn’t read as a progress indicator quite as easily as the other two apps.

The Barnes & Noble Nook app does something different still. It presents page numbers based, I think, on the pagination of the print book. In other words — and I realize it’s slightly insane to define a page number based on something else — it’s essentially the Kindle location, but with location markers placed at the start of each print page.


I can’t decide whether I think that’s the best of both worlds or the worst — I like the look of it best, though. Like the Kindle, the Nook’s locations are permanent, and therefore citable. There’s a certain kind of familiarity in keeping page numbers in a familiar range. That said, it’s genuinely a little weird to turn the virtual Nook page and not see the number changed — the first time I noticed it, I thought it was a bug.

So that’s one tiny little usability decision that turns out to be complicated enough to have three separate answers, and even having used all three I’m not sure which one I like best. Superficially, I like the iBooks approach, I think, but I also think that a permanent location marker is needed. As usual, it leaves me with respect for how complicated even easy decisions get once users are involved.