Another set of bugs in Leopard

A number of weeks ago, I fought with Leopard to be able to use a magnetic stripe reader in one of my apps. The Apple sample code worked on Tiger, but broke on Leopard. OK, I reported that as a bug. Next, I looked at some new USB code in Leopard and that failed as well. After opening an Apple DTS incident, buying a magnetic stripe reader for them, and going round and round, they acknowledged the first bug and the second bug which was a workaround to the first one. DTS did send me code that finally did work.

This week, I fought with Leopard (or maybe it is Tiger) dealing with the Keychain. The Keychain (along with System Configuration) are some of the most confusing frameworks to write code. This weeks' issue dealt with using the Keychain framework to get a password out of the System keychain (like for PPP passwords). If the user clicks on Always Allow, the method returns a -61 error which is a write permissions error. What's the workaround? Well, if I get a -61 error, I put up the request again. While this gets me to the end goal, it really confuses the user.

Today was another bug dealing with the Image Capture. I wanted to add supporting Image Capture in addition to TWAIN as it might be more reliable. I got as far as implementing the UI and all the code, only to find out that if I scan once, when I close the scanner session, I get an error and then I can't scan again. All that I've read indicates that the Image Capture Framework (ICA) doesn't work properly when compiled against 10.5. This doesn't surprise me as someone changed the TWAIN header files in Leopard so that UInt32s were changed to void * or vice versa. This, of course, causes lots of warnings that have to be typecasted. Scanning is one of those areas in the OS that doesn't seem to get touched and no one seems to care. The scanner vendors write crappy drivers so they don't complain and no one else is big enough to get Apple to care. Maybe things will change.

Paying for being stupid

The recent measles outbreak here in San Diego could easily have been prevented if the parents of the original infected child had vaccinated that child. However, the parents exercised their right to not vaccinate. Some parents believe that the mercury in vaccines leads to autism; the problem with this theory is that vaccines haven't had mercury (thimerosal) in them for years. At the same rate, autism rates have gone up, so it would lead any reasonable person to conclude that the vaccines (at least mercury in them) has nothing to do with autism.

While the parents exercised their right, their negligence (in my opinion) caused others to become infected (infants under 1 year can't be vaccinated for measles). I think that these people should pay for the medical costs of all those infected and should pay everyone for being inconvenienced. My wife has had to change plans because our son can't be vaccinated (he's 9 month old). These parents' choice has caused people all over San Diego to worry about something that I hadn't heard of in years.

Please vaccinate your children as your decision should not put my child at risk. If you choose not to vaccinate your children, please never come out of your house.

Planning for Aiden's first birthday

Our son, Aiden, is rapidly approaching his first birthday. We're trying to figure out what to do. Should we have a clown? How about a pony? How about one of those jumpy things? Wow, this is going to be huge. We're going to spend a lot of time and money planning a party that our son will never remember! Just kidding, we're not going overboard with his first birthday, maybe another birthday down the line, but why one that he won't appreciate? My wife has told me that some of the mothers she has run into are planning elaborate parties for their child's first birthday. What a waste.

Can't please everyone

Today, a very irate user sent me email complaining about the merging of ReceiptWallet and DocumentWallet. He wrote a very long email messages saying he felt ripped off and there is no mention of this on our website. Well, it isn't mentioned on the website because it is in BETA and hasn't been put into general release. There is no need to mention beta versions on our website (except for a small mention on how to get the cutting edge version).

As for being ripped off, shouldn't people buy software for what it does today and not what it could do with an update tomorrow? Does the software stop working just because a new version comes out? Personally I think that the cost of ReceiptWallet and DocumentWallet at $44.93 (50% off the second program) is easily justified. If it saves a few hours of work, then it can be justified. I was originally going to charge $39.95 for ReceiptWallet alone, but decided to start at $29.95 and never got around to raising the price. I've always been clear that the products are similar and even have articles here and here explaining the differences. The products do serve different purposes when you can only have 1 library open at a time. However, with the upcoming ReceiptWallet 2.0.0, you can have more than 1 library open at a time, so the reasons I've given no longer apply. People have never been forced to buy both products.

I had one user that loves the beta so much that even before I decided to merge the two, but just by adding the multiple libraries, bought a second copy of the software just because he thought the product was that good. A person was willing to pay $60 for ReceiptWallet!

I'm very pleased with my decision to merge the two products and think that it will help me compete and have a better, more feature rich product.