Voice of the DBA

Author: way0utwest

Prepping for 2015

It’s important that you regularly work on your career to continue to grow, and these days, ensure that you can find a job. It doesn’t matter if you’re a doctor, an electrician, a banker, or a technologist, the world seems to be regularly changing many of our jobs. Whether we need to deepen our current skills or learn a few new related ones, I think it’s just prudent to continue to develop yourself as a professional.

I think it’s fun as well when you can learn a new skill or two.

I ran across a post that talks about the top skills that will be in demand in 2015. There are 9 items, and while you should take this information with a grain of salt, it is an interesting list in a few ways. I would guess it’s fairly representative of those areas that recruiters are having a hard time finding people, so while your SQL Server, C#, Javascript, etc. skills are still valuable, adding one or more of these might help you feel a bit more confident you could get a new job if you needed one in 2015.

PowerShell is the first skill listed, and I think it’s important. If you work in the Unix world, you probably already know how to script in one of the shells, and for Windows people, PowerShell is the equivalent. Whether you manage one server or 100, this can help you more consistently handle your environment. For SQL Server people, there are some very handy uses for Powershell, especially for file type operations or DR, so I think it’s worth learning.

Many of the other skills like cloud computering, O365 and Google Apps, compliance, mobile, are more buzzword driven, but that doesn’t mean they’re not valuable skills. Managers hire people and write checks, and if they think some of these areas are worth implementing projects in, they’ll be jobs available.

The last item listed is soft skills, and if you had to pick one area to work on, this would be the one I’d recommend for most of you. Soft skills translate to any company and any position. They are more and more important these days as scarcity of jobs mean that employers have choices, and when all your candidates have similar technical skills, the things that stand out are the people that communicate better, act as team players and can build bonds with others.

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.

September 10, 2014
Untested

The 2014 Apple keynote was today, with the announcement of the iPhone 6 and iWatch taking center stage. I was excited, with an aging iPhone 4S that needs to be replaced. I tuned in, expecting to watch the announcements while taking care of some busywork on the other monitor.

At first I saw this screen (though at about 20 minutes beforehand)

About 10 minutes before the event, the countdown switched, and noted that my browser (Firefox) wasn’t supported. I almost switched to Chrome, but then saw the fine print. I wasn’t thinking and didn’t take a picture as I ran to grab my iPad, but Karen Lopez posted an “altered” version of the Apple page.

Fair enough. Apple doesn’t have to broadcast to everyone and I get that they want to let their iPhone/iPad/iTouch/Mac users see it live. The keynote was available about 30 minutes after the end for everyone, so no big deal.

In fact, in the scheme of my life, not being able to watch live wasn’t a big deal. I can catch the “showmanship” an hour later.

However I was surprised when my iPad kept showing a test screen from the broadcast truck. When it connected, it was sputtering and halting, even when a speed test showed me getting 20+MBps at the device.

I did manage to watch a little, with a Chinese translation overlaid on the sound, at a higher volume than the speaker for me. Slightly annoying, but I could deal with it.

About 15 minutes in, things started crashing, with Safari on my iOS 7 iPad and iPhone crashing. The iPhone would start Safari and connect to the Apple home page and show this:

The iPad connected a few times and showed this:

I gave up, going on with my day, knowing I could watch it later. However that brings up the question.

Did Apple test in Production?

By this I mean, did they actually test the broadcast of this event today, with the live event, or did they test things last week on a copy of what this environment would look like? Did they actually run through the same settings for broadcast that they would do today?

I do suspect they did some testing, and certainly it’s possible that many, many more people than they expected tuned in. They may have been overwhelmed, and that’s understandable. I doubt anyone has any good way to determine what capacity to plan for, other than to just guess. This event might have been larger than the Super Bowl, World Cup, etc.

Or maybe Apple didn’t want to bother scaling to a capacity beyond some xx% of Apple device owners.

Any of those is fine with me, and I can understand someone deciding to spend $yyy on this, though I’d argue it was a mistake since this is a great chance for an amazing amount of publicity and hype for their products.

However there are certainly other problems that I question the level and detail devoted to testing. The overlay of foreign languages means that someone hadn’t configured their audio correctly, and more importantly, no one was monitoring to stop the problems quickly. The problems with the stream meeting devices might have been capacity, but crashing the browser? Either there’s a major QuickTime issue, or the encoding was broken in some way (perhaps again, by capacity).

This is a shot at Microsoft as well, but I thought Tim Ford’s summary was spot on:

