Programming *

All Prometheus metrics are based on time series - streams of timestamped values belonging to the same metric. Each time series is uniquely identified by its metric name and optional key-value pairs called labels. The metric name specifies some characteristics of the measured system, such as http_requests_total - the total number of received HTTP requests. In practice, you often will be interested in some subset of the values of a metric, for example, in the number of requests received by a particular endpoint; and here is where the labels come in handy. We can partition a metric by adding endpoint label and see the statics for a particular endpoint: http_requests_total{endpoint="api/status"}. Every metric has two automatically created labels: job_name and instance. We see their roles in the next section.

Prometheus provides a functional query language called PromQL. The result of the query might be evaluated to one of four types:

Scalar (aka float)

String (currently unused)

Instant Vector - a set of time series that have exactly one value per timestamp.

Range Vector - a set of time series that have a range of values between two timestamps.

At first glance, Instant Vector might look like an array, and Range Vector as a matrix.

If that would be the case, then a Range Vector for a single time series "downgrades" to an Instant Vector. However, that's not the case:

What is distributed tracing? Distributed tracing is a method used to profile and monitor applications, especially those built using a microservices architecture. Distributed tracing helps pinpoint where failures occur and what causes poor performance.

Let’s have a look at a simple prototype. A user fetches information about a shipment from `logistic` service. logistic service does some computation and fetches the data from a database. logistic service doesn’t know the actual status of the shipment, so it has to fetch the updated status from another service `tracking`. `tracking` service also needs to fetch the data from a database and to do some computation.

In the screenshot below, we see a whole life cycle of the request issued to `logistics` service:

This is the third part of a series covering the implementation of algorithms in Go. In this article, we discuss the Merge Interval algorithm. Usually, when you start learning algorithms you have to deal with some problems like finding the least common denominator or finding the next Fibonacci number. While these are indeed important problems, it is not something that we solve every day. What I like about the Merge Interval algorithm is that we apply it in our everyday life, usually without even noticing that we are solving an algorithmic problem.

Let's say that we need to organize a meeting for our team. We have three colleagues Jay, May, and Ray and their time schedule look as follows (a colored line represents an occupied timeslot):

This article is about security. I’ll focus on this in the context of web applications, but I’ll also touch on other types of applications. Before I describe approaches and frameworks, I want to tell you a story.

Background

Throughout my years working in the IT sphere, I’ve had the opportunity to work on projects in a variety of fields. Even though the process of authenticating requirements remained relatively consistent, methods of implementing the authorization mechanism tended to be quite different from project to project. Authorization had to be written practically from scratch for the specific goals of each project; we had to develop an architectural solution, then modify it with changing requirements, test it, etc. All this was considered a common process that developers could not avoid. Every time someone implemented a new architectural approach, we felt more and more that we should come up with a general approach that would cover the main authorization tasks and (most importantly) could be reused on other applications. This article takes a look at a generalized architectural approach to authorization based on an example of a developed framework.

Approaches to Creating a Framework

As usual, before developing something new, we need to decide what problems we’re trying to solve, how the framework will help us solve them, and whether or not there is already a solution to these issues. I’ll walk you through each step, starting with identifying issues and describing our desired solution.

We’re focusing on two styles of coding: imperative and declarative. Imperative style is about how to get a result; declarative is about what you want to get as a result.

It may seem that when you are a beginner, you'll do simple things only. No need to learn data structures and algorithms. No need to understand Big O notation, complexity and stuff like that. 

This couldn't be further away from the truth!

In 2008, when I just started learning to program, I spent a lot of time reading books on PHP and MySQL. Months later, when I felt confident, I took my first freelance project. It was a real estate website. A simple one. I used a custom-made ORM and everything worked just fine!

When I released it, the search feature quickly became sluggish and made the website unusable. 

I was wondering what the heck had happened. I figured out that database queries became very slow when there were over 200 real estate objects added to it. 

This is it. What worked fine during testing did not work in real life.

I was a self-taught developer. I did not know how to measure if my project scaled well. I didn't even know that I had to do it.

I thought algorithms mattered only for launching a spaceship.

If I had some basic understanding of algorithms, I would have known that the more the input, the longer it takes. 

I am not saying I would have come up with a robust solution as a junior, but I would have looked for a solution because I knew there would be a problem. 

Please, don't make the same mistake!

Of course, data structures and algorithms are much more than that and they apply differently depending on what you work on.

But a basic understanding of data structures and algorithms is a must for every software developer. 

"Come, let us make bricks, and burn them thoroughly."
– legendary builders

You may have noticed by 2020 that data is eating the world. And whenever any reasonable amount of data needs processing, a complicated multi-stage data processing pipeline will be involved.

At Bumble — the parent company operating Badoo and Bumble apps — we apply hundreds of data transforming steps while processing our data sources: a high volume of user-generated events, production databases and external systems. This all adds up to quite a complex system! And just as with any other engineering system, unless carefully maintained, pipelines tend to turn into a house of cards — failing daily, requiring manual data fixes and constant monitoring.

For this reason, I want to share certain good engineering practises with you, ones that make it possible to build scalable data processing pipelines from composable steps. While some engineers understand such rules intuitively, I had to learn them by doing, making mistakes, fixing, sweating and fixing things again…

So behold! I bring you my favourite Rules for Data Processing Pipeline Builders.

Let's consider the following problem: we have an array of integers and we need to find out the length of the smallest subarray the sum of which is no less than the target number. If we don't have such a subarray we shall return -1.

We can start with a naive approach and consider every possible subarray in the input:

Privet, comrads!

In this article i’ll show how easy it is to setup Spring Java app with Kafka message brocker. We will use docker containers for kafka zookeeper/brocker apps and configure plaintext authorization for access from both local and external net.

Link to final project on github can be picked up at the end of the article.

This article presents generalized approaches for using value converters into writing of XAML code.

>> Read in Russian

Introduction

rotor is a non-intrusive event loop friendly C++ actor micro framework, similar to its elder brothers like caf and sobjectizer. The new release came out under the flag of pluginization, which affects the entire lifetime of an actor.