How to mark required fields with jQuery Validate

by Morten Christiansen on 16-02-2012 at 23:44 | comments [0] | posted in JavaScript

Today I was tasked with marking all the required field in an ASP.NET MVC application with asterisks, next to the relevant labels. Initially it seemed that there would be no other solution than to go through every view and add it by hand. Fortunately, I realized that there was a far better solution, one that would only require 13 lines of code. We use the jQuery Validation plugin for client-side validation and this is configured with a number of validation rules. I realized that if I could hook into these rules, I had all the information that I needed.

The concept behind this solution is simple, really. You just need to intercept the initializing logic that sets up the validation rules and update the labels as needed. The code in its entirety can be seen below.

var validateMethod = $.fn.validate;
$.fn.validate = function (o) {
if (o && o.rules) {
for (var name in o.rules) {
var rule = o.rules[name];
if (rule.required === true) {
var label = $('label[for=' + name + ']');
label.text(label.text() + "*");
}
}
}
return $.proxy(validateMethod, this)(o);
};

The code assigns the original validation method to a variable, saving it for later, while we assign the plugin a new method. This method contains our logic, ending up executing the original method. Notice that we must use the jQuery proxy function for assigning the target element to the this property inside the validation function as it expects. That's all there is to it. Of course, you can check for other types of validation rules and annotate the form fields accordingly if you need to. Just execute this code at any time before initializing your validation rules.

Refactoring: Named boolean arguments

by Morten Christiansen on 22-01-2012 at 12:29 | comments [0] | posted in Best Practices, Refactoring

This is another article in my series on refactoring code to make it more readable and maintainable

Boolean arguments have a nasty tendency of making method calls very hard to read, especially when several of them are required. For example, consider this piece of code I just ran across:

new SchemaExport(Configuration).Execute(true, true, false, true, session.Connection, Console.Out);

This might not by a typical example, but it clearly illustrates the problem. Just looking at it, you don't really know much about what this line of code does. Of course, your IDE can probably help you figure it out quickly enough, but several such lines can it makes it very hard to quickly figure out a section of code. I've run across variations of this issue countless times and have come to use one of two approaches to avoid this, depending on the circumstances.

The first is to use named variables, a feature of C#. Alternatively, you can declare a variable and supply it to the method. This makes for much clearer code:

// named arguments
var users = service.GetUsers(includeTemporary: true, loadDocuments: true);
// named variables as arguments
var includeTemporary = true;
var loadDocuments = true;
var users = service.GetUsers(includeTemporary, loadDocuments);

Most of the time, I find this to be a suitable solution. Sometimes, however, the boolean argument has such an impact on the implementation of the method that we're better served splitting it in two. This will keep each of the methods focused on a single responsibility making it easier to change one part without affecting the other. In the example below, the method is split into two because the notions of a document and a draft are, while related, not treated the same at all. Therefore, a more appropriate API would have methods for getting either type separately.

// wrong way (because drafts and normal documents are never treated as the same thing)
var documents = service.GetDocuments(includeDrafts: false);
var documentsAndDrafts = service.GetDocuments(includeDrafts: true);
// better way
var documents = service.GetDocuments();
var drafts = service.GetDrafts();

If needed, the implementations of the two methods can rely on secondary methods for any shared logic.

The IDE is dead; Long live the IDE

by Morten Christiansen on 31-10-2011 at 22:55 | comments [0] | posted in Programming

A while ago, I stumbled upon the ASP.NET Uservoice page for gathering feature requests and suggestions. Among the most popular requests was something odd, a feature named Code Bubbles. This did not sound like anything to do with web programming, but its great popularity sparked my interest. Fortunately, the suggestion featured a link to a website explaining the concept, including a demonstration video… and minds were blown!

