Plan for 2015: fuck up the comfort zones that survived 2014.— Mathias Verraes (@mathiasverraes) January 1, 2015

The message struck a chord with me, so I wrote it down somewhere, and thought to myself: "It's time to blog again". That obviously didn't work out very well.

However, looking back on this year, I'm pretty happy with the number of comfort zones I attacked. A lot of the things on this list scared me, but I'm so glad I said yes to every one of them. There's a lesson in there.

Speaking at XPDays Belgium and AtBru

Together with Erik, we hosted several workshops around "Splitting up a problem into microservices". Running these sessions has been a lot of fun, but don't let yourself be fooled by it's technical appearance. Every time we ran this session, we got surprised by the direction it took.

Organizing the Belgian software craftsmanship community

Our community has grown a lot since its start, and I'm very proud to be an active part of it. Last year, I started helping out by hosting some of our monthly open spaces, and organizing technical talks.

Thanks to Gien we rebooted the habit of giving lightning talks, and I invite you to come talk about anything you're passionate about in software at our next open space.

Building a pet project in F#

I started learning F# last year, and I'm really glad I did. F# is a great place to start learning Functional Programming, with a vibrant and very helpful community.

A very fun way to start learning something, is by building cool stuff you can use yourself. So I built a little picture archiver in F#, which automatically organizes family pics on my nas.

Also, if you're looking for a way to bring F# into your daily work, I can recommend taking a look at FAKE. Introducing this at my current client has improved the readability and maintainability of our build and deploy scripts a lot. Even if you don't know F#, it's really easy to get started with this.

SoCraTes BE 2015

Organizing the very first Software Craftsmanship and Testing unconference in Belgium was quite the challenge, but it was amazing.
Three days of getting together with over 50 developers from 8 different countries to learn, share and practice software craftsmanship.

I had such a great time, and I can't thank enough everyone who made this experience great. Here are some pictures to make you jealous if you weren't there.

{<11>}

Facilitating a Global Day of Coderetreat

Facilitating this one didn't go anything like I expected. I'm used to doing code reviews and doing technical coaching, but this was very different. My facilitation style was much more forgiving and less "brutal" than I thought it would be. It was fun letting people find their own way, make mistakes, and learn from them.

There were a lot more people doing Functional Programming than previous years, which we'll have to start taking into account for Global Day of Coderetreat 2016!

Finishing my first year as freelancer

Probably the best decision I ever took for my career, altough I still think this is a very personal decision. A lot of people have asked me whether I'd recommend it, but it's not the panacea some people believe it to be.

For me, the freedom and responsibility were exactly what I needed. It's been a lot of work and stress at times, but I'd definitely do it again.

In retrospect, a lot of things on this list still kind of scare me, but some are starting to feel comfortable. And to quote one of my favorite books of last year:

The safety zone has moved. The propaganda has been exposed, and the old promises have been broken: Conformity no longer leads to comfort. But the good news is that creativity is scarce, and more valuable than ever. So is choosing to do something unpredictable and brave: make art.

Disclaimer: I am not in any way a
medical doctor, seek advice from
qualified medical professionals.
This is a brief history of my back
problems, and how I'm handling them.

I've been having lower back pains for almost ten years now, but they gradually got worse when I started my professional life as a developer. It started out with a chronic, nagging discomfort rather than an actual pain. It appeared without warning every couple of weeks or months and disappeared just as suddenly.

I had x-rays which confirmed that my spinal discs were a bit too close together, but nothing that could directly explain the discomfort. I got nothing more than a "Just a bad back, try some exercises, watch your posture", but nothing really concrete to work with. Since the problem was intermittent without apparent cause, there was no treatment as well. The only thing I could do was try to maintain a better posture. Which I usually did as soon as the pain appeared - too late.

Two years ago I became a father. Being a father rocks, but isn't really that nice to your back. Lifting up my son all the time made the pain come back more often, and since no father wants to leave his son down, I decided to reevaluate my problem and started with some physiotherapy. The physiotherapy actually made things worse after some bad manipulations, and a couple of weeks later I checked into the hospital with sciatic pains and a hernia. After getting an injection - infiltration, they call it - the sciatic pains went away, but the nagging discomfort came back soon enough.

Attending a back school

Shortly after the hernia, I was recommended to join a back school. Doing this was the best thing I ever did for my back. I was taught how to strengthen it with simple exercises I could do at home, but also showed how to maintain my posture, relax my back and make it more flexible. They also immediately noticed I had hyper-mobility, which means looser joints and tendons, which leads to less support for my back.

The standard exercises didn't seem to cut it for me, since the nagging pain kept coming back and was atypical for regular hernia pains. Despite the hyper-mobility, they traced the pain back to a shorter hamstring. I'm pretty sure if I hadn't joined the back school, I'd have been unaware of both the hyper-mobility and the hamstring problem.

