Just read an interesting post from Leo Babuata about how important making mistakes can be. I quote:

Yet without mistakes, we could not learn or grow.

If you think about it that way, mistakes should be cherished and celebrated for being one of the most amazing things in the world: they make learning possible, they make growth and improvement possible.

I could not agree more. There are two mistakes in particular that have had a huge impact on my career, and that i’m actually very grateful for.

The first was when i once accidentally truncated 4 tables in a production database losing millions of records in the process. I actually learned a few important things from this. Checking your connection string to make sure you’re connected to the right database obviously being one of them. Not doing any important work before 8am is another one. The most important thing i learned from this? Being honest about your screw-ups. This happened in an organization where nobody ever makes a mistake (wink wink), yet things go wrong all the time. Whenever someone screwed up, they would call up the people from Operations, blame it on some kind of faulty process or whatever, never taking personal responsibility for it. The result was that the Operations guys made you jump through hoops to get the problem resolved. After my accidental truncation of those production tables, i called the Operations guys who were responsible for our Oracle server, and i said “Umm… i made a stupid mistake, and i accidentally truncated 4 production tables”. The silence on the other end of the line was deafening. It was like the guy from Operations was waiting for me to come up with an excuse, so i just asked “how can we get this fixed as soon as possible?”. And they just started working on the restoration process (which for some reason takes a couple of hours) immediately, not even requiring me to fill out a support ticket (which meant having to navigate in an application with about 16 tabs, some of them containing between 5 and 10 sub tabs, with each tab having about 20 fields on it).

Lesson learned? If you screw up, be honest about it, don’t blame someone else, don’t come up with an excuse, just tell them you screwed up. You’d be amazed at how well people react to that, and problems usually get fixed much quicker because of it.

The second huge mistake was about the 4th or 5th project in my career. It was a pretty interesting project, and was a lot of fun to do. It was an application that had to keep a lot of statistics on the usage of an intranet site of a large enterprise. One part of it was a nightly process which would parse the logfiles and store all of the data. The other part was a client tool to consult the data in variety of ways. The first version was great. Performance was pretty good (at first), and the application did what it was supposed to do. The users were happy. I was too.

Then some of the requirements changed. And i changed both tools. Then the requirements changed again, and again, and again. The code was quickly turning into such a nightmare, that i often feared making changes, knowing very well that each change was very likely to introduce new problems. The project turned into a maintenance nightmare (luckily, the only one i ever produced) and after about 2 years i was the biggest proponent of killing it and just buying some tool to do the same thing.

My biggest mistakes in that project were that i hadn’t designed my code to enable change in an easy manner, and that i had no tests whatsoever. When i had to make changes, it usually resorted in adding if and/or switch statements here and there, and lots and lots of debugging. I just didn’t know any better at the time. It actually took me a few more years before i actually started writing tests, but it did have an immediate impact into how i started designing and writing code.

Ever since that project, i’ve been gradually moving towards keeping code loosely coupled and making sure that, when necessary, i could easily change parts of it with confidence, or even replace parts altogether without affecting other parts of code. It took me a while to get there, but these days i’m pretty sure that i can deal with a lot of changes, in pretty much every layer, without causing new problems or decreasing the overall quality of the system. I may have gotten to this point without having first created a maintenance nightmare, but it probably would’ve taken me a lot longer to realize the benefits to all these hippie patterns and practices that we now subscribe to.

So yeah… learn from your mistakes, and be thankful that you made them.

It took us a while but it’s finally here: www.altdotnet.be

We started our local ALT.NET meetings in August, and have been doing them monthly ever since. We usually discuss a certain technical topic (or a few of them), although we sometimes have someone do a presentation as well. Either way, there’s a lot of great stuff to learn from these meetings, so if you’re a .NET developer who would like to keep improving your skills, be sure to sign up

In my last post i showed you how we can now use the Future feature in NHibernate. The only downside to the feature is that we only have the Future method in ICriteria, which returns a generic IEnumerable. Which doesn’t really lead to nice code when dealing with queries that return a scalar value, or just a single row in general. So i decided to extend the feature a little bit.

I introduced the IFutureValue interface, which only defines a Value property:

Then i added the FutureValue method on ICriteria, which returns an IFutureValue instance which behaves exactly like the IEnumerable that is returned by the Future method. If you access the Value property of the IFutureValue instance, it will either execute all of the currently queued Future queries in a single roundtrip, or it will simply return the result if the queries were already executed.

Here’s some useless sample code to show off the feature:

This is available starting with revision 4000, or in the official NHibernate 2.1 release.

I’m obviously biased, but i think that NHibernate is the best option for data access in the .NET world at the moment. And while we have a lot of users, there’s also a lot of people that don’t use it. I’m just curious as to why some people aren’t using it. So i’ve set up a new poll with some options you can select if you’re not using it. But if you’re not using it, do me a favor and leave a comment to explain your selection.

This isn’t meant to start a flamewar or anything like that, i’m just genuinely interested in reasons for not using NHibernate.

