I went to Golab 2022

Me at Golab 2022

Between the 3rd and 4th of October, I was lucky enough to attend the GoLab 2022 Conference in Florence. This was my first ever live IT conference and I have to say that I had a blast! Being with people who enjoy technology (and especially the Go Programming Language) as much as I do was a very unique experience that I have never felt before.

In this article, I will go through some of the talks that I enjoyed the most and try to leave you with some basic ideas that might be useful for your Go-developed services.

Note: I would like to thank the organizers of the Golab 2022 for their fantastic work and dedication as well as Travelgate (the company where I work) for giving me the opportunity to attend such an event and enjoy it!

Table of Contents

∘ Things you didn’t know about Go and how to become an expert — Roberto Clapis
∘ Beyond database/sql: The Driver Pattern — Boston Cartwright
∘ Call me maybe: communication between microservices — Adelina Simion, Artur Kondas
∘ Recipes for reducing cognitive load — Federico Paolinelli
∘ Uncover unknown bugs with fuzzing in Go — Sagar Sonwane
∘ Conclusion

Things you didn’t know about Go and how to become an expert — Roberto Clapis

This was the first talk of the conference, and what a way to start it! Roberto Clapis is a Security Engineer working at Google and in his talk he showed us some implementation “flaws” and errors that Go developers, inadvertently, commit when developing.

This talk alone would require a whole post by itself, but some interesting example mentioned by Roberto were:

• Printing out a Context by unmarshalling it as JSON. Have you tried it? Not as easy as you expect it to be. Context contains a Interface inside the Context struct definition and cannot be unmarshalled as JSON directly.
• Embedding structs into a new one, carries the embedded one’s methods. For example, including a Time struct variable inside a new struct and unmarshalling the new struct (see what happens, I don’t want to spoil you).

There was one other case that was mentioned that I really found interesting. This was the problem of “Corrupted” struct data on a mutex-based code.

Imagine having the following code:

Now let’s say that the function initB panics. You are left with a “corrupted” state of your instance of ExampleStruct (a has a correct value but b does not). This is dangerous because there is no build nor runtime error here and it can be hard to detect and debug.

A simple solution for this problem can be a state register. Basically, if all the code inside the function has been executed successfully (this means that it did what was expected of it), we mark the state of the struct as correct and finished.

With this said, the resulting code can be something like this:

Roberto was keen on indicating that Go is a very consistent language and also mentioned some tips when we detect possible inconsistencies in our code (like adding the corresponding comment).

Meeting Roberto Clapis

Beyond Database/SQL: The Driver Pattern — Boston Cartwright

I was really looking forward to this talk because I was not familiar with the driver pattern and wanted to see what the idea behind it was.

Boston Cartwright (check his blog here) gave a pretty clear definition on what the Driver Pattern is. A Pattern that allows us to use a single connector that can be reused by multiple DB systems, which are treated as drivers.

This pattern is already pretty used and you can check how it is implemented in the main SQL Golang package reference, however, Boston centered his example on implementing the driver pattern for event-based queues. You can find the detailed implementation that he showed us here.

I will not go into detail about the implementation (the driver pattern is not the most simple implementation and it will require some time to explain it in great detail) but the driver pattern has probably one of the things I value the most in IT Architecture: generalization. This pattern makes it almost trivial to include a new DB system as a driver without making any changes to the overall idea and functionality of your system.

Call me maybe: communication between microservices — Adelina Simion, Artur Kondas

Right after lunch, we were greeted by Adelina and Artur of Form3. They started explaining the concept of a microservice-based architecture and that it is the solution to achieve the main objectives that each IT service strives (or should strive) for:

• Availability
• Scalability
• Data Flexibility
• Efficiency

The Form3 team presented us with 3 microservices API communication examples using:

• gRPC
• REST
• Event-based queues

Overall this talk is very interesting for someone that is new to these API communication examples since it shows a real-life examples of their usage and indicates service characteristics like transaction load, response time, user type, etc that should be taken into account when deciding which technology to use. I myself have been working with them for a while and I knew most of the ideas mentioned but still learned new and interesting things.

The examples presented in this talk can be found here.

Recipes for reducing cognitive load — Federico Paolinelli

This was one of my favorite talks of the whole conference. The term cognitive load refers to:

The additional fatigue and extra energy that a programmer is using and experiencing when he’s working a specific project or problem.

I really liked this talk because the cognitive load issue is something that is common in pretty much every single company. Developers have different styles, projects are being maintained by many engineers, legacy code is untouched because of “fear of breaking it” and more and more.. All this mixed together can generate source code that is very difficult to understand and maintain, hence it has a very high cognitive load.

Federico Paolinelli, a Software Developer working for Red Hat, showed many different tips on how cognitive load can be reduced. I’m going to show you some of them that I found interesting:

Line of sight

For those unfamiliar with this concept, the basic definition is:

