Error handling is an integral part of programming, but in many popular languages, it comes as an afterthought.

The godfather of numerous programming dialects, C, never had a dedicated error or exception mechanism in the first place. It is up to the programmer to accurately report whether the function did what it was intended to do, or threw a tantrum—usually by relying on integers. In case of a segmentation fault—well, all bets are off.

This post goes through the experience of the author in the adaptation to the Golang error management workflow.

A list of things to pay attention to when making interviews.

The list enters some few items in details, while it only lists other items without explanation.

When I think about who I would like to work with as a programmer, I think so much more about non-technical skills than technical skills that make somebody a good co-worker. In fact, all of the skills that are in this post contribute to writing good code that improves technical projects. Most of them are really helpful for careers outside of programming too, but I'm going to focus on why they're useful for programmers specifically.

Most widely-used programming languages have at least one regular conference dedicated to discussing it. Heck, even Lisp has one. It’s a place to talk about the latest developments of the language, recent and upcoming standards, and so on.

However, C is a notable exception. Despite its role as the foundation of the entire software ecosystem, there aren’t any regular conferences about C. I have a couple of theories about why.

From Josh Mcguigan.

This is a tutorial on building your own shell using Rust, in the spirit of the build-your-own-x list. Creating a shell is a great way to understand how the shell, terminal emulator, and OS work together.

Alpine Linux-based Docker images are small, but they can still bloat up quickly. If you're concerned about image size, search for alternatives, like Minideb.

When the Docker revolution started, one argument among many in favor of using containers instead of virtual machines was their size. Container images were supposed to be small.

However, several anti-patterns quickly emerged in the early days of Docker. First, most people wanted to treat containers just like VMs, hence they wanted an SSH server in them, they wanted to run multiple processes in them and they wanted their regular Linux distributions.

This quickly ballooned the size of Docker images that could be pulled from the Docker Hub. Official Ubuntu and CentOS images used to be above 600 MB. Once dependencies and application code got added, it was not rare to see several GB Docker images around.

For the longest time I did not know what everything meant in htop.

I thought that load average 1.0 on my two core machine means that the CPU usage is at 50%. That's not quite right. And also, why does it say 1.0?

I decided to look everything up and document it here.

They also say that the best way to learn something is to try to teach it.

A nice blog post about Delaunay triangulation and Voronoi tessellation of a sphere.

Very nice interactive JavaScript animation that shows the triangulation and the tessellation as a function of some paramenters.

Dopo qualche giorno passato a radunare e organizzare il materiale necessario a presentare il CV per un concorso pubblico, voglio condividere alcune indicazioni per arrivare preparati al momento della preparazione di un CV adatto (anche) per concorsi pubblici, che tipicamente richiedono anche un qualche tipo di certificazione per le varie voci del CV.

Il problema è che i documenti necessari potrebbero fare riferimento ad attività svolte molto tempo addietro, e potrebbero essere difficili se non impossibili da recuperare.
Molto meglio conservare il necessario man mano che si accumulano i cosiddetti "titoli".

Questi consigli permetteranno di preparare il CV senza rischiare di dover cercare documenti in archivi, faldoni, email, presso uffici amministrativi, ecc., col rischio di non trovare il necessario.

Per ciascuna voce del CV sarà quindi utile predisporre un allegato in formato pdf dove si certifica l'effettivo svolgimento dell'attività. Si può trattare della scansione del contratto di assunzione, di una ricevuta di pagamento per un lavoro svolto, di una attestazione per un premio vinto o per la partecipazione ad un convegno o meeting, ecc.

I dati da salvare per ciascun item del CV sono quindi:

• data di inizio e di fine dell'attività (giorno, mese e anno) - la fine può anche non esserci se l'attività è tuttora in corso

• breve descrizione dell'attività

• descrizione dell'allegato (es. Estratto del contratto di assunzione presso ...)

• nome del file pdf nel quale è stato conservato l'allegato

Queste voci possono essere efficacemente memorizzate in un foglio elettronico, da conservare insieme ai file pdf con le certificazioni.
Il tutto, pronto per essere copiato e incollato all'interno di form o template di CV.

È arrivata anche sulla stampa mainstream la notizia delle vulnerabilità chiamate Meltdown e Spectre dei processori Intel, AMD e ARM.

Senza entrare nel merito della gravità o meno della questione, riprendo un interessante commento "collaterale" di Alan Cox, guru del kernel Linux, riguardo ad una "check-list" per capire se siamo preparati alla eventualità di dover gestire alcune attività "di emergenza" che potrebbero essere di non semplice semplice realizzazione in caso non ci si fosse pensato preventivamente;

• So keep backups, test they work and have an up to date plan for what to do if/when your machine gets hit by something evil (or for that matter gets killed by coffee, cats, fire or other natural disasters).
• Do you have the phone number to cancel your bank cards if you have no computer or internet ?
• Do you know how to restore a backup on a new machine ?
• If you are dealing with proprietary software do you have copies of any license keys ?
• What plan do you have to change passwords on accounts and how will you do it with no PC of your own working?

