Upcoming .NET Course at Eleven Fifty Academy

Well, I’ve really done it this time – I agreed to lead the Intro & Intermediate Microsoft .NET course at Eleven Fifty Academy here in Carmel, Indiana. I know that the target audience for this course isn’t likely reading my blog but if you know someone who would be interested please pass this along.

In this seven day bootcamp style course we’ll cover the following topics:

  • Walkthrough of the Visual Studio IDE
  • Declaring Constants and Variables
  • C# control statements, loops, and enumerators
  • String manipulation
  • Working with Arrays, Dictionaries, and Hashtables
  • Function Declarations
  • Anonymous functions
  • Class definitions, Structures, Enumerations, Generics
  • ASP .NET MVC 5 Overview
  • ASP .NET MVC Lifecycle
  • Controllers and Routing
  • Entity Framework 6 Code First and Database First
  • Validating form input
  • Building and Consuming RESTful services
  • Interacting with third-party API’s
  • Debugging

The course runs from October 10 through October 16 and costs $2,500 but thanks to the generosity of our sponsors T2 Systems, Do It Best Corp, and BitWise Solutions, the discount code ‘OpenHouse50’ is available for a 50% discount!

Reshaping Data with R

I was scrolling through my Facebook feed yesterday afternoon and one post stood out among the endless stream of memes. A friend had a data transformation question! She said:

Data handling question! I fairly frequently receive “tall” client data that needs to be flattened to be functional. So for example, Jane Doe may have twelve rows of data, each for a different month of performance, and I need to compress this so that her monthly performance displays on one row only, with columns for each month. Anyone know of a relatively painless way to do this quickly? I’ve been sending files like this to our data guy to flatten, but I’d love to be able to do it myself.

I immediately thought: “Hey! This sounds like a job for R!” Unfortunately, my R knowledge is limited to knowing that it’s a statistical programming language so in the interests of both helping out my friend and getting a little experience with something I’ve wanted to play around with, I set out to see how easy – or difficult – this task would be in R. It turned out to be quite simple.

Naturally I didn’t even have the R environment installed on my laptop so I obtained the installer from the R project site. Once it installed, I was off.

I started by creating a CSV that would simulate the scenario she described. My highly contrived data looked like this:

Name Month Value
Jane Doe January 10
Jane Doe February 11
Jane Doe March 5
Jane Doe April 8
Jane Doe May 10
Jane Doe June 15
Jane Doe July 12
Jane Doe August 8
Jane Doe September 11
Jane Doe October 7
Jane Doe November 9
Jane Doe December 13
John Doe January 5
John Doe February 3
John Doe March 8
John Doe April 7
John Doe May 6
John Doe June 5
John Doe July 5
John Doe August 8
John Doe September 4
John Doe October 2
John Doe November 5
John Doe December 9

With some source data ready it was time to move onto reading the data. It turns out that R has some nice capabilities for reading CSV files so I loaded it as follows:

df <- read.csv(file="C:\\Dev\\Data.csv", header = TRUE)

Here we’re reading the CSV and binding the resulting data frame to df.

Next, I needed to transform the data. After a bit of research I found there are a few ways to do this but using the reshape2 package seemed like the easiest approach. I installed the package and referenced it in my script.


Reshape2 is designed to transform data between wide and tall formats. Its functionality is built around two complementary functions; melt and cast. The melt function handles transforming wide data to a tall format whereas cast transforms tall data into a wide format. Given that my friend was trying to convert from tall to wide, cast was clearly the one I needed.

The cast function comes in two flavors: dcast and acast which result in either a new data frame or a vector/matrix/array respectively. To (hopefully) keep things simple I opted for the data frame approach and used dcast for this transformation.

To transform the data I simply needed to apply the dcast function to the CSV data. That is done like this:

pivot = dcast(df, Name~Month)

Here, the first argument df is our CSV data. The second argument specifies the column names that will serve as the axis for the transformation.

Finally I needed to persist the data. Just as with loading, R can easily write a CSV file.

write.csv(pivot, file="C:\\Dev\\Pivot.csv")

Finally, I executed the script and here’s the result:

Name April August December February January July June March May November October September
1 Jane Doe 8 8 13 11 10 12 15 5 10 9 7 11
2 John Doe 7 8 9 3 5 5 5 8 6 5 2 4

Although the data was transformed correctly it wasn’t quite what I expected to see. There are two problems here:

  1. The row numbers are included
  2. The months are alphabetized

It turns out that both of these problems are easy to solve. Let’s first handle eliminating the row numbers.

