jon torresdal

Live Meeting With Phil Haack On MVC 2 – August 26th

Jon Arild Tørresdal — Sun, 23 Aug 2009 19:52:55 GMT

The Community For MVC.NET will be running a Live Meeting with Phil Haack on August 26th @ 9am PST (4pm GMT / 6pm CET) on upcoming MVC 2 features.

Are SharePoint Developers Unable To Be Real Craftsmen?

Jon Arild Tørresdal — Sat, 22 Aug 2009 22:46:38 GMT

Even though I don’t develop software in SharePoint, this blog post by Lee Richardson reflect my thoughts and worries about SharePoint development.

The essence of his post is in this paragraph:

But the power given to end users makes rigor and good design extremely hard for developers because the production machine you deployed to last month may look completely different now that you’re ready to redeploy. And Microsoft makes good design even harder with an inflexible API. Critical classes like SPSite (think SqlConnection) contain no public constructor, rendering them completely unmockable (unless you’re willing to spend $450 per developer for some TypeMock Isolator magic). And vital classes like SPList (think DataSet) are marked final, crippling your ability to make nice strongly typed entities in your architectures.

Lee proposes some techniques to use that you should read in his post, but it’s half baked and not good enough in my opinion. The things he suggests (which is usually taken for granted on any other project) is made really hard to do by MS. Should MS rethink the way SharePoint is architected for the sake of developers to ease maintenance, improve code quality and basically allow developers working with ShapePoint to be craftsmen? Or is the dynamics of the product given to the end user so good that it’s worth all the extra efforts?

The Current Direction Of Agile

Jon Arild Tørresdal — Fri, 21 Aug 2009 04:03:39 GMT

A couple of days ago, my article about “The Current Direction Of Agile” was published on InfoQ. The article mainly represent my own learning curve within agile and lean inspired processes, hoping that my view would be interesting to others. I feel the recent Lean inspiration that agile has gotten the last couple of years, has pushed the agile community into a better place and been given tools to improve agile further.

Thanks to David J. Anderson and Arlo Belshee for reviewing the article, and not to forget Amr Elssamadisy @ InfoQ for pointing me in the right direction.

Replace Comments With Code

Jon Arild Tørresdal — Sun, 02 Aug 2009 22:36:48 GMT

It's tempting to just leave this blog post with that statement only :-) I will however explain this a bit further for those of you who either are forced to write comments (like by your boss or a policy at your company), or actually believe a lot of comments in code increase readability and ease maintenance.

I'm not trying to be sarcastic, I just believe 100% in code and not in comments. In .NET and most other OO languages there are two types of comments. The first type is the one you write in your code to explain what your code does. Like this:

//Calculate interest
double amount 
    = balance * Math.Pow(1 + (annualPercentage / 100) / 365, days)
      - balance;

How do you replace this comment with code? What about this:

double amount = CalculateInterest(balance, annualPercentage, days);

Whenever you come across comments like the above, I encourage you to refactor by replacing comments with code. Often you don't even have to extract a method like above, but just give better names to variables.

The second type of comments is the ones you use to generate API documentation:

