Sorry, but you’re just talking.

Where’s the code ?

I mean you seem to have all the time in the world to just say things on your blog , but no time to put together a simple sample up.

I seriously doubt you understand what you talk about.

As you can probably tell from my reaction, i got pretty pissed off. Normally, i don’t let comments like that get to me. But in this case, i have been spending quite a bit of my personal time working on a sample and preparing the blog posts. I’m actually planning to spend quite a bit of my weekend on this (as i did last weekend), not to mention that i’m also gonna spend a couple of hours working on it during my day off tomorrow.

I’m not getting paid for any of this. In fact, i’m only getting shit for doing this. The handful of people who are looking at this because they’re tired of the MSDN-way of developing things will appreciate it, but the vast majority of people who’re gonna read it are going to complain because “it’s too complicated!” or “i have to think too much!”. Well, you know what? You’re not the kind of developer i’m targeting anyway. If you stumble upon a post of mine about Silverlight or anything else that’s hot in MSDN-land, you probably got here through a link-blog or a link on twitter. And in those cases, odds are pretty high that the way i think about software development and the way you think about it don’t exactly match. And that’s ok. I’ll do what i wanna do in the way i feel it’s right to do so, and i suggest you do the same. But pressuring me into backing up the stuff i say with code is not really gonna get you anything sooner. I’m still gonna do whatever it is that i’m gonna do in a time frame that suits me, not you.

And to top it all off, i just got the following reply from the same guy:

“I’ll just say this.

When you make a public statement , you better have some code ready to prove it.”

Priceless, ain’t it?

But there are some things you need to watch out for in any organization which takes estimates seriously. Most development shops have estimates at the task-level. These task-level estimates are often used during the planning of the next iteration, but were most likely also used in the initial total estimate of the project. I certainly don’t doubt the importance of those task-level estimates, but i do think they should be used cautiously.

If too much importance is placed on staying below the estimates, or at least not going over them, you run the risk of growing a culture where developers let the estimates have too much influence on the quality of the work they’re doing. Some developers will strive hard to routinely stay below the estimates. Some developers will work in fear of going over the estimate. In both cases, it leads to technical shortcuts that will be taken. Those shortcuts will consist of skipping some tests here and there, skipping a bunch of tests altogether, decreasing willingness to refactor code that could use it and worst of all, no longer keeping a clean design in mind. Granted, i’m painting a very bleak picture here but it does happen with some people and the negative results can not be underestimated.

Let’s consider the overall effect of these shortcuts. A shortcut here or there is not abnormal in some circumstances, but it should be exceptional. It should not become routine, it should be frowned upon and i’d even go as far as recommending a “no shortcuts allowed unless the team approves of it” policy. A shortcut here or there doesn’t take a lot of effort to fix and because of this, it can often be done as soon as the original reason of the existence of the shortcut (typically: a deadline) is no longer an issue. An accumulation of shortcuts however leads to not only an obviously bigger workload to fix all of the shortcuts, but it also impacts a lot of other code that shouldn’t have been impacted in the first place. Once this happens, you’ve got yourself an unhealthy code base and it’s only going to get worse until it eventually dies at a younger age than it could have reached.

Now, imagine a culture where estimates are given as much importance as quality. If you’re approaching the estimate and you’ve still got a lot of work left to fully complete the task (and with fully completed, i really don’t mean watching it work on your machine as you manually test it), then you consult with the rest of your team members. Estimate how much time it would take to fully complete the task, and see if the increased time over the original estimate is doable. If you’re already behind your overall schedule, it’s probably not doable unless there are many subsequent tasks that are dependent on this particular task. But if you’re ahead of schedule, you’re probably better off accepting the fact that you’re going to go over this task’s original estimate in order to do it right. If you do so, the extra hours you spent on this task should (in most cases at least) not lead to extra hours on future tasks. Conversely, if you’ve finished a task well below the estimate, it might actually be a good investment to refactor some ‘bad’ code that you’ve come across while working on your task. Or to add some missing tests here or there. That certainly doesn’t mean that you need to spend all the available remaining time you have but you shouldn’t run to start on a new task as soon as humanly possible either. Follow the boy scout rule here… you won’t spend that much extra time on it, but overall quality can improve greatly from this.

In fact, i’d even bet that the time it takes to do it right will in a large majority of cases still be less than the sum of the original time that was spent on a task hastily done and the time that will be spent on bugs that resulted from that hastily done task, not to mention the impact it could have on the development of future tasks simply because of the suboptimal implementation of the hastily done task.

Finally, it’s also important to think about why there was a need to go over an estimate. There can be a variety of reasons for this, and one of them is that the task was simply badly estimated. If that indeed turns out to be the case, make sure that you learn from it to prevent this from happening in the future. When we find bugs in our code, we try to prevent those bugs from ever occurring again. We should have a similar attitude to our estimating practices as well. If an estimate was simply too low, make sure that a similar task in the future won’t be estimated too low again or you will again introduce a possible problem in your (future) project.

And that, in my opinion, is also a good reason to decide to go over the estimate if you can. If you go over the estimate and all people involved learn from the bad estimate, then everyone basically benefits from it. Future estimates should become more accurate, and no code was harmed in the process. You might have lost some money on it, but at least you only lost it once instead of losing it over and over again in similar future circumstances.

And i cringed. Personally, i think it’s weird to read lines of code that say view.ShowPanelWindow(false) or view.ShowBusy(false).  Instead, i’d go for something like this:

Sure, i’m not gonna win the fewest-lines-of-code contest but then again, we’re not participating in that contest anyway.  And while my version is a little bit longer, it doesn’t take more than a few extra seconds to write that extra code, and the improved readability of the consuming code is more than worth it.  After all, you do prefer reading view.HidePanelWindow() over view.ShowPanelWindow(false), no?

I’ve always liked the following approach to avoid (or at least, mimimize) bad method names.  Just pretend that the classes are people and that the method names are messages between them.  There is after all a reason why we referred to it as “sending a message to an object” originally in OO-terms.  Give it a shot, and you’ll notice that your code will become more readable with hardly any extra effort.

First, let’s briefly cover what MVVM is about for those of you who don’t know yet. MVVM virtually eliminates all of the code that would typically be placed in the code-behind file of your View (a user control, a screen, whatever) by putting all of that logic in the ViewModel. The ViewModel itself is never tightly coupled to the View. If it does have a reference to it, it’s typically through an interface that the View implements instead of a reference of the actual type of the View. This increases, or better yet, introduces testability to a large part of your UI code that you normally wouldn’t be able to cover with unit tests if you’d go with the traditional “put it all in the code-behind”-approach.

The ViewModel typically contains properties for the data that is to be shown in the View, and also raises notification events when the data in those properties changes. The View uses the powerful data-binding capabilities of Silverlight/WPF to bind the properties of the ViewModel to other user controls that the View is composed of. User-events that are captured by the View are sent to the ViewModel through Commands. Typically, these commands execute a method in the ViewModel which contains some kind of logic… usually to either send the updated data in the ViewModel’s properties to the Model (usually a Service Layer in Silverlight, in WPF it could be either a true Domain Model or also a Service Layer), to perform some business logic in the Model, or to retrieve data from the Model so it can be placed in the ViewModel’s properties so the View can bind to it.

That is, in a nutshell, how the MVVM pattern works. So why do i have issues with this? You can develop and test most of the application’s logic without being dependent on a physical View and that is typically a Good Thing, no? It sure is! However, my problem with this approach is that too many responsibilities are concentrated within the ViewModel. Its main responsibilities are to facilitate databinding and to interact with the Model. And that, in my opinion, isn’t very clean. In some ways, you could actually think of the ViewModel as a glorified code-behind, with the only difference being that it’s not tightly coupled to the (physical) View.

In most (if not all) MVVM implementations, a ViewModel has many possible reasons to be changed. It might need to be changed because of different data-binding requirements. Then again, it might also require changes when a part of the Model is modified. Now, i’m sure many of you can agree with me when i say that two of the most important principles in software development are Seperation of Concerns (SoC) and the Single Responsibility Principle (SRP). Obviously, the ViewModel doesn’t fare well when it comes to both of these principles.

Lets forget about MVVM for a second and focus on the concerns and responsibilities that a user control can have… say, a user control that shows customer information and allows the user to edit that data so it can be persisted:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• communication/interaction with the Model
• making data (from the Model) available so it can be displayed
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc…)

Without MVVM, all of these would be taken care of in the View. Obviously, not a good idea right? After all, if it were a good idea, we’d never have had a reason to start using MVVM in the first place.

Now, with MVVM, a lot of people would divide these concerns and responsibilities like this:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc…)

ViewModel:

• communication/interaction with the Model
• making data (from the Model) available so it can be displayed

In this case, the View still has 3 responsibilities which is still too much according to ‘the guidelines’, but it’s not that big of a deal (though plenty of people would argue that the simple validation would be better placed in the ViewModel). You’re highly unlikely to actually want to write automated tests for pure visualization anyway and the SRP is not something that you absolutely need to follow to the extreme in every single place. For the View, this is really not a problem and very much acceptable.

The ViewModel however has 2 important responsibilities in this case, and i’d argue that these 2 things should not be done in the same place. Making data available is done through data-binding. To do this, you need a set of properties and you need to raise the necessary events. In most cases, raising those events is very straightforward, but in more complex controls you might need a bit of additional logic to determine which event should be raised at what point. The other important responsibility is the communication/interaction with the Model. In most Silverlight applications, the Model will be a Service Layer. To communicate with this Service Layer, you need Service Proxies. That means that your ViewModel is essentially responsible for communicating with the Service Layer, dealing with business exceptions that might be thrown by some service calls, and dealing with technical exceptions that can occur simply because of network-related problems. Group all of those together and i don’t think i’m going out on a limb here by saying that that is a lot of logic to put in one class, no?

(Sidenote: what i don’t really understand is that many people who vigorously advocate adherence to SRP and SoC in their domain and business code don’t seem to hold their UI code to the same standards. I do.)

At work, we do a lot of Silverlight development. We typically have around 5 Silverlight projects in active development at the same time. And it’s been that way for over a year now. That equals a lot of Silverlight code that we’ve written and experience and knowledge that we’ve built up. And we haven’t used MVVM for any of it. All this time, we’ve been using the MVP pattern (Supervising Controller variant) with a slight twist. That twist being a slimmed down version of a Presentation Model. Our Presentation Model’s sole responsibility is to facilitate data-binding, and in some cases, a touch of validation is added as well.

If we go back to our previous example of the customer screen, the responsibilities and concerns would be divided like this in our MVP-PMlight approach:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc…)

Presenter:

• communication/interaction with the Model based on the contents of the Presentation Model

Presentation Model:

• making data (from the Model) available so it can be displayed

Which leads to classes which are more focused on their task instead of trying to focus on too many things at the same time. In my opinion, this approach is much better/cleaner than MVVM. Not only is there a noticeable benefit in code quality (classes are more focused), there is also increased potential to reuse our ‘light Presentation Models’ in multiple controls. Testability is increased over MVVM as well since it’s always easier to test classes which are focused versus testing classes which have too many responsibilities. All in all, a couple of important benefits and we still haven’t thought of a real drawback compared to MVVM.

A few years ago, i worked at a large financial institution in Belgium where we developed software for internal use in the main offices. The UI was pretty much always done in Dutch, but most of the time we wrote all of our code in English. There were a few projects where the developers had used Dutch in their code though. At first, this wasn’t an issue and seemed to be more of a personal preference thing (though mixing within a project is just horrible). After a while, the company got involved in the outsourcing game and suddenly, they were sending a lot of the projects that were in maintenance to a group of Indian developers. It’s hard enough to get developers who use a different language and are part of a different culture on the same page when working on software, but it’s obviously even harder if the code they are supposed to read, maintain and extend is in a language they don’t even know.

At my current job, we also have a branch in Hungary. We often mix teams so naturally, we all write our code in English. We not only write our code in English, but we also use English as our language in any kind of documentation. Now, we do have one customer who insists that the functional designs are all done in Dutch. Maintaining 2 sets of documents is something that we won’t do, and since our development process requires developers to link our code to our functional designs, we’ll never be able to use our Hungarian developers on the projects that we do for this customer. To me, that is a huge downside to having to write the documents in Dutch. And it’s the exact same problem we’d have if we would write our code in Dutch.

Both those examples should tell you why i’m so much in favor of just writing code in English all the time. Generally speaking, if you pick a non-English language to code in, you are limiting the pool of possible future developers to those developers who know the language you’ve chosen. It’s that simple. The more people who know the language, the bigger the pool of future developers. And when it comes to languages that aren’t used by a lot of people… well, that’s a pretty big restriction on your future options.

Another downside to using non-English in your code, is that you’re effectively already mixing multiple languages in the code base. Your programming language already is in English, and using non-English in your code leads to something that just sounds (or reads, i guess) wrong.

The biggest problem that people bring up with always using English, is that you obviously need to translate business concepts. Especially for people who are doing DDD and who want to leverage the Ubiquitous Language, this isn’t always an easy decision to make. For one, your domain experts might not be willing to take on the translation burden. If they are unwilling to do so, you can still use a translated version of the Ubiquitous Language but then the entire team (except for the domain experts) has to deal with that burden on a daily basis.

Now, i’m not sure if that’s really that big of a problem. For starters, English terms are becoming more pervasive in ‘business language’ every day. I’m not saying that everyone is already using English for their business concepts/terms, but i would argue that it is increasing, that it’s only going to increase more and more and most importantly, that more and more business people don’t really have a problem with using English terms anymore.

And lets not forget that the percentage of teams that is truly doing DDD and leveraging the Ubiquitous Language is probably still small. After all, most true DDD experts will say that DDD is only a good idea for 10% of all projects , so i can’t help but wonder how big of an issue the translation burden really is.

Thoughts?

Suppose you’ve got something like this:

The idea was to write the EntityBuilder somewhat along these lines:

Of course, that doesn’t even compile… you’ll get the following compiler errors:

error CS0266: Cannot implicitly convert type ‘MyProject.IntIdGenerator’ to ‘MyProject.IIdGenerator<TId>’. An explicit conversion exists (are you missing a cast?)
error CS0266: Cannot implicitly convert type ‘MyProject.GuidIdGenerator’ to ‘MyProject.IIdGenerator<TId>’. An explicit conversion exists (are you missing a cast?)

So, how exactly do you get this working with generics? That’s when he asked for my help, and i didn’t know the answer either… i’ve struggled with this exact problem in a few previous situations and i never really got a clean solution either.  But then i thought “wait, can’t we just avoid the problems with generics through the dynamic keyword?”

We changed the code to look like this:

We just changed the return type of the GetIdGeneratorFor method to ‘dynamic’, and the call to the GenerateId method is now a dynamic call instead of a normal method call.  And it works.  No messing around with generics voodoo, no (direct) usage of reflection either.  Just clean code.

I’ll probably use this trick a lot more times in the future when i run into the limitations of generics

So… any tips from you twitter addicts on how to keep the signal-to-noise ratio down and how to make the whole experience as valuable as possible?

Top 10 All Time:

1. Career Advice For Young Developers
2. At This Point, I’d Prefer Java Developers Over .NET Developers
3. NHibernate Mapping Examples (pretty outdated by now though)
4. Build Your Own Data Access Layer Series
5. Upgrading To NHibernate 2.1 (this is what happens when people are too lazy to read exception messages)
6. A Reading Guide To Becoming A Better Developer
7. Data Access Layer With NHibernate
8. Managing Your NHibernate Sessions
9. Sending NHibernate Entities Over The WCF Wire (i wish i never wrote this)
10. Request Response Service Layer Series

Top 10 Of The Last 100:

1. Why You Shouldn’t Expose Your Entities Through Your Services
2. Using NHibernate In Your Service Layer
3. Hey Microsoft, Our Databases Aren’t Services!
4. Unit Testing An NHibernate Application
5. Avoiding Leaking Connections With NHibernate And TransactionScope
6. Agatha Vs NServiceBus
7. Do You Know What’s Really Going On?
8. Dependency Injection Inversion Rejection
9. Real World Benefits From Loose Coupling, Inversion Of Control And Dependency Injection
10.  Virtual Method Performance Penalty

So… on to the next 100 i guess

It no longer runs inherited tests.  Which is especially annoying to us because we use inherited tests to make sure that our NHibernate CRUD operations work.  We also use the inherited tests pattern for some other things, but that means we’re pretty much screwed now.

The bug has already been reported but since they closed the Early Access Program due to the release of 5.1, i guess we’re gonna have to wait quite a while before we can get our hands on a version that has a usable test runner.

If anyone from the Resharper team reads this: please tell me how on earth something like this could break in a bugfix release?  You sell software for continuous integration, for code coverage, for running tests.  If you’d actually use these things and wrote correct tests then this wouldn’t have happened…

Well, time for another short vacation. I’ll be chilling and hanging out at the Côte d’Azur next week. I will have internet access but i’ll probably make very little use of it. So, emails probably won’t be replied to until July 13th and obviously, there won’t be any posts either

See you in a week!

