Tackling Spring

Spring is undoubtedly a powerful framework. But as I started to use it I was confused by its "magic". The complexity hidden from the user/developer. Hiding complexity may seem like a useful thing first but it will definitely bite you later. IMHO frameworks do not save you from the complexity. In order to use a framework productively you have to understand what it does under the hood.
What makes a good framework in my opinion is consistency. Some kind of pattern that runs through the framework. Something that makes it a lot easier and more convenient to deal with the framework once you understood it.
And I'm still struggling to find this pattern for spring. Maybe because spring is just huge. What I've learned so far is that spring is at its core a dependency injection framework. You can define stuff with annotations like @Component @Service or @Bean. Based on the type (or qualifiers) these dependencies (beans) are injected via the constructor or into fields marked with @Autowired.
Seems simple enough but what makes it more complex imho are "hidden" bean declaration declared by the use of other annotations.
Let's see where this quest will lead me to. Spring integrations are the next thing I'm going to learn.

Is REST really just CRUD over HTTP?

Over the last week I had an interesting discussion about API design. It's often said that a good web API must be RESTful. Many modern web APIs claim to be designed that way so REST seems to be a good idea. Unfortunately the most examples I've found on the web reminded me of CRUD. People tell you that one of the key principles of REST is to separate your api into logical resources and let the client manipulate these resources using the HTTP verbs (POST, GET, PUT, DELETE). At the first glance this sounds pretty much like CRUD. Are people still considering "our grand failure" as best practice for web applications? (I'm not saying CRUD is the failure. CRUD works very well for databases. The failure is trying to enforce a CRUD interface on applications! Feel free to use CRUD, but you have to understand the implications!)

But is REST really just another name for CRUD? I don't think so. Like Christopher Atkins says in his blog post "Three Common Fallacies Concerning REST" the idea that REST is simply CRUD over HTTP is "perhaps the most common fallacy in RESTful computing". REST does not depend on a certain protocol. It's an architectural style that defines some constraints for web architectures. According to "Architectural Styles and the Design of Network-based Software Architectures", Chapter 5 these constraints are:

1. Client and server for separation of concerns (to improve portability and scalability).
2. Stateless communication between client and server (to enable visibility, reliability, and scalability).
3. Cache to improve network efficiency.
4. Uniform interface to decouple implementations from the services they provide.
5. Layered system to facilitate scalability.
6. Code on demand (optional).

None of these constraints force you to use CRUD. But probably it's the uniform interface constraint that is often confused with CRUD. However Roy T. Fielding writes in a blog post: "Search my dissertation and you won’t find any mention of CRUD ..." (It's ok to use POST). He also says: "The only thing REST requires of methods is that they be uniformly defined for all resources (i.e., so that intermediaries don’t have to know the resource type in order to understand the meaning of the request)." So like mentioned before REST doesn't depend on a certain protocol, i.e. it doesn't require HTTP.  Therefore you don't have to use POST, GET, PUT and DELETE in a RESTful API. Not all of the four nor a subset of them. But regardless of what methods you use, each method must have the same meaning for all resources. As I understand it, one reason for this constraint is to distinguish between safe and unsafe operations without any knowledge of the resource type, e.g. if GET is a safe operation for all resources the results can be cached regardless of the resource type. Furthermore I think a uniform interface doesn't mean that every method must be defined for all resource types, e.g. if GET is defined for A you don't have to define it for every other resource type. But if you do you have to ensure that GET has the same meaning as for A.

So REST doesn't require a CRUD interface and even less a "CRUD-style architecture". A CRUD architecture exposes the entities to the client and lets the client manipulate them. A REST architecture makes resources addressable through URIs. But a resource is a "logical concept" which I think is not the same thing as an entity in terms of CRUD. Moreover in a REST architecture the client does not operate on resources but on their representations: "Defining resource such that a URI identifies a concept rather than a document leaves us with another question: how does a user access, manipulate, or transfer a concept such that they can get something useful when a hypertext link is selected? REST answers that question by defining the things that are manipulated to be representations of the identified resource, rather than the resource itself." ("Architectural Styles and the Design of Network-based Software Architectures", Section 6.2)

Doing research for this blog post I learned a few things about REST but I still don't have the feeling that I fully understand REST. There are also some questions that remain unanswered for me, e.g. how do I make behavior accessible through a uniform REST interface? A web service provides behavior not data. Can I model something that provides behavior as a logical concept? What are the representations of behaviors? How can I build a RESTful interface that captures the intent of the client?

Edit: Nice explanation about differences between CRUD and REST: http://programmers.stackexchange.com/a/120800

Lazy Evaluation And Infinite Data Structures In C#

Today I was reading the "Functional programming with Haskell" tutorial by Rob Harrop. In this article Rob also shows the ability of Haskell to handle the so called Infinite Data Structures using an infinite list of prime numbers as an example. The author defines infinite data structures as "data structures that abstract the details of some infinite stream of data". Due to Haskells support for lazy evaluation such infinite lists can be treated like normal lists. While reading the article I was wondering if I can do the same thing in C#. Though it's an eagerly evalutated language (means: the expression gets evaluated as soon as you assign it to a variable) using the yield keyword you can deal with infinite data structures:

