History is a Pain in the Ass

One of the features I wanted when I started Researcher@Large was a script that would pull an item from "today's" date and show what had happened on that same date during the war. I'm not programmer, but I can learn enough to be dangerous. I took a couple of stabs at it here and there, but it wasn't until about three years ago that I got up one morning and managed to create something that actually worked.

Of course, that left me with the problem of then having to WRITE all those events down!

I started in on it, and discovered that it's a slow process, if one wants to do it right. There are any number of sites that offer dated information, but often they simply scrape other sources without fact checking or adding anything to the data; it's simply a churn of what has been said before, sometimes in error. There are some good books out there, but they're just a start, and typically focus one one subject.

So to create a list of at least one event for each year for each day can take a while. I started building up a list of web sites that had good, dated information:
http://www.ww2australia.gov.au/
http://www.combinedfleet.com/
http://www.ibiblio.org/hyperwar/USN/USN-Chron.html
http://www.burmastar.org.uk/
http://www.kensmen.com/chronology.html
These aren't all of them, by the way.
 
I would read through the online copies of books about specific battles and campaigns:
http://www.ibiblio.org/hyperwar/USMC/USMC-C-Guadalcanal
http://www.ibiblio.org/hyperwar/USMC/USMC-M-Okinawa

And of course, hit my library of books, looking for events.

But there are other problems as well, even with a number of good sources. How accurate are sources? Were the dates based on local time, or does the international date line come in to play (As far as Japan is concerned, the attack on Pearl Harbor happened on December 8). Then, when researching one day, you might find a source that had a whole bunch of good items for other days; do you stop that day or simply note the good source and come back to it later?

I've had to break things down and take it in smaller chunks; the first time I tried it I burned out, and that's something I try very hard not to do; this is a hobby, and it needs to remain fun so that it doesn't die like many other sites. This is something that also happens with some of the larger damage reports I post; the initial OCR of a document may go pretty quick, but the amount of back-channel work dwarfs the original scan and OCR, and I always finish a large report with a lot less enthusiasm than when I started it. So I try and build up a volume of shorter works that I can present while I'm working on the larger ones; that way I'm under less pressure and can take a day or week off if I need a break or life gets too busy.

The "Today in Pacific Theater" history for July became one such monster, but I'm happy to report that the month is done. I started in the middle of June, and had the first ten days done soon enough, but after that things bogged down and became more of a slog. I was working each night just to at least finish the next day's entries. It ate nearly all of my time; I started a new camouflage document at one point when I had an hour to kill without an internet connection, but otherwise my total time on Researcher@Large for this month was a feature that most people probably either won't see or pay much attention to. But I do believe it's an important feature.

For, despite being a pain in the ass, history is something we need to connect to in order to remain connected to it and understand the impacts and implications of events. Events will pass us by sometimes, so I think it's nice to have an extra reminder that there was something important happening to someone, somewhere in the war.

4th of July, 2012

Some shots from tonight's fireworks at Lake Kathleen. Happy Birthday to the USA!

Volume

I've been gearing up for a trip to NARA II in College Park this October. One of the topics I'd like to make some progress on is the 1945 shift to neutral camouflage colors on Navy ships. The colors were ordered into use in February of 1945, but the it's a question as to when and if certain ships were painted in them.

So, I'm going through some of the online finding aids in "ARC" I'm going through all of the folder listings for "Commander, South Pacific Area and Force. (04/13/1942 - 09/02/1945)" which is 175 boxes long. Obviously, I am not tearing through these very quickly.....

I'm at the Logistics section right now, and there are 18 folders listed with the L21 designation, which covers shipments. There's also a separate file code under materials for paint, JJ52 (no hits in this accession), and one under ships materials, S19. Complicating the problem, camouflage and paint directives were sometimes issued under administrative orders (A codes) or fleet orders (FF codes). I digress....

These 18 folders occupy boxes 28 through 31, and since all ARC lists is the folder titles and file codes, I don't know if there's actually any paint information in them or if they only deal with the base commanders staff car replacement. What's also adding to the volume of work is that this accession was broken down into three sections, so those 18 folders are just the first set; there are two more

Then, of course, there are the twenty-three BOXES of secret  memos; I've found at least two memos in other archives from that group:
http://www.researcheratlarge.com/Ships/S19-7/1944JulyPacificPTCamo.html
http://www.researcheratlarge.com/Ships/S19-7/1945FebruaryCVCamouflage.html
Since the Fleet Maintenance Office was responsible for camouflage paint, this is another area to hit.

And this is just one accession of records.

Memorial Day, 2012