To exclude the row numbers from the resulting CSV we simply need to set the optional row.names parameter to FALSE in the write.csv function call.

write.csv(pivot, file="C:\\Dev\\Pivot.csv", row.names=FALSE)

Fixing the column order isn’t quite as simple but it’s really not bad either; we simply need to manually specify the column order by treating the frame as a vector and using the concatenation function to specify the new order.

In the interest of space I used the index approach but it’s also acceptable to use the column names instead.

pivot = dcast(df, Name~Month)[,c(1,6,5,9,2,10,8,7,3,13,12,11,4)]

Putting this all together, the final script now looks like this:


df <- read.csv(file="C:\\Dev\\Data.csv", header = TRUE)

pivot = dcast(df, Name~Month)[,c(1,6,5,9,2,10,8,7,3,13,12,11,4)]

write.csv(pivot, file="C:\\Dev\\Pivot.csv", row.names=FALSE)

Run this version and you’ll get the following, cleaned up result:

Name January February March April May June July August September October November December
Jane Doe 10 11 5 8 10 15 12 8 11 7 9 13
John Doe 5 3 8 7 6 5 5 8 4 2 5 9

So I ask this of my friends and readers that are more versed in R than I. Is this the preferred way to handle such transformations? If not, how would you approach it?

Camp Pluralsight

I’m a bit late to the party on this one but on July 13, Pluralsight kicked off Camp Pluralsight, a 6-week online “summer camp” featuring more than 30 of its highest rated courses (no, my course sadly isn’t among them) covering topics in development, IT operations, and design. In addition to providing free access to some high quality content, Camp Pluralsight includes weekly challenges for participants to complete and become eligible to win prizes such as a Surface Pro 3, an Alienware X51 gaming desktop, and a Silicon Valley Comic Con VIP Package for two.

If you’re looking for an easy way to boost your skills and want a chance to win something while doing it, this is definitely a great opportunity. You can find the official rules and registration form on the Camp Pluralsight event page. Good luck!

Upcoming Events

I have a few speaking engagements coming up that I wanted to let you know about. First, I’ll be visiting Cincinnati, Ohio on July 28 for CINNUG. Then, on August 20 I’ll be making the quick trip down to Louisville, Kentucky for the Louisville .NET Meetup Group.

For both of these events I’ll be speaking about Functional .NET. In this talk we’ll explore some of the ways that we can utilize higher-order static methods and extension methods to enable the rough equivalent of some functional patterns in C#. As a bonus, I’ll also be giving away a copy of my book, The Book of F# at each of these events!

If you’re in the Cincinnati or Louisville areas and interested in learning how applying functional techniques in C# can improve your overall code quality, be sure to join us! As always, check the respective group pages for up-to-date logistics. I hope to see you there!


I’ve been working in Visual Studio for years – long enough that many of the most useful keyboard shortcuts are now permanently embedded in my finger muscle memory. Sure, there are plenty of shortcuts I need to look up from time to time but I usually think I have a pretty good handle on them. Every once in a while though, I do something silly and Visual Studio either rewards or punishes me in an unexpected way. Today was one of those days.

For whatever reason, I was holding the ctrl key when I hit backspace in VS2013 and suddenly the entire property name just disappeared! I tried it again and the preceding dot disappeared. One more time and the object name disappeared.

I have no idea how it’s taken me this long to stumble upon this shortcut but I’m glad I did! You can see the behavior in the animation below.


My 5 Favorite C# 6.0 Features

With C# 6 nearly upon us I thought it would be a good time to revisit some of the upcoming language features. A lot has changed since I last wrote about the proposed new features so let’s take a look at what’s ahead.

I think it’s fair to say that have mixed feelings about this release as far as language features go especially since many of my favorite proposed features were cut. I was particularly sad to see primary constructors go because of how much waste is involved with explicitly creating a constructor, especially when compared to the same activity in F#. Similarly, declaration expressions would have nearly fixed another of my least favorite things in C# – declaring variables to hold out parameters outside of the block where they’re used. Being able to declare those variables inline would have been a welcome improvement. That said, I think there are some nice additions to the language. Here’s a rundown of my top five favorite C# 6.0 language features in no particular order.

Auto-Property Initialization Enhancements

The auto-property initialization enhancements give us a convenient way to define an auto-property and set its initial value without necessarily having to also wire up a constructor. Here’s a trivial example where the Radius property on a Circle class is initialized to zero:

public class Circle
    public int Radius { get; set; } = 0;

The same syntax is available for auto-properties with private setters like this:

public class Circle
    public int Radius { get; private set; } = 0;

