Questo post potrebbe essere un banalissimo post su Telegram, ma così mi viene più comodo editarlo, aggiornarlo e aggiungerci pezzi.
Fondamentalmente, prima delle vacanze mi sono convinto a raccogliere tutta quella massa di hack, bozze e idee su come vorrei un regolamento, in un regolamento vero. Al momento non ha neanche un nome, se non il provvisorio “Progetto Ratto” (perché mi aspetto che, come i miei ratti domestici, mi tirerà addosso della cacca).
E’ tutto ancora violentemente work in progress e, soprattutto, open source: trovate i sorgenti su GitLab.
Man mano che ci lavoro ci finirà dentro roba dal blog e viceversa, ma, siccome mi piace parlare anche di processi, oltre che di contenuti, vi beccate pure il pippone su come faccio a scrivere “Progetto Ratto” (così, se volete, potete farlo anche voi) e su come potete fare voi a scrivere “Progetto Ratto”, perché il bello dell’Open Source è che non è che posso lavorarci solo io.
Come funziona¶
Esattamente come per il blog, quando scrivo Progetto Ratto scrivo in Markdown. Qua cominciano però le differenze: il blog ha bisogno di diventare un sito internet, mentre vorrei che Progetto Ratto diventasse quanto più accessibile possibile, quindi, al momento, ne produco 4 versioni diverse (e sto valutando la quinta):
* PDF (un classico)
* epub (per gli ebook)
* HTML (al momento non servito in alcun modo, ma poi ci lavoro)
* TXT (testo puro, non penso che qualcuno vorrà mai leggerlo, ma mi serve come stepping stone per la quinta versione)
Inoltre, dando in pasto al TXT a un lettore vocale, dovrei poter ottenere una versione audio, anche per i non vedenti. Ovviamente farsi leggere in modo sequenziale, da una macchina, un manuale di GDR, è una delle esperienze più pallose dell’universo, quindi sto pensando a un modo di renderlo più fruibile. Un’idea potrebbe essere quella di spezzare il tutto in capitoli, invece di fare un unico file, magari anche dividendo i capitoli. Ovviamente sarà tutto letto da una macchina, sia perché bisogna P R E T E N D E R E L A P I E N A A U T O M A Z I O N E sia perché, tanto, il budget per fare una cosa con degli umani non esiste.
Per fare tutto questo utilizzo pandoc, che è un convertitore universale di documenti di testo (supporta perfino Word, se fate parte di quella brutta gente). Siccome sono pigro, invece di chiamare 4 volte pandoc per fare quello che mi serve, uso GNU Make, che mi permette di definire un’unica comoda ricetta per generare tutti i documenti, nella stessa cartella e con un nome sano.
Ma, siccome abbiamo già parlato di P I E N A A U T O M A Z I O N E, ho deciso di automatizzare l’automatizzabile. Versionando il tutto su git (come faccio con praticamente tutto il mio lavoro), mi sono appoggiato a GitLab e ho definito una pipeline di build, in modo che, ogni volta che mando sul server una nuova versione, tutti i tipi di documento vengano generati.
Prossimi step¶
Innanzitutto, sarebbe bello avere una cosa più leggibile. Al momento il testo c’è, le tabelle pure, ma mancano finezze come le interruzioni di pagina e simili. Non credo che questo sarà mai un lavoro fatto bene dal punto di vista grafico, sia perché so di non essere capace, sia perché sarebbe estremamente difficile produrre in modo così automatico così tante versioni diverse.
Poi, la build automatica non è ancora 100% affidabile, ogni tanto qualche versione salta dei pezzi, cosa che mi succede anche quando buildo dal mio pc.
Come contribuire¶
Fondamentalmente, basta aggiungere contenuti. Se siete un po’ sgamati con git potete farvi un vostro fork, modificare o aggiungere quello che volete e effettuare una merge request. A questo punto la palla passa a me. Il requisito fondamentale per rendere accettabile una merge request è che non si spacchi la build: se la vostra versione non genera tutti i documenti in modo corretto, verrà rimbalzata. Ovviamente, anche il contenuto può essere un buon motivo per rifiutare: se non mi piace la direzione che state dando al mio topastro intellettuale, vi rimbalzo comunque. Questa è la fine? No, perché Progetto Ratto è Open Source, quindi se pensate che la vostra idea sia migliore potete tenervi la vostra versione indipendente, giocarci con gli amici, pubblicarla e via dicendo. Potete anche mettervi su una cosa completamente indipendente. Non mi manderò gli avvocati alle calcagna ma mi sembra corretto farvi sapere che, se il motivo per cui vi rifiuto i cambiamenti è perché spaccano la build, cercare di farvi un nuovo manuale potrebbe non essere una mossa intelligente.
Se non avete il tempo, o la familiarità con gli strumenti, per fare tutto questo, potete sempre aprire un issue, indicando cosa avete in mente, dove lo mettereste e perché. Mi studierò io un modo per rispondere alle vostre proposte (o per rimbalzarvi).