The Third Bit

Why are so many computers so insecure? As Whitten and Tygar pointed out in their 1999 USENIX paper, “Why Johnny Can’t Encrypt”, the biggest reason may be that most security software is hard to use. Requiring people to know how DNS works in order to turn on a firewall is a good way to ensure that they never turn it on. Similarly, Sending people 25-character license keys that use both 0′s and O’s (recent personal experience—still bitter) doesn’t make anything safer from piracy, since it actually is easier to google for a cracker than to try all plausible permutations of the license.

That’s why I had high hopes for Security and Usability. Unfortunately, the book didn’t live up to them. These “34 groundbreaking essays from leading…researchers around the world” are what I’d expect to find in an academic journal, rather than the how-to-do-it for which O’Reilly is famous. Many of the individual articles are interesting, but I felt there was too much stamp collecting, and not enough physics. My recommendation would therefore be borrow and browse, rather than buy.

Pro PHP Security, on the other hand, is very much a how-to book, and a very useful one. PHP has a bad reputation when it comes to security—by making web programming easy, it also made it easy for people to do things the wrong way. This book takes the reader step by step through common attacks, such as session hijacking and cross-site scripting, and explains how to foil each. While the examples are all in PHP, the discussion is thorough enough that many of the ideas can be applied directly to Ruby, Python, and other nimble languages. If you’re using PHP, this book’s definitely worth buying.

---

Lorraine Faith Cranor and Simson Garfinkel (eds): Security and Usability: Designing Secure Systems That People Can Use. O’Reilly, 2005, 0596008279, 715 pages.Chris Snyder and Michael Southwell: Pro PHP Security. APress, 2005, 1590595084, 500 pages.

Books

I always feel badly about giving a book a poor review. Whatever else it may be, it’s somebody’s baby. Someone put hundreds or thousands of hours into saying something they thought was important (or at least, something they thought other people would spend money to know). Sometimes I find myself making excuses for books, like “Maybe I’m just not its target market” (translation: I can’t imagine who it’s for). But when I read two books on the same subject back to back, and one is so clearly better than the other, it’s hard not to point that out.

So: Augustine’s Managing Agile Projects was, unfortunately, not as good a book as Berkun’s Art of Project Management. Its core content was solid enough: if you believe in agile methods (I’m still agnostic), then MAP is a usable description of what you have to do other than program in order to make a project succeed. However, I’ve had to sit through a lot of talks by managers who were using buzz words as a substitute for real understanding. As a result, when someone starts using terms like “fractal teams”, I have to wonder whether I’m getting meat or bun. Similarly, telling me to evolve a shared team vision is all very nice (hugs all around!), but how do I know when I’ve got one? I mean, how do I actually know, unequivocally, that people are on the same page?

In contrast, it’s clear from the first page of The Art of Project Management that Berkun understands how software developers think, what frustrates them, and what they want to know. The book is divided into three sections, called “Plans”, “Skills”, and “Management”. Each is full of hardheaded advice on topics ranging from scheduling to decision making and what should be in a product requirements document.

Just as importantly, Berkun talks about the really important parts of management—team building, trust, and communication—in a much more concrete way than most other management books. There’s no Zen, no quotes from German philosophers that I’m pretty sure he hasn’t read, and no kayaking anecdotes. Instead, he says that if you’ve fallen behind, one way to catch up is to hide from everyone for a few days so that you won’t be interrupted, and that another is to call in favors, beg, and bribe people. Don’t be misled by the soft-edged diagrams: Berkun is clearly a get-it-done kind of manager, and this is very much a get-it-done book.

---

Sanjiv Augustine: Managing Agile Projects. Prentice Hall PTR, 2005, 0131240714, 229 pages.

Scott Berkun: The Art of Project Management. O’Reilly, 2005, 0596007868, 374 pages.

Books

In 2002, scientists at Lawrence Livermore National Laboratory found that on average, 12% of the effort in a large project went into maintaining the build environment, and that on some projects, the figure was in the 20-30% range. If you include the time needed to cull stale entries from the bugbase, figure out which parts of the documentation are out of date, and manage tests, it’s surprising that any actual development ever gets done.

