March 2009 - Posts

April's Toolbox Column Now Online
21 March 09 03:13 PM | Scott Mitchell

My Toolbox column in the April 2009 issue of MSDN Magazine is available online. The March issue of MSDN Magazine has a focus on the Web and my reviews in Toolbox follow suit and include:

  • The Microsoft Chart Controls - Did you know that Microsoft has released a free, robust set of charting controls for both WinForms and ASP.NET applications developed using the .NET Framework version 3.5? With this control suite you can add pie charts, line charts, bar graphs, and a host of other chart types to your .NET applications.
  • Snippet Designer - Visual Studio 2005 introduced code snippets, which are task-oriented blocks of code that can include replaceable regions. In a nutshell, a code snippet can be used to inject common code blocks, such as the stock code for sending an e-mail message, or the skeleton of a try/catch block. Unfortunately, Visual Studio does not include much in the way of tool support for building these code snippets. Snippet Designer, an open-source project hosted on, provides a straightforward user interface that integrates with the Visual Studio IDE and makes creating and editing snippets a much more intuitive and pleasant experience.
  • Blogs of Note - Sara Ford: Sara Ford is a Microsoft employee who, over the years, published 382 tips on getting the most out of Visual Studio. Her blog serves as a great resource of Visual Studio tricks and tips. Spend an afternoon pouring through her old blog entries, and I guarantee you that you'll learn a few new things about Visual Studio.

The Bookshelf section reviewed two books: More Effective C#, by Bill Wagner, and Refactoring SQL Applications by Stephane Faroult and Pascal L'Hermite. An excerpt of Effective C# follows:

More Effective C# assumes the reader is already familiar with C# and language features like generics, LINQ, multithreading, and so on. You won't find any discussions on what generics are or the syntax for lambda expressions. Instead, the book states a specific guideline, such as "Distinguish between IEnumerable and IQueryable data sources," and then provides a deep and detailed discussion on the why of the guideline with illuminating prose and helpful code snippets. And each guideline stands on its own and can be read and digested without having first read other guidelines, meaning that you can jump around to what guidelines interest you the most or are the most relevant for your current projects. ... More Effective C# is a must-read for experienced C# developers who are already familiar with C# language features such as generics, extension methods, lambda expressions, anonymous types, and LINQ, but who want guidance on how best to use these features.

Enjoy! -

As always, if you have any suggestions for products, blogs, or books to review for the Toolbox column, please send them to

Filed under:
Happy Pi Day
14 March 09 12:53 PM | Scott Mitchell

Our esteemed House of Representatives passed a resolution earlier this week, designating today - March 14th - National Pi Day. This is an American-centric 'holiday,' as we colloquially denote our dates in MM/DD format, hence March 14th is 3.14, the first three digits of Pi. Most other countries start with the least significant date part and work their way to the most significant - DD/MM/YY - which would mean the International Pi Day should fall on the 3rd day of the 14th month (hrm) or the 31st day of the 4th month, i.e., April 31st (hrm, again). Of course, God-fearing computer scientists denote dates from the most significant to the least, always using four digits for the year - YYYY/MM/DD - which would place Computer Scientist Pi Day on May 9th, 3141 if you were being flexible on parsing the month and day and allowing either one or two characters.

As we all learned in elementary school, Pi is the ratio between the area of a circle and its radius, squared, or the ratio between the circle's circumference and its diameter, and approximates 3.14159. One of the shortcomings of mathematical education in our schools is that math is initially introduced in a way that suggests that its rules and results are handed down by some oracle. Furthermore, children are taught that learning math involves mindless memorization. I think this turns a lot of kids against math; they end up thinking that it's some stuffy, boring pursuit that is of little interest. But there are interesting ways to present math, and ways in which the child discovers first hand why certain things are the way they are. And explaining why Pi approximates 3.14159 is a great example of a more involved and interactive form of math education.

My daughter is 6 months old, but one day I plan on sharing the following math discovery with her. I don't know when this would be age appropriate. The first part - computing Pi as a ratio of the circumference and diameter - only requires understanding of division, and I imagine it could be introduced around age seven or eight. The second 'experiment' involves areas and necessitates understanding exponentiation and square roots, and would probably have to wait until age 10, or so.

