There was a period of time that I was really into the game show Jeopardy!

I even had aspirations of becoming a contestant on the show, but alas it hasn't happened yet. But I did some research, and tried to figure out the best way to study/practice.

One of the best ways to practice is to actually play along with episodes of the show. Karl Coryat, a contestant on the show in 1996, came up with a way that you can practice at home and track how well you are doing. I started doing this, but it was somewhat tedious to do it with pen/paper or even an Excel sheet, so I wrote a little HTML/JavaScript to do most of the tedious stuff for me.

You can check out my Coryat Scorekeeper now on Github. It's actually a pretty old piece of code at this point (it uses jQuery 1.4.0, which I believe was the latest release at the time I wrote it). It could probably use a fresh coat of paint (and an updated reference for the average Coryat score), but it's still functional!

I just open-sourced a tool that I wrote that I've been using internally at Zimbra (previously Telligent) for almost a year. It's an ugly little tool that I wrote out of frustration, but I've gotten so much use and time savings out of it that I thought I would share it. It's called SQL Profiler Query Cleaner.

SQL Profiler is a great tool to show you exactly what SQL is being executed, along with the parameters. This is especially useful when debugging, because sometimes you aren't sure what SQL is being executed. However, often times I will find myself having to pull that SQL+parameters out of SQL Profiler and paste it into SQL Server Studio in order to analyze, tweak, debug, etc. However, notce the output of SQL Profiler (bottom part of the screenshot):

The SQL string is there, but there are escaped characters. The parameters and arguments are there, but they're first declared, then assigned, "doubling" the syntax. It executes fine in SQL Studio, but if there's a syntax error, you can't really pinpoint exactly where in the query the error is, because you have to unescape the strings, manipulate the parameters (in two spots), and it's just time-consuming if you're doing this a lot (which I was).

So, fire up Sql Profiler Query Cleaner, paste the SQL Profiler output into the top text box, click the "Clean" button, and the bottom text box will have a more SQL Studio friendly query. I pasted the query from the above screenshot, and this is the result:

Please let me know if you find this useful. My guess is that if you use SQL Profiler a lot, this tool will save you some time.

Hello, again! "Weekly Concerns" is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• Pete Shearer from the Pete on Software podcast kindly invited me to be on his show so I could shamelessly plug AOP in .NET:
  • Episode 5 of the Pete on Software podcast
  • AOP with Matthew Groves blog post, from Pete's blog.
  • Pete also did an Intro to AOP with PostSharp blog post.
• "Pete, Pete, Pete, enough about Pete already!" Okay, okay.
• I was reminded again recently how bad I am with regular expressions and how much I don't like them. Well, I came across a "fluent" interface for regular expressions called VerbalExpressions. I haven't used it yet, but it's something to keep an eye on.
• These sorts of questions aren't common on Stack Overflow anymore, but check out the answers for Strangest Language Feature. There are some answers that I found very cool and some that were real head-scratchers. Not a lot of C# answers in there; I guess C# isn't a very strange language :)
• Another tool to help remote pair programming: go-pty-screen

Today I discovered a little trick with XAML binding while working on a Windows Phone 8 app.

Let's say you have a TextBlock, and its value is bound like so:

<TextBlock Text="{Binding MyInnuendo}" />

Which works fine, but suppose I want to add some additional text, formatting, etc, kinda like a string.Format? I guess you could just do that in a property on whatever model object you're binding to, but you can also do this:

<TextBlock Text="{Binding MyInnuendo, StringFormat='\{0\}, if you know what I mean'}" />

Now the extra text and formatting will show up. I just thought it was a nice little trick; I'll leave it up to you to decide if you should do it this way.

The principle of least surprise (sometimes known as the principle of least astonishment in more posh circles) is an axiom of design: typically UI design, but also software design. The idea is that some object, operation, device, etc, should be obvious and consistent with its name/appearance. A trivial example: a "left click" should be done by pushing the button farthest to the left on the mouse. To do otherwise would be quite surprising, and make for a bad experience. (That sounds shockingly simple, but it's just an example).

I was thinking about this when I was writing some validation code. I was thinking about a user selecting a U.S. State in a dropdown. On some forms, it's required for the user to select a State, on other forms it's optional.

I wrote a class to help me manage a list of States/Provinces like so:

Elsewhere, I wrote code to use the IsValidState method to check to see if the user, in fact, selected a valid state or not. The first time I did this, it was on a form where the field is required. So, if user doesn't select a state, then IsValidState wouldn't even get executed.

But, later on, I reused IsValidState on a form where the state field is optional. What happens when the state argument is null? A big fat exception, that's what. So, I changed the method:

Is that the correct decision? Or should IsValidState only be called when there's an actual value? I think I made the correct decision, because null isn't a State. Another decision that could be made is throwing an ArgumentException if the argument is null or empty. However, I don't think the correct decision was to leave the method the way it was.

So now let's enter the land of hypotheticals in order to think more about the principle of least surprise.

What if, instead of being a boolean function, IsValidState instead acted upon a StateArgs object being passed in (and its name was changed to ValidateState). Let's suppose there is some reason for this, and that part of the design is a given.  Suppose there's a Value string property with the State and an IsValid boolean property. (ASP.NET Validators, specifically CustomValidators, work like this: the validation method get an "args" object, and you can act upon it by manipulating args.IsValid). What would the correct behavior be then if args.Value is null? Clearly, args.IsValid shouldn't be set to true. So, should it be set to false, or should it just be left unchanged?

In this circumstance, ValidateState is probably one method call in a series of validation method calls (probably with some polymorphism involved with the parameter instead of a specific StateArgs class). So it seems like the least surprising thing to do would be to not make a decision (option A in the above source code). Since ValidateState does not return a value, it's not required to make a decision.