Interesting bugs also rear their ugly head – it turns out that running our developement on the newest of the newest in terms of hardware and software versions is problematic, since our test customer is running on an erhm… let us say technically challenged platform. We are using every tool in the shed in terms of query-optimization in NHibernate – and it turns out there is a corner-case where certain combinations will work on SQL server 2005 but not SQL server 2000. I’m working on testing it on a small test project to prove that it is not us, that are idiots. For those interested – our bug manifested using HQL, a sorted query on a class that has joined subclasses with collections that we wanted to use subselects on in a paged resultset – and no lazy-load (yeah, not the simplest of scenarios…). NHibernate tries an optimization that uses the function Row_Number() which only works on on 2005 and later, thus throwing an exception. And yes, we use the MSSQL2000 dialect option in NHibernate.

So, before we do any further optimization on their solution, I want them to change to at least a newer version of their database software and get some decent hardware to go along with it. Next step will be cleaning up their workstations (4+ year-old-installations of XP perform… uhm… interestingly) and maybe upgrading them with DirectX 10. The problem is that they really do not want to spend much on their IT-infrastructure as they are planning on outsourcing it next summer, but right now their employees are suffering. Originally the plan was that they would have outsourced it already – we made it clear in the beginning that this new software would be hardware-hungry, but as the saying goes – “No battleplan is worth anything once the battle has started”, so we will adapt and overcome.

Jeg var lidt nervøs før vi gik i gang – jeg havde kun mødt den ene af deltagerne og var i tvivl om niveauet, jeg skulle lægge for dagen. Det viste sig dog at jeg havde ramt tæt på bortset fra at vi nåede lidt længere end forventet. De får naturligvis en opdateret version af kursusmaterialet, når jeg har opdateret det med det ekstra.

Undervisningen blev en blanding af en hardcore-design session og så en gennemgående øvelse, hvor de fik lov at bygge en Outlook-klon. Ikke fordi det er nogen banebrydende øvelse – mange før mig har brugt netop Outlook som baggrund, men det gav mig en chance for at visualisere alle de ting i WPF, som hører hjemme i et crash-course. Jeg var samtidig lidt heldig med de deltagere jeg havde. De havde begge prøvet WinForms og Delphi, så det var rutinerede kræfter, som blot skulle omskoles til WPF.

De næste kurser bliver en udfordring dog – det her kursus ville jeg kunne holde stort set uden forberedelse. Næste gang bliver det med en eksempel-applikation, hvor abstraktionsniveauet kommer til at lægge langt højere og der skal arbejdes for at gøre det til en strømlinet oplevelse. Kursusmaterialet er godt og vel halvt færdigt – så det tegner til at alt nok skal lykkes.

Nu mangler jeg bare at få solgt kurserne til nogle flere…

Kurserne er bredt fordelt over emnerne WPF og agil programmering, hvor undertegnede primært skal varetage WPF-delen.

Vi holder kun kurser i emner, som vi har en aktuel og dyb indsigt i – og dermed kun de ting, som vi selv benytter til daglig. Vi håber at vi på den måde virkelig kan tilbyde kursisterne noget ‘andet’ end det de er vant til. Vi har selv haft problemer især på WPF-fronten med at finde kurser, der var på højt nok niveau og som samtidig blev afholdt i Nordjylland. Det er der hermed rådet bod på!

This may sound a bit harsh – but it is actually true. When you know at least part of what is probably going on under the hood – you take a lot of things for granted. Of course that functionality is in the menu under Tools -> Settings – that’s the garbage can for any developer… but of course you should just right-click, hold control and drag it across the screen waiting two-thirds of a second for Windows to update the UI before moving out of the listbox.

And the things that annoy developers are unlikely to be the things that annoy Joe the Plumber and vice versa. Developers will complain – “But I have 47 controls – and if I don’t use up three rows in the tool-panel, the user will never see my brilliant functionality and I’ll spend hours explaining how to reach them”.

So, what to do? It’s actually quite simple, start looking at things that you don’t remember using – without looking, tell me how you activate the rear-view wind-shield viper? Most cannot. They will still be able to do it, when they sit in the car, but they will be unable to tell you. It is a combination of placement and icons incl. mapping. Cars must meet certain usability demands for drivers not to endanger themselves and everyone else on the road. All critical functions must be doable without taking your eyes of the road.

So, what does the car manufacturers do better than your average software developer? They spend a lot of time and energy on making sure buttons are where people expect them to be, make them of varying size and texture to allow the driver to find them without looking. And they place all the controls you need the most (steering wheel, gear stick, the horn and light-controls) at the most convenient positions. The less-used controls are not hidden away, but placed in secondary positions and less convenient to avoid taking the focus from the critical ones. (And of course, the car stereo designer still has not learned anything – I count 34 buttons on mine – 33 of them identical in size, colour and texture with tiny icons with made-up acronyms on them).

