Questione di desideri…

15 anni fa, desideravo diventare uno sviluppatore web: ero affascinato da questo mondo e avrei voluto farne parte anche io. Un po’ alla volta ho imparato a usare gli strumenti necessari e creai il mio primo sito.

12 anni fa, ho realizzato che non bastava fare delle pagine web e basta, ma dovevano avere uno scopo. Ho anche realizzato che fare sia il contenuto, che tutto il sistema per gestirlo era un lavoro enorme e le mie competenze non ne erano all’altezza. Sono quindi passato a dei CMS: Flatpress, DokuWiki e altri.

Dopo 6 mesi, poi ho deciso di tenere solo il blog, ma a parte qualche cambiamento di grafica, è rimasto così per 10 anni.

Poi, 2 anni fa, cercavo un tirocinio per l’Università e volevo che il sito potesse dare una panoramica nonché reseoconto cronografico dei miei progetti. Ne ho aprofittato per dare una rinnovata: già da diverso tempo non mi trovavo più con PHP, avevo deciso di abbandonare Flatpress e volevo che il risultato fosse più professionale. Sono passato così a Python, in particolare Django, per il backend, più un Bootstrap leggermente personalizzato per il frontend.

Inizialmente ero rimasto soddisfatto, ma ad un certo punto ho constatato che queste dipendenze fossero eccessive, per i miei scopi, e ho iniziato a volermi liberarmi di tutta la pesantezza, sia in termini di prestazioni, che di peso del sito stesso. Ma soprattutto, volevo seguire il principio di aumentare la sicurezza diminuendo la superficie d’attacco.

… e di sorte

Di tanto in tanto quest’idea mi tornava in mente, ma non ci ho mai dato troppo seguito. L’ultima volta era stata il 9 marzo, avevo anche dato un’occhiata al database dei post per decidere sul da farsi, quindi avevo già capito che questa invece sarebbe stata la volta buona.

E in più si è messa in mezzo la sorte: la notte successiva ha preso fuoco il datacenter SBG-2 di OVH, dove era ospitato il mio VPS.

Non avrei mai pensato che quel sistema sarebbe morto così. Ormai avevo più di 1200 giorni di uptime, in cui non avevo mai avuto nessun problema. Piuttosto mi sarei aspettato un cambio perché OVH di tanto in tanto alza i suoi prezzi. Ma anche all’ultimo rinnovo avevo desistito, in parte perché comunque in giro non c’è di meglio, e poi perché fare il setup di un VPS è, ahimè, un impegno oneroso.

In ogni caso, non ho perso niente: i backup quotidiani hanno sempre funzionato, e con una certa cadenza creo anche dei backup manualmente nel mio NAS.

Ma a questo punto, avrei dovuto riprendere in mano software che non toccavo approfonditamente da 2 anni. Django mi ispira di progetto molto stabile, quindi probabilmente non mi avrebbe causato troppi mal di testa. Invece ho colto la palla al balzo e ho creato una nuova versione del sito.

Da questo il titolo. Tante volte si usa fenice in senso figurato, non mi sono lasciato sfuggire l’occasione di usarlo in senso letterale 😉️ .

Vecchi e nuovi principi

Una volta, creare i siti a mano era una ragione di vanto, tra chi lo faceva. Io, mi annoveravo tra questi anche se, con il senno di poi, ammetto che non fossero un granché. Poi ho cominciato a usare i CMS. Con Django avevo già fatto un passo indietro, ma adesso l’inversione è stata totale: ho confezionato un software totalmente su mia misura. E nel frontend solo il lightbox è stato preso da terze parti.

Poi ho portato avanti l’idea di Web 1.0. Non sono d’accordo col ritenere il Web 2.0, o eventuali versioni successive, migliore. A me piace pensare di avere il mio angolino tranquillo di web, in cui pubblicare mie esperienze ed opinioni, in cui, appunto, solo io scrivo, e gli altri leggono. Sono aperto al confronto, ho una pagina di contatti per questo. O chiunque può fare il proprio sito, eventualmente solo per rispondere 😁️ . Avere un sito statico (o quasi) ha anche dei vantaggi tecnici. Invece un form dei commenti indipendente da altre piattaforme vuol dire diventare vittime degli spammer.

E questo mi conduce ad altri due caposaldi: il primo è appunto avere un sito statico. È una cosa che in tanti apprezzano, basti pensare agli utilizzatori di Pelican. Sono appunto d’accordissimo con l’idea: non ha senso dover ripetere tutta una serie di elaborazioni per ogni richiesta. Però preferisco avere un sistema di instradamenti, a uno più semplice, basato su una struttura di file e directory nella document root.

