Toolleeo's links
A comprehensive description of how I currently use org-mode.
The Pulitzer prizewinner shares his advice for pleasing readers, editors and yourself.
BLUF is a military communications acronym - it stands for “bottom line up front” - that’s designed to enforce speed and clarity in reports and emails.
Da Propp a Campbell-Vogler, passando attraverso le 12 tappe, gli archetipi e i generi letterari.
Is there a way to conveniently define a C-like structure in Python? I'm tired of writing stuff like:
class MyStruct():
def __init__(self, field1, field2, field3):
self.field1 = field1
self.field2 = field2
self.field3 = field3An easier way to build and share serverless applications w/ the Serverless Framework.
Tips for writing effective emails avoiding misunderstandings, with examples from the software development world.
Learn from Docker experts to simplify and advance your app development and management with Docker. Stay up to date on Docker events and new version announcements!
A guide to understand the importance of commit messages and how to write them well.
Best practice and tips & tricks to write scientific papers in LaTeX, with figures generated in Python or Matlab.
Over the years I learned a lot about git. Most of the parts I learned the hard way by using it on a regular basis. Here I summarize a lot of the things which I would consider Git Best Practices for using git in a team. Use the force Luke – use the CLI.
Which options are preferable:
- More coffee is always better. [XY]
- More coffee is always better [XY].
- More coffee is always better[XY].
- More coffee is always better.[XY]
- According to [XY], more coffee is always better.
- According to XY[XY], more coffee is always better.
- According to XY [XY], more coffee is always better.
- According to XY, [XY] more coffee is always better.
- According to XY,[XY] more coffee is always better.
- According to XY, more coffee is always better [XY].
- 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 che 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:
- Non si deve pensare ogni volta a che tipo di risposta (singola o collettiva) va data: quasi sempre è da indirizzare a tutti!
- 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:
- se si sa che il default è reply-to-all, allora automaticamente ci si ricorda di fare risposta privata quando serve;
- nell'era delle chat e dei gruppi di Facebook, Whatsapp, Telegram, ecc., è ormai normale scrivere comunicazioni "collettive"
Personalmente negli ultimi anni (statistica recente: più di 30.000 email scambiate) 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.