Tips

How to Keep Backwards Compatibility and be Less Grumpy About It

Andy Kim — Sun, 04 Nov 2007 03:35:01 -0800

I dread backwards compatibility. I dread it because it means that for every product that I need to keep backwards compatible, the testing burden is at least twice as big. The math is simple: testing on two major OS versions and two processor types can be as much as 4 times of stuff I'd rather not be doing.

The last time I had to maintain a product with backwards compatibility, this is what I used to do:

Build then copy application to test machine.
Get it to fail. This is the one part where I don't have to work very hard.
Try to fix while scratching head then proceed to littering print statements all over the code.
Go back to step 1.

You can make this process a little less sucky by configuring Xcode to copy after each build, or by mounting a share so that there's no copying at all. But in the end, debugging with print statements alone is limiting and time consuming. There has to be a better way, right?

The better way turns out to be handsomely better and it's called remote debugging. A remote debugger is usually used for kernel hacking or for developing full-screen applications such as games, but it's quite handy for fixing backward compatibility problems—especially if your app no longer builds on Tiger.

With remote debugging, I can code in Xcode 3—my new favorite IDE—then just hit command-Y. It works as any great software should. Like magic. The application launches on the test machine and you're off debugging as if it were running locally. You can set breakpoints, examine variables and stack traces, fix and continue, or whatever else that gdb can do. There's no longer a cycle of doom, and as a result, I'm a much happier person.

There are just 3 things you need to do to get stress free debugging on older systems with Xcode:

Set up password-less ssh for logging into your test machine.
Share the build directory in a way that both machines can access it through the same path
Configure a new executable in Xcode for remote debugging.

The Xcode User Guide does a fine job of explaining these steps succinctly.

Xcode User Guide — Debugging Programs Remotely

Some additional tips:

1. If your test machine has a different kind of processor, duplicate your Debug build configuration and set it up to build a universal binary.

2. Use "DWARF with dSYM File" as your debug metadata format. With the other two options, breakpoints set through the Xcode UI didn't work for me.

Email Voice Candy Recordings as MP3

Jin Kim — Sat, 30 Dec 2006 01:35:41 -0800

One of the feature in Voice Candy is the ability to add custom AppleScript actions to interact with different applications. One action that I think Voice Candy users might find handy is an action to send email with the recording in MP3 format. Currently, Voice Candy only records to the QuickTime movie format and so the "Send Email" action sends the recording as a .mov file which might not be accessible for recipients on PCs without QuickTime installed.

So, in this post I would like to show you a way to send emails with MP3 recordings by using an AppleScript action.

First, you need to download the following AppleScript file:

Once you have the file, open Voice Candy's actions preference:

Hit the "Add Action" button and you will be presented with the following sheet:

Hit the "Choose AppleScript..." button and select the AppleScript file that you have just downloaded.
Enter the name for this action and hit "Save".

You will now notice that a new action "Email as MP3" is available from the list of actions:

Now record something then perform the "Email as MP3" action. Tada:

Hope you find this post useful. Best wishes in the year 2007.

Update (01/14/07):

You can also make a slight modification to the script file to perform different operations such as saving to Desktop:

Voice Mail

Andy Kim — Sat, 27 May 2006 06:36:36 -0700

A Mr. Randy Harris comments about Voice Candy at MacUpdate:

I've been using Voice Candy for a few weeks now and I really like it a lot. I bought it with the intention of using it like a voice version of Apple's PhotoBooth, which my kids love.

After using it a little I quickly realized that Voice Candy is about the best and easiest to use Voice eMail program that I've run across.

This put a broad grin on my face because while the effects are cool, we really wanted to make a general purpose voice recorder that is useful in addition to being fun. It is satisfying to see someone reaching that conclusion.

In any case, there actually is something helpful in this post.

If you are sending voice emails (or really just any attachments), like Mr. Harris here, and some of your recipients are Windows users, you will want to do this in Mail.app:

If you don't do that, Mail.app will send two attachments: a "Recording.mov", which is the real thing, and a "._Recording.mov"—what we have come to call the "shadow file".

"Uhm, Randy... I get no sound?", will be the response you get invariably because for some reason, they never click on the real file first. Part of the reason is because the shadow file shows up first in the attachments list. The other reason I won't say out loud.

So what is this shadow file? Why is it there? Well, the file contains resource fork data. Windows users have no use for it, and frankly, I don't think Mac users have much use for it either these days.

[ Desktop image, "Where Real Work Happens", courtesy of Veer ]

