First, i’ll show the whole class again:

Basically, the purpose of this class is to hold a set of ISessionFactory instances, each of which belongs to a particular tenant in a multi-tenant application.  Tenants can be added on the fly (without restarting the application) and when an ISessionFactory doesn’t exist yet for a particular tenant, it must be created when the first request for an ISession for that tenant comes in.  Obviously, access to the sessionFactories dictionary must be thread-safe since multiple threads will be reading from the dictionary as well as occasionally writing to it.

I considered 3 options to make sure access to the dictionary would be thread-safe:

1. Traditional locking (through the lock statement or the Monitor class)
2. Using the ReadWriterLockSlim class
3. Using the copy-on-write pattern

Traditional locking was quickly scratched from the list because that would require me to lock for every read of the dictionary as well as every write.  Now, pretty much every single request requires an NHibernate session which means that pretty much every single request results in a lookup in the sessionFactories dictionary.  If i need to lock for every read, this significantly hurts overall throughput of the system. 

The ReadWriterLockSlim might be a good solution here… after all, the short description of this class in MSDN says this:

Represents a lock that is used to manage access to a resource, allowing multiple threads for reading or exclusive access for writing.

Sounds like what i need, right?  But the thing is, i’ve never used the ReadWriterLockSlim class before and it hasn’t really gained my trust yet.  I know that’s a terrible excuse for not using it, but here me out.  While the ReadWriterLockSlim likely reduces locking overhead over traditional locking substantially, there still has to be some overhead for read operations, even if it is small.  In most situations, that small overhead wouldn’t bother me but in this case, that little overhead would be added to pretty much every single request in the system.  Now, writing to a dictionary implies that a new tenant has been added to the system.  In the context of this system, that’s not even gonna happen on a daily basis.  Hell, once a week is probably a best-case estimation and even that is highly optimistic.  So i really don’t want any kind of overhead on read operations when the write operation is only going to happen very occasionally.

That leaves the copy-on-write pattern.  I’ve used it before with success (though at the time, i didn’t know it was a known pattern) so this approach has already gained my trust.  It basically implies that we don’t do any locking on the read operations, but whenever a write operation occurs we copy the original set of objects, perform the write on the newly copied set and then set the reference of the original set to the newly created and modified instance.  During this whole time, every single read is safe.  Successive reads within the same logical operation however aren’t, so the following code would not be thread-safe:

Because there’s no locking on the reads, the code within the if-block could fail because the sessionFactories reference could be pointing to a new dictionary which no longer contains the element for that key. 

Of course, if you have frequent writes, the overhead of copying the set of objects every time you need to add/remove one might be bigger than you want, so this isn’t a pattern that you should use whenever you need to protect access to a shared resource. For this situation however, i think it’s ideal… though i’d obviously like to hear about better solutions

Now, let’s take a closer look at the pieces of code that perform the write operations.  First, adding a new ISessionFactory to the dictionary:

As you can see, the entire operation is put between a lock on the writeLock object instance.  The downside of this is that creating an ISessionFactory instance is an expensive operation, which means the lock will be held for a long time (could easily be one or more seconds).  Then again, i don’t anticipate this happening frequently so it’s not that big of an issue… especially since reads aren’t being blocked by this anyway.  This approach also prevents the creation of 2 ISessionFactory instances for the same tenant.  Well, unless i missed a bug here :p

Now, once the ISessionFactory instance is created, we create a new Dictionary based on the contents of the old one and then we add the new ISessionFactory instance to it.  After that, we replace the sessionFactories references with the new dictionary and from that point on, every read will use the new dictionary instance.  During this entire operation, no read operation was impacted negatively. 

Now lets take a look at the other write operation, removing an ISessionFactory instance from the dictionary:

The first if-check, which happens outside of the lock is a bug that i missed but that was pointed out in the comments of the original post.  If CreateSessionFactoryForCurrentTenant and RemoveSessionFactoryForTenant would execute concurrently for the same tenant, it’s possible that the ISessionFactory instance of that tenant is never removed from the dictionary (and also never disposed of…) since the check happens outside of the lock and could be executed before the ISessionFactory of the tenant was added to the dictionary.  In that case, the ISessionFactory instance would stay in the dictionary as long as the application stays up.  This is definitely a race condition that you want to avoid in every other situation though in this case, the odds that we’re simultaneously adding and removing the same tenant are slim to none.  Nevertheless, i don’t want to be accused of promoting race conditions so we’ll make the change anyway

Now, as you can see we once again create a new dictionary based on the previous one, then remove the ISessionFactory instance for the current tenant and then we overwrite the sessionFactories instance once again.

Finally, there’s the read operation that i specifically didn’t want suffering from locking overhead:

The only time this code will block is when a new ISessionFactory for the current tenant needs to be created.  Luckily, that only happens once for each tenant.  As i mentioned earlier in the post, using this pattern doesn’t guarantee that successive reads within the same logical operation are thread safe, so there is a bug in here.  If a tenant already has an ISessionFactory instance, it’s possible that the RemoveSessionFactoryForTenant method has been executed between the if-check and accessing the ISessionFactory based on the tenantId.  In that particular scenario, the ISessionFactory instance is no longer in the dictionary which will cause this code to throw an exception.

That’s a bug that i don’t feel like fixing though… Once a tenant has been removed, they are no longer a paying customer.  If they are no longer paying for the software, there is no reason whatsoever why i should care about any possible exceptions they could get while running the software

Seriously though, if the RemoveSessionFactoryForTenant method is called, users of that tenant won’t even have access to the system anymore so it’s really a non-issue.

Anyways, i think i’ve covered the implementation in more detail than you probably cared for.  So, any thoughts? Are there still issues that i haven’t thought of? Is there another approach that you would use for this specific scenario?

