SQL Saturday DC 2017 Prologue

I’ll apologize upfront, not every blog post is mind-shattering and deep. This is one such lightweight one.

Once again I’ll be heading to a SQL Saturday, this time in Washington DC. I actually had two to choose from, one in Providence Rhode Island and this one. Mostly because I have friends in DC from the days I worked there, I choose to submit some sessions to present in DC.

Submitting presentations is always a bit nerve-wracking for me. You feel confident you’ve got a good session and you hope it is what what the organizers want. I’m not really sure how many SQL Saturdays I submitted sessions to before I was finally selected for my first one in NYC. My topic then (and still one I still present from time to time) was “Tips that Saved my Bacon.” I even made bacon cookies to hand out. (Never again, they didn’t come out great.) I knew I was off to a good start when I saw Micron Technologies handing out t-shirts with a bacon motif and even a scent of bacon. Must be kismet.

I get to my room, I get setup, I’m all set. I’m a bit excited and waited for the people to pour in and fill the room. Ok, then I waited for anyone to walk into the room. Finally some people showed up. Great, first hurdle cleared, I had an audience. Not as large as I had hoped with which to share my amazing wisdom, but an adequate one nonetheless.

Before I started, a question, from a woman I believe who was Muslim, “what is bacon?” Of course, with pork being harām to most observant Muslims, she may have never even encountered it. But I realized too, I had a bigger issue. She didn’t understand the idiom!  I was really off to a great start now.  I did the best to explain both what it was and the idiom.  She seemed satisfied. And then we were off.

Fortunately I sort of had a plant in the audience; a friend of mine who was attending who had wanted to hear my talk.  He claims he got a lot out of it.  I hope so.

Since then I’ve given that talk several times and fortunately had better turnouts and better results.

After that I’ve had pretty good luck in getting selected to speak, but sometimes you still get the rejection. I had previously put in to speak at DC at least twice before and turned down both time. You take it in stride and try to not take it personally.

So, again, this year I put in to speak at DC. I submitted three different possible presentations, hoping at least one would be accepted.

The final date for submissions came and went. And nothing. Then I saw they had reopened the period for submissions. This didn’t instill hope in me getting selected.

And still nothing. Oh well, I decided I’d go to SQL Saturday DC anyway, just to attend and to see my friends in DC.

Then I was at the RedGate After Party at Pass Summit and Chris Hyde walked up to me and said, “Congratulations. I really wanted to see your talk in DC, but apparently we’re presenting at the same time.” So, I had to go through my emails and find the one from DC. (That day I had a system that was giving me some warning messages, so I had to sort through about 100 messages to find the one from SQL Saturday DC, hence why I had originally missed it.)

But, as Chris didn’t say WHICH of my presentations he was going to miss, I pulled out my phone, logged into the site. And lo and behold, I discovered I wasn’t presenting just once, but TWICE! I was completely shocked. And… now in a wee bit of trouble.

You see my talk on Who’s flying the plane? What IT can learn from plane crashes, is one of my favorites and one I’ve given multiple times before (and the one apparently Chris will miss). But, my 2nd talk Presently Presenting…. Presenting was one that had hadn’t quite fully written. Ok, I had the outline in my head, but hadn’t written it at all! I generally do NOT recommend this style of doing things. I really like to present at a smaller group first (say my local user group) but I figured this was a good way to give me a kick in the pants and get the talk written. And I was right. The presentation is written, I’ve run through it a few times (and will run through it a few times more before Saturday) and I’m quite happy with it at this point.

So, this coming Saturday, I’ll be giving not just one, but two talks at SQL Saturday in DC. If you’re reading this and already signed up, I’d love to see you there. If we know each other, of course say hi. If we don’t, introduce yourself. I always enjoy meeting new folks.

And if you haven’t signed up, there is unfortunately a wait-list, but you can still add your name to it and if folks cancel, get in.

So, I hope to see you there!

P.S. I’ll give one piece of advice that’ll be in my talk on presenting. If you DO get turned down, don’t take it personally. Take it with grace. SQL Saturday organizers face a lot of challenges in picking presenters and are often overwhelmed with the number of submissions. Trying to argue with them or worse calling them names or getting upset with them is a sure fire way to guarantee you do NOT get selected in the future. And, organizers talk to each other. You do NOT want to get tagged with being “that person”. If you get turned down, don’t take it personally and move on.

Too Secure 2

A quick followup to my blog post from the other day.

So, today I tried to update a service at the client. But of course, with IE locked down and cookies not allowed, I can’t update the service. Hmm. Tell me how that’s more secure?

And my wife just came back from work last night, talking about how she’s no longer able to get to a website critical for her job; because the firewall rules changed.  All this in the name of security.

Yes, we can be too secure!

Too Secure

There’s an old joke in IT that the Security Office’s job isn’t done until you can’t do yours.

There’s unfortunately at times some truth to that.  And it can be a bigger problem than you might initially think.

A recent example comes to mind. I have one client that has setup fairly strict security precautions. I’m generally in favor of most of them, even if at times they’re inconvenient. But recently, they made some changes that were, frustrating to say the least and potentially problematic.  Let me explain.

Basically, at times I have to transfer a file created on a secured VM I control to one of their servers (that in theory is a sandbox in their environment that I can play in). Now, I obviously can’t just cut and paste it. Or perhaps that’s not so obvious, but yeah, for various reasons, through their VDI, they have C&P disabled. I’m ok with that. It does lessen the chance of someone accidentally cutting and pasting the wrong file to the wrong machine.

So what I previously did was something that seemed strange, but worked. I’d email the file to myself and then open a browser session on the said machine and get the file there. Not ideal and I’ll admit there are security implications, but it does cause the file to get virus scanned at at least two places and I’m very unlikely to send myself a dangerous file.

Now, for my webclient on this machine, I tended to use Firefox. It was kept up to date and as far as I know, up until recently, on their approved list of programs.  Great. This worked for well over a year.

Then, one day last week, I go to the server in question and there’s no Firefox. I realized this was related to an email I had seen earlier in the week about their security team removing Firefox from a different server, “for security reasons”. Now arguably that server didn’t need Firefox, but still, my server was technically MY sandbox. So, I was stuck with IE. Yes, their security team thinks IE is more secure than Firefox.  Ok, no problem I’ll use IE.

I go ahead, enter my userid and supersecret password. Nothing happens. Try a few times since maybe I got the password wrong. Nope. Nothing.  So I tried something different to confirm my theory and get the dreaded, “Your browser does not support cookies” error. Aha, now I’m on to something.

I jump into the settings and try several different things to enable cookies completely. I figure I can return things to the way they want after I get my file. No joy. Despite enabling every applicable options, it wouldn’t override the domain settings and cookies remained disabled.  ARGH.

So, next I figured I’d re-download FF and use that. It’s my box after all (in theory).

I get the install downloaded, click on it and it starts to install. Great! What was supposed to be a 5 minute problem of getting the file I needed to the server is about done. It’s only taken me an hour or two, but I can smell success.

Well, turns out what I was smelling was more frustration. Half-way through the install it locks up. I kill the process and go back to the file I downloaded and try again. BUT, the file isn’t there. I realize after some digging that their security software is automatically deleting certain downloads, such as the Firefox install.

So I’m back to dead in the water.

I know, I’ll try to use Dropbox or OneDrive. But… both require cookies to get setup.  So much for that.

I’ve now spend close to 3 hours trying to get this file to their server.  I was at a loss as to how to solve this. So I did what I often do in situations like this. I jumped in the shower to think.

Now, I finally DID manage to find a way, but I’m actually not going to mention it here. The how isn’t important (though keeping the details private are probably at least a bit important.)

Anyway, here’s the thing. I agree with trying to make servers secure. We in IT have too many data breaches as it is. BUT, there is definitely a problem with making things TOO secure. Actually two problems. The first is the old joke about how a computer encased in cement at the bottom of the ocean is extremely secure. But also unusable.  So, their security measures almost got us to the state of making an extremely secure  but useless computer.

But the other problem is more subtle. If you make things too secure, your users are going to do what they can to bypass your security in order to get their job done. They’re not trying to be malicious, but they may end up making things MORE risky by enabling services that shouldn’t be installed or by installing software you didn’t authorize, thus leaving you in an unknown security state (for the record, I didn’t do either of the above.)

Also, I find it frustrating when steps like the above are taken, but some of the servers in their environment don’t have the latest service packs or security fixes. So, they’re fixing surface issues, but ignoring deeper problems. While I was “nice” in what I did; i.e. I technically didn’t violate any of their security measures in the end, I did work to bypass them. A true hacker most likely isn’t going to be nice. They’re going to go for the gold and go through one of at least a dozen unpatched security holes to gain control of the system in question. So as much as I can live with their security precautions of locking down certain software, I’d also like to see them actually patch the machines.

So, security is important, but let’s not make it so tight people go to extremes to by pass it.

 

She’s smart and good looking.

Now, if you work from home like I do, this exercise won’t really work, but if you work in an office, look around at your coworkers and start to notice what gender they present as. Most likely you’ll notice a lot of men and a few women.

Sexism is alive and well in the tech world. Unfortunately.

We hear a lot about efforts (which I support by the way) like Girls and Data and Girls Who Code. These are great attempts at addressing some of the gender issues in the industry.  We’ve probably all heard about the “Google Manifesto” (and no, I’m not linking to it, since most of the “science” in it is complete crap and I don’t want to give it any more viewership than it has had. But here’s a link to the problems with it.)

