Back when I wrote firmware for a living, every project had an exciting phase in the middle which we called “bringing up the board.” Bringing up the board consisted of getting a fresh, chemical-smelling new circuit board from a short-run manufacturer, applying power to it, and attempting to take control of it with software. It sat neatly in between a very waterfall-ish design and coding phase at the beginning and a very deathmarch-y integration and test phase at the end.

Bringing up a board requires intensive, cross-disciplinary debugging in which very few abstractions are of any use to the engineer. Rarely do enterprise software developers think about things like reset vectors and fetch-and-execute cycles (much less voltages and currents), but these are the stock in trade of the firmware developer working with a brand new hardware design. The phase is full of the seemingly intractable problems and contradictions that normally attend test-last debugging. Inevitably, at least once on each project, some impossible condition will arise in which the engineer knows he is flipping a bit in a control register somewhere, and he knows the corresponding digital output pin is driving a high impedance, but somehow under such-and-such conditions the trace on the oscilloscope barely wiggles when it should be banging back and forth between five volts and zero. He’s sure of everything else in the system, he knows he’s got the address of the control register right, he’s certain he understands the circuit the output is driving. There’s just no other option: Ohm’s Law must be wrong in this case.

Of course it never is. And while widely used, production-ready web frameworks like Grails are less reliable than fundamental laws of physics, they can probably handle trivial form submissions with aplomb. Of course, that still didn’t stop me from thinking Grails had a bug last week.

I had generated some scaffolding for a fairly simple domain class, and had begun elaborating on it in the way that any Grails developer does for a real-life application. The GSP code looked something like this:

When I clicked on the submit button, I got a 404 error. I verified that AssessmentController had a save action, which it did. I bounced Grails, which I was running in dev mode. Still no love. I banged my head against this for a while, unable to believe that I couldn’t get a form submission to work. Was it some strangle UrlMapping oddity? Was it a problem with allowed HTTP methods? Nothing made sense.

So I decided to bypass the Grails GSP tags and code up a form myself. It looked like this:

Question 1: Question 2: Question 3: Question 4:

That worked perfectly! My next task was to figure out what was different between the two requests. Ever a fan of the big hammer (my favorite debugging tool in my firmware days was the oscilloscope), I broke out HttpFox to see what was happening on the wire.

I saw, as you might expect, two apparently identical requests that looked something like this:

No differences in headers, request URL, or anything that might affect how the request would be routed to an action. Everything was the same until I looked at the POST Data tab. The version of the form that was built by the Grails tags looked like this:

while my custom form generated these parameters:

The _action_Submit vs submit difference should have tipped me off right away, but it didn’t. I had simply forgotten that Grails is capable of doing request mapping through the submit button, so I continued plugging away at the code for longer than I’d care to admit. I knew at this point that there was some kind of internal processing of this form parameter going on, and was ready to resign myself to spelunking in the source to figure out what it was. Since this was such a basic operation going on here, surely this had to be a bug in the framework excited by an as-yet-undetected subtlety in my form markup. Surely. Then it hit me: the form code I was debugging used . Shouldn’t that be ?

Sure it should, if g:submitButton is all you ever use. I’ve never been a big fan of scaffolding—a conceit I have long suspected is to my detriment, and one I am currently in the process of reforming—and I had never had occasion to become familiar with g:actionSubmit. What that magical tag does is allow you to include multiple submit buttons inside a single form, each of which targets its own action within a given controller. Great idea, and great tag. And an epic failure if you’re trying to accomplish mapping through the tag and ignore the submit button tag’s parameters altogether.

I’m tempted to conclude that the moral to the story is to know how your web framework accomplishes simple tasks like form submissions, even if it throws a few nice features your way to spice them up a bit. And there is nothing wrong with knowing this; in fact, it’s a good trick if you can do it.

The real lesson, however, is about debugging. Ohm’s Law is never, ever, ever wrong, and when you sit down with ohmmeter and oscilloscope and proceed to prove that it is, all you’re doing is establishing that your mental model of the problem is badly off-base. Grails, like any web framework or well-used public API, sometimes is wrong—it is not a fundamental physical law—but public releases probably aren’t wrong about trivial things like form submissions. If you think you’ve got a bug so obvious that someone had to have caught it in the past, then somebody probably did. The bug is probably with you, either trivially in your code or even in your debugging process itself. In the heat of the chase, it can be difficult to remember this, but how often is the resolution to the story actually some complex subtlety that takes hours to explain? Sometimes it is, but most of the time you’re just using the wrong tag. Looking for the obvious is probably going to pay off well in advance of a deep dive into the code. Or, for that matter, a reconsideration of classical physics.