Starting Strength

I read about Starting Strength a year ago, which is workout routine developed specifically to help you start lifting weights. It focuses almost exclusively on lifting free-weights and doing exercises with a long range of motion. The idea is that lifting weights like that should develop more useful muscles and a stronger body when compared to doing isolated exercises on machines.

After attending the back school for a couple of months, I felt my back was strong enough and started Starting Strength. I tried going to the gym a couple of times in the past years, but always quit after a couple of sessions. Even though Starting Strength is a rather simple routine, it is quite challenging and it got me coming back 2 to 3 times a week for the last couple of months now.

More importantly, I have the feeling it's actually working for my back ache. My body feels definitely stronger, my hamstrings get stretched regularly because of the squats and deadlifts, and the pains haven't appeared since I started the routine.

If nothing else, having a stronger body in general means I no longer worry about lifting my son out of bed every time or being unable to do my job and hobby at the age of 30 because of crippling back pains.

The takeaway

If you're having back pains, try joining a back school. It's more likely you'll find your specific problem and treatment when you're exercising in a room with multiple experts for months ( 6 months repaid in Belgium ) than going to a single therapist for massages for a couple of weeks - it still took 2 months to figure out my problem in the back school.

If you want to make your body stronger, take a look at Starting Strength, but consult your medical doctor first. I started only after consulting both my general physician and the people from my back school. It's not a panacea either, it seems to work for me but I might switch in the future if I find something that will benefit my back more. There are lots of other workouts and routines that might work better for you. Most of these fitness sites seem to have a very active forum and a lots of people willing to give you advice.

Don't settle for the default general answer you get when first diagnosed with back pains. Chances are you can really do something about it.

Related links

How to adjust your chair - first thing I do on a new chair

Everything You Know About Fitness Is a Lie - interesting article on fitness in general, mentions Starting Strength

Starting Strength Wiki

Starting Strength book

I’m working from a walking desk - with lots of references to why sitting is bad for you

Starting Strength book

If you have any questions or remarks, feel free to leave them in the comments or contact me @koenmetsu.

If you're new to distributed version control systems, I'd recommend you to order the free book (even the printed version is free!) by Eric Sink, Version Control by Example. It has a great workflow comparison of Subversion, Mercurial (Hg) and Git and gives you some insights on why you should use a distributed version control system.

Why you should learn the command line of your DVCS

Next to the advantages of a distributed vcs, using the command line is:

• blazingly fast
• very user friendly ( especially Hg )
• incredibly powerful (especially Git)
• amazingly flexible (especially Git)

The problem with graphical shells for a command line vcs is that as a new user it's harder to understand the version control system underneath. The graphical shell is trying to shield the user from the internals with "easier" jargon and automatically performing steps for the user ( without the user realizing this).

On the work floor this custom jargon can cause confusion amongst developers using different graphical shells, when in essence they're using the same version control system. Using Git or Hg via the command line gives you an experience closer to the inner workings, and will enable you to use the full power of those systems.

Starting with Mercurial

If you're just starting out with a distributed version control system, I'd recommend using the command line with Mercurial for it's user-friendliness and easier learning curve (see "Other References" for a good example). Joel Spolsky has a wonderful tutorial on Mercurial called Hg Init. You should totally follow it if you're interested in starting out with Hg or any dvcs.

If you're still a bit uneasy about going full command-line, try using the command-line together with TortoiseHg (in my opinion the most mature and user friendly free GUI for Mercurial). This way you can actually see your changes from the command line appear simultaneously in the TortoiseHg Workbench. The Workbench also shows the commands you made in the GUI in the output log, so you can see which command you have to use the next time you want to merge.

Having a GUI as a visual guideline and being able to switch easily between GUI and command line ( for the more complicated commits ) helped me a lot during my initial dvcs learning.

Moving to Git

Once you've got the taste of working with the command line via Hg, you should definitely try out Git. It's local branching model is more light-weight and intuitive, and doing complicated commits from the command line is much easier.

With Git's staging model, you can select files individually and even select separate lines of a file for a commit, which means you can now properly commit the lines of code you changed for story/ticket XYZ, and keep your commits smaller and cleaner.

On top of that, Git feels like it was made purely for command line usage. Need an example? Take a look at this graph Git can generates.


I've been using Git at home for about half a year now and 2 months with my employer, and not a single time have I felt the need for a GUI.

Honestly, the first few weeks ( especially with Git ) you're going to do a lot of lookup work. Git still suffers from a major curse of knowledge, especially for us Windows users, so I'm trying to add my bit to help you on your way ;-)

If I've got your attention, hold on to the next post, in which I'll explain in detail how to set up and use Hg and Git with the least possible friction for us Windows users.

