Decaying Code

Where code comes to die

"If you build it, they will come" - Or how to start a community

I've always found that the best practices inside my field were not always respected. Doctors always wash their hands, architect follow all the rules to have a building that is safe for the people living/working inside it. However, with software, anyone can improvise himself "Software Architect" or "Software Developer" without having any problem to find a job. Most people in the .NET community will follow what is given to them by Microsoft. Be it SharePoint, Entity Framework, Linq To SQL, Visual Studio, or whatever. Sometimes, alternative is good because they offer you a different view on the state of things.

When I met Greg Young for the first time, it was in .NET Montreal Community meeting where he was doing a presentation on DDD. We took a beer together and talked about improving the level of those in Montreal. Improving the level of average developer in Montreal is a hell of a task. First, there is people like me, Greg and Eric De Carufel who are passionate with their craft and are not satisfied with the status quo. We believe in ALT.NET but are most of the time called "passionate programmer". The people like me and Eric are the easy one to help. Then there is those that want to improve themselves but that doesn't have time (life, family, house, etc.). They are not easy to attract and the best way to instruct them is to do it internally (official training or coworkers). Then there are those that don't care about their craft. Those are of no interest to me.

When I took a beer with Greg Young, he talked about action on what would be needed to improve the level. That is the reason why I started (or at least... still trying) to start the ALT.NET Montreal Community. We started a month a ago. We were only 7 back then. It was small but friendly. Now, on June 25th, we will hold our second Coding Dojo of the ALT.NET Montreal Community.

What is important to remember when starting a community I think is, to start! So, if there is anyone from Montreal who wants to help us boot start a community... the ALT.NET Montreal Community, you are all welcome to our next Coding Dojo on June 25th.

My baby steps to PostSharp 1.0

So... you downloaded PostSharp 1.0 and you installed it and are wondering... "What's next?".

Well my friends, let me walk you through the first steps of PostSharp. What could we do that would be simple enough? Hummm... what about writing to a debug window? That sounds simple enough! Let's start. So I created a new Console Application project and I added the reference to PostSharp.Laos and PostSharp.Public. As a requirement, the class must be tagged with "Serializable" attribute and implement OnMethodBoundaryAspect (not in all case but let's start small here).

Next, I have a few methods I can override. The two that we are interested in right now is "OnEnter" and "OnExit". Inside of it, we'll say which method we are entering and which one we are exiting. Here are my Guinea pig classes:

public class FooBar
        public void DoFoo()
        Debug.WriteLine("Doing Foo");

        public void DoBar()
        Debug.WriteLine("Doing Bar");

        [AttributeUsage(AttributeTargets.Method | AttributeTargets.Property)]
        public class DebugTracer : OnMethodBoundaryAspect
        public override void OnEntry(MethodExecutionEventArgs eventArgs)
        Debug.WriteLine(string.Format("Entering {0}", eventArgs.Method.Name));

        public override void OnExit(MethodExecutionEventArgs eventArgs)
        Debug.WriteLine(string.Format("Exiting {0}", eventArgs.Method.Name));

See how simple this is? But... does it work? Let's see the trace of calling each methods:

Entering DoFoo
Doing Foo
Exiting DoFoo
Entering DoBar
Doing Bar
Exiting DoBar

Isn't that wonderful? Compile execute and enjoy. But... what about the community you say? Of course if the tool is not open source there is probably nothing built around it, right? Wrong!

Here is a few resources for PostSharp that include pre-made attributes that are ready to be used:

That was everything I could find. Do you know any others?

PostSharp - The best way to do AOP in .NET

Who knows about Aspect-Oriented Programming (AOP)? Common! Don't be shy! Ok, now lower your hands. My prediction is that a lot of you didn't raise their hands. So let's resume what AOP is:

Aspect-oriented programming is a programming paradigm that increases modularity by enabling improved separation of concerns. This entails breaking down a program into distinct parts (so called concerns, cohesive areas of functionality). [...]

So what does it mean truly? Well, it's a way to declare part of your software (methods, classes, assembly) to have a "concern" applied to them. What is a concern? Logging is one. Exception handling is another one. But... let's go wild... what about caching, impersonation, validation (null check, bound check), are all concerns. Do you mix them with your code? Right now... you are forced to do it.

The state of current AOP

Alright for those who raised their hands earlier, what are you using for your AOP concerns? If you are using patterns and practices Policy Injection module, well, you are probably not happy. First, all your objects need to be constructed by an object builder and need to inherit from MarshalByRefObject or implement an interface.

This is not the best way but it's been done in the "proper" way without hack.

What is PostSharp bringing?

PostSharp might be a "hack" if think so. Of course, it does require you to have it installed on your machine while compiling for it to work. But... what does PostSharp does exactly? It does what every AOP should do. Inject the code before and after the matching method at compile time. Not just PostSharp methods but any methods that is inherited from the base class PostSharp is ofering you. Imagine what you could do if you could tell the compiler to inject ANY code before/after your method on ANY code you compile. Think of the possibilities. I'll give you 2 minutes for all this information to sink in... (waiting)... got it? Start to see the possibility? All you need to do is put attributes on your methods/attributes like this:

        public string Name { get; set; }

        public int Age { get; set; }

