Early access beta of “Objects on Rails” Now Available

UPDATE: Objects on Rails is now complete and freely available online.

Often, at conferences and users group meetings, I find myself discussing the intersection of Ruby on Rails, Object-Oriented development, and Test-Driven Development, and I’ll mention something like “I prefer to develop my business objects first, and add ActiveRecord in later”. This usually leads to questions about how I structure my projects, how I isolate the business logic from ActiveRecord for testing, and so on. These discussions usually wind up with me saying “I’ll write a blog post about it…”.

A couple months ago I set out to start that blog post. I looked up from my keyboard a few hours later and realized that I had something rather larger than a blog post on my hands. Since then I’ve been pecking away at from time to time, in between work and conference travel. Now it’s reached the point where I’ve got a rough draft and it’s time to get some reader input.

When the book is complete I plan on releasing it for free for online reading in it’s entirety. It’s not quite ready for that stage yet. But today, I’m making an early-access (very) beta draft available for $5.

Wait a second… I’m selling you a book which I’ll eventually put online for free? How is that a good deal?

Here’s what you get for your money:

  • Early access!
  • Input into the final product.
  • When they are ready, you’ll get PDF, Mobi, and Epub versions for your offline reading pleasure. These versions will not be made available for free.
  • Once it is ready, a copy of the full source code including revision history of the working demo project the book is based on. Again, this will not be made available for free.
  • A warm, fuzzy feeling because you’re supporting me in writing this and future books, like my upcoming “Confident Ruby”.
Curious about what’s in the book? Here are some of the topics covered:

  • Starting with business models, adding persistence later.
  • Blazing-fast isolated tests using minitest without Rails loaded.
  • Using the language of the domain, not the language of the framework.
  • Stubbing out whole classes and modules in tests.
  • Stop worrying and learn to love Dependency Injection
  • Using the Presenter pattern to iron out convoluted view logic.
  • Exposing rich hypermedia RESTful resources with presenters.
  • Treating ActiveRecord as an implementation detail.
  • Separating fast unit tests from slower integration tests.
  • When to throw away your tests.
  • Using object composition to separate concerns.
  • Extracting object Roles into their own objects.

Sound interesting? Click here to buy it now:

Add to Cart

UPDATE: Want to submit feedback or discuss the book? I’ve created a Google Group for that purpose: https://groups.google.com/group/objects-on-rails

27 comments

  1. Where’s my book I didn’t pay for but got an email saying I paid for and now I want my free book that isn’t free but is going to be free!!!

    But in all seriousness, got an email I bought this, when I didn’t. Can I buy it again? Will that be okay? Because I want this.

    1. My apologies for that! I screwed up the email that was supposed to go out to buyers of the book, and it went out to buyers of Exceptional Ruby as well. I’ve sent out an apology email, and I’ve filed a ticket over the UI bug which facilitated this mistake of mine. Sorry!

      1. No worries, an odd bit of advertising there. Had I signed up for “Avdi sends me an email when he starts a new book” I may have ignored it. But since it was a mistake, I took a greater interest in it, came here, and now actually want the book. I would have read the book at some point, but perhaps not in beta, unless I heard about it elsewhere (like if you mention it on Ruby Rogues).

      1. Just tonight bought this but can’t seem to locate a link for an ePub version…

          1. No email yet with these links… Any idea who I could connect with about it? I definitely see the PayPal transaction records.

            Thanks for being so prompt in responding!

          2. Avdi, thanks again for a timely reply. I had failed to realize the email the link was sent to is a less-used one. When I finally thought to check there I found my link. ePub is on the iPad and all is clear. Thanks!

  2. It still makes me cry that people think about data storage as “object persistence” and something they can “add later”.  Your data is the most important part of your application.  If you’re not designing it first, you’re Doing It Wrong.

    1. For certain domains that’s true. But there are a huge number of applications where that’s simply not true. Twitter is a great example: it turns out the data model isn’t nearly as important as getting the tweets to people quickly – after that persistence is almost an afterthought. Twitter really screwed themselves early by architecting themselves as a CMS where the persistence strategy came first, and they’ve been paying down that technical debt ever since. This isn’t just my opinion, BTW, it’s what Twitter has said publically abouty their architecture mistakes.

      Uncle Bob has a great talk about how in developing FitNesse they kept deferring and deferring the persistence layer, and it worked out incredibly well for them. Eventually, like six months into the project, they realized they had such a good domain model that it took one day to write a persistence layer which would write the data out to files. They still planned on putting in a “real” persistence layer on top of a DB some day, but it turned out that with the volume that particular app had in any given installation, nobody actually needed the DB backend. And the file store had unexpected benefits: they could put the whole thing under revision control essentially for free.

      And then of course I’ve worked on various aeorspace systems which had no need for persistence at all, and the business logic (how to calculate radar track trajectories, etc.) was far, far more important than how the data was stored in memory.

      So no, your data model and persistence strategy really isn’t the most important thing across the board. For some apps, sure. But by no means all.

  3. Avdi, I only know you by reputation, and have respect for you.  So, I’m going to pretend that we’re friends, and you were hanging out with me some evening, and you told me about this idea you had.  I imagine talking about this over dinner.  At the moment you told me your plan for this book, I think I’d stop, fork frozen in the air, look you in the eye, and ask you if you were high.  Seriously.  

    I bought the book.  Thank you for your efforts so far.  I think you should be charging $40 or more for this, and I don’t think you should give it away when you’re done.  I think you should recover from this mistake by continuing in this vein, helping real developers kill the pain of their software development and multiply the money they are making with this kind of advice.  And, I think you should be a bigger part of this equation.  In the economies of time, money, and respect, you’re getting all the respect, but we’re saving all the time and money.  

    I just wish you were being more fair is all.

  4. Just went through this book. Great stuff, man. 

    I hope you’re thinking about hitting up the conference circuit with this material. DCI, separating out presentation concerns from domain logic, separating domain modeling and data persistance, I know people have already been talking about these subjects along with SOLID, etc. but I think your take is pretty unique in terms of the comprehensiveness and cohesiveness.

    1. I’m kind of conferenced-out, but fortunately there are some other sharp folks out there preaching the good word. Thanks for the vote of confidence!

Comments are closed.