These guys have completely reimagined the IDE, laying down the shackles of technology that have held back current efforts. Sounds dramatic? That's because it is. Abstractions have been added to allow more freeform ways to organize code without being limited by the notion of files and the project structure as we know it. The central theme of the work is to have all the code you need on your screen, and nothing else, working down to the method level – the groupings of code that give the concept its name. A host of features have been developed for making the workflow of navigating to related code effortless. But alas, words prove too poor a medium as I try to explain this wonder. Go, spend the next 8 minutes of your life watching the demonstration video of a working Java IDE exploring the Code Bubble idea. Here are their own words, describing the concept, but do follow the link to see the video and read more:

“Developers spend significant time reading and navigating code fragments spread across multiple locations. The file-based nature of contemporary IDEs makes it prohibitively difficult to create and maintain a simultaneous view of such fragments. We propose a novel user interface metaphor for code understanding and maintanence based on collections of lightweight, editable fragments called bubbles, which form concurrently visible working sets.

The essential goal of this project is to make it easier for developers to see many fragments of code (or other information) at once without having to navigate back and forth. Each of these fragments is shown in a bubble.

A bubble is a fully editable and interactive view of a fragment such as a method or collection of member variables. Bubbles, in contrast to windows, have minimal border decoration, avoid clipping their contents by using automatic code reflow and elision, and do not overlap but instead push each other out of the way. Bubbles exist in a large, pannable 2-D virtual space where a cluster of bubbles comprises a concurrently visible working set. Bubbles support a lightweight grouping mechanism, and further support connections between them.

A quantitative user study indicates that Code Bubbles increased performance significantly for two controlled code understanding tasks. A qualitative user study with 23 professional developers indicates substantial interest and enthusiasm for the approach, despite the radical departure from what developers are used to.”

I'm absolutely in love with the idea that you have a sort of working space with all the methods and structures you are working on, allowing you to shift between them as you work on different tasks. Some urgent bug just came up? No problem, just move to a new work space and begin stepping through the affected code, building up the new working space.

Working on large projects, I'm sometimes tempted to bundle too much functionality into a single class, just to have all the related code at hand. As a project grows, the number of files that are relevant to some piece of functionality can grow very high, especially when you have to include all the layers of the application. What Code Bubbles does that looks so promising, is to put all the related code in a single screen or at least scrollable area. The calling hierarchy is clearly defined and it becomes easy to follow the thread of execution as it goes from class to class and module to module.

After finding this, I've begun noticing activity regarding the project across the web. One such this is the very interesting Debugging Canvas project from Microsoft Research. It is actually the result of a collaboration between Microsoft and the people behind Code Bubbles in an effort to bring the new ideas to Visual Studio. It's a limited part of the whole Code Bubbles concept but I'm thrilled to see it taken seriously by Microsoft. After all, until it lives in Visual Studio, it's largely irrelevant to me in practice. There is also a video for the Debugging Canvas on their site, so take a look at that as well. You can go install it now as an extension to Visual Studio, that is, if you have the Ultimate version of Studio.

I, for one, welcome our new Code Bubble overlords.

Refactoring: Naming conditional statements

by Morten Christiansen on 21-10-2011 at 19:37 | comments [0] | posted in Best Practices, Refactoring

This is the first in a series of small tips that you can apply to make your code more readable, maintainable and generally just smell better. This one deals with conditional logic and how it is often unnecessarily hard to read. The problem is that many people, myself included, tend to pile a lot of different checks into the conditional statement, without regards for readability. I guess splitting up the statement into several lines of code triggers some base programmer instinct we all have for keeping our code tight and clean.

Regardless of why, I've found it very useful to break out the boolean expression into one or more variables that explicitly declare the semantic meaning of the expression. When several checks are combined that are not directly related, it can even be better to break it into several variables.

