Site icon Smart Central

Programmatori inconsapevoli

Come avrete intuito dal titolo, oggi parleremo di programmazione ma lo faremo utilizzando un metodo di apprendimento più “amichevole” e “zen” rispetto a quello proposto su altri percorsi didattici.
Pertanto, questa lunga (ma leggera) lezione è prevalentemente rivolta a tutte quelle persone acerbe (o curiose) che vogliono iniziare a comprendere quest’arte da un punto di vista più generalista, semplicistico ed elementare.

Sicuramente qualcuno di voi, tra i più accorti, si starà chiedendo cosa c’entri la programmazione nel contesto in cui ci troviamo?!

E’ lecito chiedersi: “Questo portale mica tratterà di linguaggi di programmazione o cose simili, vero?”

Esatto! Ma non del tutto… ed è proprio partendo da queste domande che vorrei fare una rivelazione in merito alla programmazione, una rivelazione per tutte quelle persone alle prime armi che associano (inconsciamente) la programmazione all’informatica e, dunque, alla conoscenza di un linguaggio/strumento.

In realtà la programmazione scinde da un contesto specifico, come quello informatico, e la si applica costantemente in tutto ciò che ci circonda. Per tale motivo apprendere la programmazione nel senso generale del termine, vi aiuterà ad averne una visione/interpretazione più familiare quando inizierete ad approcciarla in termini informatici.

“Ummm, potresti spiegarti meglio?”

Si, cechiamo di capirlo!

Nell’immaginario collettivo è come se la programmazione e un linguaggio di programmazione fossero necessariamente la stessa cosa, ma non è così; La programmazione può essere espletata in vari modi tra cui un linguaggio/strumento informatico, ma quest’ultimo non è la programmazione.

“Frena un attimo, sono un po’ confuso. stai dicendo che la scrittura di un linguaggio per lo sviluppo di un software non è programmare?”

Si che lo è, ma la programmazione assume un significato più ampio e merita un accenno e una lezione anteposta all’apprendimento di un linguaggio/strumento a fini prettamente informatici; La programmazione, come concetto, è alla base di molteplici aspetti che viviamo (come quello informatico), ed è bene ritrovarvisi con specifici accostamenti.
Capiremo più avanti il senso di questa frase.

In questo momento sappiate solo che questa lettura, nella sua interezza, proverà a gettare le basi per una più agevole comprensione di determinati strumenti e concetti logici/informatici, e lo farà ereditandoli da contesti a noi più familiari: la quotidianità. Questi concetti di base serviranno a tutti voi per comprendere meglio strumenti utilizzati in informatica ma, principalmente, per ciò che tratteremo su Smart Central: cioè domotica e realizzazione dei Comandi Rapidi, sia essi annessi alla domotica o indipendenti.

Chiariamo il motivo di questa lezione

Prima di continuare con il racconto, vorrei spiegarvi il motivo che mi ha spinto a realizzare questa lezione “zen” sulla programmazione.
Spesse volte, facendo zapping in rete, mi accorgo di come venga naturale trattare la programmazione esclusivamente come accostamento all’informatica e ad un linguaggio, con un inevitabile abbondanza di termini tecnici lasciati lì a generare punti di domanda nella mente di chi vuole apprendere.

Ma perchè nessuno si sforza a rendere più familiari ed esemplificativi i concetti? Mah, chissà! 

Alzi la mano chi ha letto spesso titoli come – “Impariamo a programmare con … “ – piuttosto che – “Imparare a programmare”

Forse un po’ tutti avrete alzato la mano.

Forse titoli come “imparare a programmare” si riescono anche a trovare ma il loro contenuto finisce spesso con un avvicinamento alla programmazione mediante l’uso di un linguaggio informatico.

Forse alcuni di voi si staranno chiedendo che differenza ci sia tra i due titoli; non è sempre di programmazione che si sta parlando?

Beh la risposta a questa domanda è Ni! 

C’è molta differenza se la si osserva da più punti di vista! Ed è il focus di questa lezione svelarvi il motivo.

