I am delighted to introduce FOTM readers to a very special guest columnist — Peter Offermann.
His post today (see below) is prompted by the mare’s nest of technical issues that arose from my post of Jan. 16, 2013, “Guide on how to talk to children about Sandy Hook 4 days BEFORE massacre.” That post is about a PDF document by the Crisis Management Institute which, we suspect, had been uploaded onto the net before the Sandy Hook massacre. If true, that would be an extraordinary feat since the document was on how to counsel children and teachers about the massacre.
This is the first of a series of essays by Peter.
For FOTM’s other posts on the massacre, see our “Sandy Hook Massacre” page.
~Eowyn
AN ANALYSIS OF ANOMALIES ON www.arlingtonlocalschools.com
By Peter Offermann
To start with I’d like to give you a brief backgounder on the kind of experience I bring to this analysis. For approximately 12 years I owned and operated a computer support company specializing in developing custom software solutions within several different industries; also for unions and regional governments. The software was mostly developed in a database environment to provide solutions such as custom point of sale, payroll, inventory control, accounting, storing and retrieving digitized records of all kinds, personnel / union member management, meeting minutes management systems and so on.
The code was developed by myself from scratch. As an example I wrote payroll programs for a number of industries, some of which had extremely complex compensation procedures that ordinary payroll programs couldn’t handle. I was one of a small handful of people in Canada that understood Revenue Canada’s constant flow of new payroll deduction laws well enough to translate them into computer algorithms capable of calculating deductions without resorting to data tables which were the norm at that point in time. These algorithms are incredibly complex logical structures with very serious consequences from erroneous logic. Mistakes could quickly add up to significant amounts and much grief for clients from Revenue Canada.
I wrote binary search routines from scratch and developed indexing systems allowing fast retrieval from large data sets, and for enabling complex analysis of financial information.
My experience is not current but the fundamental logic of how data is handled in virtual environments such as databases is as relevant now as it was when I made a living from it. I do not know the current syntax well but understand what is being done.
Most of the confusion in the previous discussions we’ve had is caused by people not understanding that there has recently been an enormous change in the methods used to create websites.
Until just a few years ago websites were ‘physical’ objects.
The current generation of websites created in environments such as WordPress, Drupal and Joomla are ‘virtual’ objects.
It is important to understand the difference because the way urls act differs greatly depending on which kind of environment they are in.
I’ll explain the difference in a simplified example.
A normal human community laid out with access streets is a physical object. A single map of the community always holds true until physical additions or deletions are made. If Sally lives on street 1 and Joe lives on street 5 they will always have the same relative location to each other. If a delivery service needs to make deliveries to both the driver needs to go to one place first, traverse the distance between the 2 houses and then make the second delivery.
Imagine how happy the delivery person would be if he could physically rearrange Joe and Sally’s houses to be side by side when he had to make deliveries to both. It would save a lot of time and work. If he could do the same with all the other houses as needed when he had to make different combinations of deliveries he would be in heaven. Such a town is ‘virtual’ because the house relationships are not static, they can be rearranged constantly to serve any purpose. Virtual towns would need a whole series of different maps, one for each of the arrangements the town could assume.
Earlier websites are like physical towns. The developer decides how to lay the website out and the site always stay that way unless the developer makes changes. Such a website is a physical structure on the server’s hard drive using directories that never changed on their own. You always knew where Sally’s house [home page] was located. A URL / map of such sites never changes.
Newer virtual websites do not have their structures/addresses built directly on the server hard drive, they are instead stored within a database on the hard drive. Each house address/page/post is a separate record within the data base. A single record is all the information about any one unique location. If there are 100 houses in the community then there will be 100 records of houses in the database. To allow rearranging houses to specific streets there would also be a record for each street in the database.
The house records do not need to stay in the same place in relation to each other in the database. They can easily and quickly be rearranged to suit. If you want Sally and Joe to live next to each other on street 10 you create an index/map allowing the records to change to that position.
Each unique piece of information about a house in a record is called a field. Lot name is a field, owner name is a field, lot size is a field. There are additional fields for building indexes. If you have a field for street number on house records you can assign street number 4 to both Joe and Sally then sort the records by street # and joe and sally would both exist on street 4. If you changed your mind and decided that you wanted everyone in town to live alphabetical order you would resort the house records by owner name and all the houses would move around accordingly. The url/address in such an environment varies according to where the house currently is. It is not static like in a physical town.
It gets more complex than this in a virtual town. A house can exist in two places or more at the same time. Joe and Sally’s houses can at the same time be on street 1 and 4 for them and together on street 2 for the delivery guy/google bot. In this case each house would have 2 urls/addresses at the same time. Depending on who you are you would only see one or the other of the addresses.
In a virtual town a record/addresse’s url is determined by it’s place in the index the database is currently ordered by.
Sally and Joe’s Urls would be determined by the Living Index and Delivery guys Urls would be determined by the Delivery index.
I’m going to leave off here to get this thread started.
Pretty dry stuff so far. Hang in there I’ll get right to the interesting stuff with the next installment.
Any questions?