Software Tools

Suitability of makefile production rules as an aspect-oriented language.

Usefulness of extending makefiles towards aspect orientation.

Enhancing makefile production rules toward aspect orientation with a preprocessor (eg, m4).

How each aspect of aspect-orientation applies (or doesn't) to makefile production rules.

Adding code-generation (eg, pduconvert) support to a build system (eg, WUCE), with abstracted code samples.

Makefile production rules. As an implementation of the Backus-Naur form.

Aspect orientation.

Thesis.

Executive summary.

Market research of WiMAX by self-selected Slashdot posters.

Tariq Qureshi, general manager at Pakistan's Wateen Telecom, concluded his presentation, at WiMax World Europe event in Vienna, with a message for the vendor: "Please don't let me down."

Dave Agans enumerates nine rules in his short book, Debugging. As a reminder, the rest of this post lists headers from the rule chapters, formatted in one page for my cube wall.

Understand the system. Read the manual. Read everything, cover to cover. Know what's reasonable. Know the road map. Know your tools. Look it up.

Make it fail. Do it again. Start at the beginning. Stimulate the failure. Don't simulate the failure. What if it's intermittent?. What if I've tried everything and it's still intermittent?: a hard look at bad luck; lies, damn lies, and statistics; did you fix it, or did you get lucky?. "But that can't happen". Never throw away a debugging tool.

Quit thinking and look. See the failure. See the details. Now you see it, now you don't. Instrument the system: design instrumentation in; build instrumentation in later; don't be afraid to dive in; add instrumentation on; instrumentation in daily life. The Heisenberg Uncertainty Principle. Guess only to focus the search.

Divide and conquer. Narrow the search: in the ballpark; which side are you on?. Inject easy-to-spot patterns. Start with the bad. Fix the bugs you know about. Fix the noise first.

Change one thing at a time. Use a rifle, not a shotgun. Grab the brass bar with both hands [stop and look, examine and think, then act]. Change one test at a time. Compare with a good one. What did you change since the last time it worked?.

Keep an audit trail. Write down what you did, in what order, and what happened [easier if you're recording your steps anyway in idiom files]. The devil is in the details. Correlate. Audit trails for design are also good for testing. The shortest pencil is longer than the longest memory [and automation is faster].

Check the plug. Question your assumptions. Don't start at square three. Test the tool.

Get a fresh view. Ask for help: a breath of fresh insight; ask an expert; the voice of experience. Where to get help. Don't be proud. Report symptoms, not theories: you don't have to be sure.

If you didn't fix it, it ain't fixed. Check that it's really fixed. Check that it's really your fix that fixed it. It never just goes away by itself. Fix the cause. Fix the process.

First Impressions

I've now twice looked through the Google Notebook screenshots. It seems, in general, to provide less ability for me to organize links than del.icio.us.

Google Notebook groups notes (content excerpt or comment, title, and link) into optional sections, thence into notebooks, thence into a collection of notebooks.

del.icio.us associates tags with links (title, comment or copied excerpt, and link) instead of grouping them. This allows more flexible link sets than groupings, and more of them.

Google Notebook's shallow hierarchy does not let you know if you have the same link in multiple notebooks, or in multiple sections within a notebook. Even if your notebook is shared, Google Notebooks (as far as I've seen) does not let you know what other public notebooks contain your link, so you can't see what related content other users found. It would not surprise me to learn that notebook agglomeration is planned, though.

Google Notebook's groupings do allow more efficient control over sharing links. del.icio.us links must be shared or unshared one at a time. I'm not sure why you would want to, but Google Notebooks allows you to share a link in one notebook, but leave it unshared in another.

Controlled sharing would be useful for cases where you want to share the results of your research with a only few other people (eg, confidential research on personal medical conditions). Google Calendar has a good interface for this: the owner publishes a calendar to another user by Google account name; then Google Calendar incorporates these entries into the other user's events.

Google Tools I Use

I use Google Search (including Google Trends), GMail, and Google Calendar, because no other services I've found work as well as they do.

I used Google Reader, but switched to Rojo (better tags, and better feed interaction); Google's personal home page, but switched to Pageflakes (multiple pages, and multiple items of the same type on a page); used Blogger, but switched to WordPress (better templates and widgets; more control over posts, pages, and categories). In each case, Google provided an adequate startup tool, but I found its replacement worked more the way I wanted.

Kanso Carries the Day

In practice, del.icio.us wins over Google Notebook, JetEye, and Clipmarks, since its browser extension is simpler. I can use its interface (two bookmarklets) with the alpha releases of Bon Echo. The applications for the other two services check the version of the browser that's running, and don't recognize Bon Echo, so they won't run. I'm sure they'll all recognize the new Firefox when it's official, but I would rather use a tool that does not inhibit early adoption of other tools.