# Monday, 17 May 2010

Episode 88

In this interview, Microsoft Product Unit Manager Cameron Skinner describes the architecture tools that his team built into Visual Studio 2010

Monday, 17 May 2010 10:55:01 (GMT Daylight Time, UTC+01:00)
# Friday, 14 May 2010

Like most statistical measurements of large groups, the success of people in a given population usually forms a normal distribution or "bell curve". In other words, most people fall at or near the average level of success; and as we move further above and below the average, fewer and fewer people appear at each level until the number approaches zero far above and below the average.

But some people fall well outside the boundaries predicted by the normal distribution. These people are outliers.

In his book "Outliers", Malcolm Gladwell is primarily concerned with those outliers who excel far beyond the level expected. These are intellectual geniuses and musical prodigies and world-class athletes who achieve great success.

Becoming an outlier takes talent and hard work - a lot of hard work: 10,000 hours of dedicated practice, according to Gladwell.  For example, the Beatles owe their success in large part to the fact that they performed 8-12 hours a day for 2 years at the clubs in Hamburg, Germany, allowing them a chance to perfect their craft before they recorded their first hit records.

But Gladwell insists that enormous success takes more than talent and hard work. It takes luck. And that luck sometimes follows measurable patterns and those patterns can be predicted.

As evidence, he points to birth dates as a major factor in the success of many outliers. Bill Gates, Paul Allen and Steve Jobs were born within months of each other; Of the 75% richest people in history, 14 were born in the United States between 1831 and 1840; and the vast majority of elite Canadian hockey players were born during the first half of the year.

He then explains reasons why something as seemingly arbitrary as a birth date would affect one's chance at extreme success. In each case, he presents a plausible explanation of the cause and effect. Canadian hockey players born in January, for example, tend to be placed in the same league as the much younger players born in December of the same year. At a very young age, this can be a huge advantage, so the older, bigger, stronger January-born athletes tend to dominate the less mature December-born players. As the stronger kids stand out more, they get picked for the better leagues, where they receive superior instruction and more practice time (making it more likely they will be able to put in 10,000 hours of practice before adulthood).

Just as talent and hard work alone will not guarantee success, neither will lucky circumstances. But these things improve one's chances - sometimes drastically.  Not all Canadian hockey players born in January make it to the NHL. But almost none of those born in December do.

Gladwell's case studies are very interesting and very plausible. He supports his hypotheses primarily with anecdotal evidence. But he supplies enough statistics to support his conclusions.

These seemingly random factors are often predictable, so it is possible to modify our behavior and increase our chances at great success. Some of them (month of birth, for example) are beyond our own control; while others (year of birth, are only known to be success factors later on), so it's difficult to modify all our behavior.

Outliers challenges the notion that people achieve great success solely through talent and hard work. Outliers is an interesting study of his findings and worth reading.

Friday, 14 May 2010 11:28:21 (GMT Daylight Time, UTC+01:00)
# Thursday, 13 May 2010

The var keyword was introduced in C# 3.0 and is used to declare a new variable.

The var keyword looks suspiciously like the variant keyword from Visual Basic 6. However, unlike variant, var is used to specify a strongly-typed variable. The type of the variable is inferred by the value initially assigned to that variable. As a result, whenever we use var to declare a variable, we must assign a value to the variable on the same line. So

var myString = "Hello";

is valid, but

var myString;

is not.

As mentioned earlier, the type of a variable is inferred from the value assigned to it, so in the line

var myString = "Hello";

is equivalent to

string myString = "Hello";

and

var myNum = 99;

is equivalent to

int myNum = 99;

The compiler is smart enough to recognize that "Hello" is a string and 99 is an integer and type the variable appropriately. This type checking is done at compile time, so the following code is invalid and will not compile

var x = 99;
x = "Hello";

because x is an integer, it is not possible to assign a string to it and the compiler knows this.

The var keyword is also smart enough to infer data types from the return types of functions. For example, if I have a function that returns an int and I assign the results of that function to a variable declared with the var keyword, that variable will be defined as an int. Here is a sample

static int AddNumbers(int x, int y)
{
return x + y;
}
var sum = AddNumbers(2,3);

The variable sum is an int because AddNumbers returns an int.

Earlier this year, following a user group presentation and someone noticed my use of the var keyword in my demos. The appropriateness of var became a Twitter debate and the subject of at least one blog post.

As long as I follow the rules, the compiler doesn't care whether I declare a variable using var or the explicit data type. So when do I use var? I use var when I think it will improve readability.

Consider the following 2 (equivalent) lines of code

Line 1: Customer cust = new Customer();
Line 2: var cust = new Customer();

Both lines are the same as far as the compiler is concerned. But the second line of code is more concise and easy to read. I have communicated the same information in a shorter command and with no loss of information. It should be obvious to anyone reading the second line that the variable cust contains a Customer object. In this case, I would declare the variable with the 'var' keyword because it is more readable.

