Forem: Juan Vega

A tip to get a nice git history: let git tell your code story

Juan Vega — Fri, 07 Jul 2023 11:03:56 +0000

If you're new to git, it can be overwhelming to manage your code changes and keep your git history clean. In this post, we'll explore some tips to help you get a nice git history that tells your code story effectively.

Avoid merge commits

Merge commits can make your git history messy and hard to follow. Instead, you can use git rebase to keep your git history linear and make it easier to understand. With git rebase, you can merge changes from one branch onto another and create a clean and concise git history.

All in one, interactive rebase

To use git rebase, you can use the interactive mode (-i) to squash multiple commits into a single commit with a new message. For example, you can run the command git rebase -i HEAD~3 to squash the last 4 commits into a new one with a new message. This will open up an editor where you can choose which commits to squash and edit the commit message. GitHub and GitLab also support squash and merge operation to create a single commit with all your Pull/Merge Request changes.

Use conventional commit

Conventional commit is a specification for adding human and machine-readable meaning to commit messages. By using a conventional commit format, you can make your commit messages more informative and easier to understand. To learn more about conventional commit, you can check out this post which explains what it is and how to use it effectively.

Convetional Commit: A meaningful commit message proposal

Juan Vega ・ Oct 14 '22

#tutorial #git

With these tips, you can create a clean and informative git history that tells the story of your code changes effectively. Happy coding!

cover from pexels

Convetional Commit: A meaningful commit message proposal

Juan Vega — Fri, 14 Oct 2022 12:09:13 +0000

Could you say how many commits the repositories you usually work with have altogether? I don't know, probably hundreds of thousands. Furthermore, most of them have a message that will never be read, but if you need to navigate the history. I ensure you will thank a clear structure with a concrete and explicit statement describing the commit purpose.

How do you write a commit?

What rules do you usually enforce while writing a commit message? Have you checked if all people on your team follow the same? And what about developers within your company or your tech stack community? I had never thought about this topic until I needed to navigate git history and package release looking for compatibility issues.

Of course, this is not something I invented or that only happened to me. If you have good versioning following SemVer supported by clear commit messages, you can easily detect breaking changes affecting a bug at first sight.

Let's agree on how to write a commit message

Based on the Angular community commit guidelines, we have Convetional Commits, a simple yet powerful specification to write clear messages for both automated tools and humans. I already talked about it in my last post:

Configure the release of your golang module with Github Actions

Juan Vega ・ Oct 9 ・ 2 min read

#go #tutorial #beginners

The idea is to have three sections within the commit headline and then a body and a footer of the message:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Please go and read the examples. You will notice how natural it feels.

Configure the release of your golang module with Github Actions

Juan Vega — Sun, 09 Oct 2022 17:44:12 +0000

Building and distributing a golang module is relatively easy. You need to create a GitHub repository and push your code. That's all, isn't it?

Not really. An adequately distributed module needs to be tagged and versioned so people can trust your module for production usage.

How do you decide when or how to bump your package version?

Luckily, you don't need to reinvent the wheel. Most packages inside and outside the golang community follow SemVer. TL;DR:

You have three numbers divided by a dot (.) -> 1.2.5
For changes that break the existing API, you change the first number
For changes that add new capabilities but don't affect existing ones, you change the second
For changes that fix existing behavior because of a bug, you change the third.

There are minor trade-offs and personal tastes that might change the practical application. Still, the core concepts are as simple as that 4 points, and with that foundation, the semantic-release package was created.

semantic-release / semantic-release

📦🚀 Fully automated version management and package publishing

📦🚀 semantic-release

Fully automated version management and package publishing

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification and communicating the impact of changes to consumers.

Trust us, this will change your workflow for the better. – egghead.io

Highlights

Fully automated release
Enforce Semantic Versioning specification
New features and fixes are immediately available to users
Notify maintainers and users of new releases
Use formalized commit message convention to document changes in the codebase
Publish on different distribution channels (such as npm dist-tags) based on git merges
Integrate with your continuous integration workflow
Avoid potential errors associated with manual releases
Support any package managers and languages via plugins
Simple and reusable configuration via shareable configurations
Support for npm package provenance that…

View on GitHub

Commit Convention

Using a proper commit convention is crucial for versioning and keeping an up-to-date change log easily. I have been using Convetional Commit for a few years. From my point of view, it is the easiest to adopt and manage with a great return on investment.

Check, how clean and clear the semantic-release git history feels.

Tag and release

Suppose you are using Convetional Commit, and you want proper semantic versioning. In that case, the best choice is the semantic release package.

At first sight, you might find it strange because the tool is written in JS, designed for the nodejs environment. Still, you can abstract those implementation details using GitHub and GitHub action.

Semantic Version with golang

The package will create a release and a tag on the GitHub repository. You can check an example on my go-again repository

You need both the GitHub Action configuration and the .releaserc file.