The announcement of the first release can be found here, and an example can be found here.  Here’s a little glimpse at the code of one the examples:

I think that piece of code is a nice illustration of how powerful and flexible this is

There’s nothing wrong with putting in a few extra hours occasionally. Sometimes, it just needs to be done. But, as soon as it is required more than occasionally (and with occasionally, i mean every couple of months), something is wrong. First of all, you’re not gonna produce anything good if you’re doing a lot of overtime. At first, it starts with a couple of late nights. The first couple of nights, the work you do is still ‘good enough’. It’s not gonna be great, but hey, it’ll do. After a couple of nights though, if you’re still doing a lot of extra hours, there’s gonna be a noticeable negative effect on the work you’re doing. And you know what the worst part is? You, of all people, won’t notice it. You’re working hard, you’re trying to catch up with the schedule, and you’re doing the best you can. Or at least, you think you are.

In reality, you are hurting yourself, the project and your teammates more than you could imagine at that time. Here’s the deal: there’s a reason why most people are working 8 hours a day on average. If you routinely work more than 8 hours a day, your work is going to suffer from it (it depends on the job obviously, but for software developers, i’d argue that this is definitely the case). If you do a bit of overtime occasionally, then you, nor the project will suffer from it. It’ll just take a little bit more out of you than what you’re used to. But once it becomes a routine, you, as a human being, will start performing worse and worse as time goes on. Inevitably, that deterioration will become very noticeable in your work. And here’s the sad thing: you’re putting in the extra effort to catch up with the schedule. But by doing so, you’re actually performing worse and you’re hurting the schedule. Here’s what happens: you spend a few late nights at the office. At first, things go ok. You’re getting things done and it appears to be working. You keep spending late nights at the office. After a few days (really, it happens that fast), the quality of your work starts deteriorating. And you won’t notice it until you get back the next day. So then what happens? You start cleaning up the mess you made the night before. Which only means you’re getting even more behind schedule. So then you’ll need even more time to catch up with the schedule. But you’re already spending this much extra time at work, and the problem only seems to get worse! Well, yeah… that’s the whole point that i’m trying to make here. You know what’s the best thing you could possibly do in those situations? Go home at 3 or 4 in the afternoon, go have some fun, relax, and get a good night’s sleep. You won’t believe how much more productive you’ll be the next day.

But where is this need to do overtime coming from? I’d argue that, in the large majority of cases, this is due to management mistakes. Either the wrong things were promised to the customer, or your management doesn’t have a clue of what is really going on. So, if you find yourself in a position where you routinely need to do overtime, you really need to start asking yourself whether or not you’re working for the right company. If you routinely need to do overtime to reach a deadline, that tells you that the project management (and highly likely, every kind of management beyond that) is pretty messed up. I don’t know about you, but i really don’t want to work for people who don’t know what they’re doing. If you’re doing a lot of overtime, your management is either clueless or stupid. Probably a combination of both.

As for the developers who are proud of their 60-80 hour work weeks… what does that tell you about them? There truly are very few people who can keep on producing great results beyond the regular 40 hours a week. Something tells me that very few of those developers who brag about their extra hours really fit into that category. If they really did fit into that category, they’d let their results speak for themselves instead of needing to brag about the amount of effort they’re putting in.

So why did it work for him, yet failed in my situation? The answer turns out to be quite simple.  If you look at the Tuple type of .NET 4 in Reflector, you’ll see this:

So it actually is serializable.  The thing is, my client is not a .NET project, it’s Silverlight.  And the Tuple type in Silverlight looks like this:

Silverlight still doesn’t support the Serializable attribute and the Tuple types don’t have a parameterless constructor, so that’s why it can’t deserialize a Tuple instance when it’s returned from a WCF call.  I can’t believe i didn’t think of this earlier since i’ve been bitten by this problem a few more times (not with the Tuple type, but with other Serializable classes) in the past, but then again, i can’t believe something like this still doesn’t work when using .NET 4, Silverlight 4 and WCF 4 together.

Type ‘System.Tuple`2[System.Guid,System.Nullable`1[System.Guid]]’ cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. Alternatively, you can ensure that the type is public and has a parameterless constructor – all public members of the type will then be serialized, and no attributes will be required.

That’s all… now if you’ll excuse me, i gotta go include a useless DTO in my project.

System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. —> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn’t have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers.