The idea of sponsoring an open source project and helping out financially is definitely nice, but there are some very important practical issues that need to be kept in mind.  Those practical issues are IMO being ignored by this campaign (which honestly feels like a publicity stunt more than anything else) … some of them were mentioned in the original mailinglist discussion but no resolution has been offered.  There are probably more issues that we haven’t even thought of yet, but the most important ones are (again, IMO):

• Who’s going to decide how much of the money will go to the committers, and what will that be based on?  Will it be based on past contributions? Future contributions? The complexity of the contributions? Total number of contributions? Total time spent on the project?  We can’t even measure some of these things, so this is bound to either raise some discussions sooner or later, or might even upset some people.  I can certainly imagine that some contributors from the past (like, the ones who did most of the really hard work in the beginning) could feel that they’re entitled to some (or most) of the money.   Discussing how to spend the money on committers is just going to open a can of worms that could possibly cause much more problems between committers than it would solve. 
• There has to be some legal entity (or at least a person) who’s in charge of the bank account where the money will be deposited.  At this point, we have no formal structure or organization to deal with something like that.  I’m no expert on legal matters at all, but i can’t help but think that this isn’t something you can just decide on in a mailinglist… Some level of formalization is most likely required here.
• Taxes… if the money goes to committers, then they will have to pay taxes on it based on the laws of the country they’re living in.  Tax laws obviously vary from country to country, but i don’t think it’s unrealistic to claim that between 25% and 50% of the money will simply go to the government(s) instead of actually benefitting the project.  You might wanna keep this in mind before you donate…

These are just 3 big issues that could come of this, and i don’t really see a true benefit to the whole thing.  The people who in the past have spent time on NHibernate either volunteered to do so, or were paid by someone (or some company) to spend a certain amount of time on it.  Without donations, it will just go on like that and i don’t really think there’s anything wrong with that.   While resources are certainly limited, this approach probably causes less problems than one that distributes donations amongst committers.

Now, just to be absolutely clear on this… i am one of the NHibernate committers, and i don’t feel that i’m entitled to any of the money that will be raised.  For one, i haven’t committed anything in the past 6 months, and the things i did commit definitely aren’t worthy of a donation.  If we are going to accept donations and spend it on people instead of infrastructure, i believe any money that would be raised should go to the people who originally started NHibernate and worked hard to get it to a state where it actually became usable in the .NET world.  If it weren’t for their efforts, it never would’ve been in a position to become the de facto ORM in the .NET world, regardless of who’s working on it right now.

1. it might contain bugs that i’m not aware of
2. it contains weird parts that were either brainfarts on my part, things i did on purpose to avoid possible issues, or both
3. it contains at least one bug that i know about, yet don’t care about
4. i removed the comments that i originally put in it to make things more interesting
5. i haven’t tested the code yet
6. i haven’t even executed it yet
7. i think it’s ok… but i’m not sure

Questions will be answered if you have them (and i’m sure you will) though i can’t make any promises as to how soon i can answer them… I will post a follow-up post to discuss the code in its entirety later on, though i’ll probably wait a few days to do so.

This is the code:

The sad (and typical) part is that the methodology which makes everything sound easy and prescribes the least amount of effort required is the one that took off the most.  Obviously, i’m talking about Scrum.  Scrum makes no mention whatsoever about technical practices that are required to enable sustained progress and Scrum proponents will proudly proclaim that it doesn’t need to since it’s about product development instead of software development.   You can easily become a certified Scrum master while you might not know anything about real-world software development.  In fact, i’ve seen plenty of people boasting that certification on their resume and their linkedin profiles while they really shouldn’t be involved in any kind of professional software development to begin with.

And since Scrum is simple enough for middle-management (you know who i’m talking about… the ones that are usually not competent enough to promote to upper management) to understand, they jump on it as well and before you know it, they’ll be talking about the Scrum concepts as if they actually knew what they’re talking about.  Teams and even entire departments in large corporations are told to be ‘agile’ and follow the Scrum rules and concepts for every new project.  And they do.  And it works great… for a while.  We all know what happens after that.

Then take a look at Extreme Programming (XP).  It’s been around for a while now.  And it unfortunately doesn’t have a good, catchy name.  In fact, its name is probably one of the biggest reasons why it never took off the way Scrum did.  XP prescribes a lot more than Scrum, and even details the technical practices that you’ll need to enable sustainable progress.  And while you don’t need every single one of them, they all provide major benefits and the more of them that you do use, the better off you’ll be.   So what is the problem with XP?  I never really understood why so many people jumped on Scrum, and now Lean (until the Toyota recalls that is) but never really got into XP.   Well yeah i do understand.  XP takes more work and effort to understand and apply.  And that, my friends, is the price you’ll have to pay for sustainable progress(*).

*: i’m talking about the actual effort and work, not XP in itself

And that is when problems might appear.  If you’re using Castle Windsor with the default ReleasePolicy (which is the LifecycledComponentsReleasePolicy) then each resolved transient instance will be stored in memory by that policy until the instance is explicitly released.  The benefit of this policy is that the container can automatically dispose any disposable transient dependency of a resolved component.  In my case, i’ve come to rely on that feature to achieve deterministic disposal behavior throughout my code base. 

Now, when you configure NServiceBus and pass it your instance of Castle Windsor, it obviously doesn’t change the ReleasePolicy like it does when it creates its own instance of Castle Windsor.   This is good because changing the policy of a passed in container would almost certainly have a huge behavioral implication for the application and such an action would be unacceptable when integrating a new framework into your project.   But since NServiceBus doesn’t have the notion of needing to release resolved components, every single transient instance it resolves through your container will be stored in memory until the application’s process is terminated.  Which means that you’ll leak instances of the following types for each message that your system needs to handle:

