This Slate feature (via IASlash) really shows the power of good design. They asked four design firms to re-do the new USDA food pyramid. The results are much more useful than the official version. My favorite is the nutrition label (slide #2)...how powerful would that be??
Interesting post about textbooks. The dead trees have at least a few years still...we're still mailing textbooks out to students taking online courses...
Grig Gheorghiu has created a neat little python implementation of the sparklines concept. Cool!
I've been interested in the behind-the-scenes organization and development of the Wikipedia. I guess I find the development of such an open--bordering on anarchy--community very interesting. So, I read Larry Sanger's two part account of the history behind Wikipedia with some interest. The articles are long, but worth it.
I've finally gotten around to reading Andrew Hunt and David Thomas' The Pragmatic Programmer: From Journeyman to Master. I say "finally" not because it's been on my reading list for an exceedingly long time. Rather, this is a book that I should have read some time ago.
Although it is a technical book, and it does include code samples, the focus is not on a particular language or technology. This books operates on a higher plane, explaining techniques and tips that will help you become a better programmer. The effect is like that of the "master" explaining to the "journeyman" how the job should be done.
Hunt and Thomas lay out their message in a series of patterns, in the style of one of my favorite books, Christopher Alexander's A Pattern Language. The style encourages connections between patterns, a nice touch as you browse through.
Of course, I don't find everything they say to be fully relevant. The most useful, for me, are the higher-level concepts. At this point, I'm more interested in things that affect architectural decisions as opposed to patterns that are closer to the code. But, the pattern style of the book lets me cherry pick the good stuff and skim the less relevant.
I mentioned above that I wished I'd read it earlier. As I read through, I realize that I have been fortunate to pick up most of the advice from other sources. But having it packaged up like this would have been much easier. Would reading it in one fell swoop have prevented poor decisions in the past? Hard to say. Experience is still the best teacher.
I think one of the reasons I'm excited about the Ruby on Rails system is that it encourages (and sometimes forces) you into using the best practices preached by Hunt and Thomas. The system was designed explicitly to follow patterns like "Don't Repeat Yourself (DRY)" and to use the Model-Controller-View concept. The flexibility provided by, say, perl or PHP, can be great, if you know what you're doing. But, too few developers have the maturity (myself included) to do the right thing. So, you end up with code that is creaky and hard to maintain ("hacks" – using the negative connotation). I have a feeling that a Rails system, even one designed by programmer without tons of experience, will be easier to maintain and extend over the long term. At least, that's what I keep thinking every time I dive into one of the older systems in place at work…
Cool technology toy of the day: Google SMS. Send a cell-phone text message to Google and get back the answer (weather, prices, search results, movies, driving directions). Very nifty. And, it nicely routes around the expensive internet options provided by cell phone companies (of which I'm not using) and uses plain old SMS technology, something built into pretty much every phone for quite some time now. And since I tend to send a lot of SMS messages, I'm already paying for 'em, so this service works for me...
I'm pretty sure I'd seen this before, but I didn't play with it until I saw Nick Finck's mention of it today.
Don't worry, this isn't one of the lame April Fool's jokes that have been infecting, well, just about everything I've read so far today. If you'd like to just read about the interesting ones, the Washington Post has a roundup of the online jokes (via Tech Review). Oh, and my favorite joke of the day has to be this bit from the Library Journal: "Degree in “Google Science” Offered by Syracuse I School."
Now that we've dispensed with that little bit of unpleasantness, on with the show...
Go check out Jamis Buck's description of of Test-First Development. His post makes me even more interested in this. Like him, I'd dabbled in it before, just a bit. And, like him, I found it pretty cool. And, like him, I generally just dive into a project and play around with things until I get them right. So, like him, I should probably start to make a concerted effort to do test-first development. So should you, too.
One question: if you're a newbie, just learning to program, or just learning the language, would the test-first approach work? When I'm at this stage (now, learning a new language), I'm often so clueless I wouldn't know where to start. I suspect that doing tests would provide one with a good framework as they learn (as well as a safety net), but I'm not sure. Anyone out there ever start from scratch with this approach?
(How was that for a post on two different topics that had NOTHING to do with each other??)