Noodlings

One of the main design precepts for Hazel was that it would do its work without bothering you and I feel I was successful in that goal, unless you are a developer. The one place where Hazel can get chatty is the console logs, much to the annoyance of some developers. I know how it can get in the way when you are trying to sift through your own application’s logs (though I do find that typing the process name into the search field does wonders).

Anyhoo, if you want to redirect the logs, you can use a defaults setting. Just type the following in at the command-line:

defaults write com.noodlesoft.Hazel LogFile file


file, of course, is whatever file you choose, including /dev/null. Removing the default will reverse the change. Note that this only applies to the background program; the UI, being a pref pane, logs wherever System Preferences logs, but it’s not nearly as talkative so hopefully this isn’t an issue. Also, there is no UI for this setting as I consider it to be something only developers would care about.

Random tangential reference to a piece of nostalgia/trivia:
When telling a friend (who was the one who brought up the original gripe) about this setting, I referred to the defaults setting as a dwrite which my friend found amusing (we’re both old NeXTies). In any case, along with dread and dremove, dwrite was the precursor to the defaults command and to this day I still refer to defaults settings that are only accessible via the command-line as “dwrites”. Old habits die hard.

Not-so-random, but nonetheless tangential info:
There’s another camp that would say that Hazel is too quiet. I am working on Growl support so if you have any particular opinions or ideas on the matter, let me know in the forums.

A new year is upon us. As is the cliché, it’s a time to look back before looking forward. While my posts have been mostly technical, I thought I’d start talking about the business and logistical end of things.

Hazel launched some months back and seeing as how you only launch a 1.0 once, I thought I’d post some thoughts on my experiences.

What Went Right

Shipping at all
I had to make some hard choices on what features to cut so I could ship. Otherwise, I would have spent much more time in perpetual beta (the Chinese Democracy Syndrome as Gus Mueller likes to call it). Complicating the release schedule was WWDC. I had originally thought about launching before WWDC but fortunately for me, I waited and ended up revamping a chunk of the UI based on feedback I got there. But in the end, I just had to bite the bullet and ship. I think the feedback I’ve gotten since shipping is far more valuable than any extra time spent toiling on it in isolation. Also, having a clear roadmap for the 1.1 release helped me in terms of my own neuroses about shipping prematurely.

Using 3rd party libraries and services
I used Kagi for my purchasing system. While not without faults (I still do not have in-app purchasing set up with Kagi because of some issues), they have worked well with much less effort than rolling my own. If anything, they freed up a huge chunk of mindspace. Also, using Aquatic Prime has been great for me. Overall, the less I had to worry about, the better.

What Went Wrong

Not shipping with Sparkle
I punted on launching with Sparkle for doing software updates. The main reasons had to do with the fact that it wasn’t just build and go for me (Sparkle needs a bit of tweaking to integrate with preference panes). The result was support issues when upgrading (boiling down to Obj-C not being able to unload classes). This was rectified in version 1.1 but in retrospect I feel that it should have been in there from the start.

A Bad Bug Right At Launch
Soon after launch, someone noticed that the Apple Help buttons weren’t working. While not the end of the world, I felt I had to fix it immediately. It is a new product so having help available was more important now than ever. Oddly, it worked fine for me on my main development machine but I was able to replicate the problem on my Powerbook (even though it had worked in a previous beta version on that same machine). I ended up scrambling and released a 1.0.1 release within hours of launch which is somewhat embarrassing. While the obvious lesson would be more regression testing on different hardware, it’s easier said than done. Being the only person here makes it hard to do all the testing a product needs. Probably the topic for another post some other time but for now this remains an unresolved issue.

What I Learned

When running your own business, I have to say that the hardest part of the job is making decisions. Especially being a one-man shop, I do not have the luxury of someone available to bounce ideas off of at will. It’s the decision making that keeps you up at night. The trials of going solo are better served as the subject of another post but I would say that if you are going it alone, use all the resources you have available for getting feedback on your decisions. Personally, I have found the macsb mailing list and IRC channel to be indispensable in this regard. Perspective is a valuable thing.

The other lesson is that bugs will get out there. The important thing is to have the infrastructure in place to deal with them. This ranges from decent feedback channels (email, forums, etc.) to a good QA process to having an easy way for users to keep up to date.

What I Did Not Learn

What I am still not sure about is the marketing end of things. I chose to be somewhat stealth during beta and focus on marketing at launch time. Of course, the cat got out of the bag earlier but the general notion was to not to not overhype too early. Since I was unsure about my exact launch date for a while, I was afraid of any buzz that I generated dying out if I took too long. So, I’m curious as to how other developers out there dealt with promoting their product before and during launch.

So, that’s it, in a nutshell. Not very exciting but what do you expect from a post with “mortem” in the title.

It’s here. A bunch of improvements and fixes, including the ability for rules to execute Automator workflows, AppleScript and shell scripts. Since this blog is a bit more developer oriented, maybe one of you out there can come up with some interesting scripts.

This release also incorporates Sparkle for software updates. In actuality, I’m using the Sparkle+ variant, though I’m not using the system profiling aspect of it. If any of you are developing a pref pane and want to incorporate Sparkle, feel free to drop me a line as you have to change a few things. Tom Harrington, who is the maintainer of Sparkle+ also has experience doing this but I’m not going to volunteer him for questions though if you join the Sparkle+ mailing list I’m sure he’ll answer them.

In short: Sparkle good. In retrospect, I should have included it from the beginning since you get problems when installing a pref pane over itself. I know that Objective-C can’t unload classes but you’d think that System Preferences would restart when this happens. It does detect it since it asks the user if they want to install over the old one.

At the risk of raising the ire of those Geico cavemen: Download. Buy. *grunt*