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,511
Comments: 51,108
Privacy Policy · Terms
filter by tags archive
time to read 1 min | 99 words

Check this out. Even though that Jim says that it is on the IronPython site, I can't find it, but I am still loving it. Making the CLR more friendly to dynamic languages is a Good Thing in general, but the thing that excites me is the possiblity that it can be leveraged from my code as well.

I paid my IL taxes, and while Linq expressions are nice, I would like to get solid support for runtime code generation without having to do it in the assembly level.

time to read 1 min | 68 words

I am writing a document, and I just had a hilarious typo. The subject of the document is managing development environment, the title of the document, however, was: "Managing Secudction Envrionment". First time I realized that in hebrew, development and seduction are literally one typo away.

Considerring the target audience, it is a good thing that I got that in time.

time to read 8 min | 1526 words

About a week ago I posted how to handle Multiple Cascadiong Drop Downs using MS Ajax. That worked, except sometimes it didn't work.

Took me a while to figure out that there was a race  condition there. Let me tell you, Javascript in the browser is not the language for tracking down threading issues. At any rate, here is the fix.

function changeOnParentChangeOnProductsToAvoidRaceConditions()


      var behaviors =  Sys.UI.Behavior.getBehaviors($('<%=Benefits.ClientID%>'));

      if(behaviors == null || behaviors.legth==0)


            //wait for the behavior to be defined.

            setTimeout("changeOnParentChangeOnPoliciesToAvoidRaceConditions()", 10);



      for( var i=0; i<behaviors.length;i++)


            var behavior = behaviors[i];

            //required to get around race condition

            behavior._oldBenefitsOnParentChange = behavior._onParentChange;

            behavior._onParentChange = function()


                  if( $('<%= Insurances.ClientID %>').selectedIndex == 0)




                  behavior._oldBenefitsOnParentChange ();




Event.observe(window, 'load', function() {



time to read 2 min | 290 words

This post from Sam Gentile has made me realize that I need to clarify a few things about the recent TFS vs. XYZ discussion.

This post isn't really aimed at him [that would be me] but I do find a post by him seeming to suggest that you only can use OSS tools to be "Agile" to be, well, quite disappointing

I guess that I didn't notice the conversation digress, but I really should clarify that it has never been my intention to suggest, or seem to suggest, any such thing. Tools helps, and I think that they are important. I have my own preferences, based on my experiance and the way I like to work.

I am mostly talking about OSS tools because I am familiar with them and it makes it easy to point out and show. The best project management system that I have worked with is JIRA, but Trac does quite a bit of the work, and doesn't require as complex a setup.

There is no correlation or dependency between the tools that you use and the way that you work. And you most assuredly can use TFS to be agile.

I do think that tools can be of significant help, you can certainly be agile without them, but it is easier with them. My issues with TFS has nothing to do with agility, and everything to do with seamless usage, a whole seperate issue alltogether.


time to read 10 min | 1869 words

Aha, my dear colleague. Yet you continue to use Visual Studio .NET, which, even without team system, has it's share of usability problems for you, I'm Sure. Why not use notepad or eclipse for writing the code, then running a command line to compile it, then use an XML Editor to change the config files? Why are you using a suite of integrated tools to develop code, in an environment which you probably aren't that crazy over?

Seeing the bigger picture perhaps? There is some value to it after all.

I actually do quite a bit of development using Notepad :-). I am not using Eclipse because I was never able to really grok it, I am afraid. A simple case of being lazy about it, I admit. I don't think that I ever said that there isn't a big value in an integrated environment. You won't find me running for kdbg to debug my CLR program (Ahem, yes, I was talking to that shady guy, right over there, not debugging the kernel to find ArgumentException).

I think that it is safe to say that it is public knowledge that I am not crazy in love in VS (maybe crazy because of it). There are two reasons that I use it over Notepad / #Develop / Eclipse. It has an excellent debugger, and I get ReSharper. Oh, and I am willing to degrade the debugger experiance. There is a reason why I would like a JetBrains IDE so much.

I should also point out that for a very long time, I developped in Boo, which entailed working in Notepad2, with Python syntax colors, compiling via NAnt and debugging with CLR Debug. Boo's syntax made it possible, and I worked on small enough projects that allowed me to live without R#.

And don't get me started on the "zone" thing. You develop on a windows machine, right? your "zone" gets disrupted a million times a day by tiny little operating system mishaps, dialogs, crashes and what not, yet you continue to use it and not another operating system. I guess sometimes you compromise to get what you need.

And how about working with people? People sometimes take me out of the "zone", and cellphones too. Gosh, I should just program in a cave with a rock and a wall in front of me. Oh, wait, there are advantages to doing the opposite.

While taming Windows is not a task for the faint at heart, I do believe that I have managed to do so. My system doesn't interrupt me, and if I want to do a bit of serious coding, I close outlook, phone and messenger, growls at anything that comes near, and work. That cave sound charming, I would need a whiteboard and someone to ping ideas from, though.

Did I really paint myself as a binary guy? "My way or none"?  I hope not.

About the people comment, I can get quite a bit done when I am working alone, but it is much more fun to work with other people.

Resharper has it's slow moments inside VS.NET. It sometimes makes you aware that it is working. Yet I still use it. Sum is great than thee parts etc..

There is a big difference here, actually. ReSharper almost never does anything unles I tell it to. If it takes time to refactor, or search for a reference, etc, that is okay, I just told it to do so. The problem with TFS taking me out of the zone is that it surprises me, and not in a good way.

Roy makes an excellent point when he asks who this is good for:

I'm wondering if the word "I" is to blame here. Yes, for you you get all that you want, while still paying the price of configuration, forking, patching, learning curve etc. What about "us"? Would it be just as easy for an entire team or an full dev group to do such a move? Assuming that this magical suite of OSS tools that provide exactly what you could get in TFS exists (yes, I'm sure you can make it happen, Oren), what is the cost of:

  • Learning that you can actually do something like this without having an OSS guru in the house? (Solution Discoverability)
  • Writing the documentation of how you did it and keeping it all as one big happy maintainable system?

Again,  not for you personally, but for an organization?

Let us put the forking/ patching out of the loop please. I don't do that, and it muddy the waters with irrelevant stuff. And configuration / learning curve exists for TFS as well, I would say.

Roy, I assume that when you do a TFS project, you rarely gets to go in, install it, and go home. Usually there is customization that needs to be done, to make it work the way that organization works. There is configuration, there is training an admin that can watch for it, there is documenting what you did and how / why it was done, etc. That one is not different for any stack that you choose.

For discoverability, that is another matter. Assuming that I am in the market for a new development environment, that is a big desicion, and I need to make an informed one, so I would look at what I need, and then see what set of tools would give me the best solution. It has long been heralded as the unix tradition, but collaboration of focused tools is often greater than the sum of its parts.  The integrated solution is tempting indeed. But most people have learned that integrated solutions often carry their own set of problem and would evaluate separate solutions working together as well.

Would it be easy for the entire team? Yes, I believe so. You would need to teach them what is the way that it is going to work, which you need to do anyway, and off they go. I didn't find any of the tools that I have mentioned to be of high maintaince, zero friction, again. And here I am talking not about me, I am talking about team memebers that doesn't have my experiance in working with those tools.

I am certainly not seeing any issues in my organization, and as I mentioned, my time troubleshooting those tools in the last 6 months was ~15 minutes. And they are certainly in active usage.

TFS may not be your thing, but it sure as hell saves lots of time for lots of people who learn to work with what they have and optimize it, extend it, and not go and work on something that may be the "perfect" thing for them, but less perfect for other people. If you plan on saying "just say no" you should at least know that people might find out that what they turned down actually has more value than the little things that annoy you.

