This is how I work with my source control system:

First, what do I check in? Logical chunks that work.

Then, how do I check it in?:

1. You start with no local changes (that’s the best way to start the day)
2. Get the latest source from the source control system.
3. At this point you want to be certain that not anyone else have broken anything, do one of the two:
• Have a build server that notifies when there is a check in, if the last check in was ok, then you’re good to go (this is by far the preferred way)
• Run the tests just after getting the latest source
4. Do what you came here for: code. Whenever you have a logical “chuck” of code, proceed to the next step.
5. You want to be certain that what you are about to check in is working: Run the unit tests one last time to make sure your code is working.
6. You have to merge your changes with anything else that might have changed: Get latest from the source control system.
7. Run the unit tests: At this point, you want to be certain that the combination of your code and the code from the repository is not failing anything. (Here it is a great advantage to have a build server that tells you that the source you are getting from the source control is working, so any failing tests you get now are guaranteed your fault)
8. Fix whatever is broken
9. check in (when all tests are green)
10. Repeat

Also note:

• On a general note, do your best not to check in failing code (failing tests, or even not compiling code). Failing code impeeds all the other team members. Don’t you get really annoyed when someone else on your team are messing up the source, and making lots of extra unnecceary work for you? I do not want to be that person.
• Do not, I repeat: do not, check in anything before getting the latest source. You want to make sure that all the latest source (not just yours) are working together.
• Do not wait too long to check in (to check in at least once a day is a good rule of thumb). The longer you wait, the more merging you will probably have to do.
• It is also a big advantage to have a build server that notifies if someone checks in failing code (so you do not have to be uncertain if it was you or someone else that broke the code when you get the latest source)

I am very interested in hearing your experiences with how to work with source control systems, feel free to post comments.

- Tore Vestues

I’m actively developing it. I’m also actively using it. In this post I’ll share my experience as a user of Glue, and how easy it is to set up the mappings using TDD.

The example

We want to create a mapping between DomainPerson and GuiPerson, listed here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class DomainPerson
{
    public int Id { get; private set; }
    public String Name { get; set; }
    public DomainAddress Address { get; set; }
}
 
public class DomainAddress
{
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}
 
public class GuiPerson
{
    public int Id { get { return 0;} set { return;} }
    public String Name { get; set; }
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}

Making sure all properties are related

What I test first is that all the properties are related (or actively ignored). This makes it easy to later detect changes in the classes we map between. It also makes it easy for us to see what properties we have to handle.

But first, in traditional TDD style, lets start with writing a failing test. The test should verify that all properties on GuiPerson are either related or actively ignored. The test looks like this:

1
2
3
4
5

[Fact]
public void AsserAllPropertiesRelated()
{
	mapping.GetRelationsVerification().AssertAllPropertiesRelated<GuiPerson>();
}

and, as this will not compile, let’s create the actual mapping:

1

mapping = new Mapping<DomainPerson, GuiPerson>();

It compiles, but as expected, it fails. We have created a mapping, but nothing is related. A nice feature with Glue is that it tries to be as informative as possible when it fails. Look at the exception we receive when running this test:

Not all properties are related (or ignored): Id, Name, StreetAddress, ZipCode, City, Country

It tells us what properties we need to handle. This makes my job easy. I’ll just have to relate (or ignore) all the properties reported in the exception:

1
2
3
4
5
6
7

mapping.Relate(domain=>domain.Id,gui=>gui.Id);
mapping.Relate(domain => domain.Name, gui => gui.Name);
 
var addressMapping = new Mapping<DomainAddress, GuiPerson>();
addressMapping.AutoRelateEqualNames();
 
mapping.Flatten(domain=>domain.Address,addressMapping);

Running the test, I get another Exception:

Glue.GlueException : The relation between ‘Id’ and ‘Id’ has atleast one readonly property, and can not be related TwoWays

Ah, fair enough, it went a bit fast there. I related all properties, but I didn’t check if any where readonly. Luckily, Glue tells us this early. I’ll make this change:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

