I followed an interesting link from Daring Fireball, relating to recent debate about WikiLeaks. Nelson Minar reaffirms the often-stated aphorism, apparently attributed to Stewart Brand, that “information wants to to be free.”

I think this is a useful way of thinking about it, but it’s insufficient for describing the way that information actually travels. Even taking to heart Minar’s reminder that information can’t strictly “want” to do anything, the suggestion that it even tends toward or prefers freedom is not accurate.

Information is like water: it wants to be everywhere. Unlike say, a person, who will almost universally want to be free. Information in a cage will not rattle the bars, or scramble frantically to reach a just-too-distant key. On the contrary, information is happy to occupy every corner of the cage, and yes, given an opening, to seep out of the cage as well.

This is truer than ever in the digital age. As individuals we have more capacity than ever to stash away information for our own private use. And we relish it. Consider your private computer archives with their thousands of photographs, unfinished stories, poems that nobody will ever read, and bookmarks that nobody will ever visit. Information is as content to live on the front page of the New York Times as it is to occupy several square millimeters of hard disk surface in a Backblaze server farm.

For every person who wants to shout information from the rooftops, there are probably twenty who want to keep a nice private stash of it for their own enjoyment. The presumed motivation for information to be either public, private, or undiscovered is imbued by the people who care most deeply for it. Perhaps in this light the truly earth-shattering, profound information does want to be free. But by default, information wants to be everywhere.

Relatively hot-on-the-heels of the previous release, MarsEdit 3.1.4, fixes some major memory performance issues and includes some fixes that streamline integration between Tumblr photo posts and the media manager.

Major Memory Meltdown

I have always been pretty proud of my ability to manage memory usage in my code. In addition to using good programming habits, I periodically run Apple’s memory leak-detection tools, and the clang static analyzer. These tools do a great job of finding accidental memory management errors. But as I discovered, they are not enough.

For months I have received anecdotal feedback that MarsEdit is using more RAM than it should. But I couldn’t find any evidence of wrong-doing on my part, so I committed a major mistake: I just assumed it was normal. MarsEdit uses a lot of Apple’s frameworks, including WebKit, which is so big and expansive, I assumed there was something about the degree of WebKit I use in MarsEdit that explained the large amount of memory consumption.

Wrong! I was inspired by a recent one-two punch of feedback, combined with a recent blog post I had read, to dig deeper.

Twitter user @Fletcher_Chris was exceedingly polite when he asked if MarsEdit’s 200+ MB memory usage was “normal.” Ugh! Normal? I don’t know? I think so? Not knowing about why your software does what it does is a major alarm bell.

Then my friend John Gruber wrote to let me know that not only is he noticing major RAM consumption, but that it’s something that has bothered him for some time now. A recurring, nagging issue, noticed by somebody who is technically competent enough to know a real issue from a false one. I have a problem on my hands.

It was lucky timing that my friend Bill Bumgarner recently published an article on the very subject of hard-to diagnose memory leaks. I had actually read this article, enjoyed it, and blithely assumed it didn’t apply to any of my current software challenges.

It turns out that MarsEdit was in fact suffering from exactly this kind of leak: one that the brilliant leak-targeting tools from Apple are not able to detect. For a variety of reasons mainly involving retain cycles, I was neglecting to clean up after a major part of the MarsEdit post editor’s user interface, which means that every newly created and closed document would leak hundreds of KB of RAM.

Mea fricken culpa. Fixed in 3.1.4.

Tumblr Photo Posts

Tumblr has been a major challenge for MarsEdit because of the degree to which it doesn’t follow the usual paradigm for media management. This means in a nutshell that things you can do with almost every other blog system are not possible in Tumblr, making the user-interface a little clunkier to handle. In particular:

1. Tumblr does not allow direct file uploads. Even though their web-based UI allows you to upload an image for direct insertion into a post, this is not something they have exposed for remote clients such as MarsEdit.
2. Tumblr supports the notion of a “Photo” type of post, but it takes at-most one single photo. Usually MarsEdit is happy to add as many photos as you like to a post, but with Tumblr it has to be limited to one, and requires that the post type be switched to photo.

In MarsEdit 3.1.4, I take baby steps towards improving the situation when users do want to publish photos to a Tumblr blog. First, the per-blog “image constraints” settings are now applied to Photo posts on a Tumblr blog. So if you’ve got it set to limit posts to no more the 400×400 pixels, it will apply to any photo you drag in to Tumblr’s photo well.

I also streamlined the experience when choosing a photo from the Media Manager for a Tumblr-style post. Not only will the image constraints selected in the Media Manager be applied to the photo, but for example selecting and inserting a photo will automatically set the photo for the open Tumblr post document, or create a new post if one is not already open. This should make the photo-blogging experience on Tumblr a lot smoother.

A Curious Lack of Crash Reports

Since MarsEdit 3.0 was released, I have included a crash reporter mechanism that will automatically notice when MarsEdit quits for any unexpected reason, and offer to let the user send me a crash log plus any additional information they choose. This has been a great tool for measuring the number of harder-to-find bugs that remain in MarsEdit, and for zeroing in on and fixing some of them.

Luckily, the flow of crash reports is a relative trickle, compared to the number of users running MarsEdit on a daily basis. But after MarsEdit 3.1.3, the crash reports all but dried up! Was I really so brilliant as to accidentally fix any remaining bugs in the application? 3.1.3 forever!

No, what actually happened was I was brilliant enough to break the crash reporter in 3.1.3, so that it would fail to present the dialog to users offering to send in the report. Crashes were still happening, I’m sure, but I wasn’t hearing about them. Now fixed in 3.1.4, and I’m anxious to get back to monitoring the pulse of MarsEdit stability with this great feature.