• NServiceBus.Grid.MessageHandlers.GridInterceptingMessageHandler
• NServiceBus.Sagas.Impl.SagaMessageHandler
• Your own MessageHandlers (and their transient dependencies as well)

If your MessageHandlers don’t have dependencies (highly unlikely if you’re already using an IOC container) then you’d still have 3 leaking instances per incoming message.  Add the number of transient dependencies of any handler to that and the number of leaking instances can increase dramatically.

First of all, if you do not depend on Windsor’s default ReleasePolicy’s behavior, then the easiest way to avoid this problem is definitely to set the container’s ReleasePolicy to the NoTrackingReleasePolicy like NServiceBus does itself when it’s configuring itself with a new instance of the container.

If you do depend on it, and you don’t want leaking instances that hang around forever, then the approach listed below is one way to solve this problem.  There are probably other solutions available, and while the approach listed below can definitely be considered to be a HACK, i do think it’s the best solution to this particular problem.

Because we don’t want to change anything about the way that we’re already using the container, we just need to make sure that NServiceBus’ usage of the container doesn’t conflict with ours.  That basically means that we need to make sure that the components that it resolves should not be tracked by the container.   There are 2 kinds of components that NServiceBus will resolve during normal operation:

1. Its own components that it needs to implement the features it offers you
2. Your message handlers that you need to handle incoming messages

The first category is easy to exclude from Windsor’s tracking behavior.  We can simply create our own ReleasePolicy which extends the default ReleasePolicy, and make sure that any instances of an NServiceBus-type are no longer tracked by the container:

Then you need to set this release policy somewhere in your application’s startup routine:

(in this case, IoC.Container returns an IWindsorContainer instance)

This will make sure that no instances of NServiceBus-types will ever leak in the container.  But now we still have to deal with our message handlers.  The solution to making sure they are not disposed is not the cleanest out there but hey, it works.  I basically introduced a base class that all my message handlers will need to inherit from, with the following implementation in the Handle method:

Uh oh… i just felt a great disturbance in the Force, as if tens of voices suddenly cried out in terror about my direct usage of the IoC container in a component!

Conceptually, this is wrong on many levels.  Then again, this makes sure that the message handlers (and their dependencies) that are resolved by NServiceBus will always be guaranteed to be released by the comtainer.  It might not be nice, but it avoids the memory leak and it doesn’t force me to change my other code.

And once NServiceBus is modified to release the components it resolves (if it’s ever modified that is…) i only need to get rid of my custom policy and the try/finally block.  Unfortunately, my existing message handlers will then all implement the Process method instead of the Handle method but that is quickly fixed with a simple rename-refactoring.

Even though this is a pretty big hack (IMHO), at least its impact on the code is minimal… it will be easy to get rid of once the real problem is solved in NSB, and there are no real downsides to this that i can think of at the moment.

These days, you’re an absolute moron if you’re still using a relational database. And forget about getting invited to the best parties if you’re not developing according to the Command and Query Responsibility Segregation (CQRS) pattern. And if you’re not doing Lean then you’re really not worth listening to. Oh no wait, talking about Lean isn’t hot anymore since the Toyota recalls so we can scratch that off the list, sorry about that one folks.

Now, i’m not saying that the whole NoSQL and CQRS thing is worthless. I actually find them both very interesting. But to all of you who are now pushing these things as if they are the greatest things since sliced bread, i would just like to ask one thing: can we get some more real-world examples? You do use these things in real-world projects before proclaiming that these approaches will fix all (or most) of our current problems, right? You’re not just trying to be cool on the internet, are you? Honestly, of all the people that i hear talking about these things lately i only really believe about a handful of them when they say they use these things in real world projects. I’ll leave it to you to figure out who the real ones are, and who is just jumping on the bandwagon.

And no, i’m definitely not going to claim that using an RDBMS for every system is the best choice. I complain about databases every day, but i’m not just going to claim that going with a NoSQL database is going to solve all our problems either. I’d actually feel rather silly doing so, unless of course i’d be able to actually back up what i’m saying. Which i haven’t really seen happen yet.

The thing is… there simply is no one-size-fits-all approach to software development and it’s pretty sad to see that some idiots actually appear to believe that there is. Sometimes an RDBMS makes sense, and sometimes it doesn’t. Sometimes MVC makes sense, and sometimes it doesn’t. Sometimes DDD makes sense, and sometimes it doesn’t. Sometimes CQRS makes sense, and sometimes it doesn’t. That goes for every tool, library, architectural style, or whatever other buzzword you can think of. Use what makes sense for what you need, and let’s not pretend to be someone or something that you’re not, ok?

and then this:

to make a problem go away.

Can you come up with a WHY comment? (the category of this post is another hint)

Some people will stick with Castle Windsor, some swear by StructureMap, some will always use Autofac, some only want NInject… hell, i even know a few people who still prefer Spring.NET. The only one that doesn’t seem to have many loyal followers is Unity . Every container has its strengths and weaknesses but most of them range from very good to downright excellent. When new features are introduced to one container, they often quickly find their way into the other containers as well. A cool new feature in container X is rarely a good incentive to switch containers because odds are high that your favorite container will get the new feature pretty soon as well.

What i think is a big reason of this (observed) loyalty is that the more you rely on your IOC container’s power, the less likely you are to switch to another container out of fear that some things might behave differently or might not work the way you think or expect they will. If the container you’ve chosen to use has proved itself to you in production usage, you are very unlikely to replace it with another. After all, it’s a very important piece of how your project works and you probably depend on it a lot. You’ve probably become very familiar with its behavior in different circumstances and you’ve either come to rely on that, or have learned to live with it in some way. But you’ve learned how it works and you’re pretty sure that there are no unpleasant surprises that will pop up a couple of days or weeks after a new deploy. Because of that, i really wouldn’t feel all that comfortable with switching to a new container. And lets face it, they all have their little special cases that you really need to know about to avoid problems.

And if you are using features that are unique to your container, then you’re obviously even more unlikely to make a switch. In my case, i used Castle Windsor when i first started to use an IOC container. I ran into some issues with memory usage because of the way Windsor works, but once i learned that i always have to explicitly release any resolved components, the problems went away. In fact, i’ve come to rely on the fact that by releasing a resolved component, its disposable transient dependencies will automatically be disposed by Windsor as well. I’m not sure about this, but i think Windsor is the only container that does this, or at least one of the few that do. I actually consider it a must-have feature for a container, but most people don’t seem to consider this as important.

I can’t really imagine a situation that would make me consider switching to another container at this point… well, unless its development would someday halt obviously. And even then i’d probably be holding on to it for a long while. How about you? How likely are you to switch to a different container? And what would make you switch? What holds you back from switching to a different one? Which one do you use and why do you like it so much?

Ok, i’m back from my trip to New York. The picture above shows me and the 2 friends that joined me on the trip on top of the Rockefeller building. For those of you who have no idea what i look like (and i’m assuming that’s most of you since i never put a picture of myself on this blog before), i’m the dude on the left (_your left_). The entire trip was simply fantastic… we did so much stuff that we often didn’t remember what we did over 2 days ago without pulling out the digital cameras, but some of the highlights include:

• The statue of liberty… it’s a bit cliche, but seriously, the level of detail on that statue is truly astonishing… the French really did a fantastic job on it (yea i said it )
• Going to a taping of David Letterman’s Late Show… i was sorta hoping in advance that we could get in, but we really didn’t plan on it. We went into the Ed Sullivan’s theater asking for tickets, and luckily we were ’selected’ (the fact that it was freezing and that this was the tourist low season obviously helped) to attend a taping a few days later.
• Brooklyn Dekker… anybody who knows me in real life knows i have a soft spot for good looking women, but when Brooklyn Dekker (the Sports Illustrated Swimsuit Edition cover model) got on stage during the taping of the Late Show the entire audience kinda got silent for about 2 seconds.. she really looked that stunning.
• I’v been an NBA fan for the last 16 years or so… i finally got my first chance to see an NBA game in real life. Ok, it was the Kincks vs the Kings (2 of the worst teams right now) but it was still a great experience… and i was actually at Madison Square Garden! (if you don’t know the significance of that, don’t worry… only basketball fans will understand)
• My pancakes with strawberries and ice cream breakfast… yeah seriously, it was that good
• Me asking an NYPD officer holding an M16 politely if i could take a picture of him and answering “oh… ok then” when he said he didn’t want me to take a picture of him
• Walking through Brooklyn during Snowmaggedon looking for Grimaldi’s Pizzeria only to (finally) found it being closed.

Those were the highlights but pretty much every single moment of the trip was memorable and i truly hope that i never forget a single one of them. I took 1125 (according to iPhoto) pictures and they were definitely needed to remember everything that happened in such a short timespan. We went during the low-season and even then, New York is definitely worthy of visiting. The only thing you’ll regret is that you either didnt’ stay long enough, or that you didn’t buy enough clothes (thank you oh horrible Dollar).

Once i got back to my country (Belgium for those that don’t know), i was astonished to see how badly it was handling the less than one inch of snow after what i had just seen in Manhattan. The difference really is huge. I usually avoid politics on this blog as much as possible, but the way our government is handling things compared to how they’re dealt with in New York in much worse weather conditions is truly saddening. Less than an inch of snow and the whole country seems to be at a stand still. And people wonder why i dont go out to vote (that’s right… we are required to show up at elections but i refuse to show up because there really isn’t even a single person who’s worthy of a vote right now).

Anyways, i’m back and i’m working through the backlog of unread posts in Google Reader… there have been a couple of posts so far that might inspire a few posts but other than that, i’m lacking any kind of inspiration to write a real post at the moment so if you have any requests, now is the time to make them

To wrap up this post: it was great to be gone for a while, but it’s great to be back as well

I’m not leaving until Saturday morning, so if you have some ‘must-see’ or ‘must-do’ tips about New York, bring em on!

(note: these numbers are obviously only from visits to this blog and are thus not representative of the entire internet (yet) etc…)

I started at the month before the first Chrome users were reported to give you an idea of Firefox’s score at that time.  Naturally, the people that come to this blog are into technology so it’s no wonder that Firefox is the dominant browser instead of IE.  Before Chrome entered the picture, nearly 70% of all visits to this blog in August 2008 were from Firefox users.  In its first month, Chrome immediately got about 8%, which i thought was pretty impressive.  Firefox’s numbers dropped below 50% for the first time less than a year later.  That’s a pretty big impact in a relatively short time.   And as you can see, Chrome usage has been growing a lot in the past 6 months ago, at the expense of both Firefox and IE.  I wouldn’t be surprised if Chrome catches up to Firefox in another 6 months.

I’m not fanatic about any browser (as long as i don’t have to use IE, right?)… i use Firefox for OS X at home, but i use Chrome at work.  I’m not really into the whole plugin/extension thing (except for Adblock obviously) so i’m not really ‘tied’ to a specific browser.  Now, some people are pretty fanatic about their browser so what i’m wondering is: what would it take for you to switch to another browser (no matter which one you use now)?  Are you hooked on extensions that you can’t go without in another browser?  What was the reason you picked your current browser and why are you sticking with it? Or is it all pretty much the same for you?  Do you frequently use multiple browsers?

In some weird way, i find that kinda stuff interesting so please do share

This probably sounds a bit touchy-feely, but I think dismissing it on those grounds is ignoring a fairly fundamental part of human nature. If every day, every task is a thankless struggle, the intertia will pull down your team’s morale, motivation, concentration, and reduce their creativity and ability to innovate. On the flip side, once the team gets up a bit of steam and starts churning through stories, seeing visible progress as they move across the task board and into the Done column, the team’s enthusiasm and creativity soars. They start kicking around new ideas on how to remove some duplication from the code and reduce some overhead for future stories.

David is right, but i’d go even further than that.  I’d assert that good team dynamics are essential for achieving high technical quality that is sustainable in the long term.  I think we can all agree that people work better together if they actually like working with each other.  And i’m pretty sure that many of us have experienced first hand how a negative relationship within a team can have a pretty negative impact on the technical quality of a project. 

Have you ever been on a project where you were looking at a piece of code thinking “wow, this really ought to be cleaned up… but i’m not touching it since John is gonna get all pissed over somebody touching his code”.  Or worse, “wow, he really made a mess of this but i’m not touching it… let him live with the pain”.   I certainly wouldn’t be surprised if many of us have at one point (or more) in our career had this exact thought about a certain piece of code written by a teammate at the time.  That is a perfect example of how negative team dynamics can have a pretty serious impact on the technical quality and thus, i’d argue, the long-term viability of the project.   See, the thing is that it won’t end what that certain piece of code.  Sure, code rot has been introduced.  But even worse, team rot is being introduced by this behavior as well, even if you are just trying to preserve the peace by trying to avoid a possible confrontation.

This kind of team rot will not end there.  If you don’t actively try to get rid of it ASAP, it’ll eventually spread throughout the team, as more and more people gradually get into the same mentality.  Eventually, even the strongest, most positive personalities can fall victim to it.  When new people join the team, they’ll quickly pick up on it as well and there are very few people who are willing to stand up to such a situation when joining an existing team.  As i’m sure you can imagine, nobody really likes working in such a team.  A lot of people in that situation will get into a “i’m just gonna look out for myself and to hell with anyone else” mentality.   They will try to do their job in a way that they will not be blamed for anything.  Communication will drop to a ‘nothing-more-than-necessary’-level.  A lot of issues will be ignored until they are actually found by end-users.  A lot of time and effort is going to be wasted in general.  And you’ll probably end up with a pretty high turnover rate of team members.  Believe it or not, these kind of teams truly do exist.

On the other hand, if everybody on the team gets along everything seems to go much more smoothly.  People won’t be afraid to make changes in other people’s code if everyone understands that it’s for the best of the project and if they know that it’s not gonna lead to a bitchfest from a difficult team member.  Discussions will be about actual facts and merits, not about not-wanting-to-give-in-to-someone-you-no-longer-like.  People will alert their team members when they notice something that could cause problems later on.  People will be much more likely to maintain their technical discipline when there is positive peer pressure to maintain high standards.   People will help each other when they can.  Essentially, those people will form a true team instead of being a collection of coworkers who are unfortunately working on the same project together.

As much as many of us strive to improve our technical abilities and skills on a continuous basis, we also need to ask ourselves the following questions regularly:

• Am i a good team member?
• Would i like to work with someone like me?
• What can i do to make people enjoy working with me more than they might do now?

That doesn’t mean you have to become Mr Popular.  It doesn’t mean you have to crack the best jokes.  You can be almost entirely yourself, as long as you realize that:

• communication is extremely important
• treating others with respect is crucial
• nobody likes working with whiney developers
• you can’t expect others to work on their flaws if you’re not willing to work on yours… it’s a two-way street

Once you install the Visual Studio addin through the VisualNDepend.exe tool, you’ll notice the following menu has been added in Visual Studio:

If you select the first item, you can easily create a new NDepend project for your current solution:

You’ll also notice an NDepend icon in the bottom-right corner of Visual Studio.  Clicking on it shows you an immediate overview of NDepend’s CQL query results for your solution:

Clicking on the Show SQL Explorer immediately brings you to this view, which many NDepend users will recognize:

You can also right-click on a type (or a method) and you’ll see the following NDepend context-menu:

Which in turn allows you to open many of the familiar NDepend views:

This particular view is something that i find extremely useful.  Notice how you get an immediate overview of relevant metrics when you click on one of the items in the graph.  Or you can look at the metrics view:

I’ve never understood how to interpret this view, but NDepend users who do will be glad to know they can now access it extremely easily

One thing that i can see myself make extensive usage of are the following features:

I’ve only played around with it for about 15 minutes now, but i’m impressed.  I never really liked NDepend 2 because i always got completely lost in the VisualNDepend UI.  Now that i have all of this integrated in Visual Studio, it just seems much easier to get to the information i really want.  And if you have to review a lot of code (like me), then this new NDepend version is sure to save you a lot of time.   It’s pretty much everything you’ve always wanted or already loved from NDepend, but much more easily accessible.

I did notice some small visual glitches (which might be related to running this in a VMWare virtual machine on OS X) and at one time even a Visual Studio crash, but i’m sure those issues will be fixed before the final release.

Oh, and i’m also very happy to note that this particular issue has also been resolved

I don’t like to tie myself to WCF-specific features, so i always plug in custom authentication into either a custom Request Processor, or a base Request Handler class that all other Request Handlers must inherit from.   But first, how do we get the authentication-related data from the client to the service?

In each project i use Agatha in, i always have a MyProjectRequest and MyProjectResponse base class:

Each request in the project inherits from this base request, and each response inherits from the base response.  The base response class is often empty, though this does make it very easy if you ever need to send something back with every response.

Now obviously, if every single request that is sent to your service layer needs values for the UserName and PasswordHash properties you want this to be done in only one place.  I do this by using a custom request dispatcher:

The IUserContext dependency is just a component that is registered in my IOC container and will be injected automatically whenever you get an instance of IAsyncRequestDispatcher.   Now, in this example you can see that i add the authentication data to every request in a batch, even though the batch will be sent in one roundtrip.  If you want, you can add the authentication data only to the first request and then only use the first request to do the authentication within your service layer.  I prefer to add the authentication data to each request and then authenticate every single request (even subsequent requests in a batch) within the service layer.  I’ll get back to this point later on.

Now, the only thing we need to do to make sure that your requests will always have the authentication data contained within them is to instruct Agatha to always use instances of your MyProjectAsyncRequestDispatcher class whenever an IAsyncRequestDispatcher is needed.  This is easily done during Agatha’s client-side configuration:

Keep in mind that you still have to register your IUserContext with the container on your own though. 

With that in place, we are sure that each request that comes from our clients always contains the proper authentication data.  Now we need to make sure that we actually authenticate these requests within the service layer.  You basically have 2 options: either implement your own Request Processor which adds authentication checks, or create a base Request Handler that your other Request Handlers inherit from.

We’ll first cover the option of using a custom Request Processor.   You could create one like this:

The BeforeHandle virtual method is called right before the request is passed to its Request Handler to be handled.  Note that this Request Processor would authenticate every request.  If you want a Request Processor that only authenticates the first request, you could do so like this:

The BeforeProcessing virtual method is called before any of the requests are handled, so you could authenticate only the first request in a batch and then proceed with regular processing if the first one is authenticated.  Now, the big problem that i have with this approach is that you aren’t really in control of what is sent to your service layer.  Yes, you can guarantee that each request coming from your clients contains the proper authentication data.  What you simply can’t guarantee however is what other people or custom clients can send to your service layer.  If they send you a batch of 2 requests, the first containing valid credentials of a normal user for a benign request, it will pass the authentication just fine.  If the second request in that batch contains invalid credentials (to trick your authorization into believing it’s from a user with higher privileges for instance) for a request that could cause some damage (deleting important information or triggering certain tasks or whatever), then you can’t really do anything to prevent that.  Unless of course, you reject this approach and authenticate every single request.

As for the MySecurityException type, that’s up to you as well.  When you configure your Agatha service layer, you can set the SecurityExceptionType property to the type of exception that should be considered as a security exception.  When the Request Processor catches an exception of that type, it will set the ExceptionType property of the response to ExceptionType.Security so you can check for that specific situation in your client.

To configure Agatha to use your custom Request Processor, your configuration code would look like this:

Another alternative is to create a base Request Handler for your project and to have each Request Handler inherit from it.  Something like this, for instance:

In case you’re wondering why i’m using Setter-injection here instead of Constructor-injection, read this.

I typically prefer the custom Request Handler approach for authentication.  In most applications that we write, authentication is not enough and we need custom authorization checks for many requests.  So i’m going to need a base Request Handler which introduces the virtual Authorize method anyway.  So i might as well do my authentication check right before it.

With the custom Request Handler approach, you probably still want to configure Agatha to use your custom security exception type:

And then you just need to let your own Request Handlers inherit from your MyProjectRequestHandler.  Authentication will be performed for each request by default, and you can easily add specific authorization logic for every request. 

And those are pretty much the options you have to secure your Agatha Service Layer.   Oh, and be sure to only expose your Service Layer through SSL

Agatha is a Request/Response Service Layer framework.  It basically supports synchronous and asynchronous Request/Response style communication and tries to make it as easy as possible to write a service layer for that type of communication.  Apart from being easy to use, it also encourages a clean implementation of your service layer and a way to minimize the repetitiveness of cross-cutting concerns.  It also enables you to get better performance than with typical Remote Procedure Call or Remote Method Invocation style service layers because it will try to minimize roundtrips by batching requests and responses together.  In the next release, it will also offer a caching layer so certain requests (depending on how you set it up) don’t need to be processed and cached responses can simply be returned.  There’s also support for one-way requests (or fire-and-forget requests) but it has the same downsides as one-way requests with typical WCF services have. That’s pretty much all it does.  That’s probably all it’ll ever do.  In short, it’s just an upgrade over your typical WCF services.

NServiceBus on the other hand also does Request/Response, but that’s just one of the things it can do.  Again, Agatha is essentially an RPC or RMI framework whereas NServiceBus is built on top of one-way messaging technology.  This allows for much more possibilities when it comes to communicating between different applications or different parts or processes within the same application boundary.  A great overview of those possibilities can be found here.  Because it is based on messaging, there are a lot of benefits that you can get from NServiceBus that you’ll probably never get from Agatha.  For one, the ‘Store & Forward’ messaging model from NServiceBus might seem similar to Agatha’s one-way requests on first sight, but there are some very important differences.  If you send a fire-and-forget request with Agatha, and the service is currently down, then that request is essentially lost.  With NServiceBus, the message is stored in a message queue and it will be processed when the target of the fire-and-forget message comes up again.  From a reliability point of view, that’s obviously a tremendous improvement over what Agatha can offer you.  Another area where NServiceBus truly shines (IMO) is in its Publish/Subscribe implementation.  Some people have asked me if i’ll ever provide something like that in Agatha and the answer has always been ‘no’.   For one, it doesn’t fit into what Agatha tries to do and i don’t see the point in implementing it if a better implementation is available already in another project.   There’s plenty more interesting things in NServiceBus to deal with more advanced scenarios, which you’ll have to find out about on your own

