Lightning!

Texas has been experiencing its worst drought since the 1950s, so it is understandable that we get excited when a little rain comes our way. I get doubly excited because it gives me an opportunity to photograph lightning. A storm came through this evening, bringing some much needed rain and some Big Scary Lightning. I started off photographing from the back porch, but self-preservation kicked in after a few minutes and I moved inside and set up at a window. Here is the best shot of the evening:

The little smudges that dot the image are water drops falling from the roof. The odd device to the lower-right is a satellite dish.

I can not emphasize this enough: LIGHTNING IS DEADLY. If you can hear thunder then you are well within the danger zone for a lightning strike. I do not recommend that anyone attempt to photograph lightning; but, for those of you who have made up your minds that you are going to do it, here are some guidelines that I follow:

• Set the camera to Manual mode.
• Focus the camera on a distant object. I use autofocus if it is bright enough outside. Once focused, I turn off autofocus.
• Lightning images are best made at night.
• Pick an area of the sky that looks promising for lightning activity. This can be hit-or-miss, depending on the nature of the storm. Move the camera as the storm progresses to increase the chances of capturing lightning.
• Use a steady tripod and place the camera in a location where it will not get wet or blown over.
• Set the ISO to a low setting (I use ISO-100).
• Take 5-second exposures (shorter if the sky is bright) to help bring out the surrounding features. Also, longer exposures mean that the camera will spend less time processing the image and more time imaging the sky. Remember, lightning is fast!
• Use the lock on the remote control cable to take multiple exposures. 99.9% of the images will have nothing of interest in them, so expect to take a lot.
• Work from a safe location! Outdoors and near windows are not safe locations. Set up, lock the remote control, and get to safety!

A Love-Hate Relationship

I have a love-hate relationship with the telescope mount that I use at the observatory. For reasons that I have yet to determine, it works very well sometimes and not so great other times. I will spend several hours trying to tweak the thing and the results will be mediocre, which is a shame considering that this is supposed to be a high-end mount.

Maybe it's me, but on the other hand I can set up my little Vixen SP mount with the ST80 and get very good results with a minimum of fuss. (One major difference, though, is that the ST80 has a much wider field of view, and so is a little more forgiving of tracking errors.)

Anyway, I finally got to spend some time working with the Epsilon-200 after a long hiatus. I battled the mount, which apparently thought it was on another planet, for a couple of hours and managed to squeeze in about two hours of imaging. All of my intended targets had either set or crossed into the light pollution of Huntsville (why didn't I use the light pollution filter???), so I picked the following items to image:

Messier 2, Epsilon-200 on NJP mount, 16x60 + 8x30

Messier 29, Epsilon-200 on NJP mount, 13x90

NGC 6992, the Eastern Veil; Epsilon-200 on NJP mount; 9x180

Addendum:  The right ascension motor had come loose on one side, resulting in the tracking errors that plagued me the night that I took the above images. The problem became obvious while slewing the scope during a star party--the dust cover that protects the gears began scraping one of the gears as the motor slipped further down. After reattaching the motor and balancing and aligning the scope, everything started working fine.

The Server Farm

I was a Database Administrator (DBA) in my previous job. We were a highly specialized shop in most respects, which means that different individuals handled specific tasks. For example, as a DBA I was not allowed to set up virtual servers or allocate resources to existing servers, and I had limited authority to make configuration changes at the operating system level. As a result, I sometimes found it difficult to guarantee system integrity. This lead to a lot of personal stress, so as a stress-relief exercise I made light of a particular series of events that occurred during my last year of employment. I shared this story with my coworkers in bits and pieces as the events unfolded and they found it entertaining, so I thought I'd share it with the world at large.

I've included some additional commentary to help explain the circumstances a little better.

Mainframe had a database that was one of the primary sources of information used by my employer.  Directly accessing the mainframe for daily reports was impractical because of performance issues.  I used the DRDA gateway to copy the relevant data into the Prod database on a regular basis and ran the reports from there.

The conversation between me and the Network Person went something like this:

NP:  "Are you using Test?"

Me:  "No.  I am not doing any testing today.  Do you need to take it off-line?"

NP:  "Yes."

I interpreted this conversation to mean "We, the Network People, need to reboot Test because we are using it for some nefarious purpose of our own, such as World Domination."  It was a perfectly reasonable assumption since both the Network People and I used this particular server for a variety of testing purposes.  What the Network Person really meant was, "We, the Network People, are going to reformat Test's hard drive and turn this machine into a menial Zombie Slave."

Reports was brought on-line for a single user who did a lot of complex queries and reporting.  It was determined by our administration that this individual should have a separate database in which to work.  Reports was supposed to be simple:  one machine would have all of the necessary tools, including the database, running in an easy-to-use GUI operating system.

I never did find out why Reports and Mainframe couldn't get along.

Most of Dev was set up to parallel Prod, so it was a fairly easy operation to "graft" Dev to Prod. Still, it made me look like a Genius Miracle Worker to most of my peers. (Those who didn't think I was a Genius Miracle Worker probably didn't understand the setup, anyway.)

Starting at this point, Reports was only used for hosting the database. The reporting tools were installed on a different server.

There was a long period of time between the slide above and the slide below. We had to coast along like this for a while because other projects had to take precedence.

Certain batch processes on the mainframe would lock entire tables, causing Prod's jobs that read those tables to time out. The scheduling of the mainframe batch processes seemed to change unpredictably.

Well, that's the end as far as I'm concerned. My successor will need to pick up the standard and carry it forward into the battle now. I wish him or her all the best.