Informatica Libera - Francesco Galgani's Blog

> INDICE DEL CORSO

Quanto segue deriva dalla mia esperienza nell'Ingegneria del Software per applicazioni mobili e dai miei tanti errori e correzioni di rotta...

Linee guida di base per la gestione della complessità in un progetto software

1. Rapportati continuamente con gli stakeholder e con altri sviluppatori, prendi l'abitudine di usare in maniera proficua piattaforme di mutuo aiuto tra sviluppatori come StackOverflow e Github, costruisci rapporti umani di fiducia, cerca di far parte di un team in cui il tuo lavoro è apprezzato e valorizzato (cioè retribuito) e stai lontano da ambienti dove le relazioni umane invece di essere costruttive sono distruttive.
2. Chiarisci il problema da affrontare, poi pensalo ad oggetti, lavoralo ad oggetti, struttura tutto ad oggetti. Scegli un linguaggio che ti direzioni correttamente e ordinatamente a lavorare ad oggetti (Java).
3. Fa che i tuoi strumenti di lavoro riducano al minimo il tuo sforzo e che ti regalino la massima compatibilità multi-piafforma: un'eccellente scelta lato client è l'approccio "write once run anywhere" di Codename One, un'ottima scelta lato server è l'approccio "production-ready" di Spring Boot.
4. Il codice deve essere organizzato secondo un approccio top-down, nella maniera più intuitiva possibile: parti da una visione globale del problema, struttura il codice in livelli diversi, in modo che ogni funzionalità complessa sia alla fine ridotta ad una sola riga di codice (o quasi), la cui implementazione sia la più generica possibile (finché ha senso generalizzare in base al contesto e finché è verosimile che sia utile). Seguire un approccio top-down significa anche fare in modo che i problemi implementativi siano il meno possibile bloccanti rispetto al progetto complessivo.
5. Suddividi il lavoro in task programmabili: un approccio top-down rende realistica la creazione di una serie di compiti che possono essere programmati senza conoscerne ancora l’effettiva implementazione, permettendoti di avanzare con maggior sicurezza e senza perdere l’orientamento anche quando le cose da tenere a mente (ovvero le questioni aperte su cui stai lavorando) sono tante.
6. Prima di scrivere il codice, valuta varie alternative, magari facendo grafici, disegni o procedure anche su carta, e scegli l’algoritmo meno incasinato e più vicino alla logica di funzionamento del tuo ambiente di sviluppo (ad es., il più vicino possibile alla logica delle API di Codename One).
7. Tra le varie alternative di algoritmi, parti sempre dalla soluzione che ti pare più semplice e che “approssima” sufficientemente il problema, creando un apposito test case: l’aggiunta di dettagli o di perfezionamenti dovrebbe essere indipendente dal progetto complessivo, in modo da isolare le singole funzionalità, e dovrebbe avvenire solo quando il codice più semplice è sufficientemente collaudato.
8. Ogni parte del codice deve essere autoesplicativa, si deve capire velocemente cosa fa: ne segue che non ci devono essere casini, cioè ogni codice che può apparire criptico va evitato, oppure, in casi particolari che proprio richiedono un codice non intuitivo, questo va isolato e adeguatamente documentato. Anche la scelta dei nomi dei package, dei nomi delle classi e della collocazione delle classi all'interno dei package dovrebbe essere autoesplicativa.
9. L’aggiunta o la modifica di funzionalità dovrebbe essere agevole: ciò è una naturale conseguenza dei punti precedenti se applicati correttamente. Più è grande il progetto, infatti, e maggiore è il bisogno di rendere il codice manutenibile e comprensibile anche a distanza di tempo. Evitare grossi blocchi di codice, isolare i problemi e ridurre la ridondanza sono d'aiuto.
10. In progetti complessi, i dettagli implementativi potrebbero essere inseriti in un apposito package diverso dal resto del progetto (una sorta di package che contiene solo utilities).
11. L'esecuzione di test e lo sviluppo vanno di pari passo: fai i test di ogni pezzo di implementazione sia nel simulatore (di Codename One) sia sui target previsti dal tuo progetto (ad es. Android, iPhone, Web-App, ecc.). Soprattutto quando sviluppi multi-piattaforma, non dare per scontato che le cose funzionino sempre come previsto: per ogni modifica o aggiunta su cui hai dubbi, è sempre meglio fare verifiche su target diversi.
12. Fai release frequenti del tuo lavoro e sottoponile agli stakeholder: ciò serve sia da testing, sia da costante verifica del corretto perseguimento degli obiettivi del progetto.
13. Ogni volta che si verifica un imprevisto o un'anomalia non chiara, è meglio isolare il problema in un test case sufficiente a riprodurlo, usando il minimo strettamente indispensabile di righe di codice: ciò è molto utile anche per chiedere aiuto ad altri sviluppatori (anzi, di solito è l'unico modo proficuo per poter chiedere aiuto). Repetita iuvant: se qualcosa non va, ma il codice è corretto o ti sembra tale, isola il problema e chiedi ad altri sviluppatori, piuttosto che tentare di raggirare il problema inserendo ulteriore codice.
14. Quando capitano cose che ti appaiono impossibili o insensate, è il momento di fare una pausa. Soprattutto quando sei assolutamente certo che il tuo codice deve fare una cosa e invece ne fa un'altra... spegni il computer e vai a fare altro.
15. Quando per risolvere un problema semplice il tuo codice si fa via via sempre più complesso e ti sembra di aver perso il controllo di ciò che fa o di come interagisce con il resto dell'app, allora... calmati, accetta l'ipotesi che forse hai speso ore e ore nella direzione sbagliata e, a mente serena e riposata, affronta di nuovo il problema da capo.
16. Usa un ambiente di sviluppo (IDE) che ti agevoli nel conservare copie del tuo lavoro risalenti a momenti diversi e che, ogni volta che sarà opportuno, ti permetta di annullare le modifiche per tornare a uno snapshot precendetemente salvato: una soluzione valida può essere Netbeans all'interno di un ambiente virtualizzato (ad es. con VirtualBox). Questo approccio dà grande libertà di sperimentare senza paura di far danni o di perdere il lavoro fatto.

Francesco Galgani,
1 maggio 2019

If you have trouble following these instructions, you can download the deb file I made from here:
https://www.informatica-libera.net/files/oracle-java8-jdk_8u231_amd64.deb.

At the moment, there is no working PPA to automatically download and install Oracle Java8 JDK 8u211 or 8u212 or later on Debian / Ubuntu / Linux Mint, because it's strictly necessary to manually download the jdk-8u211-linux-x64.tar.gz or jdk-8u212-linux-x64.tar.gz file from the Oracle site, after logging in:
https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

You can transform the jdk-8u212-linux-x64.tar.gz in oracle-java8-jdk_8u212_amd64.deb using make-jpkg provided by java-package.

So, remove any other Java version previously installed from the discontinued Java8 PPA (sudo apt-get remove oracle-java8-installer) then:

1. sudo apt-get install java-package

2. make-jpkg jdk-8u212-linux-x64.tar.gz

3. sudo dpkg -i oracle-java8-jdk_8u212_amd64.deb (or any graphical installer opened by a double click on the deb, like gdebi-gtk)

4. sudo apt-get -f install (to install missing dependencies)

That's all! :-)

Francesco Galgani,
30 April 2019

fonte per scaricare PDF o acquistare volantini cartacei:
https://www.agireoraedizioni.org/opuscoli-volantini/vegan/volantino-latte-uova/

Per una visione di come vengono trattati gli animali, rimando al film documentario DOMINION, che denuncia la violenza sugli animali di ogni specie. Racconta in modo estremamente toccante gli orrori dello sfruttamento animale in ogni settore, ma soprattutto in quello degli allevamenti per l'alimentazione umana.

Una delle leggi della Fisica è che non è possibile superare la velocità della luce. La prendo per vera, ci hanno già pensato altri a dimostrarla. Piuttosto… stavo pensando una cosa…