And when I run the test again, it goes green. Now all properties are related, and we are protected from future changes.

Make sure the mapping actually works

But will it really work? We can also easily check if the actual values can be set on the target object. You should do this. I always do. So, lets start with another test:

1
2
3
4
5

[Fact]
public void AssertMappingWorks()
{
    mapping.GetMapperVerification().AssertMapsCorrectlyTowards(new GuiPerson());
}

Running this test, we get an Exception:

Glue.GlueException : Failed properties: Id (Failed to set value)

Ah, it detected that Id on GuiPerson is totally unable to set. Ok, lets say that this is supposed to be this way. That means we should not map Id towards GuiPerson. That means that we must remove this:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

Running the tests again makes AssertMappingWorks gets green, but now AsserAllPropertiesRelated got red again. That is because we have not related Id on GuiPerson. But since we do not want to relate it, we ignore it, to signal that we actively have made that choice. We do it like this:

1

mapping.IgnoreTowards<GuiPerson>(gui=>gui.Id);

Running the tests, they both are green, and now we know that we have a working mapping, which also are protected from failing on future changes.

Note that this example only tests the mapping and relations towards GuiPerson, in a bidirectional mapping scenario I advice to write the same two tests towards DomainPerson.

This is how I do it, and it works great for me. Hope you liked it. To learn more about Glue, and to download it, go to the Glue homepage at Codeplex

- Tore Vestues

It is about how your entities communicate, it is about where you place your logic. It is about where to place the code. And when you are programming you are putting code somewhere all the time. That means this is one of the fundamental things to learn as a developer.

So, what is it?

The phrasing itself means that you should tell other objects to do things, instead of asking other objects for information and processing it yourself. (”you” are of course an object in this case).

Example: The car dealer

Say you’re making software for a car dealer. You want to create a report that lists all cars for sale that can be distributed to the customers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ForSaleReport
{
    private readonly List<Car> allCars;
 
    public ForSaleReport(List<Car> allCars)
    {
        this.allCars = allCars;
    }
 
    public List<Car> GetAllCarsForSale()
    {
        return allCars.FindAll(car => car.SoldDate != DateTime.MinValue);
    }
}

There is a violation of “Tell, don’t ask” right there:

1

car.SoldDate != DateTime.MinValue

You ask for information (the cars SoldDate), then make a calculation based on it (calculating if the car is for sale). So, what should you have done? You should tell the Car-object to resolve if it is for sale. It is not your concern to figure it out (when you are in the ForSaleReport), your only concern is to list out cars that are for sale, not why or how they are. So, instead of trying to figure things out yourself, you should just ask the car:

1

car.IsForSale()

Be ignorant

It is easier to apply Tell, don’t ask if you think of your objects as ignorant. You give them a responsibility, and beyond that they should be totally ignorant. Always ask someone else to solve the problems. This makes them ask less questions. Asking less questions means less coupling. Only caring for a single concern means higher cohesion.

And if I don’t .. ?

Didn’t you see the major difference between the two (asking for the SoldDate versus telling the car to figure out if it IsForSale)? Well, there is a difference, and normally it doesn’t take long before it shows.

Say you ask for the SoldDate (thinking Tell, don’t ask are for stupid programmers that wouldn’t understand as advanced logic as yourself..). And say that since this application is growing big you ask for SoldDate several places to resolve if the car is for sale (I’ve seen systems where asking for such “innocent” information is done hundreds of places). Then one day the owner of the car dealership comes to you, quite agitated, telling you that your reports are plain wrong: “A car doesn’t have to be for sale even though the sales date is not set. It can be held of or be in for repair. Fix it now!”

Hm, now you have to search for all the places where you did your “innocent” information asking, changing it everywhere, and test it to see if you broke something else. Pray that you do not have any indirect references to SoldDate (getting it from a car and sending it away for processing further away), that would be hell to track down. Wouldn’t it be better if you just had to change the logic in one place? in Cars “IsForSale” method? I would think so.

