Which options are preferable:

1. More coffee is always better. [XY]
2. More coffee is always better [XY].
3. More coffee is always better[XY].
4. More coffee is always better.[XY]
5. According to [XY], more coffee is always better.
6. According to XY[XY], more coffee is always better.
7. According to XY [XY], more coffee is always better.
8. According to XY, [XY] more coffee is always better.
9. According to XY,[XY] more coffee is always better.
10. According to XY, more coffee is always better [XY].
11. According to XY, more coffee is always better. [XY]

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.

CLIs are a fantastic way to build products. Unlike web applications, they take a small fraction of the time to build and are much more powerful. With the web, you can do whatever the developer programmed. With CLIs, you can easily mash-up multiple tools together yourself to perform advanced tasks. They require more technical expertise to use, but still work well for admin tasks, power-user tasks, or developer products.

At Heroku, we’ve come up with a methodology called the 12 factor app. It’s a set of principles designed to make great web applications that are easy to maintain. In that spirit, here are 12 CLI factors to keep in mind when building your next CLI application. Following these principles will offer CLI UX that users will love.

We’ve also built a CLI framework called oclif that is designed to follow these principles to build great CLIs in Node.

For quite some time I’ve wanted to record a new video talking about code comments for my "writing system software" series on YouTube. However, after giving it some thought, I realized that the topic was better suited for a blog post, so here we are. In this post I analyze Redis comments, trying to categorize them.

Along the way I try to show why, in my opinion, writing comments is of paramount importance in order to produce good code, that is maintainable in the long run and understandable by others and by the authors during modifications and debugging activities.

Adapted from http://www.possibility.com/Cpp/CppCodingStandard.html and NetBSD's style guidelines.

This is version 1 of a cookbook that will help you check whether a data table (defined on the data tables page) is properly structured and free from formatting errors, inconsistencies, duplicates and other data headaches.

Get to the point.

1. Subjects with keywords.

ACTION – Compulsory for the recipient to take some action
SIGN – Requires the signature of the recipient
INFO – For informational purposes only, and there is no response or action required
DECISION – Requires a decision by the recipient
REQUEST – Seeks permission or approval by the recipient
COORD – Coordination by or with the recipient is needed

2. Bottom Line Up Front (BLUF)
3. Be economical.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan.

Everyone tests their software to some extent, if only by running it and trying it out (technically known as “smoke testing”). Most programmers do a certain amount of exploratory testing, which involves running through various functional paths in your code and seeing if they work.

Systematic testing, however, is a different matter. Systematic testing simply cannot be done properly without a certain (large!) amount of automation, because every change to the software means that the software needs to be tested all over again.

This is an introduction to some lower level automated testing concepts, and how to use built-in Python constructs to start writing tests.

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

• Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
• Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
• Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
• Minimize divergence between development and production, enabling continuous deployment for maximum agility;
• And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

In the world of software management there exists a dread place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

This page provides guidelines for version numbering your software.

By Derick Bailey

Most professional software developers understand the academic definitions of coupling, cohesion, and encapsulation. However, many developers do not understand how to achieve the benefits of low coupling, high cohesion and strong encapsulation, as outlined in this article. Fortunately, others have created stepping stones that lead to these goals, resulting in software that is easier to read, easier to understand and easier to change. In this article series, I will define three of the primary object-oriented principles and show how to reach them through the five S.O.L.I.D. design principles.

Leslie Lamport inventor of Paxos and developer of LaTeX introduces techniques and tools that help programmers think above the code level to determine what applications and services should do and ensure that they do it. Depending on the task, the appropriate tools can range from simple prose to formal, tool-checked models written in TLA+ or PlusCal

I'm trying to schedule a repeating event to run every minute in Python 3...