The last example may not seem like there is much difference in readability between the two lines, but check out the following two equivalent lines

Line1: Dictionary<int, string> dict = new Dictionary<int, string>();
Line2: var dict = new Dictionary<int, string>();

Clearly, Line2 is more readable than Line1 in this case.

Now consider the following (equivalent) lines of code

Line 1: Customer cust = RetrievePrimaryCustomer();
Line 2: var cust = RetrievePrimaryCustomer();

Both lines are the same as far as the compiler is concerned. But I can't be sure, just from looking at the declaration, what data type is returned by the RetrievePrimaryCustomer method. The compiler knows the type, but I need to go through one or more manual steps to figure it out. In this case, the first option is more readable because it provides to anyone reading my code more information about the variable.

So my rule for using var is simple:

If the data type is obvious to anyone reading my code, use the var keyword; Otherwise explicitly specify the data type.

The var keyword is a useful shortcut that can help make your code more readable.

C#
Thursday, 13 May 2010 12:42:27 (GMT Daylight Time, UTC+01:00)
# Wednesday, 12 May 2010

Episode 87

In this interview, Day of .Net organizers John Hopkins and Jason Follas describe what went into planning this event and what were the results.

Wednesday, 12 May 2010 05:04:36 (GMT Daylight Time, UTC+01:00)
# Monday, 10 May 2010

Episode 86

In this episode, David Hoerster describes how he uses jQuery and WCF to create rich, interactive applications.

Monday, 10 May 2010 11:18:51 (GMT Daylight Time, UTC+01:00)
# Wednesday, 05 May 2010

Episode 85

In this show, David Isbitski and Matt Van Horn describe Behaviors, a feature that allows you to easily enhance the user interface of your Silverlight applications.

Wednesday, 05 May 2010 12:09:02 (GMT Daylight Time, UTC+01:00)

Microsoft Product Unit Manager Cameron Skinner came to the midwest to show off the Architecture features of Visual Studio 2010. He began his tour in the Detroit area, speaking at local companies in the afternoon and at the Great Lakes Area .Net User Group (GANG) in the evening. I recorded two of his presentations, which are available here.

Here is the presentation at GANG

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Here is the presentation at a Detroit-area company.

Part 1:

Part 2:

Part 3:

Part 4:

Wednesday, 05 May 2010 03:04:35 (GMT Daylight Time, UTC+01:00)
# Monday, 03 May 2010

Episode 84

In this interview, John Petersen describes how to use jQuery, JSON and Ajax to enhance an ASP.Net MVC application.

Monday, 03 May 2010 11:28:46 (GMT Daylight Time, UTC+01:00)
# Friday, 30 April 2010

I began reading Agile Principles, Patterns and Practices in C# by Robert C Martin and Micah Martin after a friend recommended the chapters on pair programming.  My friend was right, of course. The Martins not only decribed pair programming but included an entertaining script of two developers pairing on a programming problem.

But, as I dove deeper into this book, I found a wealth of other information.

The book begins with a section on agile development, defining some basic terms and concepts recommended practices. It follows with a detailed section on good design practice. This second section is the most interesting, as it describes the famous SOLID principles. SOLID is an acronym for a set of good design practices:

S=Single Responsibility Principle: Each class should serve only one purpose and have only one reason to change.
O=Open-Close Principle: Classes should be open for extension but closed for modification
L=Liskov Substitution Principle: It should always be possible to substitute a derived class with its base class
I=Interface Segregation Principle: Interfaces implemented by a class are defined by the client objects that use that class; a class should implement a separate interface for each client that calls it.
D=Dependency Inversion Principle: To maintain flexibility, you should write code that depends on abstractions, such as interfaces.

Next, the authors present an overview of Unified Markup Language (UML), a graphical language used to describe software designs and requirements. Common UML diagrams and shapes are described and the author offers opinions of which ones are most useful and when to best use them.

The last half of the book is a case study of a Payroll System in which the authors use examples to illustrate the concepts introduced in the first half of the book.

Although C# is included in the title, the book does not focus on C# and almost none of the concepts are specific to any particular language. All the code examples are in C#, which makes it a bit more accessible if that is your strongest language.

The book is filled with lots of information and good advice. For example, the authors recommend an iterative approach to writing software, a test-first approach to development and encourage developers to refactoring their code frequently.

Whether you read all of Agile Principles, Patterns and Practices in C# or pick through the sections of interest, you will benefit from this book.

Friday, 30 April 2010 19:41:42 (GMT Daylight Time, UTC+01:00)
# Monday, 26 April 2010

Episode 83

In this interview, Eric Greene describes the advantages of using a Content Management System to rapidly build a flexible web site

Monday, 26 April 2010 16:02:50 (GMT Daylight Time, UTC+01:00)