• The devil is in the details

    I'm a very detail oriented person and one of the things that annoys me in reading code is something like this in header files:

    Copyright 2010 __MyCompanyName__. All rights reserved.

    There are numerous posts including this one that tell you how to change this by default. However, you can change it on a per project basis in Xcode by setting the organization. While many may consider this minor, the question I have to ask is "what else did the developer miss?". This kind of detail is one of the reasons I've been quite good at reviewing code and finding issues.

    I've seen this mistake made in commercial projects as well as open source projects. Do people look at the code when they first create a file? While we're at it, when I create a file, I make sure the copyright is set to whoever really owns the source; when I've done contract work, the source is always owned by the client, so I make sure it is set. About 70% of the code I've seen has had the wrong copyright. Most people don't care about this, but if push comes to shove, I don't want to be in the middle of someone trying to determine who owns the code.

  • New Service: Professional Source Code Review

    While discussing what I should do with my spare time, a colleague suggested that I write a book. That sounds interesting, but what makes me qualified to write a book? He said what makes anyone qualified to write a book. Good point, but I still am not writing a book.

    Today I spent my time on the (almost) daily dog walk thinking about that and came up with an idea "professional source code review".

    So, I'm now opening up my new service. For a flat fee, I'll spend up to 5 hours reviewing source code and then I'll prepare a detailed outline of issues and recommendations on how to proceed. Who am I targeting? In general I'm looking for companies that have outsourced their projects and want to keep an eye on the development to make sure they're getting their money's worth and to be advised of where things can go wrong. Many companies that undertake development don't have internal resources to review source code and rely completely on the outsource vendor. While many applications work, reviewing code can assist in polishing the code and possibly preventing future issues.

    What happens if your vendor fixes the issues and you want another review, I'll spend an additional 5 hours (at half price) re-reviewing the code. Are my services cheap? Well, no, but how much is your vendor going to charge you fixing their own mistakes? Software development is a unique business where we're paid to write the software and then fix mistakes (most projects I've worked on are on a time and materials basis).

    Why should you hire me? I've been writing handheld software for over 16 years (yes, I actually have as I wrote Newton software while I was still in college). I'm very meticulous and have seen enough code to know what is good and what is bad. Software can work, but some of the hardest problems to track down are caused by poorly written code. I can help resolve these issues.

    If interested, contact me. Of course, there are certain projects that I can't review, so I'll need a high level overview of your project before I can let you know about proceeding.

  • Can you spot the differences?

    Do you spot the differences between the 2 boxes below?

    newbox.pngoldbox.png

    If you don't, you're not the only one. My three and a half year old son saw the box on the left (these Trader Joe's Crushers are a staple in his diet) and said "It has 2 holes". My wife and I looked at him and didn't quite understand what he was talking about. He was clearly talking about the box, so I grabbed the old box and low and behold, the old box (on the right above) has one connected hole to display the product. The new box (the one on the left has 2 holes). While there are other differences that you can now see by looking at them side by side, I never would have paid attention to something like that.

    The mind of our son amazes me; he notices so many things that I ignore or simply neglect.

  • Another run in with Mail.app

    It seems that I rarely encounter issues with Mail hanging while talking to Gmail. Maybe I'm lucky, but it seems that my sister has more problems with the combination than anyone else I know. Today she called me almost panicked as her husband's machine wasn't getting mail. Turns out there were a number of issues contributing to the problem. The solution was relatively simple once I figured out the issue.

    The problems:

    • Too many messages in All Mail. There were over 37000 messages in the All Mail folder on Gmail, so when he selected All Mail, Mail happily started retrieving all 37000 messages (several gigabytes). This never finished.
    • Closing the computer kept restarting the process.
    • Corrupted IMAP cache directory.

    The solution:

    After a bit of searching I came across a reference to the .OfflineCache folder. This is a hidden folder in ~/Library/Mail/IMAP-nameofaccount/. You have to use Terminal to access it. Removing this folder (when Mail is not running) will cause Mail to start recaching the IMAP mail. This would unstick Mail, but the problem would come back once the All Mail was hit.

    I remembered that Gmail labs added some advanced IMAP options. I turned on Advanced IMAP options in Gmail labs. This brings up a few very important options.

    Safari.png

    Once that option is turned on (and saved), Forwarding and POP/IMAP has an extra option.

    Safari.png

    If you set the limit, Mail will at most show 1000 messages. This significantly reduces the number of messages that come down. Deleting the cache folder, setting this option, and then restarting Mail (and waiting a few minutes), cleaned up everything. However, there was one more option that I missed that would reduce that 1000 down to none (viewing All Mail in Mail is kind of a waste). Click on Labels and you can turn off the Labels that are shown in IMAP. Basically turn all of them off.

    Safari.png

    Presto! Problem solved.