Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

Well, this is probably going to be the last post on the topic, because to be frank, I am getting a headache and I don’t really see the point anymore. I would strongly advise anyone looking at this sample application to consider it to be the epitome of worst practices and what not to do. I am frankly stunned to see something like that.

I didn’t spend a lot of time with the application, and I more or less just skimmed it here and there, and almost every single time, I found something that horrified me.

Yes, there are places for disagreements when you discuss software architecture, places where a decision can go both ways and while you might disagree with it, you can live with it.

This isn’t such a case, this is a case of a project that is literally choke full of traps and scary places. If you don’t look too deep, it says all the right things, but once you get a bit deeper, you can see how this is causing a black hole in your mind, eating away anywhere where good things can grow.

This is the ultimate architectural exercise, building an architecture without building an application.

Except that you can’t talk about an architecture in isolation, architecture is always driven by the actual needs of the application, not by whatever the architect read about last night and is dying to see how it works in the real world.

This isn’t how this it done, and attempting to follow the guidance in this manner would result in a lot of time and money going down the drain.

I can’t emphasize this enough, avoid this codebase, don’t look at it, and never try to follow anything shown there, it will end in tears, pain and suffering.

I have a headache now, and I think that I’ll stop before it goes over the top.

Just before DevLink, I am going to be giving full day training on RavenDB and NHibernate.

• RavenDB Training with Oren Eini – August 15th, Chattanooga, TN
• NHibernate Training with Oren Eini – August 16th, Chattanooga, TN

This should be fun!

After spending so much time talking about the application, I think that you can understand why this isn’t going to work:

For a start, we don’t create an Inmate. A prison just doesn’t have this concept.  Second, the process of accepting a new Inmate into the prison is a pretty complex one. An Inmate can come from one of several sources. It can be a guy just brought in from the streets or it can be an Inmate from another prison (and then it depends on where he came from), etc.

Each scenario requires different workflow for processing the new Inmate. And what about errors in the process? For example, let us say that your prison is rated for 14 years old and up, and suddenly you have at the gate an officer with three 13 years old that were just arrested with suicide belts. Legally, you aren’t allowed to hold them. Practically, you can’t really let them go. (For the record, that was a real scenario that happened, I had to get a judge to approve this.)

Here is another true story. I sent an Inmate to another prison, and along the way, the escort manage to forget the documents (those are the oh so important that the sky fall down and smacks you in the head if you don’t have them) in my prison. They got to the other prison around 2 AM, and only then discovered what happened. I was able to convince that prison’s commander to hold the guy until morning in his prison until I can send the documents.

Validation? You make me laugh. This is the real world, and if your system reject an Inmate that the prison commander has decided that he is going to accept… well, that Inmate still has to be tracked, but now it is offline and probably done on the back of some envelope somewhere. The system may alert and warn, but it cannot deny people.

Welcome to the real world.

Overall, the process for accepting a new inmate is quite simple, at its core. You need to be able to identify the Inmate, and you need to have a valid chain of lawful incarceration. The first might be a problem (the guy might have been just picked up, have no idea and refuse to identify himself). The second might also be a problem, as we have seen above.

But eventually, we have the Dossier for an Inmate, which contains name, id, picture and the chain of lawful incarceration. The next step is to place the Inmate in the prison, and that is a whole different key of gunpowder. I’ll discuss that in my next post.

I am not sure if you have noticed, but for the last few weeks, we have had a small tag on the top left side of the blog. Clicking on this would reveal the following information:

As you can see, generating the main page took 6 sessions and 8 calls to the RavenDB server. This reflect the fact that when building RaccoonBlog, we were far more focused on the architecture and paid very little attention to the actual performance of the system and mostly focus on being correct and architecturally sound.

I’ll point out that with no attention to performance, the new blog out performs the old blog quite handily.

We can dig a bit deeper into what is going on here:

As you can see, we have a list of requests made to the server, including all of the queries made. This make it quite easy to figure out what is actually going on. For bonus points, we can even dig deeper and look at an individual request:

From debugging stand point, it is incredibly helpful. From a performance optimization perspective, it is invaluable. This feature alone has been responsible for three different bug fixes (all of them very hard to figure out without it) and has guided us into several performance improvements for the blog.

We took the idea from the Mini MVC Profiler, I really liked the idea of that, but didn’t really like the code, so we set out to build Raven.Client.MvcIntegration.dll.

In your MVC application, you need to reference that assembly and:

• In the Application_Start method, call Raven.Client.MvcIntegration.RavenProfiler.InitializeFor(documentStore).
• In your main layout, include the following line: @Raven.Client.MvcIntegration.RavenProfiler.CurrentRequestSessions()

That would setup the RavenDB Profiler for MVC applications, giving you direct access to whatever is going on in that request. We even handle Ajax requests as well

And a minor point as well, this feature is probably not something that you would use in production, but since I wanted to show it off for you, I made sure that it can be run in production. In order to facilitate this, there is a way to redact the information sent to the client, scrubbing it from any personal information. That has been done on this blog, but it is a fairly simple system, compromised mostly of the ability to black list specific fields by name. I would be careful when exposing this to the world, but especially if you are using this to see what is going on against a remote RavenDB instance, it can be invaluable tool.

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

Is it not invented here if a Microsoft project chooses to re-invent something that Microsoft already did?

Take a look at how queries are being performed:

That looks strange, let us dig a bit deeper, shall we?

And it is not alone! It has a full family and some friends too:

