Accepting responsibility for bugs

When I make a mistake, I take full responsibility for the issue. While some people think I never make mistakes, I am human. The same goes for bugs in my software; software will never be perfect and I make my share of mistakes. I acknowledge these mistakes in my release notes where I say "Fixed". If it wasn't broken, then how could I fix it?

Today I had a user get on my case about me blaming others for bugs in ReceiptWallet. There are basically only 2 cases where I do this. The first is a bug where if "write metadata to PDFs" is turned on, sometimes PDFs will become corrupt. This one is quite easy to blame Apple. I've had users send me the original documents in question, I opened them in Preview (an application that Apple wrote), showed the Inspector, added some keywords, saved the document and then re-opened it. The result was that the document was corrupt. Recently I had a user report a very odd behavior in which the document didn't look corrupt, but when he tried to copy information out of it, the copied text was garbage. Sure enough, I did the above steps in Preview and demonstrated the problem. Sure sounds like an Apple bug to me; I've reported this to Apple a few times and have seen it fixed in the next OS release. Unfortunately it keeps coming back; what that means to me is that Apple's CoreGraphics routines for handling PDFs are not tolerant enough. Some random program implements PDF writing and then Apple has to handle it; so while I blame Apple, maybe I should blame the original PDF writing application. That, of course, would be fruitless as there are far too many of them out there. If Apple could work on their PDF handling, this issue might go ago. In any case, turning off "write metadata to PDFs" works around this bug. (I love this feature as it lets my wife enter receipts, email me the archive, and then I can just import them into ReceiptWallet with all the information intact.) This issue is clearly not an issue with ReceiptWallet except for the fact that ReceiptWallet has this option.

The second issue has to do with me blaming scanner vendors for their poor quality drivers. Anyone that has had a scanner on the Mac for any length of time knows how crappy the drivers are. I finally had my father acknowledge this after he fought with the HP drivers for the longest time (I wrote about this last August when the scanner driver reported that it used 16815 bits per pixel which means it had a ton of color information!). These drivers are typically ports from Mac OS 9; some of the UIs still look like OS 9. I see com.epson in crash log all the time; anyone that reads crash logs knows that this is in the bundle that ReceiptWallet has to load in order to run the scanner. In addition, I've lately seen crashes when ReceiptWallet quits.

Thread 0 Crashed:
0   libobjc.A.dylib               	0x905eb688 objc_msgSend + 24
1   com.apple.CoreFoundation      	0x93f9f372 CFBundleGetIdentifier + 50
2   com.apple.CoreFoundation      	0x93fa2dc5 __CFBundleDeallocate + 53
3   com.apple.CoreFoundation      	0x93fff768 _CFRelease + 216
4   ???                           	0x00fc5340 0 + 16536384
5   dyld                          	0x8fe13083 ImageLoaderMachO::doTermination(ImageLoader::LinkContext const

After some investigation and looking at Console logs for the users having this problem, there is clearly a message in it saying that the EPSON plugin is releasing its bundle identifier when it should not be and that the user should report this to the plugin vendor. Who should I blame in this case?

The only scanners I recommend are the Fujitsu ScanSnap and the Pentax DSMobile 600. The ScanSnap series don't use TWAIN drivers so they can't blow up ReceiptWallet and the Pentax DSMobile has incredibily well put together drivers. My guess is that they didn't start from legacy code. I've also had an engineer at a major scanner vendor acknowledge that their drivers are pretty poor, but unfortunately it will take time to fix. (Of course, I can't tell you which vendor.) I'd love for scanner vendors to either fix their drivers or acknowledge that they are poorly written; however, most vendors bundle some of their own software and barely test the TWAIN interface (Pentax doesn't bundle any Mac software, so they are totally dependent on TWAIN).

So while I'd love to be able to accept responsibility for these issues in ReceiptWallet and fix them, there is nothing I can do about it (I had one user suggest that I write scanner drivers for all the scanners...after I got up off the floor from rolling around laughing, I told the user that that was not going to happen).

ScreenSteps, cool idea, but not quite a Mac app

On Friday I stumbled across ScreenSteps, a program for doing documentation by quickly and easily capturing screen shots. While I no longer do documentation for my own software, I am starting to do some internal documentation for work on things like connecting to our VPN, setting up connecting to a file server, etc. I put together one "lesson" in maybe 15 minutes and was able to stick it on our internal web site. One thing that bothered me was that there were some dialogs that didn't look like Mac dialogs like the following (The icon looks funny and it should have been a sheet):

Things like this usually indicate it was written in REALbasic. While I don't have anything against REALbasic itself, I have problems with people slapping together programs in REALbasic and passing them off as Mac applications; in most cases they work like Mac applications, but they seem unpolished. I realize that this is a generalization, but I haven't seem a REALBasic based program that I'd purchase (at least knowingly). ScreenSteps didn't have the REALbasic libraries buried in its app bundle, so I knew it wasn't built using REALbasic. So did the developers purposely create crappy looking buttons? I don't think so. They appear to release the Mac and Windows versions at the same time, so they must be using some type of cross platform library. Ah, the about box gives me a clue. They're using a system called Runtime Revolution. Uggh, another attempt at creating cross platform applications with the click of a button.

So the question boils down to, can I live with the sort of Mac like appearance to quickly build documentation or can I find another tool? I'm not sure, but I'm definitely not a fan of cross platform tools as they produce apps that just aren't up to Mac UI guidelines.

NekFit, hokey but useful

At Macworld, I saw an iPod Nano case called nekfit. I have been running with my iPod Nano using an armband, but the wires always got in the way, so I was intrigued by nekfit. When I stopped by their booth, the marketing guy said if I didn't like it, give him a call and he'd make it right. So, I went ahead and ordered one. I received it a few weeks back and must say that it looked like something that was slapped together in a garage. If you take a pair of sunglasses, but them on backwards around your neck and attach an iPod to it, that's what the nekfit looks like.

I've taken it for a few runs and after I got all the wires tied up the way I wanted (one of the wires kept getting caught on the side), I think I like it. It's pretty comfortable and definitely keeps the wires out of the way. I had to turn off the rotate mode on my iPod Nano 4G as I couldn't switch tracks when it was rotated (it kept going to CoverFlow mode). My only complaint is that I wish I could adjust the angle that the iPod hangs as it kind of rubs against my neck.

Will this last? I have no idea. My previous armbands had to be replaced as the neoprene started breaking down and smelled so bad that I couldn't use it anymore (I went as far as bleaching it and that didn't help).

For $35, it is definitely a viable alternative to an armband as long as you don't mind people thinking you're a little crazy for having this thing around your neck!

iWeb, the hidden gem?

I bought iLife '09 and installed it, but all I've had time to do is launch iPhoto a few times and play with the facial recognition which is pretty cool. The other night I was watching CNET's weekly TiVo videocast and they reviewed or at least introduced iLife '09 (which is kind of surprising as they seem to not like Macs). One of the things that was mentioned is that iWeb '09 now has the ability to upload to FTP. Hmmm...I only played with iWeb a few times way back when, but ignored it as I don't have a .Mac/MobileMe account. I fired up iWeb '09 and immediately looked for the FTP export. Not only did I find it, I found that it also did SFTP (Secure FTP, which is FTP over SSH). To top off that, it lets you specify the SSH port (I changed the port on my server from the standard 22 to another port to reduce the number of attempts to get in; while people we're getting in, it bogged down the system denying the requests). Very, very cool. I played a little more with iWeb and am quite impressed; I like the ability to place pictures wherever as it seems more flexible than anything else I've used. Publishing worked well and this might be my new web tool of choice (for the little web work I do).