And that is not the only problem. Opening up a class, exposing information (like SoldDate in this case) makes it easier for other classes to hard wire itself to the class. This means more coupling, and more coupling means that the class will be harder to change. In this case, there is no way you easily can change the representation of SoldDate within Car. If you want to change it, you have to change every class that refers to it. This might be a very tedious task.

Another problem, which might not be so obvious since there is no “principle” attached to it, is the developer experience: How easy it is to write code in this system. I find this an important issue, and a bit underestimated at times. This is important because it has to do with productivity. When writing new code for this system, and you have to find out if the car is sold or not, it would be much easier just to write “car.IsSold()”, then it would be to actually have to find out how to calculate it, and then implement it (find somewhere else in the code that calculates it, copying that code, and so on…). Figuring out if a car is sold or not should be done once. When it is figured out and implemented, everyone else should just reuse that logic, never again caring for how it is implemented (unless of course, you have to fix or change something in that logic).

Conclusion

For me, Tell, don’t ask brings with it several realizations about programming:

• It is important to think about your modelling when you write code. Where you put your code has major implications on your softwares maintainability.
• Modelling isn’t just for “architects”. As a developer you make decisions every day that can make or break the software.
• Focus on responsibilities, and who should be concerned with what. This makes your application more cohesive and less coupled.
• Don’t repeat yourself (DRY). Tell, don’t ask helps you put logic one place (where its concern is handled) instead of scattering and copying it all around.
• When modelling, it is also important to consider how easy it is to read and use the code for the developers.

So, if there is only one thing you want to keep in the back of your head when programming, I suggest it is Tell, don’t ask.

- Tore Vestues

You’ll find examples and code here: http://glue.codeplex.com

Glue is a general purpose, bidirectional automatic mapping for the .Net platform, with strong verification and testing tools.

I’ve seen quite a lot of less than optimal handling of mapping issues in quite a few projects over the years. Again and again mapping seems to be just a task we have to do, and a bit too small for automating. It becomes clearer and clearer to me that mapping is both an important task in many projects, and it is always a repetitive and boring task. In addition far to often subtle annoying bugs tend to sneak into mapping code. This motivated me to create Glue. And this is what I need from a mapping framework:

a) a way to automate mapping, mostly because it is boring, and that makes it error prone,
b) a way to automatically test the mapping, I’ve found that manual written test code for mapping is seldom done in a good way,
c) a way to prevent future changes making my mappings obsolete. When people make changes, they rarely focus on mapping (and honestly they should not either). They should be told when they have to update the mapping.

Now, you could argue that there is already a mapping framework available on the .Net plattform. And when I started this work, I actually started with that framework, thinking I could just make a few extensions to fulfil my needs. I actually spent some time in the source code to try to implement it, but sadly I realized that our needs differed too much. So, I created Glue, and these where the driving forces:

General purpose

Glue is a general purpose mapper. We realize that in the real world there are a lot of different solutions, and not all of them follow “the one true pattern”. In fact, mapping is often used to map to and from subsystems that are far from well designed. Subsystems we try to hide in a layer because we do not want it to leak into the other layers. Thus, we believe a mapper must support quite a few different scenarios. The goal is to promote good coding practices, but not to ignore the fact that there is a lot of legacy code out there that forces us to work a bit differently at times.

Bidirectional

I would say that in many mapping scenarios we need to map in both directions. First we get data from an object in a layer, and map it to an object in the layer above. When that layer is done with manipulating that object, we often want to map it back to down to the layer where it all came from. I have noticed not all mapping frameworks see it this way, and this was one of the reasons why I started working on Glue instead of trying to extend existing frameworks.

Strong verification and testing tools

I want to be absolutely certain that my mapping works. I also want to make sure that it is very hard to break it later. Manually writing tests for mapping is even more tedious than writing manual mapping. Glue automates this. Future changes has a sad reputation of breaking mapping code. Glue helps you detect this. Tools for helping the mapping is very important to me. And more tools will be available in future releases.

Simplicity

Mapping should be simple. Glue tries to simplify both the mapping process, and the verification and testing. You should not have to state the obvious, and Glue support relating properties automatically based on names.

