PragDave

Displaying Code on the Kindle

So, I'm in a quandary.

Having used one now for a few months, I'm slowly warming to Amazon's Kindle 2. Sure, it still feels a bit cheap compared to the Sony 505, but it's fast, and the ability to download over their wireless network is a bit plus. (Stay tuned for an announcement from us about that...)

But my biggest issue with the Kindle is the markup it supports. Think 1995 browser, minus the <blink> tag. It is very, very limited.

I pride myself on the look of our books, so when I added support for eBooks on the Kindle, I worked hard to get something that looks half-way decent. We're still tuning it, but by and large I think our books look good. But we still have an issue. It is really hard to display code listings on the device. Let me explain why, and show you some examples. Then, at the end, I'll ask for your help.

First, the problem. When the Kindle was first launched, it lacked a fixed-width font. They recently added one. But the choice of sizes is limited, and the code tends to end up too big, even at <font size="-2"> This leads directly to the main problem. The Kindle display is narrow. You can get roughly 45 fixed-width characters across it at the smallest font size. That means code lines will either be truncated, or they'll wrap.

But, we went ahead and did our best. And we didn't much like the result. In particular, I didn't like the way long lines in the code wrapped onto the next line. So I went back to the drawing board and took a new approach.

In the books as currently published, code listings on the Kindle are actually images. That means I get to choose the font, and I get to choose the size. And I can do some cleverer things than I could do with straight HTML formatting. For example, if a listing is wide, I know before hand that it won't fit the horizontal size of the screen, so I scale the font down until it does. And, because the font I'm using is narrow, I can fit more code per line anyway. But there are some major downsides of this approach.

• The code doesn't scale up and down when you change the font size on the device.

• The font we're currently using in the images doesn't have bold and italic versions, so we're not syntax highlighting it. This is clearly fixable, but it would be something of a pita to do.

• The .mobi files we generate are about three times bigger than they'd otherwise be because of the embedded images.

• If an image is too big to fit on a page vertically, we currently chop it off.

So, there's no clear winner. Just to show you what I'm talking about, here are some comparison images taken from Daniel's Cocoa book. The ones on the left are pages from the books as we currently distribute them. The ones on the right use text, rather than images, do display code. (You can click on an image to see it at full size.)

Code As Image	Code as Text

So, given the pros and cons of each approach, what should we do? Stick with the current scheme? Move to text-based code? Or...?

Shipping the Rails Book

Last week we completed our largest direct shippment, as we sent out the preorders for Agille Web Development with Rails, Third Edition. We had tons of books delivered, and bought tens of thousands of dollars of shipping supplies and postage, but despite the volume everything went well (apart from the inevitable paper cuts). I even learned where the big boys go to the Post Office (which turns out to be a pretty impressive facility right next to DFW airport).

So I thought I'd share just a couple of statistics. Domestically, we shipped books to every state except North Dakota. Internationally we shipped to three US bases, and a total of 55 different countries (from Angola to Vietnam). Sometimes I close my eyes and think of the trajectories of all those books spreading out from Raleigh and Dallas—it's a cool picture.

So, if you bought a Rails book from us: thank you! It's been an interesting year (way longer than would would have liked, but that's the joy of working with a rapidly changing technology). We hope you enjoy the result. And, remember, we now have eBook formats  available for your Kindle, iPhone, and so on.

Clearly I've missed an opportunity with our book covers

Like the rest of our publishing business, I like to keep our covers simply and easy. But now I realize that these covers fail to capture the true epic nature of our books. Joey deVilla posted some reworkings of book covers last year, but I only came across them today. I'm inspired...

The strange thing is: I'm not sure where he got hold of the image. After we posed for the picture, DHH and I thought better of it. We thought we had destroyed all the copies...

The iPhone Book is in Beta!

We've heard back from Apple. We've double checked with the authors. And the iPhone book is in beta.

After a rocky start, I have to say we've had nothing but help and support from folks in Apple. And eventually the senior management listened to the community and did the right thing. Thanks to our friends in Apple for their help, and thanks to everyone for your support and patience.

Enjoy the book. And write some killer iPhone apps.

Dave

The Apple NDA is lifting...

A great huzzah! was heard through the land. Apple today announced that they will be lifting the NDA on the iPhone SDK. This is incredibly good news, as it means that, once lifted, developers will be able to talk with each other about the iPhone. And, among those developers are those that have created iPhone content for our Core Animation and iPhone SDK Development Books, a screencast series on iPhone development, and a brand new Pragmatic Studio on iPhone Development. All of these have been sitting here, waiting to get released.

So, all day I've been getting calls and e-mails saying “The NDA is lifted. Where are the books?” The answer is simple: right now the NDA hasn't been lifted. Apple have announced that they will be dropping it, and that a new developer agreement will be sent out within "a week or so." Our developers are still apparently bound by the existing NDA.

So, I spoke with someone senior at Apple this morning, and I'm waiting to hear back. In effect, the NDA is dead. But I need to protect our authors, so we can't release any iPhone content until we hear back that they're out of danger.

I'll blog here when I know more. We'll also send out an e-mail to our announcement mailing list and RSS feed.

Interesting times...

Time for Cocoa

I've always wanted to get into Cocoa programming. I like the look and feel of a good Cocoa app, and folks I respect tell me that it's a wonderful environment. But, to be honest, I've always been somewhat put off by the way that Cocoa programming is tightly coupled to Xcode and Interface Builder. I've never really liked IDEs, simply because in the past they've felt like they're in my way.

So then Daniel Steinberg twisted my arm and got me to edit his new book, which introduces Cocoa programming to people who are already programmers in some other OO language. Trying to be a good editor, I gritted my teeth are fired up Xcode and started to follow along with his tutorial chapters. And, somewhat to my surprise, I had a working (if minimal) web browser up and running in a few minutes. I added buttons, and later a progress bar, and it all just worked. So now I've changed my opinion. Cocoa is a really well thought out framework, but the tight integration with Xcode and IB make it very, very sweet. I'm looking for an excuse to spend some serious time writing a decent-sized app with it.

