Voice of the DBA

Tag: software development

  • Secure Programming

    This editorial was originally published on Mar 19, 2009. It is being re-run today as Steve is away at DevConnections.

    Writing secure software is hard. The way most people learn software, from simple examples that slowly build our knowledge, doesn’t encourage complicated solutions that provide robust error checking, error handling, and secure practices. Most examples that I’ve seen in the world include “dumbed down” code that is easy to understand and explain in a class or seminar.

    And that’s the code that often gets used by developers.

    They go with the simple example, and enhance it, not really concerning themselves with best practices, or even great practices. In fact, if you search for sample code on the Internet, read articles on various sites about programming, or buy a book from an “expert” it seems that more often than not, the code isn’t well written from a security perspective. Yet that’s the code, and the mentoring, that many developers get.

    And for a DBA, that code is a nightmare.

    Too often the code samples and practices that are taught to people include dynamic SQL built in the application with little to no thought about SQL Injection. And it doesn’t matter if the application is at fault. As the DBA it’s often your phone that rings, and you that end up explaining to your boss why all the products on the site cost $1, or why every customer’s name is “0wned by S&p#rG##k.”

    The NSA, along with a number of other companies, is trying to do something about poor programming practices. They have release a list of the 25 most dangerous programming mistakes. What’s interesting is that some government agencies, and hopefully companies soon, are using this list as a litmus test for vendors. Software companies are being asked to guarantee that their software contains none of these mistakes.

    I think it’s a great idea, and I wonder how well it will be enforced. Microsoft and Oracle, among quite a few other software vendors, provided input into the list. You’d hope that their software would be fixed, or at least all new software would comply with the recommendations and not contain any of these mistakes.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s 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.

  • Best Practices for Database Deployment

    The easiest part of any deployment is running the deployment script on production. But what have you done to prepare that script for production? Was the script tested? Is the script tightly coupled with the application code?

    The difference between a successful deployment and a failed or problematic deployment is all the preparation work you’ve done to ensure that you’re deploying the right script, the right way to your production environment. This session will explore best practices that you can implement to ensure that your deployments are as successful as they can be.

    Slides:

  • Automated Build and Test

    Continuous Integration (CI) is a well known process in the software development world, but it’s not often implemented with databases. This is despite the fact that database code could benefit from the practice of checking the changes on a regular basis for potential issues. This talk will show how to implement continuous integration for databases and include more realistic testing of the code for potential issues.

    We will set up CI for a SQL Server database project, using the following tools:

    • Team City (CI Server)
    • Subversion (VCS)
    • SQL Automation Pack (database -> CI integration)
    • tSQLt  testing framework
    • SQL Data Generator

    Slides

  • Team-based Database Development with Version Control

    An efficient development process requires that all of your team members coordinate their efforts. This session shows how a version control system (VCS) and standard development practices help improve the speed and quality of your development process.

    This talk will look at:

    • reasons for using VCS
    • methods for including a database in version control
    • how we share changes from a VCS
    • linking static data in VCS
    • enforcing standards in development

    Length: 60-75 minutes

    Slides: