'Tis the season

I was looking at my calendar, and realized that Christmas is in less than two weeks. Dates in calendar are closer than they appear.

I was thinking about the holiday season this year and about what I’m doing. Alas, it appears that my Christmas will be somewhat subdued this year. This is the first Christmas since I was married that my father-in-law will not be around. My wife informed me that she will likely be working on Christmas day (such is life when you work for a newspaper). And I’ve told some people not to go nuts in terms of getting me presents. I’m at the age where I can pretty much buy whatever I want or need on my own, and asking for holiday gifts isn’t as meaningful as it was as when I was a kid. (That said, I do intend to get gifts for my siblings and my wife — not sure what, yet — and I also intend to spoil my niece and nephews.) In terms of a Christmas “gift” for myself, I told my wife that I’d like a vacation for both of us — where and when are to be determined. I have no shortage of places that I’d like to go. And it will likely not happen around Christmas. It might not happen until the summer.

This isn’t to say I’m doing nothing to recognize the holidays. I’m currently music-directing and accompanying a holiday community theater musical. My symphonic band performed their holiday concert earlier this week. I made a reservation for next week for a holiday happy-hour get-together for my work group. And speaking of work, my office will close (as it typically does) for a week around Christmas. It seems that my gift to myself is that my schedule will quiet down for about the next month. I’ve had quite the busy year, and I can certainly use the downtime.

So however you spend your holiday — whatever holiday it may be, whether it’s Christmas, Hannukah, Festivus, Kwanzaa, Ramadan, or whatever — I hope it’s enjoyable.

#SQLSaturday Albany, July 25, 2020 #SQLSat961

The SQL Saturday #961 site went live this morning! It will be held on July 25, 2020, on the campus of the University at Albany. This will be the seventh time that CASSUG has hosted SQL Saturday!

I’ve already submitted my sessions (in fact, I was the first one to submit)!

My hometown SQL Saturday is always a special one for me, and upstate New York is beautiful in the summertime (and I’m not just saying that because I’m a native of upstate New York)!

Come and join us in late July for a great day of learning and networking!

Consistent code infrastructure

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

— Martin Fowler

I’m currently working on a project in which I’m trying to deconstruct a database. In doing so, I’ve come across a number of things about it that, in the scope of databases, appall me. Who the hell creates a relational database with no defined primary or foreign key constraints??? And this thing is in a production environment, no less! While that’s a big part of my frustration, that’s another rant for another time. For this article, I want to focus on something else.

A big part of my task — and my frustration — is trying to figure out what the data columns are and how they’re being used in the application. I did come across a table that contains data as to what primary keys are defined (I have no idea why whomever built this thing didn’t actually create the primary keys), and I’m spending a lot of time trying to figure out how these tables relate to each other. As I already mentioned, there are no foreign key relationships defined. So a lot of my time is being spent trying to figure that out.

This is where my frustration — and the purpose of this article — kicks in. Whomever built this structure used names like “DataCounter,” “CrossReferenceCounter,” and so on, to define their “primary keys.” (I put it in quotes, because, like I said, they’re not actually there. And who uses the word “counter” to define them?) What I’m finding is that the corresponding foreign key isn’t exactly the same. For example, while the entity table uses ” DataCounter” for its “primary key,” other tables reference it using ” DataIDCounter.”

This might not seem like a big deal, but when you’re trying to figure out how to map large numbers of data tables and columns, you start questioning whether or not the relationships are correct. And I came across several others whose naming conventions are even worse.

Some of you might be saying, “that’s not a big deal. What’s your problem?” Well, trying writing an ad hoc query where you type in what you think is the column name, and it turns out to be something completely different. You end up wasting your time going back to look it up and trying to figure out what it is.

I remember a previous job in which I was looking at a piece of JavaScript code that contained two nested loops. You would think that the increment counter would use words that would make some sense, right? Wrong. Whomever programmed it named the variables “dog” and “cat.”

Explain to me how that is helpful to somebody trying to troubleshoot or edit the code.

In my previous life as a developer, I would write what I referred to as “open-ended code” — that is, I wrote it with the idea that it would likely be rewritten somewhere down the line. I wanted to make it easy for me (or someone else) to go back and edit or change the code, if necessary. I like to think that other developers have this same mindset, but, all too often, I come across examples like this that tell me that that is not the case.

