Random Code

Blog can now be accessed via http://randomcode.net.nz

Someone queried the NZ.NET mailing list yesterday about how to get the stack trace out of an exception logged via the NLog logging facility.

Having a quick look at the docs for layout renderers seemed to indicate that the ${exception} layout renderer, however by all accounts that wasn’t working so I’ve thrown together a couple of quick tests and a MonoRail site with Windsor integration enabled demonstrate how to achieve it and make sure it works. You can get the demo from the link below – it is a rar file but as WordPress won’t let me upload rar files, so I have changed the extension to .png. You will need to download it to your machine and change the file extension back to .rar to access the content.

Logging with NLog via Windsor

For those of you who just want to know what the configuration looks like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <targets>
            <target name="debugconsole" xsi:type="Console" layout="${message}"/>
            <target name="errorconsole" xsi:type="Console" layout="${message} [br] Details:${exception:format=type,message,stacktrace:separator=[br]}"/>
        </targets>
        <rules>
            <logger name="*" level="Debug" writeTo="debugconsole"/>
            <logger name="*" level="Error" writeTo="errorconsole"/>
        </rules>
    </nlog>
</configuration>

The targets are both console targets because I temporarily redirect Console.Out to a StringWriter so that I can capture and display the logged data.

Be aware that this demo is built against a copy of the Castle trunk from mid January (all referenced assemblies are included in the download), if you are not seeing the same behaviours in your code, it may be due to differences (or an issue) in the version you are using.

In early December of last year I started working on a new web application designed to simplify telephone-assisted exit interviews. I don’t quite remember my rationale, but I made the choice to build the system using MonoRail (probably something to do with 5 or so years of WebForm inflicted pain). 3 months later I have a system that allows the user to log in, view the list of pending surveys, edit various details about a survey or employee and fill in a questionnaire on behalf of an employee; doesn’t sound like much does it?

MonoRail is hard, don’t let anyone tell you any different. You have to download a bunch of stuff, set it up on your machine, learn some weird new syntax for writing your web pages, you don’t get intellisense in your webpages, there’s no nice server controls, no drag and dropping to build the UI, the documentation doesn’t always show you how to get things done and much much more.

Still reading? Still thinking you want to use MonoRail in your next project? Good! Everything I said in that last paragraph is true, however it doesn’t cover the whole story.

When I started out using MonoRail, I read about most people’s experiences and got a warm fuzzy feeling – they all tell you it is great; I want to inject a little bit of realism here, starting out with MonoRail is hard work.  The key thing with MonoRail is, once you know how to setup and build a MonoRail application, nothing changes (unless you runoff the trunk and Hammett goes and changes a bunch of stuff – but that’s your own fault and a story for another day). Compare that to WebForms; you get everything out of the box, you can build your first “useful” page in minutes and the learning curve is quite shallow (depending on how heavily you use the designer). There’s a gotcha hidden in there though, over the entire time I spent building WebForms applications, I rarely had a “pleasant” experience where things just worked and I didn’t have to spend at least some of my week fighting the framework.  I think the biggest difference between MonoRail and WebForms is how soon using it becomes “easy”.

3 months on I have a web application that does everything I mentioned above as well as:

• a suite of unit tests (82 and counting – time to investigate coverage) that cover everything except the final rendering step
• integration with a inversion of control container
• uses a repository to isolate persistence and a unit of work to manage persistence
• rolling file based logging
• email based exception notifications
• strongly typed view interfaces
• clean html that the designer loves to work with (thats designer in the human sense, not the drag n drop surface in your IDE)

Still doesn’t sound like much – maybe it isn’t but here’s the thing, in the past 3 months I have done all the learning I need to build a reasonably scalable and robust solution, that means my productivity will keep accelerating as I get better at dealing with the domain and the business problems (Ayende has talked about this before but I cannot find the specific post I had in mind).

At the end of the day, I am glad I made the switch to MonoRail, developing is fun once again and I get to concentrate on solving the bits of the problem that should be solved, rather than fighting with the framework I’ve chosen to implement the solution with.  Hopefully I have set some realistic expectations about the initial investment required to get going with MonoRail, and given you an indication that the investment is well worth the gains in the end.

Yes, that ubiquitous statement that indicates a novice (developer) is playing with a new technology. I have a stack of concepts for posts sitting half typed up in text files on my desktop (all based around my current experiences with MonoRail / Windsor / TDD / DDD) so keep checking back, there will be some real content here soon