Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,319 | Comments: 46,927

filter by tags archive

NHibernate Query Analyzer for NHibernate 1.2 GA

time to read 1 min | 112 words

I am a bit late with this one, but here is a new version for NHibernate 1.2 GA. This also supports Castle Active Record, hopefully in a version neutral way.

You can get it here, or admire the UI here:


As an aside, I am thinking about adding Criteria Query functionality, since this is something that I use a lot. I am not sure yet what form this would take, at any rate it would involve runtime code generation, so that is complex (and sort of fun/pain).

I am opened to ideas.

Have fun...

Arrest that man! He had built workaround a technical limitaion!

time to read 1 min | 117 words

Alex* has posted a piece of code that will solve my issue with Window Live Writer and spell checking.

The problem is that this is clearly working around a technical limitation in the software, as a non English speaker, I am obviously required to use Windows Live Writer Team Edition, which will (in the next version only, mind you) support English spell checking for non-English speakers. I am expecting the Cease & Desist to come at any moment, and Alex is currently expecting an attack from the Tean Ninja Lawyers teams.

Nice hack Alex, now off to prison with you.

* Sorry to pick on you, but that was too good an example not to use.


time to read 1 min | 63 words

So I finally found the time to build the project and put it on castle contrib. The main idea is that this is the place where community contributed view components can be aggregated, including documentation and sample code.

You can get the initial stub here, it includes the Grid Component and Smart Grid Component, as well as (hopefully) thorough documentation about their usage.

Thou Shall Not Work Around Technical Limitations

time to read 1 min | 161 words

Frans Bouma has a really good overview of the implications of Microsoft behavior in the TDD case. The thing that really bothers me is that the thing that they are hinging their treats against Jaime is "work around techincal limitations".

Well, excuse me, but that is my job. What am I supposed to in cases such as this or this? Report a bug to Microsoft and wait two years so maybe they will fix it? (Or maybe they will decide that it is there for backward compatability.

This is generating so much bad will around the community, I just can't understand Microsoft's position in this matter. I am with Frans on this issue, I don't think that Jaime is in the wrong here, neither technically nor legally.

We have heard from a few Microsoft people about the issue, mostly re-iterating the same nonesense. I would like to get a response Scott Guthrie on this subject.

Effective Software Development or Policing Of Monkeys

time to read 3 min | 504 words

Jeff Atwood is talking about why background compilation is part of a culture of code monkeys and that we should accept it and get on with the program:

You could throw emacs and volumes 1-5 of The Art of Programming at your development team. Or you can buy them the best, most advanced development tools on the market. Which approach do you think will be more effective?

One of the problems with the army of monkeys approach that everyone seems to ignore is that treating someone like a monkey will get you monkey-like responses. We have a problem of escelating complexity in software, and trying to solve it by serregating the problems to the "Smart Dudes" and the "Monkeys" is not really helping. We are not writing Hello World applications any more.

I had the chance to try to port a monkey's code from one langauge to the other, and I couldn't make sense of it. You can imagine at what stage I had to throw up my hands and seek that monkey out to have it explain to me what the hell is going on in the code. It was 2 months old code, and the monkey couldn't do it. The magic numbers in the code were what the monkey was told to write, the logic constructs in the code were what the monkey was told to write. The bugs were the monkey's own fault, I assume, but it may very well be the case that the monkey was instructed to put them in as well.

Trying to get a good product out of an army of monkeys requires constant policing, lest they do something stupid. Software is such a complex beast that have a monkey anywhere in the process will put a serious risk to the project at large. Some of the stuff that I have seen:

  • Using a public static bool g_IsUserAuthenticated;
  • Subscribing each page to a global & static event handler.
  • String concentration for query building (using the safeForSQL() method, of course)
  • The single user only web applications
  • For more references, check the Daily WTF

Each of those share a single trait, this is a single stupid thing that had a drastic affect on the entire application.

In the case of the static event handler, it took about two days to see the effects properly, at which point the application crushed with OOM errors. That was fun to find out.

Armies of monkeys simply doesn't scale, a monkey can't handle complexity well, so you end up dumbing the environment to the level of the monkey, therefor, you are reducing your ability to make any sort of change and maintainability is a nightmare.

So, Jeff, I do agree with you that there is this cult of monkeys, I do not agree that we should agree to this.

Blog Design Help

time to read 1 min | 98 words

I have been using the blog skin for the last two years or so, and I really like the look & fell of the blog. There is a problem, however, with some of my posts on 1024x768. I got several complaints about it, but all the "easy" solutions that I have tried are not really working well.

So, I decided to ask your help :-)

You can get the blog skin here: http://www.ayende.com/Files/BlogSkin.zip It is a standard SubText skin, and I only want one thing, to get it to work reliabely on 1024x768.

Thanks in advance...

Developers are consenting adults, treat them as such

time to read 1 min | 88 words

I was just asked how I prevent a developer from doing something stupid. My answer was "rational explanation". I see way too much effort to protect developers from themselves. There is a very simple approach to handling rogue developers, it involve a conversation with their manager and a guided tour toward the door.

That is not to say that you shouldn't have reasonable error messages, "token error 0x443234FEA" is pretty nasty to do, but don't try to make them work without all the power that they can have.


  1. Low level Voron optimizations: Transaction lock handoff - 11 hours from now
  2. RavenDB Conference Videos: Delving into Documents with Data Subscriptions - about one day from now
  3. Low level Voron optimizations: Primitives & abstraction levels - 2 days from now
  4. RavenDB Conference Videos: Replication changes in 3.5 - 3 days from now
  5. Analyzing RavenDB 4.0 with NDepends - 6 days from now

And 6 more posts are pending...

There are posts all the way to Mar 14, 2017


  1. RavenDB Conference videos (12):
    27 Feb 2017 - Building Codealike
  2. Low level Voron optimizations (5):
    20 Feb 2017 - Recyclers do it over and over again.
  3. Implementing low level trie (4):
    26 Jan 2017 - Digging into the C++ impl
  4. Answer (9):
    20 Jan 2017 - What does this code do?
  5. Challenge (48):
    19 Jan 2017 - What does this code do?
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats