Yet another classic. This book is an extensive compilation of refactorings that range from providing meaningful names for variable to collapsing class hierarchies. Every pattern is introduced in three stages – Motivation, Mechanics, and Example. The Motivation section presents the problem that a refactoring is trying to solve. Then the Mechanics section explains how a refactoring should be conducted. When a refactoring is a combination of other refactorings the author provides references to those refactorings so that you can easily find them in the book. The last part provides a step-by-step example of how a refactoring can be applied to existing code.

The book is neatly organized and can be used a reference book for your everyday programming endeavors.

Print Friendly

“Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees.”

Here is another one of my favorite books. I am not sure if this book needs introduction but if you haven’t heard about it or read it, Clean Code is one of THE books on the art, I would say, of writing code. The book is all about writing clear, readable, and flexible code.

The first part of the book identifies patterns and best practices for writing clean code. Fortunately the book is not simply a compilation of patterns – in the second part of the book Robert C. Martin demonstrates how those patterns fit into real life refactoring scenarios. In the final chapter the author presents a list of code “smells” that can help you identify bad code.

Great book! Enjoy.

Print Friendly

Just copy the two .snippet files into C:\<Program Files Folder>\Microsoft Visual Studio 9.0\VC#\Snippets\1033\Visual C# , restart Visual Studio and you are good to go.

Enjoy.

Download snippets

Print Friendly

This is one of those movies that makes you think about our disregard of all living creatures and our arrogance as rulers of Earth. This amazingly well-crafted documentary exposes the annual slaughter of thousands of dolphins in a National Park at Taiji, Wakayama, in Japan. Though killing of dolphins is not banned in Japan the movie reveals the shocking methods that are used to capture and kill one the most intelligent and magnificent creatures on the planet. 

Not only does this movie deliver an important message but it is also a marvelous piece of filmmaking. Everything from the soundtrack and the spy-thriller-like script, to the shocking final images represents filmmaking at its best. This is definitely one of the greatest documentaries that I have ever seen.

And you would expect no less from the people that were involved: Louie Psihoyos (Director) who is regarded as one of top photographers in the world and has worked for National Geographic for 18 years, Fisher Stevens (Producer) – an actor and producer who has produced or executive produced over 15 films 5 of which have been nominated for Academy Award, Joshua Ralph (Music) whose scores are included in the Museum of Modern Art’s Permanent collection of film and video in New York, Richard O’Barry who is one of the top dolphin specialists in the world with his more that 45 years of experience,  and many other brave activists and filmmakers.

Some might consider the issues discussed in The Cove as inferior to ones like AIDS, Global Warming, and other ecological catastrophes but the final words of the movie reveal that no issue is too small to be neglected:

“If we can’t stop that, If we can’t fix that, forget about the bigger issues. There’s no hope.” – Richard O’Barry

Related links

Official website of The Cove
The Cove at TakePart Social Action Network
Oceanic Preservation Society

Print Friendly

As expected the program will rely on the file system classes that the .Net Framework provides. Naturally, I wanted to cover the I/O logic with tests so that I am confident that when the software is used it will not do damage to my files and will behave according to my requirements. So I started writing tests…

And here is the catch – in general it is not a good idea to have tests that are performing I/O operations like accessing files and databases. In such situations, but of course not limited to, mock objects are your friend. And before I go into more details about what mocking really is lets find out why mocking I/O is important? Well, for a ton of reasons:

• Usually faster than performing I/O operations
• You do not have have to deal with security issues
• You have more control – easily test intricate scenarios
• Test setup is far more easier to do 

The first thing that most people think about when asked about mocking is interfaces. And that is no surprise since mocking is built around interfaces. Here is a simplified version of the file system interface that I have created for my application:

public interface IFileSystem
{
    bool FileExists(string path);

    string GetFullPath(string path);

    string GetFileName(string filePath);

    string GetPathRoot(string path);

    string GetDirectoryName(string path);

