Category Archives: Guidelines

Expanding and compacting a virtual disk of a VirtualBox machine

Today I suddenly got errors due to low disk space in my VirtualBox virtual machine. It appeared that I only had a few bytes of free space left on my dynamically expanding hard disk of 60 GB, so I was getting into trouble!

To solve this, I closed all programs, removed unneeded data and applications on the virtual hard disk (by deleting or uninstalling them manually and then using the disk cleanup utility):

compact1

After that I was able to free up 3 Gb, but of course this was not enough. It appears you have to do a number of additional things in order to really shrink the hard disk – and maybe at the same time make it a little bigger.

The next thing to do was to run defragmenter. In my case however the disk was not fragmented, so this step was not really necessary.

Then I downloaded a tool called sdelete and executed it in the virtual machine in an elevated command prompt (run as administrator), as follows:

compact2

This tool zeroes out unused bytes, which is needed before actually compacting the disk. After this, I shut down the virtual machine.

Now because the format of my virtual disk was VMDK, I had to download a tool called CloneVDI, which enables you to clone a virtual hard disk and at the same time compact and expand it. Cloning is also a safer method because if something goes wrong, you don’t screw up your original hard disk and so you can still go back and try again:

compact3

Note that I also checked the ‘Keep old UUID’, as I want the exact same machine (otherwise windows would have to be reactivated). If the new size is bigger, make sure to also check the ‘Increase partition size’ (alternatively you can extend the partition later in disk management of windows 7).

The clone process may take a while to complete:

compact4

The end result however is a virtual disk in native VDI format. Now it was just a matter of creating a new virtual machine and selecting the new VDI hard disk for it. But before that you can do this, you have to remove the original hard disk from the Virtual Media Manager, otherwise it will complain that a disk with the same UUID already exists:

compact5

After this, starting the new virtual machine resulted in a blue screen. The reason is that the hard disk was added under SATA controller, so I removed it and added it again under IDE controller:

compact6

After that it worked as expected.

Advertisements

WCF contract guidelines

Designing WCF services means you have to specify the contracts of the functionality that you want to expose. This blog entry contains some notes about the guidelines I follow.

Be explicit

The Name and Namespace properties control the name and namespace of the elements in the WSDL. Especially namespace is important because when you send SOAP messages, the elements need to be namespace qualified so that they can be serialized/deserialized correctly.

Namespaces follow the URI format, like http://schemas.dunatis.be, but are not actual addresses – they just represent the domain of your company, which is guaranteed to be unique.

In general, I recommend to:

  • explicitly specify the Name property, as to clearly distinguish the internally used names from the ones that will be exposed publically. Changing an internal property name will then not break the contract!
  • explicitly specify the Namespace property, because if you don’t specify the namespace, it defaults to http://tempuri.org – so it’s recommended to specify you own namespace – one that is relevant to your application.
  • explicitly specify the IsRequired property
  • explicitly specify the Order property, because if you don’t, the schema will be generated in alphabetical order. As a result, if you add new properties they will not appear at the end of the schema, which may cause issues.

Strict versus lax versioning

If you don’t have control over the clients that consume your service, you have to assume that contract changes would break their implementation. After all, a contract change means that the XML message changes, and clients may not be able to deal with that. In that case, use strict versioning, so that the original contract is not changed and instead, a new version is created and made available.

On the other hand, if you control the clients, you may choose lax versioning, and in this case you are allowed to modify the existing contract (in a non-breaking way) because it won’t break the clients using it.

For versioning I use a date indication yyyy/mm instead of version number, because it’s a W3C standard and it has more meaning.

Here’s a nice article that discusses versioning rules in detail. And this series is an excellent explanation about versioning strategies: part 1, part 2 and part 3.

Case sensitivity

Important to notice is that when contracts are processed, the WCF infrastructure is case-sensitive to both the namespaces and the names of data contracts and data members. Therefore I use:

Of course, this is personal taste.

