Tag: software development

  • Advent of Code

    I ran across this site after reading a post from Jeremiah Peschka. It’s an interesting idea, and since I’m trying to improve my development skills in between the rest of my work, I thought this would be fun.

    Advent of Code is a site that has a neat idea. A series of puzzles, two a day, that are released each day leading up to Christmas. Since we’re within the 25 days, I’m late (and so are you), but you can join in anytime.  It’s also cool since it’s a fixed font, console looking site.

    2015-12-11 10_25_46-Jump List for SQL Server 2014 Management Studio

    The idea is that you get requirements for a puzzle, that you must code to solve. The inputs are too long to do by hand, though I suppose if you wanted, you could solve them in Excel. If you solve the first, you get the second.

    You can solve them however you’d like. I started doing some in Python, and also then re-solved them in Powershell. It’s mostly to just get some practice coding, and these are good excuses. I have been doing Python first, but I may switch to Powershell first, just to practice. If I get time, I’d like to redo them in C# as well.

    If you are looking to do some programming on the side, and practice something, this is a good way to focus on a particular problem and have fun. If you get stuck, there is even a subreddit with people posting questions and answers in a wide variety of languages.

  • Python Command Line Calls

    There was a time I worked in a company any we lived in the command line. This was in the early 90s, prior to Windows v3.1 being released and we primarily used DOS on a Novell network.

    We also had paper phone books on every desk for the 1,000+ people on the property. However, as you might guess, the phone books went out of date, and were only updated a couple times a year. We might get a new sheet, but mostly people learned to cross out a name and write a new extension in for the people they dealt with regularly.

    However updates to the master list happened regularly, every few days. These were done in a small Lotus 1-2-3 file that an administrative assistant maintained. As a network person, I knew where this lived, and arranged a text export of this every night with a scheduled task.

    Why text? Well, I’d come from a university where we had our phone details in a text file and would grep the file to find information. In DOS, I knew we could do the same thing with FIND. However, rather than write the find command with parameters, I put a batch file on our global share that called FIND with the parameters needed and the path to the phone book. I called this 411.bat. When I needed a phone number, I could type

    411 “Andy Warren”

    I’d get Andy’s name, location, and phone number back. It was a trivial piece of programming for me, but the rest of the network team, all non-programmers, were thrilled. I even added a /? check to return help information to the user.

    With my playing with Python last week, I decided to do this for myself as well. I took my Python program to send tweets and changed it to send a tweet when the program was called, and to send the parameter as the tweet. The code looked like this::

    import sys
    import tweepy
    def send_a_tweet(tweettext):
    consumer_key = "X1GWqgKpPP4OuqWJZ7hw6"
    consumer_secret = "QW3EkMHlyzF69AHn8DjyWyRG5CAQ0wjK9RqUZ2"
    access_token = '146009-MqpeZFslj0VGgTSik1fq5klvJpqc1x6HAsiu'
    access_token_secret = '8wIZlPbIqXtczc2LOsJgjMP3dCRRw5ajMvkjEspF'
    
    auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
    auth.set_access_token(access_token, access_token_secret)
    
    api = tweepy.API(auth)
    
    api.update_status(status=tweettext)
    
    if __name__ == '__main__':
    send_a_tweet(sys.argv[1])
    

    I placed this in a “\tools” folder that I have in my path. I also added a “tweet.cmd” file in this folder with this code:

    python c:\tools\send_tweet.py %1

    Since Python.exe is in my path as well, I can do this:

    2015-11-06 15_25_19-Command Prompt

    And I’ll see this on my timeline. I guess you’ll all be able to see this as well.

    2015-11-06 15_25_26-Steve Jones (@way0utwest) _ Twitter

     

    Why bother? Well, it was partially playing around. As I have been learning Python, I have mostly been playing in an IDE, solving small problems, but not really doing things useful. I also like the idea of command line tools, since I find them quick. Tweetdeck is big and bloated, and if I wanted to send a tweet from my desk, this is a quick way to do it. I could do a “readtweets” as well, and may.

    However I also learned how to call Python programs with a command line, which is a good step to starting to build more useful programs that I can customize. This is also the start of me being able to schedule a program, and perhaps build more automation into my life with Python.

    Mostly, however, it was just fun.

  • Visual Studio Subscriptions

    Many of us that work with SQL Server do so exclusively through SQL Server Management Studio (SSMS). I find so many people really do the majority of their jobs with SSMS, Outlook, and a web browser. Even back in 2003 when I was a full time DBA, I probably spent the majority of my time in those three applications.
    However I also see more and more people using Visual Studio and other tools to accomplish their jobs. The growth of new tools, like Powershell, the expansion of our work into BI areas, and more mean that more and more people are using tools besides SSMS to work with SQL Server data.
    This past week there was an announcement that MSDN subscriptions were changing. At most of my jobs, I’ve had an MSDN subscription available to me. In fact, some of you might remember the large binders of CDs (and later DVDs) that arrived on a regular basis and contained copies of all Microsoft software. However many of you out there haven’t had MSDN available to you, or you’ve struggled to justify the yearly $1000+ cost, but you do want to work on your careers and practice with Microsoft software.
    At first I saw the yearly cost of MSDN at $799, which is a pretty large investment. However as I looked to the side, I saw a monthly subscription, no large commitment, available for $45. That’s not an extremely low cost for much of the world, but it’s very reasonable in the US. It’s also a great way to build a setup that allows you to work with a variety of Microsoft technologies at an affordable cost. What’s more, you can stop paying at any time. Or start again at any time.
    I know that it can be a struggle to invest in your own career, probably more difficult to find time than money. However this is a good way to get access to the various development and server tools for a period of time if you want to tackle a project or force yourself to learn a new skill.
    I’m glad that Microsoft has moved to a subscription model for MSDN. I expect to see this subscription growing as small companies use a small investment that scales linearly with new hires to provide their employees with tools. I can only hope that many other vendors adopt this same model and allow us to rent our tools, and upgrade, for a very reasonable cost. I just hope they all let us backup and save our settings in case we interrupt our subscription for a period of time.
    Steve Jones
  • Technical Debt

    I was speaking with one of the development teams at Redgate earlier this year. They were working on a product, and had planned out a few sprints worth of work. Each sprint, called a train, was a couple weeks long, with specific goals and ideas to be implemented. That was all good, but I noticed that there was a sprint in the middle of the list that was devoted to technical debt.

    Technical debt is a strange term. It’s one that many managers don’t understand well, often because the code may work fine. I ran across an interesting piece that looks at what the concept means, with what I think is a good explanation. We get technical debt when we sacrifice maintainability to meet another requirement. The piece also looks at the accumulation of the debt and why it becomes problematic later. Certainly the more debt that piles up, the mode difficult it can be to change code. Since we are almost always going to go back and maintain code, this becomes a problem.

    I think the ideas given to keep technical debt under control are good ones. We should make an effort to clean code as we can, though not make it such a priority that we end up causing more work with constant refactoring. We do need to get work done. However the suggestions given require a good amount of discipline and buy in from management, and I’m glad Redgate tries to keep debt under control. I think our developers like the debt trains as well.

    I thought the idea was pretty cool until I was looking for a feature to be completed and the technical debt train was running that week. I thought about complaining, but I decided to have patience and wait a week. After all, if the debt isn’t kept under control, I might be waiting much longer than a week for some fix or feature next year.

    Steve Jones

    The Voice of the DBA Podcast

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