Explicitness

Although Glue enables you to automate much of the mapping process, it also gives you the opportunity to be explicit about the mapping. So if you want to describe every relation in detail, you can. When it comes to understandable code this can be a good thing. Taking difficult to understand implicit mappings, and stating them explicitly can sometimes make things much easier to understand.

Current version and the future

The current version is 0.2.0 Alpha. It is still in Alpha because if we find good ways to improve the API, we do not want to lock ourselves to it just yet, before we get more feedback. I’m guessing the next release will be Beta.

I am currently using Glue on the project I am working on, and in about a month it will reach production. This somewhat guarantees that it will continue to evolve as our needs expand, and that we will find bugs sooner, and they will be fixed sooner.

Looking into the future we have some exciting ideas on tools to help with the mapping, and we are also working hard to make Glue as easy as possible to use, so expect simplifications. In addition we want Glue to serve a broad set of needs, so feedback is highly appreciated and if you explain your special needs, we might just implement it.

You’ll find examples and code here: http://glue.codeplex.com

- Tore Vestues

In my last project we used the ASP.NET MVC framework along with StructureMap, which made us create our own controller factory. I just blogged about it here.

If it was a good design decision or not I am not completely certain anymore, but we added some more framework logic to the controller factory, including checking state on the HttpRequest-object. This, it turned out, was a path to trouble. After a while we had unexpected behavior in our system, sometimes it leaked information between HttpRequests it seemed! But since this only happened during stress testing, it was hard to find the cause.

What we found was that the RequestContext.HttpContext-object was not all the way thread safe. When a request hits our custom controller, and the request goes to sleep to serve another request, the HttpContext of the factory changes to the second requests HttpContext. This means that the first request will work on the second requests HttpContext when it wakes up. This is bad news if you are dependent on the HttpContext in your custom controller factory.

The lesson is this: you have to do at least one of the two actions below if you want to access the HttpContext in your custom controller factory.

1)

The problem occurs when you set your controller factory like this (normally in the global.asax file)

1

ControllerBuilder.Current.SetControllerFactory(new CustomControllerFactory());

If you send in an instance lik this, it will be the only instance of your controller factory, and this is where the HttpContext-concurrency issues arrive in the first place. What you can do, which will take away all the concurrency issues is to send in the type instead of an instance, like this:

1

ControllerBuilder.Current.SetControllerFactory(typeof(CustomControllerFactory));

The drawback to sending in the type is a) your controller factory will be instantiated for every request and b) you cannot send in anything to your instance (since you’re not instantiating it). This might not be a problem, and if not, you’re good to go.

2)

If you have to use one instance only of your controller factory, and you need to access the HttpContext for a request, you MUST use the HttpContext.Current-instance and not the RequestContext.HttpContext. The HttpContext.Current is as far as I’ve tested thread safe.

Not thread safe:

1

RequestContext.HttpContext

The thread safe alternative:

1

HttpContext.Current

I just found out that this is a bug

- Tore Vestues

The ASP.NET MVC framework has a default controller factory (DefaultControllerFactory) that requires all controllers to have a parameterless constructor. So, if you want to inject your dependencies to the constructor, you can’t do it. In addition, Microsoft suggests the following pattern to mock out the dependencies when testing:

The Microsoft way of testing

(Example from www.asp.net/mvc)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

//The Microsoft way...
public class GroupController : Controller
{
    private IContactManagerService _service;
 
    public GroupController()
    {
        _service = new ContactManagerService(new ModelStateWrapper(this.ModelState));
    }
 
    public GroupController(IContactManagerService service)
    {
        _service = service;
    }
    //...
}

In other words, create one constructor for the actual application, and one constructor for testing. It works, you get to test it, it’s not all that bad, but it just doesn’t sit well with me.

Take control of your controllers!

Don’t you like this either? Well, there is an easy way out of it. One of the really good things about ASP.NET MVC is that it is easy to configure. You can create your own controller factory and take control of the whole process. It might sound like a complex task, but it isn’t.