// Bad code
if ((user.HasRole("seller") || user.HasRole("manager")) && order.IsHandled && order.HandleDate < DateTime.Now)
{
// snip
}
// Better
var orderIsProcessedAndCanBeSeenByUser = (user.HasRole("seller") || user.HasRole("manager")) && order.IsHandled && order.HandleDate < DateTime.Now
if (orderIsHandledAndCanBeSeenByUser)
{
// snip
}
// Best
var userCanSeeOrder = user.HasRole("seller") || user.HasRole("manager")) ;
var orderIsProcessed = order.IsHandled && order.HandleDate < DateTime.Now;
if (userCanSeeOrder && orderIsProcessed)
{
// snip
}

There is one caveat with using the multi-variable approach, as you circumvent the short-circuiting mechanism of C#. If the second part of the check performs an expensive operation such as a database call, this approach will force it to be evaluated every time. If you're insistent, you can always wrap secondary expressions in a lambda function, but that will look a bit odd, I should think.

Tips & Tricks: Improving the performance of your website–Pt. 2

by Morten Christiansen on 13-10-2011 at 09:47 | comments [0] | posted in ASP.NET MVC, Performance

Continuing my previous article on website performance tuning, today I'll talk about how you can achieve better performance at the server side of things. This part will be reflected in the time it takes to create the html that is sent in response to the initial http request. If this takes too long, all the previous optimizations with regards to reducing scripts, images, styles, etc., will seem irrelevant. The final goal with this whole exercise is to serve the page and have it be ready for the user to operate before he really notices the lag, becoming effectively instant. I personally try to aim for a 300ms load time for the html page itself; this seems to give a very smooth experience.

You should start out by setting a goal yourself, so you won't be spending time optimizing pages that are actually fast enough. It might be a good idea to distinguish between read-only requests and requests that alter the state of the server. The latter type of request will often require a lot of extra validation and generally do not happen as often. Depending on the standard workflows in your system, you might want to have different goals for these types of requests.

Application caching

In the previous article, I showed some code that I mentioned would be explained today. This is a caching mechanism I've been using in web applications for a while. There are near infinite ways to perform caching in your application, but this is my take. The purpose is to avoid database queries as much as possible, keeping results in memory and invalidating them when they grow stale.

My implementation is a wrapper over the ASP.NET caching mechanism but the implementation details can be swapped as needed without changing the interface. For ease of use, I prefer to have a switch in the web.config to toggle whether the feature is enabled. You can see the complete cache provider below.

public static class CacheProvider
{
private static bool _enableCache;
static CacheProvider()
{
// Implement as you like
_enableCache = CacheConfiguration.Enabled;
}
/// <summary>
/// A cache duration of one year.
/// </summary>
public const int Forever = 31556926;
public static TQuery CacheQuery<TQuery>(Func<TQuery> performQuery, string cacheKey, object cacheLockObject, int duration)
where TQuery : class
{
if (!_enableCache)
return performQuery();
var result = HttpRuntime.Cache[cacheKey] as TQuery;
if (result == null)
{
lock (cacheLockObject)
{
result = HttpRuntime.Cache[cacheKey] as TQuery;
if (result == null)
{
result = performQuery();
HttpRuntime.Cache.Insert(cacheKey, result, null, DateTime.Now.AddSeconds(duration), Cache.NoSlidingExpiration);
}
}
}
return result;
}
public static void InvalidateQueryCache(string cacheKey, object cacheLockObject)
{
if (!_enableCache)
return;
var result = HttpRuntime.Cache[cacheKey];
if (result != null)
{
lock (cacheLockObject)
{
result = HttpRuntime.Cache[cacheKey];
if (result != null)
{
HttpRuntime.Cache.Remove(cacheKey);
}
}
}
}
}

As shown in the last code listing in the first article, the following line of code is an example of how to use the provider.

return CacheProvider.CacheQuery(query, cacheKey, _cacheLockObject_Src, CacheProvider.Forever);

The cache looks if there is an entry stored for the specified key. If there is, it is returned, and if not, the supplied lambda query is executed. A simple Action lambda to represent queries allows us to cache any type of operation, making it very flexible. Removing the dependency on the ASP.NET cache would even allow it to be used for caching algorithmic computations in a desktop application.

