On the organization of organization: Blog 3

Since I failed to discuss something in my last blog that I am in charge of organizing I will start out this blog by doing so. I work for the information systems department for schweitzer engineering laboratories. My title there is intern desktop system administrator. Part of my duties in this position is to create and maintain a set of tools that are used to install software on all computers purchased by SEL. One of the tools used is a script that installs all of the drivers and software that cannot be stored in an computer image. A computer image is a complete backup of everything on a computer. By setting up a computer with the software that all computers at SEL need to have and then making an image of it allows us to apply that image to other computers and thus save the time of installing every single piece of software one every computer. However not all software can be moved about in this fashion and all the drivers that relate to specific hard ware must also be left out of the image.
For this reason I maintain a 500 line script that installs all of the left overs that could not be installed on the image. In order to ensure that each computer gets it's proper drivers it was necessary to devise a system to store the drivers for each computer model. In all the script supports some 20 different models of computer. Originally I decided the easiest way to store all the drivers for these computers was to create a folder named hardware with 20 sub folders, one for each computer model. Inside these subfolders were stored the drives for the model the folder was named after. The script would look up the computer model for the computer it was being ran on and then use a case statement to find the proper folder and run the right commands to install the drivers in this folder. A case statement can be thought of as a list of possibilities. After looking up the model of the computer it was being ran on the script would compare it to each of the 20 cases that made up the case statement. If it matched any of the cases it would run the lines of code denoted within that case and in doing so install the drivers for that particular model.
There were two problems with ordering the drivers in this fashion. The first is a matter of storage. While in general computer hard drives are dropping in price networked storage can still be expensive. This has to do with the need for data redundancy and the cost of maintaining servers. In addition to this the location I was storing the drivers in is replicated to several other servers world wide. This means that I needed to keep my hardware folder as small as possible so that it cost less and took less time to replicate to other locations. Many of the computer models we use at SEL share some drivers. My system did not allow for this. If two computer models shared a drive then I had to store that driver in the folders for both models. This is clearly a waste of space. The second problem with this organization scheme is that it required a case statement in the script. This meant that every computer model had to be listed and whenever we began using a new model of computer the script had to be edited to include it. Out of the 500 lines that made up the script perhaps 300 of them were taken up for this one case statement.
Recently I had cause to switch the scripting language used for the script. I decided to improve the system during this process. After careful consideration I decided to lump the computer models by series. Each model of Dell Business laptops belongs to a series. For instance model E4200 belongs to the 'E' series. It is common for computers within a series to share some drivers. So I changed the file structure so that in the hardware folder there were several series folders. They were named E_Series, D_Series, S_series ect. Within each series folder was a folder for each model in that series and a common folder. Most of the driver for each model were still stored in the folder named after that model but any drivers that were shared by the entire series were stored in the common folder. This allowed me to significantly reduce the storage space required for all the folders. It also allowed me to rewrite the script so that it pulled the model number, looked in the folder for that model and installed any drivers and then installed any driver in the common folder. If we begin using a new computer model we need only create the proper folder for it and the script will find that folder and install its contents. By doing this I shortened the script by more then 200 lines of code. While the reorganization was not strictly necessary for this new script to work it made coding the script a lot easier.
So there you have it, my experience with organizing and reorganizing. I would say I defiantly tend to be a lumper when it comes to organization. I would also say that this is a good example to contradict the book with as it is one instance when it was important to have just one of a digital object.

So on the book and chapter 4. I found this chapter interesting because I have never realized the extent to which human categorize. When Weinberger talks about the power of meta data to give us context for a statement I was amazed. I never before realized how much definitions are trees. The entirety of my understanding of the world is one enormous tree. I don't see it because I have been living within it my entire life. I am going to go ahead and keep up with the coding references here because it seems to mix well with this topic. Most programming languages require that you declare variables. A variable can be thought of as container with a name. When declaring a variable you are telling the computer 3 things. First you have to tell the computer to create something and refer to it by x name. X being whatever name you assign to the variable. Second you have to tell the computer what type of information will fill that variable. This is so the computer knows how to treat the variable. For instance I might tell the computer that the variable is an integer. The computer now knows that the variable will hold some type of number and so to treat its contents like a number. If I tell it to add 12 to the variable it will know I am referring to the value of whatever number is in the variable. Lastly you must tell the computer what is stored number should be stored inside this variable. This does not need to be done right away but must be done before the variable is used in any computations.
What I really want to do here is focus on the second part. When I tell the computer that the variable is an integer the computer automatically applies all the rules it knows to that variable. It can be used for math. It cannot be used to sort alphabetically. It can be used to store numbers. It cannot be used to store letters. I never before realized that this is how my brain works. If some is a bird it will have wings. It won't be able to breath under water. It wont have fur.
Many of the more modern programming languages no longer require a programmer to explicitly state what type of data will be store in a variable. This is largely because computers are fast enough to run tests against the variable to determine what type of data it holds and then treat it accordingly. I fell like this has a strong correlation to the Colon Correlation mentioned in the book. We are headed towards a system that allows anything be anything. The colon correlation system allows for almost limitless books. Only when we want some specific do we have to assign restrictions on the system. In the digital world things will be ambiguous until they are giving definition by our looking at them.