Moving my RSS feed to feedburner

As part of my blog redesign I've decided to try out using FeedBurner to monitor the use of my RSS feed. So please update your feed readers to point to my new FeedBurner RSS feed

A much needed facelift

For the past couple of months I've been wanting to give my blog a new layout. Well tonight was the night when I finally got around to it. I upgraded the layout to use a new blogger template and I also integrated the excellent DISQUS comment system.

Initially there was a problem with the images used in the template, the page that they were hosted on kept exceeding their bandwidth limit so I had to move them to my own image gallery. They should be fine now, but if you experience that some graphics sometimes doesn't get loaded please let me know.

There are still some bits and pieces that I need to work out, but all in all I'm quite pleased with the make over

Now to put some more contents on it ;)

Getting .LESS 1.0.0.4 run on your machine

Today I set out to play around with .LESS with the goal of deciding if it was something we should bring into our toolkit at work. I downloaded the current version, which at the time of this writing is an assembly with the version 1.4.0.0, and set out to configure our site to use it. The configuration it pretty straight forward, the instructions are at the first page of the .LESS domain, in a 5 step list. However, this is where things deviated from the intended path.

The first obstacle I ran into was Visual Studio telling me that it did not recognize the dotless.Core assembly I pointed it to, for the new configuration section handler I was adding. This was quickly resolved as it turns out that the setup instructions had not been updated to reflect the latest assembly version 1.0.0.4. So changing the section handler registration from

<section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core, Version=1.0.0.1, Culture=neutral" />

to

<section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core, Version=1.0.0.4, Culture=neutral" />

Unfortunately after creating a .LESS file and running the application resulted in no styles being applied. When I tried to directly navigate the .LESS file by typing in the path in the browser address field, I got an ASP.NET error page informing me that the file could not be found at c:\css\main.less. This turned out to be a bit more difficult to resolve.

After moaning about this on Twitter, one of the developers, Erik van Brakel, on the .LESS project suggested I should have a look at the .LESS Google Group since he believed someone found a solution to this before. I found a post talking about a feature request that looked like it could have something to do with my issue. In one of the posts another of the .LESS developers, Daniel Hoelbling, linked to a blog post on some changes he had made to accommodate the new feature.

This blog post gave me the hint I needed to figure out how to solve my problem. Turns out that the custom configuration section that .LESS uses, now supported a new attribute called source. This tells .LESS how to resolve the location of requested .LESS files. However there were a slight error in the statement by Daniel, that stated that the AspServerPathSource source engine was the new default instead of the FileSource engine.

What I found was that unless I explicitly configured that the AspServerPathSource should be used, .LESS resorted to using the FileSource engine which was the cause of my problem. So by updating my configuration to

<dotless minifyCss="false" cacheEnabled="false" source="dotless.Core.AspServerPathSource"/>

everything started to work like intended. I am now able to use the (currently) latest drop of the .LESS binaries. I’ve told Erik about this so hopefully the documentation should be updated to reflect the changed I have come across.

The 6 steps to mastering refactoring

Last night I was in the process of refactoring some of the code in the project I am currently working on. After a while I fired of the following update on twitter

Is refactoring more fun than writing the initial code? It's like putting the finishing details on a piece of art,see it take it's true shape

It did not take long before I got a couple of replies from people agreeing with me. This got me thinking. Refactoring is essentially the same as restructuring your code and to many that is a daunting task, something they would rather try to avoid because of the risk that something might break. I came to the conclusion that there are 6 things that I make sure I follow before and during any refactoring and here they are

1. Make sure you have good suite of tests – Let me be perfectly honest here; if you do not have a good suite of tests in place for the code you are about to refactor, then it is not going to be a pleasant journey, period. Having a suite of tests you know prove that the code is working as intended is going to make you a lot more comfortable with making radical changes to it. They are your primary refactoring safety net, so make sure they are in place. You are going to want to run these tests a lot so take the time to setup keyboard shortcuts to re-running them, you are going to be thankful you did. Re-running your tests should not be a chore, it should be second nature and switching out of code-mode to move the mouse to select the menu option to run the tests are going to start gnawing on your patience pretty quick. If re-running your tests is tedious you will not run them as often as you should.
   
