Probably most developers already know about O’Reilly’s Safari service, which, for a monthly fee, enables you to have a set number of books checked out of an online library and use them in electronic format. I had known about it for ages, but hadn’t ever subscribed until I recently started using PHP and JavaScript a lot more than I had been. I had never been attracted to it as a Java developer, because between experience, the books I own, JavaDoc, and source code, I can pretty much find the answers I need without additional reference material. In areas where I’m less experienced, though, Safari is incredibly helpful. I don’t want to go out and buy a shelf full of books for things that, hopefully, I’ll never have to use again, so Safar is a great deal. Just throw a few relevant books onto your bookshelf and go. Like I said, everyone but me probably already knew this, but if you didn’t, then go check it out.
One other thing I had wondered about was the Safari business model. I had assumed that there was enough reference material freely available online for most things that Safari wouldn’t provide a significant marginal benefit. As I wade into the PHP world, though, I find that the online reference material is generally lacking. The PHP manual is pretty uneven, and most of the developer resource sites run by third parties are advertising-laden crapfests. Safari really hits the sweet spot there. I wonder how many subscribers they have? Any money they do make must be almost pure profit since O’Reilly already owns the rights to the books and the site must not be horribly difficult to maintain.
Poor test coverage
Reading some of the software development weblogs lately, it seems like the anti-unit testing backlash has begun. It wasn’t too long ago that people were talking about becoming “test infected” and that Test Driven Development became an important buzzword, the idea being that you would write automated tests to verify that your code worked before writing the code itself, and then making sure that your code complies with those tests throughout the development cycle.
I was a bit late jumping on the bandwagon and becoming test infected, but as soon as I really leapt into it, the value became apparent to me immediately. Indeed, one thing that has been confirmed repeatedly lately is that all of the most embarrassing bugs I’ve had to deal with have been direct products of having poor test coverage for a feature. Had I written all of the unit tests I needed to, I would have caught those bugs and not had to deal with customers contending with them. And the thing is, in every one of those cases, it’s not like I couldn’t foresee needing to write the unit tests I miss. Rather it was that cycles are short and there are too many things to do, and so testing suffers. Anyway, unit testing may be a fad to a certain extent, but it’s a fad that I won’t be leaving behind anytime soon.
There’s no worse feeling than getting burned by a bug and knowing that a bit of extra work on the testing side could have saved you.