mfbmina.dev

Hey guys, editing the post to say that after talking to some people, I noticed that I whole misunderstood how Go dependencies work, and I was expecting some feature that already kind of exists, since just what is used from the code is at the final binary! A special thanks to Laurent Demailly, from Gophers Slack, and to some Reddit users!

After many years working with Ruby, I migrate to Go without much experience with the language. My first friction was with dependency management because I always find it bad, with fuzzy commands and, the worst, without distinction between development and production dependencies, since both of them are included in the binary. Let’s take a look at a go.mod from a PoC:

One of my favorite features in Go is the possibility of writing benchmark tests. At Go 1.24, this feature has a new look, making it easier to use.

To demonstrate these changes, let’s suppose a function that calculates the factorial recursively and one that calculates it through loops.

func FatorialRecursive(n int) int {
  if n == 0 {
    return 1
  }

  return n * FatorialRecursive(n-1)
}

func FatorialLoop(n int) int {
  aux := 1
  for i := 1; i <= n; i++ {
    aux *= i
  }

  return aux
}

Previously, to write a benchmark, it was necessary to write down the whole execution loop of the test. When done, we need to run the command $ go test -bench .

After reading the book the Goal , I went after the next reading, and I was recommended to read The Mythical Man-Month, from Fred Brooks. This book is a computer science class, which I didn’t know yet, that describes the software development life cycle in the 70s.

The book’s main subject is told at the title: the mythical man-month. Man-month is a productivity metric like the ones that are used today, such as points, t-shirts size or whatever that is being used. The argument is the metric is failed and number of tasks, line of codes or features developed by someone aren’t constant between projects.

Nowadays, a huge part of a developer’s work consists in calling APIs, sometimes to integrate with a team within the company, sometimes to build an integration with a supplier.

The other big role in daily work is to write tests. Tests ensure (or should guarantee :D) that all the code written by us works on how it is expected and, therefore, it will not happen any surprises when the feature is running at production environment.

At the developing world, it is necessary to know how the application that you’re working on is behaving, and the most known way of doing that is by metrics. They can be of several types, such as performance, product, or health. Nowadays, Prometheus is the market way for collecting metrics.

It is an open-source service maintained by CNCF , the Cloud Native Computing Foundation. It works like the following: an endpoint is exposed, and it responds with a desired body format. Then Prometheus calls this endpoint time to time, collecting all the information from there.

At the end of 2023, my squad started its most important project. I assumed the project leadership role, organizing the project, coordinating the meetings, the release process, etc. At the first months, the project went well, as we took some hard decisions, proved a couple of concepts, and started the rollout for the first phase.

However, I always felt that I was holding the team back and being a bottleneck in the whole team. At a 1x1 with the head of the area, I told him about my frustration and got this answer back:

The first time I heard about RPC, I was in a distributed systems class while completing my bachelor’s in computer science. I like it but didn’t fully understand why I should use it instead of REST. Time passed, and I started working at a company where the legacy services use SOAP. I remember thinking: “hm, that’s cool! It is like RPC but using XML instead! Years later, I heard for the first time about gRPC, but I’ve never fully understood it until now!

When I chose to pursue a career in computer science when I was 15 years old, it was basically on liking math and physics. I want to distance myself from writing posts, essays, etc. Time goes by, and now, one of the things that I value at a mature company or team is the existence of technical documentation.

Docs help us to gain historical knowledge of our company, reevaluate decisions, and comprehend the trade-offs between all the decisions. It is also beneficial for the newcomers because it tells them a story. The richer in detail it is, the better it is.

Today it is common for our applications to have a couple of dependencies, especially when working in a microservice environment. It isn’t rare when our app reports errors, we find out that one dependency is down.

One good practice for improving our resilience is to shut down the communication with those apps that are not behaving well. Looking into other fields, we learned the concept of circuit breakers from electrical engineering, where a switch turns off when a failure happens. In Brazil, all houses have these switches that automatically shut down if our electric network becomes unstable.

Building a game is an excellent way of starting programming. Tons of people have started programming because they wanted to create computer games. Even me, back in 2010, had one of my first projects to write a small game when I was still in my Technician course.

In this course, we used Python to develop a slide puzzle. It was very challenging because I had to learn about the game mechanics and GUI, but I could handle the project. When I started to work with Ruby, I also built one to compare with what I did with Python.