Turns out, I had my mapping screwed up. My related entity Y had two enumeration fields that I’d mapped as Int32. This throws off the comparisons. Int32.Equals doesn’t consider an enum of value 0 equal to the Int32 value 0. So every time I saved an entity referring to Y it considered entity Y dirty and updated it. Solution: in your mapping file, define the type of the field as the actual enumeration type or just leave the type out and let NHibernate figure it out.

This occurred even if I closed the solution and tried to open the individual files. ProcessMonitor.exe revealed nothing. Disabling plugins didn’t help. Deleting .suo and .user files didn’t help.

Googling for a solution revealed a couple of patterns. People were getting this either in VB.NET Windows Forms projects, profiling C++ applications or trying to open TFS work items. The latter resonated. TFS, my long-time nemesis, we meet in battle again.

I tried removing the local path mapping for the project in my TFS workspace, deleted the folder and recreated the mapping. Win.

Eric Ries – The Lean Startup @ Oredev

Really useful advise on startups, be it a new product, a new business endeavor or a whole new company altogether.

Giles Bowket – Archaeopteryx MIDI generator @ Rubyfringe

I just love Giles’ delivery on this one. He’s presenting a MIDI generator software he’s been working on and throws some cold water on the industry in the process. An absolute classic.

Steve Souders – Even Faster Websites @ Google I/O

Invaluable tips on performance optimizing web sites, presented by the maker of YSlow.

Brian Fitzpatrick & Ben Collins-Sussman – The Myth Of The Genius Programmer

A talk about confidence, communication and facing failure. Among other things. Nothing really revolutionary here, but should be a good reality-check for many. I know it was for me.

That’s it for now.

A quick fix for this is to enable AspNetCompatibilityMode on the WCF hosting infrastructure. In your web.config, add the following tag under your <system.serviceModel> declaration:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

You also have to decorate your .svc class with the following attribute:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

I don’t know if this is an ideal solution however, and if it has any negative effects on performance etc. More elegant solutions seem to be available. More information on AspNetCompatibilityMode is available on MSDN.

Coding, after all, is just writing.

– Jeff Atwood

Yup. Jeff covers some essential aspects of the curious relationship between writing and coding in his post, focusing on the perspective of style and readability. I’ll now give a shot on extending on that topic. I’ve been kicking around the subject of domain modeling in my post drafts bin for quite a while, not knowing how to present it. Today it hit me during a sprint review at a client. There is nothing revolutionary here. It’s all basic domain modeling and design patterns, but viewed from a different angle.

Numerous are the times I have come across inconsistencies in domain models due to misunderstandings in the development process from the actual domain to object model. I’m sure you have too, and this is nothing new under the sun, and to some degree somewhat unavoidable. Perhaps you’ve also seen objects used for something they weren’t meant and designed for. This could be due to architectural shortcomings, laziness or just plain ignorance.

As a harsh example, I’ll describe a case of architectural shortcomings that forced me to do an ugly hack and thus leverage a wrong object for the job at hand. The GUI components of the application featured a parameter-generated form – dubiously titled ViewForm -  for performing complex database queries to ultimately retrieve an entity to open into another form for modification.

First of all, naming the form ViewForm is just a cracker-jack job at crafting an ubiquitous language. It’s a form that views stuff. You must be shitting me. How about SearchForm? After all, it’s a form that searches stuff. Infrastructural domain objects should be named with equal care as the ones in the business end that have taken years and years to refine into concise,  yet semantically clean terms. Ultimately the distilled purpose of the ViewForm component is to search stuff, so I’ll assume from now on that this naming quirk hadn’t been there.

The hack in question? I was asked to implement a search form that queried two separate tables – import and export shipments – and opened a different form depending on the type of consignment the user double-clicked on. I ended up creating a dummy form with absolutely no visual components on it, and some code in the Form_Load (or such, luckily can’t remember a thing of the VB6 API’s) event handler that figured out which of the two consignments it was, opened the corresponding form and closed the dummy one.

The said form performed nicely enough in the job of querying, and being configurable and all that. The problem, however, presented itself when a series of domain modeling mistakes met, reaching a critical mass of code smell. Following are the essential shortcomings that led me to produce probably the ugliest hack I’ve ever had the balls to ship:

1. We’re talking about ERP-style software here, and thus object-oriented programming should be a given. No objects here, other than infrastructural ones, courtesy of VB6 (Form, Control etc). This results in aforementioned search form querying for database rows instead of entities. So no strong typing to be relied on. That also means that refactoring the query form configuration model would’ve been a tedious exercise of implement-and-wait-for-the-bug-reports.
2. When the data schema is modeled merely as database tables and a bunch of functions scattered across random forms all over the place, the domain model easily scatters into a bit of a disorganized mush. In this case, the business requirements dictated that the system should handle import and export shipments, thus the developer creates separate tables for them without stopping for a minute to ponder the semantics of the two. A shipment is a shipment, regardless of its direction, I dare to assert.
3. The configuration data schema for the query form was modeled so that there was a query form definition and it had a bunch of associated column definitions. The gotcha was that the query form definition held the name of the form that would be opened when a user double-clicked a row in the results grid. The semantics of a query form per se come into question here – is query form a query form or a query-and-open-another-form form – but mostly in the sense of separation of concern.

