Bootstrap2hugo upgraded to Bootstrap 4

 April 30, 2019

For a few years now, I’ve been using Hugo for my website as well as other websites as well. My first Hugo website was my own since I wanted to learn more about the technology before suggesting it to anyone else. Back then I was not able to find any minimalistic theme I liked, and for that reason, I started my own. As you can imagine from the name, I based it on Bootstrap, version 3 since that was the current version when I started to work on it. I’ve made some minor updates over the last few years, but it was still based on Bootstrap 3. In the last couple of months I did some commits in a branch to bring it to Bootstrap 4, and today I merged them in master, so the template now is based on Bootstrap 4.

GoLang vanity urls on AWS Lambda

 March 21, 2019

After the article on the reasons to use vanity URLs in Go and the one about how to implement a lightweight vanity URLs provider, I’d like to share with you how you can leverage AWS Lambda to implement a vanity URLs provider.

The first thing we will need is to import the github.com/aws/aws-lambda-go package. This package will provide us with the needed functions to easily integrate our Go code with AWS Lambda. In our main we will just need to start the Lambda with a handler like this:

Reasons to prefer vanity URLs for GoLang packages

 January 18, 2019

Golang forces its users to use the repository URL of the dependency in the import statement.

For instance, if we want to import the “test” package that is hosted at github.com/fale/test, we will need to use github.com/fale/test. On the one hand, this is very nice since it allows anyone reading the code to immediately understand where the code is hosted and therefore find it very quickly. Also, this URL-based import path guarantees that no two different packages can have the same import path, preventing this kind of confusion for both programmers and the compiler itself. On the other hand, this is a limitation since it makes the code very reliant on the repository location.

Calling a SOAP service in Go

 December 3, 2018

Today the IT world is very focused on high performance, high throughput interfaces. In this situation, it is common to find REST and gRPC API, given their performances compared to the other solutions. Sometimes, though, we still encounter old API written with older techniques or new API that for some reasons have been developed with outdated technologies. One of those cases that I’ve encountered a few times over the last few months is SOAP.

CORS with Go and Negroni

 November 18, 2018

There are some pieces that you need to put in every microservice you write. Those are for instance logging, error handling, authentication.

Over the last year, I found myself writing over and over CORS headers. This requirement brought me to think that I should have used a Negroni middleware since we are already using Negroni for other middlewares. I started looking online for an already written one, and I found a bunch, but I was not happy with what I found, so I decided to write my own.

A lightweight approach to Go vanity import paths

 September 23, 2018

Golang uses URLs for the dependencies packages resolution. To unbundle the code repository hosting the package and the import path, Golang supports the idea of Vanity Import Paths. The way this has been implemented is that, as long as the import path points to a page where Go can find the real package URL, it will follow through.

So, we will need to create a web server that can serve pages in a way that the Go toolchains can understand. To do so, I use the following code:

A small HTTP debug server in Go

 August 31, 2018

Lately, I found myself to work on an application that was communicating via SOAP with a server. My goal was to understand how this application worked with the SOAP server to emulate its behavior. Even if I had access to the source code of the application, I thought it would have been easier, faster and more fun to do the work without actually reading the code. It’s important to note that actually, the application is fairly small and self-contained. Otherwise, I would have probably taken a different approach.

Why everything will end up in a container

 May 9, 2018

A couple of months ago, I wrote a blog post about why containerization is not always the answer and I’ve received quite a few comments about it. This article has the goal to analyze an aspect in favor of containerization which I believe to be true but was not mentioned in the previous post: the time aspect of the phenomenon.

In the ICT sector, we are used to new technologies, or at least we should be. Speaking of architectures, I still remember when I started in the ICT sector that VMWare had just introduced ESX (not ESXi) and there were two ways of looking at it:

An HTTP server to serve GCS files

 April 12, 2018

As many other clouds, Google Cloud Platform provides an Object Storage service, Google Cloud Storage. As many other Object Storage service, Google Cloud Storage provides an HTTP server to deliver your files quickly. When I started to use Google Cloud Storage and its HTTP server I have not been entirely pleased by how it works and therefore I wanted to re-implement the HTTP server so that I can manage it completely.

Why containerization is not always the answer

 March 27, 2018

UPDATE: I’ve then written another post to clarify better my point of view on the future of containers.

When I hear people (and usually those people are salespeople) saying that as soon as you put a Container Platform in your company, all your problems go away, I feel bad for the company they are trying to sell it to.

I’ve seen far too many container platforms (as well as many other technologies) fail at customers because they have been sold as this magical problem that makes all your problems go away. There are many reasons why a container platform could fail in a specific environment. The main reasons in my opinion are: