John Lam, the guy writing IronRuby, cannot look at the Ruby source code. That is the way Microsoft works. This is setting yourself up for failure, hard.

The main issue that I have with this is that this is purposefully putting blinders on, and then acting surprised because the direction that the project went is rejected by the community.

The Entity Framework debacle is a good example. How the hell can you miss what is going in the OR/M world for the last 5 years? How the hell can you get to the point where you are surprised by the need for persistence ignorance?

Well, the answer for that is simple. You don't look at what is happening outside. This is irresponsible behavior at best, and the reason of a lot of the angst with Microsoft.

Oh, and another thing, if you are actually going to do something in a certain field. Don't go and ask people that have never been in this field. It is highly recommended to ask people who are actually doing stuff in that field, so you can get experience. That way, you don't have to repeat all the same mistakes.

MS MVC is actively doing the reverse, but that is only one project, but I hope that this approach will spread to other teams as well.

So far, the only Microsoft employees that I have met and didn't like were the marketing drones. I dislike being lied to, by I digress.

All the Microsoft employees (that were even remotedly techincal) that I have met or spoke with so far were really nice guys, open to suggestions and to conversation. Microsoft, the company, however, seems to behave in a rather different manner.

At some point in the chain, there is a huge management problem, because I want a Microsoft that behaves the way most of its employees are behaving. I really want Microsoft to be as open and honest and smart as most of the employees that I have met.

I spoke with some Microsoft employees at DevTeach, and I am sorry to say that they got a lot of heat because of that.

I am not saying anything new here, I have read it elsewhere, many times. But some action must be taken, because I, personally, am sick of this duality. I don't like being angry at really nice people because they work at Microsoft.

Either change that, or let us know who the real culprits are, because I really want to shout at them.

And to foretell the expected response, no, I am not saying or suggesting that you should reject Microsoft. This post is a suggestion to Microsoft. Microsoft should start to say no.

Let me give you the scenario that we are talking about, and I hope that it will make it clearer:

A customer tells microsoft: "We really want to use this new approaches that we have been seeing talked about, like inversion of control and dependency injection. Can you provide that for us?"

Now, up to this point, what Microsoft has been doing is to release a copy of some OSS project. It usually has greater complexity and lower quality than the equivalent OSS project that it is trying to copy (more on that in another post).

The reasoning for that is always: "Our customers asks us for this since they want a Microsoft XYZ"

You know what? There is another path. That path is saying, "You know what, there are already some good implementations of that in the OSS world. We are not intereted in trying to duplicate that."

I came, I rejuvenated, I went away happy.

I won't get into the specifics, but both DevTeach conferences were the highlight of the year for me. Just interacting with all the people that came there was a pure pleasure.

I am talking about far more than just the speakers, the people that came to Dev Teach were a lot of fun to talk to.

Just a few more memorable moments:

Avish, I think that you are the only person that I know who would think that the expectation management in Rhino Mocks is the complex part, instead of the runtime emittion of classes.

"It is not complex, just arcane" was simply hilarious!

Greg, I am still waiting for the full quotes list.

Shane, just to reiterate, there might be sever bodily harm if you think that I am better than you again.

Can't continue, run out of battery, and late for the flight.

Let us take a simple example, scheduling tasks, and see how we can demonstrate the difference between the two. From the perspective of the client, what do we want from a scheduling tasks?

• Define named tasks
• Define what happens when the task is executed
• Define when a task should execute
• Define conditions to execute the task
• Define recurrence pattern

Now, let us look at the fluent interface for this:

new FluentTask("warn if website is not alive")
	.Every( TimeSpan.FromMinutes(3) )
	.StartingFrom( DateTime.Now )
	.When(delegate
	{
		return WebSite("http://example.org").IsAlive == false;
	})
	.Execute(delegate
	{
		Notify(“admin@example.org”, “server down!”);
	});

And contrast that with the DSL sample:

task "warn if website is not alive":
	every 3.Minutes
	starting now
	when WebSite("http://example.org").IsAlive is false
	then:
		notify "admin@example.org", "server down!"

The second version has far less line noise, it a lot more clearer, and allows me to grow my DSL as I get more information, without hitting the language limits.