I am not "just saying no", I have made multiply attempts to use TFS, in all cases, I have run into those issue which were unacceptable to me and my team. I am not saying that TFS is worthless, or that it doesn't bring value. I am saying that in the grand scheme of thing, I have found that TFS has issues that prevent me and my team from using its core functionality. And that without the SCM integration, I don't see the value in TFS over other tools.  I also think that you are underestimating how big those "little things" are.

I have seen people that works with it that accept those flaws as given. If they can manage that, fine, and I hope that they will leverage TFS to its full potential. That is not the way I feel, and from the attempts that we made, we found that after getting used to zero friction tools, tolerating friction gets very annoying, very fast.

When you aim wide, you have to aim a little lower. I think that's just the way it is.

And I disagree with this completely. You have different set of concerns when you aim wide, but that doesn't mean that you have to aim lower. That may work as long as there isn't a competitor that aims wide, but keep better quality. I think the Japanese proved that with their cars thirty years ago.

I may sound a bit harsh, but this is all in a good mood. I respect and like Oren very much, and much beer will be had together at DevTeach next month!

I am not my code, not am I my opinons, I can enjoy a good debate even if at the end I won't "convert" you to my way of thinking. Frankly, I don't even expect it. The fun is in the debate itself...

TFS: Potshots

time to read 1 min | 138 words

Jeremy Miller just commented on my previous post, and I couldn't help responding:

I've heard pro-VSTS folks slam the OSS tools for being tinker toys and difficult to integrate (not in my experience, but it's their story), but many of these same pro-VSTS folks sell consulting services to set up VSTS.  If VSTS is so easy to get up and going, why are people able to make a living doing just that?

Because when you are integrating OSS tools, you are wasting your time. When you integrate TFS, you are being enterprisey.

