Pleanty of people have said that concurrency and functional programming are becomming essential to developing modern systems. Some have even gone so far as to say that if you don't adapt you will become a maintenance programmer in a few years. With the increasing need for concurrency to provide speed and handeling of huge amounts of data, I beleive it to be true. I do however beleive there will still be pleanty of smaller applications, so I am not predicting doomesday for anyone quite yet.

More...

Almost two years ago I took my first look at MongoDB as my first exploration into the NoSQL. Today I still find it to be one of the most interesting NoSQL tools – rivaled mainly by RavenDB, for most what I would call common scenarios. Recently I finally had the chance to use MongoDB in a real project, when we were talking over our options for doing faceted search, where the main design criteria was speed.

To get a good smooth user experience, the performance of the faceted search is critical. One if the limitations of a traditional SQL database is that everything is modelled as rows and columns. So when you need to have complex structured objects, you rely on joining tabels together and mapping them into objects. This is all fine and well in most cases, but when you aim to get the very best performance and the objects are well defined we can do better with tools like MongoDB. Not having to deal with schema reduces development time, when building something that should be denormalized, and avoiding mapping and multiple joins cuts the cost of a query runtime.

Takes two to perform

Just as it takes two to tango, it also takes good performance both backend and frontend, to provide the experience of good performance. To facilitate this I chose to use KnockoutJS – another tool I have blogged about earlier. knockout was used to handle two-way binding of the model and elements on the page, and Ajax for requesting the search results from the server, and updating the model.

Snapping together the logo pieces

As Scott Hanselman often describes it, modern tools should fit together well, giving the same feeling as lego pieces that snap together. This really was the feeling I had when I implemented the faceted search. Defining the model serverside, passing objects on through a service, and then having them serialized to JSon which in turn was made into KnockoutJS observables just felt smooth and painless.

The only thing I had to reconsider was using the LINQ implementation in NoRM, which isn’t quite good enough yet. This was however a small hickup, as the more native API that NoRM provides worked fine and was easy to use.

Looking back the actual implementation including doing indexes did not take long, and the performance just rocks. So this is without a doubt one if the more fun challanges I have had lately, and a solution that I feel proud of.

Why MiniMe?

For a while I have been using SquishIt to minify, bundle and version JavaScript and CSS files – and to a large extent it did a good job. However on a number of occations I ran into a group of scenarios where it just didn’t quite do enough for what I wanted. So when I was starting a new project and ran into the same issues again, I decided to take a look at making my own.

The basic idea behind MiniMe is that it should make it easy to bundle JavaScript and CSS files across masterpages, usercontrols etc. with the option to control how they are sorted, and end up with one file that is minified and versioned. It should also be easy to introduce into an existing project, with a minimal amount of refactoring, and lastly it should be easy to adhere to best practices and inject the script tag at the very bottom of the html page.

These are the requirements that I run into again and again, so I wanted a tool that did exactly that.

Getting started

To make it as easy as possible I made a nuget package, so all you need to get off the ground is to search for MiniMe in the package manager and hit install.

Building a complete file

Now you have access to the classes MiniJavaScriptBuilder and MiniStyleSheetBuilder, that can be used to build either a JavaScript or CSS file. The approach is similar, so from how on I will just show the JavaScript case. Using either one you can build a collection of files by calling Add or AddToRequest, which takes a path to the file you wish to add. The difference is that Add is local to the instance of the builder, where the ToRequest version is stored for the request across any number of builders. Both methods return the builder instance, so calls to Add/AddToRequest can be chained.

@{ new MiniMe.MiniJavaScriptBuilder()
    .AddToRequest(Url.Content("/scripts/myFirstScriptFile.js"))
    .AddToRequest(Url.Content("/scripts/mySecondScriptFile.js"), 1)         
    }

When using AddToRequest you can optionally pass an index as a second parameter. Files with a lower index are included before those with a higher index – allowing files that are added from usercontrols to run after those added in the masterpage.

Manually rendering a combined file

When all your files have been added you can call either Render or RenderForRequest, which will behave differently depending on if you have turned debug on in web.config or not. If you are in debugmode there is simply rendered a reference to each file, allowing you to debug like you are used to. If you are NOT in debugmode the files that were added will be combined and saved to the path you pass to the method. Writing a # as part of the path will enable versioning, so the # is replaced by a hashvalue of the filecontent. Versioning will make sure the filename changes when any of the files are changed, so caching does not prevent your users from getting any changes that you have made.

@{ MvcHtmlString.Create(new MiniMe.MiniJavaScriptBuilder()
.AddToRequest(Url.Content("/scripts/myFirstScriptFile.js"))
.AddToRequest(Url.Content("/scripts/mySecondScriptFile.js"), 1)
.RenderForRequest(Url.Content("~/Scripts/Site_#.min.js")))
}

Automatically injecting a combined file

Working with complex layouts can be a pain, because you have to take into account the order the usercontrols are rendered, and you will have duplication of code to render the files. To solve this MiniMe comes with an HttpHandler that will handle the rendering for you. This means that files that are added to the request, will be bundled, the combined JavaScript is referenced from the very bottom of the page and the Stylesheet is referenced from the header. All you have to do is add the HttpModule.

<system.webServer>
    <modules>
        <add name="MiniHttpModule" type="MiniMe.MiniHttpModule, MiniMe"/>

By default the HttpModule renderes the files to “/Scripts/Site_#.min.js” and “/Content/Site_#.css” – this can be overwritten using appSettings

<appSettings>
    <add key="MiniJsRelativePath" value="/Scripts/OtherSite_#.min.js"/>
    <add key="MiniCssRelativePath" value="/Content/OtherSite_#.min.css"/>

Create .min.js versions of all JavaScript files

In some cases you might want to have MiniMe generate .min.js versions for any files that have not yet been minified. This will also give you a slight performance boost, because MiniMe will not have to do the minification on the fly when files are combined. It is important to note that MiniMe will only make minified versions when no minified version already exist. Personally my preference is to do it when not running in debugmode, because then I won’t have to delete the minified versions when I make chances, in order for MiniMe to generate new ones.

if (!HttpContext.Current.IsDebuggingEnabled) new MiniGenerator().EnsureMiniVersions("/Scripts");

Go to the source to gain more insight or contribute

MiniMe is hosted on bitbucket, so if you wish to see how it works, or if you want to contribute please don’t hesitate. The first version was focused around the features I felt were missing, but there are undoubtedly other scenarios that can provide value.