2. Get to know the tools in your toolbox – Most modern development environments have support for the basic refactoring steps, such as renaming, extracting method, reordering parameters and so on. Refactoring can quickly become repetitive and tedious, but it does not have to if you know how to take advantage of the tools at hand. Learning the keyboard shortcuts to perform the basic refactoring steps is going to solve both of these. Take the time to learn the keyboard shortcuts to speed up the process and soon enough code will literally change shape as if magic was involved. Tools such as ReSharper, CodeRush and JustCode brings a lot to the table that and, once you know the tools, it will increase productivity a lot.
   
3. Use a version control system – I can not stress this enough, but being able to reverse the changes you have made can, and will, turn out to be a life-saver more than once. By having your source code under version control you bring instant reversibility into the game and there is no need to worry if you find yourself in a place where the state of the code is horrible. Simply revert the changes you have made and start over from scratch, but with the experience gained and lessons learned from the previous failed attempt. The most widely used version control systems, such are Subversion, Git and Mercurial, are all free, so there are little or no reason not to use them, even if it is just a local repository on your hard drive.
   
4. Keep the iterations small – Part of the agile process is to keep tasks small and the same goes for refactoring. Focus on improving one thing at a time or you are likely to loose track of your changes and end you reducing the quality of your code instead of increasing it. If you (and again, you really should) have your source code under version control, then make it a habit of (at a minimum) committing your changes after each iteration. Break down large tasks into many smaller ones to get a better overview of changed you are making.
   
5. Have a game plan – Do not start refactoring your code without having a game plan. Just randomly trying to improve the quality of your code is to sell yourself short. Take a moment and get a mile-high view of your code, then formulate a game plan. During the initial coding, you probably made notes, mental or in some other form, of points that you would like to revisit later on to improve, start from there. Having a game plan enables you to define the confines of the iteration, in other words you will be able to know when your work is done.
   
6. Do not add new behavior – Refactoring is about improving the quality of your code. If you find yourself introducing new behavior then immediately stop. Looking at the refactored code might make it more evident on how additional functionality could be introduced, than if you had looked at the old code. However if you decide to walk down that path you are no longer refactoring, you are now designing a feature and you should revert back to the normal process, such as TDD. The last thing you want to do is to change or add behavior in your code without making sure it is covered by tests.

There you have it, my steps on how to make refactoring into a pleasure instead of a burden. If you have any more steps that you follow, please leave a comment! I would love to hear about them.

So you write unit tests, but do you really TDD?

Many developers are claiming to be TDD practitioners, without really understanding the differences between Test-Driven Development and unit testing. Somewhere along the line the definition of TDD has gotten lost and it is time to set the record straight; just because you write unit tests does not mean you practice TDD.

Unit Tests

When doing unit testing you want to isolate the smallest possible unit of your application, usually a class, and test it in complete isolation. This means that you need to be aware of any external dependencies that the unit under test has, so that you can create an abstraction between the unit and the environment around it, usually by taking advantage of mocking framework or fake objects.

Without isolating the unit from its external dependencies you would be creating integration tests. An integration test asserts that the interaction between two or more units produces results that satisfy functional requirements. These types of tests are completely different from unit tests, but are equally important.

A unit tests should not be concerned with the internal implementation details of the unit under test. Testing implementation details such as internal members or state is a code smell and is almost certain to produces brittle tests; tests that break when you make seemingly unrelated changes. If you find that you keep having to rewrite your tests when you update the internal implementation of your units, then you are probably heading down a terrible path and should step back and reconsider the way you are working.