(Yeah, cheap shot, sorry, can't help it)

time to read 5 min | 806 words

Bil Simser has a few things to comment about me and Roy's discussion about TFS vs. the OSS stack:

Yes, other packages out there are extensible by nature (Subversion for example) but require coding, architectural changes, hooking into events, all of which are nice but systems like this were not designed for it.

That depends on what you want, but usually coding is not involved, scripting usually does. Arhcitectural changes, etc, are usually not involved.

Was subversion really designed at the start to be extensible so I could maybe have my storage be in a relational database rather than the file system?

I am not familiar with SVN's internals, but I would answer yes, it already has two storage providers, adding a third should be possible. Let me turn that question around for a moment, can I extend TFS to use Oracle as the backend storage?

Could I crack open subversion to support a way to link checkins to an external feature list? Sure. Why would I when TFS has this already.

And since Subversion has this already, the point is moot at any rate.

And finally, the piece that caused me to post it here:

As for modifying open source systems to do your bidding, you enter into a fork scenario. Unless the system supports a plug-in pattern and you can just add a new assembly (like say oh the TFS policy sub-system) I really can't do much with a tool even if I have the source code, unless I want to run the risk of being in a maintenance nightmare from Hell scenario. Do I really want to do diffs of new relases of NUnit with my own code to support new extensions.

Forking isn't nice for you, and I would usually recommend against it. But the point is, most OSS projects already have an extension model. NUnit certainly does, Rhino Mocks does, Subversion does, NHibernate has them all over the place, Castle Windsor is a big (and beautiful) extensibility model all in itself, log4net lets you plug in at any point in the pipeline, etc.

In fact, that is one of the reasons that I like OSS, because so often they have this really nice model of safely extending the functionality. Bil mentioned extending TFS to include a "steps to reproduce" field, here is the same for Trac:

repro = textarea
repro.label = Steps to repreduce
repro.cols = 60
repro.rows = 30

Very simple to extend, and if I wanted to add logic as well, that is simple to do as well.

And while it might have deficiencies in various places I can plug in new features or introduce entirely new concepts to the repository so that I can make it match whatever business process I use.

TFS makes me wait for it, that doesn't mesh with the way I do business. Please instruct me at the values I should put in the "MakeIsFast.config" file.

Is the source control system in Team Foundation Server extensible or replaceable? No, but I'm willing to live with a few problems while we get to version 3.0.

I think that you under estimate just how critical this deficiency is to me. It makes me snap out of the zone. It makes me aware of the tool, and not in a good way. If a tool get in my way I would either improve it or throw it.

time to read 8 min | 1525 words

This is getting fun, another reply from Roy in our discussion about TFS vs the other alternatives.

Regarding my last post, Oren (Ayende) points out that regarding TFS's features, he can either find a match for them in open source land, or he doesn't really care about them.

What bugs me is whether, assuming you can find and create such a solution out of a package of open source applications working together that operate with the same level of integration as TFS, can you still handle the things that matter to the organization using your solution.

I believe that I can, and we have been doing this for the last several projects that we built. Roy lists some interesting points about choosing the development stack:

Maintainability: Granted, it's not easy to maintain a TFS installation, but it sure as hell just as hard if not harder to maintain a full range of open source tools, each one from a different publisher, different versions and compatibilities, documentation and support services (if at all).

About 6 months ago I had a go at installing and configuring Trac for Wiki/Issue tracking. It took me a few days to grok the way it works, but we have been using it ever since. The last time that I had to administer it was three months ago, when we had to open a new project, and it tooks three minutes on the phone to deal with that.

There is a reason why I keep coming back to Zero Friction. That is what I get from my stack of OSS tools. They are there, and they are working, I use them when I need their services, at all other times, they don't get in my way.

TFS gets in my way, I accidently clicked on the Team Explorer band on the right side and it hung VS until it connected to the server and did something that is of absolutely no interest to me at the time. Annoying in the extreme, shove me out of the zone, and makes me feels out of control. Controlling Your Environment Makes You Happy!

Learning curve: I have no doubt that 9 times out of 10, it is harder to get up to speed on an open source product than a commercial one (there are always exceptions). Double that by the number of different products you are using and see what you get. Usually the documentation is not as good, and the support contract (if exists) is very poor as well. The efforts to maintain the source code and create your own version might actually be higher than what you are trying to save. And no, I don't think it will still be less that the cost of a commercial product (TFS or otherwise)

I am probably in no position to disagree (biased), but I still disagree. I could come up with a few examples, but they would fall into the exceptions clause, so I would just say that it is usually rare to maintain forked version for a long period of time, and usually not necessary. OSS usually has better solutions for this (well defined extension points, for instance).

In fact, I can say that synergy between OSS projects can cause some really sweet results. I have profiling and tracing for NHibernate built on top of log4net, and the NHibernate Search deal is really sweet. That said, I am using a lot of commerical tools because they are better/easier then a comparable OSS project. My reasons may be different, though. I am using SQL Server because Management Studio is a nice UI (although I wish it would still some features from PL/SQL Developers), WCF because it has good UI for logging, etc.

Ease of use: Usually I find that Open source products tend to be less usable than commercial ones. Money does matter. Yes, there are always exceptions. Actually, Eclipse is an IDE I find more usable than VS.NET. But then again, Eclipse's community is funded as far as I know. Money matters.

No argument here. The final coat of paint care make a lot of difference, and it usually takes some money to really get all those nooks and cranies.

That said, there is another element of ease of use that should be considered, and that is the simplicity of the architecture, the assumptions being made about the amount of time that is going to be invested in it, etc. The Entity Framework (to take an example at random) can afford to be complex and ungainly, because they can cover the ugly stuff with pretty designer, an OSS project is usually not at liberty to do so, and as a result, would arrive at a much simpler solution to the same problems.

If you found subversion to be working too slow for you, what are the odds you'd go hack the code for yourself to get a better version? then update it with every new drop? what would be the cost of that?

I don't think that Subversion being slow is the case here, but I will answer anyway.

I know C and C++, so yes, I would. I wouldn't need to update it with every new drop, I would submit the patch to the core team, and then have it there forever.

What is the cost of that vs. a commerical product (which is not slow in theory only)? Well, 0 for the software, and some high amount for spending time hacking at the source to make it faster. What is the cost for doing the same with commercial product? Some initial high amount (although probably less than than the hacking would be), then contiual bleeding of time as a result of problems that I can't fix. But you know that this comparision is flawed, because Subversion is not working too slow for me (and it is known to scale much better than TFS).

It's quite easy to say "I'm not using this because of X,Y,Z". It's quite a different story to say "I know it has it's problems, but looking at the bigger picture I owe it to myself to see if I can find a way to work with it despite of the shortcomings"

And it is another story yet again when to say, "I know a different solution, which can give me all that I need/want, so I don't have to deal with those shortcoming." The bigger picture as I see it is that I get everything that I want, and don't have to waste my time on patching holes in the tools that I use. Tools should be transperant, not road blocks.

But slamming on a tool just because some parts of it are not the fastest is just wrong. The Source control is still one of the strongest ones I've seen in terms of features. discounting it would mean underestimating a product that actually has much value.

Let me put it in the simplest terms that I can, TFS puts me out of the zone. That is simply unacceptable, period. If I need to be aware of "Don't go near the Team Explorer Tab, it will hung VS for 5 seconds", I am not in the zone. If I am not in the zone, I rarely get to code well. Beyond that, the source control in TFS doesn't offers anything that I haven't seen before, not in terms of features, and not in terms of the UI for them.

time to read 5 min | 893 words

Roy responded to my post about disliking TFS:

I think that Oren is making one big mistake: he's throwing the baby out with the bath water. Just because the source control is not as zero-friction as some open source alternatives, does not mean that TFS is not a valuable suite of tools, with more added value than most open source tools that I know of.

[List of advantages that TFS has snipped, will cover them later]

I mean, Oren, c’mon! You don’t like a part of a part of team system – the source control aspect is not perfect for you, but what alternative do you have for a suite of tools that works together so powerfully?

First of all, I am grateful that I am only making one big mistake :-) That said, I don't really have an issue with the rest of TFS, but the problem is that without the source control integration, it is losing quite a bit of its charm. The source control is the most visible and annoying part of TFS, I would love to give it a short with SVN integration, but I don't really see it coming.

