Noodlings

In my recent quest to deal with some long needed “home improvement,” I’ve just rolled out my own store based on PotionStore. For those that don’t know, PotionStore is an open-source store implementation done by Andy Kim. It’s used by PotionFactory, of course, as well as a few other shops.

Until now, I’ve been using Kagi for all my payment processing. Kagi is great for someone starting out as they provide the store, deal with taxes and can even provide a license number generator. I think when you are doing your first release, outsourcing the commerce side to someone else can save a good deal of time.

So why am I switching off Kagi? Mainly much lower commissions on each transaction and more control over the store itself. I was finding that the commissions were adding up to significant money as my volume rose and there were certain features I wanted to add that I couldn’t. On top of that, there was a bit of confusion regarding having customers dealing with a 3rd party.

Unfortunately, now with my own store, I am going to have to charge sales tax to New York residents. One of the downsides to living in the same state as me. Trust me, I’m not looking forward to doing the tedious sales tax filings.

Using PotionStore has been great. The integration took a bit longer as I had to learn Ruby on Rails at the same time (more on this possibly in a future post). I also had to change the code a bit for certain requirements I had (sales tax, license files, family packs, etc.). My thanks to Andy for sharing his code. I hope to see other devs pick it up and maybe even contribute to it. Oh, and a thanks to Gus Mueller for letting me crib some Javascript from his store.

The result of all this is a store which I hope looks nicer and has a more streamlined flow. I’ve added the ability to download your licenses immediately as well. You’ll still get them emailed to you but this way, you’ll get instant satisfaction coupled with some level of redundancy.

So, give it a spin. Maybe even buy something :). If anything goes wrong, or even if everything goes right, I’d love to hear about it.

Recently, Quentin Carnicelli of Rogue Amoeba asked if there were NSResponder methods that you could hook your “OK” and “Cancel” buttons to to dismiss a modal panel (or sheet). As far as I knew there wasn’t but, gosh darnit, that would be a useful thing to have.

To clarify what I’m talking about here, when you run your own modal window or sheet with “OK” and “Cancel” buttons (or some equivalents), you end up hooking those up to methods that dismiss the window/sheet, stop the modal session and return some code (either one for confirmation or cancellation). Most of the time, you end up writing the exact same code. It’s glue code that shouldn’t have to be written.

Now, if you look at NSResponder, you’ll see all sorts of action methods in place. Sticking these glue methods into NSResponder will allow you to hook up your “OK” and “Cancel” buttons to the “First Responder” in IB. The idea here is that there is a default implementation that will close the current modal window or sheet and set the return code to either NSOKButton or NSCancelButton. With this, your code can act more like it’s using NSRunAlertPanel() or NSBeginAlertSheet() by just interpreting the return code.

I’ve created an NSResponder category with the methods -confirmModal: and -cancelModal: to which you can hook up your “OK” and “Cancel” buttons in IB. Note that you may have to manually add the methods to NSResponder in IB as it doesn’t know about them.

Now NSResponder’s versions of these methods don’t actually do anything besides pass it on to the next responder. The main part is in NSWindow, which overrides it. It will check to see if it’s the current modal window or sheet, order itself out, stop the modal session and send back the appropriate code. By using the responder chain, this mechanism will find the “nearest” modal window. Note that it is assumed here that the buttons to dismiss a modal window are in the same window. If you want to dismiss it from a different window, it may or may not work (depending on the responder chain and other subtleties such as the odd specification of NSWindow’s -isSheet method). I can’t think of a non-contrived case where you’d want this or care but if one comes up, let me know.

So here’s the download. Suggestions, questions, bug reports appreciated.

modalresponder.zip

If you are reading this right now, then that should mean that the host migration was successful. No, I didn’t accidentally re-post my last article. I’ve moved Noodlesoft to yet another hosting provider. Noodlesoft is now on SliceHost.

Unfortunately, things didn’t work out with WebFaction so I decided to go shopping again.

While many people were recommending SliceHost, I resisted as I wasn’t relishing the idea of doing sysadmin work. I’ve done my fair share in my lifetime, including compiling kernels, setting up firewall rules and mucking with sendmail.cf files. The whole purpose of using shared hosting was that I could pay someone else to do it. Nonetheless, I found myself in need of a higher level of reliability and control. I had to bite the bullet.