I checked my MSDTC security settings to make sure that everything was still configured correctly, and it was. I then checked to see if Windows Firewall is still disabled, and it was. Then i remembered that i’ve had problems with MSDTC transactions failing after Microsoft Security Essentials (MSE) had installed updates. Again, when that happens i typically just reboot and everything works again.  Just for the hell of it, i turned off MSE’s real-time protection and tried again.  And it worked without problems. I turned the real-time protection back on to see if it would fail again but it kept working. I have no idea what the problem is, but at least i’m now armed with yet another thing to try when MSDTC stops working on my machine.  Gotta love options!

Seriously though, with all the problems i (and others) have run into with using MSDTC, i’m starting to wonder if Microsoft has some kind of covert Make-MSDTC-Usage-As-Painful-As-Possible mission going on somewhere…  Then again, maybe their QA is just getting even worse than it already was.  Oh well…

There are only two things you need to do to use Agatha’s server-side caching feature:

1. Use the EnableResponseCaching attribute

If you want certain Request-derived types to be eligible for caching, you need to put the EnableResponseCaching attribute on top of them.  This attribute enables you to set the logical region (more on that later) where the Response for this Request needs to stored in the cache, and it requires you to set an expiration.  Here’s a simple example:

For this particular request type, responses should be cached for a maximum duration of 10 minutes, and the cached responses will be stored in the Issues region.  A region is pretty much just a section within the cache.  If you don’t specify a region, each response will be placed in the default region.  If you do specify one, each cached response for that region is placed within that section.  This gives you the ability to clear an entire region (and thus, all the cached responses that are stored in that region) without impacting any of the other regions (including the default one).

The expiration can be configured by providing a number of hours, minutes or seconds (or a combination of those three) to the attribute.

Now obviously, Agatha needs a way to differentiate between multiple instances of the GetUnassignedIssuesForProjectRequest class.  More specifically, Agatha needs to know when a request can be considered equal to a previous request for which a response has already been cached.  So that brings us to the next thing you need to do:

2. Override the Equals and GetHashCode methods

The response for a GetUnassignedIssuesForProjectRequest instance with ProjectId set to e35c60f7-c35e-43db-9988-0dab3f39c61b will obviously contain a different set of unassigned issues than one for a GetUnassignedIssuesForProjectRequest with ProjectId set to 5d47161a-f334-4cce-9cc4-9606a9d294a6.  To make sure that Agatha knows which response can be returned for a given request, your request needs to override the Equals and GetHashCode methods so you can tell Agatha when an instance of a certain request can be considered equal to one for which a cached response already exists.  In the case of our example, requests of type GetUnassignedIssuesForProjectRequest can be considered equal if they both return the same value through their ProjectId property.  So in this case, our request class needs to look like this:

Now that we have an Equals and a GetHashCode method which only looks at the value of the ProjectId property, Agatha can differentiate between different requests on a value basis instead of a reference basis.  Note that this doesn’t mean that your request types need to be value objects in the truest sense of the term.  They just need to be able to perform an equality check based on the values that make the difference between actually handling the request, or returning the response that has previously been cached for the set of values that you’re using to determine equality.  Simply overriding the Equals method is not enough, since Agatha will use these instances of requests as keys in a dictionary so you need to provide a proper GetHashCode implementation as well (which is recommended anyway if you’re overriding the Equals method).

It’s very important to really consider which properties you want to include in the equality check and the hashcode calculation.  If your request type inherits from some base request (typically one that contains user credentials and stuff like that), then you typically don’t want to include those inherited property values in your equality check, unless you really want to cache different responses based on one of those inherited properties.  I’d recommend writing enough tests to verify that your equality checks and hashcode calculations indeed behave the way you want them to because if they don’t, you will either get suboptimal results from Agatha’s caching or even incorrect ones which would lead to bugs that will be very hard to debug.

A question that came up recently in the Agatha discussion group was how to implement the Equals and GetHashCode method for request types for which each instance should really be considered equal.  For instance, a request type like this:

In this case, the default Equals and GetHashCode implementations will be reference-based and not value based.  But as you can see, there are no values to differentiate between requests.  In this case, there is only one way to retrieve the known Countries in this system, so how do we implement the Equals and GetHashCode methods so this request type can be used correctly with Agatha’s caching layer?  Well, the solution isn’t very nice but it is pretty simple.  You can just introduce a dummy field with a fixed value:

