K. Scott Allen

Upcoming Events

K. Scott Allen — Mon, 08 Feb 2010 14:12:00 GMT

Here are some events I’ll be speaking at over the next couple months:

DevTeach

Toronto / Mississauga March 8-12. DevTeach stands for Developers Teaching. It’s a conference done by developers for developers. This annual event offers the elements of an international conference and the elements of a community event. Sessions include both presentation material and, whenever possible, hands-on training. We like to describe this event as the Developers Festival. Find out who should attend at this link. Check out the top ten ways to convince your boss to let you go this event. DevTeach is about becoming one of the best developer by getting training from the best in the industry.

Scandinavian Developer Conference

Göteborg, Sweden March 16-17. Whether you are someone learning development in Java, .NET or IBM i or you are an experienced user of these technologies for 10 years or more, there are lot of great information to be shared with everyone.

In addition to technical sessions, we will also have tracks with presentations about the Development Process and Methodology: Agile Methodology, Test Driven Development, System Engineering, Architecture, Project Management, Best practices, "Agile in the Organization". We will also have tracks about hot topics like Cloud Computing, Testing, Web Development and Mobile Solutions. At the Conference there will also be a track of Emerging Technologies presented in cooperation with ThoughtWorks ( www.thoughtworks.com )

DevDays 2010

DevDays is being held at World Forum in Den Haag March 30-31. DevDays 2010: the biggest Microsoft event in the Netherlands for software development and software architecture. Every year, thousands of professionals visit DevDays to get completely up-to-date with all recent developments in their area of expertise in two days.

DevConnections

Las Vegas April 12-14 2010. Developers from around the world will gather at the world famous Bellagio, for the Microsoft Visual Studio Conference & Expo, ASP.NET & Silverlight Conference & Expo and SQL Server Conference & Expo. You can be a part of this exciting event while you enjoy one of the most stunning hotels on the Las Vegas Strip at a great conference rate!

Thoughts on an MVVM Rant

K. Scott Allen — Tue, 02 Feb 2010 14:12:00 GMT

I stumbled across “A vent abount MVVM Development” thanks to a tweet from @peterbromberg. Excerpt:

What really irritates me is that I am forced to waste so much time on how to try and figure out how a complex User Interface will work together with a suitable "ViewModel" all for the sake of being more "testable". I could cobble together a pretty darn good application and still be able to split up the work among User Interface and code-behind developers. I think adopting a non-industry standard, seemingly "best practices" ideology just because it seems 'cool' and it's "there" is the wrong approach to application development

Ah, MVVM! MVVM is the rock star who packs the house at every XAML event. It’s in books, blog posts, and podcasts. You can’t swing a dead laptop without hitting someone who is spouting about the virtues of model-view-viewmodel. With so much hype, there’s bound to be backlash.

Does MVVM deserve the hype?

Short answer – no.

An Alternative?

You’ve got a complex UI with lots of rules, and you reject the MVVM best practice crap the whiteboarding architect is jamming down your throat. You’re gonna be … pragmatic!

void SaveButton_Click(object sender, RoutedEventArgs e)
{
   if(ThisIsValid)
   {
       if (ThatIsValid)
       {
           IsDragging = false;
        
           if (DraftCheckBox.IsChecked.HasValue &&
               DraftCheckBox.IsChecked == true &&
               ItemList.SelectedItem != null)
           {
               DragDropTarget.Children.Clear();
               SaveSomethingToWebServiceAsDraft();
           }
           else
           {
               DoSomethingElse();
               EmptyAllControls();
           }
       }
   }
}

Managing a complex UI by jamming code into event handlers results in something spectacular – as does throwing a bucket of water on a raging grease fire. Afterwards the fundamental problem of complexity (or fire) still exists – and it’s even worse than before!

Doesn’t MVVM Take Care of Complexity?

I’d argue that MVVM doesn’t solve the complexity problem by itself. Neither does SOA or object databases or tomorrow's next big thing. They all help - but they don’t make complex requirements disappear. At some point you have to roll up your sleeves and work on a design that manages the complexity at an acceptable level for your team, your skill level, your business, and your environment. Experience plays a key role here because it’s all been done before. Breaking complex things into simple, composable pieces requires practice with abstraction techniques and knowing where to apply the right amount of encapsulation.

