Monthly CASSUG meeting — April 2019

Greetings, data enthusiasts!

This is a reminder that our April CASSUG meeting will take place on Monday, April 8, 5:30 pm, in the Datto (formerly Autotask) cafeteria!

Our guest speaker is Monica Rathbun!  Her talk is entitled: Performance Tuning, Getting the Biggest Bang for Your Buck!

Note that our meeting location has moved!  Datto/Autotask is now located at 33 Tech Valley Drive.  Please do not map this address at this time, as most online maps have not yet been updated. Drive past the old building all the way to the end, where the new building is located! Refer to the map below for the new location.

For more information, and to RSVP, go to our Meetup link at http://meetu.ps/e/FWkVd/7fcp0/f

Thanks to our sponsor, Datto/Autotask, for making this event possible!

Advertisements

SQL Saturday Boston BI — this Saturday, March 30

This coming Saturday, March 30, I will be speaking at SQL Saturday #813, Buston (BI Edition)! This is my first SQL Saturday for 2019, and it will be the third time since last September that I will be speaking in the Microsoft facility in Burlington, MA!

I will be doing my presentation on how to talk to non-techies, called “Whacha just say? Talking technology to non-technical people.”

SQL Saturday is always a great time! It’s a great opportunity for free training, and it’s also a great networking event — you have an opportunity to meet a number of SQL Server and other data industry experts, as well as a chance to meet other peers within your profession!

Hope to see you in Burlington this Saturday!

Developing an introductory presentation to SQL Server

So far, all of my SQL Saturday presentations have been professional development talks — “soft topics,” as they’re often described. I don’t present about technical topics, but I do present topics that are of interest to technology (and perhaps other) professionals.

This is not to say that I don’t have technical skills. I do have a background in development and databases, but as I often introduce myself during my SQL Saturday presentations, I probably fall under the category of “knows enough SQL to be dangerous.” I am neither a SQL expert nor an MVP. While I am knowledgeable about SQL Server, I likely won’t be doing any presentations about power BI, data compression, or data security anytime soon.

I can, however, discuss rudimentary topics about SQL Server that might be of interest to people who are just getting started with SQL Server. When I first started my ‘blog, I wrote some articles about how to get started with SQL Server. As my ‘blog (and my professional life) has evolved, I’ve been moving more toward the soft topics about which I’m more knowledgeable and tend to present, and away from the hardcore technological topics.

An idea that has been in the back of my mind for some time is to develop presentations geared toward people who are just getting started with SQL Server and even databases in general. This idea is not new; I’ve toyed with it for a while, and only lack of time has kept me from developing it further.

One observation I’ve made during my frequent trips to SQL Saturday events is that many of the presentations are geared more toward “seasoned” SQL personnel; that is, people who already have some background knowledge of SQL Server and its workings. They are all very good topics, but for a person who is just getting started, they can be overwhelming — as is often described, a proverbial “drink from a firehose.”

There does seem to be a market for this idea. I’ve spoken to Grant Fritchey a few times about my idea, and he has encouraged me to pursue it. One thing that was mentioned to me was that part of the reason why many SQL Saturday presentations tend to be more advanced is that the presenters themselves are fairly advanced. A lot of them are SQL experts and MVPs, and are presenting topics at a much higher level from where a SQL beginner would need to start. It would be akin to asking a college professor to teach kindergarten.

Grant even suggested that I make these presentations into an entire precon — as there is way too much material to cover in a single SQL Saturday presentation. This is an idea that intrigues me, and it’s something that I’m interested in developing. It’s just a matter of me taking the time to sit down and putting it together.

I have a few reasons for writing this article. Among them are a form of self-encouragement to pursue this endeavor and a forum to list some of my thoughts. On the latter, I wanted to list a few topic ideas listed so that I can refer to and develop it as I go along.

Some of the topics I would cover would likely include the following.

  • A general high-level introduction to SQL Server and databases in general
  • Basics of T-SQL
  • An introduction to relational tables
  • Basics of data normalization
  • An introduction to database applications

