Apple makes switching phones incredibly easy

One of the things I've always dreaded about switching phones the laborious process of entering the phone numbers of friends and family members. I've got all those in my Mac Address Book so why can't I sync it straight to my phone? I've gotten used to doing so with my Palm Centro but wasn't sure it was easily accomplished using my old Razr.

Apple comes to the rescue again. It turns out they've included enough intelligence in their Bluetooth software that I can choose groups of contacts from my Address Book to sync.

But wait, there's more. I was also able to add my favorite wallpaper image to the old phone by using Apple's Bluetooth browsing feature. In the future, I'll be able to transfer photos taken with my cell phone via Bluetooth instead of being charged a fee for using the phone's data connection.

The procedure for accomplishing this was pretty easy to figure out... after all, it is an Apple. But here's the procedure spelled out if you don't feel like noodling it out yourself.

I did a little work with Google but I didn't see a similar procedure available for Windows. That doesn't mean it doesn't exist but if it does, it must not be quite so obvious as Apple's.

A farewell to Palms

The phone portion of my Palm Centro has been slowly dying for the past few months. The signal strength varies wildly over time. Occasionally I'll look at the Centro's status display and see the full 4 bars indicating a strong signal. Minutes later at the same location it may show a single bar or worse yet, the dread "SOS Service Only" message. A visit to Google indicates that this is a very common problem with Centros.

So much for my attempt to combine PDA and phone functionality into a single device. I had such high hopes for the Centro. Having been a Palm PDA user since I got the original Pilot as part of a special employee purchase back when I worked for U.S. Robotics, I've grown to depend on my PDA heavily. Palm PDAs provided the ideal combination of application support and built-in features. If only their phone capability worked as well as the rest of the device.

I've been doing a bit of research and so far I don't see a suitable replacement device, at least not among the subset of devices available from my cellular provider. The iPhone comes closest but I'm too cheap to want to be saddled with a $30 per month data plan when a little planning can make it completely unnecessary. The iPhone doesn't make any sense without the data plan. Many of the other smart phones suffer from poor battery life, poor signal quality, crashes, or insufficient application support.

For the time being I've switched back to my old Motorola Razr phone which despite its age has much better signal strength and battery life than the Centro did when it was new. I'm using the Centro without a SIM card as a standalone PDA device.

I'm considering the Motorola Q Windows Mobile device. I can find Windows Mobile equivalents for all the applications I've come to depend upon (contact management, calendar, to-do list, memos/notes, database, and secure password storage). I've got a few months before I'm eligible for a reduced cost equipment upgrade. I'm hoping a better option presents itself between now and then as the prospect of switching to a Windows Mobile device doesn't thrill me.

FAT32 sucks!

I'm doing my monthly offsite backups and am seriously frustrated by the limitations of the FAT32 file system again. FAT32 is something of a de facto standard since most external hard drives and USB flash storage devices come pre-formatted with FAT32. However FAT32 carries with it the limitation that the size of an individual file may not grow beyond 4 GB. Many backup programs don't handle this limitation gracefully since this requires the backup program create multiple output files.

So what are my options for getting around this limitation? I'm currently using external drives with 2 partitions equally split between FAT32 so the Windows machines can write to it and HFS so our Macs won't be limited by the arbitrarily small maximum file size. Another option is formatting the entire drive with NTFS and using MacFUSE/NTFS-3g to allow the Macs to read and write to the NTFS partition. I like this approach better as it doesn't force me to correctly predict how much space I'll need for each type of machine.

Ultimately I think I'd prefer to use drivers to allow me to mount, read, and write to Linux EXT file systems but this requires more investigation. This is mainly because I really hate the thought of trusting my Mac data to NTFS.

Vim continues to amaze me

Every time I think I've learned all of Vim's tricks, it manages to surprise me with some new feature. There are two things I've discovered recently which have made it more enjoyable to use.

The first is Vim's ability to edit files on remote systems which can be reached via scp or ftp. Since I frequently need to edit files on embedded Linux systems which don't have X11 installed, this feature is a huge timesaver for me. The following commands illustrate the basic commands for either editing a file over scp or ftp.

gvim scp://username@system//home/username/filename
gvim ftp://username@system//home/username/filename

This feature is referred to as NetRW.

