The Third Bit

Michael Swanson has posted an article about continuous integration, which covers much of the same material as Mike Clark’s new book on project automation. The idea is a simple one: every 15 minutes (or hour, or whatever), an automated process checks out a clean copy of the project source, builds it, runs the unit tests, and generates a report, so that project stakeholders always know where the project is.

What adds spice to Swanson’s and Clark’s descriptions is the various devices people use for communicating with developers. Red and green LavaLamps are one way: red means that something’s broken, while green is the all-clear. I (briefly) thought about wiring up a hula dancer doll to let the Helium team know where they were. (“The job’s not done ’til the hula dancer shimmies” has a kind of ring to it, don’t you think?) However, I find the white-noise hiss of headphones three cubicles away annoying enough; trying to design complex software to the sound of a six-inch figurine’s grass skirt doesn’t really appeal…

There is an open source tool for managing continuous integration, called CruiseControl. It uses Ant to build code, then generates an HTML report, sends email, or whatever, all at regular intervals.

Or at least, it’s supposed to. Michelle Levesque spent several hours trying to get it set up on the Debian Linux box that hosts our projects, without luck. Like too many open source projects (including Subversion), CruiseControl requires a lot of configuration, including re-configuration of previously-installed packages. As a result, many fewer people will use it than should.

Contrast this with JUnit. If someone had told me five years ago that thousands of programmers would routintely write unit tests within my lifetime, I wouldn’t have believed it. JUnit has changed that, not only because it’s easy to use, but also because it’s easy to set up.

Which is why I’m worried that we’re probably going to incorporate ViewCVS into Helium, at least initially. I have nothing against ViewCVS per se—it’s written in my favorite language, and I’m in favor of recycling software. My concern is that it’s yet another external dependency, which means yet another thing that administrators might have to upgrade, downgrade, sidegrade, wrestle with, curse, or whack. If Helium is going to be used by other institutions (which I’d like it to be), ease of installation is crucial.

Uncategorized

Kanglin Li and Mengqi Wu: Effective Software Test Automation.
Sybex, 2004, 0782143202, 408 pages.

---

One of the most important features of the “New Standard Model” of
programming is its emphasis on unit testing. Just five years after
the first version of JUnit was written, an ever-increasing number of
programmers actually create and run tests as a matter of course.

But writing tests by hand is still tedious, and still requires a fair
degree of programming skill. Enter Li and Wu’s new book. Over the
course of twelve detailed (and sometimes rather intense) chapters, the
authors explain how to build a higher-level testing tool for .NET
programs using:

• reflection, to find and call the methods being tested;
• CodeDOM, to generate testing code from specifications; and
• Excel, as a user interface.

Using an application like Excel as a UI may sound strange to Unix
programmers, but thanks to its COM interface, programs can drive it,
and read data from it, with ease. Once QA staff have created a
spreadsheet full of tests, the tool described in this book reads in
their test cases, generates code to implement those tests, loads the
classes to be tested, and runs that code.

The testing tool by itself is interesting and useful, but what I
really enjoyed about this book was the authors’ explanation of how to
build it. Flat text files and handwritten code will always be with
us, but structured data and machine-generated code are becoming more
important with every passing day. If you’d like a glimpse at how the
next generation is going to program, this book is a good place to
start.

Books

Mike Gunderloy: Coder to Developer. Sybex, 2004, 078214327X, 297 pages.

---

When I was a young lad, there weren’t many books that would teach you
how to program. Oh, there were plenty that talked about this
language, or that algorithm, but if you wanted to learn the mechanics
of developing software that worked, there was Brian Kernighan’s
Software Tools in Pascal, and very little else.

Twenty-two years later, there’s still only a handful to choose from.
The good news about Gunderloy’s Coder to Developer is that it
increases the number by one. This practical, readable book is
subtitled Tools and Strategies for Delivering Your Software, and
that’s exactly what it’s about. Project planning, source code
control, unit testing, logging, and build management are all there.
Importantly, so are newer topics, like building plugins for your IDE,
code generation, and things you can do to protect your intellectual
property.

Everything is clearly explained, and illustrated with well-chosen
examples. While the focus is definitely on .NET, Gunderloy covers a
wide range of other technologies, both proprietary and open source.
I’m already using two new tools based on references from this book,
and plan to make the chapter on “Working with Small Teams” required
reading for my students.

Coder to Developer is a little more nuts ‘n’ bolts than Hunt and Thomas’s Pragmatic Programmer, but just as well written, and just as useful. Two thumbs up.

Books

Joe Walnes, Ara Abrahamian, Mike Cannon-Brookes, and Pat Lightbody:
Java Open Source Programming. Wiley, 2004, 0471463620, 459 pages.

---

