Zabasho - (Hebrew: זבש"ו) - can be literally translated to "It is his problem", but is usually meant to also express complete disinterest in the result of an action done by someone else.

Example: "If he will send that email, he is getting fired, I told him that. Zabasho."

Ayende's Example: "The user wants all the screen aqua on pink, he will go blind. Zabasho."

StoryVerse is an agile management web application, based on MonoRail & Active Record. The UI is very googlish in nature, and I really like it. Still very early in the project, but showing a lot of promise.

The way that the guys from LunaVerse are using the criteria objects had me scratching my head for a while, until I saw how it is used on the controller, then I had a "Wow! That is cool!" momemt.

Here is a sample:

You really need to check out the code in order to appriciate it. It is like placing a lot of domino pieces and watching them all fall into places, no extra work required. Here is one technique that I am so going to take advantage of next time I am going to write a search screen.

Just to reference a great article about using NHibernate & WCF, worth checking out.

Quite a few parts of NHibernate are serializable. ISession and ICriteria are of particular interest to this post. Serializing the session (neccesiate that the entities are serializable, of course) is very useful for the Session-pre-conversation mode. But it is the criteria that I would like to talk about right now.

Criteria in NHibernate is the OO interface for making queries. So, why is it important that it is serializable? Well, it opens up some interesting scenarios. Saved searches or reports are just one of many. I have used similar functionality in the past to build a rule engine, where saved criteria where the basis of selecting what a rule should process.

The only problem with that is that you usually want to display the query to the user. I have recently added inspection capabilities to the criteria, but they are focused more on infrastructure stuff rather than ease of extraction for the UI. For those cases, you might want to add a way or the UI to restore itself to the appropriate state for the selected search.

Okay, here it is. This is a little diferent style than the one I have made before. This isn't scripted at all. This is literally a recording of me trying to solve the Event Broker issue. As I have mentioned, I have spiked the issued previously, but not in any serious manner.

As a result, you can see me stumbling over issues in the implementation, and it is much less professional sounding. It turns out to be less than one hour recorded (+ 5 minutes spent checking the Rhino Mocks source code "off stage"), and I think that I have a good solution for the Event Broker issue.

I am afraid that at times I have been reduce to unintelligable muttering at time, but I hope that it is still valuable.

Stuff that is covered in the screen cast:

• Event Broker
• Declerative Event Wiring
• Registering to events from classes we don't own
• Avoiding memory leaks

The code starts at 2:30 minutes, and it is pretty much just code (and my mumbling) from then on.

As usual, the code is supplied, and the download page is here.

I think you can pretty much understand how I feel about this feature.

Think about it, a compile time only method declaration, that you can "override" in another method, like this:

The crazy part is that the code below is not compiled unless you supply an implementation to the method, and the implementation is not neccesary.

The reasoning behind that is to have light-weight events, that exists only when you "subscribe" to them. The reason for that is the Linq code generation features, which produce a lot of events.

So, this is basically compiler macros again, for a dubious reason at best. I don't think that the language should change because of a tool that it using it. If they want to make any useful changes, there are more than enough suggestions. Method Missing would be welcomed, as well as attributes that can accept useful parameters (i.e, not just String, Int32, Type).

Yuck!

Yes, this is another response to Sam's post, and this time is has nothing to do with the CAB or P&P. This is about a few things in Sam's post that really bothered me:

• Let's leave out the fact that three of my best friends in the world designed and implemented CAB. That's just the personal stuff. My problem is simply that many of the assumptions and things they wrote are patently false. They don't know these people, they don't know CAB at all.
• But what I object most is how they are targeting the wrong team in Microsoft! The P&P teams are one of the ONLY if not the ONLY team(s) in Microsoft that do Agile XP.
• Here's a group trying to spread the good news of Design Patterns/Fowler, TDD, Agile and Iterations, etc and you have to stick it to them?

So, let me rephrase that.

If:

They are your friends and they are doing agile, TDD, XP, etc.

Then:

I must not criticise what they are doing, even if I think that they are doing something wrong.

I am all for Agile and TDD, and I love to see people using them, but I don't think that this makes them automatically successful, or that they will choose the best approach. And I am certainly not going to let the fact that someone is doing Agile or Open Source, or something else that I also believe in, to stop me from telling them that they are wrong.

I think that the P&P team is going in the wrong direction, I can see why but that is not relevant to the discussion, that they are agile (or Sam's friends) is not an issue, I still think they are wrong.

Probably because he has a point. He took issue with my statement about the CAB, being too complex for the job it is supposed to do. Perhaps the thing that I regert the most is that I don't have truly constructive criticism to offer in this subject. I can understand why "I don't think that this is good" can be seen as offensive.

Before I respond to Sam's post, I would like to mention that I do believe that we can have a reasonable discussion without attacking each other, even if I decide to offer criticism. I would admit that not offering a constructive criticism is a problem in this case, but I don't have anything valuable to suggest about improving the product at this time.

In addition to that: I don't like personal attack in response for a technological discussion, and I really wish that the discussion would not stoop to that.

Now, to the part where I try to answer Sam's points. This is addressed specifically to Sam.

I am sadden to hear that. I have some snippy remarks to this, but I would try to refrain from that. I would like to mention two things. I do believe that I am not talking empty words. The second is that while Israel and the US may have superficially similar cultures, there are many changes between both culture. Oh, and I am also narcissistic & opinionated jerk.

Sigh, why do people assume that I don't deliver business value to my customers? If I wanted to sit in an ivory tower and write frameworks, I could do it. I am pretty sure that I could get paid for it. I hadn't any complaint from any of my customers (or my boss) about using work-time for doing frameworks-in-the-sky.

A bare bone OR/M implementation takes about a day to write, Fowler has the basis in PoEA. If that was all an OR/M had to offer, I wouldn't really bother with an existing one. You can check here to find what are the basic requirements for an OR/M. I estimated that as three months for me + 2 good developers to get to a version that other people could start developing on. Of course, that is a fairly rough estimate, so it may take more.

I am sorry if this is the way it came out. I am using this blog as a way to express my thoughts about software and development, not as a way to put down other people. I would try to give it some thought, but I would request the same from you.

Again, it is not the patterns that I am objecting to, and I think that the CAB has some good ideas in it. I am delighted to hear that you have been successful in implementing a CAB-based solution, and that it has worked for you.

Nevertheless, "We actually don't find CAB that hard anymore" - that is after over a year of working with it, right? I would say that it would have to be hard to use after that period of time. Incidently, this is not the only reference for about a year to get the CAB.

If you feel that your invensment in the CAB had been worth it, go celebrate it in a pub. I feel differently about the applicability of CAB to my projects, for the reasons that I have already specified, and I have yet to hear something that would change my mind or would actually address the question.

Ha? I fail to see the connection between the CAB and SQL Server, sorry. You would have to use hand puppets to get that throught for me.

I wanted to take some time to clear some issues regarding my previous post about the P&P. A lot of people seems to grab on to my mention of CAB (interestingly, no one tried to defend the DAAB :-) ), and the conversation has turned that way. Just to remind you, here is what I said:

The only other thing that people seem to have noticed is the part about developing in vacum, but I will touch that separatedly. Since so much of the discussion has centered about the CAB, I am going to discussed it specifically. I would like to mention first that I have not built a real-world CAB based solution. I have listened to a few presentations on it and pursued the quick samples and the code itself, however. By no means am I a CAB expert, but I believe that I am able to evaluate the CAB and its ability to meet my needs based on that.

A lot of the discussion has been about the technical merits of the CAB, and whatever it is useful to use that or not. I have a few issues with the CAB from a technical point of view, but nothing truely major. I even said so explicitly in my previous post. I am not talking about the quality of the code, or whatever it uses the right patterns, or allows you to write testable code.

I am talking about the whole approach that the CAB has taken. This approach is too heavy weight in my opinion. My approach to big, complex WinForms UI application would basically consist of hierarchical MVC, probably with an Event Bus and a common base class for the Forms. If hierarchical MVC sounds familiar to you, that is very similar to the idea of work items. The CAB approach is to re-structure the entire application around the CAB.

It may be a personal preference thing, but I don't like it when I need to do something in a completely different way because of a tool that I am using.

About the complexity of the CAB approach, just a few quotes (hopefull not out of context):

• From Sam Gentile: "...I was going to show how to tame this CAB beast..."
• From David Hayden: "I have never had the pleasure of working with the Composite Application Block ( CAB ) or Smart Client Software Factory ( SCSF )"
• From Bil Simser: "I've spent the better part of a year learning CAB, EntLib, ObjectBuilder, WorkItems, and all that jargon..."

Complexity is not a good thing, especially when it is exposed to the user.

Developing in vacum:

This is another thing that some people took offence at is that I said that the P&P develop stuff in vacum. Sam Gentile don't think that this is the case:

That may have started out the proper way, but "working with dozens of customers" it not what I mean about developing in vacum. Perhaps a better word would be dog-fooded. As in, you build stuff that you will use. So you see all the pain points, and you find out what is needed in order to smooth the wrinkles. I said it explicitly in my post, I want stuff that people are incentivized to make great for the oldest reason there is, because it makes their life easier.

Now, please correct me if I am wrong, but I do not believe that the CAB team is also a customer of the CAB. That makes it development in vacum.

As long as I am stirring the pot, here is an amazing comment by Steve ( no blog, apperantly :-( ) left at Chris Holmes post about my P&P post. In reference to: "Would it be acceptable for them [P&P] to build Enterprise Library using Castle Windsor?"

I have no further comment to make, except that I would like Steve's blog.