Backbone & underscore beauty

Recently I’ve joined a project which is based on the Single Page Application paradigm. This means no page refreshes after the first load, after login and a plenty of client side scripting. To enhance the project speed a stack of client side libraries is used including, RequireJS (for module management), Underscore, Backbone and Backbone Marionette. There are more of them, but the last three are very interesting because of their paradigm.

Underscore, Backbone and Marionette are not frameworks. They are libraries, great libraries providing a few tools to deal with a web app development. They do not make you to use all of they features components (as ‘features’ are overloaded, framework term). You can pick wisely and use only a few of the provided tools. Of course there is a risk of creating a monster, an unusable app, but it’s up to you and your paradigms, what to use and what to implement on your own. Strongly encourage you to get accustomed to them, especially all of them have a beatiful common denominator, they provide the annotated codebase (code as documentation) which can be found here: Underscore, Backbone, Marionette.

Use libraries, don’t let frameworks use you!

Enhancing log4net exception logging

Using a library like log4net is surely helpful in your day to day app development. One of the most important cases where an entry should be logged is an application exception occurring on the production environment. It’s quite common to use Windows’ event logs as a storage for log entries and log4net has a special appender which is used in this cases called simply EventLogAppender. All it does by default is appending an entry to the Application event log using a parametrized event source name. It does not set an event id or a category of the entry, disabling a simple querying of entries by this param. There are imperative ways of adding one, like by adding an element EventID or Category to a dictionary log4net.ThreadContext.Properties. This makes you either wrap each call to log4net with a proxy (it’s useful and may be used in your project) or pollute your code with plenty of a logging logic. Can it be done in another way?

Filter to the rescue
It’s not quite hard to provide a better, separated way of enhancing your log entries on the information based on the exception object being thrown. One of them is using a filter, which has an ability to access an exception by a LoggingEvent instance. A simple code of doing it can be found in the following gist.

As you can see, the consts of EventID and Category are stored in the filter’s implementation as the original EventLogAppender uses inline consts to check them. Once their added they will be used by the mentioned EventLogAppender to mark the given entries with EventId and Category. The logic of determining them is up to you. You can hash the exception stacktrace, use an exception’s source property or something else. At the very end remember to add this filter to your appender. Happy logging! 😉