Jul 20 2005


The last 20%

David Heinemeier Hansson recently wrote about his experience with Dave Thomas and the Beta Book version of Agile Web Development with Rails. DHH talks about learning that readers won't hate the author over a few mistakes; that, essentially, they are much more interested in new knowledge, and a few mistakes here or there don't matter to readers, only to publishers who want to make perfect books. As such, DHH claims, Dave Thomas' original fears of releasing the book early were unfounded.

I'm here to tell you, they were far from unfounded. They were entirely right on. Readers demand that the book that they take back to their office, or bookshelf, or the trunk of their car, is perfect down to the last detail. Especially when we're talking about errors in code. Typos in text? Not really a big deal. Typo in the code? The world has ended. And they are right. If I pay $29.99-$54.99 for a book about a technology, I expect that the technology inside it is clean, checked and ready to go.

However, I don't think DHH's overall point is invalid; readers LOVE the beta book program, for a very specific reason. They can get their hands on an early, malleable, updateable ELECTRONIC copy of the book. If there are errors, they report them. Then they get a new copy with the fixes in it. More importantly, they are constantly given copies with fixes that other people have found, saving them the expense. And the book that they receive at the end, the physical copy, is clean. Perhaps cleaner than any other book they've ever purchases.

The key is permanence. If readers get one crack at a book, that last 20% is vitally important. Errata lists don't help. Reprintings don't help. The time it takes to integrate fixes to a print book is extremely counterproductive to a relationship built on trust and expectation of quality. A beta book, on the other hand, is ephemeral, fixable, bi-directional. The first and only model of publishing books where, to quote my English professors from college, the "reader can engage in a conversation with the author". And with all the other readers.

So, yeah, when you are using the beta book model, nobody cares about the last 20%, UNTIL the last 20%. When you have a traditional print model, everybody has to care about the last 20%, from the guy writing the book to the guy sticking it in the box at the printer. Because that's the only chance you have to get it right.

UPDATE: So, I guess what I'm saying is, Agile Development works for books as well as for software. Get the product in front of readers early and often, and they'll work with you to make the perfect product. Deliver once, at the end, and there are bound to be problems, and lots of unhappy customers who, rightfully, can't understand why the problems existed in the first place.

Jun 25 2005


Gmail == Kevin Bacon

So, now it finally occurs to me. Google isn't really interested giving people free email. Google wants to be able to definitively answer the eternal question: how many hops does it take to get to Kevin Bacon? By making Gmail invite-only, and being that Google keeps information about who invited whom, and further given that Google has the worlds most powerful search tools, can there be any other conclusion than that Google wants to play a giant game of Six Degrees? If everybody in the world ends up getting a Gmail acccount, then they'll know, won't they? And with information like that at their fingertips, who will be able to stop them?


Jun 22 2005



Fed up, finally, with the various OS CMS systems around, we moved the Relevance website to a custom Rails base. We're still using WordPress for the blog portion, but everything else is a homegrown amalgam. In the process, I've discovered something about myself. I can add a feature to this version faster than I can look for, download, install and figure out plug-ins for the canned systems. That isn't to say that the canned versions are bad or that I'm some kind of wunderkind, but that, for me, it is easier to think in code than in admin.

Jun 14 2005


Spring and J2EE

I was speaking at the Raleigh/Durham No Fluff show this weekend, and one of the attendees caught me in the hallway to ask a question. At this show, I wasn't even presenting on Spring; my talks were on SOA, Security Web Services and Hibernate. However, this attendee presented to me his problem: his company is dealing with a longstanding WebSphere project. One of his colleagues has been introducing Spring slowly into the group. Another told the assembled team that Spring was just an open-source J2EE wannabe, and it was silly to use it since they already had WebSphere. He wanted to know what I thought.

I told him that his colleague who was introducing Spring quietly to the group had it right. I also told him that his other colleague was a blowhard who hadn't read TFM. Rod n Co. created Spring in the first place to make J2EE easier to configure, more flexible and more fun to use. They will be the first to admit that they were trying to eliminate *EJB* from their toolkit, but we all know that EJB != J2EE. His colleague apparently went on to say that the overhead of the Spring framework on top of WebSphere was too burdensome to the project. Now, I haven't looked at the current footprint of WebSphere, but I'm willing to guess that the 90K Spring adds isn't damaging the overall image or resource usage.