Attenzione!! non sto dicendo che è necessariamente sbagliato imparare i concetti della programmazione attraverso un linguaggio/strumento informatico, sto solo dicendo che a fini didattici (e per il bene di chi ci ascolta) è doveroso, a parer mio, mettersi nei panni del pubblico (in genere alle prime armi se è lì per imparare) fornendo una comunicazione più semplicistica ed esemplificativa possibile, partendo da una programmazione generalista e facendo uso di parallelismi mirati al fine di atterrare alla programmazione informatica con un senso di minor smarrimento; l’obiettivo che vi propongo è quello di ritrovare se stessi all’interno della programmazione informatica. Forse un po’ troppo filosofico o New Age detto così, ma è più realistico di quanto possa sembrare.

Aveva ragione Morpheus quando diceva: “Matrix è ovunque, è intorno a noi. Anche adesso, nella stanza in cui siamo. È quello che vedi quando ti affacci alla finestra, o quando accendi il televisore. L’ avverti quando vai al lavoro, quando vai in chiesa, quando paghi le tasse. È il mondo che ti è stato messo davanti agli occhi.” 😀

Beh! di sicuro non viviamo in un mondo fittizio/artefatto come quello che vediamo in Matrix (anche se alle volte lo potremmo definire distopico) ma potremmo sostituire la parola Matrix con la Programmazione: “La Programmazione è ovunque, è intorno a noi. Anche adesso, nella stanza in cui siamo. ecc”

Pertanto, proprio perchè la programmazione è ovunque, ci tengo a sottolineare quanto detto in precedenza: la programmazione merita un’accenno e una lezione anteposta all’apprendimento di un linguaggio/strumento. Soltanto cosi potremmo iniziare a vederla con occhi nuovi, averne una visione più familiare.

Ovviamente non tutto il materiale didattico che si trova in rete è cosi “sbrigativo”, ma l’evoluzione dei social e di tutti gli strumenti di comunicazione ha messo “chiunque” nella condizione di condividere il proprio “sapere” in modo semplice veloce.
Il che è un bene, ci verrebbe da dire; È molto bello e appagante condividere conoscenza, No?
Si! Ovvio che si, ma bisogna anche saperlo fare o, meglio, bisogna saper raccontare un argomento nel modo più chiaro possibile. Il guaio, spesso, risiede proprio nell’improvvisazione comunicativa di chi, per età, inesperienza espressiva/formativa o malavoglia, tratta argomenti (di varia complessità e dei quali può essere anche molto bravo) in modo errato, superficiale, rapido e poco attento al punto di vista altrui.

Altrettanto spesso, forse proprio per questa errata conformazione comunicativa di cui parlo, le persone che vogliono imparare la programmazione informatica lo fanno seguendo un percorso prematuro, cimentandosi direttamente nella scrittura del codice di un rispettivo linguaggio nativo ancor prima d’imparare i fondamentali della programmazione.
Tale approccio non fa altro che generare confusione in chi è alle prime armi, confusione e carenza di basi che porta ad inevitabili lacune future.

Pertanto, al fine di diventare programmatori e non improvvisatori informatici di un linguaggio/strumento, è doveroso per chi insegna argomentare nel modo più esaustivo ed esemplificativo possibile, tanto quanto è doveroso per chi impara documentarsi il più possibile.

Iniziamo a fare sul serio

Bene! allontaniamoci da questo tono di sprono generale (che sembra più un rimprovero) ed entriamo nel vivo della lezione.
Vi chiedo un piccolo sforzo mentale, d’ora in poi quando dirò – Programmazione – dimenticate l’accostamento informatico e pensate più in generale; L’obiettivo di questa lezione è tentare di farvi comprendere la programmazione informatica mediante accostamenti di programmazione generalista.