I signed up and within minutes, was logged in to my slice. And oddly enough, I found myself actually enjoying setting up my server. Sure, it took some time to get everything up and running but not as long as I expected. It’s put together the way I want and if something goes wrong, it’s hard to beat the response time of going in and fixing it myself. It’s not for everybody but if you know what you are doing then I say give it a try. I would recommend paying extra for the backup feature where you can save snapshots (or have snapshots automatically taken daily or weekly). Restoring slices from these snapshots is quite easy in case you mess up or something else goes wrong. They also have articles on how to install most of the software you’ll need to get up and running. My only beef right now is that I’d like more snapshots slots available (you only get 3).

Here is the obligatory/shameless SliceHost referral link in case you are interested in signing up.

Oh, and I am keeping my DreamHost account for things such as hosting my mail. Also, since DH’s plans offer ridiculous bandwidth, it’ll be good to have as a backup when there’s some sort of burst.

And because it’s what I’ve been dealing with for the past couple weeks, you’ll probably see some sysadmin articles from me in the near future. I’ve even added a “System Administration” category. I’ll post a report on SliceHost and my experiences with VPS hosting in a month or two.

If you are reading this right now, then that should mean that the host migration was successful. You probably didn’t notice anything but Noodlesoft has switched hosting providers. It’s been a long time coming, but I’ve moved the site from Dreamhost to Webfaction (note: this is an affiliate link).

The transition had its share of bumps and glitches as the two providers do things a bit differently. Except for the forums being offline during the migration, hopefully you shouldn’t have noticed a thing. If you do find anything not quite right, please let me know.

It’s too early to tell whether this was a good move but I’ll post a report/comparison after I’ve developed a track record with the new provider. In the meantime, I’m keeping my fingers crossed that nothing blows up.

It seems customary for people to post pics of their workspaces and Rands’ recent post has spurred me on to post mine. I’ve been spending this early part of 2008 clearing out my desk area so the timing is a bit serendipitous. I’ve finally packed away my old, dusty PC, which is now in the other room ready to be given to a friend. I’ve also installed a cable management solution which gets most of the cords and cables off the floor and (mostly) out of sight.

So, here it is (pics hosted on Flickr):

It is also in Rands “Pixel Rigs” group where you can find other people’s setups.

Some notes:

• The cheese grater on the left is a PowerMac (2.3GHz DC). It is being retired in favor of the Mac Pro next to it. It was the machine I originally developed Hazel on. Will be looking to sell it so drop me a line if you are interested in it.
• The monitor on the left was intended as the second display for the main machine but is attached to the old PowerMac for the time being.
• I like large tabletops, but getting the second monitor cut me off from the left side of the desk. Real desktop space sacrificed for virtual.
• There is a scanner hidden away behind the left monitor. It’s a very low traffic item so I don’t mind having to get up to get to it.

Additional pop-up notes available on Flickr.

By the way, this is my desk on a good day. Unfortunately, I haven’t ported Hazel to RL (real life) so my desk can accumulate quite a bit of stuff. With great desk space comes great clutter.

Yes, folks, it’s Happy Fun Bug Time where I talk about what has been making me tear my hair out recently. In this installment, we talk about NSCalendar.

NSCalendar has a method called rangeOfUnit:inUnit:forDate:. What this method is supposed to do calculate how many of one time unit are in another. For instance, how many days are in a particular month. Since date calculations can get tricky, with daylight savings, leap years and all, this method is quite handy.

Or, it would be handy if it didn’t suffer from some pretty bad bugs on Leopard. At first, I tried something like the following to calculate the number of days in a given year:

  range = [[NSCalendar currentCalendar] rangeOfUnit:NSDayCalendarUnit
                                             inUnit:NSYearCalendarUnit
                                            forDate:[NSDate date]];
                                  
  NSLog(@"%@", NSStringFromRange(range));

Given that this is a leap year, I’d expect “{1, 366}”. What do I get? “{1, 31}”. I suspect that wires got crossed with the days-in-a-month calculation. Oh, but the fun doesn’t stop there. Try this at home (kids: do not try this at home):

  NSCalendarDate          *date;
  int                     i;
  
  date = [NSCalendarDate dateWithYear:2007 month:1 day:1 hour:0
                               minute:0 second:0 timeZone:nil];
  
  for (i = 0; i < 365; i++)
  {
    range = [[NSCalendar currentCalendar] rangeOfUnit:NSDayCalendarUnit
                                               inUnit:NSWeekCalendarUnit
                                              forDate:date];
    
    if (range.length != 7)
    {
      NSLog(@"Date %@ has week of length %d", date, range.length);
    }
    date = [date dateByAddingYears:0 months:0 days:1 hours:0 minutes:0 seconds:0];
  }

