Hi there, I’m Firmino Changani and I have been working as a Software Engineer since 2014.

I currently work as a Senior Software Engineer at GetHarley, a UK-based startup in the skincare space, but before that I worked for Mercedes Benz as a Software Engineer.

I enjoy working on product-oriented teams, building side projects, writing about subjects I find interesting and I do enjoy running 🏃‍♂️.

Moreover, often if/elses and regular expressions tend to be naive approaches to such a problem.

In Go, one shall avoid code such as the one written below because it’s ugly, complex, hard to maintain, and it isn’t even effective at validating perfectly valid email addresses.

1var pattern = regexp.MustCompile("^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$")

Instead one is provided with the package net/mail, which has a function to parse email addresses based on the RFC 5322, and here is how one can leverage it:

 1package main
 2
 3import (
 4	"fmt"
 5	"net/mail"
 6)
 7
 8func main() {
 9	err := validateEmail("tim.cookapple.com")
10	if err != nil {
11		fmt.Println(err)
12		return
13	}
14}
15
16func validateEmail(address string) error {
17	_, err := mail.ParseAddress(address)
18	if err != nil {
19		return err
20	}
21
22	return nil
23}

> mail: missing '@' or angle-addr

What if one still wants to write an email validator from scratch?

That’s a reasonable question for the sake of learning or any other reason one might have. That being said I recommend starting with the following resources:

• Email address: this Wikipedia article is a good starting point because it’s rather practical and succinct.
• RFC 5322: in this RFC one should expect to learn about the formal specification about the standard syntax of an email address.
• net/mail’s implementation: implementation details matter.

 1package main
 2
 3type User struct {
 4    lastUpdatedAt *time.Time
 5}
 6
 7func main() {
 8    lastUpdatedAt := time.Now()
 9    user := User{
10        lastUpdatedAt: &lastUpdatedAt
11    }
12}

Even though the approach displayed above works just fine it still ends up requiring the initialisation of a variable that potentially won’t be used anywhere, and perhaps for the use-case above one would be better off by performing an inline conversion of the intended value to a pointer.

What I do and rather often, is to write a function that will receive anything and return that same thing as a pointer, here is how I express it in code:

1package main
2
3func ToPtr[T any](value T) *T {
4	return &value
5}

Here is the initial example rewritten with such a function:

 1package main
 2
 3type User struct {
 4    lastUpdatedAt *time.Time
 5}
 6
 7func main() {
 8    user := User{
 9        lastUpdatedAt: ToPtr(time.Now())
10    }
11}

And that’s all, thanks for passing by.

1BEGIN;
2
3SELECT * FROM urls
4FOR UPDATE
5SKIP LOCKED
6LIMIT 100;
7
8END;

The key to achieve such skip, is to first ensure that the rows to be queried will actually be locked, hence the FOR UPDATE clause, and then the SKIP LOCKED clause to prevent the query from waiting for the RDBMS to release the locks that another query might have acquired.

With SKIP LOCKED, any selected rows that cannot be immediately locked are skipped. Skipping locked rows provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table - PostgreSQL Documentation: The Locking Clause

How was this useful to me?

I am working on a monitoring tool architected with the Leader-follower model where the service acting as the leader, and the service acting as a worker needs to be capable of working with multiple replicas of themselves. The leader needs to query data on an interval basis and publish events/messages to a queue to be consumed by the workers.

Due to the potential volume of data, and to prevent having a single point of failure I needed to foresee having multiple leaders running in a replicated fashion, which without proper concurrency control would have led to issues such as multiple leaders accessing the same rows for the same purpose.

That’s it for this post, thank you.

On this blog post I will my preferred set up to Dockerize Go services.

Binary, Binary, Binary

Binary, Binary, Binary - Steve Balmer

The command go build generates a binary, and this is a relevant and non-trivial fact that is going to impact how I am going to set up the Dockerfile, but I am going to come back at this later, for now here is the code snippet:

 1##
 2## Builder stage
 3##
 4FROM golang:1.20 AS builder
 5
 6ARG VERSION
 7
 8WORKDIR /usr/app
 9COPY . ./
10
11ENV CGO_ENABLED=0
12RUN go build -buildvcs=false -o bin/service -ldflags="-X main.Version=${VERSION}" ./
13
14##
15## Final stage
16##
17
18FROM alpine
19WORKDIR /usr/app
20COPY --from=builder /usr/app/bin/service ./service
21
22ENTRYPOINT ["./service"]

Source

The Dockerfile above has two stages where the first stage is solely focused on building a binary from the source code:

• It relies on the base image golang:1.20 and it is aliased as builder because it’s referenced further down
• Defines docker argument VERSION, which is used to specify the image’s and the binary’s version during build time
• It sets a workdir, and copy everything from the project root to the root of the working directory set as /usr/app
• CGO is disabled because the source code doesn’t rely on any library written in C. Read more here
• Builds the binary:
  • Omitting the version control metadata with -buildvcs set to false
  • Defines the output directory and binary filename to bin/service
  • Sets the docker argument VERSION to the variable Version defined in main.go

