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.

• Give Spritz a try. I was able to read surprisingly fast, and I also felt like I was concentrating more and therefore retaining more of what I was reading.
• C# Pad, a web-based C# REPL.
• REPL means "Read-eval-print loop", by the way.
• Check out what's new with JustMock, JustCode, and JustTrace from Telerik
• Interesting posts from Rob Conery on UnitOfWork and Jimmy Bogard on Query Objects

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

Even though I've been using Windows Azure for quite some time, a lot of the functionality is unexplored territory to me.

Recently, I took a look at Azure Blob Storage, and I was surprised by how simple it was.

Blob storage is simply a way to store stuff (mainly files). That's about the long and short of it. Here's how to get started:

1. Create a new storage service: on your dashboard, click "+ NEW", then Data Services, then Storage. Pick a URL subdomain, region, and subscription. There you go.
2. In that service, create one or more containers. This is basically an organizational structure, kinda like a folder. Containers can be public or private.
3. Put stuff in the container. Each item of "stuff" in this container is called a blob, and each of these items have their own URL.

I don't know of a way to directly upload blobs right from the Azure control panel (yet), but it's very simple to do with some C#. Just add Windows Azure Storage to your project with NuGet (Install-Package WindowsAzure.Storage).

You'll need to create a "connection string" to your storage service. The connection string is just:

DefaultEndpointsProtocol=https;AccountName=yourServiceName;AccountKey=yourAccountKey

Where yourServiceName is whatever your named your service. yourAccountKey can be grabbed right from your Azure Dashboard. Click on the service name and then click "Manage Access Keys" at the bottom of the screen. Copy "Primary Access Key" and paste it in there.

Now you're ready to write some C#. Here's a simple class that I wrote that lets you check for existence of a blob (by name), upload a new blob given a name and a stream (from a file uploaded to a web site, for instance), and a way to delete a blob (again, by name).

It's really that simple. Once you upload some files, go back to your Azure Dashboard and take a peek in the container. You'll see all the blobs there, as well as URIs to get to them.

It's so easy, that I've already moved the images for this site (Cross Cutting Concerns) over to Azure Storage (previously I was storing them off-site with traditional hosting).

Some drawbacks that I've noticed, and how I dealt with them:

• You can get a List of blobs using WindowsAzure.Storage, but you can't really get a total count (at least not without iterating through the whole list). So if you are building a tool to manage these blobs, you may need to store some metadata (like name, uri) in a local database or something (which is what I did for this site). I believe there are already a bunch of tools out there to access containers/blobs that you can use as well: you don't have to build your own.
• There's no "transaction" or "rollback" when doing blob transactions. You'll need to handle that case yourself. In my case, if something goes wrong with other parts of the "transaction", I'll use DeleteIfExists to remove the blob. Not the most elegant, but it works.

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.

It's Seth Petry-Johnson's birthday this weekend. That doesn't really tie into this week's Weekly Concerns, but I guess you could check out Seth's blog! It will also be David Giard's birthday as well: you should check out his excellent Technology and Friends podcast/TV show. Episode 144 is particularly good.

• If you've played around with game system emulators, you might be familiar with some of the image scaling filters meant to enhance pixel art. Microsoft has developed their own image scaling algorithm which yields surprisingly good results. They've even set up a comparison page with competitive image scaling techniques.
• #1014 of 2000 things you should know about C# - using the default operator in a generic class.
• Deploying an Azure Website and WebJob via Git, from Mark Greenway
• How to specify a Webpage Icon for for Web Clip - defining an apple-touch-icon in your markup.

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.

I've been working a little bit here and there on a mobile app. One thing this app does a lot is use a RESTful API over HTTP, where the results are JSON.

I'm using RestSharp to handle these requests, and RestSharp can automatically serialize Json results into C# object(s), assuming I have C# objects that match.

Well, some of these JSON results can be a little complex. Not terribly complex, mind you, but enough to where it's annoying to create the classes myself. But I thought to myself, maybe there's a tool out there that already does this for me. I googled around and found json2csharp, which is a handy web app that does exactly that.

Well, thanks to Rob Gibbens, I now know that this feature is actually built-in to Visual Studio 2013, and available for 2012 as part of "ASP.NET and Web Tools".

You can see that there are some differences, but these tools get you most of the way there!