Debug Logging in Shipping Code is not nice

During some development today, I had to install the scanner drivers for my HP 6110xi all-in-one device. Knowing that scanner drivers have been consistently horrible for the Mac, I decided against installing on my main machine (which also serves as my development machine) and instead installed it on one of my test machines. Well, it is really sad to be right in this case. The 101 MB download for the HP scanner included a whole lot of crappy software. As I was debugging my application, I write a bunch of stuff to the Console and as I was watching the Console, I saw lots of stuff like this:

2006-10-21 16:30:34.134 HPEventHandler[204]: DebugAssert: Third Party Client: (NULL != m_lock && 0 == errno) Can't create semaphore lock[/Volumes/Development/HP/Mac-Sirani/mac-software/components/HPEventHandler/Sources/Core/HPTMNotificationManager.cpp:62]

appear, as well as debug statements showing the scanning process. I didn't enable any special logging or anything like that. I wonder how much debug code shipped with the driver and bloated it? It really is a good idea to turn off the debug logging when you ship a product or at least turn if off and make it an option to turn it on in case you need to have a user send you something.

With the rush to get products out to market, quality has gone to the birds in a lot of products.

Learning new technologies (Apple technologies, that is)

For a long time now, I've been wanting to learn various Apple technologies such as Core Data and Bindings. However, it hadn't been until last week when I finally had a chance to start learning them as well as Image Capture Framework. I came up with an idea that I'm excited about and started work on the project last week. Since I'm supporting OS X 10.4 and later, I can use Cored Data and Bindings (bindings go back to 10.3.9 or so). I always have trouble learning new software stuff if I don't have a use for it; now that I have a use for it, I learned both technologies in a matter of days. I'm pretty impressed with Core Data. It works well and I haven't found anything to really dislike about it, yet. Bindings, on the other hand, sounds great in theory, but sometimes just doesn't work how I want it to work. So, I spend a lot of time trying to jam a square peg in a round hole until I give up and go back to the way I did it before. This isn't to say that bindings are useless, they're just not for everything.

On to Image Capture. The sample code made it look easy and scanning was working real well until I tried to muck with the contract, brightness, etc. It appears that none of the settings work (at least with my scanner). So I start poking around and figure out that most scanner apps on my machine are using TWAIN instead of Image Capture. OK, so I wasted another day realizing that Image Capture Framework (for scanners) is broken or I'm not using it right (the sample code produces the same results as my code). TWAIN seems to work OK, until I try to have 2 scanners on my system so that I can detect them. Took me 30 minutes to figure out that the EPSON Perfection 1250 drivers that say that work on Intel Macs aren't universal binaries, so they work in Rosetta applications, but not native ones. My other scanner, a DocketPORT 465 does have native drivers (that's one of the reasons I bought it). So my code worked fine, EPSON is just behind the times. On a side note, it's amazing to me that scanner vendors still are clueless after all these years...they make crappy software and always have.

Anyway, a few more technologies under my belt and it wasn't all that painful. Stay tuned for my latest product which has managed to get me excited about programming, again!

First Impressions of the Sony Reader

I managed to get my hands on a Sony Reader yesterday as I've been itching to get one for awhile now. The digital ink technology is very intriguing and I wanted to see and use it for myself. First off, the price tag of $350 is a bit steep to make it a generally accepted consumer gadget, but I'm a technology person so I added it to my collection.

When I first started it up, it had a nice selection of excerpts of books as well as some classics like George Orwell's 1984 (which I've never read). Since I knew out of the box, it wouldn't work with a Mac, I hooked it up to my Mac to see if the reader would mount as a USB mass storage device. Unfortunately it didn't. Why Sony did this, I have no idea as the PSP mounts as a UBS mass storage device. So, Mac users are stuck using SD cards or MemorySticks which is fine, however, you can't remove the pre-installed books without Windows. I fired up Parallels and was pleasantly surprised to see the Sony Connect software work fine on it and link up to the Reader over USB. Like most Sony user interfaces I've seen in the last decade, the Sony Connect software is just awful. While it tries to mimic iTunes, it fails miserably. You can only drag and drop books on certain places (you can drop a book onto the reader, but not the Books category on the reader), has annoying alert dialogs confirming deletes that take up the entire screen, and has no way to "eject" the Reader even with the warning on the Reader's display not to disconnect.

