Voice of the DBA

Category: Editorial

  • Growing Outside of the English World

    The CEO of our company is English, and he likes to remind me (jokingly) that there was a long time when the sun never set on the English empire. I will jokingly remind him that one country has set foot on the moon.

    One of the things that has changed me in the last decade is travel. I’ve been lucky enough to visit many countries around the world for work, and a few more for personal trips. In this time, I’ve often engaged with local people and tried to experience life a bit from their perspective, rather than be a tourist and just look at a thing or place as an outsider. I’ve often read a bit or researched an area to learn some history or get some context.

    That’s changed my view, and helped me understand how different the world can be. While I do find most people are similar around the world in many ways, cultures vary, and the emphasis placed on one thing vs. another can be much different.

    I also see how the wealth and privilege in the US makes many things quite easy compared to other parts of the world.

    This is something I am think about often as I try to restart SQL Saturday and think about events in different parts of the world. It’s something I think about as I deal with customers in other countries as well, understanding that their database problems are the same, but the way they work and interact can vary.

    Stepping outside my own US-centric view also helps me think about my past and how I may not have respected or treated others equally when their culture was very different from my own. Growing up involves learning more than you already know. In my mind, it also involves some empathy, appreciation, and respect for just how different the world can be for others. Something I am trying to do more and more often, especially with those outside the US/UK/ANZ world.

    Steve Jones

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

  • Republish: I Hate To Send This Email

    My first plane flight in over a year. Out in Philly today, coaching youth volleyball, so you get: I Hate To Send This Email

  • Poor Software Testing

    I am a big advocate of testing your code, including your database code. I like repeatable testing, especially unit testing. I think this has contributed to the increase in quality over the last ten years as more developers have incorporated unit testing into their work. That, along with the increase in standard frameworks, seems to have resulted in less crashes and instability in much of the software I used today.

    That being said, the client ultimately decides if software works as expected. Certainly there can be logic errors, but there also could be errors in how specifications and requests are interpreted. This is one reason we need humans to do some QA testing and clients to ensure there is some user acceptance review.

    Apparently that didn’t happen with one election machine. There is a hash that is supposed to be used to verify that the correct version of software is installed. However, if that reference hash isn’t there, the machine still reports things are fine. Certainly an issue that is a problem, though not necessarily one that users would detect. We would expect someone that purchases, updates, or administers these machines to check for the correct version.

    That isn’t an issue here because the acceptance testing was done by the vendor. While I am a big advocate of developers checking their work, there needs to be independent evaluation by a CI process, and there ought to be some QA review by another group. Certainly a client ought to be able to double check the software as well, and some client should have done acceptance testing here.

    As the world moves more towards DevOps type software development, we need better testing, and that likely needs to include some independent testing outside of the developers and testers. I certainly could see the need for clients to submit some tests and get some verification that those tests passed. Automated CI/CD systems can do this, and provide detailed logs of what happened.

    Ultimately we may still have bugs, either because we don’t have enough testing, or we don’t quite write the code that does what client expects. We may also have performance issues, but that’s another testing issue.

    We can get better, but we have to work to do so, learning from our mistakes, ensuring we are always improving testing, and listening to feedback.

    Steve Jones

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

  • Removing SA from Azure SQL Database

    One of the recommendations from Microsoft SQL Server is to use Windows authentication. This has been in the docs for years, and I’ve heard many MS consultants and employees note this. Many customers and clients have tried to use Windows Authentication only, but often in a cross platform environment with Java or Linux clients, one usually has needed SQL authentication with a user and password. Client libraries have been enhanced so this isn’t necessary, but still some people prefer SQL authentication, especially with clients outside their organization. It’s simple, easy, and developers can make it work in seconds.

    With Azure SQL Databases, some companies defaulted to a username and password, as their Active Directory (AD) wasn’t extended to Azure. That has become easier to do, and many people are taking advantage of it. In fact, some customers are so integrated, they want to do away with usernames and passwords in Azure.

    Microsoft has listened, and is giving them the option. The feature is in preview, but if you enable this, SQL auth is turned off, which means whatever administrative account you set up for the server with a name and password will not work. That’s essentially the “sa” account, though with your own custom name.

    While this feature won’t be useful for everyone, it’s a good option to have. As more companies look to tighten security and limit the attack surface area, being able to make this choice is important. It’s also something that architects and administrators should be aware of and consider in their decisions on how to implement applications in Azure.

    Steve Jones

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