When I first started working at Apple, I was 18 years old. I was going to school at UC Santa Cruz and studying to be a computer programmer. Like my dad.

I was lucky to end up as a Quality Assurance tester inside a software development group at Apple. I worked for the Software Update team, which was essentially responsible for diagnosing, evaluating, fixing, and shipping bug fixes for anything in the System 7.5.x era software that Apple was building at the time.

I was so bold back then that I told my bosses, and my bosses’ bosses, and my peers, and anybody who would listen that I wanted to be a programmer. I wanted to write Mac software. No, I wanted to write the Mac!

That dream came true on May 13, 1996, when I joined Apple as Software Engineer I in the System Updates team for Mac OS Engineering. I immediately went to work, fixing bugs here and there as fast as I could. I took copious notes, in an effort to assure my bosses that I was the right person for the job. How did I spend my time over the past 5 minutes? I could happily elaborate.

I was so nervous about my performance, so worried that somebody might notice I was a fraud, that I didn’t ask for help as much as I should have. When somebody assigned me a problem, I scraped the walls of hell to find the answers, lest it be revealed that I wasn’t quite as smart as I might have seemed.

All the bugs in our group were difficult. One day I was assigned a particularly vexing one. I had shown a knack for tracking down tricky issues, but this one stymied me. I hammered away at the bug but I couldn’t figure out the cause. I couldn’t even think of where to go next. I was petrified. This was it, they would learn about my incompetence and put me out to pasture. I decided to take a walk.

I clearly remember that balmy summer day in Cupertino. I was filled with dread. I walked from Apple’s Infinite Loop headquarters, across Highway 280 on De Anza boulevard, towards the expansive suburban doldrums of Sunnyvale.

My pre-hire boldness had abandoned me. “Maybe I should quit,” I thought to myself. “That would be a stoic way of getting out of this mess.” It sounds so dramatic in retrospect, but I was so sure of my failure, it seemed like an obvious move at the time. I talked myself through the facts of the bug in question, and simply could not think of a solution. I couldn’t think of a part of a solution. I couldn’t even think of a step in the direction of a solution.

I walked for an hour or more, and then returned “home” to my office at Infinite Loop. I sat at my desk and stared into the monitor, hoping against hope for some inspiration. My friend and coworker, Darren Litzinger, stopped by my office.

“What are you working on?” he asked.

“I have a terrible bug, and I can’t figure it out.” The thought of asking for help didn’t even cross my mind. But fortunately, my frustration spoke on my behalf.

Darren sat down in my guest chair and adopted an excited look. “Well, what do you know about the bug?” He was here to help. I hadn’t even asked for it, yet here he was. I could have asked for it at any time, and I didn’t even realize it.

Talking through the bug with Darren, he asked me to perform particular tests at the computer. I realized that we had completely different approaches to problem solving. It wasn’t that his were right or that mine were wrong, they were just different. As it turned out, his technique saved the day and we got to the bottom of the issue within a couple hours.

As I moped along De Anza Boulevard that afternoon, I thought that I might not be cut out for software engineering in general, let alone at a world-class company like Apple. After I retreated back to my office and got a surge of help from a trusted colleague, I realized that I was perfectly qualified for the job. Especially if I could ask for help every once in a while.

MarsEdit 3.1.3 is out and contains some “finally!” bug fixes, as well as a relatively major shift in the way that Google Blogger type blogs are configured by default.

Improved Rich Text Paste

As I have said before, the Rich Text editor in MarsEdit, as incredible as it is, is a work in progress. One of the things many people have reported since MarsEdit 3 came out is that it can be particularly irritating when it comes to pasting text. Often extra paragraphs would be inserted, and things just seemed generally unreliable. I’m not promising perfection yet, but I think you’ll find it a lot cleaner starting with this update.

Communicating With Blogger

For years, MarsEdit has communicated with Blogger using its standard “Google Atom” interface, which was developed in tandem with the standard AtomPub protocol. Over the past couple years, they have been working on a newer version of the interface which aims to be more compatible with the AtomPub standard. MarsEdit started supporting this in release 3.1.2, and starting with 3.1.3, “Google Data Protocol 2.0” will be the standard means of communicating with Blogger.

The big win for users with this change is it should lead to more reliable preservation of HTML markup in your posts. But I don’t want to jump the gun and shift everybody over to it just yet, so I’m only defaulting newly configured Blogger blogs to use the new protocol for now.

If you’re feeling adventurous, you can switch your previously-configured Blogger blog to use the new protocol. Just open up the blog settings in MarsEdit, switch to the “General” pane, and select “Google Data Protocol 2.0” from the System API popup. Then refresh your blog to make sure you get a fresh copy of all your recent posts.

Local Draft Duplicates

One of the major annoyances people run into with MarsEdit is a creeping number of extra draft copies in the “Local Drafts” area. I have been tackling this problem for years, and I think I finally found one of the last, if not the last cause of the problem. If you’ve been running into this, delete all the cruft now and hopefully it will stay tidier going forward!

Change Log

Most of this was discussed in detail above, but in case you want a definitive list of the user-facing changes that come with 3.1.3, here it is!

• Improvements to paste functionality in Rich Editing mode
• Avoid a bug where saved local-drafts were not deleted after publishing
• Fix a bug that caused custom field values to go blank while editing a post
• Blogspot-specific changes
  • Newly configured blogs now default to GData 2.0 protocol, fixing some HTML formatting issues
  • Fixes to GData 2.0 protocol to allow edit date, categories, etc.