Cosa va provato ?

Di qualcosa e di qualcuno bisogna fidarsi. Non si tratta di una scorciatoia, è il modo per non lavorare come dei buoi.

Se facciamo, per esempio, una funzione che somma due numeri, fare un unit test che provi le somme o farne cinque, sei oppure mille è la stessa identica cosa, infatti non potremo mai provare tutte le combinazioni di numeri possibili: dobbiamo solo verificare che il nostro programma sommi e che non faccia sottrazioni o altre operazioni. Fare tanti test significa provare "l'operatore somma" dello strumento e non ha senso: se non va, si cambia strumento immediatamente.

Allo stesso modo chi fa test di un' applicazione di database non deve provare il funzionamento del database stesso, perché se si scoprisse un bug sul database, bisognerebbe intervenire subito a sostituirlo o ad applicare una correzione. E' necessario avere dei punti certi, fissi.

Credo che troppo spesso nelle software house italiane si premi la velocità di sviluppo, perché la velocità determina il costo di produzione. Credo che questo dipenda in larga parte dal fatto che esse producono soluzioni con basso valore aggiunto, quindi il fattore determinante è il costo. E' chiaro infatti che produrre un sistema per una banca online senza il quale la banca non esisterebbe, ha un gran valore e il cliente è ben disposto a pagare la novità e la qualità. Fare lavoretti, che al massimo danno prestigio all'azienda di lustrini italiana, non porta valore e bisogna fare presto. Allora via libera a modi di lavorare alienanti e tempi asfissianti, che portano per assurdo a lavorare di più e a metterci di più.

Oltre alla frustrazione per il lavoratore, il costo è più alto! Vaglielo a spiegare.

I test vanno fatti con intelligenza, non con fretta.

Tutto passa, anche la jvm

Credo che il tempo glorioso dei linguaggi (ma sarebbe meglio parlare di ecosistemi) basati su virtual machine stia volgendo al termine.

Con questo non voglio dire che i vari Java (quindi Scala, Jython ecc...) così come .NET, spariranno domattina, vista la base di installato, ma anche vista l'enorme disponibilità di librerie e strumenti.

Voglio però dire che c'è sempre meno bisogno di un programma cross platform, grazie alla possibilità di virtualizzare un sistema operativo intero. Ci sono strumenti che compilano programmi cross platform e non hanno quindi tutto l'overhead di una virtual machine. Se poi guardiamo i sistemi con i container, i quali magari si lanciano e chiudono dinamicamente per la scalabilità orizzontale dell'applicazione, è preferibile avere strumenti che usino poche risorse e che siano veloci a caricarsi; è quindi evidente che l'overhead di una virtual machine è un problema. Non mi stupisce quindi che si spingano tecnologie come GraalVM, ma mi chiedo se a questo punto non valga la pena di guardare altrove.

Da un lato C++ spaventa i neofiti così come spaventa le aziende, che sono abituate a cercare programmatori a basso costo, bassa formazione e alta sostituibilità e ne ho viste tante, veramente troppe. Oggi i linguaggi possibili sul cloud non sono comunemente compilati, penso a Javascript con Node.js, che si può usare anche nelle funzioni o lambda dei cloud più comuni oppure sono semisconosciuti (come Swift e Rust, soprattutto quest'ultimo mi sembra una vera chicca, ma non trovo offerte di lavoro su di esso, quindi mi chiedo se in Italia lo usi qualcuno). Altre soluzioni mi sembrano troppo sperimentali.

Il concetto però è che usare Java o .NET in una funzione di un cloud come in un container non è la scelta migliore, perché quando sono nati non si parlava certo di container o di lambda. Se poi dobbiamo fare una piccola web app, con poco budget e magari ci occupiamo sia del front end che del back end, di sicuro dobbiamo imparare javascript, allora tanto vale usarlo anche sul server, perché imparare un linguaggio diverso?

Non voglio parlare poi del desktop, che sta diventando sempre più una nicchia, ma personalmente trovo che Java in quel settore sia sempre stato un pesce fuor d'acqua: evidentemente non muoveva il denaro dietro allo sviluppo lato server (il nuovo Cobol si diceva), quindi le proposte fatte nel tempo (AWT, Swing e alla fine JavaFX) non hanno mai convinto del tutto. Oggi JavaFX è stato scorporato dal JDK e se dovessi fare un'applicazione desktop, oggi cercherei delle alternative e questo vale anche per .NET, lento, grosso, un framework che non mi è mai piaciuto.

Java ha perso un'occasione fantastica con gli smartphone, perché se da un lato Android per me è un fork di Java e non mi stancherò mai di dirlo, su iOS non esiste proprio.

Ho investito gran parte della mia carriera lavorativa su questo linguaggio, ma oggi vedo sempre meno opportunità.

Oggi è meglio conoscere un po' di diverse tecnologie, imparare bene nei dettagli uno strumento richiede un investimento di tempo che difficilmente ritorna, le tecnologie invecchiano in fretta e si rischia veramente che l'investimento non ritorni, però non voglio giustificare chi si butta nei progetti e, soprattutto, butta i collaboratori, senza conoscere lo strumento. I corsi sono tutt'ora molto utili per evitare i guai, ma credo che imparare bene un framework intero paghi meno che sapersi districare su diversi strumenti. Non vale soltanto per la programmazione, anche con i database è così e oggi bisogna conoscere almeno un database NoSQL, perché i database relazionali non sono la soluzione migliore con i microservizi e a questo potrei dedicare un articolo più avanti.

Noi non siamo la tecnologia che usiamo. Non ci dobbiamo identificare con essa e dobbiamo essere pronti a cambiarla, quando i tempi e le condizioni di mercato lo impongono.

Bisogna sempre stare con la valigia in mano insomma. Da un lato si dice che serve una grande specializzazione, ma dall'altro specializzarsi non deve significare legarsi a una tecnologia, che passa.