Start by drawing some circles (with a compass) and talking about the components of the circle - the circumference, the area, the radius, the diameter. It's pretty clear that there's some relationship between these components. A bigger radius means a larger area and a longer circumference. Next, get out some string and measure some of the circles' circumferences. It becomes clear that a circle with twice the radius has twice the circumference. But given just the radius, can one arrive at the circumference? There is some missing number that we need to arrive at this, and this can be approximated empirically: using the string, measure out the circumference for a circle and then hold the string up to a ruler. Divide this measurement by the diameter and you should arrive at a value that approximates Pi. Using this newly discovered number, tackle the problem the other way around - starting from a known diameter, what should the circumference be? Compute it, then measure it with the string and see how the values align.

Can we devise some ratio between the radius and the area? When in doubt, get out the graph paper! Start by deciding on a radius and then determine what points on the graph paper are bounded by a circle with said radius. I'm not sure the best way to explain this to the pupil in a way that isn't along the lines of, "This is the way it is," but the square at coordinates (x,y) on the graph paper is bounded by the circle if the square root of x2 + y2 is less than or equal to the radius. Using that knowledge, visit each square on the graph paper and apply the formula. If the square root is indeed less than x2 + y2 then shade in the square, otherwise leave it empty. After enumerating the squares, count up the shaded ones and divide that total by the radius squared. And, lo!, the result is eerily similar to the number we were getting when dividing the circumference by the diameter. Repeat the graph paper process a couple times with larger radiuses. As the radius gets larger, the area is computed more accurately as the edges of the circle are less jagged. Consequently, the ratio of the area and the radius gets more and more refined and close to the true value of Pi.

And if my daughter enjoys computers and likes spending time giving them instructions (fingers crossed), the final part of the lesson would be to have the computer do the grunt work for us. Why spend all afternoon shading in graph paper squares when a computer can shade in millions of squares for us in seconds? Here's a snippet of C# that approximates Pi.

const int r = 10;

int A = 0;

for (int x = -r; x < r; x++)

for (int y = -r; y < r; y++)

if (Math.Sqrt(x * x + y * y) <= r)


Console.WriteLine("Enjoy a slice of {0}", Convert.ToDouble(A) / Convert.ToDouble(r * r));

You can adjust the value of r to see how the approximation becomes more refined. For example, when r = 10 the approximation is 3.15. With r = 100 it's 3.1415. Of course, too large of a radius results in an overflow, which is a great segue into a discussion on how computers represent numbers!

Filed under:
Computer Science Is All About Tradeoffs
13 March 09 10:37 PM | Scott Mitchell

I oftentimes have a student or client remark, “I love how technology X does Y! However, I don't like X because it does Z.”

I don't know what else to say other than, “Ok,” or “I concur,” because after all, that's what computer science, and perhaps all of engineering, is all about - tradeoffs. There is no silver bullet. There is no panacea. Solutions are created to solve a specific problem, but the solution has shortcomings or deficits in other areas. That's life as a software developer.

If there were a silver bullet, if some technology existed that solved all the problems with no shortcomings elsewhere, we'd all be out of a job.

Filed under: ,
Daylight Savings and ASP.NET Fun Fact
08 March 09 08:24 AM | Scott Mitchell

Today marked the start of Daylight Saving Time (DST), the day of the year with the most missed airline flights.1 There's an esoteric ASP.NET issue that centers around Daylight Savings, and affects websites both at the very start of Daylight Savings and at the very end. ASP.NET's forms authentication feature assigns a forms authentication ticket to a user once they sign in, with the ticket serving as an identity token. This ticket is, by default, stored as a cookie on the user's browser and is sent back to the web server on each subsequent request to the site until it expires. The ticket's expiry is specified both in the Set-Cookie header and within the ticket itself. The expiry specified within the contents of the ticket is an absolute time that the ticket expires in terms of the web server's time zone. Can you see the problem? When DST starts or ends the expiry in the ticket remains constant, but the web server's clock is shifted. For a person signing on right near the start or end of DST, the the ticket is either rendered expired an hour earlier than expected or an hour later than expected.

I describe this issue in Forms Authentication Configuration and Advanced Topics, one of the tutorials in my Website Security Tutorials series:

