Software Development

Interview of Yours Truly

Andy Kim — Mon, 19 May 2008 15:19:18 -0700

Will Holmes was kind enough to interview me on his blog. I talk about square watermelons and Don Norman. I hear they're giving away licenses of Tangerine! and Voice Candy too.

Link to Interview

Best Crash Report Ever

Andy Kim — Sun, 06 Jan 2008 16:32:42 -0800

I was chatting with a developer friend about crash reports and as one thing led to another, after a quick Gmail search, I ended up showing him this one particular crash report I got sometime last year:

A flash of lightning could be seen through the north-facing window, the squak of the dark night's crow taunted me from a distance as I just reloaded the library in Tangerine. Shortly after a masked butcher, knife and all, broke through my thrice-locked front door barking threats of murder, Tangerine! unexpectedly quit. As a father feels when he loses his son, I felt an overwhelming sadness until I was warmly greeted by Apple's "YOUR PROGRAM CRASHED, BROTHA!!" window suggesting I relaunch Tangerine. That's what brings me here, composing this message to you. I have personally attached the Crash Long Contents for your reviewal. I can only hope, pray, that you will use it to correct the wrong that I have experienced. Now I must bid you adieu.

I cringe whenever I get a crash report, but if they were all like this, I wouldn't mind so much.

It's from a Mr. Eric L. Pheterson. I hope he doesn't mind my publishing it here. Oh, and the bug was fixed a long time ago.

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.

Licensing Scheme Switch

Andy Kim — Tue, 12 Dec 2006 15:43:55 -0800

Announcement

With the release of Tangerine! we moved to a new licensing scheme across all of our applications. If you upgrade Podcast Maker or Voice Candy and all of a sudden find that it thinks that you are not registered and your trial has expired, it is because you need to put in your new license key. We emailed them out ahead of time, but you may not have gotten it for one reason or another. In that case, please go here to retrieve your license.

But... Why?

So why would we go through the eye-poking pain of updating every order in the database, not to mention having to write code that we don't enjoy writing? Well, there are several reasons why it's all justified. With Podcast Maker we wrote code first and asked questions later. Thus, when we were done with the code, we looked to Kagi as the best solution to quickly take the product to market. We had to abandon them to our own custom store eventually, but it was... sufficient... at the time. The attractive thing about Kagi was that they provided us with a ready to go licensing code. We knew that it was a generic solution that is easier to reverse engineer, and we were proven right recently. A leaked license key can be blocked, but a new license key generated by the crackers is a different game altogether.

With the release of Voice Candy we moved to a license file based system while still accepting the old Kagi license keys in Podcast Maker. While it is cool and some people do prefer the convenience of just double clicking a file to register, it proved to be a burden on us support wise. Most of the times, it wasn't even the users' fault or ours. Some email servers classify email as spam more readily if it contains attachments of unknown extensions and others block it altogether. Some email clients such as Eudora do not even allow file extensions longer than 20 characters, rendering the license file useless for the user, and sometimes even turning the user into a mad and angry user.

So in the end, we are back to issuing license keys but generated with our own algorithm. I'm hoping that the crackers will leave us alone for now (uhm... because we are nice guys?), but I get a feeling that that's just wishful thinking.

Release Happy

Andy Kim — Tue, 23 May 2006 02:45:31 -0700

Developers experience a high when releasing 1.0 software. The sensation that it's finally done! Each and every one of the congratulatory letters really makes one feel proud too. I relate the experience to taking a ginormous dump (uhm... don't take that too literally). Here are links to two newly released softwares, each deserving a look, and what their devs have to say:

My Post WebNoteHappy 1.0 Experience by Luis of HappyApps who just released WebNoteHappy, a better bookmark manager for your Mac.
Post Release Stress by Dan of Karelia who just released Sandvox 1.0 along with Terrence.

A big congratulations and a round of applause to these developers for getting their one dot oh's out the door. Keep an eye on their blogs because now that they have released their software, I'm sure they'll be writing more often, just as this dev hopes to. They are both good writers in addition to great developers.

Iron Coder #0

Andy Kim — Mon, 06 Mar 2006 01:24:56 -0800

In the spirit of the show Iron Chef, some mac developers have joined together for the first ever Iron Coder contest. Developers are given 24 hours to come up with something cool given an API and a theme. The API for the first contest was Accessibility and the theme was Mardi Gras.

Here are our entries (with source code!):

Jump to Iron Coder

UPDATE: You can get all of the entries here.

UPDATE 2: Lucas Eckels got the honor of being the first ever Iron Coder with his entry Symphony. Congratulations Lucas. On a completely separate note, Steve Harris of Reinvented Software and Feeder fame has created a mash-up of our submissions titled GrassyKnoll. You can now shoot beads at passing windows. Grab the mash-up here for some good laughs!

Technorati Tags: ironcoder

Hidden Gem

Andy Kim — Thu, 13 Oct 2005 11:36:22 -0700

Lots of announcements today from Apple. New iMacs, Video iPods, blah blah blah. It's the only thing that anybody is talking about. I'm going to tell you about something else that is cool today.

We were brainstorming sometime before the release of iTunes 5, and I came to think about sliders. They are useful but pretty hard to use. If you want to change the value of the slider continuously, you have to grab the tiny knob and drag it around. For something like a volume slider, a real world knob is much easier to operate and more precise than anything in a computer. Well, a lot of people have mice with scroll-wheels nowadays so why not use it with the slider! Just move the mouse over a slider and scroll to adjust the value. Pretty nice idea I thought and proceeded to check a few apps to see if it was already done that way by default in OS X. Nope.

When iTunes 5 came out, I unconsciously flicked my scroll-wheel over its volume slider. It moved! I felt like a young padawan using the force for the first time. It was very strange, but in a good way. I didn't think that anybody would be that detail oriented, or put another way: anal. Some programmer at Apple must have been thinking the same thing as me about around the same time because that feature sure wasn't there in iTunes 4. Creepy. I might have a twin separated at birth working at Apple...

So yeah, you can use your mouse wheel to adjust volume in iTunes 5... uhm... 6. I think it's a nice touch.

I haven't put that in into Podcast Maker yet, but I will eventually.