Now look at that code and ask yourself what it do exactly. Shouldn't be hard. The properties won't allow any number under "0" to be inserted inside "Age" and "Name" will not allow any null or empty string. If there is any code that try to do that, it will throw a ValidationException.

Wanna try it?

Go download PostSharp immediatly and it's little friend ValidationAspects on Codeplex. After you have tried, try to build your own and start cleaning your code to achieve better readability.

And yes... both are Open-Source and can be used at no fee anywhere in your company.

Suggestion to CLR Team

Now, PostSharp force us to have it installed with the MSI for it to work because it needs to install a Post-Compile code injector (like some obfuscation tools). What would be really nice, is to be able to do the same thing built-in with the compiler. The compiler is already checking for some attribute already... I would love to have this "internal working" exposed to the public so that we can build better tools and, more importantly, better code.

UPDATE: I want to mention that PostSharp is NOT open-source. However is free unless you need to package it with your tool.

So I just finished reading Clean Code by Uncle Bob

This must have been the most enlightening book I've ever read. It's filled with "evident" knowledge. Of course, some of them you have never thought about... but some that you just can't avoid nodding in approval.

As everyone know, I'm a .NET Developer and Uncle Bob is a Java developer (not exactly but the book have code in Java). There is some recommendation in the books that are targeted at Java developer and that don't apply to .NET.

So? If I had to tell what the book is about, what should I say?

I would say:

  • Humans are good at mixing abstraction level
  • Keep the variable/class/function clear and concise
  • Commenting must be done with care otherwise it just clutter the code
  • Refactor, refactor, refactor. A code base is never perfect but if you follow the Boy scout rule, the code base will always be better in the end
  • Code should always have test and high coverage

Am I hitting the bulls eye here? What do you think?

Redefining ALT.NET or rather, rediscovering it's meaning

I've heard about ALT.NET about a year ago. At first, I thought that it was about using alternatives to Microsoft or to avoid Microsoft software. ALT.NET was supposed to be about going "alternative" and being against "The Man" and being for "The People". Well, I must agree that I wasn't totally right with that. I mean, Microsoft make some mess but it also does a lot of great tools and particularly a great IDE with lots of extensibility point.

Then, I did what I should have done in the beginning. I looked up the definition. On the ALT.NET website, we have this:

We are a self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development.

Hum... that's a totally different story now. The emphasis is mine and helps get the key points. First, I would have never gotten into a field that I hate and I love to learn. That makes the desire to improve ourselves done. I always challenge assumptions and try to find the better tool for the job. I know that Microsoft makes some great tools but sometimes they just don't cut it. They will someday... but they not always will. Most of the time, you can't wait for Microsoft to build a tool that will help you finish a software... so you get what works for you at the moment.

Finally and not last, "help each other pursue excellence". That is the hardest one. Of course, I participate in the .NET Montreal Usergroup, but... I felt that more could be done. I then started to speak with Greg Young and other passionate programmers in Montreal. Something that Greg kept repeating during our "Beer Meeting" was always: "But what concretely can we do to improve the level of the people in Montreal?". This stayed in my mind for weeks.

Since I wanted to help improve my fellow programmers and I thought that we learn best while coding... I started searching for a way to improve everyone while coding. It happens that it already exist and it's named a Coding Dojo.

Last Thursday, I organized the very first Coding Dojo for the ALT.NET Montreal group. We were few but learned a lot. We also had a lot of practice in learning TDD. It was hard since I never did a Coding Dojo before. I learned a lot, and our fellow programmers learned a lot. I'll try to get one Dojo per month and to get more and more people to join the group. As Kevin Coster was told... "if you build it, they will come".

So my last word goes to Scott Bellware. All hope is not gone Scott. People around the world is still organizing to teach other people best practices and to try to raise the bar of everyone. Our group is small... but if it had to start somehow it had to be small. I hope all hope is not gone on your side Scott. Passionate programmers love to learn and we are trying to offer them a way to learn and improve themselves and at the same time... propagate their knowledge to the workers that didn't cared enough to come.

Participating in the community and improving yourself

This post is sadly not going to be about code so much that it's going to be about the profession. Some professions have it easy. You can cut hairs without having to learn something new every 2-3 months. You can build houses without having to learn new methods every year. Of course, all professions are evolving and new ways to do the same task more effectively are created.

What is really different when you are coding is that new languages are coming every 1-2 years. Methodologies are coming every 5 years. New frameworks are coming every 5-6 months. I might be off on those numbers but I feel pretty confident about it. WPF came in less than 2 years. C# 3.0 came in a year and a half ago. C# 4.0 is due to 2010.

All those technology require a lot of our time to learn. This is the main reason why there is so much conference, workshop and community event happening in a single city. This year, I'm going to the .NET Montreal User group , I'm trying to organize a Coding Dojo, I'm attending the Montreal Codecamp 2009 and I'm presenting at this same Codecamp. My question here is... is it too much?

