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.
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
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.
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.
`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.
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.
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...
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.)
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.
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.