Let’s start with our controller, it has a dependency that is injected through the constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class HomeController : Controller
{
    private readonly Speaker speaker;
 
    public HomeController(Speaker speaker)
    {
        this.speaker = speaker;
    }
    public ActionResult Index()
    {
        ViewData.Model = speaker;
        return View();
    }
}

Running the website now, trying to reach this controller, will make the framework crash (”No parameterless constructor defined for this object.”). We need our own controller factory to make this work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class StructureMapControllerFactory : DefaultControllerFactory
{
    private readonly IContainer container;
 
    public StructureMapControllerFactory(IContainer container)
    {
        this.container = container;
    }
 
    protected override IController GetControllerInstance(Type controllerType)
    {
        return (IController)container.GetInstance(controllerType);
    }
}

This controller takes in a StructureMap.IContainer and uses it to create all the controllers. It inherits from the DefaultControllerFactory and overrides the GetControllerInstance-method that is used to create controllers.

Now all we have to do is to tell the ASP.NET MVC framework that it should use our controller factory. To do that simply add this line in the Application_Start() method in the Global.asax file:

1

ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory(new Container()));

(Notice that we do not need to configure StructureMap since our dependencies are so easy to resolve. In a real world app you will most probably need to configure the container)

There you go. Using StructureMap with the ASP.NET MVC framework is easy!

Download the complete example here

-Tore Vestues

Let me give you an example.

When Kent Beck and his extreme programmers started out (with XP – extreme programming), they were talking about not writing comments in your code. And they explained what they meant: Comments are often an indication that your code isn’t readable on its own, the fix is often to write code that is easier to understand, not to add comments.

For me this is great advice. I try to keep my code clean and readable, and when I feel the urge to write comments, I first check if I can make the code more self explainable on its own. I personally write some comments, but never to explain code that looks like crap.

The problem with this advice is that it is actually bad advice if you do not understand why you should follow it. Those that do not understand why they should reduce their amount of comments, but still dig the idea, are probably writing as unreadable code as they always did, but now explaining the mess with even less comments. The result is probably all over worse code than if they didn’t follow the advice in the first place!

There are at least two lessons to be learned here.

First, if you do not understand why you are doing something, you are probably doing it wrong. It is time to start questioning what you are doing, always ask why.

Second. Say too many people misunderstand the purpose of something, thus applies it wrong, and thus is actually producing worse results than before. In our “no comment” example, people would, based on empirical evidence of the practitioners, say that the “no comment”-idea is a joke (since most of its followers are actually writing worse code). So by applying the idea wrong you are probably discrediting the whole idea.

I like to define agile in one sentence: “Ask Why”. “Why should we write this piece of documentation?” “Why should we follow this process?” “Why should we follow this practice?” If we better understand what we are doing, and can adjust our practices accordingly, I think we will get a long way. I think this is the core of agile.

- Tore Vestues

Unit tests specify
There is a lot of functionality (or business logic) that is accidental, meaning that it is not really necessary and it might even be plain wrong, a bug. It happens, a lot. It is hard to know if a piece of code is accidental or not if you do not have a way to express it. A unit test is a great way to express your intent and your “real” functionality. For me, unit tests are specifications. They specify the intended functionality. This is explicit functionality. I love explicit functionality. In fact I love almost anything explicit when it comes to code. I want to read loud and clear what the intentions are. The opposite of explicit functionality is of course implicit functionality. This is the functionality that resides in the code without anything or one to claim its importance. Implicit functionality might always be accidental, and that is why it is so hard to work with that kind of functionality. You do not know if it’s supposed to be there.

Unit tests verify
If all important functionality is ensured with unit tests, you have your safety net. The unit tests verify what you specified. Then refactoring is a dream. Keeping the codebase neat, up to date and clean is easy. To be able to nurture your codebase, through refactoring, you will need this safety net. It verifies your intentions and ignores all unnecessary code.

