Sometimes it's the little things that really make me smile. This time, it's a pleasant little UI surprise in Apple's Safari web browser.

OK, say you've googled through to some page at http://some.host/some/deeply/nested/url. And the page is sort-of what you want, but you want a more general, broader context. What do you do?

• If you don't use Safari, you click in the address box and start deleting off parts of the URL, getting rid of /url, then /nested/url, then /deeply/nested/url, until you find what makes sense.
• If you do use Safari, you just right-click (or control+click for you silly one-button mouse users) the title bar and select whatever shortened URL you want.

Thanks, Apple. Thapple.

OK, I've had to get two logic boards replaced recently and have gone through this twice, re-constructing the steps each time. Now I'm writing them down for future reference. See, Time Machine saves the Ethernet MAC address on your computer's logic board as part of the way of identifying your system. But suppose your logic board gets replaced? Now Time Machine thinks you've got a brand new computer, even though all that backed up data is really the same.

To re-associate your old Time Machine backups with your computer's new logic board:

For this example, machine ginger is the machine with the new logic board, and machine tarragon is the backup host. ginger's old address was 00:11:22:33:44:55, and its new address is aa:bb:cc:dd:ee:ff. On tarragon, the backup volume is called gin.

Don't know the old MAC address? No worries, just follow along below. Don't know your new MAC address? Open System Preferences, Network, Ethernet (or Airport if you're using that), Advanced, Ethernet; it'll be listed next to "Ethernet ID".

1. On ginger, open Time Machine Preferences and turn it off.
2. On tarragon, open a terminal and enter:

   % cd /Volumes/gin
   % ls -aF
   .001122334455
   .0013ffac9302
   .01facc0e962b
   .DS_Store
   .Spotlight-V100/
   .TemporaryItems/
   .Trashes/
   .com.apple.timemachine.supported
   .fseventsd/
   Backups.backupdb/
   Desktop DB
   Desktop DF
   cilantro_0013ffac9302.sparsebundle/
   ginger_001122334455.sparsebundle/
   thyme_01facc0e962b.sparsebundle/

   Notice the .001122334455 file and the ginger_001122334455.sparsebundle bundle? We got to fix those. The old MAC address is in the filenames, just run together without colons.

3. In the terminal on tarragon, type:

   % open ginger_001122334455.sparsebundle

   After a check, the backup volume will be mounted as /Volumes/Backup of ginger.

4. Confirm the old MAC address by entering these commands:

   % xattr -p com.apple.backupd.BackupMachineAddress /Volumes/Backup\ of\ ginger/Backups.backupdb/ginger
   00:11:22:33:44:55

   That tells us we have three things we need to fix: the MAC address in the .001122334455 file, the MAC address in the ginger bundle name, and finally the MAC address in the extended attribute of the "ginger" directory in the Backups.backupdb directory.

5. Fix the dot file. In the terminal, type:

   % sudo mv .001122334455 .aabbccddeeff

6. Fix the extended attribute. In the terminal, type:

   % sudo fsaclctl -p /Volumes/Backup\ of\ ginger -d
   % sudo xattr -w com.apple.backupd.BackupMachineAddress aa:bb:cc:dd:ee:ff /Volumes/Backup\ of\ ginger/Backups.backupdb/ginger
   % sudo fsaclctl -p /Volumes/Backup\ of\ ginger -e

   The first command disables file system access control list checking, the second writes the new MAC address, and the third re-enables access control list checking.

7. Unmount the "Backup of ginger" backup volume by dragging it to the trash.
8. Rename the bundle:

   % mv ginger_001122334455.sparsebundle ginger_aabbccddeeff.sparsebundle

9. Finally, turn Time Machine back on back on ginger.

That's it! The next time ginger backs up, it'll see it's just another incremental. The oldest backup available will still be the oldest one available and not today's date.

The sleepy little bedroom community of Allen, Texas is home to a few surprising gems.

For example, the Zagat-surveyed Samui thai/fusion cuisine restaurant boasts a swanky décor and an upscale menu, nestled in a grocery store's strip mall. The best croissants in the Dallas-Fort Worth metroplex are made by french-born Jean-Christophe Blanc, who opened Voilà in this small town. And it's in the humble little Chili's franchise that you find Chris Adair, nimble drummer for Industry 6.

Industry 6? Yep. Traversing the roads between Allen and Garland and Mesquite and Ferris, six individuals have come together to form a progressive, metallic-tinged, and decidedly alternative rock sound that's unlike anything I've heard before.

Another gem.

It's against this wasteland of Texas suburbia that Industry 6 strums out edgy rocking sounds. Performing in local hotspots, battles of the band, and even for charity events, crowds sway and scream to the band's massive rhythm sections, hugely intense guitars, and morose vocals that, together, weave a musical tapestry brimming with emotion. I got my hands on their hard-to-get self-titled EP Industry 6—and I'm not letting go.

In the track "Hard to Swallow", keyboardist Tiffany Adair lifts listeners off their feet with ethereal sounds while rhythm guitarist Randy Forester and bassist Steven Brandon set the stage with a speedy beat. Solo sections show just how nimble their fingers are on those strings. Chris Adair's precise drumming leads off on "Benevolence" while Michael Angel's vocals lay out emotion in its pure, unrefined form. And then there's a nearly primal scream that reminds the listener just how intense he can be. No less than two separate mood changes in this track make it shine brilliantly—it's a voyage from woe to introspection to elation. "Anything" lets lead guitarist James Smylie shine. He strums like a demon on acid, as if channeling guitarists of the past into a rocking convocation. "Insignificant Others" rounds out the EP with more of Smylie's magic along with a head-banging structure framing the piece with genuine power.

If I had to find a flaw with Industry 6's EP, it'd be the mixing: it's a bit off, as Angel's vocals tend to become lost in the sea of fierce instrumentation. But that's all right: these guys are just at the start of their game.

I think they'll be playing it for quite some time to come.

Thanks to all of the reports of a broken link to NASA headquarters, the Better Web App Development movie is back. A manager at Jet Propulsion Laboratory asked if I could edit out the copyright notice at the front and put the video back to its original location.

"With pleasure," I answered.

Now all I need is some time to update it for 2008!

I won't hide the fact that I'm an Apple fanboy. Mac OS X is the most refreshing desktop operating system I've ever used. I'll never touch Windows or Linux again. And of course, I have an iPhone, a couple iPods, and Apple TV, a .Mac membership, and so forth, and I use iWork, iLife, and so on. Naturally, watching Steve Jobs's famous keynote addresses are a treat.

But I always thought showing off his latest television advertisements during them was ... well, pushing things. The commercials are always compelling and interesting, but isn't the whole keynote a kind of advertisement?

However, Jobs surprised me with his latest keynote at WWDC 2008, by showing the newest iPhone ad not just once, but twice in a row.

He said, "Want to see that again? Let's roll that again; I love this ad." And off it went.

Wow.

I've been asked to pull the "Better Web App Development" movie from its location which was previously at http://oodt.jpl.nasa.gov/better-web-app.mov. I did so by renaming the file to better-web-app-nolink.mov yet otherwise leaving it intact, just in case NASA changes its mind.

Why the retraction? A middle-manager at the Jet Propulsion Laboratory expressed concern that the video never passed the "document review process". He's being proactive by asking it to be unlinked from its old location rather than reactive when document review discovers the video and gets us all in trouble.

(As usual, these opinions are mine and do not reflect the policy of the California Institute of Technology, the Jet Propulsion Laboratory, NASA, or Northrop Grumman.)

The exciting new release of the glistening operating system from Apple, Mac OS X Leopard, arrived at my home this morning. And just in time, too, as the hard drive in my desktop system (a Power Mac G5 from a few years ago) just died.

In addition to Apple's usual slick style and attention-to-detail-that-borders-on-psychosis, I had to laugh out loud as I browsed my local network using Finder. I saw my familiar servers rosemary, ginger, and sage. But the icon that appeared for a epazote, a Windows XP file server, looked ... familiar. I clicked "Get Info" after selecting it and saw the unmistakable image in a larger size:

Ah, I'd recognize that horrific white text on blue background a mile away. I'd like to express my gratitude to the developers of Leopard for making me chortle. Thanks, Apple. Thapple.

During installation, I was getting:

Calling tpc_finish() on a disconnected transaction

And a failed install. To fix, edit the zeo.conf and increase the transaction-timeout from 15 to 15000:

<zeo>
  address 127.0.0.1:9893
  read-only false
  invalidation-queue-size 100
  monitor-address 9894
  transaction-timeout 15000
</zeo>

Restart Zeo and Zope and install the product. Don't forget to bump it back down to 15 when done.

I recently got in my mailbox a question from a non-programmer wanting to know how to estimate how much time and effort it would take for him to solely develop a new idea for a web application.

Oh goodness, what a loaded question!

In general, individual developers and even teams of developers all work differently. What one person can finish in a week another may take a month. What one team and complete in a month, another takes a year.

To that end, looking at historical data is really the best way of estimating how much time and effort will be required towards completing a project, including its projected costs, defect rate, and schedule.

I myself follow the Personal Software Process (PSP), a system developed at Carnegie-Mellon, to gather such data and track it over time. As a result I can usually estimate the time/cost/defects of my future projects with good accuracy; after all, we are creatures of habit, and it takes quite a bit of change to effect change in the quality of our products. (As an aside, my productivity from C++ to Java tripled; from Java to Python tripled again!) Yet if you lack such data, then making these guesses will be quite challenging.

Still, there's no time like today to start gathering metrics. Try building some smaller software systems, then look at the time it took you, and the size of the programs in lines of code (lines of code, or LOC, is a terrible metric for program complexity, but no one's yet come up with a better one, and as Gibbs once said, "Everything can be measured in some way that is better than not measuring it at all."). For your ultimate project, look at aspects of smaller projects that are similar to what you want to accomplish. Use the productivity rates from those tasks to estimate the time it will take, and the defect rate from those tasks to estimate how many bugs you'll face.

