Originally posted at 11/19/2010

I am writing this post from the point of view of the one you might have to ask forgiveness from, not the one who has to ask forgiveness.

There are two common styles of building software, one of them is Bold Exploration, and the second is Detailed Survey.

Bold Exploration have a rough idea about what is required, and immediately set out to build something that matches the current understanding. Along the way, both the team and the client will continually triangulate toward where they want to be. This is in effect the old “I’ll know it when I see it”. The problem from the point of view of the client (as in, me), is that I might be required to pay for those mistakes. For the most part, I don’t mind too much. One of the best aspects of this approach is that the time to get a feature in my hands is very short. I had a few memorable cases where it took the team three or four days to get something out that I could immediately comment on. There is another very important aspect. For the most part, this approach means that from my perspective, this is fire & forget. The way that I handle such things is usually by just having a phone call or two with the team, and then just getting their output and going over that, correcting the course if needed.

There were several times that mistakes where made, either because I didn’t explain right, a difference in vision or just simply because the team didn’t do things the way I wanted to. I asked for those to be fixed, and since we were operating on short time frames anyway, it didn’t cost too much (and I paid for both the mistake and the fixing of it).

Detail Survey involves the same initial phone calls, but then the team goes away to plan, estimate and build a plan for building the project. They are very careful about the way that they are going about doing things, and get back to me multiple times asking for clarification for this or that. When they start building the project, they start by building the foundations, getting things to work from the bottom up.  In many aspects, this is a very reasonable way to build software, expect for one very big problem. There is a long lead time until I get something that I can actually something with.

More importantly, this is me you are talking about, I am perfectly capable of looking at the code produce and estimate what they are doing. But, as impressive as a design is, it isn’t really interesting to me at all. I want to see the end features. And this approach takes a long time until I have something that I can actually work with.

I experienced both options recently, and I have to say that my preference is strongly toward the first approach. If pressed, I could give you a whole lot of reasons why I want that, valid business reasons, enough to convince any CTO or CFO. But mostly, it is an issue of matching expectations. When someone goes off for a month or two to do stuff, I get very nervous. And if you start building from the bottom up, it gets progressively harder to truly evaluate what is going on. When you get a working feature in the first week, even if additional work would cause rewrites/changes to this feature, you can be much more confident that this is going somewhere you want.

The other side is that no matter how careful the team is, there are still going to be differences between the final product and what I want, so changes will be made, but it is far more likely that with the Detailed Survey team aren’t used to those changes, and they are going to be harder to make.

In short, it all comes back to the fact that the shorter the feedback cycle is, the more happy I am.

Originally posted at 11/19/2010

I am writing this post from the point of view of the one you might have to ask forgiveness from, not the one who has to ask forgiveness.

There are two common styles of building software, one of them is Bold Exploration, and the second is Detailed Survey.

Bold Exploration have a rough idea about what is required, and immediately set out to build something that matches the current understanding. Along the way, both the team and the client will continually triangulate toward where they want to be. This is in effect the old “I’ll know it when I see it”. The problem from the point of view of the client (as in, me), is that I might be required to pay for those mistakes. For the most part, I don’t mind too much. One of the best aspects of this approach is that the time to get a feature in my hands is very short. I had a few memorable cases where it took the team three or four days to get something out that I could immediately comment on. There is another very important aspect. For the most part, this approach means that from my perspective, this is fire & forget. The way that I handle such things is usually by just having a phone call or two with the team, and then just getting their output and going over that, correcting the course if needed.

There were several times that mistakes where made, either because I didn’t explain right, a difference in vision or just simply because the team didn’t do things the way I wanted to. I asked for those to be fixed, and since we were operating on short time frames anyway, it didn’t cost too much (and I paid for both the mistake and the fixing of it).

Detail Survey involves the same initial phone calls, but then the team goes away to plan, estimate and build a plan for building the project. They are very careful about the way that they are going about doing things, and get back to me multiple times asking for clarification for this or that. When they start building the project, they start by building the foundations, getting things to work from the bottom up.  In many aspects, this is a very reasonable way to build software, expect for one very big problem. There is a long lead time until I get something that I can actually something with.

