OdeToCode.com now runs on Windows Azure.

Once the decision was made to move, the first effort was investigating how to move the OdeToCode database from SQL Server 2008 to an Azure SQL Database.  At this moment in time, Azure SQL databases have most of the same features as regular SQL Server databases with one notable exception: there is no ability to run BACKUP or RESTORE commands. However, there are at least 5 different options for moving a database to Azure listed in the Microsoft documentation, as well as a few third party tools.

The first recommended option in the Microsoft documentation is to use the "Generate Scripts" option of SQL Server Management Studio. Since this option only migrates the database schema (no data), I didn't give it a try.

The second option is to use the Microsoft Sync Framework. Since I wasn't interested in setting up a long term synchronization capabilities, I didn't give this option a try, either.

The third option is to use SQL Management Studio to "Export a Data-tier Application". This option looked promising because it is similar to a backup and restore operation. The Export operation creates a BACPAC file, which you can place into Azure blob storage to import into a new Azure SQL database. Setup is simple and just requires right-clicking on a database in SQL Server Management Studio and finding the export option under the Tasks menu.

Unfortunately, I was never able to export my local database because of the following error: "statements in user dbo's definition cannot be deployed". Since the dbo user is a special user in SQL Server, there are no options to change or recreate the dbo user, or at least no options I could discover. The OdeToCode database was originally a SQL Server 2000 database, and perhaps there are some legacy pieces the export routine cannot cope with. I'll also mention that once the database made it to Azure, it was simple to export the Azure database and import locally.

After failing with BACPAC I tried the fourth option of using SQL Server Integration Services. I should mention that I have a history with SSIS dating back to 2005.  Most of the history is filled with tears and gnashing of teeth, but I was willing to give SSIS another try in 2012. I gave up after 3 failed attempts. SSIS continues to be on my list of things to avoid unless I'm under extreme duress (it goes on the list after the vegetable celery, but before Philadelphia International Airport).

Success!

Just moments away from writing a one-time custom import/export, I tried the fifth and final option of downloading the "SQL Database Migration Wizard". Be careful with the big, purple "Download" link on Codeplex, because the default download is (currently) v3.9, which requires SQL Server 2008 bits. I had to hunt around in the downloads area to find v4, which works when you only have SQL 2012 bits installed.

The SQL Database Migration Wizard isn't the prettiest application in the world, but it has three endearing qualities:

1) It works

2) It's simple

3) It works

The tool generates all the SQL scripts needed to recreate a database, and uses the SQL bulk copy (bcp) tool to export and import data (creating one .bcp file per table). The end result was a working Azure SQL database for OdeToCode.com to use.

Summary

BACPAC might be the path for the future, but BACPAC exports only seem to work with fresh, new databases. The SQL Database Migration Wizard on CodePlex is a solid tool that works with new databases as well as legacy, quirky databases.

Three cheers for community tools!

In the .NET Rocks show on "What Developers Should Care About in 2013" I mentioned Bootstrap – an open source frontend web framework from developers at Twitter. 

Here are some additional thoughts on Bootstrap to describe what Bootstrap is, as well as arguments for and against using the framework.

What Is Bootstrap?

Ultimately, Bootstrap gives you CSS and JavaScript to control the presentation of content in HTML. Bootstrap provides the default settings for typography, tables, forms, and buttons. Bootstrap also provides  components (navigation bars, pagers, and progress bars) as well as scriptable widgets (tooltips, tabs, and picture carousels), to name just a few things.

Since Bootstrap is all CSS and JavaScript you can use Bootstrap with any server technology or development environment. The idea behind Bootstrap is to get a site up and running quickly with a good looking and visually consistent interface.

Arguments Against Bootstrap

There is an inherent usability in the familiar and mundane, but some web designers will feel Bootstrap's sense of style is a little too familiar, and a little too mundane. These designers would rather start from scratch than start building another web site that looks "Bootstrappy".

