I’m Presenting at GCSQL’s May Meeting

Part of the Gulf Coast By Pimvantend (Own work) [Public domain], via Wikimedia Commons

Part of the Gulf Coast

I wanted to share a quick Friday update to mention that I’ll be presenting Build your Own Virtual Lab at the Gulf Coast SQL Server User Group on May 23, 2013. As much as I’d love to visit in person, I’ll be joining my peers over webinar that evening. I think that we may end up using Google Hangouts, and if we do, I may be able to record the session directly to my YouTube channel. So I’ll be sure to keep everyone updated on the status of that as we parse it out in the coming week.

I’ll see you wonderful Gulf Coast folk next Thursday!


T-SQL Tuesday 42: Priorities, Goals, and Dead Ends

Logo for T-SQL Tuesday

T-SQL Tuesday

It’s time for T-SQL Tuesday the forty-second, and Wendy Pastrick has asked that we talk about our experiences with change in our working lives, specifically as it relates to technologies we’re using. I’d like to share a bit of my own history and relate it to managing change.

Career Milhouse

Post graduation (and even pre-graduation), I was landing typical gigs as a temporary employee: admin jobs, stuffing envelopes, and data entry. Jobs that paid bills and allowed me to eat. While it provided me with a good amount of experience, the jobs were unfulfilling. To make the issue worse, I lied to myself about the situation: "As long as I have personal time for my own projects," I’d say, "then I’ll be happy with whatever pays the bills."

I was attempting to cover up the fact that I was holding a series of dead end jobs. Positions that were unchallenging, and didn’t have any means of growth or promotion. As a consequence, my work life tended to be lifeless.

Everything's coming up Milhouse meme

I knew I had wanted to work in technology for years at that point, but didn’t know how to manage or act upon it. And it didn’t help that most "entry level" tech jobs required "two or more years of experience." In that place in my life, I had a mismatch between my goals and my ability to meet them, which isn’t to say that I’m special in this regards. I think many twenty-somethings have the same experience as they stumble about post-graduation and figure out how the world works and their place within it.

Simply, I was in a dead end, had a goal in mind, but no way to prioritize it to move forward.

Drowning in Technology

After the happy accident that turned me into a DBA and technologist, I still ran into challenges. Burnout on the job, learning to manage "poser" feelings in relation to the greater community, and balancing both a career and family became the new obstacles that shifted my priorities. But that’s common: everyone deals with that.

Technology itself often becomes a burden for me. I have a love of learning, and a love to figure out how technology works, but these traits aren’t solely positive. There are repercussions to being a "jack of all trades." The main problem is that you’ll spend time away from your primary focus, which in turn will delay your professional growth. And with the exception of DevOps, technical generalists aren’t ever in demand.

Road ends in water 5.8 miles

On a side project, it had been decided that we would build an app using Python on top of Django. "Perfect!" I thought. "This will be a great chance to build some basic programming skills and learn more about MVC!" And it was. But in the scope of a data professionals career, how helpful are those base level skills? While I spent only a few months on that particular project, I’ve not used Python or MVC since. What SQL Server learning opportunities did I miss in the meanwhile?

On a more hostile note, when I was a contracting I had the misfortune to troubleshoot deep issues with SharePoint. I was the only person on staff capable of the work; project managers were spinning and playing the blame game. While we all failed from a customer service perspective, I was still successful in closing out the issue. But since the work was so specialized, the knowledge I gained from it wasn’t useful towards my larger goal of becoming a more competent data professional.

As in all things, there is a need for balance. On one hand, we need to maintain a base-level knowledge of new and upcoming technologies to remain competitive in our careers. But always chasing the shiny new hotness can lead to dead ends slowing down your growth instead.

Finding the Right Mix

In all honesty, it wasn’t until the end of 2012 that I figured out how I wanted to focus my career, and started to lay out concrete goals for myself. And even before I started laying those goals, I had to come to a difficult decision about where my true technological passions lied. And in the end, it was with data. It had always been data. (I apologize for this having turned into a sappy love note.)