So which one is more suitable for you or your applications? As with every technology choice, it depends.  Agatha is great for most typical business applications.  If you need to communicate between one or more different clients (with different i don’t mean multiple instances but different types of clients like a web app, a silverlight client and/or a WPF client) and one service (you can obviously use it with more than one service as well if you want to) on an application server which encapsulates your business layer then it is a very attractive solution, as long as you don’t need the superior reliability that NServiceBus can offer you.  With superior reliability i particularly mean the ability to still process received messages once the service layer comes back up after having been unavailable.  In my experience, most business applications don’t really need that, since most of those applications are entirely unusable if the service they depend on is down.  In short, if all the possible downsides of using a WCF service layer are not an issue for your project, then Agatha will be a great fit.

If however, you need to maximize reliability, performance and general robustness of a critical enterprise application, then NServiceBus will definitely be a much better choice.  If you’re dealing with many distributed parts, NServiceBus will also make things much easier for you than Agatha (or any other WCF service layer for that matter) will.   And obviously, if you want to integrate multiple applications while reducing coupling between applications as much as possible, NServiceBus will also be a much better fit than Agatha.  With NServiceBus, you’d only need to share an assembly containing the types of the messages.  With Agatha, you either need to share an assembly with shared request/response types or use proxies for them and you would also have to know about the other applications since you’d need to access their services directly.  This can get quite ugly pretty fast.

And in some cases, you can just use both of them at the same time.  At work we have two projects that use Agatha for all of their internal communication within their own application boundary, yet they use NServiceBus to notify each other of certain events.  Neither of the applications knows about the existence of the other… the only thing they share is one assembly with some shared message types.  We’ve also started working on a new platform where each application in the platform will use Agatha for all of the communication within their own application boundary (since they’re all typical silverlight clients backed by a WCF service style applications) but they will use NServiceBus for every kind of communication that goes outside of the application boundary.

As with many things, it’s just a matter of choosing the right tool for the right job.  Hopefully, this post will help some of you make that decision should you need to make it in the future

The book is divided in 3 parts.  The chapters of the first part explain in depth what kind of debugging strategy you’ll need.  Discussed topics include:

• figuring out what you’re really looking for
• tips and tricks to come up with a reliable reproduction of the bug and the value of having that reproduction
• diagnosing the actual problem
• coming up with a true fix
• reflecting on why the bug ever got into the software
• making sure that the bug can’t come back and that we learn from the mistake

For some of you, most of this stuff will just be common sense.  For a lot of developers though, this part alone should be considered required reading.  It’s a complete process of how to deal with bugs efficiently in less than 80 pages!  Think about that for a second: 80 pages that will improve your efficiency at your job and will reduce the amount of time you spend doing something you probably don’t like doing.  How could you resist?

The second part is pretty short (only 2 chapters) but pretty interesting as well.  It mostly deals with organizational patterns and practices that a development shop should take into account.  It covers things such as:

• the importance of bug tracking
• what makes a good bug report
• effective communication with users and support staff
• giving priority to bugs as soon as they’re discovered
• the importance of pragmatic zero-tolerance for bugs
• ways to get out of a Quality Hole

Not all developers will like the second part, but it definitely contains some valuable information for technical managers, or for developers who need to convince their technical managers

The third part of the book deals with a lot of various strategies for a variety of specific situations.  While not everyone will get something out of every topic discussed in this part, odds are that quite a few of them will indeed be interesting for you.  You’ll find specific advice for quite a few special cases (performance, concurrency, backwards compatibility, third-party bugs, etc…).  You’ll also find the obligatory chapter on creating an ideal debugging environment with automated tests, a build system and continuous integration.  If you’re reading this blog, you’re hopefully already convinced of the values of such things so you might want to skip this chapter.  The final 2 chapters are again very interesting… They’ll show you how you can write software that will debug itself.  While not everyone will actually go out and do this, some ideas of that chapter should definitely be kept in mind by most of us.  The final chapter deals with some common (mostly organizational) anti-patterns for dealing with bugs.

All in all, there is just a lot of tremendously valuable information in this book.  And it’s only about 190 pages so it definitely won’t take you a long time to read it.  I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur.  And i’m not just talking about bad developers.  I’ve seen plenty of good or even great developers having trouble with debugging efficiently.  This book would definitely get them on the right track, with just a little bit effort.

Some quotes that make me cringe:

The performance is acceptable now and I would consider the product generally shippable…

Acceptable? One of the originally stated goals for Visual Studio 2010 was better performance over 2008.  At this point, it should be more than acceptable IMO!

I’ve been running the SLCTP3 for about 3.5 hours today and its been amazing. Previously I would have crashed at least 2 times and had insane perf issues.

I can only hope that it runs without crashing and insane performance issues for those of us who are using it 8 hours (or more) a day…

I’d say the performance is about equal or maybe slightly better in some scenarios than VS2008.

I find this very disappointing… again, it was supposed to be faster than VS2008

VS2008 still feels snappier when compared side-by-side on the same VM, but the performance doesn’t bother me in this build of VS2010.

I’m glad it doesn’t bother Brian, but i sure as hell would prefer that the new version is at least faster and snappier than the previous version

Build time is 10-15% longer for the same solution compared to 2008

Excuse me? Build time in 2008 is already ridiculously slow for large solutions… the fact that it has gotten slower on the same hardware is simply unacceptable

Compilation of WPF project is >500% slower on VS 2010 SLCTP 3

Wow… just wow

Intellisense pop-ups are slow to pop up

It’s not like we need those to be fast, right?

For those of you who think i’m making a big deal out of this, you might be right.  But i’m often working with large solutions and i frequently have multiple instances of VS running at the same time.  The performance of VS2008 is at times embarrassingly bad and to think that VS2010 is not going to improve this, and likely even make the situation worse is something that i can’t really be happy about. 