And they don’t start switching the brake-pedal with the accelerator, because it just seemed more aesthetically pleasing! Nor do they start making the car turn right when you turn the steering wheel counter-clockwise. (So, for goodness sake, stop placing the cancel-button to the left of the ok-button) In other words – they follow conventions even if it might conflict with other goals.

To sum up – to make better UI-designs – stop trying to invent the new and better wheel – and rely on already established conventions and use the hard-earned lessons other people have learned before you.

I’ve always had a pet-peeve with badly designed software, but being unable to express what was actually wrong with it – I realized I had no vocabulary in usability. So, I started with these two books that are recognized as must-reads for designers generally. What I learned was not so much how to design beautifully nor how to design in the first place, but rather a vocabulary to express what I already knew and also, some research to back up my understanding of why design is important. These two books are not aimed at software designers in particular but rather the principles behind design in general. As such, many of the principles don’t really apply to software.

Most developers face a challenge when confronted with the word usability. They all know it exist, but most do not see the problems because having a technical insight makes you blind to the problems non-technical users have with their creations. Concerns are discarded just because the developer a) does not see the problem and b) cannot relate to the underlying cause.

The catch-phrase from my reading has been: “The user must see the conceptual model to understand the interface”. For us software developers, this means that if we are unable to convey the conceptual model of what we wish to accomplish in the GUI, the user will most likely fail. The conceptual model is basically “what happens under the hood” – in other words, it is everything the user cannot see. Humans are adaptable beings and jump to conclusions. This is why we have users saying “the computer freezes everytime I turn on the coffee-machine, so, since I started drinking tea, it has been running fine”. We (the IT-people) know this simply cannot be the under-lying cause, but the user does not know the technical bits – he saw to circumstances happen at the same time, and concluded that they must be intertwined.

So, what to do? Should we start educating users to be IT-minded – maybe throw in a MCP to make the users understand why stuff works the way it works? It would certainly make Microsoft happy… but no, it is not a viable solution. Instead, we need to focus on making better GUI. We need to make the conceptual model clearer and simpler. When the application fails, the error-message should not read: “Exception occured in major module hj_uuullk. Fatal failure reading harddrive kl_llij at position 0xE3F2E5″. It should read: “There was a problem with opening your document – you did nothing wrong. Technical staff has been informed about the problem and will fix it as soon as possible. If you want to follow progress: >link<. Please, do not attempt to open this particular document before technical staff gives the go-ahead. Other documents should work fine. If you need the document before, contact jim@farkvad.com.”. The user gains no insight from the first error message. Basically, he has no way of knowing if he did something wrong or it was a software mishap. All he knows that something went wrong, but he is left thinking… “Maybe my coffee cup was too close to the screen… hmm… could be that it was due to reading an e-mail at the same time…” The chances of him reaching the correct conclusion is slim-to-none.

I will return shortly with a series of posts around usability and general design concerns.

The whole collection-issue that I mentioned in my last post can be frustrating if you missed the point with NHibernate using reference equality. In most situations you will not notice that one untill it is too late as it will be non-noticable in small datasets (if you are not paying attention to the SQL output, of course).

Another thing about equality – often, you will have entities publish an ID-field mapped to an Identity-column in the DB (for look-up purposes) and have it backed by a field. If you decide to use the ID for equality-purposes and have the property mapped with access: field be aware that any proxy from that persistent class will have different values for the field versus the property – the field will always be 0! So, always use the property in Equals(). Also, when considering equality in general, be sure not to use any lazy-loading entities as they will be loaded whenever equality has to be determined (WPF does a lot of that!). A rule of thumb is to use all properties for a value-type class (as per the DDD-terms) and only the ID for persistent aggregates (especially when they will be used as attached aggregates). The reason for this is that lazy-loaded entities do not have to be

evaluated (ie. loaded) to determine equality. I used to be a DBA in former employments and have spent a lot of time normalizing tables and I grew accustomed to mapping each fine-grained object to it’s own table – this is performance-killing! Consider the traditional simple Customer-class consisting of an accountnumber, a physical address, a billing address and billing information. If you map this to three-four tables (one for the customer, one or two for the addresses, one for the billing information) – NHibernate will unleash a LEFT OUTER JOIN hell of magnitudes (or a series of SELECT’s that will have your DB spinning out of control if you have yet to mark it to use sub-selects or outer joins)… Now consider when you start using the customer in other objects… The lesson here is that your typical one-to-one relationships with objects that will most likely not be null should be mapped as components and thus for the DB’s sake exist in the same table. Only consider a seperate table, if the associated class will often be null, or rarely used (lazy-load).

