Roger Alsing Weblog

Here in sweden there are currently circulating some email with a challange about solving a math puzzle.
It’s nothing special really but the mail goes something like this (translated):
(Don’t blame me for the claims in the quote, it’s not my words)

It’s said that only people with an IQ over 120 can solve the following problem:

If we assume that:
2 + 3 = 10
7 + 2 = 63
6 + 5 = 66
8 + 4 = 96

How much is?
9 + 7 = ????

The mail contains an excel file with a password and can only be opened if you know the answer to the above.

Just for the hell of it I entered the problem into my old genetic expression evolver:
http://rogeralsing.com/2008/02/07/genetic-programming-math/

The application is based on genetic programming and does use genetic crossover and a real population (unlike my EvoLisa sample).

The problem was described like this:
problem.Cases.Add(new Case(2, 3, 10));
problem.Cases.Add(new Case(7, 2, 63));
problem.Cases.Add(new Case(6, 5, 66));
problem.Cases.Add(new Case(8, 4, 96));

The first and second arguments are variable values and the last argument is the expected output.

And here is the output of the application:

As you can see on the screenshot, the application have solved the equation in 250 generations (a few milliseconds).

That’s probably faster than you solved it ;-)

PS.
If it makes you feel better, I didn’t solve it at all, I go into fetus position on the floor when I see math problems ;-)

//Roger

I’ve been toying around with the Reactive Extensions (RX) Framework for .NET 4 the last few days and I think I’ve found a quite nice usecase for it;
Since RX is all about sequences of events/messages, it does fit very well together with any sort of message bus or event broker.

Just check this out:

Our in proc message bus:

public class MiniVan
{
    private Subject<object> messageSubject = new Subject<object>();

    public void Send<T>(T message)
    {
        messageSubject.OnNext(message);
    }

    public IObservable<T> AsObservable<T>()
    {
        return this
            .messageSubject
            .Where(m => m is T)
            .Select(m => (T)m);
    }
}

Subscribing to messages:

bus.AsObservable<MyMessage>()
    .Do(m => Console.WriteLine(m))
    .Subscribe();

The nice thing about this is that you get automatic Linq support since it is built into RX.
So you can add message handlers that filters or transform messages.
Pretty slick isnt it?

I’m currenty writing an example IRC chat client based on this idea which I will publish in a week or two.

//Roger

I’m still trying to learn a bit of F# and I thought of a quite nice experiment.
Since F# supports quotations (for you C# devs, think Linq Expressions on roids) wouldn’t it be possible to serialize such quotation and pass it to a webservice and execute that code there?

Imagine the following code for a fractal calculation:

for y = 0 to 100000 do
    CloudExec(
            <@
            let Fractal xx yy =
                .....fractal calculation....

            for x = 0 to 100000 do
                Fractal x y
            @>)

If “CloudExec” passes the code quote for individual scanlines of the fractal to the cloud, we could get some massive parallelism.
It would be just like PLinq but instead of executing a delegate in multiple threads, we would execute blocks of code on multiple threads on multiple machines (please ignore how naïve the code sample above is).

The biggest problem as far as I can tell would be to pass a result set back to the client in some way (that is missing in the sample code).
Input data doesn’t seem to be a problem since values defined outside the quotes are represented as constants in the quote.

It would ofcourse madness to expose such services to the public since you could pass in any code you want, but maybe it would work in an isolated environment.

Have anyone done such thing already?

//Roger

Here is one such example where F# developers try to make it look like F# can do things that C# can not.

http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!165.entry

F# code
F# code that apparently is much easier to read than C# code:

HttpGet "http://www-static.cc.gatech.edu/classes/cs2360_98_summer/hw1"
|> fun s -> Regex.Replace(s, "[^A-Za-z']", " ")
|> fun s -> Regex.Split(s, " +")
|> Set.of_array
|> Set.filter (fun word -> not (Spellcheck word))
|> Set.iter (fun word -> printfn "   %s" word)

C# code
My attempt to accomplish the same in C#.

HttpGet("http://www-static.cc.gatech.edu/classes/cs2360_98_summer/hw1")
    .Transform(s => Regex.Replace(s, "[^A-Za-z']", " "))
    .Transform(s => Regex.Split(s, " +"))
    //.AsParallel()  // [EDIT] now with parallelism support
    .Distinct()
    .Where(word => !Spellcheck(word))
    .Process(word => Console.WriteLine("  {0}", word))
    .Execute();

I think that’s fairly similar?