Other References to get you started

For a good comparison between the learning curves of Git and Hg, take a look at this answer on stackoverflow, it explains why Git is MacGyver and Mercurial is James Bond

[Git for beginners: The definitive practical guide] on StackOverflow(http://stackoverflow.com/q/315911/367388)

Pro Git, which you can download for free in PDF, mobi or ePub format.

If you're new to distributed version control systems, I'd recommend you to order the free book (even the printed version is free!) by Eric Sink, Version Control by Example. It has a great workflow comparison of Subversion, Mercurial (Hg) and Git and gives you some insights on why you should use a distributed version control system.

Why you should learn the command line of your DVCS

Next to the advantages of a distributed vcs, using the command line is:

• blazingly fast
• very user friendly ( especially Hg )
• incredibly powerful (especially Git)
• amazingly flexible (especially Git)

The problem with graphical shells for a command line vcs is that as a new user it's harder to understand the version control system underneath. The graphical shell is trying to shield the user from the internals with "easier" jargon and automatically performing steps for the user ( without the user realizing this).

On the work floor this custom jargon can cause confusion amongst developers using different graphical shells, when in essence they're using the same version control system. Using Git or Hg via the command line gives you an experience closer to the inner workings, and will enable you to use the full power of those systems.

Starting with Mercurial

If you're just starting out with a distributed version control system, I'd recommend using the command line with Mercurial for it's user-friendliness and easier learning curve (see "Other References" for a good example). Joel Spolsky has a wonderful tutorial on Mercurial called Hg Init. You should totally follow it if you're interested in starting out with Hg or any dvcs.

If you're still a bit uneasy about going full command-line, try using the command-line together with TortoiseHg (in my opinion the most mature and user friendly free GUI for Mercurial). This way you can actually see your changes from the command line appear simultaneously in the TortoiseHg Workbench. The Workbench also shows the commands you made in the GUI in the output log, so you can see which command you have to use the next time you want to merge.

Having a GUI as a visual guideline and being able to switch easily between GUI and command line ( for the more complicated commits ) helped me a lot during my initial dvcs learning.

Moving to Git

Once you've got the taste of working with the command line via Hg, you should definitely try out Git. It's local branching model is more light-weight and intuitive, and doing complicated commits from the command line is much easier.

With Git's staging model, you can select files individually and even select separate lines of a file for a commit, which means you can now properly commit the lines of code you changed for story/ticket XYZ, and keep your commits smaller and cleaner.

On top of that, Git feels like it was made purely for command line usage. Need an example? Take a look at this graph Git can generates.


I've been using Git at home for about half a year now and 2 months with my employer, and not a single time have I felt the need for a GUI.

Honestly, the first few weeks ( especially with Git ) you're going to do a lot of lookup work. Git still suffers from a major curse of knowledge, especially for us Windows users, so I'm trying to add my bit to help you on your way ;-)

If I've got your attention, hold on to the next post, in which I'll explain in detail how to set up and use Hg and Git with the least possible friction for us Windows users.

Other References to get you started

For a good comparison between the learning curves of Git and Hg, take a look at this answer on stackoverflow, it explains why Git is MacGyver and Mercurial is James Bond