Examples

Service contracts

[ServiceContract(Name = "CustomerService",

Namespace = "http://schemas.dunatis.be/2012/08")]
public interface ICustomerService
{
[OperationContract(Name = "GetCustomerDetails")]
GetCustomerDetailsResponse GetCustomerDetails(

GetCustomerDetailsRequest request);
}

The service contract has an explicit name and namespace. Namespace also has a version specification; this allows me to have a second version of the service later on in case breaking changes were needed in the contract (strict versioning).
 
The operation contract has an explicit name.
 

Message contracts

[MessageContract(WrapperName = "GetCustomerDetailsRequest",
WrapperNamespace =

"http://schemas.dunatis.be/customer/getcustomerdetailsrequest/2012/08")]
public class GetCustomerDetailsRequest
{
[DataMember(Name="Customer", IsRequired=true, Order=0)]
public Customer Customer { get; set; }
}

The message contract has an explicit wrapper name and namespace. Namespace also has a version specification.

The data members have an explicit name, and also Order and IsRequired are specified.

Data contracts

[DataContract(Name = "Customer", 
Namespace = "http://http://schemas.dunatis.be/customer/2012/08")]
public class Customer
{
[DataMember(Name = "FirstName", IsRequired = true, Order = 0)]
public string FirstName { get; set; }
}

The data contract has an explicit name and namespace. Namespace also has a version specification.

The data members have an explicit name, and also Order and IsRequired are specified.

Service implementation

