PHP/Laravel
a Torino

In questa pagina si trova un elenco non esaustivo di strumenti che uso regolarmente, quelli che uso meno regolarmente, quelli che vorrei esplorare con l'intento di introdurli nei miei flussi di lavoro, e quelli che ho aggiunto qui per mio personale promemoria.

Da qui si intuisce cosa so o non so fare, e come preferisco farlo.

Gitlab CI/CD #

Essenziale per eseguire le pipeline di analisi statica e unit testing; talvolta è necessario qualche tentativo per imbroccare la configurazione giusta ed includere tutte le dipendenze necessarie, ma ne vale la pena.

Hetzner #

Per me, il miglior fornitore per VPS e server dedicati in termini di qualità/prezzo. Tutti i server che gestisco direttamente sono in Unione Europea, in area GDPR.

Scaleway Object Storage #

Ideale per i backup, ma anche per conservare immagini e documenti sui siti che prevedono l’upload da parte degli utenti o la generazione da parte dell’applicazione (e dunque senza rischiare di saturare il disco locale del server).

Scaleway TEM #

Sinora, la migliore soluzione che ho trovato per l’invio massiccio di email transazionali: il progetto GASdotto da solo genera tra le 5.000 e le 20.000 email alla settimana, al costo di pochi euro. Personalmente ho seguito l’evoluzione di questo servizio fin da quando è stato inaugurato da Scaleway, ed ho contribuito a correggere il relativo driver di integrazione per Symfony Mailer.

Stripe #

Capita di integrare Paypal o Satispay, ma Stripe offre comunque la migliore esperienza (almeno, dal punto di vista dello sviluppo). Se mi trovo ad implementare un sistema di pagamenti online per conto mio, preferisco questa piattaforma a tutte le altre.

Scaleway Serverless #

La possibilità di avere anche solo per pochi minuti RAM e CPU a disposizione, senza necessariamente allocare un VPS sempre in esecuzione, permette di ottimizzare i costi. Ma solo in determinate circostanze, e dati determinati task da portare a termine periodicamente. Al momento sto usando questo strumento per qualche mio progetto, ma potrei proporlo a qualche cliente.

Docker #

Certo non uno strumento nuovo, ma che ancora non mi sono abituato ad adoperare con costanza. Prima o dopo rivedrò le mie procedure di deploy per meglio isolare le diverse applicazioni ed i diversi ambienti, ed automatizzare alcuni passaggi.

Google Cloud #

Con la piattaforma Google vivo un rapporto di amore ed odio: offre innumerevoli API e servizi, ma ad un costo solitamente elevato; d’altro canto, per alcune attività (solitamente, quelle legate all’AI) il risultato è oggettivamente migliore.

AWS #

Mi capita di usare la piattaforma AWS per conto di qualche cliente, ma evito di usarla per me stesso ed ancor meno di raccomandarla. Costosa, inutilmente complessa, e con un supporto pressoché inesistente.

Brevo #

Ho utilizzato Brevo fin da quando si chiamava SendInBlue, salvo poi passare a Scaleway TEM sia per i costi che per il livello di supporto tecnico. Può forse essere utile per le funzionalità legate al marketing, non certo per le email transazionali.

Paypal #

Trovo che, col tempo, il servizio offerto da Paypal sia peggiorato. E non esiste neppure più un SDK PHP ufficialmente supportato. Per i pagamenti online, meglio Stripe (e, sul mercato italiano, noto che anche l’integrazione con Satispay viene occasionalmente richiesta).

Bootstrap #

La libreria di componenti CSS per eccellenza, ampiamente personalizzabile - contrariamente alle comuni dicerie - in virtù delle innumerevoli variabili che possono essere definite in fase di compilazione Sass.

jQuery #

Bistrattato dai più, per un motivo molto semplice: utilizzare efficacemente jQuery richiede grande dimestichezza con il DOM HTML, e molti ritengono più semplice utilizzare delle astrazioni - che hanno a loro volta delle complicazioni. Mi capita occasionalmente di metter mano a React o Vue, ma solo per aggiustare qualche componente realizzato da altri: se devo implementare qualcosa io da zero, jQuery è ancora la prima scelta.

Laravel #