Instead a unit test should only be concerned with testing externally observable behavior of the unit. This does not only mean the public API of the unit, but also behavior that can be observed through the dependencies of the unit. What this means is that the unit under test might be calling out to one of its dependencies and that call can be observed from outside of the unit.

One thing that you need to tend to when you are writing unit tests is to make sure they have no side-effects. A unit test should run in complete isolation of each other and the order in which they are executed should not have an impact on whether they fail or not. This could happen if the units have not been isolated and one test alters the state of a dependency (for example a database) in such a way that another test will fail because of it.

I recommend that you read ”What is unit testing?” by Justin Etheredge if you want to learn more about the characteristics of a unit test.

Test-Driven Development

The one thing that TDD has going against it is its name. Because it has the word ‘test’ in the name it is often misunderstood as being a more fancy way of saying that you write unit tests for your code, nothing could be more wrong.

So exactly how does TDD differ from writing unit tests? Strictly speaking from a testing perspective, not much. You use the same techniques and tools to write your tests. Both tests are unit tests and both tests are interested in the externally observable behavior of the unit. The difference lays in the goal of the tests.

TDD is not about testing, it is about how you develop software. The goal of TDD is to produce code of high architectural quality by letting the tests drive the design of your code. This done by applying what is known as “Test First”, where you write the test case before you implement the code that will make it pass. This forces you to really think about how the implementation should work, instead of writing a test to make sure the code you already have in place works.

This is where the ‘test’ part of the name skews many people’s conception of TDD, because it is not really so much about testing as it is to write down (executable) specifications on how the code should behave. Got that? First you write down your specification on how it should work, then you write just enough code to make it work.

Because of the naming confusion people like Martin Fowler suggested it should be called Specification By Example and Brad Wilson (and friends) started calling it Design By Example, both being far more descriptive of the real intent of TDD.

When writing code using TDD you follow a what is known as the “TDD Mantra” also referred to as Red – Green – Refactor. This breaks down to a very simple development cycle.

1. Write a test that captures the intent of the code
2. Run the test to be sure it fails
3. Implement the least amount of code required to make the test pass (do not take design into account)
4. Run the test to make sure it passes
5. Re-factor the code into a more elegant design
6. Re-run tests to make sure the refactoring did not break anything

By starting with writing the test first you really have to think about the intent of the code you are going to implement. You run the test to make sure you do not get a false positive. Next you write just enough code that is required to make the test run and verify the implementation by running the test once more, making sure it does not fail this time. Once that is done, you refactor your code to a more elegant design, taking full advantage of all your code design skills and practices. After you have cleaned up your code it is a good idea to run all of you tests again to make sure you did not break anything else in the process.

If you stay true to this development cycle you will realize that you are no longer adding code based on assumptions, but instead only add the code that your specifications require. There are probably not a developer alive that is not guilty of adding that extra method overload or property just because it could turn out to be useful. Instead of being useful it could turn out to be a maintenance nightmare and because of backward compatibility issues you may not be able to remove it later on. Scott Bellware talks about this in his ”TDD is about not knowing” post.

Assumptions really do have a huge impact on code design even though we do not think much of it. Even if you were to follow the TDD development cycle you are still going to be putting a great deal of assumptions into your design. It is in our nature as humans and, most of all, developers. Keith Braithwaite created a workshop titled ”TDD as if you meant it” to challenge our perception of how many assumptions we really put into the design of our code.

Gojko Adzic attended Keith’s workshop and blogged about it in a post entitled ”Thought-provoking TDD exercise at the Software Craftsmanship conference” and later on Mark H. Needham did a ”coding dojo” on the same subject. I encourage you to visit and read those posts, even if you are a seasoned TDD practitioner, I’m sure they will challenge your perceptions.

Even though TDD is not explicitly about testing, the tests still have some quality assurance values. For example they are still a prime candidate for automated regression and acts like a safety net when you refactor your code to reach a higher degree of architectural quality. Be sure to treat the tests like first class citizen in your project and take the time to keep them up to date and clean. Avoid commenting out a failing test because you feel you are under time constraints or with the notion that you will be coming back to fix the test at a later stage.