(Oh, I happen to offer training courses in PSP.)

I've been writing monthly articles on developing web applications with Plone for Developer.com. Part 3 covering ArchGenXML is now online.

Sadly, this will be the last article. The editors of Developer.com have decided to cut the series short, since Plone doesn't generate quite as many page hits (a.k.a. revenue) as their other topics.

That doesn't mean I'll stop writing, of course. Look for more screencasts, articles, and other docs here and at plone.org.

I've committed (or should be committed) to writing a series of articles covering Plone, one each month. Part 2 is now online for your viewing pleasure and/or derision. You can also check out part 1 if you're really bored.

Slashdot recently carried a posting containing Microsoft's response to the US Department of Transportation's decision to not upgrade to Vista, including this gem of corporate double-speak:

We respect the customer's decision. As with any of our other Federal customers, it's our job to help DOT maximize the value of its Enterprise Agreement through the adoption of our technology. We are engaged with large, strategic customers across government at every level, and are working closely with them on these products through their participation in our Technical Adoption Programs.

And Slashdot's reader-submitted and reader-moderated comments flew in fast and furiously, including these gems:

• "Alternate versions: —We're going to make them an offer they can't refuse; —Once you join the family, you can never leave."
• "We are Microsoft. Lower your Firewalls and surrender your systems. We will add your cultural and technological distinctiveness to our own. Your IT departments will adapt to service us. Resistance is futile."