So we saved a few keystrokes by not needing a constructor. Big deal, right? If this were the end of the story, this feature definitely wouldn’t have made this list but there’s one more variant that I’m really excited about: getter-only auto-properties. Here’s the same class revised to use a getter-only auto-property:

public class Circle
    public int Radius { get; } = 0;

Syntactically these don’t differ much but behind the scenes is a different story. What getter-only auto-properties give us is true immutability and that’s why I’m so excited about this feature. When using the private setter version, the class is immutable from the outside but anything inside the class can still change those values. For instance,
in the private setter version it would be perfectly valid to have a Resize method that could change Radius. Getter-only auto-properties are different in that the compiler generates a readonly backing field making it impossible to change the value from anywhere outside of the constructor. This is important because now, when combined with a constructor we have a fairly convenient mechanism for creating immutable objects.

public class Circle
    public int Radius { get; }

    public Circle(int radius)
        Radius = radius;

Now this isn’t quite as terse as F#’s record types but by guiding developers toward building immutable types, it’s definitely a step in the right direction.

Using Static

Using static allows us to access static methods as though they were globally available without specifying the class name. This is largely a convenience feature but when applied sparingly it can not only simplify code but also make the intent more apparent. For instance, a method to find the distance between two points might look like this:

public double FindDistance(Point other)
    return Math.Sqrt(Math.Pow(this.X - other.X, 2) + Math.Pow(this.Y - other.Y, 2));

Although this is a simple example, the intent of the code is easily lost because the formula is broken up by references to the Math object. To solve this, C# 6 lets us make static members of a type available without the type prefix via new using static directives. Here’s how we’d include System.Math’s static methods:

using static System.Math;

Now that System.Math is imported and its methods are available in the source file we can then remove the references to Math from the remaining code which leaves us with this:

public double FindDistance(Point other)
    return Sqrt(Pow(this.X - other.X, 2) + Pow(this.Y - other.Y, 2));

Without the references to Math, the formula becomes a bit clearer.

A side-benefit of using static is that we’re not limited to static methods – if it’s static, we can use it. For example, you could include a using static directive for System.Drawing.Color to avoid having to prefix every reference to a color with the type name.

Expression-Bodied Members

Expression-bodied members easily count as one of my favorite C# 6 feature because they elevate the importance of expressions within the traditionally statement-based language by allowing us to supply method, operator, and read-only property bodies with a lambda expression-like syntax. For instance, we could define a ToString method on our Circle class from earlier as follows:

public override string ToString() => $"Radius: {Radius}";

Note that the above snippet uses another new feature: string interpolation. We’ll cover that shortly.

At first glance it may appear that this feature is somewhat limited because C#’s statement-based nature automatically reduces the list of things that can serve as the member body. For this reason I was sad to see the semicolon operator removed from C# 6 because it would have added quite a bit of power to expression-bodied members. Unfortunately the semicolon operator really just traded one syntax for an only slightly improved syntax.

If expression-bodied members are so limited why are they on this list? Keep in mind that any expression can be used as the body. As such we can easily extend the power of expression-bodied members by programming in a more functional style.

Consider a method to read a text file from a stream. By using the Disposable.Using method defined in the linked functional article, we can reduce the body to a single expression as follows:

public static string ReadFile(string fileName) =>
        () => System.IO.File.OpenText(fileName),
        r => r.ReadToEnd());

Without taking advantage of C#’s functional features, such an expression wouldn’t be possible but in doing so we greatly extend the capabilities of this feature. Essentially, whenever the property or method body would be reduced to a return statement by using the described approach, you can use an expression-bodied member instead.

String Interpolation

Ahhh, string interpolation. When I first learned that this feature would be included in C# 6 I had flashbacks to the early days of my career when I was maintaining some Perl CGI scripts. String interpolation was one of those things that I always wondered why it wasn’t part of C# but String.Format, while moderately annoying, always worked well enough that it wasn’t particularly a problem. Thanks to a new string literal syntax, C# 6 will let us define format strings without explicitly calling String.Format by allowing us to include identifiers and expressions within holes in the literal. The compiler will detect the string and handle the formatting as appropriate by filling the holes with the appropriate value.

To define an interpolated string, simply prefix a string literal with a dollar sign ($). Anything that should be injected into the string is simply included inline in the literal and enclosed in curly braces just as with String.Format. We already saw an example of string interpolation but let’s take another look at the example:

public override string ToString() => $"Radius: {Radius}";