Can’t we just get a Visual Studio 2008 Service Pack with support for .NET 4.0 instead?

1. it is a mindset
2. it is a community
3. there is a movement

The ALT.NET mindset was originally described perfectly by Dave Laribee:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

This mindset still lives on, and will always stay alive. There will always be .NET developers that are continuously looking for better ways to create software.  We might not think there are enough of them, but they are still growing gradually.  Typical ALT.NET topics, practices and principles have become much more popular and more and more people are definitely still looking to learn about them.  I can’t think of a single reason why this would ever cease to happen.

As a community, ALT.NET hasn’t done a good job (IMO) of being accessible to new-comers.  I’ve complained about this in August 2008.  Nothing changed after that post, and nothing will change after this post either.  A lot of the people in the ALT.NET community are still too negative in expressing their views, or have even stopped trying altogether.  Some of them just attacked everyone who disagreed with them.  Things like that will obviously never, ever lead to adoption of your thoughts and ideas.  And after that, they’d complain that nobody was listening anyway and that they were tired of trying to discuss these things with people who didn’t believe in it yet. It also doesn’t help that quite a few people got involved purely for the sake of bettering themselves.  After all, the ALT.NET name was hot and being associated with it and getting involved with it was an easy way to improve your reputation, status and for some even their finances.

As a movement, we’ve failed as well.  Essentially, the ALT.NET movement is about education.  Teaching people the things we believe in.  Showing them that there are better ways to develop software than that what is more accepted in the Microsoft world.  In the early stages of the movement, there was a tremendous amount of interesting blog posts being written with exactly that purpose in mind.  Teaching people.  Showing them the benefits.  Explaining things to them.   After a while though, some of those bloggers didn’t quite put the same effort into it anymore.  A lot of them resorted to one-liners about why approach A is better than approach B and they weren’t really taking the time anymore to try to educate people.  The rise of Twitter certainly didn’t help either since you simply can’t teach this stuff to people through 140-character tweets.  You can’t really show them the benefit of whatever it is that you think is a good thing to do.  And since a lot of those bloggers are spending more of their time on Twitter than on working on their blogs nowadays, a lot of valuable knowledge and experience isn’t being spread as much anymore as it used to.  Now obviously, we can’t tell people how to spend their time so if those people prefer to spend time on Twitter instead of writing good posts that could help more people, that is their personal choice and nobody can blame them for that.   At the same time, they can’t really complain about the current state of ALT.NET as a movement and a community either.

But hey, the mindset still lives and will continue on living.  The best thing you can do is to share your knowledge and experience with as many people that want to hear it.  And trust me, there are quite a few people who want to hear it. 

As you probably know by now, i’m a big proponent of using IOC containers.  I’ve never stated that they should be used in every single application, but using one certainly pays off in most applications, especially as complexity increases gradually.  When you use an IOC container, you’ll have much less need for factories.   There are however two situations where i certainly prefer to use a factory.  And that is when:

1. a certain dependency might not always be used by a class and that dependency is expensive to create
2. i might need multiple instances of a dependency during the lifetime of a class

A good example of both those situations is when using Agatha’s AsyncRequestDispatcher class from a Silverlight user control.  Creating an AsyncRequestDispatcher is expensive because it in turn requires an instance of the AsyncRequestProcessorProxy class.  The AsyncRequestProcessorProxy class inherits from WCF’s ClientBase class, and those types are relatively expensive to create.   And due to the asynchronous nature of those service calls, you can never deterministically dispose of a AsyncRequestDispatcher instance with absolute certainty that it won’t be disposed before the response of the service call is returned from the service.  Because of that, the AsyncRequestDispatcher class was designed to dispose of itself automatically once the response is returned.  This effectively means that you’ll need a new instance of AsyncRequestDispatcher whenever you need to make an asynchronous call to an Agatha service. 

For most user controls, it obviously doesn’t make sense to inject one instance of the AsyncRequestDispatcher into the user control because you often need to make multiple service calls depending on user interactions or other events.   A good way to deal with this is obviously to ask a factory to create the AsyncRequestDispatcher whenever you need one.   Which is why Agatha offers the AsyncRequestDispatcherFactory class, which looks like this:

Now, some of you are probably thinking: what is the difference between this and Uncle Bob’s example?  Well, unlike Uncle Bob’s example this factory is not responsible for registering the required components to create an AsyncRequestDispatcher with the container.  It merely resolves an instance and returns it.  And yes, it uses the container to do so.   I could actually just new up an AsyncRequestDispatcher myself but then the factory would also have to know about its dependencies and make sure it’d be able to create them.  If those dependencies have dependencies of their own, i’m back to dealing with dependencies manually which is exactly what i’m trying to avoid throughout my codebase.

I can’t come up with a single reason why this would be wrong, but some of you probably will so feel free to point out those reasons

The benefit of this factory is that it enables me to delay the instantiation of an expensive dependency, and it also enables me to get more than one instance if i need to during the lifetime of a single object.  At the same time, it doesn’t have any of the downsides of Uncle Bob’s approach.  Also, this approach is something that you won’t need to resort to throughout your codebase, it’s more for edge-cases.

Now, how do we use this factory?  Instead of new’ing the factory manually like Jeffrey does in his example, the factory is registered with the IOC container and i simply inject the factory into the class that needs to use it.  This still enables me to change implementations of both the factory as well as the instances the factory needs to create.  And it also makes it easy to stub or mock the factory during tests.  I get all of the benefits from using Dependency Injection and an IOC container, and i have yet to notice any downsides to this approach.  But again, i only use this approach in the 2 situations i mentioned in the beginning of this post.  In most cases, you really don’t need factories anymore.  And when you do, just leverage your IOC container to make the factory as simple and dumb as possible.