    string PathCombine(string firstPath, string secondPath);

    void MoveFile(string filePath, string newFilePath);
}

This interface represents all operations that my application will be able to perform on the file system. As we will see, this interface allows me to create a fake implementation of the file system functionality (mock) which will be the cornerstone of all of my I/O tests.

As you have probably guessed I will be using MSTest to drive my tests but you can use a testing framework of your choice. In addition to a testing framework you also need a mocking framework. My favorite one is called Moq – it is very powerful and yet easy to use.

Let’s write some tests…

private Mock<IFileSystem> fileSystemMock;
private IFileSystem fileSystem;

[TestInitialize]
public void Initializer()
{
    this.fileSystemMock = new Mock<IFileSystem>();
    this.fileSystem = this.fileSystemMock.Object;
}

The first thing to do is to create the mock implementation of the interface that we are interested in. This first line of the Initializer  method will create a dummy implementation (mock) of the specified interface (in this case IFileSystem) and you can use the Object property to interact with an instance of the this dummy interface implementation. For convenience we copy the instance reference to “this.fileSystem”.

The mock (“this.fileSystemMock”) allows you to control the behavior of the mocked object and setup assertions which allow you to test the behavior of the mocked object.

The following two tests will assure that the Rename method of the MusicFileConfigurator class behaves according to my specifications. Here is the code that will be tested:

public class MusicFileConfigurator
{
    private IFileSystem fileSystem;

    public MusicFileConfigurator(IFileSystem fileSystem)
    {
        if (fileSystem == null)
            throw new ArgumentNullException("fileSystem");

        this.fileSystem = fileSystem;
    }

    public void Rename(string filePath)
    {
        if(!this.fileSystem.FileExists(filePath))
            throw new FileNotFoundException("File was not found", filePath);

        var newFilePath = this.AdjustNewFilePath(filePath, "renamed.test.file");

        if (this.fileSystem.FileExists(newFilePath))
            throw new IOException("New filename already exists -> " + newFilePath);

        this.fileSystem.MoveFile(filePath, newFilePath);
    }
}

Notice that the constructor accepts a parameter of type IFileSystem. This is very important, as you will see shortly, since it enables us to plug in different interface implementations. This technique is know as Dependency Injection – in this particular case we use the so called Constructor injection. For the sake of simplicity the Rename method will always rename the specified file to “renamed.test.file”.

Back to the tests… First I want to be sure that if a non-existent file is passed as argument the method will throw an exception.

[TestMethod]
[ExpectedException(typeof(FileNotFoundException))]
public void Rename_ThrowsException_WhenTheSpecifiedFileDoesNotExist()
{
    MusicFileConfigurator creator = new MusicFileConfigurator(this.fileSystem);
    this.fileSystemMock.Setup(fs => fs.FileExists(It.Is(s => s == "test.file"))).Returns(false);

    creator.Rename("test.file");
}

The first line, though boring, is crucial for understanding how the test works. Remember that “this.fileSystem” is actually an instance of the mock implementation? Well, now the MusicFileConfigurator is going to use this mock implementation of the IFileSystem.

The second line of the test reveals some of the power of Moq and mocking in general. This line instructs the file system mock to return “false” whenever “test.file” is specified as argument to the FileExists method. By doing that we ensure that the first condition of Rename will not be met and FileNotFoundException will be thrown.

The Setup method is very powerful and allows you to specify how the methods and the properties of your mocked objects behave – what results they returns, whether they throw exceptions and more.

Moving on to a move sophisticated test which asserts that the Rename method can successfully rename the specified file.

[TestMethod]
public void File_IsRenamed_Correctly()
{
    MusicFileConfigurator creator = new MusicFileConfigurator(this.fileSystem);
    this.fileSystemMock.Setup(fs => fs.FileExists(It.Is(s => s == "test.file"))).Returns(true);
    this.fileSystemMock.Setup(fs => fs.FileExists(It.Is(s => s == "renamed.test.file"))).Returns(false);

    creator.Rename("test.file");

    this.fileSystemMock.Verify(fs => fs.MoveFile("test.file", "renamed.test.file"), Times.Exactly(1));
}