[Git for beginners: The definitive practical guide] on StackOverflow(http://stackoverflow.com/q/315911/367388)

Pro Git, which you can download for free in PDF, mobi or ePub format.

As part of improving my coding skills, I lot of the time I spend is in reading blogs and articles. However, only reading up on technology will only take you so far. Trying out some new technologies like NoSQL or SignalR is fun as well, but usually doesn't go any further than a few small POCs. It hardly covers all the aspects of software development we "meet" in real life.

This year I decided to actually create stuff. The premise for this was simple: I wanted to use technologies that are new for me, or learn new ways to use them, everything had to be open-sourced, and probably most importantly: it had to be fun.

New technologies

NuGetFight was created with ASP.NET MVC 3, along with an HTML 5 canvas to create and animate the bar graphs. We decided not to use a library to create these bar graphs, but instead rolling our own. This is not something I'd recommend for real business projects (use a framework instead), but it was great fun and frustration as we were learning all about the different ways to animate the canvas with javascript. I learned a lot of new stuff there, and I'm pretty glad with the results as well.

We wanted to create some very basic and light-weight logging of the fights, for which we ended up using MongoDB, a document-oriented NoSQL database I talked about earlier on this blog. We used MongoLab to host a free database in the cloud. This was very lightweight like we wanted to, but we also had some minor issues with it that you would never notice without actually using it in production. In the end however, I am very pleased with how it worked out, and would definitely use this setup again.

We also used the NuGet OData API to query the packages, which was a breeze to use, and hardly worth mentioning here as it's as simple as consuming a common webservice. The most important thing here is that I learned how invaluable LinqPad really is if you want to try out some queries to an OData feed, before you actually start coding them. We had some issues with the data coming through, and LinqPad was a very useful tool to verify and fix this little bug on our side.

And finally, as we are working from geographically very different locations, a distributed version control system like Mercurial seemed like a natural fit. I've known and used Mercurial and Git for a little while now, but had never used it this extensively and actually, you know, distributed. We used BitBucket as our central repository, and it worked great in every single way. The peace of mind local checkins give you, the ease of merging, light-weight branching, ... Once you get used to DVCS you wonder how you ever coped without. If you're working on a pet project in your spare time right now, even if you're working alone on this, I can fiercely recommend learning about DVCS and using it together with a hosting like BitBucket  or Github.

Overcoming fear of being in the open

We decided on BitBucket because it can host Mercurial ( which is easier if you're new to DVCS, in my opinion ), and because it allows for repositories to be private. Putting our code out in the open for the first time is something we were reluctant to do, and BitBucket gave us the opportunity to develop in a private repository, before opening it up to the public when we were ready for it.

For me, the decision to open-source NuGetFight and our future projects was not necessarily made just to contribute to the community, or because we expected a lot of pull requests from the community. If the community does benefit from our code, all the better, but on a personal level the decision was much more about overcoming the notion that all code should be perfect before putting it out in the open.

I see a lot of developers having great ideas, but keeping their projects and code to themselves only because "their code is not good enough". This is a shame, and I encourage you to share your pet projects regardless of how good your code is.

More fights to come

I had a lot of fun developing NuGetFight, and we will definitely have fun further improving the code and making NuGetFight better. We already implemented integration with SymbolSource after a suggestion from @TripleEmcoder, so any feedback or ideas you might have for NuGetFight are welcome.

We've also got a couple of very exciting features coming in the next week(s), so keep in touch.

I'm not going to talk about whether or not NoSQL is right for you, which NoSQL implementation/provider is best or whether or not NoSQL is better or worse than SQL. I'm just having some fun with it, and seeing how easy this goes. I will focus on document store databases and C# .NET.

Personally, I'm also hoping to find out if NoSQL is a better match for quick and dirty personal projects than Plain Old SQL.

Choosing a NoSQL for .NET

After reading up on what NoSQL databases are most popular for .NET, the choice came down to RavenDB, CouchDB and MongoDB.

RavenDB

RavenDB is made by Ayende ( among others, I suppose ), and has the reputation of having a very nice and clean API plus a very good-looking management application made in Silverlight ( perhaps Silverlight isn't dead yet after all ). RavenDb however has a commercial license for non-open-sourced projects, and since I wanted to use NoSQL for one of my personal ( non-OS ) projects, I decided to let this one go for the moment. It's definitely worth taking a look at though, so it stays on my list for later projects.

CouchDB and MongoDB

This left me with the other 2 competitors. I didn't put much effort into comparing the two in terms of functionality since I'm only exploring the the subject of NoSQL, and decided on a "community knows best" approach.

A quick NuGet Fight ( somebody should make this into a website, which we now did ) gave the advantage to MongoDb ( aka Mongo ), and off I went.

I usually don't let a simple NuGet Fight decide which libraries I use, but since this is only experimentation, it's good enough for me.

Setting up Mongo ( the very easy way )

The whole point of this exercise was to have a no-friction-at-all experience. Setting up a mongoDb locally? Aaah, friction, get it away!

But seriously, I wanted none at all.

Mongo in the cloud

This matches my philosophy of "somebody probably already did this better than me", and since a lot of these providers offer a free sample of their services, how much less friction can you have?

I decided to use MongoLab, mostly because their free offer was the best I could find. They offer 240MB for free, all you need to do is sign up.

How can you resist?

Creating your database

MongoLab offers a nice web interface for all creation and management of your MongoDB.

Creating a new database is easy, you can even choose your provider. I also like the fact you can get different pricing schemes for different databases. For now, we'll test our luck with the free version.

Et voila! We have our new database. You can see the connectionString in the overview, which we'll use in our application later.

All we have to do now is create some collections ( aka tables in other environments ) to put our data in. We can do this via the web interface as well as in code. For now, we'll stick to the web interface.

I want to create a small exhibitor website for this demo, but I don't know which properties I will store for each entity. With document store database, you do not have to define any columns on your table (because there is no table, only a collection of documents), so I can choose  what to store later instead of having to decide right now. This once again removes some friction, and more importantly: it delays design choices to when I'm ready for it.

Consuming Mongo

A small controller and an entity class later, and my little expirement is already taking form.

public class HomeController : Controller
{
    readonly MongoServer server;
    readonly MongoDatabase mongoDb;
    readonly MongoCollection<Exhibitor> exhibitors;
    public HomeController()
    {
        server = MongoServer.Create(string.Format("mongodb://{0}:{1}@ds031587.mongolab.com:31587/myfirstmongodb", ConfigurationManager.AppSettings["MongoUser"], ConfigurationManager.AppSettings["MongoPwd"]));
        server.Connect();

        mongoDb = server.GetDatabase("myfirstmongodb");
        exhibitors =
           mongoDb.GetCollection<Exhibitor>("exhibitors");
    }
    public ActionResult Index()
    {
        return View(exhibitors.FindAll());
    }
}        

Conclusion

So far, everything is still going well for me. I've set up a small database in a couple of minutes and got a simple piece of code working.
Next post, I'll be going deeper into the code and create a simple CRUD application using our newly created Mongo database.

Begin this year, I decided to pick up blogging again. I had some good ideas to blog about (most of which I probably forgot already), but one thing kept me from doing so: WordPress.

I think WordPress has a great platform, but I've never found the actual blogging to feel natural. This is mostly due to the online editor which is just really, really awful to work with.

The biggest dealbreaker for me? The lack of control.

Moving away from WordPress was a real pain at times. The plan involved using BlogML and Disqus to make the move an easy one, however nothing worked out of the box.
If you're interested in reading the full story on moving away from WordPress, I suggest you read this post by Kevin Pelgrims. He kept a nice log of everything that did and didn't go according to plan  :)

Looking at alternatives

Looking at alternative blog engines, I met OctoPress, a static site generator which looked really promising (all the cool Ruby kids use this today). I kept holding on to the idea of baking vs frying my site because I liked the philosophy of not having to go to your database for every page view (even if that number is not very high).

However, OctoPress missed the ability to publish from anywhere (ie: online) and had a steep enough learning curve to keep me away from it. I was very excited about Code52's .NET open-source alternative called Pretzel, but this too missed the ease of use I was looking for.

Enter FunnelWeb: Full Control meets Ease of Use

When I met FunnelWeb, I found what I was looking for:

• Easy editing with MarkDown, which you can easily edit with MarkPad
• Good looking source code in posts with Prettify
• Support for themes, and a good number of nice and clean themes available
• FunnelWeb's source code (in .NET) looks really good, so I can change anything I want

In short: lots of control and still easy to use.

The result

I'm really liking my new blog! Discussions and analytics have been outsourced to Disqus and Google Analytics, and the fact that FunnelWeb has a BlogML export means I can move away from it anytime I want. This post was written using MarkPad, which is a breeze to use and gives me the content without having to mess around in some badly-generated HTML.

It's exactly this feeling I was after: being enabled by my tools, instead of being hindered by it. I look forward to using FunnelWeb for my further blogging, as well as contributing to it =)

This probably sounds like a broken record to you, and though I could go on all day presenting you with examples, I’d rather suggest an alternative: Refactoring.

Refactoring is a word mostly spoken in the domain of TDD, from its well known mantra “Red - Green - Refactor”.  However, refactoring does not belong exclusively to the exotic world of TDD, which can spark fear in the minds of many developers not familiar with TDD.

Refactoring has been the topic of many books, and rightfully so. The list of possible refactorings is a long one, but many of these techniques are really quite simple.
And more importantly: it can significantly improve your code base.

Yes, refactoring can improve readability and flexibility, which in turn improves maintainability. Improved maintainability leads to less money spent on fixing bugs, which leads to happy customers, which leads to less picking on us poor developers, a more satisfying job and ultimately: improved health by reduced stress. See that? All benefits! =)

When done, refactor

So why do we write less readable, less flexible code than we possibly can?

With deadlines and project managers breathing down our neck, it is easy to conveniently forget the refactoring part and move on to the next task at hand. We hope to never see that piece of code again, or think that the code we just wrote is “pretty ok enough" to understand 6 months down the line ( hint: it isn’t ).

So when you’re leaving the campground, be sure to leave it cleaner than you found it, and clean up after yourself. Start off by asking yourself the following simple questions:

• Could my field names be any more meaningful?
• Are my method names truthful? ( ie: don’t lie )
• Do I repeat myself unnecessarily?
• Does my code need any documentation? ( answer = yes )
• Do I still need that piece of commented code? ( answer = no )
• Could any other developer read this code and on sight understand what it does?

Contemplating about these things alone can be the first step towards a cleaner codebase and a happier life in code, knowing you’ve become a better developer. Next time you have to change something in that particular code file, you will thank yourself you took 5 minutes to clean up.

So while you’re at it, why not also improve your codebase with:

• Checking if your code is SOLID
• Programming to interfaces instead of     implementations?
• Writing meaningful tests?

There are so many other things you can do to improve your code. Keep reading about ways to code better, and remember to refactor and clean up your code whenever you’re done with a little piece of code.

ConclusionEven if you won’t have to maintain your code in the future ( never say never ), clean up your code when you're done with it, even if it's just for good programmer’s Karma and the next guy that might have to maintain it.

Stay realistic: your code will never be perfect. But writing bad, cluttered or unreadable code willingly or knowingly should never be an option, and since you have read this post, you now no longer have any excuse. ;-)

