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.

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.

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.

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

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.

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#.

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.

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:

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.

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.

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 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...

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

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)

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

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

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?

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

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

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:

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

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.

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.

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

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:

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!

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.

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.

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).

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.

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.

Roy responded to my post about disliking TFS:

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:

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.

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.

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?

All of which are nice, but by no mean unique or even very impressive on their on.

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.

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:

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 :-)

NHibernate:

• 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

Castle:

• (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.