Unit tests do not test software
This way unit tests ensures that the intended functionality in your classes stays there, and makes it easier to refactor. But it does not check if your system work. It does not verify that you have put it all together the right way. It does not check if everything goes right in the databases, on files or in the user interface. Partly integration tests will do this job for you, and partly manual testing.

Abstractions through OO
When I talk about unit tests, I consider my units to be classes. I also want to stress the point of knowing where to put your logic. Responsibilities should be placed where it belongs, in the right concepts (on the right classes). This is the fundament of object orientation, expressed elegantly through domain driven design. The concepts are the classes. Thus it is very important to verify the logic where it belongs, on the classes. And why should we use classes and separate logic? There are mighty reasons for this, but for now let me just say: to avoid cognitive overload.

You need all types of tests
So, unit tests are there to specify the behavior of the systems concepts (think DDD). This is imperative to be able to refactor the core of your system. But as I’ve said, this is far from enough to test your system. I find integration tests best for testing your software. Tests that are more like acceptance tests, checking a complete path of calls from top to bottom (and yes, I often include the database in these tests). In addition there are things you will not be able to test automatically (that easily). How does the gui look and feel? You need someone to test that too.

To conclude, you need a whole lot of unit tests to lock down functionality. You need integration tests to test your software, and you need people to test gui and other stuff that isn’t feasible to test any other way. And my opinion is that you should do all this before you send it to QA.

-Tore Vestues

Disclaimer: There are several reasons software projects fail and many of them are caused by management – way above the developers. Still, we as developers have to take our part of the blame, and crap code is our contribution to the failure.

It is not about algorithms and performance

I didn’t learn much about communicative code at the University. And I still do not think people learn a lot about it. Students probably still think that software development is all about performance and effective algorithms. I’m sorry, often it’s nothing like that. In most business applications today there are no fancy algorithms. It’s just a huge amount of code that is trying to express the rules and logic that exist in the business. Performance might be an issue, but it has nothing to do with tweaking algorithms, it’s about architecture, data loads and sometimes really bad code.

So, what’s the problem?

The major problem with business applications today is the huge amount of code. The amount is not a problem in itself, but it gets to be a problem very fast when it’s hard to understand what it does.

Let’s take a simple example: Methods in today’s software are often way too long. It takes a lot of time to understand 100 lines of code that does several different things, and it’s even harder to change it without breaking something. I’ve seen tons of code that looks like that, and I’ve spent ages fixing such code. Believe me, code like this is very expensive and it will soon be full of bugs. Such software deteriorates pretty fast, and before you know it you’re at a point where whenever you remove a bug, you add two new ones. We should all be ashamed, honestly.

Code that is hard to understand is hard to change; software that is hard to change will be expensive and slow to change, and the risk of the changes adding new bugs is high. Who wants an application where it costs a fortune to add features, takes forever, and adds new bugs?

It’s about communication

Yes, it is a mess, but what can you do? We have to understand that writing software is about communication!

Put simple: Code that is easy to understand is easy to change. When it’s easy to change the risk of introducing bugs is low. That’s the kind of software your customers want!

Martin Fowler hit the nail on the head when he said:

“Any fool can write code that a computer can understand. Good programmers write programs that humans understand.”

What can I do?

When I write software, my main concern is actually if I am expressing my code in a way that others will be able to understand. And the “others” are quite often myself. When I get back to code I wrote two months ago I want it to be really easy to both understand and change that code.

When I have to work with code that is hard to understand I often make it easier to understand first, then make the changes. I keep my methods short. I keep my classes short. I try to organize my code so that related logic is grouped together, and unrelated logic is separated. I write tests for my code that explains the code. I care about the code I write.

Writing code that communicates is first and foremost a mindset. Get it! Then it is a set of practices and principles. Read them, train them and practice them. Find out what works for you. Nothing can replace experience.

Robert “Uncle Bob” Martin has written an excellent book on the topic: Clean Code. Read it now! Kent Beck is also passionate about this, and wrote this book: Implementation Patterns.

I’m holding various presentations about what I call Code Quality. Communication is a vital part of that.

- Tore Vestues