Partiamo pensando alla programmazione come ai fondamentali della comunicazione generale che ci porta ad imparare una o più lingue. Ognuno di noi, crescendo, impara a comunicare mediante espressioni direttamente proporzionali alla sua crescita socio/culturale. Ad esempio, possiamo chiedere l’ora a qualcuno, oppure fare un saluto, esprimere un sentimento d’amore o, ancora, creare un l’email formale per richiedere un posto di lavoro ecc.
Ogni espressione o format comunicativo del nostro bagaglio interiore, è universalmente riconosciuto a prescindere dalla lingua parlata. Possiamo fare un saluto in Italiano così come in Francese. Possiamo impostare una lettera formale in Italiano così come in Francese.
E’ vero, probabilmente alcune abitudini locali possono apportare dei cambiamenti su come ci si saluta o altro, ma il discorso alla base non cambia.
Pertanto, possiamo dire che la programmazione, e le infinite dinamiche in essa racchiuse, rappresenta i fondamentali di comunicazione di un linguaggio.

Sappiate che è esattamente ciò avviene anche in informatica; Si hanno dei concetti di programmazione universalmente riconosciuti in ogni linguaggio, ma ognuno di questi linguaggi potrebbe avere una sintassi (grammatica) differente tra loro. Ad ogni modo, questa differente sintassi non altera i concetti universali, che possono essere considerati come dei postulati.

Capite bene, a questo punto, che la comprensione di tali concetti universali non può che semplificarvi l’approccio con un linguaggio piuttosto che un altro.

La programmazione che è in noi

Proviamo a cambiare prospettiva d’osservazione e concentriamoci sul significato letterale di PROGRAMMAZIONE. Vi renderete subito conto delle mille sfumature che può assumere:

  1. Programmare la nostra giornata
  2. Programmare la lavatrice
  3. Programmare il lavoro
  4. Programmare le attività per il tempo libero
  5. … (Trovatene altri)

Una parola apparentemente sconosciuta (da forzature della nostra mente) che risulta essere applicabile e riconoscibile in mille contesti che ci riguardano.

Ecco che iniziamo a ritrovare un po’ di familiarità, un po’ di noi stessi nella programmazione; Siamo dei programmatori inconsapevoli.

Programmazione, quindi, non è conoscere un linguaggio informatico ma un linguaggio generalista, ed è esattamente un’astrazione di ciò che siamo.
In fondo, se ci pensate bene, la programmazione informatica è una creatura dell’uomo e, come tutto ciò che realizza, non può che essere a sua immagine e somiglianza. Esattamente come l’uomo è ad immagine e somiglianza delle leggi universali… Ma questo è un’altro discorso…

Concentriamoci sul concetto generalista di programmazione e proviamo a capire il perché tutti noi nasciamo e cresciamo programmatori.

Ognuno di noi esegue miriade di procedure/attività (come fossero applicazioni naturali) nell’arco della propria giornata. Nel momento stesso in cui ci alziamo dal letto, ad esempio, iniziamo ad eseguire delle routine atomiche (cioè fine a se stesse) o legata ad altre mediante interscambio di informazioni.
Per ognuna di queste routine utilizziamo degli strumenti (che in informatica vengono definiti oggetti), immagazziniamo uno o più dati (che in informatica vengono definite variabili o aree di memoria volatili), sfruttiamo dei dati di riferimento (che in informatica vengono definite dati immutabili o costanti), eseguiamo delle ripetizioni (che in informatica vengono definiti cicli) e applichiamo delle condizioni. Questo è il set base dal quale partiremo.