And my personal, laugh-out-loud favorite:

• "I have maximized the value of our Enterprise Agreement. Pray I do not maximize it further."

In between my work for NASA and the National Cancer Institute, writing articles for Developer.com, and helping out the websites of various local interests, I've also been doing some work for a major online magazine for home theater. I've never been involved with high-volume sites before, and so it's been a hugely educational experience.

See, the good folks at Audioholics.com thought my videos were pretty interesting and contacted me to assist in transitioning their site from their old content management system to Plone. Given how easy it is to develop compelling new web applications with Plone and its underlying web application server, Zope, not to mention the highly agile Python programming language, I thought it'd be a piece of cake.

And it was, until they tried to go live with the new system.

It seems in the Ploniverse that the Squid proxy and HTTP accelerator is generally considered some of the "best practice" when it comes to high volume web sites. Your CMS may spend a lot of time compositing a page, but once it's all assembled it doesn't change all that much. Sure, the little "portlets" on the sides may be updated, but the meat of the page is still the same, and so caching the assembled page for a hungry web audience to consume via direct-from-cache-to-browser is a good idea.

And if not Squid, then there's always Apache's mod_proxy, or even a combination of Squid and Apache. At least if you believe the community knowledge.

And you have the patience to get all that working.

Which I thought I did.

That was until the site tried to go live, several times, with the Squid setup—only to find that its confounding configuration and impenetrable log files showed that it was doing almost no good. Even after we got a Plone expert to help out, Squid just refused to play nicely. It also refused to do round-robin upstream requests to multiple Zope servers after the site decided to make some major hardware investments.

Now, I'm generally a patient person, and many of my colleagues know just how much I'll put into banging my head against a configuration file to get something working. With Squid, though, I feel as though I was literally wrestling with a giant leviathan from the deep, a massive monster of a squid risen up from oceanic depths to do battle with me, balancing futilely from a tiny little dinghy rocked upon angry waves.

I fought the squid. And it won.

My bruised and battered body, covered in welts from the beast's suction cups, washed up on some lost shore. Barely able to breathe and move I crawled away from the livid sea—to discover that same expert recommending that I now try Varnish.

