small medium large xlarge

07 Apr 2009, 15:04
Scott Wright (2 posts)

I am working my way through AWDWR3, and spent some time last night trying to figure out why something was failing. Would you believe I had a typo? I ended up copying the file from the code sample and everything was fine.

I use Subversion for all my web projects even though I am a one man team. It occurred to me that hosting a Subversion repository for all the code in the book would make it really easy for people to get back on track. You could have commits at each chapter end, or more often if you wish and just include a note as to the revision number at various points. You could even go so far as to adopt a standard for all your books where a revision number would appear after a code snippet in say curly brackets {Rev#}. You could also do standardized notes with each commit stating the chapter, page, and figure number of each commit.

Not only would it make it easy for people to get back on track, it would also allow people to jump around the book with ease, and, at the same time, it may introduce people to Subversion and get them to start thinking about version control. I realize that the book is already printed, but perhaps future printings or revisions could include this feature and of course the pdf version can be updated anytime.

I’d really like to hear from others on this topic and I’d especially like to hear from the Pragmatic Programmers staff. Has this been suggested or tried before? Do you see value in this? Would the bandwidth cost of hosting the repository be prohibitive?

I am enjoying the book. Thanks for your efforts.


08 Apr 2009, 18:59
Dave Thomas (396 posts)

We’ve talked about doing something like this. There are quite a few technical problems which make it really very difficult, unfortunately. The main thing is that the code in the books does not represent a simply linear flow through time. We write the application, then the core team changes rails, so we have to go back and change every version of the depot app (say). All these changes are versioned in our build system (along with the source of the book itself), but those versions represent slices through the history of the book not the history of the app in the book. So, to create the repo you’d want, we’d need to start from scratch and manually build it.

Then, when we have to change the code in the book for the next release, we’d have to go back and build the repo again.

But, it’s a nice idea, and one that’s bubbling away in the back of my mind constantly. Maybe one day I’ll find a way :)

09 Apr 2009, 12:36
Scott Wright (2 posts)

So it definitely sounds like a ton of work, and work that will have to be repeated as changes occur.

Perhaps you can make it a community thing. You put the repository up and give certain responsible people write access to the repository in the early stages (when the book first becomes available as a pdf). These people would then do the work of committing the code, and would also serve as testers both for the code in the book and the code that gets committed. Perhaps you could even compensate them in some small way (free hard copy of the book, store credit towards future orders, etc.). Just a thought.

My other thought is that the code samples you provide for download could serve as the basis for the repository, with each iteration basically serving as a version. I wouldn’t think it would be that much work to simply overlay each successive iteration and do a commit. Another benefit not previously mentioned would be that everyone who started with the app checked out from your repository would be starting with the same version of rails (2.2.2).

09 Apr 2009, 14:30
Sam Ruby (634 posts)

I don’t see how that could work if the book were to provide {rev#}’s. Specifically, if somebody were to make a change to step 17 of 193 in order to support Rails 2.4 at some point in the future, how would people be able to specify that specific version?

Please treat the following as brainstorming: it may not solve the problem you want addressing, and certainly doesn’t address in the manner that you have suggested, but in “this directory”: are a makedepot.rb and a data.tgz. The script is a certainly a bit rough, but if you download it and unpack the data directory you can run a large subset of the examples from the book, including depot. There are a few if-checks that do different things based on which version of Rails you have installed. “makedepot.html”: is an example of the output produced.

You must be logged in to comment