Here, we’re simply returning a string that describes the circle in terms of its radius using string interpolation. String.Format is conspicuously missing and rather than a numeric placeholder we directly reference the Radius property within the string literal. Just as with String.Format, we can also include format and alignment specifiers within the holes. Here’s the ToString method showing the radius to two decimal places:

public override string ToString() => $"Radius: {Radius:0.00}";

One of the things that makes string interpolation so exciting is that we’re not limited to simple identifiers; we can also use expressions. For instance, if our ToString method was supposed to show the circle’s area instead, we could include the expression directly as follows or even invoke a method:

public override string ToString() => $"Area: {PI * Pow(Radius, 2)}";

The ability to include expressions within interpolated strings is really powerful but, as Bill Wagner recently pointed out, the compiler can get tripped up on some things. Bill notes the conditional operator as one such scenario. When the conditional operator is included in a hole the colon character confuses the compiler because the colon is used to signify both the else part of the conditional operator and to delimit the format specifier in the hole. If this is something you run into, simply wrap the conditional in parenthesis to inform the compiler that everything within the parens is the expression.

Null-Conditional Operators

Finally we come to the fifth and final new feature in this list; a feature I consider to be a necessary evil: the null-conditional operators. The null conditional operators are a convenient way to reduce the number of null checks we have to perform when drilling down into an object’s properties or elements by short-circuiting when a null value is encountered. To see why this is useful consider the following scenario.

Imagine you have an array of objects that represent some type of batch job. These objects each have nullable DateTime properties representing when the job started and completed. If we wanted to determine when a particular job completed we’d not only need to make sure that the item at the selected index isn’t null but also that the completed property isn’t null, either. Such code might look like this:

DateTime? completed = null;

if(jobs[0] != null)
    if(jobs[0].Completed != null)
        completed = jobs[0].Completed;

WriteLine($"Completed: {completed ?? DateTime.MaxValue}");

That’s quite a bit of code for something rather trivial and it distracts from the task of getting the completed time for a job. That’s where the null-conditional operators come in. By using the null-conditional operators, we can reduce the above code to a single line:

WriteLine($"Completed: {jobs?[0]?.Completed ?? DateTime.MaxValue}");

This snippet demonstrates both of the null-conditional operators. First is the ? ahead of the indexer. This returns if the element at that index is null. Next is the ?. operator which returns if the member on the right is null. Finally, we see how the null-conditional operators can be used in conjunction with the null-coalescing operator to combine the giant if block into a single expression.

So why do I consider this feature a necessary evil? The reason is that I consider null to be evil, null references have been called The Billion Dollar Mistake, and Bob Martin discussed the evils of null in Clean Code. In general, nulls should be avoided and dealing with them is a costly nuisance. I think that these null-conditional operators, which are also sometimes collectively referred to as the null-propagation operators, will do just what that name implies – rather than promoting good coding practices where null is avoided, including the null-conditional operators will encourage developers to sloppily pass or return null rather than considering whether null is actually a legitimate value with the context (hint: it’s not). Unfortunately, null is an ingrained part of C# so we have to deal with it. As such, the null-conditional operators seem like a fairly elegant way to reduce null’s impact while still allowing it exist.


There you have it, my five favorite C# 6 language features: auto-property initialization enhancements, using static, expression-bodied members, string interpolation, and the null-conditional operators. I recognize that some popular features such as the nameof operator and exception filters didn’t make the cut. While I definitely see their appeal I think they’re limited to a few isolated use cases rather than serving as more general purpose features and as such I don’t anticipate using them all that often. Did I miss anything? Let me know in the comments.

Creating a Generative Type Provider

In my recently released Pluralsight course, Building F# Type Providers, I show how to build a type provider that uses erased types. To keep things simple I opted to not include any discussion of generative type providers beyond explaining the difference between type erasure and type generation. I thought I might get some negative feedback regarding that decision but I still believe it was the right decision for the course. That said, while the feedback I’ve received has been quite positive, especially for my first course, I have indeed heard from a few people that they would have liked to see generated types included as well.

There are a number of existing type providers that use generated types, most notably in my opinion is the SqlEnumProvider from FSharp.Data.SqlClient. That particular type provider generates CLI-enum or enum-like types which represent key/value pairs stored in the source database.

Although SqlEnumProvider is a great example and is relatively easy to follow, general how-to documentation for generative type providers is hard to come by to say the least. As such I thought that showing how to write the ID3Provider built in the course as a generative type provider would be a nice addendum for the course material. I clearly won’t be covering everything I do in the course here so if you’re looking for a deeper understanding of type providers I strongly encourage you to watch it before reading this article. (more…)