Voice of the DBA

Author: way0utwest

  • Social: A Small Step to Address Poor Past Behavior

    Tl;Dr – This is about changing your main branch in git to main. However, please read and think about what I am saying here.

    When I started working with Version Control, the main branch was named trunk. I worked with code and we always branched away from trunk, which was our source of truth. I have no idea of the origin, though people seem to think this relates to trees. That makes sense.

    Then why master? No idea. The inventor of Git is Linus Torvalds. He’s been accused of poor behavior, though I don’t know I think he is racist. Git was supposedly chosen as it’s an unpleasant person in British slang. That makes sense.

    I followed him early on, and remember trying to get Linux 0.6 working on hardware. I was fascinated with his work, and I hope he chose “master” as the moniker for the main branch because of the verb definition rather than the noun. Who knows?

    In any case, technology is littered with the use of “master” in our terminology. Replication, especially, but HA tech and in many places where we distribute something from one machine to another. I would like to think this is idea of one with more/better knowledge (the master, in the Kung Fu sense), distributing that to others.

    However, there is the connotation of control.

    The IETF agrees and has draft terminology change recommendations. In line with that, I saw a note from Scott Hanselman on changing your git default branch, this after I saw a few people this weekend noting they were submitting PRs to make the change.

    I decided to do the same. I don’t know how to do this on GitHub without a local repo, so I’m following Scott’s process.

    git branch –m master main
    
git push –u origin main

    This moves all the code (all commits and history) to a branch called main. Then pushes this up and tracks it.

    Once it’s there, I need to go to the repo settings and change the default branch to main and delete master. This will cause some issues on laptops, but those are up to date, or they have minor unpushed demo changes that I can abandon. I’ll then pull down the new structure of the repo.

    Don’t do this haphazardly. Communicate with your team and ensure everyone is aware of the change. Then slowly work your way through the repos. It’s a chore but a small one. One I’ll be working my way through until I’m done.

  • Reading an dataset in R

    I got a dataset file the other day with an .rds extension. I had never seen this, but with a quick Google, I figured out this was a dataset exported from r. The extension is for “R DataSet”.

    That’s interesting, but how do I get this data into my workspace? Does readcsv just work on this? It doesn’t, as you can see here:

    2020-05-29 15_36_04-RStudio

    The format used is different, and there is a separate function to get this data. I searched and found this link, which describes loading data in the two different ways. Looks easy, so let’s try it. I’ll use the readRDS function in code like this:

    > qb.2016 <- readRDS(file="passingleaders2016.rds")

    This works well, as we can see below. I get my data loaded in.

    2020-05-29 15_36_53-RStudio

    The first link above recommends this for working in R, but I often am going from a database or other system to R, so I think I’ll mostly stick with CSV. It’s good to know how to load them, if I do need to work with these files.

  • Daily Coping 8 June 2020

    I’ve 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.

    Today’s tip is to re-frame a worry and try to find a positive way to respond.

    Today, I truly worry for the way forward in the US. I don’t think we’re headed for civil war, or anarchy, or the collapse of the economy, but I do worry that we continue to devolve into a place I no longer want to live.

    I consider leaving the country more and more, something I hadn’t done before the last 2-3 years. Despite my differences with people, leaders, laws, systems, etc., I have often thought this was one of the best places to live.

    In some ways, I still see that. I see tremendous creativity, activism, and effort from young people. In way that I only read about people in the 60s, and didn’t experience in my generation, I see changes and work in a younger one. I don’t always agree, but I appreciate their work.

    In some sense, I miss the simple world before the Internet, but at the same time, I am constantly amazed by the way in which young and old people produce music, media, art, sports, and share with the world. They come up with things that never get through some committee or individual funding work.

    I’m also amazed by the enthusiasm and creativity of technology professionals. Certainly dismayed and disgusted by many, but the people that build software, that try to make something useful, that compile and distribute data, they are doing incredible things.

    All this gives me hope and positivity at a time when many things are not.

  • Double Half and Quarter

    I’ve worked in a a couple very high performing organizations that adapted to changing conditions and built software well. I’ve worked in more poorly performing organizations that struggled to release updates and patches, causing tremendous stress for the IT staff.  DevOps is designed to help improve our software delivery and quality, if you work on improvement in many areas.

    I saw a post on LinkedIn, from the Chief Architect at HSBC bank. This was interesting to me because I see HSBC ads constantly when I travel to the UK. They’re the 7th largest bank in the world and was founded in 1865. If ever there was an organization with lots of legacy everything, this is it. They have every reason to do what they’ve been doing for years, since it’s worked out well.

    The post notes that Jez Humble, well known DevOps author and co-founder of DORA, came to talk to them about software delivery and DevOps. For the author, the highlight of the day was the CIO giving this challenge: “… setting every team the goal to double, half and quarter every year: double the frequency of releases, half the number of low impact incidents, and quarter the number of high impact incidents.”

    That’s an ambitious goal, and as the post notes, this results in exponential improvement year over year if the team can achieve this. I think there is likely some limit to this, based on team size and application complexity, but certainly when you’re going from a mid range performing software development group, this isn’t bad.

    I like that this goal was set not just to increase deployments, but to also prevent incidents. I think too many managers look at speed as the goal, without requiring quality to improve. This goal doesn’t quite address this, unless the impact incidents include bugs and poor performing software. It can be easy to limit incidents to downtime from deployments, and not necessarily the use of software.

    The hands off management of this approach is good as well. Not specifying how this gets done. Leave it to the technologists to get this done and hold each other accountable. With that kind of support from management, I’d hope most professionals would step up, improve process and quality, and take pride in their work. It seems to have worked as HSBC, as they’ve been written up a few times in their DevOps approach to IT. I think it can work anywhere with the right management approach.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.