« April 2009 | Main | June 2009 »
In my ongoing attempt to keep myself honest, here's another piece I wrote, again played by Mike Springer. I'm not sure how to categorize this one—I wanted to play around with 7/8, and ended up with what I think are some interesting patterns. Anyway...
And here's the music
I've known Chad Fowler for almost ten years. He's a seriously good guy: musician, developer, leader, and friend. So when he came to me some years ago with an idea for a book, I jumped at it. I was hoping for something good, but what we got was something truly great.
Andy and I wrote The Pragmatic Programmer over 10 years ago. It was a book full of advice on the job of programming, from low-level coding to teams and projects.
Well, Chad had written the companion book. Where our book looked outward at the job you were doing, The Passionate Programmer looked inward at the person doing the work. It's a book about finding fulfillment in what you do. It's a book about rekindling the fires that you felt when you first entered the profession. It's a book about creating a career, rather than turning up for a job.
I was blown away.
And then I did something really stupid. The book came out about 5 years ago, and outsourcing was big on everyone's mind. So I thought "let's make a jokey title that'll grab people's attention." I called the book My Job Went to India (And All I Got Was This Lousy book). I've already blogged about how stupid that was—it was probably the single dumbest thing I've done since I got into publishing. The title put people off; it gave them the wrong idea. The book was really nothing to do with outsourcing, but you wouldn't know it from the cover. This book deserved so much better
So, four years later, we revisited the book. Chad's given it a spring cleaning, revising and updating it. And we gave it a new title and a new cover, both of which do a better job of conveying the energy and enthusiasm that lie within.
I'm not into selling: my philosophy with our books is “if they're good, people will buy them.” But this book is different. I really think it can make a difference. So I'd love for you to read the extracts and maybe take this book home with you. I honestly think you'll thank me (and, most importantly, Chad) if you do.
I've had an on-again, off-again relationship with my Kindles. The original was not much more than a toy, but the Kindle 2 was a more usable device. It still needs work in the formatting department (hopefully the Lexcycle acquisition will help with this—I very much hope to see epub support rolled in to the Kindle at some point courtesy of the folks who brought us Stanza). But the distribution model is a good one. If you buy a book from the Amazon store, it gets delivered over the air to your Kindle.
Now, the Pragmatic Bookshelf doesn't participate in the Amazon eBook store: it is frankly too expensive for us, and we value having a direct relationship with our readers. So when we announced our support for the Kindle, we did distribution from our own site: you download your .mobi file from us and drag-and-drop it onto your Kindle via USB.
But… Amazon also let you send files to your Kindle via e-mail. In the old days, this used to cost $0.10 per file. So we modified our store. If you have a Kindle, you can register it with us and we'll send your eBooks to it automatically. If we release a new beta, it'll get sent to you, and we'll send you an e-mail to let you know it's there. It was a nice compromise, and at 10 cents a pop, not a bad proposition for our readers.
But then, yesterday, Amazon changed the rules. They now charge for transfers on a metered basis. Send a file to your Kindle over the air, and it will cost 15 cents/megabyte. Suddenly what once looked attractive now starts to become expensive. If we update a beta book 10 times, and the .mobi file is 5.5Mb (about our average), then you're out of pocket $9. Because we don't want our readers to get hit by surprise Amazon bills, we'll probably remove the feature from our store over the next few days (let us know if you think we should keep it).
Color me paranoid, but I suspect, that's exactly what Amazon wants publishers to do. Of course, they could argue that it's fair for readers to pay for bandwidth usage, but in reality I suspect that these transfers are a vanishingly small percentage of their overall network usage. Instead, Amazon probably realizes that this facility allows publishers to bypass their store and have direct relationships with clients. And Amazon d0esn't want that. This charge is just enough to discourage most readers to sign up with publishers such as ourselves to receive automatic updates to the eBooks they own.
I think that's a shame. We were looking at an entirely new model. Imagine how cool it would be if your books updated themselves while you slept. Now we'll have to wait for another device to become popular before that becomes a reality (Apple tablet, I'm looking at you…).
In the meantime, if you own a Kindle, and you'd like to receive automatic updates on it without having to mortgage your house, you might want to consider asking Amazon to reconsider this charge. I don't hold out much hope, but you never know.
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...?