'Twas late in the day when I received this.... I had mulled posting something, but had found nothing that felt adequate. This takes care of that. In memory of all who made the ultimate sacrifice..... http://video.google.com/videoplay?docid=-2487638612433437293&q=Vetera

Research Time-lapse

Finally managed to pull off something I've wanted to do for a bit; a time-lapse video of what it's like at the Seattle branch of NARA. San Bruno is similar; I haven't been to the new Riverside one yet. NARA II in College Park is much different. Record types are divided by floors (textual, cartographic, film, photographic) and instead of the 8-15 the regionals can fit in they can handle maybe hundreds on the textual records floor. The nice thing about the regionals is that they're a lot quieter, and Seattle has one table off to the side that I could set up a camera at without getting one else in frame (a no-no without prior permission).

(Note - the video is a little wider than what the format of the Blog will allow... click on the "Researching at the Seattle Branch..." text on the top of it to open in a new window if you'd like to watch.)

What this illustrates is the basic process of looking for information and then capturing it. One box of records at a time on the table. One folder from that box out at a time, with it's position marked so that you return it to the same place. One sheet of paper out of that folder is allowed out at a time, so that there is less of a chance of the records getting mixed.

There is no text search. There is no google. There is simply page after page of paper that must be gone through some how. There are no document-feeder scanners; the presumption is that every document you handle is the last surviving copy, and thus you want to avoid destroying it with a feeder jam. Some people work around the slowness of a scanner with either a fast, expensive scanner or a good camera mounted in a camera stand, but I prefer to scan over camera as I don't really have a time constraint and the quality is much better. This is more of an issue with photographs than textual records, however.

Research at the archives, while rewarding, does not happen at internet speed.

Normalisation of Deviance

A little I.T. digression from the normal History stuff. I came across the term "normalisation of deviance" recently in an article about the Hubble Telescope mirror fiasco. It's a term that has application in the I.T. world, and one that any good support person or company should strive to notice and avoid.

We run into it a lot when there's a rush to complete a project, or when there's a great number of tasks firing at the same time. The trick is to keep track of all the open items and not let them fester. Not only can they lead to loss of data and heartache for a client, but as an outsourced IT consultant, it can lead to loss of a client even if nothing "bad" happens and the aberration is discovered in advance of a catastrophe.

I always tell our new consultants, "backups are your most important insurance policy." Yet since they are pretty boring they're one of the most overlooked. It's the first thing I look at when taking over a new client from another company, and I'd say about a third have some sort of issue, from a particular server that doesn't back up successfully, to in one case, an entire very expensive infrastructure that had no backups even after 18 months of implementation!

They are a regular "target" of normalisation of deviance; but often we see things like patching and anti-virus that doesn't update properly in a state of deviance. Like a space disaster, things go fine until all of a sudden the IT support group gets into a cascade of failures, where one small failure begets a larger group that winds up unhappily for everyone involved.

An early 2012 look at visitors

Hadn't been planning on doing this, but since I had to try and figure out how many of my readers are still using dial-up internet, it was a good time.

As of March 25th, 72% of all visitors are new, and 27% of you are returning visitors.

* 45% of the site visitors are using Internet Explorer (46% IE8, 40% IE9, 11% IE7, Thankfully just under 2% on IE6, and two visits on IE10, of which one was me testing)
* 25% are using Firefox (57% on version 10, 11% on version 11, 7% on version 9, 3% on version 8, and just under 9% on versions 4 and earlier.)
* 15% are using Chrome (.6% on version 18, 91% on version 17, .6% each on versions 16 and 15, and .42% on version 12)
* 9% are using Safari (Build numbers are a bit weird - 25% on 7534.48.3, 8% on 6533.20.27, and ~55% on 533/534.X.X)
* 1.75% are using Opera (3.5% using version 12, 85.5% using version 11, with 8-10 at about 1.75% each)
* 1.6% are using an Android browser (Tablet or Smart phone)

* 85% are using Windows (46% Win7, 39% WinXP, 14% Vista, less than 1% total "everything else")
* 7% are using Macintosh (27% 10.7 "Lion," 46% 10.6 "Snow Leopard," 18% 10.5 "Leopard," 8.5% 10.4 "Tiger")
* 2% are using iPad (no version info)
* 1.6% are using Android (13.5% version 3 variants, everything else some version of version 2.3 or 2.2)
* 1.2% are using iPhone/iPod (no version info)
* .75% are using Linux (no version info)
* .09% are using Blackberry (no version info)
* .03% are using Chrome OS (netbooks)

5% of the visitors were from mobile devices and 95% were from more traditional laptops or workstation/home systems