After the binary gets built on the state named builder, Docker jumps into the second stage and does the following:

• It uses a very small Docker image based on Linux named alpine, which is as big as ~5 MB in size, and that is possible because the newly built binary doesn’t rely on an external runtime such as Node.js or JVM
• The working directory is set to /usr/app
• The binary generated in the previous stage gets copied thanks to COPY --from=builder
• Finally, the entrypoint is a call to the binary ./service, just like you would do if you were running it locally

How to build it, and run it

To build a new Docker image versioned 0.0.1, run the following command:

docker build --build-arg VERSION=0.0.1 -t go-docker-demo:0.0.1 .

And to run the image newly built run the following command:

docker run -p 8080:8080 go-docker-demo:0.0.1

Conclusion

That’s the end of this post, and perhaps to I would like to conclude that the fact that Go generates a binary that can be executed without an external runtime helps to build Docker images based in lightweight images such as alpine, which makes the build faster, and very cheap to host it on an Images Registry provided by a Cloud vendor, which tend to charge by data transferred in and out.

Cheers, Firmino

The example I prepared is effectively a function that takes another function as an argument and repeatedly executes it based on the time interval passed in the first parameter.

 1package main
 2
 3import "time"
 4
 5func main() {
 6	runOnInterval(time.Millisecond*500, func(ranAt time.Time) {
 7		iWillPanic()
 8	})
 9}
10
11func iWillPanic() {
12	panic("something went wrong")
13}

The implementation of runOnInterval() is rather simple, it makes use of a for/loop that blocks on every iteration based in the time interval provided.

1func runOnInterval(interval time.Duration, handler func(ranAt time.Time)) {
2	ticker := time.NewTicker(interval)
3
4	for {
5		handler(time.Now())
6		<-ticker.C
7	}
8}

Such a small program panics every time it’s ran, and it outputs the following information on the terminal:

1panic: something went wrong
2
3goroutine 1 [running]:
4main.iWillPanic(...)

A naive assumption…

What if the function passed in runOnInterval() is not meant to panic? And that perhaps if something unexpected were to happen runOnInterval() should at least retry it three times before stopping the execution altogether. That’s when the recover() function enters the conversation, and its basic syntax can be defined as such:

 1package main
 2
 3func iWillPanic() {
 4	panic("Yeah, I refuse to run")
 5}
 6
 7func main() {
 8	defer func() {
 9		if r := recover(); r != nil {
10			log.Println("Oops, something went wrong: ", r)
11		}
12	}()
13	iWillPanic()
14}

recover must be called within a deferred function. When the enclosing function panics, the defer will activate and a recover call within it will catch the panic. - Go by Example: Recover

Now let’s recover

 1package main
 2
 3import (
 4	"time"
 5	"log"
 6)
 7
 8func runOnInterval(interval time.Duration, handler func(ranAt time.Time)) {
 9	ticker := time.NewTicker(interval)
10	for {
11		func () {
12			defer func() {
13				if r := recover(); r != nil {
14					log.Printf("The handler has panicked: %v", r)
15				}
16			}()
17			handler(time.Now())
18		}()
19		<-ticker.C
20	}
21}

The use of defer inside a loop is discouraged, but runOnInterval still needs to check whether the handler has panicked and to do that I wrapped both the recover and the handler inside an anonymous function that is going check whether the handler has panicked or not. Here are the logs shown in the terminal after the change made above:

2023/07/05 08:25:39 The handler has panicked: something went wrong
2023/07/05 08:25:40 The handler has panicked: something went wrong
2023/07/05 08:25:40 The handler has panicked: something went wrong
2023/07/05 08:25:41 The handler has panicked: something went wrong
2023/07/05 08:25:41 The handler has panicked: something went wrong
2023/07/05 08:25:42 The handler has panicked: something went wrong
2023/07/05 08:25:42 The handler has panicked: something went wrong
2023/07/05 08:25:43 The handler has panicked: something went wrong
2023/07/05 08:25:43 The handler has panicked: something went wrong

It works, but the implementation is rather incomplete because runOnInterval will attempt to recover forever, which is not ideal because there is no guarantee that whatever is making the handler panic will ever change. As a countermeasure, a counter - no pun intended - comes in quite handy:

 1package main
 2
 3import (
 4	"time",
 5	"log"
 6)
 7
 8func runOnInterval(interval time.Duration, handler func(ranAt time.Time)) {
 9	panicCounter := 0
10	ticker := time.NewTicker(interval)
11
12	for {
13		if panicCounter == 3 {
14			log.Printf("The handler has panicked %d times. Ending execution", panicCounter)
15			break
16		}
17
18		func() {
19			defer func() {
20				if r := recover(); r != nil {
21					panicCounts++
22					log.Printf("The handler has panicked. Panic count: %d", panicCounter)
23				}
24			}()
25			handler(time.Now())
26		}()
27
28		<-ticker.C
29	}
30}
31
32func main() {
33	runOnInterval(time.Millisecond*500, func(ranAt time.Time) {
34		iWillPanic()
35	})
36}
37
38func iWillPanic() {
39	panic("something went wrong")
40}

Here are the logs that the program outputs with the introduction of the counter:

2023/07/05 08:29:33 The handler has panicked. Panic count: 1
2023/07/05 08:29:34 The handler has panicked. Panic count: 2
2023/07/05 08:29:34 The handler has panicked. Panic count: 3
2023/07/05 08:29:35 The handler has panicked 3 times. Ending execution

That’s it for this blog post, and thank you for passing by.

Example

 1package main
 2
 3import "fmt"
 4
 5func main() {
 6
 7	// Creating a pointer
 8	var fullNamePtr *string = new(string)
 9	fmt.Println(fullNamePtr) // Prints the address: 0x14000110230
10
11	// Storing value in the pointer's address by dereferencing it
12	*fullNamePtr = "John Doe"
13	fmt.Println(fullNamePtr, *fullNamePtr)
14
15	// Getting the pointer of an existing variable
16	country := "Brazil"
17	fmt.Println(&country)
18}

When to use pointers

Since I come from the Javascript world, despite learning the syntax to create a pointer, learning when to use them wasn’t that obvious.

For instance, in Javascript, it is possible to mutate a property from literal object inside a function by just updating the argument passed:

 1const person = {
 2  name: "John Doe",
 3};
 4
 5function updateName(person, name) {
 6  person.name = name;
 7}
 8
 9updateName(person, "Jane Smith");
10
11console.log(person); // { name: "Jane Smith" }

In Go, such operation wouldn’t mutate the struct passed as argument, unless the function updateName was declared with an interface ready to receive a pointer, rather than an actual value.

 1package main
 2
 3import (
 4	"fmt"
 5)
 6
 7type Person struct {
 8	Name string
 9}
10
11func updatePersonName(person *Person, name string) {
12	person.Name = name
13}
14
15func main() {
16	fmt.Println("Go fundamentals")
17
18	person := Person{Name: "John Doe"}
19
20	fmt.Println(person) // {John Doe}
21
22	updatePersonName(&person, "Jane Smith")
23
24	fmt.Println(person) // {Jane Smith}
25}

1result, err := Db.ExecContext(ctx, `INSERT INTO tenants (name) VALUES ($1)`, "My Awesome, Inc.")
2
3if err != nil {
4	// do something with the error
5}
6
7id, _ := result.LastInsertId()
8
9fmt.Println(id) // 0

However, the id returned was always 0, despite the id type being set as a VARCHAR. After a quick digging I learned that unless the table’s id has been created with a SEQUENCE generator, PostgreSQL won’t return the id upon row insertion.

To overcome the challenge I’ve just described above, I’ve used the RETURNING clause, and replaced Go’s Db.ExecContext() with Db.QueryRowContext() to gain access to the modified row.

Take a look at the full script:

 1func FindTenantById(ctx context.Context, id string) (*Tenant, error) {
 2	tenant := &Tenant{}
 3    // Use QueryRowContext instead of ExecContext() to perform an INSERT
 4	row := Db.QueryRowContext(ctx, `INSERT INTO tenants (name) VALUES($1) RETURNING id`, id)
 5	err := row.Scan(&tenant.Id, &tenant.Name)
 6
 7	if row.Err() == sql.ErrNoRows {
 8		return nil, nil
 9	}
10
11	if err != nil {
12		return nil, nil
13	}
14
15	return tenant, nil
16}

That will be all for now, and don’t forget to take a look at the links I’ve listed under references.

Cheers.

References

• https://www.postgresql.org/docs/9.5/sql-createsequence.html
• https://stackoverflow.com/questions/33382981/go-how-to-get-last-insert-id-on-postgresql-with-namedexec

The error above is thrown whenever a Go program tries to scan a query result that contains at least one column whose value is NULL to a struct defined with primitive types instead of sql.NullString type.

To solve this issue at the query level, the SQL function COALESCE comes in handy.

 1package demo
 2
 3type User struct {
 4    Id string
 5    FirstName string
 6    LastName string
 7}
 8
 9func findUserByEmail(ctx context.Context, email string) {
10    user := &User{}
11	row := DbConn.QueryRowContext(ctx, `
12		SELECT id, COALESCE(first_name, '') as first_name, COALESCE(last_name, '') as last_name
13		FROM users
14		WHERE email = $1
15	`, email)
16	err := row.Scan(&user.Id, &user.FirstName, &user.LastName)
17
18    // ...
19}

When the query above is executed, the function COALESCE will replace the NULL value of the columns first_name and last_name returned by the database for the value passed as second argument, which is an empty string.

References

• https://github.com/go-sql-driver/mysql/issues/34#issuecomment-158391340
• https://www.postgresql.org/docs/14/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL