Recently I've discovered two interesting was in creating monorepos for go projects. In this article we are going to talk about the advantages and disadvantages of each of these techniques.

In this article we are going to finally get to building the Parser. We are going to start parsing syntax, package and import statements, and we are going to see how to represent our serializable AST. Hope you are ready for this, it's gonna be fun!

This article is a small one intended to solve a bug related to token position. As of right now, we only tested that our token got the right literal and the right token kind. In this article, we are going to add the position checking in our tests.

In this article we are going to delve into the second part of the lexing which is tokenizing more advanced part of the input. More precisely, we are going to lex spaces (whitespaces, new lines, ...), comments, Identifiers, Numbers (Int and Float), and Strings. At the end of this article, we will have a fully functioning lexer that can tokenize the descriptor.proto which is the longest proto file in the protobuf repo. Let's get started.

As promised in a LinkedIn Poll, we are going to develop Parser for proto files which will create an AST that is serializable in Protobuf itself. Obviously, this is going to be a series of articles because we need to write quite a lot of parsing code. However, I believe that this is worth doing since we are going to see another use of Protobuf outside of gRPC.

Recently, I answered a StackOverflow question related to writing protoc plugins and Protobuf custom options. I thought this would be interesting to share how to write one because I believe this is quite an involved process and it fits the context of an article.

Recently, I've been working with Markus Tacker on improving his comparison of JSON vs. Protobuf for a Wifi Site Survey. This has been a lot of fun and I thought I could do a simple post about what went well and what my mistakes were.

As this is a common and not well documented mistake that developers are doing, I decided to do a post explaining the problem that you might face when using repeated fields in your Protobuf messages.

One of the common thing that my students are asking about recently is the difference between 2 Type Embeddings when your are defining a Server type for Service Registration. While this is an important topic, the gRPC doc seems to only mention that the Unimplemented version is for Forward Compatibility, and my course, up until now, uses the name of the generated Service Server directly. As such, I thought I would give an explanation on why I now recommend to use Unimplemented and some examples of the 3 Type Embeddings that you can use.

This article is much more a note to myself than something else but this might be interesting for people out there. I wanted to calculate the thresholds at which it is better it is to use a fixed rather than a varint.

While working on a new course, I was looking for an example to store a Color in Protocol Buffers. At first this seemed like an easy task but it turned out to be an interesting example of optimization. Let's work through it.

For student taking my class on gRPC C# (Udemy), here is the way to get the code.

Caching is everywhere! It is an essential part of most applications out there and so obviously there are a lot of options you can chose from. Here is a non exhaustive list:

After the decision of using Crashlytics for our first pilot (Education for ethopia), the tech team discovered that one particular crash was redundant. This crash was due to a malformed Intent between the video player in portrait mode and the video player in landscape mode.

After being used to the traditional way of debug an android app by using mocking and interceptors, I came across an interesting problem with gRPC. I wanted to do the same. Basically, add an interceptor that mock a server response.

Recently, I was trying to handle errors in the programming language I'm developping. Nothing fancy here and the problem was quickly solved with a simple: