Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,640
|
Comments: 51,261
Privacy Policy · Terms
filter by tags archive
time to read 1 min | 167 words

When creating a generic method, strongly prefer to supply an overload that is not generic, can accept the types manually, and is externally visible.

Reasoning: The generic version often looks significantly better than the non generic version, but it comes with a cost. It assumes that you know, up front, what the types are. When you are writing any type of generic code, this is almost always not the case and your generic method is useless in that scenario.

Example: myContainer.RegisterComponent<IService, ServiceImpl>(); is a good syntax to have, but the problem with that is that it cannot be used with this code:

foreach(Type type in GetComponentTypes())
{
    myContainer.RegisterComponent<type.GetInterfaces()[0], type>();
}

Since we cannot use the generic overload, we need to resort to trickery such as MakeGenericMethod and friends. This is costly at runtime, obscure and generally make life harder all around.

time to read 2 min | 337 words

There were several comments for my recent post about the disadvantages of creating a single assembly for a project, instead of the more common multiply ones.

The main one seems to be related to dependency management. How you can be sure that the UI isn't accessing the database, and other fun violations of layering.

I have to say that I don't really have much issue with that. I want good layering, but I find that code style in a project tend to keep consistent over a long period of time in any reasonable time. As such, once you have sufficient size, it will more or less manage itself.

That isn't going to be an acceptable answer for a lot of the people that want to have more control over that, I know. There are two answers to that, the first is from the human perspective, the second is from enforcement perspective. Let us deal with the first one first.

Make it easy to do the right thing. I seem to be saying that a lot lately, but this is a core concept that all developers needs to assimilate.

If loading a user from the database is as simple as:

usersRepository.Load(userID);

Then you can be certain that no one will try to write this:

using(SqlConnection connection = new SqlConnection("Data Source=LocalHost;Initial Catalog=MyAppDB;"))

{

    connection.Open();
    SqlCommand cmd = connection.CreateCommand();
    cmd.CmmandText = "SELECT * FROM Users WHERE Id = " +userId;

}

Yes, it is that simple. And yes, this assume non malicious people in the team. If you have those, termination is recommended. It is your choice whatever it would be of them or their employment.

Enforcement is easy as well. Get NDepends and setup the appropriate CQL queries. Something like: error if class in "MyApp.UI" references "MyApp.Infrastructure".

time to read 2 min | 250 words

Back to technical content :-)

This post from Kyle Baley got me thinking about my last few projects. In them, I trended toward the assembly per logical layer of the app. So I had things like:

  • MyApp.Model
  • MyApp.Web
  • MyApp.Services
  • MyApp.Infrastructure
  • MyApp.Tests

It worked, but at one point I found myself managing 18 projects solutions, and that was only because I was committed to reducing the number (otherwise it would have been much higher). I hear about people talking about 30 - 60 projects in a single solution, and there are people with more. Considering the cost of just managing that (not to mention the cost for compilation per project), that sounds like a very bad approach.

Right now, I think that on the next project I'll have the following structure:

  • MyApp
    • /Model
    • /Web
    • /Services
    • /Infrastructure
  • MyApp.Tests

Everything that the application does will be in a single project, without the need to split it off to a lot of separate projects. I found that the vaunted isolation that we seem to seek is achievable easily without forcing artificial barriers between the different parts of the application. It also means shorter compilation times and easier deployment mode.

More than everything else, it means that I have less noise to deal with.

I would extend that to an assembly per physical location, so assuming that I had a smart client application, I would use the following scheme:

  • MyApp.Server
  • MyApp.Interfaces
  • MyApp.Client
  • MyApp.Tests

And that would be it.

Thoughts?

time to read 4 min | 726 words

image
                         (Image from Boing Boing)

I don't generally comment on such things, but in my recent trip to London, I had to go past the Heathrow Airport, and I found the security measures there... excessive. Especially in light of several other... observations that I made while in London. Those observations match across several countries (Canada, UK, Denmark, and I am pretty sure that it will match what I will find in USA). This is not an attack on the UK, this post was merely sparked by my recent trip there.

You could say that I have a professional interest in terror and terrorists. And I spent some time trying to understand them. Living in Israel, a country with a long and bloody history of dealing with terrorism, certainly help bring the lesson home, even if I haven't had personal experiences with it.

Israel's security forces, by and large, have long institutional memory with regard to how to handle potential threats, and I did my share of that a few times. As such, I have to say that while the security on Heathrow was excellent after you passed it, there seem to be zero security whatsoever until that point.

