Serilog is a great tool to write structured log messages. To fully profit from the structured part you need to write your log messages in a certain way. Otherwise you lose most of the great features and could use any other traditional logging framework. Luckily there are only a few simple things you should keep in mind and I will show you today what those are.
As I explained in the last posts, log messages are not just strings but have an inner meaning. When we use Serilog to write structured log messages we make them explicit to query them later. The tool we want to use to search for a specific orderId should give us this capability without the need to write all the code from scratch. We therefore need a tool that understands log messages and, if possible, even Serilog. One such tool is Seq that I explain in this blog post.
As I explained in the last post, creating JSON documents with Serilog is easy. But to make something useful with the log messages we must be able to query them. When I think about storing JSON documents then RavenDB is the first system that comes to my mind.
As a .Net developer you can choose from a variety of logging frameworks. All are more or less built to mitigate the shortcomings of the built in tracing framework. While System.Diagnostics.Trace has some helpful concepts, it misses many basic features most other logging frameworks can offer out of the box.
Log files could be a great place to find the answer on what went wrong in our applications. They should contain all the necessary information to understand the state of the application before and while the error happened. Instead most log files are giant collections of data without much structure and even less meaning. What is unfortunate in one single application is a problem as soon as multiple applications need to work together.
As a little distraction from writing I was procrastinating on Hacker News and Reddit. The blog post “Why are we interviewing Developers by asking Architect questions?” caught my attention and got me thinking about the term "maintenance developer". Those mythical species of developers who are so insisting that their work is so fundamentally different from all other things that developers do. As Ted Winslow points out they should not need to know anything about architecture. Others think they don’t influence the code and therefore don’t need training. Visiting a conference is a waste of time, then all they do is maintenance…
Geofences are a nice feature that can help you to focus on important things based on your location. At work you care for other things than in the supermarket. Showing your groceries list is a help there, but at work it's a distraction at best. Applications that support geofencing can help us when the technology is used wisely.
This year's NDC Oslo was once more a remarkable conference. Great speakers doing 9 parallel tracks for 3 days crated an enormous amount of content. So far I can give you an overview on the sessions I attended. It will take me some time to catch up on all the other sessions I want to watch. Those sessions will be part of another post in a few weeks.
The videos of the NDC can be found on Vimeo. I can highly recommend the presentations I mention in this post. With many more to watch I'm happy for any recommendations.
The next version of RavenDB will have some exiting new features. Beside many optimisations, improvements and new functionality you will get a new RavenDB Management Studio. Dropping Silverlight is only one of many improvements you will notice. Let's have a look on what is changed and how much still works as expected.
Dogfooding, as in use your own software, is a great way to find the pain points in your product. When you build a project management tool you could track its progress within that tool. If you are annoyed to insert the same values over and over again so might be your users. To improve this small part not only makes your life easier, but also helps the other users.