Il secondo punto invece è l’autarchia del sito: non mi è mai piaciuta l’idea di affidarmi a un CDN, non l’ho mai abbracciata e continuerò a non farlo. Al massimo linko del codice su GitHub, ma se cambiassi idea potrei sempre ospitare direttamente io il codice. In passato qualche volta ho incorporato il player di YouTube, ma lo considero quasi alla pari di mettere un link. Tutti casi non collegati all’ordinario funzionamento del sito, che potrebbe sopravvivere anche da solo.

Un altro principio che ho sempre cercato di seguire è che tutto il materiale vecchio deve rimanere funzionante. Nessun link rotto, nessun errore, né lato frontend, che impedisca alla pagina persino di arrivare, né lato frontend, come formattazione sbagliata. Ci sono post di cui adesso un po’ mi vergogno, ma spero che i lettori siano capaci di leggere le date di pubblicazione e trarre le loro conclusioni 😄️ .

Infine, vorrei non dover toccare più il codice del sito e dormire sonni tranquilli: bassa superficie di attacco, codebase più piccola possibile e dipendenze ridotte.

Qualche tecnicismo

Ho fatto un dietrofront anche sull’avere un database: ho recuperato i dati e li ho messi in una struttura sul filesystem. Con uno script mi passo quelle directory, creo l’HTML e gli indici di tag e categorie.

La trasformazione del testo avviene con degli script che ho scritto esattamente 3 anni fa. Avevo portato le funzioni principali che Flatpress applicava ai testi da PHP a Python, e non avevo richiesto grosse dipendenze. Il codice non segue molto la PEP-8, ma almeno funziona e non ho voluto rimetterci mano.

Lo script che elabora le richieste HTTP si basa su Werkzeug. Fondamentalmente è un router che controlla che gli URL siano fatti come piace a me, e altrimenti fa un reindirizzamento o lancia un 404.

Questo è un argomento che mi sta molto a cuore: adoro le espressioni regolari, però a volte, semplicemente, non sono lo strumento corretto. Per un come sito il mio, o per molti blog in generale, più che usare delle regex, è più utile ragionare per token: in un certo senso ho sfruttato l’esperienza che avevo acquisito con il plugin RewriteURLs che avevo scritto per Flatpress.

Fondamentalmente, il primo token è il più importante: consente di verificare subito se si è in un caso particolare: una certa “pagina statica” (e.g. informazioni e contatto), la ricerca, oppure un redirect. Tutto deve essere considerato parte dell’archivio, e ancora una volta può essere implementato tramite token: prima tag/categoria, poi i token per il filtro sulla data, e infine le pagine o i feed. In pratica ho tenuto un approccio più da DFA, quindi comunque del tutto equivalente a una espressione regolare.

Il resto è venuto abbastanza da sé, a parte la ricerca è tutto già “precompilato”. Per la gestione dei template ho deciso di usare Jinja2, e semplificarmi la vita, invece per la ricerca Whoosh, di cui avevo già parlato.

Una cosa di cui vado un po’ fiero è l’autocompletamento della ricerca: in questa circostanza ho scoperto i <datalist>. Mentre l’utente digita, vengono fatte delle richieste AJAX e con le loro risposte viene aggiornato il contenuto di una datalist. II browser gestisce il tutto, e lo fa in un modo molto naturale, perché il risultato è UI nativa.

Nella mia macchina di sviluppo (dotata di un Ryzen 3700X) il sito era abbastanza veloce: in genere il tempo per gestire la risposta a una pagina di archivio era sul millisecondo, o qualcosina in più, ma quasi sempre sotto gli 1,5ms. La maggior parte del tempo veniva consumata da Jinja per mettere insieme la pagina finale, ma per ora va bene così.

La VM del nuovo VPS invece è un po’ più scarsotta. Solo per fare l’indice ci impiega 3-4 volte il tempo che ci mette il mio computer. Speravo di avere un incremento senza fare alcuna fatica con Pypy, vista l’autoproclamazione che si può leggere sul loro sito. Ma ho avuto diversi problemi ad installare pacchetti come Pillow, e alla fine nemmeno uWSGI funzionava, quindi sono rimasto con CPython. Andare a erodere sui 2-3ms è abbastanza inutile, visto che da rete TIM (l’unica tier 1 italiana) il ping verso il VPS a Francoforte è raddoppiato rispetto a quello che avevo verso Strasburgo (40-50ms contro i 20-25ms che misuravo prima).

Per il momento sono abbastanza soddisfatto, almeno del sito, chissà se il me del futuro mi darà ragione. Invece sul VPS devo sistemare ancora praticamente tutto, ma un po’ alla volta ce la farò 💪️ .