• Archive your Mail inbox to a backup file and then delete your account out of Mail.
• Set up Mail to use your new GMail IMAP account and verify that it works.
• Import your backed up inbox to Apple Mail. This will create a new folder separate from your GMail stuff.
• This is the slow part. Drag about 300 messages at a time into your new GMail inbox folder. Mail will sync these new messages from your machine to the GMail servers while removing them from your import inbox. I had to go through about 3000 messages, so this took about an hour or so.

Your messages will appear in the GMail inbox in the correct date order, but if you sync with an iPhone, you’ll only get the most recently added 50 messages, which are most likely the ones you just imported and are quite old. To get around this, I found this technique in Google groups which worked like a charm:

In your inbox, select all messages (ALL, not just the first page!) Then give them a dummy label like “sort label”. Once you’ve applied this label only to the messages you want to be sorted in your inbox, select all inbox messages again and click “Archive”. This won’t delete your messages, just move them out of the inbox and into the “All Mail” folder. Once your inbox is empty, click on the label you made in the sidebar (e.g. click on “sort label”) to pull up those messages with that label. Then, select all (ALL) messages with that label, and in the drop-down menu above select “Move to inbox.” Once you do this, you can delete that label (it won’t delete your messages) and your inbox messages will now sort correctly on the iPhone.

Case in point: the initial settings dialog that’s presented when a user first loads our app. This dialog gathers the user account information necessary to login to our service. It also persists the information into our root.plist file so it can later be edited by the iPhone settings application (I hate shunting our users to another application just to edit login credentials, but that’s a rant for another time).

Our initial architecture put a simple “Welcome! Enter your information, etc.” sort of message at the top of the screen and a group-style UITableView below it with cells corresponding to each user credential item (username, password, etc.) When the user touched a cell, we pushed in an editing view that allowed them to set the credential item. The editing view consisted of a single UITableViewCell with an embedded UITextView, and the iPhone keyboard for text entry.

The user interaction worked like this:

• Tap an item in the settings dialog to edit
• The app slides you over to the editing view controller and displays the iPhone keyboard to do your editing
• Tap the Done button in the upper right when you’ve completed editing.
• The app slides you back to the settings dialog and displays your newly edited item

So this worked fine. It was solid, gathered the data properly and got the job done.

But it bugged me that there had to be so much moving around just to edit these couple of fields. When I would debug the app’s initial load experience, I’d have to blow away the app each time on the simulator to go through this process literally dozens of times. And sometimes I’d forget where I was in the process and type in the wrong credential. Sometimes I’d get so tired of the whole back-and-forth process, I’d hardcode credentials for the debugging session just to avoid having to enter into the dialog at all.

Warning bells. This was a point of friction in the interface. A small point, but frustrating for me. True, I was going through the process dozens of times, but it still bugged me. If I was having these issues as the developer of the application with a debugger in front of me, our users would be guaranteed to have issues. Not showstopper-type issues, but I’d hear about it.

So I took a few hours yesterday and did something about it. I decided that our screen should work almost exactly like the iPhone settings app—if a user interface works and works well, copy what it does.

I reworked the editing mechanism. Gone is the movement to a separate screen for editing. In it’s place are text fields embedded in the table view cells that are activated when the user taps a credential item in the initial screen, allowing for in-line editing of this information. This brought up a second problem. When the user tapped on a field toward the bottom of the screen and the iPhone keyboard was displayed, the keyboard hid the field. This was a stumper. No amount of calls to selectRowAtIndexPath:animated:scrollPosition: would work. Finally, a bit of googling revealed this gem by Matt Gallagher to get me over the top. The view would now automatically scroll to display the selected field if it was occluded by the keyboard.

So the final result? Let’s check out the user’s interaction with this dialog again:

• Tap an item to edit
• iPhone keyboard slides up and you edit the item
• Hit return or select another field to continue, or hit the “Save” button to exit the dialog altogether

