I like it... What is it?
ElmahR is my pet project, although I must say so far it's been much more successful than expected. It was really born as a playground to test and learn some new stuff, but it caught momentum, and it even received some contributions. It has about 30 forks on Bitbucket, and a few collateral projects using it or modding it have popped up. I'm pretty happy with all that :)
Thanks to a notification I received here, I discovered that ElmahR was not behaving well on Azure, Actually the problem is a little bit fuzzy, and it has to do with the exact sequence used to initialize SignalR bits, but anyway I found some detail about the problem and, after tweaking a bit the way ElmahR bootstrap, I was able to patch it and deploy a new 1.1.5 version on Nuget.
During the last few months I took a break from ElmahR, and I did not add any big new feature. I did some bug fixing and I added little things, but the last one I introduced in 1.1.0 is actually interesting, so I decided to talk a little bit about it.
Three months after my last port, this one is to announce that ElmahR has reached version 1.0! Last time I was not expecting such a long time to finish the latest "details", but some feedback I received (like this one) made me realized that I was still missing more modularity, and that has not been so easy to achieve. I had to deeply reorganize a lot of things in order to separate different concerns not only from a code perspective (that part was already fairly ok), but also from a packaging one. It's been though, but I'm very happy about what I achieved, and this allowed me to produce a set of new Nuget packages from which you can built a full ElmahR dashboard from scratch in Visual Studio, or add it to any existing monitoring application yo might have in place.
It's been almost one year since I started ElmahR, and it's been a long journey, with a lot of fun and learning: I added a lot of features, which are described in my blog posts about the project, and probably many others could be added, but I think I'm getting near to what I'll release as version 1.0. In the last weeks I did some cleanup to the plugin system (which is not yet as good as I'd like, but it's good enough for now), and I enabled some "startup" statistics which allowed me to send down to clients numbers that apply not only to the errors received since the connections, but to the whole errors history. This means that now both the numbers related to the errors grouped by type and the errors piechart reflect the whole persisted errors history, which I think is a more useful information.
I've been quite silent about ElmahR on my blog lately, but that was just because I was taking some more rest than I usually do, I needed it :) This does not mean I did not do anything on the project, actually I added at least 3 interesting new features.
So, lately I've been working on features that improve the way ElmahR help you in maintaining ElmahR itself healthy. Earlier I improved the way it notifies about error happening in ElmahR itself, and lately I added a new feature that allows you to see how many historical errors have been recorded for each monitored app. It also let you clean up those error offering a set of 'trash bin' buttons which give you a (hopefully) easy way to clear ranges of errors that are not interesting anymore. Each application box has a new icon like this:
Vacations are over, so I'm back working on ElmahR. In my previous post I already described what I've been doing to make ElmahR more robust, during the last weeks I've been going on developing those features. The most important feature I added is a new 'way' to launch an ElmahR dashboard. If you specify a
logparameter on the query string, and you give it a truthy value (
yes), like this:
I'm enjoying my vacations, and today I was having a nice, quiet and relaxing day at home, so at some point I said "there's no better day than today to fix some ElmahR bugs" :)
After the aspConf session I slowed down a little bit because I needed some rest, and right now I'm having some vacation, so my work on ElmahR is going on at a lower pace. As I mentioned in earlier posts and im my aspConf session, ElmahR is growing but it still needs some work to make it more error proof. ElmahR is about errors happening on monitored applications, but errors can happen inside ElmahR itself, no? In the latest days I started working on this particular aspect, and soon an ElmahR dashboard will be able to treat errors happening on the dashboard itself. You might think that this is not a problem: why didn't I just configure the dashboard to post errors to itself through ELMAH + ErrorPostModule? Well, that's possible of course, but it's also very easy to fall in cases where this scenario could generate endless loops of errors. Imagine you have a problem connecting to the database where errors are stored: when ElmahR receives a new error from a monitored source, it tries to store it and it fails, the error is intercepted, posted to ElmahR itself and received, then ElmahR will try to store this one too, and that will fail, and the loop starts again... A different approach is needed, and I begun to work on it. I already released some bits of it, but soon after my short vacation I will review a couple of details to make it cleaner, and I'll tell you more about the internals of this piece.
UPDATE: the recording of the session is now available on Channel9 here!
Last time I've been already mentioning the new Appharbor integration plugin I've been working on, but there's more to tell about it, mainly for two reasons: the plugin system deserves some more details, and along with the Appharbor plugin I completed a quite deep restructuring of the whole project, which actually makes much easier to start from a repository clone and build up a fully functional and customizable ElmahR installation with just a few clicks. Nothing is perfect, and actually these advantages come with a little more maintenance burden on my side, but so far I'm happy with it and when I'll have some more time I'll work on it. But first let's see more about the finished Appharbor plugin.
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.
I decided to have a post about things happening around ElmahR. Lately people around blogged or talked about it, and those interactions are, or have been, available on the web, here I'll just collect them for (my) future memory :)
ElmahR reached today 0.7.5, with more improvements in several areas. Let's see them very briefly.
As already mentioned, a few days ago @gsuttie offered his help in building Nuget packages for ElmahR. We discussed and agreed that the most meaningful place to start was a package to easily configure a source, and he did a good job coming out with a first version. But then I soon realized that it would have been much easier to have the process more integrated with ElmahR project itself, taking advantage of all the Nuget packaging features. So I took over the task and finalized it, and now an 'official' Nuget package is available!
Quick update about ElmahR. After preparing the ground to support persistence, and building errors persistence on top of it, I went a step further, enabling a first draft of a simple 'user settings' storage system. The functionality if really a basic one, what it does is just storing a guid in a persistent cookie, and using that guid to associate a bunch of setting to the current user and store them inside the same database used for errors persistence, provided the user activated the functionality ticking the corresponding option. The implementation itself is not really worth many words, what's maybe more worth noting is the fact that this work is been the preparation for something more useful like profiling 'real' users connecting to ElmahR through whatever authentication mechanism you'd want to use. In fact the idea here is to let user authentication as an external piece, letting implementors choose the most appropriate one or maybe even write their own ways to handle the problem, ElmahR will just leverage IIdentity interface and all the related concepts to store settings.
My work on ElmahR is going on, during the last few days I've been adding useful features which I'll describe here briefly. Then I'll spend a few words about what's going to become more and more important very soon: documentation.