I've fiddled with my blog template because I decided I wanted more horizontal viewing space, given that it was using less than a third of my 1920 horizontal pixels. If it feels too spread out for you, I added a drag-and-drop handle over to the left to let you resize the main content column. The javascript is pretty primitive. If it breaks, drop me a comment.
>
>
>
>

Saturday, January 31, 2009

Cookies

The web is full of "the best chocolate chip cookie recipe"s, but here is one from a NY Times article that would truly be a grievous loss to civilization if it were to pass out of knowledge. According to the accompanying article, this recipe was created with the input of a number of master bakers from New York City. I believe it. This recipe makes what could be the absolute best homemade chocolate chip cookies I've ever had. The recipe is online, but I'm replicating it here. Note if you don't read the article: refrigerating for 24-36 hours before cooking is a very important step. Also, I used regular semi-sweet chocolate chips, and they turned out fine. Maybe they'd be even better with the fancy chocolate?

Time: 45 minutes (for 1 6-cookie batch), plus at least 24 hours’ chilling

2 cups minus 2 tablespoons

(8 1/2 ounces) cake flour

1 2/3 cups (8 1/2 ounces) bread flour

1 1/4 teaspoons baking soda

1 1/2 teaspoons baking powder

1 1/2 teaspoons coarse salt

2 1/2 sticks (1 1/4 cups) unsalted butter

1 1/4 cups (10 ounces) light brown sugar

1 cup plus 2 tablespoons (8 ounces) granulated sugar

2 large eggs

2 teaspoons natural vanilla extract

1 1/4 pounds bittersweet chocolate disks or fèves, at least 60 percent cacao content (see note)

Sea salt.

1. Sift flours, baking soda, baking powder and salt into a bowl. Set aside.

2. Using a mixer fitted with paddle attachment, cream butter and sugars together until very light, about 5 minutes. Add eggs, one at a time, mixing well after each addition. Stir in the vanilla. Reduce speed to low, add dry ingredients and mix until just combined, 5 to 10 seconds. Drop chocolate pieces in and incorporate them without breaking them. Press plastic wrap against dough and refrigerate for 24 to 36 hours. Dough may be used in batches, and can be refrigerated for up to 72 hours.

3. When ready to bake, preheat oven to 350 degrees. Line a baking sheet with parchment paper or a nonstick baking mat. Set aside.

4. Scoop 6 3 1/2-ounce mounds of dough (the size of generous golf balls) onto baking sheet, making sure to turn horizontally any chocolate pieces that are poking up; it will make for a more attractive cookie. Sprinkle lightly with sea salt and bake until golden brown but still soft, 18 to 20 minutes. Transfer sheet to a wire rack for 10 minutes, then slip cookies onto another rack to cool a bit more. Repeat with remaining dough, or reserve dough, refrigerated, for baking remaining batches the next day. Eat warm, with a big napkin.

Yield: 1 1/2 dozen 5-inch cookies.

Note: Disks are sold at Jacques Torres Chocolate; Valrhona fèves, oval-shaped chocolate pieces, are at Whole Foods.

Monday, January 26, 2009

Good Design in 42 Seconds

Caution: not for the novice programmer! Ready? Go.
Find a method that's more complex than average. Use "extract method" refactoring to decompose a complex method into smaller pieces: private methods with self-documenting (doesn't-need-comments) names and correspondingly well-defined roles, like createNewThis, storeThat, and processIntoTheOther. Then convert each of the private methods into an interface/implementation pair. Apply this across a project, and you find yourself with pyramids of objects. The very lowest-level business and integration operations are encapsulated by small building blocks at the bottom. Mid-level objects are no larger than the lower, but assemble the lower-level objects into useful sequences for doing work. Higher level objects continue extending this pattern of maintaining small size but assembling functionality from lower-level chunks. Then unit testing any single object is as simple as mocking the few objects it depends on and testing that it invokes its dependencies in the right order and passes them the right parameters under whatever conditions it's in charge of knowing about. Changing behavior is equally easy because simply writing a new implementation of an object that's <100 lines is nothing. The old implementation stays around for reference, including its supporting tests, or it and its tests can be removed. No more changing the code and then having to trace through old tests to see what needs to be fixed there. Polymorphic open/closed.