Now, every instance of the GetAllCountriesRequest will be considered equal to each other and they’ll all return the same hashcode as well.  So every incoming instance of this request will return the same cached response (once it’s been cached that is).

That’s pretty much it.  In itself, the caching layer of Agatha is very easy to use, but you definitely need to make sure that your Equals and GetHashCode implementations are correct.  That’s pretty much the only tricky part (and downside) to how Agatha’s caching works, but i was unfortunately unable to come up with something that was easier to use.

One final word on the usage of regions.  If you’re caching responses, then you typically want a way to remove stale responses from the cache.  If some of the data that you’re caching is changed before the cached responses expire, you can clear the region in which those cached responses are being stored.  Just add an ICacheManager constructor parameter to your handler (or any other class for that matter) and call the Clear method which takes a region name as a parameter.

As always with caching: be careful in how you use it, and make sure you think it through

And indeed, if you browse the web to find the reason why application pools are configured to recycle automatically periodically, you’ll be hard pressed to find a reasonable answer that doesn’t pertain to memory issues.  It’s like the community in general has pretty much accepted the fact that our web applications (or service layers hosted in IIS) will need to be recycled to avoid memory problems.  To make things worse, i’ve frequently seen people discuss workarounds on how to keep things working properly after an application pool recycle in mailinglists for various projects.  And again i ask myself: why?

I’ve always been of the opinion that if your code requires periodic restarts to keep working correctly, then something is clearly wrong.  There is a bug in your code somewhere and you need to fix that, instead of restarting the process occasionally to make the problem ‘go away’.  Guess what, it’s not going away, and if the load on your application increases, the problem will only pop up more frequently.  So what are you going to do about that? Make the application pool recycle even more frequently?  Put in another server to share the load?  Perhaps we should focus more on fixing the actual code.  You’re leaking resources somewhere, and that is what you need to fix.

In my company, it’s just standard procedure to disable application pool recycling on all application pools.  Our applications simply have to keep working without application pool recycles.  It’s that simple.  If we run into a memory leak that causes problems, we focus on the actual problem and we fix it.  We’ve ran into plenty of memory leaks (though it hasn’t really happened a lot in the past year, guess why?) and we’ve fixed each and every single one of them that we’ve ran into.  Side note: i’m talking about .NET code that is running on the server.  While i’m pretty sure that we do better at memory management in our Silverlight clients than most other Silverlight-using-shops do, you just never know for sure with Silverlight, partly because there are so many memory leaks in Silveright itself.  But for .NET code running on a server, a memory leak is simply inexcusable in my opinion.  I mean, it can happen to the best of us (i’m pretty much responsible for most of ours to be honest), but it’s not about who introduced the memory leak.  It’s all about how you deal with it.  And recycling the application pool periodically is not dealing with it, it’s living in denial.

The only viable reason to recycle application pools that i can think of is in the situation of a shared hosting provider.  If you’re offering shared hosting, it only makes sense to recycle application pools occasionally since it’s quite realistic to assume that most of those application pools will not be in use constantly.  If a pool is recycled, it will not consume any resources until the next request for an application in that pool is received.  In the context of shared hosting, that actually makes sense.  In the context of real applications, that makes little sense unless you’re hosting a lot of them and plenty of them are hardly being used.  Still, is that really a good enough reason to enabling application pool recycling by default?  I obviously don’t think so.

In my opinion, we, as a community, really need to start focusing more on memory management in .NET and on making sure that our applications can keep running without problems.

I have a very simple rule when it comes to avoiding hype: if you can’t say something bad about it, you don’t know it well enough (yet).  And until you are able to say something bad about a library, framework, approach, technology, tool or whatever, i simply can’t believe all of the good things you’re saying about it without some form of skepticism.  In life, nothing is perfect.  In software development even less so.  Every single piece of technology or approach has its drawbacks, issues and problems.  And quite often, those things only become noticeable after having truly used it on a real project for a while.  I think most of us will be able to agree on that.  So really, what does that tell you about someone when that person is extremely positive about something, without being able to mention any downside?  That either tells me that you don’t know what you’re talking about or that you’re not even using whatever it is that you’re hyping on something real (hobby projects don’t really count).  So does it really make sense for one to listen to it?  Conversely, if you are very positive about something but are also able to mention the negative points that you’ve encountered (they don’t have to be huge, and can in fact even be minor) then i’m immediately much more inclined to believe what you’re saying. 