Nel bene e nel male, il framework che mi trovo ad usare più frequentemente. Forse anche troppo frequentemente: talvolta non fa male provare qualcosa di diverso. Resta il fatto che negli anni ho acquisito una conoscenza piuttosto approfondita di questo sistema e dei suoi internals.

Go #

Potrebbe essere una soluzione per l’implementazione di applicazioni binarie, laddove fosse necessaria una prestazione superiore rispetto al solito PHP. Attualmente sto conducendo qualche esperimento, e francamente lo trovo più comprensibile di Rust.

Lunar #

Non mi capita spesso di implementare piattaforme e-commerce, ma sinora questo è il miglior strumento che ho avuto modo di provare, offrendo un ottimo equilibrio tra funzionalità out-of-the-box e personalizzazione.

SPARQL #

Benché relegato da anni agli ambiti accademici, ritengo che SPARQL (e, per estensione, tutte le tecnologie che ricadono nella più ampia definizione di “Semantic Web”) abbia un grande potenziale per l’implementazione di modelli dati iper-relazionali. Non di rado mi piace metterci mano, e sto iniziando ad introdurlo in qualche progetto per i miei clienti.

Symfony #

La mia dipendenza da Laravel mi impedisce di iniziare nuovi progetti con quello che, di fatto, è il framework PHP su cui Laravel stesso è costruito. Ma davvero non mi dispiacerebbe cimentarmi più frequentemente nel suo utilizzo.

daisyUI #

Non riesco a comprendere Tailwind, ma una libreria di componenti potrebbe aiutare a farmelo digerire. Almeno, come occasionale alternativa a Bootstrap.

Flutter #

La mia grossa lacuna, in qualità di developer freelance, sono le app mobile. E l’integrazione di Progressive Web Apps implicherebbe comunque l’adozione di framework Javascript client-side tipo React, con cui non vado molto d’accordo. Flutter potrebbe essere una via di mezzo, ma non ho ancora avuto il coraggio di affrontarlo sul serio.

htmx #

Non sono ancora riuscito a capire se sia un compromesso tra jQuery e gli ingombranti framework stile React, o se sia un inutile grattacapo. Confido di scoprirlo presto, facendo qualche esperimento.

Tauri #

Un’altra possibile soluzione per colmare la mia lacuna sulle applicazioni mobile e desktop, col vantaggio di poter comunque “riciclare” ed anzi estendere le mie competenze di sviluppo web (contrariamente a Flutter).

Rust #

Ho provato ad implementare qualcosa in Rust, ma ho disastrosamente fallito. Sei anni di esperienza in programmazione C sul curriculum non sono bastati per districarmi in un sistema di tipizzazione assai più sofisticato e complesso. Non l’ho completamente accantonato, ma sto valutando con maggiore interesse Go come alternativa per le applicazioni binarie ad alte prestazioni.

Beanstalkd #

Semplice da installare e da configurare, quando devo predisporre una queue in cui processare i job più lenti di una applicazione web preferisco il buon vecchio Beanstalkd a soluzioni più blasonate.

DebugBar #

Tra le dipendenze che includo quasi ciecamente ogni volta che avvio un nuovo progetto (in particolare con Laravel), ed uno strumento essenziale per fare qualche ottimizzazione a posteriori.

eCharts #

Ci sono infinite librerie Javascript per la creazione di grafici, ma trovo eCharts quella più personalizzabile e performante per visualizzare grossi dataset. La mia prima scelta quando devo realizzare dashboard di analisi.

Jekyll #

Non il miglior generatore di siti statici in assoluto, ma il più documentato e semplice da usare. Ogni tanto provo qualcosa di diverso, ma per ora questa è ancora la mia scelta primaria quando si tratta di realizzare un sito web che richiede altissime prestazioni. Nonostante il mio Ruby sia un po’ limitato.

Vite #

Talvolta ci devo litigare, ma non ne posso fare a meno: qualsiasi mio nuovo progetto web, a prescindere dal linguaggio o dal framework, prevede sempre compilazione e compressione degli asset Javascript e CSS con Vite (finalizzata, tra le altre cose, al raggiungimento dei requisiti richiesti dai Core Web Vitals).