Once again we have almost the same setup with just two additional lines. This time we want to test that when the Rename method executes without any errors it will actually rename the specified file. The two Setup statements ensure that the specified file exists and that the new filename does not (which is required by the Rename method).

So far we have just ensured that the Rename method will run without errors. To be sure that it can really rename files we have to make sure that Rename will call MoveFile with the correct arguments. With Moq this is a piece of cake.

Whenever we want to make sure that certain method has been executed or hasn’t been executed we use the Verify method. In this particular setup I want to assert that the Rename method calls the MoveFile method of the file system exactly one time with the expected arguments. If the conditions are not met – for instance the method is called more times – Verify will throw exception and the test will fail. 

I do not know if it is just me but I think that this piece of test code is simply beautiful. In addition to the easily readable fluent interface of Moq you are not dealing with the actual file system which spares you a a great deal of time and resources to setup our tests.

You might be wondering how is the MusicFileConfigurator going to working in a real scenario? Well, I have created a special implementation of the IFileSystem interface which uses the actual file system.

public sealed class DefaultFileSystem : IFileSystem
{
    public string GetFullPath(string path)
    {
        return Path.GetFullPath(path);
    }

    public string PathCombine(string firstPath, string secondPath)
    {
        return Path.Combine(firstPath, secondPath);
    }

    public string GetFileName(string filePath)
    {
        return Path.GetFileName(filePath);
    }

    public void MoveFile(string filePath, string newFilePath)
    {
        File.Move(filePath, newFilePath);
    }

    public bool FileExists(string path)
    {
        return File.Exists(path);
    }

    public string GetDirectoryName(string path)
    {
        return Path.GetDirectoryName(path);
    }

    public string GetPathRoot(string path)
    {
        return Path.GetPathRoot(path);
    }
}

And whenever I initialize the MusicFileConfigurator I do something like that:

class Program
{
    static void Main(string[] args)
    {
        MusicFileConfigurator configurator = new MusicFileConfigurator(new DefaultFileSystem());
    }
}

I have attached the full source code for this article which includes more tests.

Related links:
The Moq Project
Beginning Mocking with Moq

Download File – FileSystemMockingSource

Print Friendly

I have been yearning to write about this book for a long time since it  had become an all-time favorite. You have got to love this book for its incredible depth, witty jokes, great style, and funky structure. Definitely a must-read for every developer.

Don’t get fooled by the name though – the author covers a lot of ground and the book could be helpful not only to developers but project/product managers, QAs, HR, even top-level management.

Hard Code is a compilation of opinion columns written by the fictitious figure I. M. Wright (got to love the name), or as Eric Brechner calls it “my alter ego”.  In addition to topics like dev schedules, managing risk, agile methodologies, and testing the author covers other more esoteric, yet just as important, ones like people issues and team growth. Moreover the book can be considered as The Hitchhiker’s Guide to Microsoft since it offers quite a few details about the inner-workings of the software giant.

I will leave you with three of my favorite quotes from the book:

“A horse walks into a bar and says: I can code that feature in two days.”

“If you think Agile methods fix all that is wrong with how we build products, you are, in fact, a fool… If you are an anti-Agile curmudgeon who thinks Scrum is an acronym for System of Clueless Reckless Untested Methods, you are as much a fool and just as ignorant”

“If you treat your test team like trash, trash is likely what you’ll ship and trashy is how you’ll feel. If you prefer a smooth release and want to ship a great product, make your test team your ally. … [testers] They cover areas that you can’t or don’t want to do. They keep you on schedule and track. They keep you honest and represent the customer’s perspective.”

Now go read it!

Print Friendly

