The Third Bit

Last year, Dr. Dobb’s Journal ran a series of short articles describing some of 2005′s Summer of Code projects, and we’d like to give this year’s participants the same kind of recognition. Some samples from the last time around are on the new DDJ web site at:

• http://www.ddj.com/184406349
• http://www.ddj.com/184406383
• http://www.ddj.com/184406437
• http://www.ddj.com/184406467

If you’re an SoC mentor or student, please have a look—if you’d like to contribute something similar this year, please write a draft similar in length and format to the examples, and send it with a short bio and photo to the editor, Jon Erickson, at jerickson@ddj.com.

Writing

Now that my new laptop and monitor are working [1], I hope to wrap up Version 2 of the Software Carpentry notes and close the file. However, the last step is one I can’t take myself: I need 4-5 hours of help from someone who knows their way around CSS, and can rewrite my rather crufty style files to make the notes beautiful. If you’re interested in contributing to this particular open source project, please contact me.

Uncategorized

Todd Veldhuizen (who is, as I have observed before, simultaneously one of the smartest nice guys, and nicest smart guys, I know) has just accepted a position at the University of Waterloo. It’ll be great to have him back in Canada.

Uncategorized

I know a fair bit about GNU Make, but this one has me stymied. The Makefile that rebuilds the Software Carpentry course notes contains the following definitions:

