This is the sort of attitude that makes me want to bitch-slap some sense into the lot of you.

more...

…four points define a wobble. Some months back, I left myself a note to buy the Manfrotto Modo Pocket camera stand when it finally reached the US. I had taken their tabletop tripod with me to Japan, but hadn’t used it much because of the overhead: pull it out of the bag, find a dinner-plate-sized surface to set it up on, take the shot.

I didn’t bother buying any of the other “quickie” mini-tripods that are out there, because most of them struck me as gimmicks first, stabilizers second. The Modo Pocket, though, looked eminently practical:

Small enough to be left on the camera while it’s in your pocket, with a passthrough socket to mount on a larger tripod or monopod. Usable open or closed. Solidly constructed, like most Manfrotto products. A design that derives its cool looks directly from its functionality. It’s even a nice little fidget toy.

What it isn’t is a tripod. If you put a three-legged camera stand down on a surface, it might end up at an odd angle, or even fall over if there’s too much height variation between the legs, but it’s not going to wobble. A four-legged stand is going to wobble on any surface that’s not perfectly flat, and is also going to be subject to variations in manufacture.

The legs on my shiny new Modo Pocket are about two sheets of paper off from being perfectly aligned, which means that it can wobble a bit during long exposures. Adjusting it to perfection is trivial, but even once it’s perfectly aligned on perfectly flat surfaces, it won’t be that way out in the real world.

It can’t be, because it has four fixed-length legs. This is a limitation, not a flaw. Just like it’s not designed to work with an SLR and a superzoom (it would fall over in a heartbeat), it’s not designed to replace a tripod. It’s designed to help the camera in your pocket grab a sharp picture quickly, before you lose the chance. I expect to get some very nice, sharp pictures with this gadget, and I don’t regret the $30 in the least.

I’m doing some load-testing for our service, focusing first on the all-important Christmas Morning test: what happens when 50,000 people unwrap their presents, find your product, and try to hook it up. This was a fun one at WebTV, where every year we rented CPUs and memory for our Oracle server, and did a complicated load-balancing dance to support new subscribers while still giving decent response to current ones. [Note: it is remarkably useful to be able to throw your service into database-read-only mode and point groups of hosts at different databases.]

My first problem was deciphering the interface. I’ve never worked with WSDL before, and it turns out that the Perl SOAP::WSDL package has a few quirks related to namespaces in XSD schemas. Specifically, all of the namespaces in the XSD must be declared in the definition section of the WSDL to avoid “unbound prefix” errors, and then you have to write a custom serializer to reinsert the namespaces after wsdl2perl.pl gleefully strips them all out for you.

Once I could register one phony subscriber on the test service, it was time to create thousands of plausible names, addresses, and (most importantly) phone numbers scattered around the US. Census data gave me a thousand popular first and last names, as well as a comprehensive collection of city/state/zip values. Our CCMI database gave me a full set of valid area codes and prefixes for those zips. The only thing I couldn’t find a decent source for was street names; I’m just using a thousand random last names for now.

I’m seeding the random number generator with the product serial number, so that 16728628 will always be Elisa Wallace on W. Westrick Shore in Crenshaw, MS 38621, with a number in the 662 area code.

Over the next few days, I’m going to find out how many new subscribers I can add at a time without killing the servers, as well as how many total they can support without exploding. It should be fun.

Meanwhile, I can report that Preview.app in Mac OS X 10.5.4 cheerfully handles converting a 92,600-page PostScript file into PDF. It took about fifteen minutes, plus a few more to write it back out to disk. I know this because I just generated half a million phony subscribers, and I wanted to download the list to my Sony Reader so I could scan through the output. I know that all have unique phone numbers, but I wanted to see how plausible they look. So far, not bad.

The (updated! yeah!) Sony Reader also handles the 92,600-page PDF file very nicely.

[Update: I should note that the “hook it up” part I’m referring to here is the web-based activation process. The actual “50,000 boxes connect to our servers and start making phone calls” part is something we can predict quite nicely based on the data from the thousands of boxes already in the field.]

[Update: sample picture of a PDF with kanji and furigana below the fold]

