Month: December 2019

Another year down, another year coming

As I write this, it’s fewer than forty-eight hours until the new year, which, I figure, is just a good a time as any to review the past year, and look forward to the next.

Because I focus my ‘blog about professional development and technical communication, let’s start there. How about a run-down of my speaking engagements this year?

It looks like I’ve had a busy speaking year. While compiling this list, it also made me think about other events around my calendar.

So, those are some of what I did in 2019. What do I have coming up in 2020?

As of today, I have two confirmed speaking dates.

Also, as of today, I’ve submitted presentations to the following events.

I also intend to apply to speak at Boston on October 3. As of today, this event page is not yet live. I am also contemplating applying to speak at PASS Summit in Houston and SQL Saturday in Virginia Beach.

2019 was a busy year, and it appears that I will not be slowing down in 2020.

Happy New Year, all! I’ll catch you on the other side!

Advertisement

Choosing which #SQLSaturday to submit

I saw an interesting (and amusing) tweet from Matt Cushing about applying to three SQL Saturdays in February and questioning his own sanity. Matt, I could’ve told you that you’re insane! 😉

All kidding aside, it did get me thinking: how do I select the SQL Saturdays to which I apply to speak? If you’re a new speaker, this might be a question that you’re considering.

For those of you who may be new to my ‘blog, I’m a regular SQL Saturday speaker. I’ve been speaking at SQL Saturday since 2015. I’ve written before about what to expect at a SQL Saturday, and I’ve even written about some of my experiences traveling to SQL Saturday. So I figured I’d write a primer as to what I consider when selecting where to submit my presentations.

Before I do, however, I should lay out a disclosure. I present at SQL Saturday completely on my own. And by this, I mean on my own time and on my own dime. I don’t do this for pay, and my employer does not dictate what events I attend or where I speak. I do this because I love doing it (and it doesn’t look bad on a resume, either). All schedules are my own schedules, and all expenses come out of my own pocket. My employer does not reimburse me for my trips (some speakers have their companies pay for their trips, but I do not have that luxury). This plays a huge factor into my planning, as you’ll read about below.

Will it break the bank?

Since I mention that I do this on my own dime, I’ll start there.

Cost is a huge factor whenever I consider where to submit. Traveling gets expensive (and traveling also incurs other issues, which I’ll talk about in a minute). The easier it is for me to get to an event, the cheaper it is for me to get there. I apply to nearly all SQL Saturday events that are within easy (about a few hours) driving (or, for NYC, commuting) distance from my home in Troy, NY. I have yet to apply to an event (other than PASS Summit) where I have to fly. There is good reason for that. Flying is neither cheap, nor convenient.

Of course, I apply to speak at Albany every year. It takes me all of twenty minutes to drive from my home to the UAlbany campus, where the event is held. It’s my hometown event, and it’s sponsored by my local user group, of which I’m a member. I am not paying for a hotel, and my trip expenses are no more than my normal commute to work. Other than nominal expenses, I pay nearly nothing to attend this event.

I attend New York City pretty much every year, regardless of whether I’m speaking or not. It’s an easy trip — doable in a day, in fact. Amtrak goes directly from Albany right into midtown Manhattan, making it a very easy trip. If I do need to stay overnight, my siblings live in the City, so I have a place to stay. Or, I might splurge a little for a hotel. New York isn’t the cheapest city to visit, but if you look hard enough, deals can be had.

Boston — straight shot down I-90 for me, roughly a three-hour drive. And while Boston area hotels aren’t necessarily cheap, I can find lodging that won’t break the bank.

I did apply to speak at Chicago this coming year. I created a theoretical itinerary and realized that I could make it work. If I’m accepted, it would represent my first SQL Saturday where it wasn’t feasible for me to drive there.

There are a number of other examples, but at this point, you can see where I’m going with it. Finances will often dictate whether or not I can attend an event. However, finances alone aren’t the only factor. There are other things I need to consider, such as…

How easy is it for me to get there?

One event that I’ve never attended — and would like to — is Cleveland. With its relative proximity to New York State, you’d think that Cleveland would be an easy one for me to attend.

It isn’t.

For starters, Cleveland, for me, is roughly an eight-hour drive… in good weather. Now consider: Cleveland holds their event in February. Imagine trying to make that drive in unpredictable, snowy, winter weather. Maybe I could get lucky and get good weather on a drive out that way, but it’s a crapshoot and not guaranteed.

Okay. Amtrak goes to Cleveland. How about hopping the train?

The Lake Shore Limited, which travels between Boston/NYC and Chicago, makes a stop in Cleveland. Is it a direct line from Albany? Yes. Is it convenient…?

That would be a big no. The train arrives in Cleveland at 3:30 AM. As for the return trip, it departs at 5:50 AM. Either way, it would make for a very inconvenient itinerary.

That pretty much leaves flying. In years past, this would also not have been an option. Flights from ALB to CLE have been expensive and inconvenient. Additionally, there are no direct flights between the two cities. I did look up a theoretical flight for SQL Saturday #930 and found a roundtrip flight as low as $218. I’d have to fly through Detroit to do it.

Maybe I could’ve applied to speak in Cleveland and flown out. But I didn’t want to deal with the hassle.

One of these years, I might be able to make Cleveland work. That day hasn’t yet arrived.

Is the travel convenience (or inconvenience, as the case may be) worth it for a short weekend trip? That’s up to you to decide, but it is another major factor that I consider when I think about submitting to an event.

Does it fit my schedule?

Another event that has interested me is Pittsburgh. I spoke at Pittsburgh in 2016, and it was an enjoyable event; in fact, I’ve been wanting to return ever since. It’s a long drive for me, about eight hours. At the time, it was the farthest that I’d ever traveled for a SQL Saturday (that has since been surpassed by Virginia Beach).

I decided that eight hours is a long time to spend in a car, so I’d prefer not to drive there. It turns out that I can get Amtrak to Pittsburgh, and the schedule works for me. On top of that, I have a friend who lives there, so I’d probably have a place to crash. Pittsburgh is a long trip for me, but it’s one that I can make work.

So why haven’t I been back? Mostly, it’s been because of scheduling issues. One year, I withdrew from Pittsburgh because it was separated by only a week from another SQL Saturday where I was accepted to speak, and I decided that traveling on back-to-back weekends was a bit much. This past year, I’d fully intended to apply… and New York scheduled theirs for the same day. Other years, I’ve had a number of things come up on my calendar that have interfered with the event.

I’ve withdrawn from or didn’t submit to other events because of schedule conflicts. As much as I’d like to submit to every event that’s within a couple of hours from me, it doesn’t always work out.

If I was able, I’d apply to as many SQL Saturday events as possible. However, there’s also something to be said about work/life balance… and maintaining your own sanity.

Summary

So if you’re a road warrior, you like to keep a busy schedule, have deep pockets, or have an employer who will fund your trips, a lot of these issues might not affect you. But for other SQL Saturday speakers (like me), we do this on our own time and our own dime. These are the things I consider whenever I decide whether or not to apply to speak at a SQL Saturday. Whether or not you can handle the issues that come with getting to an event is up to you.

‘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!