Voice of the DBA

Tag: software development

  • Running Multiple Threads Quickly

    Recently I was looking to generate a quick workload against an instance. I wanted to add to the amount of work my system was doing by executing a number of queries simultaneously. There are a variety of ways to do this, but I just wanted a quick set of queries. I’ll show a couple ways to do this and then look at a few other tools in later posts.

    The Cumbersome Way

    I can open queries in two windows in SSMS. Note, each of these will execute 50 times.

    2016-05-20 14_17_34-SQLQuery1.sql - 192.168.1.71.SQLServerCentral (sa (56))_ - Microsoft SQL Server

    Now I have two windows, and I can click execute in one, then click to the other, and click execute again. That’s easy. When I do this, I’ll have two threads, each running a query 50 times.

    A Better Way

    A better way is to use a SQLCMD call with my query in it. In this case, I’ll create a notepad file and add multiple SQLCMD calls in it.

    2016-05-20 14_29_03-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    The key here is the “start” at the beginning of the line. This will spawn a new thread with the program being called in it. In this case, I’ll get 5 windows very quickly, each running my query. My query is in another file:

    2016-05-20 14_28_19-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    If each query is set to run multiple times, I’ll have a simple load generated. In my case, I’ll run the .CMD file from the command line, but I could double click it. When I do, I see this:

    2016-05-20 14_30_13-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    You can see the window where I started the queries in front. Three of the command windows are in the background, each of them running queries over and over. The output from the query, with all the dashes for spacing between the headers and data, are in each window.

  • Successful Projects

    What techniques or ideas allow you to build a successful software project? There’s been no shortage of writing and studying on this topic across the last few decades. So many people expend energy and thought trying to solve the problems of building software at a high level of quality, in a reasonable timeframe, and within some scope that matches the desires of their customers.
    I’d like to think most of us succeed, but study after study shows that most parties are disappointed in some way. Developers are under pressure and can’t/don’t built the level of quality they’d like. Management sees software as taking too long and costing too much. End users see too many bugs, though I think that overall quality has risen in the last decade are more proven frameworks are used and developers have gained more experience in newer and better development techniques.
    I ran across a post on a test for successful software projects. It’s the Kevin Test for Successful Projects, and it’s based on a combination of the Joel Test and the Rands Test. The idea is not that you implement all of these test items, or do them perfectly, but that you work towards doing more of them than not. There are explanations of what each item in the test means in the various pieces.
    I think these are good guidelines for projects, and they’re simple ones. They certainly can apply to database development. However most people don’t really want to spend time on these tasks. However, I think the mundane nature of these items slows you slightly, but forces you to think more about what you’re doing. The gains in quality and velocity, in my mind, come from avoiding rework, avoiding losing work, and avoiding regressions.
    Sometimes I think the problems in software development aren’t that we write poor code, but rather that we rush a complex endeavor, being willing to redo work rather than proceeding in a more engineered fashion.
    Steve Jones

    The Voice of the DBA Podcast

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

  • Build a POC

    I have a few friends that work sales engineers for various companies. They often build a proof of concept (POC) project for various customers or potential customers, which is a great job. They get to showcase how a particular product or technology might work in a situation. We see this all time from lots of companies, including a great POC from BMW shown at the recent //build/ conference.

    Sometimes the POC is more mockup than reality, but often this is a way to actually test some software and determine if you should invest more resources in that particular direction. I’ve used this myself, setting up a small project to test items, and I recommend this for others that might want to try something out.

    For example, I like the idea of Continuous Integration (CI) for databases, but implementing CI in one of your production pipelines, on a production database is hard. It’s complex, and it can be distracting, not to mention stressful. Who wants to make a deployment mistake in production?

    What I recommend instead is that you take a small database and practice. I don’t like Adventureworks, but you could grab a few tables from your system and build a new database, download a pre-built one from SQLskills, or even just create a Hello World type database with one table. Download TeamCity, or use the Visual Studio Online build system. Experiment and learn how to take your database code and programatically deploy changes to another system. Redgate has toolsto help, or you can roll your own.

    No matter how you do it, try using a POC the next time you are wondering what the best way to proceed with new technology. You might find the POC makes a new technique more approachable and gives you confidence to tackle deploying the changes in the rapidly changing environments in which we work.

    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.

  • Dexterity Matters

    I typo things. I make mistakes in the QOD, checking the wrong box. Even in a browser at times there’s a button or hot area too close to the bookmarks bar and instead of completing an action, like checking my VSTS control panel, I’ll end up on some other website. It’s really annoying, but it’s also an issue that occurs when my muscle memory takes over with my fingers not moving as expected, or moving quicker than the system expects.

    In Star Trek or media, we see these flat, touch interfaces similar to smartphones, but there’s never any mention about the missteps or mistakes that could be made by users selecting the wrong item. As we move further from hardware controls to software selections, are we worried about issues? Is this something we run into with our interfaces?

    I certainly think so. No matter how often I can do something correctly, I make mistakes. Often simple mistakes, born of impatience. This is especially apparent in Azure and online interfaces where the control, or the browser, might not respond as quickly as I expect. As a result, I might click something multiple times, spawning more actions than I expect. Or I might have an unexpected action occur.

    This is one of the great arguments from me for having local software. The interface interactions tend to be more reliable and expected. If nothing else, a local process can allow control of the input buffer, discarding or limiting the multiple clicks that cause issues.

    As we move forward, software designers should expect that users will make mistakes and ensure there are ways to cancel or undo accidental mistakes made in an interface. This isn’t always possible, and certainly there are some actions that might not be easily undone, but as we become more dependent on software, we need to consider the potential mistaken actions that users will make and provide methods to correct issues. Especially where data is involved.

    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.