Since working at Tabblo, I've been trying to learn more about photography, and bought myself a nice camera (a Nikon D50 digital SLR) and a couple of lenses. My brother has been a big help.

I realized that my growing understanding of photography can be captured in a series of facts and guidelines:

• Hold the camera as still as you can.
• Take lots of photos.
• Throw away photos you don't like.
• Get closer to your subject.
• The subject doesn't have to be in the center of the frame.
• The slower the shutter, the blurrier the image will be.
• The lower the aperture number, the wider the actual aperture (the opening in the lens that lets in the light).
• The wider the aperture, the more light gets in, so the faster your shutter can be to get the same exposure.
• The wider the aperture, the shallower the depth-of-field, so the background will be blurry.
• A lens with a wider maximum aperture is called "faster" because it lets you use a faster shutter.
• The higher the ISO number, the more sensitive the sensor, but the more noise in the image.
• A lens will be sharpest in the middle of its aperture range.
• Back-lit subjects are really hard, but different metering modes can help.
• Shooting in RAW gives you more flexibility in post-processing, but gives you the largest files.
• Filters do magical things that I don't understand yet.

I'm not sure I can encapsulate my understanding of other fields aphoristically like this. It would be interesting to try.

My dad and step-mother live in New Hampshire, and we visit them a few times a year. Today was one of those times (to bury my uncle Dick). On the way there and the way back, we pass a tiny airfield with a few tiny airplanes, and a hand-painted sign reading "Bi-plane Rides". I've long thought about stopping and at least inquiring about the flights, it seemed like fun.

» read more of: Biplane ride... (12 paragraphs)

Right off the bat, let me say that this is not about Mac-bashing, or a Mac-vs-Windows flame.

I use Windows, but Susan uses a Mac, so I occasionally am called on to perform simple maintenance on her laptop. This morning, that involved upgrading an application. I like the Mac, and generally find it to be well thought out, and easy to use. But I've never understood the application installation process. Here's what I did to install the application Foo:

1. Downloaded FooDownload.dmg.zip to the desktop.
2. StuffIt Expander launched automatically, and gave me a FooDownload.dmg Folder on the desktop.
3. At this point, nothing is happening, so I opened the folder, inside was a FooDownload.dmg icon.
4. I opened that, a license agreement appears.
5. I agreed to that, and a window appears with an application icon, and instructions to "Drag this icon to your Applications folder".
6. I have to find the Applications folder, and drop the icon into it.

At this point, the application is installed. To clean up, I had to:

1. Close the Applications folder.
2. Close the window with the dragging instructions.
3. Close the FooDownload.dmg Folder window.
4. Get rid of the three (!) things on the desktop: The dmg, the FooDownload.dmg Folder, and the FooDownload.dmg.zip file.

To me, that seems like a lot of manual steps. In the Windows world, you'll sometimes find shareware where the author gives two options: an installer, or a zip file where you can do everything yourself. The Mac installation process is like the Windows do-it-all-yourself case.

Again, I'm not trying to slam the Mac. I genuinely do not understand why on a platform that makes things really simple, where the mantra is that stuff "just works", ordinary users are expected to do all these manual steps. Why isn't the installation process more automated? This isn't a rhetorical question.

I know someone will answer, "Because you may not want to put the application in the Applications folder," but really, how many users organize them differently? And the Windows installation wizards often let you choose another installation directory anyway, so that control is not incompatible with automating the experience.

I'm not flaming the Mac.

Because of Damien's post about his flying helicopter toy, I asked for one for my birthday. As a result, I now have two! They are actually different brands. One is a Air Hogs Havoc Heli from Amazon (thanks Sarai!), and the other is from ThinkGeek (thanks Susan!).

It's interesting to see the two together. They are different brands, came in completely different boxes (not even the same size and shape), and have completely different bodies. But the mechanisms and remotes are clearly identical.

They are rugged copters, and fly very easily. They don't control easily, though, so be prepared for them to buzz around and crash into things. They are lightweight enough that the crashes don't bother them. One thing to watch out for: if it skitters under the furniture, it can tangle up in hair and dust, and then you have to get a tweezers to unclog the rotors.

Practicing with the controls does help, but I still haven't gotten them to turn predictably or move forward in any real way. The main rotor is an interesting double-rotor, with a linkage between the two to provide some sort of stabilization. I don't understand the mechanics enough to figure out exactly what it does.

Although they are pretty tough, one of my copters has developed a disabling shimmy: it isn't stable enough to hover any more. At the office, we've had three or four of the best software minds in the business trying to analyze and fix the mechanical problem, to no avail.

It's definitely a fun toy. The tiny copter is a marvel, and seeing it hover for the first time is an eye-opener. I recommend it.

1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 = 45

Synchronicity abounds. Just as a blog post was forming in my mind, Kevin Dangoor wrote about the very same topic: Python dictionaries are not the same as instances. Python makes it so easy to cobble together ad-hoc data structures of lists and dicts, I find myself making do with them long past the time when I should have promoted them up to real classes.

