Birds and Glass Doors

Birds and Glass Doors don't get along very well. In fact, despite all the complaints you hear about windmills eating birds, more birds die annually from collisions with glass patio doors than they do from encounters with windmills (try this Google search).


On Sunday, one of the girl house finches that lives near my yard (and frequents my feeders) hit the door to my deck. [Edit: no, that's not a house finch. It's the Canadian cousin of the Gold Finch that's been hanging around here lately due to lack of food in Canada from the droughts last year. Don't remember it's name. I'll ask again at Wild Birds and post back. Given how colorful the Canadian finches aren't, it may even be a boy.] Hard. So hard that I expected to see her dead when I looked outside. But she wasn't dead — she was just stunned. Really stunned. So I scooped her up and set her on my table and got my camera and took some pictures with the macro extension. The light was lousy, but the results were still pretty good. I shot these at 400 ISO at about f6.3 — that was the best aperture I could manage with the lousy light. Getting really close to something with a macro means significant depth of field is needed to keep the subject in focus, so that why the focal plane seems so narrow.

Here's a close up of her eye; you can see the lattice pattern of the table reflected in the lower part of her iris:


Another close up, of her beak, with a lot of perspective:


Here's a close up of her tail feathers; on the full image, you can see a lot of detail:


The story ends well, too. We were going to put her in a rag-lined pot so she'd stay warm, but before we could move her, she flew away and landed on a tree near the back of my yard.

P.S. The long hiatus was due mostly to being busy, but also to having little that wasn't mundane to talk to about. Seemed better to be silent than post boring stuff.

LinkedIn

Today, I joined the 21st century and created a profile on a social networking site (LinkedIn). I've resisted for a number of years, but the thought that I might be able to recruit through LinkedIn was enough motivation.

On Auto Save

I was just coding up something Eclipse for work and decided I wanted to pop a dialog to ask the user "Do you want to save?" I did a quick Google search to see if I could find the name of dialog I wanted - and instead, ran across this blog post. The author, in a nutshell, through the post and his subsequent comments, argues that asking the user to save is a bad thing and, instead, your program should always be saving - but in such a way that it is possible to roll back the changes.

At first blush, that seems like a really good idea. If the program is always saving, you never need to worry about losing your work, so you never need to stop and think "now I want to save" - and hence can't forget to do it. Likewise, if you discover that you've been going down the wrong path, you can always step back and reverse your changes (just undo until you get back to where you would have preferred to be). Presumably, the program will even reload your undo history when you reload a given document.

Here's the problem. "Save" does more than just commit a set of recent changes to non-volatile storage. It's also an expression of intent that means "and now I've made a meaningful set of changes to which I want to be able to return (in the event of a crash, etc.)." In some circumstances, these two things are equivalent (or very nearly so). For instance, when I'm typing a blog, I might periodically be saving my entry because, after all, any change I've made is meaningful. Sure, I might decide later to back up, but there's no problem if basically every change I make is saved.

This is simply not true in all circumstances. Imagine, instead, a database application with hundreds (or thousands or millions) of users, all of whom are working on pieces of a single, centralized data store. Anne opens a form to edit an entry in one of the records on the database. As she makes changes, she effectively breaks things - while updating field 1 but not having had a chance to update fields 2 and 3, the entry is now in an inconsistent state: its data no longer makes sense and should not - or cannot - be committed back to the database. If it were committed (if the database allowed it), Bob might see some of Anne's changes but not all of them and he might either be thoroughly confused, or take some incorrect action based on the inconsistent data.

Save, then, becomes the mechanism by which Anne says "And now my data is consistent and should be visible to all users of this database." Likewise, should Anne try to close the form through which she is editing the entry, the software well and truly should ask her "are you sure you don't want to save those changes?" Here, save is a clear expression of intent and cannot be serviced with auto save plus versioning.

One final thought: it's tempting to say that the software should ensure that Anne cannot make changes to any entry and in so doing put that entry in an inconsistent state - even temporarily. But that assumes that there is some mechanism by which the software can "guess" at reasonable or correct values for all related fields when any one of them is changed. In the case of a set of related dates (Earliest Launch Time, Latest Launch Time, Preferred Launch Time), this is easily handled. In general, simple solutions cannot be found: when updating code, for instance, how is the software supposed to guess at a correct set of actions to take in response to an arbitrary line being updated? Anne must make the changes she had in mind and then signal to the software that now her changes should be committed and thus should be visible to all users.