One drawback to the MVVM hype is how the hype drives people to one solution for every problem. The truth is there are lots of tricks to managing a complex UI, and some of them are dead simple and have built-in tooling support. Here is a sample:

User controls and custom controls
Behaviors (underutilized, IMHO)
Triggers and visual states
Events and event aggregators

The trick is to pick the right tool for the job.

So What Can MVVM Do For Me?

I think MVVM does help to manage complexity and and produce maintainable code. I’ve had success with MVVM. Like every separated presentation pattern it divides the varied concerns of a user interface. You can’t dismiss the MV* type patterns as pie in the sky architecture –they’ve served the industry well for decades.

What makes MVVM different? Why is it shiny and new? I think it’s because MVVM’s raison d'être is data binding. It’s easy to dismiss MVVM as just another UI pattern, but binding does give MVVM a slightly different flavor (a bit salty at times, but that’s just because of the static typing). If you’ve already been using a separated presentation pattern, it’s the data binding capabilities you need to understand and leverage. Data binding is quite powerful in WPF and Silverlight. You can perform amazing feats with little effort and without sacrificing encapsulation. Giving up on data binding is giving up on many of the advantages in the platform.

Proper use of MVVM also gives you a testable chunk of code. I think it’s strange that the MVVM rant dismisses the work needed to make a complex UI testable. I’d think a complex UI would need more testing than a simple UI.

On the other hand, I did just read “How a stray mouse click choked the NYSE & cost a bank $150K”, so I might not be thinking clearly.

Wrapping about Collections

K. Scott Allen — Mon, 01 Feb 2010 14:12:00 GMT

Mark Needham’s “Thoughts On Software Development” is a great collection of blog posts. Last year Mark wrote “Coding: The primitive obsession”, and challenged the idea that the primitive obsession anti-pattern is just about overusing low level data types like string and int.

The most frequent offender seems to be the creation of collections of things which we then query to find specific items elsewhere in the code. More often that not we'll also perform some custom logic on that particular item.

At its most extreme we might extract each of the items in a collection and make use of them separately. This somewhat defeats the purpose of the collection.

When this happens it often seems to me that what we actually have is a series of attributes of an object rather than a collection.

Mark goes on to describe how wrapping a collection can often create a more useful abstraction, then points to his debate in Wrapping collections: Inheritance vs Composition. It’s a good read.

I’ve been wrapping collections a bit myself lately, and it’s not too hard to create a custom collection that is both feature rich and descriptive of the problem it solves using composition. For example, let’s say you need to keep a collection of Stamp objects and support INotifyCollectionChanged.

