miercuri, 23 iulie 2008

The Evils of Shared Check Out

I won’t discuss the obvious what-do-you-do-when-somebody-else-checked-in-before-you-and-now-you’ve-ended-up-resolving-the-conflicts. I think there are more subtle motives why the version control shared check out has negative impact on modern software development.

I believe that the shared check out feature of most source control system (svn, cvs, tfs) originated in a time when developers worked on huge code files, when solving one bug meant making adjustments in more than one of these monstrosities at the same moment. In a time of stone age development tools, when modern programming concepts like OOP and FP were in still in the realm of academia and of obscure languages.

The tools and languages evolved, but the way they were used had its own inertia, based on human habit and familiarity with a way of “doing things”. Forget about one class - one concern, some people are still struggling with one function – one concern.

The conclusion is that if you are aware of a couple of development techniques, there will be no need for shared check out. One class should be modified for only one reason, so two people don’t have to edit it at the same time.

Of course there are counter examples. I already hear people shouting “configuration files”, “generated code files” etc. Those are exceptions and at the same time, they are not. If you’re willing to break the structure into small, manageable parts, you’ll find a solution for them. And if you really need to store many things into one file, be sure to set rules for how people should edit it, so they know how to not get into trouble. This is a similar problem to using only pure functional programming. FP is great, but you’ll need to modify state sometime: make sure you’re doing it in a standard, isolated way, so when a problem arises you’ll know what you’re dealing with.


Stumble Upon Toolbar

marți, 22 iulie 2008

Why You Should Write Your Own O/R Mapper ... Or At Least Try

Because you will not use it. But in the process you'll probably learn a lot of things about what a data access layer is. And more important, you'll be able to judge the existing O/R mappers and chose the one that fits most of your needs.

The down side is that the period of time before you choose to "upgrade" to an already existing solution will seem a waste, and all the code you've written must be thrown away. That won't be an issue if you keep in mind that things are replaceable and if you build a loosely coupled designed so components, like the data access layer, can be replaced, almost, effortless.

This pattern applies to other general "patterns", like dependency injection containers. Hands on experience with their "entrails" should give you a better understanding of how they work, and a better appreciation of the ones that are already available. And chances are you've already tried to build something similar but never knew exactly what you wanted, or what the big picture of the solution is.
Stumble Upon Toolbar

vineri, 18 iulie 2008

Nice Design Example for a Simple Data Access Layer

If you are in the process of implementing a small data centric application, you'll probably need to write some data access code. I've recently stumbled upon Los Techies, which is a wonderful resource for good programming practices. I especially enjoyed Jimmy Bogard's series on the problem of separation of concerns.

The series is centered towards refactoring an existing solution to a better design, employing well known patterns and practices. But the interesting part is that at the end the result is a nice blue print for a general data access layer based on Linq. And a really good start point if you're trying to build one.

Below are links for the six parts of the series:
Separation of Concerns - how not to do it
Separation of Concerns by example: Part 1
Separation of Concerns by example: Part 2
Separation of Concerns by example: Part 3
Separation of Concerns by example: Part 4
Separation of Concerns by example: Part 5
Stumble Upon Toolbar

joi, 17 iulie 2008

Linq to SQL Server CE and uniqueidentifier columns

There will be a couple of issues if you you try to use linq to sql with a SQL Server CE database. First of all the VS2008 designer doesn't allow adding tables from this type of database. The solution is to use the SqlMetal command line tool in order to generate the dbml or the code file (see here).

The second issue is that uniqueidentifier columns with the rowguid property will not work. More precisely, they will not autogenerate a value upon inserting a new row. Setting the column property to IsDbGenerated in the dbml mapping file is even worst: it will crash the insert operation. There is a workaround for this problem: in the partial class of the respective table entity, create the partial method "OnCreate" and manually set a new Guid for the new record:

partial void OnCreated()
{
    if (ID == Guid.Empty) ID = Guid.NewGuid();
}
Stumble Upon Toolbar

luni, 3 decembrie 2007

Implementing a Double Linked List in C# - part III

Welcome to the third part of the series on implementing a double linked list. It is now time to finalize the basic functions of the list, as well as some extra helper functions. The latter have the purpose of easing the use of the list for its users.

In this episode we'll cover the following:

  • Delegate some of the concerns of the list to its nodes;
  • Implement the IEnumerable interface, and the associate iterator;
  • Add a bit of "closure" to our list.
  • Removing items from the list

Preamble

The main difference between our implementation of the doubly linked list and the one provided by the .Net framework, is in the accessibility of data. While the .Net framework version exposes the data through the nodes containing it, we, on the other hand, expose it directly. This might be a shortcoming in terms of flexibility for navigating locally in the list. But the benefits come in form of structural integrity of the list, while permitting low level alteration of the structure of the list, and a better user experience in terms of accessing the data. What I mean by keeping control over the structural integrity of the list is that the consumer of the list can't make modifications that could break the chain of references or desynchronize the count of nodes, but the list can make modifications at that level internally. Of course these low level operations are also available to the inheritors of the list.

Revisiting the Node Class

Until now we've managed to ignore the Node class, but she "feels" that and tells us: "Listen, I'm pretty good at holding hands (references) with my left and right neighbors, so let me add new neighbor nodes as well as remove myself from the list". So we delegate to the Node class the concern of "keeping up references" during the operation of the list.

Adding a neighbor to the left of a node, means that we have to change:

  • the reference of the original left node to its right node, to the new node;
  • the reference to the original left node, to the new node;
  • the reference of the new node's left node, to the original left node;
  • the reference of the new node's right node to the current node.

    public Node<T> EnchainBefore(T item)

    {

         Node<T> node = new Node<T>();

         node.Data = item;

         node.Previous = Previous;

         node.Next = this;

         Previous.Next = node;

         Previous = node;

         return node;

    }


Removing the current node means we have to make its two neighbors reference each other:

public void RemoveFromChain()

{

     Previous.Next = Next;

     Next.Previous = Previous;

}

Implementing the IEnumberable Interface

The interesting part is not implementing the IEnumerable interface, but the IEnumerator. The twist is that the enumerator must "enumerate" through the list in two directions: forward as well as backward. Essentially the iterator will follow the chain of references starting with the left sentinel and ending with the right sentinel for forward enumerating. The iterator will go the other way around for backward iteration. This logic is embodied into the MoveNext method:

public bool MoveNext()

{

     if (forwardDirection)

     {

          current = current.Next;

          return current != rightSentinel;

     }

     current = current.Previous;

     return current != leftSentinel;

}

The rest of the code is just plumbing and we shall not go over it.

A Little Bit of Closure

We need a way of applying some function to the list of nodes. The process must be controled by the function, meaning that the function can dictate when to stop the process.

Introducing the predicate. The predicate is a delegate with one generic parameter, which returns a boolean value. We could have built our own delegate, and in one way it would have been better, because we are abusing the purpose of the predicate as intended by its creators. But why reinvent the wheel when it's already there.

So let's define the Apply method, which applies a predicate received as parameter to each node, as long as the predicate evaluates to (returns) true and there are still items in the list:

Public virtual void Apply(Predicate<T> predicate)

{

     Node<T> node = leftSentinel.Next;

     while (node != rightSentinel && predicate(node.Data))

          node = node.Next;

}

Removing items from the list can be easily implemented by using the Apply method. What I intend to do is iterate through the list as long as the current node does not contain the value we are trying to remove, and when we find it we'll ask the containing node to remove itself from the list and stop the iteration:

Apply(delegate(Node<T> node)

{

     if (item.Equals(node.Data))

     {

          node.RemoveFromChain();

          count--;

          return false;

     }

     return true;

});

Another method that coud use the help of the predicate is the Add method. This way we could make the items beig added to the list obey certain rules:

public virtual void Add(T item, Predicate<T> check)

{

     Node<T> node = leftSentinel.Next;

     while (node != rightSentinel && !check(node.Data))

          node = node.Next;

     AddBefore(node, item);

}

Now we have to tools to implement an ordered list:

public class SortedList : DoubleLinkedList<int>

{

     public override void Add(int item)

     {

          Add(item, delegate (int data)

          {

               return data < item;

          });

     }

}

That's all for this episode. Remember you can find the source code here.


Stumble Upon Toolbar

sâmbătă, 1 decembrie 2007

Creating a Double Linked List in C# - Intermezzo

Day by day I am amazed by Google's other services, besides web searching. One of the useful collaboration services offered by Google is Google Code. It is a free service for project hosting, which provides SVN version control.

You can now find the source code for the double linked list series at this location.
Stumble Upon Toolbar

joi, 29 noiembrie 2007

Headache Installing Visual Studio 2008

Last night I've tried to install Visual Studio ‚Orcas' RTM, but the setup kept crashing at the fisrt step of the installation (installation of the 3.5 framework). Digging into the setup log files I've traced the problem to the installation of the 3.0 framework SP1. After some trials and misses (I've even uninstalled the MacAfee antivirus), I've downloaded the framework 3.5 setup redistributable (the full install package). The setup went flawlessly, and after it ended I was able to install the new Visual Studio.

I hope this information will help someone in need.


Stumble Upon Toolbar