The other thing I discovered was completely by accident. I was using MacVIM (my favorite Mac port of the GUI version of Vim made available from the fine folks at Google) when I found I could drag the file icon off the titlebar and into a bash shell. Once dragged into the window containing the bash shell, the full pathname of the file being edited was placed on the command line. Granted this isn't something I need to do often but when I do, it saves me from having to manually type a long pathname.

Python is slowly winning me over

I've been learning Python at work and I have to admit that it's slowly winning me over.

I was skeptical at first. I've been a low level programmer (firmware, diagnostics, operating systems, device drivers, etc) for most of my lengthy career. A mixture of C and assembly language has served me well for most of that time with a little shell scripting thrown in for good measure.

When I started my current job, I discovered they use a mixture of C and Python. The parts of the product which aren't performance sensitive such as the GUI are implemented in Python. This code is much smaller than C code to accomplish the same purpose would be. Thanks to the interactive nature of Python it's also much quicker to develop this code and to get instant feedback.

What finally won me over was examining a short script designed to generate some proprietary TCP/IP packets. This script had a small problem when talking to one of our products. It produced the integer and float portions of the structure with the wrong endianness. A little searching with Google showed me that adding a single "<" character to the format string used by the "struct" module (which prepares individual fields within a structure) would correct the problem.

It took a minute for the full impact of that to sink in to my deeply ingrained C mindset. A single character would correct my problem. Couple that with the fact that the script to generate these packets was probably less than a third of the length of a comparable C program and I was forced to admit that Python is much more useful than I originally thought.

I was tempted to end with a comment about old dogs learning new tricks but I suspect that phrase is far too tired to carry the proper impact. I am finding that old engineers can learn new tools with sufficient incentive. Seeing how much more productive I could be with solid Python experience under my belt is more than enough incentive.

The Neuros OSD is so cool!

I just watched part of the first recording from the Neuros OSD (a Linux based DVR) my wife got me for Christmas. What a cool little device! I'm serious about the little part... it's only about 5.5 inches square and just 1.25 inches tall. Just check out the image. The device itself isn't much bigger than the small remote included. It records programs onto SD or compact flash cards. There's also a USB port so you can record to a USB thumb drive or hard drive.

The first order of business was to upgrade the firmware. There are two ways of doing that. If you've connected the Neuros OSD to an ethernet port, it can upgrade the firmware directly. If you don't have a network connection, you can download the new firmware image to a flash card and upgrade from that. During the ~10 minutes which the upgrade requires, the Neuros shows you a little pong game on the TV screen. The on-screen score appears to be the percentage of the upgrade currently completed.

Is it perfect? Not exactly but it's pretty darned close. It's especially attractive given the low price. It appears to have been primarily created for recording a single recording at a time. That fits my requirements nicely since this was just intended to supplement our existing full-featured DVR. Occasionally my wife will have a couple simultaneous recordings set up which takes up both tuners. It's nice to have the option of not worrying about how much space is used on the main DVR or whether both tuners are spoken for at the time my obscure SciFi program is on. There's a couple other restrictions. Your connection from the set top box must provide composite video (one of those 3 connector cables with 1 video and 2 audio connections).

The other restriction is not really a shortcoming of the Neuros but rather of the FAT-32 format used on many of the flash devices. FAT-32 has a maximum file size of 4 GB. That's probably somewhere between 3 and 3.5 hours of recording. So you might need to choose a flash device capable of recording the maximum length program you'd be interested in watching. If you're keen on catching some type of program marathon, you're probably looking at a small portable hard drive rather than a flash device.

Well, enough of my blathering on about it. Check it out for yourself at the links above. It's a very nice gadget and a useful too.

The sound of many Zunes freezing...

My neck is sore from so much head shaking over the Zune freeze problem. I would have hoped that the development teams at Microsoft would have held regular code reviews which should have caught a glaring error like this one. I understand why they may not have done so. It's quite hard to get people to review your code if company procedures don't demand it. This is especially true in consumer electronics where the schedules seem to be compressed to ridiculous levels.

So what do we learn from this public relations fiasco?
1) Code reviews should be mandatory, not optional.
2) Developers must do much better unit testing. In the past I've had coworkers criticize me because I insist on running functions under a debugger to force execution of tough to test code paths.

I'm always amazed that software engineers can take such a cavalier approach to verifying their code performs as expected. Then again I'm old and cranky. Hey you kids... get off my lawn! :-)