name: Release
on:
  push:
    branches:
      - main

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master
      - name: Release
        uses: codfish/semantic-release-action@v2.0.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

And the .releaserc



branches:
  - name: "main"

plugins:
  - "@semantic-release/commit-analyzer"
  - "@semantic-release/release-notes-generator"
  - "@semantic-release/GitHub"

Every time you merge or push a commit to the repository, you will get a new version following the conventional commit to semantic versioning:

fix: --> patch
feat --> minor
BREAKING CHANGES -> Major

The translation for commit type to semantic versioning bump is configurable using the commit-analyzer package

A golang library to retry operations with exponential backoff

Juan Vega — Fri, 30 Sep 2022 09:30:02 +0000

I have created go-again, a small library to retry operations using different timing algorithms. By default, it uses exponential backoff with a jitter to generate various delays for each retry.

jdvr / go-again

A set of utility algorithms to retry operations, again and again.

Go Again

A simple and configurable retry library for go, with exponential backoff, and constant delay support out of the box Inspired by backoff.

Features

Configurable delay calculation algorithm
Support for exponential backoff and constant delay out of the box
Support for generics
Simple and clean interface

There are two main concepts:

Retry: Given an operation and a ticks calculator keeps retrying until either permanent error or timeout happen
TicksCalculator: Provide delay for retryer to wait between retries

Examples:

Call an API using exponential backoff

package main
import (
    "context"
    "errors"
    "fmt"
    "net/http"

    "github.com/jdvr/go-again"
)