I feel that I won't learn enough in my lifetime to but a great programmer but that if I work enough, I might just be good enough to be proud of my work and make changes in the way that we do our job (The Daily WTF anyone?).

However, even if the amount of changes are tremendous... I don't see any desire to participate in community events. It doesn't mean a lack of desire to improve. I just think that a lot of people like to learn on their own off a book or by doing the trip themselves.

How is it on your side? How is it like in the US? India? Slovakia (yeah! got a lot of those readers!) ?

What is your take on participating inside the community and self improvement? - How to retrieve lyrics for your mp3 in C#?

I have an iPhone and I got a lot of songs on it. I don't particularly love to sing but I got a few bands that have tendencies to say their lyrics in a... obscure way. Since I'm really curious, I'm always on Google searching for the lyrics. I wanted to save some time and avoid unnecessary browsing. The iPhone have the capacity of displaying lyrics if they are included inside the mp3 metadata. Updating the lyrics is something but where will I retrieved thousands song lyric?

I recently found out about a website called What is interesting is that they have a web service (for free) available. I then decided to share how I did it. First thing is to start a project. You will then add a service reference like this:


Click on Go, change namespace and click on OK. Once  this is done, the easy part is done. Please note that the service URL has been stored under App.config with all the related settings.

Now to retrieve the actual lyrics, no more than a little bit of code:

// create a client to connect to the service
        LyricWikiPortTypeClient client = new LyricWikiPortTypeClient();

        // retrieve a song. Creed is good. Love this band.
        LyricsResult song = client.getSong("Creed", "One");

        // display the artist and the lyrics
        Console.WriteLine(string.Format("Found lyrics for \"{0} - {1}\":\r\n\r\n" +
        "{2}", song.artist,, song.lyrics));

        // let you read it :)

That was easy now wasn't it? Next post, how to update your mp3 with iTunes! Keep reading!

EntLib 4.0 - ExceptionPolicy.HandleException is not thread safe

We've faced this problem recently where Enterprise Library was crashing. Not everywhere... just on this little line of code. We were trying to save to a database asynchronously but if the database was not available, it threw an exception which Enterprise Library was supposed to catch.

However, this never happened. Enterprise library crashed on us. Mind you, we didn't figure out this problem until recently because the problem was just happening in production.

When we managed to reproduce the exception in a development environment (where debugging is possible), we got an error similar to "An item with the same key has already been added". Here's the beginning of the stack trace:

Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionHandlingException: The current build operation (build key Build Key[Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyImpl, LogException]) failed: The current build operation (build key Build Key[Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter, null]) failed: An item with the same key has already been added.

That lead me to this thread where it was mentioned that an issue was logged. I found this issue which mentioned concurrency issue. Since our code was multi-threaded, we had two options. Replace Enterprise Library 4.0 by Enterprise Library 4.1 or make a thread safe wrapper for the call to the log exception.

The first option required reconfiguring the build and all development machine, the second one consisted of coding a dirty patch. We went with the first one (what else did they fix in 4.1?) for obvious reason.

So, if you have this kind of problem with Enterprise Library 4.0, you might want to upgrade to Enterprise Library 4.1. Since the problem happen in the error handling section, it makes this kind of bug hard to understand and erratic (due to concurrency).

Find and Reproduce Heisenbugs - CHESS is the tool for you

Microsoft is mainly known for 2 things. Windows and Office. However, for programmers,  Microsoft is also know for many more projects/product like .NET, Enterprise Library, ASP.NET MVC, Team Foundation Server, SharePoint, etc.

Among the few tools that are not really known and publicised at the moment are the projects inside Microsoft Research. This is the land of Beta or "software-never-to-be-released". Either the project is too crazy(read: inovative?) or not useful for people at the time. But there is time where a tool stands out and need to be  talked about.

My friend Eric De Carufel recently talked to me about this tool called CHESS from Microsoft Research. He tested it and it allows for testing for those rare bugs that are only found when there is enough concurrency. Those bugs were tested before with stress test. Stress test are not supposed to be used for finding concurrency bugs but they are traditionally used for that too because when a system is under stress, concurrency happens.

CHESS is there to solve this problem. It includes itself among your unit test and try every possible permutation of code that happens asynchronously. This include race condition, dead lock, and what else exists (not an expert in multi-threaded applications).

Of course, I expect Eric to blog more about this amazing software that is coming from Microsoft's Trenches.

Want more information? Get on the CHESS website. If you want to find more interesting projects that Microsoft's genius are working on, visit Microsoft Research.

CodeCamp Montreal 2009 - Unit testing with Moq

I'm happy to announce you that I've been selected to present a session at the Montreal CodeCamp.

My session is going to be focussed on Moq and unit testing. Since simply looking at a framework can be done simply, I'll be going over the framework and many "how-to". I'll also try to fit a few interesting demo with some "refactoring for unit test". Of course, this will all be centered around "best practices" since it's the theme of this year.

See you all there!