public class StampCollection : IEnumerable<Stamp>, 
                               INotifyCollectionChanged
{
    public StampCollection()
    {
        _items = new ObservableCollection<Stamp>();
        _items.CollectionChanged += ItemsCollectionChanged;
    }

    public void AddStamp(Stamp newStamp)
    {
        /* logic */

        _items.Add(newStamp);
    }

    public void RemoveStamp(Stamp stamp)
    {
        /* logic */

        _items.Remove(stamp);
    }

    public IEnumerator<Stamp> GetEnumerator()
    {
        return _items.OrderBy(stamp => stamp.Something)
                     .GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    public event NotifyCollectionChangedEventHandler 
        CollectionChanged = delegate { };

    void ItemsCollectionChanged(object sender, 
                                NotifyCollectionChangedEventArgs e)
    {
        CollectionChanged(this, e);
    }

    readonly ObservableCollection<Stamp> _items;
}

Yes, it’s a bit of code, but it:

Gives you complete control over the surface area of the API compared to inheriting from ObservableCollection<T> or List<T>
Allows precise control over adding and removing objects (validation, perhaps updating fields).
Becomes a more descriptive part of the domain
Is not to be confused with a rap collection.

KISS Your ASP.NET MVC Routes

K. Scott Allen — Mon, 25 Jan 2010 14:12:00 GMT

A little bit of thinking and compromise can remove unnecessary complexity from the routes in an MVC application.

For example:

Morgan’s web site has authenticated users,and Morgan decides the URLs for managing users should look like /morgan/detail. Morgan adds the following code to register the route:

routes.MapRoute(
    "User",
    "{username}/{action}",
    new { controller ="User", action="Index" }
);

Morgan runs some tests and it looks like there is a problem. The User controller is getting requests for /home/index. Oops, that request should have gone to the Home controller. Fortunately, Morgan knows there is all sorts of whizz-bang features you can add to a route, so Morgan creates a route constraint:

public class UserRouteConstraint : IRouteConstraint
{
    public bool Match(HttpContextBase httpContext, 
                      Route route, string parameterName, 
                      RouteValueDictionary values, 
                      RouteDirection routeDirection)
    {
        var username = values["username"] as string;
        return IsCurrentUser(username);
    }

    private bool IsCurrentUser(string username)
    {
        // ... look up the user
    }
}

The constraint prevents the User route from gobbing requests to other controllers. It only allows requests to reach the User controller when the username exists in the application.

Morgan tweaks the route registration code to include the constraint:

routes.MapRoute(
    "User",
    "{username}/{action}",
    new { controller ="User", action="Index"},
    new { user = new UserRouteConstraint() }
);

Morgan runs some tests and everything works!

Well …

Everything works until a user registers with the name “home”. Morgan goes off to tweak the code again...

STOP!

As a rule of thumb I try to:

Never use advanced routing features like constraints
Always stick to a URL like {controller}/{action}/{id} or {controller}/{id}/{action}

Sometimes you have to go break those rules, but let’s look at Morgan’s case. If Morgan was happy with a URL like /user/index/morgan, then Morgan wouldn’t need to register any additional routes. The default routing entry in a new MVC application would happily invoke the index action of the User controller and pass along the username as the id parameter. Morgan could also go with /user/morgan and use a simple route entry like this:

routes.MapRoute(
    "User",
    "User/{username}/{action}",
    new { controller ="User", action="Index", username="*"}
);

No constraints required!

The KISS principle (keep it simple stupid) is a good design principle for routes. You’ll have fewer moving parts, consistent URL structures, and make the code easier to maintain.

Silverlight and ASP.NET MVC Don’t Serve the Same Master

K. Scott Allen — Tue, 19 Jan 2010 14:12:00 GMT

I’m flipping between MVC and Silverlight projects when a startling contrast starts to emerge. It’s not the obvious contrast between stateful and stateless. It’s a subtler contrast in design.

If you poke around in a new MVC project, one of the first pieces of code you’ll run across is the code to register the default route. It’s in global.asax.cs, and looks like this:

routes.MapRoute(
    "Default",                                            
    "{controller}/{action}/{id}",                         
    new { controller = "Home", action = "Index", id = "" }
);

This snippet relies on some of the recent features added to C# – extension methods and anonymously typed objects. It obviously draws some inspiration from Ruby on Rails, which builds on top of the dynamic, malleable Ruby language.

Compare that code to the code you’ll see when you open up just about any Silverlight control.

Well, you don’t actually see much code because the code is swept underneath a carpet of regions. This happens quite often in Silverlight, and I think it’s because developers are embarrassed to write lines and lines and lines of code to define a single simple property. It’s the elegance of RPG combined with the verbosity of COBOL.

public bool IsDropDownOpen
{
    get { return (bool)GetValue(IsDropDownOpenProperty); }
    set { SetValue(IsDropDownOpenProperty, value); }
}

public static readonly DependencyProperty IsDropDownOpenProperty =
    DependencyProperty.Register(
        "IsDropDownOpen",
        typeof(bool),
        typeof(Foo),
        new PropertyMetadata(false, OnIsDropDownOpenPropertyChanged));

I realize IsDropDownOpen isn’t just a simple property. It’s a dependency property, and dependency properties hold many great and magical powers. Data binding in Silverlight (and WPF), for example, is wonderfully feature rich and easy, but it comes with a price. Instead of writing one line of code …

public bool IsDropDownOpen { get; set; }

… we need twelve!

The contrast isn’t in the number of lines of code, however. The contrast is in who the frameworks were designed to serve.

MVC is for Developers – Silverlight is for Tools

The MVC framework is designed for developers who write code. This fact is obvious in the API design and how the team fights for programmer friendly features like the new HTML encoding block syntax. The MapRoute code we saw earlier is just one example of many. The MVC framework took inspiration from platforms that are popular today because they favor convention over configuration and essence over ceremony. These are fancy terms for keeping things simple and readable.

Silverlight is designed for tooling. Visual Studio, Expression Blend, and other XAML, code, and art editors. I’m not saying we get rid of the tools. We need the tools for the feedback and capabilities they provide when building effects, animations, and irregularly shaped objects. But, it seems the developer’s life gets more difficult with the addition of every feature.

The Next 5 Years

I’d be surprised if another language doesn’t come along to become the de facto standard for the code behind XAML files. A language that is just as friendly to programmers as it is to XAML. A language that makes writing code for System.Windows fun, simple, and readable. Maybe it will look like …

depprop bool IsDropDownOpen { get; set; }

… but smarter people then me can figure out the syntax. I just know there has to be something better.

Drop-down Lists and ASP.NET MVC

K. Scott Allen — Mon, 18 Jan 2010 14:12:00 GMT

Working with drop-down lists in ASP.NET MVC has some confusing aspects, so let’s look at an example.

Imagine the goal is to edit a song (not the music and lyrics of a song – just the boring data pieces). Each song is associated with an album, and each song has a title and track number. With this description, you can imagine an edit view using the following code:

<%= Html.DropDownList("AlbumId", Model.Albums)%>
  ...
<%= Html.TextBox("Title", Model.Title) %>
   ...
<%= Html.TextBox("TrackNumber", Model.TrackNumber) %>

The Html.DropDownList helper method likes to work with SelectListItem objects, so a view model you can pair with this view looks like the following:

public class EditSongViewModel
{        
    public string Title { get; set; }                
    public int TrackNumber { get; set; }
    public IEnumerable<SelectListItem> Albums { get; set; }
}

Some people don’t like to use SelectListItem types in their view models. Instead, they’ll convert to them in the view. I think it’s entirely reasonable to use SelectListItem in a view model, because the view model is supposed to make the view easier to write. Having the view model perfectly aligned with the needs of the view means you need to think less (and write less code) when creating the view.

Creating SelectListItems

There are a couple approaches you can take when creating a sequence of SelectListItem objects. I think the cleanest approach is to have an extension method that knows how to take a collection of objects in your software (like Album objects), and map them into SelectListItem objects.

public static IEnumerable<SelectListItem> ToSelectListItems(
              this IEnumerable<Album> albums, int selectedId)
{
    return 
        albums.OrderBy(album => album.Name)
              .Select(album => 
                  new SelectListItem
                  {
                    Selected = (album.ID == selectedId),
                    Text = album.Name,
                    Value = album.ID.ToString()
                   });
}

You can use the method like this:

model.Albums = _repository.FindAllAlbums().ToSelectItems(selectedId);

That code works, because Html.DropDownList will happily work with IEnumerable of SelectListItem.

The class you need to be careful with is the SelectList class. I’ve seen quite a few people make the mistake of wrapping their SelectListItem objects in a SelectList without setting the DataTextField and DataValueField properties. This does not work:

model.Albums = new SelectList(
                _repository.FindAllAlbums().ToSelectListItems(1)
                );

You’d think the SelectList class would know how to work with a collection of SelectListItem objects - but it doesn’t. The following doesn’t work either (the drop-down list will display “System.Web.Mvc.SelectListItem” for every entry):

model.Albums = 
    new SelectList(_repository.FindAllAlbums()
                              .ToSelectItems(selectedID));

The SelectList class is really designed to perform the conversion we did earlier (with the extension method), but it uses late binding reflection. The following would work, because we tell the SelectList where to find the text and value fields:

model.Albums = new SelectList(
                _repository.FindAllAlbums(), "ID", "Name"
                );

Reading the Selection

If you are using the same model to accept input from the edit view during a postback, you might think the default model binder will repopulate the Albums collection with all the album information and set the selected album. Unfortunately - the web doesn’t work this way and the Albums collection will be empty.

The only album related information the browser will post is the value of the selected item. If you want this value bound to a model, you’ll need to provide an AlbumId property (to match the name we gave the DropDownList in the view - “AlbumId”).

public class EditSongViewModel
{
    public int AlbumId { get; set; }
    public string Title { get; set; }                
    public int TrackNumber { get; set; }
    public IEnumerable<SelectListItem> Albums { get; set; }
}

Some people will create two separate view models in this case. One view model is designed to carry information to the view, and will have an Albums property (but no AlbumId property). The second view model is designed to accept user input during postback and will have an AlbumId propery (but no Albums property). This approach adds the overhead of an extra class, but the view models are perfectly aligned with their duties and no properties go unused. You’ll have to decide which approach is best for you.

Summary

Don’t use a SelectList without telling it the DataTextField and DataValueField properties to use.
Don’t expect to see a collection for a drop-down list repopulated on a postback.
Extension methods make it easy to create a sequence of SelectListItem objects in strongly-typed code.
Html.DropDownList doesn’t require a SelectList – it’s happy working with any sequence of SelectListItem objects.

T4MVC in MSDN Magazine

K. Scott Allen — Thu, 14 Jan 2010 14:12:00 GMT

The January 2010 issue of MSDN Magazine is online with my article covering T4MVC:

Microsoft Visual Studio includes a code generation engine known as T4 (which is short for Text Template Transformation Toolkit). You’ve probably already used T4 templates in Visual Studio without even knowing they were working behind the scenes. In this article I’m going to give you a basic introduction to T4 templates and show you how ASP.NET MVC uses this technology. I’ll also show you how to customize T4 templates to enhance your day-to-day work with the MVC framework

Thanks go to David Ebbo for his help and comments on the article. David continues to improve T4MVC, for example: T4MVC 2.6.10: fluent route value API, shorter way to refer to action, and more

Enjoy!

Of Web Browsers and Humanity

K. Scott Allen — Wed, 13 Jan 2010 14:12:00 GMT

Douglas Crockford posted an interesting topic for discussion on his site (look for the Discussion Topic section at the bottom of the page):

If a web browser is defective, causing errors in the display or performance of the page, should the page developer struggle to hide the browser's defects, or should the defects be revealed in hope of creating market pressure to force the browser maker to make good? By which approach is humanity better served?

What I’d Like To Say

When I was a kid, I loved Mad Libs. And I bet you could come up with a Mad Lib that represents a style of question every web developer asks on a regular basis. I think it would look like this:

I’m trying to ______ a ______ and it’s fine in ______ and _______, but in ______ it doesn’t _______ing work.

It’s always the same question - you just have to fill in the blanks with 1 CSS property, 1 DOM element, 3 browser versions, and one profanity. Isn’t it insane? Can’t we start a revolution and all make a New Year’s resolution?

But …

It’s a business decision. I think this is what gets under the collective skin of the web development community more than anything else. We can’t make a resolution to stop! We already told the bosses they’ll spend an extra $10,000 to support IE6, but they are more than happy with the return on the investment. So, we sulk back to our offices and grudgingly add some more conditional CSS comments to the site’s style sheet.

If there is going to be market pressure, it won’t come from developers per se, but from big Internet properties with fanatical followers, like Facebook, Amazon, eBay, and Twitter. They have the power to force users to move, and when users start moving the makers react.

And yes, I think it is in the best interest of humanity.

Don’t Let Your Code Marry An Axe Murderer

K. Scott Allen — Tue, 12 Jan 2010 14:12:00 GMT

It’s a lesson I learned from the school of hard knocks: be careful about the shady characters you let into your software.

There are lots of software frameworks, components, and tools in the world – and they all want you to think you can live with them happily ever after. They seduce you with the promise of productivity, then hack you to death once they’ve gained your trust.

Here are a few questions I’ve learned to ask when trying to spot next year’s problems:

1. How easy is it to deploy?

I’ve been burned by software that is difficult to move from one environment to the next. Some products, particularly server products, assume you never need to move software into different environments (like development, test, productions). Avoid anything you can’t automate!

Software should be as easy to deploy as possible, otherwise it doesn’t get deployed often enough.

2. Will it work in source control?

Some tools and designers generate files that don’t work well under source control. If you can’t diff and merge you lose a tremendous amount of flexibility when it comes time to branch, patch, and support concurrent development. Database tools are historically notorious for having problems in this area because they tend to design for DBAs instead of developers.

It is, however, perfectly reasonable to check in binary dependencies.

3. Is it needy?

Speaking of dependencies – they are a touchy subject. You can’t invoke the “not invented here” rule in every decision without writing your own compiler. At the same time, every dependency you introduce to a product is a calculated risk. How many dependencies does this new thing have? Will you ever delay shipping because you are waiting for a new version of a dependency? Will you ever delay shipping because you are waiting for a new version of a dependency’s dependency? How many things will break when the next version arrives? Are you willing to run beta code, or code from the trunk? The answer is different for every application and business.

In the end you need to make a decision from the gut, which means research into the history and pedigree of a dependency might be required.

4. When will it be obsolete?

If you implement the solution to a problem in a mainstream programming language like C#, you can be reasonably sure it will still work and compile in 5 -10 years, even with new versions of the compiler. But, if you implement the same solution with Data Transformation Services (wait, that’s obsolete), or Notification Services (wait, that disappeared), or SQL Distributed Management Objects (oops, it’s only a matter of time) - then you got some rewritin’ to do!

Remember – nothing lasts forever … unless you have all the source code.

More On The Death of If-Else

K. Scott Allen — Mon, 07 Dec 2009 02:12:00 GMT

Aaron Feng posted recently on “The death of if-else, if, and else”. In the post Aaron rewrote some JavaScript conditional checks using a dispatch table type approach.

Following along with Aaron’s post using C#, we’d start with a list of Channel objects:

var channels = new List<Channel>
{
    new Channel { Number = 2,
                  Station = "NBC",
                  ShowTitle = "Saturday Night Live",
                  Genre = "comedy",
                  Repeat = true },
    new Channel { Number = 3,
                  Station = "ESPN",
                  ShowTitle = "College Football",
                  Genre = "football",
                  Repeat = false}
    // ...
};

Then we have the logic for deciding which channels to record:

public void Surf(IEnumerable<Channel> channels)
{
    foreach (var channel in channels)
    {
        if (channel.Genre == "football")
        {
            Record(channel);
        }
        else if (channel.Genre == "comedy" && 
                 !channel.Repeat)
        {
            Record(channel);
        }
        else if (channel.Genre == "crime" &&
                channel.ShowTitle != "Cops!")
        {
            Record(channel);
        }
    }
}

Rewriting the code using Aaron’s final approach would look like the following:

public void Surf2(IEnumerable<Channel> channels)
{
    var dispatch = new Dictionary<string, Action<Channel>>
    {
        { "football", c => Record(c) },
        { "comedy",   c => {if(!c.Repeat) Record(c);}},
        { "crime",    c => {if(c.ShowTitle != "Cops!") Record(c);}}
    };

    foreach (var channel in channels)
    {
        dispatch[channel.Genre](channel);
    }
}

Personally, I feel Aaron’s dispatch table is not a big improvement over the previous “if else” version. The actions in the dispatch table are too busy. I think a cleaner approach is to just extract the rules into a data structure – essentially build a collections of predicates to evaluate. Given a channel, the data structure can tell me if the channel should be recorded.

public void Surf3(IEnumerable<Channel> channels)
{
    var recordingRules = new Func<Channel, bool>[]
    {
        c => c.Genre == "football",
        c => c.Genre == "comedy" && !c.Repeat,
        c => c.Genre == "crime" && c.ShowTitle != "Cops!"
    };

    foreach (var channel in channels)
    {
        if(recordingRules.Any(rule => rule(channel) == true))
        {
            Record(channel);
        }
    }
}

Not quite as flexible, but for this specific example its easier to read and maintain.

What do you think? Is that better or worse?