This cycles through each day of last year (2007) and calculates the number of days that week. Now, having just recently lived through that year, I think I can say with some certainty that no week had any more or less than 7 days in it. The above code prints out any oddballs. If you run it yourself, you find that quite a few days are in weeks exceeding 7 days. Upon closer inspection, you find that any day in a week straddling two months reports the number of days in the month, not the week. On weeks fully contained within a month, it reports 7 days. Again we are seeing a tendency towards the days-in-a-month calculation. Someone really likes computing that.

I've filed a bug report (rdar://5704940 for you Apple folks). Unless I'm doing something really wrong here or there were some time distortions last year that I was unaware of, you may want to avoid using NSCalendar's rangeOfUnit:inUnit:forDate: on Leopard for the time being. Thinking about it though, the time distortions would explain a couple weekends…

Update (Feb. 1, 2008):
I strongly recommend reading the comments. Thanks to Chris Suter for explaining what Apple's logic is in doing it this way. We all thought he was nuts at first but it appears that he was just explaining Apple's craziness.

In short, things probably are working as designed by Apple. I still think the design is flawed and that it is horrendous API. It seems that, in Apple's mind, Leopard is correcting a bug in Tiger (in other words, the intuitive and useful behavior in Tiger was a bug).

The original point stands that one needs to take care with -rangeOfUnit:inUnit:forDate:. It seems to be only useful for specific combinations of units and given the change in behavior between Tiger and Leopard, it becomes even more of a headache. If Apple is going to continue with this interpretation, then they should just treat these computations as undefined since the results are misleading.

A common user annoyance is having alerts popping up at bad times. The worst is when the user is typing and focus gets stolen only to have subsequent key presses going to the new window, possibly resulting in the user inadvertently confirming something they didn’t want to. Peter Hosey discusses this particular case and outlines an NSAlert-based solution.

I recently submitted a patch for Sparkle+ to deal with a similar situation. It can be annoying to get an alert about a new version when you are working. A new version is not a “drop everything and deal with this now” type of alert. With this patch, when a new update is found, it will check the user’s idle time and hold off showing the panel until a certain amount of time has elapsed. This minimizes the chance of the user being in the middle of something when the alert comes up. Of course, this is only suitable for when the alert itself is not terribly critical or time-sensitive. It should not be used if it is in response to direct user action or if the alert is something that needs to be dealt with immediately.

Since this type of thing may be useful in other contexts, I’ve decided to generalize it and put it out there for your consumption. It’s a little NSObject category with two new methods: performSelector:withObject:afterSystemIdleTime: and performSelector:withObject:afterSystemIdleTime:withinTimeLimit:. The first will call the given method on the receiver when the user has been idle for the given period of time. The second method does the same but allows you to set a limit after which it will call the method regardless of idle time, thus preventing the method from being delayed indefinitely.

Beyond the use described above, you can use it in several other situations, such as doing some internal maintenance that may get in the way if the user is actively using the machine. You can reclaim/free memory, clear out caches, compact file stores, optimize data structures or whatever.

For the time being, I am using this in my Sparkle update alerts and my scheduled evaluation period expiration nags. What will be interesting is if this leads to some sort of “refrigerator light syndrome” where users notice that it only happens when they are not looking and are somehow bothered by it. Most likely, though, users probably won’t notice and, with any luck, they will be more receptive to the alerts when they do pop up. If that leads to an extra spring in their step, then I consider it a job well done.

The project is linked below. Make sure you read the Read Me file. If you end up using it, let me know.

Update (Jan 10, 2008): The original project had a couple files specified as absolute paths (so XCode wouldn’t find them). A new project has been put up with this error fixed. It is marked as version 0.6 in the package name and Read Me file.

performwhenidletest-0.6.zip

Update (Feb 5, 2008): It appears that the CGEventSourceSecondsSinceLastEventType() function hangs on Tiger systems. I have updated the code to check for the OS version and only do the idle delay on Leopard and later.

performwhenidletest-0.7.zip

I am also looking into patching this in Sparkle+. If you are using Sparkle+ with this feature enabled, drop me a line or wait for the patch which will hopefully happen soon.

