Venerdì scorso ho tenuto un talk interno alla mia azienda sulle basi (molto basi) del framework Spring.
Mi sono concentrato poco sui dettagli, ho preferito puntare verso le potenzialità del framework e le feature più innovative e interessanti, con un occhio buono al cloud, vera punta di diamante di tutta la tecnologia Spring.

Oggi parlo di DevOps, argomento a me caro, chi mi conosce di persona sa quanto posso essere un serial killer di cabbasisi su questo argomento.

Introduco brevemente l’argomento dicendo che si tratta di una metodologia di organizzazione del lavoro strettamente legata all’informatica e che si presta molto bene per determinati gruppi di lavoro, determinati progetti e determinate aziende.

Oggi parlo di Git, e in particolare di una feature di questo indispensabile strumento che spesso viene sottovalutata o non considerata a dovere nell’organizzazione del codice.

Ho sempre lottato contro le cattive pratiche, chi mi conosce lo sa.
Ho sempre parteggiato per il codice di qualità, con la forte convinzione che questo possa essere un vantaggio strategico per il progetto e l’azienda che ne è proprietaria.

Proprio per questi motivi ancora oggi, da 12 anni, non riesco a comprendere perché certi project owners abbiano sempre l’idea di risparmiare il budget dello sviluppo tagliando sulla qualità. Che poi risparmiare sulla qualità non significa niente, non è che a comando siccome ti pagano di meno puoi fare un lavoro schifoso. E infatti, per forzare il programmatore a produrre codice schifoso spingono sul fattore tempo (che è sempre poco).