/// <summary>
/// Calculate interest
/// </summary>
/// <param name="balance">Current balance of the account</param>
/// <param name="annualPercentage">Annual percentage</param>
/// <param name="days">Days to calculate interest for</param>
/// <returns>Interest amount</returns>
public double CalculateInterest(double balance, 
                                double annualPercentage, 
                                int days)
{

Almost on every project I've been on we've had these comments/documentation. Also, on the same projects they've never been used for anything useful. I've actually forced devs to do this myself! If you're creating a product/framework to be used by other devs, writing this type of documentation makes sense. If you don't, it makes no sense! I used to do this just to satisfy my own satisfaction of generating a chm file and see that all my methods and classes was documented. That was about it. I never used it once! It's much easier to look in the code than to look at the API doc.

The worst thing about this type of documentation is that it clutters your code and makes the code hard to read. A class with 50 lines of code becomes 100 lines with comments. As a practice, try to remove all comments and see if it's easier to understand and read the class. I strongly believe it is. If not, it's a code smell and you should refactor your code! Comments should not be used to explain bad code.

When I talk to people about comments in code I often ask them two questions:

Do you think it's hard to maintain code?

How hard to you think it is to maintain comments?

If you change your code, do you also make sure to check if the comments are still correct after you've done the changes? Most people don't and you shouldn't really need to worry about it. Outdated comments can create confusion and bugs just because someone forgot to update them.

Pricing For Azure

Jon Arild Tørresdal — Sun, 19 Jul 2009 12:51:15 GMT

This escaped my radar. The pricing for Azure is now public. From Mary-Jo Foley's blog:

Windows Azure:

Compute @ $0.12 / hour
Storage @ $0.15 / GB stored
Storage Transactions @ $0.01 / 10K

SQL Azure:

Web Edition – Up to 1 GB relational database @ $9.99
Business Edition – Up to 10 GB relational database @ $99.99

.NET Services:

Messages @ $0.15/100K message operations , including Service Bus messages and Access Control tokens

Bandwidth across all three services will be charged at $0.10 in / $0.15 out / GB

It's quite similar to Amazon's prices. Be interesting to see how long that lasts…

Start Using More Value Objects!

Jon Arild Tørresdal — Sun, 19 Jul 2009 11:29:12 GMT

At QCon London 2009, Dan Bergh Johnsson had a talk on the DDD track about how to make use of Value Objects (VO's) (The Power of Value - Power Use of Value Objects in Domain Driven Design (PDF)). In his talk he took a piece of code and refactored it into a better piece of code by using VO's. By doing this Dan showed some really good concepts of using VO's. Even though I knew about the concept of VO's before his talk, he made me realize many new scenarios where they are applicable. And more importantly that it is not limited to DDD.

So what is a VO anyway? Is it related to value type in .NET?

To answer the last question first: The real answer is no, but the way I see it there is a relation. A value type in .NET is everything that is not an object. Typically simple types like int, char, double, but also enums and structs. The relation is that often you find yourself creating VO's where value types was previously used. It is however not limited to value types.

Now to the first question. I first came across VO's after reading Evans DDD book (commonly known as the blue book). In DDD a Value Object is an object without an Id and are usually immutable. In examples of VO's, Address is commonly used, which I don't find particularly useful. I think Address way too often has an Id and people have a hard time relating to that as a Value Object. I find the Amount example I gave in an earlier post to a better example or the one below illustrated as an interface (borrowed from Dan):

public interface IPhoneNumber {
  bool IsValid {get;}
  string Number {get;}
  string AreaCode {get;}
}

How many times have you used the concept of a phone number in your code? Like mobile, fax, fixed etc… How often have you kept it as a string? How much code do you have for doing different types of validation, getting area code etc? Do you have it all in one place or scattered around in different places? Other examples are Money, ZipCode etc… These are great candidates for Value Objects.

Now that we know what Value Objects are, what is so powerful about them and why should I use them more? Great question :-) Below is my three reasons:

Code readability - I find that using Value Objects greatly improve the overall code readability and eliminates comments. Just like good names on methods and properties does.
DRY (Don't Repeat Yourself) - By having a Value Object for PhoneNumber, you avoid writing code to handle specific cases around phone numbers and you reuse them wherever the concept of a phone number is used.
Helps people getting back into OO thinking – We who have been living in the Microsoft .NET world for a long time have been thought to think of programming from a data/database perspective and not object oriented programming as we once learned it. In other words: think of behavior instead of data.

When I started to use VO's, I soon discovered I used them all over. They really add great value to my code. As an example, lets implement the IPhoneNumber above:

public class PhoneNumber : IPhoneNumber
{
    private readonly string _phoneNumber;
    public PhoneNumber(string phoneNumber)
    {
        _phoneNumber = phoneNumber;
    }
    public bool IsValid
    {
        get { return Regex.IsMatch(_phoneNumber, @"^[01]?[- .]?(\([2-9]\d{2}\)|[2-9]\d{2})[- .]?\d{3}[- .]?\d{4}$"); }
    }
    public string Number
    {
        get { return _phoneNumber; }
    }
    public string AreaCode
    {
        get
        {
            return Regex.Match(_phoneNumber, @"^[01]?[- .]?(\([2-9]\d{2}\)|[2-9]\d{2})").ToString();
        }
    }
}

The above code handles US phone numbers. To be used in a production system there should probably be even more validation in the regexp's, but I hope the example gives you and idea of what I'm thinking.

Different Ways of Refactoring Switch/Case

Jon Arild Tørresdal — Sat, 18 Jul 2009 22:53:15 GMT

One of the code smells I see most often in C# and other OO languages is the misuse of switch/case statements. When I was a young Jedi (some might argue I still am :-)) I didn't see anything wrong with using the switch statement. Actually there still are a few cases where it's still applicable, but most usages I come across should have been solved differently. So why is this? What is so bad with the switch statement?

As Dan North tweeted me when I asked for the perfect refactoring solution for switch statements :-) :

A switch is often a sign of behaviour that should live elsewhere - so where should the code in the cases live?

Functions should only do one thing, the one thing which they state. Like CalculateInterest and ConvertDateToString should do exactly that; calculate interest and convert a date to string. Since switch always reside inside functions it almost always violates that principle.

Let's look at what Uncle Bob (Robert C. Martin) says in his Clean Code book about switch statements:

Even a switch statement with only two cases is larger than I'd like a single block or function to be. It's also hard to make a switch statement that does one thing. By their nature, switch statements always do N things.

My answer to Dan's question above was using polymorphism. The cases should live in their own classes. By doing that you don't have to modify existing code when introducing new behavior, you just create a new state (read class). Btw Dan is really good at asking questions to questions where you end up answering your own question :-)

Enough with the coding theory. Below is a method using a switch statement for getting messages from different systems. Typically these are systems that another system depends on (the system containing the below code). The messages might be if the system is available or not, or if there are any maintenance planned.

public string GetSystemMessage(System system)
{
    switch (system)
    {
        case System.System1:
            return GetSystem1Message();
        case System.System2:
            return GetSystem2Message();
        case System.System3:
            return GetSystem3Message();
        case System.System4:
            return GetSystem4Message();
        default:
            throw new ApplicationException("System not found");
    }
}

This is actually quite a good switch. It uses return instead of break and it only has one line per case. If you can't avoid writing a switch, this is how you should do it.

Now let's pull it apart and make it better and extendable. Time for refactoring.

Polymorphism by using Strategy Template Pattern
Here's my code using the Strategy pattern:

public interface ISystemStrategy
{
    string GetMessage();
}
public class System1Strategy : ISystemStrategy
{
    public string GetMessage()
    {
        return "System1";
    }
}
public class System2Strategy : ISystemStrategy
{
    public string GetMessage()
    {
        return "System2";
    }
}
public class System3Strategy : ISystemStrategy
{
    public string GetMessage()
    {
        return "System3";
    }
}
public class System4Strategy : ISystemStrategy
{
    public string GetMessage()
    {
        return "System4";
    }
}
public class SystemMessenger
{
    private readonly ISystemStrategy _system;
    public SystemMessenger(ISystemStrategy system)
    {
        _system = system;
    }
    public string GetMessage()
    {
        return _system.GetMessage();
    }
{
}

First I define an interface to be used by the different systems (ISystemStrategy) and next each system (1-4) implements that interface, resulting in a class for each case in the switch.In addition I have a class called SystemMessenger that is responsible for accessing the system and get a message.

The switch can now be replaced by this code:

public string GetSystemMessage(ISystemStrategy system)
{
    return new SystemMessenger(system).GetMessage();
}

Note that the "client" only relates to the SystemMessenger class and not to the different implementations of ISystemStrategy.

The benefit of this code might not be obvious. Actually it might give the impression that this was a lot of code for almost nothing. Well, don't be fooled. The strongest aspect of the above solution is that you don't have to change the GetSystemMessage later when/if a new system is added, you just implement a new class.

To prove the above, here's what I need to do to introduce a new system:

public class System5 : ISystemStrategy
    public string GetMessage()
    {
        return "System5";
    }
}

To use the new system, an instance of System5 will be sent into GetSystemMessage just as before, and SystemMessenger handles the rest as before. No code change!

Dictionary
Another refactoring option is using some type of lookup table. In my example I'll use a dictionary together with the Func<TResult> delegate. However, I don't recommend doing this unless you have a really good reason to do so. Stick with the Strategy pattern if you can.

public class SystemMessengerDictionary
{
    private readonly Dictionary<System, Func<string>> _systems;
    public SystemMessengerDictionary()
    {
        _systems = new Dictionary<System, Func<string>>
                           {
                               {System.System1, GetSystem1Message},
                               {System.System2, GetSystem2Message},
                               {System.System3, GetSystem3Message},
                               {System.System4, GetSystem4Message}
                           };
    }
    public string GetSystemMessage(System system)
    {
        return _systems[system]();
    }
    //GetSystemX Methods
    ...
}

I decided to show this example even if I don't like it. The reason is that it is better than the switch. The worst about this in my eyes is that the enum is still there. I just hate enums! When reading the code they look like classes with interesting behavior, but then you discover they're just glorified int's :-|

Conclusion
Hopefully this example will help you understand why switch is something you should avoid and also give you an example of how it should be done. But before you consider doing any refactoring of existing code, consider a second question Dan asked (answered?) me:

How would it evolve if you added a few more cases? And how likely are a few more cases?

This is an important question, because you don't want to refactor just for the sake of refactoring. Keep this in mind before making use of any of the suggested solutions above.

WiX 3.0 Released

Jon Arild Tørresdal — Sat, 18 Jul 2009 10:52:39 GMT

A bit late announcement from me, but 4th of July WiX version 3.0 was declared stable. You can also find updated documentation for v.3.

Regarding my focus on WiX lately I haven't done much in WiX for a while. I was planning to add some more posts to my WiX tutorials, but currently this has not been my priority after I changed job. I used to work for an ISV where deployment was very important. Where I currently work we're in full control of all servers we deploy to. I do however plan to do some stuff with WiX here as well, but that will have to be later.

Refactoring TryParse Into a Value Object

Jon Arild Tørresdal — Mon, 22 Jun 2009 22:17:10 GMT

Recently I worked with a colleague on some code using decimal.TryParse() and tried to find a better way of using it. Specifically I had a string value representing a currency amount entered by a user in a web form. The amount needed more than just normal validation, so I needed to do some stuff with it.

Here's the code I started with:

public void SomeMethod(string userEnteredAmount)
{
    decimal amount;
    if(decimal.TryParse(userEnteredAmount, out amount) {
        //Do some stuff with amount
    }
    else {
        //Show message to user about invalid amount
    }
}

I've recently found many cases where I find the use of Value Objects to be very applicable. I found this case to be a particularly interesting example. Anyway, I created a Value Object called Amount to abstract away the TryParse stuff. Below is the class I created.

public class Amount
{
    private readonly decimal _value;
    private readonly bool _isValid;
    public Amount(string amount)
    {
        _isValid = decimal.TryParse(amount, out _value);
    }
    public decimal Value
    {
        get { return _value; }
    }
    public bool IsValid
    {
        get { return _isValid; }
    }
}

See how clean it got? At least I think so. The important part though is that it's usage is so much easier to understand and read:

var amount = new Amount(userEnteredAmount);
if(amount.IsValid) {
    //Do some stuff with amount.Value
}
else {
    //Show message to user about invalid amount
}

It's more code, but cleaner. Or did I say that already? :-) And of course it's reusable other places where amount has a meaning.

Scott Hanselman and Jeremy D. Miller to NNUG Bergen!

Jon Arild Tørresdal — Thu, 04 Jun 2009 11:08:05 GMT

As I’ve previously twitted through @nnugbergen and also through the invites I sent out yesterday, Scott Hanselman and Jeremy D. Miller is coming to NNUG Bergen Monday the 15th of June (Jeremy) and Saturday 20th of June (Scott).

Jeremy will do two talks. The first being Software Design and Testabillity and the second will be about StoryTeller, his take on integration testing. Scott will do his Deep Tour of .NET 4 talk.

To sign up or see the full agenda, use the links below:

Jeremy: http://nnug.no/Avdelinger/Bergen/Moter/NNUG-Bergen---Juni-2009---Jeremy-D-Miller/
Scott: http://nnug.no/Avdelinger/Bergen/Moter/NNUG-Bergen---Juni-2009---Scott-Hanselman/

In case you don’t know, all events going through NNUG is free, including these two! I’m already now worried how we’re going to top this next year. Maybe we should just close down NNUG Bergen after 2009 ;-)

Password Security Annoyances

Jon Arild Tørresdal — Sun, 17 May 2009 14:48:33 GMT

When so called secure institutions like banks, insurance companies and others ask you to create a password, you expect them to allow strange characters like ,.$#@{}[] to make the password stronger. To my surprise on several occasions I’ve experienced that they did not accept other than plain letters and numbers! What!? Didn’t the developer that implemented that logic raise a flag??

One specific case is with BankId (a national authentication mechanism for all banks in Norway), where I know the underlying implementation support strong passwords. However, when prompted by my bank to create the password, you’re not permitted. Actually I had to type in a temporary weak password and then change the password in the login screen which support the expected behavior!

At some point there had to be a discussion like this:

Developer: What type of password should we support?

Product Owner: What do you mean?

Developer: Should we allow people to make up their password from everything that they can find on their keyboard?

Product Owner: No, the normal alphabet and numbers should be sufficient. Or else people just forget their passwords.

My above experience with BankId was just an example from today, and in that case there were a workaround, which is not the common case. I always get puzzled when this happens. What puzzles me even more is that to prevent people from entering strong password, you actually have to code a business rule for exactly that! And what about those who only permit numbers!? What’s that all about?

Sorry for this rant, but I think it is important that we as developers, architects and technically skilled people take responsibility to avoid stuff like this to happen. I just can’t see one single good reason for limiting the users choice when it comes to passwords.

Geek On Bike

Jon Arild Tørresdal — Sat, 16 May 2009 16:27:10 GMT

This is a non technical post to add even more pressure on myself than the actual investment of my new bike and associated equipment.

I found it was about time to add some physical fitness to my life other than moving from the computer to get coffee or to and from the car on my way to work :-)

So this is a promise to myself (and now to the rest of the world I guess) that I will ride my new racing bike to and from work whenever the weather permits (read not snow or ice). However, I might need a few weeks of training to actually physically be able to get to work on a bike :-)