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