We talk about thorough testing on a copy of production. A real, scale, same sized version. Few of us do it, but certainly some do, especially those with big budgets. Apple has big budgets, so I suspect that their testing was cut short, or someone assumed things would work the same way they had in the last keynote, which went off without a hitch for me.

Complacency, coarse attention to detail, poor quality control and monitoring seemed to be in play today. None of which as a good thing.

Perhaps Apple was testing in production.

September 9, 2014
Estimates

Estimating the time it takes to build a piece of software is quite a difficult task. As many of us have seen over the years, most estimates can wildly differ from the actual time it takes to complete a project. There are lots of reasons for this, but I was surprised to find this post explaining some of the problems in a very interesting way.

I realize that many software projects are very different in scale and scope, but I hadn’t ever considered the spectrum to be quite as wide as explained in the post. Just as in other industries, there are times that your software project needs to create its own technologies and techniques in order to be successful. While software might not be as complex as curing a disease, it might not be that far off at times.

However it’s not just that the body of knowledge about software development techniques is so vast, it’s also the problem that each of us might have a very limited amount of knowledge about building specific types of projects. What might seem simple and easy to some developers feels complex to others. A simple example I’ll give you is with version control. I know version control isn’t the same as building software, but it’s a tool that many developers use.

I think version control is fairly trivial to implement and use. It can be a pain to use with T-SQL code and scripts without some tooling, but it’s easy to learn how to use a version control system (VCS). However as I’ve spent two years talking about version control at various events to lots of people, and I still meet lots of people and organizations that see a VCS as an impediment to getting work done. Hint, it’s not.

I think we share so much knowledge in the SQL Server community, but it still seems that we don’t seem to be educating people as well as I’d like, and as quickly as I’d hoped. Our Stairway Series were designed to try and organize information, but I’m sure there are other, better ways to do so. I’m open to suggestions, and other efforts to help raise the level of knowledge for SQL Server professionals. I’d like to find ways to help people learn more, write higher quality code, at a faster pace.

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.

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.

September 9, 2014
T-SQL Tuesday #58–Passwords

It’s the second Tuesday of the month, time for T-SQL Tuesday again. This time the invitation to participate comes from Sebastian Meine (@sqlity, blog) with the topic of passwords. It’s a great topic, especially as security concerns are growing regularly.

I would encourage anyone that looks to build their brand, and further their career to write a post for T-SQL Tuesday. It’s easy, just look for the invitation and then publish on the second Tuesday of the month. Be sure to follow the #tsql2sday tag on Twitter.

You can even go back and write about previous topics, and share your own thoughts and insight. I keep a list of previous topics here: T-SQL Tuesday Topics.

SysAdmin Passwords

I’ve tried to maintain strong passwords for years. I used to have a formula, similar to Bruce Schneier, where I’d use a sentence to build a password. However a few years back I went to Password Safe, and have been using that on Windows, OSX, iOS, and Android, with Dropbox keeping my password safes in sync. I let Pasword Safe generate my passwords, 12 characters), with random digits and I use this to stick passwords into systems.

I use a different password for every system, which has been fine for me. It’s slightly annoying to unlock the safes on a mobile device, but I like the idea that a compromised password on one system doesn’t affect any others.

Years ago, I worked as a DBA and we managed a large number of systems. One of our mandates was that administrative passwords would be changed every 30 days. That was fine for the people running the systems, but changing the administrator password for hundreds of Windows hosts was an issue. We grouped servers (IIS servers, Exchange servers, etc), to make it easier for each administrator to manage the systems, but it was still a challenge to create passwords for each group every 30 days.

I introduced Password Safe, and simplified things. We let the application generate passwords for each group, stored them in the safe, and used a script that took the group and password as parameters to change all the systems passwords. This was still time consuming, but it provided for a limited window to crack a password, allowed us to use longer passwords, and we could also retrieve them when we needed to administer a particular system.

Note that this was just for administrator passwords. We had a separate scheme for service accounts, which was to randomly create a long, 15+ character, password that was used to start the service, but was never stored. Similar to many applications, we couldn’t recover the service account passwords. If we needed one, we changed it, and sent a note to the security group whose event log scanners would note the change.

I know that strong passwords don’t necessarily solve our security issues with hackers and social engineering, but I do think this is the lowest bar you can tolerate. If “sa” and blank, or “sa” and “password”, or “system” and “manager” (for the Oracle folks) work on your database, you deserve to be fired. There’s no excuse for not picking a strong password for privileged accounts.

September 9, 2014