Antagonizing Microsoft and its admirers has long been a part of my professional work culture. It’s easy to get a tinge of excitement when I see the giant stumble (ironic, given that I actually own some stock in the beast). But as I’ve matured (heh, heh, he said “matured”), I’ve come to know many people from Microsoft’s past, present, and I’m sure, future. And these people are passionate. They want to change the world for the better.

Microsoft is just a company, and yet its significance in the history of computing is so great, and its power over operating systems so daunting, that it’s far from being just a company. The company is a giant, figuratively and literally.

In his article, Be Microsoft, David Weiss expresses simultaneous love and disdain for the company he works for. In not so many words, it’s depressing to David that the giant lumbers around, fearful of all the smaller creatures surrounding it. So concerned is Microsoft with the competition, that it’s forgotten how to be itself.

I find David’s analysis to ring true. Grippingly true. It’s coming from the heart of Microsoft. The figurative heart, that is: straight from its precious employees. David’s blog is a perfect example of the thoughtful, well-intentioned self-criticism that I wish Apple would allow its employees to engage in more often.

The fear of anti-employee-blogging companies like Apple is that such off-the-cuff self-reflection might bode ill for the company’s public image. But posts like David’s only strengthen my impression of Microsoft as a company with character. A damaged character, perhaps. But one that is worthy of my consideration.

David draws parallels between Apple’s downturn several years ago, and Microsoft’s situation now. While David suggests that Apple’s recovery should instruct Microsoft about the value of “Being Microsoft,” perhaps Microsoft’s pro-blogging policies could teach Apple to “Be Human.”

Since I took over development of MarsEdit back in February, a lot has happened! I’ve released several bug-fix releases, and a modest 1.2 feature release, which added support for Growl, image uploads to Picasa for Blogger users, and early support for the Vox weblog system.

And of course, I heard feedback. Lots of feedback. MarsEdit users know what they want, and they’ve helped shape the priorities for the next major release of MarsEdit. And working on MarsEdit 2 is how I’ve spent a great deal of my time over the past few months.

I don’t want to give too many details away, because (crosses-fingers) things can always go wrong and features get pulled, but the release is starting to gel in some areas. Here is a sneak-peek at the new post editor window as it stands today:

(Click for full-size image)

Suffice to say, there are some features you can glean from the screenshot. The post editor window, and some other important parts of the user-interface, are being given a significant overhaul. I think most MarsEdit users will find it a refreshing cleanup, that manages to pack more features into MarsEdit without ruining its visual simplicity.

As for the complete feature list. Well, why don’t we wait until the features are actually complete :)

Some code is not meant to live forever. In particular, during development phases of projects, it can be very reassuring to know that a particular release of an application will have a short life-cycle, because you’ll be (relatively) assured that users aren’t accidentally running crufty old (development!) versions of the app.

The basic means of accomplishing this is to put a date check in your code that determines if a certain time has come and, if it has, refuses to run any longer. Anecdotally, I can tell you that lots of developers do something like this. But I can also tell you that lots of developers do it the error-prone, labor-intensive way. I did too, until I picked up a great tip from Brian Cooke a while back, that completely automates the process.

The laborious and error-prone method involves manually typing into your code a particular date in the future, and using that date as the test for whether or not to keep running. Brian’s brilliant observation was that the future date is almost always some number of days from “now,” where “now” is the date the code is being compiled. Using a gcc predefined macro, __DATE__, the code can know for itself when it was compiled, and build in an expiration date based on that value.

// Two-week expiration
#define EXPIREAFTERDAYS 14

#if EXPIREAFTERDAYS
   // Idea from Brian Cooke.
   NSString* nowString = 
      [NSString stringWithUTF8String:__DATE__];
   NSCalendarDate* nowDate = 
      [NSCalendarDate dateWithNaturalLanguageString:nowString];
   NSCalendarDate* expireDate =
      [nowDate addTimeInterval:(60*60*24* EXPIREAFTERDAYS)];

   if ([expireDate earlierDate:[NSDate date]] == expireDate)
   {
      // Run an alert or whatever

      // Quit!
      [NSApp terminate:self];
   }
#endif

By putting code like this in all of your projects, you have at your disposal a simple, error-proof way of releasing a build that will stop working N days from now. When you’re ready to release a non-suicidal version, just change the EXPIREAFTERDAYS preprocessor macro to 0. Nifty, eh?

PS: Thanks to Jon Trainer for inspiring this entry by thinking the idea was cool when I told him about it.

Update: Rosyna points out that dateWithNaturalLanguageString might be a dangerous method to use here, because it will implicitly use a different locale to parse the string, depending on the user’s language settings. Furthermore, the documentation for that method strongly discourages its use. Ironically though, the reason its use is discouraged, because it’s got a limited vocabulary and favors English, is probably just about right for parsing the date from GCC.

The GCC documentation describes the contents of __DATE__ as “eleven characters and looks like ‘Feb 12 1996’.” I’m not really sure how many locales this will or will not work correctly for, so I’m thinking the safe bet is to use a more explicit string -> date conversion format. I’m busy with something else right now but if anybody has a good capsule solution for this, please share it in the comments! Rosyna suggests offline that perhaps some POSIX date string formatter will do the trick.

If I wanted to program in a crappy language just so I could get more customers, I’d switch to Windows, not stinking JavaScript.

Pretty much sums it up for me, too. Wil makes this point and about a million other cutting and accurate remarks about Apple’s sloppy presentation of web development as an “SDK” for the iPhone. It’s a common theme among developers that we feel burned not by the lack of an SDK, but by the fact that Apple expects us to believe that this is one.

iPhone’s AJAX SDK: No, thank you.