Book List: Task 1

Getting the book list itself was pretty simple, really, even though the physical files were spread over several devices and/or formats.

In order to make my life easier, I decided that a ANSI/ASCII text file would present the fewest problems. The easy way to do this, of course, seemed to be to go into each device/format and email the files to one PC, and then "Save As..." to get them all to the same physical disk.

It was, suprisingly, just that simple.

Book List

I have a list of books that I want to import into a DB, so I can sort them, group them, and just generally use them as sample data. This doesn't seem like it should be that big of a deal.

Right?

Okay, well, perhaps the list is a little unscrubbed because I both pulled some entries from the Internets and hand entered some others into this list. Still, it shouldn't be that big of a deal, right?

Ha! You'd like to think so, wouldn't you?

So, the simple version of the project plan looks like this:

1. Take multiple files, filled with some combination of

• Author
• Title
• Other Spacing / Whitespace

1. Import said files into a SQL 2008 DB
2. Validate that authors are really authors, titles are really titles
3. Run a single select to indicate the distinct list of books in the set
4. BONUS: Add a column indicating ownership status
5. BONUS: Add a column indicating "have read" status

Blackberry date issues

I have a problem - my BlackBerry, when I sync it, doesn't keep all day events as all day. Instead, it changes them internally to midnight-based.

This is an issue, as once the BB changes them to midnight-based, and they get synced back to Outlook/Exchange, they show up in Outlook as existing only at 12:00AM on the day of the event. Since the bulk of my calendar time isn't spent looking around the overnight hours, but instead is focused on waking hours activities, so it's rather easy to miss activities.

Armed with Outlook macros, I wanted to try and see what was going on under the covers.

I've written a form and a macro to expose all events that have an Outlook start date of midnight.

I ran into a couple of things really quick:

• Outlook stores its dates in UTC
• My time zone is -5
• I have no record of what an event USED to be

Outlook storing dates
Outlook stores its dates in UTC, Universally Troublesome Conversions. Basically, it's a fancy name for not-your-local-time. Yes, I know what it is really.
That said, you're going to have to get the appointment in UTC, and convert it back to your local time zone. Or, if you're a programmer by nature, you do the math in your head, and hardcode the value in during the R&D phase. That said, instead of looking for events at midnight, I'm now looking for them at 04:00.

My time zone
My time zone is -5. I didn't know, when I began, that Outlook was storing things in UTC, so I hadn't recalled what my time zone UTC differential was.

No record
This is actually what's got me stuck. I have no way of knowing, just from programmatically reviewing an events current properties, if it should be an all day event or not. If I did, then I could write a sync program pretty easily. Since I don't, what we're talking about is writing a sync program that would run to "backup" the current Outlook calendar dates, and adjust them before or after the BlackBerry sync runs.

That seems like overkill - after, don't I already have a sync program?

Documenting Requirements

While building a requirements document recently, I came across the challenge of building for purpose. I found that in order be as clear as possible for the developer who was the target audience, I was going to have to build the document in such a way that it didn't know anything about future maintenance.

This presented an interesting dilemma, as how could I then use these same requirements for the maintenance work that I know is coming for this work product?

I found there were certain aspects I could boil it down to, and instead of creating a large, formal document, I boiled the whole thing down to an email with three parts.

• Background - I used this to cover the ground with a general layout of where we were.
• Current Issue - I used this section to cover how we got here, from there, and what exactly "there" was.
• Proposed Solution - Lastly, I outlined what I was proposing we do about it.

Lead Thoughts

I took my kids out shopping the other day to pick some things up. While we were out, one of the kids started playing one of the demonstration video games in the store. They hadn't played the game before, and weren't really all that concerned about place or position - they just knew they were having fun.

While playing the racing game on the demonstration system, they were driving around what appeared to be a mostly-deserted track. I knew from experience that it wasn't, and I noticed immediately the indicator that showed them in 8th of 8 places. They didn't seem to notice, or care, and it made me reflect.

How do you know when you're leading?

How do you know you're not behind the curve, and just can't see the first place car?

On-Call Best Practices

I've studied on-call best practices, and they all seem to come down to:

1. Communicate. First think of yourself as in sales - you are selling your customers and co-workers that you are the buck stopper, and once you own problems, they WILL get fixed. Do whatever you have to do to cultivate that image, especially if you don't like the on-call portion of your job.
2. Track what you do. You can bet your customer/co-worker/boss will, if they think you're slipping!
3. Communicate. Tell people what you did.
   
4. Track when you do it. This may seem to be a part of #1, above, but it really isn't. Using simple tools, like the calendar portion of your email client, is a pretty simple, integrated way to get this done.
5. Communicate. The timeliness of your actions can make or break other peoples solutions, so don't be afraid to talk, talk, talk!
6. Track how you do it. If you involve someone else, especially on the late night calls, a quick email outlining the steps you took while the issue is still fresh in your mind can (and will!) save you both later.
7. Communicate. Telling others how to reproduce your success isn't being generous, it's being responsible.

I hope you see the pattern. :)

SSIS /dev/null

While working with SSIS 2008 recently, I needed some random data. While I was poking around on the same site, I found this:

http://www.sqlis.com/post/Trash-Destination-Adapter.aspx

From their webpage:
When developing a package it is very useful to have a destination adapter that does nothing but consume rows with no setup requirement. You often want run a package part way through development, or just add a path so you can set a Data Viewer. There are stock tasks that can be used, but with the Trash Destination all columns are treated as selected automatically (usage type of read-only), so the pipeline knows they are required. It is also obvious that this is for development or diagnostic purposes, and is clearly not a part of the functional design of the package.



So, basically it's a /dev/null for SSIS. Cool!