OK, I cheated, “Transform”,”Process” and “Execute” does not exist out of the box in C#.
You would have to write those extension methods yourself.
However, they are reusable and fits nicely into a util lib.

public static class Extensions
{
    public static TOut Transform<TIn, TOut>(this TIn self, Func<TIn, TOut> selector)
    {
        return selector(self);
    }

    public static IEnumerable<T> Process<T>(this IEnumerable<T> self, Action<T> action)
    {
        return self.Select(item =>
        {
            action(item);
            return item;
        });
    }

    public static ParallelQuery<T> Process<T>(this ParallelQuery<T> self, Action<T> action)
    {
        return self.Select(item =>
        {
            action(item);
            return item;
        });
    }

    public static void Execute<T>(this IEnumerable<T> self)
    {
        self.ToList();
    }

    public static void Execute<T>(this ParallelQuery<T> self)
    {
        self.ToList();
    }
}

Either way, I hope this shows that you can accomplish the same thing using good old C# instead of F#.

I think that Microsoft are trying to sell F# to us as something new and awesome, but I’m having serious problems seeing the benefits over C#.

But F# can do function currying!
Well, so can C#.

string Foo(int a,bool b)
{
    //do stuff
}

void UseCurry()
{
  Func<int,string> curriedFooWithTrue = a => Foo(a,true);

     //invoke curried function.
  var res = curriedFooWithTrue(123);
}

F# can do pipelining!
Well, so can C#

var listOfInts = new List<int> {1,2,3,4,5,6};
Func<int,int> squared = x => x*x;
var squaredListOfInts = listOfInts.Select(x => squared).ToList();

F# can use tuples!
Well, they are built into .NET 4 as a generic type so they are available for all .NET languages with generics support.

F# can do tail recursion.

OK, you got me, it can.
Now let me know the last time you really needed that?
All tail recursive algorithms can be implemented as iterative.
But sure, syntactic sugar is nice to have.

F# makes it easier to write async code.

This was one of the arguments at a demo of F# at PDC 2008.
They showed how it was made possible by using PLinq wrapped up in a C# assembly.

Maybe I’ve misunderstood every example I’ve seen, but most of them can be done in C# with pretty much the same amount of code.

What I would like to see is a really good F# example that would be very hard or impossible to accomplish with C#.
If F# is just slightly better than C# on some tasks, then the cost of bringing F# competence into a project will always outweight the slight benefits it brings.

Another argument is that it targets a completely different problem area.
OK, show us where F# shines without lying about what C# can and can not do.

Anyone got such example?

I predict that the C# 4 “dynamic” keyword will be the most abused feature.
It will be used for everything from ducktyped dependency injection, dynamic dictionaries and about a million Rails like frameworks.
All in a very non refactor friendly way.
…It will rarely be used to interop with dynamic .NET languages.

The least used will be the co/contra variance feature.
In 2011 not even the C# team will remember it exists.

The most frustrating feature will be code contracts.
Developers will cry out in pain when they realize that it might not be so easy as they expected it to be.

I’m just guessing :-)

Fetching POCO Entities and Value Objects using Linq To SQL

Linq To Sql support neither POCO Entities nor Value Objects when using it as an O/R Mapper.
What we can do is to treat it as a simple auto generated Data Access Layer instead.

By treating it as a DAL we can manually handle the data to object transformations in a type safe manner.
If we for example want to fetch a list of POCO Customers that also have an immutable Address value object associated to them,
we could use the following code to accomplish this:

//Poco prefix only used to distinguish between l2s and poco entities here
IList<Customer> FindCustomers(string name)
{
   var query = from customer in context.Customers
                   where customer.Name == name
                   select new PocoCustomer
                   {
                      Id = customer.Id,
                      Name = customer.Name,
                      Address = new PocoAddres
                            (customer.AddressStreet,
                             customer.AddressZipCode,
                             customer.AddressCity)
                   };

    return query.ToList();
}

This approach is quite handy if you work with multiple data source and don’t want to mix and match entities with different design in the same domain.

I’m sure many will find this approach quite dirty, but I find it quite pragmatic;
You can be up and running with a clean domain model in just a few minutes and simply hide the Linq To Sql stuff behind your DAL classes.

This works extremely well if you are into the “new” Command Query Separation style of DDD.
You can use Linq To Sql to create typed transformations from your Query layer and expose those as services.

Personally I’ve grown a bit tired of standard O/R mapping frameworks, simply because they try to do too much.
There is a lot of magic going on, it’s hard to keep track on what gets loaded into memory and when they will hit the database.

