Thanks! As to your questions:
- I've been a lurker in the Rails community ever since it was first released. So no, not active. I guess in that sense I'm doing things backwards. I hope to be active now that I'm not spending all my free time writing and am polishing up an acts_as_rdf plugin for ActiveRecord that I hope will help the semantic web-minded folks.
- I had co-authored another book for Wrox before, so had been emailing back and forth with them afterwards about how important Rails was. That email thread turned into a book proposal.
I can only speak for my own book writing experience with Wiley/Wrox, but it is likely similar across the tech industry. You don't have to write the book up front or get an agent. Instead you submit a proposal to the publisher that is essentially your pitch: it includes a potential table of contents, your own market analysis, and why you think the book is a necessary addition to the existing set of published knowledge.
If all goes well, the proposal turns into a contract, which is basically a 15 page way of saying that you split the copyright, get a royalty advance, and get X% of sales, where X seems to be around 10% for the big publishers. (Pragmatic gives 50%!!).
Then you start the writing process, which took about a year both times for me, divided into ~8 months of writing, ~2 months of editing, and ~1.5 month of last-minute bug fixing and waiting for the book to print.
All in all, it's been simultaneously the hardest and most rewarding thing I've done in my (admittedly short) professional life. If you're interested in more details about how to get your foot in the door, feel free to shoot me an email (edward [dot] benson [at] gmail [dot] com).
@ambition - not a snarky question at all. The Rails book market is certainly growing crowded, so I think it is a very valid question. I hope this isn't a cheesy thing to say, but I really tried to make this the book I wish that I had to guide me after I had been experimenting with Rails for a while.
This book is different for a few important reasons:
First off, it speaks to issues of design rather than issues of API. That has important ramifications in the way the material is covered. Agile Web Development with Rails (Pragmatic) and The Rails Way (Addison) are two fantastic books, and both are on the shelf next to my desk right now, but they both concentrate on exhaustive coverage of the Rails API. The Art of Rails is meant to be the kind of book you buy after owning one of those. It takes someone familiar with the /syntax/ of coding Rails and attempts to provide guidance and insight into the /style/ and design patterns of architecting an entire application with Rails.
Second, it devotes three whole chapters (8, 9, and 10) to developing with the "Ruby style". So many web developers learn Ruby because of Rails that they eventually get to a point in their Rails development skills where they stand to really benefit by taking a few steps outside of Rails to learn how Ruby is a fundamentally different language than {PHP, Java, other OO/Procedural languages}. The Art of Rails really devotes a significant effort to talking about the new and Ruby-centric design patterns that constructs like blocks, Procs, method_missing, and instance_eval make possible, and then it provides examples of how you can use these design patterns in your Rails applications.
Third, it backs up design patterns with useful, concise examples that you can actually execute, but otherwise stays clear from drowning you with example code that is better left to online format.
Finally, I wrote it to read cover-to-cover, or at least a chapter at a time, whereas a lot of tech books these days are really centered around dictionary-style reference lookup. This book should be fun to read, have you nodding your head, and leave you with some useful abstractions, coding techniques, and new tricks when you're done.
I'll stop here to prevent myself from leaving a run-on comment, but thanks for pushing back for more justification of the book
Heh - I wish. As far as I know, Wiley (the publisher) doesn't have any plans to do an electronic version.
If it is e-books you're looking for, you should really check out Geoffrey Grosenbach's Peep Code (peepcode.com). It has a collection of screen casts and PDF books that are really great, and cost $9 bucks each, which is far worth the information they contain.
We've been to a few Ruby group meetings, hoping that community might overlap a bit with the startup minded, but haven't checked into Meetup yet -- thanks for the idea.
We're split between Boston & Washington, DC actually, but looking to base the startup out of NYC.
Thanks! As to your questions: - I've been a lurker in the Rails community ever since it was first released. So no, not active. I guess in that sense I'm doing things backwards. I hope to be active now that I'm not spending all my free time writing and am polishing up an acts_as_rdf plugin for ActiveRecord that I hope will help the semantic web-minded folks.
- I had co-authored another book for Wrox before, so had been emailing back and forth with them afterwards about how important Rails was. That email thread turned into a book proposal.
I can only speak for my own book writing experience with Wiley/Wrox, but it is likely similar across the tech industry. You don't have to write the book up front or get an agent. Instead you submit a proposal to the publisher that is essentially your pitch: it includes a potential table of contents, your own market analysis, and why you think the book is a necessary addition to the existing set of published knowledge.
If all goes well, the proposal turns into a contract, which is basically a 15 page way of saying that you split the copyright, get a royalty advance, and get X% of sales, where X seems to be around 10% for the big publishers. (Pragmatic gives 50%!!).
Then you start the writing process, which took about a year both times for me, divided into ~8 months of writing, ~2 months of editing, and ~1.5 month of last-minute bug fixing and waiting for the book to print.
All in all, it's been simultaneously the hardest and most rewarding thing I've done in my (admittedly short) professional life. If you're interested in more details about how to get your foot in the door, feel free to shoot me an email (edward [dot] benson [at] gmail [dot] com).