Line of sight is “a straight line along which an observer has unobstructed vision”

There are 2 lines of sight. The first one, on the far left indicates the content of a function and the next one is the return value.

An example of code that has “bad line of sight” can be the following:

As we can see this code returns an error if the values introduced are empty but does it at the very end of the function. Also, it misuses the else statement making it very hard to read.

Federico suggested 4 simple tips on how to improve the line of sight:

• Try to reduce elses
• Return early
• Avoid extra nesting
• Wrap in functions

With these tips, the previous code transforms into the following:

You can find more information on the line of sight and these tips in the following article.

Error Validation

A very common practice is to check for errors by validating the error message that the error struct contains.

Both these examples do not take full use of the methods that the error struct offers, instead they access the error message string and validate it. Since Go 1.13 there are functions for error validation much more elegant and intuitive that this. Here is an example of how to do a proper error validation:

The mysterious boolean

Have you ever seen something like the following code?

Take a look at the ValidateResult function call in DummyFunc. To know what each one of those constant boolean values mean you will have to go to the function definition and then back again to check the values (if you are like me you will have to do it multiple times because I forget the order and get confused).

This has a very simple solution. Just declare constants and use them in the ValidateResult function call.

And there you go! Now you can simply click on the name of the constant and you can see the value that you are setting.

Methods that can be functions

This one can be pretty obvious but, it still tends to happen to people to use struct methods that don’t manipulate or use the data of the struct. It is declared as a struct method just because it shares the same source file as the struct.

For example:

As we can see the SumAges function is declared as a method of the Person struct but it does not interact with the attributes that this struct contains. This can be solved by changing the method to a function:

To make it clearer you can move the SumAges function into another source file (called Util for example) and remove all relation to the Person struct.

(Bonus) The “newspaper” read

The “newspaper” read refers to a certain way to organise the code by dividing it into parts, just like the pages of the newspaper are divided (you have the headers and titles, the main news, and at the bottom the footers). This applied to code means:

• Move the imports and global files at the beginning
• All util functions should be added at the bottom (footers)
• Split to files when necessary (just like the sections of the newspaper)

Uncover unknown bugs with fuzzing in Go — Sagar Sonwane

This was the last session of the conference. Everyone was a bit tired but I gotta say that this talk opened up my curiosity about testing in Go. I’m not proud to say that I’m not a big tester and I do not implement many tests in my applications. That is probably why I had never heard of the concept of fuzzing and maybe that was what impressed me the most.

Using the quote from the official Go documentation

With fuzzing, random data is run against your test in an attempt to find vulnerabilities or crash-causing inputs. Some examples of vulnerabilities that can be found by fuzzing are SQL injection, buffer overflow, denial of service and cross-site scripting attacks.

This gives fuzzing a great advantage over unit tests as it allows you to continuously generate different inputs without having to change them, manually, each time.

So the next question should be, how do we define a fuzz test? Well, it’s rather simple.

Let’s say we have the following function we want to test:

We will write the following test function in the /test/sum_test.go source file:

There are a few changes in the function naming and implementation regarding normal unit tests, that we need to address:

• The name of the function has to start with Fuzz
• It receives the f *testing.F input as opposed to the t*testing.T input of the common unit tests.
• You use f.Add to add all the test cases and the f.Fuzz to declare the test.

Now that the fuzz test is created, it’s time to run it! It can be run the same way as a normal test but indicating that it’s a fuzz test:

go test -fuzz=Fuzz

Once the test starts it will loop over different inputs until it finds a case where the test fails (you can also set a timeout for the test or a max number of inputs that you want to be tested).

Fuzzing is a great tool but it does have its limitations

• Not knowing the exact input of a test can make it harder to validate if the output of the function that is tested is correct. If, following the example in the Go developer page, you have a test that prints the reverse of a string and your input is “Hello World” you know that, for the function to be correct, you will have to receive “dlroW olleH” in the response.
• Fuzzing argument can only be atomic types: int, bool, string, byte… For now, structs are not allowed as arguments (what you can do is create a function that builds the struct inside the test, using the random atomic values from the input).

In conclusion, why to fuzz?

• It helps to locate missing edge cases.
• No assumptions are made.
• A fuzz case can identify bugs that the unit test can’t.

Conclusion

These were some of the talks and sessions that I found most interesting but feel free to check the entire schedule of the GoLab 2022 to find out the other subjects that were discussed. Many of the speakers were very open to discussion via Twitter or Mail.

In conclusion, I have to say that I do not regret attending this conference. It was my first but for sure that it will not be my last. Just listening to the talks and questions presented gives you knowledge. I felt the same way as I felt when I was at uni. There were subjects that were more dull but the ones I found interesting and entertaining, I was obsessed with and intrigued all the time.

If you get the chance to attend a conference, I highly recommend it!

Hope these tips serve you well!

Happy coding :)