A list created as of March, 2004: Open-Source Diabetes tools at sourceforge.net. This list was forwarded as a base of investigation for a Debian-oriented dev list.

I also located a Germany-based product for diabetes tracking in the Symbian OS; unfortunately the screen shots of the product only depict it on the PC side and the UI is too intimidating for the general user, I believe.

There are a passel of tracking programs available for Palm, and have been for years, so the market is pretty well-developed. However it’s really a Symbian product we need.

I have been discussing how valuable a blog-like tool for diabetes users would be. I wonder if it’s possible to develop a plugin for the main blogging tools that would allow the user to select the kind of entry that they will make. I envision something could capture the dietary and blood-test information separately and allow non-publication, password-based access to the data, easy data transmission from the tool, etc, all while allowing the user to blog in the customary fashion as well.

An ideal use of my imaginary ‘diablog’ tool would be as a destination for the testing data, synching when the user synchs their PDA data.

Many meters also have onboard data storage and transfer ports. Unfortunately the tools for getting the data out are mired in the high-castle world of medical suppliers, and of course, medical data is a privileged class of information as well, which might well complicate liability for tool-providers aiming to make the datastream transparent.

macosxhints – 10.3: A script to create a segmented disk image. Possibly of use.

I have been thinking about backup for obvious reasons. In an ideal world, I would prefer to back up to nonvolatile, disposable media such as tape or discs, but the fragility and slowness of tape and the relatively small capacity of discs makes these choices currently untenable. Like others, I’m afraid I have concluded that hard drives are the only solution for home backup at the current time.

With that in mind, I conducted a pricing study, using recently completed eBay auctions as the basis. I did not account for shipping, speed or other product details, crunching only the raw closing price. The URLs in the table will not provide the same data I employed, but rather the current set for the searches I employed. The column labeled ‘Average price’ contains exactly that, a simple average calculated against the first page of results returned from ebay.

Here are the results:

This table corroborates the data seen above. The most economical choice for obtaining backup drives is the 200gb class.

It should be noted that the average sale price reported for the 200gb product class is actually higher than the $89.95 price offered by at least one merchant using the eBay ‘buy it now’ option.

In conclusion, these are bare drives intended for either internal mounting or for mounting into a separately-purchased case, which will run under $50. I have heard of folks swapping their backup hard-drives like tapes, but I believe that this is an impractical option. I don’t have a budget developed for this yet, as I need to tally what I have to address in terms of data. However, I think that an additional 400gb should provide me with sufficient storage space to implement a scheduled full backup and subsequent incremental backups on a weekly /daily schedule.

Dan Bjoregren’s SpotBus! presents a quick-loading, simplified UI front-end to Metro’s Trip Planner transit information service. [via Tom]

He’s done this by stripping away the in-Metro navigation chrome, adding some pre-loaded landmark-name data to help populate the form on entry, and setting the default time of travel to the current date and time.

He notes that the project is all his, not affiliated with Metro, and I applaud his effort. Metro has some seriously good stuff available – comprehensive route schedules, the bustracker Java map that display the physical location of all busses in a given area, and more. But the services are implemented in ways that make it difficult for outside developers to do more than what Dan has done here.

I have written about this more than once.

My particular desire is that the real-time bus arrival data be made available in a lightweight, fully parsable format, so that independent developers might be able to, for example, deliver the data to the desktop in a floating ticker window. The same data could than be easily made accessible in several PDA and cell-phone oriented formats (this implementation may actually meet all my requirements), so that the user would set up a list of the usual bus stops they patronize, and on-demand, learn which buses are the next ones to arrive.

The basic code for this is already done; the people who developed Tracker at UW wrote a javascript implementation of the service. Unfortunately, I have been told that there is no way to create ad-hoc location-specific stop tickers; the feeds that power the six stops are custom-parsed server-side and no further location feeds are available, which is a shame. The service itself is physically deployed on several bus-shelters throughout the Metro service area. I corresponded with a member of the development team, who informed me that my feature request would not be met, for several reasons, not least of which being that the grant for the project had been completed and the project had no further allocated development resources. In my recollection, a request that the codebase be made open source was not responded to.