That’s around 1-2 fewer steps, with the added bonus that users have a very clear context in their minds of what they’re editing—something which they didn’t have when they were forced to another screen each time to edit a simple text field.

I never would’ve done this with a desktop application. It wouldn’t have been an issue. Need to gather user information? Put together a dialog with the correct number of text fields, some labels and an OK button and you’re done. Not enough real estate? Resize the canvas.

Not so with the iPhone. Since the platform is so limited, the thought you put into an interface affects your users an order of magnitude more than it would on a desktop app. It’s a bit like a fractal—the deeper you think about your user’s interaction with your app, the more interaction scenarios you uncover, the more code you write to handle these interactions, the more rewarding your app is to use.

Exposure to more than one platform and language

If your only experience is with one language on one platform (i.e., perl on Linux, C# on Windows, etc.), this is a signal to me that you're inflexible and not willing to stretch yourself to do new things. It's definitely uncomfortable to do try new languages and OSes, but that's the only way to stretch yourself and get better.

Exposure to pointers

Lack of exposure to pointers is one of Joel's pet peeves and I've adopted it as one of mine as well. Where I went to school, Java was the language of choice for freshman year CS courses. This was a bad decision since the first sophomore year course was Architecture and Assembly language, something which Java does precious little to prepare you for.

When I first started in industry, my first language again was Java and then C#. Another bad experience, since this left me with a rather steep learning curve for my next experience, working with low-level C++ code on HP-UX. But, to tie in with my previous point, I specifically went after this position because I saw a gaping hole in my experience and wanted to fill it in. And I'm much better off for it. I'm confident with my feel for how memory is being managed and manipulated during the course of a program's execution, be it managed, unmanaged, embedded or desktop.

But I sure wish I'd had the low-level introduction to C in my first year as a CS student.

Exposure to things that are not code

I'm talking about documentation, gathering requirements, interacting with users and customers, creating a design document or diagram. These are the things that you will most certainly not learn in college, and they're definitely not as fun as just coding all day, but they're essential to being anything more than a coding monkey.

There's probably more that I'm forgetting, but if I'm going to interview you or be interviewed by you, these are the big things I'm going to be looking for besides competency with your hard skillset.

• Krispy Kreme: Famous for their hot glazed donuts and nothing else really. They possess a light, airy texture and aren't overly sweet or doughy.
• Dunkin' Donuts: Basic donuts for when you're in a bind and need one quick. Not a lot positive to say here. Cakey, mass-produced and not very good. My personal favorite is their jelly, which is usually pretty generously filled and covered with a healthy dose of powdered sugar. I really wish Dunkins would divert some of their resources from developing new 1000-calorie monster flatbread sandwiches to developing a better donut.
• Honey Dew: See Dunkin' Donuts
• Grocery Store Donuts: Don't. Just...don't.
• Top Pot Doughnuts: My current favorite. They started offering these at Starbucks a year or so ago and quickly ascended to the top of my list. When consumed cold, you're basically eating a rock, but a warmed-up Top Pot is something to savor. Plenty of texture, and very filling. Their chocolate glazed leaves something to be desired, however. It lacks any sort of chocolaty flavor and tastes more like their plain glazed version only...off somehow.

Still on my list to try: About a million mom-and-pop donut places in greater Boston, including Verna's in East Boston.

It’s somewhat disturbing for me to think that the young people of our country can’t do basic math, but then they sky seems to be falling on our mathematics education standards with the start of every new school year. I wonder if I should start administering a basic math skills assessment when I interview potential engineers.

The basic problem here seems to be lack of class time. The meteorologist in the video states that children don’t receive enough teaching on the basic algorithms of mathematics—how to perform double digit multiplication, long division, etc. The curriculum she rails against instead teaches more abstract approaches to solving these problems—breaking down a long double digit multiplication into smaller pieces and then adding those pieces up, for instance.

I’m of two minds about this, as with most things. I agree that not teaching children so that they can evaluate math problems mechanically with a foolproof algorithm so that they can be guaranteed to arrive at the correct answer seems to be a mistake. It’s creating a culture where nobody can do arithmetic anymore without a calculator and that clearly isn’t a good thing.

On the other hand, only knowing how to mechanically solve problems doesn’t prepare children for the inevitable moment when they encounter a problem that doesn’t fit into the algorithm, a problem that requires more analytical, critical thinking. I solve both types of problems every day as an engineer, and we need people who can handle both.

So. This is something of a departure for me, coming from a mostly C++/Java on Windows background, but this is also an opportunity to develop new skills and learn a platform that will be invaluable in the coming years. Here are my initial observations:

• Xcode is just plain awful when you compare it with Visual Studio. It’s clearly a far more immature product and it shows, from the brain-dead window management philosophy to the debugging tools to the keyboard shortcuts. Don’t get me wrong; I’m not whining because it’s different. I use vi for half my day when I’m coding on my Linux VM and get by with minimal fuss. I’m whining because there are clearly established UI standards for IDEs and for editors that have been proven over the years and Xcode just ignores them, doesn’t implement them or takes a completely different and wrong direction.

• Interface Builder is…OK. It’s a different UI design and layout mechanism than I’m used to, but once you grasp how the controls you’re laying out in a NIB/XIB interact with and are represented by the objects in your code, it’s pretty painless. I don’t like having to drop into another app every time I want to tweak my UI however.

• The supporting platform libraries and API are likewise just OK. Cocoa Touch brings over almost everything you would want from regular Cocoa, with the notable exception of a few selectors (why doesn’t [NSDateFormatter initWithDateFormat] work?). However, I really, really wish they’d ported Core Data or a subset thereof. My data-driven app would be about half the size and would have been done weeks ago. I think I understand why Apple chose to exclude CD from the iPhone API—it’s a behemoth and performance might have been unacceptable. But I spend way too much time writing sqlite database glue and plumbing code and it’s a bit frustrating.

• Objective-C is fun. I enjoy the dynamic nature of the language. I suspect I’ve made the inexperienced ObjC developer mistake of abusing categories, but I’ve put a few on NSString and NSDate and they’re just so useful I don’t see how you can’t get by without them. The release/retain memory management approach also takes a bit of adjustment but it’s not without it’s merits. I’m not sure if I wouldn’t rather trade a few CPU cycles for a garbage collector however—maybe I’m just lazy.

Given these criticisms, you might gather that I’m somewhat down on the platform, but my overall experience has been quite to the contrary. It’s been a pleasure, and part of the reason why is that it’s so easy to create a polished, professional UI that just looks like it belongs on my iPhone. This is due to the tools Apple gives you—the default controls, views and behavior you get out of the box put you on a straight path to a nice UI. You don’t get it for free; you have to constantly tweak and work at it, but compared to Windows Forms or MFC, it’s like night and day.

Let me say this more clearly: It doesn’t matter how pristine, well-architected and beautiful the code supporting an app is—if the UI isn’t intuitive for your users or is so obviously different from the rest of the platform and it’s standards that using your app becomes a jarring experience, you’ve failed. This is where the iPhone SDK shines and why I’ll be actively developing for it in the future.

One aspect that I find merits further thought is this notion of duck typing. What is duck typing you say? I'm glad you asked. It boils down to this oft-used analogy:

If it walks like a duck and quacks like a duck, I would call it a duck.

That is to say, if the object I'm working with behaves like an instance of a duck, it's a duck for all intents and purposes. Or, more bluntly, invoke whatever operation you want on an object, as long as it says it can do it. But what does this get us? It's not immediately obvious that it's all that quicker to code with these looser typing restrictions. Consider the following C++ function:

class Duck
{
    public:
        virtual string Quack()
        {
            return "Quack!";
        }
};

void QuackLikeADuck( const Duck& aDuck )
{
    std::cout << aDuck.Quack() << "!" << std::endl;
}

And now the same code in Ruby:

class Duck
    def Quack
        return "Quack!"
    end
end

def QuackLikeADuck( duck )
    if duck.respond_to?("Quack")
        puts duck.Quack();
    else
        raise "Called with an invalid object type"
    end
end

The Ruby version seems a bit more verbose, but this is a contrived example and I would concede that the sort of type checking in that function wouldn't always be necessary. If you're the only one using that code, you can make certain assumptions about those objects that will be passed into that function.

But where this sort of agility really shines is in it's dynamic nature. What if my application now demands the introduction of a Human type, but for some reason it needs to quack like a duck too? Consider the C++ approach:

class Human : public Duck
{
    public:
        string Quack()
        {
            return "Ceci n'est pas un duck!";
        }
};

A brittle class hierarchy to be sure. To be able to use the QuackLikeADuck as originally declared, I've been forced to have my Human subclass Duck. What if a previous class hierarchy had already been established and there were other classes that needed to QuackLikeADuck too? Sounds like a long of afternoon of refactoring and unit testing to me.

Now look at the Ruby approach:

class Human
    def Quack
        return "Ceci n'est pas un duck!"
    end
end

And that's it. No tortured class hierarchy, no tedious error-prone refactoring. Just add the method and you're good to go.

I'm of two minds about this flexibility. On the one hand, it allows you to get things done much quicker and not sweat the object-oriented design cruft that can so often pollute a design when requirements change. On the other hand, it puts a lot of responsibility on the developer to correctly anticipate ways in which their code might be used and to handle error conditions gracefully (a tall order for some developers I've encountered).

Which brings us back to the title of this entry. This has all happened before and it will all happen again (Battlestar Galactica was on last night). I would argue that for most of the 90's and the early part of this decade, strongly typed languages were in vogue (C++, Java, .NET, etc.) Right now, the hip language paradigm pendulum has definitely swung to the dynamic typing side (Ruby, Python, PHP). But for me, it doesn't really matter. Strong typing, dynamic typing, it's all the same--I'll just choose the one that let's me get my job done quickly and easily and right now that's looking a lot like Ruby.

So I took some time this morning to stroll down memory lane and see how far my programming skills had progressed since then. I decided I would code up a little Mandelbrot set plotter using Windows Forms. It took me about two hours of Googling and Wikipediaing to get here:

This was already further than I ever got in high school--we didn't even have color screens back then.

I realized that this was pretty dull without a zoom feature, so I implemented a little zoom box that you can set by clicking and dragging on the fractal. Then I realized I have a dual-core laptop, so why not parallelize the code a bit? Fractals are perfect for this sort of thing--there aren't any data dependencies so synchronization isn't much of an issue. I moved the actual fractal calculation code to a thread and parametrized the coordinate window it would draw so I could render it in two threads (one for the left half, one for the right). I could subdivide the coordinate window as much as a I wanted depending on the number of cores on the machine, but that's a project for another day. Also, I set pixels directly in a Bitmap object in the calculation thread, so there actually is a little bit of locking there that could probably be optimized away (because we all know how expensive a lock is, right?)

