It’s dawned on me that I haven’t said much about my new job yet. One of the major downsides to leaving California was giving up my job at HighWire, but I’m happy to report that I like my new job at U Penn’s School of Medicine even better. I’m in the Information Services group. I don’t have as much customer contact as I did at HighWire (which I miss), but on the technical side, there is a much greater breadth to the work. Instead of having a primary focus on just scripting, I’m doing a lot of application design and database development. My current projects are a web-based email account application system, and revamping the Med student online application process. All the tools used here are new to me – PHP, Oracle, Smarty, and some home-grown tools – so that also helps keep things fresh. I’m working in a small group of about a dozen very likeable people, so I’m making new friends too. Unfortunately, my position is funded for only one year. It looks like there’s a good chance it’ll be extended for a second year, or made permanent, so I’m crossing my fingers. I’ll find out when the budget is finalized for the next fiscal year, which will happen around the end of the summer.

The application architecture that’s been deployed here is the best I’ve seen. A typical architecture for web applications consists of a database backend, Java or CGI scripts as a middle “application” layer, a templating system for the front end, and maybe a security layer (typically handled through the web server or the application layer). The architecture here has 4 layers: 1. the database (Oracle) back-end; 2. the LDL (Logical Data Layer), which provides role-based access to the database (you define your queries in XML, along with column and row based access rules, and it’s then compiled for better performance); 3. the “WI-Engine” which serves as the application layer, written in PHP (it allows you to design your pages in an object-oriented fashion – using “panels,” “subpanels,” and “dialogs” which can communicate with each other); 4. a template layer, using Smarty.

The WI-Engine took the most getting used to, as I had to orient myself to thinking of all the page components as objects. Once you get going with it though, it’s very efficient. The LDL is cleverly constructed. Since the applications we design are for use within the School, you always run into issues such as what a student can do with an application vs. what an administrator can do with it. All those access rules are clearly defined in one place, and it’s sitting just above the database itself, so it’s quite unlikely that someone could hack through any loopholes in the application layer.

I’ve begun work on a daunting task: the Mike Toppa Archiving Project. I have many shoeboxes full of floppy disks: Commodore 64 5 1/4″ disks, old PC 3 1/2″ disks, Zip disks, and a few Mac disks. These contain research papers, correspondence, software (including programs I’ve written), games, and lots of data. With my current PC, I obviously can’t access the C64 disks, and I can’t read about half the data on my old PC and Mac disks due to file format incompatibilities. For current versions of MS Office, Microsoft no longer provides filters for my old Ami Pro (word processor) and Quattro Pro (spreadsheet) files.

Aging computer files are actually a very serious, worldwide problem, as described in this excellent Technology Review article: Data Extinction. “The layman’s view is that digital information is more secure, when in fact it’s far more ephemeral…We know how to keep paper intact for hundreds of years. But digital information is all in code. Without access to that code, it’s lost…more and more of what matters to us is digitally produced, and we can’t guarantee that any of it will be usable 100, or 10, or even five years from now.” The article describes four possible solutions (see the table at the bottom of the article) but the only one that’s practical for your average person is “migration,” so that’s what I’m doing.

I mentioned in an earlier post that I got may hands on a newly developed network card and a web server for my C64. I spent some time this weekend trying to get it talking to my home network, but haven’t succeeded yet. Once I do, I can transfer C64 disk images through its web server, onto my PC. At that point, there’s a PC program I can use that will extract files from the disk images. My primary goal is to get at text I’ve written (mainly letters and research papers – I used my C64 all the way through 1992). The C64 used a variation of ASCII, so I should be able to extract the majority of the text. It would take forever to migrate the hundreds of games that I have, and others have already migrated most of the old games anyway, so I don’t think I’ll bother (you can download C64 games to your PC from various sites and then run them with C64 emulator software).

For my old PC files, I still have the install disks for the old software that can read them. But I don’t want to pollute my PC with those programs (since they’re Windows 3.1 programs, I doubt they’d uninstall properly). Maria’s old laptop is overdue for a full re-install of the OS, so before doing that, I’ve installed my old versions of Ami Pro and Quattro Pro there. I’m converting everything to rtf and csv format, which I’m hoping are generic enough to keep them compatible with whatever kind of software we’re all using 10 years from now.

The last step is to put everything on CD-Rs. I’ll go from 5 shoeboxes of floppy disks to probably less than a dozen CDs. Of course the problem there is – despite claims that they’ll last 100 years – you can actually end up with unreadable disks in as little as two years. See The Myth Of The 100-Year CD-Rom. So I guess I’ll just have to regularly make copies of them until something more durable comes along.

Wish me luck!