Though all of the aforementioned architectural turds play an important role, the third one is the most essential one in this particular case. The coding-as-writing analogy plays out here in the sense that having a semantically clean ubiquitous language paves the way for clean and pragmatic separation of concern. If the domain model defines a search form, you implement a search form that knows about searching for stuff, and that maybe something needs to be done with the stuff that it finds: something, but not what exactly.

Rather than referring to an individual form to open, the search definition should’ve pointed to a strategy object that would’ve done whatever it wanted with the row of information: figure out a form to open or perhaps perform some other processing on the record. Now I had to emulate that behavior using a Form object to do something it’s not designed nor meant for.

Moving on to unfolding screwup number two. I once tried fishing out a reason for the crowbar-separation of the two shipment directions and got something along the lines of “well it’s because they are a totally different business”. Well humm righty-o, but isn’t a shipment still a bunch of goods that is going from one place to another, results in costs to an array of involved parties and is dictated by a set of legislation, contracts and whatnot?

An imported shipment might hold some information that an exported one doesn’t and vice versa, but object-oriented programming provides inheritance and relational databases provides relationships for just that. Eventually both of the shipment types still need to be treated as equals, just like what happened here. Another highly probable case would be a statistical report on import-to-export ratios.

The key point I’m trying to make here, is that, if the ubiquitous language has been crafted carefully, evaluating semantics provides a logical and robust back bone for designing the object model. Now that I think of it, I can’t see another way to really model a domain. Yet every day I witness failures – albeit smallers ones – in modeling that would’ve been solved by really grinding the terms used to describe the objects.

When an ubiquitous language starts to take shape, go through the terms described and really chew them fine. If the term isn’t concise or unambiguous enough, finetune it until it is. Then use that information to form a pragmatic object model that separates concerns logically.

However, there’s a catch. Nesting the files causes the file names to be overwritten. In this case, the .hbm.xml suffix gets dropped. That effectively prevents Configuration.AddAssembly() from finding the mapping information. A way around this pitfall is defining the dependency as follows:

<EmbeddedResource include="ServiceRequest.hbm.xml">
<DependentUpon>ServiceRequest.cs</DependentUpon>
<LogicalName>ServiceRequest.hbm.xml</LogicalName>
</EmbeddedResource>

Thanks go to Sami for cracking this nut with me.

Just thought a no-nonsense reminder about this is in order.

The Chinese New Year was celebrated in Helsinki for the 3rd time on 25th January 2009. The event featured spectacular wushu, puppetry, chinese opera and dance performances. I froze my ass off standing in the slush photographing some of the performances. Enjoy.

I wrote (heh) an empty trace listener for LAB and an empty appender for log4net and ran a couple of unit tests. While not nearly as dramatic as Loren Halvorson’s findings 4 years ago, the results weren’t exactly flattering from LAB’s perspective.

The unit tests wrote 100000 info level – not that it matters, after all we’re using empty appenders – log entries and timed the whole deal. Log4net’s effort took a respectable 153ms, while LAB’s time was a significantly longer 1396ms. I also tried actually writing the entries out, using FlatFileTraceListener and FileAppender on LAB and log4net respectively. The results: log4net 1450ms – LAB 4243ms. Not as dramatic, but relevant nevertheless.

Oh, and by the way, I’m not handing out a table of the dubiously conducted performance test results, because I’m mean and I want you guys to read my posts.

Going beyond performance, setting up LAB is – to put it gently – laborious. Microsoft’s documentation doesn’t offer configuration examples in their native xml form. Rather, they “encourage” you to use a configuration tool that is shipped with Enterprise Library. That sucks. I had to download and install Enterprise Library to use a tool to edit App.config, instead of just copying the DLL from a project I already had and modifying a copypasted configuration to suit my needs. I hate clicking around to produce stuff that’s essentially lines of code in my Visual Studio solution.

Then there’s the behemoth of an API that LAB sports. Constructing LogEntry objects, then asking whether it should be logged and then writing them out to the logger isn’t actually succinct. Surely you can encapsulate this behavior in your own helper methods, but I can hardly see the point in rewriting the API. Logging code should be really succinct, and by default log4net’s API provides ways to do just that.

log4net 1 – MS Logging Application Block 0

ps. Do note that Enterprise Library 3.1 is already outdated so I don’t know if these conclusions apply to Enterprise Library 4.1.