Voice of the DBA

Tag: software development

  • GUI or CLI

    There’s a debate over on Scott Hanselman’s blog about the GUI v CLI in the comments for his Azure CLI post. It’s a blend of people complaining about one or the other, mixed with a few (I think) rational people that recognize the GUI and CLI are both valuable. In fact, there’s one person that mentions SQL Server and the SSMS GUI that can generate scripts for later use.

    I like the command line, but sometimes it’s hard. I don’t remember the syntax for a variety of commands, including various T-SQL ones, because I don’t use them very often. I may find myself depending on Google or BOL for a quick refresher, but often I’ll just use use SSMS if I can to pick some items in the GUI, click Script, and then examine the code before executing it.

    I really don’t mind someone wanting to use the GUI the vast majority of the time they’re working, but someone should be comfortable with a CLI interface. If there is a task that need repeating multiple times, then I really want everyone using the GUI. It doesn’t matter how you’ve written the code, executing something from a CLI is much more reliable than having to click around a GUI, consistently and quickly, over and over.

    I’d like to think that most computer professionals these days are able to use a CLI, even if they aren’t too comfortable. The growth of PoSh as a wrapper around so many features and functions in the MS stack certainly contributes to this, as well as the showcase of much code as code, not as images from a GUI. Github and collaboration, as well as more and more samples of code should mean that many people are comfortable working with code and executing it from some CLI.

    I’m sure there are plenty of exceptions. Someone that works mostly with SQL Server might be happy running code in a query window, but use SSMS for everything else, and maybe not even be aware that they can build things like SQL Agent Jobs from a CLI. I get it, the GUI is quick and easy. I use it for jobs, for Extended Events, and various other tasks where the code is complex and cumbersome. However, if something is easier from a command line, I like using it. Perhaps that’s why my console of choice, ConEmu, is always just a CTRL+~ away.

    Steve Jones

     

  • GUI or CLI

    There’s a debate over on Scott Hanselman’s blog about the GUI v CLI in the comments for his Azure CLI post. It’s a blend of people complaining about one or the other, mixed with a few (I think) rational people that recognize the GUI and CLI are both valuable. In fact, there’s one person that mentions SQL Server and the SSMS GUI that can generate scripts for later use.

    I like the command line, but sometimes it’s hard. I don’t remember the syntax for a variety of commands, especially PowerShell where I use tab completion constantly. I don’t even remember options for many T-SQL functions, because I don’t use them very often. I may find myself depending on Google or BOL for a quick refresher, but often I’ll just use use SSMS if I can to pick some items in the GUI, click Script, and then examine the code before executing it.

    I really don’t mind someone wanting to use the GUI the vast majority of the time they’re working, but someone should be comfortable with a CLI interface. If there is a task that need repeating multiple times, then I really want everyone using the CLI. It doesn’t matter how you’ve written the code, executing something from a CLI is much more reliable than having to click around a GUI, trying to be consistent and quick, over and over. The CLI just works better.

    I’d like to think that most computer professionals these days are able to use a CLI, even if they aren’t too comfortable. The growth of PoSh as a wrapper around so many features and functions in the MS stack certainly contributes to this, as well as fact we seee so much code as code, not as images from a GUI. Github and collaboration, as well as lots of code samples in articles should mean that many people are comfortable working with code and executing it from some CLI.

    I’m sure there are plenty of exceptions. Someone that works mostly with SQL Server might be happy running code in a query window and use SSMS for everything else. They might not even be aware that they can build things like SQL Agent Jobs from a CLI. I get it, the GUI is quick and easy. I use it for jobs, for Extended Events, and various other tasks where the code is complex and cumbersome. However, if something is easier from a command line, I like using it. Perhaps that’s why my console of choice, ConEmu, is always just a CTRL+~ away.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Detecting Issues

    Here’s a simple question: how are more of your application issues detected, by people or systems? I bet most of you initially think of your monitoring systems and the automated messages or pages that are sent out regularly as detecting most, or even all, of your problems. Have you stopped to think how many times a phone call lets you know about an issue? Do you consider the ways in which a code review or human tester brings up a concern?

    I try to think about all software problems, both the ones that reach production and the ones that are prevented early. If I catch a SELECT * in a view during development, I can prevent a problem months later when a table adds a column and no one refreshes the view in production. Those potential issues that never get to the customer are wins for me, and I think this is something we should be proud of as software engineers and testers.

    Can you move the numbers, though? Is there a way to find problems before people find them? I think there is, and it’s with better monitoring and better testing. For monitoring, we need better, and more, instrumentation that measures what we expect, looks for deviations, and (low level) alerts someone. This is an area where I think machine learning and better analysis will help. Those ML models can be hard to setup, so I’m hoping that some individuals or projects will start some work here. Microsoft is doing some of this in Azure, and I hope they share some knowledge with us.

    Testing is really the way to catch more issues before humans do. We’ve known this for decades in software development, but so many developers have been resistant to the idea of building some sort of formal test for their code. It’s not fun, it’s hard to maintain, and really, it’s just hard for most people to start writing tests.

    I think things are getting better with testing frameworks that make building and executing tests easier. We have frameworks for all major application languages, and even quite a few for T-SQL. We’ve also learned more about the types of tests to write, which type to ignore, and how to avoid building so many brittle tests that testing is more work than coding features. If you know nothing about testing, you owe it to yourself to spend a little time learning about unit testing and practicing writing tests.

    Now that we are collecting more and more data about our applications, we have the opportunity to really build software that better meets the goals and needs of our customers. However, we have to take advantage of this data, and the advances in testing, to ensure that we build the best software we can.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Multilingual Programmer

    At the recent SQL Konferenz in Germany, the keynote was from Michael Rhys of Microsoft. His talk was on the evolution and design of the U-SQL language. If you haven’t looked at it, U-SQL is what the Azure Data Lake (ADL) uses, and it’s designed to improve your ability to query various data sources in the ADL. If you want to know more, and begin working with U-SQL, we have a stairway you can go through.

    Michael opened his talk by looking at the languages he’d learned in his career. He started with APL and moved on from there. He asked if anyone had used APL, and there were few of us. It was my second language at University, and one I didn’t enjoy. The nature of the language was un-intuitive to me, and I was glad I only suffered for a few months. If you’d like to try it, you can tryapl.

    I thought this would make a fun discussion, so I wanted to ask: what languages did you learn for programming and in what order?

    For me, I started with BASIC, and a little assembler with early systems. I moved to Pascal in high school, trying to develop fun games and computer assisted homework help for myself. In University, I began with LISP, which caused plenty of people to drop out of computing. I’m not sure if that was a good idea or not, but I enjoyed that. From there, I went to APL, Assembler, Fortran and C before switching away from computers for a bit. When I returned, C++ was all the rage, and I soon found jobs that paid me to write FoxPro/Clipper code, then VB, then a touch of Java before the web became popular and I worked in ASP and ASP.NET. Along the way SQL became more and more of my career, and I’m glad it did.

    These days I’m trying to improve my C#, PowerShell, and Python skills, more for fun than anything else, but those are sueful as both languages are useful in data work. I haven’t done much with R, but I have fingers crossed that the sp_execute_external_script call that allows a parameter of @language=N’Python’ gets added to SQL Server before I need to learn any R. After all, most of the R libraries exist in Python, and I find the language much more intuitive.

    Let us know today what your journey has been, and if you haven’t been a developer, maybe its time to learn some programming skills. After all, I think that’s important for a DBA.

    Steve Jones

    The Voice of the DBA Podcast

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