For the impatient, he seems to have enjoyed it, although he makes some valid points about one or two things I could have done better.
It's nice, after all that work, to see that Chapter 8, which was among the hardest to write, is "worth the price of admission," at least in his opinion.
A few weeks ago I got a new laptop.
It may suprise some of you, but it's not a PowerBook this time. Instead, I'm typing this on an IBM Thinkpad t42p. There are a number of reasons I went with an x86 machine this time, including, but not limited to, the following.
I just finished up version 0.05 of mod_speedyfeed.
New in this release is an Apache::Test based test suite and support for ETags and If-None-Match.
I manufacture an ETag header based on the crc32 checksums of the entries, and drop from the body of the response any that match checksums seen in the client's If-None-Match header. This is similar to the RFC3229 feed support implemented in Sam Ruby's weblog, but I do it dynamically as part of an Apache filter.
For the curious, here's the relevent entries in the CHANGES file.
* Add support for ETags and If-None-Match. Our ETags are crc32 checksums of the entries, concatenated together. If we see a fragment that matches an entry's crc32 in the client's If-None-Match we drop it.
* Account for the fact that Content-Type headers can have arguments.
* Genericified some stuff so it will be easier to add support for other feed formats in the future.
* Added an Apache::Test based test suite.
Get it while it's hot: http://electricjellyfish.net/garrett/mod_speedyfeed/mod_speedyfeed-0.05.tar.gz
As usual, I welcome any comments.
Yesterday I sent the examples from Practical Subversion off to my publisher, which was the last remaining task I had before I could call the book officially done. Sometime yesterday (or perhaps today, I'm not entirely sure) the final PDFs were sent to the printer, and I'm told that in about a month we should have actual dead tree versions of the book. It's taken far longer than I'd originally thought it would, and a lot more work than I had anticipated, but I'm glad I did it. I've learned a lot, improved as a writer, and at some point soon I'll be able to walk into a brick and mortar book store and see something with my name on it sitting up on the shelf. That's so much cooler than seeing things I wrote up on a website, and I'm glad I have been given the chance to do it.
Before you ask, no, I'm not planning on writing another book anytime soon. Instead I think I'm going to stick to actually writing code, which I've missed over the past year or so, and while I will continue to write it'll probably be limited to much smaller pieces. This whole process has truly made me appreciate the value of a quick return on investment. Taking an entire year worth of hard work before you actually see the result in a bookstore is not nearly as much fun as a few hours over the course of a week or two before you can see an article up on a website somewhere ;-)
In any event, for everyone out there who is tired of hearing me pull out the "I've got to work on the book" excuse way too often, I'm no longer going to be able to use that one, so I'll have to work on an all new set of excuses for not being all that much fun...
I just sent the final post-copy-edited chapter of the book back to my copy editor.
My copy editor is great, and the book is a hundred times better because of her, but I'm so glad that I'm done with this part of the process.
Getting a copy of a chapter back with a thousand little notes on it about things you need to fix is just so disheartening.
I recently saw a description of the process of writing a technical book as being similar to "Having your teeth pulled out with pliers, slowly, over the course of a year". It's been a bit more than a year for me, but other than that it's about right...
In case I wasn't clear on it in the past, the Apache::Test perl module is just the coolest thing.
The docs on how to get it up and running if you're not building your standard everyday mod_perl module aren't exactly the best (so far I can't find a way to set things up wthout using either Apache::TestMM or Apache::TestMB, neither of which I really care about since I'm using configure + make instead of ExtUtils::MakeMaker or Module::Build, but it was easy enough to fake up an Apache::TestMB one liner to do what I need), but once you're over that part it's just so damn cool.
I've now got a test suite that automatically builds the module, configures and starts Apache, runs automated versions of the tests I was doing manually, and shuts everything down, and all I have to do is type make check.
Should have done this much earlier in the process...
So version 0.04 of mod_speedyfeed just hit the net.
Here's the appropriate entry from the CHANGES file:
* Fake up a status line so we can work with versions of Apache that do not have support in the core for the 226 status code.
* Work around the weird way APR-Util's XML code treats xml:lang attributes.
* Compare namespaces as well as element names when looking for the atom:entry and atom:modified elements.
* Added a configure script and makefile.
The big deal is that first bullet point. Justin Erenkrantz was nice enough to point out that even if Apache doesn't have support for the "226 IM Used" status code you can fake it up by manually setting the status_line in the request. This means you don't need to apply a patch to Apache to make use of this module.
I've also got a version of this up and running somewhere people can access it, so feel free to play around with sending various combinations of If-Modified-Since and A-IM to http://quicksort.net/index.atom and let me know what you think.
Next on the TODO list is investigating adding support for more of rfc3229, either some of the other IM values (probably range) or the ETags/If-None-Match parts of the feed IM value.
(I am, of course, an idiot, and neglected to post the link to the tarball... You can grab the new version here.)
Just rolled the release tarball for mod_speedyfeed 0.03.
Quoting from the CHANGES file:
* Fix bug in parsing of A-IM header that would cause us to not work in cases where more than one IM was specified by the client.
* Switch to GenX instead of the APR-Util XML code for outputting the document.
* Various code cleanups.
The big reason for the release was the first bullet point, that was a reasonably embarassing bug. The move to GenX is part of my long term plan to stop using the APR-Util XML code, since it's got a lot of weird quirks and I'd rather have something more general anyway.
Grab the new tarball here if you're interested.
As always, comments of any sort are welcome.
Ok, so like I said earlier, it only took a few hours of playing around to get the first version of mod_speedyfeed working and out the door.
Get it while it's hot: http://electricjellyfish.net/garrett/mod_speedyfeed/mod_speedyfeed-0.02.tar.gz
You'll also need a patched version of Apache2 to get support for the new 226 status code, grab the patch from the Apache Bugzilla.
What does it do?
In short, it allows you to only send new entries in your Atom feeds down to the clients. The client program adds a few HTTP headers (a If-Modified-Since to tell you what the last time they got was and an A-IM that indicates you support the 'feed' IM) and things just magically work.
Best of all, the content that's sent down, while smaller, remains valid Atom XML, so no real change is needed on the client side other than sending the new headers.
All you need to do on the server side is compile and install the module, it works as a filter so any content that's served up with an application/atom+xml content type is automagically effected.
(The first release is 0.02, not 0.01, since I naturally found a show-stoppingly bad bug at the last second...)