By the time you read this, the snowstorms that shut Toronto down during the first two weeks of 1999 will be part of history. However, the web site that Huw and Gary started building for their new business while the streets were closed will probably be up and running, and the books I read to while away the hours will probably still be on your local bookstore's shelves. People say that the Internet has made geography irrelevant, but right now, it seems that it's just given us a more interactive fireplace to huddle in front of when our local geo-graphy is having a bad day.
I was thinking about Huw and Gary's site as I was reading Jennifer Fleming's Web Navigation. Like a lot of techies, I find the engineering side of web-site design a lot easier than the human side. Making links change color as they're brushed is easy; deciding whether they should, and what they should say, seems unfairly hard. I keep hoping that someone will just say, "Here's the right answer," even though I know there aren't "right" answers.
Instead, there are just right questions, and examples of good and bad practice. Fleming's book does ask a lot of the former, and she includes quite a few of the latter to illustrate the points she is trying to make. The book starts with the usual generalities, such as the importance of knowing who your site's audience is, and the basics of interactive interface design. Chapters 7 through 12 then look at how to structure different kinds of sites -- retail, educational, and so on -- to make navigation easier. Along the way, Fleming includes a lot of quotes from designers of sites that seem to do things well. This approach was in some ways the most interesting thing about the book for me, as the emphasis on personalities and philosophies made it feel more like an architectural review than a facts-first-and-last computer manual.
Benjamin Kovitz's Practical Software Requirements is also a question-oriented book. Kovitz defines the scope of his book in the first sentences of Chapter 1: "This book is not about programming. It is about how to define a problem for people to solve by programming..."
Kovitz starts by demolishing "the myth of functional decomposition" (which is actually the title of Section 1.1). As he points out, a good engineer is one who knows a lot about problems that have been solved in the past, and can use that knowledge to figure out which of those proven solutions should be applied to the present problem. Defining a problem's requirements is therefore really about gathering the information needed to choose, and customize, a solution (or set of solutions).
All of this is good stuff, and I learned quite a bit from the first few chapters of this book -- especially Chapter 5, which describes five common kinds of problems, and the sorts of questions that a requirements document should answer for each. But then I started to wonder, "Where's the UML?" The Unified Modeling Language is now a standard, but Kovitz only mentions it in passing, and uses a variety of other notations to describe what he's doing. The answer came in Chapter 12, where Kovitz gives his critique of design approaches that are based on use cases (as UML is). I don't know if I agree with what he says, but he says it well, and provides some useful templates for requirements documents to boot.
Jim Blinn's two collections of graphics-related articles, Jim Blinn's Corner: A Trip Down the Graphics Pipeline and Jim Blinn's Corner: Dirty Pixels, and Steve Heller's Optimizing C++, also share this personal feel. Blinn has been a major innovator in computer graphics for many years. His two books bring together articles from his column in IEEE Computer Graphics and Applications, and cover everything from circle-drawing algorithms to how to write a paper for SIGGRAPH. Some of these articles now seem dated, but Blinn's perspective on graphics, and computing in general, comes through very clearly. Like most such collections, they are better borrowed and browsed than owned, but there are some nice little gems in here for nonmathophobes.
Heller's Optimizing C++ is also episodic, although its chapters are much more tightly tied to one another than those in Blinn's books. Heller is the author of several other books, including the best-selling Who's Afraid of C++. His writing is clear, his explanations orderly, and he only irritates me occasionally (as with the comment on page 338: "Unlike some well-known authors who shall remain nameless, I take technical writing very seriously").
As its title suggests, this book is about making programs go faster. While "C++" appears in the title, most of the optimizations Heller looks at in his case studies are low-level C-isms (such as using bit vectors to reduce a program's memory requirements) or algorithmic (such as why quicksort is not always the best sorting algorithm to use). Each chapter introduces a particular application, discusses design and algorithmic alternatives, and then presents successively faster solutions, along with a description of how Heller figured out what to tune next. I enjoyed the book (although I would have broken the listings up into smaller sections, and numbered the lines), and think that with one more chapter on general principles, it would be a worthy successor to Jon Bentley's classic, Writing Efficient Programs.
Essential COM and Effective COM, by Don Box and others, are similarly gritty books. COM is one of the three main component technologies on the market today. While many people think it is the weakest technically, it is by far the most widely used. (For an excellent overview of COM, CORBA, and JavaBeans, and the problems they are meant to solve, see Szyperski's Component Software.)
Box is a recognized COM guru, and these two books are aimed squarely at programmers who already have some familiarity with it. The first chapter of Essential COM is the best explanation I've ever found of why COM has the features it does. Subsequent chapters look at those features in mind-bending detail; they are not for the faint of heart, but if you have to do a big project with COM, you're going to have to learn this stuff some time.
Effective COM is clearly patterned after Scott Meyers' Effective C++. Each of its 50 short sections states a general rule, then explains what it means, and why you should follow it. Some of the rules are rather vague, such as "Code defensively," but others, such as "Always initialize [out] parameters," can save you hours of frustration. As with any good manual of style, you may not want to follow it all the time, but when you break one of these rules, you should know that you're doing so, and have a good reason for it.
The last two books in my winter storm reading list are much less applied than the aforementioned ones, but in some ways a lot more fun. Gary Flake's The Computational Beauty of Nature is the book that the author wishes someone had given him when he first became interested in fractals, chaos, adaptation, and other "sixth generation" topics. It contains code, mathematics, and (most importantly) explanations to help you make sense of these subjects, and many more. You'll need at least college-level calculus to make sense of some parts, and Flake is clearly not afraid of using big words, but this is a solid starting point for anyone with a serious interest in computational approaches to complex systems.
Finally, there is Paun et al.'s DNA Computing. I confess right now that I only skimmed much of this book -- if you haven't done a graduate-level course on computational formalisms recently, you'll probably have to skim parts too. The book looks at what sorts of computations can theoretically be done using DNA by developing a theoretical model of what DNA molecules can do based on "sticker systems." The authors pull no punches: There's a lot of hard math on virtually every page, and most of my undergraduate course on finite automata and grammars is compressed into about 10 pages. Still, the ideas are exciting, as is the fact that a solid theoretical basis for this kind of thing is now appearing. I don't expect to read "DNA Computing in a Nutshell" any time soon, but who knows? I didn't expect Huw and Gary to get their site up as quickly as they did...
DDJ