Jeremy Miller, me and Udi Dahan had a discussion about the echo chamber effect. Basically, we tend to talk to a lot of people who either agree with us, or in complete disagreement. Either way, the people we tend to talk to are those who are involved.

I was at a client two weeks ago (trying to tell them that a single remote debug server for 20 developers is not practical) and I saw people still doing active development in ASP classic. I went to lunch with them and tried some conversation avenues, but they were all met with glazed stares. This people are building something really big, which tens of thousands of people are using daily, and they literally had no idea about what Web Services were. (That was when I stopped to last year's buzzwards, in order to find if they know that.)

That is somewhat depressing, because there is no way that anything that we do here would be able to reach those types of guys.

I had a few discussions recently with Roy Osherove, about learning WPF. Roy is a fun of Petzold book about it, mainly because it goes through all the API and explain their usage in depth. I haven't read that book, but I am currently going through Adam Nathan's book about WPF, and I am enjoying it very much.

From Roy's perspective, Adam's book is too high level, not giving all the details that Roy feels he should know in order to be a great WPF developer. I don't agree with that approach, personally. I like Adam's book because it talks about the concepts, and it has just enough low level details so I can grasp the how without getting lost in the details.

I am certain that there are certain depths and pitalls that Adam's book doesn't cover, and Petzlod's book does, but I don't learn that way. I want a book to learn the high level stuff, the model, and then I can start working with the technology. Frankly, I can figure out stuff much easier on Reflector than from a book, and that is the kind of learning that sticks.

Then again, I am the guy that learned the Page LifeCycle model by going through System.Web.UI.Page.ProcessRequestMain on reflector, cursing all the way.

Roy's approach is more structured, I think, but my way allows me to just grasp how things works, and then I can do the rest on the job. It works for building applications that uses this stuff, but probably not if you want to go deeper into this.

Given a choice between a developer who can explain what MVC is vs. a developer that knows .Net 3.0, I would always choice the first developer. I just had finished talking about this with Jeremy Miller and Udi Dahan about the most important things that you need to have in your developers. The converstion started from talking about making design "compromises" for non-advance developers. And moved to the reasoning behind this approach.

Basically, there are a lot of developers that chase that technological rainbow, investing all their time in technology, and not on understanding. This is a great treatise about the subject:

Frankly, it is a much better investment to understand the design of software than the mechanics of it. It makes it much easier to pick up the mechanics at a later date.

Companies that don't understand that is doing themselves a dis-service, because they are basically hiring a programmer whose only interest is to use current technologies, not the business problem or the best way to solve that. Technical solution isn't the only way, or even the recommended one.

I can't believe how fun this is.

I have arrived yesterday, and took a walk in Montreal, this is a really pretty city. The architecture is vastly different from what we have back home, and I can't figure out the walk/don't walk lights in the roads, but other than that, it is very similar.

I made a mistake and entered a book store (Indigo), I gravitated to the Fantasy section, and I spent literally two hours there, just browsing books. I am not used to rows over rows over rows of interesting books. At one point I started to just skim them, there were so much of them.

I got to meet a lot of people that I have only met electronically so far. We are having some really interesting discussions, and the sessions (I am sticking to the agile track) are facinating. I also discovered that I am very bad in remembering people's names. I will remember conversations but rarely names.

The best part is that just about everyone that I meet here understand what I speak, which means that I conversations are very high level, and a lot o fun.

I am doing two sessons tomorrow, about Rhino Mocks and about MonoRail. And now it is nearly the end of the day, so I am heading to the speakers' dinner.

Oh, and Roy really should put some CD* of all his songs.

* By CD, I mean a collection of MP3, of course :-)

So, a few more things about the Entity Framework that came up today:

• One thing that worries me more than a little bit is that the Entity Framework has this three layers model, but all the focus is currently focused on 1:~1 (1:1 or nearly so) approach. This means that the interesting aspect of the Entity Framework, radically different models, is the least visited code path.
  At best, this mean that it wouldn't be supported by the designer, at worst, it wouldn't be supported at all. In either case, pain is waiting for the implementors.
• The Entity Framework doesn't support lazy loading, this means that your code is going to have stuff like: "customer.Orders.Load()" scattered throughout it. Microsoft is saying that they are doing this in purpose, in order to make it explicit when you are going to the database.
  Frankly, I consider this as a cop out for the lazy loading problem. Now Microsoft can blame the developers for this problem. This is something that should be solved by the framework, not shifting the blame elsewhere.
• This bring me to another issue, the Entity Framework's eager loading facility is a cartesean product nightmare. Trying to load a deep object grap will return a very wide result. NHibernate, on the other hand, has MultiQuery/MultiCriteria, which can be used to load a deep object graph with a single roundtrip, but with multiple result sets, drastically reducing the amount of data that goes on the wire.

I was talking to Scott Bellware during a presentation about the entity framework, and I think that I have a new idea about what the Entity Framework is trying to do.

From the vision statement, it looks like Microsoft is trying to build a data management system, including all the relevant tools, that is beyond RDBMS. The mention of reporting, replication, querying, etc against the entity model is what is mentioned as the key differenciator from OR/M such as NHibernate.

In the DotNetRocks episode talking about Entity Framework, Daniel has mentioned that they are thinking about relaxing RDBMS constraints (but keeping the model's ones). This, to me, signify departure from the RDBMS land, and when you are talking about non-RDBMS data management, there aren't many options out there.

Considering the entity framework in this light, it starts to make a lot more sense. It is not an attempt to make an OR/M, it is an attempt to build an OODB system, without calling it that (probably because of the bad rep).

This is a much more ambitious endavour, and probably Microsoft is one of the few that can do it, but I still think that they are trying to ambrace too much.

I was at an Entity Framework talk, and at one point they guys from Microsoft were criticized for bringing the industry back because:

I laughed so hard about that...

After years of telling their customers that Stored Procedures were the only way, it was beyond funny to hear them being criticized on not support the old (bad) way. I also like the way that they tried to avoid saying that this is a wrong idea.

I am currently building a project that needs a permissions framework. The overall idea is that you have a user, an object and a set of permissions, and I need to verify whatever a user has or hasn't the specified permission on the object.

Problems:

• Permissions may be granted to a group, and a group may aggregate other groups.
• Aggregates always has their own set of permissions, but some permissions are inherited to child objects, some do not.
• Permission may be granted on a group of (unrelated) objects.
• Need for deny permission.
• It has to perform well for large amount of permission queries (I want to call it over set of objects returned from a query).

I considered AzMan, and it would be great, but as far as I know, it handles only roles, not permissions on objects, and while I could handle this using some sort of a naming convention, I would rather avoid it. Creating objects in Active Directory and using Windows Permissons on that is also not a good idea, most probably.

Any suggestions?

I had a chat with a pal that works in a company that is slowly (and relucently) moving to .Net. They are moving slowly because they have existing Main-Frame based infrastructure, and they can't figure out why it takes longer to develop an Ajax-Based ASP.Net application over the usual green screen terminals. We spent a lunch discussing the difference between the two styles of development. One is for a static environment, where each of the developers has 15+ years not only as a programmer, but in the business.

Once and for all, am I a bug magnet? All I did was try to find out some information about the flight. I wasn't even trying. And no changing of locales seemed to have help.

Conclusion, WebLogic is lame, the ASP.Net error page is much prettier. :-)