"The Lords of Finance" includes a story about famous economist John Maynard Keynes, who was diagnosed with a chronic cardiac condition and needed medical help*.

In 1939, he fell into the hands of a Dr. Janos Plesch, a Hungarian Jewish émigré, who, according to Keynes, was a cross between a “genius” and a “quack.” In addition to some highly unorthodox protocols—three-hour sessions of ice packs placed on the chest or Dr. Plesch jumping up and down on his patient as he lay in bed...

Jumping up and down on the patient? At least Keynes suspected his doctor was a quack, but once you realize this was only 80 years ago you also begin to realize that medicine spent dozens of centuries treating patients using blood letting and other techniques based on beliefs, faiths, and superstitions.

Overall I think software has done far more good than harm, but I do wonder how long it will take us to figure out programming once and for all, or if we ever will. A lot of our practices today are based on hard won experiences, but we all carry our own beliefs, faiths, and superstitions (and thus the opportunity for technology evangelism). 

* Fascinating book, particularly if you are interested in a human story involving macro economics, gold bullion, and fiat money.

Here is some code similar to other code I've seen that has a severe bug. The Entity Framework model configuration is setup to allow optimistic concurrency checks via a movie's Version property.

public class Movie
{
    public virtual int ID { get; set; }
    public virtual string Title { get; set; }
    public byte[] Version { get; set; }
}

public class MovieDB : DbContext
{
    public DbSet<Movie> Movies { get; set; }

    protected override void OnModelCreating(
        DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Movie>()
                    .Property(p => p.Version)
                    .IsRowVersion();
        base.OnModelCreating(modelBuilder);
    }
}

During editing, the view correctly holds the row version in a hidden input.

@Html.HiddenFor(model => model.Version)

But unfortunately, the controller action accepting the edit request has a flaw. It's trying to retrieve the existing movie from the database, overwrite the entity with new values (and the previously retrieved version value), then save the entity. The idea is that if the underlying record changed, we'll see an optimistic concurrency exception because we gave the entity an old row version value.

[HttpPost]
public ActionResult Edit(int id, Movie editedMovie)
{
    if (ModelState.IsValid)
    {
        var movie = db.Movies.Find(id);
        movie.Title = editedMovie.Title;
        movie.Version = editedMovie.Version;       
        db.SaveChanges();
        return RedirectToAction("Index");
    }
    return View(editedMovie);
}

The update will almost never fail with an OptimisticConcurrencyException. The update will almost always overwrite the current record in the database*.

What's wrong?

Hint: the Entity Framework doesn't behave like the implementation expects.

Answer

A property marked as a RowVersion property implicitly holds a  "store-generated" value. The Entity Framework never expects an application to modify the value. When you retrieve an entity and set a computed property to a new value, you'll still see the original value sent to the database when you call SaveChanges. The Entity Framework will always use the original value loaded from the database. The correct way to save the new values is to "attach" the movie instead of using a query to retrieve values from the database.

[HttpPost]
public ActionResult Edit(Movie editedMovie)
{
    if (ModelState.IsValid)
    {
        db.Entry(editedMovie).State = EntityState.Modified;
        db.SaveChanges();
        return RedirectToAction("Index");
    }
    return View(editedMovie);
}

* I say "almost" because you could have a concurrency exception if the data changes between the query and the call to SaveChanges (where time is measured in milliseconds). It doesn't fail if the data changes between the Edit GET request and the POST request (where time might be measured in minutes).

Continuing from the previous post about MapReduce with MongoDB, we can clean up the code a bit using an extension method that takes a single string parameter.

var db = server.GetDatabase("mytest");
var collection = db.GetCollection("movies");
var results = collection.MapReduce("CategorySummary");

foreach (var result in results.GetResults())
{
    Console.WriteLine(result.ToJson());
}

The code no longer needs to embed JavaScript into the C# code, or specify the map reduce options. Instead, the "CategorySummary" parameter tells the extension method everything it needs to know.

First, it can load the map, reduce, and finalize functions from JavaScript files on the file system using the parameter to build the path to the files. Keeping the script code in .js files makes the functions easier to author, maintain, and test.

Secondly, it can automatically build output options and will assume you want to send the MapReduce results to an output collection using the same name. The code looks a bit like the following:

public static class MapReduceExtensions
{
    public static MapReduceResult MapReduce(
        this MongoCollection collection, 
        string name)
    {
        var options = new MapReduceOptionsBuilder();
        options.SetOutput(name);            
        if(FinalizeExists(name))
        {
            options.SetFinalize(ReadFinalizeFile(name));
        }
        return collection.MapReduce(ReadMapFile(name), 
                                    ReadReduceFile(name), 
                                    options);
    }

    static string ReadMapFile(string name)
    {
        return File.ReadAllText(Path.Combine(ROOTDIR, name, "map.js"));
    }

    // ......

    static bool FinalizeExists(string name)
    {
        return File.Exists(Path.Combine(ROOTDIR, name, "finalize.js"));
    }

    private static string ROOTDIR = "mapreduce";
}

The idea is to make things like MapReduce as easy as possible by hiding some infrastructure, and applying easy to learn conventions.

It's been my observation that the worst architectural decisions are made when technical people meet by themselves in a room with a whiteboard. I'm not saying the decisions are always bad, or wrong, but the plans and rules that come back to bite you consistently seem to incubate under these conditions.

I first witnessed this early in my career when "the architect" would fly into town for two days every few weeks and diagram the architecture for the upcoming application on a whiteboard. Then the architect would fly out of town and developers would fire up IDEs to implement the architecture. I'm ashamed to say that I had no idea at the time just how utterly insane the process was that we were involved with.

I'm happy to say I've never seen malpractice on such a grand scale in many, many years. However, from time to time I still find myself in a room full of developers and a whiteboard. It's sometimes hard to keep the conversation grounded and not solve problems that don't exist, or devise rules that offer no practical benefit. For example, a rule about how to divide the solution for a new application into umpteen projects before the first line of code is checked in.

I think there are two strategies to avoid architectural flights of fancy. One strategy is to keep a business person in the room. The business person can help a team focus on the real problem to solve, and avoid trying to solve problems that don't exist. The second strategy is bring up application code, and even do some group programming to flesh out details. If the problem doesn't lend itself to group programming, it might be time to let one or two people go off on a spike and bring back some code to evaluate.

Without something tangible and real in the room, it's easy to succumb to the dark side.

The jQuery UI slider widget doesn't display it's current value by default. However, you can tap into the slide event and grab the current value from the second parameter passed to the event handler. The second parameter in a jQuery UI event handler is typically named ui, and always contains some useful information about the state of the widget.

$(function () {
    var ageInput = $("#ageInput");
    var ageDisplay = $("#ageInput > div");

    var updateSliderValue = function (event, ui) {
        ageDisplay.text(ui.value);
    };

    ageInput.slider({
        min: 0, max: 122,
        slide: updateSliderValue
    });        
});

You can also position the display of the value above the slider handle / thumb. The DOM element representing the slider thumb is passed in the ui parameter as the handle property.

var updateSliderValue = function (event, ui) {
    ageDisplay.text(ui.value)
              .css($(ui.handle).position());
};

Having the value display immediately (before the user starts dragging and the slide event fires) is a bit trickier. A complete example with one possible solution is available on jsFiddle.

One reason some people don't like JavaScript, I think, is because idiomatic JavaScript favors fewer keystrokes and CPU cycles over readability. There is a large amount of script code that is hard to read, and even harder to maintain and change.

Take, for example, the following snippet. I think this represents a typical DOM ready event handler with jQuery.

$(function () {
    $("#warning").dialog({ autoOpen: true });
    $("#openDialog").click(function () {
        $("#warning").dialog("open");
    });
    $("#submit").click(function () {
        $("#warning").dialog("close");
    });
    $("#names").autocomplete({
        source: ["Foo", "Bar", "Baz"] 
    });
});

It's a wall of text written in the get in, get done, and get out style. The code requires some concentration to see what is happening inside.

I think the code improves after lifting out the nested, anonymous functions.

$(function () {
    var warning = $("#warning");

    var openDialog = function () {
        warning.dialog("open");
    };

    var closeDialog = function () {
        warning.dialog("close");
    };

    warning.dialog({ autoOpen: false });   
    $("#openDialog").click(openDialog);    
    $("#submit").click(closeDialog);       
    $("#names").autocomplete({
        source: ["Foo", "Bar", "Baz"] 
    });            
});

And to take the idea one step further, here is a pattern I'm going to try and follow over the next few weeks: initialize, implement, act. 

$(function () {

    var warningDialog = $("#warning");
    var openButton = $("#openDialog");
    var submitButton = $("#submit");
    var nameInput = $("#names");
    var inputValues = ["Foo", "Bar", "Baz"];

    var openDialog = function () {
        warningDialog.dialog("open");
    };

    var closeDialog = function () {
        warningDialog.dialog("close");
    };

    warningDialog.dialog({
        autoOpen: false
    });
    nameInput.autocomplete({
        source: inputValues
    });
    openButton.click(openDialog);
    submitButton.click(closeDialog);
    
});

The initialize section initializes variables, and tries to lift as many selectors as possible out of the code that follows. The implement section contains functions and other implementation details for the behavior of a page. The act section is the place for wiring up event handlers, creating widgets, and kickoff any data binding for the page.

The end result is verbose, but I've already found it easier to read and change as the requirements shift.

Thoughts?

The idea is to use an image as a "command button". When the user clicks on the image, the image greys out and acts disabled for a period of time. The image slowly transitions back to an enabled state by letting color sweep around itself in a clock-like manner. 

There are hundreds of approaches you could use to implement the effect. My initial attempt used a single image and pixel manipulation in a canvas.  I need to give credit to David Catuhe (blog, @deltakosh) for giving me the idea of using two images and a canvas. One image has color, and one image is in black and white. Selectively drawing the images into a canvas element can achieve the smooth "World of Warcraft cool down" effect, and the code is simple. David, by the way, is one of the many people I met last year who work for Microsoft France and who were all wonderfully friendly and smart. Fond memories!

Try it out on jsFiddle.