Friday, February 22, 2008

Operation Sleepy Eagle

Well, the veil has been lifted on Operation Sleepy Eagle. A cunning plan to surprise my parents on their 30th wedding anniversary. It appears that we've managed to sneak in the entire out-of-town family without any leaks (though, truth be told, you can never be sure).

My sister and I have been working out the details of this party for a few months, and it's a relief that it went off without a hitch. I picked up the out-of-towners at Westchester Airport at 11:30 and got them started at a local bar. After that, all I had to do was get Mom and Dad to the restaurant at ten past six.


Last night we celebrated three birthdays and a 30th anniversary. Mission Accomplished.

FYI: Photographically, I had a frustrating night. I changed a white balance setting in my camera a week or so ago and forgot about it. Since then I'd performed a firmware update so I wasn't sure why all of my photos had a nasty hue.

Lesson learned: When in doubt, reset the camera's controls. It could take me an hour to search through all the settings on my camera, but it would probably only take a minute to restore my settings from scratch.

Thursday, February 21, 2008

The moon and his buddies

It's been a few years since I last watched the moon disappear behind the shadow of the earth. The last time was in the fall of 2004 - I think. While I'm having a little trouble remembering the date, I recall perfectly sitting outside in parking lot of the Dunkin Donuts watching the moon turn red.

There's something very cool about watching the moon change shape before my very eyes. I think the reason it appeals to me is that it's almost like watching a time-lapse event.


The dim red light illuminating the moon makes it a far less formidable photographic subject as well. Under normal circumstances, when photographing a full moon, I need to dial my camera's sensitivity way down in order to expose any lunar detail. However, with the fainter moon, the surrounding celestial bodies pop out of the night sky. Last night we were treated to the planetary glow of Saturn to the left of the moon and Regulus above it.

So why am I writing about this? Well, I'm afraid I don't have a very good answer. There's something about freezing my butt off trying to get a shot that makes me want to talk about it.

Monday, February 18, 2008

Managed mobility

Have you ever been to dinner with someone who's cell phone would simply not stop making noises the entire night? If you have, you might have been sitting across the table from me.

I get a lot of text messages. Last month, I received about 8,000 of them.

Thats 8,000 little 'beeps'. Not to mention the countless number of emails that I get both at the office and on my Gmail account creating another 1,000 little 'boops'. Thats a lot of noise to go walking around with.

Now by this point, you're probably thinking: "Okay, he can't possibly be that popular. After all, he's a software guy with a blog." Well, you're right. I am not that popular. The vast majority (about 98%) of those text messages are from automated monitoring applications trying to keep me abreast of what's going on at the office.

This situation has two inherent problems:
  1. I get so many alerts that I don't even try to keep up with them all
  2. I have no good way to distinguish between text messages from people and robots
The first problem is interesting to consider, and only slightly less easy to fix. Anyone who's ever worked in a real time environment knows the importance of automated monitoring software. Software which will pro actively let you know when trouble occurs. Without monitoring software we'd only know about problems when a user told us. Obviously no one wants to do business like that.

The problem with automated monitoring software is, that unless its properly tuned, you can end up in a situation where you have a really crummy signal to noise ratio. It's very important to spend time thinking about what things you want to be alerted about otherwise you just end up ignoring the system.

In our situation we never spent the time to correctly tune our alerting system. As a result I would constantly be getting text messages. Maybe I'd get one or two every five minutes. And by and large I didn't read them - even though some of them were probably important.

So why didn't I just turn off the system? Well, my brain started to become a pretty efficient filtering system. I got to the point where I would tune out the text messages unless they started coming in quickly. What's more, my brain seemed able to do this automatically as well. I could sleep through the individual text messages easily, but I would usually wake up when they started coming in more quickly.

The second problem, that of distinguishing alert messages from human-sent text messages, was one that begged for a software remedy. Not wanting to reinvent the wheel, I went in search of such a product.

Watchflag has changed my relationship with my cellphone. Watchflag is a rules based message alerting system for portable devices running Windows Mobile 5 or Windows Mobile 6. In my case I run Watchflag on a Samsung Blackjack2. My cell phone now vibrates and lights up when I get a human text message. Computer-based text messages just get the little ICQ "uh-oh" noise.

The other cool thing about Watchflag is that it is apparently written by actual human beings. When I recently had a problem with a new version, I emailed support and got in touch with one of the developers who fixed the problem and sent me a new version. Additionally, at the moment, Watchflag is being developed very actively. In the past week it feels like we've had 3 or 4 new versions. To some people that can seem like a drag, but since every upgrade brings new features, to me it's like a fun little present!

Lastly Watchflag is inexpensive. At the moment it is only $15 (half-off) and seems to feature free version upgrades. If you use a Windows Mobile based phone I highly recommend it.

Friday, February 15, 2008

The real deal

Lately I've been building sets at Staples High School in the evenings. Schedule-wise, this makes for some long days, but oh well, I like the work. At the moment we're building the set for Romeo and Juliet. The set consists of three walls forming an Italian plaza. The set is conceptual in its design so we make no attempt to disguise the fact that these walls are sitting in the middle of a theatre.

The centerpiece of the set is a gigantic clock. The clock is six feet in diameter and is built into the front of the center building. The clock rests about six feet off the ground and is designed to be illuminated from behind so that it can "become" the moon. The clock also needs to have real hands which dangle limply wherever we decide to put them.

So, it sounds like we need a gigantic lightbox. The design called for a six foot square lightbox to be skinned with rear-projection material which can be painted to look like the face of the clock. This all sounds good on paper, and when I converted the designers sketches into CAD drawings everything looked good. Yesterday we built the box.

