A common problem with writing software is the complexity. It doesn’t matter how much abstraction you can do, you will always end up in situation where you have to take certain things for granted: “an argument is not null”, “the control has been properly initialized”, etc. When these assumptions are broken a number of things might happen. If you’re lucky an exception will be thrown, and if you’re not so lucky, you will suffer the consequences of the randomness in invalid states.

This was bothering me for quite some time and I didn’t really think there would be a solution until I listened to a podcast about the Spec# project. They are trying to implement design by contract in a .NET environment which is very cool.

In their language you can specify both preconditions and postconditions for your methods, and you can put conditions on you classes that always must be true. Example: An arraylist must always have the private field count larger than -1.

So, this podcast really blew my mind, but I guess that we will sadly have to wait before it is implemented in C# (if it ever is going to be). But, with the latest additions to the language (C# 3.0) you can apply something similar, if not so powerful, a substitute. Take a minute and reflect on the following code:

public static void AssertThat(this T argument, Predicate condition, string message)
{
        if (!condition(argument))
                throw new AssertException(message);
}

This is an extension method that will take a lambda expression and an error message. If the condition doesn’t validate, an exception will be thrown. Let’s say that I would write a method that repeats a string a given number of times:

public string Repeat(string arg, int count)
{
    arg.AssertThat(s => s != null,
        "Repeat was called with arg == null");

    count.AssertThat(i => i > -1,
        "Repeat was called with count = (negative number)");

    return count == 0 ? string.Empty : arg + Repeat(arg, count--);
}

First I make sure that the string argument is not null, because that could result in an unexpected state. Second, I make sure that count argument is a positive number (how do you really repeat a string a negative number of times?). At the third line, were we usually start writing our code, we don’t have to bother about the edge cases where count is a negative number or the string is null. This has now been taken care of.

I have two overloads to AssertThat, that I would like to share with you. First is AssertNonNull that does exactly that, makes sure that the argument is not null. The second one is usefull on strings when you need a string that is neither null or empty.

public static void AssertNonNull(this object argument, string message)
{
    argument.AssertThat(arg => arg != null, message);
}

public static void AssertNonNullOrEmpty(this string argument, string message)
{
    argument.AssertThat(s => !string.IsNullOrEmpty(s), message);
}

Happy coding!

I’ve set up the Visual Studio solution and started to write some of the Virtual Path Provider code. It is now, at the beginning of the project all the important decisions are made. “Should I unittest?”, “Are there any need for continuous integration?”, “Do I have to use Subversion when I’m the only programmer?”

I will get back to those questions regarding tools in a later post. Right now I will focus on the solution.

First up is a solution directory called Configuration. This will contain configuration files for all the different environments, development, test and later on production. Right now it only has the configuration for development and this is added as link from the other projects and copied on compilation. I like having configurations in a separate folder. It gives me better control over the differences between environments.

Main solution directory contains the source code and Test contains the same assemblies as Main, but with an added UnitTests at the end. Mixing unit test projects and the main source code always gives me headaches, and that is why i prefer this setup. I don’t like having too many solution directories, because it hides stuff away from you (as with regions in code), but in this case I do find it easier to look at the main source or the test code.

I’m not the kind of guy who writes his tests first. I’ve tried it but it doesn’t suit my style of programming. I like to sit with a blank piece of paper and think through the solution, writing code. The testing is just a way to do excessive refactoring and finding the bugs that you missed out when you first wrote the code. It works well for me, and most of my code come out defect free in the end.

• Mint.Configuration
  I like to have a configuration project in all my larger projects. There is only so much you can do with the Visual Studio Settings stuff and it will mostly end up being not enough. A real configuration SectionHandler is nice to have even if it is quite a lot of code to write to make it happen. I always reference this from App.config or Web.config to an external file that is easy to find and easy to handle.
• Mint.Data
  I’ve decided to use Entity Framework (from .NET 3.5 SP1) as DAL, so this is where my context and my entity classes will reside. At the moment, I’ve just generated some classes from the database schema, but this will be an interesting thing for me, since this is my first Entity Framework project. The reason to use EF and not LINQ to SQL is the promising way to expose the entities through web services which will save me a lot of time when I start coding the frontend (web application) of Mint.
• Mint.Web
  This will be the actual application. I want to have a web gui that is XHTML Strict, CSS 2.1 and fully featured with AJAX. I also have a huge priority for accessibility and will follow the guidelines for at least conformance level A. This is why I’ve chosen not to use the ASP.NET Forms, but instead go for the MVC-model that in this moment is at Community Preview 5. I expect it to go live before Mint is finished.
• Mint.VirtualPathProvider
  In Mint it will be very important that users can upload and handle files in a smooth way. That is why I’ve started to implement a virtual path provider. This resides in a namespace of its own, since it is such a decoupled entity. Before I’m finished with it, I have probably introduced Unity in this project to decouple this provider completely from the whole Mint core. Just think about it. Being able to replace the file storage system on the fly. That is really nice.
• Vanilla
  This is an assembly with some extension methods that have followed me around from one project to another. They are quite handy and I will go deeper into them in some other blog post.

A user in Mint should be able to upload his own files. He should upload images, css-files, xsl-files and maybe even video clips. In order to support this I will build a Virtual Path Provider where user files will be located.

Building a Virtual Path Provider is very easy. All you have to do is to override three classes in the System.Web.Hosting namespace.

• VirtualPathProvider
• VirtualFile
• VirtualDirectory

All those have perfectly comprehensible examples on MSDN for implementation.  It is a quite cool technology where you can have most parts of a website (including aspx pages) inside a virtual place, which could mean “stored in the database” or some xml-format, or i a zip-file.

I’m just going to use it for user files, so my implementation will first look for a “real” file on the hard drive, and after that, try to get the VirtualFile. A list of files and directories will be stored in a SQL database, and I think I will place the data on the actual hard drive as a file. I think it will be both faster and more manageable than having them as a blob in the database.

The following database schema came into mind

One of my collaeges att work told me that I should think about merging file and directory table because a file and directory is basically the same. It is just the relation that is different ie. a file can’t have another file as a parent. He’s probably right and I might have to think about changing the database model.

Hello! And welcome. This is the first blogpost here on the Mint Blog, and I’m going to write some about this blog and what it is for.

First of all, I’m a swedish software engineer that works for a consultant firm in Stockholm. I mainly work with Microsoft technologies (not that I have any preferences) and as any consultant; web applications. Those applications vary from corporate websites, CMS applications, intranets, extranets, customer service applications and web services.

I started to think about Mint a year ago, and that I wanted to build an application on my spare time. I had a pretty rough idea what this application should offer, but I don’t want to go into that in these early stages of its development. Over the year when I still hadn’t moved my plans into creating a Visual Studio solution yet, the application idea grew and got much more mature in my head.

Now it is time for the actual implementation. I expect that it will take about a year to get a first beta version out there, so I got this idea for a blog where I could report about the development and how it goes. I will write about design decisions, security, technologies that I will use, etc.

This blog will nog only be for interested people in my vicinity, but also for myself to keep track of the development. Also, some problems are much easier to solve when you write them down and describe them in their essence.

Hope to see you around.
Over and out!