Apparently, Leopard changed the file command. On Tiger, the -i argument makes it print out mime types instead of the more human friendly descriptions it normally uses. On Leopard, this has been changed. From the man page: “If the file is a regular file do not classify its contents.” What this means is that a lot of files just get identified as “regular file” which doesn’t seem all that useful to me.

I found this change a bit reckless as it can break software using it (like a certain piece of software written by yours truly). I thought this might be a change that Apple inherited from BSD, but, doing a small survey (thanks to Tom Harrington for the FreeBSD datapoint), that may not be the case:

In addition, according to this man page which seems to describe the same version of file that is installed with Leopard, it also shows -i behaving like everyone else’s version.

So, the question is, “Apple, why?” It appears there are a bunch of other letters in the alphabet available. Why cannibalize an existing one?

In the meantime, I’ll just use the equivalent --mime option but I’m still a bit confused as to why I’m having to make this change at all. Bad Apple, no cookie for you!

Update:
Tim Buchheim points out in the comments that this new behavior is to make Darwin compliant with the Single Unix Specification. Now knowing what to search for, I dug up these release notes which list the changes (including the ones to the file command). Good to know that there was some reason for this.

As the year winds down I thought I’d do the obligatory year-end reflection. As usual, I’m overdue for a blog post so this will make good filler until I can come up with something more interesting.

The main thing to note is that I’m now fully indie. What that means is that Noodlesoft is a full-time affair and that it is supporting me financially. This actually has held true for some months now though it’s only now that I’ve realized that I haven’t really mentioned it here. So yes, Hazel has gone from a preoccupation to an occupation. I have done the occasional side contract here and there but Noodlesoft is paying the rent on its own.

After what seemed like an unending beta period, 2007 saw the release of Hazel 2.0. With that release, I felt Hazel had become much more the product I had originally envisioned and its reception has been great. I also dabbled with promotions this year, including MacUpdate and MacSanta, both of which were great successes. Also, a promotion with ScreencastsOnline worked out wonderfully as, in addition to the added sales, I got screencasts out of it which I’m now using on the site.

What didn’t go so well? Well, I’d say the main thing would be Leopard. A lot of stuff broke that shouldn’t have and I’m still tackling Leopard bugs now. Yes, I’ve had access to seeds for some time now but fact of the matter is that a lot of the stuff was fixed by Apple in the final month or so and more stuff broke with the GM and subsequent releases.

I hesitate to make any announcements on what’s in store for 2008 but I’ll mention that Leopard adoption is much higher than I anticipated. As a result, I am seriously considering making Hazel 3.0 a Leopard-only release. What’s going to be in 3.0? I still haven’t worked that out so it will be some time until that happens. Until then, there will still be 2.x releases that will still run on Tiger as there’s still stuff I can put in there that doesn’t require Leopard. And of course, there’s always the possibility of a new app though I have to say that nothing has gotten past the drawing board phase yet.

In any case, 2007 was a good year and I’m hoping that 2008 will be even better. A big thanks to all of you for your support this year and best wishes moving into the next.

One of the neat hacks features added in Leopard is that iCal’s icon can now display the correct date even when it’s not running. It works for me as advertised except one thing, which this picture will make clear:

This has bugged me since I upgraded to Leopard. Fortunately, someone recently figured it out as indicated in this MacFixIt forum post. It just involves weeding out duplicate fonts (in this case, Helvetica Neue).

It seems that Font Book indicates a duplicate font by adding a bullet (•) after the entry in the list. I would have preferred something more self-apparent as I never was able to guess that. To be fair to Apple, if you search in Font Book’s help for “bullet”, you get the entry “If a dot appears next to a font name”. Make sure you read this entry. The MacFixIt post referenced above says to use the “Resolve Duplicates” feature. What it doesn’t point out (that Font Book’s help does) is that you need to select the version of the font you want to keep. Selecting all fonts under the “All Fonts” collection didn’t work for me; my guess is that it’s indeterminate which font is used since that collection is a mix of the system and user ones.

If you want the system installed versions of fonts to override any others, click on the “Computer” collection, select all the fonts there and then do “Resolve Fonts.” Also, it doesn’t seem that just disabling the fonts does the trick. I had all my user fonts disabled up until now. It was only after I re-enabled them and did the “Resolve Fonts” thing did it all clear up.

I filed this as rdar://5592647 and I have amended it with the info above, for you Apple people keeping score at home.

As with all things (especially when dealing with font stuff on OS X), YMMV.