Voice of the DBA

Category: Editorial

  • Most of Us Are Vulnerable

    I saw this study recently, where most people think they are better-than-average drivers in the US. I thought about it myself afterward, and I think I’m maybe average. I do pay attention most of the time, I try to be more careful when it’s wet or snowy and give myself more time to slow down. I  try to be aware of the other cars and obstacles on the road. I also usually have a drink (coffee, soda, water) with me, and I certainly mess with the music player. The Tesla reminds me constantly when I’ve strayed near a line, so a few months of driving seems to tell me I’m not great. Certainly not above average.

    I would expect that most of us think we’ve done a good job with security for our systems.  We don’t expect to get hacked or deal with ransomware. I don’t know how realistic that is, as a recent set of penetrations tests shows the vast majority of networks are vulnerable.

    It sounds bad, and it is. It also is not likely to change as the complexity of many networks is high. There are so many devices, constant additions and changes to services and applications, and regular requests to grant access to a new group. It’s amazing there is any security at all, given how quickly people want to access systems and how impatient they are when they can’t connect.

    The data doesn’t show that every system is wide open, but there are ways in which every network can be disrupted. Whether this is significant or not is hard to assess, but given the reports I see in media, as well as private notes from friends, I suspect that most companies have plenty of work to do.

    It’s not all had work, however. I think many people that configure networks are careful and are wary of opening firewalls. The bigger problem, which continues to exist, is likely simple passwords from far too many people. That, combined with a lack of multi-factor authentication being rolled out, means that there a lot of simple changes that could make a big difference. I know my company rolled out a corporate password manager recently to all employees. This, combined with our MFA app on mobile devices means that we should have strong passwords and better verification of legitimate access for most systems.

    At least, I hope we do.

    Steve Jones

     

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • It Isn’t Worth Automating

    Every year I’m responsible for a portion of the Database Weekly newsletters. I used to do half, but right now Kathi, Grant, and I are on a rotation. Our boss puts out a schedule each year, which tells me the weeks for which I am responsible. Each January I then set up a recurring appointment for Mon/Wed/Fri on my weeks to remind me to curate articles and write an editorial.

    Each year I also think about whether or not I can automate this. Last year I spent a few hours looking into the Exchange APIs for creating appointments, at the C# code, and PoSh (which is a nightmare). I spent a few hours, got frustrated, and gave up, just manually creating appointments.

    This year I took a slightly better approach and tried to figure out how long it takes to create an appointment. I got a stopwatch and went through the process. Each recurring appointment takes about 30 sec to create and (a repetitive) 15 clicks. I have 17 weeks, so this is about 9 minutes (rounding) to get this done.

    That doesn’t seem worth automating. In a decade, I’d spent 90 minutes doing this. I’m not sure I could automate it in 90 minutes. I might learn a new skill, but I don’t do much calendaring, and honestly, I’m not sure I could do something I’d think would be reliable, portable to others, or even useful in other ways.

    Throughout my career I’ve had a lot of tasks like this as a DBA or developer. They are often short tasks, things I do fairly rarely, and are not tightly defined. Often I just do a little manual work rather than spend too much time trying to automate things. In my life, I’ve found similar tasks, where I’m not sure the time spent building automation or the maintenance requirements over time, would be worth the effort.

    I am, however, a big proponent of automation, and I think there are many places where the time spent is worth the effort. Periodically cleaning log files from servers, running data loads of know files, DevOps CI and CD processes, and more are worth the effort. Many people need these processes running often, and the work to get automation running becomes a time saver.

    Not everything needs to be automated, or even should be. Certainly, when the manual time or effort requirements are small, it pays to do a little analysis. If you disrupt the way humans do their work, then be sure your solution saves time or effort. As technologists, we often reach for the scripting/programming tools to solve problems, but be sure that you include a little thought before you start coding to be sure the process is worth automating.

    Steve Jones

     

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • A New Language

    In my life, I’ve mostly dealt with people that speak English. I tried Latin in high school and Japanese in university, but I wouldn’t say I learned a lot. This past year I’ve been working on Japanese (konichi wa) and French (Bonjour) on a regular basis, but I’m still fairly uni-lingual. At least compared to many of the people I’ve met in my travels that speak multiple languages. I’m mostly just trying to read a bit, and that’s quite hard.

    In my career, I haven’t met many technologists that only know one programming language. Even the SQL professionals know a little C# or a scripting language. Quite a few people know a bit about many languages, and some are very competent. I used to think it would be good to master one language before moving on, but I find that trying different languages can give you an appreciation for others, or even an appreciation for your primary one. Comparing and contrasting code might even help you learn faster.

    These days many of us are being asked to handle more tasks, and we may be required to support or work with code that others have written. As a result, I think it makes some sense to have a basic knowledge of other languages that you might encounter. I can often look at code in different languages and get an idea of what’s happening. I might even think about fixing simple bugs if needed.

    I saw a Data Exposed edition recently with Hamish Watson that was titled KQL: The Next Query Language You Need to Learn. I had heard of it, but never used it. After watching the episode I played with it a little. While I don’t know how important it is, I do appreciate I may run into it and will likely spend a small amount of time writing some queries and familiarizing myself with some of the common aggregates and other types of structures.

    Today I’m curious, which do you think you would learn as a next language? Not that you’d give up your current work in T-SQL or something else, but what else might be good for your career, or perhaps be exciting to you personally?

    I’ve enjoyed doing some work in Python and PowerShell over the last year, and time spent in R before that helped me appreciate those languages. There are places I’d choose to work in those over T-SQL, especially for data not already in a SQL Server.

    Take a moment and leave a comment: what new language would you like to learn and why?

    Steve Jones

     

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Coding for the Future

    I posted a note on Twitter about some code. In this case, it was the start of a for loop, but with two things in it that I didn’t like. The code is shown here:

    for ($i = 2011; $i <= 2021; $i++) {

    Both the starting point and the ending condition were problematic for me. This code is used in a scheduling application, to populate a dropdown that I used regularly. It’s always worked, since about 2017 or 2018, and I had no reason to even think about the algorithm. I assumed the code was something like this:

    for ($i = 2011; $i <= year(); $i++) {

    In fact, when I had issues on 27 Dec, I assumed that things were coded to the current year and I’d be able to schedule things on Sunday night when I got home. Instead, things still didn’t work the first few days of 2022 and I had to get someone to come in from holiday to fix the code. Now it looks back a few years (likely unnecessary) and looks forward one year, as it should.

    I don’t know why a developer would bother coding anything like this. Get the need to perhaps test something expediently and limit choices, but hard-coding most anything is a poor idea. There ought to be some logic in how or why you choose values, and that logic often can be expressed in code that adapts to situations. I certainly could have lived with only the current year being available, though that still doesn’t think through the problem space well.

    I’ve seen lots of simple bugs in code over the years that are similar to this one. These often occur because the developers haven’t thought through how code might need to adapt to slightly changing situations. Something like a change in the year, or maybe the addition of a time slot for scheduling or a new location added, even a new tax rate. Often I find developers think they have considered the problem given to them, but a little too tightly. They haven’t thought about how their code might change if the user requesting the feature has made a mistake.

    Writing code that solves a problem and allows for adaptation to likely scenarios is a bit of an art. It can be hard to do, but great developers assume users will need some changes and plan for this in their solution. They also assume users make mistakes in their specifications and they don’t hard code anything.

    Steve Jones

     

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.