• MovieConverter available on the App Store

    I'm pleased to announce that my MovieConverter app is now available on the iOS App Store. The app is designed for iPad users that want to import and edit video that was taken with a compact digital camera in iMovie.

    The premise is pretty simple, but I think it is a huge help to those that don't want to travel with a laptop and want to edit video.

    While I don't expect to become a millionaire on this, I do hope to sell enough copies to go out to dinner a few times!

    Thanks Apple for the fast turnaround on approving this! Total time less than 9 calendar days from initial submission.

  • Are there tricks to interviewing to get good candidates?

    Last week I had a discussion with some of my colleagues about interviewing. As they have come from a computer science background, their questions consisted of things like showing how a linked list works, how to do bitwise operations, etc. I actually struggle with these questions as I don't have a computer science background, I haven't been in college for 16 years, and I pretty much haven't touched this type of code in years since I've been doing Objective-C development. So do these questions help find solid candidates? I have no idea.

    When I've interviewed people, I'm not clever enough to come up with this types of computer science questions, so I've taken different routes and try to get at how a person thinks and what they can learn. One of the most important things I learned in college was how to teach myself anything which has proven to be an asset. A number of years ago, I had an interview at Apple for AppleWorks and I basically didn't get the job because I didn't know C++. The next interview I went on, I don't believe I was asked highly technical questions and was hired. Within 2 weeks, I learned C++ and was off and running.

    There is no magic to interviewing and maybe computer science questions are great for candidates right out of college, but do they help adequately screen candidates? If the candidate gets the CS questions wrong, could a good candidate be slipping through the cracks? Possibly. I find that if I probe a person for specifics on what they have on their resume, I can get a pretty good idea of how the candidate will work.

    To each his own; there are no right answers or formulas for finding and retaining good employees/contractors.

  • Another Lion change wreaking havoc

    One common practice when subclassing a class is to use an application specific prefix so that if Apple adds a similar class in the future, it doesn't conflict. For ReceiptWallet, I always used RW. One of the classes I subclassed was NSTextView so that I could draw text in gray when no text is entered. This is similar to NSTextFieldCell's setPlaceHolderString method. I named my member variable placeHolderString and added a property. The code worked fine on Snow Leopard, but when it was run on Lion, we had reports that the placeholder text was drawn twice and blurry.

    It appears that Apple added this property to NSTextView in Lion, but didn't document it. I tried lots of different tactics to fix it, but decided the easiest thing to do was to rename my member variable/property. That worked perfectly and remains backwardly compatible.

    So despite my best effort to keep my changes in my own namespace, there was no way for me to anticipate or detect this kind of change.

    Lesson learned.

  • Bit by API Changes

    Mac OS X Lion has changed some of the internal workings of various APIs and as I don't work much on Mac apps, I didn't care too much. However, one app I work on got bit by this pretty hard. In various places in the NSDocument based app, I called:

    [self saveDocument:self];
    

    This, I had assumed, was a synchronous call and then proceeded to make calls after that based on the fact that the call succeeded. Up until OS X Lion, things seemed to work fine. However, with Lion, this call seemed to cause problems and after reading the header file for NSDocument, I instantly realized the issue:

    /* The action of the File menu's Save item in a document-based application. The default implementation of this method merely invokes [self saveDocumentWithDelegate:nil didSaveSelector:NULL contextInfo:NULL].
    */
    - (IBAction)saveDocument:(id)sender;
    

    So I was tricked into thinking there was a synchronous call and got bit by it. So I've fixed the code to use a callback and things seem to be working better. While I should have been using the asynchronous call all along, I don't recall if it existed in OS X 10.4 when I first wrote the program.