The expiry stored in the authentication ticket is an absolute date and time value, like “August 2, 2008 11:34 AM.” Moreover, the date and time are relative to the web server’s local time. This design decision can have some interesting side effects around Daylight Saving Time (DST), which is when clocks in the United States are moved ahead one hour (assuming the web server is hosted in a locale where Daylight Saving Time is observed). Consider what would happen for an ASP.NET website with a 30 minute expiry near the time that DST begins (which is at 2:00 AM). Imagine a visitor signs on to the site on March 11, 2008 at 1:55 AM. This would generate a forms authentication ticket that expires at March 11, 2008 at 2:25 AM (30 minutes in the future). However, once 2:00 AM rolls around, the clock jumps to 3:00 AM because of DST. When the user loads a new page six minutes after signing in (at 3:01 AM), the FormsAuthenticationModule notes that the ticket has expired and redirects the user to the login page. For a more thorough discussion on this and other authentication ticket timeout oddities, as well as workarounds, pick up a copy of Stefan Schackow’s Professional ASP.NET 2.0 Security, Membership, and Role Management (ISBN: 978-0-7645-9698-8).

Happy Programming!

[1] This is a total guess, but based on some emperical evidence from a sample size of one. Back in 2001 I would have missed a flight on the day Daylight Savings Time started had my girlfriend at the time (now my wife) had not called me that morning to ensure that I was aware of the time change.

Filed under:
Leo Tolstoy for Developers
04 March 09 07:52 AM | Scott Mitchell
All successful software projects resemble one another; each failed project fails in its own way.
Filed under: ,
What Johannes Kepler Can Teach Us About Debugging
01 March 09 02:59 PM | Scott Mitchell

Debugging code is a lot like the scientific method. Most importantly, both involve careful measurements and analysis of the resulting data. Be wary of the developer who is quick to announce the cause of an error. When an error occurs, a developer's first thought should be, "What data to I need to collect to better understand and analyze this error?" A less experienced developer is one whose first thought is, "Maybe the cause of the problem is (the database query|session timeout issues|invalid user input|etc.)?" This latter approach leads the developer down a series of dark alleys, many of which are dead ends.

Another important component of debugging and science are control groups and experimental groups. For the results of a scientific experiment to be sound, the researcher must have a control group that is not experimented upon, and an experimental group that differs from the control group by only one variable, namely by the "thing" that is being tested. In debugging, constructing the control group involves reproducing the error. If the QA department reports that an error occurs when entering a value longer than 50 characters into the Billing Address textbox on CheckOut.aspx, the first step in debugging is to visit CheckOut.aspx and enter an input longer than 50 characters into the Billing Address textbox to ensure that the reported error occurs. Likewise, the same steps should be repeated after the bug is fixed to help ensure that the fix has indeed solved the problem at hand.

Additionally, when debugging the practitioner must be careful not to taint the observations with his own preconceived notions or bias. The history of science is littered with examples of scientists who knowingly or unwittingly let their personal beliefs or the current societal mores color the data and influence their analysis. Johannes Kepler, the famous German mathematician and astrologer who penned the three laws of planetary motion, is a great example. Kepler started his astronomical career by using astronomical measurements to describe the motion of planets in our solar system. Although Kepler subscribed to Corpernicus's heliocentric model - that the sun was the center of the solar system rather than the Earth - he held to a rather convoluted theory that the planets orbited the sun based on different 3-dimensional polyhedra according to the Platonic solids. Kepler's problem was, in part, that he was approaching the problem backwards. Rather than taking the data at his disposal and asking, "What arrangement of the sun and planets would most sensibly explain these astronomical observations," he asked, "Can I construct a model that fits with the observations yet still maintains a semblance to the work done by the ancient Greeks and upholds my personal theological beliefs?" Fortunately, Kepler eventually abandoned his initial forays and came upon the a much simpler and, more importantly, a correct theory that proposed elliptical orbital paths with the sun as a focus.

A developer can fall victim to biasing observational data just as easily as Kepler did. A developer might be accustomed to bugs originating from a particular module, or from the code of a particular coworker. While such information is useful when deciding what data to collect, it is important to not let these preconceived notions influence the analysis of the data. While it may be mathematically probable that a particular error originated from a certain buggy module, don't ignore data that would suggest otherwise.

A corollary to Kepler's story is Occam's razor: that the simplest hypothesis is usually the correct one. If you find that you need to concoct an elaborate and complex scenario to explain the cause of the error, chances are you're barking up the wrong tree. More briefly, don't think too hard.

All this being said, debugging and science involves more than the mechanical process of gathering data and methodically interpreting it. There is an art form to the practice, and a certain wiliness and level of insightfulness that comes with much practice. But don't forget that the overwhelming bulk of any successful debugging session or any successful scientific experiment is keen measurement and straightforward, analytical interpretation of the data.

Filed under:
More Posts


My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.