La velocità, in senso assoluto, non esiste, nel senso che è sempre relativa a qualcos’altro. Ad es., un passeggero seduto all’interno di un treno in movimento a che velocità si sta muovendo? Beh, ovviamente dipende dal punto di vista: rispetto al suolo sotto il vagone, la sua velocità è uguale a quella del treno, mentre rispetto al vagone la sua velocità è zero (perché ho ipotizzato che è seduto). Fin qui nulla di straordinario…

A ben vedere, però, si potrebbe obiettare che sia normale prendere come punto di riferimento per la velocità qualcosa di “fermo”. Peccato, però, che nell’universo non ci sia nulla di fermo, o meglio, qualcosa può essere considerato fermo (cioè a velocità zero) solo se si sta muovendo nella stessa direzione e verso di ciò che prendiamo come punto di riferimento. Come nell’esempio precedente, il passeggero è fermo solo nel senso che si sta muovendo nella stessa direzione e verso del treno. Al tempo stesso, il suolo è fermo? Direi proprio di no, tutti sanno che la Terra si muove sia su se stessa, sia intorno al Sole. Il Sole è fermo? No, si muove insieme a tutta la galassia. E così via… qualunque punto di riferimento non è fermo in senso assoluto, quindi qualunque cosa può essere legittimamente presa come punto di riferimento per il calcolo di una velocità. Anche fin qui, nulla di straordinario…

Continuando questo ragionamento, prendiamo come punto di riferimento per il calcolo della velocità di me stesso, mentre scrivo al computer queste riflessioni, un fotone che si sta muovendo dal Sole verso la Terra. Qual’è la mia velocità rispetto al fotone?

Semplice: il fotone, essendo il nostro punto di riferimento, è fermo (rispetto agli altri fotoni che si stanno muovendo insieme a lui nella stessa direzione e verso), mentre io mi sto muovendo alla velocità della luce “verso di lui”. Chiaro? Se poi, invece di starmene seduto al computer, salgo su un ascensore e comincio a salire andando incontro al fotone, la mia velocità, che prima era pari a quella della luce, la supera, seppur di poco. Ovvio, no?

Questa è la Legge della Relatività dei Punti di Vista, con la quale ho superato (di poco) la velocità della luce.

Potrei concludere qui… e invece preferisco concludere con un altro esempio per chi desiderasse superare di molto la velocità della luce. Basta prendere due puntatori laser direzionati lungo la stessa linea, ma con verso opposto: prendendo come punto di riferimento uno qualsiasi dei fotoni del primo laser, i fotoni del secondo laser si muoveranno al doppio della velocità della luce rispetto ad esso (in questo caso, il segno della velocità sarà positivo se i due laser puntano l’uno verso l’altro, negativo altrimenti).

E se volessi ottenere una velocità pari al triplo di quella della luce? Lascio questo esercizio ai miei lettori dotati di fantasia. Quel che spero di essere riuscito a comunicare è che i nostri punti di vista possono essere molto illusori perché tremendamente agganciati a ciò che conosciamo: cambiando punto di vista, anche ciò che sembra impossibile può essere superato. E questo, ovviamente, non vale solo per la velocità della luce.

A proposito di velocità della luce, il ragionamento fin qui esposto contiene una contraddizione tra la tesi iniziale (l'impossibilità di superare la velocità della luce) e la sua conclusione (velocità della luce superata). Ne segue che una parte di questo ragionamento è sbagliata (o che è sbagliata l'ipotesi iniziale), proprio perché "agganciata a ciò che conosco". I nostri ragionamenti possono essere molto fallaci se si basano su conoscenze, deduzioni o ipotesi che a loro volta sono incompleti, inesatti o falsi. Non solo: da un punto di vista strettamente logico, da una ipotesi falsa si può arrivare a qualsiasi conclusione, ovvero è possibile dimostrare tutto ciò che vogliamo, anche in contrasto con la realtà, se ci basiamo su ipotesi che non sono corrette nel senso di aderenti alla realtà. Qui però si aprirebbe un altro discorso su cosa è reale e cosa no, e sul fatto che non è reale ciò che è reale ma ciò che noi riteniamo tale... ma ora davvero mi fermo qui.

Buone riflessioni,
Francesco Galgani,
23 aprile 2019