Blog about software development

This blog has been started 4 months ago on the 27th of May, 2018. My first post was post about new machine learning framework from Microsoft called ML.NET ( this ). It was my first time ever starting any blog! And yesterday this blog has reached a mark of 20,000 page views. It took a 4 months and 7 posts :) If you are reading this, I want to say you: "Thank you for your visit!". I hope you have found some of my posts interesting and will get back in the future :)

Quick Summary In this post, I will show you how to easily build and deploy a simple TicksToDate time web app like this: https://zubialevich.github.io/ticks-to-datetime .

All minor changes in Rest API should be backward compatible. A service that is exposing its interface to internal or/and external clients should always be backward compatible between major releases. A release of a new API version is a very rare thing. Usually, a release of a new API version means some global breaking changes with a solid refactoring or change of business logic, models, classes and requests. In most of the cases, changes are not so drastic and should still work for existing clients that haven't yet implemented a new contract. So how to ensure that a Rest API doesn't break backward compatibility?

One of the easiest and most popular ways to increase system performance is to use caching. When we introduce caching, we automatically duplicate our data. It's very important to keep your cache and data source in sync (more or less, depends on the requirements of your system) whenever changes occur in the system. In this article, we will go through the most common cache synchronization strategies, their advantages, and disadvantages, and also popular use cases.

  The first not serious rule of programming says: "don't touch if it works". It means that you should not spend much time checking things that proved to be reliable in a working system. But sometimes things can go wrong.