Inheritance and generics is another issue – just because NHibernate supports both, doesn’t mean you have to use it! It is most often not a perfect match and you will be twisting NHibernate into a knot to conform to your domain or vice versa. Also, remember that if you have an associated aggregate that is mapped with the base class – the resulting lazy-loaded proxy will always be the same type as the base class – never one of the derivatives. (See Ayende’s blog for further details as to why). Use it sparringly and be aware that mapping files do not support open generics – so, if your inheritance tree consists of a generic superclass – you cannot use it as the base class in the mapping unless it is a closed generics (and then it is a really advanced case – and you should really try for a simpler solution…). Generally speaking – using generics and inheritance in your mapping files will most often lead you into a world of hurt when the dependencies evolve and a key class in the inheritance chain will suddenly no longer conform to the dependencies. It is bad enough to have that happen to your domain – if you add data-migration head-aches to that mix… you’ll end up being wary of making needed changes to your domain.

All this said – if you stay clear of the pitfalls, NHibernate is a very nice fit for most agile TDD/BDD/DDD projects with databases as the early iterations will benefit from the easy DB-schema generation and the reduced DB-work. Later on, you’ll have to somehow solve the data-migration issues for projects in production – most customers will not take it lightly when you drop their databases for the new version to take effect… I have yet to find a silver-bullet there (there are products out there, but I have yet to need one badly enough to actually test them). My experience is that Active Record (which uses NHibernate under the covers) is really good for the early iterations – and then shift to full-blown NHibernate when you start running into the advanced stuff. DBA’s may seem like they get the short end of the stick and be out of a job, but it is actually a win-win situation – they get to do the fun performance-tuning part of their job in favour of the error-prone database generation part.

But MVVM – for the life of me, I just couldn’t see the benefits – handling the mismatch between the string-typed world of UI and the many-typed world of the domain classes were beautifully handled with shared ValueConverters (thanks, WPF) and nice services. So, I was left thinking – I’ll end up duplicating logic, duplicating all interfaces and all I’ve got to show for it was no implementation of INotifyPropertyChanged in my domain-classes? No way, Jose!

Let’s just say – things went well for about a 8-9 months period – and then pain came creeping. Performance was dwindling faster than you can say *cough*poorly-matched domain-model*cough* and I simply didn’t understand why. Everything was coded both to satisfy a rich end-user experience, caches were used to share common DB-queries and patterns were used to relieve coding smells when they emerged, but still performance kept dropping… And some weird persistence bugs kept re-emerging (“Why is this entity suddenly detached and this one screaming it has a transient one… when they should be one and the same?”).

Then it dawned on me (reading “Nhibernate in action”) – everything keeps ending up dirty whether I’ve touched it or not after retrieving it from the database making for endless useless round-trips when there should have been none. Investigating the matter further, I came to a clue: Every-time an entity had a collection of custom type, it wasn’t dirty when retrieved, but as soon as it was shown in the UI, it became dirty. WTH!? I started investigating in all the wrong places, WPF Binding bugs might be it, doing an extra setter somewhere – maybe the NHibernate Interceptor taking care of audit – and I just kept drawing blanks.

Then (going back to reading NHibernate in Action) it finally dawned on me… collections => dirty when databinding to it… I found code-snippets like this all-over our domain-model (truth be told, I made them myself… They did not appear by magic):

private IList<ISomeClass> _list;
public ISomeClassCollection List
{

if(!(_list is ISomeClassCollection))
{

_list = new SomeClassCollection(_list);
OnPropetyChanged(“List”);

}
return _list as ISomeClassCollection;

}

The reason for the ISomeClassCollection was a work-around to better support INotifyCollectionChanged as ISomeClassCollection would act as a wrapper around the original list and notify UI of changes to the collection. Can anyone spot the problem? NHibernate identifies dirty-state in collections by ReferenceEquality on the collection and equals on the content of the collection… So, the first time, UI would ask for the current collection to show it in a ListBox or a DataGrid, it would mark the entity dirty because the retrieved collection was no longer… Collected as common garbage, you might say…

So, back to the drawing-board for that one. Before turning to NHibernate in Action I had just plowed through HeadFirst Patterns and Design Patterns (Amazon them, I couldn’t be bothered to find a link) and I came to the conclusion why MVVM would be a good idea here… Not only would entities stop being marked dirty all the time without cause, but I could support 1 level undo, simply by copying the state of the entity when read, and only setting it when the conversation was over and the user had agreed to the changes reducing the number of round-trips even further.