Quite a while ago, Sony promised to update their e-ink reader (the 505 model, at least; owners of the original 500 are SOL) to support Adobe Digital Editions (emerging DRM ebook standard), as well as fix a lot of bugs and in general support the product. People have been wondering if it would ever happen, or if it would be a new model. The recent UK release of the 505 was a head-scratcher as well, since it came without any announcement about the overdue update.

It took a while, but it’s here (more precisely, it’s linked from here; there’s no direct download link). Lots of other improvements, including SDHC compatibility and… (wait for it)… kanji in PDF files! You still need to use one of the hacks to see Chinese and Japanese text in text files and menus, but now that there’s a real firmware installer for the 505, you can recover from bad hacks.

Looks good so far.

[Update: the PDF reflow works pretty well for straightforward text-heavy PDFs with sensible internal layout. That is, the order the text was generated in the PDF file is the order it will appear; it doesn’t understand “columns” as such. Unfortunately, the Microsoft Word equation editor violates this constraint, and furigana in Word is implemented as an equation. Net result: Japanese PDFs may turn into crap when you ask the reader to reflow them, so you should format them for its page size.

This also means that graphics-heavy PDF files can’t be resized at all. Maps and complex diagrams must be converted to JPG to be useful, because the PDF viewer still doesn’t scroll, and the resize button is always a reflow button now.

Generally, the UI is much faster (except the date-entry screen, which is glacial), and page-turning is slightly faster. The only EPUB-format document I’ve tried turned out to be very graphics-heavy, which basically locked up the device during rendering. I haven’t tried an SDHC card, but people are reporting very mixed results. I’m loving the kanji support in PDFs, and look forward to trying an updated version of the Unicode font hack to get kanji working in text files as well.]

more...

We’ve been taking it slow, but we’ve finally got a retail trial running. If you’re in the Los Angeles area, you can finally see our product before buying one, at Best Buy.

"Now throw the switch and let us begin the battle for the planet."
--- The Brain

Aozora Bunko is, more or less, the Japanese version of Project Gutenberg. As I’ve mentioned before, they have a simple markup convention to handle phonetic guides and textual notes. The notes can get a bit complicated, referring to obsolete kanji and special formatting, but the phonetic part is simple to parse.

I can easily convert it to my pop-up furigana for online use (which I think is more useful than the real thing at screen resolution), but for my reading class, it would be nice to make real furigana to print out. A while back I started tinkering with using Word’s RTF import for this, but gave up because it was a pain in the ass. Among other problems, the RTF parser is very fragile, and syntax errors can send it off into oblivion.

Tonight, while I was working on something else, I remembered that Word has an allegedly reasonable HTML parser, and IE was the first browser to support the HTML tags for furigana. So I stripped the RTF code out of my script, generated simple HTML, and sent it to Word. Success! Also a spinning beach-ball for a really long time, but only for the first document; once Word loaded whatever cruft it needed, that session would convert subsequent HTML documents quickly. It even obeys simple CSS, so I could set the main font size and line spacing, as well as the furigana size.

Two short Perl scripts: shiftjis2utf8 and aozora-ruby.

[Note that Aozora Bunko actually supplies XHTML versions of their texts with properly-tagged furigana, but they also do some other things to the text that I don’t want to try to import into Word, like replacing references to obsolete kanji with PNG files.]

I like Google Earth. I even pay for the faster performance and enhanced features. A few things, though:

• Why can't I keep North at the top of the screen? I hate constantly double-clicking the "N" in the gaudy navigation scroll-wheel.
• Why do you auto-enable new layers in my view, so that, for instance, I suddenly see every golf course on the planet, even though I had that entire category disabled?
• Why can't I switch between different sets of enabled layers?
• Why is the "Google Earth Community" layer such a dumping ground of unsorted crap? For instance, what value does this have to anyone who's not an airline pilot? Or this, where points scattered around the globe are all labeled, "here's my collection of 4,728 placemarks".

I’m sure I can come up with more if I think about it for a bit…

[update: ah, press ‘n’ for north, ‘r’ for a total view reset, and then figure out how to fix all of the KMZ files that were broken by the upgrade]