Luckily for all of us, Matt Doar has produced a practical guide to what should be in every team’s toolbox, how competing entries stack up, and how they ought to be used. His new book, Practical Development Environments, covers everything from configuration management tools like CVS and Subversion, to build tools (make, GNU’s Autotools, Ant, Jam, and SCons), various testing aids, bug tracking systems, documentation generators, and we’re still only at the halfway mark. He names names, provides links, and treats free and commercial offerings on equal terms. My copy currently has 28 folded-down corners, which is 28 more than most books get; recommended.

Neither of the other two books in this list measures up to this high standard. Maraia’s The Build Master is an uneven mix of how Microsoft does it (good), management advice (less so), and anecdoes (uneven). Some of the material is eminently practical, and if he had concentrated on that, and provided more example code, I’d give this book good marks. As it is, he seems to be trying to distil everything he’s learned into one book.

Fit for Developing Software, on the other hand, is very focused. It describes Fit, a table-based framework for organizing and running tests that’s the best idea to come along since JUnit. I like Fit (and its web version, Fitnesse), but I came out of the first four chapters of this book feeling like I knew less than I had before I started. I understand that there’s always tension between breadth-first and depth-first exposition, but this book seemed to follow neither. In the end, I found the best way to use it was via the index (a primitive form of Google, for those of you under 25). Fit’s great, and everyone should use it, but if your mind’s built along the same lines as mine, this book is probably not the best place to start learning about it.

---

Matthew B. Doar: Practical Development Environments. O’Reilly, 2005, 0596007965, 297 pages.

Vincent Maraia: The Build Master: Microsoft’s Software Configuration Management Best Practices. Addison-Wesley, 2006, 0321332059, 288 pages.

Rick Mugridge and Ward Cunningham: Fit for Developing Software. Prentice Hall PTR, 2005, 0321269349, 355 pages.

Books

We’ve all cursed slow software and unresponsive web sites, and most of us have probably built a few, but making them zippy is often as big a challenge as building them in the first place. One reason is that modern computer systems are among the complex artifacts ever created; another is that their components often interact in counter-intuitive ways, so that optimizing a loop or adding another server can actually slow the whole system down.

Gunther’s Analyzing Computer System Performance with Perl::PDQ, and Menascé et al’s Performance by Design, both aim to introduce developers to the mathematics used to analyze and predict system performance. Both start with the kinds of simple models used to figure out how many customers a grocery store checkout clerk can handle in an hour. From there, they move on to more complex setups with preemptive interrupts or feedback loops.

Both books compare theory’s predictions with measurements of actual systems, and both are clearly written and well organized. The big difference between them is their pace: Menascé et al is a gentle stroll, while Gunther varies between a fast jog and a gallop. As a result, I often found myself flipping ahead in Menascé, but flipping back to re-read something crucial in Gunther. The extra effort Gunther requires is paid back by the Perl toolkit his book is built around, but on the other hand, I sometimes found myself tripping over minor layout problems, such as the word Perlfollowed immediately by another word without a break.

Which book you read depends on how much calculus and probability you remember, and how complex the systems you’re trying to tune are. If you’re building something whose performance matters, though, you should definitely read one. Otherwise, you may find that a week reconfiguring a server farm has saved you twenty minutes of thought.

---

Neil J. Gunther: Analyzing Computer System Performance with Perl::PDQ. Springer, 2005, 3540208658, 536 pages.

Daniel A. Menascé, Virgilio A.F. Almeida, and Lawrence W. Dowdy: Performance by Design. Prentice Hall PTR, 2004, 0130906735, 462 pages.

Books

This post, from Kathy Sierra, is a lighthearted look at how well-designed software should behave. Those of you building your first real web application, take heed…

Uncategorized

Paul Gries, Arnold Rosenbloom, and I spoke to the Toronto Java Users’ Group meeting this past Tuesday about Java as a teaching language. It was fun, and the questions and comments from the audience gave me lots to think about — as did the fact that of the 45 people there, only one was female. That, and this, and hearing about schools with a 60:1 male/female ratio, makes me feel weary. (For the record, the ratio in my project course stands at 3:1.)

Equity

If the smart paintbrush posted earlier wasn’t enough to drop your jaw, try this (thanks to Miles Thibault).

Uncategorized

As I’ve mentioned before, I’m running a workshop on “Essential Software Skills for Research Scientists” at the Annual Meeting of the American Association for the Advancement of Science on Friday, February 17, in St Louis. I’m hoping to use the workshop to convince scientists, administrators, and policy makers that the things covered in the Software Carpentry course are essential to good science. If you know someone who ought to attend, please let them know, or pass them my contact information.

Software Carpentry