This is Part 2 of the pprof series. If you’re new to pprof, start with Part 1: Quick Start. Last week I had a service that was “slow.” The recommendation endpoint was taking around 28ms per request. Not terrible, but not great either. Management wanted it faster. I could have guessed. Maybe the database? Maybe JSON serialization? Maybe string operations? All reasonable guesses. All probably wrong. So I profiled it. The results surprised me.

I spent two weeks optimizing a function that accounted for 0.3% of my program’s runtime. Meanwhile, a JSON unmarshaling call that ran in a loop was eating 45% of CPU time. I just didn’t know it. This happens more often than you’d think. We optimize based on gut feeling, not data. We assume the database query is slow. We assume the algorithm is the problem. We’re usually wrong. pprof is Go’s profiling tool.

Introduction In the Go programming ecosystem, developers have a plethora of libraries available for solving common problems. However, some libraries may not always be the best fit for every project or developer preference. This article highlights a few Go libraries that I personally avoid using, along with the reasons behind these choices. The intention is not to discourage the use of these libraries universally but to shed light on potential challenges that may arise when using them, especially in larger or more complex projects.

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.