Voice of the DBA

Author: way0utwest

  • Daily Coping 14 Apr 2021

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag. 

    Today’s tip is to turn a regular activity into a playful game today.

    One of the things I like to do to relax is play some guitar. While I enjoy learning and playing songs, I don’t do quite enough dedicated practice for things like scales. These would help me with improving my play and exercising my fingers. I’ve seen a few exercises, but I haven’t always been interested.

    Today I tried something different. I set up a metronome app on my phone, and set it to a fairly slow speed. I then worked on a scale, matching the beat.

    Not terribly playful.

    However, I started to try other things.

    • doubling up, two notes for each beat
    • tripling up, 3 notes for each beat
    • playing triplets, as in for the C scale, playing
      • C, D, E
      • D, E, F
      • F, G, A
      • etc.
    • Skipping some beats. As a prelude to some solo practice, I would play3 notes on one beat, then let a beat go by, holding the 3rd note. Then 3 more on the 3rd beat, and holding the fourth.

    None of these are earth-shattering, but they do make the exercise a little more fun, and they are a little game.

    Now if I would do this more often.

  • 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

  • T-SQL Tuesday #137–Notebook Uses

    It’s actually my month to host T-SQL Tuesday, and I came up with the notebook idea last year. Aaron Nelson (b | t) sent me a link to a talk he did at a Meetup. It contained some interesting things, showing how you can use notebooks. Worth a watch.

    For me, I don’t use notebooks a lot in my work. I had thought about using them to show clients and customers how to use our products, but I hadn’t moved far in that direction. I think too many customers are still using SSMS primarily, and haven’t moved to ADS.

    The one place I’ve found them interesting is with Python. When I am sometimes trying to work through an issue, I think it’s easier to run a cell of code and get some results to work through an issue. If I use the REPL, I lose things. In VS Code, which I prefer, I don’t like the split code/terminal. I find that slightly annoying. Notebooks make things easier.

    I was doing this recently, as I tried to work on the Advent of Code. I tried different parts of an algorithm in different cells, just to see what the results were. This helped me to work out some logic.

    2021-04-13 10_02_06-● Day5.ipynb - Data Analysis - Azure Data Studio

    That’s not a great algorithm, and I got better over time, but this was really a good way for me to think about the sections of the problem, putting each on in a separate area.

    It’s a little of “teaching myself” within the construct of a notebook. After all, that’s what a lot of data scientists are doing when they start to go through different code items in a notebook.  They can share the notebook with others, which helps to teach.

    For me, it’s teaching myself.

  • DevOps in Space

    Some of the early science fiction books I read were by Robert Heinlein, often including rocket ships and space travel. These days I’m uninterested in actually going to space, but I am excited by the prospect of the efforts being made to send others. It’s an exciting time to be interested in travel off of this planet.

    One of the headline makers is SpaceX, which has had quite a bit of success launching reusable rockets carrying all sorts of cargo. My son was very interested in their work as an 18 year old, and I still remember taking him to Cape Canaveral and watching the first first rocket launch and land at the facility. An exciting time for us.

    SpaceX has adopted a DevOps attitude towards their physical rockets, adapting and iterating quickly to improve their designs. The pace of progress is quite interesting, analogous to how some companies have changed their software development lifecycle practices, becoming quite adept at building and improving applications in a rapid fashion. Alex Yates draws some parallels, and includes lots of fascinating rocket information, in this post on the Octopus Deploy blog.

    One of the big challenges I find with changing software development is that we struggle to let go of old practices. Even as we look to iterate, often we are unable to accept risk, and we often want to stick with the “always done it this way” for some things. While we might accept some changes, we don’t accept others, and may even cancel out the benefits of automation improvements with a lack of willingness to adapt our culture.

    I do hope that other companies challenge SpaceX, and learn from them. Ultimately we do better with a competitor that forces them to continue to improve and not rest on past success. The same is necessary for software development teams to continually improve. If your organization is stuck in a rut with software development, request (or push) for a team to try something new. To adopt and grow with DevOps. Make them prove they can build, deploy, and operate software in a better way. Then challenge other teams to try and adopt their ideas, and then improve upon them over time.

    Steve Jones