If I’m required to use both a memory profiler and a O/R mapper profiler in order to use the framework successfully, then something is very wrong with the whole concept.

This dumbed down DAL approach to Linq To Sql however makes the code quite explicit, you know when you hit the DB and what you get from it.
Sure you lose features like dirty tracking that mappers generally give you, but this can be accomplished by applying a Domain Model Management framework on top of  your POCO model.
Or maybe you just want to expose your objects as services and don’t care about those features.

[Edit]
In reply to Patriks comment:

If you go for Command Query Separation, you would only query the query layer, so you wouldn’t need to handle updates there.
And when it comes to writing data, you do that in the command layer , the commands carries the changes made from the GUI and thus you wouldn’t need to “figure out” what has changed.
The commands will carry that information for you.

Tracking changes in the GUI could simply be done by storing snapshots of the view specific data when you send a query.
Then pass a user modified projection together with the original snapshot to a command builder.
You could then submit the commands for processing.
[/Edit]

( hmmm, I somehow managed to turn a post about Linq To Sql into a rant about other O/R mappers, I usually do it the other way around :-) )

Dynamic where clause using Linq To SQL:

Let’s say we need to implement a search method with the following signature:

IEnumerable FindCustomers(string name,string contactName,string city)

If the requirement is that you should be able to pass zero to three arguments to this method and only apply a “where” criteria for the arguments that are not null.
Then we can use the following code to make it work: 

IList<Customer> FindCustomers(string name,string contactName,string city)
{
     var query = context.Cutomers;

     if (name != null)
        query = query.Where ( customer => customer.Name == name );

     if (contactName != null)
        query = query.Where ( customer => customer.ContactName == contactName );

     if (city!= null)
        query = query.Where ( customer => customer.City == city );

     return query.ToList();
}

This way we can pass different combinations of arguments to the method and it will still build the correct where clause that executes at database level.

Do note that this only works when the different criteria should be “AND”‘ed together, but it’s still pretty useful for use cases like the one above.

I have been trying to practice domain driven design for the last few years.
During this time, I have learnt that there are almost as many ways to implement DDD as there are practitioners.

After studying a lot of different implementations I have seen two distinct patterns.

I call the first pattern “Aggregate Graph”:

When applying aggregate graphs, you allow members of one aggregate to have direct associations to another aggregate.
For example, an “Order” entity which is part of a “Order aggregate” might have a “Customer” property which leads directly to a “Customer” entity that is part of a “Customer aggregate”.

According to Evans book this is completely legal, any member of an aggregate may point to the root of any other aggregate.
Evans is very clear on the matter that aggregate root identities are global while identity of non root entities are local to the aggregate itself.

The opposite pattern would be what I call “Aggregate Documents”:

Here the aggregates never relate _directly_ to other aggregate roots.
Instead, the associations may be designed as “snapshots” where you store light weight value object clones of the related aggregate roots.
An “Order” entity would have a “Customer” property which leads to a “CustomerSnapshot” value object instead of a Customer entity.
This way each aggregate instance becomes more of a free-floating document.

Since I have been applying both of these patterns, I will try to highlight the pros and cons of them in the rest of this post.

Aggregate Graph

The Aggregate Graph pattern is the approach I used when I first started doing DDD and I think that it is the most common way to implement DDD.
Since I was an O/RM developer (NPersist) this felt very natural to me, I could design my object graph in our design tool and then draw a few boxes on top of it and claim that those were my aggregates.
I most often used eager load inside the aggregates and lazy load between aggregates in order to avoid that the entire database was fetches when one aggregate instance was loaded.

This had a very nice “OOP” feel to it, I was working with objects and associations and I could ignore that there even was a database involved.

My “Repositories” were mere windows into my object graph, I could ask a repository to give me one or more aggregate roots and from those object I could pretty much navigate to any other object in the graph due to the spider web nature of the aggregate graph.

The pros of this approach is that it is easy to understand, you design your domain model just like any other class model.
It also works very well with O/R mappers, features like Lazy Load and Dirty Tracking makes it all work for you.

However, there are a few problems with this approach too.
Firstly, Lazy Load in O/R mappers is an implicit feature, there is no way for a developer to know at what point he will trigger a roundtrip to the database just by reading the code.
It always looks like you are traversing a fully loaded object graph while you are in fact not.
This often leads to severe performance problems if your development team don’t fully understand this.

I have seen reports over this kind domain models where the implicit nature of Lazy Load have caused some 700 round-trip to the database in a single web page.

This is what you get when you try to solve an explicit problem in an implicit way.

If you are going to use Lazy Load, make sure your team understands how it works and where you use it.

Another problem with this approach arise when you need to fill your entities with data from multiple sources.
Many of the applications I build nowadays relies on data from multiple sources, it could be a combination of services and internal databases.

When using Lazy Load to get related aggregates, there is no natural point where you can trigger calls to the other data sources and fill additional properties.
You will most likely have to hook into your O/R mapper in order to intercept a lazy load and call the services from there.
nowadays, I mostly use the second approach, Aggregate Documents.

Aggregate Document

Aggregate Document approach is much more explicit in its design.
For example, if you want to find the orders for a specific customer;
Instead of navigating the “Orders” collection of “Customer”, you will have to call a “FindOrdersByCustomer” query on the “OrderRepository”.

While I do agree that this looks less object oriented than the first approach, this allows developers to reason about the code in a different way.
They can see important design decisions and hopefully avoid pitfalls like ripple loading.

Another benefit is that since you only work with islands of data, you can now aggregate data from multiple sources much easier.
You can simply let your repositories aggregate the data into your entities.
(If you do it inside the actual repository or let the repository use some data access class that does it for it is up to you)

You don’t have to hook into any O/RM infrastructure since you no longer rely on lazy load between aggregates.

Personally I use eager load inside my aggregates, that is, I fetch “Order” and “Order Detail” together as a whole.
A side effect of this is that since I don’t use Lazy Load between aggregates and don’t use Lazy Load inside my aggregates, my need for O/R mapping frameworks drops.
I can apply this design without using a full-fledged O/R mapper framework.
I’m not saying that you should avoid O/R mapping, just that it is much easier to apply this pattern if you can’t use an O/R mapper for some reason.

This also makes it easier to expose your domain model in an SOA environment.
You can easily expose your entities or DTO versions of them in a service.

Lazy Load and services don’t play that well together.

Maybe it looks like I dislike the first approach, this is not the case, I may very well consider it in a smaller project where there is just one data source and where the development team is experienced with O/R mapping.
You can also create hybrids of the two approaches;
e.g. In Jimmy Nilsson’s book “Applying Domain Driven Design and Patterns” there are examples where an “Order” aggregate have a direct relation to the “Product” aggregate while the same “Order” aggregate uses snapshots instead of direct references to the “Customer” aggregate.

Snapshots also comes with the benefit of allowing you to store historical data.
The snapshot can for example store both the CustomerId and the name of the customer at the time the order was placed.

Thats all for now.

//Roger

For the last month I have been spending my spare time porting the awesome Java framework QI4J to .NET.
QI4J is the brain child of Rickard Öberg and Niclas Hedhman and it attempts to enable Composite Oriented Programming for the Java platform.
(For more info regarding Composite Oriented Programming see the QI4J website: http://www.qi4j.org/ )

I’m well aware that others have been doing spikes on COP for .NET, a few of those attempts can be found here:
http://stackoverflow.com/questions/152196/composite-oriented-programming-cop-net-4-0-mef-and-the-oslo-repository

However, I think it is sad to not reuse all of the effort and brain power that has been put into QI4J, and thus I decided to port it instead.

The code is currently only available from my SVN repository at google code:
http://code.google.com/p/alsing/source/checkout

Please note that the code will be released under the same license as the Java version (Apache License version 2.0)
And copyright notices for the ported code will also be applied to give credit where credit is due.

The .NET version is largely identical to the Java version as it is pretty much a plain class by class port.
However there are a few exceptions:

The concept of “Property<T>” is not available in the .NET version since C# and most .NET languages does support properties out of the box and it would feel awkward to write things like:

“order.Customer.Set(theCustomer)” rather than “order.Customer = theCustomer”

However, the framework does rely on the Property<T> internally and thus most of the state holding infrastructure is also identical to the Java version.

The Java version relies on its own set of query expressions while my plan is to possibly reuse those internally but rather expose a LINQ API for querying.
(I have not yet started to build that)

Currently supported concepts:

• Transient Composites.
• Prototyping
• Typed and Generic Concerns.
• Typed and Generic Side Effects.
• Typed Mixins, Generic Mixins and Private Mixins.
• Most of the QI4J injection annotations.

Soon to come:

• Value Composites
• Service Composites
• Immutable properties
• Abstract Mixins (which sadly won’t be as nice as in Java due to language differences)

And I will ofcourse post a few samples of what you can do with this ASAP, I just wanted to drop a little sneak peek :-)

//Roger