My friend Mark Greenway introduced me to Brandoo WordPress recently. I had never heard of it, so I thought I would share with you.

I've heard of WordPress, of course. I taught a class where all the labs used WordPress on Azure for three semesters at Capital University. Brandoo WordPress is a branch of WordPress that is designed with Windows Azure in mind. It uses a Microsoft SQL/Azure SQL database instead of MySQL. And, best of all, it's available in the Windows Azure gallery for an easy install.

Why would you want to use Brandoo instead of plain WordPress? On Azure, MySQL is available through ClearDb. Although my experience with plain WordPress and ClearDb has been pretty good, Azure SQL is a first-class citizen of Azure, with built-in scaling and tooling right through the Azure dashboard.

It does appear as though the Brandoo installation through the Azure gallery is a slightly older release of WordPress. But since WordPress has a self-updating feature built in, that's not really much of an issue.

So, if you use Azure and WordPress, consider giving Brandoo a shot.

Welcome to another "Weekly Concerns". This 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.

• Tainted Love as played on 13 noisy floppy and 1 hard disk drives.
• ConduitJS is a "targeted AOP" framework for JavaScript
• Couldn't get enough Pete last week, eh? He wrote another blog post about Parameter Checking with Postsharp
• Check out this book on the Mikado Method of refactoring. I'm not familiar with it yet, but looks interesting.
• Using RealProxy for AOP

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

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.

With my expanded focus, I decided to bring back my weekly link collection under the "Weekly Concerns" banner. Once again, this is just an excuse to avoid the work of having to write a real post.

• "using you're type's good by Gary Bernhardt" - a lightning talk from CodeMash 2014. Not quite as good as Wat (from CodeMash 2012), but still a very good piece of entertainment for developers.
• A news report from 1981 about the internet. Did you know that in the future you may read your newspaper ON YOUR COMPUTER!? "We aren't going to lose a lot [of money]..." Oh, you poor fool.
• An article about refactoring that I think demonstrates "sawtooth code" well
• Some code on-screen in an episode of Airwolf had a bug in it. Why do I know this? Internet.
• I recently moved this site to Windows Azure. This is the first site on Azure I ever had to move out of the "free" plan (since I'm using a custom domain name). I find this calculator to be very helpful when estimating what I'll be paying.

Maybe this series will turn into an Every-Other-Weekly Concerns?

• The Ruby Rogues podcast discussed AOP in a recent episode (episode 46). It's a good idea to listen to the whole podcast for context, but they don't really start discussing AOP directly until about 28 minutes in.
• The proxy/decorator pattern gives some of the same benefits that AOP can give you. Derick Bailey blogged about using proxies and decorators in JavaScript.
• A couple of white papers for you:
• FeatureC++ and AOP - What's feature-oriented programming?
• AOP is Quantification and Obliviousness - "obliviousness" often has a negative connotation, but I believe AOP in a team setting on a properly architected application can free up developers to concentrate on adding business value without having function requirements slowing them down

That's it for this week. Have a great weekend.