Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In my previous article, I took a closer look at the Java ExecutorService interface and its implementations, with some focus on the Fork/Join framework and ThreadPerTaskExecutor. Today, I would like to take a step forward and check how well they behave when put under pressure. In short, I am going to make benchmarks, a lot of benchmarks.
All the code from below, and more, will be available in a dedicated GitHub repository.
Concurrency is one of the most complex problems we (developers) can face in our daily work. Additionally, it is also one of the most common problems that we may face while solving our day-to-day issues. The combination of both these factors is what truly makes concurrency and multithreading the most dangerous issues software engineers may encounter.
What is more, solving concurrency problems with low-level abstractions can be quite a cognitive challenge and lead to complex, nondeterministic errors. That is why most languages introduce higher-level abstractions that allow us to solve concurrency-related problems with relative ease and not spend time tweaking low-level switches.
In this text, the final summary of my categories theory series, I will use my spotlight and take a closer look at the relations between all three previously described functional containers, namely: Functor, Monad, and Applicative.
Below, you will find a comparison of them in terms of:
JetBrains IDEs based on the IntelliJ platform are probably one of the most common IDEs in existence nowadays. Their popularity is especially visible within the JVM languages community, where IntelliJ IDEA remains the right-away IDE pick for most developers. All of this is despite some new competitors showing up and old competitors overcoming their previous shortcomings and joining back the table.
In this text, I would like to describe the plugins for IntelliJ IDEA that may be a great help for you in your daily fight with your tasks, and that will make your work easier. Some plugins will be language agonistic, while others can be language dependent.
This part of the "Math Behind Software" series will be focused solely on math. I am going to present to you a few types of numbers that you can find all around and I bet that you never thought that they may even exist. Let's start with the Armstrong numbers.
In general, an Armstrong number (or narcissistic number) is a number n in a given number base (number of unique digits used to represent the number – the most common base currently is decimal system) b which can be expressed as a sum of its digits raised to the power of b.
In today’s text, I want to take a closer look at gRPC and REST, probably two of the most commonly used approaches for creating API nowadays.
I will start with a short characteristic of both tools — what they are and what they can offer. Then I will compare them according to seven categories, in my opinion, most crucial for modern-day systems.
I have already described how to secure a Spring Boot 2-based REST API with Keycloak here. Today, I would like to create a separate text with the same topic but for Spring Boot 3 — a newer, shiner version of Spring Boot.
Most of the Keycloak configuration and settings is one to one with the article for Spring Boot 2. I do not want to duplicate too much content so if anything is unclear I recommend going there.
Correctly evaluating model performance is a crucial task while working with machine learning. There are quite a few metrics that we may use to do so. That can be problematic for someone who just started the journey in this field — at least, it was for me.
I will start with describing concepts like true/false negatives/positives as they are the base for more complex metrics. Then I will mention and explain metrics like accuracy, precision, recall, or calibration error. I will also explain the basics behind the confusion matrix and a short code snippet on how to build one.
In today’s text, I will describe and explain OpenID Connect Flows. The processes of authentication are described in the OpenID Connect specification. As OpenID Connect is built upon OAuth, part of the concepts below will have the same meaning as in the case of OAuth.
Flow is the OpenID Connect counterpart of the OAuth Grant Type. It is a process of obtaining an Access Token. It describes the exact sequence of steps involved in handling a particular request. As a result, flow affects how applications involved in handling particular requests communicate with one another.
Although you probably know them already, I want to make a quick recap for everyone reading this to be on the same page.
In this part of the Math Behind Software series, I will be taking a closer look at a branch of mathematics known as queueing theory and its potential applications in the world of software engineering. I will describe some basics around the queueing theory, explain the basic laws from said theory and show you the equations which can be used to estimate queue throughput. I will end with a short example of calculating service capacity with all the things explained earlier. Let’s start with a quick recap of what was described in the previous part, which can be found here.
In the previous part of the series, I explained contention and coherency delay and their impact on the performance of our system. I brought up concepts like Amdahl’s Law, which is focused on measuring the impact of contention and Universal Scalability Law (Gunther’s Law) which additionally accounts for coherency delay. I described them and presented their equations. I also plotted graphs to show the difference in numbers between both Laws.
Today, I would like to try something new and start exploring the world of Python. In this article, I will present a step-by-step tutorial on how to implement a simple REST API using Python, Fast API, Hydra, and Mamba. Moreover, I will provide you with a short description on how to pack all these snakes into a single Docker image and make them work together. The whole code presented below is available on my GitHub.
Let’s start with a short paragraph on why I decided to choose this topic.
During the whole recruitment process, we are asked a lot of questions to prove our skills as software engineers. This is understandable, as each company wants to get the best employee to meet their — more or less sane — criteria.
It is equally understandable that we, as engineers, also want to work for the best companies out there. The “best” company means something different to each one of us, but no matter our criteria, we still need to work out a way to filter out the right companies or at least cross out the wrong ones.
Ah, writing chats. So simple yet so complex. Yes, writing chats — as in coding them, not chatting (though that might prove to be problematic too, but that’s a whole different problem). If you’re looking for a step-by-step tutorial on implementing the backend for a basic multichannel chat, read on.
So let’s dive into the technicalities. To give you some more details, the service will be implemented as a mix of a simple REST API and a Web Socket app. To make this more interesting, I decided to use Akka-related libraries and typed actors in as many numbers as possible.
In this article, I will tell you a few things about sharding and explain why it is actually an important technique.
Despite its significance, sharding also has some cons, and there are certain problems you may encounter if you decide to use it. What are they? I’ll explain that below.
Applicative is just another concept similar in meaning and history to Functors and Monads. I have covered these two in my previous articles, and I think it is finally time to start closing this little series about the most commonly known functional abstractions. Besides explaining some details and theory, I will implement a simple Applicative. I will also use Optional, hopefully one last time, to show what advantages Applicatives give us.
The source code for this article is available in GitHub repository.
In short, the CAP theorem is a mathematical theorem describing how our application will behave in the event of network partitioning. It is one of the most important laws currently in existence. Through the course of this text, I will share more information on this theorem and why it is important. By the time you’re done reading, you’ll also know why CAP may not be enough for modern-day systems.
Before we start, because the CAP theorem is inseparably related to distributed systems, I would like to add a quick word about them.
In general, a Functor is a concept originating from mathematics, to be exact from a part of mathematics called category theory. In my very first article, I described in detail a similar concept known as Monad. Here I want to continue that thread, so I will try to give you some more insight into Functors — what they are, how they work, and what the theory behind them is. I will also implement a simple functor to better understand how they work and why using them may be a clearer solution.
The source code for this article is available in GitHub repository.
