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.

MarsEdit 3.1 is available now, and includes a number of changes for performance, compatibility, and ease of use.

MarsEdit 3.1 – Summary of Changes

• 64-bit Compatible
• New per-blog setting to constrain image media to pre-set size
• Support for Lightroom 3 media libraries
• Added new “Paste HTML Source” command for e.g. embedding YouTube easily in rich mode
• Enabled plugins for rich editor so you can e.g. see embedded movies
• “Send To Weblog” command now works when preview window is front-most
• Optional support for Google Data API 2.0 with Blogger
• Bug Fixes
  • Fix issue that prevented ejection of external media volumes
  • Fix some cases where the preview window could turn blank
  • Make sure changes to the preview template save to disk immediately
  • Restore functionality of “send post to blog” scripting command

In more detail…

Media Management Enhancements

Since MarsEdit 3.0, it’s been a lot easier to browse for images on your Mac to upload along with blog posts. But there are still many improvements that would make the job even more streamlined. By far the most common request I get about the media features in MarsEdit is that there should be some way to automatically limit the size of images, both so they don’t take so long for viewers to download, and so that they fit neatly into the visual layout of a particular blog.

With MarsEdit 3.1, just double-click the blog icon in the main window to bring up settings, and look under the “Editing” pane:

The constraints you specify here will apply whenever you select an image in the Media Manager “On Your Mac” section, or in the Upload Utility window. The settings can be overridden on a case-by-case basis, just type in a different size as you wish.

Another important change in the Media Manager is updated support for Adobe’s Lightroom 3, which was not compatible with previous releases of MarsEdit 3. I thank Pierre Bernard of Houdah Software for his contributions to the iMedia open source project, which made this possible.

64-Bit Compatible

For most users, it doesn’t make any difference whether a particular application runs in 32 or 64-bit modes. But for applications such as MarsEdit that use Apple’s WebKit framework, it makes a huge difference for one simple reason: Flash runs in its own process. When Flash crashes, as it’s sometimes known to do, it shouldn’t bring down MarsEdit along with it.

Another benefit of 64-bit applications is simply that, as more and more applications switch over to 64-bit, there will be less and less reason for the 32-bit versions of Apple’s operating system libraries to be loaded into memory. In a nutshell: the last 32-bit application on your Mac is the rotten egg that can’t share the libraries already in memory for the benefit of 64-bit applications.

Minor Features and Fixes

People are loving the new rich editor introduced with MarsEdit 3, but occasionally it’s necessary to paste in “raw” HTML text, even if you are in the rich editor. A prime example of this is embedding YouTube videos. When you copy the embed codes from a YouTube page, you used to have to switch to MarsEdit’s HTML text mode in order to paste them into a post. Now, just select Edit -> Paste HTML Source from the main menu bar, and your embedded YouTube movie should show up right there in the rich editor.

I also fixed a number of niggling details that were vexing some folks. I still have plenty to do, so it’s back to work for me. But I hope you’ll enjoy the modest improvements in this free upgrade!