public class Primes {
  public IEnumerable<int> All () {
    int number = 2;
    while (true) {
      while (!IsPrime (number)) ++number;
      yield return number++;
    }
  }

  public bool IsPrime (int number) {
    if(number < 3) return true;
    var seq = Enumerable.Range (2, number - 2);
    Func<int, int, bool> divides = (n,p) => n % p == 0;
    return seq.All(p => !divides (number, p));
  }
}

The Primes.All() method returns an "infinite" list of prime numbers. Thank to the yield keyword the numbers are not computed until you really use them, e.g. you can get the first ten prime numbers by:

var primes = new Primes ();
var firstTenPrimes = primes.All().Take(10);

With the power of the LINQ framework the Primes.All() method even becomes a "one liner":

public IEnumerable<int> All () {
  return Enumerable.Range (2, int.MaxValue - 1)
                   .Where (IsPrime);
}

I really like these functional features in C# :)

Changing the mindset (Anemic Model -> DDD & Event Sourcing)

Found a great series of blog posts about the journey from the procedural or so called Anemic Domain style of programming towards DDD and Event Sourcing: Changing the mindset! Using a simple domain the author starts with the Anemic Domain (I would say procedural) approach. Then he refines the solution using Object Oriented Modelling (the good old nouns and verbs game) and finaly presents an "event sourced" model for the same domain eliminating the need for a (relational) database in the course of the model transformation. In the last part the author also highlights the change in the mindset of the developer with each change in the modelling approach.

WaitiN Web Applications Testing

WaitiN: a .NET framework for testing web applications.

Greg Young's Event Store Now Available

Good news! :) Greg Young's event store implementation is now available on GitHub. For more information see http://geteventstore.com.

Backup data to a DVD-RW on OS X from the command line

1. Erase the DVD:

   drutil erase quick

2. Create an iso image:

   hdiutil makehybrid -iso -joliet -o image.iso path/to/source

3. Burn the image:

   hdiutil burn image.iso -noverifyburn

Slow Cheetah - XML transforms for config files

Today I have found another nice visual studio extension: Slow Cheetah. Using this extension you can transform configuration files during the build. It's really useful if you want to change the contents of your config files depending on the build configuration, e.g. adapting connection strings, paths, hostnames, wcf settings etc. With Slow Cheetah you can transform all kind of configuraion files in your project not only the app.config or the web.config.

Programmer Beekiping

Programmers are like bees :) "You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey". This quote is from a great article by Orson Scott Card: How Software Companies Die. A must read for all who wants to know how to scarry away good programmers and kill a software business.

Scritchy - CQRS without the plumbing?

There is a new lightwight CQRS framework/library that claims to allow quick building of CQRS applications for beginners or intermediate developers: Scritchy. It's a .NET project. The source code can be found at https://github.com/ToJans/Scritchy. There is also an example of a stocklist app that uses Scritchy: http://scritchyexample.apphb.com/. On that page there is also a video that shows how to build a CQRS application within few minutes using Scritchy. Since there is a widespread opinion that CQRS is hard to understand and an overkill for most applications let's hope that this micro framework can help to encourage developers to delve into CQRS.

Change the Target Framework for all Projects in a Solution

