The Daily Parker

Politics, Weather, Photography, and the Dog

Marriage in New York

Sullivan raves about how New York's political leaders in both parties have made gay marriage a real possibility this year:

It's a BFD because it doubles the number of Americans with the right to marry the person they love, even if they are gay. That is one hell of a fact on the ground. It will almost certainly help in California. It will reveal even more profoundly that this does not mean the end of civilization, but is, more prosaically, a modest reform to strengthen the family, integrate the marginalized and enlarge our moral universe. And it cannot now be undone.

Fingers crossed.

Photo of the Day

The Guggenheim Museum, 31 December 2000:

ISO-100, 1/125 at f/4, Kodak DC4800, 12mm, taken here.

I mentioned a while ago that only with my Canon 7D have I gotten digital images with about the same resolution as film. Even though I made this photo on a 3Mpx camera, I shot it at 1536x1024 because I had, I think, a 64 MB card in the camera, which could hold only about 300 shots. Still, the shot looks decent enough at Web resolutions.

I spent part of the weekend organizing photos from the last decade in Adobe Lightroom. From late 2003 to 2006 I used a Nikon E2100, a little throwaway camera, and I almost cried comparing its photos to the Kodak DC4800's (like the one above) and photos from the Canon SD400 that followed it. The lack of resolution and exposure control gave me more than two years of photos with less quality than shots from most modern mobile phones.

Small classes (geeky)

Andrew Binstock, editor of Dr. Dobb's, has a pair of editorials in praise of and instruction to create small classes:

High levels of complexity, generally measured with the suboptimal cyclomatic complexity measure (CCR), is what the agile folks correctly term a "code smell." Intricate code doesn't smell right. According to numerous studies, it generally contains a higher number of defects and it's hard — sometimes impossible — to maintain. ...

My question, though, is how to avoid creating complexity in the first place? This topic too has been richly mined by agile trainers, who offer the same basic advice: Follow the Open-Closed principle, obey the Hollywood principle, use the full panoply of design patterns, and so on. All of this is good advice; but ultimately, it doesn't cut it. ...

...[Y]ou need another measure, one which I've found to be extraordinarily effective in reducing initial complexity and greatly expanding testability: class size. Small classes are much easier to understand and to test.

In Part 2, in which Binstock responded to people who had written him about the first editorial:

Coding classes as diminutive as 60 lines struck other correspondents as simply too much of a constraint and not worth the effort.

But it's precisely the discipline that this number of lines imposes that creates the very clarity that's so desirable in the resulting code. The belief expressed in other letters that this discipline could not be consistently maintained suggests that the standard techniques for keeping classes small are not as widely known as I would have expected.

Both editorials make excellent points. Every developer should read them.