While I cannot deny my love for learning, I’m maintaining a greater focus on technologies that are closer to my chosen profession, and with an eye toward the future. That’s why I chose to take my current job with Sanametrix, because I could pair my career in data atop of AWS‘s cloud platform. While I didn’t work directly with Obama’s AWS team, I saw the results of their work, and it changed how I thought about availability and serving end users. It is the future, and the future is here. Returning to my theme of balance, it’s not that the cloud will ever fully replace the enterprise (at least foreseeably), but that they’ll be used in conjunction to meet business needs.

It’s in this latest job that I’m finding an alignment of my priorities and my goals. And thanks to the continued growth of data and the cloud, I’m staying well away of dead ends.


I’m Presenting at the Professional Development Virtual Chapter

I’ll have the pleasure of presenting to the Professional Development Virtual Chapter next Wednesday, May 9th, at 1pm (EST). I’ll be presenting Communicate for Great Good, which I’ve detailed here:

Communicate for Great Good!

“No one knows what I do.” That’s a chief complaint of data professionals everywhere, and it’s a dangerous position to be in as well. Reviews may not be favorable, promotions more uncommon, and training dollars more rare. But by practicing written and verbal communication, you may be prepared to take advantage of new opportunities that present themselves. This presentation is for data professionals looking for fun activities to grow their written and verbal communication skills.

I’d love to have you attend. Typically the session is laid back and interactive, and I’ll do my best to keep it that way over the webinar. And if you haven’t already, do hit the link for the Professional Development chapter as they offer great content every month, and it’s one of the easiest venues to find new ways to further your professional growth.

See you next Wednesday!


Quick Tip for Using AWSPowerShell API Credentials

With all the fun PASSDC stuff going on, it’s been a while since I’ve blogged on a technical topic. But today I’d like to share a small story and solution as relating to PowerShell and Amazon Web Services (AWS).

The Setup

My struggle came about as I was setting up an off-site backup location on AWS’ Simple Storage Service (S3). This is something I’ve blogged about in a past T-SQL Tuesday, and I’ll be talking about in an upcoming presentation. The trouble was that my PowerShell script would no longer move the .bak files to S3. The even more troubling part was that I hadn’t made any changes to the server.

If you haven’t had the chance to work with PowerShell in the past, I can only describe the troubleshooting process as obtuse. Perhaps with a great deal more skill it becomes simple, but as a novice I wasn’t sure where to begin, especially because my SQL Agent jobs were returning successfully. My technique involved printing my variables and parameters to file until I narrowed it down. Thankfully this worked, and I figured out that, while I had stored my AWS credentials properly, they couldn’t be accessed by the SQL Agent job.

The Details

According to the engineers at Amazon, the API credentials are stored on a per-user basis. This means that while I could RPD into the server and do my normal setup, those credentials would then be tied to my login. This is sensical, but makes setting up administration a bit more tedious as you have to set up the same credentials for any other user accounts that may need them. In my case, I needed to perform additional setup for my SQL Server Agent account, since I’d be calling my PowerShell script through the Agent.

The interesting part is that Amazon enforces this per-user basis in how they store the credentials. Within each user’s appdata\Local folder, there is a .json file that has the credentials. But the credentials are (appear to be) salted and hashed to tie them to each user uniquely. So while copy-pasting the .json file from one user to another allows the new user to see the credentials through a call to Get-AWSCredentials -ListStoredCredentials, they won’t be able to use said credentials.

The Fix

So how do you fix this so the SQL Agent can store the appropriate credentials? Well, I just wrote a new job to store the credentials, similar to what I did in my original post, and then I deleted the script and the job afterwards for security’s sake. Really, you wouldn’t want to leave the API credentials in a script or even a PowerShell $profile. And you can bet that I’m going to be looking for a nice “PowerShell” way to script the credential setup on new machines. I’ll share once I crack that nucket.