ClearWriter is translated in English, Dutch, French and German and is free to try for 7 days. It can be downloaded from the store. If you like the app, and want to support its further development, you can buy it for only € 1,19.

If you have any questions concerning the app (feature requests, improvements, bugs, questions about the development) feel free to ask them here, or mail them to clearwriterapp@gmail.com.

In future posts i’ll document some interesting parts of the development process of ClearWriter.

Honestly, I’m not affiliated with JetBrains in any way, but I think they’ve got a fantastic tool, which makes a developers life a whole lot easier. If you are a C# developer, you should check it out.

I’m still discovering new functionality, even after using it for a few years. In this post I wanted to share my favorite shortcuts. They’ve saved me countless hours, so hopefully you’ll find some new ones, and save yourself some time too!

A remarks before we begin: these are the default ReSharper mappings, but it’s possible that you’ve made some changes to these mappings. If they don’t work, head over to your Visual Studio settings and check your keyboard mappings

Here they are (in no particular order)

Alt-PageUp/Alt-PageDown and Alt-Enter – Next/Previous highlight and Quickfix
It gives you a great feeling of power and control, just cruising over all the warnings in a file with Alt-PageUp/PageDown and fixing them with Alt-Enter. Clean code in no time.

Shift-Alt-L – Locate in Solution Explorer
When you need to quickly locate the file you have open in the Solution Explorer, this handy shortcut does the trick. You’ll be amazed at how many times you can use this!

Ctrl-F12 – Go to Implementation
Navigating around my code with F12 (Go to Definition) was common practice, but on an interface most of the time I wanted to go to its implementation. You can imagine my joy when I discovered this shortcut 🙂

Ctrl-Shift-R – Refactor this
The mother of all refactoring shortcuts. This gives you a context menu with the possible refactorings in the current context.

Recently a friend of mine handed me a copy of Martin Fowlers Refactoring: Improving the Design of Existing Code (that’s what friends are for). The book is considered a standard on refactoring en can still be seen as a must-read for every programmer, although it published in 1999.

Refactoring means to rewrite code, in small, safe (backed by unittests) steps. Doing this cautiously ensures that there is no loss of functionality and results in a decrease of error-proneness of the code and an increase in readability and maintainability. As Folwer mentions: the compiler reads your code once, while your and your colleagues will be gazing over it and changing it a lot times during coding. Making sure your code is readable (really readable, like a book) will save you and your coworkers a lot of time!

Fowlers book also helps you maintain the DRY (Don’t Repeat Yourself) principle. If you have to duplicate a piece of business logic in your code, it WILL cause you trouble. When the logic has to be altered, you can be sure that one of these places will be forgotten.

Before Fowler starts working on a piece of code, to fix a bug or add new functionality, he’ll often start with a refactoring to better understand the code. This may sound strange, but it is almost impossible to write perfect code from the start. I don’t mean working code, but code that is open enough to support all the possible questions, extensions or other changes and still is small enough to only do what it needs to do. If you accept the fact that you are going to have to refactor, and that it’s not a failure for you as a programmer, you can write better, cleaner code.

My favorite tool to do this (in .Net) is the fantastic ReSharper. A lot of the refactorings in the book can be done automatically and safely with this tool. It has an enormous list of functionalities, and I’m still discovering new uses every day.

An important note on refactoring is knowing when to stop. Knowing when to start is one thing, but at least as importing is knowing when you’ve refactored enough, or when a refactoring isn’t going as planned and the best thing to do is undo your changes. Huge reworks are done one refactoring at a time. You can always come back tomorrow to do the rest of them. As long as you leave the code in a better state than it was before, your good!

Refactoring fits perfectly in the iterative Agile process and is a corner-stone of Extreme Programming (XP). It’s no coincidence that Martin Fowlers can be found underneath the Agile Manifesto. Clean code will also provide value for the customer. Although it sounds counter intuitive, investing time in refactoring saves time writing code. A win-win!

I’m had to do some biztalk 2009 development on my machine, but it already had visual studio 2010 installed. So I had to install VS2008, which went better than I hoped (did not have to do an uninstall of 2010).

So I had my biztalk 2009 and my Visual Studio 2008 installed and was ready to go when I came across a problem. When I tried to open an existing or create a new Biztalk project I got this error:

Creating project ‘BizTalk project name’… project creation failed.

Damn…

After some google-fu I found a lot of people experiencing the same problem and even an msdn page about my problem. All of the evidence was correct. I had installed VS2008 SP1 after I installed biztalk.

From the MSDN page:

When Visual Studio 2008 is repaired or when a Visual Studio 2008 update is installed, the value of the following registry entry is changed from csproj;btproj to csproj:

The problem was that I did not have a PossibleProjectExtensions registry key. I added it, with the correct values. Same error. I repared biztalk. Same error. I restarted multiple times. Same error.

I tried to set the registry key to the value it should have been after an update of Visual Studio (only ‘csproj’) and after doing a repare of Biztalk then I found it changed the value to the correct value. Still, the same error…

So I gave up for now, lost too much time on it already. I’m developing biztalk on a different (virtual machine). Still if anyone has found a solution or experienced the same problem let me know, maybe we could start a self help group…

Because I practice Test Driven Development, I write alot of unittests. When code gets branched, most of the times these unittests all fail (an yes, they all ran green on the main branch). Most of the tests failed with the exception “Could not load file or assembly”.

Time to do some investigating, my dear Watson.

Nothing could be wrong with the tests themselve, because I was sure they worked and since they all failed, it was a global problem. I checked out the test settings we use (x.testsettings, should be next to your sln file) and went through all the tabs.

On the Data and Diagnostics tab I found we only had Code Coverage enabled, so I took a closer look at that by selecting the line and clicking configure at the top of the grid.

Aha, seems like all of these paths are still pointing to my main branch! I have no idea why these paths are not relative, but after selecting the correct assemblies (the ones from my branch) and deselecting the ones from the main brach, all was well and I could return to my unittesting bliss.

Now this is still a bit of a bummer if I have to do this for every branch I make. I should probably try to change these paths to relative ones, but I have not done that yet.

In our line of work it can be vital to keep up with the latest technology. Blog are ideal to keep up with recent news.

My favorite programming related blog is definitely that of Scott Hanselman. The humor he brings to these technical subjects is always entertaining. Also, he is one of my favorite speakers!

Another great blog to keep up with .Net related news is that of Scott Guthrie. Great in depth technical information.

Finally the ideal blog for programmers who don’t have enough time to keep up with all the blogs out there: The morning brew. Having someone wrap up all the interesting other blog posts daily means I don’t have to and can just read this one post!