Untangling gdata

Update (2 Feb 2012): We got docs uploads working in GoogleCL with python gdata versions 2.0.15 and 2.0.16 after noticing a random page in Japanese (thanks Google Translate!) that mentioned changing all references of gdata.docs.data.DocsEntry to gdata.data.GDEntry. Also, the gdata.docs.data.MIMETYPES variable that was provided "for your convenience" went missing in 2.0.15 and 2.0.16.  I've updated the table accordingly.

A brief history of python-gdata to upload files to Google Docs.  (Much of this is also relevant to the other language interfaces to Google's gdata API.)  Coila from the "Let's Get Technical" blog (where she has more details and links) and I worked all this out this evening trying to sort through some of the nastier open GoogleCL bugs.

Versions of python-gdata (as it's known in debian/ubuntu, or gdata-python-client on the code.google.com site):

2.0.0 .. 2.0.4: Uses old OAuth mechanism.  Supports uploading limited file types to docs.

2.0.5: client.py interface added.  Uses a new OAuth mechanism.

2.0.8: "Resumable upload" mechanism added.

2 May 2011:

Google starts allowing uploading arbitrary files to Google Docs.  I believe this worked on versions 2.0.5 through 2.0.14 (2.0.15 wasn't released yet).

30 September 2011: 

Google servers start returning "403.4 SSL Required" errors for versions 2.0.5 through 2.0.9, and also 2.0.11 for some reason.  2.0.10, 2.0.12, 2.0.13 and 2.0.14 seem to be fine.

Also, "403 Files must be uploaded using the resumable upload mechanism" errors start appearing.  But only, apparently for versions 2.0.5 and later -- 2.0.0 through 2.0.5 still are able to upload limited file types.

One last wrinkle: GoogleCL is currently broken with version 2.0.15, failing due to gdata.docs.MIMETYPES having gone missing.  So I don't yet know anything more about it.

Got all that?  Here's a handy chart to help you keep it straight:

python-gdata version	OAuth	Can upload text files to docs as of 11/2011	Can upload arbitrary files to docs as of 11/2011	Arbitrary file upload without Resumable (5/2011 - 10/2011) ??	Supports Resumable Uploads	403: SSL error	403: Resumable upload required	Has gdata.docs.MIMETYPES	DocsEntry/GDEntry
2.0.0	old	X
2.0.1	old	X
2.0.2	old	X
2.0.3	old	X
2.0.4	old	X
2.0.5	new			X		X	X	X	DocsEntry
2.0.6	new			X		X	X	X	DocsEntry
2.0.7	new			X		X	X	X	DocsEntry
2.0.8	new			X	X	X	X	X	DocsEntry
2.0.9	new			X	X	X	X	X	DocsEntry
2.0.10	new	X	X	X	X		X	X	DocsEntry
2.0.11	new			X	X	X	X	X	DocsEntry
2.0.12	new	X	X	X	X		X	X	DocsEntry
2.0.13	new	X	X	X	X		X	X	DocsEntry
2.0.14	new	X	X	X	X		X	X	DocsEntry
2.0.15	new	X	X	?	X		X		GDEntry
2.0.16	new	X	X	?	X		X		GDEntry

Flat bottom table saw cuts

If you've spent much time watching New Yankee Workshop, you've seen Norm cut a wide dado (slot) in a piece of wood by making multiple passes with the table saw, moving the wood a little to the side after each pass.

But when I tried it, I found that my saw left a V-shaped profile at the bottom of the cut, like the one on the left here:

That's because my blade, like most table saw blades, has an Alternating Top Bevel (ATB) grind.  You can see a good picture at the bottom of Rockler's blade selection page.  If you look carefully at a blade edge-on in the store, you can generally see the alternating profile, like you see on that page.

What I needed was a blade with a flat top grind.  Apparently there are blades where all the teeth have a flat (or "raker") grind, but I've only ever seen them on Dado sets.  (Ripping blades supposedly are ground this way, but I've never seen one that actually was.)

So instead of having all flat top grinds, I wanted an ATB/R (Alternating Top Bevel with Raker) blade.  The rockler page calls this a "combination" grind.  Remarkably, only two of the 10" blades they sell have this grind.

I ended up buying two blades: the Dewalt 7150PT ($36.04) and the Freud LU84R011 ($69.99).  Both are 50 tooth "combination" blades, designed to be good at both ripping and crosscutting.

The Dewalt blade also happens to be a "thin kerf" blade -- it makes cuts that are 0.100" wide, compared to the 0.125" kerf of the Freud.

Once the blades arrived, I took some test cuts in a piece of 3/4" MDF to see how they compared to my original 80-tooth Diablo ATB blade.  (Huh, turns out that's also a 0.100" thin-kerf blade.  I never noticed before!)

I cut both single-pass and multi-pass slots:

Here you can see the profiles left by the blades in single-pass cuts:

The cut on the right is my ATB Diablo blade.  It leaves the deepest V-groove.  Measuring the groove in the wood with my calipers, it looks like the bottom of the groove is about 0.016" deeper than the top.

The cut on the left is the Dewalt ATB/R blade.  Disappointingly, it also leaves a pretty significant V-profile, about 0.009".

The wider middle groove is from the Freud.  It's the flattest, but still not perfect; I see about 0.005" difference between the top and bottom.

On to the multi-pass cuts.  I should have been more careful to control the amount I moved between each pass, but the results agree pretty well with the single-pass tests.

The photo at the top of the page shows the Diablo ATB results.  Here's the slot left by the Dewalt:

And here's the slot left by the Freud:

Conclusion: I'm not particularly satisfied with the dadoes from the Dewalt blade.  The main reason I considered replacing my existing blade was to get flat bottomed channels, and the slots it leaves are bumpy enough that I'd still want to clean them out by hand with a chisel.  On the other hand, it's half the price of the Freud, and cuts just as easily.

The Freud blade is the one I'll keep on my saw (there's another table saw at work I'll use with the Dewalt).  I was hoping for completely flat slots, but these are good enough for my needs.

linux-alsa-driver-modules not up to date

To get HDMI audio working on my lucid machine, I added some PPAs and then did:

$ sudo apt-get install linux-alsa-driver-modules-$(uname -r)

That fails currently, since the PPA hasn't kept up to date with the most recent kernel:

E: Couldn't find package linux-alsa-driver-modules-2.6.32-34-generic-pae

So for now, I've just downgraded to the old kernel.  I also removed linux-image-generic so that it wouldn't automatically upgrade my kernels in the future:

$ sudo apt-get remove linux-image-generic-pae

$ sudo apt-get remove linux-image-2.6.32-34-generic-pae

Update (31 Jan 2012): Good grief, and now it's broken again.  The latest kernel is 2.6.32-38.  The fix this time was to add the lucid-proposed repository and install linux-backports-modules-alsa-lucid-generic-pae. That installs linux-backports-modules-alsa-2.6.32-38-generic-pae, which seems to take the place of linux-alsa-driver-modules-2.6.32-38-generic-pae.

To add lucid-proposed in synaptic, it's Settings... Software Sources... Updates... Pre-released updates.

That adds this line to the /etc/apt/sources.list:

deb http://us.archive.ubuntu.com/ubuntu/ lucid-proposed restricted main multiverse universe

Viewing Step (STP) files in Linux

Mechanical engineers use step files to send their designs out for manufacturing.  FreeCAD is Free Software that will view them. So tonight all I had to do on my Ubuntu Lucid machine was "sudo apt-get install freecad", then run it.  It opened up the smaller step files in the liquid galaxy mechanical drawings just fine, although it did hang for quite a while when I tried the bigger ones (and I wasn't patient enough to see if it'd eventually figure it out).

The chasm between photo and video

One of the reasons the web became so popular is that it made it easy to put photos and text together.

Now we're straining at the limits of static photos.  We want them to be more lifelike, not just paintings on a wall.  The sway of trees, our wandering gaze, the way we bob and turn our heads to get the shape of a thing.  We get none of that with a static image.

Sure, it's getting a lot easier to embed video.  But videos are like movies: they demand our whole attention from start to finish, and then they're done.  Videos are entertainment, distractions.  I'm talking about ambiance, digitized memories.

Here's what I see happening at the edges of what an image is.

Cinemagraphs are just animated GIFs, adding a tiny amount of motion to a scene to give it life.  Cinematograph gallery, another one

Google Street View was one of the earlier players, showing panoramic photos on a map.  Here's "indoor street view" from the Iraq Museum

Lytro has an after-the-fact refocusable lightfield camera.  They call their photos "living pictures".  Lytro gallery

Several news outlets have been playing with before/after photos of natural disasters.  Click-to-toggle before/after / Slide before/after

"360 views" for products are gradually spreading through the online marketplace.  Click "360 view" to see an example here: http://www.ford.com/cars/focus/?intcmp=fv-hpbb-dflt-40mpg-focus

A sackful of kludges


Except for the GIFs, every one of these innovative trends has something in common: somebody had to write code to make them work.  Street View and Lytro, and many of the 360-degree product viewers require Flash.  The before/after photos seem to have been one-off projects by the news outlets.

That's why the images I linked to are just static pictures -- only the .gif actually "works" without clicking on the links.  (And the .GIFs themselves are also a huge kludge -- it's an ancient image format that only supports 256 colors, and has been a headache for browser vendors for years).


