Voice of the DBA

Author: way0utwest

  • The Advent of Code

    In early December, I ran across a post from Jeremiah Peschka on practicing your coding skills. Apart from the points made about practicing skills, he referenced a site called the Advent of Code. It’s a site that uses a Christmas theme and a little gaming to get people to solve programming problems. I mentioned it on my blog, and across a few weeks, a few people in the SQL Server community started working on the problems in SQL.

    Probably like most people that started this, I didn’t finish in December. In fact, I didn’t work on problems most days because life got in the way. However I haven’t given up. Around vacations and other events, I’ve continued to work on solving the problems in multiple ways, using different languages. I’ve tackled problems in Python, PowerShell, and T-SQL.

    I’d urge you to give some sort of programming challenge a try, mostly just to gain some practice in building algorithms and investigating the ways in which you can solve problems with software. If nothing else, the exercises challenge your brain and exercise your mind.

    I’m considering working on something like this for SQLServerCentral next year, with a series of complex problems that you can work on to practice your T-SQL and SQL Server skills. I don’t think I’ll make it an Advent of T-SQL for Christmas, but I do think having a series of challenging problems is a good way to drive your learning.

    If you’ve got suggestions for other programming exercises, feel free to pass them along.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Hash Tables in PowerShell–Advent of Code Day 3

    I continue to work on solving the Advent of Code puzzles in both PowerShell and T-SQL after completing them in Python.

    When I hit day 3 in PowerShell, it was a few new tricks to learn, one of which was reading a large string from a file. However the interseting thing for me was learning to work with hash tables.

    The Day 3 puzzle looks at moving Santa around on a grid. We don’t know the size or shape of the grid, just that we get directions in 1 of 4 ways (^<>V) and then must move to a new house. The first puzzle asks how many houses get one present.

    This is interesting, and naturally to me the first thing that occurs is a dictionary. I used one in Python, adding new elements as I received new coordinates. I wasn’t sure how to do this in PowerShell, and ended up searching a bit about two dimensional arrays, thinking I could perform a count there, adding indexes as needed. However I ran into hash tables while searching, and this was a better solution for me.

    The short part of working with hash tables is that you declare them with a simple command. In my case, since I had a delivery at coordinates (0,0), I wrote this:

    $houses = @{“0,0” = 1}

    This uses the @{} syntax to set up a key value pair. Essentially a dictionary. From here, I computed new “keys” from the directions, and could add new values like this:

    $houses.Add(“1,1”, 1)

    Of course, I had to check for existing values, and if there were existing values, I had to increment them.

    $houses.Set_Item(“1,1”, $houses[“1,1”] + 1)

    With that code, I could easily solve the puzzle. However I was struck by the various ways I work with the hash tables. I use braces, {}, to declare the table. I use brackets, [], to access elements and then parenthesis, (), when calling methods. All of that makes programming sense, but it’s something to keep in mind, especially as those three marks mean different things in Python.

    I also learned how to search with ContainsKey and ContainsValue, as well as how to Set_Item and Get_Item, which didn’t appear to work with the ISE Intellisense.

    All in all, it was interesting working with a hash table and good to learn PowerShell supports them. They are very handy constructs when building up a set of data that you’ll need to work with, and you need more than the simple buckets an array provides.

  • 100 Hours

    How long does it take someone to learn to be good at building software in some language? I’m sure many of you have heard of the 10,000 rule that notes the truly gifted in a field need 10,000 hours of practice to become experts and master their craft. There’s some debate about how true that is, but certainly becoming an expert takes tremendous dedication, certainly years of time.

    I ran across a piece that referenced a slightly shorter rule, the 100 hour rule. The rule is fairly simple: “for most disciplines, it only takes one hundred hours of active learning to become much more competent than an absolute beginner.”

    One hundred hours is nothing. That’s a long week or two of active learning to get good at something. But how good? If we look at software development, what can you accomplish in 100 hours? After all, absolute beginner is a low bar. That’s the level my Mom is at and I’m not sure how much I could teach her beyond “Hello, world” in a few hours. Even in 100 hours, I’m not sure she could solve many problems.

    The good thing is that most of us aren’t absolute beginners, especially in software. We have frames of reference for many parts of how computers work. I suspect that 100 hours of deliberate, guided, practical (meaning typing and practicing skills), would turn lots of people into a good junior developer, maybe even a mid level developer. I think many senior developers would be very competent in a new language in a few hundred hours, because they’d learn the syntax translation quickly and then start understanding the tips, tricks, and gotchas that experts in that language might know. The algorithms and problem solving skills are often the same between languages.

    For most of us looking to grow our careers and improve our technology skills, I would guess we could learn a new skill every year, becoming competent, with 100 hours of practice. Reading books and articles is good, but the hands on practice is most important, and that’s what really drives home active learning. That’s something I’d encourage many of you do, with exercises, puzzles, or maybe even start a small project that help you learn. It will help your career, by improving skills, and might even be fun along the way.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Adios, IE

    The first browser I used on the Internet to find information was the text based lynx browser. This was quite an improvement (at the time) over Archive and Gopher. When Netscape released their Navigator browser for Windows, I abandoned those old tools, moving on to a new way to access information across the world.

    However I primarily worked in a Microsoft world as my career grew and that meant using Internet Explorer, or IE. In fact, I remember thinking all the ActiveX extensions and the bundling on installations of Windows meant that the browser was convenient. It was even nice to program on, since it dealt with poorly formed HTML fairly well. However it had plenty of issues and was a never ending source of calls from customers that had stability and security issues.

    In fact, sometime around Windows XP, I moved to Firefox and never looked back. I only had IE installed on my systems because Microsoft included it with the OS. The last 5 or 6 years, I’ve run Chrome and Firefox together, only using IE when a few specific sites required it. Even then, I’d give an inward groan each time I clicked on the familiar “e” icon.

    However times have changed. This month, on January 12, Microsoft ends support for all versions of IE prior to 11. While IE will still be run for many years by some people, just as Windows ME and NT 4.0 still exist in places, Microsoft won’t provide support or patches, and we can only hope that people switch to another browser quickly.

    I haven’t been thrilled with the Edge browser in Windows 10, as it hasn’t worked in some sites I use regularly. That seems strange to me, but alas, the idea of a Microsoft browser not working the same as other browsers is nothing new. I can only hope that Microsoft fixes the issues in Edge rather than having web developers include code to handle the finicky nature of Microsoft’s browser technology.

    The death of IE shouldn’t matter much to us, as data professionals, but I wonder how many of us still have applications using web browser controls based on IE technology. I suspect quite a few, and it’s entirely possible moving forward that we’ll continue to deal with issues of poor rendering of data from our databases through web controls for many years to come.

    Steve Jones