devblog.avesse.net

A successful Git branching model » nvie.com.

Leveling Up: Career Advancement for Software Developers | Peter Lyons.

Some sound advice given here.

A quick thought, after I  just clicked a link on Facebook to a mobile YouTube video (http://m.youtube.com/watch?v=-T2UeKKac-s), and it ties in with my previous post on handling mobile/PC redirects.  YouTube gets it almost right.

My only gripe is that it did not automatically detect, from my User Agent string, that I’m on a PC.  However, it got the rest of the basics straight:

• Even though I arrived on the YouTube mobi site, there was a big and prominent link to view the same page in a desktop version.
• Being a geek, I didn’t notice the desktop link at first, and in stead, deleted the “m.” part of the URL, figuring it will (should) probably work.  By some miracle, it did.

Google, you’re doing it (almost) right.

They’re just not technically minded.  I read this article by @RianVDM yesterday (I suggest you do too) and it again struck home that we are developing software for normal humans, not for other developers, or even the IT crowd in general.  And we forget that, sometimes wilfully.

When responding to a recent bug report, we shook our heads in frustration when the user couldn’t respond to the simple question “Which version of Internet Explorer are you using?” (it was a corporate client, so the fact that they were using IE was a given).  Not only did they not know how to check the version, they didn’t understand the question.  It’s possible they didn’t even know they were using Internet Explorer (because that little blue “e” icon is called “The Internet”, not “Internet Explorer” or “my browser”).

It’s become quite common for us as developers to sneer and giggle at users who don’t know or understand things that we consider to be basic.  It’s easy when you’re surrounded by tech-savvy people, and even easier when you’re working in a dev shop and have little to no interaction with the non-tech crowd or the lay people who use what you build (developers are generally not hired for their people skills).

An epiphany of sorts

I recently had to provide training to one of our clients on an application we built for them.  It was something I really did not want to do, as I thought the interface should be intuitive enough for even non-geeks to figure out and besides, it’s not my job to deal with clients.  And initially I even weaselled out of it by making tutorial videos in stead.

They insisted, however and it turned out to be an extraordinarily valuable experience.   I’d recommend every developer does something like this at least once in a while, unpleasant as it may be – sit next to your users and watch them use your software.  It’ll make you cringe at first, but it made me realise:  My users are not stupid*; they just aren’t geeks.  Software is not their job, and the internet is not their hobby.

Watching normal people use our software made it instantly clear where and why they were getting confused, and enabled me to update the interface, make it easier to use and best of all,  improve myself as a developer.

*T’s&C’s apply

There’s been a lot of talk in our company around ORMs and the best data access strategy lately.  As .NET developers, we’ve grown accustomed to using ORM’s (whether it be Linq2Sql, EntityFramework or NHibernate (I assume it applies just as well to non-.NET ORMs)) for our domain model.  Sometimes the ORM classes would be extended and customized, but at the root the ORM “Model” always represented the “Domain Model” of the application.  I’ve even seen a couple of guides saying that an ORM negates the need for a data layer – the ORM is your data layer.

When ORMs went mainstream in the .NET world with the release of Linq2Sql, it completely blew my mind.  I learned later that it was not a new concept, with patterns like ActiveRecord being widely applied in other languages, but it was new to me.  For my whole development career up to that point (admittedly quite short) I had manually mapped relational database queries to their object counterparts using repeated, ugly and cumbersome code.  I clearly remember watching a video by Anders Hejlsberg – the main developer behind C# – around the mismatch of relational data vs classes and objects.  The problem presented was exactly the problem I faced.  The solution presented was perfect.  You can now treat your database rows, with all their related data, as native CLR objects and child objects.  “Mindblowingly awesome” could not describe it.

The benefits of going this route seems endless.  Refactoring becomes easier.  You reduce boring, repetitive boilerplate mapping code.  It’s even, dare I say it, elegant.

Since ORMs became mainstream in the .NET world with the release of Linq2Sql, the pattern of using ORM models (hand-coded POCOs or generated code) as the domain model of an application had become commonplace.  You’d find it in tutorials and guides from reputable websites, and everyone was doing it, so it must be best practice, right?  It was for a while, but with hard experience, issues started to creep in.

The dreaded Select N + 1 problem.

If  the phrase “Select N + 1” is new to you, start here (and keep googling). The main problem with an ORM model is that it gives you the illusion of an always-available hierarchy of objects that you can call at will.  That means you can loop over an object’s child properties, and it’ll just be there, thanks to the lazy-loading capabilities of most ORMs.

Which means, if you don’t consider the ORM when writing domain logic code, you have an ever-increasing number of trips to the database for each child entity, and the result can’t be cached, because the rest of the application depends on having that lazy-loading, get-it-if-I-need-it capability always being there.  The problem compounds when you have child entities numbering in the thousands.

Of course, you can use a LoadWith() method or something similar to specify which child entities should be loaded with the main object to solve this problem to some degree.

Blurring of application layers

But even if your data layer is optimised to load child entities when needed, you still have the unloaded child entities as exposed properties of your ‘main’ entity object, handing the incentive to another developer to load those child entities as needed.  And having to give consideration to these issues at a lower level defeats the purpose of treating your data model as native CLR objects in the first place.

Your ORM model is not your Domain Model

The conclusion I’ve come to is that, except in very simple cases, treating your ORM “model” as your domain model is a fundamentally bad idea.  Your ORM model is a very convenient representation of your database, nothing more.  Sure, you can abstract a little bit using inheritance hierarchies and class extensions, and configure your Repository to load the child entities you might need, but underneath it all, you’re still working with a relational database and SQL queries.   Using an immediate-feedback tool like MiniProfiler to see what goes on in the database makes that uncomfortably obvious.

Of course, chucking out the ORM pattern completely deprives you of many benefits.  An ORM gives you type-safe access to the database with no use of magic strings.  When using a type-safe language such as C#, changing the data model will tell you at compile-time where else you need to make changes.  And it just makes data-access code that much easier to write.

A solution?

So what I’ve started to do with new projects is to treat the ORM as a data-specific layer, similar to how you would treat data consumed from a web service.  There’s a separate layer dealing with the mapping logic, and you never expose the underlying data model.  It creates some extra work, but makes the rest of the application easier to write and more reliable.  It also means that if you decide to use stored procedures or some other custom data access logic code, it’s completely abstracted.

For anything vaguely complex, I find the latter of the following patterns desirable.

ORM-centered Pattern:

(ORM + business logic)  -> (UI/ORM mapping) -> UI

ORM-ignorant pattern:

ORM model -> (ORM/Domain model mapping)  -> Domain model + business logic  -> (UI/Domain model mapping) -> UI

What do you think?

Recently I had to implement some error logging on an old-ish ASMX SOAP web service.  Specifically, I wanted to get the stack trace for errors and the request input that caused them.  I’m told this is quite easy with WCF, but takes a bit of hackery with ASMX.

Initially I wanted to use Elmah because it’s super easy to set up and I use it in all my projects.  Unfortunately, ASP.NET  web services never fire Application_Error, which is where Elmah hooks in.  And I wasn’t going to wrap every method in a try/catch to log errors manually.

To intercept requests and responses as well as errors, you need to write a Soap Extension.  The Soap Extension then writes to the logging tool of your choice.  For this I used Log4Net, mostly because most of the log viewers are built for Log4Net and easy to configure for it (I quite like YALV, but there are many others).  Of course you can also log with Elmah, which I did for errors.

I used the template for a SoapExtension from MSDN and just plugged in the logging code in the appropriate places.  You can attach the SoapExtension by either using an attribute on the web service method you want to log, or you can register it in the web.config to log all requests.  I chose the latter, and configured Log4Net to use the XML Layout, since YALV (which I quite like) displays it nicely.

Get the Log4NetSoapExtension class and configuration here.

Just copy the Log4NetSoapExtension class to your project and add the config settings, and you’ve got a log of every SOAP request and response, as well as stack traces for errors.

From Content Modelling: A Master Skill:

On Developers:

Developers will need a greater level of detail in the content model. If the content strategist doesn’t provide them, the developers will interpret content needs and make up the details themselves. And they may not be in a position to keep in mind all the design requirements, as well as the needs of the content producers who will use the system.

On Content Authors and CMS Users:

It’s important to keep this audience in mind because they’ll be the ones working with the CMS each day. For their sake, try to keep the model intuitive, be consistent where there are similarities, and keep redundant activities to a minimum. Depending on how you set up the content model, you can make it easy for them to get their work done, or you can make them dread having to use the system.

Doing CMS development and design I’ve already learned some of these lessons the hard way. There’s much more to be done than just following a spec (much of it written based on assumptions or incomplete information).

It’s nothing short of amazing how many (major) sites get this wrong.  It’s one of those basic details that makes the difference between a smooth user experience and one that starts off with an annoyance.

Here’s what I think are some good rules to go buy:

1. The obvious

If I land on your desktop site with my phone, redirect me to your mobile site.  Most sites with mobile versions seem to do this, but this is not the most important redirect – mobile browsers generally know how to deal with content that wasn’t designed for them.

2. The not so obvious (it seems)

If I land on your mobile site when I’m at my PC, redirect me to your desktop site. Surprisingly many sites don’t do this, and I’m left to stare at a full 23-inch-wide screen of ugly 11px unwrapped text where most paragraphs don’t even make it onto a second line. And mobile sites don’t have much advertising, so you’re giving me a shittier experience that makes you less money.

I’m not picking on anyone in particular, but for a good example check out any mobile link on TimesLive.  Screenshots for posterity’s sake:

If you’re not sure about the browser, at the very least give me the option to switch (a link at the top will do).

3. Redirect me to a different version of the same page

Don’t redirect me to the home page. No, I’m not going to go look for that article. Besides, I’ve already forgotten the title of it. I’m tapping the back button and all you’ve accomplished is to waste a few bits of bandwidth and a couple of seconds of my precious time. Your CMS knows which article is being requested, and should be able to figure out the mobile URL.

That’s not so hard, is it?

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!