GrandCentral Dialer

I've been using GrandCentral for awhile now and think I have finally managed to get people to start calling that number. The flexibility is great; I can pick the phone I want to use and if I travel, I can set calls to goto my cell phone. If I'm around, calls goto my VOIP line. One of the interesting features they added to GrandCentral was the ability to call a Gizmo Project number as a calling number. Combine this with click to call on GrandCentral's web site and I basically can get rid of a phone line. I currently have a BroadVoice VOIP line which costs me about $12 per month.

So the other day I was thinking, could I get rid of the BroadVoice number? After some searching, I found that Gizmo Project is a standard SIP provider and if you can configure the phone to connect to a SIP account, you can get it to work. OK, easy part done. Phone rings when my GrandCentral number is called. Next the harder part. I wanted to be able to dial any number via GrandCentral so a) it doesn't cost me any money and b) the caller ID is from my GrandCentral number. A few web searches later, I found a perl script to do what I wanted. The UI, of course, is non-existent, so I put my Cocoa skills to the test. I started my little app yesterday and completed it this evening. I now have a little menu bar item that lets me select my "originating number" (usually my Gizmo Project number) and lets me dial any number. To top things off, I added a little AppleScript support so that I can dial from the OS X Address Book.

Very cool. It could stand to use a little more polish, but I'm pretty pleased with it. Now I have to contact GrandCentral/Google and see if I can use their logo as the menubar icon. I'm sure that will go over real well.

I still need to decide if I'm going to sell this or give it away. Hmmm. I think it hinges on what GrandCentral says. Can't sell something if they get pissed at me.

Less complaining, more fixing

I, like many modern Mac developers, use Sparkle for auto-updating ReceiptWallet. This is an amazing framework that keeps getting enhanced. Many developers just shove it in and forget it. When there is an issue, they just complain about crappy code (I know I do that a lot). Today in updating ReceiptWallet, I found that my update crashed. I am using the absolute latest and greatest Sparkle code, so it always has risks. I dove into the code, found the bugs and suggested fixes. Andy Matuschak, the Sparkle guy, must not sleep (well, he is a college student), as he fixed the bugs within hours after I reported them (someone actually reported one before I did, but I identified the exact causes) and then when I was looking at the fixes, I noticed that Andy made a mistake (probably easy to do with a lack of sleep) and reported it again. Andy quickly fixed it and all is well. I really love Sparkle and it is the only way to get people to keep up-to-date on my software.

I'd suggest that other developers try the latest code and report bugs. This is the only way to improve the framework.

Anyway, thanks Andy for a great framework and keep up the good work!

Treating customers like garbage

I got my bill from MCI (The Neighborhood plan) the other day for our home phone service and saw that it jumped! After some research (viewing my invoice online was a nightmare because the server kept dropping my connection even when I tried from Windows), they raised my rate $10 per month. I've been a customer for a long time and wasn't notified of this change; they swore that they notified me in my online bill (I still can't find a record of that). The increase is ridiculous. This comes at a time when people are dropping landline phones to go only cellular. I still like the call quality of a landline and knowing that 911 is available. So MCI charges me $56.99 per month. If I'm a new subscriber, it would be $59.99 per month, but each year I'd get a free month of service. So basically as a long time customer, I get screwed out of $24 per year. I've looked into switching to AT&T, but their online help is kind of useless. They can't even tell me exactly how much voicemail costs. The base cost for unlimited local and long distance is $40 per month and somewhere between $6.95 and $9.00 per month for voicemail. So would it be cheaper than MCI? Possibly, but I can't quite tell. The signup page lists all the fees and stuff which seems to indicate that the total, including voicemail would be a little more than $10 per month cheaper than MCI. If I go through with the signup, there isn't an option to add voicemail, so I'd have to talk to a rep and deal with that.

After my call with MCI, I got a recorded call back to fill out a survey. I rated them poorly and at the end, it offered to connect me back to a rep to straighten things out. After being on hold for awhile, I gave up.

Maybe tomorrow I'll call AT&T and see if I can get more information. At this point, it looks like MCI will lose me as a customer because of a small rate increase. $10 is $10 and I'd rather have it in my pocket. (Also it is interesting to note that MCI's fees are about $6 per month higher than AT&T's probably because MCI has to pay AT&T to use the lines.)

Supporting ancient OS versions?

I had a user today purchase ReceiptWallet and then complain that it doesn't work on Mac OS X 10.2.8! First off, people should download the demo prior to purchasing as I have a big "agree to this" section when purchasing that tells people to try before they buy and says we don't offer refunds. (I did give this guy a refund as I don't want to fight chargebacks because people can't read.) Second off, 10.2.8 came out in October 2003! This guy said that he stays 2 OS versions back (apparently major versions). How can anyone expect developers to support such old OS versions? Apple stopped providing security updates to 10.2.8 a long time ago!

Based on usage statistics I started gathering a few months back (anonymously, of course, which requires me to make some assumptions), Leopard (10.5) users outnumber Tiger users (10.4) 4 to 1. Since ReceiptWallet uses CoreData, it requires 10.4 as CoreData was introduced in 10.4. Based on these statistics, going forward, I have to really decide if I will continue with 10.4 support. For now, I'll keep supporting it, but some features will require 10.5 (or even 10.5.3) and higher.