One thing to keep in mind is that Bootstrap is not a "theme". Bootstrap is a framework. If you accept all of the defaults you'll build yet another Bootstrappy site. It takes a little bit of work to make a unique looking site, but building a unique look is certainly possible (take a look at Built With Bootstrap for inspiration). There are also now dozens of sites like Bootswatch (motto: saving the web from default Bootstrap)  where you can download colorful themes for Bootstrap.

There are also some limitations and quirks to Bootstrap, but like any framework if you follow the conventions and direction the framework wants you to follow, you'll have an easier time.

Arguments For Bootstrap

Here are three reasons I like Bootstrap:

1. Semantic class names. Building reusable components is a challenge in designing any kind of framework, and since Bootstrap is about style we want reusable style definitions. The classes provided by Bootstrap are meaningful without being specific about presentation details. For example, classes like warning, important, info, and alert all have an obvious meaning, but they don't give away any spoilers about the background colors they'll use. You can then use these Bootstrap classes in any application and even with heavy amounts of customization, the class names still make sense.  

2. Compositional classes. Another technique Bootstrap uses to achieve reusability is the use of composition. Similar to compositional design techniques in an object-oriented programming language, the style definitions provided by Bootstrap are small, focused, and designed to be combined together in interesting ways. For example, giving a span the class of "label" will allow you to present text inside an area that stands out a bit, but with a neutral background color. Giving a span a class of "label" and "label-important" will make the label text stand out (white text on a red background, by default). The "badge" classes are similar but provide rounded corners. Once you get the "feel" of how to combine Bootstrap classes, you'll find it is easy to build everything from alert messages to zebra striped tables with row hover effects.

3. The Grid. Grid layouts have been around for many years now, so it's almost unthinkable to have a framework without the ability to layout content in a grid. With Bootstrap you have fixed grids (using specific widths) or fluid grids (that expand and contract to the available space), and add in responsive design touches as well. More in the grid in a future post.

Why Do I Use It?

There are more reasons to like Bootstrap than just the three reasons I provided above. Ultimately, though, I like using Bootstrap because someone carefully designed a framework that is both re-usable, extensible, and provides sensible defaults.  If you haven't used a CSS framework before, 2013 would be a year to try one. If nothing else, you can learn how to better organize and design your own presentation rules.

You can build custom views for mobile devices in ASP.NET MVC 4 using the DisplayModeProvider features of the framework (see "Browser Specific Views" of the "ASP.NET MVC 4 Mobile Features" article for more details). The default view switching behavior happens by ultimately looking at the incoming user agent header to determine if the request came from a a mobile device, but display modes can do more than just peek at user agent strings.

Let's say we don't want a user agent or cookie to tell us which view to use. Instead, we want information in the path of the URL to tell us the view to use.

For example, the following URL should always use a "normal" view like Layout.cshtml:

/Home/About

And the next URL should always render a mobile view, like Layout.Mobile.cshtml, when a mobile view is available.

/Mobile/Home/About

Both URLs should go to the same controller action and we only want to influence the view selection. One possible solution to the problem is to have display modes and routing work together.

Routes & Display Modes

The first thing we'll do is register a new route before the default route. This "DefaultMobile" route will only match URLs starting with "mobile/". When the route does match it will add a mobile=true entry to the route data dictionary.

routes.MapRoute(
   name: "DefaultMobile",
   url: "mobile/{controller}/{action}/{id}",
   defaults: new
                 {
                     mobile = true,
                     controller = "Home",
                     action = "Index",
                     id = UrlParameter.Optional
                 }
);

Also during application startup, we'll modify the default "mobile" display mode to look at route data values instead of looking up device capabilities with the user agent string.

var mobileMode = DisplayModeProvider.Instance.Modes
                 .OfType<DefaultDisplayMode>()
                 .First(m => m.DisplayModeId == "Mobile");
                 
