This post is a response to this month’s T-SQL Tuesday #112 prompt by Shane O’Neill. T-SQL Tuesday is a way for the SQL Server community to share ideas about different database and professional topics every month. In this month’s topic Shane asks us to describe past accomplishments that help keep us going.
Before the start of each presentation I give, I’m a nervous wreck.
It’s not that I don’t like presenting (I do) but in the minutes before my presentation start time I’m always filled with dread . Once I start my talk and am in the flow of my content the nerves usually subside. Those first few minutes are always rough though.
Before speaking I try to calm myself by going through a few various techniques, one of which is thinking about previous successful speaking engagements.
You’ve Done This Before
I rarely focus on a single past speaking engagement; rather I look at all of my appearances and pick one that best helps for the current situation.
Every presentation I give has some kind of new elements associated with it; some of these might be environmental like a bigger audience or a strange room setup, but others are self-imposed like wanting to try out a new story-telling technique or an interactive audience exercise.
At this point, I usually have enough previous speaking experiences to try and rationalize away any stressful thoughts:
“Speaking is scary.” – You’ve done it before, you can do it again.
“This is a big audience.” – Your online audiences have definitely been bigger.
“This joke will bomb.” – You won’t know until you try. And your past session reviews indicate that people think you are funny.
The great thing here is that I’m always able to find a way to rationalize some successful past experience as having been comparable or more difficult than the current scenario. Even when I only had a couple of speaking sessions under my belt, I could think back to when I successfully taught my coworkers something, or had to teach my family members how to do something technical.
100% Survival Rate
I still get nervous before speaking, but at least I can also remind myself that I’ve survived every previous time I’ve done it.
I’m not sure my nervousness will ever go away, but having past successes to think back on always helps quiet those nerves just a little bit.
This post is a response to this month’s T-SQL Tuesday #111 prompt by Andy Leonard. T-SQL Tuesday is a way for the SQL Server community to share ideas about different database and professional topics every month.
In this month’s topic Andy asks why do we do what we do?
Two years ago, I was
I’d come home from work, spend my free time watching Netflix and surfing the internet, occasionally tinker with some random side projects, and eventually going to bed. Rinse and repeat, day in and day out.
I felt unfulfilled. While I value free time and relaxation, I had an overabundance of it. I felt like I should be doing something more productive with at least some of that time. I wanted to work on my “professional development” somehow, but it was extremely difficult to get motivated to work on boring career stuff.
I decided what I needed was a long-term project that would allow me to have fun and be creative, while also having some positive personal and professional development benefits; what I was looking for was the ULTIMATE side project.
After spending some time thinking about different ideas, I decided to make videos about SQL Server. Not only would I enjoy learning more about how SQL Server works (fun), but I could get practice writing and speaking (career) as well as get to incorporate my other hobby of film making into the mix (creative).
At first it felt forced; while I enjoyed learning new things about SQL Server, it was not easy thinking of topics. Writing and editing was strenuous, but coming up with jokes and visual ways to convey ideas was fun. Filming (and lighting and audio recording) was hard, but editing has always been pure pleasure for me.
So while at times coming up with a weekly bit of content was challenging, I kept at it because not only was it good for me, but I incorporated enough fun and creative elements into the process to look forward to it and keep going with it.
Fast forwarding to today, the process still isn’t perfect but things have gotten better: I have enough ideas to probably last me a few years (and generating more all the time), writing is still tough but I’ve seen noticeable progress so I’m motivated to keep at it, I still don’t like being in front of a camera but I have a dramatically easier time speaking about technical topics so the practice has paid off there, and while every episode isn’t as creative as I’d like, I have a lot of fun being weird and coming up with new ideas for weekly videos.
Not only that, I now have new motivating factors that I didn’t have from day one. I’ve made friends with a lot of people in the SQL Server community, and they are fantastic and supportive. Many of them even want to collaborate and make fun videos which is something I always look forward to. The audience that consumes the content is wonderful as well; every time I receive a thank you email or comment, I am filled with joy. And obviously all of the skills I have learned – technical, presenting, and networking – have helped immensely in my day-to-day.
In conclusion, the reasons that caused me to start creating SQL Server videos still apply, however over time that list of motivators has grown and helps me continue to remain excited about what I do, even when the challenges feel greater some weeks than others.
This post is a response to this month’s T-SQL Tuesday #110 prompt by Garry Bargsley. T-SQL Tuesday is a way for the SQL Server community to share ideas about different database and professional topics every month.
This month’s topic asks to share how we automate certain processes.
I’m a fan of keeping documentation close to the code. I prefer writing my documentation directly above a procedure, function, or view definition because that’s where it will be most beneficial to myself and other developers.
Not to mention that’s the only place where the documentation has any chance of staying up to date when changes to the code are made.
What drives me crazy though is making a copy of that documentation somewhere else, into a different format. You know, like when someone without database access needs you to send them a description of all of the procedures for a project. Or if you are writing end-user documentation for your functions and views.
Not only is creating a copy of the documentation tedious, but there is no chance that it will stay up to date with future code changes.
So today I want to share how I automate some of my documentation generation directly from my code.
/// Retrieves the details for a user.
/// <param name="id">The internal id of the user.</param>
/// <returns>A user object.</returns>
public User GetUserDetails(int id)
User user = ...
I like this format: the documentation is directly next to the code and it is structured as XML, making it easy to parse for other uses (eg. use a static document generator to create end-user documentation directly from these comments).
This format is easily transferable to T-SQL:
<summary>Retrieves the details for a user.</summary>
<param name="@UserId">The internal id of the user.</param>
<returns>The username, user's full name, and join date</returns>
CREATE PROCEDURE dbo.USP_SelectUserDetails
SELECT Username, FullName, JoinDate FROM dbo.[User] WHERE Id = @UserId
<summary>Returns the value 'A'.</summary>
<param name="@AnyNumber">Can be any number. Will be ignored.</param>
<param name="@AnotherNumber">A different number. Will also be ignored.</param>
<returns>The value 'A'.</returns>
CREATE FUNCTION dbo.UDF_SelectA
Sure, this might not be as visually appealing as the traditional starred comment block, but I’ve wrestled with parsing enough free formatted text that I don’t mind a little extra structure in my comments.
Querying the Documentation
Now that our T-SQL object documentation has some structure, it’s pretty easy to query and extract those XML comments:
WITH DocumentationDefintions AS (
SCHEMA_NAME(o.schema_id) as schema_name,
o.name as object_name,
CAST(SUBSTRING(m.definition,CHARINDEX('<documentation>',m.definition),CHARINDEX('</documentation>',m.definition)+LEN('</documentation>')-CHARINDEX('<documentation>',m.definition)) AS XML) AS Documentation,
p.parameter_id as parameter_order,
p.name as parameter_name,
t.name as parameter_type,
INNER JOIN sys.sql_modules m
ON o.object_id = m.object_id
LEFT JOIN sys.parameters p
ON o.object_id = p.object_id
INNER JOIN sys.types t
ON p.system_type_id = t.system_type_id
o.type in ('P','FN','IF','TF')
t.c.value('author','varchar(100)') as Author,
t.c.value('summary','varchar(max)') as Summary,
t.c.value('returns','varchar(max)') as Returns,
p.c.value('@name','varchar(100)') as DocumentedParamName,
p.c.value('.','varchar(100)') as ParamDescription
OUTER APPLY d.Documentation.nodes('/documentation') as t(c)
OUTER APPLY d.Documentation.nodes('/documentation/param') as p(c)
p.c.value('@name','varchar(100)') IS NULL -- objects that don't have documentation
OR p.c.value('@name','varchar(100)') = d.parameter_name -- joining our documented parms with the actual ones
This query pulls the parameters of our procedures and functions from sys.parameters and joins them with what we documented in our XML documentation. This gives us some nicely formatted documentation as well as visibility into what objects haven’t been documented yet:
Only the Beginning
At this point, our procedure and function documentation is easily accessible via query. We can use this to dump the information into an Excel file for a project manager, or schedule a job to generate some static HTML documentation directly from the source every night.
This can be extended even further depending on your needs, but at least this is an automated starting point for generating further documentation directly from the T-SQL source.