Someone - not me - suggested putting a terminal on the shop floor so that the workers could scan a bar code on the product, where this bar code contains the EC number. Magically the blueprint would appear on the computer's screen. This is fairly easy to do within Priority, as the bar code would lead directly to the EC record, where the path to the blueprint is stored. Then someone asked whether this could be done outside of Priority: my initial thought was that this would not be possible, as the required files are stored in a labyrinthic directory structure, where the target files are several directories deep.
Then the penny dropped: I could write a program that receives a barcode for input then performs a recursive search starting with the top level directory in order to find the required file (displaying the file at the end is trivial). This would not be fast but at least it would work. Writing this recursive search was slightly tricky, as most of the examples that I found of recursive directory search simply create a list of all matching files as opposed to looking for one specific file. Another hurdle was that within one terminal directory there could be several files for the same EC - the most recent version is the target (coding this turned out to be much simpler than I originally thought).
So I wrote the program, going through several revisions, tested it at home with a much simpler directory structure and a barcode reader, then tested it at work. The program fulfils its requirements, although it's slow - because of the search.
Last night I was walking the dog when I had another bright idea: instead of constantly performing a recursive search for one target file, I could write a program that performs a complete recursive search, saving its results in a file, then update the current program to search the file (that is loaded into the program's memory via a stringlist). This of course is very fast. Should the target not be found in the stringlist, the original recursive search algorithm gets called; this would happen if a new EC has been created since the directory structure was last mapped.
Writing the mapping program was very easy, being based on the original program, but without the user interface and without the complications of looking for a specific file. I had trepidations about the amount of time that this program would required to create a complete map, but had I thought more deeply about it, I would have realised that it wouldn't require much more time than the current program required to find one file. True, I am 'pruning the search tree' the moment the target file is found, meaning that the original program doesn't have to search the entire directory tree, but I get the feeling that all the target files that are searched appear towards the end of the recursive search, so pruning doesn't save that much time.
But 'the proof is in the pudding': after writing the mapping program (and testing it at home), I ran it at work. The program required two or three minutes to build the directory tree! I had been thinking that it would take half an hour or more. Once I had the directory tree map/index, it was a simple matter to include this in the original program that now works very fast. It's not instantaneous, but I think that the slight delay is due to executing the PDF viewer.
Moral of the story: walking the dog provides one with time for unconstrained thought. As always, these bright ideas seem so simple in retrospect that makes me wonder why I don't think of them earlier. The reason is that we are curtailed, 'blinkered', restrained, in our thinking, and one has to get out of the work environment (by walking the dog) in order to free oneself of the restraints.
No comments:
Post a Comment