A number of posts and concerns about Code Contracts revolve around the static checker, and how to make it prove that certain contracts are correctly followed.
Sometimes this can be quite challenging, though I see this more as a pro than a con.
Making you think twice (or more) about your code is never a bad thing, really.

But for those who desperately seek salvation in their quest to annihilate all static checker warnings ( with or without Contract.Assume() ), I would recommend the following guidelines:

1. Install the Code Contracts Extension for Visual Studio 2010.
2. Use Reflector to see Code Contracts on the Base Class Libraries.
3. Use Pex to automatically test your methods.
4. Split more complicated statements into multiple lines.

1. Code Contracts Intellisense.

Install the Code Contracts Extension for Visual Studio 2010. This brings contracts right to your Intellisense as you type, as well as some other handy features.

2. Use Reflector to see Code Contracts on the Base Class Libraries.

When you use the static checker, you might notice that a lot of methods in the BCL already have contracts defined on them. For example, the IList.Clear() method has a postcondition stating that the Count property will be equal to zero.

These contracts are not magically inferred from the BCL assemblies, but rather found in the Contract Reference Assemblies that are included with the Code Contracts installation. These assemblies are found under <%YourProgramFiles%>\Microsoft\Contracts\Contracts.NETFramework\v4.0.

Using Reflector you can browse through these assemblies, which contain nothing but Contracts. Although a lot of methods already have contract defined on them, the BCL contract assemblies still have a lot of contracts missing.
Using Reflector on these assemblies, you can find out for yourself why you keep getting a warning that a certain "contract cannot be proven".

