Ectobit - The Missing Bit

Since some time apt-key is deprecated and lot of Ubuntu 22.04 based systems throws the following warning: 1 Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details You can easily fix this by properly installing Docker and Kubernetes apt archives public keys: 1 2 3 4 5 6 7 wget -qO - https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor | sudo dd of=/usr/share/keyrings/docker-archive-keyring.gpg echo 'deb [ arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring....

Go has very rich standard library which also contains database/sql module with generic interface over SQL databases. Further, lib/pq PostgreSQL driver is fully compatible with database/sql and provides all basic database operations. However, since this is generic implementation over all supported databases, using it is a trade-off not supporting some PostgreSQL specific features. Fans of PostgreSQL (in further text pg) may want more and here comes pgx in help. pgx is a very rich pg driver supporting LISTEN / NOTIFY, COPY, type mapping between pg and Go, all specific pg types, wire protocol and much more....

Go is over ten years old language but generics (type parameters) are introduced just in the March this year. Hence, still lot of developers avoid using them or have certain problems once decided to give it a try. One of the common problems is how to check the concrete type of a generic parameter, specially of non constrained parameters. So, if you try to do the following, it won’t work:...

Lot of the tutorials on the Web show different ways of writing Go HTTP middlewares, but most of them use functional approach meaning using functions that get dependencies as parameters and return HTTP handler function or handler. There is nothing wrong about this, but it can be quite messy to write a complex middlewares like database based authentication and authorization or simply middlewares which have lot of dependencies. In this article I am going to explain how to use more object oriented way of writing such middlewares....

In the previous blog post I described how to define GitHub Actions pipeline to benefit from caching Rust dependencies and container images’ layers. But the final result may also depend on your Dockerfile. Namely, Docker Buildx Action supports BuildKit and buildx and in order to benefit from this, your Dockerfile has to explicitly cache layers. Actually, this is quite easy to achieve, let’s see the example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 # syntax=docker/dockerfile:1....