mobileMode.ContextCondition = ctx =>
    {
        var handler = ctx.Handler as MvcHandler;
        if(handler != null)
        {
            var routeData = handler.RequestContext.RouteData;
            return routeData.Values["mobile"] != null;
        }
        return false;
    };

This is all you need to have /Home/About use regular views, and have /Mobile/Home/About use a mobile view.

Good night, and good luck.

You Broke My Links!

Oh, right, you might notice that the following ActionLink will always generate a URL like /Mobile/Home/About, even when you are on a non-mobile view.

@Html.ActionLink("About", "About", "Home")

The ActionLink helper talks to the routing engine to figure out the URL needed to reach the About action of the Home controller. Since the "DefaultMobile" route we added to the route table is greedy and can reach any controller, it will happily respond to any ActionLink that just specifies controller, action, and optionally an ID.

We need to constrain the "DefaultMobile" route so it only gets involved in generating URLs when we are generating links during a "mobile" request.

Adding A Route Constraint

What follows is a route constraint that will only match a route when a given key (specified by parameterName) is in the route data dictionary.

public class RouteValuePresent : IRouteConstraint
{
    public bool Match(HttpContextBase httpContext,
                      Route route, string parameterName,
                      RouteValueDictionary values,
                      RouteDirection routeDirection)
    {
        if (values.ContainsKey(parameterName))
        {
            return true;
        }
        return false;
    }
}

We could also check the routeDirection parameter to only perform checks during link generation (RouteDirection.UrlGeneration), but the constraint also works for incoming request matching, too (since route data is already in place).

Now we just need to add the constraint to the "DefaultMobile" route we added earlier.

routes.MapRoute(
   name: "DefaultMobile",
   url: "mobile/{controller}/{action}/{id}",
   defaults: new
                 {
                     mobile = true,
                     controller = "Home",
                     action = "Index",
                     id = UrlParameter.Optional
                 },
    constraints: new { mobile = new RouteValuePresent() }
);

I'm sure there are other possible solutions, but I rather like the explicit route entry to know something magical happens when "mobile" is in the path.

I work in an industry obsessed with novelty, so it must be the contrarian in me that likes to see software last a long, long time.

OdeToCode.com started almost 10 years ago. Internally there were 2 different applications running the site, and over the years we made tweaks and added features, but most of the code was the same code from 10 years ago.

A couple weekends past I sat down to fix some performance problems and, in a fit of short-sightedness, ended up rewriting everything (except for the database) from scratch. The result is a leaner, meaner, single application that will be easier to move to an environment with more headroom, like Windows Azure. 

I hope I don't have to do that again for a long, long time.

Problem: A content heavy web site undergoes a massive reorganization. A dozen URL rewrite rules are added to issue permanent redirects and preserve permalinks across the two versions. The question is - will the rules really work?

Brute Force Approach: Take the last 7 days of web server logs, and write about 40 lines of C# code:

static void Main()
{
    var baseUrl = new Uri("http://localhost/");
    var files = Directory.GetFiles(@"..\..\Data", "*.log");

    Parallel.ForEach(files, file =>
        {
            var requests = File.ReadAllLines(file)
                .Where(line => !line.StartsWith("#"))
                .Select(line => line.Split(' '))
                .Select(parts => new
                                     {
                                         Url = parts[6],
                                         Status = parts[16],
                                         Verb = parts[5]
                                     })
                .Where(request => request.Verb == "GET" && 
                                  request.Status[0] != '4' &&
                                  request.Status[0] != '5');

            foreach (var request in requests)
            {
                try
                {
                    var client = new WebClient();
                    client.DownloadData(new Uri(baseUrl, request.Url));
                }
                catch (Exception ex)
                {
                    // .. log it (in a thread safe way)
                }
            }
        });
}            

The little console mode application isn't foolproof, but it did uncover a number of problems and edge cases. As a bonus, it also turned into a good workload generator for SQL Server index re-tuning.