A casual survey of the way that I would attempt to make any sabotage attempt suggested several routes that seems very opened for attack.

Now, to be clear, I despise terrorism to the depth of my soul, and I have little but contempt for the actions of people who believe that random killings and the attacks on civilians are a viable method of operation.

I can think of at least three non violent ways to cause problems that are going to bring as much news coverage, cause no loss of life or damage to property and are even likely to be legal.

Oh, and they would be aggravating as hell itself.

That disclaimer aside, assuming that you can get a bomb (and you can find enough instructions in Google, even if you can't get a basic chemistry book), there is a lot of damage that can be done easily enough.

Just take the train. I got into the train by walking into the station with a large suitcase. At no point did I even see security, much less had them inspect what I was doing. I left the suitcase at one end of the train car and found an empty seat in almost the other end of the car.

During the one hour ride, it appears that no one has noticed that there was an unattended suitcase that was just sitting there for a long period.

Compare that to the experience that I expect to have in Israel. In nearly all public buildings (from the Mall to the Library), you have a guard that will ask to open your bags, and I can't imagine an unattended bag sitting anywhere with people for a long period of time. People here notice that (and trains, bus stations and even on the buses themselves there are security guys that will generally catch this type of thing).

Just to give you an example, here is what happens if you leave your laptop unattended in Israel. They shot it dead.

Israel has very good reasons for this type of behavior. I went for a pub with a friend from the states not long ago, and we sat down in a place on the shores of Tel Aviv, and talked a bit. The discussion moved to terror at some point, and I began to list bombings in the area. That very pub we were sitting on, a club not 500 meters away, a bus on the next street, etc. And that was what I could recall off hand and at a moment's notice.

I do not expect it to be the same elsewhere, but I was disturb by the difference between level of security for getting on a plane vs. everything else.

This post is getting long, morose and I have another flight to catch soon. It is also a subject that I tend not to talk about much, at least not on the blog, so I'll wrap it up now. But that dissonance is annoying as hell, disturbing at many levels and irritating just about all my professional senses.

time to read 2 min | 206 words

Well, apparently is is customary for bloggers that do not have anything to post to put some pictures of their cat. I don't have a cat, but I have a this shy little dog that I adore, her name is Rose.

image

Of course, that doesn't really give you any sense of scale, so here is her standing up, I am a big guy, her nose topped six feet by a fair margin. (about 1.85 for the civilized among us).

image

And, of course, the other side, here is her after I let her know that I am going away for a few weeks. I hope the bruises will heal soon, but for now, I need to move a bit carefully.

image

And no, it is not going to become a theme in this blog. But I found myself explaining to people on the phone all too often why they suddenly hear cries of "No, you are not supposed to eat cats!" and "Damn it already, I am not edible, get that through your head" or just "Argh!".

I hope this clarify things a bit.

time to read 4 min | 686 words

Phil Haack is talking about why the MS MVC team changed IHttpContext to HttpContextBase. I follow the argument, but at some point, I just lost it. This, in particular, had me scratching my head in confusion:

Adding this method doesn’t break older clients. Newer clients who might need to call this method can recompile and now call this new method if they wish. This is where we get the versioning benefits.

How on earth does adding a new method to an interface would break an existing client? How on earth does adding a new method to an interface require a compilation from client code. Now, to be clear, when I am talking about changing the interface I am talking solely about adding new methods (or overloads), not about changing a method signature or removing a method. Those are hard breaking changes no matter what approach you take. By adding a method to an interface? That is mostly harmless.

The only thing that require that is if you are implementing this interface, not if you are using it. It is possible that Phil is using the term clients in a far wider meaning than I would put on this, but this is not the general use of the term as I see it.

Prefer abstract classes to interfaces, use internals and no virtual by defaults are three of the main issues that I have with the framework design guidelines. I have major issues with them because they are actively harming the users of the framework. Sure, it might make my work as a framework developer harder, but guess what, that is my job as a framework developer, to give the best experience that I can to my users. [Framework Design Guidelines rant over]

Now, I do believe that I have some little experience in shipping large frameworks and versioning them through multiply releases and through a long period of time. I also believe that some of those frameworks are significantly larger and more complex than what the MS MVC is going to be. (Hint, if MS MVC even seems, by an illiterate drunken sailor on a rainy day, to approach NHibernate's complexity, it is time to hit the drawing board again).

And those frameworks are using frameworks to do pretty much everything. And I cannot recall off hand any breaking change that resulted from that. In some cases, where the interface is an extension point into the framework, we have gone with interface + base class with default functionality. If you use the base class, you are guaranteed no breaking change. The reasoning for an interface is that it is giving the user more choice, you aren't limiting the options that the user have when it comes to use this (by taking out the single inheritance slot, for example).

Now, if we analyze the expected usage of IHttpContext for a moment, who is going to be affected by changing this interface? Only implementers. Who is going to implement IHttpHandler? I can think of only two scenarios. Hand rolled test fakes and extending the Http Context in some interesting ways, perhaps by adding proxies or decorators to it.

In the first case, that is no something that I would worry about. The second is far rarer but also the much more interesting case, but those are generally not done by hand (I wouldn't want to type all the methods of IHttpContext, that is for sure). Even if it was, I still have no issue with it. New framework version, add a method. It is not a significant change. A significant change would require me to rework large swathes of my application.

Now, why do I care for that?

The reason is very simple. It is a pain to me, personally, when I end up running into those warts. It is annoying, frustrating and aggravating. I like to be happy, because otherwise I am not happy, so I try to minimize my exposure to the afore mentioned warts. Hopefully, I can make them go away entirely. And not just by pulling the blanket over my head.

time to read 1 min | 91 words

Note, this is a copy of the discussion that is taking place in the Rhino Mocks mailing list.

Now that I pushed all the current changes out, we need to start thinking about the next version. I am planning on seeing what kind of syntax I can get from the language using C# 3.0. As of yet, I don't have any concrete ideas about what should be done, so I am here to solicit ideas about what you want.

Syntax suggestions, patches, comments, etc are all welcome.

time to read 2 min | 371 words

Well, it is about that time again, I got enough changes to make a release worthwhile. It has been almost five months, and we got a whole bunch of stuff going on, including a lot of stuff from contributors. (Take that, one man project :-) ).

As usual, you can get it here and the source is available here.

It is interesting to note that a lot of people have stuck with Rhino Mocks 3.1, I guess that there is really no need to upgrade, if you get what you want...

Features, more features, glorious features!

  • Added CreateMockWithRemoting and DynamicMockWithRemoting to work around BCL bug when overriding a generic method with generic constraint.
    This is useful when you want to force Rhino Mocks to use Remoting proxies (usually it just guess and you don't deal with this). That is needed because at certain cases ( generic methods with generic constraints ) there is a bug in Reflection Emit that generate invalid code.
  • Mike Nichols  has added List.ContainsAll() constraint
  • Shawn Neal added the DoNotExpect syntax, which is clearer the Expect.Call().Repeat.Never(), it is certainly shorter.
  • Added trace writer with stack trace, should make it easier to track down strange mocking behavior. Now you can just enable logging and see all the method calls that are being made.
  • Guido van Loon supplied the Property.AllPropertiesMatch constraints
  • Making sure that recorders that wrap recorders will be merged if they contain only one element. Again, this is something that you are not supposed to understand unless you went deep into the code. Suffice to say that the behavior is easier to understand now.

Bugs, annoying bugs, stupid bugs!

  • Fixing issue with empty recorders nested in recorders that has expectations. If you don't get that, then rest assure, neither do I.
  • Demid Sukhovsky  fixed Rhino Mocks support for Out/Ref values using remoting proxies.
  • Fixing null reference exception when stubbing a class with protected setter.
  • Aaron Jensen fixed the validation message when you expect a method that accept a mock object as a parameter.
  • Aaron Jensen also fixed a bunch of my typos.
  • Steven Rockarts fixed a bunch more of my typos.
  • Fixed an issue with methods returning non primitive value types, such as UInt32
time to read 1 min | 110 words

image Well, this is a big moment. My book is now available for as part of the Manning Early Access Program.

Chapter 1 to 4 are already there, but they are there in their nearly raw format. That means that they have not been edited yet, and I didn't put in the results from the review cycle that we did yet.

The book forum is here, I eagerly awaits the posts telling me how off base I am :-)

More seriously, I would appreciate any feedback that you have on the book, the topic, the code, etc.

Thanks,

  ~Ayende

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. API Design (10):
    29 Jan 2026 - Don't try to guess
  2. Recording (20):
    05 Dec 2025 - Build AI that understands your business
  3. Webinar (8):
    16 Sep 2025 - Building AI Agents in RavenDB
  4. RavenDB 7.1 (7):
    11 Jul 2025 - The Gen AI release
  5. Production postmorterm (2):
    11 Jun 2025 - The rookie server's untimely promotion
View all series

Syndication

Main feed ... ...
Comments feed   ... ...