In the meantime, if you're like me, and want to dip a toe into Cocoa development, I'd recommend his Cocoa Programming: A Quick-Start Guide for Developers. If you're more of a hands-on learner, the good news is that Daniel and Bill Dudney will also be running a great 3-day Cocoa Studio at the end of October. It's in the amazing Inverness facility in Denver (which I'm at right now, teaching a Rails Studio with Chad).

Technical eBooks part II

In the previous post I mentioned the epub format in passing, saying it also had issues. However, I didn't bother to qualify that, nor did I give an epub sample.

When I went back to create the sample, I discovered that the 1.5 release of Adobe Digital Editions no longer worked with the epubs generated by our toolchain (and, by no longer worked, I mean looped-burning-up-CPU-until-crashing no longer worked—DE is a remarkably fragile piece of software.)

Anyway, I fixed that up (and, in the process, discovered that while id="fig:one" should be perfectly valid xhtml, epubcheck and DE both say not. Sigh).

So, here's the complete list of the versions of that sample chapter.

• In PDF format.
• In a rough-and-ready HTML format
• In .mobi format (which is suitable for the Kindle—just copy it to your Kindle's documents folder). You'll want to right-click and "Save As" to download this link.
• In .epub format (which I've only tested in DE). Again, you'll want to right-click and "Save As" to download this link.

epub is clearly better than mobi for formatting, but still has issues. But, I thought I'd post them all here for comparison purposes.

Just shipped tons of books (literally)

In the last week we shipped out two much anticipated books: Advanced Rails Recipes and Deploying Rails Applications: A Step-by-Step Guide. We've finally reached the kind of shipping volumes where we get special treatment at the Post Office—I'm now allowed to make deliveries around the back, driving my truck up to the loading dock between all the 50' monsters. It's an interesting insight into their business. The vast majority of stuff sitting out there during the day is the free advertising fliers that get added to your mail—pallet upon pallet of them. If we want to save the forests, finding some way of banning those things would be a start. (But, of course, they probably subsidize the mail, so doing so would double the cost of postage. In this case, that's a price I might be willing to pay.)

Also (getting back on topic), Mike Clark has made a 12 minute video highlighting some of the more visual recipes in his book. Check out the link on the book's home page.

Two New Groovy Titles

Just to prove we're not totally Ruby-centric, we just took two books on Groovy into beta.

Venkat has written Programming Groovy: Dynamic Productivity for the Java Developer, a wonderful introduction to the language. And Scott Davis complements it with Groovy Recipes: Greasing the Wheels of Java.

The Joy of Titling

One of the joys of being a publisher is seeing books develop over time.

One of the trials of being a publisher is helping to pick book titles.

Sometimes it is fairly easy. Agile Web Development with Rails pretty much summed up the book's content.

At other times, though, it's remarkably difficult. A back title can seriously harm a book. For example, Chad Fowler's first book with us is really, really good: a guide to managing and developing your career as a programmer. It was a joy to edit, and everyone who's read it loves it. But when it came time to give it a title, we were stumped. In the end, we decided to go for something a little jokey with some shock value, and My Job Went to India was born.

Big mistake.

The title didn't work. We sold a decent number of copies (just under 10,000), but we *should* have sold 3, 4, or 5 times that. It's a very, very good book. But I blew it for Chad by going with the wrong title. (It says a lot for Chad that he went ahead and wrote Rails Recipes with us after that.)

And now I feel like it might be about to happen again. Jeremy Sydik is finishing off a wonderful book. IT's all about how to create web sites that can be used by people with disabilities: the blind and color blind, those with motor problems, and so on. We clearly have a responsibility to create accessible sites but, as this book points out, we can also benefit greatly in terms of traffic if our sites can be used by the whole online population.

So then we come back to the thorny title problem. Right now, we're selling the beta with the name The Accessible Web—Creating Content for Everyone. But that doesn't seem to be working; folks I've talked to aren't clear what the book is about.

We're thinking about retitling the book. The current front-runner is Designing Web Content for Users with Disabilities—36 Keys for Unlocking the Accessible Web.

So, here's my question. Does that work better as a title? Or is there a *great* title we're missing?

I want to give these books the audiences they deserve. Help me out.

Thanks

Dave

Shipping Rails Recipes

The Rails Recipes books just came in from the printer, and we spent the last 3 days shipping the preorders. It's still a family kind of thing, and I took some pictures and made a wee slideshow (1.6Mb) so you can see what goes on. (If you're looking for the gerbils—they know better to get involved when there are heavy boxes around.)

Direct Shipping Record

I really like that fact that Andy and I still ship direct orders in-house: we're not currently using a fulfillment service. It means we can take that little bit of personal care with the packing, and we can correct minor order problems on-the-fly. We also get to see first-hand just what is going on. We see a surprising number of orders for multiple books, and it's fun to track which books tend to sell with others. We also get the occasional surprise, like the order in the picture for 12 titles. Even more surprising is the fact that it was from Australia.

AWDwR 2

Rails has changed a lot since we announced the first edition of the book a year ago. DHH says that the 1.1 release "boasts more than 500 fixes, tweaks, and features from more than 100 contributors." Who are we to disagree?

To celebrate the release of Rails 1.1, we're delighted to announce the second edition of Agile Web Development with Rails. This is a major update to the original, and we're releasing it as a beta book.

So far, we've rewritten the Depot application chapters. They now illustrate new Rails features such as RJS templates for Ajax support and has_many :through. We've lost the SQL in favor of migrations, and even include an rxml example so we can show off RESTful interfaces and respond_to. It uses the new rake tasks, keeps its sessions in the database, and generally tries to follow all the latest Rails programming recommendations (including dropping things that are likely to become deprecated over time). The testing chapter supports transactional fixtures, shows new features, and illustrates the new integration testing framework.

Over the coming months, we'll be updating the rest of the book. The Rails core chapters will be revamped to show all the changes to ActiveRecord, ActionController, and ActionView. The Web2.0 chapter will be rewritten to illustrate RJS; and the deployment chapter rewritten to use Capistrano and to show how to set Rails up in production. All in all, the book will be significantly updated to illustrate all we've learned about writing Rails applications in the last year.

All this represents a bunch of totally new content—entirely new chapters and largely rewritten old ones.

Today, we're releasing this new edition as a beta book. As with all our beta books, you'll be able to download updates as we add new content, and then, after we complete the book, continue to download changes to this second edition. We anticipate that the book will be finished in the fall, at which point the paper copies will ship.

However, we're doing this beta book slightly differently to our other ones. Rather than releasing just the new content as it becomes available, we're instead releasing a hybrid that mixes the new content with that of the original, first edition. That way you'll be able to use the beta book as a complete reference that gets updated over time. Each chapter is color coded: ones with a gray header are from the first edition, while those from the second have a red header.

From May 2nd onwards, if you buy the AWDwR PDF, you'll be getting the beta book version. If you want the paper book, you'll have the choice of buying the first edition now or buying the second edition that will ship when it's ready.

If you bought a first edition PDF from us on or after April 1st, 2006 (order numbers 27140 and above), you qualify for a free upgrade to the beta book. We'll be sending you instructions by email over the next few days. (If you have a spam blocker, we suggest whitelisting pragprog.com and pragmaticprogrammer.com—you'd be amazed how often our PDF download e-mails get bounced.)

Visit the book's page to see samples from the new chapters and check out the changes for yourself. Be sure to visit the in-place upgrade link to see how the process works.

We're really excited to be able to offer the most up-to-date information on the amazing Rails framework. If you're a Rails developer, we think you'll find this book an invaluable companion.

R-Rails Gets R-Recognized

`

No, I'm not stuttering. This evening, at the Software Development Jolt Awards at SD West in Santa Clara, Agile Web Development with Rails received the Jolt Award for best technical book, and Rails 1.0 won the Jolt for best web development tools.

I have to say, when I saw that both the book and the framework were up for awards, I was nervous, thinking that the judges might not want to vote for Rails in two separate categories. The fact that they did says a lot for the way Rails is now a mainstream player in the enterprise software world. It's clear the tipping point is behind us now, and we're a player.

Congratulations to DHH on his Jolt. And congratulations to the Pragmatic Bookshelf: this is our second Jolt Award in three years.

And, mostly, thanks to the Ruby community for providing the environment in which all this can happen. I'm really proud of us all.

Discuss This Book…

The announcement of Tobias’ Opinion software couldn’t have come at a better time. We were thinking about introducing some kind of discussion around our titles, where authors and readers could discuss issues and generally help each other out.

It’s a testament to the growing maturity of Rails that it took about 20 minutes to install and configure it on our shiny new server. So, to celebrate the release of 8 new recipes today, Chads Rails Recipes book is the first to have its own discussion group. It’ll be interesting to see how this works out.

Book Ecosystems

One of the joys of being a publisher is that you get to see things early, and then watch them develop. Right now, I'm having a ball with two books. And, by coincidence, both of them are companions to Ruby books that I wrote.

Maik Schmidt's Enterprise Integration with Ruby lives up to it's title, and then some. Not only does it show you how to use Ruby to create enterprise-level applications (both standalone and by gluing together existing apps), it also does an incredible job of describing the underlying technologies. I learned a boatload about databases, LDAP, SOAP, and XML background, as well as a ton of stuff about the Ruby libraries that support these technologies. Joe O'Brien puts it well:

If you are wanting to get into Ruby development, you work in a company with more than 5 employees, and you want to see some concrete examples of how Ruby can help you in your day to day job, please purchase a copy of Enterprise Integration with Ruby along with your copy of Programming Ruby. You will not regret it.

The second book that's blowing me away is Chad Fowler's Rails Recipes. This isn't the standard "27 ways to parse a string"-style recipe book. Instead it focuses on real-life problems you face when writing an application, then shows you the full solution. And I love that, because it means I can just pick up the code and run with it. I know Rails pretty well, but each recipe in Chad's book teaches me more. Alan Francis seems to like it, too:

Run, don't walk. Go now to the PragBookshelf site and buy the Rails Recipes beta by Chad.

And the fun thing is that both of these books are great follow-ons to existing books: if you have the PickAxe, you'll probably want to get Enterprise Integration with Ruby. And if you have Agile Web Development with Rails, you'll need Rails Recipes.

It's really nice to see this kind of evolution, as books grow and build on each other. I think its a sign of the growing maturity and strength of the Ruby community. And we've got some really cool stuff under development, too...

Rails Guidebook is Full

I’m blown away!

The Rails Guidebook, our day of pre-conference training before RailsConf, is now officially full. Chad Fowler and Jay Zimmerman, who are handling logistics, twice negotiated to get bigger rooms, but we’ve had to draw the line at 150.

Yes, 150!

One hundred and fifty people are coming to learn about Rails, and have agreed to donate at least $40 to charity. Many folks have already donated a lot more. (And, remember, the three biggest donations get some VIP treatment.) I’m so, so proud of our community for making this happen. Ruby folks have always been nice to be around. To see them contributing back to the outside world like this just confirms it.

Thank you all.

(If you are coming, remember to get your donation in, and bring your receipt. See you there.)

Imitation is the Saddest Form of Flattery

If you read the literature on process improvement and lean manufacturing, you’ll have heard the story about Toyota.

After the war, Toyota revolutionized the way cars were built, first with their ideas of Just in Time inventory, and later by pushing control down to teams on the floor, capitalizing on the agility that enabled.

Detroit manufacturers noticed this, and sent representative to Toyota to see just how they did this. These invited spies brought back copious notes on what they saw, the the auto makers set about copying the Toyota process. Without exception, these early attempts at imitation failed: the car companies replicated what they saw Toyota doing, but only on the surface. They didn’t really understand what was behind these practices. It was like trying to become an artist by copying the angle and velocity of the brush held by a master.

Andy and I have tried to think differently about publishing. We came to it knowing nothing about the industry. We did, however, know how to make projects work. So we took what we knew and applied the principles, if not the practices, to what we did.

• To my knowledge, we’re the only publisher to keep all our books under source control, and give authors access to their portion of the repository.
• We’re (I think) the only publisher where the author edits the actual material that gets typeset, so we can make changes right up to the day we go to press.
• We’re the only publisher to have continuous build systems for our books, so authors can see what they’ve just written, typeset as for the final book.
• We’re the only publisher to give authors monthly royalty statements (soon to be real-time), and quarterly royalty checks.
• We’re the only publisher to pay 50% royalties.
• We’re the only publisher where you can record an erratum for a page in the PDF you’re reading by clicking a link on that page.
• We pioneered the concept of the Beta Book, where you can get access to a book as it evolves, and then get the final copy when it’s available. Other publishers did have chapter-by-chapter programs, but our production system allows us to update the whole book, all the time.
• We pioneered the idea of Fridays, small, inexpensive, PDF-only books on focused topics.

According to the feedback we get, we’ve caused something of stir in the publishing industry.

And it’s no surprise that other publishers do what the car companies did to Toyota. They try to copy. Just this month I’ve heard of two publishers who’ll be running beta-book programs (even, somewhat lamely, calling them Beta Books). And I just heard that a well-known technical publisher might be launching a series of cheap, PDF-only, books. (Perhaps they’ll call them Thursdays to show some originality.)

As the Toyota example showed, this kind of surface-level imitation is flattering, but ultimately it’s unlikely to succeed.

Behind the stuff that you see us doing, there’s an underlying philosophy and set of practices. They all reinforce each other. For example, the fact we have continuous builds and author-typesetting means we can create beta books that are living documents. The fact we have an errata system hyperlinked from these beta book pages means we can put feedback in the hands of our authors, and hence we can get updated revisions out faster. Each of these aspects of what we do is a small thing in isolation, but we have hundreds of them, and they all add up to a cohesive, and we feel revolutionary, whole. Copying just the visible aspects misses this depth.

For this reason, I honestly don’t mind other publishers blatantly ripping us off. But I’d rather they didn’t. Instead, I’d rather they found their own ways of innovating, and build their own ideas that others found useful. The publishing industry is in transition. It needs all the good ideas it can get. All publishers should contribute in their own way to the reshaping of the industry. Simply aping someone else’s success won’t help the community as a whole.

Chad Fowlers Speaks!

SysCon interviewed Chad Fowler about My Job Went to India. Lots of cool music talk too.

A Picture's Worth a Thousand Words

‘nuff said...