Voice of the DBA

Category: Editorial

  • The Machines are Learning

    One of the technologies that Microsoft is promoting heavily is machine learning. This has rapidly gone from a technology that I heard little about to being in multiple keynotes that I’ve seen at large conferences this year. It almost seems that I can’t go a week without seeing some sort of machine learning article, announcement, or reference.

    How applicable is machine learning for most of us? I’m not sure, but banks have certainly taken advantage of machine learning to reduce their risks associated with fraud and their systems work well. In fact, given the ways in which I travel, I’m amazed that I don’t get more calls about fraud related to my card use. With me in a new state almost every month, on a very irregular schedule, sometimes buying computer supplies far from home, I get called by a bank once or twice a year.

    Across the ten or so calls I’ve gotten in the last few years, only one questioned legitimate purchases. The rest caught fraud on the same day that someone tried to use my card without my knowledge. That’s a very successful rate of both true positives, and a very, very low rate of false positives. I’m impressed.

    If you haven’t played with machine learning, Microsoft has made it easy to give a try in Azure. You don’t even need to put in a credit card to get up and working with machine learning. Whether it’s applicable to your industry or not, you’ll have to decide, but I do think that lots of tedious analysis that humans do now could be better done by a machine.

    At least after one of us humans has configured the algorithms and trained the machine to recognize patterns. And, of course, with one of us technologists periodically tuning the system to work better  and monitoring the analysis as data changes.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • The Years of Experience

    I heard Tim Ford say recently that the years of experience don’t matter as much as what you do with them.

    That’s a great quote. It’s also one that goes along with the idea that there is no shortage of people that mistake 5 years at a job for 5 years of experience. It’s highly likely that many people really get 6 months of experience and repeat those same skills for years, because that’s what the job requires. Unless you have a dynamic, changing environment, one that experiments and regularly looks to upgrade systems, it’s hard to get those years of experience without changing jobs.

    That’s a conundrum. Do you want to change jobs to get new experiences and grow? Some people become consultants for this reason. Others regularly look to move on to a new company, sometimes sacrificing benefits, short commutes, or something else to grow their careers. However plenty of people prefer to stick with an organization, whether that’s because loyalty, a great set of coworkers, security, or nature of the work being accomplished. Many people will stick with a job as long as they can.

    In those cases, I do believe that you can still do something with your years and grow experience. Continue to learn, experiment, and suggest changes where they fit. Learn to write the complex T-SQL that’s needed in older SQL Server 2005/2008 systems, but spend a bit of time also learning how Window functions in SQL Server 2012+ run more efficiently. Rebuild reports in PowerBI, and see if your organization can see the benefits of investing in one new thing this year. Even if your company won’t make changes, imagine what you’d do if they ever change their minds.

    Above all, practice your skills. Rewrite old processes and squeeze out more performance. Automate things in your job, whether you use PoSh or VBScript, when you can make gains in productivity, you can create time. Time that’s valuable in helping you learn. Even if you can’t get your code deployed, will will have the satisfaction of improving your skills, and knowing you can make a difference if you ever get the chance.

    I realize many of you are busy. I realize that learning about R or Kimball data warehousing might be seem to be pointless because your organization will never use the technology. I get it, and I don’t disagree. However I hope to inspire you to try to enjoy technology. Jump on Twitter with the #sqlfamily and gain some motivation with what others are doing, or have them cheer you on as you learn. You might be surprised what you can do with your years when you find something you enjoy and get support from others that share your excitement about computing.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • The $90,000 Laptop

    A hospital got the opportunity to pay $90k for a lost laptop.

    There’s no excuse for this. If you have a Windows laptop, enable bitlocker today. If you have OSX, setup FileVault. If you’re on Linux, choose dm_crypt or something else. Go ahead, get that setup, save off your keys as a backup, and come back. I’ll wait.

    Now, don’t you feel better? I’m sure you do, and you are somewhat more protected from the random theft, misplacement, or loss of your laptop. All of those things happen regularly. Not to each of us, or many of us, but as the collective set of developers and DBAs around the world, we lose laptops regularly.

    Certainly some of us have precautions like never carrying data around. That’s good, and I’d recommend that. For those that need to develop on the go, they might have a curated set of test data we can use for development. That’s fine. We should make an investment in building test data and have that data used for unit, integration, and system testing.

    We should have investments in ensuring that our systems can not only be encrypted, including encryption of backups and networks, but that we can restore those systems in disasters. Make the investment in ensuring recovery, and everyone is more likely to accept encryption. We need to invest in a process for managing keys, revoking them, and re-issuing them. We need to be sure we can upgrade encryption algorithms over time. What is secure today might be easily broken tomorrow.

    I’d urge you to make all those investments, but until you do, at the very least, encrypt your laptops and desktops. While any random theft could result in a lost laptop, it’s not unheard of for anyone walking through your office to pilfer a drive lying around, or even one inside a desktop.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Security Decisions

    How many of you have written code that results in a security issue or data breach? It’s possible many of you have, but are unaware of the issues. I’m sure a few of you have been hacked, have had to clean up data or code, but often it’s not your code. Maybe it’s something you inherited. Maybe it’s code your team wrote together. In any case, the feedback loop between your action (writing code) and the result (a security incident) isn’t tightly coupled.

    I ran across a post from Bruce Schneier on how people learn about cybersecurity. The piece links to a research paper, and it’s an interesting read. It turns out the researchers see most non-experts learning from news, friends, and websites, often with biases towards actions that have had immediate negative consequences, but not necessarily those that are more serious.

    That has me wondering about us, as supposed expert, or expert-ish, developers and DBAs. How many of us get security training, or get this training updated? How many of us learn from friends, or websites, and re-use this knowledge over and over in our work, not necessarily understanding, or unsuring, that we are building in strong security into our systems. I suspect many of us just try to get by, writing the minimal level of security that “works” for us, not really understanding how there might be flaws or holes in our system.

    Our code, our configurations, our systems have much farther reaching impact than ourselves. In some sense, I think that a fundamental broken concept of information technology is the lack of security practices and architectures being built into our platforms and applications from the start. While convenience may get the boss off our back, or allow greater profit for our companies, it’s not helping our industry, or even our companies in the long term.

    I just wish I had some idea on how to change things.

    Steve Jones