Voice of the DBA

Tag: software development

  • Updating tsqlt

    I was looking to write a new test with the tsqlt framework recently. I wanted to isolate a stored procedure’s logic and planned on using the FakeFunction procedure available in tsqlt.

    I wrote my test, using a template from the Pluralsight course on tsqlt and the documentation. I tried to execute the test and get a “tsqlt.fakefunction does not exist” error.

    I was slightly confused at first, but checking my list of functions and stored procedures showed that I didn’t have the FakeFunction procedure available. It’s a relatively recent addition to tsqlt, so I needed and update.

    After downloading the framework (a zip file), I opened it up to find this:

    tsqlt_a

    A number of files there, but the tsqlt.class.sql is the important one. I double clicked it from the zip and it opened in SSMS.

    tsqlt_b

    It’s a standard T-SQL script, albeit a long one. I executed it and it ran fine. My framework was updated to the latest version and I now had the function I needed.

    tsqlt_c

    Of course, I used my test to ensure this worked as expected and I was pleased to see it work well.

  • Artist or Scientist

    Which are you, an artist or a scientist? If you automate, you’re the latter. If you are a scientist, you can go on vacation. You can be more productive. People can count on you. You get things done quickly, consistently, and reliably. Everyone knows what to expect when you’re done with a task. They can expect things to be completed a certain way.

    If you manually run installation programs, click GUIs to configure options from memory, and customize each system you work on, you’re an artist. Artists build works of art, each of them unique. I know some incredibly talented artists working in technology, people who duplicate their work over and over extremely consistently. However at some point they’ll make a mistake, and then I’ll never know what state the system or code is in.

    While we need artists to push boundaries and experiment with new techniques, we don’t want them managing production systems or writing production code.  I want production code to use well known and proven techniques, best practices, good error handling, application of standards, logging and more. I want production systems to be stable, not with a lack of change, but with a lack of issues. I need scientists that produce work that can be counted on.

    Don’t build works of art. In development you must be an artist at times, but when you solve problems, ensure that the code contains best practices (secure coding and error handling among them), and make sure that your team understands and can reproduce the code later. In production, ensure you learn automation (PoSh, scripting, templates) and can build, or rebuild, your systems quickly and consistently. Deploy your builds to QA and development so that all the environments are the same.

    Become more of a scientist and not only will people depend on you, they’ll be less worried when you go on vacation because there will be fewer surprises for the person covering your work.

    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. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • One System to Rule Them All

    As I read this piece about a failed software procurement by the US Air Force, one section stood out:

    “In the original contract solicitation, the Air Force said that it wanted a system that was “truly ‘off-the-shelf’: unmodified and available to anyone.” But it also wanted a fully integrated system out of the box. What it got instead was three separate software products from Oracle and a collection of tools that a system integrator could use to put them all together ”

    I’ve been involved in this type of decision before, both at large and small companies. Many times I’d have liked to buy a single piece of software, but rarely could I find one I wanted or that even met my requirements. Even by sticking with a single vendor, I’ve often found myself with disparate applications that are somewhat cobbled together and didn’t work smoothly as one unit.

    That makes me wonder if it’s a silly dream to continue to pursue large single systems to handle our needs. Are we better off choosing specialized systems and planning on development efforts to integrate information together? Is the future of software a series of dashboards, web sites, and reports that access a disparate group of databases and services, each built, supported, and upgraded separately?

    On one hand I think that’s a better way to build large systems, mainly from the standpoint of size, scale, complexity, and likelihood of completion. However I also realize this means that all companies need to account for some level of software development, either in-house or on a contract basis.

    Perhaps there is no good solution and some companies will accept disparate systems while others perform their own integration work. In either case, I suspect we will continue to bemoan the state of software for the foreseeable future.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Frustration with Bad Design

    This is not how you handle things. When you find security issues, and they don’t get fixed, it’s one thing to attempt to prove a point with a PEN test. It’s quite another to publicly expose information. You might find yourself in trouble, and you should be in trouble. This is a violation of the professional responsibility you undertake when working for someone.

    This is the type of frustration that occurs in many IT workers. I’ve seen more than a few people working in technology that are sure they know how to properly configure and manage an application. They know how to set up security, and they become upset with a company that doesn’t do a good job of running internal systems. They know that the architecture chosen for their application will fail when a load is applied.

    There are some smart people in IT, but sometimes they think they’re smarter than they are. Bad design, bad decisions, mistakes, even poor security practices will occur. However it’s usually not your company, and it’s not your place to prove that there is a flaw in a system. It’s especially true that it’s not your place to prove things without having been given permission to do so. Proving a point on your own is something children do, not professionals.

    When you find problems in your organization, it is your responsibility to report them. I hope you think it’s your job as a professional to do the best job you can, following the best practices as we know them. It’s also your decision to choose to leave a job if you can’t go along with, or abide by, the decisions made by your management.

    If your company has chosen poorly in their technology decisions, I understand your frustration. I’ve often shared it, but I’d advise you to do what I’ve done. State your objections and either support the chosen path or find another job.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.