If you’re a developer — whether it’s for an application, website, database, network, or whatever — keep your naming conventions and infrastructure consistent and meaningful. You will save another developer or support analyst a great deal of grief, frustration, and time.

NY subway map: Designing out of the box

I came across this link on the New York Times website that talks about how the current New York City subway map was designed. I found it to be fascinating. It was a neat article about how the design came about, and how thinking out-of-the-box resulted in ideas that made it better.

Out of curiosity, I looked for previous iterations of the NY subway map before it was overhauled starting in 1979. I came across this map from 1978 on NYCSubway.org. Although I don’t actually live in NYC, I know it well enough to be able to get around and survive. I don’t know about you, but if I tried to use this map to get around New York City, I’d probably be totally lost. I only vaguely remember how rough NYC subways were at that time (for some people, that bad reputation endures to this day), but it wouldn’t have surprised me if this map contributed to subway rider angst.

A number of things struck me as I went through the Times‘ interactive article.

  • Designing out of the box: Some of the design techniques included, among other things, designing lines by riding the subway with eyes closed and sketching how they “felt,” eschewing “straight-line maps” used by many other subway maps to reduce confusion, and combining parallel routes into trunk lines.

    I think it goes to show how much can be accomplished with unconventional thinking.

    Much of this out-of-the-box thinking emphasizes a concept that I espouse as a technical communicator, which is…
  • Less is more: As I’ve said time and again, reading is work. If a document needs to be understood within seconds, and it takes more than a few seconds to comprehend a document, it has failed. Innovations, such as the aforementioned trunk lines, strategically using varying colors and fonts, and eliminating superfluous landmarks, contributed to making the map easier to follow.
  • Documenting history: I also found the interactive article to be a neat history lesson about the NY transit system, map design, and New York history in general.

Any time that I take a trip down to the City, I take the NYC subway map for granted. I now have a greater appreciation of it, and I’ll probably be thinking about it the next time I hop a NYC subway.

And for those of you who are planning a trip to New York City, hopefully, this makes your planning somewhat easier!

Expect the Unexpected with DiRT

Steve‘s article reminded me about the first time I gave my Disaster Documents presentation at a SQL Saturday.

At the end of my presentation, one attendee started an argument with me. He kept saying that paper was dead, everything was online, and there was no reason to keep hardcopy documents. I argued, what if you can’t get to your online documentation?

Not surprisingly, he gave me a poor evaluation.

The bottom line is this: even documentation needs a backup. Other than, say, getting lost in a fire, paper documents can’t break. At a minimum, have hardcopy documents that instruct how to get minimal services back up and running, and back up other recovery documentation so you can recover it later.

Voice of the DBA

Disaster recovery is one of the core tasks that many DBAs think about on a regular basis. Ensuring that we can get our data back online, available, accessible, and intact is important. More than a few DBAs that haven’t been able to recover systems, find themselves seeking new employment.

That’s not to say that most DBAs perform perfectly under pressure. Plenty make mistakes, and there may be times when they can’t recover all data. There does seem to be a correlation between how often DBAs practice recovery skills and how well they perform in an actual emergency. I know that at a few companies, we scheduled regular disaster tests, though often with simulated recovery of a systems that didn’t expect to actually take over a workload. Arguably not a good test, but better than nothing.

Google takes things a step further. They have annual, company wide, multi-day DiRT (Disaster Recovery…

View original post 359 more words

Blogging virtual presentation — January 21

A couple of weeks ago, I mentioned that another virtual presentation was in the works. Well, it’s been scheduled!

I will be doing my ‘blogging presentation at noon, EST, on Tuesday, January 21!

Use this link for more information and to register! Feel free to join me!

#SQLSaturday #953, Rochester — February 29 #SQLSat953

A couple of weeks ago, I submitted presentations for SQL Saturday #953 in Rochester, NY on February 29, 2020. The other day, I received an email from the organizers (Andy Levy, I presume) encouraging us to spread the word about the event.

Okay, Andy. I will oblige!

I submitted the following five presentations for Rochester.

Assuming that I’m selected to speak, this would be my next scheduled presentation event, as of today. Hopefully, I’ll see you in Rochester in a couple of months!