Voice of the DBA

Author: way0utwest

  • Life Logging

    This editorial was orignally published on Dec 8, 2009. It is being re-run as Steve is on vacation.

    There’s a new book from Microsoft Research called Total Recall. It’s actually on my list to read soon. It’s from Gordon Bell of Microsoft Research, and it talks about the idea of life logging, of capturing things about what you do and what you’ve done, in audio, video, and text. These might be things that are private, available to you and not the public. Or things that you might want to share with some people, like your family, but not others. Dr. Bell actually carried around devices to record his life for a long time, with the idea of working through the technological hurdles of life logging.

    Whether you think you’d like this in your life or not, it’s an interesting knowledge idea for companies or individuals. Maybe it’s a good idea for programmers or DBAs. What if you could have all the code you’d ever written? What about tests of that code and the applications where it had been used? Would a walkthrough of tuning efforts you’d made for some types of SQL or even queries that solved particular challenges be useful? What about a walkthrough of the changes to your schema across time?

    There are some interesting possibilities here in terms of your career work. If you could add meta data, annotations, correlations between emails, requests for work, problems, your particular implementation, and then the later results,  you might learn from your mistakes quicker. You could perform some type of root-cause analysis of your efforts across time, or on a system and find out what you are doing wrong, or what you’re doing well.

    I don’t know how well you could analyze someone’s work and help them find out what they’re doing well or not well. I also have some serious concerns about the privacy and security of the details about someone’s efforts being shared without their consent, or even the ownership of this data. But I think there are some great possibilities here as we develop new, and cheaper, ways to collect and store all kinds of data.

    At the very least having a “life log” of a server might prove to be a very valuable troubleshooting tool.

    Steve Jones

     

  • SQL in the City This Fall

    We’ve got a couple of large SQL in the City events coming this fall.  I’m speaking at both, which I think means my boss is happy with my work for Red Gate Software. At least, that’s what I’ll tell myself.
     
    In a little over a week I’ll be in both London and Seattle, delivering a variety of sessions on DBA and development topics. I start the day off with a session for the DBAs with Avoiding a DBA’s worst days with monitoring. This is based on The DBA Team’s 5 Worst Days in a DBA’s Life where we look at some of the situations you can avoid by keeping an eye on your environment. I then cover Version control and CI Fundamentals for databases, looking at how you can get your database code in a VCS and build a Continuous Integration (CI) process. I’ll also cover testing, using the free tSQLt framework to write some tests against your databases.
     
    It’s a quick set of sessions for me, but I’ll be around all day to talk to you about your database delivery, deployment, development, or administration issues. Or just shake your hand if you’d like.
     
    I fly to London for our event on Fri, Oct 24 and then will be in Seattle on Nov 3 for the second stop on the tour. A lot of travel for me, but I’m sure it’s an easier commute for most of you.  I hope you’ll join us and come learn a bit more about SQL Server than you might know today.

  • Challenge Yourself

    I am a proponent of blogging as a way to build your brand. Your work showcases your knowledge, thought process, and interests. It provides a way for potential employers to perform due diligence and determine if you are a good fit for their team and position. Blogging can also help you to learn more about your craft and focus your learning. After all, it’s been said that if you can’t explain something to others, perhaps you don’t really understand it.

    As I meet people, and talk to them about blogging, I often get asked “what should I write about?”. The easy answer is to write about the things that you do on a regular basis, the problems you solve at work, and the solutions you implement. However, what do you write about if you don’t do much at work and are looking to learn new topics. If you want to show that you are building experience with SQL Server in a way that isn’t required at your current position?

    I think it’s easy, and I’ll give you a few ideas. First, build a lab at home. These days it’s easy (and free) with VirtualBox and a little memory, both of which can be had for relatively small investments. Next, start following the #tsql2sday tag on Twitter and challenge yourself to get a post written every month. However don’t stop there. I keep a list of previous topics and you can go back and write a post for every one of those topics. Your effort won’t be in the recap, but you’ll force yourself to learn, or at least explain, your thoughts in those areas.

    If you want additional challenges, read a question like this one on splitting strings. Don’t read the replies, but try to answer the question on your own by writing a blog that explains your solution. You can link to the post and show how you would solve the issue if you encountered it. If you want to press yourself further, go through my list of article requests and pick one. It doesn’t matter if the article has been written and published or not. Write your own solution on your own blog, as I saw Jason Carter do here for this request on exporting XML files. Feel free to submit your post as an article, and maybe we’ll publish your solution as well.

    There are so many ways to challenge yourself and learn more about SQL Server that it could be a full time endeavor by itself. Please don’t make it one, and remember to balance your career growth with the rest of your life. However, do continue to work regularly on your career, and showcase your knowledge. It’s good practice for your communication skills, and you never know when you might count on the wide breadth of knowledge you’ve documented to help you land that dream job.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Making Better Presentations–Organize Things

    This is part of a series of tips for speakers on how to make your presentations better.

    Organization matters, and it makes a difference to how your presentation goes. The more organized you are, the better the experience for attendees. If you are very unorganized, then it becomes hard for the audience to follow what you are doing.

    I’m am giving a few tips and tricks here, not for the actual outline and focus of your talk, but a few items that can help you smoothly move through your presentation.

    Startup

    Most of us don’t present a talk exclusively from Powerpoint. If you do, that’s great, but often I find people need to move from Powerpoint to Management Studio, or switch to a VM, show code in Visual Studio, run a browser (for Azure), etc. I personally need to sometimes run Red Gate tools as part of my talks, so I’ve learned to get organized.

    I actually got this trick from Brad McGehee and I think it’s great. As I’ve written and organized my talks, I’ve learned to make notes in Powerpoint. Every time I need to run some tool or application, I put a note in the first slide of my deck. These are a few things I need to run, and when I get ready for a talk, I have a list of items to start right away.

    Here is the first slide from my Continuous Integration for Databases talk.

    betterpresent_a

    Even if you only have one talk, it’s easy to forget things. I’ve seen lots of presenters forget to run Zoomit, start Visual Studio, or even SSMS. As someone that watches dozens of talks a year live, I can tell you it’s less than impressive or exciting when I get to watch Visual Studio start up on a projector.

    Code

    I’ve tried different methods for organizing my presentations. I’ve put all the code in separate folders. I’ve numbered the files; I’ve named them. I’ve put everything in one long script file with comments.

    All of those have worked, and all of them have failed. The important thing is that you have some organization. When you’re speaking in front of people, you’re concentrating on your topic and flow. Anything that distracts you is PAINFULLY obvious for attendees.

    It will happen, no matter what, but minimize it. Get some sort of organization and ensure that what you’re showing on the screen smoothly transitions from one section to the next.

    Comments

    In line with having code organized in files, I would highly recommend that you include comments and notes in your code for both you and the audience. We are trying to teach and explain our code and concepts. There’s no mystery or magic that we need to keep people from knowing, so the more we can disclose, the better.

    Your attendees will appreciate some instructions in the code when they try to duplicate your efforts on their own machines. However these same instructions can be very helpful for you during a talk. The instructions will guide you alone, allowing you to continue to speak and explain things, without trying to multi-task and remember the flow of your presentation.

    Think Ahead

    All of the organizational items really come down to you thinking ahead. Just as you might do as a DBA or administrator, considering what might go wrong, or what might interrupt your “uptime” as a presenter will help you prepare for a smooth delivery in front of an audience.