MarsEdit users sometimes sheepishly admit that they aren’t blogging as much as they “should” be. Excuses vary, but it usually boils down to the classic issue afflicting all of us who try to stick to a productive routine: we simply fall out of the habit.

Long time readers of this blog will note that I’ve had my dry periods as well. But watch closely: I’m blogging now about a thought I had just earlier this evening, while reading Twitter updates and responding to them. Colin Barrett complained that his perfectionism is limiting his blogging:

I plan to write more; I think my @secondconf talk on freelancing would work well as a series of posts. Just gotta get past my perfectionism.

I’m incredibly familiar with this line of thinking. In fact, it’s a variant of the indefinitely postponed software releases that I just wrote about. I read Colin’s tweet and, before I had even noticed that the neurons in my brain were firing, I had responded with a bit of encouragement:

@cbarrett The modern business model for solo writing is to blog your first draft and sell your final.

I’m referring to the fact that very few blogs are edited to the level of professionalism you might find in literary or scientific journals. On the contrary, some of the web’s most celebrated bloggers have let their essays loose in a semi-rambling form, only to piece them together later into a more refined, salable volume. Rands in Repose and Joel on Software spring to mind in the techie world, while writers such as Heather Armstrong and Julie Powell turned their respective parenting and cooking blogs into million-dollar enterprises.

The ever-so-thinly veiled message? Don’t worry so much. Just blog it. If you are among the lucky few who achieves perfection effortlessly, then by all means carry forth. The rest of us are lucky if we coerce a unit of coherent thinking out our brains and onto the web. Perfectionism? Your editor will help you achieve it after you’re famous.

When I introduced the rich HTML editor in MarsEdit 3, I knew there would be some issues. WYSIWYG editing is freaking hard. I don’t pretend to have started out an expert, nor have I become one. I’m getting there, though!

I decided to release MarsEdit 3.0 when I did because of what I refer to lovingly as my “suck it up and ship” mantra. I tell other people all the time that you can’t hoard your work. Sure, putting off the ship date indefinitely will allow you to avoid the embarrassing critiques, the discovery by the public that you are in fact imperfect. But you know what? They never get to try out your app, either.

The customer-developer feedback loop is exceedingly important when it comes to prioritizing bug fixes. The months you spend “perfecting” your stuff will undoubtedly focus on parts of the app that your users don’t even, as it turns out, give a damn about. Get your 1.0 (or 2.0, or 3.1.2) to users as quickly and responsibly as possible, and evaluate the results.

On that note, MarsEdit 3.1.2 is available today, fixing an issue in the rich text editor that, suffice to say, is far more than a “minor glitch.” In a nutshell: if you did a “search and replace” where the replacement text included the search text, the app went into an infinite replacement loop, hung, and required a force-quit.

That is so not Red Sweater. Yuck! I discovered this thanks to my new (as of 3.0) crash reporter that, while providing precious few details about the reason for the force-quits, eventually included key feedback from a user who offered the hints as to what was happening.

I hope this release cuts down dramatically on the number of mysterious, context-free crash reports. There are some other goodies, too:

MarsEdit 3.1.2

• Fixes for issues with Find/Replace in the rich editor
  • Fix a potential hang when doing replace all
  • Fix “Use Selection for Find” menu item
  • Fix behavior of “Replace All” when limiting to selected text
• Fix a bug that prevented “None” from sticking as preview filter choice
• Fix a bug that caused wrong alt text to be generated for some uploads
• Prevent ugly clipping of font descenders e.g. on lower case “g” in Media Manager

Here’s to the next imperfect release!

Jeff LaMarche presents a rundown on whether Objective-C dealloc implementations should bother nil’ing out an instance variable after releasing it.

LaMarche offers a fairly balanced presentation of the two sides, but in my opinion he gives too much credibility to the argument that nil’ing is a good idea. He essentially embraces the argument that nil’ing the variables in production code is wise, because it might mask crashing bugs that would obviously vex the user:

Generally speaking, this is only going to happen if you’ve got a bug elsewhere in your code, but let’s face it, you may very well. Anyone who codes on the assumption that all of their code is perfect is begging for a smackdown.

And speaking specifically about the approach I prefer, leaving the instance variable alone and not bothering to nil it out:

On the other hand, that approach is really, really bad in a shipping application because you really don’t want to crash on your users if you can avoid it.

I disagree with the assertion that avoiding crashes at all costs in shipping code is the right priority. The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways. Sure, we all make mistakes as programmers, but giving in to the chaos and putting up safety nets “just in case” is not the right approach, especially considering it has unwanted consequences.

Consider that by masking the crash from occurring in the wild, you may be putting off detection of and resolution of the underlying bug indefinitely. But if your application has a crash reporter, or if you take advantage of Apple’s iOS crash reports, you will learn quickly that there are issues needing to be resolved.

It is reasonable to take steps that mask mysterious crashes, but this should only be done after you know there are actually crashes to prevent. Masking the symptoms in a blanket manner is akin to cutting half the phone lines in the neighborhood and celebrating the reduced number of 911 calls.

It’s also worth noting that LaMarche’s defense of nil’ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways. Consider this incredibly contrived Cocoa-based nuclear arms controller:

if ([mDiplomat didReturnGestureOfPeace] == NO)
{
 	[[NuclearWarehouse nuclearMissile] launch];
}

By LaMarche’s reasoning, it’s a good idea to nil out the mDiplomat variable on release, so that it won’t crash when you message it. But in this case, messaging nil for a BOOL result causes a logical flaw in the program, with obviously dire consequences. If the instance variable were not set to nil, it would probably crash before the launch message could ever be sent.

We should aim to comprehend what our software actually does. Deliberately decreasing the symptoms of problematic code won’t lead us any closer to that understanding. Ship the best code you have to your customers, and if it crashes, try to fix the root cause of the crash as quickly as possible. Don’t get in the habit of writing “hope this fixes it” code, and by all means don’t adopt that philosophy as a boilerplate coding habit.

I’ve been in and out of Apple’s iPhone simulator for the past two years, and for the entire time, I’ve been frustrated by what I assumed was an inherent limitation: pinching and zooming and only works in the middle of the screen:

Today I was so supremely frustrated by this that I played around with all manner of double-clicking, alternate modifier keys, etc., until I stumbled on the simple solution. Googling for answers after-the-fact revealed that I’m by no means the first person to discover this, but it’s quite possible I’m the first person who has told you!

To zoom in on an arbitrary point with the iPhone simulator:

1. Hold down the option key to obtain the familiar “simulation fingertips”.
2. Move the mouse until the fingertips are the desired “starting width” for your gesture.
3. Keeping the option key pressed, hold down the shift key to enter “panning” mode.
4. Move the mouse until the fingertips are at the desired starting position.
5. Remove the shift key while continuing to hold the option key.
6. Click and drag to zoom in or out at the selection location.

It’s a little cumbersome, but it’s about 1000% more useful than not being able to do it at all.