I’m sure there are some other topics that haven’t occurred to me. If you have any suggestions, feel free to list them below in the comments.

This is an idea that has been kicking around my head for at least a few years. Maybe sometime, I’ll actually sit down and start working on it. Hopefully, that sometime will be soon.

Monthly CASSUG meeting — March 2019

Greetings, data enthusiasts!

This is a reminder that our March CASSUG meeting will take place on Monday, March 11, 5:30 pm, in the Datto (formerly Autotask) cafeteria!

Our guest speaker is George Walters! His talk is about security features from SQL 2005 through 2017!

For more information, and to RSVP, go to our Meetup link at http://meetu.ps/e/FWkSv/7fcp0/f

Thanks to our sponsors, Capital Tech Search, CommerceHub, and Datto/Autotask, for making this event possible!

SQL Saturday #855 Albany announced!

The Capital Area SQL Server User Group (CASSUG) is pleased to announce that, for the sixth time, we will host SQL Saturday #855, Albany on July 20!

For additional information, to register for the event, or to submit a presentation, click the link above!

I’ve already submitted presentations, but I will be there, regardless of whether or not I’m picked to speak!

Hope to see you there!

Monthly CASSUG meeting — January 2019

Starting with this ‘blog post, I’m beginning a new habit. Since I’m responsible for communications for my SQL user group (CASSUG — “Capital Area SQL Server User Group”), I will start announcing monthly meetings here in my ‘blog. This is my first such entry for this year.

Our next meeting — our first of the new year — is on Monday, January 14. Andy Mallon will give his presentation titled “Demystifying Data Compression.”

For more information and to RSVP, go to our Meetup link!

Hope to see you there!

It was the best of times, it was the worst of times

Steve Jones recently asked: what were your best days at work, and what was your worst?  He also issued a challenge to write about our typical days at work.  In terms of writing about a typical workday, I have the first of four (per Steve’s challenge instructions) draft articles warming up in the bullpen; hopefully, I’ll crank that one out sometime within the next week or so.  But in the meantime, for this article, I want to take a moment to address the best and worst days.

In terms of the worst day, I don’t think there is any contest.  I think it’s pretty safe to say that 9/11 was my worst day at work.  (For the benefit of those of you who don’t feel like clicking my article link, I worked for a company that had an office in the World Trade Center — when 9/11 happened.)

In terms of the best days, however, that requires a little more thought.  It’s not that I haven’t had any great days — that isn’t true — it’s just that there are a number of them, and having been a working professional for (cough! cough!!!) years, trying to pick out a few that stand out over the years is difficult for me to do.  So what I’ll do is pick out a few project victories that I’ve had over the course of my career.  Granted, I’m picking these from the top of my head, and there very well might be others that were more significant that I’m not remembering right now, but for purposes of this exercise, I’ll write about some projects with which I was involved and take a measure of pride.

I’ll start with a project related to the worst day that I mentioned above.  One of my tasks was to maintain an inventory of the servers in our data centers.  For a long time, this was a tediously manual task.  I went through our data centers with a clipboard, checking to see what servers were in each rack, noting any changes and adding new servers and racks that I found.  I drew a map of each room in Visio, even going as far as to count the floor tiles so that I could draw them to scale.  I populated the maps with boxes representing server racks and came up with a naming scheme directly tied into a row-and-column location scheme, making it possible to identify and label each rack so they’d be easy to find.  Included with the maps was a listing of servers within each rack.  I maintained the Visio file on my PC, making sure it was backed up to a departmental file server, and keeping hardcopies in each server room as a reference for various IT workers.

Because this was a manual process, the maps were never completely accurate — I have no doubt that new servers were continually added in-between map updates — and it was a tedious process.  All the while, I kept thinking, “there has to be a better way to do this.”  Sure enough, I found one!

I discovered that all our servers included a product called Insight Manager.  Among other things, it included the ability to collect server BIOS information and store it in a format suitable for importing into a database such as SQL Server.  Using the Insight Manager data structure as a template, I set up a SQL Server database on one of our departmental servers and created a system that enabled it to import data from any server on demand through Insight Manager.  I now had a central database with server data that could be updated at any given time!

