Two years ago, the folks released React version 18 and made changes to Strict Mode.

… React 18 introduces a new development-only check to Strict Mode. This new check will automatically unmount and remount every component, whenever a component mounts for the first time, …

A new toy has arrived - the Howard Leight Impact Pro headphones. Purchased on Amazon for 58 American dollars, which turned out to be practically half price. The headphones came in a box containing the headphones themselves, instructions, 2 batteries, and a cable for connecting to a phone or MP3 player. The headphones are made of solid dark plastic and look quite high-quality. They have a decent weight, but not too heavy to be cumbersome.

In the kitchen, the handle of my 3D-printed Geeetech MeCreator 2 broke, which was printed several years ago. I needed to set up my old Raspberry Pi 3 to print a new handle. To avoid using the printer directly, I decided to install OctoPi on it for easier control of the printing process.

There are various ways to install OctoPi, but I found the use of Raspberry Imager to be the quickest and most convenient.

With the development of web application architectural design, microservices have become a successful new trend in application landscape construction. Alongside advancements in application architecture, transport protocol methods such as REST and gRPC are becoming more efficient and faster. Additionally, containerization of microservices significantly contributes to flexible development and rapid delivery. Everything is evolving and embracing new principles and approaches. However, the question of how best to organize the project structure remains open. In this article, I will discuss two approaches to organizing project structure: monorepo and polyrepo.

I understand well that the topic has been discussed extensively on the internet, and the holy war between proponents and opponents of each approach shows no signs of abating. Nevertheless, I have decided to share my thoughts on this matter.

In recent years, microservices architectures have become extremely popular, and for good reason. When managed properly, they improve scalability, foster faster development and deployment, and reduce data and domain coupling. Companies of all sizes—from small startups to large enterprises—have been migrating their monolithic applications to microservices and service-oriented architectures.

However, transitioning from a monolith to microservices is a significant step. Your team needs to be prepared for this change both technically and organizationally. Without careful planning, an improper migration can lead to serious issues in the future.

Scaling applications and ensuring service availability are essential parts of any project, and at some stage of development, they become a necessity. Kubernetes is one of the tools that can address all these needs, but it comes with its costs — support and setup. However, in the end, it’s worth it for large projects. But what about small projects? To avoid using a sledgehammer to crack a nut, we decided to use Docker Swarm. It doesn’t require such hefty investments in support and setup but still allows scaling applications and ensuring high-level service availability. In this article, I’ll explain how to set up a Docker Swarm cluster and configure monitoring using Prometheus and Grafana with Slack notifications.

In our company, we have an internal application that utilizes MongoDB. The application consists of multiple microservices, each interacting with its own MongoDB instance. While the application doesn’t experience heavy loads, it’s critical for our business, so we need it to be resilient. Creating multiple MongoDB instances for each service seemed impractical and costly. Therefore, we opted for a unified resilient MongoDB cluster. Since we currently don’t require sharding, we’ll only be using MongoDB replicas. In this article, I’ll describe how I set up replicas in AWS using Docker and how we use them in our application.

I have been using GPG for a long time, but I never got around to setting it up in Apple Mail. There was always something more important. But recently, I finally did it. The main problem was that I couldn’t find a suitable solution for iOS. I haven’t solved this issue yet, but if I need to work with constantly encrypted content, I would rather use ProtonMail or Tutanota.

So, PGP allows you to sign and encrypt a message. The signature ensures that the message has not been altered after it was signed by the sender. Encryption ensures that the message will not be read by third parties. Signature and encryption can be used together or separately. I always enable the signature, and encryption only when necessary.