Today is Thanksgiving in the US, a holiday that most people get away from work.
A reminder for all of you, no matter where you are. Be thankful for something in your life. We’re only here for a short time and we need to appreciate and find joy where we can.
Enjoy the day and see you tomorrow.
I got my feedback the other day, and was a bit surprised by a comment. I wasn’t having a great day and posted a note on Twitter. Not the best idea, but I did get some validation back that others support me and appreciate (and enjoy) when I speak. That’s always good, so maybe not the worst idea either.
This was the last session on Friday, and I wasn’t sure how many people would be interested in the topic. I was hoping for a few, since I think too many of us do a poor job protecting sensitive data.
The ratings:
Glad to see that last one because although my company (Redgate Software) has products and solutions in this area, I want people to think generally about the problem and challenges. If we’re a good fit, fine but there are other solutions.
A couple interesting comments:
“Good content, its very abstract and everything depends on individual scenario. That said it was a great way to explain baby steps and things to get thinking about”
“Very motivational. I must go fix my systems now.”
That last one is meaningful to me. I inspired someone.
“A lot more about devops than I thought it would be considering only one mention of devops in the session description.”
One that struck me as strange. I don’t think I spent too much time on DevOps, but DevOps is a driver here as management puts pressure to get more done and companies build things quicker, including dev/test environments. The abstract was:
According to Gartner, more than 80% of companies use sensitive data for non-production in development and for more reliable testing. Hackers view non-production environments as a tempting target since they often have less rigorous security controls. In this session you’ll learn about securing your work in a compliant DevOps fashion with strategies for reducing your attack surface area, and why data masking, anonymization, and data minimization are fast becoming best practices for securing sensitive data in test and development environments.
I did spend a bit of time describing DevOps and what this means for people working in dev/test areas. I’m also not sure that the description means there will be little mention of a topic like DevOps, but I will think about this for future abstracts.
I’m also surprised I didn’t get a ding on data masking as I talked relatively little about this.
I’ve done this session in many places, including the Summit in the past. I was surprised this was picked this year, but it was. It was crazy that I tweeted this picture, and ended up with over 100 people.
Ratings:
The comments were mostly good. A few people mentioned they’d seen it before and still came. That’s very exciting as a speaker. This comment really made me smile:
“I chose this session as filler and, thus, it was the session I was least expectant about. Thus far, it’s been the most impactful session I’ve attended. Positively inspiring!”
This one makes me think.
“Your slides could be a little more jazzed up. I think what your saying is awesome and I got some great tips but it was hard to stay engaged with the slide deck.”
I do try to keep things interesting with pictures and used to have more. I got complaints that not enough info was on slides that would help later, so I may have tipped more to the other side. I’ll have to review this for next year.
This is another one I’ve done at the Summit. I actually did it last year to a huge crowd (250+), and wasn’t sure how well this would be attended this year. I was up against some other great speakers and sessions, so I was happy to have 100+ people.
Ratings:
That last one is interesting. I try not to talk products specifically, even though I use a few Redgate tools, I don’t think I try to sell them. I usually refer people to the booth or sales, but I got this one:
“I know they probably want the sessions to be free from non-Microsoft product endorsements, but would have loved to see you be able to go deeper with the redgate products. I did get a lot out of the session as it was, and got some ideas to improve our processes in our shop. Thanks!”
Contrasted with this one:
“I know you were trying to be vendor agnostic in the talk but I think because of this it didn’t go as deep as you could of”
This is a tough topic. I’ve spent a few years trying to refine the message to one that’s understandable, and exciting, but not too deep. This isn’t designed to teach you how to do DevOps. I can’t do that in an hour. However, I did get a suggestion:
“This was great. Maybe stretch it to pre-con?”
And this one made me smile:
“I love you and hate you. Great advice but now I despair at my ineptitude ”
However, this was the Twitter one that caught me off guard.
“Good session. To me speaker came across as somewhat arrogant which to me reduced the value of the session. I would not come to another session by this presenter. He seems knowledgeable but not a good presenter ”
I know I can’t please everyone and not everyone will like my style or my talks, but I haven’t ever been told I’m too arrogant. Or that my style turns someone off that much, even though I’m knowledgable.
Not sure I’ll change anything, but I’ll keep an eye on whether I might be doing something that offends people.
I was only in Seattle for 31 hours, and it was a whirlwhind. I had a half day Thursday, giving a session and chatting with friends. Then a busy Friday, with a few meetings, two talks, and lots of shaking hands.
I think I did a good job of presenting sessions this year, with good ratings. Not a lot of things to change, but as I’ll deliver new sessions next year, I need to be sure to continue to build and practice high quality sessions. A few comments will make me think and re-examine parts of what I do.
Like other aspects of my job, and DevOps, continuous improvement along with some experimentation is important.
This is likely a short and quiet day for many of you with Thanksgiving in the US tomorrow. Most people have tomorrow off in the US, and those that do business with the US may have a quiet couple of days with little communication from the US. A good time to catch up on things.
Before you go, I want you to think a bit about security today, and perhaps across the weekend before you come back. Security is important, and many of us that work in the data world know this. We see more and more data breaches occurring every week, with the rate of incidents at this point being a little over 4 per day. These are losses of data from all sizes and kinds of companies from household names to local law firms and retails organizations.
Most of us work for some company that has data, and we know a portion of this deserves protection to ensure we don’t need to pay for identity insurance or get fined by the government. There’s another reason to care about security: branding. There’s a survey that just came out, which notes that consumers are likely to stop using a brand if there’s a data breach. There’s a report on the survey as well, if you don’t want to give up more data to get the data.
Consumers note that many would stop working with a brand if there were a data breach, but that might not mean not using that service, just not using their online services. This makes some sense in some industries, but not others. I also know that consumers can be emotional and look to leave a service, like a mobile phone provider, after a breach, to move to a new provider. In many cases, this may create churn as most providers have had some breach, and it’s entirely possible whoever is last is the one losing customers this quarter.
What I did find interesting is that more consumers are being careful what information they share, preferring to use official portals rather than email, even avoiding clicking on links. To me, this is only a matter of time before customers stop providing most voluntary information, or the start to make up data values. That might be a problem for those of us that look to analyze data for our employers. If quality falls, perhaps we’re less valuable.
We need to do a better job of securing system, patching them against vulnerabilities, writing better software, and preventing exposure of data. We’ve gotten better in recent years, but we need to do more work, including avoiding keeping extra copies of sensitive data in development and test environments. It requires work to mask or remove this data, but it’s better than the risk of accidental exposure and brand damage.
Steve Jones
Listen to the MP3 Audio ( 4.5MB) podcast or subscribe to the feed at iTunes and Libsyn.
I ran into an interesting problem while working with the POWER() function. I was trying to do some binary conversions and had a statement like this to process powers of 2.
SELECT POWER(2, n)
This was designed to take a value and return a power of 2. I then used a different value to determine if this was added to my conversion factor or not. In trying to work with some larger numbers, I ran into this error:
Msg 232, Level 16, State 3, Line 3
Arithmetic overflow error for type int, value = 2147483648.000000.
The error tells me I’ve exceeded the size of an integer. When I looked up the POWER() function, it tells me that it returns a bigint for a bigint input. Since I had ensured my “n” was a bigint, I was confused for a few minutes.
Then I realized that it’s not the n, but the “2” that’s the problem. By default, this scalar value is an integer. That means I need to ensure that this is a bigint to make this work. I changed to:
SELECT POWER(CAST(2 AS BIGINT),n)
And things worked.
Double check all the data types when you get a conversion error. SQL Server knows what’s wrong, but sometimes you need to dig in to determine where in your code you’ve made the mistake.