3. Use Pex to automatically test your methods

Pex provides a way to create parameterized unit tests to see which input causes your method to violate a contract. Actually, it does a lot more than that. Way too much to elaborate on in this post.

To make a long story short, Pex can automatically unit test your parameterized methods with different kind of inputs ( without resorting to brute-force). What's great about this, is that it works in combination with Code Contracts, and can actually suggest contracts for you.

The documentation pages includes a nice tutorial on how to use the power of Pex in combination with Code Contracts.

4. Split more complicated statements into multiple lines.

Although simple, quite effective.

A lot of concerns surrounding the static checker's inability to prove something are easily solved by this one. Some developers have the tendency of joining multiple statements in one big statement. This can improve readability and shorten your code files, but also confuse you about which statement the static checker is complaining about.

Split your big statement into several lines, and it will become more clear which method the static checker is complaining about.

For example:

StringHelper.CleanUrl( new PageManager("BasePage.aspx").GetFullUrl()) ;

has a lot of places where there could be a nullreference occurring. Splitting this into several statements would make this a lot easier for you to see what method gives you the problem. ( This is actually general debugging advice, not just for the static checker )

Conclusion

A lot of static checker warnings will easily be solved by following one or more of the solutions provided here, others will require more digging through your own code. There will be times when you will still need to Assume some conditions, as the static checker will never be able to statistically proof every line of code you write.

However, hopefully these guidelines will aid you in proving your contracts to the static checker, further improving your code base with better documented behavior, promises and expectations.

This new extension brings a couple of cool new features that help you while developing with Code Contracts.

See contracts as you type

Just start typing a method with contracts, and they will be listed right beneath the description of the method.

The great thing about this is that it works for methods in the BCL as well as your own methods.

See inherited contracts

Contracts that are inherited show up above your methods. It's a helpful visual reminder of the contracts that are defined on the interface or class you're inheriting from.

This way you can easily add preconditions and postconditions without having to look back and forth to see which contracts are already defined.

And it doesn't actually add text to your code file, it's just an adornment which you can easily click away too.

See contracts for external assemblies

Another helpful addition is being able to see contracts of external assemblies. The contracts are visible in the metadata file you see when you 'go to definition' of a member of a class of which you don't have the source.