More importantly, this is me you are talking about, I am perfectly capable of looking at the code produce and estimate what they are doing. But, as impressive as a design is, it isn’t really interesting to me at all. I want to see the end features. And this approach takes a long time until I have something that I can actually work with.

I experienced both options recently, and I have to say that my preference is strongly toward the first approach. If pressed, I could give you a whole lot of reasons why I want that, valid business reasons, enough to convince any CTO or CFO. But mostly, it is an issue of matching expectations. When someone goes off for a month or two to do stuff, I get very nervous. And if you start building from the bottom up, it gets progressively harder to truly evaluate what is going on. When you get a working feature in the first week, even if additional work would cause rewrites/changes to this feature, you can be much more confident that this is going somewhere you want.

The other side is that no matter how careful the team is, there are still going to be differences between the final product and what I want, so changes will be made, but it is far more likely that with the Detailed Survey team aren’t used to those changes, and they are going to be harder to make.

In short, it all comes back to the fact that the shorter the feedback cycle is, the more happy I am.

Originally posted at 11/18/2010

Since RavenDB’s indexing is based on Lucene, we get a lot of advantages. One of them is supporting suggestions.

What is the Raven Suggest feature?  Let us say that we give the user the option to perform some query, but the query that they sent us isn’t returning enough results (or non at all).

We can ask RavenDB to figure out what the user meant. Here is the code:

 var q = from user in session.Query<User>("Users/ByName")
         where user.Name == name
         select user;

Now, we can call q.FirstOrDefault() on this query, and see if we got any results. If we didn’t get a result, we can now ask RavenDB for help:

 var suggestionQueryResult = q.Suggest();
 Console.WriteLine("Did you mean?");
 foreach (var suggestion in suggestionQueryResult.Suggestions)
 {
     Console.WriteLine("\t{0}", suggestion);
 }

This will produce the following output:

Enter user name: oren
Found user: users/1
Enter user name: ore
Did you mean?
        oren
Enter user name: onre
Did you mean?
        oren

This is a nice little feature, which can really make a difference in terms of your application’s user experience.

Originally posted at 11/18/2010

I got an interesting question today (I am teaching my NHibernate course now).

The tabular structure is similar to this:

But the desired object structure is:

That is quite different than the tabular model, but it is actually very easy to handle this with NHibernate.

Here are the mapping for the Address entity. We use the <join/> tag to have an entity that spans more than a single table:

<class name="Address"
       table="Addresses">
  <id name="Id">
    <generator class="identity"/>
  </id>
  <property name="City" />

  <join table="PeopleAddresses" >
    <key column="AddressId"/>
    <property name="IsDefault"/>
    <property name="ValidFrom"/>
    <property name="ValidTo"/>
  </join>

</class>

We then map the Person, using standard many-to-many mapping for the addresses:

 <class name="Person"
             table="People">

   <id name="Id">
     <generator class="identity"/>
   </id>
   <property name="Name" />

   <bag name="Addresses" table="PeopleAddresses" inverse="true">
     <key column="PersonId"/>
     <many-to-many class="Address" column="AddressId"/>
   </bag>
   
 </class>

There is just one thing thing to be aware of, you can’t add new addresses via the Person.Addresses collection, because the PeopleAddresses table has more data in it than just the keys. Presumably, you are handling this in some other fashion already.

All in all, this is a pretty elegant solution.

Originally posted at 11/17/2010

This is now a passing test…

public class UntypedMessages : IDisposable
{
    private readonly RavenMqServer ravenMqServer;
    private readonly RavenConfiguration configuration;

    public UntypedMessages()
    {
        configuration = new RavenConfiguration
        {
            RunInMemory = true,
            AnonymousUserAccessMode = AnonymousUserAccessMode.All
        };
        ravenMqServer = new RavenMqServer(configuration);
    }