The options of the poll are:

• Tried it, just didn’t like it
• Tried it, but had problems that prevented me from using it
• Can’t try it because i have little to no faith in the project
• Can’t try it because i’m not allowed to use it (because of management, technical leads, legal reasons, etc…)
• Won’t try it because i use something else that i’m perfectly happy with
• Won’t try it because i’ve heard too many stories of projects having problems with it

Also, if there’s another reason why you’re not using it, please do share

As some of you already know, i’m a big fan of avoiding excessive roundtrips by batching queries and/or service calls. For NHibernate, i wrote the QueryBatcher class which makes this pretty easy to do. Ayende recently added a much easier approach for this to NHibernate.

Take a look at the following code:

This is a really trivial example, but it should be more than sufficient. It simply executes two very simple queries and loops through the results to do something with each returned entity. The problem, obviously, is that this hits the database twice while there really is no good reason for doing so.

With the new Future feature we can rewrite that code like this:

Apart from the comments, did you spot the difference? Instead of calling ICriteria’s List method (which causes the query to be executed immediately), we call ICriteria’s Future method. This returns an IEnumerable of the type you provided to the Future method. And this is where it gets interesting. Instead of executing the queries immediately, the queries are added to an instance of NHibernate’s already existing MultiCriteria class. Only once you enumerate through one of the retrieved IEnumerables will all the (queued) Future queries be executed, in a single roundtrip. Once they are executed, their result is final (as in: enumerating through the IEnumerable will not cause the query to be executed again).

The example used here is obviously very trivial, but you can use this with any ICriteria so you can very easily start batching your complex queries as well. The kind of query doesn’t really matter, as long as it’s an ICriteria instance.

This feature will be available in NHibernate 2.1, or if you’re using the trunk you can use it starting with revision 3999.

I recently read a post from J.P. Hamilton where he admits that he sometimes writes bad code. I quote:

That’s a brave admission in our industry, but I am willing to bet that even the best of best write bad code now and then.

I would go even further than that. Any developer who claims he never writes bad code is either lying, ignorant or living in a fantasy world. The thing is, as J.P. points out, is that good developers will try to minimize the amount of bad code that they write, and when they do, that they try to get rid of it as soon as they can. But if those developers are so good, then why do they occasionally write bad code in the first place?

Building software takes resources and requires dealing with constraints. With resources i mean more than just the number of developers that are available to work on a project. Software libraries are resources. Tools are resources. A lot of things can be resources or constraints (sometimes they can be both simultaneously). And obviously, each resource has a certain level of quality, which can have a positive or a negative effect (which enables these resources to also become constraints).

The cumulative effect of all of these resources and constraints means that you sometimes need to make compromises. One of those compromises can be that a good developer comes to the realization that for whatever reason, he (apologies to my 2 female readers: it’s not easy to refer to developers in a gender-neutral way all the time ) needs to write bad code to make a problem go away. Code that is not up to his usual standards and that he is not proud of.

This is usually referred to as incurring some technical debt. Nobody likes to incur debt, but sometimes you just can’t avoid it. If incurring some debt enables you to start creating value sooner rather than later, then it might actually be a good idea to do so, provided that you have the means to pay back the debt later on at a reasonable cost. You definitely should strive to keep that debt as low as you can (or even eliminate it entirely) because if you don’t pay off the debt, you’re definitely going to regret it sooner or later.

I honestly have a lot more respect for developers who can identify the need to occasionally write a bit of bad code instead of foolishly clinging to a dogmatic “i shan’t write bad code, no matter what the circumstances” stance. Well, as long as they remember to pay off their debts as much as possible, and that they do strive to write clean code as much as possible

Being a .NET developer isn’t easy. Being a .NET developer who wants to get better all the time is even harder. Where do we go for guidance? Where do we go to get that valuable knowledge that will help us improve our skills and help us serve our customers/employers better?

A lot of .NET developers expect this kind of guidance from Microsoft, particularly from groups like Patterns & Practices. In the past, i honestly think they did a pretty lousy job at that. In the last year however, i think we’ve seen some positive signs that things are improving, although rather slowly.

There’s also an ever increasing group of .NET developers who look to the ALT.NET community for guidance. There are a lot of talented, motivated and passionate developers in this community and there certainly is a whole lot of valuable knowledge to be found there. However, in the last couple of weeks especially, it seems like this community is ruled by the Holy Trinity Of Continuous Bitching. Well, the mailing list especially. At times it feels embarrassing to even be subscribed to it, although there still is the occasional nugget of interesting information to be found. At least, if you don’t mind going through all of the high-school drama to get to that valuable information.

So who should we, the regular nobodies who happen to develop software for a living look up to for advice and guidance? Should we just listen to what Microsoft recommends? Hmm, no. Should we blindly follow the supposed ALT.NET leaders? Please don’t.