"Why All The Lambdas?" is a question that comes up with ASP.NET MVC.

@Html.TextBoxFor(model => model.Rating)

Instead of lambdas, why don't we just pass a property value directly?

@Html.TextBoxFor(Model.Rating)

Aren't we simply trying to give a text input the value of the Rating property?

There is more going on here than meets the eye, so let's …

Start From The Top

If all we need is a text box with a value set to the Rating property, then all we need to do is write the following:

<input type="text" value="@Model.Rating" />

But, the input is missing an important attribute, the name attribute, which allows the browser to associate the value of the input with a name when it sends information back to the server for processing. In ASP.NET MVC we typically want the name of an input to match the name of a property or action parameter so model binding will work (we want the name Rating, in this case). The name is easy enough to add, but we need to remember to keep the name in synch if the property name ever changes.

<input type="text" value="@Model.Rating" name="Rating"/>

Creating the input manually isn't difficult, but there are still some open issues:

- If Model is null, the code will fail with an exception.

- We aren't providing any client side validation support.

- We have no ability to display an alternate value (like an erroneous value a user entered on a previous form submission – we want to redisplay the value, show an error message, and allow the user to fix simple typographical errors).

To address these scenarios we'd need to write some more code and use if statements each time we displayed a text input. Since we want to keep our views simple,we'll package up the code inside an HTML helper.

Without Lambdas

Custom HTML helpers are easy to create.  Let's start with a naïve helper to create a text input.

// this code demonstrates a point, don't use it
public static IHtmlString MyTextBox<T>(
    this HtmlHelper<T> helper, object value, string name)
{
    
    var builder = new TagBuilder("input");
    builder.MergeAttribute("type", "text");
    builder.MergeAttribute("name", name);
    builder.MergeAttribute("value", value.ToString());
    
    return  new HtmlString(
        builder.ToString(TagRenderMode.SelfClosing)
    );
}

The way you'd call the helper is to give it a value and a name:

@Html.MyTextBox(Model.Rating, "Rating")

There isn't much going on inside the helper, and the helper doesn't address any of the scenarios we thought about earlier. We'll still get an exception in the view if Model is null, so instead of forcing the view to give the helper a value (using Model.Rating), we'll instead have the view pass the name of the model property to use.

@Html.MyTextBox("Rating")

Now the helper itself can check for null models, so we don't need branching logic in the view.

// this code demonstrates a point, don't use it for real work
public static IHtmlString MyTextBox<T>(
    this HtmlHelper<T> helper, string propertyName)
{
    var builder = new TagBuilder("input");
    builder.MergeAttribute("type", "text");
    builder.MergeAttribute("name", propertyName);
 
    var model = helper.ViewData.Model;
    var value = "";

    if(model != null)
    {                
        var modelType = typeof(T);
        var propertyInfo = modelType.GetProperty(propertyName);
        var propertyValue = propertyInfo.GetValue(model);
        value = propertyValue.ToString();
    }
    
    builder.MergeAttribute("value", value);
 
    return new HtmlString(
        builder.ToString(TagRenderMode.SelfClosing)
    );
} 

The above helper is not only using the propertyName parameter to set the name of the input, but it also uses propertyName to dig a value out of the model using reflection. We can build robust and useful HTML helpers just by passing property names as strings (in fact many of the built-in helpers, like TextBox, accept string parameters to specify the property name). Giving the helper a piece of data (the property name) instead of giving the helper a raw value grants the helper more flexibility.

The problem is the string literal "Rating". Many people prefer strong typing, and this is where lambda expressions can help.

With Lambdas

Here is a new version of the helper using a lambda expression.