This can also be disabled by a simple click of a button labeled "Hide all contracts" ( See, it's all obvious ).

Conclusion

Before this extension, visibility of the contracts was one of my major concerns with Code Contracts. Not being able to see contracts as you type made you rely on the static checker to see what contracts were defined on your code. This extension is a great improvement and incentive to using Code Contracts. It's only just released, but I'm loving it already!

Great! So how  can you have a piece of this?

It's easy!

1. Install the latest version of Code Contracts
2. Install the Code Contracts Editor Extension for Visual Studio 2010.
3. Enable Code Contracts and choose 'Build' for 'Contract Reference assembly' in the Code Contracts properties pane.
4. Build your code

And you're ready to see your contracts showing up as you type! Have fun =)

Something that troubles starting users is the fact that you have to add a lot of contracts 'twice or more'. I've recently seen this issue appear on stackoverflow as well. You can check out the specific code sample there, but I'll lay it out for you here as well.  Suppose you have a public method calling a private method, both of which accept an input parameter of type string.

public void ValidateString(string givenString)
{
    Contract.Requires(!string.IsNullOrEmpty(givenString));

    var isValid = SomeValidatingMechanism( givenString );
}

private bool SomeValidatingMechanism( string toValidate )
{
    return toValidate.Contains("someImportantValue");
}

I've immediately added a precondition to the ValidateString method, to make sure the caller never wrongfully provides me with an empty string and make my application crash to death.  Now when you let the static checker loose ( and you've set it to check for possible nullreference occurrences), it will whine about my private method calling Contains on a possible null value. What's that all about? I added a precondition to the public method, so the toValidate string can't be empty, right?

Solution

Well, actually the static checker is really thinking ahead here. First of all you've got the static checker which cannot prove that the the toValidate string isn't actually null. You know it, because you can clearly see from the code above. But the static checker cannot mathematically prove that you did not alter the toValidate string after it entered the public method. For all it knows, you might have maliciously set it to be null right after it entered the method, trying to crash my application once again!  This might seem like a limitation to the static checker, but imagine you made some calls to an external API before you called the private method here. The static checker is just really playing it safe.  Secondly, for now you might have only one call to the private method, but what happens when you add more calls to it from methods which didn't have a precondition like the one above? Adding a precondition to the private method now can prevent future errors and possibly lots of debugging.

public void ValidateString(string givenString)
{
    Contract.Requires(!string.IsNullOrEmpty(givenString));

    var isValid = SomeValidatingMechanism( givenString );
}

private bool SomeValidatingMechanism( string toValidate )
{
    Contract.Requires(!string.IsNullOrEmpty(toValidate));
    return toValidate.Contains("someImportantValue");
}

With the above code the static checker's warning is gone, and your code feels safer once again =) You can sleep tight and never worry about some co-developer calling your private method with an empty string.  So no, the static checker isn't really that thick, it's actually quite smart and following it's advice can often lead to better and safer code.

Code Contracts is a language-agnostic tool that provides you the power of Design By Contract development. In short, it enables you to make statements about what your code expects and delivers. It's a great way of telling whether or not your code does what you expect it to do.

Actions speak louder than words, so let's bring in an example: the BankAccount class.

public class BankAccount
{
    public decimal Balance { get; set; }
    public double InterestRate { get; set; }

    public void Withdraw(decimal amount)
    {
        Balance -= amount;
    }

    public void Deposit(decimal amount)
    {
        Balance += amount;
    }

    public void AddInterests()
    {
        var interests = Balance * (decimal)InterestRate;
        Balance += interests;
    }
}

A real simple class that should speak for itself. It maybe could use some comments, DDD or better logic, but it'll do for this post.

Adding preconditions

Preconditions are a way to define what state your application must be in at the start of execution of a called method. They're all about telling what you expect from someone calling your methods.

Let's take the Withdraw method: someone withdraws money from their account. We might have the following expectations:

• If you withdraw money, you should at least have money on your account.
  