Later, when implementing it, I also discovered a nice side-effect, I hadn’t considered. The domain-classes are now very compact and it is much easier to enforce how to use the domain. Since collections used for full-fledged databinding needs to both implement IList and INotifyCollectionChanged, the collections in the domain tended to be full of features, that weren’t used (and shouldn’t be used, since they lacked the logic of the proper methods).

So, now collections are usually IEnumerable and the ratio of value-type compared to entity-types (in the sense of DDD’s notion of value-type and entity) has reached an all-time record of 65%! Having a value-type with only getters and a few methods and then letting the ViewModel have the setters and all the handling of the user… it just makes for real simplicity in the domain. Yes, the ViewModel can end up cluttered with all kinds of weird tricks to satisfy the demanding master of UI-updates, but that’s what it’s there for!

I still have a few things to iron out (mainly with duplicate logic to support notifications to the UI without touching the domain entity when services and dependant objects are in play), but just the first round of refactorings has increased my satisfaction with the domain-model ten-fold. It turned from being just wrapping the domain objects to a complete refactoring of the interfaces of the domain and complete re-working of the database-schema, but it is well worth it in my oppinion. For certain it would have been much more critical to do it after it had gone to production (the mind boggles at the amount of data-conversions to be done…).

The lesson? I, Magnus, do hereby solemnly swear, never to let UI-concerns enter my domain model again! I now understand it will be my doom and much pain will be caused… mainly to me. (And I’ll swear again, the next time it happens!)

Testing

• NUnit – A classic. Really, I could have used MS’ own test-framework, but I just don’t trust it yet. I don’t use anywhere near 1% of the framework (the attributes, Assert… and that’s pretty much it), since my projects are simply not that advanced… well, they are in terms of WPF, but NUnit has no inherit support for WPF-testing (a.k.a. VisualTree-walking).
• Rhino Mocks v. 3.5 – also a classic. I’m a huge fan of the new AAA style although I tend to apply it with StoryQ’s approach. Also, the new .AssertWasCalled combined with lambda expressions makes for really nicely condensed code. I have yet to find a better mocking framework.
• StoryQ – the new-comer. Basically StoryQ is a way for Acceptance-tests to make their way into your test-code. It plays well with NUnit and is a relatively light-weight API, that really lends well to minimizing the number of small interface-driving spec-tests. I was skeptical at first, but now, I’m convinced that it makes for better and more condensed code and also, to keep that red thread throughout my test-procedures making it far more readable.

Persistence

• NHibernate – also a classic. I started out using NHibernate when I started using ORM’s. I have yet to find a fatal flaw in the design. Usually it has been my ignorance that lead to the problems introduced. I’m currently reading NHibernate In Action (which has lead to a few realizations – more info on that later) and my usage is still far from ideal due to limited understanding of the architecture.

WPF

• WPF Toolkit – I use this sparringly due to a number of irritating errors in the implementations. I primarily use the DataGrid and the DatePicker. Sadly, it shines through that it is a glorified CTP-version out there.
• Prism – my favorite among the frameworks emerging for WPF. Very light-weight framework for supporting pluggable architectures. Some problems, of course, but 3-4 of the ideas are usefull out of the box and the rest only need minor tweaking.

IoC

• Windsor – most thoroughly tested. Feature-list is far beyond my skills as I use IoC mainly for Service Locating problems. I tend to favour fluent configuration and a static service locator for the small hobby’ish applications.
• Unity – MS’ try at IoC container. Have yet to find any bugs and is the default container in Prism – so usually end up using Unity while the project is in the early stages. Usually shift to Windsor when the going gets tough and I need run-time evaluation of services. Has the most annoying exception-handling of the IoC containers I’ve tried. Wrapping the exception every GD time it is rethrown… that just makes for dull debugging in VS.

I use other libraries, but so far they are easy come – easy go. They usually don’t end up staying. Going to attend a meeting comparing NHibernate and Entity Framework – very much looking forward to seeing the giraffe. Otherwise, my main focus will probably shift from Prism (pretty much exploiting every corner of it at the moment – so nothing much left to discover) towards a new series of Usability challenges. I will begin reading up on it and probably attend a few courses over the next 6-9 months. Very much looking forward to that. And I’ll try to keep you updated with my findings.

På engelsk:
I’ve decided to send GoblinCave the way of the lost bit. EconomyDeluxe will still be available for download, but updates will be scarce. The blog will continue to be online come next registration-date. The reasons are several but ultimately of no consequence for you as a reader. I can be reached at duckhero@gmail.com.

So long and thanks for all the fish.

UPDATE: Jeg har valgt at genoptage blogningen – jeg har fundet et emne, som det er værd at beskæftige mig lidt nærmere med. Mere info senere.

UPDATE: I’ve chosen to start blogging again – I’ve found a subject worth investigating further. More info to follow.