// this code demonstrates a point, don't use it for real work
public static IHtmlString MyTextBox<T>(
    this HtmlHelper<T> helper, 
    Func<T, object> propertyGetter,
    string propertyName)
{
    var builder = new TagBuilder("input");
    builder.MergeAttribute("type", "text");
    builder.MergeAttribute("name", propertyName);

    var value = "";
    var model = helper.ViewData.Model;
    
    if(model != null)
    {
        value = propertyGetter(model).ToString();
    }

    builder.MergeAttribute("value", value);

    return new HtmlString(
        builder.ToString(TagRenderMode.SelfClosing)
    );
}

Notice the reflection code is gone, because we can use the lambda expression to retrieve the property value at the appropriate time.  But look at how we use the helper in a view, and we'll see it is a step backwards.

@Html.MyTextBox(m => m.Rating, "Rating")

Yes, we have some strong typing, but we have to specify the property name as a string. Although the helper can use the lambda expression to retrieve a property value, the lambda doesn't give the helper any data to work with – just executable code. The helper doesn't know the name of the property the code is using. This is the point where Expression<T> is useful.

With Expressions

This version of the helper will wrap the incoming lambda with Expression<T>. The Expression<T> data type is magical. Instead of giving the helper executable code, an expression will force the C# compiler to give the helper a data structure that describes the code (my article on C# and LINQ describes this in more detail).

The HTML helper can use the data structure to find all sorts of interesting things, like the property name, and given the name it can get the value in different ways.

// this code demonstrates a point, don't use it for real work
public static IHtmlString MyTextBox<T, TResult>(
    this HtmlHelper<T> helper,
    Expression<Func<T, TResult>> expression)
{
    var builder = new TagBuilder("input");           
    builder.MergeAttribute("type", "text");
 
    // note – not always this simple
    var body = expression.Body as MemberExpression;
    var propertyName = body.Member.Name;           
    builder.MergeAttribute("name", propertyName);
 
    var value = "";
    var model = helper.ViewData.Model;
    if (model != null)
    {
        var modelType = typeof(T);
        var propertyInfo = modelType.GetProperty(propertyName);
        var propertyValue = propertyInfo.GetValue(model);
        value = propertyValue.ToString();
    }

    builder.MergeAttribute("value", value);
 
    return new HtmlString(
        builder.ToString(TagRenderMode.SelfClosing)
    );
}

The end result being the HTML helper gets enough information from the expression that all we need to do is pass a lambda to the helper:

@Html.MyTextBox(m => m.Rating)

Summary

The lambda expressions (of type Expression<T>) allow a view author to use strongly typed code, while giving an HTML helper all the data it needs to do the job.

Starting with the data inside the expression, an HTML helper can also check model state to redisplay invalid values, add attributes for client-side validation, and change the type of input (from text to number, for example) based on the property type and data annotations.

That's why all the lambdas.

Canvasfill is a demo for a friend who wants to flood fill a clicked area in an HTML 5 canvas.

A couple notes:

JavaScript loads a PNG image into the canvas when the page loads.

var img = new Image();
img.onload = function () {
    canvas.width = img.width;
    canvas.height = img.height;
    context.drawImage(this,0,0);
};
img.src = "thermometer_01.png";     

The image and the JavaScript must load from the same domain for the sample to work, otherwise you’ll run into security exceptions (unless you try to CORS enable the image, which doesn’t work everywhere).

The code uses a requestAnimationFrame polyfill from Paul Irish for efficient animations.

The code uses getImageData and putImageData to get and color a single pixel on each iteration.

image = context.getImageData(point.x, point.y, 1, 1);
var pixel = image.data;

This is not the most efficient approach to using the canvas, so if you need speed you’ll want to look at grabbing the entire array of pixels. With the current approach it is easier to “see” how the flood fill algorithm works since you can watch as pixels change colors in specific directions.

The flood fill algorithm itself is an extremely primitive queue-based (non-recursive) algorithm. It doesn’t deal well with anti-aliased images, for example, so you might need to look at more advanced algorithms if the image is not a blocky clip art image or a screen shot of Visual Studio 2012 with the default color scheme.