Varnish? Never heard of it—which isn't saying much for the names of open source software packages, which have given up on even providing the tiniest hints of what their function might be. Consider: Siege (a regression test system), Spring (web application framework), Scarab (issue tracker), Cantus (media file tagger), Elektra Initiative (key/value pair framework), Cactus (test framework), Azureus (P2P client), Fink (Mac package framework) and so forth.

But anything's got to be better than Squid. And that's exactly what Varnish is. And not just by default—it's lightyears ahead of Squid.

Now, Squid certainly tries to be a lot more than an HTTP accelerator, which is all I wanted for this client, so I should forgive it that. Except that in trying to do so many things—outgoing web proxy, FTP proxy, transparent proxy, load balancer, and reverse proxy—it made it really hard to do just the one task that I needed it to do.

Squid also comes with a default configuration file that weighs in at over 4000 lines. Granted, there's a lot of documentation in that file, but it's essentially an embedded man page; strip out all the comments and it's still over 250 lines of configuration. Worse, the past stable version 2.4, and the current development version, 3.0, both have good online documentation. But the current stable release, 2.6, doesn't! Are you supposed to surf the bleeding edge or be mired in the past with Squid? Both, apparently.

Lastly, Squid, despite my own lame attempts at configuration and an expert's corrections, is just slow. Let's look at why.

Squid, when acting as reverse-proxy HTTP accelerator, takes an incoming request for a page and sees if it already has it in its memory cache or disk cache. If it's in neither location, it'll ask its upstream content management system to compose the page, at which point it'll cache it in memory in the optimistic hope that someone else will request it again soon. Memory's fast, after all.

If, after awhile, there are no other requests for it, it'll write it off to disk for the less optimistic case that some request will come in later. Disk's slower than memory, after all.

Sadly, this strategy effectively defeats the whole point of demand-paged virtual memory provided by modern operating systems. It's an operating system's job to abstract out memory so that an application doesn't have to worry about it. Squid, in actively worrying about it, ruins the operating system's ability to give the application any edge. Take the case where Squid has an object cached in memory—and the operating system sees that the memory page hasn't been referenced in awhile before Squid notices. The operating system transparently and without Squid's knowledge pages it out to disk. Then Squid's timers go off and it decides to write that same object out to disk. It forces the operating system to page it back into memory only so that Squid itself can write it back out to disk!

Modern Unix operating systems have the mmap system call which makes such shenanigans totally unnecessary. Disk, memory, it's all the same these days! Varnish instead just maps into memory a huge disk file and treats it as cache. It's the OS's job to manage that and it does just fine, whether you're on Linux, FreeBSD, or otherwise. Squid's disk cache consists of hundreds of files in dozens of subdirectories, forcing the disk subsystem to do dozens of cartwheels to track inodes, disk pages, and other metadata. Varnish's cache is just a big chunk of a file which you can preallocate with dd, minimizing fragmentation, maximizing speed.

Look at what else Squid does that's slow and back-asswards: Squid takes the configuration file and uses it to set all sorts of conditions in memory whose codeways must be traversed in order to figure out what to do. Varnish takes its configuration and compiles it at launch time into executable machine code!

Squid logs to files, causing disk I/O virtually all the time. Varnish writes to a round-robin shared memory area. I've seen this technique once before, when I worked for a company that made commercial-grade digital video servers. We had two of the core team from FreeBSD working there, and they used the same technique: logging was absolutely vital in debugging that system, and yet it was lighter than the breath of a fairy.

I guess it's no wonder that the principal architect of Varnish is yet another FreeBSD core team member: Poul-Henning Kamp. This is definitely slick software.

Use Varnish.

/sbin/fsck SQUID!

This most recent xmas, Santa brought me a whole bunch of neat little toys with odd names: carboy, refractometer, thief, racking tube, airlock, and even a bung.  Yes, a bung.  Using these toys, a bunch of grape juice, and some yeast I'm apparently going to make wine.

I have no clue what I'm doing. (Any pointers?  Anyone?)

Winemaking of course has a rich and lurid history which I won't go into here, except to say that human beings do love alcohol, and we've been finding ways to make it for some 7000 odd years.  Beer and wine homebrewing is pursued by thousands of devoted practitioners who have their own subculture documented in books and talked over at conferences.

Yesterday I joined that subculture by starting my first batch of homebrew wine: sauvignon blanc.  Why this unassuming white wine? Well if I screw it up it's no big deal.  Sure, I'd love to make a killer syrah (shiraz) and zinfandel blend with a light oaky character, good tannins, and plenty of up-front pepper, but you got to crawl before you can walk.