GFX_SUFFIX := gif jpg png
GFX_SRC := \
    $(foreach fmt,$(GFX_SUFFIX),\
      $(wildcard ./img/*.${fmt}) \
      $(wildcard ./lec/img/*/*.${fmt}) \
      $(foreach sitedir,${SITES}, \
        $(wildcard ./sites/${sitedir}/img/*.${fmt}) \
      ) \
    )
GFX_WEB := $(subst ./,./web/,${GFX_SRC})

On all of the Linux and Windows (with Cygwin) machines I’ve used to date, this does the right thing: GFX_SRC is a list of all the image files in ./img and ./lec/img/*, and GFX_WEB has the same entries with ./web prefixed to them. (The SITES variable is empty, because I’m not building any site-specific content.)

But on my new Windows laptop (again with Cygwin), something goes wrong: Make misses two of the files in the lec/img/oop01 direcctory, and tries to copy one file from the lec/img/oop02 directory twice: once under lec/img/oop02, and once (incorrectly) under lec/img/oop01. Since this doesn’t exist, Make reports an error and halts.

I’ve checked versions, and all five machines are using GNU Make 3.80. Is this a bug in Make? In the way I’m defining my variables? If so, why is it only triggered on the one box?

Uncategorized

I’ve revised the Software Carpentry lecture on using team tools. I’d be grateful for feedback.

Software Carpentry

When Diomidis Spinellis’s first book, Code Reading, came out in 2003, I said that it didn’t matter whether you were still in high school, or had been programming for 30 years—it would teach you things you really needed to know. Well, guess what? The second one is even better.

Code Quality picks up where Code Reading left off. Instead of explaining how to find your way around in large projects, it tells you how to judge the quality of what you’re looking at. Spinellis breaks this down into seven categories: reliability, security, time performance, space performance, portability, maintainability, and floating-point arithmetic. Each gets a chapter of its own; each chapter draws dozens of examples from well-known open source projects, such as NetBSD, Perl, ACE, and Apache; and each example makes its point clearly and irrefutably.

Flip it open at random. Page 414 dissects the sin of code duplication; the accompanying diagram shows how many hundreds of lines of code have been copied and pasted in the Catalina class loader. Page 279 compares the number of instructions required to call a virtual method with the number required to inline the same operation, then goes on to explain why such simple comparisons can be misleading. Flip back, and page 432 is the start of a 19-page discussion of testability.

Like its predecessor, Code Quality is a bit dry—I’ve read half a chapter at a time for two weeks—and very Unix-centric. Those are minor—nay, miniscule—complaints, though: the book ought to be required reading in every undergraduate software engineering program, and everything it covers should be on every professional developer’s check-list.

---

Diomidis Spinellis: Code Quality: The Open Source Perspective. Addison-Wesley, 2006, 608 pages, 0321166078, $54.99.

Books

I spent the last boom working with a team that took security very (very) seriously. As a result, when I look at most of the software I use—at the web sites I sign into every day, or at the dozen and one applications I run on my desktop—I can’t help but wonder how many holes they have. Everyone now acknowledges the scale of the problem, but all too often, good intentions aren’t translated into practice because developers simply don’t know where to start.

Kenan and McGraw’s new books can both help. Kenan works for Symantec; his book is a very detailed look at how how to go about securing data that’s stored in relational databases. And when I say “detailed”, I mean it: this is a brick-by-brick description of a security architecture that covers everything from crypto engines and key management to the process changes needed to produce hardened requirements. The extended example that takes up the last third of the book shows how to put these ideas into practice using Java.

In contrast, McGraw’s book is more forest than trees. While his earlier books focused on secure coding, this one steps back and looks at what development teams have to do to ensure that security gets built into the product from the start. Its material is organized into three broad themes: risk management, touchpoints, and general knowledge. The first and third are self-explanatory, and his discussion of them is mostly common sense (i.e., things most of us would realize only in hindsight). The second is a set of best practices: abuse cases to go with your use cases, risk-based security testing, code reviews and reviewing tools, penetration testing, and so on.

McGraw’s book is a lot to absorb: more step-by-step examples like the ones in Kenan’s book would certainly have made its 448 pages easier to absorb. On the other hand, it does cover the whole process from end to end, while Kenan focuses solely on one technical aspect.

---

Kevin Kenan: Cryptography in the Database. Addison-Wesley, 2005, 0321320735, 312 pages, $44.99.

Gary McGraw: Software Security: Building Security In. Addison-Wesley, 2006, 0321356705, 448 pages, $49.99.

Books

For the past ten years, I’ve been trying to learn as much as I can about small-scale software engineering: what to do when you have a dozen people, a dozen months, and a dozen major features to implement. My reasons are partly personal—I don’t like working in large, bureaucratic organizations whose HR departments have more people in them than my home town—but it also seems that a lot of what’s cool in our industry starts off in groups that size.

In order to understand what development practices make sense for groups that size, I’ve had to learn what makes small companies succeed or fail. I’ve therefore found myself reading less about bytes, and more about balance sheets. Much to my surprise, I’ve been enjoying it, especially when it gives me an excuse to read books like these two.

The first of the pair is Eric Sink’s Business of Software. Like Joel Spolsky’s Joel on Software (reviewed here in June 2005), it began life as a series of blog postings. The chapters are short, the language is informal without being chatty, and the author’s prefatory comments add a fresh breath of after-the-fact perspective. The book starts by asking, “What is an independent software vendor (ISV)?”, then goes on to look at how to pick a product idea, how to figure out whether there’s a market for it, who to hire, and so on. Sink draws on his own experience with SourceGear Vault and other projects to illustrate his points, and throws in just the right number of amusing anecdotes.

The second book, Bob Walsh’s Micro-ISV: From Vision to Reality, is more structured. As Walsh says on the back-cover blurb, “I wrote this book because it didn’t exist when I decided it was high time for me to start my own micro-ISV.” It’s only a few pages longer than Sink’s, but significantly denser: there are more quotes and references, lots of screenshots, and more case studies than anecdotes. I didn’t grin as often while reading it, but I put in a lot more yellow sticky notes, and would seriously consider using it as a textbook in a course on the business of software.

Which one should you read? I’d say both: the sixty-odd dollars and ten hours they cost could well be the best investment you ever make. If you’re serious about going solo, though, I’d start with Walsh’s, and take lots of notes.

---

Eric Sink: Eric Sink on the Business of Software. Apress, 2006, 1590596234, 301 pages, $24.99.

Bob Walsh: Micro-ISV: From Vision to Reality. Apress, 2006, 1590596013, 376 pages, $29.99.

Books

Thanks to Noah Lockwood, I have a workaround for the PNG printing problem in the Software Carpentry notes: get rid of the transparency, and use a colored background instead. If it’s light enough, it’ll print as white from both IE and Firefox (on Windows, at least — haven’t tried Linux or Mac). Noah tells me that printing transparent PNGs has been a known problem with Firefox for at least two years, and that the only fix for IE 6 involves Javascript. Me, I’m happy to close this ticket off and move on…

…except for the places where the source images were actually white, rather than transparent. The way we colorized the backgrounds was to create a new beige layer, and slide it to the bottom of the image; those arrowheads and boxes that are solidly colored, instead of transparent, now look a little odd on the web, though they print cleanly. Flood-filling or replacing all 0xFFFFFF pixels with 0xFFFFD2 won’t solve the problem: the images are anti-aliased, so a straight replace-pixel-by-color leaves white jaggies. Converting to GIF has the same effect, for the same reason. But it’s close enough for now: I’m going to tackle the regexp markers next, and then try rewriting the second development lecture.

Uncategorized

Revision 1111 of Software Carpentry just went into the repository. All the images are now there (thanks, Nick), along with code fragments and exercises (not as many as I’d like, but enough to get people started). Printed, it comes to 346 pages, but don’t do this at home—the supposedly-transparent PNGs are still solid black when printed.

Things I’d like to do (or would like volunteers to contribute in the usual open source way) include:

• #5: complete the description of how to use the subprocess module.
• #14: add a lecture on numerical programming, and another one on how to test numerical code.
• #24, #25, #115, and #120: put material on eval, exec, code coverage, profiling, and other reflective ideas back in.
• #28: fix the markers around regular expressions so that they display on all platforms.
• #40: add a lecture on object-oriented analysis and design using the ICONIX process.
• #65: come up with a better way to display the evolution of code fragments on-line using JavaScript.
• #67: document the XML markup used in slides so that other people can easily contribute.
• #93: fix image backgrounds so that they print properly.
• Several: clean up the build process used to produce the notes.
• #105: automatically check that all Python source examples conform to style guidelines.
• #116: put material on time/date handling back into lectures.
• #121: add a second lecture on style that focuses on what makes a good (or bad) class.

Any volunteers?

Software Carpentry