Here’s what i recommend: try to learn from the people who actually make sense to you. It doesn’t matter who they work for, what they have done in the past, what they are working on right now, or even how unknown they are. If it makes sense, it makes sense. If it helps you improve your current way of working, it’s a step up already. It really doesn’t matter if what you’re doing is ‘right’ according to the ‘big shots’. Do what works for you. Do what helps you improve what you’re doing. Don’t resort to blindly following anyone.

Fluent NHibernate is an interesting new project that allows you to configure your NHibernate mappings with a fluent API instead of using the typical XML mapping files. I think it’s great that Fluent NHibernate exists, as there are quite a few people who dislike NHibernate’s mapping files. But i don’t really see why so many people dislike the XML mapping files.

I’ve stated many times before that i seriously dislike having to write a lot of XML just to get something working. Most of that comes from previously having used some of P&P’s older offerings. XML can be easy to read and write or it can be very painful to read and write. I feel that a lot of Microsoft tools which can be configured with XML are typical examples of the painful kind of XML. The old “XML is like violence: if it doesn’t work, apply more!”-joke certainly comes to mind here.

But NHibernate’s mapping XML? I think it’s pretty nice to be honest… it’s not too verbose, and if you add the XSD to Visual Studio’s XSD folder, the Intellisense support is pretty good. When you’re starting out with NHibernate, it might take some time getting used to it, but i don’t think the learning curve (for mapping) is that much higher for the XML mapping than it is for Fluent NHibernate.

A lot of people also say that better refactoring support is a great reason to move to the Fluent NHibernate… that’s true but there’s also a Resharper plugin which supports refactoring NHibernate mapping files.

One reason to stick with the XML mapping files for now is that Fluent NHibernate doesn’t have support (yet) for everything that the XML mapping files allow. This is probably only a temporary issue as Fluent NHibernate seems to be under pretty active development. But if you run into something that isn’t supported yet by Fluent NHibernate, yet is supported by the XML mapping files then you might end up with 2 sources of mapping: most of it in code, and some of it in the XML files. I’d prefer to have all of the mappings in one format/style so that might be an issue until Fluent NHibernate supports everything the NHibernate XML mapping files do.

This is certainly not meant to dissuade people from using Fluent NHibernate. I just prefer to use the XML mapping (for now) and since nobody seems to be sticking up for the XML mapping, i figured i’d stand up

How about you guys? Do the mapping files really bother you? Or do you prefer the XML over Fluent NHibernate?

Writing a post about some of the most important design principles has been on my TODO list for a long while now. And luckily, Laila beat me to it

Sometimes it’s useful to be able to store an object somewhere so you can easily access it for the duration of the current request, instead of having to pass it around with every method call that you make. That request could be an ASP.NET request, or a request in your WCF service layer. I used to resort to storing these objects in ThreadStatic fields (which is basically a static reference for each thread), thinking that it would be safe because only one thread handles a complete request. Last week i read that some requests can be paused and resumed by another thread. If you’re using ThreadStatic fields, this could lead so major issues which would be a royal pain in the ass to debug. In order to prevent this possible problem, i wanted to have a safe way to keep state that should be available for the duration of a single request.

If your code executes in an ASP.NET environment, you can safely use the HttpContext.Current.Items dictionary for this. If your code executes in a WCF environment, you can store these things in the OperationContext. I don’t want my code to be tightly coupled to either ASP.NET or WCF, so i wanted some kind of abstraction. This is the approach that i came up with.

First, we have the IRequestState interface:

This just offers a way to store objects and retrieve them. That’s pretty much al we need, right?

Then we have the ASP.NET implementation:

Very simple stuff… the AspNetRequestState implementation simply uses the HttpContext.Current.Items dictionary underneith to store and retrieve the objects.

For WCF, it is slightly more complicated. Every WCF call is an operation and it has a context as well, which is provided through the OperationContext class. The OperationContext class doesn’t have an Items dictionary like HttpContext does, but it does have a way to add extensions to the context. We can use this extensions mechanism to store state which should be kept around for the duration of the current WCF operation. First, we need to define our Extension:

The IExtension interface that we must implement defines the Attach and Detach methods but we don’t really need them for what we’re trying to do. This extension simply initializes a Dictionary instance and exposes it with a public getter. Now we can easily create our WcfRequestState implementation:

Pretty simple as well, and pretty similar to the AspNetRequestState implementation. The AspNetRequestState implementation is able to simply use the HttpContext.Current.Items dictionary, which we can’t use here. So when we want to access the ‘State’ dictionary in this implementation, we look it up in the current OperationContext’s Extensions collection. If it’s not there yet, we add a new instance of our MyExtension class to the OperationContext’s Extensions collection.

Now we can use this wherever we need to store something for the duration of the current request, regardless of whether we’re executing in an ASP.NET or WCF context. Just configure your IoC container to create instances of AspNetRequestState whenever an IRequestState instance is needed in your WebApplication, or configure it to return WcfRequestState instances in your WCF service. The code that needs to store some request state will no longer have to resort to using ThreadStatic fields, and it doesn’t need to know about it’s runtime environment either. It merely needs an instance of IRequestState.