In physics, the Standard Model is today’s baseline explanation of How
It All Works. It encompasses quarks, leptons, force-carrying
particles—pretty much everything except gravity. From subatomic
physics to cosmology, practically everyone builds their theory in its
image, hoping to create a new standard to supplant today’s.

For developers of my generation, the Standard Model of programming
consisted of C, Emacs, Make, Unix command-line tools like cat and
grep, CVS, and character streams. Now, twenty-five years later, a
replacement is taking shape. Its main elements are:

• Java
• Eclipse and its many plugins
• Ant (for building), JUnit (for testing), and Subversion (for version
  control)
• reflection for making systems extensible; and
• XML as a universal storage format.

So much of this New Standard Model is open source that most of the
books describing it—including this new one from Walnes et al—have
the word in their title. The first half of JOSP shows readers how
to build yet another on-line pet store. Instead of starting with
servlets, however, the authors begin by explaining how they will test
the application with JUnit and dynamically-generated mock objects, and
how they will use Hibernate to handle database persistence.

The application itself is then built using WebWork (a
Model-View-Controller framework) and SiteMesh (for layout). Search is
added using Lucene, XDoclet is used to generate configuration files
from metadata embedded in the Java source, and then the authors pause
to describe how they communicate via CVS, wikis, mailing lists, IRC,
and so on.

And we’re not even at page 200 yet…

The second half of the book goes back over the application, replacing
the simple throwaway prototypes of the first half with versions that
could carry their weight in the real world. Want to know how an
experienced developer figures out how to manage object lifecycles and
dependencies? That’s Chapter 14. Look and feel? Chapter 17.
There’s even some discussion of security, although this material felt
like an afterthought, and didn’t quite live up to the standard set by
the rest of the book.

Which is quite high. The writing is clean, the examples are explained
well, and the authors didn’t waste time grinding methodological axes.
It’s definitely not for beginners, but every professional developer
will find something useful in this clear, topical survey.

Books

Michelle Levesque recently posted about her discovery that scripting the existing partial implementation of Helium would help her develop the rest of it. Scriptability is actually one of the system’s must-have features: instructors must be able to create accounts and projects by the dozens, to assign people to groups by processing ad hoc flat files, and so on.

So what are our options?

1. Web services: have scripts in Perl, Python, and whatever talk to the web interface we’re building for Helium anyway.
2. A library of bindings to whatever scripting language(s) we choose to support (probably managed using SWIG).
3. Use of a Java-friendly scripting language that can talk to Helium‘s model directly.

The third option appeals to me most, as it seems like the least work. Several scripting languages, like Jython (the Java implementation of Python) and Rhino (Mozilla’s pure-Java implementation of JavaScript) can manipulate Java classes directly. It sounds like a good fit, but I’ve never used either in anger. I’d enjoy hearing from anyone who has…

Uncategorized

People talk about code reviews far more often than they do them, despite the fact that everyone (reviewers and coders alike) seems to get a lot out of them. We’ve been talking about implementing code reviews in my real job for almost four years, but have never actually gotten around to doing it.

So, I marked up 48 pages of Helium on the way back from Montreal last Sunday, and spent a couple of hours going over it with the team Monday morning. We covered everything from low-level formatting and out-of-date JavaDoc, to asymmetrical class design and
poor choice of data structures. I learned a lot about why the code is structured the way it is—in particular, about some of the restrictions and requirements associated with Hibernate—while the team came away with a much better idea of what they’re actually expected to do. Three and a half hours of reading, two hours of talking—I think it was a good investment.

I’d really like to get code reviews into the undergraduate curriculum. The major obstacle is the chicken-and-egg problem: most instructors and TAs have never been subjected to a code review, so how can they teach students how to do them? Reading Code, by Diomidis Spinellis, is a start, but (a) it’s very C-oriented, (b) it’s more about reading code than reviewing it, and (c) who has time to read several hundred pages in order to put together a lecture or two?

One possibility (which some study group members are investigating) is to use code metrics to identify suspicious code segments, and focus on reviewing those. For an example of a metrics-driven review process, see this article by Michael Swanson. It’s also worth reading the Mozilla Code Review FAQ to get an idea of how a large open source project handles this.

[1] Asymmetrical class design means that two classes that seem to do similar things do them differently; in Helium‘s case, this is required by our object/relational mapping layer, Hibernate.

[2] Helium‘s data model contains users, user groups (which are sets of users or other user groups), projects (which are organized in a tree), and memberships (each of which represents a single user or user group’s association with a single project). Right now, each UserGroup stores its members in a Set. This allows fast lookup, but only if you already have the object you’re looking for. In most cases, the code actually iterates through the set’s members, comparing a user’s name with the name recorded in the set entry. A cleverer data structure would allow lookup either by object identity or by name, but would require more work to maintain consistency. I’ve told team members not to worry about it for now, since we’re not going to bump into performance problems for a long, long time…