Thursday, January 1, 2009

Ubuntu Video Problems or How I Learned To Stop Worrying and Love Installing ATI Drivers

I've finally gotten around to fixing my broken Ubuntu desktop. It required a reinstallation of ATI video drivers for my Radeon X1900 card. The Situation: I had installed a fresh copy of 8.04 just after it came out, and I updated via the update manager as updates became available. A couple months ago, I installed some updates which upgraded me to kernel version 2.6.24-19-generic. I don't know what else changed, but after this I couldn't get to the desktop. I removed gdm from the init scripts so I could work at the command line. Every time I tried to run startx, though, it would first go to the grey/black and white check background with the "X" mouse cursor, then to a plain white screen with the normal Gnome mouse cursor. The mouse was responsive, but there was only the white screen. Hitting Alt+Tab would show the outline of what appeared to be a dialog box with the outline of the "task switch" panel in front of it. Hitting enter would make the dialog go away so that this didn't happen anymore and I was just stuck with the plain white screen. Ctrl+Alt+Backspace would make the desktop appear for an instant before dropping me back to the command line. The Resolution: Googling led me in a few different directions, and I tried things like trying to reset my xorg.conf via dpkg-reconfigure xserver-xorg. This generated a basic xorg.conf, but it also failed with this error about a battery: FATAL: Error inserting battery (/lib/modules/2.6.24-19-generic/kernel/drivers/acpi/battery.ko): No such device ??? This is a desktop! Obviously there's no battery! I never figured out what was up with that. Anyway, the new, very small xorg.conf didn't make anything different happen. I also tried updating a couple times along the way with: apt-get update apt-get upgrade Still no dice. Previous experience had taught me that, regardless of which OS you're using, if you have weird problems like this, there's a better-than-even chance that it's got something to do with the video drivers, so I thought I'd try updating those. The Unofficial Wiki for the ATI Linux Driver was very handy in this regard. I found it linked on the ATI driver page when I went there to download the driver. Of course, downloading and installing the driver yourself is considered the Hard Way, but I've done it once before, and it was the automatic way that got me in this predicament. The wiki has instructions for multiple version of multiple distros, including a page for Ubuntu 8.04. I followed the instructions along to the "Install .debs" step before I hit my first problem. The problem was that I had conflicting packages installed because while I was waiting for the driver to download, I had installed Envy with the intent of trying to have it straighten out my drivers for me. I never tried it though, opting instead to handle the installation myself. It turns out, though, that in installing it, several packages had been added that got in the way of the packages that the driver wanted to install. Removing the Envy packages let the driver packages install fine, but at the very end, I got this error message: [fglrx:firegl_init_module] *ERROR* firegl_stub_register failed Further Googling led me to a forum thread that mentioned that trying to install the fglrx module (the ATI drivers) with modprobe fglrx is what causes this error. I tried running that command, and sure enough, I got the same message. The thread also mentioned that modules "radeon" and "drm" seem to get in the way of fglrx, and removing them allows modprobe fglrx to work. lsmod showed that I also had the two modules in question installed, so I crossed my fingers (I had no idea what would happen) and removed them with rmmod radeon and rmmod drm, then ran the entire installation process again, just to be safe. This time it went fine. I started on my way down the checklist again, and when I got to sudo aticonfig --initial -f, I realized that this is something I should have tried in the first place, since this generates an xorg.conf file with all the right ATI stuff in it. Oh well. After finishing the checklist, my desktop is back, and this is the first blog post I've made from Ubuntu. Woohoo! P.S. The title of this post is a reference to one of the greatest movies ever: Dr. Strangelove.