Tagged: c# elmah signalr elmahr aspconf

Last time I blogged about ElmahR progress was less that 2 weeks ago, but to me it seemed much more than that, probably because I worked a lot on it, and amount of things I did made me feel those days have been longer. Most of the work I did has been 'behind the scenes' stuff, reorganizing projects and files in order to make room to new things, so if you will give it a try you will not notice big changes, but still there are a couple of new features, and the new structure will help a lot to build more of them.

But before going into details, I have to tell you that I'm really excited because I've been accepted as a speaker for the next aspConf! I'll be talking about ElmahR of course, but not because the project itself is really relevant, but because it's been a very interesting and challenging playground where to learn and experiment about what the ASP.NET platform and the web Open Source world give us today to build (hopefully) great and cool applications. If you feel you have a good idea, there is a lot of great stuff out there you can use to make it real, in my talk I'll try to expand on this showing those pieces in action inside ElmahR. It will be my first time as a speaker in a conference (and this is a BIG one), and I'll be surrounded by awesome speakers, I hope I won't be too bad. No pressure :) For more details go to the aspConf web site.

Appharbor integration

ElmahR is hosted on Appharbor infrastructure, which since the very first days has revealed as a very good place where to easily deploy it. Reading stuff about Appharbor platform I came to know a little more about their HTTP API, and one of the things I read made me think that I could build some more direct integration with their platform. ElmahR is about monitoring errors, and an errors normally implies building a solution for them and deploying it. Therefore I began finding interesting the way Appharbor allows you to configure a 'service hook' in your monitored application, in order to post info about how a build went when triggered. This way a dashboard user would know that a new version of the buggy app is available, and would therefore monitored it with different eyes :)

Looking at Appharbor docs it's been quite easy to build such a functionality, and now ElmahR supports this feature. Whenever your monitored application is hosted on Appharbor infrastructure, you can have the dashboard notified about build events related to that application, and have them displayed real-time inside the box associated to the source application. So far the implementation is quite basic, and most noticeable there is no persistence for build info events yet, but after some more code reorganization it should be quite easy to store them for future retrieval.

A plugin system, and related projects reorganization

ElmahR codebase it's always been very simple, we always had just a web application and a .NET assembly where the ErrorPostModule lives. But during the last week I reorganized it in a slightly more complex, but more flexible structure. Now most of the code of ElmahR moved in an assembly called ElmahR.Core, including things like the SignalR hub or the persistence system.

Why did I do this? I just told you about the Appharbor integration, that's indeed a very interesting feature, but to be honest I worked on it because it was a (good) excuse to find a way to build a plugin system into ElmahR. I started writing the new functionality first, and then working on it to extract it out in a way that I could get to the point where that piece becomes totally isolated to the rest of ElmahR, and easily pluggable, maybe soon with a Nuget package. And, by the way, that's the only way it would have made sense, having Appharbor related stuff hardcoded inside ElmahR would have been a too much strong statement, especially if your hosting platform is different. Reorganizing the code base has been a first step towards that goal, and having isolated ElmahR.Core helped with it, and it will in general do for future pluggable features.

I've been thinking a lot about how an ElmahR plugin should look like, and so far I identified 5 components:

• server-side endpoint: a plugin might set up an endpoint where external system would send messages
• server-side hub: if the plugin is not about errors, it might need to deliver real-time communications about different type of messages, therefore a new type of SignalR hub might be necessary
• client-side logic: the plugin might need javascript code to do its job on the client
• client-side rendering: ElmahR is a visual dashboard, so quite likely a plugin will need to emit appropriate (and possibly Knockoutjs-integrated) HTML
• client-side resources: images, css... those will be needed too!

Working on this vision, I refactored out most of the Appharbor stuff into a new assembly (ElmahR.Appharbor), containing a dedicated endpoint and a specific hub. I said 'most of it' and not 'everything' because the client-side stuff is still in the main ElmahR projects, but that's just a matter of a more general reorganization of the whole solution, which is pending since a while and I'll try to achieve soon. If we forget about this last tiny detail, the plugin system works just fine, and actually it's been a very interesting piece to develop because it allowed me to learn more about SignalR, which in this context I used in a less conventional way: a content distribution system. Curious about this? Next time... :)