Apache Jena #

Usando SPARQL, ovviamente serve un triplestore. Apache Jena non è forse il più veloce disponibile, ma è il più semplice da mettere in opera ed offre numerosi strumenti che semplificano l’attività di sviluppo.

Insight Hub #

Utile per il monitoraggio applicativo, e per intercettare tempestivamente problemi ed errori che si manifestano sulle istanze di produzione. Lo uso per alcuni progetti personali e progressivamente lo sto adottando per le attività di manutenzione continua dei clienti.

SonarQube #

Strumento per l’analisi statica, che fornisce interessanti segnalazioni e consigli per perfezionare il codice ed aumentarne il grado di organizzazione, astrazione e manutenibilità. Attualmente lo uso solo per alcuni progetti personali, vorrei man mano estenderlo anche ai progetti dei miei clienti.

XHPROF #

Occasionalmente, quando DebugBar non basta, mi capita di fare profiling di qualche applicazione o di qualche libreria. Un altro strumento che sinora ho utilizzato solo per i miei progetti, ma che potrebbe tornare utile anche per i progetti di qualche cliente (soprattutto dove sono richieste performance elevate).

Zabbix #

Già da qualche tempo ho predisposto una istanza Zabbix per il monitoraggio dei miei server, ma sono sicuro che si possa fare molto di più e molto meglio, sia in termini di prevenzione dei problemi che di raccolta dati. Sicuramente uno strumento da sfruttare meglio.

FrankenPHP #

Da una parte mi incuriosisce, dall’altra mi intimorisce, ma resta il fatto che prima o dopo dovrò fare qualche sperimentazione seria con il “worker mode” (approccio che in verità ho già adottato in passato usando ReactPHP, ma solo in circostanze molto particolari).

Jigsaw #

L’idea di avere un generatore di siti statici in PHP, e che utilizza pure il template engine di Laravel (anziché il classico Twig, che ha i suoi difetti), è allettante, ma le prime esperienze con Jigsaw non sono state entusiasmanti: l’ho trovato un po’ caotico. Probabilmente ci riproverò.

Static Analysis #

Basta una semplice riga nella configurazione della propria pipeline Gitlab per eseguire qualche controllo formale sul codice, ed identificare immediatamente (e automaticamente) un errore di battitura, una possibile vulnerabilità e altri piccoli e grandi problemi prima di procedere col deploy in produzione. Quando creo un nuovo progetto PHP/Laravel, PHPStan è tra le prime cose che installo.

Unit Testing #

La stesura di test automatizzati richiede un poco di impegno in più rispetto all’allestimento dell’analisi statica, ma spesso ne vale la pena. Tantopiù nei progetti in cui le specifiche evolvono insieme all’implementazione, e capita fin troppo spesso di modificare (ed involontariamente rompere) qualcosa. Di norma provvedo ad una copertura almeno del 40% del codice scritto, in casi molto specifici arrivo al 70%.

Core Web Vitals #

Naturalmente, per i siti web che prevedono una parte pubblica di contenuti che devono essere indicizzati e posizionati dai motori di ricerca, bado all’ottimizzazione tecnica e raramente mi accontento di uno score inferiore a 80 su PageSpeed Insights. Ma vorrei integrare questo genere di ottimizzazioni anche per le parti non pubbliche, e non necessariamente finalizzate alla performance SEO, allo scopo di rendere più efficienti le mie implementazioni.

RDFa #

Direttamente correlato al tema del Semantic SEO, attualmente sto conducendo qualche test sull’integrazione di attributi RDFa nei template web. Non solo per favorire la lettura dei contenuti, ma anche il loro popolamento automatico da parte dell’applicazione.

Semantic SEO #

L’idea di poter arricchire di significato semantico le pagine web mi affascina, e se questo poi ha anche un ritorno in termini di prestazioni SEO tanto meglio. Al di là delle classiche implementazioni Schema.org, ogni tanto mi capita di fare qualche esperimento più sofisticato su qualche mio sito personale.

Svelte #

Se mai adotterò un framework Javascript diverso da jQuery e più orientato alla “reattività”, questo potrebbe essere Svelte. Ma non è ancora passata abbastanza acqua sotto i ponti.