Metrics.NET Update

Since March, i've been working on this Metrics.NET library.

I'm using it in a few production projects and i've become addicted to having everything measured and having the metrics information available when making decisions. Especialy when writing systems that are asyncronous where it's difficult to rely only on logging for understanding what is going one.

What it is

Metrics.NET library is a .NET Port, with lots of additional functionality, of the awesome Java metrics library by Coda Hale.

To paraphrase the Java library description - Metrics is a library which gives you unparalleled insight into what your code does in production. Metrics provides a powerful toolkit of ways to measure the behavior of critical components in your production environment.

The full description and documentation is available on the GitHub Wiki.

Plans for the future

For the near future, my focus will be on a solution for remote, persistent metrics. This includes the integration with Graphite/Ganglia/InfluxDb and maybe others. But for some odd reason none of this existing solutions runs on windows. Which is strange since they are all written in cross platform languages. We now run C# on unix, but we can't run go or python on windows.

And since I have to deal mostly with production running on windows I'm also considering storing metrics in the EventStore or even maybe in something like LMDB or Ayende's Voron. Or even postgres if it comes to that.

Any feedback, especialy on the public API of the library would be appreciated.

Metrics.NET

For the past couple of weeks I've been working on a new pet project, a .NET port of Coda Hale's Metrics library.

The Metrics.NET library provides a way of instrumenting applications with custom metrics (timers, historams, counters etc) that can be reported in various ways and can provide insights on what is happening inside a running application.

The library is published on NuGet can be installed with the following command:

Install-Package Metrics.NET

Supported runtimes: .NET 4.5.1, .NET 4.5, .NET 4.0, Mono 3.4.0 ( tested on OsX ).

The API of the library might change until a 1.X version will be made available.

Documentation:

Quick Usage Sample

public class SampleMetrics
{
    private readonly Timer timer = 
      Metric.Timer("Requests", SamplingType.FavourRecent, Unit.Requests);

    public void Request(int i)
    {
        // measure until disposed
        using (this.timer.NewContext()) 
        {
            // do some work
        }
    }
}

For more information on the library see the GitHub repository and the GitHub Wiki.

The Expert

I'm sure everybody felt like this expert at least some times. It makes me laugh and cry an laugh and cry...

Please share with everybody.

NodaTime - Coherent date time types for .NET

For the last two weeks I've been working on an internal project. Being a low risk project, I had the option of introducing new technology that was harder to introduce in other projects. I'm hoping to write a few posts about my experiences with NancyFx, EventStore & NodaTime, to name a few of the things I'm using.

One library I've been looking for a chance to try is the NodaTime library, written by the famous Jon Skeet.

The experience of using NodaTime in a few words:

  • extremely low learning curve
  • perfect API
  • everything is where you expected it to be and named as you expect it to be named

I can't say that I've experienced major issues with the native DateTime form .NET. But I have often felt that it is not a perfect match for representing a concept or not being clear enough in a public APIs. When trying to represent a particular day, or a time in a timezone or UTC the DateTime abstraction did not capture the full intent.

So far the most useful types for me from NodaTime have been: Instant & Duration.

Instant represents a specific point on a clear and unambiguous time axis. This is a common representation also found in other languages - like the time_t type in C - representing the number of ticks from the Unix epoch (January 1st 1970 00:00 UTC).

The "zero point" used everywhere in NodaTime is the Unix epoch: midnight at the start of January 1st 1970, UTC. (UTC itself did not exist in 1970, but that's another matter.)

Duration represents an exact number of ticks on the same time axis. This is similar to the TimeSpan type from .net.

I have also used a LocalDate type to represent a birth date.

As I've said I'm using Nancy to expose an HTTP API and EventStore for persistence. For moving data across this boundaries I'm using the awesome and now almost standard Json.NET library. My first worry was that I'm going to have to convert the types from NodaTime to and from a format supported by API and events consumers.

Almost as expected, I've found that NodaTime already provides a NuGet package for this. Flawless Json.NET serialisation is available by installing the NodaTime.Serialization.JsonNet package.

Conclusion

If you value the expressiveness and correctness of your code, I encourage you to give NodaTime a try. It risks becoming an addiction, but it is definitely worth it.

As a starting point continue reading the excellent User Guide for NodaTime.

In the end I'd like to thank Jon Skeet and the rest of the authors that made this awesome library available for the rest of us.

Moving to Jekyll

With hope that this will also mean writing more often, I've finally decided to move to a modern blogging platform.

Moving away from Wordpress

Wordpress is a mature blogging platform, full of extraordinary features. You get automatic updates, easy updates for plugins, nice interface to manage the whole thing and a lot of available plugins & themes.

Why move away from this?

It requires hosting, it is kinda slow and it is not exactly low ceremony.

Why Jekyll

  • You get to host it for free on Github pages.
  • You get to write markdown.
  • You get full control over the theme.
  • You are free to use modern web technologies.
  • You get to manage content with GIT.
  • It's low ceremony - write, commit & push to publish.

Update

I've finished migrating posts, and content to Jekyll. Even if some of the content required manual fiddling, it has not been a difficult experience. Now waiting for Google Webmaster's Tools to tell me what I've screwed up.

One thing I've noticed is that my blog now is blazing fast - which is normal, considering it's just a bunch of static web pages hosted on Github.