diff --git a/.gitattributes b/.gitattributes index 94f480de..d0c0c4c1 100644 --- a/.gitattributes +++ b/.gitattributes @@ -1 +1,2 @@ -* text=auto eol=lf \ No newline at end of file +* text eol=lf +*.png binary diff --git a/GUIDELINES-CONTENUTI.md b/GUIDELINES-CONTENUTI.md index 50874702..3532fe98 100644 --- a/GUIDELINES-CONTENUTI.md +++ b/GUIDELINES-CONTENUTI.md @@ -23,8 +23,8 @@ Si precisa che il conteggio dei tempi di approvazione e raggiungimento del quoru Per l'approvazione di un contenuto all'interno di main, che sia da parte di un Ambassador che di una figura esterna, sarà sufficiente: -- Approvazione di almeno 5 Ambassador. -- Approvazione di almeno 1 membro del Drafting Group. +- Approvazione di almeno 3 Ambassador non membro del Drafting Group. +- Approvazione di almeno 1 Ambassador membro del Drafting Group. - Superato il tempo massimo di 15 giorni dall'apertura della PR - O 15 giorni dall'ultimo commento o approvazione da parte di un Ambassador -, questa sarà considerata non valida e verrà chiusa da qualsiasi Ambassador avesse modo di farlo e verrà richiesto alla persona che ha aperto la PR di riproporla cercando di creare più coinvolgimento o di modificarne il wording. ## Disapprovazione di un contenuto @@ -33,5 +33,5 @@ Per esprimere la disapprovazione dei contenuti sarà sufficiente che un membro d La disapprovazione andrà a ridurre di 1 i numeri per il raggiungimento dei criteri di cui sopra. -Di conseguenza, a titolo di esempio, una PR verso main con 5 voti a favore e approvazione del drafting group ma con una disapprovazione renderà necessaria un'ulteriore approvazione per poter passare. +Di conseguenza, a titolo di esempio, una PR verso main con 3 voti a favore e approvazione del drafting group ma con una disapprovazione renderà necessaria un'ulteriore approvazione per poter passare. Lo stesso vale per il conteggio del Drafting Group, per cui la disapprovazione da parte di uno dei suoi membri richiederà l'approvazione di altri 2 di essi per raggiungere il netto positivo di 1. diff --git a/Gemfile.lock b/Gemfile.lock index f50ae961..ac7adb9a 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -11,6 +11,7 @@ GEM eventmachine (1.2.7) ffi (1.16.3) forwardable-extended (2.6.0) + google-protobuf (3.25.2-arm64-darwin) google-protobuf (3.25.2-x86_64-darwin) google-protobuf (3.25.2-x86_64-linux) http_parser.rb (0.8.0) @@ -64,16 +65,16 @@ GEM rexml (3.2.6) rouge (4.2.0) safe_yaml (1.0.5) - sass-embedded (1.70.0-x86_64-darwin) - google-protobuf (~> 3.25) - sass-embedded (1.70.0-x86_64-linux-gnu) - google-protobuf (~> 3.25) + sass-embedded (1.63.6) + google-protobuf (~> 3.23) + rake (>= 13.0.0) terminal-table (3.0.2) unicode-display_width (>= 1.1.1, < 3) unicode-display_width (2.5.0) webrick (1.8.1) PLATFORMS + arm64-darwin-22 x86_64-darwin-22 x86_64-linux @@ -81,4 +82,4 @@ DEPENDENCIES just-the-docs BUNDLED WITH - 2.3.26 + 2.4.19 diff --git a/README.md b/README.md index b4c47dd0..bf53df2d 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,7 @@ # Il Libro Open Source +> Vuoi unirti alla community del libro? Entra nel nostro nuovissimo [canale Telegram](https://t.me/illibroopensource)! + Questo progetto nasce da un post su LinkedIn che ha raccolto decine di persone attorno all'obiettivo di realizzare un libro completamente Open Source. Dalla scelta del tema alla stesura del contenuto, il tutto verrà gestito e condiviso con la community e con chiunque voglia contribuire al progetto. @@ -43,6 +45,7 @@ Trovi i capitoli già presi in considerazione o già in fase di stesura [qui](ht ## Dove posso scrivere le mie idee? +Nel [canale Telegram](https://t.me/illibroopensource) creato apposta per la community! Nella discussione [Idee sparse](https://github.com/Il-Libro-Open-Source/book/discussions/27) o aprendo una issue senza template. ## Domande Frequenti diff --git a/_includes/header_custom.html b/_includes/header_custom.html new file mode 100644 index 00000000..c6dafad7 --- /dev/null +++ b/_includes/header_custom.html @@ -0,0 +1,84 @@ +
+ + + + + + + + + + + + + + + +
+ + \ No newline at end of file diff --git a/docs/it/ai.md b/docs/it/ai.md index f318feb9..8b956e4d 100644 --- a/docs/it/ai.md +++ b/docs/it/ai.md @@ -1,7 +1,7 @@ --- layout: default title: AI -nav_order: 13 +nav_order: 14 --- diff --git a/docs/it/aziende-di-consulenza-vs-prodotto.md b/docs/it/aziende-di-consulenza-vs-prodotto.md index 9e6562e9..f02e6b9c 100644 --- a/docs/it/aziende-di-consulenza-vs-prodotto.md +++ b/docs/it/aziende-di-consulenza-vs-prodotto.md @@ -1,7 +1,7 @@ --- layout: default title: Aziende di consulenza vs prodotto -nav_order: 7 +nav_order: 9 --- diff --git a/docs/it/carriera-junior.md b/docs/it/carriera-junior.md new file mode 100644 index 00000000..106c7bbc --- /dev/null +++ b/docs/it/carriera-junior.md @@ -0,0 +1,165 @@ +--- +layout: default +title: Carriera - Junior +nav_order: 7 +--- + + +# Carriera - Junior +{: .no_toc } + +- TOC +{:toc} + + + +## Introduzione + +All'interno di questo libro vengono affrontati, in diverse forme, molti dei tecnicismi che fanno parte del mestiere di chi sviluppa; l'obiettivo di questo libro, però, non è parlare di devs visti solamente come artigiani/e del software, bensì in modo più generale: come risorse umane. + +Sono presenti infatti diversi capitoli, pubblicati o in stesura, che parlano del modo in cui formarsi, del significato di questa professione o dei percorsi possibili di carriera, e che affrontano quindi l'aspetto più "personale" e "lavorativo" di questo mestiere. + +L'obiettivo di questo capitolo è descrivere per noi cosa significa in linea generale essere Junior Developer, esplorare le pratiche giornaliere per poter crescere e collaborare in modo sano in un team e infine il percorso per crescere di livello e non solo, il fine è raccontare anche quanto questa fase della carriera possa essere complessa oltre che delicata e fondamentale per il futuro, a seconda di come viene affrontata. + +Molti dei suggerimenti e alcune delle conclusioni proposte in questo capitolo sono tratte da esperienze personali e da riflessioni fatte in anni di lavoro in questo settore. Il fine ultimo non consiste nel fornire una guida perfetta e definitiva per essere un/a buon/a Junior Developer, ma piuttosto nel dare degli spunti di riflessione e delle linee guida che possano aiutare chi si trova in questa fase della carriera a crescere e a migliorare. + +## L'identikit di Junior Dev + +Come possiamo identificare un/a Junior Developer? Spoiler: non è semplice. + +A seconda dei panni che si stanno indossando (es. dev, recruiter, team leader, coach...) questo ruolo può assumere molteplici forme e declinazioni che aumentano esponenzialmente a seconda delle tipologie e delle dimensioni delle aziende, oppure se della categoria di consulenza o di prodotto e anche ad esempio se si è impiegati in ambito front-end o back-end. + +Anche affidandoci ad internet per trovare una definizione, le sfumature che emergono sono diverse; potremmo classificare chi sviluppa in base all'età (ad oggi non è più di tanto un indice di esperienza), in base agli studi e da quanto tempo siano stati completati o anche in base agli anni di esperienza in una determinata azienda o in generale di carriera. + +Per creare un piano comune che ci permetta di esplorare facilmente l'argomento e fissare quello che per noi è il fulcro del capitolo, la definizione di Junior Dev per noi è la seguente: + +> Una persona di una qualsiasi età, proveniente da qualsivoglia ambito di studi e che ha seguito un percorso di carriera di un qualsiasi tipo che però è in grado di leggere ed interpretare i requisiti di un possibile artefatto software o di una sua parte e ha le competenze tecniche per riprodurlo, non in completa autonomia. + +Per noi la chiave di volta è questa, non una delimitazione basata su aspetti come i titoli di studio, gli anni di esperienza o di lavoro ma un'identificazione tramite la capacità di scrivere software, con una particolare attenzione al livello di autonomia. + +Se volessimo schematizzare e fare qualche esempio a sostegno di questa tesi: + +| Tesi | Antitesi | +| ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| "Ho 10 anni di carriera alle spalle quindi non sono più un/a Junior Dev" | Il tuo apprendimento è stato efficace in questi anni? Sei autonoma/o nel tuo ambito? In quali ambiti hai lavorato? Come possiamo misurare la qualità del tuo lavoro sapendo solo che hai 10 anni di carriera alle spalle? Potresti essere stagnante da tempo e non essere aggiornato/a. | +| "Ho una laurea o un dottorato in Ingegneria o in Informatica" | Che tipo di competenze hai assorbito durante il percorso di studi? Come le hai applicate nel tuo lavoro? Sei autonomo/a grazie al tuo percorso di studi? | +| "Come esperienza lavorativa hai solamente un anno nella Azienda Esempio Srl, sarai certamente Junior Dev!" | Potresti invece aver praticato in autonomia in side-projects o potresti aver contribuito a progetti FOSS le tue abilità nello scrivere codice. | +| "Ho 40 anni, non posso essere classificata come Junior Dev " | L'età è solamente un numero, non fornisce informazioni sul tuo background o il percorso aziendale che hai compiuto. | +| "Con una laurea in Psicologia non puoi che essere un/a Junior Dev" | Alcuni background contribuiscono a migliorare le tue soft-skills e soprattutto ti forniscono un punto di vista diverso e come per l'esempio dell'esperienza lavorativa, potresti aver programmato nel tempo libero per anni, come passione e aver appreso abbastanza. | + +È importante però fare una precisazione, fermo restando che una persona può sviluppare e apprendere per passione tutte le capacità di programmare che vuole, lavorare in team è differente e lo è soprattutto perché si lavora all'interno di un'azienda, con le sue regole, i suoi tools e le sue pratiche. + +Sicuramente ci sono fattori che non possono mancare in un/a dev con molta esperienza, come i test, l'attenzione alla security o le performance ottimali di un applicativo insieme alla sua architettura, che sono tutti aspetti più complessi da assorbire in autonomia come Junior Dev, anche se la passione e la voglia di imparare possono portarti ovunque. + +Potresti essere contributor di progetti FOSS da anni o potresti aver lavorato per molto in un'azienda ma, arrivata/o in un'azienda nuova, è facile trovarsi spaesati nonostante l'esperienza, ricadendo quindi nella figura di "Junior" in un certo senso, a prescindere dalla sfida da affrontare. + +Magari in qualche modo hai curato in autonomia o in un team gli aspetti più complessi citati sopra -come security e performance, ad esempio-, iniziando da zero in una nuova realtà aziendale però tutto potrebbe sembrarti diverso e nuovo e come ribadito in diversi capitoli di questo nostro libro open, noi devs non finiamo mai di imparare, ricordandoci che chiunque potrebbe avere qualcosa da insegnarci, anche chi ha iniziato da poco. + +Questo cosa può significare? + +Non si smette mai di essere Junior Dev, anche se pratichiamo un apprendimento continuo e costante e che segue la natura mutevole di questa professione, e forse è anche meglio cosí. + +## "L'occasione fa del Dev un Senior" + +Stabilito un punto fisso come definizione di Junior Dev, possiamo proseguire nell'esplorare questa figura analizzandola dal punto di vista della carriera, immaginandola come la prima fase di un percorso lavorativo. + +In primis è bene stabilire che ogni persona che lavora nello sviluppo, a seconda delle esperienze, ha i suoi tempi e di conseguenza non esiste un limite di tempo già stabilito entro cui dovrai evolvere come dev e nel titolo abbiamo deliberatamente ripreso un vecchio proverbio per introdurre un concetto per noi fondamentale: nessuno, se non te stess\* può far avanzare la tua carriera in termini di competenze. + +Con questa espressione intendiamo evidenziare che di "occasioni" se ne presenteranno molte: la spiegazione di un concetto da parte dei colleghi, affiancamenti ad un senior, contenuti grautiti online (per il momento lasciamo perdere la formazione a pagamento), serate spese a sperimentare in autonomia oppure un nuovo progetto in azienda dove poter toccare con mano un nuovo aspetto mai affrontato. + +Sta solamente a te decidere di riconoscere di non sapere e non limitarti a "non lo so" ma ponendoti nella posizione di dire "non so, ma posso imparare" che non significa che l'unica dimensione formativa sia quella del "learn-by-doing", ma è un buon inizio cosí come è un inizio anche solo osservare altri mentre fanno, porre delle domande e in seguito magari sperimentare in un ciclo continuo di apprendimento, mattoncino per mattoncino. + +Al concetto di "occasioni" però è bene aggiungere anche i casi "limite" che nel bene nel male come vedremo rimangono comunque momenti per imparare ma andiamo per fasi. + +In caso non ti fosse mai capitato sappi che è facile uscire dal "recinto" del ruolo di Junior Dev in termini di responsabilità, soprattutto in aziende o team di piccole dimensioni, un collega è malato o si è licenziato, un progetto fuori tempo che si accavalla ad altri ed è un attimo trovarsi a gestire aspetti di un progetto che normalmente non dovremmo gestire noi e in linea di massima, non dovrebbe gestire una figura Junior. + +Beh per fortuna che almeno in questi casi il compenso economico aumenta... sbagliato, non è cosí che funziona. + +Potremmo dipingere il mondo come un bellissimo posto pieno di arcobaleni e di RAL commisurate alle responsabilità e ci sono sicuramente un sacco di aziende validissime e dalla struttura solida dove questi scenari sono ben lontani dalla norma, ma è comune che possano presentarsi ed è comune trovarsi in situazioni dove non si è abbastanza formati. + +Con queste righe non vogliamo assolutamente promuovere una cultura tossica del lavoro ne incoraggiare ad accettare situazioni "scomode" di questo stampo che si ripetono nel tempo e soprattutto non vogliamo spingerti a gestire situazioni di grande responsabilità per le quali non hai le skills, ma siccome ci sono e ci saranno sempre probabilmente realtà di questo tipo, è bene che tu acquisisca una adeguata preparazione. + +Cosa possiamo fare per affrontare queste situazioni? + +Possiamo lamentarci, alzare le mani e sedersi immobili ad aspettare aiuto, oppure possiamo vedere queste situazioni, come detto in precedenza, come occasioni. + +Potresti iniziare a scorrere la codebase, indagare su internet, raccogliere più informazioni possibili, fare piccoli tentativi in codebase separate e magari, in caso di bug, riprodurre le casistiche per delineare con più precisione il problema e poi, successivamente, confrontarti con altri dev. E se non hai modo di farlo? Beh, non ti resta che provare in autonomia. + +In linea di massima finché non ci sono perdite di dati in produzione, interruzioni di servizio e perdite di codice importante, possiamo agire ed è quello lo spazio dove possiamo muoverci per aumentare le nostre abilità di coding con una certa confidenza. + +Ribadiamo che queste situazioni non dovrebbero comunque essere la norma, non senza supervisione e non senza gli adeguati riferimenti in caso di problemi e in caso tu ti trovassi in questa posizione, questi sono tutti campanelli d'allarme per un'azienda che non considera la salute mentale dei suoi dipendenti e l'efficacia del proprio team. + +Quello a cui dovremmo mirare è arrivare ad avere un sottile limite entro cui è salutare esplorare "terre sconosciute" per imparare, senza alcun rischio e forse non avrai sempre una RAL commisurata alle responsabilità, ma avrai nuove abilità da esercitare. + +Se decidiamo di non cogliere nessuna delle occasione che arrivano, abbiamo il rovescio della medaglia: essere stagni nella propria posizione. + +Questo per noi è un altro dei fondamenti dell'essere buoni Junior, ossia non fossilizzarsi, il che in linea di massima è un termine generale per indicare che non dovrai porti dei limiti nell'apprendere, nel definire quando qualcosa è fuori dalla tua sfera d'interesse o delle tue responsabilità e soprattutto, fatto un "gradino" (ad esempio appreso un nuovo framework) è bene pensare al prossimo da superare, ritornando al concetto di apprendimento continuo. + +Anche in questo caso però dobbiamo avvisarti, perché c'è una costante che è bene ricordare sia come Junior Dev che in tutta la carriera nel campo dello sviluppo: attenzione alle nuove tecnologie. + +Spesso ti capiterà di veder persone che gridano che il framework, il linguaggio o la tecnologia che stai usando stanno morendo e che è bene imparare la nuovissima tecnologia di cui invece sono dei sostenitori o a cui hanno contribuito. +In realtà potremmo vedere molti di questi esempi grazie all'IA, dello stampo "Inutile imparare a programmare ora!" ma la realtà dei fatti è che tutto va filtrato e analizzato singolarmente e l'aspetto fondamentale di una tecnologia da valutare è la sua robustezza e non c'è giudice più capace del tempo, la tua stella polare dovrebbe essere la giusta flessibilità accompagnata dalla solidità e la sicurezza di aver scritto (o aver tentato il più possibile) di scrivere codice di qualità. + +In poche parole, equilibrio tra questi aspetti: innovazione, adattabilità, ottimizzazione, sicurezza e robustezza. + +Non spingere la tua mente in uno stato mentale di stress o di FOMO, la paura di "perdersi qualcosa", solo perché non hai appreso l'ultima tecnologia e a sostegno di questa tesi ti segnaliamo che ci sono sistemi centrali per l'umanità che navigano con tecnologie inventati decenni fa o con codice a basso livello. + +Prendi le novità cosí come vengono, se ti interessano informati e magari provale ma fai attenzione alla tentazione di integrare queste novità ovunque e concentrati sul non dimenticare i fondamenti e la forma mentale in favore di ciò che arrivato ieri piuttosto che un mese fa. + +Imparare, sperimentare e testare nuovi strumenti richiede tempo e sicuramente la frizione nell'assorbire una nuova tecnologia fa parte delle occasioni sopracitate ma è anche vero che forse un training di due settimane sul nuovo framework è poco sensato per ottenere semplicemente due millisecondi risparmiati durante il render di una pagina web, forse hai modi migliori di trascorrere il tuo tempo... magari contribuire all'open source :) + +Faccenda complessa vero? + +Come puoi vedere non vogliamo indorarti la pillola; la fase di carriera da Junior è parecchio delicata e composta di molteplici fattori da considerare e ancora non abbiamo esplorato cosa dovrebbe fare o non fare un/a Junior Dev per lavorare in modo ottimale, ci sono mille sfaccettature perché dopotutto in questa fase starai gettando le basi della tua carriera, quindi in realtà l'unico consiglio che possiamo darti è di non demordere, visto che ora avrai più chiaro quanto può essere complesso iniziare a sviluppare nel mondo di oggi. + +## Come crescere professionalmente + +Partiamo dal presupposto che spesso ad essere identificati professionalmente come Junior troviamo tutta una fetta di popolazione che, per definizione, Junior non è. Dedicare un capitolo di questo libro ad ogni "livello" professionale sarebbe impensabile, ed è per questo motivo che abbiamo deciso di inglobare nella definizione di Junior anche chi sviluppa come entry level. +Per questo motivo, il percorso di crescita professionale che andremo ad analizzare in questo capitolo potrà essere seguito sia da chi si sta affacciando per la prima volta al mondo del lavoro, sia da chi ha già alle spalle qualche anno di esperienza. +La chiave di volta per la crescita professionale nel mondo dello sviluppo software è la proattività. Essere proattivi significa non aspettare che le cose accadano, ma fare in modo che accadano. Questo concetto è particolarmente importante per chi si trova nella fase iniziale della propria carriera, in quanto è proprio in questo momento che si gettano le basi per il proprio futuro professionale. +I primi anni della carriera, così come i primi anni di vita, sono quelli in cui si impara di più. È in questa fase che si acquisiscono le competenze tecniche e non tecniche che saranno fondamentali per il proprio futuro professionale. È in questo momento che si impara a lavorare in team, a risolvere i problemi, a comunicare con gli altri, a gestire il tempo e le risorse a propria disposizione. + +Per tutte quelle persone che hanno appena avviato la propria carriera professionale, è importante scegliere la prima azienda nel modo giusto. Spesso si tende a sottovalutare l'importanza di questa decisione, ma è proprio da qui che si parte per costruire il proprio futuro professionale. È importante scegliere un'azienda che offra un ambiente di lavoro stimolante, che permetta di crescere professionalmente e che dia la possibilità di mettersi alla prova. In questa fase è molto importante riconsiderare le proprie priorità a breve termine per puntare quasi esclusivamente su quelle a lungo termine. +Per anni, soprattutto a causa di influenze dettate dai tempi passati, siamo stati abituati a pensare al luogo di lavoro come ad un posto in cui scambiare il proprio tempo per denaro. La retorica degli ultimi cinquant'anni ci ha portato a credere che il lavoro fosse un obbligo, un dovere, una necessità, ma la realtà è ben diversa. Il lavoro è una scelta, una scelta che facciamo ogni giorno e che ci permette di esprimere noi stessi, di realizzarci, di crescere. Ecco perché è importante scegliere con cura il luogo in cui lavorare, perché è da qui che parte tutto. +In generale, durante la scelta di un posto di lavoro, mettiamo sul piatto della bilancia diversi aspetti, e tendiamo ad attribuire un peso a ognuno di essi. La retribuzione, e anche la flessibilità sulla modalità di lavoro, spesso giocano un ruolo fondamentale nello spostare l'ago della bilancia, ma è importante non dimenticare che ci sono altri aspetti che possono fare la differenza, soprattutto se stiamo per varcare per la prima volta la soglia di un'azienda. Un lavoro non è per sempre, i nostri gusti, le nostre abitudini, i nostri modi di fare possono cambiare, e con essi anche le nostre priorità. + +Nei primi tre mesi di carriera il tuo obiettivo principale dovrebbe essere quello di farti conoscere e conoscere l'azienda nella quale ti trovi. Questo periodo di solito coincide con il periodo di prova, e quindi è importante capire se siete fatti per stare insieme. Non aver paura di fuggire se il tuo sesto senso ti dice che non è il posto giusto per te. Non è un fallimento, è solo un'altra tappa del tuo percorso. E ricorda, non è mai troppo tardi per cambiare strada. In questo momento l'obiettivo principale è imparare, imparare, imparare. Non preoccuparti troppo di fare errori, è normale, è umano. +Nei primi sei mesi di carriera dovrai diventare un/a detective, cercando di acquisire quante più informazioni possibili sia su come lavora l'azienda, e sia sul dominio applicativo della stessa. Ci sono realtà dove il dominio applicativo è molto complesso, e richiede tempo per essere assimilato. Non aver paura di chiedere, non aver paura di fare domande, non aver paura di sbagliare. Ricorda, sei lì per imparare, non solo per dimostrare quanto vali. In questa fase dovresti riuscire a identificare il capobranco del tuo team, colui o colei che ha più esperienza, e che può aiutarti a crescere. Ecco, ti ci dovresti attaccare come una cozza al suo scoglio. +Nei tuoi primi nove mesi di carriera dovresti dimenticare totalmente il tuo stipendio. Questo non significa che non dovrai preoccuparti di come pagare l'affitto o la spesa, ma che non dovresti permettere allo stesso di diventare un'etichetta per il tuo livello di professionalità. Non lavorare mai gratis, piuttosto meglio farsi assegnare un rimborso spese, il lavoro, seppur non di esperienza, va sempre ricompensato. Evita di accettare lavori superpagati ma senza prospettive o che non ti soddisfano, la gratificazione economica dura poco e soprattutto non è considerata un investimento a lungo termine. +Durante il primo anno di carriera ti ritroverai a svolgere task sia semplici che leggermente più complessi. Da junior, è molto probabile che il tuo lavoro sarà spesso di supporto, e che ti troverai a lavorare su task che non richiedono particolari competenze tecniche. Questo non significa che il tuo lavoro non sia importante, anzi. Il tuo lavoro è fondamentale per il buon funzionamento del team, e per la riuscita del progetto. Non sottovalutare mai il tuo ruolo, e non permettere a nessuno di farlo. Se ti trovi in un ambiente in cui il tuo lavoro non è riconosciuto, è il momento di cambiare aria. Ricorda, il tuo lavoro è importante, e tu sei importante. +In questo periodo, spesso e volentieri ti capiterà di svolgere attività nelle quali non ti senti a tuo agio, o che non ti piacciono, o peggio, che per un motivo o per l'altro, non riuscirai a risolvere. Qui la contemporanea presenza e assenza di informazione giocheranno un ruolo fondamentale nello sviluppo delle tue abilità di problem solving. Cerca di attivare la modalità esplorativa nel tuo cervello, poniti domande, e soprattutto falle agli altri. È importante imparare a porre le domande in modo da mantenere attiva la modalità esplorativa. Cerca di desistere dal chiedere di fornirti la soluzione: un cervello in fase di stress positivo è un cervello che impara. +Un altro importante momento che dovrai imparare a sfruttare al meglio per massimizzare l'apprendimento è quello di pair programming e di code review. Cerca insistentemente di lavorare a stretto contatto con i tuoi colleghi, e fai revisionare il tuo codice ogni volta che puoi. Questo ti permetterà di imparare nuove tecniche, nuovi pattern, e soprattutto ti permetterà di capire come lavorano gli altri. Ricorda, il pair programming e le code review sono due attività fondamentali per la crescita professionale di un developer, e non dovrebbero mai essere trascurate. Cerca di mettere da parte l'idea che il giudizio degli altri possa essere negativo sulla tua persona, e cerca di accettare le critiche come un'opportunità di crescita. Ricorda, il tuo obiettivo è imparare, non dimostrare quanto vali. + +Dopo un po' di tempo passato a lavorare in azienda, molto probabilmente individuerai una certa predilezione verso determinati processi e maturerai un certo livello di competenza verso alcune aree del dominio applicativo. Le attività di pair programming si riducono allo stretto necessario, e le sessioni di code review non impegnano troppo tempo al tuo reviewer nel suggerirti dei cambiamenti. Inizierai ad avere responsabilità diverse, e probabilmente ti troverai a dover gestire task più complessi e a dover prendere decisioni più importanti. Complimenti! Questi sono buoni indicatori che la tua professionalità sta crescendo, e che stai maturando come sviluppatore. +Quasi sicuramente le tue competenze tecniche saranno migliorate, imparerai a conoscere più nel dettaglio un linguaggio di programmazione, a saper utilizzare meglio il framework di riferimento nella tua azienda, e soprattutto a saper risolvere attività più lunghe e corpose nel minor tempo possibile utilizzando pattern e dogmi dell'ingegneria del software. +Sta accadendo qualcosa di meraviglioso e probabilmente neanche te ne sei accorto: stai diventando un middle developer. Questo è un momento molto importante nella tua carriera, perché è qui che inizierai a capire quali sono le tue reali competenze, quali sono le aree in cui dovresti migliorare, e quelle in cui vuoi specializzarti. È qui che inizierai a capire chi sei, e chi vuoi diventare. +Probabilmente sono passati due anni da quando hai iniziato a lavorare in azienda, sei sempre meno dipendente dai tuoi colleghi e colleghe che hanno più esperienza di te e inizi a prendere decisioni in autonomia. Partecipi attivamente alla vita del team di lavoro, proponi soluzioni e discuti della fattibilità delle tue idee e delle idee dei membri del tuo team. Inizi a capire che il lavoro di squadra è fondamentale per la riuscita di un progetto, e che la tua professionalità è strettamente legata a quella dei tuoi colleghi. Inizi a capire che il tuo lavoro non è solo il tuo lavoro, ma è il lavoro di tutto il team. + +E adesso che si fa? Adesso che sei un/a middle developer, è probabile che la persona che ti fa da responsabile diretta ti premi con una promozione: più responsabilità, task via via sempre più complessi ma alla portata delle tue competenze, e soprattutto un migliore trattamento economico. Ma attenzione, non è detto che questo accada: non è detto che tu debba essere promosso/a per forza, tuttavia è plausibile che tu possa ambire a una promozione. In ogni caso, è importante che tu continui a lavorare sodo, a metterti in gioco, a cercare di migliorare sempre di più. La tua crescita professionale non dovrebbe mai fermarsi, e non dovrebbe mai essere condizionata da un titolo o da un compenso. La tua crescita professionale deve essere un obiettivo personale, un obiettivo che ti permetta di esprimere al meglio le tue potenzialità, e di realizzarti come professionista. +Se dentro di te senti una voce che ti comunica che "hai fatto la differenza", è il caso di organizzare una sessione con il tuo superiore per negoziare una promozione o per fissare degli obiettivi da raggiungere per ottenerla a stretto giro. Se invece non senti questa voce, è il caso di fare un passo indietro e di riflettere su cosa ti manca per sentirti realizzato come professionista. +A volte può capitare che il lavoro non sia più stimolante, e che tu senta il bisogno di cambiare aria. Questo è normale, e non è un fallimento. È solo un'altra tappa del tuo percorso professionale. Se senti che il tuo lavoro non ti soddisfa più, è il momento di cambiare. Non aver paura di fare un passo indietro, di tornare sui tuoi passi, di cambiare strada. La tua crescita professionale è un percorso personale, e solo tu puoi decidere quale strada prendere. +In questo caso puoi ricominciare a fare colloqui, ed è in questo particolare momento che riuscirai a ricevere feedback con molta più frequenza rispetto a quando sei in azienda. Fare colloqui è un ottimo strumento per avere un parere esterno sul tuo livello di competenza, e per capire quali sono le aree in cui potresti migliorare. + +E dopo? Dopo lo sai solo tu. Non esiste il manuale della carriera perfetta. Ogni percorso professionale è diverso e degno di essere vissuto. L'importante è non smettere mai di crescere, di imparare, di mettersi in gioco. L'importante è non smettere mai di essere curiosi, di voler sapere di più, di voler fare di più. L'importante è non smettere mai di essere un junior. L'importante è non smettere mai di essere te stesso, di voler essere la migliore versione di te stesso. L'importante è non smettere mai di essere un developer. + +## La sindrome della pappa pronta + +"Ciò che dobbiamo imparare a fare, lo impariamo facendolo." (Aristotele) + +Questa frase di Aristotele riporta una grande e bella verità: eppure, nonostante abbia un significato manifesto, spesso ci troviamo a cercare la soluzione ad un problema senza dedicare la giusta quantità di attenzione al perché. Così come il titolo di uno dei più famosi libri dello scrittore e saggista Simon Sinek ("Partire dal Perché") ci suggerisce, è importante capire il motivo per cui stiamo facendo qualcosa, prima di passare al come e al cosa. +Questo comportamento, che potremmo definire come "sindrome della pappa pronta" o "da eccesso di informazione", è molto diffuso tra chi è giovane nel settore dello sviluppo, e spesso è la causa principale di molti problemi che si presentano durante la fase di crescita professionale. + +Viviamo in un mondo in cui l'informazione è ovunque, e spesso ci troviamo a dover fare i conti con un eccesso di nozioni che ci confondono e ci distraggono. La nostra soglia dell'attenzione è sempre più bassa, e spesso ci troviamo a saltare da un argomento all'altro senza approfondire nulla. Inoltre, con il diffondersi delle intelligenze artificiali generative, non potremo far altro che continuare ad impigrirci, a delegare sempre di più il pensiero critico e la risoluzione dei problemi a macchine sempre più potenti e sempre più intelligenti. +Intendiamoci, non sono assolutamente contrario ai vantaggi che tutti questi strumenti possono portare all'interno della nostra vita quotidiana e professionale, ma credo che sia importante non dimenticare che la nostra mente è la nostra risorsa più preziosa, e che dobbiamo fare in modo di mantenerla sempre attiva e sempre pronta ad affrontare le sfide che ci si presentano. +Ecco perché è importante imparare a fare le cose, e non solo a leggere o a guardare qualcun altro farle. + +Se vuoi ambire ad una carriera professionale di successo, devi imparare a lavorare con il pensiero critico sempre attivo e a porti sempre delle domande, sia quando ti si presentano dei problemi e sia quando ti vengono proposte delle soluzioni. +Uno degli strumenti più potenti che ogni dev ha a disposizione è la community. La community è un luogo in cui puoi trovare risposte ai tuoi dubbi, soluzioni ai tuoi problemi, e soprattutto, persone con cui condividere le tue esperienze e le tue conoscenze. +Se c'è una cosa che dovresti fare fin da subito è non prendere mai per oro colato quello che ti viene detto, ma cercare sempre di capire il perché di una cosa, e di metterla in discussione. Solo così potrai crescere professionalmente, e diventare un/a developer migliore. + +Fra le community di dev più utilizzate e conosciute ci sono sicuramente Stack Overflow, GitHub, Reddit, e molte altre. Chi si trova alle prime armi si affida a queste piattaforme per cercare risposte alle proprie domande, e spesso e volentieri quando le trova, si limita a copia-incollare la soluzione o lo _snippet_ di codice della risposta più votata, senza concedersi il tempo di capire il perché di quella soluzione, e di metterla in discussione. +Questo modus operandi è molto pericoloso, perché ti porta a non imparare nulla, a non crescere professionalmente, e soprattutto ad impigrire la tua mente. Chi sviluppa, specie se con poca esperienza, potrebbe essere piuttosto insicuro/a delle proprie capacità, e peccare della giusta maturità nell'accettare i propri limiti sulla propria conoscenza. +Spesso e volentieri questo atteggiamento viene messo in atto per impressionare il team di recruiting quando si cerca un nuovo lavoro, ed ha lo stesso valore di quando si copia il compito del compagno di banco a scuola. Ha davvero senso fare una cosa del genere? Come saremo in grado di affrontare un colloquio di lavoro se non siamo in grado di rispondere alle domande che ci vengono poste? E se non siamo in grado di rispondere, come possiamo sperare di ottenere quel lavoro? + +La soluzione a questo problema è molto semplice: basta dedicare il giusto tempo a capire il perché di una cosa, e a metterla in discussione. L'imparare facendo (in inglese altresì noto come learning-by-doing) è uno dei modi migliori per acquisire nuove competenze, e per crescere professionalmente. +Se sei un/a junior developer, non temere di star perdendo tempo. Impara a destinare una buona quantità di tempo alla tua formazione prima di pensare al risultato finale. Così come detto nella sezione "Come crescere professionalmente", in questo momento della tua carriera è molto più importante puntare ai risultati che potresti ottenere a lungo termine, e l'apprendimento è uno di questi. diff --git a/docs/it/ciclo-del-feedback.md b/docs/it/ciclo-del-feedback.md index 1adf8f59..e4c35c0f 100644 --- a/docs/it/ciclo-del-feedback.md +++ b/docs/it/ciclo-del-feedback.md @@ -1,7 +1,7 @@ --- layout: default title: Metodologie Agile e ciclo del feedback -nav_order: 12 +nav_order: 13 --- diff --git a/docs/it/community-e-networking.md b/docs/it/community-e-networking.md index 0a1ceac4..4546d047 100644 --- a/docs/it/community-e-networking.md +++ b/docs/it/community-e-networking.md @@ -1,7 +1,7 @@ --- layout: default title: Community e Networking -nav_order: 9 +nav_order: 10 --- diff --git a/docs/it/curriculum.md b/docs/it/curriculum.md index ba03d54f..f7e4a3ec 100644 --- a/docs/it/curriculum.md +++ b/docs/it/curriculum.md @@ -1,7 +1,7 @@ --- layout: default title: Il Curriculum -nav_order: 10 +nav_order: 11 --- diff --git a/docs/it/documentazione.md b/docs/it/documentazione.md index 1f309fe9..43fd85d6 100644 --- a/docs/it/documentazione.md +++ b/docs/it/documentazione.md @@ -1,7 +1,7 @@ --- layout: default title: Documentazione -nav_order: 16 +nav_order: 17 --- diff --git a/docs/it/domain-driven-design.md b/docs/it/domain-driven-design.md new file mode 100644 index 00000000..df43742c --- /dev/null +++ b/docs/it/domain-driven-design.md @@ -0,0 +1,208 @@ +--- +layout: default +title: Domain Driven Design +nav_order: 20 +--- + + +# Domain Driven Design +{: .no_toc } + +- TOC +{:toc} + + + +Il Domain Driven Design é una tecnica di modellazione del codice molto utile per progetti con team medio / grandi. + +Il termine é stato coniato da Eric Evans nel suo libro `Domain-Driven Design: Tackling Complexity in the Heart of Software` pubblicato nel 2003. + +## Perché? + +Come sempre nel mondo dello sviluppo, non esiste una soluzione universale, e il DDD non fa eccezione. Pro e contro di questa metodologia sono stati discussi in lungo e in largo, e la sua applicazione dipende da molti fattori, come la dimensione del progetto, la complessità del dominio, il numero di sviluppatori coinvolti e la loro esperienza. +Di seguito, abbiamo voluto elencare alcuni dei principali vantaggi e svantaggi del Domain-Driven Design. + +A prescindere da questi pro e contro, riteniamo utile per chiunque lavori nel campo dello sviluppo software conoscere il DDD e le sue best practices, in modo da poter valutare se e come applicarlo nei propri progetti. + +### Perché usare il Domain Driven Design? + +- Allineamento tra business e tecnologia: Il DDD promuove una stretta collaborazione tra sviluppatori e esperti di dominio, assicurando che il software rispecchi fedelmente le esigenze e i processi del business. +- Gestione della complessità: Suddividendo il dominio in sottodomini più piccoli e più gestibili, il DDD aiuta a mantenere la complessità del sistema sotto controllo. +- Manutenibilità: Grazie a una chiara separazione delle responsabilità e a un focus sulla coesione interna dei modelli di dominio, il codice risultante è più facile da mantenere e da estendere. +- Comunicazione efficace: L'uso di un linguaggio comune (Ubiquitous Language) tra tutti i membri del team di sviluppo e gli esperti di dominio migliora la comunicazione e riduce le ambiguità. + +### Vantaggi del Domain-Driven Design + +- Adattabilità: Dato che il DDD si basa su una profonda comprensione del dominio, il software può adattarsi più facilmente ai cambiamenti del business. +- Qualità del codice: Promuovendo pratiche di buon design come l'incapsulamento e la separazione delle responsabilità, sfruttando il DDD è possibile produrre del codice di alta qualità e ben strutturato. +- Riduzione dei rischi: Identificando chiaramente le aree di complessità e focalizzandosi su di esse, il DDD aiuta a ridurre i rischi associati allo sviluppo software. +- Focus sugli obiettivi di business: Mantenendo costantemente il focus sugli obiettivi e sui processi del business, il DDD assicura che il software sviluppato abbia un impatto positivo e diretto sull'organizzazione. + +### Svantaggi del Domain-Driven Design + +- Complessità iniziale: Implementare DDD richiede un investimento significativo in termini di tempo e risorse per comprendere appieno il dominio e formare il team sui concetti del DDD. +- Costi elevati: La necessità di una continua interazione con gli esperti di dominio e la possibile necessità di ristrutturare il codice esistente possono comportare costi elevati. +- Curva di apprendimento: Per i team non abituati a lavorare con il DDD, la curva di apprendimento può essere ripida, richiedendo formazione e tempo per diventare produttivi. +- Non sempre necessario: In progetti piccoli o con domini semplici, l'overhead introdotto dal DDD potrebbe non giustificare i benefici, rendendolo un approccio sovradimensionato. + +## Subdomains + +Il Domain Driven Design (DDD) suddivide il dominio di un'applicazione in varie tipologie di sottodomini per affrontare differenti aspetti di un sistema complesso. Ecco una breve descrizione dei principali tipi di sottodominio nel DDD: + +### Sottodominio Core (Core Domain) + +Questo è il cuore del modello di dominio, dove si trova la logica fondamentale che distingue l'azienda o l'applicazione dai concorrenti. È il centro dell'innovazione e dell'investimento strategico, poiché contiene le funzionalità più cruciali per il successo dell'impresa. + +### Sottodominio di Supporto (Supporting Subdomain) + +Non centrale come il Core Domain, ma ancora necessario per supportare le operazioni dell'azienda. Questi sottodomini forniscono funzionalità che facilitano o migliorano le operazioni realizzate dai core domain, ma non offrono un vantaggio competitivo diretto. + +### Sottodominio Generico (Generic Subdomain) + +Si tratta di aree del sistema che sono necessarie per il funzionamento ma che sono standardizzate e non specifiche per il contesto dell'azienda. Esempi possono includere funzioni come gestione degli utenti, autenticazione o logging. Sono spesso candidati per l'outsourcing o l'uso di soluzioni software preesistenti. + +L'identificazione e la classificazione dei sottodomini in una delle categorie sopra menzionate aiutano le organizzazioni a concentrare le risorse e gli sforzi là dove sono più necessari e a utilizzare soluzioni standardizzate dove possibile, ottimizzando così il tempo e il costo dello sviluppo software. + +## Ubiquitous Language (Linguaggio Onnipresente) + +L'Ubiquitous Language è un concetto fondamentale che riguarda lo sviluppo di un linguaggio comune tra tutti i partecipanti di un progetto software. Questo linguaggio è condiviso tra sviluppatori, analisti, stakeholder e qualsiasi altra persona coinvolta nel progetto. L'obiettivo è eliminare ambiguità e garantire che tutti comprendano esattamente gli stessi concetti quando discutono di aspetti del sistema. + +Lo Ubiquitous Language è più di un semplice gergo; è un insieme di termini e frasi che sono strettamente allineati con il dominio dell'applicazione. Viene utilizzato costantemente in tutte le comunicazioni, sia nella documentazione che nelle conversazioni, e dovrebbe essere riflettuto direttamente nel codice, rendendo il codice più leggibile e comprensibile. + +Questo linguaggio evolve man mano che la comprensione del dominio cresce e si adatta durante lo sviluppo del software, garantendo che il linguaggio e il software rimangano perfettamente allineati con i bisogni del business. La creazione e il mantenimento di un Ubiquitous Language efficace sono cruciali per il successo dell'implementazione del DDD, poiché aiuta a prevenire malintesi e migliora la coerenza del progetto. + +## Bounded contexts + +Il concetto di Bounded Context è essenziale per gestire la complessità nei grandi sistemi software. Un Bounded Context delimita la pertinenza di un particolare modello di dominio, creando chiari confini all'interno dei quali un modello specifico è definito e applicabile. Questo permette di mantenere la coerenza del modello all'interno di quel contesto, pur permettendo l'esistenza di differenti modelli in altri contesti all'interno dello stesso sistema. + +Ecco alcuni punti chiave riguardanti i Bounded Contexts: + +### Isolamento + +Ogni Bounded Context isola il suo modello da altri modelli, evitando collisioni e ambiguità tra terminologie e regole di business che possono differire significativamente tra un contesto e l'altro. + +### Integrazione + +Anche se un sistema può avere più Bounded Contexts, spesso è necessario che questi contesti si integrino. Ciò avviene tramite meccanismi ben definiti di integrazione e traduzione, come ad esempio API, eventi di dominio, o pattern specifici come l'Anti-Corruption Layer, che prevengono le dipendenze dirette e i conflitti tra i contesti. + +### Mappatura + +La relazione tra modelli in differenti Bounded Contexts può essere mappata attraverso pattern come Shared Kernel, Customer/Supplier, Conformist o Partnership, facilitando la gestione delle interazioni tra team diversi che lavorano in contesti distinti. + +### Autonomia + +Ogni team può sviluppare, scalare e distribuire le sue funzionalità indipendentemente all'interno del proprio Bounded Context, promuovendo pratiche di sviluppo agile e microservizi. + +I Bounded Contexts aiutano a organizzare e strutturare sistemi complessi, facendo in modo che parti diverse del sistema possano evolversi in modo indipendente pur contribuendo al successo complessivo del progetto. + +## Cooperation + +La cooperazione tra i diversi Bounded Contexts è cruciale per il funzionamento complessivo del sistema. Eric Evans descrive vari livelli di cooperazione tra i Bounded Contexts per gestire come questi si relazionano e interagiscono. Ecco una panoramica di questi livelli di cooperazione: + +### Partnership + +In questo livello di cooperazione, due o più team lavorano insieme verso obiettivi comuni, coordinando strettamente le loro attività. Questo richiede una comunicazione frequente e un alto livello di collaborazione per assicurarsi che i cambiamenti in un contesto non abbiano impatti negativi sugli altri. + +### Shared Kernel + +Qui, diversi Bounded Contexts condividono una parte comune del modello di dominio. Questo kernel condiviso (composto da codice e modello di dati) deve essere gestito attentamente per evitare conflitti, e ogni modifica al kernel condiviso deve essere negoziata tra tutti i team coinvolti. + +### Customer/Supplier + +In questo modello, un Bounded Context (il fornitore) fornisce servizi o dati a un altro Bounded Context (il cliente). Il cliente dipende dal fornitore e deve adattarsi alle sue interfacce e ai suoi tempi di consegna, mentre il fornitore deve assicurarsi di soddisfare le esigenze del cliente. + +### Conformist + +Un Bounded Context può decidere di conformarsi completamente al modello di un altro contesto per evitare la complessità della negoziazione. Questo accade spesso quando il contesto "follower" non ha sufficiente influenza o interesse per negoziare cambiamenti. + +### Anticorruption Layer (ACL) + +Questo livello di cooperazione introduce uno strato che funge da traduttore tra due contesti per prevenire che il modello di uno influenzi o corrompa quello dell'altro. L'ACL agisce come un buffer, traducendo le richieste e le risposte tra i due contesti in modo che ciascuno possa mantenere il proprio modello interno puro e coerente. + +### Open Host Service + +Un Bounded Context offre un'API o un servizio ben definito che altri context possono utilizzare senza la necessità di una stretta collaborazione o negoziazione. + +### Published Language + +Questo livello implica la creazione di un linguaggio o un protocollo standard che tutti i Bounded Contexts interessati possono comprendere e utilizzare per comunicare tra loro. + +Questi livelli di cooperazione aiutano a definire e gestire le interazioni tra diverse parti di un sistema in modo strutturato, facilitando l'evoluzione indipendente dei Bounded Contexts pur mantenendo la coerenza e l'integrità complessiva del sistema. + +## Domain model pattern + +Il Domain Model pattern è una rappresentazione concettuale e dettagliata del dominio di problema, che enfatizza la cattura della logica e del comportamento del business in modo che il software possa essere più funzionale, manutenibile e scalabile. + +### Entities + +Sono oggetti che hanno un'identità persistente attraverso il tempo e diverse rappresentazioni. Una entità è unica per la sua identità, non solo per i suoi attributi. + +Esempio: In un'applicazione bancaria, un conto corrente è un'entità perché persiste mentre i suoi attributi (come il saldo) possono cambiare. + +### Value Objects + +Sono oggetti che non possiedono un'identità e sono definiti solo dai loro attributi. Sono immutabili, il che significa che una volta creati, i loro dati non possono essere modificati. + +Esempio: Un indirizzo in un sistema di gestione delle spedizioni può essere un oggetto di valore, rappresentando una combinazione di via, città, stato e CAP. + +### Aggregates + +Un Aggregato è un cluster di entità e oggetti di valore che vengono trattati come un'unità per le operazioni di persistenza e di business. +Ogni aggregato ha una Radice di Aggregato, un'entità particolare all'interno dell'aggregato che funge da punto di ingresso e di controllo per tutte le operazioni sull'aggregato. + +Esempio: Un ordine con i suoi dettagli di ordine e pagamenti potrebbe essere un aggregato, con l'ordine stesso come radice. +Servizi di Dominio (Domain Services): + +Contengono logica di business che non appartiene naturalmente a nessuna entità o oggetto di valore. Questi servizi aiutano a mantenere il modello pulito da logiche che non si adattano bene agli oggetti di dominio. +Esempio: Un servizio che calcola l'ammontare degli interessi su più conti potrebbe essere realizzato come un servizio di dominio. + +### Domain services + +Forniscono un meccanismo per accedere agli aggregati o entità, astraendo la logica di accesso ai dati dietro un'interfaccia più orientata al dominio. +Esempio: Un Domain service di clienti potrebbe fornire metodi per trovare clienti specifici, aggiungere nuovi clienti, o aggiornare informazioni esistenti. + +## Event sourced domain model + +L'Event Sourced Domain Model è un approccio di modellazione che si basa sulla cattura di tutti i cambiamenti apportati allo stato di un'applicazione come una sequenza di eventi. Questo modello non solo traccia lo stato corrente degli oggetti di dominio, ma anche come essi hanno raggiunto tale stato attraverso un registro immutabile di tutti gli eventi che hanno modificato lo stato nel tempo. + +Caratteristiche principali dell'Event Sourced Domain Model: + +### Eventi come Registro Primario + +Invece di memorizzare solo lo stato corrente di un'entità nel database, l'event sourcing memorizza una sequenza di eventi che rappresentano le azioni eseguite su quell'entità. Ogni evento riflette un cambiamento nello stato dell'entità. + +### Replay degli Eventi + +Lo stato corrente di un'entità può essere ricostruito "riproducendo" gli eventi dal primo all'ultimo. Questo processo permette non solo di vedere lo stato attuale ma anche di esaminare lo stato dell'entità in qualsiasi punto nel passato. + +### Audit Trail Naturale + +Poiché tutti i cambiamenti sono registrati come eventi, l'event sourcing fornisce automaticamente un tracciato completo e verificabile delle modifiche. Questo è particolarmente utile in domini come la finanza o la salute, dove la tracciabilità e l'audit sono cruciali. + +### Resilienza e Recovery + +L'immagazzinamento degli eventi piuttosto che degli stati rende più facile il recupero in caso di errori o disastri. Se lo stato corrente viene perso o corrotto, può essere ricostruito riproducendo gli eventi. + +### Decoupling Temporale + +Gli eventi possono essere processati asincronamente o differiti, il che permette una maggiore flessibilità nell'architettura del sistema, come l'integrazione con architetture basate su CQRS (Command Query Responsibility Segregation) o sistemi di messaggistica. + +Componenti chiave dell'Event Sourced Domain Model: + +### Eventi di Dominio + +Rappresentano cambiamenti significativi nello stato di un'entità o in un sistema e sono immutabili una volta che sono stati emessi. + +### Aggregati + +Gestiscono gli eventi e producono nuovi eventi come risultato di comandi. Gli aggregati sono responsabili della validazione delle regole di business prima di generare eventi. + +### Repository di Eventi + +Memorizzano gli eventi in un modo sequenziale e sono utilizzati per ricostruire lo stato degli aggregati quando necessario. + +### Proiezioni + +Sono viste costruite dagli eventi per fornire stati derivati utili per le query. Le proiezioni possono essere ottimizzate per specifiche operazioni di lettura e non devono necessariamente rappresentare l'intero stato di un'entità. + +L'Event Sourced Domain Model è particolarmente utile in contesti dove la comprensione dell'evoluzione dello stato e la sua completa tracciabilità sono più importanti della semplice rappresentazione dello stato corrente. diff --git a/docs/it/la-formazione-per-autodidatti.md b/docs/it/la-formazione-per-autodidatti.md new file mode 100644 index 00000000..db96b04b --- /dev/null +++ b/docs/it/la-formazione-per-autodidatti.md @@ -0,0 +1,71 @@ +--- +layout: default +title: La formazione per autodidatti +nav_order: 19 +--- + + +# La formazione per autodidatti +{: .no_toc } + +- TOC +{:toc} + + + +Impadronirsi dei fondamenti di informatica e programmazione, sia per farne una professione che per scopi puramente hobbistici, è certamente un'impresa stimolante ed eccitante, tanto per i risultati a cui può condurre, quanto per il puro piacere del _viaggio_ nella conoscenza che state intraprendendo. + +Prima di proporvi un possibile itinerario di apprendimento, però, trovo utile e necessario porvi di fronte ad un esame di coscienza: più sinceramente ed onestamente risponderete a voi stessi, maggiore vantaggio trarrete dal quadro che le vostre risposte delineerà. + +Un noto adagio recita _**chiunque può programmare, ma non chiunque può diventare developer**_. +Sembra una contraddizione in termini ma in realtà questa frase nasconde una grande verità: al di là di qualunque eccitazione iniziale per la faccenda, è utilissimo essere onesti con se stessi e capire - magari facendosi aiutare da chi può valutare con obiettività e cognizione di causa la vostra predisposizione -, se effettivamente la programmazione può essere per voi una strada serena o se è destinata a trasformarsi in una fatica improba, costellata solo di frustrazioni. + +Contrariamente a quello che vi aspettereste di sentirvi dire in questo libro, programmare è un mestiere molto più **creativo** e molto meno tecnico di quanto si pensi. +Guardare il monitor e vedere schermate di codice che scorrono sotto i vostri occhi non è sufficiente; è necessario che quel codice lo vediate con _gli occhi della mente_ e che nella vostra testa si delinei subito il quadro complessivo in cui quel codice si innesta. +Meglio ancora: dovreste poter guardare il codice sempre in questo modo, e dovreste essere in grado di immaginare scenari diversi, dovreste sentire una voce interna che vi dice: _Ah, sì, questo codice fa questa cosa ma si può fare meglio/più rapidamente/con meno dispendio di energie e risorse se facessi in quest'altro modo..._ +In due parole: se non avete una _inclinazione naturalmente_ verso la materia, potete farcela lo stesso, ma la vostra vita professionale sarà una fatica perenne. +Vi conviene? Solo perché avete in mente un'immagine _romantica_ di chi programma e del suo mestiere, magari tratta dai numerosi film che potreste aver visto? +Non che il mestiere in sé sia gelido, tutt'altro: a volte l'eleganza di una soluzione ad un problema, può commuovere fino alle lacrime e non per densità semantica condensata in due righe di codice ma per l'idea che dietro quelle due righe di codice c'è stato un guizzo creativo, subito accompagnato da finezza nella tecnica, ma pur sempre prodotto da un essere umano: questo, è il bello ed il romantico di questo mestiere. +Inutile dire che di sola romanticheria non si vive e che spesso e volentieri, anche utilizzando gli strumenti più appropriati e più adatti per sollevarci da lavori ripetitivi, la vita quotidiana da developer non è sistematicamente soggetta a scariche di adrenalina. +Anzi, dietro un lavoro ben fatto, di norma, c'è tanta, tanta _falegnameria_. +Insomma, se alle domande _Ho una reale predisposizione?_ e _Riuscirò ad accettare che il percorso di istruzione che sto per intraprendere non sarà tutto un tappeto di petali di rose?_ avete risposto con un Sì netto e sicuro, siete già a metà dell'opera, congratulazioni! + +Chiunque può programmare, allora? +In teoria, nel momento stesso in cui pensate _Ah, ora vado a mettere su la caffettiera_, voi tutti avete in mente - senza rendervene conto -, un piano precisissimo che prevede i seguenti passi: + +1. Prendere la caffettiera +2. Riempire d'acqua la caldaia fino al segno +3. Inserire il filtro +4. Svuotare dell'eccesso di acqua +5. Riempire il filtro con il caffè senza pressarlo +6. Ecc... fino alla tazzina fumante + +Non tutti i problemi si risolvono altrettanto facilmente ma spesso, più che la competenza tecnica, quello che fa un'enorme differenza è l'approccio al problema e - di riflesso -, anche alla sua soluzione. +Esempio banale ma calzante: una volta mi è capitato di avere a che fare con un'applicazione discretamente complessa nella quale, ad un certo punto del processo, avrei dovuto stabilire in un loop molto pesante se nel database dovevo effettuare un'operazione di inserimento o di aggiornamento dei dati. +Richiedendo la cosa molti controlli e volendola semplificare a tutti i costi, risolsi felicemente la faccenda inizializzando valori nelle tabelle all'apertura dell'applicazione. +E ciò fece in modo che avessi automaticamente (e gratis) solo operazioni di aggiornamento e, quindi, potei eliminare tutta una serie di controlli lunghi, complessi, farraginosi e forieri di errori. +Non è un esempio esaustivo, ma spero vi abbia suggerito un'idea migliore di quella che poche righe fa ho chiamato _creatività_. + +Tra l'altro, l'esempio che vi ho appena fornito mette in luce che la programmazione, sia pure con una buona dose di creatività, richiede comunque ed in prima istanza un **approccio analitico ai problemi** e, a seguire, la conoscenza dei metodi/mezzi/strumenti con cui implementare una possibile soluzione (perché sì: _c'è sempre più di un modo per farlo_). +Fortunatamente, è possibile migliorare le proprie capacità analitiche attraverso un lungo periodo di esercitazione mentre per la creatività... o ce l'hai o non ce l'hai, punto. +Questo non vuol dire che chi programma eseguendo i suoi compiti in maniera canonica sia peggiore di una persona baciata dalla Musa della Creatività, ma è fuori discussione che quest'ultima avrà una marcia in più. +Ora, zoomiamo sul nostro specifico interesse, l'auto-formazione: è ovvio che la discussione filosofica sin qui fatta si applica a tutti, autodidatti e/o persone che hanno seguito un corso di studi classico (università) ma per entrambi, la storia della creatività continua a valere. +Di contro, è anche vero che seguire un percorso universitario non ha mai fatto male a nessuno ed offre il vantaggio di frequentare un ambiente nel quale è possibile confrontarsi con altre persone con la nostra stessa passione ed interessi, mentre se siamo autodidatti, queste possibilità sono un po' più ridotte, ma non insuperabili. +Resta il fatto, che in generale sarete _soli_ davanti a libri, monitor, codice e... caffè! +Ad ogni modo, a volte è _meglio soli che male accompagnati_ e con la giusta motivazione e passione per la materia, anche lo studio e la sperimentazione in solitaria non vi peserà più di tanto. + +Da non sottovalutare, nel 2023, che la pervasività e disponibilità H24 7/7 di una connessione ad internet è di grandissimo aiuto ad un autodidatta, perché le risorse che può reperire in rete, gratis o con poca spesa, sono praticamente sterminate e - soprattutto agli inizi -, costituiscono un validissimo aiuto alla comprensione di argomenti che tutto sono meno che romantici. +Superate le domande motivazionali, prima di mettervi all'opera, dovete porvi parecchie altre domande, stavolta di natura squisitamente più tecnica/tecnologica. + +Il termine _programmare_ è un ombrello enorme che accoglie sotto di sé innumerevoli sfumature di codice e dunque, sapere con la miglior precisione possibile a quale tipo di programmazione volete dedicarvi, vi tornerà utilissimo per sfrondare l'inutile e farvi invece una lista utilissima degli strumenti dei quali dovreste impadronirvi. +Non esiste una sola forma di programmazione ma qualunque applicativo (a meno che non vogliate scrivere solo script bash di amministrazione), di solito ha una _interfaccia utente_, in genere ma non necessariamente anche grafica che è detta _**Frontend**_ e tutto quello che succede quando un utente clicca su un pulsante del Frontend; questa parte, è nota come "**Backend**" o retrobottega. +Il Backend non è visibile all'utente e quindi non viene applaudito e lodato come i Frontend ma state certi che se avrete fatto un buon lavoro - che ne so? -, su un sistema bancario, l'utente finale vi sarà grato per avergli ad esempio evidenziato in maniera chiara e precisa problemi o anche opportunità legate al suo conto corrente. + +Fatta questa prima scelta, dovete preoccuparvi di capire su quali tecnologie volete formarvi e prepararvi. +Un mio consiglio, opinione del tutto personale, è: evitate come la peste di gettarvi a corpo morto sui numerosi _framework_ in circolazione. +Che siano framework frontend o backend, è essenziale che prima di utilizzarli vi impadroniate di ciò che c'è alla loro base. +Questo approccio, non solo vi permetterà di comprendere le cose a basso livello, ma, in seguito, quando vi avvicinerete ad un qualunque framework, vi consentirà di comprenderne molto più rapidamente e facilmente i suoi _internals_, che sono invariabilmente basati proprio su... le basi. +Non posso suggerirvi tecnologie o linguaggi specifici ma posso dirvi che in generale, è vero che dovreste sentirvi molto _falegnami_ e sapere quale è l'attrezzo, lo strumento, l'utensile più idoneo ad assolvere ad una determinata funzione. +E dato che le funzioni possono essere molte, questo spiega anche il proliferare dei framework e la necessità di sapere almeno _che cosa fanno_, per quale compito meglio si prestano. +Diversamente, sarebbe come andare a casa dell'anziana signora per ripararle una tapparella ed accorgersi solo una volta sulla scala, che avremmo avuto bisogno di un cacciavite a croce oltre che di quello a lama piatta. +Il che significa scendere dalla scala, tornare in officina, prendere il cacciavite mancante e quindi tornare sulla scala; una perdita di tempo ed energie inutile, vi pare? diff --git a/docs/it/linkedin.md b/docs/it/linkedin.md index 0fd8b2ef..26a9c36b 100644 --- a/docs/it/linkedin.md +++ b/docs/it/linkedin.md @@ -1,7 +1,7 @@ --- layout: default title: Il profilo LinkedIn -nav_order: 11 +nav_order: 12 --- diff --git a/docs/it/partner-e-amici.md b/docs/it/partner-e-amici.md new file mode 100644 index 00000000..4683f67e --- /dev/null +++ b/docs/it/partner-e-amici.md @@ -0,0 +1,27 @@ +--- +layout: default +title: Partner e amici +nav_order: 99 +--- + + +# Partner e amici +{: .no_toc } + +- TOC +{:toc} + + + +In questa pagina raccogliamo i link a community, aziende e persone che supportano e promuovono il nostro progetto. +L'ordine di apparizione è meramente alfabetico. + +## Need For Nerd + +Community di developers in cui far convergere le esigenze delle aziende con quelle dei developer. +[Pagina Facebook](https://www.facebook.com/NeedforNerd) - [Gruppo Facebook](https://www.facebook.com/groups/1703058016594724) - [Instagram](https://www.instagram.com/needfornerd/) - [LinkedIn](https://www.linkedin.com/company/need-for-nerd/) + +## TheRedCode.it + +Un blog di informatica e programmazione, con articoli e tutorial su vari linguaggi di programmazione, tecnologie e strumenti. +[Sito](https://theredcode.it) - [LinkedIn](https://www.linkedin.com/company/theredcode-it) - [Instagram](https://www.instagram.com/theredcode_it) diff --git a/docs/it/percorsi-di-formazione-alternativi.md b/docs/it/percorsi-di-formazione-alternativi.md index 128a7c8e..970e5abb 100644 --- a/docs/it/percorsi-di-formazione-alternativi.md +++ b/docs/it/percorsi-di-formazione-alternativi.md @@ -1,7 +1,7 @@ --- layout: default title: Percorsi di formazione alternativi -nav_order: 17 +nav_order: 18 --- diff --git a/docs/it/protocolli-di-comunicazione.md b/docs/it/protocolli-di-comunicazione.md new file mode 100644 index 00000000..134078f7 --- /dev/null +++ b/docs/it/protocolli-di-comunicazione.md @@ -0,0 +1,150 @@ +--- +layout: default +title: Protocolli di comunicazione +nav_order: 22 +--- + + +# Protocolli di comunicazione +{: .no_toc } + +- TOC +{:toc} + + + +# + +In ambito tecnologico e informatico esistono concetti fondamentali e strutture consolidate da tempo che spesso diamo per scontato. I protocolli di comunicazione sono un esempio di questa casistica: sono strumenti che utilizziamo quotidianamente, sia nella nostra vita lavorativa sia in quella privata. Ogni giorno infatti interroghiamo un server, inviamo dati, riceviamo risposte e tutto questo avviene grazie ai protocolli di comunicazione anche se, a volte, non ne siamo consapevoli. + +Questi infatti sono un insieme di regole che definiscono come avviene la comunicazione tra due o più entità, in questo caso tra due o più computer e come le informazioni vengono trasmesse e interpretate. + +L'esempio più comune nel nostro ambito lavorativo è quello delle chiamate HTTP, che avvengono tra un client e un server, dove, per esempio, il client è il nostro browser e il server è un computer che ospita il sito che stiamo visitando. In questo caso il protocollo HTTP definisce come avviene la comunicazione tra il nostro browser e il server web, come vengono trasmesse le informazioni e come queste vengono interpretate. +Essendo così diffuso, spesso le specifiche del protocollo HTTP vengono date per scontate ma è importante tenerne conto, soprattutto quando si sviluppano applicazioni che sfruttano questo protocollo. + +Il protocollo HTTP è solo un esempio: esistono molti altri protocolli di comunicazione, e variano molto in base alla loro diffusione, complessità, sicurezza garantita, performance e contesto di utilizzo. + +In questo capitolo vedremo i principali, in quali ambiti vengono utilizzati e come funzionano. + +## Protocolli testuali e binari + +Una prima distinzione che possiamo fare è quella tra protocolli testuali e protocolli binari. Entrambi i tipi di protocolli sono utilizzati per trasmettere informazioni tra due o più entità, e la principale differenza tra i due è nel come i byte trasmessi sono interpretati. In questo caso con "interpretati" si intende come i byte vengono trasformati in informazioni leggibili da un computer: per fare un esempio, secondo la codifica ASCII, il byte `01000001` viene interpretato come il carattere `A`, mentre può essere interpretato in modo differente da altri protocolli binary. + +I protocolli testuali sono protocolli che utilizzano un formato testuale per trasmettere le informazioni, ovvero i bytes trasmessi hanno un corrispettivo nell'alfabeto, tipicamente tramite la codifica ASCII o UTF8. +Questo significa che le informazioni vengono trasmesse in un formato che è sia leggibile da un essere umano sia da un computer. Questo tipo di protocolli sono meno efficienti e veloci, ma sono più facili da implementare e da utilizzare. Inoltre, essendo leggibili da un essere umano, sono più facili da analizzare in caso di problemi. L'esempio più comune di protocollo testuale è il protocollo HTTP/1.1. + +I protocolli binari, invece, sono protocolli che utilizzano un formato binario per trasmettere le informazioni, ovvero i bytes trasmessi hanno un significato ben preciso, solitamente diverso dalla codifica ASCII. Questo significa che le informazioni vengono trasmesse in un formato che non è leggibile da un essere umano, ma che è leggibile da un computer. Questo tipo di protocolli sono più efficienti e veloci, ma sono più difficili da implementare e da utilizzare. Esempi di protocolli binari sono il protocollo TCP, UDP, HTTP2 e gRPC. + +Entrambi i tipi di protocolli sono utilizzati e utilizzano lo stesso principio di base: definire un formato per trasmettere le informazioni e serializzare le informazioni in bytes. La differenza è che i protocolli testuali utilizzano una codifica testuale, mentre i protocolli binari utilizzano una codifica dedicata e binaria. + +### Lo stack OSI e la distinzione tra TCP e UDP + +In base al modello [OSI](https://it.wikipedia.org/wiki/Modello_OSI), i protocolli di comunicazione si dividono in vari livelli ma il concetto di base è il seguente: la comunicazione è strutturata su più livelli, ogni livello ha un compito specifico e viene definito basandosi sui livelli precedenti. Per esempio, il protocollo HTTP/1.1 è definito al livello 7 e utilizza il protocollo TCP, che è definito invece al livello 4, il quale si basa sul protocollo IP, definito al livello 3. Questo permette di definire protocolli più complessi basandosi su protocolli più semplici e di riutilizzare i protocolli più semplici in più contesti. + +Senza però entrare troppo nei dettagli, possiamo dire che i protocolli di comunicazione possono essere divisi in due categorie: quelli orientati alla connessione e quelli non orientati alla connessione. + +Il protocollo TCP è un protocollo di comunicazione orientato alla connessione, questo significa che prima di trasmettere le informazioni, il client e il server devono stabilire una connessione tramite un handshake. Questo meccanismo permette di inizializzare la connessione che garantirà che le informazioni vengano trasmesse correttamente e che non vengano perse durante la trasmissione. + +Il protocollo UDP è un protocollo di comunicazione non orientato alla connessione, questo significa che non è necessario effettuare meccanismi di inizializzazione per la trasmissione delle informazioni. Vista la mancanza di azioni iniziali come quella dell'handshake, questo tipo di protocolli permette di trasmettere le informazioni più velocemente, ma non ne garantisce la correttezza o che esse non vengano perse. + +Il modello OSI è una struttura concettuale che ci permette di identificare e catalogare i protocolli di comunicazione, ma solitamente non viene utilizzato direttamente nella pratica. In pratica, i protocolli di comunicazione vengono utilizzati in modo trasparente, senza dover conoscere i dettagli del modello OSI. + +### Il protocollo DNS per la risoluzione dei nomi di dominio + +Durante la navigazione web, siamo soliti utilizzare i nomi di dominio per accedere ai siti web, come ad esempio `www.google.com`. Questi nomi di dominio sono più facili da ricordare, utilizzare e da condividere. Purtroppo però, i computer non possono utilizzare direttamente i nomi di dominio per connettersi ad un server web: è necessario convertire il nome di dominio in un indirizzo IP. Il protocollo DNS (Domain Name System) è utilizzato per rispondere a questa esigenza. + +Il client, prima di effettuare la richiesta ad un server web, deve quindi tradurre il nome di dominio in un indirizzo IP. Per fare questo, il client invia una richiesta ad un server DNS, ossia un server avente nel proprio database la corrispondenza tra i nomi di dominio e loro indirizzi IP. Solo quando il client riceve dal server DNS l'indirizzo IP corrispondente al nome di dominio, può effettuare la richiesta al server web. + +Ma cosa succede quando un server DNS non conosce la corrispondenza tra il nome di dominio e l'indirizzo IP? In questo caso, il server DNS inoltra la richiesta ad un altro server DNS, che a sua volta inoltra la richiesta ad un altro server DNS, e così via, fino a che la corrispondenza viene trovata. Questo meccanismo di inoltro delle richieste è chiamato risoluzione dei nomi di dominio. +Questa tecnica è per esempio utilizzata quando si hanno dei nomi di dominio non pubblici, come ad esempio quelli utilizzati in una rete locale. In questo caso, il nome di dominio può essere risolto solo all'interno della rete locale, e non all'esterno, garantendo la sicurezza e la privacy della rete. Esempi tipici sono i nomi di dominio utilizzati in una rete aziendale come i nome di dominio di un database o la intranet aziendale. + +Il meccanismo di traduzione viene usato in realtà per tutti i protocolli di comunicazione che richiedono la traduzione tra nome di dominio e indirizzo IP, non solo per il protocollo HTTP. Ad esempio, quando si invia una mail, il client deve tradurre il nome di dominio del server SMTP in un indirizzo IP per poter inviare la mail. Oppure, quando il backend di un'applicazione deve connettersi al database, deve tradurre il nome di dominio del database in un indirizzo IP per poter effettuare la connessione. + +Il protocollo DNS è complesso e supporta altre funzionalità oltre a quelle descritte sopra che purtroppo per motivi pratici non sono coperte in questo capitolo. +Rimandiamo comunque alla [pagina di Wikipedia](https://it.wikipedia.org/wiki/Domain_Name_System) per una spiegazione più dettagliata. + +### Il protocollo HTTP + +Il protocollo HTTP (HyperText Transfer Protocol) è sicuramente uno dei protocolli di comunicazione più diffusi nel web. Questo protocollo è utilizzato per trasmettere informazioni tra un client e un server, dove il client è l'entità che vuole effettuare la richiesta e il server è l'entità che deve produrre la risposta. +Agli inizi del web, il protocollo HTTP era utilizzato per trasmettere informazioni testuali, come ad esempio il contenuto di una pagina HTML. Con il tempo, il protocollo HTTP è stato esteso per trasmettere anche altri tipi di informazioni, come ad esempio file multimediali, file binari, JSON, ecc. + +Nel corso degli anni, il protocollo HTTP ha avuto diverse revisioni atte a migliorarne alcune caratteristiche come le prestazioni e la sicurezza, ma lo scopo principale è rimasto lo stesso: trasmettere informazioni tra un client e un server. Infatti la prima versione è la version 0.9 (oramai non più usata) che è stata utilizzata per trasmettere informazioni testuali, descritta qui: https://www.w3.org/Protocols/HTTP/AsImplemented.html. +La versione 1.0 è la versione che ha introdotto il concetto di `header` e che ha permesso di trasmettere informazioni di contesto della chiamata come il `content-type` e i `cookie`. +Tale introduzione ha permesso di sviluppare siti web più complessi con possibilità di autenticazione e di trasmissione di file multimediali. +La versione 1.1 ha introdotto il concetto di connessione TCP persistente: essa permette infatti di mantenere la connessione aperta tra il client e il server per poterla sfruttare nuovamente per una nuova richiesta HTTP. Con la versione 1.0, infatti, ogni richiesta HTTP richiedeva una nuova connessione TCP: effettuata la richieste e ricevuta la risposta, la connessione TCP utilizzata veniva distrutta. Se il client voleva effettuare un'altra richiesta, doveva aprire una nuova connessione TCP e questo comportava un aumento del tempo di risposta e delle risorse utilizzate. +Con la versione 1.1, invece, la connessione TCP viene mantenuta aperta e riutilizzata per effettuare più richieste sequenziali. Questo favorisce le prestazioni e la velocità di trasmissione delle informazioni. + +Le versioni 1.x dell'HTTP avevano tutte un grosso limite: per effettuare 2 richieste in parallelo si dovevano utilizzare 2 connessioni TCP differenti. Con la versione 2 del protocollo HTTP questo limite viene superato grazie al concetto di multiplexing: il protocollo HTTP/2 utilizza infatti un unico canale di comunicazione TCP per trasmettere più richieste in parallelo. Questo permette di migliorare le prestazioni e la velocità di trasmissione delle informazioni. Questa modifica migliora nettamente le performance in linea generale, ma in particolar modo delle applicazioni web che utilizzano molte risorse esterne come ad esempio le immagini, i file CSS e i file JavaScript. La versione 2 utilizza un nuovo formato binario per trasmettere le informazioni. + +La versione 3 del protocollo HTTP è stata introdotta per migliorare la sicurezza delle connessioni. Infatti con questa versione, la comunicazione è forzata ad essere criptata e migliora le tempistiche per la creazione di una connessione sicura. +Un ulteriore cambio tecnologico introdotto prevede l'utilizzo del protocollo UDP: tale scelta è stata necessaria visti i problemi riscontrati con HTTP versione 2 per cui il multiplexing in casi di errore di trasmissione non era performante. Pur prevedendo infatti il multiplexing, l'invio dei dati avviene in modo sequenziale: la gestione degli errori di trasmissione del protocollo TCP cu sui la versione 2 si basa soffre del problema noto come "head-of-line". +Se sulla connessione vengono inviati tre pacchetti, e solo il secondo ha un errore di trasmissione, il client è costretto a inviare nuovamente gli ultimi due pacchetti anche se l'ultimo ha raggiunto la destinazione correttamente. La versione 3 basata su UDP, non soffre di questo problema per cui è consigliata in modo particolare in casi di bassa connettività o dove il numero di errori di trasmissione è alto. + +Una menzione va fatta anche al protocollo HTTPS (Hypertext Transfer Protocol Secure): non si tratta di un protocollo a tutti gli effetti, ma di un'estensione del protocollo HTTP, utile in particolare quando la connessione non è garantita sicura dal protocollo stesso, per esempio HTTP1.1 e HTTP2. In tale occasione, per rendere la comunicazione sicuro è necessario fare affidamento su un layer di criptazione. + +Non esiste un protocollo HTTP migliore di un altro: mentre sono da sconsigliare i protocolli deprecati come HTTP 0.9 e HTTP 1.0, gli altri rimangono molto validi. +Per esempio per endpoint interni, invocati solo da applicazioni, il protocollo HTTP 1.1 è solitamente la scelta utilizzata. + +### Il protocollo SSH + +Il protocollo SSH (Secure Shell) è un protocollo di comunicazione basato su TCP e permette di stabilire una connessione sicura tra due computer. +Questo tipo di protocollo viene comunemente utilizzato per connettersi ad un computer remoto, per trasferire file e per eseguire comandi, il tutto in modo sicuro. Il protocollo SSH è considerato ad oggi lo standard per eseguire queste operazioni. + +Il protocollo è diviso in tre layer distinti: + +- Transport Layer Protocol: è il layer che si occupa di stabilire una connessione sicura tra il client e il server. Qui vengono, per esempio, decisi gli algoritmi per la connessione. Vengono inoltre scambiate le chiavi pubbliche per garantire la sicurezza della connessione. +- User Authentication Protocol: è il layer che si occupa di autenticare l'utente che si sta connettendo al server. Vengono scambiate le credenziali dell'utente e vengono verificate dal server. Esempi di autenticazione sono la password e la chiave pubblica. +- Connection Layer Protocol: è il layer che si occupa di gestire i comandi del protocollo SSH, come ad esempio l'esecuzione di comandi remoti, il forwarding delle porte e il trasferimento dei file. + +Questa suddivisione permette di avere un protocollo flessibile e sicuro, che può essere configurato differentemente a seconda delle esigenze. Per esempio è possibile configurare il protocollo di compressione o di disabilitare l'autenticazione tramite password, utilizzando solo la chiave pubblica. + +Questo protocollo è molto diffuso e viene spesso usato per accedere a server remoti su cui si ha bisogno di operare. + +### Il protocollo FTP + +Il protocollo FTP (File Transfer Protocol) è un protocollo testuale di comunicazione che permette di trasferire file tra un client e un server. Questo tipo di protocollo viene comunemente utilizzato per trasferire file tra un computer e un server, per esempio per trasferire file da un computer locale ad un server remoto o viceversa. + +Poiché questo protocollo non usa connessioni sicure, sono stati proposti dei protocolli derivati come SFTP (Secure File Transfer Protocol) e FTPS (FTP Secure) che permettono di trasferire file in modo sicuro. Questi protocolli utilizzano connessioni sicure basate su SSH o SSL/TLS per garantire la sicurezza del trasferimento dei file. + +## La rappresentazione dei dati applicativi + +I protocolli di comunicazione sono utilizzati per poter trasmettere informazioni tra due o più entità, e i client e i server devono concordare sia sul protocollo della richiesta sia sul contenuto della stessa. Infatti una volta che il client e il server concordano su quale protocollo di comunicazione usare, devono anche concordare quale formato usare per scambarsi le informazioni applicative. Per fare questo, è necessario definire un formato comune per la trasmissione serializzando le informazioni in bytes. Questo processo è chiamato rappresentazione dei dati che può essere di due tipi: testuale e binaria. + +La rappresentazione dei dati testuale utilizza un formato testuale per trasmettere le informazioni. Questo significa che le informazioni che vengono trasmesse in un formato che è leggibile anche da un essere umano, oltre che dal computer. Questo tipo di rappresentazione è meno efficiente e veloce, ma è più facile da implementare e da utilizzare. Inoltre, essendo leggibile da un essere umano, è più facile da analizzare in caso di problemi. Esempi più comuni di rappresentazione dei dati testuali sono il formato JSON, XML e YAML. + +La rappresentazione dei dati binaria è invece una rappresentazione che utilizza un formato binario per trasmettere le informazioni. Questo significa che le informazioni vengono trasmesse in un formato che non è leggibile da un essere umano, ma che è leggibile da un computer. Questo tipo di rappresentazione è più efficiente e veloce, ma è più difficile da implementare e da utilizzare. Esempi più comuni di rappresentazione dei dati binari sono il formato Protocol Buffers, Avro e MessagePack. + +Per approfondire: + +- https://protobuf.dev/ +- https://avro.apache.org/ +- https://msgpack.org/ + +### Il formato JSON + +Il formato JSON (JavaScript Object Notation) è un formato testuale per la rappresentazione dei dati applicativi. Questo formato è basato sulla sintassi del linguaggio JavaScript e permette di rappresentare dati in modo semplice, strutturato e leggibile. Questo formato è molto diffuso e viene utilizzato in molti contesti, sia in ambito web sia in ambito mobile. +Potremmo aver incontrato questo formato in diversi contesti, ad esempio quando si effettua una chiamata HTTP ad un server web, il server restituisce una risposta in formato JSON, oppure in un file di configurazione. + +### Il formato XML + +Il formato XML (eXtensible Markup Language) è un formato testuale per la rappresentazione dei dati applicativi. Questo formato è basato sulla sintassi del linguaggio XML e permette di rappresentare dati in modo strutturato e leggibile. Questo formato è molto diffuso poiché permette di definire un formato personalizzato per la rappresentazione dei dati, usando una definizione di schema. +Potremmo aver incontrato questo formato in diversi contesti, ad esempio in un servizio SOAP, in un file di configurazione o in un file SVG. + +### Il formato YAML + +Il formato YAML (YAML Ain't Markup Language) è un formato testuale per la rappresentazione dei dati applicativi. Questo formato è basato sulla sintassi del linguaggio YAML e permette di rappresentare dati in modo strutturato e leggibile, evitando la verbosità del formato XML e JSON. +Potremmo aver incontrato questo formato in diversi contesti, ad esempio in un file di configurazione. + +### Il formato Protocol Buffers + +Il formato Protocol Buffers è un formato binario per la rappresentazione dei dati applicativi. Questo formato è basato sulla sintassi del linguaggio Protocol Buffers e permette di rappresentare dati in modo strutturato e veloce. Questo formato è molto diffuso poiché permette di definire un formato personalizzato per la rappresentazione dei dati, usando una definizione di schema. Permette di gestire in modo semplice e veloce la serializzazione e la deserializzazione dei dati anche in modo retrocompatibile. +Potremmo aver incontrato questo formato in diversi contesti, ad esempio in un servizio gRPC, essendo un formato binario e quindi più veloce e più efficiente di un formato testuale. + +## Conclusioni + +In questo capitolo abbiamo visto i principali protocolli di comunicazione, come funzionano e in quali ambiti vengono utilizzati. Abbiamo visto che i protocolli di comunicazione sono un insieme di regole che definiscono come avviene la comunicazione tra due o più entità, in questo caso tra due o più computer. Queste regole definiscono come avviene la comunicazione, come vengono trasmesse le informazioni e come vengono interpretate. +Non tutti i protocolli di comunicazione sono uguali: nel capitolo abbiamo dato solo alcuni esempi non esaustivi dei diversi utilizzi. + +Da notare inoltre che i protocolli non sono studiati a tavolino, ma rispecchiano l'evoluzione di diverse esigenze scaturite da problemi reali tecnologici, come per esempio migliorare le performance, la sicurezza o la gestione degli errori. + +Pur non essendo uno degli argomenti più gettonati e divertenti, mi auguro che tu sia riuscito/a ad arrivare fino a qui in fondo e che l'argomento ti abbia stimolato un po' di curiosità! diff --git a/docs/it/refactoring.md b/docs/it/refactoring.md index 36740a26..947e78c7 100644 --- a/docs/it/refactoring.md +++ b/docs/it/refactoring.md @@ -1,7 +1,7 @@ --- layout: default title: Refactoring -nav_order: 14 +nav_order: 15 --- diff --git a/docs/it/remote-working.md b/docs/it/remote-working.md index 9559a1ba..79aefc55 100644 --- a/docs/it/remote-working.md +++ b/docs/it/remote-working.md @@ -1,7 +1,7 @@ --- layout: default title: Remote working - tra mito e realtà -nav_order: 15 +nav_order: 16 --- diff --git a/docs/it/senior.md b/docs/it/senior.md index 0b24fd4c..4e2932df 100644 --- a/docs/it/senior.md +++ b/docs/it/senior.md @@ -124,11 +124,11 @@ Concentriamoci un attimo sulle competenze tecniche. Dopotutto, visto come funzio In qualità di sviluppatore senior, possedere competenze tecniche che coprano diverse aree è fondamentale. Per essere uno sviluppatore senior di successo è essenziale avere un profilo a _“forma di T”_ (o _T-Shaped profile_), che si concretizza nel saper padroneggiare una specifica competenza pur possedendo solide e ampie basi in altre aree. -Immagina di disegnare una "T". la linea verticale rappresenta una profonda conoscenza in una specifica area tecnica. Più questa linea è lunga più si è raggiunta una padronanza della specifica area tecnica. Invece, la linea orizzontale rappresenta una vasta conoscenza in tante altre aree, non necessariamente una conoscenza approfondita ma sufficiente sviluppata da fornire i mezzi per poter spaziare tra gli argomenti piú disparati durante una conversazione tecnica. +Immagina di disegnare una "T", la linea verticale rappresenta una profonda conoscenza in una specifica area tecnica. Più questa linea è lunga più si è raggiunta una padronanza della specifica area tecnica. Invece, la linea orizzontale rappresenta una vasta conoscenza in tante altre aree, non necessariamente una conoscenza approfondita ma sufficientemente sviluppata da fornire i mezzi per poter spaziare tra gli argomenti piú disparati durante una conversazione tecnica. Questo tipo di profilo permette al singolo individuo di poter contribuire in modi diversi ad un progetto pur essendo esperto nella propria area di specializzazione primaria: avendo competenze diverse, i profili a T consentono una collaborazione efficace con membri di lavoro, aprendo la strada ad un processo di sviluppo con maggiori probabilità di successo. -Un buon modo per costruire il profilo a T è quello di iniziare a sviluppare il tuo tratto verticale, ovvero quello che alla fine diventerà il tuo punto di forza! Concentrati per un po’ su una singola area. Ovviamente è meglio preferire delle aree tecniche per le quale ci si senta particolarmente propensi e per le quali si abbia un grosso interesse. Più qualcosa ci appassiona, più è facile stare al passo con l'innovazione e trovare il tempo per sperimentare ed imparare. +Un buon modo per costruire il profilo a T è quello di iniziare a sviluppare il tuo tratto verticale, ovvero quello che alla fine diventerà il tuo punto di forza! Concentrati per un po’ su una singola area. Ovviamente è meglio preferire delle aree tecniche per le quali ci si senta particolarmente propensi e per le quali si abbia un grosso interesse. Più qualcosa ci appassiona, più è facile stare al passo con l'innovazione e trovare il tempo per sperimentare ed imparare. Quando pensi di avere raggiunto la padronanza di una data competenza tecnica, allora potrai espandere la tua conoscenza partendo da lì, sviluppando così il tratto orizzontale. Esci fuori dalla tua comfort zone ed esplora argomenti correlati. Questi argomenti dovrebbero auspicabilmente arricchire le tue conoscenze pregresse e permetterti di contribuire in modo più esteso ai vari aspetti dello sviluppo di un prodotto software. diff --git "a/docs/it/universit\303\240-vs-self-made.md" "b/docs/it/universit\303\240-vs-self-made.md" new file mode 100644 index 00000000..48577faa --- /dev/null +++ "b/docs/it/universit\303\240-vs-self-made.md" @@ -0,0 +1,61 @@ +--- +layout: default +title: Università VS Self-Made +nav_order: 21 +--- + + +# Università VS Self-Made +{: .no_toc } + +- TOC +{:toc} + + + +## La terza via: l’ITS + +Nel momento in cui si vuole intraprendere la via della “specializzazione” da developer, una volta concluse le scuole superiori, spesso ci si trova davanti a quello che è, a tutti gli effetti, un bivio: _intraprendere la via dell’Università o iniziare un percorso di autoformazione?_ + +La risposta non è sempre così scontata, vista anche la soggettività della scelta. Nel primo caso stiamo parlando di un percorso che dura minimo tre anni (o cinque, a seconda dell’obiettivo), strutturato e tenuto da docenti formati e che seguono un piano di studi ben preciso, mentre nel secondo abbiamo una durata potenzialmente ignota e che si basa esclusivamente sulla nostra organizzazione, disciplina e motivazione. + +Molte persone spesso però sottovalutano o addirittura non sono a conoscenza di una terza via, ovvero degli [ITS (_Istituto Tecnico Superiore_)](https://www.miur.gov.it/web/guest/tematica-its) di programmazione, degli enti solitamente finanziati dalla regione e/o da alcune aziende del settore, il cui scopo è quello di formare nel giro di un paio d’anni delle figure professionali da inserire nel mondo dell’IT. + +### Un ibrido tra Teoria e Pratica + +**_“Com'è strutturato il percorso formativo di un ITS?”_** + +Per integrare in modo corretto e graduale la “Teoria” e la “Pratica”, il piano formativo standard di un ITS generalmente prevede: + +- **Primo Anno**: Prevalentemente dedicato alle **lezioni in aula**, dove si ha l'opportunità di apprendere dalle competenze di **docenti aziendali**1 e universitari, i concetti, i linguaggi e gli strumenti fondamentali della figura professionale che si ambisce a diventare. + Inoltre c’è da menzionare che in alcuni ITS viene offerta la possibilità di prepararsi e sostenere esami per certificazioni esterne quali: [CISCO IT Essentials](https://www.netacad.com/courses/os-it/it-essentials), [ECDL](https://www.aicanet.it/aica/qualita/ecdl-full-standard) e [PET/FIRST/ecc.](https://www.cambridgeenglish.org/exams-and-tests/) per citarne solo alcune. + +- **Secondo Anno**: Dopo una breve fase di lezioni dedicate agli ultimi moduli, mirate a esplorare concetti più avanzati, come l'_Architettura del Software_ per esempio, l'attenzione si sposta principalmente sullo **stage lavorativo**, nonché ultima attività prima dell’esame finale (necessario per conseguire un _Diploma di [V livello EQF](https://europa.eu/europass/it/description-eight-eqf-levels)_). + +**_“Come posso trovare gli ITS?”_** + +Prima di rispondere a questa domanda, è bene precisare che gli ITS in Italia offrono una vasta gamma di corsi dedicati a settori diversi, tra cui tecnologia, industria, e servizi. Per ovvi motivi in questo libro, più precisamente in questo capitolo, si parlerà di quelli legati al settore IT. + +Chiusa questa parentesi, il sito dell’**_[INDIRE](https://www.indire.it/progetto/its-istituti-tecnici-superiori/dove-sono-gli-its/)_** (_Istituto Nazionale Documentazione Innovazione Ricerca Educativa_) è sicuramente la migliore risorsa per ottenere una risposta a questa domanda. Ovviamente non l’unica, ma sicuramente tra tutte le pagine risulta essere la più completa, presentando anche a sostegno i dati relativi agli ITS della regione e all’occupazione degli studenti diplomati. + +**“_Perché l’ITS potrebbe risultare un’ottima via?”_** + +Innanzitutto come già citato è un corso molto breve (2 anni), a numero chiuso (quindi con un test di ammissione) e alla portata di tutti dal punto di vista economico, dal momento che l’iscrizione è gratuita o a costo molto ridotto. Solitamente viene fornito un PC da poter utilizzare durante le lezioni e dedicato completamente alla programmazione, ma soprattutto, ciò che contraddistingue l’ITS (e il motivo per cui viene citato in questo capitolo) è la sua **dualità tra lezioni in aula e stage in azienda** per poter testare in modo pratico “sul campo” i concetti appresi. + +Qualcuno potrebbe obiettare dicendo che la preparazione concettuale e teorica potrebbe risultare meno solida rispetto a quella universitaria, anche se questa scelta, come spiegato in precedenza, predispone molte attività in ambito aziendale, essendo maggiormente orientata al mondo del lavoro, e quindi aiuta nel "salto". Proprio in questo contesto, sfruttando le opportunità lavorative e gli incontri con i professionisti del settore, dobbiamo far emergere la nostra proattività e curiosità per valorizzare al meglio le competenze di base che abbiamo acquisito! + +Per esempio, le lezioni di Python che ho seguito in Accademia hanno stimolato la mia curiosità e adesso non vedo l'ora di affinare le mie conoscenze su questo linguaggio. Partendo da questa "infarinatura" posso apprendere più facilmente, anche in maniera autonoma. + +Tramite questo percorso, passando per gli stage, si possono acquisire anche competenze su argomenti che non sono stati affrontati in aula. Ad esempio, in futuro potrei trovarmi a svolgere uno stage in un’azienda che usa un framework specifico: avendo seguito le lezioni su JavaScript, ho acquisito delle solide basi che non potranno far altro che semplificare il processo di apprendimento di una nuova tecnologia basta su questo linguaggio di programmazione. + +Ma le opportunità offerte dall'ITS non terminano qua! Infatti se tutto ciò non dovesse essere sufficiente per trovare l'impiego che desideriamo o non dovesse soddisfare appieno le nostre aspettative sul grado di approfondimento degli argomenti, la conclusione di questo percorso biennale, ci permetterà di accedere in modo agevolato alle Università che riconoscono questo corso e i crediti formativi guadagnati durante gli studi. Così facendo sarà possibile perseguire la via della laurea senza dover ricominciare da zero, evitando di dover preparare ogni singolo esame2. + +In ogni caso, a prescindere dal ramo che si decida di intraprendere una volta conclusa questa esperienza, è importantissimo alimentare sempre questo “fuoco”, questa sete di conoscenza che, oltre ad essere fondamentale in questo settore (perché non si smette mai di imparare nel mondo IT 🤓), ci aiuterà a crescere come figura professionale e a farci notare da aziende dove sarà più facile fare esperienza e assimilare nuovi concetti. + +--- + +### Note + +> 1**Docente Aziendale**: Una figura che lavora nel settore e che tende dunque a spiegare i concetti più da un punto di vista aziendale/lavorativo. Le loro lezioni sono molto importanti in vista dello stage, che per molti potrebbe essere la prima vera e propria esperienza lavorativa + +> 2Il riconoscimento dei crediti formativi ottenuti durante il percorso ITS, e gli esami che non è necessario preparare, possono variare da Università a Università