This coming Saturday, I will be speaking at SQL Saturday NYC! Of all the SQL Saturdays, I have attended the NYC event the most, and this is one of my favorite events! It is a great opportunity for networking and to learn about a variety of data topics and professional development!
SQL Saturday is always a good time! It is free to attend (there is a nominal fee for lunch), but you need to register. Go to the NYC SQL Saturday page for more information, including a link to register for this great event!
It seems like it’s been a while since I posted one of these speaking engagement updates, but as the calendar turns to April, more opportunities come up. As of this update, I have two confirmed speaking engagements and two more where I’ve applied. I think more of these will come up as the year goes along. But in the meantime, here are my upcoming speaking engagements, as of today.
Confirmed
I am confirmed to be speaking at the following events.
May 6, 2023: SQL Saturday NYC: I pretty much try to attend SQL Saturday in NYC whenever it comes up, regardless of whether I’m speaking there or not. It just so happens that I will be doing two presentations there this year.
Disaster Documents: The role of documentation in disaster recovery: On September 11, 2001, I was working for a company that had an office in the World Trade Center. Prior to that infamous date, I had written several documents that ended up being crucial to our recovery. In this presentation, I talk about those documents, the roles they played, and lessons learned. In my newly revised presentation, I also provide an overview of what’s changed since 2001 — things like smartphones and cloud technology did not exist back then — and how they can be applied to disaster documentation today.:
Whacha just say? Talking technology to non technical people: Explaining technology to those who don’t understand it is difficult, and a skill that people take for granted. In this presentation, I demonstrate how difficult it is to give instructions, and steps we can take to get better at this skill.
May 16, 2023: STC Summit, Atlanta, GA: On Tuesday, May 16, I will be speaking at STC Summit! I am especially excited about this event, as speaking for STC has been on my bucket list for quite some time, and I’ve never been to Atlanta (other than changing planes at the airport, which doesn’t count)! I will be doing my job hunt presentation for this event. This presentation has been one of my best-sellers as of late, and I hope I’m able to help people with their job search.
Applied
I’ve applied to speak at these events.
October 14, 2023: SQL Saturday Boston: I’ve spoken in Boston (okay, it’s actually Burlington, MA, but they call the event Boston) a number of times. I always enjoy speaking here, and I hope I get selected to speak again!
I enjoy giving these presentations, and I hope people are able to get something out of them. I’m always satisfied knowing that I was able to help somebody out, and I hope that I’m able to continue doing so.
I found out over the weekend that I’ve been selected to speak at SQL Saturday NYC on May 6! This is one of my favorite events, and I try to attend every year. To the best of my memory, I’ve only missed one SQL Saturday, as either a speaker or an attendee, in NYC since they’ve been holding this event.
I will be doing two presentations:
Disaster Documents: The role of documentation in disaster recovery — Documentation is a critical part of disaster recovery. This became evident on September 11, 2001. At the time, I was working for a company that had an office in the World Trade Center. When the towers fell, documentation was a critical for our recovery. In this presentation, I tell my story of how documentation played a role in helping my organization recover from that fateful day.
Whacha just say? Talking technology to non technical people — The language of technology might as well be a foreign language to people who don’t understand technology. In this session, I talk about how non-technologists can be overwhelmed by this language, and offer tips as to what technical people can do to convey that language.
New York SQL Saturday is always a good time! I hope to see you there on May 6!
I have a personal connection to this natural disaster. My wife has a cousin who lives in Tonga (if you’re wondering about how her cousin ended up there, she was there on [I think it was] a Peace Corps mission and met a guy there with whom she fell in love and eventually married). The last I heard, my wife’s cousin and her family are okay, but they are cut off from the rest of the world.
Another one of my wife’s cousins (the Tonga cousin’s sister, in fact) has been organizing relief efforts for Tonga, including a GoFundMe campaign. You can view the GoFundMe by clicking this link.
I kicked in a few bucks, and I’m posting to see if I can get others to donate as well, if you are able and willing to do so.
I don’t think there’s an experienced web developer or DBA who isn’t familiar with the classic “Bobby Tables” XKCD cartoon above. Just about any time you mention “Bobby Tables” to most experienced IT people, (s)he will immediately know to whom you are referring. Most experienced web developers and DBAs are aware of SQL injection and will take steps to ensure that it’s addressed. Grant Fritchey has a presentation about SQL injection (you can view and download his slide deck here) in which he’s not shy about his desire to “kill Bobby Tables.” I’ve seen him present it at SQL Saturday, and I highly recommend it.
Of course, the keyword here is “experienced.” For people who don’t have that experience, and who build websites that connect to databases, I think it should be lesson #1. Today, I had an experience that reminded me of that.
Earlier today, my sister texted me, asking for help with editing SQL code. She asked me what I use to edit SQL. I told her I generally use SSMS, although you can edit SQL code with a straight-up text editor, if necessary (she is not a DBA, so I felt somewhat comfortable telling her this). She told me she had to clean up spam comments in her data.
That last comment immediately grabbed my attention. I then asked her, how are your security settings, and do you have data backups.
She told me: that IS her data backup.
If her earlier comment had gotten my attention, this one immediately set off alarm klaxons in my head.
I started thinking about what could have corrupted her data to this extent. I started asking questions about her admin setup (I should’ve asked her to make sure she wasn’t using “sa” or “admin” as her admin login — Sis, if you’re reading this, make sure you check this!), including her passwords. Her admin password was pretty secure (thankfully).
She then mentioned her website. I asked if her website was accessing her data. She said yes.
I asked her about Bobby Tables (admittedly, in my advancing age, the term “SQL injection” didn’t immediately come to my mind). Her response: “who?”
At this point, I was convinced that I had my answer. Her database had been corrupted through SQL injection attacks. I told her to make sure you address your SQL injection issue before you even think about your data backups. Worrying about your data backups before addressing your SQL injection issue is like trying to rebuild your house before you’ve put out the fire.
I’ve been talking about SQL injection all throughout this article. For a brand-new web or database developer who has no idea what SQL injection is, here’s a quick primer: it’s a data security attack in which a hacker breaches your database by sending SQL commands through your web interface. I won’t get too much into how it works; instead, here are a few links that explain what it is.
So consider this a warning to any fledgling developers who are interested in web or data development: data security issues, such as SQL injection (and there are many others) are a big deal and need to be considered when building your setup; it’s not as simple as just setting up your website and connecting it to a database. By not considering this when you first assemble your system, you might be setting yourself up for major issues down the road.
I’ve always had a morbid fascination for air disasters. (Don’t ask me why; I have no idea.) I’m fascinated by shows such as Air Disasters, Why Planes Crash, and Mayday: Air Disasters. Whenever I hear about a plane going down, I’ll start thinking about what happened, clues, what might have caused it, and so on. There are times when I think I should have gotten a job with the NTSB.
Greg Moore has some publications in which he talks about lessons learned from aircraft accidents; his book partially discusses these lessons. He also has an excellent SQL Saturday presentation titled “Who’s Flying The Plane?” which talks about lessons learned from air disasters and how they can apply to IT. Go check it out if you have a chance; Greg gives a great presentation!
For the purposes of this article, however, I want to concentrate on a particular topic: how communication — or, the lack of — either contributed to or was the root cause of a disaster.
Last night, I watched an episode of Air Disasters that talked about the plane crash that took the life of professional golfer Payne Stewart. The plane went down after the cabin depressurized (the cause of which was never determined), the crew became incapacitated, and the plane ran out of fuel. What made it interesting to me was that bad documentation might have been one of the contributing factors to the accident. After the cabin lost pressure, the crew likely consulted a checklist, as is standard procedure for nearly any cockpit activity or incident. The checklist was poorly written and unclear. What should have been the very first instruction was, “put on your oxygen mask.” It was not. By the time the crew got to that instruction, it was too late; they were overcome by hypoxia.
It reminded me of a tenet that I preach in my documentation presentation: if, in a step-by-step instruction, an instruction cannot be understood within a few seconds, it has failed.
I also remember another Air Disasters episode that focused on Avianca Flight 52. In January of 1990, the plane, a Boeing 707 carrying 158 people, crashed on approach to Kennedy Airport in New York after running out of fuel, killing 73 people. There were numerous communication issues during the flight. Had any one of them been addressed, chances are the disaster never would have occurred.
How often have you been involved in some kind of activity where things were miscommunicated? How well did those activities go? I’m guessing that they didn’t go well. How often have they happened when deadlines were approaching? What was the mood of your organization? I’ll guess that it was likely one of high stress and low morale. And during that time, how smoothly did things go? Probably not very. I’ll bet that plenty of mistakes were made.
I’m painting this picture within a business environment. Imagine what these conditions are like when people’s lives are at stake.
The number of disasters that have occurred from poor communication are countless; entire studies have been dedicated to the subject. Indeed, numerous solutions and subcategories related to miscommunication have been devised. The airline industry developed the process of crew resource management. Extensive research has been done on the phenomenon known as groupthink. Even simple measures such as checklists have been studied and implemented.
The moral of the story: good communication, including documentation, is critical. The consequences of it can have adverse effects. At best, bad communication can disrupt your business. At worst, it can cost lives.
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.
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.
A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.
This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped…
For those of you who are not regular readers of my ‘blog, SQL Saturday is a daylong conference centered mostly (but not entirely) around data topics related to SQL Server. It’s also a great networking event, and an opportunity to hook up with a number of data professionals! Check out the schedule to see what sessions interest you!
Additionally, there are three pre-con sessions on Friday, July 19. Unlike SQL Saturday, these sessions are not free, but they provide quality daylong training for specific topics at a decent price. Information about these pre-cons can also be found on the web site!
For more information and to register for the event, visit our website! Upstate New York is a great place to visit during the summertime! Hope to see you there!
Welcome to Ray Kim's 'blog 