As every year, May brings the annual swim down Town Lake in Austin, my motivation to get to the pool twice a week all winter and stay in some kind of shape. This year I moved up an age group into tougher competition, which was both good and bad: I didn’t have any hope of placing this year, as I have the last two times I swam the race, but I didn’t have any pressure to, either. So I didn’t swim very hard–I was barely winded at the finish–but I finished 60th overall, exactly the same as in 2008. If I were still 34, I’d have scored yet another third place plaque (or maybe I would have swum six seconds faster and taken second); instead, I got ninth.

(Yes, that’s actually the photo from 2007. I don’t know if Molly got a photo this year.)
Disappointed? Not at all. I love collecting trophies, sure, but I got to spend a week in Austin with my sister and take a quick trip to New Orleans, eat lots of great food, and hang out in the sun at Barton Springs, my favorite place on Earth.
It’s gotten to the point where I dread Xcode updates. Every new release adds “features” that never work for me and only get in the way, or trade something that worked for something that doesn’t. Example: a while back Apple “fixed” potential multithreading problems in gdb by simply making it refuse to do what you ask it to. Thanks! Or Fix and Continue–just doesn’t work any more, as far as I can tell. In 3.2, Xcode expanded autocompletion into places I really don’t want it and didn’t provide, as far as I can tell, any easy way to turn it off.
Here’s the not easy way to do it: Paste the following text into a file at ~/Library/Application Support/Developer/Shared/Xcode/Specifications/C.xctxtmacro.
(
{ Identifier = "c.block.if"; },
{ Identifier = "c.block.ifelse"; },
{ Identifier = "c.block.elseif"; },
{ Identifier = "c.block.for"; },
{ Identifier = "c.block.for.i"; },
{ Identifier = "c.block.while"; },
{ Identifier = "c.block.dowhile"; },
{ Identifier = "c.block.switch"; },
{ Identifier = "c.caseblock"; },
{ Identifier = "c.elseblock"; },
{ Identifier = "c.enum"; },
{ Identifier = "c.struct"; },
{ Identifier = "c.union"; },
)
On the other hand, if you’d rather let the editor autocomplete these but you prefer the following curly bracket on the next line, where god intended it to be, you can change Xcode’s sacrilegious behavior thusly:
defaults write com.apple.Xcode XCCodeSenseFormattingOptions '{ "BlockSeparator" = "\n" ; }'
More useful tips here: http://cocoawithlove.com/2008/06/hidden-xcode-build-debug-and-template.html
Yeah, I know: computer art. But still, I like how these came out.

This is a plot of an iterated function system. I’ve coded these up plenty of times before, but always using affine transforms as in Barnsley’s Fractals Everywhere. After seeing the Sheepsaver screen saver I realized there’s no reason not to use other kinds of functions, and throwing in second-order products is an obvious next step.
A surprising thing happened, though: With affine transforms, most of the randomly-generated IFSes aren’t very interesting—one of the functions usually has a scaling factor close to zero, and the whole thing sort of collapses into a spiky jumble. With the higher-order functions, nearly every set of randomly-chosen parameters produces an interesting image. (Or as interesting as the one above, anyway.)
So what do I do with this? I’m not sure it’s worth the trouble of fixing up the app for general consumption—in that context it seems like it’s not much more than a novelty. But I’ll keep playing with this, maybe put prints up on Etsy. I’ll let you know.
Steven points out that his Kana Hakkliha remix competition was five years ago (!) this month. My entry was the result of a weekend alone with an accordion, a ukulele, and a 12-pack of PBR—click for the video:

The app I’ve been building for the last two years has finally launched. (Actually, it launched two weeks ago, but I’ve spent nearly every waking hour since then fixing bugs.)
Click the big magnet to go check it out!
Just like everyone else, I’ve found that twitter has killed my blog–and probably for the best. But 140 characters can be a bit constraining at times, and I still want somewhere to post photos that isn’t flickr. I gave tumblr a try, but it just didn’t click. Then Cabel set up Wordpress for the new Panic blog and said it was pretty painless, so I thought I’d give it a try. I’ll probably neglect this one, too, but now I don’t have to see that I haven’t posted anything since March.
Here’s the old blog, just for sake of completeness.
@implementation NSMutableDictionary (AddListObject)
- (void)addListObject:(id)obj forKey:(id)key
{
NSMutableArray* list = [self objectForKey:key];
if ( list == nil )
{
list = [NSMutableArray array];
[self setObject:list forKey:key];
}
[list addObject:obj];
}
@end
On the local boatbuilding list, Frank asked for suggestions on gluing the plastic pieces of his broken headphones together. Chuck Gottfried shows how it’s done:
Frank, the entire issue hinges on if you want traditional, or more hoity-toity modern. Strictly speaking, the ‘classic’ fix would use walrus hide, applied wet and allowed to dry. If it needed a ‘filler’, I would suggest peat moss. A more modern fix would include seal oil tar under the walrus hide, but you could substitute pitch, or (gasp!) roofing tar if you wanted to go hi-tech.
If you go with pitch/roofing tar, the correct process would be to first tar the headphones, worm the repair, parcel with tarred canvas strips, then serve with marline following standard techniques. If the headphones have any discernable lay (twist), remember to always worm and parcel with the lay, and serve against it. You COULD substitute tarred nylon, for marline, but it wouldn’t be quite as realistic. In a pinch, you could even substitute fresh cat gut for the marline, but I’m not gonna guarantee how that will hold up in the weather. It should set up nicely, tho, once it shrinks a bit.
There are numerous texts on the precise lashing you could use; I suggest Brian Toss’ Rigger’s Apprentice as a place to start. There are other texts for info on the proper use of walrus hide, if you go that route. If you need a serving mallet, let me know and you can borrow mine. For this, its probably not worth making your own, and you can’t buy ‘em.
I recommend against just parceling the headset in this instance, no matter how tempting that may sound, tho there are some who might argue. You need the additional strength here, and parceling, while helping with the critical headphone-to-head chafe, won’t add strength you get from the hide, even if well dosed with seal tar. Keep that stuff out of your hair, whatever you do.
If you didn’t catch the joke (and don’t feel bad if you didn’t) he was describing how standing rigging was historically treated—see this wikipedia entry for a brief description.
Another, possibly more practical, suggestion was to check the [terribly useful] site http://thistothat.com/.