One thing that I do not like about the original themes, being a Silverlight and a WPF developer, is the fact that the XML colors were not configured. In addition to that, the output window uses a horrifying green-colored font that can make your eyes pop. Apart from those two problems I consider the two themes to be the best low contrast themes available.

I have made some adjustments to the original themes and I came up with my version which I use every day. Now the output window uses more subtle font color and the XML markup look a lot better. Here is the Zenburn Remixed:

I have attached a zip file that contains a Visual Studio 2008 setting file that you can use to apply the Zenburn Remixed theme. To do that just open Visual Studio, go to Tools –> Import and Export settings, and follow the wizard.

Many thanks to the guys that compiled the original themes.

Print Friendly

I have created a simple PowerShell script that will search for specific files in a directory and after that replace those files with a single file, which is specified in the script. Here is the scripts:

$FileName = "C:\new.png"
$TargetDir = "C:\myFolder\"

$FilesToOverride = get-childitem $TargetDir -recurse | where {$_.extension -eq ".png"}

Foreach ($file in $FilesToOverride)
{
    echo ("Replacing " + $file.FullName + " with " + $FileName)
    copy-item $FileName ($file.DirectoryName + "\" + $file.Name)
}

This version of the script will search recursively for all PNG files in myFolder and overwrite every PNG file with new.png. 

The script is very simple but if you are new to PowerShell (like me) you might not be familiar with all of the script’s building blocks. The first one is the “get-childitem” cmdlet. It retrieves items from a specified location, which could be anything – directory, registry, etc. The recurse switch indicates that the scripts will retrieve files not only myFolder but also from all of its subfolders. Get-childitem accepts many parameters which allow you fine tune the search query but that is outside the scope of this post. Here you an find more information about get-childitem.

In its current form get-childitem will return all files in myFolder regardless of their extension. That is where another commandlet comes into play. Where-Object (alias where) cmdlet is used to filter results from other commandlets and I use it in the script to select files with a specific extension (in this case PNG files).

Finally the script goes through the list of all files in FilesToOverride and overwrites each file using the copy-item cmdlet.

Helpful links:

Guide to Windows PowerShell Cmdlets

Piping and the Pipeline in Windows PowerShell

Get-ChildItem Cmdlet

Where-Object Cmdlet

Copy-Item Cmdlet

Print Friendly

Once in a while you have to change the size of a VHD file and I think I have found the perfect tool for the job. It is called VHD Resizer (previously known as VHD Expander) and it very easy to use. You can grab it from the vmToolKit (http://vmtoolkit.com/) website and expand or shrink the size of any Virtual Hard Disk file with just a few clicks.

Once you start the program you have to select a VHD file to work with and choose how to change the original VHD file.

You can choose the type of the VHD file (Dynamic or Fixed) and also the new size of the disk in GB or MB units. Click resize and after a couple of minutes, depending on the size of the disk files, you will have the resized file.

Mount the new file onto your Virtual Machine and you are almost ready to go. If you have expanded your VHD file, most probably, the partition that your Virtual Machine uses is not the correct size and the newly added space is reported as unallocated.

Use your favorite partition management tool, expand the partition, and you are ready to go.

Of course, you could do the geeky thing and use DiskPart utility to change the size of a VHD file. There is lengthy description of this utility called “A Description of the Diskpart Command-Line Utility” that you can find here .

Cheers.

Print Friendly

If you are working on a large project it is very probable that the project is composed of several parts/modules which are build separately. What are your options if you want to be able to rebuild the whole thing easily? If you are a Quake tournament winner equipped with Razer Copperhead mouse you could probably schedule 10 builds (in the right order) in a matter of seconds but what about your colleagues that are not so gifted? Well, there is the TfsBuild command line tool but in case you are using the 2008 version and you would like to have the freedom to choose a build agent when scheduling a build you are out of luck. It seems that the only viable option is to write a custom tool that talks directly to Team Build.

You can find the whole blog post here.

Print Friendly