So if we ignore the crappy Windows software, how does the Reader do? Well, the books that ship with it are great as well as some RTF files that I transferred to it. The display is amazing and these books work quite well with page turning that is quite speedy. However, one of the reasons I got this was to read technical info that usually comes in PDFs. The Reader's PDF viewing has some issues. First off, it is dreadfully slow. It can take 10+ seconds to turn a page. Second off, it reduces the page without being able to zoom/scroll. So, after cropping some PDFs (Preview lets you crop PDFs), I was able to read the 8.5x11" PDFs on the display, but it was still slow (I had to rotate the display and then I could view the PDFs in 2 halves). Not content to accept this fate, I started playing with some tools and found the free/open-source HTMLDOC which converts web pages into PDFs. Since the initial documentation I wanted to read is also in HTML (however it is in multiple pages), I gave HTMLDOC a whirl using some settings others have posted. Using the following settings:

htmldoc --webpage -f book.pdf --textfont Helvetica --fontsize 18 --left 1mm \
--right 1mm --top 1mm --bottom 1mm  --gray --size 5.24x6.69in --textcolor black\
 --footer . --header . --browserwidth 800 --no-embedfonts

and then specifying 1 or more web pages, I was able to generate PDFs that are easily viewable on the Reader and pages turn quickly. To top it off, it shows the images which RTF wouldn't get me. While this isn't an automated process (yet), this does show me that I can get decent content on the device. In addition, Project Gutenberg has lots of titles that I can put on the device. There are been some talks on websites about RSS Feeds to PDF which would be real cool, but I haven't seen anything for the Mac.

I'll have to keep using this to see how much I really like it, but who knows, maybe I'll read more!

Software registration schemes; the good, the bad, the ugly

I've worked on a number of consumer products in my career, some with registration schemes, some without. What is the purpose of a registration scheme? Are people trying to prevent piracy? Are they trying to keep the honest people honest? Or is there some other motivation? For me, it is about motivating people to purchase the software when the demo has expired (in my shareware world). With some of my products, people use it, like it, and forget that the software is even working, so they forget to register. A registration scheme here has proven to be quite effective on my NotifyMail program. I had another program called PhotoCapture that had no registration scheme (I was young and dumb) and asked people to send me a postcard if they used it. I know it was used on various websites back in the day, but only got a handful of cards. That method clearly didn't work.

I worked on one product that had such sophisticated registration that it made the product hard to use. That and the fact it was buggy lead to its downfall. So is there a happy medium? In many cases, yes, as long as the software is useful and used frequently. In my opinion, if a product is used infrequently (there are some products that a demo version suffices for some), its value goes down to me and then maybe it needs stronger protection. I was playing around with a program yesterday that I had tried months ago while working on writing something that had a similar concept, but worked in a completely different way. Since I had tried the app, the demo expired and I couldn't play with it or reset my demo period. After about 3 minutes of poking around with Interface Builder, I discovered a serious flaw in their registration system (Interface Builder is a free developer tool that is available from Apple and ships with every Mac). They had 4 buttons on the registration screen that popped up; register (brings up a dialog to enter your code), purchase (takes you to a website), quit, and try. The try button was grayed out because my demo had expired. So in Interface Builder, I duplicated the try button, linked it to the tryAction, hid the original try button, and then ran the application. Oops. Now I had a working version of the application that I simply had to hit the try button each time I ran it. A simple code/design change could have fixed this. Instead of having a quit and a try button that were separate, have one button that had the title change depending on if the demo had expired and then have the action linked to "dismissRegisterDialog" where code behind that would determine if it should quit or should run in demo mode.

Of course I won't say which app this was, but a few more minutes with the registration code could go a long way. I don't think most developers should spend a ton of time on registration schemes as they will be broken by hackers anyway. I think it's important to make it hard enough that the casual person, even developer, can't break it. I definitely don't put in registration schemes that are hacker proof, but they seem to work good enough. In my next product, I think I may take a different approach.