The tests are your specifications. If your specifications are not up to date and correct then there is no way to tell if the code you are developing is the code you should be developing. You would not treat a formal specification document with such disregard would you? If not, then why would you want to do it with an executable version of them? They are your friend, they will keep you out of trouble and out of the debugger. They are the first client that will touch your code and, if you take the time to craft them well, they will never lie to you. Embrace them.

Summary

I hope that it is evident what the difference are between just writing unit tests and committing to the Test-Driving Development. There is very little required to get started with TDD, if you are already writing unit tests then you have all the tools you need to get going. TDD is a discipline and as time passes by you will use your gained experience to hone your skills. Why not grab a couple of friends and setup a ”Code Kata”, getting other peoples insight is awesome whether you are just fine tuning your own skills or just learning from scratch!

You can follow me on Twitter @ TheCodeJunkie

Thoughts on Jon Skeet not being allowed to renew his MVP

Today I launched twitter and saw some tweets that mentioned that Jon Skeet was no longer an MVP. Jon no longer an MVP? The very same Jon that has an unchallenged amount of reputation on the user list on Stackoverflow.com, the Jon that you’ll have a hard time not coming across if you browser the popular help outlets for .net related questions? Knowing well that Jon is one of the busiest guys in the .net community, when it comes to helping others out, this came as quite the surprise to me. So I headed over to his MVP blog and he confirms that he has asked not to be reconsidered fro renewal this year.

What came as an even bigger surprise to me was the reason behind it all. Apparently he had asked his employer whether or not it would be ok for him to be renewed this year and was advised that it would not be a good idea. So his employer doesn’t want him to receive recognition for his awesome contribution to the .net community? What business is it of theirs if he gets recognition for something he does on his spare time? Turns out (I can’t say I’ve been following his career) he works for Google and this is when I got a really sad expression on my face!

Of course everything here after are purely my own speculation and conclusions, but it looks like Google didn’t want one of their employees to get a Microsoft award, doesn’t it? It’s no secret that Microsoft and Google are fierce competitors. Microsoft is trying to gain shares of the online advertisement business, a multi-billion market, while Google have started gaining shares of markets that Microsoft have been perusing for years, such as mobile devices and operating systems. Don’t get me wrong, I think that the competition is a good thing for me as a consumer and I even endorse it, but I was hoping it didn’t have an effect on the employees of said companies.

I know a lot of people in the .net community and many of them work for Microsoft. There doesn’t appear to be a problem with people at Microsoft owning Apple hardware such as laptops, iPhones and iPods, not does there appear to be a problem with them using the Google search engine instead of Bing. I hope I’m wrong about this, surly Google can’t be that restrictive when it comes to their employees choice of hardware and platforms?

I hope the people at Google wake up and have a change of heart, Jon deserves to receive recognition for his contributions to the .net community despite who he works for. It can’t have been a secret who he was, what he did and that he was an MVP when he got hired.

Jon Skeet for MVP

Downloadable videos of the NDC09 sessions

Most of the recorded sessions from the Norwegian Developers Conference 2009 can now be downloaded from Rune Grothaug (Microsoft Developer Community Manager in Norway) blog. The entire conference was awesome and there’s plenty of great material to watch!

The following speakers can be found in the downloadable contents

 

• Ayende Rahien
• Craig Larman
• Ian Griffiths
• Jeremy D. Miller
• Jimmy Nilsson
• Jonas Follesø
• Kevlin Henney
• Michael Feathers
• Michele Leroux Bustamante
• Mike Cohn
• Peter Provost
• Phil Haack
• Rafal Lukawiecki
• Richard Campbell
• Robert C. Martin
• Roy Osherove
• Scott Hanselman
• Ted Neward
• Tim Huckaby
• Udi Dahan

So what are you waiting for? Go download the videos now!