Reviews: Debugging and Write Portable Code

Two books I bought recently were ones I expected to be easy going. They were, but I think they were still worthwhile.

Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David J Agans is about, well, debugging. Anything, not just software. It’s full of war stories from many domains (including cars, houses, and Sesame Street). The rules are how to logically approach problem solving, and make sure the problem is actually solved (rule 9). Most of it is common sense, but it doesn’t hurt to see it distilled. And based on the war stories, it’s easy to get wrong. Of potential use to non-developers: there’s a chapter on applying the 9 rules from the Help Desk, when you can't observe directly.

Interestingly, one of his war stories was kind of mentioned in...





Write Portable Code by Brian Hook. I’d had some dealings with Brian when I was at GameHouse, so I knew he knew his stuff. This book too was largely review (I’ve had to deal with getting code to run on different processors and compilers), but again it’s nice to have things spelled out sometimes. And I’d never heard of compile-time asserts or #pragma STDC before. Some of it’s a bit dated (version control in particular — and it must have been written right before the Mac Intel transition), but much of it is stuff you’d still have to deal with when moving between Mac and Windows — or even Mac and iOS. (Scalability is one aspect of portability.)

High-Bandwidth Sneakernet

I love the plan to deal with the huge amounts of data expected from a proposed black hole imaging project. Each station will create about 22 terabytes of raw data per day. “No imaginable link from remote mountaintops permits live telemetry of such a torrent. Astronomers will physically pull eight-pack cartridges of disk drives from the data recorders. ‘We’ll mail them,’ says Doelman. ‘You can’t beat the bandwidth of a 747 packed with hard drives.’”

iPad Data Gotcha

Just spent way too much time on the phone with AT&T. I haven’t completely resolved problems I was having with cellular access for my iPad, but I can give a warning: be 100% sure your email address is correct.

If it’s not, you won’t be able to log in again (since it’s your account name). And you won’t be able to retrieve a lost password, even with the web form that asks for IMEI and ICCID, because it’s sent to the wrong address. Nor can AT&T change it for you. And you won’t be able to stop automatic billing.

The whole idea of having plans that purport to be by the month, but expire, seems pretty lame, and is ultimately responsible for my problems. But that’s perhaps the topic of another post.

Predecessor to DiceBook

I had a reason to open up my Newton, and realized that I had written a dice roller for that platform. No PDF viewing, but it provided simplicity and easy configuration. (I apologize for the poor photograph — I can’t remember how to take a screen capture from the device.)

I don’t remember if this was ever distributed — there certainly wasn’t an App Store in those days!

DiceBook Now Available for iPad

Just a quick note that I’ve finally gotten through the App Store approval process, and the ~4 hour wait to have the app show up in the store…

DiceBook is a specialized PDF reader that includes a flexible dice roller. It’s designed to be used with rolepaying games (like Dungeons & Dragons, HeroQuest, or Spirit of the Century). You can make dice rolls without leaving the app (so it should be useful even when iPad gets fast app switching).

Learn more from the DiceBook web site, or go right to the App Store.

Apple Recycling Redux

I decided to upgrade my iPad to a model with 3G wireless (so I could access maps in the car if need be), so I was once again able to avail myself of the Apple Recycling Program. This time, I shipped off a Radius color pivoting monitor and another Power computer, both probably dating from 1998. Total shipping weight: 92 pounds. Shipping weight of the iPad: 3.3 pounds (about 1/28 as much).

So if you’re on the fence about getting an iPad, think about it as a great way to clean out your closet!

Is the Future the Past?

One thing that struck me about John Siracusa’s interesting article on Apple’s language and API future: Apple did a high-level language once before. NewtonScript.

Whenever I see Python or Lua code, I think back to when I was coding in NewtonScript, which had a similar syntax and similar concepts. Here’s a bit of code from the original implementation of Jigami:


regTile := {_proto: pt_Tile, _parent: self, viewBounds: RelBounds(11, 112, 34, 34)};
regTile.edges := pt_Tile.possibleEdges[tileNum];
regTile:CalcEdges();
regTile.symbols := NIL;

There was also a visual design tool, Newton ToolKit (NTK). The combination of a dynamic language, no pointers, and a graphical editor was quite productive. And NewtonScript was good enough to use for all of the system apps. Yes, there was a little C++ code in parts, but a lot of it was probably premature optimization (there was nothing like Shark or Instruments for Newton).

I don’t know what direction Apple is moving, but at the very least it’s an interesting proof of concept for something that works well in a mobile device.