Noodlings

Just a little heads up. The Infinite Loop folks at Ars Technica were kind enough to interview yours truly. Check it out.

I’ll say up front that I’m skeptical of this whole Twitter thing. Instead of me being a grump about it though, I’m trying an experiment. I put up a profile for Hazel for those who can’t resist getting micro-updates on what’s going on with Hazel. If you want to see what’s going on with development or other related news doled out in little SMS-sized chunks, then check out user Noodle_Hazel .

Hazel’s not the only Mac software on the Twitter circuit. Recently acquired MarsEdit is already there. And if you want Twitter updates on your desktop, there’s Twitterrific.

So, we’ll see how it goes. As always, comments and suggestions are welcome.

As I’m sure you’ve heard by now, Red Sweater Software has acquired MarsEdit. A big congratulations to Daniel Jalkut.

There are a couple great things about this. First off, MarsEdit will continue to be actively developed. I think this shows a real commitment to making the users happy. I know a lot of companies who would just keep their marbles but it’s great that NewsGator realized they could not support the product and let someone who could take over. Secondly, I think it’s a big deal that a small developer got it. I feel NewsGator could have sold it for more money to a bigger shop.

I’m not privy to the details of the deal but from where I’m sitting, it looks like a deal that was less concerned about the bottom line and more focused on working out something that was best for the developers (on both sides), users and the community at large. Looks like it’s in good hands now.

My graphic designer is working on a menu bar icon for the next version of Hazel. The problem is that it’s hard to visualize them in situ. To aid my designer in this regard, I threw together a quick little proggie. It’s just a simple program that has a menu bar icon. It provides a controls where you can edit NSStatusItem settings as well as image wells into which you can drag icons. The status item updates so you can see your icons in their natural habitat.

I also added an image well where you can test out app icons to see how they look in the dock.

Source (what very little there is) and binary included. MIT license. Valentine’s Day has passed but it’s never too late to show your designer a little love.

Download: Status Item Tester

Over the years you learn a few lessons and make a few rules. You swear to yourself that you’ll always follow them but over time you get lazy or you just forget. Especially when debugging, you get in that panicky state where all that goes out the window. Urgency beats out common sense.

Usually when you find a crasher, you end up going at it head-on, in a brute force manner. Run it through the debugger. Carpet bomb the code with log output. Bang your head against the desk. Rinse. Repeat.

The lesson here is obvious (maybe painfully so) but I don’t see it applied enough in practice. I find that it’s commonly forgotten in the heat of the moment and is only heeded as a last resort. Basically, it is this:

If it worked before and is now broken, go back and look at what has changed.

Simple enough. Machines are deterministic and most systems you code are as well. Code usually doesn’t degrade and break on its own; something must have changed to cause the problem. Go back and see if you can isolate the build where the thing broke. If you have QA people, you can parallelize and have them isolate the build while you debug. Now look at the commit logs, starting at that build and go back. Many times, this will be the “a-ha” moment you needed. Even if the changed code is not the actual cause, it’s usually a trigger or it somehow exposes the problem. Now debug, focusing on the areas of those changes.

Now, this doesn’t always work. Maybe the code just acts differently after a certain date for some odd reason (Y2K anyone?) or there’s a hardware glitch or your program is getting input it never received before. But these cases are the exception. I have repeatedly regretted not checking the change logs but not once regretted doing it.

So, now that you know the rule, how do you make sure you follow it next time you’re looking down the barrel of a EXC_BAD_ACCESS error? Try this: set a timer for, say, 10 minutes and then start debugging. When the timer goes off, if you do not have a good sense of what’s going wrong, then stop and check the commit logs. How do you remember to set the timer? Actually, I don’t have good answer for that. Maybe you can write a hook into CrashReporter to start it for you. Or maybe you hire a magical pixie that appears whenever your program crashes and reminds you. Or you combine the two and have CrashReporter somehow wake up the magical pixie who will then remind you to set the timer. Then, just work in a bowling ball and a cuckoo clock and you’re golden.