Note to self

In the context of programming

1. Less code is more code
2. Less code is in my experience usually better code
3. Less is easy, pretty (pretty easy)
4. Less doesn't need to be simple
5. Simple doesn't need to be less
6. Simple isn't bad!
7. Fancy code doesn't necessarily need to be simple nor less
8. Many steps doesn't need to be complicated or bad, but make sure you document it
9. Don't over-engineer!
10. Documentation is important but it is more important to be documenting
11. Keep your documentation up to date, use a wiki
12. Code should be self documenting
13. You can't document everything
14. Readability is very important
15. Trust your instincts
16. Structure and organisation is very important

1. Always insist on using a english platform when as developer, useful when:
1. creating screenshots you want to send to another country
2. searching for error messages on line
3. learning keyboard shortcuts 

Design problems in our view model?

The following code is found in the view model. An object is serialized, marked exported and persisted to the repository.

private void Export(object obj)
{
    var item = obj as IItem;           
    _itemSerializer.CreateCustomerItemXML(item);
    item.IsExported = true;
    _repository.Save(item);
}

There might be a problem with this function that I want to discuss a little. There is also an ExportAll method which iterates through all items not exported and persists that to the database.

As you probably already noticed there are no mechanics in the Export functionality that captures the fact that the item is already exported before it saves it. That means that you can select any item and re-export it any time you like, even after you've done changes to the item.

But in my opinion this is just weird behavior and a recipe for disaster since

• If you edit an item and invoke ExportAll the edited item updated but not exported.
• If you edit an item and invoke Export the edited item overwrites the existing data.

Also this code is found in the view model and a RelayCommand is instantiated so that we can use this code in the xaml view. But what if we want to use this code somewhere outside of this view? Another service. Shouldn't this logic be deeper and available at a lower more common level?

If I do changes to the logic in this method the changes will only be valid in the view model, but maybe this is ok? I hoping that I'm not creating technical debt in doing modifications to this method to throw exception when trying to commit data to the repository when trying to export items already having been exported.

Hello World with Microsoft Unity framework

Inversion of Control, dependency injection is achieved with the Microsoft Unity Framework. It is a nice framework for making loosely coupled applications.

Add the following references to your project after having installed the Unity application block.

--> Microsoft.Practices.ObjectBuilder2
--> Microsoft.Practices.Unity
--> Microsoft.Practices.Unity.Configuration
--> Microsoft.Practices.Unity.Interception
--> Microsoft.Practices.Unity.Interception.Configuration
--> Microsoft.Practices.Unity.StaticFactory

And then include the following using statement in your code:

using Microsoft.Practices.Unity;

The Hello World program:

using System;
using Microsoft.Practices.Unity;

public interface IHelloWorld
{
    string Text { get; }
}

public class HelloWorld : IHelloWorld
{
    public string Text
    {
        get { return "Hello, World"; }
    }
}

class Program
{
    static void Main(string[] args)
    {
        // Bootstrapping
        IUnityContainer unityContainer = new UnityContainer();
        unityContainer.RegisterType<IHelloWorld, HelloWorld>(); 

        // Resolving what class is registered with what interface
        var obj = unityContainer.Resolve<IHelloWorld>();

        Console.WriteLine(obj.Text);
    }
}

What's going on above?

1. Define the interface

public interface IHelloWorld

2. Make a implementation

public class HelloWorld : IHelloWorld

3.Bootstrapping: register your interface to any interface implementation

IUnityContainer unityContainer = new UnityContainer();
unityContainer.RegisterType<IHelloWorld, HelloWorld>();

4. Resolving what class is registered with what interface, invoke your code

var obj = unityContainer.Resolve<IHelloWorld>();

5. Resolve what class is associated with our interface. This is how you run/start your class.

var obj = unityContainer.Resolve<IHelloWorld>();

6. And you're ready to print hello, world. Of course you don't need to return a property. You could have done the console writing inside your implementation of the interface.

Console.WriteLine(obj.Text);