Crisis Averted!

Coda, the new all-in-one web development tool from Panic is truly a great app. It has tons of useful web development features within reach: text editor (complete with optional fancy CSS editor, syntax highlighting and code completion, and more), FTP client, live preview, terminal and code references (books) all wrapped up into one very slick, very Mac UI.

Despite all these good things, I feel that version control is sorely lacking. Users of TextMate, or other tools with version control integration (Eclipse, etc.), will find Coda's lack of version control a slight setback. Of course, command line access to version control is still possible, and power users won't mind. But, if Coda were to have support for this built right in, I think there are a lot of folks that wouldn't mind that, either.

DisplayConfigX is one of two or three decent tools for making OS X play nice with televisions, with powerful overscan correction settings. However, the documentation is sorely lacking a single sentence that could have saved about 4 hours of my life:

After installing new resolutions and rebooting, you may need to open Display Preferences and re-select the desired resolution.

For whatever reason, the changes I made took hold immediately after rebooting, but the overall display geometry didn't correct itself to compensate. I just couldn't seem to get the settings to do what I expected based on the documented behavior. Switching down to 800x600 and back forced the display geometry to recalibrate.

After about 4 hours of tweaking porches, rebooting, RTFMing, and googling for other folks' run-ins with DisplayConfigX, I figured I should try something different. In hindsight, I feel pretty foolish for not doing it sooner.

At any rate, here are the settings I finally landed on for my Philips 32PF7320A/37 32" LCD TV:

In preparing the recent releases of Jabber::Bot, I had my first OS X experience with using tar to produce a tarball; I had previously only been a consumer of tarballs, at least in OS X.

Using OS X on the command line means dealing with resource forks. Especially when doing things like copying or archiving files for public distribution. Of course, most OS X folks are familiar with .DS_STORE files. They are a nuisance, but generally can be dealt with without much fuss. Resource forks, on the other hand, can be a whole different animal.

Which brings me to my point. In order to create a public tarball, it's a good idea to exclude resource forks. They serve no purpose to anyone but you or another OS X user, who likely doesn't really care anyway. But, tar on OS X (Tiger) likely won't exclude them, even if you specify a proper exclude pattern. Like, say, --exclude='._*'. It took a few attempts, but I finally was able to prod all-knowing Google for a solution. On the command line (that's Terminal, folks):

export COPY_EXTENDED_ATTRIBUTES_DISABLE=true

Then, run tar as you normally would. Maybe tar -cf foo.tar ./foo, or so? Yeah, now you're talking.