Perché teniamo un diario
Elchi Studios mette per iscritto cosa costruisce, cosa decide e perché. Cosa ci entra, cosa resta fuori e come il diario è fatto per persone e macchine.
Aggiornamento del 9 ottobre 2026: il diario esce ora in italiano, tedesco, francese e inglese, e un articolo è online appena viene pubblicato. Due paragrafi più sotto descrivono la situazione precedente. Il diario in quattro lingue spiega cosa è cambiato.
Qui Elchi Studios mette per iscritto ciò che costruisce e ciò che decide, e il perché. Non è un flusso di notizie e non è un elenco di funzioni. Quando cambia qualcosa che noterebbe un cliente, uno sviluppatore o chiunque altro conti su di noi, lo raccontiamo qui per intero: cosa è cambiato, il motivo, quanto costa e cosa manca ancora.
Perché metterlo per iscritto
Un sito web Le dice che cosa vende un'azienda. Raramente Le dice come lavora, ed è proprio di questo che Lei si fida quando ci affida il Suo sito, il Suo login o la Sua posta. Un changelog si avvicina di più, ma dice cosa è cambiato e quasi mai perché. Il perché è la parte utile. Ed è la prima che si dimentica, anche da parte nostra.
Per questo ogni decisione che conta finisce qui, con il ragionamento che l'ha prodotta, finché quel ragionamento è ancora fresco. Se sbagliamo qualcosa, l'articolo che spiega l'errore resta accanto a quello che spiega la correzione.
Cosa ci entra e cosa no
Un articolo descrive qualcosa che Lei può usare o notare oggi. Piani, «prossimamente» e funzioni che esistono solo su una slide non trovano spazio qui. Quando qualcosa è fatto solo a metà, l'articolo dice quale metà.
Ogni articolo è firmato da chi l'ha scritto, con il suo ruolo, perché la dichiarazione di un'azienda vale qualcosa solo se qualcuno ci mette la faccia. Le affermazioni verificabili rimandano alla loro fonte: la RFC, la documentazione del fornitore, la misurazione. Dove c'è un numero da dare, il numero prende il posto dell'aggettivo.
Il diario è in inglese. EAuth, la nostra documentazione per sviluppatori e la maggior parte di chi ci costruisce sopra lavorano in inglese, e con una sola lingua ogni articolo arriva a tutti nello stesso momento. Il resto di elchi.dev resta anzitutto in tedesco, perché è la lingua delle aziende di Zugo per cui realizziamo siti web.
Un articolo non cambia a Sua insaputa
L'indirizzo di un articolo pubblicato e il giorno della sua prima pubblicazione sono permanenti. Non è una promessa, è una regola nel database: ogni tentativo di modificare l'uno o l'altro viene rifiutato, chiunque lo faccia. Se più tardi un articolo va corretto, la correzione avviene apertamente e l'articolo mostra il giorno dell'aggiornamento accanto a quello della pubblicazione. Preferiamo correggere piuttosto che cancellare.
Leggibile senza eseguire nulla
Sempre più persone trovano le cose tramite motori di ricerca e modelli linguistici invece che navigando, ed entrambi leggono le pagine come farebbe una persona molto paziente, ma senza alcuna pazienza per JavaScript. Per questo il diario è fatto di semplici file:
- ogni articolo è HTML completo, senza nulla che venga caricato dopo per mostrare il testo;
- ogni articolo è disponibile anche in Markdown, a un indirizzo proprio con
.mdin coda, con l'autore e le date nel front matter e le fonti elencate sotto il testo; - c'è un feed Atom per chi preferisce un lettore di feed;
- i dati strutturati dicono ai motori di ricerca chi ha scritto un articolo, quando e che cosa cita;
- il file
llms.txtdel sito elenca i venti articoli più recenti, ognuno con l'indirizzo del suo Markdown.
Le immagini passano per la stessa pipeline di ogni sito che realizziamo: AVIF e WebP in sei larghezze da 320 a 2560 pixel, servite dal nostro host per gli asset, ognuna con una descrizione per chi non può vederla. Un'immagine senza descrizione viene rifiutata.
Come nasce
Gli articoli si scrivono nella stessa dashboard che usiamo per tutto il resto di elchi.dev, oppure si inviano alla sua API con una chiave che appartiene a un solo autore. Il testo è Markdown e viene controllato prima del salvataggio: un solo titolo, niente HTML grezzo, immagini solo dalla nostra mediateca. Un secondo controllo segnala le frasi che danno a un testo il tono di un dépliant. Avverte e non rifiuta, perché decide chi scrive. Una regola non è lasciata al giudizio di nessuno: il database rifiuta la lineetta lunga e la lineetta media in un titolo, in un riassunto o nel testo.
La pubblicazione da sola non cambia il sito. elchi.dev è fatto di semplici file, quindi un articolo compare con la build successiva del sito. Quella build preleva dall'API ogni testo pubblicato e, se l'API non risponde, si ferma piuttosto che mettere online un sito senza il nuovo articolo. Il prezzo è un passaggio in più tra la pubblicazione e la messa online. Il guadagno è che ogni pagina che un lettore vede è stata costruita e controllata nel suo insieme.
I primi articoli riguardano il rilascio del 3 ottobre 2026: EAuth che passa a un dominio proprio, i limiti su ogni accesso e una manciata di correzioni, ognuna delle quali ci ha insegnato qualcosa.
Fonti
- RFC 4287: The Atom Syndication Format, IETF, consultato il
- The /llms.txt file, llmstxt.org, consultato il
- BlogPosting, Schema.org, consultato il
Scritto da Samuel Krauss, Founder. Archiviato in company, journal.
Tradotto dall’inglese. Leggi l’originale inglese