SQL Source Control Link Errors on a New Machine

Posted on May 19, 2020 by way0utwest

I replaced my desktop recently and installed new software through Chocolatey.. One of the things I installed was git. I ran “choco install git” and then started using it. I cloned some repos and everything seemed fine.

Then I cloned a repo of a SQL Source Control database, created a new database and tried to link the repo. I got an error on screen, which I forgot to screen capture. The error was 128, which wasn’t helpful.

Fortunately, I did manage to copy the error to the clipboard. I pasted it in Notepad and saw this:

2020-05-14 14_29_25-Are you a gatekeeper_ - Evernote

Aha!

I never configured git. Since I’m mostly working in my own repos, committing back to places that I will access from another machine, I haven’t thought about this. I know I’ve done this on the previous machine because SQL Source Control worked a month ago.

What’s nice about git, and what I wish more software did, is that it tries to help you. In this case, it tells me that it can’t detect an email address and therefore can’t populate the commit metadata.

What do I do?

Run the commands and config my environment. I copied and edited the commands in a command prompt. And typo’d things one time.

2020-05-14 14_34_24-cmd

Once this was done, SQL Source Control worked.

2020-05-14 14_35_06-Link to source control created

SQL Source Control is a fantastic way to easily grab your database code and put it into a repo. Give it a try today if you never have tried it, but you’ve ever scripted out your object code.

Posted in Blog | Tagged , , | Comments Off on SQL Source Control Link Errors on a New Machine

Rolling Back One Bug for Another

Posted on May 19, 2020 by way0utwest

I was working with a customer recently that develops software for use by their clients. They work in a DevOps style flow, regularly completing work and sending that to their clients. In one case, they released a hot fix quickly to resolve a bug in their software. In this case, the developers received the report, triage’d the bug, and released the fix in less than a week. Their clients were happy with the response and speed at which the fix was delivered.

Unfortunately, they also released another bug with the fix. The new bug was in an unrelated area of the software, created by separate changes to the code. Now they had a dilemma. The hot fix helped some customers, but the fix also broke some things that other customers cared about.

What do you do here? If you were in charge of this software team, how do you decide what to do? You can pull the patch, but that means some clients might have broken software. You can leave the patch out there, but then you risk other customers being upset by a new bug.

There isn’t a good solution here, and the more clients you have, the more likely that you have a large split of customers wanting version 1 versus those wanting version 2. You could rebuild the hotfix to remove the new bug, or you could make another patch that just addresses the second bug. The latter idea is what DevOps would suggest, with a roll forward to a third version of the software. The idea being you keep improving things and fixing bugs as you continue to develop new features. You will release some bugs, but you can fix them quickly.

The downside of this is that if you release too many bugs, customers are loathe to upgrade. When this happens, you start to find yourself having to support many versions of your software. If you respond to customers with special patches that only fix bugs without adding features, you may end up with many more versions than you can track, which can be a real nightmare for developers to manage.

How do you deal with patches causing bugs? I recently re-read a piece by Eric Sink in which he recounts releasing three maintenance versions to his customers in a week. Embarrassing for a version control vendor. It’s a good (but long) read, and one that might give you some perspective. We can’t squash every bug, and we can’t test for everything, but we can work to continue to improve, chasing the dream of bug free software. Or at least, regression bug free software.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged | Comments Off on Rolling Back One Bug for Another

Daily Coping 19 May 2020

Posted on May 19, 2020 by way0utwest

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 take a positive action to help in your local community.

This is an interesting one. What can you do in your community? You can help someone, or try to help a lot of people. It’s could be a lot of work, or a little thing. I chose a relatively little thing.

When I saw Tim Radney and Paul Randal printing ear savers, I was intrigued. I’ve been tempted to buy a printer, but honestly, I don’t have time to mess with it, and don’t need another hobby. Between trying to take care of myself, helping on the ranch, cooking for the family, and then spending time with family, I’m a bit worn out. In fact, I’m as busy as I’ve ever been.

There is a nurse that comes here for lessons, and I chatted with her one day about wearing a mask all the time. She’s used to it, but was interested in ear savers. I pinged Tim and he sent me 6, which was incredibly generous. I gave them to my nurse friend, and she really liked them. I decided to donate more.

This time, I contacted Paul Randal, mostly because he reached out on Facebook, noting he is looking to continue donating more. I sent him a donation and put in a request for 100. I’m looking to give some to my nurse friend to spread around, but I’m also giving them our randomly at grocery stores, since those people are wearing masks constantly as well, and I can see they sometimes struggle.

Not sure how much of a difference it will make, but it’s something.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 19 May 2020

The Challenge of Chat

Posted on May 18, 2020 by way0utwest

I’ve followed 37 Signals (now Basecamp) and Jason Fried for years. I think they’ve built an amazing company and have a philosophy on business and life I admire. They’ve written books, and they blog often. Recently I saw a post on chat, which is something that I’ve struggled with at times. Even before this work-at-home-at-scale experiment we’re all living, the challenges of everyone reaching out have weighed on my mind.

Without an office that physically concentrates many people together, many of us are only communicating electronically with our coworkers. We’ve had email for years, and video conferencing is growing in use, and some of us have had instant messaging for years.  It seems that chat has become more pervasive and the ability to reach out with live, interactive chats is something that has become expected in many organizations. Whether this is on Slack, Teams, or some other channel, there is some good and bad with the medium. I think the post highlights the bad outweighing the good, and it mentions a few things I hadn’t thought about.

I do have Slack running most of the day, and initially I found it to be exhausting and distracting. I think I also knew chat might create some implied consensus and lessons deep thought, but I hadn’t thought much about before reading this post. Chat has been a great quick tool for questions and answers. I often use it to pose a question about how some feature in our product works, not necessarily getting an immediate answer, but also having this work better than email as a developer can pull the question rather than it being pushed to them. It works well in threads, but not very well if responses aren’t tied to questions.

At the same time, there are enough distractions for most of us, and having more of them randomly appear throughout my day has been an issue. Over time, I’ve learned to utilize some of the advice in the piece. I ignore lots of channels and just mark them as read often. I’ll take bigger discussions into email or a meeting, and I’ve learned to not check this all day. I use it at times, but I’m happy to drop out, and even ignore direct messages if I’m concentrating. It helps I have most notifications turned off.

Attention is limited, and like time, it’s a valuable resource. As you work alone, there might be more of a need to interact and engage with others, but recognize it for the productivity drain it can be.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged | Comments Off on The Challenge of Chat