Author: Matt

When maintaining and improving upon legacy code it’s easy to redefine standards, or define nonexistent standards, which have cascading effects on the pipeline. Take something as simple as an ill-conceived naming convention which, in hindsight, turned out to not make sense over time. At some point the benefits of rewriting lots of code outweigh simply sticking with the bad convention. In these cases consistency over standards become the convention.

I recently went to a forum hosted by Women In Technology where they invited a large group of young women, some in high school up to some in their first internship out of college, who were there to meet one-on-one with tech professionals to ask questions and interact with some of the industry’s best (not self-promoting; there were many fine, far-more-seasoned-engineers at this event). Think speed-dating but for gathering knowledge, which I’ve dubbed: Women In Tech Speed-Mentoring.

I, of course, promoted data; I promoted the hell out of data!

The event itself was unfortunately quite short, for the mentees anyway, for which we all only spoke one-on-one with three aspiring tech geeks (plus a few chats while waiting in the pizza line). Some were declared computer science majors while others were still unsure of a direction to go in this broad world of tech. I, of course, promoted data; I promoted the hell out of data! However, in doing so, I was taken back by a couple things and pleasantly surprised at others — all of which gave me a chance to really connect with them, I hope. These surprises made me want to write this post…

After a lot of swearing I decided to make this post, dynamic column names in SSRS 2005, to help the internet and give back to the huddled masses who still have to support this old reporting services instance from 2005. In this version, as all of my dead-end googling revealed, there is no way to dynamically or ordinal-positionally set the column names in your reports — which is insane! I mean, what year were Microsoft in, in 2005?

Anway, like I said, after a lot of swearing, I came up with a creative way to achieve dynamic column names in SSRS 2005 and this post will share how you can implement the same solution.

I’ve recently challenged myself to build a few extensions for the Chrome browser. I recently finished my first one, still working on the others, and was so proud of the results I thought I would make a post about it. The extensions is called Tab Colorizer and, if it wasn’t obvious, is a chrome extension which allows you to customize and change the color of your open tabs.

I recently was tasked with building a new table with two Type-2 tables as a source and, not only maintain the history but, rebuild the history. Let’s look at the best way to join two type-2 tables together and then, more specifically, how to join the two historized tables together while preserving the logical history of changes as though they were one.

Join Two Type-2 Tables

The Setup:

Imagine you have two tables, typically type-2 dimensions, which have persisted historical records of changes: One for capturing your customer’s name over time, and another for tracking your customer’s phone number changes over time. In some cases, you may not have a historical record in one table, or the other, leaving an unknown name or phone number captured for a given customer. When re-building history you have to take care of these new periods of time where something hasn’t happened yet.

Now imagine that a customer changed her name three times and only on that third time did she also provide a phone number. That means, our third historical entry of her name change could potentially turn into five records, depending on when the phone number insert/update occurred.

Look for something ridiculous? Not that long ago I used to think that the best interview questions were one where the candidate could answer the question in many different but accurate ways, rather than just one perfect way. Which, at the time, would have weeded out many incompetent colleagues, consultants, and managers. It seemed fool-proof!

Fast forward to today, after much more experienced in interviewing and matured in my expectations of nervous people. These people are just people – they just mostly suck. Like, foundationally terrible candidates, four out of every five. The cure is that while they may not perform like you expect, they may show other signs – much like how I thought the ability to Open Notepad was a single testament to skill – there is one great trait to look for: Passionate Interest! No matter the questions you ask a candidate if they get excited, geeky, inspired, passionate about the answer, then you’ve got something special.

My argument here is that one who would answer the questions the way you’d ideally-expect versus someone who may underperform, yet still be a contender, will still be equally expressive in a positively geeky way. While the true underperformers will break down in many obvious ways, the common denominator between them will undoubtedly be their disdain for coming to a solution; An eagerness to say something, rather than feeling something. These are the simple clues to look for. Look for something ridiculous and genuine. These are the people who will be there to bounce ridiculous ideas off of and fuel the team.

Nobody wants to work on a team where people only share details when you ask for them. I want to work on teams where people share information because they think it will be helpful even though you didn’t ask for it.

Regardless of your RDBMS you’ll find more than a handful of scripts online to add a Date Dimension or Calendar Table to your schema. One problem I’ve seen is they lack an every-other-week column. So, let’s explore a common SQL Server script and how to add an Every Other Week flag to our date dimension.

This method is written for Microsoft’s SQL Server, but it is ANSI standard and will work with any date dimension which has an integer day-of-week column, which I’ve never seen one that doesn’t…

Dynamic SQL, a photo of a single train track splitting into many tracks.

In ETL, we often have to load many targets from a common set of base tables. Inevitably the targets are different enough that we have to create multiple queries or views to populate the many outputs of data. Which is fine, except now you’ve got yourself a maintenance nightmare, one that is avoidable. I’d like to share a trick with you to take a single query that can be recursively modified to dynamically change its structure to get different outputs. I call it, dynamic querying using block quotes.

The business case:

The sales department would like to take a single report that already exists and split it into two reports. The additional report will require different fitlers, aggregates, columns, and even joins!