Tuesday, March 30, 2010

Is Entity Framework 4.0 ready for the real work?

This morning, on the Developer Days 2010, I did a talk on the current state of affairs of the 4.0 version of the Entity Framework, including a rough comparison with NHibernate 2.1. Apparently this is something that’s on the mind of many people. The room was supposed to accommodate a maximum of 80 attendees, but at least 30 people were standing in the back or sitting on the ground and 10-20 more were refused access. I think that counts as a success… Anyway, you can find the slides here and download the demo code from here.

During the day many attendees asked me about the final conclusion. So, is Entity Framework 4.0 ready for the real work?

Yes…because the designers are excellent for rapid application development and suitable enough for simple domain models that provide a one-to-one mapping to the database. Moreover, you don’t need to struggle with big bundles of documentation to quickly get started.

But…the Code First functionality in CTP3 is still too limited for serious Domain Driven Design. It simply misses too much concepts very common in mature OR/Ms like NHibernate and its fluent add-on Fluent NHibernate. Worse, there is no Go-Live yet, so you can’t use it in production systems yet.

Nevertheless, the choice between NHibernate and EF4 is not trivial and depends entirely on the context of your project. NHibernate is still my first choice, but looking at the progress Microsoft has made the last year or so, I’m confident EF will gain some ground soon…

My two days of fame at the Developer Days 2010

Some of you who have been visiting the Dutch Developer Days 2010 in The Hague today may have noticed the flyers and banners for promoting the new online version of the .NET Magazine. Those who already know me may have noticed that it’s me on those banners. 

Since the photographer spent a considerable amount of time setting up his photo studio at Aviva Solution, and the fact that he shot almost 100 pictures, I wanted to give him Marco Hofste, the photographer, some credits. You can find his portfolio over here.

Wednesday, March 24, 2010

The curious case of the unsolved extension methods

As part of my effort to improve the type-safety of Fluent Assertions, I’ve been investigating the possibility to use C# extension methods all the way. Unfortunately I think I’ve ran into the limitations of C# 3.0 (and C# 4.0 since it doesn’t add anything useful for this). Essentially, I’d like to do the following things.  

var someList = new List<string> {"hello world"};


someList.Should().Contain(s => s.Length > 0);

The first one is easy because it does not require any type-specific extensions and can be implemented by the following piece of code:

static class Extensions


    public static EnumerableConstraints Should(this IEnumerable subject)


        return new EnumerableConstraints();



public class EnumerableConstraints


    public ShouldConstraint(IEnumerable subject) { }


    public void HaveCount(int expectedCount)  { }


The second one is more tricky. In order for the Contain() method to take a lambda expression on a List<string>, it needs to know the actual type of items in the IEnumerable collection. We can fix that by changing the type of the subject parameter to IEnumerable<T> and pass the <T> type parameter to the class that exposes the actual assertion methods:

static class Extensions


    public static EnumerableConstraints<T> Should<T>(this IEnumerable<T> subject)


        return new EnumerableConstraints<T>(subject);



public class EnumerableConstraints<T>


    public void HaveCount(int expectedCount) { }

    public void Contain(Func<T, bool> predicate) { }


That solves our initial two requirements, so let’s add another one. I’d like to be able to use a lambda expression on any possible type. Something like this:

var dto = new FindOrdersDto { CustomerName = “blah”, MaxItems = 10 };
dto.Should().Match(d => d.MaxItems < 100);

The first idea that pops up in my mind is to add an overload of Should<T> to the Extensions class, like this:

static class Extensions


    public static EnumerableConstraints<T> Should<T>(this IEnumerable<T> subject) { }


    public static BasicConstraints Should<T>(this T subject) { }


Unfortunately, this overload takes precedence over the overload taking an IEnumerable<T> and breaks the first working example. That’s a real bummer. If only I could use a where constraint stating that the <T> does not  comply with a specific constraint. For instance

public static BasicConstraints Should<T>(this T subject) where not T : IEnumerable

I’ve also tried to change the HaveCount(), Contain() and Match() methods into extension methods on a single generic class ShouldConstraints<T> like this:

static class Extensions


    public static ShouldConstraints<T> Should<T>(this T subject)


        return new ShouldConstraints<T>(subject);



    public static ShouldConstraints<T> HaveCount<T, TItem>(

        this ShouldConstraints<T> constraints, int expectedCount) where T : IEnumerable<TItem> { }


    public static ShouldConstraints<T> Contain<T, TItem>(

        this ShouldConstraints<T> constraints, Func<TItem, bool> predicate) { }


    public static ShouldConstraints<T> Match<T, TItem>(

        this ShouldConstraints<T> constraints, Func<TItem, bool> predicate) { }



class ShouldConstraints<T>


    public ShouldConstraints(T subject)


        Subject = subject;



    protected T Subject { get; set; }


This compiles fine, but causes the compiler to complain about missing type parameters because it is unable to infer these from the usage. This forces us to use this rather ugly syntax:

var someList = new List<string> {"hello world"};

someList.Should().HaveCount<List<string>, string>(1);

someList.Should().Contain<List<string>, string>(s => s.Length > 0);

Other solutions that crossed my mind included testing the ability to define two extension methods with the same name and the same parameters but having different constraints such as:

public static EnumerableConstraints Should<T>(this T subject) where T : IEnumerable
public static ComparableConstraints Should<T>(this T subject) where T : IComparable

But this is, as I expected, not supported by C#.

The conclusion? Well, as far as I can tell, my problem is currently unsolvable…

Tuesday, March 23, 2010

ALM Practices Part 5: Checklists

What is it?
An (online) list of verification tasks to sign off as part of the delivery process of a newly delivered unit of work. Usually these include things that are often forgotten, or aspects that require explicit verification. See an example of such a list here.
Why would you do it?
Because quite often, things considered common sense, are overlooked anyhow. Browser compatibility is one example of this. Also, most teams have written down some form of project-specific rules and guidelines. However, writing something down and complying with them are two different things. So it may be wise to include the most important functional, technical or administrative guidelines on the checklist.
What’s the bare minimum you need to do?
  • Create a minimal checklist on the project site and adapt and extend it all along the project. Use it with important deliveries.
What’s the usual thing to do?
  • Use the checklist as a formal sign off document after finishing a use case, screen or user story.
How do you do that?
  • Store the checklist as a wiki on the SharePoint site associated with your TFS Team Project. This lowers the threshold for the team to change or update the checklist with new insights, and causes it to become a team effort for gaining high quality.
  • Make sure each entry on the list is short, concise and that it means the same for every member of the team.
  • If an entry on the list requires the verification of multiple aspects of the product, split the entry in multiple single-purpose entries. If you don’t, you risk the chance that people only roughly look at it and quickly sign off the corresponding entry.
  • Include the most important design guidelines and coding standard rules as individual entries.
  • Ensure that your team members complete one checklist per screen, use case or user story (depending on your planning unit) and file it either physically or on the project site.

Friday, March 19, 2010

TFS, ALM, what’s in a name?

In response to my posts on Peer Reviews, Unit Testing & TDD, and Common Code Layout, someone noticed that all these posts were part of my Team Foundation Server Development Practices series, but not every post actually mentioned TFS. Obviously, he was right. The reason for using the TFS prefix is that our company is heavily using TFS as a platform for supporting Application Lifecycle Management. Most of the practices I talk about include a lot of practical advice on how to get the most out of the TFS product suite. Nevertheless, I’ve renamed the series to ALM Practices to better emphasis the real purpose of it. So what’s planned?

  • Code Analysis & Coding Standards
  • Refactoring
  • Automatic Builds & Continuous Integration
  • Checklists
  • Work Item Tracking & Tracibility
  • Architectural & Technological Audits
  • Pair Programming

Monday, March 15, 2010

ALM Practices Part 4: Common Code Layout

What is it?

A collection of rules stating what a block of code should look like. These may include rules on where line breaks are required, how to place parentheses, how much whitespace to put before and after those parentheses, how many spaces to use when indenting and where to insert empty lines.

Why would you do it?

  • To allow developers to work on virtually any part of the code base without being confronted with another different layout. And even though this may seem like a feeble issue, I’ve seen firsthand how difficult it can be to navigate through a block of code which uses an entirely different layout.
  • To improve the reviewability of your code base. For the same reason another developer benefits from it, the reviewer needs to be able to easily scan code for often-made mistakes or other issues.

What’s the bare minimum you need to do?

  • Use a standard layout for the entire code base and remind everyone to adhere to it.

What’s the usual thing to do?

  • Use a product such as ReSharper and configure it in such a way that it will format your code automatically according to the standard layout.

How do you do that?

  • Together with your team, agree on a common layout and write it done somewhere such as your team site, preferably accompanied by a piece of example code that illustrates all aspects of the standard.
  • If another team within the company has already created something like that, consider adapting their standard. This eases the burden when team members move from one project to the other.
  • Consider buying a ReSharper licence and use its Code Style sharing feature so that all team members will automatically receive the most up to date version of the standard settings. It also allows you to reformat entire files, projects or even the entire solution with one click of the mouse.
  • Create a one-page cheat sheet with a block of example code that clearly demonstrates the proper layout and distribute it amongst the team members. Use it while performing a Peer Review.
  • Install StyleCop and use it for automatically checking the layout and the XML documentation according to a configurable set of rules.
  • Add compliance to this standard code layout to the project quality Checklist (I will blog about that later on) so that developers and reviewers don’t forget to check for it.

Friday, March 12, 2010

Speaking at the Microsoft Developer Days 2010

Thanks to all the voters who voted for my wildcard proposal on Entity Framework 4.0, I will be speaking at the Microsoft Developer Days 2010, again. Last year, the whole wildcard thingy was a bit fuzzy, but this year, the organization has gone through great lengths to seriously include us wildcard speakers in the entire planning process.

I’ll be speaking on March 30st, at 11:05. I’m not sure about the room number yet, but I do know it should be able to handle up to 80 attendees. Check out the most recent schedule here.

Now I still have to decide whether to move to Visual Studio 2010 RC before the conference. I probably have to to evaluate CTP 3 which is essential when looking at the Code Only features (oh, sorry, Code First), so might have to. Shame that we don’t have SIlverlight 4 yet in the RC build.

We are looking for new colleagues!

Even though Aviva Solutions is still a relatively young company and we too have ‘noticed’ the changes in the economic climate, but we’re still growing steadily. Consequently, we are actively looking for medior and senior developers that are willing to join us in the journey of becoming the best Microsoft-focused company in the Netherlands.

Obviously thorough knowledge of the .NET platform is of essential importance to every developer within our company. But we do see some differences in the areas people naturally focus on. These include:

  • Custom Development & Software Factories
  • Integration
  • Information Worker
  • Business Intelligence
  • E-Commerce.

That doesn’t mean you have to choose between one of them, it just means that you may favor one area over the other just now. I, for example, am leading the Custom Development & Software Factories theme including things like Application Lifecycle Management, Agile development and the many double-D practices (DDD, TDD, BDD). But I still keep an eye open for the things the other people are doing. This enables me to consider all options when challenged with a complex consultancy problem.

Regardless of your area of interest, if you're looking for a fresh change in your career, be sure to check out our career site. Aviva Solutions currently employs almost 40 professionals, and of course we do have an informal but professional work environment, and yes, we do offer competitive conditions. But what makes us different from all those other IT companies is the passion with which we engage any challenge, and the freedom and acknowledgement that our two CEOs offer us. And I’m not even going to start on the social event we have each year in some warm and sunny country...

Anyway, if you’re interested send me an email or call me at 0647-033908.

Friday, March 05, 2010

Fluent Assertions 1.1 has been released

It’s only a few days ago since we released the first version of Fluent Assertions, and we already have a new release. The reason for this is that the first release was just the public release of an internal set of classes that we’ve been using for a year or so. But this week, we've worked hard to add some important missing features that we really needed, and also improve resilience against illegal arguments such as an empty collection or null. Release 1.1 includes the following improvements.

  • All dependencies on MSTest assemblies have been removed. So assertions will work with all testing frameworks.
  • Added support for Silverlight
  • Improved the verification messages around assertion of collections so that you don't need any debugging to figure out what went wrong.
  • Added object.Should().BeAssignableTo()
  • Added object.Should().Satisfy() to verify against a lambda or delegate.
  • Added extension methods on an Action or Action<T> which allows better support for the AAA syntax. We've rewritten a large portion of the framework's unit tests and it definitely improves unit test maintenance.
  • Added a ValueOf property to the exception assertions syntax that allows chaining additional Should()s on the properties of the exception.

