Voice of the DBA

Author: way0utwest

  • Ending My Loop in PowerShell Early

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as#SQLNewBloggers.

    I was modifying my PowerShell (PoSh) script to download SQL Saturday files recently to not re-download files. However when I did this, I also realized that I didn’t necessarily want the script to run too long.

    One of the challenges of downloading the data is that I don’t know how many events exist. We don’t keep that number handy, and it changes regularly. One of the things I decided to do was run my process in a loop.

    While ($i -lt 9999) {

    That’s fine, but it’s not a great loop. It runs 9999 times, which isn’t what I want. It works, but it’s an unnecessary use of resources. However I don’t want to break the loop when the file file isn’t found. There have been issues generating a file, like #350, when #351 exists and is there.

    I decided to use a shortcut technique I had learned as a kid. I set a variable and then incremented it when I missed a file. When the increment reaches some value, I break the loop.

    I decided to use 12 as my number of missed. No good reason, but that’s what I picked. I started by putting a variable outside of the loop.

    $missedXML = 0
    While ($i -lt 9999) {

    Then I increment this variable in the CATCH section of my error handler.

    Catch 
{ 
  # if we can't load the file, assume we're done for now. 
  $missedXML++ 
  Write-Host "error with  #" $i 
}

    Finally, I set up an IF loop at the bottom of the loop. If I’ve missed 12 times, I break the loop by setting the counter to the last value.

    $i = $i + 1
    if ($missedXML -ge 12) { 
 $i = 9999 
}

    I tested this with some debugging information and what I found was that when I got to 494, I started missing files. As soon as I hit 12, the loop ended.

    Enhancement complete.

    SQLNewBlogger

    This post came about when I started working on the script. I made the modifications from the previous post and decided to also fix the extra loops with this technique.

    This post took about 10 minutes to write.

    References

    No resources needed here. I’ve got enough PoSh knowledge to handle this task myself.

  • Rethinking Hiring

    We’ve had endless discussions here, and elsewhere on the Internet, about hiring qualified candidates. We’ve had conversations about interviewing unqualified candidates. There are also no shortage of talented people, evidenced by the the knowledge and code they share on the Internet, who struggle to find good jobs that fit their skills.

    It seems that overall, we have a problem in matching people with jobs. Many companies bemoan the difficulties of finding talented development staff, and I understand the challenges. Certainly there is no shortage of individuals that don’t bother to expand their skills and learn good, fundamentals about their craft. Often this lack of skill shows up in interviews and leaves many of the interviewers thinking they’ve wasted thier time, or the candidate has misrepresented their experience.

    However, I think part of the issue is the lack of training and investment in individuals the companies make. Maybe one of the more problematic issues I see is that we don’t have good paths for teaching and progressing knowledge, whether inside of a company or as a person seeking to learn. It seems that while there is a huge amount of information available, it is poorly organized, and very cumbersome for an individual to manage. Even with companies, we don’t seem to have well structured training that adapts and helps our staff grow.

    I thought this was an interesting piece on how many companies don’t do a good, basic job of deciding who to interview. Too often companies have fallen back on the general guidelines of a degree or years of experience in a job. That’s not a great solution, and since most of us don’t have great track records in hiring, this limits the chances we’ll see good candidates. There are definitely failings on both sides of this equation. I hear constant horror stories from people interviewing DBAs and developers that don’t know basic concepts. However I also hear from candidates that aren’t even called to interview for positions because they don’t have a degree or some other generic qualification.

    I do think that many people can learn new skills and new jobs. I think as developers and DBAs, we should be trying to learn new skills, or improve our existing ones regularly. I also think that companies should look to invest in their staff and improve the skills of individuals. I realize that this is a tough task, and there aren’t necessarily easy ways to do this, especially as it seems talented staff might just leave for another position right away.

    I hope that in the future we find companies that look to grow their staff’s skills at all levels, with the understanding that they might leave, but they might stay, especially if they are treated well. And if they do leave, a good training program will help minimize the impact, since other people should have some idea of what work is being performed, and new people can be taught the skills they lack.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Changing Scales and Creating Disappointment

    I got an email recently that notified me that session feedback from the Summit was available for my talk. I’d had a lot of people in the room, and was curious how things went. I think the session was OK, a little off on time, a few too many questions I tried to answer, and perhaps a bumpy flow.

    However when I got my scores, I had a 2.85 for the session overall, with various aspects of the talk being rated from 2.5 to 2.9.

    Well, I sucked.

    That was my first thought. I’ve been getting rated, and evaluating speakers on a 5 point scale for quite a few years at PASS events. I was surprised, and disappointed, and then a bit embarrassed that I hadn’t delivered a good talk at the Summit. Since I hadn’t delivered that talk in public anywhere prior to the conference, I thought I had made a big mistake. Apparently my practice that week in my hotel room had been for naught.

    However then I saw this note in another email: One of the changes this year was to move from a five point rating scale to a three-point scale.

    Hmmm, I missed that in my email somewhere, and didn’t notice this as I filled out a couple of session evaluations.

    I don’t think there’s anything wrong with changing the scale. Personally I like the 3 point scale, but it wasn’t a change I noticed. The first communication with speaker feedback didn’t mention this.

    Scale matters. Many of us know that by manipulating scales, we can make data look different, We can prove a point that might not be supported by a different presentation of the data on another scale.

    Our clients and business users come to know and expect the various ways we present data. They will start to internalize scales and interpret data based on their expectations. We can change scales, but we need to make it clear and visible that we have changed scales.

    Personally I would have appreciated the results being reported as:

    Overall Session Score: 2.85/3.00

    instead of

    Overall Session Score: 2.85

    That little extra information can mean a lot. Keep this in mind as you make fundamental changes to the way you present data.

  • The Auditor Attack Vector

    The phone on the desk buzzed. The CEO picked it up, expecting his assistant to let him know his next appointment had arrived. Instead he was told a person had called and wanted to discuss why his managers were paid less than some of their direct reports.

    The CEO was puzzled, and worried, so he accepted the call.

    “Did you know that you have programmers making more than some of their managers? ” the caller asked, quoting the specific people and their salaries.

    The CEO did know, acknowledged this, but declined to discuss the matter. Instead he asked who was on the phone, and how did they know the salaries of his employees.

    The caller declined to give their name, but told him that they had found a USB thumb drive outside on the street and had plugged it into a computer. A number of spreadsheets were on the drive, with one containing the salaries and organizational structure of the company. The called left the story there, promising to mail the drive back to the CEO.

    The CEO was upset, and worried, but waited a few days to get a package in the mail. He had been planning to terminate someone for carelessness. However when he opened the package, he realized none of his employees was to blame. Instead, this was a device given to an auditor who was verifying the accounting practices of the company.

    I don’t know the rest of the story, but it was given to me by someone that runs a decent sized company. It’s a scary story and shows a concern one that has nothing to do with most of us that work in technology departments. However this does show that there are always holes in our processes and practices. We need to consider the fact that many of the businesspeople we work with value convenience much more than security. We need to be sure we take precautions where possible, such as encrypting all data at rest, and in transit, wherever possible.

    It might not be our fault, and it might not be something we’re blamed for, but I certainly would feel some guilt if I had copied the data onto the USB drive without providing additional security, such as encryption or at least a password.

     

     

    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.