Date archives "March 2016"

A few days ago I’ve gave it a shot and posted a link to my project on the reddit. Amongst some positive comments, there was this 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.Continue reading →

CQS stands for the command query separation. There’s a chance that you may have not heard about it, but on the other hand the CQRS might ring a bell. Even though these 2 patterns have very much in common, there is a significant difference (definitely a bigger one than the additional “R” character within the CQRS acronym) in how do they apply to the architecture of our system. In this post I’ll focus on the CQS – the older brother of the CQRS – that will help you understand how to design the software that is less error prone.Continue reading →

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.Continue reading →

For over a year, I’ve been working (after hours of course) with a friend of mine on the application called Fortitudo (42.do).
What is is exactly? Well, it’s a mobile application (Android for now, the web version lacks functionality and is just a prototype) that will help you track your training progress. There’s a list of training plans that you can choose from and then generate a training plan that is suited to your needs. You may edit that plan, save your progress, add new personal bests and even create your own training plans using our specialized editor (yes, I’ve created a kind of the DSL for that occasion). Have a look at our website at https://42.do, like our fanpage and follow our Twitter. Oh, and do not forget to subscribe to our newsletter! 🙂

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.Continue reading →

In one of my previous posts (which you can read here), I’ve told about my feelings for the repository pattern. Complaining about something is one thing (please, don’t even try to tell me, that you have never seen some piece of code, that made you cry like a baby), however, if we want to (pretend to) be professionalists, it is very important to come up with some ideas in order to solve the given problem (at least partially). In this post, I’ll present to you one of my solutions to the commonly misused repository pattern (especially on the querying side).

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):