Voice of the DBA

Category: Editorial

  • A Bug or a Vandalism Opportunity

    I hadn’t heard about this problem at all until I saw a story recently. Apparently a one line command can be hidden inside a Windows shortcut file, a ZIP archive, batch files, or various other vectors. This command can trigger hard drive errors that corrupt the device.

    Yikes. A researcher apparently has been trying to draw attention to this since August, but it has not been fixed. What is scary is that this issues can be exploited by tricking standard accounts in Windows, not just privileged ones.

    However.

    It’s not really a big problem. I asked around and someone sent me a few links that this doesn’t actually corrupt the drive, but just gets Windows to report this. In that case, this might not actually do anything, but it certainly would cause my blood pressure to rise and my heart to skip a beat. This also might be a great phishing vector.

    If you get a message about corruption, check that it’s actual corruption and not just the report from a shortcut or link that uses this message. Certainly, be careful about what you click.

    And if you’re thinking of playing a joke on someone, this isn’t a good choice. This is more like vandalism than fun. I certainly wouldn’t be pleased if you did this to me.

    Steve Jones

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

  • AI Can Improve Healthcare

    It’s early days, but I found this article to be very interesting. In this case, an AI model was trained to use some patient feedback on knee pain, as opposed to a previous methodology. The old methodology did work, but it had some problems with some populations.

    I haven’t thought that much of our ML/AI (machine learning/artificial intelligence) work is particularly smart. The algorithms learn well and they can match or out-perform humans, but these systems are really mimicking what humans do. They can be more reliably and definitely more scalable, but it’s doing what we humans do, not often leaping ahead.

    Often we train these models based on previous data and results from human experts. However, often what we think of as expert advice, what many people accept, is flawed in and of itself. Humans often work with a small set of data and experiences. They find patterns and create a solution that works, but not always as well as we’d like. Especially as the solution is applied to a wider variety of situations.

    In this case, researchers looked at alternative methodologies, and used AI/ML to test whether a different solution might be better. This isn’t going to replace the current methodology for now, but it might get more doctors and researchers to rethink how they approach this particular issue.

    This might be one area where AI/ML truly help humans move forward. By looking for gaps, oversights, and other problems in our existing methods, the computer might spur humans to make new leaps that help us drive forward.

    Steve Jones

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

  • Tough Interview Questions

    Many of us know that interviewing someone and evaluating their skills is a tough job. There have been all sorts of techniques tried by various companies, some of which require creativity, but many are related to technology and practical skills. All in all, I’m not sure any of these really predict if someone will be a valuable employee.

    I’ve seen a lot of senior technology people lament the quality of the candidates they interview. I suspect some of this is that most of the really talented people aren’t out there interviewing regularly. Instead, there are many people applying for jobs, some with narrow sets of experience that might not match what you are looking for. Some may be applying for jobs that are beyond their skills, hoping to get through an interview and get an offer. Maybe others rub the interviewer the wrong way, and create a negative impression that doesn’t represent how the person might work with others.

    I ran across an article that listed a number of SQL Server interview questions, most of which are aimed at experienced developers. It’s not a long list, but it does cover some topics that aren’t necessarily things that you use often in SQL Server. While I have written an INSTEAD OF trigger, I haven’t often and might not give a great answer for someone that is looking for deep knowledge. I would like to think I can give a decent explanation of what this is and where you might use it.

    Perhaps that’s the intent, however, to see if an experienced person has touched a lot of different features in SQL Server. Maybe this is a breadth more than a depth list? I’m curious if you think that is the case. Maybe you have an opinion you’d like to share on these, or other questions, which might help you determine the experience of a candidate.

    Finding a great candidate for your organization is hard. It doesn’t matter if you are looking for junior people that can grow, or senior ones to lead. Often interviews result in an impression that is a bit of a coin flip. After a year ,you may or may not feel that you made the right decision.

    Steve Jones

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

  • Do it. Try it. Fix it.

    “Do it. Try it. Fix it.” – Sam Walton

    That quote is interesting, and while I don’t think Sam Walton was thinking about software, this is the loop that I, and many others, follow. We see a problem, and we try some things. If they work, we move on, if not, we fix things.  At least, that’s the approach most of us would like to take when we see an issue. Sometimes management gets in the way of us following a simple process.

    The key part of that quote is the first part, the part Sam Walton talked about was acting in some way. Doing something, making a positive move towards improving something. Many of us want to take action, especially when we see a problem. Again, however, management can get in the way if the problem isn’t prioritized.

    There’s one part in DevOps and software development that comes after the “fix it.”. We need to ensure we don’t repeat that type of mistake. This means that when we find a solution, especially a better pattern of building something, we share it. We use the feedback loops and learning ideas in DevOps to ensure others in our organization don’t need to do their own “Do it. Try it, Fix it” loop and repeat our work.

    One of the hardest things to convince smart (or very busy) developers to do is change their work habits and patterns to implement something new. While it can slow things down, or create other work, in the long, or even medium term, we can all be more productive if we take the time to share what we’ve learned. We also need to take the time to learn what others share.

    Of course, proving your way is better can be a challenge. You need to be sure of yourself, gather evidence, and learn to present a convincing reason why someone else should change. If you can do that, you will have more success.

    Steve Jones

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