What I mainly use the cache for, is as an intermediary layer over my service layer, making both sides unaware of the caching by using inheritance and virtual methods. Steve Smith has a couple of posts where he describes the Cached Repository pattern that has inspired my own implementations.

Compiled queries

When using the Entity Framework ORM for more complex systems, I have seen many cases where parsing the LINQ query and building the SQL query takes far longer than executing the query itself. Using compiled queries, you can reduce this problem by storing the query in memory after it has been executed the first time, though at the price of a slightly longer compilation time than normal. The syntax is not exactly elegant, so I prefer to isolate each compiled query in its own class. This also yields another advantage, as I will describe in the tip on application warmup.

First, I've defined some base classes for making it easier to create new query types. Note that the base types define how many arguments the query takes, as generic arguments. Thus, separate bases classes are needed for no-argument queries, single-argument queries, etc.

public abstract class CompiledQueryBase
{
protected MyEntityContext GetContext()
{
var context = new MyEntityContext();
context.ContextOptions.LazyLoadingEnabled = false;
return context;
}
}
public abstract class CompiledQuery<T1, TResult> : CompiledQueryBase
{
protected MyEntityContext Context { get; private set; }
protected abstract Func<MyEntityContext , T1, TResult> Query { get; }
public CompiledQuery(MyEntityContext context)
{
Context = context;
}
public TResult Execute(T1 arg1)
{
return Query(Context, arg1);
}
}
public abstract class CompiledCollectionQuery<T1, TResult> : CompiledQueryBase
{
protected MyEntityContext Context { get; private set; }
protected abstract Func<MyEntityContext , T1, IQueryable<TResult>> Query { get; }
public CompiledCollectionQuery(MyEntityContext context)
{
Context = context;
}
public IQueryable<TResult> Execute(T1 arg1)
{
return Query(Context, arg1);
}
}

As a side note, I always disable lazy loading on my context as this will prevent the whole category of n+1 issues associated with ORMs.

As a sample on how to implement a concrete compiled query, take this code from a project I'm working on:

public class ImprovementDeadlinesCompiledQuery : CompiledCollectionQuery<int, int, string, Event>
{
protected override Func<QmsContext, int, int, string, IQueryable<Event>> Query { get { return _getImprovementDeadlines; } }
private static readonly Func<QmsContext, int, int, string, IQueryable<Event>> _getImprovementDeadlines = CompiledQuery.Compile(
(QmsContext context, int month, int year, string username) =>
from i in context.Improvements
where !i.IsClosed &&
!i.Recipients.Any(r => r.RecipientUser.UserName == username && r.IsCheckedOut) &&
(i.Recipients.Any(r => r.RecipientUser.UserName == username && !r.IsCheckedOut) || i.Recipients.Any(r => r.RecipientGroup.Members.Any(u => u.UserName == username)))
where i.DueBy.Year == year && i.DueBy.Month == month
group i by i.DueBy.Day into g
select new Event
{
Day = g.Key,
Entries = g.Select(s => new EventEntry
{
Title = s.Subject,
ActionId = s.Id
})
}
);
public ImprovementDeadlinesCompiledQuery(QmsContext context)
: base(context)
{ }
}
//Usage
var items = new ImprovementDeadlinesCompiledQuery(context).Execute(month, year, username);

While the performance improvements can be quite significant with this technique, keep in mind that the first user loading a page with a compiled query will still get the slow performance. Luckily, there is a fix for this as described in the following tip. Oh, and another minor detail – in the upcoming version of EF, all queries will be compiled by default.

Application warmup

A common problem I see is that while caching and other techniques can make warm page requests very fast, invariably, some poor user has to pay the tax for hitting a cold page. Like most other problems, this one can be worked around, and to do this, we need to rely on a little bit of IIS functionality. As it turns out, IIS has a feature that allows you to automatically start the site and run a method for accepting http requests. In this method, you can preload caches and perform other long-running tasks. Scott Gu has a nice article on the subject, but the main point is that you have a class that implements the System.Web.Hosting.IProcessHostPreloadClient interface and update the applicationHost.config file to point to the namespace of the class that implements it.