But I digress. My point is, this is what's so fun about a project like this. It helps to keep your love of programming alive when your day job is burning you out. I could optimize and tweak this thing for weeks. Why not implement the calculations as integer math and see if it's any better than the default floating point code? What about checking for periodicity and bailing out early? How about customizable color maps? Different fractals? Real-time zooming? How do we provide progress feedback to the user on a long render using multiple threads? The options are endless and I probably just lost my whole weekend to this thing. Sounds good to me.

Saying this is problematic to maintain would be an understatement. With no unit tests, or any tests at all (except loading it up and making sure it doesn't format the hard disk by accident), regressions are a very real possiblity and happen far too often. 

This being said, we're limited in our options of what to do. We can: 

• Stick it out, leave it be and continue on course to a code armageddon. Not my favorite option.
• Scrap the applications altogether and rewrite them in C# or Managed C++. Not really a good option either since, as bad as these apps are maintenance-wise, they do very complicated jobs somewhat well. We'd be lucky to code up a new app in six months that does 1/4 of what they do now. Fun for developers, bad for business. 
• Keep the codebase as is, but roll in .NET on a feature-by-feature basis. This is the best of both worlds--we keep our legacy code and all of it's (mostly working) warts, but are able to introduce .NET here and there with an eye to eventually replacing all of the legacy code with .NET in a few years. 

Can you guess which choice we're going with? The silver bullet here and the reason we're able to do this is a magical language I call Managed C++. Microsoft has done plenty of evil things (or so I read), but the interoperability of Managed C++ with legacy code is not one of them. 

Since these apps are all MFC, we're able to load them up in Visual Studio 2005 (moving from VS6, itself a rather painful transition we made last year), throw the /clr compiler switch and, after a fixing a few compiler errors (mostly due to not using the _T macro with strings as much as we should) we automagically have support for the CLR in our app. 

The first thing I'm doing is implementing a C# User Control for inclusion on one of our data entry forms. This is a pretty simple thing to do. You just drop a static control on your form where you want the User Control to go and create a data member in your dialog class like so:

class CMFC01Dlg : public CDialog
{
    // ...
    // Data member for the .NET User Control:
    // (note: ctrl_lib is a user created control assembly)
    CWinFormsControl<ctrl_lib::usercontrol1> m_ctrl1;
}

Then, in your ::DoDataExchange method, just add the following:

void CMFC01Dlg::DoDataExchange(CDataExchange* pDX)
{
    CDialog::DoDataExchange(pDX);
    DDXManagedControl(pDX, IDCCTRL1, m_ctrl1);
}

Congratulations, you now have a .NET User Control on your MFC form with about 6 lines of code. 

The point here is that very often there's a way to keep your legacy code while also transitioning to newer technologies. It may not always be easy or particularly fun, but your customers will thank you and so will your company.

• I can work in blessed silence all day long
• I can play my music as loud as I want
  
• I can change my venue when the mood strikes me--Starbucks, the Library, Quincy Market, wherever, so long as I can get a network connection.
• I don't need to worry about when I arrive in the morning or leave at night. As long as my stuff is getting done and it works, we're all good (within reason of course--if I get something done two weeks ahead of time, I can't take two weeks off of work)
  
• I don't have to drive anywhere. If I need to go into the office (on the rare occasion I do), the T is nearby.

• It's isolating. I have weeks where I don't leave my apartment complex.
  
• Communications can be a problem. We work via email and IM, with the occasional voice chat and desktop sharing session when things get too complicated to explain via text. This works relatively well, but there are definitely times when I wish we were all in the same office and I could just pop into someone's cube or office instead of sending them an email and waiting potentially hours for an answer.
• I haven't really gotten to know the rest of the company. Remember when I mentioned the support and sales folks above? I only know their names from email and when I see people in the office, it can be somewhat awkward. You can't really develop the kind of relationships you sometimes need in an office to get things done.

class SomeBigClass
{
    private:
       HelperClass *m_pHelper;
       ImportantPointer *m_pImportant;
    public:
       ImportantPointer *GetImportantPointer()
       {
           return m_pImportant;
       }

       SomeBigClass() 
       {
       	   m_pHelper = new HelperClass(this);
	   m_pImportant = new ImportantPointer();
       }
       
       void DoSomethingInteresting()
       {
           m_pHelper->DoSomethingHelpful();
           m_pImportant->DoImportantOperation();
       }
}

HelperClass::DoSomethingHelpful()
{
    // blah blah blah
    // ...
    delete m_pSomeBigClass->GetImportantPointer();
}