Uno dei metodi più efficaci per imparare a programmare è quello di mettere in pratica il prima possibile quello che si sta studiando. Divorare interi manuali o guardare interminabili corsi o tutorial senza mai scrivere una riga di codice è la strada verso la noia, l’abbandono e l’inevitabile insuccesso.
Per questa ragione, pur non essendo un programmatore professionista e non avendo grosse possibilità di diventarlo, ho pensato di lanciare una sorta di sfida a me stesso per mettere in pratica questo principio: scrivere (o riscrivere, per migliorarlo) un metodo, una classe, o una funzione ogni giorno fino a realizzare un’applicazione completa e funzionante.
La necessità di condensare il codice all’interno di un’applicazione, invece di limitarmi a scrivere piccoli programmi di esempio sparsi, è la strategia che dovrebbe incentivarmi ad essere maggiormente costante. Scrivere poche righe di codice per implementare questo o quell’algoritmo può tornare utile per fissare alcune idee o metodologie, ma senza un traguardo chiaro da raggiungere si rischia di perdersi per strada.
Obiettivo della challenge
Quello che intendo costruire seguendo questa “sfida” è il mio nuovo sito web, che per tanti anni è stato realizzato usando software “pronto all’uso”: WordPress, Ghost, Jekyll, Hugo, ecc. Non si tratta di sostituire questo blog, che resterà così com’è, ma di lavorare sul sito del dominio principale, ovvero verolinux.com.
Contrordine, compagni! Quello che intendo costruire con questa sfida è un’applicazione web per realizzare una sorta di archivio di comandi della CLI (command line interface) di diverse piattaforme: Linux, JunOS, Cisco IOS/NXOS, PAN-OS. Deve essere un’archivio ricercabile, con i comandi classificati per piattaforma e tag e una sorta di live search del tipo “search as you type”.
Quali tecnologie userò
La tentazione di usare Ruby on Rails è forte, ma si scontra con due criticità fondamentali:
- Rails è sicuramente sovradimensionato per un semplice sito web come quello che ho in mente;
- il deployment di un’applicazione Rails, nonostante gli sforzi di DHH per semplificare le cose con Kamal e Docker, è tutt’altro che banale e sinceramente non ho intenzione di impelagarmi in cose troppo complicate.
Le alternative sono pertanto Flask, Django e Sinatra. Analizziamole brevemente.
Flask
È probabilmente la scelta più indicata, poiché si tratta di un framework leggero, abbastanza facile da imparare (in parte lo conosco già) e che si può mettere in produzione senza troppe complicazioni.
Django
Per Django vale probabilmente lo stesso ragionamento fatto per Rails: è sovradimensionato e non banale da mettere in produzione (forse più semplice rispetto a Rails). La struttura di un’applicazione Django, essendo più o meno preconfezionata dal framework, è più gestibile rispetto a un’applicazione Flask di dimensioni paragonabili, ma sinceramente trovo un po’ ostica la parte di configurazione.
Sinatra
È l’outsider della situazione. Come Flask è estremamente leggero e ha in più il vantaggio di essere Ruby, che è un linguaggio che preferisco di gran lunga rispetto a Python, tuttavia lo conosco ancora poco e la documentazione non mi pare particolarmente chiara.
Date queste premesse, il ballottaggio è tra Flask e Django; la discriminante sarà proprio la semplicità con cui riuscirò a mettere in produzione due semplici esempi di applicazione.
Time To Go Live
Non è un caso se, negli scorsi giorni, ho fatto un po’ di esperimenti per esplorare i passi necessari a mettere in produzione un’applicazione Python e Ruby. Questi esperimenti li ho condensati, in maniera decisamente poco raffinata, nel post Time To Go Live.
Alla luce dei test eseguiti, e anche a valle di qualche prova di integrazione con Bootstrap, credo che opterò proprio per Flask, conscio dei suoi limiti ma anche del fatto che una maggiore manualità nella gestione del codice e delle estensioni mi aiuterà a comprendere meglio sia Python che la programmazione web.