Roy goes on to list a few points, which I would get to cover:

The ability to associate a work item with a check-in action is very powerful in determining and reporting “delta” between failing builds

Just about any bug tracker has this ability, it is not unique for TFS by eany means. Usually it is a matter of a few config options for SVN and a post-commit hook.

Builds are also connected to checkin, and build history allows you to ‘drill down” to see all the source differences between the last success build and the current failing one

This is nice, but it won't work with anything other SCM, so that it not very good. I can get that with Trac as well, so that is not something that really bothers me.

The ability to use “workspaces”, which map current source control into local directories is powerful because it allows you to work concurrently on multiple versions of the same product, and switching between them in a couple of clicks from the IDE

Bug, not a feature. You can't move the folder around, you have cruft left over in your system, deleting the folder won't rid of the remains, etc. Beside, what is the problem with "MyProd\trunk", "MyProd\Branch-1.0", etc?

  • Powerful automated reporting
  • Distributed and extensible build capabilities
  • Task and bug management
  • All of which are nice, but by no mean unique or even very impressive on their on.

    Also, it’s still a version 1.0 product, and you know that version 3.0 is usually the one to remember, but as a version 1.0 product, and compared to most OSS tools (working together), VSTS gives me something that I find hard to get anywhere else – true collaboration.

    Actually, no, I don't. And I flat out refuse to suffer the initial pain for the promised land. Feel free to call me heretic.

    The promise of TFS is that you get everything integrated, in one package. The problem of TFS is that you get everything integrated, in one package. I actually like the work items, and if I could get it outside of VS (don't your dare make the IDE any slower), I would like it better. The problem is that I can get as much and more from freely available projects, that works in zero friction.

    And you know what, I can get them to work together in the same time it takes to setup TFS.


    OSS Weekend

    time to read 5 min | 898 words

    I have been slacking my OSS duties recently, spent a whole lot more time relaxing than anything else. It was fun, but it had to end sometimes. It ended when the "to do" list got over 50 items. At that point I knew that I had to do something or drown under the sheer amount of stuff that I postphoned. I decided to dedicate some time over the weekend to weed out the todo list. Not surprisingly, quite a few of the todos were related to OSS projects I contribute to.

    There are at least three major things here:

    • Cloning / traversal of criteria queries, which, in conjuction with...
    • Multi Criteria Queries - can produce some really interesting results, and deserve their own post.
    • NHibernate Query Analyzer UI upgrade (thanks to Sheraz Khan)

    Here is a taste of what is new in NQA:

    (Image from clipboard).png

    Anyway, here is the full list, releases will have to come at a later time, I am feeling tired. Off to a non techincal meeting, that should give me enough reason to want to write code that I actually paid for :-)


    • NH-987 - SQL 2005 views used in SQL 2000 dialect
      Now using select 1 from sysobjects where id = OBJECT_ID(N'{0}') AND parent_obj = OBJECT_ID('{1}')
    • NH-831: Adding MultiCriteria
      Fixing a bug with MultiQuery and the second level cache, where each query pagination status wasn't taken into account when retrieving from the cache.
    • Moving to Dynamic Proxy 2 (Patch by Adam Tybor)
      Removed the TODO in NHibernateProxyHelper, at last :-)
    • NH-924 - inspection of criteria.
    • Fixing spelling error from previous commit
    • NH-988 - Proxy validator should complain on non-virtual internal members
      Applied patch by Adam Tybor


    • (validator) Added a way to override message definition using external resources file.
    • Fixing the build (that I broke in last commit)
    • Allowing to get the interceptors for a proxy (NHibernate needs this).
    • Revert unnecessary change to BasePEVerifyTestCase
    • DYNPROXY-58 - Inherited interfaces - FIXED.
    • DYNPROXY-56 - workaround for CLR serialization bug, applied patch from Fabian Schmied
    • (Windsor) Fixing spelling mistake
    • Adding passing test case for IoC-73.
    • (Brail) Fixing MR-248 - Pre-Processor Issue
    • MR-247 - Brail uses different keys for putting and getting items from the compilation cache.

    NHibernate Query Analyzer:

    • Much better support for AR:
       - Version insensitive
       - Can handle merged assemblies
       - Can handle pluralizeTableNames
    • Applied patch from Khan, Sheraz - Adding tree of entities and properties tree.
    • Updating NHibernate to trunk
      Updating tests to work against the new version.
    • Final touches to tests.

    Rhino Mocks:

    • Applied patch from Ross Beehler, adding more smarts to Validate.ArgsEqual
    • Fixing an issue with mocking objects with protected internal abstract methods.
    • Adding (passing) test case for mocking interfaces with generic methods that has constraints.
    • Removing 1.1 legacy collections.
    • Fixing an issue where internal interfaces could not be mocked in strongly named assemblies.
    • Adding license header to all the files.


    No future posts left, oh my!


    1. Challenge (75):
      01 Jul 2024 - Efficient snapshotable state
    2. Recording (14):
      19 Jun 2024 - Building a Database Engine in C# & .NET
    3. re (33):
      28 May 2024 - Secure Drop protocol
    4. Meta Blog (2):
      23 Jan 2024 - I'm a JS Developer now
    5. Production postmortem (51):
      12 Dec 2023 - The Spawn of Denial of Service
    View all series


    Main feed Feed Stats
    Comments feed   Comments Feed Stats