There is a great Visual Studio macro written by Scott Dorman that can be used to automate the changing of the target framework of all projects in a visual studio solution: Visual Studio 2010 and Target Framework Version. The macro is available on Scotts Sky Drive: ProjectUtilities.vb. Download it to \Documents\Visual Studio 2010\Projects\VSMacros80\MyMacros. Then open the the Macro IDE (Alt+F11), add the downloaded .vb file to MyMacros and run it. The solution must be opened in Visual Studio when you run this macro of course. The macro works well with 4.0 as target version (haven't tested it with other framework versions yet). Have fun!

Barrelfish: A New Open Source OS

On 8th july a new operating system called Barrelfish was released by ETH Zurich in Switzerland, with assistance from Microsoft Research. The source code is available in a Mercurial repository at http://hg.barrelfish.org. The system seems to be optimized for multicore architectures.

DDD Exchange 2011

Videos of sessions from DDD Exchange 2011 are now online on skillsmatter.com: DDD Exchange 2011 SkillCast videos. Great stuff! Definitely worth watching! Among others Udi Dahan talking about Composite Applications and Domain Models and showing how to turn monolithic applications with big and cluttered models into composite applications with lean domain models using Bounded Contexts. Also Greg Young showing great things you can do with tests and Event Sourcing: Assert.That(We.Understand).

Speeding up WCF Discovery

With the version 4.0 of the .NET framework Microsoft has enriched WCF with an implementation of the WS-Discovery protocol. Discovery allows WCF services to announce their availability and client applications to find these services at runtime without knowing the endpoint addresses. The WCF Discovery supports two modes the managed and the ad-hoc mode. In the managed mode there is proxy server that manages the information about available services. With the ad-hoc mode you don't even need a centralized server! In this mode services and client applications use multicast messages to announce their availability or to query available services. For more information about WCF discovery see WCF Discovery Overview on MSDN. This site also provides some usage examples.

In my opinion the second discovery mode (ad-hoc) is more interesting for loosely coupled distributed scenarios because you don't have to bother about a central point of failure (the discovery proxy). But playing around with WCF discovery I noticed that it takes some time on the client to discover suitable services. It's not really a big problem because you would usually do it only once e.g. during the application startup and cache the proxy or the endpoint address somehow. But if you only need only one service instance with a certain contract and you don't care which instance it is (if there are many of them) you can considerably reduce the time needed to discover the service address. You just tell the framework that you only need one result. To do so you have to setup the FindCriteria accordingly:

// Create DiscoveryClient
var discoveryClient = new DiscoveryClient(
                            new UdpDiscoveryEndpoint());
var criteria = new FindCriteria(typeof(IContract));
criteria.MaxResults = 1; // we only need one instance!
var findResponse = discoveryClient.Find(criteria);

If there is a service instance wich implements IWantedService the Find()-call would return much sooner than without adjusting the MaxResults property.

Unity: passing constructor parameters.

Unity is a dependency injection container from Microsoft. The version 2.0 is now available for download at codeplex: patterns & practices - Unity. You can use it to reduce dependencies in your .NET applications. Say you want to decouple your 'high level' code from the implementation details of the data access. With Unity you can define an interface like IDataContext and register the actual implementation in the Unity container:

var container = new UnityContainer();
container.RegisterType<IDataContext, SqlDataContext>();

In the 'high level' code you don't have to know the concrete type that implements the data access but just the contract: IDataContext. Unity will resolve the implementation you have registered at runtime:

var dataAccess = container.Resolve<IDataContext>();

Pretty easy so far but what if you want to pass a parameter to the constructor of your IDataContext implementation, e.g. a connection string? Just pass the value you want to be injected as a parameter when registering the type:

container.RegisterType<IDataContext, SqlDataContext>(
  new InjectionConstructor(connectionString));

Unity will pass the value you have defined here to a matching constructor of SqlDataContext when you will request an instance of it.

Dryad & DryadLINQ - academic release

An academic release of Dryad and DryadLINQ is available for download on Microsoft Research site: Dryad and DryadLINQ Academic Release.
Dryad is a distributed computing engine for clusters running Windows HPC Server 2008. DryadLINQ allows to use LINQ programming model in distributed application running on Dryad.

Parallel programming with .NET 4.0

Microsoft published 12 articles on parallel programming with .NET 4.0. You can download them here: Articles on Parallel Programming with the .NET Framework 4. These articles are mostly about TPL, PLINQ and thread safe data structures introduced with .NET 4.0.

Syntaxhighlighting for Blogger

Added syntax highlighting for the code snippets in my postings. Thanks to Heisencoder for his tutorial!

ReSharper's Object Initializer Quick Fix and IDisposable

This week I had to realize that not every Resharper suggestion is really useful. Some quick fixes carelessly applied can even introduce flaws into your code. The quick fix I have in mind is Resharpers suggestion to use an object initializer instead of creating an instance with subsequent assignments to its properties. Applying this quick fix to following code:

var person = new Person();
person.Name = "John";
person.Lastname = "Doe";

would change it to:

ver person = new Person {
     Name = "John", Lastname = "Doe" };

This quick fix is really handy and can imho improve the readability of the code. But it should not be applied when the type is an IDisposable! Why? An object initializer just creates a temporary instance of Person initializes the properties and then assignes this temporary variable to the variable person. Something like that:

var temp = new Person();
temp.Name = "John";
temp.Lastname = "Doe";
var person = temp;

The problem is that if an exception is thrown during the properties initialization you have no chance to dispose the new instance because you have no access to that temporary local variable. It's created by the compiler and is therefore not visible in you c# code. Even if you put the object initializer inside a try catch block or an using directive you will have a problem: http://ayende.com/Blog/archive/2009/01/15/avoid-object-initializers-amp-the-using-statement.aspx.

Things learned:

1. Never use object initializers with types implementing IDisposable
2. Resharper is a great tool but you should never apply quick fixes blindly. Think for yourself. Don't let the tools do the thinking for you ;)

ReSharper: remove unused references.

Today I was cleaning up unused references in a Visual Studio solution. Thanks to ReSharper it was not as tedious as I fought at first. Another great feature provided by this tool saved me a couple of minutes (or maybe hours):  http://www.jetbrains.com/resharper/features/navigation_search.html#Find_ReferencedDependent_Code.
To use it select the referenced assembly in the solution browser and choose "Find Code Dependent on Module" from the context menu. If the assembly isn't used anywhere in the current project ReSharper will show a message box saying: "Code dependent on module XXXXXXX was not found". In this case you can remove this reference safely.