Eventually, I’ve decided to change the name of my library called Sentry to the Warden. Why? Mostly due to the fact that there’s already a big service called Sentry and I don’t want to use the same name. To be honest, I was aware of that fact since the inception of my project, yet I’ve decided not to do anything about it. What has changed my mind? Mostly other user comments that maybe it would be wise to rename the project – so I did.
Immutability is a quite old concept that is mostly related to the functional programming, however, it’s also (maybe not so widely) used in the object oriented programming.
An immutable variable/object can not be mutated, which means that once it’s been initialized it will never change it’s original value/reference (unless it’s deallocated).
This approach results in some great benefits such as out of the box thread safety, yet in the OOP world, it does seem to be quite often abused or even not used at all. When should we make use of the immutability? Are there some variations of this approach? How to make immutable objects in C#? Let’s find out.
If you’re looking for a simple service for monitoring your MongoDB (things like opening a connection to the database or executing a query and processing the results), then you might find interesting a new type of the watcher added to the Sentry. The MongoDB watcher uses the C# MongoDB Driver under the hood but it’s been implemented in a way, that it’s possible to provide any driver that you’d like.
In this post I’ll present how to use it and why it’s been implemented this way instead of another one.
I would never use a library that is not documented at all
Although it was the very first version of the Sentry, a typical preview & work in progress thingy (which I did forget to mention in my post), I’ve realized that it’s high time to provide some form of documentation, otherwise why would anyone use that library, even if it was making a miracles? I thought that maybe the already existing default readme.md file with a brief decription of the project and code samples + very modest wikipage would be good enough for some time… oh boy I couldn’t be more wrong.
Recently I’ve had this idea that came into my mind while working on the Sentry – let the users of my library (if there will be any) to configure not only the set of rules, connection strings, urls etc. but also the underlying providers that do all of the heavy lifting (e.g. the HttpClient responsible for communicating with the API). It means that as long as you’re not satisfied with the default solution, please feel free to provide your own engine that will for example talk to the database and perform a query on it. And that’s one part of the story, however, even the more important thing to do was to test that behavior – I had to be sure that would work. So how can we test the classes (I’m talking mostly about the integration testing), that hardly implementy any interface (pretty much none) such as the mentioned above HttpClient? Actually it turned out to be quite simple with the usage of the Wrapper pattern.
Behavior-driven development (BDD) is a process of developing the software that has evolved from the TDD (test-driven development). We can think of a BDD such as the feature driven approach to the TDD. The main advantage of the BDD over the TDD is the way the tests are being written, in a form of the story that can be understood both by the developers and the customers. In short, we can simply state that the BDD is the TDD done right – it makes use of the so called ubiquitous language which is the core part of the domain and the concepts presented by the customers (domain experts). In this text, I’ll present how you can start using the BDD approach in your code and the general idea behind that. We will start with our simple “framework” and then proceed to the MSpec (yet there are other great libraries such as the SpecsFor or NSpec and even more of them). In the examples below, I’ll be using the NUnit as the testing framework and the Moq as the mocking framework. As for the tests itself, they will be the real live examples from my open source project called Sentry.
The new type of the watcher for the API monitoring is already available. Actually, it has much in common with the website watcher (very akin configuration, and under the hood uses the HttpClient as well), however it does serve a different purpose, which is making the request to the API and validating its response, whereas the website watcher basically pings the given url (well, it can validate its response too), and does not really care about any other HTTP method different than GET. In this POST (did you get the joke?), I’ll present how to use the API watcher with the help of code examples.
In today’s post, I’ll describe what kind of interfaces have been defined in the Sentry project, and how you can take advantage of this knowledge, e.g. in order to create the custom metrics.
I’ve tried to keep these interfaces as simple as possible, yet some of them require an explanation, mostly due to the fact, that even though the library itself is rather simple to use (I want to believe that it’s also what you think), it does not mean that the main methods when being executed, will return for example, a single boolean value that doesn’t really say much about what just happened.
After a few days of a quite intensive coding, I’ve managed to implement the first, basic version of the Sentry project and its API, along with a few (by this I mean 2) fully functional examples. I’ll use the website and MSSQL “watchers”, as these are the only ones that are currently working, however there’s many more coming in the near future. Let’s dive into the code already, as it usually speaks for itself.
The time has come to describe the project that I’ll be working on for the next few (10?) weeks. I’ve named it Sentry, and here’s the brief description (yes, I’m lazy and it’s a copy-paste from the GitHub):
Define “health checks” for your applications, resources and infrastructure. Keep your sentry on the watch.