Questo post è nato dall'esigenza di spiegare come l'uso del "Reply to all" quando si risponde alle email sia uno dei segreti di una buona comunicazione di gruppo. Ho scritto queste spiegazioni oramai troppe volte: questo mi ha stimolato a scrivere un post da linkare in futuro.

Perché fare (quasi sempre) reply-to-all

Quando una email viene inviata ad un gruppo di contatti, solitamente il mittente intende informare e mantenere aggiornati tutti i destinatari. Altrimenti dovrebbe scrivere ai singoli, oppure può indirizzare l'email a se' stesso e mettere i destinatari in BCC.

Per questo motivo, il fatto di rispondere al solo mittente crea difficoltà nella comunicazione perché si compromette l'aggiornamento che si desidera garantire per tutti i destinatari originali.

Una email inviata a più destinatari dovrebbe essere considerata equivalente ad un gruppo di Facebook, Whatsapp, Telegram, ecc.: se la comunicazione viene fatta al gruppo, è bene che anche le risposte siano indirizzate all'intero gruppo.

Ovviamente ci sono situazioni nelle quali è meglio rispondere individualmente, per esempio quando non si vuole "disturbare" l'intero gruppo per una informazione da inviare ad un singolo, ma queste dovrebbero rappresentare delle eccezioni.

Esempio di problema

Un caso tipico è quello in cui invio una email ad un insieme di destinatari, e uno di essi risponde soltanto a me (senza fare "Reply to all"), cosa che mi costringe a 1) inoltrare la email a tutti i contatti che non la hanno ricevuta, oppure 2) aggiungere nuovamente tutti i contatti alla mia successiva risposta. Questo per mantenere aggiornati tutti i destinatari circa lo scambio di email.

Reply-to-all come default nel client di posta

Suggerisco di impostare il reply-to-all come opzione di default nel client di posta utilizzato. In tal modo:

1. Non si deve pensare ogni volta a che tipo di risposta, singola o collettiva, va data: quasi sempre è da indirizzare a tutti!
2. Si evitano disagi organizzativi e logistici per mancanza di condivisione di informazioni con tutti gli interessati.

Tutti i client di posta permettono di impostare come opzione di risposta di default il reply-to-all. Una volta configurato il client, non c'è più rischio di dimenticarsi il reply-to-all.

Ma...

Che dire dell'obiezione "così rischio di fare rispondi-a-tutti anche quando non lo vorrei"?

La risposta è che il problema praticamente non si pone:

1. se si sa che il default è reply-to-all, allora automaticamente ci si ricorda di fare risposta privata quando serve;
2. nell'era delle chat e dei gruppi di Facebook, Whatsapp, Telegram, ecc., è ormai normale scrivere comunicazioni "collettive"

Personalmente, in tutte le email scambiate negli ultimi anni (statistica recente: più di 30.000 email), raramente mi è capitato di dover dare risposta privata ad una email collettiva.

In definitiva, nel caso tipico, i disagi e ritardi organizzativi dovuti al non fare reply-to-all sono complessivamente più rilevanti che una risposta collettiva inviata per errore.

A maggior ragione perché, come già detto, tipicamente quando si riceve una email inviata a contatti multipli è proprio perché il mittente punta a tenere informati tutti i destinatari. Altrimenti l'errore è del mittente, che farebbe meglio ad usare il BCC.

Ultimate Quality Development System is key to software project Twisted's ability to release stable, reliable code.

È importante ricordarsi di fare reply-to-all alle email praticamente ogni volta (le eccezioni sono generalmente rare) che si riceve una email indirizzata a più di una persona.

Per non dimenticarsene, è conveniente impostare l'opzione reply-to-all come impostazione predefinita nei propri client email.
Ecco i motivi.

VANTAGGI:

1) Non si deve pensare ogni volta a che tipo di risposta (singola o collettiva) va data: quasi sempre è da indirizzare a tutti!

2) Si evitano disagi organizzativi e logistici per mancanza di condivisione di informazioni con tutti gli interessati.

MA... Che dire all'obiezione "così rischio di fare rispondi-a-tutti anche quando non lo vorrei"?

La risposta è che il problema praticamente non si pone:

1) se si sa che il default è reply-to-all, allora automaticamente ci si ricorda di fare risposta privata quando serve; ma, comunque....

2) personalmente negli ultimi 10 anni (statistica dell'altro giorno: più di 25.000 email scambiate) mi sarà capitato 3-4 volte di dover dare risposta "privata" ad una email collettiva

In definitiva, i disagi e ritardi organizzativi dovuti al non fare reply-to-all sono complessivamente più rilevanti che una risposta collettiva inviata per errore.

A maggior ragione perché tipicamente quando si riceve una email inviata a contatti multipli è proprio perché il mittente punta a tenere informati tutti i destinatari (altrimenti l'errore è del mittente, che farebbe meglio ad usare il BCC).