I started with Vintner's Reserve juice/concentrate, bentonite, and enough water to total 22 liters. Initially, the sugar of this solution was 19 Brix exactly. I added a bunch of Saccharomyces bayanus, and those little guys went to town on that juice.

This morning, the container certainly smells like bread, but looks like nothing that's ever been in my kitchen before.

The best part about making wine, though, is that you need a bunch of empty wine bottles. And where do empty wine bottles come from? From full wine bottles! Yes, you've got to drink 30 bottles of wine to just make wine.

It's a win-win situation!

If you've installed just about any Unix-based software recently, chances are this will be familiar to you:

% ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
...

That's made by the very handy GNU Autoconf, a program that takes your own program's morphology and makes a configure script and other goodies, making it easy for thousands of Unix users out in the wild to use your fabulous software.

However, since I'm a total nutjob, I really wish the interaction with configure went more like this:

% ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is insane... no
checking whether make sets $(MAKE)... yes
...

It's not traditional to exchange gifts on the Thanksgiving holiday in America, but I've never been a traditionalist. And so I'm not launching any complaints against Apple Computer, Incorporated, for shipping my new Macbook Pro today. Thanks, guys!

I grew up in the United States and recall without mirth the American Thanksgiving feasts my mother made. I just don't like American comfort food: for comfort, give me a bowl of shiitake risotto with ginger-coconut prawns, or just a lychee martini.

I became a foodie as a result and found that my gourmet cooking and dinner parties led me into the spotlight for the quintessential American culinary holiday: Thanksgiving. For several years now I've hosted and cooked Thanksgiving, each time desperately trying to infuse some life, some vigor, some spice into what are typically bland dishes.

And this time, I'm letting my home in Texas be the inspiration: nearly half the dishes have chiles in them! And nearly all of them feature tex-mex ingredients. Check out the menu (with linked recipes) to see for yourself.

Besides, if I get all my guests smashed on the margaritas, nothing can go wrong!

My three year old iBook G4 12″ died just a couple days ago. It's been across the country with me many times, and although the screen was too small and the processor was too slow and the memory wasn't enough and the graphics card couldn't do all of the fancy effects that people come to identify with Mac OS X, it was still quite a pleasant travel Unix box.

Best of all, it means I can finally upgrade to an Intel Core Duo 2 MacBook Pro. WOOT!

After diagnosing that it was the hard drive that died, I thought I'd go ahead and fix it. After all, it's not too early for my six year old to have a notebook computer, right?

The good folks at iFixit published a very handy guide on taking apart and replacing the hard drive for a do-it-yourselfer. I diligently followed their instructions up to page 9 when I discovered the unthinkable: two loose screws!

They weren't exactly loose, as the non-conductive material underneath the metal shield was holding them in place. Indeed, I can even see some slight indentations in the material where one of the screws was (the one on top of a chip). However, the other screw was making electrical contact with components underneath it. And it must've been doing so for three years!

Is this what killed my hard drive? Probably not, but still, as far a quality control goes for a company like Apple, it's quite surprising.

I've been using Plone since January of this year (yeah, you can call me a newbie; please don't tell my clients!), and one thing that's always been nice about it is the built-in Section 508 and W3C-AA features. You may recall that Target was sued for providing a website that wasn't accessible by people with disabilities. When I deploy a Plone-based site, I usually don't worry about such issues.

However, I've got one client now that keeps insisting on features that have been bothering me. For example, the people involved in this company would like to see icons used in hyperlinks, Flash used for navigation, and tiny dots where the user would be forced to mouse-over them to discover what destinations clicking on them may lead, all in the name of "providing an environment that encourages exploration" (when all it does is force exploration and most users' reflexes would be to hit the BACK button, pronto!).

I've always felt these were bad ideas, but rather than complain from a gut reaction, I took the time to finally read all of W3C-AA. Holy crap! What an eye-opening experience! There's a lot more in there than providing text alternates where graphics would do. There's stuff about color, table transformation, graceful degradation, device-independence, and more. You've got to be prepared for people out there using screen readers, braille renderers, cell phones, and worse!

Now, without naming names, let me say that this particular client has ties to space exploration and scientific discovery relating to the universe as a whole. And, as a result, I've found a most clever way to deflect even their most impassioned pleas for glitzy and entirely unusable user interfaces: "What if Stephen Hawking visited this page?"

Works every time!

(As for being sober: relax my friends, I'll be mixing cocktails again in about an hour or so!)