A large lightbox

Sometimes you can see something drawn on paper and not realize exactly what the scale means. I knew it was a six foot lightbox, but I don't think I knew what a six foot lightbox was. I think my first reaction was "Uhh... that's pretty big". Thats before I realized that we could stand people up inside of it.

My second reaction was "Uhh... that's pretty heavy". Here's the part where I admit to making a rookie (in the field of enormous lightboxes) mistake. The sides of the box called for 3/4" plywood so that it would provide structure to the building around it. The mistake that I made, was to build the back of the box out of 3/4" plywood also. The rear of the box is non-structural and, as a result of my mistake, is now incredibly heavy. Which means I now have to alter my structural design to support the new weight of Gigantor, the lightbox.

So, what's to be made of this? Nothing really. Hopefully there's a lesson to be learned. I think the lesson is, when building large things off spec, think twice about the materials.

Thursday, February 14, 2008

A bit of knowlege

In my real job, as a software guy, I frequently find myself combing the internet for answers to my daily questions. Usually the questions are mundane: "What is the syntax for datetime.toString()" or "Why won't my asp pages run". And usually I get some pretty good answers. What's amusing to me about this is that there's no natural-language magic going on to make these search terms work. The reason they work is that it's a big Internet full of lots of people... and many of them have the same questions.

Recently I was tasked with preparing and executing a database server migration. This was no small job. I was to move our live production database from an aging server running Microsoft SQL Server 2000 to a brand new Dual-Quad EM64 bad ass server running Microsoft SQL Server 2005. And I had to do it working against the clock.

Our database is really a gigantic string-buffer with some complicated counting bits. As words are said on TV or Radio they go into the database, and after a certain amount of time they are deleted to make room for new words. This system serves us very well, but we have to stay on top of things, because when we have a database server outage, all of the text that's meant to be coming in, just waits at the front door. When too much text is at the front door waiting we run the risk of never being able to catch up.

Oh, did I mention that this database is primarily responsible for putting food on my table?

So needless to say there was a lot of planning. I wanted to have a very good idea of how long our service would be unavailable to our users. So I came up with a plan:
  1. Test
  2. Stop the old database server
  3. Copy database files from old server to new server
  4. Attach the newly copied database files
  5. Test for sanity
  6. Swing DNS to point to the new server
Three of these steps take a little bit of time:

Figuring out the time it takes to swing DNS is easy. You just look at the domains TTL and thats about the time it'll take for everything to make the change (give or take 50%).

GigE Filecopy Tests

Figuring out how to copy the files took a little bit of work. Our production database is somewhere in the neighborhood of 500GB. In the Microsoft SQL Server world, that means I have one gigantic file: My_Really_Big_Production_Database.mdf which has to get copied from the old server to the new server. Without getting too into the nitty-gritty I ended up using a Microsoft utility called eseutil to copy the files. This method seems to work quickly and didn't require me to install 3rd party software on my new database server.

The only other part of the process that had me nervous was performing the database "attach". Normally I wouldn't think twice about the performance of this operation, but in this case we were performing a rather significant upgrade. Not only did our database files have to be converted from SQL 2000 to SQL 2005, but it also had to go from 32bit to 64bit. What this means is that SQL Server performs a series of iterative upgrades on the database structure to get it up to date. So obviously I performed scaled down tests. Attaching and detaching little shell databases didn't get me any closer to an answer. The attach would either take 5seconds or happen instantaneously.

So obviously I turned to the internet. Oh no! No good answer! ACK! At the end of the day I had to cross my fingers and hope for the best as I executed the attach statement. Well, I got my answer. And now I'm giving it back to the internet. [drum roll...]

Question: How long does it take to attach a SQL 2000 database to a SQL 2005 server?
Answer: About 19 seconds for my 500GB database with about 300 tables. The truth is we moved a number of databases on that day. They all seemed to take between 3 and 19 seconds, and it didn't seem to matter how big the database was.

Phew... ok Internet, you can rest easy now.


If I were writing this post in vi, now would be the time where I run this:

:s/I/Jared and I/g

Due to lateness of the the hour when I wrote this post I inadvertently left out the fact that without the help of, my friend, Jared, this migration would have most-likely crashed and burned. I was fortunate enough to benefit from Jared's encyclopedic knowledge of SQL server throughout the migration. Thanks bud!

Update #2

Success! Now the Internet people, with the same question that I had, can have an answer!

Sunday, February 10, 2008

RE: Blogging

Memo From the Desk of Zorlack:

It's been a while since I've written here. For those of you reading this post and thinking "I told you so". Yes, yes you did. Also, get off your horse.

For you the reader: Here is a list of new truths.

1) I will not attempt to catch up: The futility of trying to get a casual blog-reader caught up with the goings-on in my real life is enormous, and any attempt would not only be unsuccessful, but very boring as well.

2) Here be format changes: Yes, I will no longer be posting exclusively about photography. I've decided that since, on occasion, I do think about other things, that maybe those things should be fair game also.

3) Some things will stay the same: I'm the same person, more or less.

I feel like every return-from-hiatus blog post should follow the following format:
¶1: Hello
¶2: Yeah, yeah... I forgot about you
¶3: Here's what I'm gonna do this time around (in a list)
¶4: Recursive meta discussion regarding return-from-hiatus blog posts
¶5: Conclusory mea culpa.

So, in sticking with the format, and without further stalling: I'm sorry for disappearing. My bad.