So you create a specification, and then you call that specification to create an expression tree, and then you use that expression tree for the queries.  If only we had builtin specification support in the framework! Oh, wait! It is called Linq! And it is already being used here, so they obviously know about it.

And no, this isn’t the case of needing to serialize specification over the wire, they are used in the same process as the one where the queries execute on.

I mean, seriously! You didn’t consider just dropping all of those abstractions and getting the work done? Oh, I forgot, there isn’t any work to be done, the application isn’t actually doing anything, all the abstractions are the point.

We recently added a very small feature to our build server, generating tags on the repository for every successful build. This has the surprising effect of giving us a really nice way of looking into something that I always wanted, the rate of change across pushes to production.

The way we work in Hibernating Rhinos, every single push to the remote repository is a viable product, and it becomes a a publicly available build. The problem is that in git there isn’t really a way to track pushes, so it was quite hard to figure out after the fact the scope of change of each build without looking at the individual commits.

With the new tags, we have a much easier time. I mean, just take a look:

You can see pretty rapid velocity here, with new goodies that come abroad.

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

Take a look at the following:

I was curious about that, I didn’t really understand what is going on here, so I tracked it down a bit…

Skipping over the part where there is a cast of null, this seems to indicate that this is a call to modify the entity to simulate concurrency, digging deeper:

Seems like I was right, it is intended to force the save of this item to the database. That seemed very strange, so I checked upward, where this is used, and I found:

So, ChangeBankAccount is just another way of saying Save(), it seems, in a very round about way.

Actually, starting with the model is usually a bad idea, it ties you to a particular representation of the application, usually as codified in the database schema / UML diagrams. Instead, I rather like to talk about responsibilities.

In the case of Macto, we need to figure out what the system is actually doing. It is an incarceration system, and it seems pretty clear that the root of everything in a prison is in the Inmate, right?

Not so fast!

As a matter of fact, the prison care very much about the Inmate, but Macto? Not so much. That is because we need to make a distinction between what happens in the Real World and what actions are required by our system. In the case of Macto, we are actually managing the Inmate’s Dossier. I thought about calling this a File, but I thought it would be a confusing term, considering how often we use this term technically.

Why is the Dossier so interesting? Because from a IT system perspective, it is the only thing that actually happens in a prison that can be captured inside a computer. For example, does it make sense to make a system for managing garbage removal from the cells?

Sure, if we could RFID all of the inmates, that would give us great IT experience (and save a lot of time and effort), but I am going to assume a prison where this isn’t possible, where most of the actual interactions with the inmates is actually happening by real live people. That means that what we actually care about for Macto is a fairly narrow aspect of what it means to manage a prison, the Inmate’s Dossier.

And after talking so long about why we care only about it, lets talk about what it is. The Inmate’s Dossier is the folder in the registration desk where all of the relevant information about a particular inmate is kept. Here is how it looks like:

What is stored inside that dossier? Well, all the really important aspects of being an Inmate. First and foremost, we have the chain of lawful authority for incarceration. What is that?

Let us take a very simple case, of a guy caught vandalizing a car. The chain of lawful authority for incarceration would be something like:

1. 27 June 2011 20:52 – Arrest by Sargent Azulay for car vandalizing.
2. 28 June 2011 14:52 – Detention, 8 days by Judge Judy
3. 5   July 2011 – Remanded in Custody by Judge Thachil Oti
4. 14 Aug 2011 – Sentenced, 3 months by Judge Koev Li
5. 27 Sep 2011 – Released at end of sentence

What does all of this mean? Well, a lot, actually. At #1, we had a guy that was arrested by the police, we then have 24 hours to bring him in front of a judge, to make a determination about the case (a small matter of Habeas Corpus). At #2, the judge gave us 8 days to complete the investigation while the guy is still incarcerated. At #3, we showed up in front of a judge and convinced him that we have a strong enough case to keep the guy in jail until sentencing. At #4, we got the final sentence, but calculating it takes some thinking, it is a sentence from the time of the incarceration, which means that the guy spent a total of 3 months in jail, not 3 months from sentencing.

The chain of lawful authority for incarceration is incredibly important, because without it, you are Unlawfully Incarcerating and that is a Bad Thing.

Please note that I am drawing off the experience of prisons that I was at, mostly high security military prisons for terrorists. In a civilian prison, you have to worry about additional things, like work release programs, rehabilitation efforts, etc. I am not going to touch those issues in Macto, though.

What other things are going to go into the Dossier, the ability to answer quo warranto inquiries is probably the most important one, but there are other things going on there as well. For example, we track where is the Inmate located (not a trivial matter, actually). We need to track Reports on the Inmate (aggressive, suicidal, etc).

There are probably more than that, but I think that this is enough for now. You may have noticed that so far, I haven’t shown you any UML nor have I started with the database schema. To be perfectly frank, it is not relevant at this stage at all. On the next post, I’ll start talking about the basics of CRUD operations.

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

Reading up on the data access implementation is always fun, mostly because of all the contortions that people go through. In this case, you can see the attempt to abstract away data access:

Of course, we expose Entity Framework types in our abstraction, but that is good, we will just have to implement EF on top of NHibernate if we ever want to switch, it is not like we are exposing a concrete class, it is an interface, we can replace it.

Let us also look at how this is used, shall we?

You know what, I am not even going to critique this, I am actually getting tired by reading this code, I have developed a bit of a tick, and it is getting hard to see wh…

My article in ACM Queue just got published, it discusses implementing Linq providers for NoSQL databases.

You can read all about it here: http://queue.acm.org/detail.cfm?id=2001564