    [Fact]
    public void Can_get_message_from_client_connection()
    {
        using(var connection = new RavenMQConnection(
            new Uri(configuration.ServerUrl), 
            new IPEndPoint(IPAddress.Loopback, 8181)))
        {
            var manualResetEventSlim = new ManualResetEventSlim(false);
            OutgoingMessage msg = null;
            connection.Subscribe("/queues/abc", (context, message) =>
            {
                msg = message;
                manualResetEventSlim.Set();
            });

            WaitForSubscription();

            ravenMqServer.Queues.Enqueue(new IncomingMessage
            {
                Data = new byte[] {1, 2, 3},
                Queue = "/queues/abc"
            });

            manualResetEventSlim.Wait();

            Assert.Equal(new byte[]{1,2,3}, msg.Data);
        }
    }

    private void WaitForSubscription()
    {
        // not important
    }

    public void Dispose()
    {
        ravenMqServer.Dispose();
    }
}

Unlike the previous posts, which were more design and up front, this post shows working code. I am still not completely happy witht his, mostly because of the RavenMQConnection ctor parameters, but I can live with this for now.

Originally posted at 11/16/2010

var readLine = Console.ReadLine() ?? "";
switch (readLine.ToLowerInvariant())
{
    case "CLS":
        Console.Clear();
        break;
    case "reset":
        Console.Clear();
        return true;
    default:
        return false;
}

What happens when you want to compose two distinct async operations into a single Task?

For example, let us imagine that we want to have a method that looks like this:

public void ConnectToServer()
{
    var connection = ServerConnection.CreateServerConnection(); // tcp connect
    connection.HandShakeWithServer(); // application level handshake
}

Now, we want to make this method async, using TPL. We can do this by changing the methods to return Task, so the API we have now is:

Task<ServerConnection> CreateServerConnectionAsync();
Task HandShakeWithServerAsync(); // instance method on ServerConnection

And we can now write the code like this:

public Task ConnectToServerAsync()
{
   return ServerConnection.CreateServerConnectionAsymc()
                 .ContinueWith(task => task.Result.HandShakeWithServerAsync());
}

There is just one problem with this approach, the task that we are returning is the first task, because the second task cannot be called as a chained ContinueWith.

We are actually returning a Task<Task>, so we can use task.Result.Result to wait for the final operation, but that seems like a very awkward API.

The challenge is figuring a way to compose those two operations in a way that expose only a single task.

Originally posted at 11/11/2010

Here is how you are supposed to read from a stream:

var buffer = new byte[bufferSize];
int read = -1;
int start = 0;
while(read != 0)
{
   read = stream.Read(buffer, start, buffer.Length - start);
   start += read;
}

The reason that we do it this way is that the stream might not have all the data available for us, and might break the read requests midway.

The question is how to do this in an asynchronous manner. Asynchronous loops are… tough, to say the least. Mostly because you have to handle the state explicitly.

Here is how you can do this using the new Async CTP in C# 5.0:

private async static Task<Tuple<byte[], int>> ReadBuffer(Stream s, int bufferSize)
{
    var buffer = new byte[bufferSize];
    int read = -1;
    int start = 0;
    while (read != 0)
    {
        read = await Task.Factory.FromAsync<byte[],int,int, int>(
            s.BeginRead, 
            s.EndRead, 
            buffer, 
            start, 
            buffer.Length -1, 
            null);
        start += read;
    }
    return Tuple.Create(buffer, start);
}

Now, what I want to see is using just the TPL API, and without C# 5.0 features, can you write the same thing?

Originally posted at 11/11/2010

The reason that I don’t like this API is that I think it provides a piss poor usability:

In short, it doesn’t provide me with any reasonable way to tell the user why I rejected a message.

Here is the proper way of doing this:

MessageVeto also contains a reason string, which provide a much better experience all around.

Originally posted at 11/11/2010

This is part of a base class, and we need to provide a way to veto messages for extensions.

Can you figure out what is wrong with this API?