So none of them are really embeddable; you can't easily save a local copy of them, email them to your friends, or put them into a slide presentation.  You can link to the pages where they live, but you're out of luck if the owners ever take the pages down.

Even ordinary product photos suffer from this kludge problem.  How many times have you clicked on a product photo to "view bigger", only to get a popup window with the same image, at the same resolution?  Some sites use flash, some use popups, some use javascript abominations that obliterate the product's description with a zoomed in image any time your cursor drifts across the product thumbnail.

What does it all mean?

The experimentation is good.  People are exploring, seeing what catches on.  There's a lot of space in the spectrum between static photos and video, and we're not done exploring it yet.

We don't even have good names yet.  "360 view" is starting to catch on for drag-to-swivel product photos, but there doesn't seem to be any standard way to talk about the before-and-after photos, or any mental framework that lets us explain how they relate to 360 views or cinemagraphs.

And we need tools.  Lots of creative people don't have the programming skills needed to build prototypes like these.  And viewers get old and rickety quickly -- flash was the only way to do this stuff a few years ago, but everything you see here could be done just as well in html5.

My humble contribution to the space is the swivel viewer, which actually could be coerced to work for most of the things I described here.  It proceeds from the notion that a set of images is better than a single one; drag your mouse to flip between images, scroll to zoom.  But it's not embeddable, awkward for cinemagraphs and useless for panoramas.

Eventually we're going to need file formats that bundle these things -- whatever you call them -- into a single file, browsers that can embed them, and editors that let us create and tweak them.

I have no idea what that's going to look like, but whoever creates it is going to enable the expression of a lot of pent-up creativity.