Captioned Lists

May 22, 2009

I love this structure:

<dl> <dt>Animals</dt> <dd>
</dd> </dl>

– Kevin Marks on [whatwg] List captions

It seems more correct than the alternative he proposes (with each of the li’s here as dd’s) in that the list is an ostensive definition, whereas each of the items is a mere example. Practically, it saves me from having to deal with some lousy CSS on nested lists. And it does feel more semantic-ish than the nested list (for this case) anyway, and certainly better than the usual headings or paragraphs inside lists.


Over the last month or so, I’ve been doing assorted tasks for the Lehigh Valley’s premier business VoIP provider. One of the more tedious VoIP related tasks is getting out-of-the-box VoIP hardware from its factory default state to fully configured. Nearly all hardware accepts some sort of remote provisioning, but you have to somehow let the phone know the path to the provisioning server (as well as related settings.)

In some cases, you can use DHCP option 66 and specify a TFTP server as you might for other netbooting devices. But in a situation where your providing phones to clients for a Hosted PBX (and in most other situations) TFTP is less than ideal, and relying on control of the DHCP server is unrealistic.

There are (usually) two more ways of providing the configuration information: through the phone’s user interface, and through the web control panel. Just grab your (non-fully-keypadded) mobile and dash off a text message with a link to a Google Maps URI and you’ll get a sense of what the first option is like. The second is only slightly less tedious.

Fortunately it’s not so difficult to tease out the http requests the web interfaces for the various phones need. (Firebug, or at least “View Source,” is a tremendous help in this. Tamper Data, or similar tools, can help in making sure things really work the way you think they do.)

With this information we can build up command line scripts with which we can automate the process of giving phones their initial configuration. prov.rb is a Ruby-based application I’ve been working on which configures phones one phone, IP range, or subnet at a time, logs MAC addresses, and more. (I’ll be committing to GitHub as I get time over the next week. I’d love help working out the kinks, and especially for adding more hardware varieties.

In the course of working on prov.rb, I teased out the POST requests for configuring all of these basic settings on both Aastra and Grandstream phones. In addition to writing a client in Ruby, Python, Perl, or whatever, one can also make these requests quite well with cURL or, my preference, wget. So, in the next two posts I’ll provide sample commands for these two brands of phones:
(I’ll add the links once I write the posts.)

Of general interest is that each company (similar to nearly every other maker of VoIP and networking hardware) use largely identical web panels across their product range. This means the same script will work with basic ATAs as with high end phones and gateways. This is especially true if you are just setting a provisioning path for the phones to get their specific configuration.

The main difference between the Aastra and Grandstream panels is that Grandstream uses cookie based authentication, while Aastra uses basic http authentication. Neither of these would do anything to secure the phones in a hostile network environment, so I won’t even speculate on the reasons for the choice of one over another. The basic authentication is a little simpler to manage than cookies with wget, and you’re not stuck with an extra file to clean up.

If your provisioning lab/supply closet/garage is anything like ours, you probably have quite a few OpenWRT boxes laying around. OpenWRT does include wget as part of Busybox, but this is a crippled minimal version of wget, which is missing options for cookies, authentication, and even manual setting of headers. I believe there is an ipkg available for a full version of wget, which could be useful. I’m still looking forward to installing the Ruby ipkg for use with prov.rb.

(Jump to the fix if you want to skip the introduction.)

Google Sites is the evolution of JotSpot. It allows individuals, teams, or organizations to create simple, revision-tracked web sites. Probably its strongest points are ease of setup and ease of embedding other objects, including Google documents, videos, slideshows, calendars, and any of the “gadgets” available to iGoogle home pages. The most obvious downside is frustratingly limited customizability, as is to be expected from a free hosted solution.

Another problem is that saves can be less than perfect. Configuring and adding gadgets can be particularly frustrating, as you may find yourself starting over several times. Read the rest of this entry »

Matthew Bass has written a nice introduction to the [dead simple] Google Charts API and to gchatrb, a Ruby interface to the API developed by Deepak Jois. (The article links to an older Google code repository. The latest version is at the github link provided here.)

Constructing the URLs for Google Charts is pretty simple, and gchartrb and its Python counterpart are almost as verbose, but it’s obviously easier to integrate the wrappers into a program’s flow.

I like Bass’ idea of using a Capistrano task to update the image, rather than rendering it from Google every time. He is a little harsh, though, on “the medieval monster which is ImageMagick.” I like ImageMagick. I’m awful with anything related to design, images, and the visual arts; but I often find myself lost in the (wrongly placed) ImageMagick docs trying out all sorts of esoteric combinations to do some stupid trick or the other. It may be one of the worst tools to have to get work out of, but in the end it does a pretty nifty (and usually not-quite-what-was-expected) job. If ImageMagick is a medieval monster, it’s Herbert the Timid Dragon:

Herbert the Timid Dragon

A few ongoing issues are building up my frustration level today. Note that these are not all strictly about usability, but if I allowed myself to title all posts “Frustration,” this blog would be worse than K-Menu (see #4): Read the rest of this entry »

Jeff Atwood this week offered the world an article on the fact that “PHP sucks [but it doesn’t matter.]” For a man who’s usually quite thoughtful, the critique presented in the article made it look like he’s been stuck on the LOST island with cached Slashdot discussions for a few years and he hit his head really hard and lost the ability to tell whether he’s actually saying anything of value or not. The substance of the apologia on the other hand – that in spite of sucking, PHP powers the web’s biggest and busiest – was put forth much more ably by Terry Chay in his thesis on the science fiction mythology behind the enterprise of the Enterprise.

However, I think Atwood has been redeemed by the fact that his piece provoked the following gem from Stanislav Malyshev: “I wish for every 50 ‘PHP sucks’ blogs people would write one good RFC.”
Read the rest of this entry »

The Google App Engine discussion list has been fairly active with people trying to rework/rehabilitate their relational database habits and knowledge to the strengths and shortcomings of App Engine’s Bigtable-based Datastore. For many, the pondering starts with “um, OK, how about JOINS?” That question keeps coming up, and there have been a few proposed substitutes.

If one even slightly “gets it” though, the next step is to try to figure out the new paradigm at work here. How do we need to be thinking about the design of our queries, our models, and our applications as a whole? There’s a dearth of documentation, successful code examples, and explicated best practices. The discussion list has been slowly filling up that hole. At the heart of much of the advice being gathered there is the need to denormalize data. All data should be accessed via models designed with a view towards the ways in which the data will actually be used. A little extra effort should be applied while storing data to optimize it to be ready for use on read, so as to avoid complicated joins and unnecessary hits to the datastore. And other such points counterintuitive to the relationally-trained mind.

Now Todd Hoff has written the best overview of the issues I’ve seen to date, titled “How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale.” This is definitely recommended reading for anyone starting out with App Engine, required reading if you’re thinking of porting an app (say one based on Django with a MySQL back-end), and remedial reading if you built (or started to build) an app where you tried to emulate what works in relational databases, and found something off.