Granted, my approach frequently prevents me from being an early adopter.  But if/when i do become an adopter, i will be a pretty informed one.  In many cases i’ll know about the negatives before they bite me, and will either guard myself against them, work around them if i have no other alternative or simply choose to ignore the technology altogether if the positives don’t outweigh the negatives.  The only downside that i’ve experienced so far from this approach is that i’ll never be one of the cool kids on the internet and among the hype-hungry developers.  Then again, that’s probably more of an upside than a downside, come to think of it

Looking back over the past 5 years or so, i can say that i was late in adopting unit testing, agile development, Inversion Of Control, Dependency Injection, ORM, and probably a bunch of other things that i can’t really think of right now.  But i’m pretty sure that i know all of those things pretty well by now.  A large reason for that (i think) is because i took my time and made sure that i made informed decisions before adopting something.  I experimented, thought about drawbacks, tried it in real projects, learned from mistakes that i made, worked around problems that were inherent with the piece of technology or approach in question and only then did i consider myself able to make informed statements about it.  That doesn’t mean you can’t talk about something that you don’t know fully yet.  A lot of very valuable blog posts are written by a lot of people who are learning things or are just experimenting with things.  The smart ones among them though, will be very honest about how much they know about it, how much they don’t know about it, and how far they are in the learning progress.

So, as Public Enemy said: don’t believe the hype!

Get informed instead.

I can only speak from my own experience, but i frequently isolate myself from my coworkers and my surroundings by turning on my iPod and listening to some music while i work.  I don’t do it all the time, and it definitely depends on what i’m working on, or who i’m working with.  Obviously, if you’re doing pair programming then listening to your iPod is pretty much out of the question.  But if you’re all sitting together, do we really need to avoid any kind of isolation?  When i’m working on something complex, and i don’t really need to communicate with my teammates at that time, then there really isn’t anything wrong with listening to some music and getting some work done.  In fact, it often helps me focus on my work without getting easily distracted, helps me get into a good zone, and it would certainly surprise me if i were the only one who thought that way.  If you or some of your teammembers actually produce better results while they tune into their music, then this can’t really be an inherently bad thing, no?

But obviously, there will be many situations where you actually want to avoid listening to music.  Sometimes you might be working on something that requires you to consult with teammates frequently, whether it is about design decisions or to ask some feedback on implications of certain implementation details.  In those cases, you can end up pausing and resuming your iPod way too frequently so it might just be better to refrain from turning it on altogether.  Or when you notice that teammates are discussing something and it’s taking them a bit too long.  It’s hard to tell when a discussion is too long if you’re not hearing what they’re saying but when i notice 2 developers talking for more then a couple of minutes, i’ll often pause the iPod to check out what they’re talking about.  Maybe you can help by offering a different perspective or maybe you know an immediate answer to the question that they’re discussing.  If you can’t help, go ahead and press Play again.

The thing is… even if you do tune into some music at work, it’s important not to tune out of your coworkers completely.  Go ahead and listen to your music, but keep looking around occasionally.  Turn it off when you notice your teammates are talking and follow the discussion to see if it’s interesting to you or if you can help them.  Conversely, if you’re participating in a discussion and you notice that one or more of your teammates is listening to music while they should probably be involved or at least hear what the conclusion or decision was, go ahead and notify them of what’s been discussed/decided/concluded.  Also don’t be afraid to involve people who weren’t involved yet if you think that it might be important to them.  If it turns out that it wasn’t important to them, then all you’ve lost is a few minutes.  But if it was important to them, you might have saved a lot more than a few minutes by pulling them into the discussion.

As for sitting in a separate office… i’m not a fan of that.  I’ve always noticed the best results are achieved when all of the developers are sitting together in the same office.  In some organizations, senior developers, lead developers or ‘architects’ might be sitting in different offices from the people they’re supposed to be working with.  I don’t know about you, but i’ve never actually seen that work properly.  The typical on-the-floor communication that is so vital to successful teamwork is just reduced a lot of if some people are sitting in a different office.  Obviously, when working with remote coworkers, this problem only increases but that’s something i haven’t really found an efficient solution for either.  In some cases, communication through IM works great.  And sometimes it doesn’t.  It depends on how effectively you can communicate through IM, and how effectively the others can. 

But anyway, when you hear people talk about how developers that isolate themselves at work is a bad thing, don’t necessarily buy into it.  Like i said, it can be good or it can be bad.  As with anything in our business, it all depends.