sfeldman.NET

The task then is to refine the code base to better meet customer needs. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won’t be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.

-- Jeff Sutherland

Anyone who worked with NHibernate knows that SessionFactory is an expensive object, that better to be constructed once, cached and re-used to build lightweight and disposable NHibernate sessions. It’s always shows up as a warning in books (NHibernate in Action, page 35), WIKIs, blogs, etc.

Today our team had a chance to experience what a wrong handling of SessionFactory can turn into – a huge memory leak. SessionFactory is a heavy object, it’s initialization and allocation is not a trivial one. Each time SessionFactory is constructed, it uses a significant amount of recourses and holds to those. If SessionFactory is not cached as a single instance, each allocation causes to the overall memory leak. Combine that with luck of Session disposing generates a very interesting result – more than a gig of  memory for something that is barely 20 megs.

Moral of the story:

- As in pair programming, so is in pair-troubleshooting – team works better

- Using a third party components (even the best out there) without exploratory tests will cause eventually pain

- Follow simple notes third party components authors write, they might simplify your life

The company I work for, Cortex Business Solutions, is in the hiring mode again. We are looking for passionate developers (Terry has worded the requirements in his post already, so I will keep it DRY).

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.
Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

Update: This is what I received today, less than 24 hours after the post was published:

Thank you for participating in the launch of our ASP.NET bundle.

I am glad to inform you that you have qualified for a free license for the ASP.NET Bundle (Typemock Isolator personal edition + Ivonna), and that the license will be sent to you in the upcoming week.

Real deal.

In my previous blog about domain objects and contracts for those, I have described the situation where the team was thinking in a different way than myself, and what we tried. I have never blogged back about the fact that the team got convinced that this is not a good practice, and long time ago we stopped doing that. Today I spotted a blog post from James Gregory where he names it properly “an anti-pattern”. That’s what it is. End of the story.

Seeing is believing. I was looking for a Hudson plugins that would allow me to present any TODOs left in the code. And as usual, found it (love that!). Static Code Analysis Plugins are useful when you need that type of information. In particular, I am talking about Task Scanner Plugin. The snapshot will tell everything.

I had an old post, back in July 2008, where I had a few comments on Data Driven vs. Domain Driven applications. It will be almost a year soon since that post, and I have definitely learned a lot since then. One thing I learned for sure, is to pick your the battles. You cannot fight a developer who knows data driven applications since day one and nothing else, that domain driven applications are not necessarily more ‘efficient’, but more maintainable, allow better link between domain concept and software, allow change, pass the reality tests when change in business is coming. It’s the same as trying to convince someone who spent 2/3 of his career without testing and sees no value in it, suddenly to start TDD or even ‘worse’, BDD. Why to bother? I know my stuff well, don’t I? Look, XX years in the industry are not wasted. No, they are invested with a little ROI. But these are religious wars. Useless. Therefore I am off the topic, and just learning, exploring, and implementing things I see the right way at the given moment. Once you concentrate on doing that rather than chasing ghosts to convince, you realize what is right and what is wrong, without a need in side-kicks.

So this is the end of discussion for me. Why did I post this? Well, it was funny to get today a comment, referencing the post. I forgot it long time ago, but someone is still fighting the fight he will eventually lose…

Anyone who's doing TDD is familiar with the CategoryAttribute coming with the most of frameworks. Today (I am surprised it took us so long!) we got read of

[Category("Integration")]

and started to use the right approach

[Category(Categories.Integration)]

where Categories is a sealed class with constants

public sealed class Categories

{

    public const string Integration = "Integration";

}

Why is it good? First - it's DRY (rather that finding strings such as "Integration" and "Integrations" all over the place. Second - it's easy to refactor.

I have a deep respect to people writing books. Not only it's a commitment, but a hard work that may not be appreciated, despite all the efforts invested into creation of a such. Saying that, some books are just not as good as the hype around them. Unfortunately, I found "xUnit Test Patterns" by Gerard Meszaros not very pleasant for reading...

Do not misunderstand me - the book has a lot of knowledge and practical experience behind it. I am absolutely sure that the author knows very well what he wrote about. The problem I found with the book was the way it laid out and presented. And in particular:

• If you are a novice in TDD, this book is way too dry and overwhelming. I would almost compare it to the "Design Patterns" by GoF reading experience when you have never touched C++/Smalltalk in your entire life and the concept of patterns in pretty new to you. What I would like the "xUnit Test Patterns" to be like for a novice (or at least a few chapters in the begging) is something similar to "Head First Design Patterns".
• If you are into TDD already, and seeking for ways to improve what you are doing - no book will help, but practice and lots of it. At the same time, it is good to read the theory to understand what should be avoided or alternatives to what you are already doing. Unfortunately, this book is not a pleasant reading, as every single page has at least one page-reference, and that has at least another one, and so on, and so on. You get destructed so by often page-jumps that you loose the content.

Finally the verdict: you can have this book as a reference, but not as a reading material. Oh, and if your shelf needs a solidity boost, it's damn good one for that :)