Voice Candy Tip

Andy Kim — Fri, 12 May 2006 20:45:17 -0700

Here is a tip for you Voice Candy users. The nice thing about the reminder clock is that you can easily set the time with just a click since it moves the hour hand to the position of the click. The downside is that you cannot drag the minute hand. You can however still adjust the minute hand by using your mouse scrollwheel. A bonus tip: When you are typing in the time and date, some characters will move the input focus to the next part. Those characters are: ; : / . , - in addition to the tab and left and right arrow keys. I personally find the period to be the most convenient because I use the numpad.

Password Protecting a Podcast

Andy Kim — Mon, 20 Feb 2006 10:16:00 -0800

A click is worth a thousand words.

Click here!

Surprised? I was too when I discovered that iTunes lets you access password protected podcasts.

Oh, by the way, you can use the username guest with the password guest to access that podcast.

Why?

At first, password protecting a podcast might sound counterintuitive, but there are actually many reasons why you might want to do such a thing. You might be a teacher or professor who wants the podcast to be available only to your students. You might want to share the podcast with just your friends. I know some people who share their music this way. You might want to podcast your work to clients so that they are automatically updated as you publish changes. You might have a podcast that you want only your department to have access to. Or you might want to do a "closed beta" of your podcast.

How?

The feed you clicked on is protected through the standard HTTP authentication schemes. iTunes supports both the "basic" and "digest" flavors of HTTP authentication. Combined with SSL this will provide robust security for your podcast.

Basically, you put a .htaccess file into the directory that contains your podcast feed with content that looks like this:

AuthType Digest AuthName "Potion Factory" AuthDigestFile /usr/local/apache/conf/digest_passwd Require valid-user

You also have to use the following shell command to make the digest_password file:

htdigest -c /usr/local/apache/conf/digest_passwd "Potion Factory" user1

I suggest you don't try this yourself unless you really understand what is written above. There are many reasons why the above will not work. Ask your webmaster to do it for you if you are not comfortable.

If you really want to try, here is a site with more detailed instructions:

Comprehensive guide to .htaccess - Password Protection

Credit goes to Mr. Mark B. Priddy of Affiliated Media Group for letting us know about this iTunes feature. We actually learned something answering a support email!

UPDATE (2/27/2006): You can password protect your podcast easily if you use FeedBurner. FeedBurner has an option to password protect your feed, which does exactly what I describe here. The only downside to the FeedBurner way is that it only allows one username and password, but it is still tremendously useful for something that only takes a few clicks.

Moving An Existing FeedBurner Feed

Andy Kim — Sat, 07 Jan 2006 23:59:46 -0800

Justin Valiquette emailed us an excellent question which I will share with everyone.

I have an existing Podcast that is registered with iTunes already. To create this podcast, I used the difficult method of creating a blog, and a feedburner account to create the .xml feed. I want to begin using Podcast Maker from now on. Also, I just purchased new hosting space that I want to transfer all our existing podcasts to, and put all the new ones on.

How can I create new podcasts using Podcast Maker that will register under the same podcast title on iTunes so people don't have to re-subscribe.

Thanks,
Justin

The nice thing about FeedBurner is that it acts as a layer between your real feed and your listeners. So even if your real feed moves, all you have to do is point FeedBurner to the new feed and your listeners won't even know that the switch happened. There are two parts to this move. Publishing your new feed, and reconfiguring FeedBurner.

Part 1 - Publishing Your New Feed

To publish the new feed, open up Podcast Maker and choose File then Import Podcast Feed in the menus.

Put in your current feed URL in the dialog that pops up.

After you hit the Import button you will see a new document with your podcast. Now, if you don't need to move all your existing media files from its current location, all you have to do at this point is hit the Publish button and upload your feed to the new server. Move on to Part 2 if this is you.

If you also want to move all of your media files to the new server, transfer all those files to a new directory on the new server using your favorite FTP program. Make sure that it's accessible from a web browser.

In Podcast Maker, choose each episode and look at its Basic tab. At the bottom you will see a URL in the Location field. Edit the URL of each episode to match your new server's URL.

Now publish your feed. You are almost done. You just need a simple configuration change in FeedBurner.

Part 2 - Configure FeedBurner

Login to FeedBurner and choose the feed that you are moving.
Click on Edit Feed Details...
Put in your new feed URL in the Original Feed field.

After this maneuver it will be easy to publish new episodes since you will be using Podcast Maker. The best part is that nobody will know that you changed anything.

Thank you Justin for the excellent question.