Uncategorized

Among other Helium tasks, I’ve working on has been some rough screenshots of what our web interface might end up looking like. What I’ve found interesting about the very high-level design process, is that I kept needing to go lower and lower in order to make the design steps easier. And all of a sudden found myself hitting where those doing the low-level design (and working their way higher) were sitting.

The screenshots started as doodles on the whiteboard. These doodles were soon converted into paper format, to make them more permanent. But as we needed them changed more and more frequently, it became difficult to manage them in paper format, so I made some rough HTML pages.

But then I started finding it tiresome to create a similar top and sidebar for every page, so I wrote a quick hacky Python script to generate these automatically. But as the pages developed in complexity, simply generating a common top and sidebar wasn’t enough: I needed more control over the pages. So I started writing some Python classes to represent projects that the mock user belonged to, so that I could just tweak the class objects in order to make site-wide changes easily.

Anyway, to make a long story short, this week I’ve found my hacky scripts inadequate again. What I really need are some User objects, and Project objects, and Membership objects, and Message objects and Conversations, and…well…basically exactly what we’ve been designing to represent the backend of Helium. I finally hit a point where I needed the backend to drive the frontend: and what I needed matched exactly with what we’d designed to build.

To me, this is cool. Means we’re doing something right, at least.

---

Greg Wilson adds: one of Helium’s must-have features is a scripting interface, so that instructors can quickly write little programs to add a hundred projects, file an identical bug report against each, and so on. Michelle has discovered that developers have the same need: once anything is running, you can accelerate further development by scripting it.

Uncategorized

One of the blogs I read (can’t remember which) said a couple of weeks
ago that almost all of the programming productivity gains we ascribe
to OO are in fact due to memory management and reflection. The first
stops average programmers from doing stupid things; the second allows good
ones to do amazing things. Neither absolutely requires a VM, but all
the languages that offer them these days are VM-based. (OK, so it’s a
stretch to call C# a VM-based language, but close enough.)

I was reminded of this while reading:

Kanglin Li and Mengqi Wu: Effective Software Test Automation. Sybex, 2004, 0782143202, 408 pages.

The tool this book describes uses run-time reflection to find callable
methods in the code under test, .NET CodeDOM to generate testing
code to call those methods, and Excel (yes, Excel) as a UI. The
combination lets QA engineers enter tests in a spreadsheet, then
click a button to make the tool generate the code to enact those
tests. You could do this in C++ (or even in C), but the
effort required would be so great that I doubt anyone would.

Uncategorized

Many books describe how to get a project rolling. Unfortunately, none of their descriptions match anything I’ve ever seen in the real world. For example, Rosenberg and Scott’s Use Case Driven Object Modeling with UML tells readers to write use cases (actor X does Y to achieve result Z), then extract system features from them. At the other end of the spectrum, Extreme Programming advocates pretty much the same approach; all that differs is how much you do in one go.

But how can you write use cases unless you know what the system is going to include? We intended to start Helium by writing use cases, but quickly ran into sand. Do we need a use case for “user joins user group”? Well, that depends: does our system have user groups? What about “administrator removes user from user group”—are there administrators? Mailing lists? Permissions?

What we actually wound up doing was stepping back and developing a conceptual model that specified Helium’s major entities. It was frustrating, since we couldn’t decide what to include until we knew what the system had to be able to do, but couldn’t specify what the system could do until we knew what it contained.

I think the reason software process books don’t emphasize this crucial stage is that there’s really not a lot you can say about it. It’s like asking an author, “Where do you get ideas for stories?” Or a cyclist, “How do you ride a bike?” I believe that you can show people how to do it, and coach them to help them improve, but descriptions are either banal abstractions (“Think outside the box!”) or case studies (“So then we decided to separate roles from memberships”).

I therefore think that one-on-one (or one-on-very-few) collaboration is as important in computing education as it is to music or swimming. Lectures and books can teach content, but not method, and twenty-five years of research have shown that method is what matters most. Since schools can’t afford to hire one instructor for every five or ten students (even for just a couple of courses), the best we can do is build tools that encourage students to do things the right way. That’s Helium’s real goal; we should know in a couple of years whether we’ve achieved it.

Quote of the day:

The fantasy element that explains the appeal of dungeon-clearing games to many programmers is
neither the fire-breathing monsters nor the milky-skinned, semi-clad sirens; it is the experience
of carrying out a task from start to finish without user requirements changing.


– Thomas L. Holaday

Uncategorized

Roy Osherove posted a description of his team’s whiteboard-based project management technique. Like most “agile” technologies, it won’t scale to large teams, or long-lived projects, but that isn’t the space Helium is aimed at. I’d be grateful for links to web-based project tracking and management tools that are as simple as this…

Uncategorized