It also brings to mind another issue, who define these tasks and when?

Most of the time, I use a DSL as a way to setup and configure a runtime engine. I might talk later about imperative vs. declarative DSL. I tend to write my DSL at a different time than the code.

In fact, if you have no need to ever do something externally, and a fluent interface manages to express the ideas that you have clearly enough, than you probably should just use that.

If you need to do things externally, than a DSL is the place to look for. In fact, if you feel the urge to put XML into place, as anything except strict data storage mechanism, that is a place to go with a DSL.

For a long time, I have used the idea of IRepository<T> as my main data access method.

It is a very good approach, and I have used a static gateway to be able to resolve that effectively. The code to use that read like this:

Repository<Account>.Save(account);

But, I have an issue with that, because this is an opque dependency. I don't have a way to look at the declaration and just get what this needs. It makes testing a lot harder than it should be, because you now need to do indirect dependency injection.

There is the additional problem of the actual IRepository<T> interface:

That is an interface with 40 methods. And most of those methods are dealing directly with the data access code.

When I first to move away from this approach, I started to inject the IRepository<Account> into my services, which worked well. The code looked like this:

public class AccountService
{
	public AccountService(IRepository<Account> accountsRepository)
	{
		//...
	}
}

The problem with that is readability, take a look at the usage:

accountsRepository.FindAll(
     Where.Account.LastActivity < DateTime.Now.AddDays(-60)
);

Can you tell me what the meaning of this is? It express what it is doing really well, I think, but not what the meaning of it.

So, I started with the idea that I have domain repositories and infrastructure repositories. So I introduced this interface:

And then I can call:

accountsRepository.FindAllInvactiveAccounts()

I didn't really like that, because infrastracture repository doesn't really sit well with me. There is another issue, which is the implementation of IAccountsRepository implementation:

I have the IAccountRepository depending on IRepository<Account>, but that is... a smell. Then I thought about this approach:

But that doesn't sit very well with me either.

Eventually, I got to this design:

accountsRepository.FindAll(
	new InactiveAccountQuery()
);

Where the accountsRepository is a IRepository<Account> implementation. A better syntax for that is probably this:

accountsRepository.FindAll(
	Accounts.Inactive
);

That looks much better, and where I am going to stop for now

Glenn Block has posted to the ALT.Net mailing list that the P&P team are working on a dependency injection application block.

At this point, I am not really sure what to think. ObjectBuilder was bad. I am still having to deal with fallout from that failure.

The OSS community already has several mature IoC products.

Just in case Microsoft has missed them:

1/ Castle Windsor

2/ Structure Map

3/ Spring.NET

If they want to decouple themselves from an IoC implementation, there is a way to do that already in .Net. It is called IServiceProvider, and is already supported by the IoC implementation. A default implementation can be done with 15 lines of code, if they want to provide one.

I would really like to know, why the hell do we need another duplication of OSS?

So, a lot of time, I hear Microsoft talk about asking their customers about their design and their requests.

I have a few personas that I have in mind when I think about that.

The first one is the clueless enterprisey architect, haven't touched code in five years.

The second one? The guy that aspires to be a Mort one day, the guy that he looks down at, that is the other persona.

I had a chance at DevTeach to just take an hour and start looking at a large code base. I made the claim several times in the past that no matter the quality of the developers and the quality of the code base, there is no way someone can just sit down on a code base and start working on that.

I tried to grok the code without help, and I failed. I could probably do that, but it would take several days. That was especially true since it was in Windows Forms, and that is not a field that I have done much at. Not knowing anything about the actual domain was a big issue as well.

After about 30 minutes of sitting down and going over the code with the developer, I got a whole new level of understanding about the application. How it works, how the structure is built. I look at a test and can work how this is used, etc.

I still have very little knowledge about that application works, but after 30 minutes, I am confident in my ability to both grok the code and work with it. In fact, after getting the introduction to the code base, I can say that this is probably one of the better code bases that I have seen.

One of the more interesting parts was that when I looked at each class, it was when I took a step back and looked at the interactions it gotten really interesting.

It was a pleasure to read the code.