So I'd like to remind everybody that Spring, while a perfectly capable "lightweight container" all on its own, shines in an environment that has been struggling to corral the goodness of J2EE through the sometimes labyrinthine configuration and management strategies of the container vendors. Spring is the outcome of several very smart people's struggles to do just that; if you can use Spring all on its own, then ballyhoo for you. But Spring seems to be being adopted most often by teams with existing "enterprise" apps with standing investments in Big Container X.

Jun 08 2005


Apple + Intel + me smiling

Apple's announcement that it is moving its processors to Intel "by 2007" is big news, and great news for me. I'm well aware of the backlash potential such a decision can have; I watched the webcast of the keynote address at WWDC and could hear the smattering of boos and hisses. Luckily, sanity prevailed and the greater part of the crowd was warm, even enthusiastic, about the announcement. I understand the psychological barrier to accepting such a switch when Appleistas spend so much time cultivating the War of the Different, but this just makes so much sense you have to look past that.

There's a lot to like here. The best thing, and I have to hand it to Apple, is they don't announce things before they are ready. Specifically, Jobs had everything lined up for this. Tiger already runs on Intel; the dev kits and even the developer boxes (looks like a 3.6ghz P4) are ready to ship. The price isn't bad. XCode 2.1 is already out. Rosetta (the dynamic translation/virtual machine for PowerPC apps to run on Intel) is already out. There is no waiting around for Apple to get with the program (unlike their Java support). And that just means that this will all be less painful for everyone. The best part of the keynote was Theo Gray's presentation on Mathematica5 and the fact that they just ported it three days before the show, in under 2 hours. Good stuff.

As for me, I love my Mac. I want nothing more than to ensconce myself in the luxuriousness of OSX. Unfortunately for me, I do most of my work on a laptop. My PowerBook G4 is well-built. Its display is luscious. The backlit keyboard is a great touch for dark flights. Everything about it and the OS screams "I am built for you; love me!" Except for one little thing: using the laptop as a laptop always reminds me of one of my favorite bands, Doug Clark and the Hot Nuts. And stuck on the G4 for a while now, development work is getting S-L-O-W-E-R all the time. I need more speed and less heat. It looks like the PowerPC isn't going to get me there. If I can get an Intel-based PowerBook in 2006 that doubles the speed and halves the heat, I'll be about the happiest guy on the block.

May 29 2005


Dumb Internet Quiz #34

I am a Defender-ship.
I am fiercely protective of my friends and loved ones, and unforgiving of any who would hurt them. Speed and foresight are my strengths, at the cost of a little clumsiness. I'm most comfortable with a few friends, but sometimes particularly enjoy spending time in larger groups. What Video Game Character Are You?

May 26 2005


The Rails BetaBook is Ready

The Rails BetaBook is Ready:

The Rails BetaBook is Ready

PragDave and friends have done it again. Having been in on the review team for the book (though, really, that just means I got to read it early, since I only submitted comments for one chapter) I can say that the book is a thorough, and much needed, work. Rails is here. Its momentum is, if not unstoppable, at least undeniable. Though the online docs and wiki are valuable, somebody needed to write the whole story down in one place. Dave, as always, has done an admirable job.

I also like the new beta book approach. In my experience, people like to have the paper copy of a book like this, and delivering an electronic version early is only going to increase actual sales. Let's hope that the PragExperiment proves that theory.

May 22 2005


Honeypot Projects

I was speaking at the Reston, VA No Fluff Just Stuff symposium this weekend, and the panel discussion got a little out of hand. Here we are at a traveling Java technology conference, and every question and every answer was about Ruby or Python. I'm afraid the attendees walked away from the panel thinking we all hate Java, which couldn't be farther from the truth. Its just that Rails is a soccer ball, and we're the Forest View 5-and-under Kids Soccer Team.

After loads of discussion of the relative merits of strong- vs. duck-typed languages, and tool support for Ruby and Python and managed versions of dynamic languages, we ended up where we always end up on these talks: how do we deal with all the losers we have to work with? It never ceases to amaze me how the audience, not the panel, always gets around to this question. "I work with a bunch of cavemen; how do I protect myself and my project from them?"

I finally came up with a good answer: Honeypot projects. Just invent something important-sounding but impossible to achieve, set up a $399 Celeron Dell desktop box but put one of the $150 cases on it that you get from Intrex that makes it look imposing and important, tell everyone that its the new Sun Optipylon 4500 server, give the cavemen logins on the box and let them build something. Just make sure the new Sun Optipylon 4500 is on its own subnet, and voila!

I kind of prefer Dave Thomas' answer, though. If you are really scared of so many folks on your team, you need to either rethink your hiring practices, or rethink your firing practices.

May 12 2005


Spring: A Developer's Lesson

Bruce Tate and I, on the heels of Better, Faster, Lighter Java, set out to introduce people to Spring. Committed as we both were to the ideas we were espousing (simplicity, ease of configuration, choosing tools that get out of your way), and admirers of what Rod and company had done with Spring, we wanted to write a book that would let people get right at the things that make Spring sing. O'Reilly suggested the book would fit well into the Developer's Notebook series, a code-heavy, to-the-point format that would highlight code and not prose. We agreed, and were off.

The end result of our work, published just two weeks ago, has flaws. Instead of waiting for the inevitable trickle of mediocre to poor reviews to poison the book on Amazon, though, I want to acknowledge those flaws now. Oh, its a good book which does what we intended it to do: introduce developers new to Spring to the variety of ways it can make their lives easier. Its flaws are not in intent, or even content. The flaws are in the execution.

There are typos, for sure, but every book has typos. There are mislabeled figures, and missing angle brackets at the end of XML snippets, and a variety of errors that creep into any book. Those are what errata pages and reprints are for, and you'll find both attached to this book. The bigger problem is with omissions: as the chapters progress, important pieces of information about how to make the code you see in the book run are missing. A taglib here, an interface there, a new dependency in the /lib directory over here, and it all adds up. People who try to follow the code in the book and make it run, quickly run afoul of these frustrating omissions and start getting (rightfully) upset.

Perhaps we were relying too heavily on people's willingness to download the code samples and dependencies. That, I believe, was the heart of my mistake, anyway. And the kernel of a valuable lesson: when you set out to make a book, *make a book*. Not a book, plus a website, and a blog and an errata page. If you want to write a book for print, make sure the book contains everything that it might need, soup to nuts, within its covers. The downloadable code all works; I urge readers of the book to grab copies and refer to them as you read the book. We broke them up by exercise in the book so it is pretty easy to see what has changed.

But you shouldn't have to, and for that, I apologize. We're issuing a reprint of the book now that fills in those holes. In the meantime, you can find the missing pieces on the errata page or follow along here as I enumerate them over a series of posts, starting with the one right after this.

Apr 15 2005


Google Hacking

There's an ever-growing database of Google hacks which demonstrates all the amazing stuff that is reachable by the Google bots. My particular favorite is the one that lets you find web camera controllers with default admin passwords, which reveals at least one airport security center.

However, you don't have to do a Triple Lindy with a twist to find interesting things with Google. Not too long ago, I was performing a security review for an organization. They had already had an architectural review of their upcoming application. While working on the security assessment, I happened to be on Google searching for something unrelated (I can't remember the search, but it was something to do with the framework stack they were considering for their new project). The fifth result in my list looked awfully intriguing: it turned out to be the architecture review that had just been performed not two weeks earlier. Apparently, their internal document distribution channel included a file server with a web front end.

The upside to the story is that on my next conference call with the team, I was able to point out this security hole before I delivered my assessment, which was scheduled to be distributed over the same channel. The downside to this story is that it is far from unique. There just isn't a healthy enough respect for the Great Eye of Google out there. Like Sauron atop the Black Tower, the Great Eye can peer into the hearts of men (well, companies) and reveal the darkest corners of their soul. And the worst part is, unlike some other kinds of security flaws, there's a public record of the leaked information. Once Google gets in, something somewhere is going to cache what it found, and that will be mirrored on another cache, and on and on. Fixing the hole that let's Google in only protects the future; your past is part of the public record.

Popular Tags