Voice of the DBA

Tag: software development

  • Always Retry

    When multiple people connect to a SQL Server database and attempt to query or update rows, blocking occurs. This is normal, and we expect a certain amount of this, usually very short lived. If it’s not, then having tools that monitor your database and can quickly let you know which connection to kill is important.

    There are also issues like network hiccups and deadlocks, which can cause a transaction to fail and roll back. In these cases, the application should retry a query, often quickly, without bothering the user. This isn’t something that most developers code into their applications, though they should. However, is this something that lots and lots of developers ought to learn and re-implement over and over?

    Microsoft has released a preview of a configurable retry logic in the SqlClinet driver for .NET (others coming soon). With this enhancement, developers can tell the driver how to react with some types of connectivity errors and perhaps resubmit the query. There are various options you can read about, and you ought to carefully test and you decide to use before you deploy them to production.

    To me, this is long overdue. Software ought to work for us and make our work easier, including easier for software developers. Often I’ve heard many vendors point to the configuration options and flexibility of their software, tool, or framework, while placing the burden on developers to write a lot of the code to actually take advantage of the tool. Whenever possible, we ought to make the preferred choice, the best practice, the most common code an easy choice by making it easy to add to a system. Give people flexibility when they need it, but make it easy for them to see the benefits of your software quickly.

    Steve Jones

  • Bug Management

    All of our software has bugs. Some bugs are just bad code, some are incorrect specs, and some are things the client thinks should work differently than the way the application is built. In any case, we know there are plenty of bugs in software.

    How companies handle bugs is interesting. Some feed these back to the current developer team. Some use junior developers to do bug work. Some have support teams that focus on bugs and coordinate with developers.

    What if you get parts of your software from another source? More and more developers are using open source libraries, packages, frameworks, and more. How do you deal with bugs in those situations? As someone that has worked in this manner, tackling those bugs yourself is problematic and introduces other issues with your software development pipeline when the upstream source is updated.

    Google is taking a different approach, actually assigning developers to projects that they need. One example is in this piece, about a couple developers assigned to the security of Linux. While the headline is that they keep finding lots of bugs, the more interesting part to me is that Google internally builds the OSS they use from source, add in their patches, and then use pull requests to get them accepted into the main project.

    I don’t know that many of us can afford to sponsor a developer to contribute to a project full time, but I do like the idea of using a fork to build your software from source. This might not prevent bugs or malware, but if you are hit in this manner, you know that lots of others will be as well.

    Steve Jones

  • ConFoo–The Future of Database Development in Containers

    I delivered a talk at the ConFoo conference. I’ve never been to this live, and when I submitted last year, I was hoping this would somehow be a live event in Montreal. It didn’t happen, but I joined the virtual event and gave my presentation.

    The deck is here: FutureDBDevelopment_confoo.zip

    No real questions, but lots of interest, which is great.

    If you didn’t stay near the end, I talked a bit about the Spawn.cc project and the journey the research group has taken to learn about Kubernetes and file systems. It’s been fascinating to watch the project evolve. The API used to change almost weekly as it was improved and enhanced.

    A few resources:

  • Remembering the Past

    Just a short time ago, the SQL Family lost Gareth Swanepoel. It was fairly sudden and sad to have someone I knew fairly well pass away. He was the first person that I directly knew that was lost to the COVID-19 pandemic.

    I’m getting older. I seem to hear about a person I’ve known passing away almost every year now. I know I’ve got more life behind me than in front of me, and I cherish the moments I do have and the memories of others.

    A few years ago Andy Warren and I were talking about this subject. This was after we lost a common friend, and we wanted to have some way to remember them. We kicked around a few ideas, but other than adding an “Obituaries” category to Database Weekly, I didn’t do much.

    I decided to change that after I heard about Gareth. While processing my grief, I bought sqlmemorial.org and started to put something together. I’ve been hearing about Jekyll and I spent a little time messing around with it. I ended up deciding to put this up and start ensuring that we have a way to remember the people that have taught and touched us. I’ll also share some articles on how I put this together.

    I set this up as a GitHub repo, and I am taking pull requests for people that want to add a memory, a link, a picture, or something else. I’m also hoping that people will let me know as others pass, a sad fact of life that we will continue to experience in the years to come.

    I’m hoping this helps me, and many of you, fondly remember the people in our SQL Family.

    Steve Jones