Oggi vorrei parlarvi di un algoritmo.

Di norma un algoritmo talmente semplice da essere usato durante i colloqui per la valutazione della capacità minima di scrivere e leggere codice che comprenda il minimo indispensabile di logica, matematica e pensiero critico.

L’algoritmo consiste nell’implementare una funzione che dati i numeri da 1 a 100 faccia quanto segue:

• stampi la stringa “Fizz” quando il numero è un multiplo di 3
• stampi la stringa “Buzz” quando il numero è un multiplo di 5
• stampi la stringa “FizzBuzz” quando il numero è un multiplo di 3 o 5
• stampi il numero quando non è un multiplo di 3 né di 5

Semplice semplice. Ma allora perché ne parlo?

Di norma direi che il calcolo delle stime è qualcosa che facciamo tutti i giorni e che quindi almeno sulla carta ogni programmatore dovrebbe saper farlo.

Di norma direi anche che ci dovrebbe essere una procedura, una best practice una formula che possa calcolare una stima.

Siamo programmatori, quindi siamo ingegneri (più o meno)!

Oggi vorrei raccontare una storia.

La storia di un recruiter incompetente che malauguratamente mi ha contattato in una giornata storta.

Ultimamente mi trovo spesso a leggere di sviluppatori che non conoscono determinati acronimi, o che si ritrovano a chiamarsi “sviluppatori” senza sapere cosa effettivamente significhi sviluppare software.

E come al solito mi triggero sulle basi e vado dritto come un pesce all’amo tentando di sviscerare un argomento che molti altri più bravi di me hanno tentato di sviscerare in libri interi spesso riuscendoci solo in parte.

Mi ripeto sempre che è una cattiva idea usare un blog per parlare di un argomento così vasto e che i grandi come Uncle Bob e Kent Beck si rivolterebbero nella tomba se ne avessero una.

Ma siccome sono entrambi ancora vivi, non temo questa reazione e quindi sbaglio con piacere, sperando anche di fare cosa gradita a quei 3 scappati di casa che leggono questo sito.

Inizio, dopo l’inizio, dicendo che le basi dello sviluppo di software sono tante, e lo sviluppo di software è un’arte complessa che merita tempo per lo studio e dedizione per la materia, mancanti le quali il software non può essere sviluppato oppure può esserlo ma sarà brutto, poco performante, difficile da mantenere e probabilmente pieno di problemi.

E soprattutto, un software sviluppato senza conoscere le basi sarà consegnato in ritardo, sempre. Qui non ci sono deroghe.

Riporto integralmente l’articolo di Tom Purl che parla dell’integrazione della matrice di Eisenhower in Emacs Org-Mode.

Purtroppo Tom ha rimosso l’articolo dal suo sito ma sono riuscito comunque a trovarlo tramite la Wayback Machine.

Di seguito (in inglese) l’articolo integrale. Forse (forse) porterò una traduzione di questo articolo nel blog, a imperitura memoria, soprattutto per chi non mastica granché l’inglese.

Recentemente mi sono appassionato al Machine Learning.

Per chi non sapesse cos’è, il machine learning è una tecnologia (un insieme di tecnologie, in realtà) che permette calcoli piuttosto complessi in modo relativamente semplice e, cosa estremamente più importante, che può imparare dai dati che gli vengono somministrati.

Questo permette di effettuare calcoli complessi sempre più precisi fino a un tasso di fallimento che rasenta lo zero, un fattore necessario per mansioni complicate e critiche come il riconoscimento delle semantico immagini e l’elaborazione statistica.

Il TDD è una di quelle metodologie che più spesso viene bistrattata qui in Italia. Spesso si sente definire questo approccio come troppo costoso o peggio come fallimentare.
Molto spesso la “colpa” va al budget, sempre troppo risicato quantunque esso sia, ma qui si sa che la coperta viene commissionata su misura per un watusso e poi arrotolata fino a non coprirci neanche un pigmeo. E quello deve bastarti, altra non ne srotolano.

Al di là delle facili critiche e delle superficiali battute tragicomiche, il fatto è che c’è molto ancora da fare per convincere i più biechi antagonisti di questa tecnica che vale la pena iniziare a fare dei test un componente necessario di ogni progetto.

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.

Qualche sera fa ragionavo sul mio pregresso lavorativo, e nello specifico mi concentravo sull’ambiente di lavoro. Il trigger è stato il treno che ho preso quella sera, Ostiense, 20.40, che non è proprio il massimo della vita, questo posso dirlo, perché mi porta a casa alle 21.45 circa.

Alla fine dell’analisi preliminare ho stabilito che volevo concentrare il mio ragionamento sull’orario di lavoro (ancora una volta) tentando di sviscerare il perché mi riduco sempre a sopportare certi orari.

Mi sono trovato a dover confutare una ipotesi che portavo con me da lungo tempo.

Avevo già verificato sperimentalmente questa ipotesi anni fa, e sembrava reggere. Fino a ora.

Sono un fan di Guerre Stellari, probabilmente lo saprai.
Da appassionato del genere e dei film della Saga, negli anni ho sempre avuto quella sorta di richiamo che ogni tanto mi porta a vedere interamente tutti i film.

La saga però ha dei problemi particolari, il primo dei quali è l’ordine di visione.