[ServiceBehavior(Name = "CustomerService",
Namespace = http://schemas.dunatis.be)]
public class CustomerService : ICustomerService
{
public GetCustomerDetailsResponse GetCustomerDetails(

GetCustomerDetailsRequest request)
{
throw new NotImplementedException();
}
}

The service behavior has an explicit name and namespace.
 

Using constants

Instead of writing every namespace multiple times as a string, you could define constants and use these. Using the constant ensures that the namespace is the same for the contract and the service. If you make it available in a shared library, it also remains consistent across all of your projects/services/solutions.

public class NamespaceConstants
{
// Ensures consistency in the namespace declarations across services
public const string Namespace = “http://schemas.dunatis.be/2012/08;
}

[ServiceContract(Name = "CustomerService",             
Namespace = NamespaceConstants.Namespace)]
public interface ICustomerService
{
[OperationContract(Name = "GetCustomerDetails")]
GetCustomerDetailsResponse GetCustomerDetails(
GetCustomerDetailsRequest request);
}

 

Formatting strings

As a developer, we are constantly working with strings. I mean it, check your code, string operations are all around! And – I can’t help it – each time I see something like this:

var text = year + "/" + month + "/" + day + " " 
+ hour + ":" + minutes + " - "
+ "Completed in " + duration + "seconds.";

I have the irresistible urge to rewrite this to:

var test = string.Format("{0}/{1}/{2} {3}:{4} - Completed in {5} seconds.", 
year, month, day, hour, minutes, duration);

But is it a good idea to do that?

I personally use String.Format almost all of the time for a number of reasons.

First, (re)arranging/maintaining a string is a lot easier than having to (re)arrange/maintain a bunch of variables. Second, you can pass an IFormatProvider, so that you can easily specify formatting options for a specific culture. Third, it’s easier to spot errors. Fourth, consistency.

Now, you probably say: but what about performance?

Indeed, there are alternatives that are ‘faster’. StringBuilder, for one, is probably the most optimized. But really, does this even matter? We’re talking about microseconds here, and micro-optimization is in most cases something you should not think about – remember: premature optimization is the root of all evil:

“The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!): Don’t do it yet.” (Michael A. Jackson)

So unless you are working in a critical high-sensitive real-time system where microseconds are a matter of life and death; or you are messing around with thousands of string operations in a double loop or something; or hundreds of users are executing your string intensive code in parallel – maintainability and readability should be your prime concern.

If eventually performance is bad and should be improved, you can start thinking about measuring and optimizing it; but I hardly think that string concatenation would be your biggest concern in that case.

Iteration or recursion?

An interesting question came up… if you have to calculate the factorial of a number, how would you do it? As you know, the formula is simple:

rec1

My first thought was a recursive function:

public static int CalculateFactorialRecursive(int number)
{
if (number <= 1) return 1;
return number* CalculateFactorialRecursive (number - 1);
}

And an alternative would be a for loop:

public static int CalculateFactorialForLoop(int number)
{
var product = 1;
for (var counter = number; counter > 1; counter--)
{
product *= counter;
}
return product;
}

The question is: what method do you prefer?

Obviously the version that uses iteration is a lot easier to understand; and because I like simplicity it would probably be the best candidate. But what about performance? Doesn’t recursion also imply more overhead?

I created a small test that calculates the factorial of 1000 one million times; and the average duration for the recursive method was around 7300 ms:

rec2

The same test but this time using the iteration method was clearly faster:

rec3

So recursion is next to being hard to read also much slower. The reason is that each function call has to pop return value from the stack and push arguments on the stack, and also creates a stack frame (with information about the stack). All these operations take time. Also, you risk a stack overflow exception if too many stack frames are created (it is limited in size). And finally, because each call is accessing different parts of the memory, it hurts cache locality, which also means another slowdown.

Sure, if you only calculate one factorial, performance is not an issue. But in general, a more complex recursive function has more impact and performance may become a bottleneck.

Conclusion: only use recursion if it’s a natural solution for your problem and if performance doesn’t get hurt. In our example, we know in advance the number of iterations so we don’t need to use recursion; instead we can use a simple iteration that is much clearer to read and gives best performance.

Strategy pattern

Imagine the following scenario: we have some customer data that needs to be exported to an xml file somewhere. A solution could look like this:

public class Customer
{
    public Customer(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
}

public void Export()
{
    // retrieve the data
    var customers = new List<Customer>();
    customers.Add(new Customer("Walter", "Jones"));
    customers.Add(new Customer("Timothy", "Dawson"));
    customers.Add(new Customer("Michael", "Boyce"));

    // Convert data to xml
    var xml = new XElement("customers",
        from c in customers
        select new XElement("customer",
            new XElement("firstName", c.FirstName),
            new XElement("lastName", c.LastName)
        ));
    var encodedDoc8 = new XDocument(new XDeclaration("1.0", "utf-8", "yes"), xml);      

    // Create xml file
   encodedDoc8.Save(@"D:\temp\customers.xml");            
}

Nothing wrong with this approach, and the generated xml file looks fine:

But now let’s imagine that the generated xml should instead be exported to an ftp server, or the data should be formatted as a comma separated file, or maybe sent to an external service that processes it further. We would need to rewrite this method, or duplicate functionality, to support this. We don’t have the flexibility to easily replace or reuse functionality with this procedural approach.

Now the strategy pattern comes to the rescue!

First, we consider the export scenario to be a strategy. The export strategy consists of three steps:

  • Retrieve the data
  • Format the data
  • Publish the data in the new format

Each step of the strategy is a separate responsibility, which means that we are going to define an interface for each responsibility:

And for each interface, we will (at this time) have only one real implementation:

The MockRetriever implementation will generate some mock data, but later another retriever can be added that reads the data from a database.

The XmlFormatter implementation will take the data and formats it as XML, and later another publisher can be added that formats the data to a comma-separated format.

The FilePublisher implementation will take the formatted data and publish it as a file to some location on a hard drive, and later another publisher can be added that publishes the data somewhere on an FTP server.

So, in code, first add the interfaces:

public interface IRetriever
{
    IList<Customer> Retrieve();
}

public interface IFormatter
{
    MemoryStream Format(IList<Customer> customers);
}

public interface IPublisher
{
    void Publish(MemoryStream data);
}

And then the real implementations:

public class MockRetriever : IRetriever
{
    public IList<Customer> Retrieve()
    {
        var customers = new List<Customer>();
        customers.Add(new Customer("Walter", "Jones"));
        customers.Add(new Customer("Timothy", "Dawson"));
        customers.Add(new Customer("Michael", "Boyce"));
        return customers;
    }
}

public class XmlFormatter : IFormatter
{
    public MemoryStream Format(IList<Customer> customers)
    {
        // Convert data to xml
        var xml = new XElement("customers",
            from c in customers
            select new XElement("customer",
                new XElement("firstName", c.FirstName),
                new XElement("lastName", c.LastName)
            ));
        var encodedDoc8 = new XDocument(
                  new XDeclaration("1.0", "utf-8", "yes"), xml);
        var memoryStream = new MemoryStream();
        var xmlWriterSettings = new XmlWriterSettings 
                  { OmitXmlDeclaration = false, Indent = true };
        using (var xw = XmlWriter.Create(memoryStream, xmlWriterSettings)) 
                  { encodedDoc8.WriteTo(xw); }
        return memoryStream;
    }
}

public class FilePublisher : IPublisher
{
    public void Publish(MemoryStream data)
    {
        var fileToCreate = @"D:\temp\customers.xml";
        using (var outStream = File.OpenWrite(fileToCreate))
        {
            data.WriteTo(outStream);
        }
    }
}

Note that the formatter returns a memorystream, and the publisher takes a memorystream; to make them generic.

And now we can write the interface and implementation of the export strategy itself:

public interface IExportStrategy
{
    void Start();
}

public class ExportStrategy : IExportStrategy
{
    private IRetriever _retriever;
    private IFormatter _formatter;
    private IPublisher _publisher;

    public ExportStrategy(IRetriever retriever, 
            IFormatter formatter, IPublisher publisher)
    {
       _retriever = retriever;
       _formatter = formatter;
       _publisher = publisher;
    }

    public void Start()
    {
       var customers = _retriever.Retrieve();
       var formattedData = _formatter.Format(customers);
       _publisher.Publish(formattedData);
    }
}

Starting the export strategy is now easy and flexible: just register all real implementations with your favorite dependency injection framework, and then call the Start method of the export strategy. Using  another retriever, formatter or publisher is very easy to do: just register the ones you want to be used. Responsabilities are very clear, and you can easily test and mock each part of the strategy.

Another example

Suppose you have some cleanup mechanism, that needs a setting that comes from the configuration file (or a default one if it was not found in the configuration file):

public class Prices
{
public void CleanupPrices()
{
// Get number of days
var numberOfDaysConfig = ConfigurationManager.AppSettings["NumberOfDays"];
int numberOfDays;
if ((numberOfDaysConfig == null)
|| (!Int32.TryParse(numberOfDaysConfig, out numberOfDays)))
{
// some default value
numberOfDays = 7;
}

// Start cleanup here
}
}
 
To maximize reuse and flexibility, we could change this into a resolver:
 
public interface INumberOfDaysResolver
{
int Resolve();
}

public class NumberOfDaysResolver : INumberOfDaysResolver
{
public int Resolve()
{
// Get number of days
var numberOfDaysConfig = ConfigurationManager.AppSettings["NumberOfDays"];
int numberOfDays;
if ((numberOfDaysConfig == null)
|| (!Int32.TryParse(numberOfDaysConfig, out numberOfDays)))
{
// some default value
numberOfDays = 7;
}
return numberOfDays;
}
}

Then you can have it injected as follows:

public class Prices
{
private readonly INumberOfDaysResolver _numberOfDaysResolver;

public Prices(INumberOfDaysResolver numberOfDaysResolver)
{
_numberOfDaysResolver = numberOfDaysResolver;
}

public void CleanupPrices()
{
// Get number of days
var numberOfDaysConfig = _numberOfDaysResolver.Resolve();

// Start cleanup here
}
}