Code. Build. Repeat.

I recently passed my 70-761 Querying Data with Transact-SQL exam as part of mt revision I created the following diagram to help me remember how PIVOT and UNPIVOT work. I thought it would be good to share. For completeness, the following gives the syntax to use when using PIVOT and UNPIVOT. WITH PivotData AS ( SELECT <grouping column> , <spreading column> , <aggregation column> FROM <source table> ) SELECT <grouping column>, <distinct spreading values> FROM PivotData PIVOT (<aggregation function>(<aggregation column>) FOR <spreading column> IN <distinct spreading values>)); SELECT <grouping column>, <target names column>, <target values column> FROM <pivoted source table> UNPIVOT(<target values column> FOR <target names column> IN (<distinct spreading values>)); The End

Introduction A few days ago the opportunity came up for me to run a sprint retrospective for our sprint team. So I took the chance to try my hand at doing something a bit different. To give a quick bit of background to our sprint team. We have been trying to adopt agile practices for a while now but for one reason and another we have been quite slow in adoption of all the sprint practices we want to use. As such even though we have been "using agile" for over a year now, we have only had one sprint retro prior to the one I volunteered to run. Before I hosted the retro I read up (probably reading the same articles that everyone else reads after googling "sprint retrospective") and got the usual things about you cover "what we should start doing", "what we should stop doing" and "what we should continue doing". Rather than this being a rehash of these articles I wanted to talk about something different - the actual practicalities of...

Work needs to be estimated so that it can be scheduled and organised. Time is the most obvious method for this estimation. But time can be hard to estimate sometimes, and how granular do you make your estimates? To the day? To the hour? Half hour? A competing method for this estimation is to estimate effort. But how do we estimate effort? This is where story points come in. Story point estimation assigns a value to a task to indicate it's complexity. The higher the number, the more complex the task. What numbers should we choose for our range of story points? That's entirely up to you. You could use the numbers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. This type of series works fine for the smaller numbers - 2 is twice the size of 1, so a task assigned 2 story points is twice as complicated as a task assigned a 1 etc. But this series of numbers falls down at the higher numbers in the series - 10 is only a ninth bigger than 9. So for the higher numbers in the series its much harder to...

I recently watched the preview of C#8 with Mads Torgersen and Seth Juarez ( here ). I would recommend giving it a watch. But if you don't have time I've written a summary of the new features they talked about in this article.  (It's probably important to say C#8 is still in the planning stages, so some of these features may change) Nullable Reference Types We are all familiar with nullable value types in C#. At the moment you can declare a type as either int or int? (for example). The int type cannot be null and if you want to use the int? type as an int (i.e. get the value of it) its up to you to perform the necessary checks on the value that it isn't null. However, for reference types, there is currently no such thing as a "nullable reference type". Creating all those "null reference exceptions" in our production system we hate. For exampe: string s = null; int len = s.Length; is valid C# but will produce a runtime error. Well, ...