Come qualsiasi sviluppatore là fuori, adoro iniziare progetti personali. Ma per me hanno un peso diverso: sviluppare un progetto personale mi aiuta a rimanere connesso alla mia missione personale.
Insegno e faccio coaching costantemente con le persone su come sviluppare prodotti migliori, che sia in corsi CSM/CSD, come consulente o come mentore. Ho la mia quota di storie da condividere durante questi eventi, ma sai com’è… mentre queste storie sono nuove ed eccitanti per gli studenti, non posso dire lo stesso dopo averle ripetute una dozzina di volte.
E inoltre… ho bisogno di una scusa per toccare il codice. :)
Il Prodotto
Come formatore, cerco di creare simulazioni così i miei studenti possono imparare dalla propria esperienza la maggior parte del tempo. Ecco perché nel 2019 ho creato il gioco di carte Scrumchkin, per esempio. Ma dalla pandemia, la maggior parte delle mie sessioni di formazione sono state online, il che rende molto difficile replicare lo stesso ambiente dinamico che avevo con le vere carte Scrumchkin in una formazione in presenza.
Quindi, ho deciso che il mio prodotto avrebbe provato a risolvere quel problema:
Gli studenti dovrebbero essere in grado di imparare argomenti complessi attraverso esperienze dinamiche e simulazioni.
Era un fit perfetto dopotutto: ho corsi periodici dove posso portare il prodotto a un test sul campo e raccogliere feedback e ho accesso a una comunità di formatori che potrebbero essere interessati a provare il prodotto e fornire un tipo diverso di feedback.
Dato che tutto ciò di cui avevo bisogno era una scusa per iniziare a scrivere codice, ero soddisfatto di questo.
Decisione: Scegli una libreria di componenti UI dall’inizio e attieniti ad essa. Puoi cambiare tutto dopo, se necessario.
Decisioni sugli Strumenti
Ho deciso di evitare l’uso di un database all’inizio, finché non capisco che tipo di dati voglio memorizzare e come voglio memorizzarli.
Elixir (il mio linguaggio preferito) ha qualcosa che fa il lavoro abbastanza bene: i GenServer. Posso usarli per memorizzare temporaneamente i dati senza dover ricorrere a un database. L’informazione sarà lì finché non accade una di tre cose:
-
Riavvio il server
-
Si verifica un errore e il GenServer viene riavviato
-
Termino il GenServer
Questo approccio mi ha permesso di muovermi più velocemente e dimenticare le migrazioni, per esempio.
Ma, ma… Mario! Non è rischioso?
Il rischio dipende dal contesto. Le mie sessioni di formazione sono brevi, e nel peggiore dei casi perderei circa 15 minuti di tempo e gli studenti dovrebbero ricominciare un esercizio se un GenServer fallisce durante la formazione.
Quindi, è un rischio che sono consapevolmente disposto a correre.
Parlando di fallimenti…
Non posso dire che sto facendo puro TDD, ma sto scrivendo molti test. Specialmente perché sto usando Claude per generare alcuni pezzi di codice per me (scriverò dopo su quali pezzi di codice Claude sta scrivendo per me).
È molto difficile usare il TDD con un LLM. Questi modelli generano enormi pezzi di codice in una volta. Nel frattempo, il TDD è tutto su quel ritmo incrementale: un test, fallo passare, e poi affronta il prossimo. Quello che sto facendo è scrivere test per i miei GenServer, chiedere a Claude di proporre test extra che potrei aver dimenticato e poi chiedere a Claude di implementare le funzioni che farebbero passare i test.
Ho imparato che i test ora sono molto più importanti di quanto fossero prima dell’IA. Quando un LLM fa dozzine di modifiche al tuo codice, è impossibile per te garantire che il tuo codice faccia ancora quello che dovrebbe fare. E Claude ha rotto i miei test più volte di quante possa contare, specialmente quando ha provato a modificare molti file contemporaneamente.
Decisione: Usare l’IA come copilota aumenta la necessità di test automatizzati. E l’IA può aiutarti a scrivere anche i tuoi test.
Decisioni di Design
Ho acquisito tailwindui molto tempo fa e mi piace usare i suoi blocchi di costruzione per creare le mie applicazioni. Posso usarlo per rendere il mio prodotto bello senza spendere molto tempo a raffinare eccessivamente il mio design.
Ovviamente, essendo un non-designer ho anche difficoltà con il layout generale. Anche se ho bei blocchi con cui lavorare sono ancora abbastanza capace di rovinare tutto quando li metto insieme. Quindi, a volte uso Lovable per capire meglio modi di visualizzare come i componenti potrebbero stare insieme.
Decisione: Prova a posticipare l’avere un database. Pensa a modi diversi per farlo così puoi imparare di più sui tuoi dati prima di impegnarti in una struttura di modello.
Meccanismo di Autenticazione
Quando sono in una sessione di formazione, non voglio che i miei studenti creino account e ricordino password per un’esperienza che durerà 2 o 3 giorni. Non voglio nemmeno spendere tempo a armeggiare con un meccanismo di autenticazione.
Ora, so che alcuni di voi stanno pensando: “Ehi Mario, è il 2025! Puoi configurare un meccanismo di autenticazione in un paio di minuti”. Forse sì, forse no. Ma sono sicuro che avere un meccanismo di autenticazione completo aggiungerebbe istantaneamente almeno un po’ di complessità a tutto il resto che voglio sviluppare.
Quindi il mio meccanismo funziona così:
Mi dici il tuo nome, lo salvo nella tua sessione e sei a posto. A meno che tu non sia il formatore, ovviamente. Allora tutto quello che devi fare è inserire il tuo nome come SUPER_SECRET_PASSWORD e avrai accesso alle funzionalità avanzate.
È sicuro? No.
È abbastanza buono da usare in una classe con 20 persone? Decisamente sì.
Decisione: L’autenticazione arriva all’ultimo momento responsabile. Pensaci, lavora attorno ad essa e forse finirai per creare qualcosa di innovativo.
Deploy
Ho recentemente letto l’incredibile libro Simplicity di Dave Thomas, e ci sono molte buone idee lì. Una che mi piace particolarmente è: automatizza il tuo deploy dal giorno zero, così puoi fare deploy spesso.
L’ho fatto usando github workflow e la mia dedibox su Scaleway. Ora faccio deploy facendo solo un semplice:
git push origin deploy
E ovviamente, il deploy avviene solo se tutti i miei test passano. Roba piuttosto basilare, lo so. Ma fare questo dal primo giorno mi permette di fare deploy spesso e raccogliere feedback rapidamente.
Decisione: Crea un hello world, fai il deploy e automatizza l’intero processo di deployment prima di fare qualsiasi altra cosa.
Considerazioni Finali
Un buon progetto personale è un progetto personale che puoi rapidamente deployare e far usare ad altre persone. Nel mio caso, come formatore, l’idea di creare una piattaforma per simulare cose della vita reale durante le sessioni di formazione sembra un fit perfetto.
Rivedrò alcune di queste decisioni? CERTO! Questa è l’intera idea dietro ciascuna di queste decisioni. Un giorno avrò un meccanismo di autenticazione appropriato e un database, ma quando quel giorno arriverà avrò una ragione per implementare queste cose.
Come direbbe Jaqen di Game of Thrones:
Cosa diciamo al nostro bisogno di implementare l’autenticazione nei nostri prodotti? Non oggi.
