Alessio Caiazza

Il sapere umano appartiene al mondo.

Implementing avatars timeline

From time to time I like updating my avatar, but this has the side effect of changing it also on old messages that I wrote with another face.

Recently I was able to recover an old repository containing the sources for this site for the period 2007-2012.
Reading my 10 years old articles was entertaining (for me) but having my grown up face next to a 13 year old post felt so strange.

So I decided to implement an avatar timeline. At least here on my website, every post will always have the face that I had at the time of writing (except on mobile, I don't display my avatar on mobile).

2006-01-10 2009-10-10 2011-01-01 2015-08-30 2018-08-31 2020-12-03
I don't expect anyone to be interested in those old posts, also many of them are written in italian.
In any case, they are all tagged with archaeology
( 59sHif)

Sending your first webmention

Yes, this website supports IndieWeb webmentions!

Webmention is a web standard for mentions and conversations across the web, a powerful building block that is used for a growing federated network of comments, likes, reposts, and other rich interactions across the decentralized social web.

This means that in order send a reply you need to publish it on your website first.

This is an example of a very simple reply to this page, if you can publish it somewere online and put your URL in the box at the end of this page, it will eventually appear on my website!

<!doctype html>
<meta charset="utf-8">
<title>My first webmention reply</title>
  <div class="h-entry">
    <!-- change the content with your own info, all fiels are optional -->
    <div class="u-author h-card"> 
      <img src="" class="u-photo" width="40">
      <a href="" class="u-url p-name">Alessio Caiazza</a>
      in reply to:
    <p class="e-content">This is my first webmention!</p>

Don’t know where to start? Take a look at the IndieWeb Getting Started page.

If you don’t have a website yet, you may consider using my GitLab Pages template to quickly create and deploy one.

( 59qCgD) utilizza una CDN per convertire il traffico HTTPS in HTTP

La Toscana entra in zona arancione ed i miei gruppi whatsapp si popolano di screenshot di con le tabelle sulle nuove restrizioni. non sicuro

Non so come mai, ma a me casca l'occhio sulla barra degli indirizzi, con quel suo preoccupante “non sicuro”.

Inizialmente ho pensato si trattasse di un fake, ma poi sono andato a controllare e ho scoperto qualcosa di agghiacciante.

Il sito del nostro governo utilizza una CDN di terze parti per redirigere tutto il traffico HTTPS su una connessione insicura HTTP!

curl -i
HTTP/2 301
server: AkamaiGHost
content-length: 0
date: Mon, 09 Nov 2020 18:46:42 GMT

E come se questo non fosse già sufficientemente grave, questo servizio di terze parti non è nemmeno menzionato nella privacy policy del sito.

( 59bC2J)

Adding new features to GitLab Workhorse

GitLab Workhorse

GitLab Workhorse is a smart reverse proxy for GitLab. It handles “large” HTTP requests such as file downloads, file uploads, Git push/pull and Git archive downloads.

Workhorse itself is not a feature, but there are several features in GitLab that would not work efficiently without Workhorse.

At a first glance, it may look like Workhorse is just a pipeline for processing HTTP streams so that you can reduce the amount of logic in your Ruby on Rails controller.

Engineer embarking on the quest of offloading a feature to Workhorse often find that the endeavour is much higher than what originally anticipated. In part because of the new programming language (only a few engineers at GitLab are Go developers), in part because of the demanding requirements for Workhorse. Workhorse is stateless, memory and disk usage must be kept under tight control, and the request should not be slowed down in the process.

What is a “large” request?

If most of the time is spent moving bytes from one end to the other, then it’s a “large” request.

git push, git pull, uploading or downloading an artifact are all good examples of large requests.

With the rise of cloud-native installations, Workhorse’s feature-set was extended to add object storage direct-upload, to get rid of the shared Network File System (NFS) drives.

You can watch the following presentation for more details on the history of Workhorse and the NFS removal.

Can I add a feature to Workhorse?

Large requests usually involves file uploads, so first of all please familiarise with the Uploads development documentation. It contains the most common use-cases for adding a new type of upload and may answer all of your questions.

What if I need to process incoming/outgoing requests?

We suggest to follow this route only if absolutely necessary and no other options are available.

Splitting a feature between the rails code-base and Workhorse is deliberately choosing to introduce technical debt. It adds complexity to the system and coupling between the two components.

The Ruby on Rails solution for this class of problems is asynchronous processing. So please think about why this feature can’t be implemented in Sidekiq.

Here follows a list of considerations that may help you answering that question:

  • Sidekiq jobs are easier to write and review, they are written in ruby, and your job can be part of the same merge request introducing the new change
  • We have better observability and scalability tools for Sidekiq jobs. We can scale the job processing machines/pods independently, as well as stop processing a specific queue
  • Sidekiq has a reduced blast radius. Each Puma instance has only one Workhorse. A failure at workhorse level is more likely to impact the whole machine, while a failure at a Sidekiq level is constrained on the queue and could result in a broken or partially degraded feature.
  • Workhorse can extract single files into a remotely stored zip archive without downloading the whole archive (see gitlab-zip-cat)
  • Workhorse can’t store files on disk or memory, every type of processing can only be executed while streaming the body. The only exception where we write files on disk are disk buffered uploads, but this may change in the future as this is preventing the split between workhorse and puma containers on cloud-native installations.
  • During an outage, the dev-escalation engineer will likely be more familiar with our ruby codebase. Finding and fixing a problem in Workhorse will be harder.

If you still think we should add a new feature to Workhorse, please open an issue explaining what you want to implement and why it can’t be implemented in our ruby code-base. Workhorse maintainers will be happy to help you assessing the situation.

( 59H9DE)


in reply to searls's tweet

What is a staff-level engineer? We recently started talking about title inflation at work, and I’ve found myself involved into that conversation.

This forced me to think about my role from my own point of view, as well as from the company point of view.

So I came out with the following write-up.

What follows, unless it got merged in the handbook, are only my opinions. 😀

Engineering IC Leadership at GitLab: going beyond Senior level

At GitLab, it is expected that everyone is a manager of one. For Individual Contributors (IC) a new type of challenge begins with the Staff Engineer role. Engineering Leadership is an alternative career path to Engineering Management.

Just like moving into management, also moving from Senior to Staff changes your day-to-day work and expectations placed on you.

IC Leaders exert technical leverage in their scope of influence. Like any other leadership role, the focus should be on helping others to improve. Your impact multiplies with every person you help grow, and the company gets more value when you’re not investing time in doing things yourself.

Your technical skills developed in your career up until now are still very important, and the role is still hands-on technical. Your technical skills are vast and are developing at a lower rate of change now, but you also get new skills that will drive your career from now on: Communication, Collaboration, and Leadership.

The four archetypes

If you ask Staff+ engineers what does Staff level mean at GitLab, you will get very different opinions.

There are four common archetypes of Staff-plus roles in the industry that could explain this variability in opinions:

  • The Tech Lead guides the approach and execution of a particular team. Most frequently they partner closely with a single manager, but sometimes they partner with two or three managers within a focused area.
  • The Architect is responsible for the direction, quality and approach within a critical area, both today and stretching into the multi-year future horizon. They combine a deep knowledge of technical constraints, user needs, and organization level leadership.
  • The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods, others bounce from hotspot to hotspot as guided by organizational leadership.
  • The Right Hand is a partner and an extension of an executive-level manager, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large-scale organizations.

The four archetypes at GitLab

The four archetypes are not roles, and we don’t map our Staff+ ICs to them. Still, they provide a framework for matching market titles and responsibilities. They also explain the presence of multiple Staff+ in a single team.

We expect our Staff+ IC to exhibit behavior from all the archetypes. The individual inclination will usually make one (or more) of them more prominent, but they all define Engineering IC Leaders.

Tech Lead

The most common archetype for a new Staff engineer is the Tech Lead, as a Senior engineer may start showing Staff level behaviors emerging from their team.

A Staff level engineer partners with the Engineering Manager and the Product Manager for milestone planning and helping teammates addressing complexity with their deliverables.

This still applies on levels above Staff+, partnering with their peers in Management and Product.


At GitLab Architecture is a practice where everyone can contribute but Staff+ Engineers play a fundamental role in that.

Architecture as a practice is everyone’s responsibility, but it is notably engrained in senior technical leadership roles, where the roles’ levels and their sphere of influence determine DRI responsibilities within the practice.


Complex problems often require a Staff+ Engineer to handle the first iterations in order to reduce the level of complexity to a manageable state. Routinely being handed the hardest, least-specified, or most-uncertain work is part of this archetype. As well as guiding other ICs in the team when they’re struggling to find a solution.

Other teams may need a Staff+ Engineer on loan. The receiving team may or may not already have a Staff+ Engineer, as a Solver not only you deal with the problem at hand, but also make sure the team is empowered to take care of your work once the complexity level is manageable by the team.

Right Hand

One of the conclusions from our work on Architecture Practice at GitLab is that introducing complex architectural changes can not happen without Staff+ ICs working closely with Engineering Leaders, that are decision-makers in such cases. This conclusion highlights the need for a close collaboration between Engineering Manager+ and Staff+ Engineers, and it fits very well into the Right Hand archetype definition.

Staff+ Engineers are supposed to broaden the perspectives of their managers. Engineering Leaders often need the additional context and perspective to make well-informed decisions about investments in the product architecture, understanding expected ROI, and a core technical vision behind such changes.

Building meaningful relationships based on trust will make this whole process smoother and will distribute leadership, both technical and managerial, at every level, from single teams up to department level.

This article is extracted from this merge request .

( 59C92o)

Book review:"Sinatra: Up and Running"

Italian version below.

The first time I leafed through this book I wondered if 20 bucks was too much for a book of just over 100 pages.

When I started reading it was clear that this book was worth every single cent.

Clear concepts and well written, too bad for some mistakes in the code examples. Not even a word is wasted explaining how to develop in ruby; surely it is a book for experienced developers.

If you are looking for a step by step guide about web development with sinatra then this is not the book you are looking for. There are no advices on how to organize a project nor any best practice.

Who is this book for?

It’s a book for experienced developers who want to sharpen their knowledge about how sinatra works and not settle for high-level API. You’ll learn how to develop and use modular applications, building the theoretical bases for applications reuse; you’ll learn how RACK works and how to integrate several web applications developed with different frameworks (Rails, Sinatra and also simple RACK based applications).

Not even a sentence is redundant in this excellent manual, surely it is a reference book to keep on hand.

O'Reilly Shop

Italian version

La prima volta che ho sfogliato questo libro mi sono chiesto se 20$ non fossero troppi per un libretto di poco più di 100 pagine.

Dopo aver iniziato a leggerlo è stato subito chiaro che il libro valeva ogni singolo centesimo.

Concetti chiari e ben scritti, peccato solo per qualche errore negli esempi di codice. Non si spreca neanche una parola per i concetti di ruby; è decisamente un libro per programmatori esperti.

Se state cercando una guida passo passo per lo sviluppo di applicazioni web con sinatra, lasciate perdere, questo non è il libro che fa per voi. Non ci sono consigli su come organizzare un progetto, né alcuna best practice.

Allora per chi è questo libro?

Per sviluppatori esperti che vogliono approfondire il funzionamento di sinatra e che non si accontentano delle API di alto livello. Vengono trattate le applicazioni modulari, gettando le basi teoriche per il riuso delle applicazioni; viene spiegato molto bene come funziona RACK e come integrare web-app differenti (Rails, Sinatra ma anche semplici applicazioni fatte secondo le API di RACK).

Neanche una frase è superflua in questo ottimo manuale, sicuramente si tratta di un testo di riferimento da tenere a portata di mano.

O'Reilly Shop

( 4KFN00)

OSX Lion, ruby and mysql2 - [FATAL] failed to allocate memory

I’ve spent a day figuring out how to solve the “[FATAL] failed to allocate memory” with mysql2 gems on Lion.

This solution should work if you installed mysql with Homebrew.

First of all, remove mysql-connector-c and mysql2 gem

$ brew uninstall mysql-connector-c
$ gem uninstall mysql2

Find the mysql version

$ ls /usr/local/Cellar/mysql                

Now recompile mysql2 against brewed mysql server (replace 5.5.19 with your version (twice))

$ gem install mysql2 -- \
  --with-mysql-include=/usr/local/Cellar/mysql/5.5.19/include \

Enjoy yourself

( 4GhP00)

Bundler with Mercurial support

Git seems to be the de-facto tool for ruby development. Lots of gems are hosted on github, and bundler may help you to work with cutting-edge release fetched from git repositories.

WOW! That’s amazing! But what if you didn’t like to use git as scm?

I’ve nothing against git, but I prefer mercurial so I spent some time to add mercurial capabilities to bundler, the best way to manage your application’s dependencies.

How does it work?

With bundler you can start gem development with a simple command (more info at Railscast episode 201)

bundle gem gem_name

This command will create for you a gem skeleton with some premade rake tasks in a shiny git repository. Wouldn’t be wonderful if we can use mercurial instead of git?

Now you can with this patched version of bundler 1.0.10 that add the ‘-H’ switch to bundle gem

 bundle help gem
  bundle gem GEM

  -H, [--hg=Use mercurial instead of git]
  -b, [--bin=Generate a binary for your library.]
      [--no-color=Disable colorization in output]
  -V, [--verbose=Enable verbose output mode]       

Creates a skeleton for creating a rubygem

Not enough for you?

If this is not enough for you, I’ve also a patch set for loading gems directly from mercurial repos. This patched bundler v1.1pre.1 will make you happy.

gem 'eusplazio', :hg => '', :tag => 'v0.0.2'

Happy conding

Install instructions

Download the zipped source and extract it; enter the source folder and type rake install

( 4ASLAn)

Hello. My name is Alessio Caiazza. I'm also known as nolith. I love writing code and technology. I'm passionate about production engineering.

This is where I write my thoughts trying to follow IndieWeb principles.

Staff Backend Engineer, Delivery @ GitLab


"Il sapere umano appartiene al mondo."

An IndieWeb Webring 🕸💍