Vediamo qualche esempio banale di attività atomica (cioè fine a se stessa) estrapolata dalla quotidianità:

  1. Attività/Applicazione – Lavaggio dei denti
    1. Andiamo in bagno. In ambito informatico può essere visto come il Container o Playground dove avviene la procedura.
    2. Apriamo l’armadietto dal quale prelevare gli strumenti che ci servono. In ambito informatico e in modo molto figurato, possiamo considerarlo come un array/dizionario (una sorte di contenitore) di elementi di identica o varia natura. Dove in ogni scomparto è presente uno o più strumenti.
      1. Prendiamo lo Spazzolino. In ambito informatico può essere visto come uno strumento (oggetto, o azione nel caso di Shortcuts) – Spazzolino – che si aspetta un dato in entrata (il Dentifricio dal Tubetto) necessario per lo svolgimento della procedura.
      2. Prendiamo il Tubetto di Dentifricio. In ambito informatico può essere visto come uno strumento (oggetto, o azione nel caso di Shortcuts) – Tubetto di Dentifricio – che fornisce un dato in uscita (il Dentifricio) allo strumento Spazzolino.
    3. Applichiamo il dentifricio sullo spazzolino. Quest’azione può essere vista, in ambito informatico, come la creazione dell’istanza dei due strumenti (oggetti, o azioni nel caso di Shortcuts), oppure come il passaggio di dati da uno strumento all’altro: cioè uno strumento fornisce un dato in uscita ad un altro strumento per permettere a quest’ultimo di dare inizio all’elaborazione: Lo spazzolamento.
      Figurativamente: Lo strumento spazzolino riceve il dentifricio in uscita dallo strumento Tubetto.
    4. Eseguiamo la prima routine di lavaggio. Sappiamo che in media occorre spazzolare per 2 minuti (dato di riferimento immutabile), pertanto ripetiamo l’azione di spazzolamento ciclicamente. Ad ogni ciclo controlliamo che siano passati 2 minuti. Se sono passati due minuti, interrompiamo e risciacquiamo, altrimenti continuiamo a spazzolare.