One of the things I use this technique for, is to preload all the compiled queries I have created. I simply iterate over all the types in my assembly and look for classes implementing an interface called ICompiledQuery with the single method void Preload(). To support this, I update the compiled query base classes I showed in the previous tip, like this:

public abstract class CompiledQueryBase : ICompiledQuery
{
public abstract void Preload();
protected MyEntityContext GetContext()
{
var context = new MyEntityContext();
context.ContextOptions.LazyLoadingEnabled = false;
return context;
}
}
public abstract class CompiledQuery<T1, TResult> : CompiledQueryBase
{
protected MyEntityContext Context { get; private set; }
protected abstract Func<MyEntityContext , T1, TResult> Query { get; }
public CompiledQuery(MyEntityContext context)
{
Context = context;
}
public TResult Execute(T1 arg1)
{
return Query(Context, arg1);
}
public override void Preload()
{
try { Query(GetContext(), default(T1)); }
catch { };
}
}

This allows me to do the following in the warmup module:

public class Warmup : IProcessHostPreloadClient
{
public void Preload(string[] parameters)
{
//Preload all compiled queries
FindAndLoadCompiledQueries();
}
public static void FindAndLoadCompiledQueries()
{
var compiledQueries = typeof(CompiledQueryBase).Assembly.GetTypes().
Where(t =>
typeof(ICompiledQuery).IsAssignableFrom(t) &&
t.IsClass &&
!t.IsAbstract
);
foreach (var queryType in compiledQueries)
{
var query = (ICompiledQuery)Activator.CreateInstance(queryType, (QmsContext)null);
query.Preload();
}
}
}

Micro ORMs

Sometimes compiled queries are simply not enough for meeting those performance requirements and you have to turn to more drastic means. I recently discovered a new category of tools for just this occasion – the micro ORMs. These tools are a breed of ORMs that I've seen cropping up recently and there are a number of them to choose from. Essentially, they're a thin wrapper over plain SQL that makes it easier to build queries and serialize the result into objects. Their claim to fame is naturally their performance, and generally they seem to add only a few percent of overhead to vanilla SQL.

Sam Saffron helped develop the Dapper ORM for Stack Overflow and they use it to replace Linq 2 SQL code in select places where performance is not satisfactory. Stack Overflow is a very high-traffic site, so the fact that they need tools such as this does not necessarily mean it makes sense for you. But it's good to know that the tools are out there if you need them. Head over and read the post on Sam's blog for more background on the Dapper project and what they use it for.

Remove unused view engines

A simple thing, but it makes rendering of views a bit faster. By default, MVC registers view engines for both the new Razor views and the old Web Forms views. This means that the types of files that will be searched for in the view folder includes extensions that are irrelevant to you unless you use both types of views in the same project. To fix this, go into the Global.asax file and add the following code in the OnApplicationStarted method:

ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());

MVC Mini Profiler

A nifty little tool, from the same people that brought you the Dapper micro ORM, is the MVC Mini Profiler. It's a light-weight profiler that is designed to remain in the running code even after deploying to production. This allows developers to go in and get detailed performance metrics in a running system. Each time a new page request is made, including Ajax calls, a small box appears, allowing you to see the result of the profiling session directly in your browser. This is immensely useful, helping you to detect problems even when you aren't looking for them. Even better, if you hook it up to your database, it will profile SQL queries as well, highlighting duplicate queries and separating the time spent in the database from that spent in the application code. Yes, it even shows you the actual SQL queries that were executed against the database.

This great little tool has become a cornerstone in my performance optimization work. All you have to do to get started is to install the Nuget package for MVC 3 project integration and fill out the blanks. Get it while it's hot.

That's it for now. There are a million other ways to optimize your websites but I find these interesting and not immediately obvious. So there you go.

Without Precedence