It starts out simple, a function needs to return a list of strings. Fine. Then I need to add another piece of data for each string, so the result becomes a list of pairs. Another piece of data will turn it into a full-blown list of lists, and so on. Another function aggregates those results together, making a list of lists of lists, and so on.

I find I often live with this scheme beyond its tenable lifetime, like the boiling frog. Unlike Kevin's scenario I usually don't start with dicts, in my mind they naturally become classes: once you have to think up names for the components, classes are easy. It's lists (with their unnamed components) that seem so simple to me that they gain favor where the "heavier-weight" classes won't do.

But of course converting over to classes is not a big deal, and always reaps benefits. Kevin lists six, but overlooked the one that usually makes me smile first: default values in the constructor.

I don't know that I will stop writing ad-hoc data structures, but maybe I'll learn, and upgrade them to classes sooner. I just changed a data structure that was clearly over its limit: it was a list of four-element lists, the first element of which was a list of six-element lists:

[
    [ [ [a,b,c,d,e,f], [a,b,c,d,e,f], ... ],
        g, h, i ],
    [ [ [a,b,c,d,e,f], [a,b,c,d,e,f], ... ],
        g, h, i ],
    ...
]

The change makes it a list of objects, one of whose attributes is a list of objects. Much nicer. I shouldn't have put it off so long.

If you don't live in Massachusetts, you may not know that same-sex marriage is not a settled issue here. The state legislature continues to struggle with the issue, in the form of a proposed constitutional amendment to ban the marriages that have been legal here for three years. The lobbying is intense: Tight Vote Looms on Same-Sex Marriage.

Of course opinions are heated, with one side insisting that citizens be given a chance to vote on the amendment ("Don't deny me my right to vote"), and the other side insisting that civil rights shouldn't be subject to popular opinion ("We don't vote on civil rights").

I side whole-heartedly with the same-sex marriage supporters. If fifty years ago, we had put racial civil rights to a popular vote, they would have lost. Do we think now that we should have let the populace deny blacks the rights we now take for granted? This is one case where we should protect rights from the tyranny of the majority.

If the amendment does end up on next year's ballot, it will be a very ugly election season, with enormous forces flowing into the state to sway the vote. The battle today in Massachusetts will come down to lobbying and parliamentary maneuvering, which is unfortunate, but many noble causes have been won with such ignoble tactics.

We had meatballs for dinner last night, and as Max was eating his, he got thoughtful, and asked:

If you took all the food that all humans have ever eaten, and mashed it into one giant ball, would it be as big as the Earth?

Good question. It called for a quick series of incredibly inaccurate back of the envelope calculations:

• We estimated that one person's daily food would be a ball about 10cm in diameter, or about 524 cm³.
• Times 365 days/year, one person's yearly food ball would be 191250 cm³.
• Times 6.5 billion people on Earth, today's humans consume 1.25×10⁹ m³ of food each year.
• Now comes the tricky part, estimating over the whole course of human history. Humans have been around for let's say 200,000 years, but the growth has been exponential over that time, making it hard to flatten it out for simple calculations. (Probably some of my forgotten calculus would help here, but did I mention it's forgotten?) A good estimate is that there have been 100 billion humans ever.
• If we take a yearly intake of 191250 cm³, times an aggregate average lifespan of 50 years, times 100 billion people, we get a total all-time human consumption of 9.5×10¹¹ m³.
• The Earth has a radius of 6372 km, giving it a volume of 1.1×10¹² km³ or 1.1×10²¹ m³.

So, rounding a little further, humans have eaten 10¹² cubic meters of food, and the Earth is 10²¹ cubic meters in volume, so we're only off by a factor of a billion!

gotAPI is an aggregated API search engine. It provides a start page with selectors for all sorts of different API libraries. Then your search term is found in the API docs you chose. It's a good idea, though I'm not sure it works as well as it could, since the search results are presented in a drop-down list rather than on a more standard search results page. It may be that I just have to get used to the navigation.

Trulia is a real estate search engine, it looks nice enough. I am not in the market for such a thing, but it is fun to poke around the neighborhood and see who is asking how much for what.

The unusual thing at Trulia is Trulia Hindsight, an animated timeline of a neighborhood showing when houses were built. It's fascinating to watch neighborhoods develop, with houses erupting like popping kernels of corn as time progresses. Their blog points to a few interesting examples, showing both slow organic growth and developer-created outbreaks.

As usual, there's some problems with dirty data: the Gloucester timeline shows a huge building boom at 1900, but Gloucester is an old town (1606!), with historical houses all over the place. I suspect that at some point many very old houses were given a build date of 1900 as a placeholder.

Hindsight is a cool visualization, one of the mashups that is being made possible by having all of our data on the internet. But I'm not sure that it really helps people buy houses. It helps Trulia get some traffic (it's the only reason I'm writing about them, for example!), but is there a deeper form of house shopping I'm overlooking?

I don't know how I missed this April Fool's page: Python on Planes, a competitor to Ruby on Rails: "it lets you write beautiful code by favoring snake oil over gems."