Noodlings

This issue came up twice in the past couple weeks thus triggering my rule that if something comes up more than once then others may be interested in it. So, here’s a little tip that may save you some frustration.

When using regular expressions with Xcode’s search, the docs mention that XCode uses the ICU library. Naturally, you’d think it would use ICU’s syntax for specifying backreferences in the replace string, which would be to use variables consisting of a dollar sign ($) followed by the number of the capture group being referenced.

Of course, if that were the case, I probably wouldn’t be writing this tip. Using $ for backreferences turns “Search & Replace” into “Search & Destroy”. The syntax is to use backslash (\) instead of dollar sign. In short, \1 instead of $1.

Type the following in an Xcode editor window: “$1 works in replace strings.”

Now perform the following search & replace:

Ok, maybe this example makes things more confusing. If in doubt, just remember: $ = bad, \ = good in Xcode Find panel.

As to why Xcode does not use the ICU syntax in the replace strings, beats me. If anyone has a simple explanation, send it my way though I also welcome apocryphal anecdotes and crackpot conspiracy theories (extra points if you can convincingly implicate the Trilateral Commission).

Recently, a couple articles caught my attention. Triggered by news of the lack of Java on the iPhone, these articles go on to address Java’s failure on the desktop in general. Check out Duncan Davidson’s post here as well as Jens Alfke’s here. In the spirit of these articles, I’d like to tell a story, one that many have not heard and that, after all these years, should be told. It’s a story not only about what was, but about what might have been.

Years ago, I worked at a company called Lighthouse Design (I refer you here for a brief history and background). Sun bought Lighthouse in 1996. While we were officially Sun, we were somewhat separate. We enjoyed some level of autonomy and even got to stay in our own offices, avoiding a move to Sun’s campus.

It was an odd transitional time for Lighthouse. The codebase for our apps was in Objective-C and Sun was pushing Java. The notion was to possibly port the apps over to Java thus giving Sun an instant desktop suite. Yes, Sun also had OpenStep but Java was shiny, new and all the rage and besides, Sun was slowly killing OpenStep. At the time, the AWT was the only option for doing UI with Java. I don’t think I need to elaborate on why that was a problem. We developed an Openstep-like framework in Java to make porting easier and for the most part we were successful. The Lighthouse Foundation Classes (LFC) were not an exact implementation but they were close enough to make porting more of a mechanical process.

As a result of this, we became another party in the Java GUI Toolkit war. In addition to us, there was Netscape’s IFC also done by NeXT-inspired developers as well as the threat of Microsoft’s AFC. JavaSoft recognized they had to do something about this. The result: they got us and Netscape to discontinue our toolkits in favor of their upcoming project, in order to provide a common front against Microsoft. JavaSoft asked us, along Netscape and Taligent (I forget how they got tangled in this), to join them in the design and implementation what would become Swing.

It quickly became evident that the people involved from the JavaSoft side had little to no experience with OO and/or GUI programming. I realized that if these were the people in charge of implementing the GUI toolkit for a platform, then the project is going to be a mess. Various design discussions ensued with the people who didn’t have any real experience with OO programming or developing and shipping real desktop apps overriding those who did. I soon dropped out. The other LFC team members managed to stick around long enough to do some coding but over time they left as well.

In a nutshell, Sun had at least two toolkits with superior APIs that were ready to go. NIH syndrome was in full effect. Politics and territorialism won.

It’s worth mentioning that Sun is sitting on the Objective-C codebase for all of Lighthouse’s apps; another casualty of war resulting from their hubris. It’s sad how they could ignore those who were experienced (but considered “outsiders”) and how they thought they could figure out this whole desktop experience thing themselves. Sun does make great system-level software but history has shown time and time again that they do not “get it” when it comes to end users and the desktop.

One can only imagine what could have been. A Java GUI framework that was quite similar Cocoa. Or possibly a whole suite of productivity apps for OS X. I can’t say whether it would have been a success for Sun, but at least they would have been taken seriously. Sun “coulda been a contenda.” Sun had the technology and talent to become a force on the desktop and managed to squander both. The code is locked away somewhere in Sun’s vaults and most of the people have moved on to better things (some to places in the Mac sphere). The only thing they seemed to really get out of the Lighthouse deal was a CEO.

P.S. I apologize if I skimped on details concerning the death of OpenStep. If anyone from that team wants to tell that story, let me know and I’ll link to it. Likewise for the IFC team.

Update: Terrence Talbot of Karelia has put up a great writeup of the history from his perspective of being a member of the OpenStep team at Sun with some background on the IFC thrown in as well. It fills in a lot of holes and goes much more into the specific details concerning the politics at Sun. An essential read.

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.