We know that grammar school and middle girls have a strong interest in the STEM field. And yet, by the time college graduation rolls around, we have a disproportionately smaller number of them in the computer sciences for example.  So the above attempts to keep them interested help, but honestly only address part of the problem.

The other side is us men.  Yes, us.  We can tell our daughters all day long, “you’re smart, you can program”.  “You too can be a DBA!” and more. But what do we tell our sons?  We need to tell the that women can program. We should be telling them about Ada Lovelace and Admiral Grace Hopper. We should be making sure they realize that boys aren’t inherently better at STEM then girls.  We should be making sure they recognize their own language and actions have an impact.

What do we do ourselves when it comes to the office environment? Do we talk too much? Evidence suggests we do.

Do we subconsciously ignore the suggestions of our female coworkers or perhaps subconsciously give more support or credence to the suggestions of our male coworkers?  While I can’t find a cite right now, again evidence again suggests we do.

Who is represented at meetings?  Are they a good ol’ boys network?  Who do we lunch with, both at work and when we network?

If you’re a member of a user group that has speakers, what does the ratio of speakers look like to you? Do they reflect groups ratio? Do they reflect the ratio of the industry?

I think it’s great that we have programs such as Girls who Code and Girls and Data, but we as men have to work on ourselves and work on our actions and reactions.

Some suggestions: “Sometimes, simply shut up.” I’ve started to do this more, especially if I’m in a group of women. LISTEN. And you know what, if you’re thinking right now, “well duh… because women talk so much I’d never get a word in anyway” you’re falling victim to the cliches and perpetuating the problem.

Support the women you work with. If they have a good idea, make sure it gets the same discussion as other ideas. And if one of your coworkers tries to co-opt it as their own, call them on it.  If you have a coworker (and I’ve had these) that is continually cutting off women in meetings, call them on it.

Seek out women speakers for your user groups. I’d suggest for example Rie Irish and her talk “Let her Finish”.  I asked Rie to speak at our local user group. Partly because of serendipity (I contacted one of our women members to let her know about the talk) we got the local Women in Technology group to advertise our meeting and ended up with a number of new members.

And finally, the title. Watch your language. Unless you’re working at a modelling agency or similar, you probably should never be introducing a coworker as “She’s smart and good looking.”  Think about it, would you ever introduce a male coworker as “He’s a great DBA and handsome too boot!”  Your coworkers, male or female are just that, coworkers in a professional setting, treat them as such.

Two final thoughts:

  1. If somehow this blog post has impacted you more than the brilliant posts of Rie Irish, Mindy Curnutt, or others who have spoken on sexism in the industry, I’d suggest you examine your biases, not give credit to my writing.
  2. If you have suggestions for women speakers for my local user group, especially local ones who can make the second Monday of the month, please let me know.

 

 

 

 

Comfort Zone

Humans are by nature, a creature of habit and familiarity. We’ll often go to the same restaurant time after time, not necessarily because it’s the best, but because we’re most familiar with it. One reason why McDonald’s is so popular is NOT because they serve the best hamburgers, but because you’re pretty comfortable, no matter where you go, knowing that you’ll get exactly the same hamburger every time.

However, if you never have anything other than McDonald’s you can miss out on some wonderful food.

I often try to get out of my comfort zone. Sometimes we have to do so to grow. Of course everyone’s comfort zone is different. I love to crawl through holes in the ground (and please, keep it simple, we call it caving, not spelunking.) To me, that’s a comfortable environment.

But recently I’ve been doing something outside of my comfort zone; I’ve been taking a sales training class. The truth is, being a consultant, as much as I love the tech side, I really need to sell myself. Sales IS part of what I need to do. And I’m not comfortable doing it.

But, to expand I have to learn how. And I have to admit, I’ve learned a lot. It’s been worth it.

Another thing I’m doing to step a wee bit out of my comfort zone is to schedule a weekly blog post. Rather than do it hit or miss, I’m going to try to make it more formal.

So, what have you done to step out of your comfort zone lately?  How has it worked for you?

Oh and if you’re ever in upstate New York and want to go caving, let me know.

Riffing on a theme

As I’ve mentioned in the past, I often write these as inspiration strikes and today it did.

Specifically I’m inspired by Grant Fritchey’s latest blog post THERE IS A MAGIC BUTTON, A RANT.

First, I couldn’t resist doing this simply because I could put a pun in the title. (Read his entire article to see what I mean.)

But more so, because it’s part of a theme I’ve heard for decades. “This new technology will put people out of jobs!”

The truth is, sometimes it’s true.  I mean, how many buggy-whip manufacturers do you see these days? How many do you think existed before Ford started rolling the Model T off of the assembly line? How many after?