You can download it here. The documentation can be found here.

Wednesday, March 03, 2010

User Stories, a different story altogether

My Dutch article on User Stories in Team Foundation Server 2010 is now available online at the SDN site. Read it over here. I will translate it to English soon.

Tuesday, March 02, 2010

ALM Practices Part 3: Unit Testing & TDD

What is it?
In essence, Test Driven Development (TDD) is a practice in which the interface and the behavior of a component is designed while writing a unit test. In other words, you typically start writing a test case and define the exact members, behavior and names on the fly. In fact, the word Test in TDD is misleading at the least, because the whole practice is really a design methodology that promotes creating testable loosely coupled software. And since this is going to be a difficult endeavor without applying the right design principles, you usually end up with a maintainable and extensible system which by incidence also includes a high code coverage. Without TDD, these same goals are very difficult to reach.
Why would you do that?
  • Because a seemingly small chance might have unexpected side effects caused by errors in the design or an solution that is too complex.
  • Because the simple practice of writing a readable unit test forces you to create code that is testable.
  • Because you will discover new scenarios while writing those tests that you usually do not find until you start running into bugs while testing the actual system.
  • Because a readable unit tests helps other developers to understand how to use the component’s API.
  • Because a set of well written comprehensible unit tests prevent you from long hours into the Visual Studio debugger, both during initial development as well as during an extensive system test.
  • Because you will be the first user of your component’s API which should stimulate you to really think carefully about how other users should use the API.
  • Because having a high coverage should encourage you to proactively refactor and improve your code base while adding new features.
What’s the bare minimum you need to do?
  • Write Intention revealing unit tests for all business critical functionality, technically complex code, components that are reused often and parts that are difficult to test manually.
  • Make sure that test code complies to the same high standards as production code. Test specifications are first class citizens as well.
What’s the usual thing to do?
  • Use TDD for everything you create and apply the red-green-refactor mantra rigorously.
  • Use the tests as your starting point for Peer Reviews. Every TFS task, user story or other functional work item should be associated with a set of tests that define the expected behavior of a component. As a reviewer you first review those tests to make sure the behavior matches your expectations, before you move on to the actual production code.
How do you do that?
  • Read all TDD-related articles pointed to from this blog post written by Jeremy D. Miller, and the article Principes of Test Automation from the book xUnit Patterns. These should give you a kick start on unit testing and TDD.
  • On your project site or dashboard, explicitly state which projects within your Visual Studio solution should be fully covered by unit tests and why (not).
  • Active Code Coverage and strive for a minimum of 90% coverage.
  • Configure a Daily Build that runs all unit tests and use the Quality Indicators report from the TFS MSF Agile process template to monitor the code coverage and the success rate of your tests over time. This report also shows the amount of code that still changes, which is very helpful when the team approaches an important deadline.
  • Configure your build in such a way that it automatically creates a bug upon any test failure and make sure the first team member that enters the office feels responsible for fixing that.
  • Automatically deploy test data required by your integration tests (unit tests that require a database) using a Database Project.
  • Consider reading the entire xUnit Patterns book. It contains invaluable resources on the organizational, technical and practical aspects of unit testing in large teams.

Monday, March 01, 2010

Fluent Assertions released on CodePlex

About a year ago, me and some other colleagues started to create a simple framework for verifying the outcome of unit tests in a more natural way. Martin Opdam already blogged about this in June and since then we have been adding some minor features.

A few weeks ago I discovered the much more powerful SharpTestEx and decided to drop further development on our own extensions. I do like some of SharpTestEx’s features, but I found some limitations that causes me to reconsider. Last weekend, I decided to reinstate our extensions under the name of Fluent Assertions and release them on CodePlex.

So why do I think it is better? First of all, because we only have one level of indirection (the Should() extension method), it is much easier to add you own domain-specific extensions. This is something we do often and should be very trivial.

Secondly, all our verification methods accept a phrase stating the reason of the expected outcome such as “because it is a required field” that is used to generate a clear and comprehensive error message when the verification fails. This should help you from staying out of the debugger hell when a test fails.

As I’m writing this we are already working on the next release which should be available in the next few days.