I’m building some simple .NET web services in a VMWare Fusion VM running Windows XP. I’d like to consume those web services from Grails code I’m developing on the host OS, which is a Mac. The easiest way to hit IIS in the VM is to switch the network connection to bridged mode, as shown here:

I had been doing this happily for a week or so, when suddenly yesterday afternoon it quit working. I tried to put a new VM into bridged mode, and I got this unhappy dialog box:

The guest OS (Windows XP) was insisting that the network cable was unplugged on my virtual LAN adaptor, and I had no way to hit my .NET services from the glorious host OS. Googling around a bit suggested that this was a problem when the Mac had more than one network adaptor configured, but that made no sense: I always have two network adaptors (wireless and wired), and have done bridging successfully while using one or the other, and sometimes while both are recognized by the OS as live options for network traffic.

Skipping to the end for your convenience, it turns out the problem was with the VPN. I can use bridged networking as much as I like, just as long as the Mac is not connected to the VPN. Even if I try to establish bridged mode while disconnected from the VPN, then connect to the VPN afterwards, it still disabled by bridged network adaptor in the guest OS. Host VPN and bridged guest simply will not coexist.

Which is great and all, but the .NET services I’m running in XP need to connect to a database server available on the client’s private network, so without a VPN, I’m sunk. The happy ending is that I can establish a VPN connection in the guest OS—in Windows—while the Mac is happily VPN-free. This still disables some of the tooling I rely on for efficient development, but it’s as good as it’s going to get, and ultimately, it’s workable.

Two weeks ago I finally succumbed to the temptation to order a Kindle. Availing myself of my Amazon Prime subscription—a service which may now find itself obsolescent—I had the device in my hands last Wednesday. My goal wasn’t just to have a new and more convenient way to read, but to figure out whether the Kindle actually delivers on that promise.

It came out of its elegant, Apple-like packaging with an image on its screen—not something you expect from a powered-off device. Having seen a Sony ebook reader before, I expected the Kindle’s screen to look fake, and it did. It was as if someone had cut out a piece of printed paper and glued it on the front of the unit. Its somewhat odd power switch worked fine, and it turned on after a few seconds. It was easy to connect it with my Amazon account (I don’t even remember the process, in fact) and wirelessly browse the Amazon store through the 3G “Whisperlink” connection. My first book purchase, which I made from the web site on my laptop, appeared on the Kindle quickly.

My first impulse, and the first impulse of several other new users who got their hands on it, was to tap the screen. I expected to swipe to turn pages, and I presumptuously expected a multi-touch gesture to bring up a coverflow-like view of the pages through which I could scroll by swiping. Somehow I doubt my reaction is unique, at least among iPhone users. At first blush, it seems imperative that future generation devices support a touchscreen.

Actual reading is quite pleasant. Text is almost suspiciously crisp and passive-looking, just like a printed page. The digital paper display is famously slow to update, reminding me of laptop screens from twenty years ago. This makes interactive functions like scrolling through menus, navigating tables of contents, or shopping in the store somewhat frustrating (and it would render my expected touchscreen functionality all but useless), but is easy to overcome in actual reading. I soon learned to anticipate the page refresh delay by pressing the next page button while my eyes were somewhere near the beginning of the last line of text on each page.

Later, I pushed a few of my book purchases to the Kindle app on my iPhone. There is an immediately obvious difference in the feel of reading on the iPhone and on the Kindle. On the iPhone, the expected touch gestures work. There’s still still no multi-touch coverflow interface, but there is a draggable slider that quickly scrolls to any location in the book. The book seems more interactive, and has a massless quality to it. Compared to the Kindle, the iPhone screen itself looks alive. You can quickly be anywhere in a text almost as easily as flipping the pages of a bound paper book. The same text on a Kindle has some random access capability through the table of contents and the search function, but otherwise the slow speed of the display rewards sequential, page-after-page reading.

In other words, reading the Kindle is more like a reading scroll than a bound book—a scroll with a search box.

So my first reaction is positive, and I’m going to continue favoring it for the delivery of new books when possible. I’d like to use it for several different kinds of material (i.e., fiction, technology, theology, article-sized works, etc.) to get a sense for how the different reading habits associated with different texts work on the device. My larger question, which can only be answered over the course of months, is how the new form will alter my reading habits and my perception of the texts themselves. Even if, pace McLuhan, the medium isn’t identical the message in a strict sense, the message is clearly shaped and constrained by the medium in important ways. It seems clear that ebook readers will be a big part of the future of text, so understanding the new form might be a good plan.