…(upon looking at a co-worker’s code) that a class named DiskBurn would, well, burn DVDs or CDs. Setting aside the fact that it should be named something more along the lines of DiskBurner, it doesn’t actually burn anything. As it turns out, it never actually will – it’s going to create ISO images instead.
But that wasn’t what bugged me – for a variety of reasons, the specs were awfully hand-wavy for this part of the application, and I knew when I started working on DiskBurn that it didn’t do what we wanted. Because of the state of the spec, I was given a fair amount of leeway in determining the final form this feature would take, so most of the actual ‘burn’ code was left until I was finished with a different part of this project (and got back from vacation, which should be the subject of another post Real Soon Now).
Basically, the application is a web-based content management system consisting of a public search interface and an administrative back end. The administrative component allows a small group of archivists to add new documents to the system, tag them with searchable metadata, edit existing metadata, and tokenize and index the document so that the body of the document can be searched through the public interface. In addition, these archivists occasionally get requests for custom data sets that they ultimately deliver on CD or DVD. Their existing manual process takes weeks to complete; DiskBurn should create a downloadable disk image in under an hour, depending upon the size of the requested data set. If everything goes according to Hoyle’s, the longest part of this process for the archivists should be downloading the image (they’re located overseas, with cranky connectivity; we’re hosting the website) and subsequently burning it to disk.
No, what bugged me was finding code in DiskBurn that searches the data set (because you need to create the custom subset, of course) – in an application that already has classes dedicated to search.
Shoot. Me. Now.