• You have to withdraw some money, which means more than nothing ( else it wouldn't be really withdrawing, would it? ).
  
• You aren't allowed to withdraw more money than you have.

All of these expectations can easily be converted to preconditions in Code Contracts, by using the Contract.Requires method.

public void Withdraw(decimal amount)
{
    Contract.Requires(amount > 0);
    Contract.Requires(Balance > 0);
    Contract.Requires(Balance >= amount);
    Balance -= amount;
}

The nice stuff is that you're not only defining the state your application must be in, you're also defining behavior here.

Adding postconditions

Postconditions define what state your application should be when it leaves the called method. This is the part that's all about delivering promises about your code, as well as checking if the method did what you expected it to do.

For the Withdraw method:

• We state that after we withdraw money, the balance  of the bank account won't be negative.
  
• We also state that after the withdrawal, the balance will be the starting balance ( when we entered the method ) minus the amount we withdrawn.

Once again, the postconditions are easily converted to contracts. The Contract.OldValue() represents the value of a certain field or parameter as they were in the beginning of the method.

public void Withdraw(decimal amount)
{
    Contract.Requires(amount > 0);
    Contract.Requires(Balance > 0);
    Contract.Requires(Balance >= amount);
    Contract.Ensures(Balance == Contract.OldValue(Balance) - amount);
    Contract.Ensures(Balance >= 0);

    Balance -= amount;
}

The second statement here seems pretty obvious because of the actual code following the contracts, but a lot of times this code will obviously be quite more complicated.

Isolating object invariants

Object invariants are conditions on an object which should be true at all times that object is visible to a client. They express the conditions under which the object is in a "good" state.

As good programmers we try to prevent writing the same code twice, and if we look at the preceded code we notice the balance must always be greater than zero.

For the balance to be in a good state, it must never be zero.

We can isolate this contract by creating a method that contains Contract.Invariant() statements, and decorate this method with the ContractInvariant attribute.

[ContractInvariantMethod]
private void EnsureBalanceIsPositive()
{
    Contract.Invariant(Balance > 0);
}

All the invariants will be checked at the end of every public method. So now we added these, we no longer need the preconditions regarding the balance being greater than zero.

Conclusion

Although this example uses really simple code, by using Code Contracts we made it exactly clear what this BankAccount can and cannot do.

Your code can become immensely more complicated, new developers can join your project but by defining the behavior of this class by contracts, they will immediately recognize what the class does.

Ideally we would define the contracts on an interface or base class, so deriving classes would all share a base behavior, but that's out of scope for this post. =)

For more info on Code Contracts, visit the homepage here.

Google Maps is great for calculating a single route, but when you want things automated, you need some kind of web service for this, which Google doesn't provide.

A lesser known competitor of Google Maps is Microsoft's Bing Maps, which has a great SDK that you can get up and running in about 5 minutes, and 4 easy steps.

1. Create a Bing AppID

To be able to use the Bing Web Services, Microsoft requires you to request a unique key through this website ( you will need a Live ID ).

2. Add a Service Reference

Add the following service reference to your project: http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc?wsdl

3. Setting up your request

Next thing we do is set up the RouteRequest.

In this example I provide the latitude and longitude myself ( from a random geocoding site ), but you could use Microsoft Bing's or Google's geocoding service as well, to get the lat/long from any address you like.

I've added some commentary in the code, so it should be self-explanatory.

// Get a key at http://www.bing.com/developers/createapp.aspx
string key = "xxx";

BingRoutingService.RouteRequest request = new RouteRequest();
request.Credentials = new Credentials { ApplicationId = key };

// the actual waypoints, from start to finish.
request.Waypoints = new Waypoint[]
{
  // Brussels
  new Waypoint(){ Location= new Location(){ Latitude = 50.8462807, Longitude= 4.3547273}},
  // Paris
  new Waypoint(){ Location= new Location(){ Latitude = 48.8566667, Longitude= 2.3509871}},
};

// For the international crowd, you can also switch this to miles.
request.UserProfile = new UserProfile
{
  DistanceUnit = DistanceUnit.Kilometer
};

// some optional parameters
request.Options = new RouteOptions()
{
  Mode = TravelMode.Driving,
  Optimization = RouteOptimization.MinimizeTime
};

4. Getting the results

Last thing on the to-do list is setting up our RouteServiceClient. This will send the actual request, and get the results back in a nice RouteSummary object.

RouteServiceClient client = new RouteServiceClient();

RouteResponse response = client.CalculateRoute(request);
RouteResult result = response.Result;
Console.WriteLine(result.Summary.Distance);

The distance will be in the unit specified in the UserProfile object.
The RouteSummary object will also contain the time needed to drive in seconds.

If you like you can even get the full route path from the RouteResult object, and a lot more, but I'm not going to be able to cover that in a 5 minute post ;-)

"Error 1603: A fatal error occurred."

Well that about says it all, right...?

After a lot of googling and frustration, it seemed that my previous installation of STM.NET caused this error.

I should have remembered that  "the STM enabled version of Microsoft .NET version 4.0 and official versions of .NET
version 4.0 are mutually exclusive, and cannot be installed simultaneously on the same computer".

Uninstalling STM.NET was not as easy as I thought. I assumed the almighty internet would have answers, but no dice. I spent  about a day and a half of trying almost everything : .NET Framework Cleanup tools, uninstalling anything with '.NET or 'Visual' in it's name, registry cleaning, manually removing folders from the Windows folder  ( I got desperate ).

Finally, I found the answer, thanks to an old Microsoft Support article.

1. Go to : Start > Run > type 'Installer', press enter
2. Right click on the column header and add the 'Comments' column
3. Sort alphabetically and search for 'Microsoft .NET Framework 4 Client Profile Beta 1 enabled to use Software Transactional Memory...'
4. Right-click and uninstall!
5. Reboot ... just in case =)

This should enable you to succesfully install the 'regular' .NET Framework 4 Beta 2 and enjoy the new Visual Studio 2010 Beta!