Of course, data isn’t information unless it can be interpreted and understood, so the next step was to create an interface for it.  I was responsible for maintaining a departmental intranet site; although it was an internal intranet, I treated it as though it was a full-blown web site.  I created a web site to display the server data stored in my back-end.  I took my Visio server room maps and created image files from them.  From the image files, I created image maps that enabled a user to click a server rack on the map, drilling down to a list of servers in that rack.  Clicking on a server displayed data for that server — serial numbers, IP addresses, applications, and so on.

My server inventory system, which I previously had to update manually, was now automated!

This project was a major milestone for my career.  It was my first significant foray into SQL Server.  (At that time, I hadn’t yet learned about data normalization; had I known about it, I could’ve made the back-end even better.)  It gave me some experience with image maps, HTML, and classic ASP (the technology used on that intranet server at that time).  Most of all, it was my first taste of what it was like to be a web applications developer.

Memories of this project also reminded me of another good day I had on the job.  One particular day, I traveled to remote offices in Yorktown Heights and Middletown to survey their data centers for the server inventory system that I just described.  I hopped into my truck (I owned a small Toyota pickup truck at the time) and drove to Yorktown.  It was a gorgeous picture-perfect day; the sun was out and it was comfortably warm with low humidity.  It was comfortable enough that I left the air conditioner turned off and drove the entire trip with my windows rolled all the way down.  It was the kind of day where I wished I owned a convertible!  My route between the Yorktown and Middletown offices took me through the Bear Mountain area, including traversing the Hudson River over the Bear Mountain Bridge.  If you’ve never driven through that area of New York State, it is an absolutely picturesque and beautiful drive.  The entire trip was so fun and relaxing that it did not feel like a business trip at all; I actually felt as though I was on a vacation!

Finally, I want to talk about one last project in which I had a hand.  In one of my first jobs out of college (my second job out of school, actually), I was responsible for supporting my company’s document imaging system at a client site (a client that eventually ended up hiring me directly).  One of the system’s components was a WORM optical platter jukebox that was in constant use and occasionally needed operations maintenance, which ranged from simple tasks such as inserting an optical platter to complex ones such as restarting it when it locked up.  The device had to be operational 24/7, even at hours when we were not in the office.

I was tasked with putting together a small set of instructions — nothing big, just a few pages — that explained how to perform these tasks, including the correct way to insert a platter, what to do when (unfortunately, not if) the machine stopped working, and so on.  It needed to be written in such a way that the night maintenance staff could maintain the device.  So I sat down in front of my PC with a blank MS Word file and said to myself, “if I was a member of the night staff, what would I want to read that would enable me to perform these tasks?”

I had intended for the document to be a simple three to four page quick reference.  As I wrote and came up with more ideas that would help the readers who would be using it (including the innovative — for me — use of illustrations), the document kept getting bigger and bigger.  I don’t remember how big it eventually became, but I think it was somewhere in the ballpark of thirty pages.  I had absolutely zero technical writing experience at the time; I wrote the document completely by instinct.  I didn’t really know what I was doing; I just did things (illustrations, headers, subject organizations, etc.) that made sense to me.

The final product was a huge success — so much so, in fact, that management developed a training program based around this document.

A couple of years later, I discovered that nearby Rensselaer Polytechnic Institute had a Masters degree program in technical communication (note: I am not entirely sure if the program still exists).  I had been interested in pursuing a graduate degree, and I thought the program sounded interesting, so I decided to apply.  During my application interview with the faculty, I brought along a copy of that operational jukebox document I’d written.  I explained that I’d written the document completely by instinct and with no knowledge or experience in technical writing whatsoever.  The faculty seemed to be impressed with my effort on that project.

I was accepted into the program.  I now have an MS from RPI hanging on my home office wall and listed on my resume.

This article ended up being a lot longer than I expected.  Looking back on this exercise that Steve assigned, I suppose my good days at work were more significant than I thought.  These projects were major events that ended up shaping this professional career.  I suppose the moral of the story is not to underestimate job achievements.  You never know where they might lead!