Cosa abbiamo appreso da questa banale routine di programmazione?

  1. E’ presente un contesto di elaborazione – (Il bagno)
  2. Facciamo riferimento ad un contenitore dal quale preleviamo degli oggetti – (L’armadietto che contiene lo Spazzolino e il Tubetto del Dentifricio)
  3. Utilizziamo degli strumenti (oggetti, o azioni nel caso di Shortcuts) aventi, ognuna, delle sue caratteristiche e funzionalità – (Spazzolino e Tubetto del Dentifricio)
  4. Facciamo riferimento a delle costanti – (dati immutabili. Nello specifico, i 2 minuti di riferimento per un buon lavaggio dei denti)
  5. Utilizziamo delle variabili (o arie di memoria del nostro cervello nelle quali immagazzinare dei dati. (Il tipo di spazzolino e dentifricio che stiamo usando, la quantità di prodotto, il colore dei prodotti, il numero di cicli in corso per il lavaggio) 
  6. Eseguiamo delle ripetizioni o cicli – (Il numero di volte in cui eseguiamo lo spazzolamento sino al raggiungimento dei due minuti) 
  7. Applichiamo delle condizioni – (Verichiamo il raggiungimento dei due minuti ad ogni spazzolamento)

 

Facciamo un ulteriore esempio basato su un’altra classica situazione quotidiana ma questa volta più raffinata del precedente, cioè ancora più vicina ad un accostamento informatico in modo figurato. 

  1. Attività/Applicazione – Prendere appunti alle lezioni scolastiche
    Per fini esemplificativi, immaginiamo di avere un quaderno nel quale appuntare gli estratti di ogni singola lezione/materia seguita nel corso della nostra giornata scolastica.
    Ad esempio, potremmo definire una gerarchia di appunti nella quale una copertina classifica il giorno delle lezioni e le pagine seguenti classificano le materie: 

Avendo chiara l’organizzazione dei nostri appunti, procediamo schematicamente con la nostra attività (applicazione naturale)

  1. La Classe (stanza o luogo in cui svolgiamo le nostre attività). Possiamo considerarlo in ambito informatico come il Container o Playground dove avviene la procedura.
  2. Apriamo il nostro zaino dal quale prelevare gli strumenti che ci servono. In ambito informatico e in modo molto figurato, possiamo considerarlo come un array/dizionario (una sorte di contenitore) di elementi di identica o varia natura. Dove in ogni scomparto è presente uno o più strumenti.
    1. Prendiamo il nostro Quaderno. Con un accostamento più realistico a quello informatico, possiamo considerarlo come un array/dizionario (una sorte di contenitore/catalogatore mono o multidimensionale, cioè può essere un array/dizionario) di dati di identica o varia natura (testo, numeri interi, numeri decimali, valori booleani e/o altri elementi riportabili all’interno).
    2. Prendiamo la nostra Penna. In ambito informatico possiamo considerarlo come ulteriore strumento che fornisce un dato in uscita (L’inchiostro) allo strumento Quaderno, al fine di scrivere nuovo dati al suo interno.
  3. Azione di scrittura sul quaderno. Quest’azione può essere vista, in ambito informatico, come la creazione dell’istanza dei due strumenti (oggetti, o azioni nel caso di Shortcuts), oppure come il passaggio di dati da uno strumento all’altro: cioè uno strumento fornisce un dato in uscita ad un altro strumento per permettere l’inizio di un elaborazione: La scrittura degli appunti.
  4. Eseguiamo delle routine di scrittura appunti per ogni materia. Tecnicamente si potrebbe dire, in termini informatici, che siamo all’interno di un ciclo nel quale andremo a ripetere le medesime azioni per singola materia:
    Se entra il professore succede questo:
    1. Apriamo il quaderno nel giorno corrente
    2. Scriviamo la materia 
    3. Scriviamo il nome del professore
    4. Scriviamo gli argomenti affrontati ogni volta che ne sentiamo l’esigenza
    5. Scriviamo la durata della lezione

Vediamo a cosa corrispondono gli elementi del ciclo in ambito informatico:

L’intera parametrizzazione degli appunti presi sul quaderno, quindi, identificherà la struttura del dizionario. Mentre la memorizzazione degli appunti presi rappresenterebbe, come detto, il salvataggio vero e proprio del dizionario su una variabile (area di memoria).

Un ulteriore passo in avanti

Come potete vedere da questi esempi, abbiamo realizzato (e realizziamo) programmi senza neanche rendercene conto e senza neanche l’uso di linguaggi/strumenti informatici.
Di esempi del genere ne potremmo fare tantissimi quante sono le attività che eseguiamo nell’intera giornata.
Prima di continuare, provate a svolgere un esercizio; Utilizzate una delle vostre attività giornaliere e cercate di individuarne/applicarne i corretti strumenti di programmazione informatica all’interno di tutta l’attività che svolgete. Esattamente come abbiamo fatto. Questo esercizio vi aiuterà ad analizzare la programmazione che vi circonda quotidianamente.

Alla luce di quanto sopra descritto, abbiamo capito che un’applicazione è formata da un insieme di strumenti, quali: cicli, condizioni, salvataggio di dati, utilizzo di dati di riferimento, utilizzo di oggetti ecc.
Appurato questo, vediamo un altro esempio banale che descrive due attività/applicazioni comunicanti. Quindi non soltanto applicazioni isolate e fine a se stesse, ma ognuna delle quali eseguirà delle azioni (come visto nell’esempio precedente) il cui scopo esemplificativo sarà quello di comprendere un altro meccanismo della programmazione: I’interscambio di dati tra due applicazioni (o comandi) sia essi in rete o localmente.

Per questo esempio resteremo in ambito scolastico e utilizzeremo una delle classiche situazioni nella quale ognuno di noi, penso, si sia trovato: Scambiarsi gli appunti di una lezione tra compagni.
Supponiamo, pertanto, che un nostro compagno di scuola, assente per malattia, ci chieda di seguire e prendere appunti alle lezioni anche per suo conto e, al termine della scuola, lui stesso ci chiamerà per ottenere gli appunti presi per lui. In alternativa a quest’ultima condizione, potrebbe chiedere a noi di contattarlo per ottenere gli appunti. 

“Perché hai voluto precisare questa ulteriore condizione?”

Ci servirà a comprendere un’altro strumento della programmazione informatica: Risorse da far richiamare ad un’applicazione in un dato momento del suo lavoro. Possiamo intenderle come fosse una Callback.
In questo momento concentriamoci sulla prima condizione, cioè quella nella quale il nostro compagno ci chiamerà ad una certa ora per ottenere i compiti.

Partiamo con gli esempi e riassumiamo schematicamente il focus prefissato nella prima condizione. Abbiamo 2 attività (o applicativi) comunicanti eseguite da due persone distinte:

  1. Attività/Applicazione 1, quella svolta dal Compagno 1: 
    1. Segue le lezioni e prende gli appunti necessari al suo studio casalingo e a quello del suo compagno. Al fine di non dilungarmi troppo, non entrerò in merito a tutte le possibili azioni che il compagno 1 potrebbe svolgere nel corso della sua attività. Diamo per scontato che, cosi come abbiamo visto per gli esempi precedenti, il compagno 1 eseguirà una serie di azioni all’interno di un contesto (cioè la scuola) che comprenderanno l’uso di vari strumenti a sua disposizione: cicli, condizioni, immagazzinamento dati, utilizzerà dei postulati (dati di riferimento), uso di oggetti come penne, quaderni ecc.
  2. Attività/Applicazione 2, quella svolta dal Compagno 2: 
    1. Chiama il compagno 1 ad una certa ora (pattuita) per ottenere gli appunti necessari al suo studio casalingo. (immaginiamola come un’applicazione che chiama un’altra applicazione per ottenere la risposta. Applicazione 2 che chiama l’indirizzo dell’Applicazione 1. Anche qui daremo per scontato che il compagno 2, nel corso della sua attività, eseguirà una serie di azioni all’interno di un contesto (cioè casa sua) che comprenderanno l’uso di vari strumenti a sua disposizione: cicli, condizioni, immagazzinamento dati, utilizzerà dei postulati (dati di riferimento), uso di oggetti come penne, quaderni ecc.

Arrivati a questo punto, è bene ricapitolare la situazione per sottolineare l’ultimo tassello che unisce le due Attività/Applicazioni: il modo/formato attraverso il quale i due compagni si scambiano gli appunti. Una sorta di standard pattuito tra i due.
Ad esempio, potrebbero essere gli appunti presi sul famoso quaderno visto in precedenza a rappresentare il format di interscambio comprensibile ad entrambi. Oppure un foglio word nel cloud al posto del quaderno.

Partendo dal quaderno (o foglio word ) con gli appunti, si potrebbe estrarre un tracciato da fornire al compagno, quello che in informatica potrebbe essere un file JSON. Quindi sto dicendo che, in termini informatici,  possiamo considerare il quaderno come il file JSON che definisce il tracciato di interscambio dati tra i due compagni/applicazioni.

Supponiamo che gli appunti siano organizzati come visto nell’esempio precedente.

Il compagno 1 sa bene che al termine della sua Attività dovrà fornire (o ritornare se fosse una funzione/risorsa informatica) un risultato (cioè il tracciato estrapolato dagli appunti presi nel quaderno con gli appunti) comprensibile al compagno 2 che lo contatterà.

Il compagno 2, invece, sa bene che ad una certa ora dovrà chiamare il compagno 1 per ottenere il risultato (il tracciato estrapolato dagli appunti presi nel quaderno con gli appunti) nel formato che si aspetta.

Schematizzandolo ulteriormente, sarebbe:

Anche questa volta abbiamo realizzato due programmi (comunicanti) senza neanche rendercene conto e senza neanche aver avuto bisogno di alcun codice di programmazione.

L’esempio però non è ancora concluso. Vi ricordate della seconda condizione nella quale il Compagno 2 chiede al Compagno 1 di contattarlo al termine della sua attività di raccolta degli appunti?
Per questa condizione descriveremo, in maniera del tutto esemplificativa, un’altro utile strumento della programmazione: Le Callback. 

Qualcuno di voi ha mai sentito parlare di Callback? Si? No? Fa niente! indipendentemente dalla vostra risposta, conoscerne l’applicazione pratica ed esemplificativa (generalista) vi aiuterà a comprenderne l’utilizzo e l’approccio programmatico per fini informatici.
In parole povere, una Callback è una funzione/risorsa da far richiamare/eseguire ad un’applicazione in un dato momento della sua elaborazione (in genere al termine).
Nell’esempio precedente verrebbe eseguito al termine dell’attività 1 e svincolerebbe l’attività 2 da qualunque carico di lavoro aggiuntivo, oltre che alleggerire le richieste rivolte all’attività 1.
Per capire meglio il senso di quanto appena detto, facciamo un ulteriore esempio che consenta di contornare la distinzione tra l’uso e l’assenza di una Callback. Ritorniamo sui due compagni:

  1. Compagno 2 che chiama Compagno 1 ad una certa ora per avere gli appunti.
    Quando il compagno 2 chiama il compagno 1, non è detto che quest’ultimo abbia finito o sistemato gli appunti, perciò potrebbe rispondere al compagno 2 di richiamare dopo 5 minuti. È chiaro che questa situazione potrebbe verificarsi un numero incalcolabile di volte fino a che il compagno 1 non abbia realmente terminato la sua attività. Quindi il compagno 2 si ritroverebbe a chiamare ogni 5 minuti il compagno 1 sino all’ottenimento degli appunti; Questo meccanismo viene detto polling in informatica. Dall’altra parte, il compagno 1 inizierebbe a stressarsi per le continue chiamate del compagno 2; Questa pratica, in informatica, potrebbe portare ad un appesantimento delle richieste e/o delle attività del server.
  1. Compagno 1 che chiama Compagno 2 al termine della sua attività.
    Questa condizione svincola il Compagno 2 da qualunque attività di chiamata, limitandosi ad attendere il contatto del Compagno 1 al termine della sua attività. È evidente che questa soluzione andrebbe ad alleggerire di molto la psiche del Compagno 1, il quale non dovrà sorbirsi la pressione delle n chiamate del Compagno 2. Anche il lavoro del Compagno 2 verrebbe alleggerito, il quale dovrà solo attendere e ricevere comodamente gli appunti.

Entrambi i meccanismi sono molto usati in ambito informatico ma non per forza uno è migliore dell’altro. Spesso si decide sulla base di determinati fattori di partenza, individuati dall’analisi delle logiche applicative.

Le Callback esistono sia come concetto di chiamate di ritorno fatte in rete (dette anche WebHook), dove si dice ad un applicativo (in genere server) di chiamare un certo indirizzo al termine della sua attività. Oppure come strumento programmatico all’interno di una stessa applicazione, dove, ad esempio, possiamo passare una funzione ad un’altra funzione al fine di farla eseguire in un dato momento della sua attività. 

Verso la conclusione

Prima di chiudere vorrei fare un accenno ad un ultimo e importante meccanismo che troverete nel corso del vostro cammino da programmatori. In realtà potrei parlare e generalizzare ancora per molto ma non voglio dilungarmi ulteriormente, voglio solo racchiudere l’essenziale dei concetti base.

Quest’ultimo accenno non credo vi servirà nel contesto in cui ci troviamo (SmartCentral), ma ci tengo ad affrontarlo a fini informativi.   

Avete mai sentito parlare di attività sincrone e asincrone? Magari si ma non in questi termini.
Sappiate solo che, anche in questo caso, svolgete attività sincrone e asincrone tutti i giorni e senza neanche rendervene conto.
Scopriamo il significato con esempio di programmazione generalista.

Un applicazione (o un set di sue attività) è Sincrona quando le procedure vengono eseguite una dopo l’altra senza alcuna concomitanza di eventi. Quindi, iniziamo un’attività, la portiamo a termine e ne iniziamo un’altra.
Tecnicamente si definisce Sincrona quell’applicazione che lavora  su un singolo Thread (o processo).
Immaginate tutte quelle attività giornaliere nelle quali, per non appesantire il nostro cervello (microprocessore biologico), preferite svolgere un’attività per volta.
In questo caso il nostro cervello farebbe da gestore di un unico Thread principale, perciò esecutore di una sola attività alla volta. Tecnicamente “monoprocesso”.
Quindi il nostro cervello non può/vuol fare altro che una singola attività.
È chiaro che se nel corso della giornata dovessimo svolgere più attività, la non concomitanza delle stesse ci farebbe perdere più tempo, bloccando l’attenzione del nostro cervello (monoprocesso) sino al concludersi di ogni singola attività di tutta la filiera.
In informatica potrebbe essere, ad esempio, un applicazione per smartphone che esegue un singolo processo (e quindi una sola interazione alla volta) nella schermata visualizzata dall’utente, di fatto bloccandola sino al termine.
Vi è mai capitato di pigiare il pulsante di un’app e vedere la stessa bloccarsi sino al termine (con un leader o senza) senza darci la possibilità di interagire con nessun altro pulsante? Ecco, in questo caso l’app sta eseguendo attività Sincrona, cioè una per volta. 

Un applicazione (o un set di sue attività) è Asincrona quando più procedure vengono eseguite in concomitanza. Quindi, iniziamo e seguiamo più attività contemporaneamente senza che una interrompa il proseguo dell’altra.
Tecnicamente si definisce Asincrona quell’applicazione che lavora su più Threads (o processi) contemporaneamente.
Immaginate tutte quelle attività giornaliere, indipendenti l’una dall’altra nel loro avanzare, ma delle quali dividiamo il nostro cervello (microprocessore biologico) all’esecuzione/attenzione di molteplici di loro contemporaneamente.
In questo caso il nostro cervello farebbe da gestore multi Threads, cioè esecutore di più attività. Tecnicamente “multiprocesso”.
Quindi il nostro cervello può/vuol lavorare più attività contemporaneamente senza bloccarne la concomitanza. Cioè il proseguo di un’attività non bloccherebbe l’altra e viceversa.
In informatica potrebbe essere, ad esempio, un applicazione per smartphone che consente di eseguire più processi (e quindi più interazioni alla volta) nella schermata visualizzata dall’utente.
Vi è mai capitato di trovarvi in un’app che vi permette di lanciare più operazioni in background su una stessa schermata? Ecco, in questo caso l’app sta eseguendo attività Asincrona, cioè crea più Threads indipendenti per ogni attività lanciata. 

Facciamo il punto

Ricapitolando schematicamente l’intera lezione, abbiamo tutta una serie di strumenti programmatici a cui facciamo riferimento per raggiungere un fine (nella realtà come in applicazione informatica):

  1. Main. Contesto di inizializzazione
  2. Array/Dizionari. Contenitori nei quali riporre/inserire matrici di dati/oggetti aventi la stessa o differente natura
  3. Variabili. Aree di memoria nelle quali immagazzinare dati temporanei. Ad esempio un numero, una frase, un’aggetto o una matrice di numeri, frasi o oggetti (Array/Dizionari)
  4. Costanti. Dati di riferimento immutabili
  5. Cicli. Ripetizioni che ci portano ad eseguire più volte una o più azioni
  6. Condizioni. Scelte che cambiano il fine di un target. Se avviene una cosa fai questo altrimenti fai quest’altro
  7. Oggetti. Strumenti aventi caratteristiche e/o funzioni da eseguire
  8. Callback. Chiamate di ritorno al fine di far eseguire un’attività specifica ad un’altra attività.
  9. Processo Sincrono e/o Asincrono. Concomitanza o non concomitanza di eventi/processi.  

In questa lezione ho voluto semplificare al massimo i concetti programmatici per il bene dell’apprendimento/accostamento logico degli strumenti, e per permettervi di comprendere l’eventuale approccio futuro con ognuno di essi. E’ bene precisare, seppur ovvio, che la logica programmatica con l’utilizzo degli strumenti discussi, non segue dei binari sempre uguali ma è direttamente proporzionale alla propria crescita programmatica e alla logica creativa di ciò che vogliamo realizzare.

È probabile che qualcuno di voi si starà chiedendo: “Tutto questo tempo a leggere un poema e alla fine non abbiamo imparato nulla di tecnico/informatico?”

Credetemi, se siete arrivati alla fine di questa lezione con coscienza dei concetti e gli accostamenti fatti, allora avrete fatto molta più strada di quello che pensate.
Vedetela come il – “Metti la cera, togli la cera” – di Karate Kid 😀

Prima di salutarvi vorrei che ripercorriate quanto appena discusso e applicaste i concetti nella realizzazione di esercizi/applicazioni – Atomiche, non atomiche e/o con callback – partendo dal vostro vissuto giornaliero.

Nella prossima lezione vedremo come realizzare in Shortcuts i processi di vita quotidiana appena raccontati, in particolare realizzeremo i comandi:

 

Grazie per l’attenzione

Exit mobile version