Yes, the Model T put many buggy-whip makers out of jobs. BUT, it created far more jobs than it eliminated.

Automated elevators put out elevator operators out of a job. But you know what, for the most part, that’s a good thing. Let’s use our human capital in a better, wiser way.

For decades I’ve heard that one technology or another will make SQL useless or pointless.  At one point it was object oriented databases. Now it’s NoSQL. But you know what, SQL is not only still here, it’s thriving and now often when folks use the term NoSQL instead of meaning NO SQL, they’re using it as a short-hand for Not ONLY SQL.

So, performance tuning automation? Great. I love it. Bring it on. It WILL in fact mean less work I have to do on that front in many cases. But you know what, it won’t fix the situation I’m in right now where a customer has a server they use for “database conversions”. The problems include databases still in FULL Recovery mode, but no log backups, DBCCs not being done in weeks or months on some of these and the tempDB log filling up the drive on Saturday while I was sitting in a talk at the Albany SQL Saturday.

Yes, at some point most of those issues will probably be handled automatically, but until they do, I’ll be busy. And when they DO automate those, I’ll have moved on to new issues.

There’s always a place for trained people.

Since I like to link my topics to other ideas like plane crashes, I’ll point out that autopilots on modern commercial airliners are amazing things. They really can pretty much handle any part of normal flight operations including take-offs and landings. But, what they can’t handle is the unexpected. And this is actually an issue in two ways. First of course, is the fact that it took human ingenuity to safely land the Miracle on the Hudson.  There’s no autopilot out there that could make that decision and pull it off.

The second, and this is actually a bigger issue automated cars are facing is that with the use of an autopilot/self-driving car, 99.99% of the time, operations become SO mundane the pilot or “driver” ends up out of the loop. They end up reading, falling asleep or simply not paying attention. This means that when they ARE required to interact, there can be a several second delay before they’re fulling aware of the situation and can react. In a plane this may or may not be an issue depending on the altitude the situation occurs at.

In a self-driving car, we’re already seeing situations were the “driver” can’t get back into the control loop fast enough and an accident occurs.

So, while automation can eliminate a lot of the drudgery and “take away jobs” we still need humans in the loop and there is no foreseeable end to the jobs we’ll be needed to do.

So don’t despair about automation.

 

Mistakes were made

I generally avoid Reddit, I figure I have enough things in my life sucking my time. But from time to time one link comes across my screen that I find interesting. This is one of them.

The user accidentally deleted a production database. Now, I think we can all agree that deleting a database in production is a “bad thing”. But, whose fault is this really?

Yes, one could argue the employee should have been more careful, but, let’s backup.

The respondents in the thread raise several good points.

  • Why were the values in the documentation ones that pointed to a LIVE, production database? Why not point to a dev copy or even better yet, one that doesn’t really exist. They expect the person to update/change the parameters anyway, so worst case if they put in the fake ones in is, nothing happens.
  • Why didn’t Production have backups? This is a completely separate question, but a very important one!
  • Why fire him? As many pointed out, he had just learned a VERY valuable lesson, and taught the company a very valuable lesson too!

I’ll admit, I’d something similar in my career at one of my employers. Except I wasn’t an intern, I was the Director of IT, and my goal in fact WAS to do something on the live database. The mistake I made was a minor one in execution (reversed the direction of an arrow on the GUI before hitting the Execute button) but disastrous in terms of impact. And of course there wasn’t a recent enough backup.

I wasn’t fired for that.  I did develop and enforce our change control documents after that and always ensured, as much as possible that we had adequate backups. (Later in a my career, a larger, bigger muckup did get me… “given the opportunities to apply my skills elsewhere”, but there were other factors involved and I arguably wasn’t fired JUST for the initial issue.)

As the Director of IT, I made a point of telling my employees that story. And I explained to them, that I expected them to make mistakes. If they didn’t they probably weren’t trying hard enough. But I told them the two things that I wouldn’t accept would be lying about a mistake (trying to cover it up, or blame others, etc) and repeatedly making the same mistake.

I wrote in an earlier post that mistakes were avoidable. But as I pointed out, it’s actually more complex than that. Some mistakes are avoidable. Or, at least they can be managed. For example, it is unfortunately likely that at some point, someone, somewhere, will munge production data.  Perhaps they won’t delete it all, or perhaps they’ll do a make a White Ford Taurus type mistake, but it will happen.  So you have safeguards in place. First, limit the number of people in a position to make such a mistake. Second, have adequate backups. There’s probably other steps you can do to reduce the chance of error and mitigate it when it does eventually happen. Work on those.

But don’t fire the person who just learned a valuable lesson. They’re the one that is least likely to make that mistake again.  Me, I’d probably fire the CTO for not having backups and for having production values in documentation like that AND for firing the new guy.