New bike! Marin Belvedere 2007

I just got my first bike since junior high, and rode a bike today for the first time since high school! Many thanks to Meg for helping me pick it out and to Dan and others for listening to me ramble about what I might or might not want.

What I wound up getting was a 2007 Belvedere from Marin Bikes, in matte coal (of course). I test-rode it and it felt great, I could even shift — something I could never do in junior high or high school without losing control, damn post-shifters — and the only limit I felt with it was me!

So after accessorizing a bit, Meg and I rode home and then walked back to pick up the car. Cupertino and the South Bay in general are so bike-friendly I can tell I’m going to put a lot of miles on it just this summer, and if I get a good set of panniers there’s no reason I won’t be able to keep doing so into the fall and even winter.

And as tired as I am just from riding a couple miles today, it feels a hell of a lot better than contributing to the climate crisis while paying nearly $5/gallon for gasoline.

Always use notification name globals, not string literals!

What’s wrong with this code?

– (void)registerForNotificationsFromTask:(NSTask *)task ( {
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:@selector(taskDidTerminateNotification:)
name:@”NSTaskDidTerminateNotification”
object:task];
}

If you didn’t notice anything wrong, look again.

What’s bad about this is that it’s passing a **string literal** instead of a **global variable** for the notification name. The code should really look like this:

– (void)registerForNotificationsFromTask:(NSTask *)task ( {
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:@selector(taskDidTerminateNotification:)
name:NSTaskDidTerminateNotification
object:task];
}

Isn’t that better? (Among other things, Xcode will offer to complete the `NSTaskDidTerminateNotification` global variable for you — unlike the contents of a string literal.)

This is a bug that often results from copying & pasting from documentation into code. “I need this notification, it needs to be a string, so I’ll just put `@””` around it.” The *type* of a notification name is, in fact, `NSString` but you don’t have to pass a *string literal* for that. Instead, pass the global variable that exists for each notification name and you’re guaranteed that the right thing will happen.

If you’re creating and using your own notifications, be sure to follow the Cocoa pattern and create your own global variables containing the notification name. Otherwise you’re at the mercy of typos within string literals.

**Update:** Sanjay Samani helpfully pointed out that by *constant string* I meant *string literal*. Thanks, Sanjay! I’ve updated my post with this correction. (Not sure where my memory was…)

I fucking hate this city

Meg rode her bike down from the hotel to Union Square to meet me for dinner, locking it up at a bike station right outside Borders.

After we walked back from dinner, we discovered it had been stolen. Right in the middle of dinner, right on the corner of fucking Union Square.

I fucking hate San Francisco. What a shit-hole of a city.

WWDC 2008

The time is upon us once again — WWDC time!

As I have the past few years, I’ll be in San Francisco all week, staying at the Hotel Kabuki in Japantown.

And of course, I’ll be around the conference all week — especially in the labs. Come by and say hi, and I’ll be happy to help with any questions you have!

CocoaHeads Silicon Valley at Apple on Thursday, May 15, 2008

The next CocoaHeads Silicon Valley meeting will be on Thursday, May 15, 2008 — that’s tonight! — at 7:30 in the Garage 1 meeting room at Infinite Loop 4 on Apple’s main campus. That’s inside and upstairs at Apple’s Infinite Loop campus in Cupertino. See the web site for directions.

This month’s main presentation is on the Best of Both Worlds — an introduction to Cocoa development by Scott Stevenson.

This talk is a combination of an introduction to Cocoa, as well as a series of advanced tips and tricks that even relatively experienced Mac programmers may not know about.

The idea here is that we want to give all of the people who are new to Mac and iPhone development a chance to get started, but we also want to do something special for our advanced programmers. So rather than choosing one, we’re just going to go ahead and do both.

Joel Norvell will also be presenting on how to edit PDF forms using Cocoa — he’s done a lot of work with PDFKit and Cocoa, and I’m looking forward to learning from him.

Thanks a ton to Scott Stevenson, Steve Zyszkiewicz, Michael Jurewitz and Joar Wingfors for organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there’s more independent mingling and discussion until it’s time to go at 9:30. Often a subset of the meeting moves to BJ’s Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

Why is Twitter not just Jabber?

Twitter is a way to post a short message to a wide group of subscribers, and to receive messages posted by a wide group of subscribers.

That’s instant messaging. There’s already a standard protocol for it: Jabber (XMPP).

Why not just use it? Why invent a new protocol?!

Actually, Twitter already does have experimental XMPP access to the full timeline — rather than to individual timelines, or to your friends’ timelines — and you can use it to build things like TweetMaps and TweetClouds and Quotably and…

But Twitter should really be built entirely around XMPP. It shouldn’t be a web app at all, though it could certainly have a web front-end. In case you doubt me, here’s an example Twitter-like service implemented by Process One atop the ejabberd XMPP application server.

Build LLVM and clang!

I’ve talked about the LLVM Compiler Infrastructure in the past, but what I haven’t talked about yet is just how easy and quickly you can build it on your own Mac running Leopard! This is a great way to get into hacking on compiler lexical analyzers and parsers, code generators, optimizers, and so on.

What’s more, you can build both LLVM and the new C front-end clang very easily and in five to ten minutes.

First, create a work area to check them out into, wherever you normally create your projects.

[~]% cd /Projects
[/Projects]% mkdir LLVM
[/Projects]% cd LLVM
[/Projects/LLVM]%

Then check out LLVM itself and clang from the LLVM Subversion repository.

[/Projects/LLVM]% svn checkout http://llvm.org/svn/llvm-project/llvm/trunk llvm
[/Projects/LLVM]% cd llvm/tools
[/Projects/LLVM/llvm/tools]% svn checkout http://llvm.org/svn/llvm-project/cfe/trunk clang
[/Projects/LLVM/llvm/tools]% cd ../..
[/Projects/LLVM]%

Then edit the PARALLEL_DIRS definition in llvm/tools/Makefile to tell it about clang. Just add clang onto the end, like this:

PARALLEL_DIRS := llvm-config  \
                 opt llvm-as llvm-dis \
                 llc llvm-ranlib llvm-ar llvm-nm \
                 llvm-ld llvm-prof llvm-link \
                 lli gccas gccld llvm-extract llvm-db \
                 bugpoint llvm-bcanalyzer llvm-stub llvmc2 \
                 clang

Now create a directory to build into, next to your llvm directory, and change into it.

[/Projects/LLVM]% mkdir build
[/Projects/LLVM]% cd build
[/Projects/LLVM/build]%

This is where you’ll actually run configure. This will ensure your source tree isn’t polluted with build products, and that everything stays self-contained while you hack.

[/Projects/LLVM/build]% ../llvm/configure --enable-targets=host-only
# lots of logging
[/Projects/LLVM/build]%

You’ll note that above I passed an argument to configure. This ensures that LLVM is only built to target the architecture I’m running on, to speed up the build process; this is generally fine for simple front-end development.

Now, to build LLVM as well as clang all I have to do is invoke make. LLVM is set up to correctly do parallel builds, so I’ll pass the number of CPUs I have in my machine via make -j 4.

[/Projects/LLVM/build]% make -j 4
# lots of logging
[/Projects/LLVM/build]%

That’s it! LLVM is now (hopefully) successfully built. All of the pieces are in the build directory under Debug/bin and Debug/lib and so on; see the LLVM web site for details about what the various components are.