Introduction In this blog post, I want to share my approach to testing functions involving randomness in Go. Recently, I was asked how I would test a specific function that calculates possible directions for an object to move. Initially, I didn’t come up with a good idea. Here, I’ll discuss how I’d solve this problem in a real-world application with a detailed explanation. The Function in Question The function calculates all possible directions that an object can move (up, down, left, right) without violating boundaries.

Are you looking to dive into the world of Kubernetes and enhance your dev skills? Whether you’re gearing up for the Certified Kubernetes Application Developer (CKAD) exam or simply eager to experiment with Kubernetes, having your own cluster is invaluable. However, setting up a Kubernetes cluster for practice can be a daunting task, especially when the available options either fall short of expectations or are too complex for learning purposes.

The best to hash passwords in Go is using golang.org/x/crypto/bcrypt: func HashPassword(password string) (string, error) { bytes, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost) return string(bytes), err } func CheckPasswordHash(password, hash string) bool { err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password)) return err == nil } You should use the default bcrypt.DefaultCost just in case that the current value will become not sufficient and the default cost will increase.

We can trace NodeJS GC by using node --trace-gc app.js And use the performance tool to get the data in runtime. const { PerformanceObserver } = require('perf_hooks'); // Create a performance observer const obs = new PerformanceObserver((list) => { const entry = list.getEntries()[0] /* The entry would be an instance of PerformanceEntry containing metrics of garbage collection. For example: PerformanceEntry { name: 'gc', entryType: 'gc', startTime: 2820.567669, duration: 1.315709, kind: 1 } */ }); // Subscribe notifications of GCs obs.

Creating an organized code structure can be a complex endeavor. Previously, I penned a blog post entitled How to structure Go code?, an attempt to demystify this topic. While I stand by the insights shared, I’ve come to realize that the article is somewhat generic and lacks clear, tangible answers to the question at hand. There’s arguably no better way to understand such concepts than by diving into concrete examples. Today, I’d like to discuss the evolution of a package named productcatalog and explain why I chose to streamline its structure.

I’m excited to share with you my new project - an open-source e-commerce platform. The frontend is built with ReactJS and the backend is written in Go. Project Goals The goal of this project is to: Continuously improve and develop the platform. Provide an opportunity for less experienced programmers to gain experience working on a real project. Experiment with various methodologies and tools that may not be available in other work settings (event-driven architecture, DDD, event sourcing, and more).

One of tasks I was working on recently is related to password policies. Of course, everything is configurable in code right now. In this note I want to tell you about some my decisions and how I got to them. My first idea was creating an interface that any policy will have to satisfy. type PasswordPolicy interface { Verify(pass string) error } That make sense, doesn’t it? When I was working on specific policy implementation I had a feeling that the type doesn’t have to be an interface.

The memory wall problem refers to a phenomenon that occurs in computer architecture when the processor’s speed outpaces the rate at which data can be transferred to and from the memory system. As a result, the processor must wait for the data to be fetched from memory, which slows down its performance and limits its speed. The memory wall problem has become increasingly significant as processors have become faster and more powerful while memory speeds have not kept pace with these advancements.

The else keyword is a commonly used control structure in programming. It allows us to execute a block of code if a condition is not true. However, overusing else statements can lead to less readable and maintainable code. In this article, we’ll explore why we should avoid using else clauses in our code and look at some alternatives that can make our code more concise and readable. Why Overusing else is a Bad Idea One of the main arguments against using else statements is that they can make our code more complex and harder to read.

There are many practices and tactics that tackle testing. Today, I’ll share with you how I write tests for my projects. Please notice that you may find it useful when starting a new project or an independent part of existing applications. You may find it difficult to apply in an already existing application. It’s not impossible but it may be challenging. Table of content General rules for tests Works out of the box Single responsible As simple as possible Irrelevant code should be extracted How does the architecture of the package look like?