I recorded my SQL Saturday session from this past weekend. If anyone is interested in checking out my presentation titled: “Networking 101: Building Professional Relationships,” it is now viewable online!
If you have an hour to kill, click here to see my presentation!
Yesterday, we (our local user group) hosted SQL Saturday for the seventh time. As many of you know, I love SQL Saturday. It’s one of my favorite events to attend, and I credit SQL Saturday for boosting my career in a number of ways. I’ve also made many friends through my involvement with SQL Saturday. I apply to speak at any SQL Saturday event that I am able to attend. My hometown event, hosted by a user group of which I’m a member, is all the more special to me. While I look forward to attending any SQL Saturday, I especially look forward to the ones we host here in Albany, and I very much look forward to next year’s event.
That said, the COVID-19 pandemic forced us to hold it virtually this year. While I’ve participated in a number of virtual events (including speaking for a virtual user group a few times), this was my first time speaking at a virtual SQL Saturday. I enjoyed the experience, but it also had a number of pros and cons.
Let’s start with the pros. There’s something to be said about attending a full day of presentations for an online conference from the comfort of your own home office (or your living room, or a bar, or even a beach with a good WiFi connection). Although it was a full day of presentations, I wasn’t necessarily chained to my office chair for the duration; I was free to get up and walk around as I pleased. We set up four different GoToMeeting channel URLs, each one representing a different “room.” Each speaker occupied his or her meeting room at their scheduled times and did their presentations, just as we would for a regular SQL Saturday. As an attendee, I could switch rooms at any time; mostly, it involved leaving a meeting I was in and switching to a different room URL. Like a regular SQL Saturday, there were many good presentations. I would have liked to have attended a lot more, but I promised that I would moderate at least one room, so I largely stuck around a couple of rooms in which I was an organizer or presenter.
Speaking of moderating rooms: I volunteered to moderate the lightning talks. If you’ve never attended a lightning talk, think of it as a “micro-presentation,” only ten minutes long. We had five speakers doing lightning talks for our session. I was assigned as meeting organizer, and I assigned each speaker as presenter when it was his turn to speak. The GoToMeeting controls took a little getting used to — there is a little bit of a learning curve — but once I got the hang of it, I felt comfortable moderating the room channel.
My own presentation also went very well! I’ll admit that I felt a little trepidation going into it. Those of you who attend my presentations know that I like to do interactive presentations. I try to get my audience involved as much as possible. It keeps them engaged, and I like to think that it makes for an interesting presentation. I wasn’t sure how that would work in an online setting, although GoToMeeting does include tools for people to ask questions in a virtual chat function. One aspect of my networking presentation is a part where I allow ten minutes for my audience to do some in-room networking. This is easy to do in a in-person presentation where we’re all physically occupying the same room, but more challenging in an online forum. I ended up asking for a couple of volunteers, unmuting them (allowing them to actually speak in the meeting room), and encouraged them to engage in a networking session while the rest of us listened in. It ended up working remarkably well! If I ever do this session again virtually, I’ll have to keep that in mind!
I also found it interesting that the virtual format meant physical geography was a non-issue. It’s not unusual for people to travel to SQL Saturday (the farthest in-person SQL Saturday events I’ve attended were Pittsburgh and Virginia Beach), but holding this event virtually meant that people could attend and present from almost anywhere. One of the volunteers for my presentation demo was from (I think it was) North Carolina. I’d be curious to know what the geographic attendance was for yesterday’s event.
I also have another thought that has nothing to do with virtual SQL Saturday. One of the presenters was Sarah Patrick, who is currently a college student (her father, David Patrick, is also himself a SQL Saturday presenter). Her presentation was a narrative about setting up a database to perform a specific task. This was the second time I’d seen her presentation; I saw her give the same presentation down in Virginia Beach last year. What I found interesting was Sarah herself — that such a young and bright person was involved in doing presentations for SQL Saturday. I would love to see more young people getting involved. Greg Moore had his entire family involved as volunteers for yesterday’s event. His oldest son is currently a college student majoring in computer science. He helped moderate one of the sessions, and I found myself wondering if he would be interested in being a SQL Saturday speaker. (Greg, if you’re reading this, hint, hint!)
As much as I enjoyed yesterday’s event, it had its cons as well. One of the things I love about SQL Saturday is seeing all the people whom I don’t see on a regular basis. #SQLFamily is a real thing. I missed being able to wander around the event and being able to randomly talk to a John Miner, a Deborah Melkin, or whomever I happen to come across. I dearly love my #SQLFamily friends, and not being able to randomly interact with them was no small thing.
Of course, I’ll also admit that I enjoy good food and drink. For the last few years, our post-event celebration has been held at a local bar. There’s something to be said about enjoying libations along with the camaraderie of your #SQLFamily friends. My wife and I settled for ordering out for Chinese food last night. And, of course, during the course of the event, I had to settle for getting or making my own coffee, snacks, and food.
Overall, I had fun yesterday, I learned a few things, and I would definitely attend another virtual SQL Saturday. That said, it is not the same as attending a SQL Saturday in-person; I vastly prefer physically attending an event. Virtual SQL Saturday was definitely a good experience, but it’s not the same as attending in-person. When the COVID-19 pandemic has passed, I very much look forward to attending SQL Saturday in-person again.
But for the time being, virtual SQL Saturday will have to do.
IMPORTANT! If you are attending SQL Saturday, you MUST register on the SQL Saturday website (NOT Meetup or Facebook) at https://www.sqlsaturday.com/961!
This is a reminder that tomorrow, July 25, CASSUG will host Albany SQL Saturday for the seventh time! And for the first time, Albany SQL Saturday is going virtual!
We will have a full day of great presentations that cover a variety of topics that include, but aren’t limited to, business intelligence, data science, database development, data architecture, and professional development!
We will also have our usual wrap-up and raffles at the end of the day!
To register, go to https://www.sqlsaturday.com/961. It is important that you register at this site; RSVPs to Meetup or Facebook do not register you for SQL Saturday!!!
SQL Saturday is always a good time! We hope to see you (virtually) on Saturday, July 25!
This morning, I had a conversation with a friend — a former coworker from a previous job — whom I listed as one of my references. He told me that he had a good conversation with a gentleman with whom I recently interviewed (whether or not I get the job remains to be seen). This friend has been invaluable throughout my job search, and I told him that I would get him a bottle of Scotch to say thank you once I landed.
It got me thinking: when it comes to advice about the job hunt, one topic that is almost never discussed are your references. Nearly every prospective employer asks for them, yet they are almost never mentioned when talking about the job hunt. I’ve read plenty of books and articles, and attended a number of SQL Saturday presentations, that talk about resumes, interview questions, how to dress, and so on. But it occurred to me that not one of them — including my own presentation (and I might need to rectify that) — talks about your references.
So, what should you consider when asking for people to serve as references? Here are my thoughts.
Your references are often an overlooked part of your job hunt. Make sure you choose them well. They might be the difference between whether or not you get the job.
It’s that time of year, when aspiring PASS speakers find out whether or not they’re speaking at PASS Summit. I was fortunate to be selected to speak last year, and I had the time of my life! If you want to read more about it, check out my synopsis of it from last year!
I got the official email notification yesterday (and now that the list is up, I can say it publicly). Alas, I was not selected this year. Oh well. C’est la vie.
That said, I was (and still am) excited about being selected last year. To be selected to speak at PASS Summit just once is a great honor and a nice feather in my cap. To be selected again would be a bonus. And although I wasn’t selected this year, it won’t preclude me from applying again for next year… and the next… and the next.
Unfortunately, given my current employment — and subsequently, my financial — situation, it is highly unlikely that I will be able to attend this year’s Summit, even if COVID-19 has forced it to a virtual event. Although the fact that the event is virtual means prices are reduced, they are still too high for me to attend (unless, between now and then, I land a job and my new employer would be willing to pay my registration fee — note to any future employer who might be reading this: here is a letter that makes the case as to why it would be good to send me to PASS Summit! Note that this link downloads an MS Word document). “Virtual” does not mean “free;” there are a number of expenses that still need to be paid, even for an online event. My friend Monica Rathbun wrote a nice article about what it financially takes to put on a PASS Summit, even a virtual one.
I went through the speakers list, and I was happy to see that a number of my #SQLFamily friends were selected to speak! Congrats to all of you who were chosen!
And although I might not be able to attend this year, if you’re able to get to a PASS Summit, I highly suggest you do so! You’ll learn a lot, and it’s a great time!
On July 25, a week from Saturday, CASSUG will host SQL Saturday #961, Albany! This is a daylong conference covering a variety of data, technical, and professional topics! And this year, we are going virtual, so you don’t have to be in Albany to attend!
To register for the event, and for more information, go to our SQL Saturday website!
And oh yes, did I mention that I’m speaking? I will be doing my presentation on networking!
SQL Saturday is always a good time, and the Albany event, which is near and dear to my heart, is one of my favorite events of the year. I’ll see you, virtually, a week from Saturday!
With my previous article about getting into REST applications, I figured it would be a good idea for me to set up a data source so I could practice. Besides, I had reinstalled SQL Server 2019 on my machine, and I needed to import some data so that I could brush up on my SQL skills as well.
Being the baseball nut that I am, of course, I had to import baseball statistics, so I decided to reimport the most recent data from Sean Lahman’s baseball database. The last time I did this exercise, I downloaded a database format. I don’t remember what format I used (the links all say “Access” — which I don’t remember downloading), but the files I used had an .sql extension. This time, I used the comma-delimited version, which downloaded a zip file containing files with a .csv extension.
I wanted to import the files directly into my database and have them create the tables upon doing so, so I opened up my SSMS, created a new Baseball database, and looked into how to do this. After poking around a bit (and a little bit of Googling), I found that flat files could be imported by right-clicking the database of your choice (in the below example, “Baseball”), clicking Tasks, and selecting Import Flat File.
Selecting this opened an Import Flat File wizard. First, it prompted me to select the input file. (Note: if you are importing multiple files, as I did for this little exercise, the wizard is smart enough to remember your last folder when you click Browse.)
When it looks at the flat file, it gives you a preview of the data that you’re importing. Since, for this exercise, I’m importing comma-delimited flat files, it was able to put my data into nice, neat columns.
Clicking “Next” brought me to a screen where I could modify the columns. I like this option a lot, as it gives me an opportunity to set up my data schema the way I want. If you’re a SQL or database newbie, I strongly suggest that you learn about primary keys and data types and take the time to set them up at this point.
In this particular example, I set my yearID to char(4), stint to int (I will likely change this to tinyint), teamID to char(3), lgID to char(2), and pretty much everything after lgID to int. I also set my first five columns as a composite primary key and everything else to be nullable.
I must have set these columns up successfully, because when I ran it, it did so without complaining.
I wish I could say that I imported all of my flat files without a hitch, but I did run into a few that didn’t run successfully the first time. Here are some of the issues that I came across.
(*Some of you might be wondering, how do you get an ERA of infinity? Answer: you give up runs without getting anyone out! Mathematically, you would get a divide-by-zero error for calculating ERA, but in baseball parlance, it means you give up runs and can’t get anyone out!)
So hopefully at this point, you now have an idea as to how to import flat files into a SQL Server database (and maybe even got a small taste of data types and primary keys). And hopefully, this little utility saves you a lot of grief when trying to import flat files.
As my job hunt has progressed (or stalled, depending on what the case may be), I see a lot of programmer and developer jobs that look for REST API experience. While I do have object-oriented programming experience, a lot of it came about before REST became a widespread term. And since I’ve been out of the developer’s loop for a while, I figure that I should do more to get my hands dirty with REST APIs.
I was recently asked about a developer position in which I was asked about my REST API experience. The response I received (and I’m paraphrasing here) was something to the effect of, “your credentials are impressive, but I don’t see a lot of REST API experience.” Unfortunately for me, that was an accurate statement. The closest I came to a RESTful experience was a project in a previous job where I worked on a project with ASP.NET MVC, which, by its nature, was a RESTful technology, but otherwise, I don’t have a lot of experience with REST APIs.
So, consider this my first article in which I talk about REST APIs. These articles will be preceded by the #REST101 hashtag.
For this first article in this series, I’ll list a few REST tutorial links (that, admittedly, I’m posting for my own reference). I went out and did a Google search for REST API. Among other things, here are some interesting links that I found.
So if you’re a budding developer, and like me, you’re looking to learn more about REST APIs, come along with me. Let’s learn about this together.
Since I speak frequently at SQL Saturday, much of my audience is usually made up of data professionals. So whenever I do my presentation about technical writing or talking to non-technical people, I always ask the following question: do you understand the difference between data and information?
For those of you who don’t understand what I’m saying, let me elaborate. The terms data and information are not, I repeat, not interchangeable. Data refers to the collection of statistics, facts, and figures that are gathered through observation, research, and log captures. Information, on the other hand, is an interpretation of that data. Its creation involves analyzing the data, interpreting it, drawing conclusions from it, and presenting it in a way that can be understood by others. To put it another way, data refers to the raw materials, while information is the “finished” product.
(We could also get into a discussion that talks about how bias is introduced when data is analyzed and interpreted by humans, all of whom have some measure of preconceived bias, no matter how small, about the data they’re researching, but it goes beyond the scope of this article, and I won’t get into that now. That is another topic for another day.)
Once I establish that distinction, that’s when I go into what I believe is an important point about written communication: there is a difference between notes and documentation.
I believe this distinction is critical, and is often overlooked by people trying to write documentation. (One of the biggest things that disparaged one of my previous employers was that they did not understand — or worse, did not care about — that difference.) How many times have you been frustrated whenever you’ve asked for documentation about something, and the person you asked pointed you to something like a loose collection of seemingly-meaningless and disorganized scribbled notes that are kept in a three-ring binder? (Okay, maybe they’re kept digitally these days, not in a binder, but humor me, here.)
Granted, notes are important. They are thoughts in someone’s head that are expressed in written form. They are often important concepts that are jotted down so they can be remembered later. Those notes can come in many forms. How many of the best ideas, for example, started out as notes scribbled on a cocktail napkin?
However, more often than not, notes are only meaningful to the person who wrote them. Notes are mnemonics. They are not conveying information to a wide audience. In all likelihood, most people who read notes will not understand what they mean. Only the person writing the notes (or, if they’re jotted down during a meeting, the people attending the meeting) will understand what the notes are.
Documentation, however, is an interpretation of those notes. Documentation is notes that are presented in a way so that they can be understood by a wider audience. This is what professional communicators, such as technical writers, do. They’re in the business of taking loose data, such as notes, and making it meaningful.
Let me say it again for emphasis: notes are not documentation. To go back to my data and information analogy, data is to information what notes are to documentation. Notes are the raw material, but documentation is what makes the notes meaningful.
One of the new projects I’ve taken on is ghostwriting ‘blog articles for one of my clients. While I have plenty of technical writing experience — where I take a topic or application that isn’t mine and try to write about it — ghostwriting is an entirely new experience for me. Not only is it something new for me to tackle, I’m finding the experience to be interesting, and even fun!
My client maintains a ‘blog as part of his website, and by his own admission, isn’t a prolific writer — which is where I (along with one or two others) come in. I’ve only done a couple of articles for my client so far, but I’m learning a few things as I go along.
“No thinking – that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”
William Forrester (played by Sean Connery), Finding Forrester
I’m discovering that ghostwriting is a rewarding experience. It’s a great way to gain writing experience, and it ultimately makes me a better writer, a better worker, and a better person.
Musing on more than data, trying to make a difference somewhere...
Cultivate Your Workforce with Effective Human Strategies
"My job is to make other people's jobs easier"
Just me and the databases...
Hand-Crafted SQL and PowerShell from New York's Finger Lakes
SQL Blogs by Monica Rathbun
Microsoft Azure, Data Platform, SQL, Speaking, Community
Ideas are the hard part...the rest is just code
Writings from Steve Jones, the Voice of the DBA
Thoughts on SQL, Disasters and thinking
Big Data and Data Warehousing
A daily selection of the best content published on WordPress, collected for you by humans who love to read.
The Art and Craft of Blogging
The latest news on WordPress.com and the WordPress community.
Welcome to Ray Kim's 'blog 