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.
Contents tagged with c#
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.
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.
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.
ElmahR reached v0.6, and a lot of improvements happened since previous version, most of them on the UI. Finally we had time to concentrate on the visual aspects of the dashboard, trying to come up with something more reactive, better at bringing the right information and at scaling along with the number of monitored applications. This last issue has been worrying us the most, it's not easy to accomodate the potentially quite big volume of info that ElmahR handles. We let ourselves be inspired by Twitter web site user experience, and we took advantage of the Twitter bootstrap framework to build a responsive layout. It is a very interesting framework, it allowed us to greatly improve how the dashboard looks like, and now we have better support of different form factors and browsers. Now IE9 is well supported too, while we still have problems with older versions, we'll try to target IE7 and IE8 in next iterations. Twitter bootstrap is quite simple, but it can also help deliver sophisticated UIs and to do that it can get pretty complex. We cannot really say we understood everything of it, but we also wanted to deliver soon, so we found a quite good and quick compromise analyzing a sample application and modifying it to our needs. You might notice it in the css files, one of them is still quite 'in progress' and it also contains stuff coming from the original sample and that we do not really use, but it's like that because we'll try to understand more of it in the next days.
Yesterday I blogged and twitted about the v0.5 release of ElmahR, and after a few retweets an amazing sequence of interactions started to happen! In the last 24 hours I received many retweets, new Twitter followers appeared and my tweet has been favorite by several people. The demo web site received hundreds of simulated errors (which actually helped me to spot at least 2 bugs :) ), my blog post has been visited by more than 400 unique visitors, and ElmahR repository has 4 new followers. And there's more, I became member of the Software Development list, and today ElmahR was on the home page of The Morning Brew, and in a very good company indeed! Those are not particularly big numbers for most of you, of course, but for me they are :)
In this short post belonging to the series about extending the world of Linq, I'll talk about an interesting way to leverage anonymous types through a pattern we use at work. We all know what they are, and we all know their most important limitation: once defined, an anonymous type cannot be passed to other functions or returned to the caller of the function which defined it (we are talking about language features, and we don't consider any technique based on reflection or other knowledge about the runtime internal structure of such types). It is quite common to write functions which return complex values, and if we want to make them reusable we need at some point to define some structure representing the result of the computation. We could use tuples, but they are not that good at communicating information, so we must surrender and define small DTOs just to represent those answers, just because anonymous type cannot cross the boundaries of a function. But is that completely true?