func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    apiResponse, err := again.Retry[*http.Response](ctx, func(ctx context.Context) (*http.Response, error) {
        fmt.Println("Running Operation")

…

View on GitHub

Retry any function using exponential backoff:



package main

import (

    "context"

    "errors"

    "fmt"

    "net/http"

<span class="s">"github.com/jdvr/go-again"</span>



)

func main() {

    ctx, cancel := context.WithCancel(context.Background())

    defer cancel()

<span class="n">apiResponse</span><span class="p">,</span> <span class="n">err</span> <span class="o">:=</span> <span class="n">again</span><span class="o">.</span><span class="n">Retry</span><span class="p">[</span><span class="o">*</span><span class="n">http</span><span class="o">.</span><span class="n">Response</span><span class="p">](</span><span class="n">ctx</span><span class="p">,</span> <span class="k">func</span><span class="p">(</span><span class="n">ctx</span> <span class="n">context</span><span class="o">.</span><span class="n">Context</span><span class="p">)</span> <span class="p">(</span><span class="o">*</span><span class="n">http</span><span class="o">.</span><span class="n">Response</span><span class="p">,</span> <span class="kt">error</span><span class="p">)</span> <span class="p">{</span>
    <span class="n">fmt</span><span class="o">.</span><span class="n">Println</span><span class="p">(</span><span class="s">"Running Operation"</span><span class="p">)</span>

    <span class="n">resp</span><span class="p">,</span> <span class="n">err</span> <span class="o">:=</span> <span class="n">http</span><span class="o">.</span><span class="n">DefaultClient</span><span class="o">.</span><span class="n">Get</span><span class="p">(</span><span class="s">"https://sameflaky.api/path"</span><span class="p">)</span>
    <span class="k">if</span> <span class="n">err</span> <span class="o">!=</span> <span class="no">nil</span> <span class="p">{</span>
        <span class="c">// operation will be retried</span>
        <span class="k">return</span> <span class="no">nil</span><span class="p">,</span> <span class="n">err</span>
    <span class="p">}</span>

    <span class="k">if</span> <span class="n">resp</span><span class="o">.</span><span class="n">StatusCode</span> <span class="o">==</span> <span class="n">http</span><span class="o">.</span><span class="n">StatusForbidden</span> <span class="p">{</span>
        <span class="c">// no more retries</span>
        <span class="k">return</span> <span class="no">nil</span><span class="p">,</span> <span class="n">again</span><span class="o">.</span><span class="n">NewPermanentError</span><span class="p">(</span><span class="n">errors</span><span class="o">.</span><span class="n">New</span><span class="p">(</span><span class="s">"no retry, permanent error"</span><span class="p">))</span>
    <span class="p">}</span>

    <span class="k">if</span> <span class="n">resp</span><span class="o">.</span><span class="n">StatusCode</span> <span class="o">&gt;</span> <span class="m">400</span> <span class="p">{</span>
        <span class="k">return</span> <span class="no">nil</span><span class="p">,</span> <span class="n">errors</span><span class="o">.</span><span class="n">New</span><span class="p">(</span><span class="s">"this will be retry"</span><span class="p">)</span>
    <span class="p">}</span>

    <span class="c">// do whatever you need with a valid response ...</span>

    <span class="k">return</span> <span class="n">resp</span><span class="p">,</span> <span class="no">nil</span> <span class="c">// no retry</span>
<span class="p">})</span>
<span class="k">if</span> <span class="n">err</span> <span class="o">!=</span> <span class="no">nil</span> <span class="p">{</span>
    <span class="nb">panic</span><span class="p">(</span><span class="n">err</span><span class="p">)</span>
<span class="p">}</span>

<span class="n">fmt</span><span class="o">.</span><span class="n">Printf</span><span class="p">(</span><span class="s">"Finished with response %v</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">apiResponse</span><span class="p">)</span>



}

Exponential backoff and jitter

Quoting Wikpedia about Exponential Backoff:

Exponential backoff is an algorithm that uses feedback to multiplicatively decrease the rate of some process to gradually find an acceptable rate.

The idea is to generate longer wait periods between each retry, assuming the system will work at some point because the issue is just a matter of time.

Suppose you have an API to get the user profile that might fail. In that case, you can introduce a retry function to keep trying the request, and this retry will wait longer between each period. Now imagine that your API crashed due to workload.

Backoff won't help. Although the request will be triggered with a delay period, all the clients follow the same algorithm with the same delays, so your workload issue is even worse.

The algorithm uses a jitter to solve the issue of the exact delays by generating a small random delay gap between different clients. Instead of having all clients waiting for 500ms, they pick a random number between 450 and 550, distributing the server workload wisely.

Go Again

I created this library for fun, but it is production ready, and of course, I will use it as soon as I have the opportunity. It is inspired by backoff, the library I am using now.

go-again goes beyond exponential backoff and offers another algorithm for a constant delay in case you want to keep it simple. Furthermore, you can define your own algorithm easily by implementing an interface.

Primeros pasos del testing en un proyecto Go

Juan Vega — Fri, 23 Sep 2022 17:28:36 +0000

This article is my opinion and it follows the just sharing principle.

Aunque go trae un runner de test en su toolchain,go test que funciona efectivamente bien. Las necesidades de un proyecto mediano o grande van más allá de hacer simplemente go test ./... y que lo ejecute todo. Si los test no son cómodos de usar, lo más probable es que se acaben dejando de lado y se ejecuten solamente en el servidor de CI haciendo los desarrollos cada vez más lentos.

La pirámide
El Sujeto
Posibles soluciones
Allanando el camino

La pirámide

Aunque no voy a usar un naming estricto, para intentar guiar los ejemplos voy a hablar de diferentes tipologías de test, para entender porque es importante tenerlos separados hay que tener un poco en mente la pirámide de test. Cada capa tiene un objetivo, un ciclo de feedback y validan diferentes partes del sistema.

Normalmente en otros lenguajes que he trabajado, suele haber (al menos) 3 grupos que se repiten siempre y que las diferentes herramientas soportan a aunque no siempre con el mismo nombre:

Acceptance (end to end): Test que van desde el punto más externo y expuesto del sistema hasta la parte más interna, ejemplo, Llamar al API expuesta para crear una entidad en la BBDD.
Integration: Testamos como algunas partes de nuestro sistema interactúan con elementos externos desde el punto de vista del sujeto del test. En ocasiones hay que incluso define integración dentro de un mismo proyecto, no voy a entrar en ese debate ahora mismo. Un ejemplo sería hacer un test del repositorio usando una base de datos en docker.
Unitarios: Igualmente no voy a entrar a definir que es la unidad, pero son los test que mejor aislados están desde el punto de vista del sujeto. Un ejemplo es tener un test que pruebe el algoritmo que usamos para calcular la puntuación de un partido.

Lo importante, más allá de definiciones para este post es tener claro que la jerarquía aquí la uso para definir que cada grupo tiene un ciclo de feedback más corto que el anterior, por ejemplo:

Acceptace: 10s
Integración: 3s
Unitarios: <100ms

Con esta premisa, la idea es tener una configuración que nos permita hacer uso de los diferentes niveles de información de forma cómoda y sin conflicto.

El sujeto

En los ejemplos me basaré en una función muy básica que simula una función para calcular el precio de un producto en función del stock que queda. He ignorado toda la gestión de errores por simplicidad.

func (calculator PriceCalculator) Calculate(product Product) float64 {
    stock := calculator.stockChecker.Check(product.ID)
    gap := stock.Gap()
    return product.BaseRate * gap
}

Voy a tener tres suite de test diferentes, una donde uso un doble de prueba para el stockChecker, otra donde incluyo una implementación real que se conecta a la base de datos para stockChecker, y por ultima uno donde simulo llamar a un API HTTP que usa el PriceCalculator por debajo. El detalle de como escribo cada test lo dejo para otro post. En resumen tendríamos tres test:

TestPriceCalculator_Calculate
TestPriceCalculatorIntegration
TestPriceCalculatorAPI

Tenemos que asumir lo que comenté más arriba. Cada test tarda al menos el doble o el tripe que el anterior, siendo el de más arriba el más rápido. Tenemos que buscar la forma de dividir los ciclos de feedback para mejorar la Developer Experience.

What is Developer Experience and why should we care?

Deepu K Sasidharan for Adyen ・ Jul 16 '21 ・ 6 min read

#devrel #engineering #discuss

Posibles soluciones

Convención de nombres

Una de las primeras opciones que me vino a la mente fue llegar a un consenso sobre el naming de los test. Hay soporte para esto en go test y lo uso habitualmente:

go test -run "regexp"

La opción -run evalúa todo los test del proyecto y ejecuta solo los que coinciden con la expresión definida.

Esta solución es valida y como digo la uso habitualmente cuando quiero ejecutar solo un test (o un grupo) de toda la suite y estoy usando el terminal. El problema principal es que no hay prácticamente costumbre de esto en la comunidad ni en mi empresa actual e iba a ser algo que explicar a cada nueva persona que se uniese.

Incluso por error se podían acabar mezclando suites, un simple typo en la palabra Integration y podría hacer que un test se fuese a otro grupo.

Build tags

Si pones un comentario al inicio de fichero usando la palabra +build lo que haces es declarar un build tag que indican al copilador y al runner de test que ese fichero pertenece a un grupo concreto.

En nuestro caso sería poner al principio de cada fichero de test algo parecido a

//go:build integration
---Ambas notaciones `+build` y `go:build` son validas.
//+build acceptance

Esta opción tiene algunos adeptos en la comunidad y se pueden encontrar post explicando como hay gente que los usa. El principal handicap para mi es que hay que tener bien configurado el IDE o puede resultar que tengas un test que no compila pero no te avisa porque esta fuera de las tags que esta mirando el IDE. Además, al igual que en la opción anterior, es sencillo dejar fuera un test por error o acabar con zombi code.

Cortos o largos, la solución de `go test`

La solución más común y la que finalmente he acabado adoptando por simplicidad a largo plazo. Valoro mucho tener algo que cualquier desarrollador Go puede heredar sin problemas.

Si no lo conoces entre los flags disponibles de go test tenemos -shot, ¿Qué hace -short veamoslo con un ejemplo?:

Si tenemos un test de integración:

func TestPriceCalculatorIntegration(t *testing.T) {
    // setup
    calculator := PriceCalculator{StockChecker: PostgreSQLStockChecker{}}
    // setup

    price := calculator.Calculate(Product{ID: "ASLSDFK000123"})

    // asserts
}

Tanto el setup como la ejecución del mismo puede ser lenta así que manualmente lo marcamos:

func TestPriceCalculatorIntegration(t *testing.T) {
    if testing.Short() {
        t.Skip()
    }

    // setup
    calculator := PriceCalculator{StockChecker: PostgreSQLStockChecker{}}
    // setup

    price := calculator.Calculate(Product{ID: "ASLSDFK000123"})

    // asserts
}

testing.Short() nos permite saber si el flag -short ha sido incluido en el comando go test, de forma que para el siguiente comando sería true:

go test -race -short ./...

De esta forma podemos generar dos ciclos de feedback, evidentemente esta opción tiene problemas:

Solo tienes dos niveles de test.
Alguien puede equivocarse al marcar un short
Por defecto, los test -short también se ejecutan al no incluir -short porque solo marcamos los lentos.

Aunque como menciono lo más relevante es que esta opción es la más común y la más conocida así que me parece la más eficaz.

Allanando el camino

Como hemos visto al final que test se ejecutan depende principalmente de los flag que hay en el comando go test, para facilitar esto normalmente utilizo Makefile de forma que simplemente con make test-unit o make test-integration se ejecuta el comando adecuado y el desarrollador no necesita recordar los flags.

Photo by Porapak Apichodilok from Pexels

Language and framework agnostic database migrations.

Juan Vega — Tue, 13 Sep 2022 12:16:12 +0000

It doesn't matter how simple your app is. If it needs a database, you will probably need a database (SQL) schema migration manager. I know other languages and frameworks bring schema management with the ORM, but what happens if you want to use plain SQL? I usually don't work with ORM.

We use Migrate because Go is our default language in Typeform. The following tutorial could work for any language or framework because the CLI works with SQL files.

The tool: Migrate

Migrate is a CLI and Golang library to manage migrations. One key feature is that migrations are plain SQL files.

The defined principles of the library follow the KISS:

Migrate reads migrations from sources and applies them in the correct order to a database.
Drivers are "dumb" migrate glues everything together and makes sure the logic is bulletproof. (Keeps the drivers lightweight, too.)
Database drivers don't assume things or try to correct user input. When in doubt, fail.

As it stands by the quoted principles, we will have:

A folder with SQL files.
Each migration is composed of two files: up and down.
Migrate CLI (migrate), among others, have two main commands: up and down.

The Setup: Your first migration

migrate the CLI tool brings a create command that will generate migrations files following a sequence of numbers.

docker run -v $PWD:/db migrate/migrate:v4.15.2 create -ext sql -dir db/migrations -seq create_users_table

The previous command will generate two SQL files inside db/migrations directory prefixed by 00001.

> ls db/migrations
000001_create_users_table.down.sql
000001_create_users_table.up.sql

You can run it multiple times to see how the prefix increases:

> ls db/migrations
000002_create_users_table.down.sql
000002_create_users_table.up.sql

But if you delete existing files, it will generate 0001 again. Of course, you won't manually delete migration files, but what happens if two dev are working at the same time and need a migration?. They will generate conflict migrations (same sequence number).

To mitigate this, although it doesn't fix it 100%, I generate migration files using epoch time as sequence number:

touch migrations/$(shell date '+%s')_$(name).up.sql
touch migrations/$(shell date '+%s')_$(name).down.sql

You now have a db folder with a migrations subfolder with two SQL files for one migration. To run the migration, you need to call migrate, but how do you make it reproducible for all environments?

Delivery migrations: Docker

Migrate projects builds its docker image, so delivering migration is nuts, we create db/Dockerfile:

FROM migrate/migrate:v4.15.2

COPY . .

ENTRYPOINT ["/run.sh"]

Start from their image, fixed version.
Copy all content of the db folder to the image
Set run.sh as the default entrypoint

The run.sh is a handy script to grab DB connection data from the environment and run any migrate command.

#!/usr/bin/env sh

set -e

# Grab DB config

DB_HOST=${DB_HOST:?}
DB_NAME=${DB_NAME:?}
DB_PASSWORD=${DB_PASSWORD:?}
DB_PORT=${DB_PORT:?}
DB_TIMEOUT=${DB_TIMEOUT:-10}
DB_USER=${DB_USER:?}

# wait for the database to be ready
for i in $(seq $DB_TIMEOUT) ; do
  echo "I am waiting for db to be read => $DB_HOST:$DB_PORT"
  if ! nc -z $DB_HOST $DB_PORT > /dev/null 2>&1; then
    sleep 1
  else
    break
  fi
done

echo "Running migrations"

# For this example I am using PostgreSQL
DB_URL="postgresql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}?sslmode=disable"

# Run the migrate cli include inside parent image.
migrate -verbose -path=./migrations -database=$DB_URL "$@"

Let's recap, inside the db directory, you have:

migrations with two SQL files with a dummy create table
Dockerfile, which defines an image starting from migrate and embedding migrations.
run.sh is a handy script to wrap migrate.

Run it: Docker Compose

Now that there is a Dockerfile, you can create a docker image to run anywhere. I will follow up with an example for a local setup using docker-compose.

version: '3'
services:
  database:
    image: 'postgres:14-alpine'
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: username
      POSTGRES_PASSWORD: password
      POSTGRES_DB: localdb
    volumes:
      - database:/var/lib/postgresql/data

  migrations:
    build:
      context: .
    command:
      - "up"
    environment:
      - DB_HOST=database
      - DB_NAME=localdb
      - DB_PORT=5432
      - DB_USER=username
      - DB_PASSWORD=password
    depends_on:
      - database


volumes:
  database:

Notice how we set the environment for migrations with DB parameters that will be read by run.sh.

So, with all setup to run your migration, you just need to run:

docker-compose run migrations up

Now you can check that the migration is applied:

> psql -U username -W -h localhost localdb
Password: 
psql (14.4, server 14.5)
Type "help" for help.

localdb=# select * from schema_migrations;
 version | dirty 
---------+-------
       1 | f
(1 row)

You can also test down command or any other migrate command running:

docker-compose run migrations down 1

It will apply down file and clean schema_migrations.

Recap

Migrate is an agnostic, easy-to-use yet powerful SQL schema migrations manager tool. You can set up the full flow with:

A folder with the SQL files
A docker image package with SQL with a proper entry point
Config to run the docker image.

You can find all code in my github: https://github.com/jdvr/migrate-template

I hope you find useful this small tutorial. How do you usually manage your migrations?

Photo by vishnudeep dixit from Pexels

Typeform Navigator: My Raycast Extension

Juan Vega — Mon, 05 Sep 2022 08:10:53 +0000

I discovered Raycast a few months ago, at first sight I notice the power of extensions. You can create automation and handy commands for everything.

I am a Software Engineer at Typeform, so my day to day use of the platform is sightly different to a standard user or customer. I have a lot of workspaces, some shared, some private and within them I have a lot of testing forms, each for every use case I usually work with. So, I have created Typeform Navigator.

Typeform Navigator

Typeform Navigator allows you to easily check form main stats, navigate to workspace page or to a form results page. There are other handy commands like copy form filling url or form ID.

Create a Raycast extension

Typeform Navigator is a nice example of raycast extension because it includes, listing, detail and it requires configuration (a personal token). You can found the source code on my github: jdvr/typeform-navigator.

Developer experience is a key advantage of Raycast you can check their Developer Documentation, starting a new extension is really easy.

The only pain point is publishing in on their storage because you need to create a pull request to their extensions repository.

If you are a Typeform user, test the extension and let me know what do you think.

The project was part of Hive Sprint, a two weeks hackathon where Typeform employees have freedom to spend time on any initiative that might improve the platform or the product.

DDD Europe 2022

Juan Vega — Sat, 30 Jul 2022 16:36:00 +0000

23rd and 24th of July, I attended for the first time to DDD Europe. I have been listening to good words about this conference for the last 4-5 years. My fellows had attended several times, and I was excited to go with them this time.

The Conference

Quoting Mathias Verraes:

DDD EU is the biggest DDD conference, followed by the DDD Foundations sibling conference.

Furthermore, the event is not just significant because of its number of attendees but also thanks to a lot of great speakers and how much content they have generated during all the past editions

Talks

I assume that they shared all talks in the video sooner or later. I will update the post with them. One important thing from the conference is how it goes deep into all aspects of DDD and not just tactical patterns.

An overview of the talks that I liked most:

Opening keynote: A Commune in the Ivory Tower? - A New Approach to Architecture

The first keynote was also an experiment with 5 speakers. They tried to create an interactive session, gathering feedback from the audience in real-time and giving voice to their responses and opinions.

I don't like it, but I appreciate the brave of trying something new.

An Introduction to Residuality Theory

Do you know Chaos Engineering? What if it wouldn't be necessary until having the whole system in production to evaluate what happens if component C dies.

Barry O'Reilly has created a theory to build resilient software by introducing different stressors into the system.

Once you have identified your stressor, you will know what is left and how it should behave to ensure the best outcome.

Domain-Driven Design in ProductLand

As himself defined, Alberto Brandolini created and got into a rabbit hole by speaking about how we can effectively apply DDD to a product company. How do we prioritize things? Which parts of the canonical DDD are still valid? How do you bring all domain experts if maybe some of them are outside of the company (customers)?

How the right architecture helps you make big changes

A hands-on workshop exemplifies how having a good architecture enables an easier refactor of the system when a new requirement arrives. You can find the base code with some instructions on GH

Technical Coaching with the Samman method

Emily Blanche is a great coach with a lot of experience and always shares her knowledge. This time he made an introduction to her own book about technical coaching.

Conclusion

In my experience, the community has embraced the idea of tactical patterns and parked aside all strategical patterns discussions. DDD Europe is just the opposite, there is room to talk about implementation details, but it is just a part of a whole.

On the other hand, I don't see it as a friendly conference for beginners. I haven't attended, but they created DDD Foundations probably because they already know.

It is a pleasure to have such a great conference here in Europe, and if you are a DDD enthusiast, I will encourage you to attend at least one.

Photo by DDD EU Twitter Account

JBCNConf 2022: A great farewell

Juan Vega — Sat, 23 Jul 2022 09:51:20 +0000

During the past few days (July 18th-20th), I have attended JBCNConf, Spain's biggest Java/JVM conference.

About the conference

Luckily I was able to attend thanks to the raffle of MadridJUG who gifted me a ticket, and Typeform which covered the cost. This edition was the last one around Java/JVM. Next year they will rename the conference to DevBcn to cover more topics.

It was my first year, but I think they had made a grand farewell, a conference with more than one thousand attendees, and a lot of talks (~100).

Although they titled the conference "Women in tech", and each room had the name of a famous woman engineer who contributed to the history of programming. I missed a bit more transparency on diversity matters. It is also my fault because I didn't ask them about the data. I went to several talks with women speakers, but I would say ~70% of speakers were men. I would highlight it as a point to improve on DevBcn

Talks

Here is the list of talks that I attended. I will not share all detailed notes but a small overview.

Artificial Intelligence needs Backend & DevOps to reach the real-world

Nerea Luis is a great communicator and speaker. She explained why MLOps is essential and how AI models and systems have been productized and need support from other roles (Backend, SRE, Security...) who already have experience shipping customer-focused software to extract the most of AI models.

She made mentions to ML-Ops and MLFlow including Vertex AI the GCP implementation. I will post the video as soon as it is available. In the meantime, you can enjoy any other talk from Nerea Luis

The hidden gems of distributed tracing

Ana-Maria Mihalceanu made a great talk with live coding on how to do distributed tracing using jaeger and opentelemetry. She explained how open telemetry tracing works and different sampling approaches. All the code is available at GitHub: https://github.com/ammbra/hidden-gems. At this talk, I also discovered RedHat Free Sanbox

Secrets of Performance Tuning Java on Kubernetes

A funny talk about the JVM heuristics to choose GC depending on available resources with a few takeaways:
We usually trust JVM to select a GC without knowing how it works.
Consider larger pods with higher throughput over more pods.
Avoid HA cargo cult that sometimes forces us to have multiple pods increasing our bill and leading to worse resource usage optimization.
Check the slides with all the data and quick-wins

Del final al principio: Un viaje guiado por métricas

Adrian and Alberto, two engineers from Wallapop, shared their experience building the saved searches feature. They journeyed from a very complex and high-cost solution to a more practical but still valid approach covering 80% of use cases with a reduced cost. From my point of view, talks that spread Real World™️ experiences are the most valuable.

Libera la potencia de tus aplicaciones con Micronaut y GraalVM

I worked with Micronaut back in 2019-2020, and I liked it but putting my taste aside, the work they are doing to enable full integration with GraalVM deserves a watch. Suppose you are a developer using Spring or Quarkus and haven't tested Micronaut. Give it a try. Alvaro Sánchez-Mariscal introduced a bit of the framework idea and GraalVM project and made a small demo.

Jakarta EE 10 Feature by Feature

I haven't used Jakarta (javax) in a while, so I decided to attend this talk to get a fresh picture of the current development. One thing I liked is the "Core Profile". It already existed, but they have included a lot of updates, and I like the idea of seeing Java runtimes keep moving to be smaller. You can see all the updates and features on the slides

Use Testing to Develop Better Software Faster

Every developer who writes tests as their day-to-day job knows that tests are as necessary as challenging to do and maintain in the right way. Sometimes wrong testing could become an obstacle to development. Marit Van Dijk shared examples and tips. I recommend reading her article on the topic.

Java Next - From Amber to Loom, from Panama to Valhalla

Similar to the talk about Jakarta, Nicolai Parlog (nipafx) puts together all the ongoing projects to push Java/JVM to the next level. I recommend checking the slides because it is full of resources. My favorites:
dev.java
inside.java
📼 The State of Project Loom with Ron Pressler
State Of Valhalla: Part 1, Part 2, and Part 3

The Hitchhiker’s Guide to a Great Developer Career

Helen and Sven gave a great talk about why it is important to have ownership over our careers. The content was great; they have outstanding delivery skills and are easy to listen to and follow.

Talent, passion, curiosity, cooperation and a special spirit for discovery

The closing keynote was a personal history from Javier Santaolalla about his experience at CERN where he participated in the experiment which led to the Higgs Boson discovery. It was a pleasure to listen to him and to see how hard he lived his profession and passion.

Conclusion

I enjoyed this conference a lot. After almost three years without attending any conference, I have been in DDD Europe and JBCNConf within a month, and I have felt again the motivation that usually comes after an event. I will update the post with videos whenever they are available.

Photo by EKATERINA BOLOVTSOVA from Pexels

Start doing better code reviews tomorrow: The emoji code

Juan Vega — Thu, 31 Mar 2022 15:30:11 +0000

One of the software engineer’s main activity nowadays is providing peer feedback about code, but giving written feedback is hard. You mainly face two issues:

Keep it short and straightforward.
Keep your intention clear.

It's all about your intention

We work with other people, and we usually don't want to hurt them or make them feel overwhelmed. To help here, and inspired by a Microsoft post, we introduced the emoji code for reviews within our team.

Make your comment intention crystal clear with an emoji.

At the beginning of each comment, you include an emoji that express your intention with that comment.

Our code

There are several public examples: Code Review Emoji Guide, My Code Review Emoji Guide and Emoji Code Review Comments. In my team we use the following one:

👍: I love this part and want to praise it!
❓: I have a question or need some insights to understand this part.
🐛: This is a potential bug. You must provide a detailed explanation and, if possible, a suggested change.
🤡: A matter of taste, it doesn't affect quality, but from the reviewer's point of view, it will improve code
💭: Not action required. I want to share a thought, to seed an idea for a future debate. Even not an answer is required.
♻️: Propose a refactor to simplify or improve a code block. The suggested change is required at least as pseudo-code.

It is short, and you can memorize it at first sight. Anyone can understand what it means, even without checking the legend.

Next step

You can start using this independently or start by proposing any of the existing examples to your team. Don't add too many emojis to the code. Make it easier to remember and be pragmatic.

Photo from Pexels

Become a better programmer in 30 minutes.

Juan Vega — Fri, 18 Feb 2022 06:54:49 +0000

Well, the title is a little tricky. It will take you 30 minutes every day, but I promise, it is effortless.

"I'm not a great programmer; I'm just a good programmer with great habits."
― Kent Beck

How do the first 30 minutes of your day usually look?

Like most software engineers, I usually spend over 60% of my workday (about 5 hours) coding. So taking away 30 minutes means nothing on the total time of the day and the project's whole time.

You might wonder "why the first 30 minutes and not the last, or somewhere in the middle?". Easy, the actions that I propose take much energy and focus when done well, so it's better to do them when you are still fresh!

My 30 minutes

All this practice works well for my current context and environment. You can start copying me and looking for new ones or adapted versions that fit you.

Self code reviews

I always start the day by doing a code review of the last code that I wrote. I asked myself what I was trying to achieve, how well the code expressed it, and what comments or clarification an external reviewer might need to understand my decisions. So, I have three steps:

What was the intention here? (Intention)
How well is the code expressing it? (Naming)
Which comments will help an external reviewer to understand it? (Comment)

Once I have answered the questions, I start again, using the answers to rethink intention, naming, and comments. For instance, I ask myself: How can I change code naming to include the value of the additional comment for an external reviewer?

Starting from scratch

There are always at least two ways of coding the same thing. A good exercise is to ask me every day: What if I use the other approach I discarded?

I don't implement it. I usually spend some minutes checking which file would change. The goal is to figure out if I could improve my current solution by evaluating it from another point of view. I might don't need to change a single line of code.

Among the previous exercise, I also wonder:

How much code do I write to solve the actual problem? Usually, the simpler the code is, the easier it will be to change if required. Sometimes we overcomplicate the solutions to cover future use cases that might never arrive.
Change some tests data and code pseudorandomly. I don't do mutation testing with an automated tool, but I manually delete some lines and change some inputs and expected values to verify how the tests break.

Do you dare to test this tomorrow and tell me how it well?

"No matter the circumstance you can always improve. You can always start improving with yourself. You can always start improving today."
― Kent Beck, Extreme Programming Explained: Embrace Change

References

Firstly, I hear from this practice, with a different approach, of reviewing previous day code from Carlos Blé

Photo by Ivan Samkov from Pexels

What should I choose Next.js or Remix?

Juan Vega — Tue, 15 Feb 2022 09:27:49 +0000

I want to rebuild my personal website, and I would like to take this as an opportunity to learn something new.

What should I learn Next.js or Remix?

I am a backend developer with a knee on the frontend, mainly React and Typescript. I don't want to learn Vue or any other framework right now.

I still need to pick a design, so if you have any suggestions.

I will keep sharing here my progress on building it.

Photo by Andres Ayrton from Pexels

Forem: Juan Vega

A tip to get a nice git history: let git tell your code story

Avoid merge commits

All in one, interactive rebase

Use conventional commit

Convetional Commit: A meaningful commit message proposal

Juan Vega ・ Oct 14 '22

Convetional Commit: A meaningful commit message proposal

How do you write a commit?

Let's agree on how to write a commit message

Configure the release of your golang module with Github Actions

Juan Vega ・ Oct 9 ・ 2 min read

Configure the release of your golang module with Github Actions

How do you decide when or how to bump your package version?

semantic-release / semantic-release

📦🚀 Fully automated version management and package publishing

📦🚀 semantic-release

Fully automated version management and package publishing

Highlights

Commit Convention

Tag and release

Semantic Version with golang

A golang library to retry operations with exponential backoff

jdvr / go-again

A set of utility algorithms to retry operations, again and again.

Go Again

Features

There are two main concepts:

Examples:

Call an API using exponential backoff

Exponential backoff and jitter

Go Again

Primeros pasos del testing en un proyecto Go

Table Of Contents

La pirámide

El sujeto

What is Developer Experience and why should we care?

Deepu K Sasidharan for Adyen ・ Jul 16 '21 ・ 6 min read

Posibles soluciones

Convención de nombres

Build tags

Cortos o largos, la solución de go test

Allanando el camino

Language and framework agnostic database migrations.

The tool: Migrate

The Setup: Your first migration

Delivery migrations: Docker

Run it: Docker Compose

Recap

Typeform Navigator: My Raycast Extension

Typeform Navigator

Create a Raycast extension

DDD Europe 2022

The Conference

Talks

Opening keynote: A Commune in the Ivory Tower? - A New Approach to Architecture

An Introduction to Residuality Theory

Domain-Driven Design in ProductLand

How the right architecture helps you make big changes

Technical Coaching with the Samman method

Conclusion

JBCNConf 2022: A great farewell

About the conference

Talks

Artificial Intelligence needs Backend & DevOps to reach the real-world

The hidden gems of distributed tracing

Secrets of Performance Tuning Java on Kubernetes

Del final al principio: Un viaje guiado por métricas

Libera la potencia de tus aplicaciones con Micronaut y GraalVM

Jakarta EE 10 Feature by Feature

Use Testing to Develop Better Software Faster

Java Next - From Amber to Loom, from Panama to Valhalla

The Hitchhiker’s Guide to a Great Developer Career

Talent, passion, curiosity, cooperation and a special spirit for discovery

Conclusion

Start doing better code reviews tomorrow: The emoji code

It's all about your intention

Our code

Next step

Become a better programmer in 30 minutes.

Cortos o largos, la solución de `go test`