Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

Ventennale

Cambiare tutto per non cambiare niente

20 anni di corsi e ricorsi storici….

Marco Piraccini

Marco Piraccini

Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/

MokaByte 1996–2016 ventennale

Cambiare tutto per non cambiare niente

20 anni di corsi e ricorsi storici….

Marco Piraccini

Marco Piraccini

E’ passato un bel po’ di tempo da quando ho iniziato a fare questo lavoro, e ancora di più da quando ho iniziato a smanettare con i computer. Ho lavorato negli anni a tanti progetti, molti non me li ricordo nemmeno, ricoprendo quasi tutti i ruoli possibili, e in molti contesti, sia italiani che internazionali.

Quindi quando Giovanni mi ha chiesto di scrivere un articolo per i 20 anni di MokaByte, ne ho approfittato per fare un po’ il “punto” e mettere nero su bianco qualche considerazione che mi girava nella testa già da un po’.

Mi definisco un Software Architect per specificare che, oltre ad essere un sviluppatore, possiedo una visione architetturale del software, cosa che in realtà ho avuto sin dall’inizio. Anzi mi sono sempre trovato molto a disagio quando ho dovuto lavorare in situazioni in cui tutta l’architettura non mi era perfettamente chiara. In ogni caso ovviamente, come tutti, ho dovuto fare i miei bravi errori per capire un bel po’ di cose.

In effetti, è difficile “imparare” ad essere un architetto, anzi non è semplice nemmeno definire cosa sia una “architettura”. Una definizione che mi piace è [1]:

“The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”

Ovvero, con un buon grado di approssimazione, potremmo definire un Software Architect come qualcuno che è in grado di pensare ad un sistema software in termini di componenti che hanno relazioni tra di loro e delle loro proprietà.

Chiaramente, oltre alla comprensione, ad un architetto è richiesta la progettazione di tali sistemi, una skill che, nonostante i job title, non sono in tanti a possedere. Per questo in passato l’uso di alcune tecnologie si è posto in modo esplicito il fatto di limitare le possibilità di disegno dei sistemi, principalmente per evitare errori (promuovendo best-practices) e portare a standardizzazione degli artefatti prodotti, con evidenti vantaggi in termini di gestione (e per i vendor di software). Un esempio che conosco molto bene di questo approccio è JEE (Java Enterprise Edition).

Credo che sia ormai universalmente riconosciuto che le prime versioni delle specifiche JEE fossero decisamente sovra-ingegnerizzate, cosa che ha portato infatti allo sviluppo di framework alternativi (per esempio Spring, Hibernate) che a loro volta hanno influenzato versioni successive delle specifiche. Questo tipo di approccio presenta comunque degli innegabili vantaggi ma impone, in modo più o meno esplicito, dei precisi paradigmi architetturali che non sono necessariamente adatti ad ogni contesto (si pensi alla difficoltà di usare JEE per applicazioni massicciamente scalabili).

Negli ultimi anni per queste (e altre) ragioni, dopo avere lavorato per qualche lustro quasi sempre su JEE, mi sono spostato su tecnologie JavaScript, in particolare NodeJS.

La cosa che mi ha attirato, non è tanto il linguaggio (già conoscevo JavaScript, anche se, come molti, lo valutavo principalmente un “linguaggio per fare i casini sul browser”[2]) quanto la filosofia che sta sotto, che altro non è che l’unica cosa che è rimasta veramente costante nel mio lavoro dai tempi dell’università, cioè Unix[3].

E’ strano come qualcosa che, potremmo dire, “va di moda” o è addirittura considerato “hipster” (qualunque cosa voglia dire) affondi le radici concettuali in un passato remoto. Molto remoto, considerando i tempi dell’IT.

In sintesi, la Unix Philosophy dice [2]:

  • “Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.”
  • Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
  • Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

Tutto questo ha decretato negli anni il successo di Unix che ora troviamo, in varie forme, oltre che nella stragrande maggiorana dei server, anche in molti dispositivi embedded e in molti smartphone. Probabilmente, anche se non lo sapete o non sembra, pure nel vostro mediaplayer, nel vostro NAS, nella vostra TV, nel vostro router, nella vostra macchinetta del caffè [3]

Notate che la Unix Philosophy esprime dei principi architetturali generali, che NodeJS fa propri con l’implementazione del sistema dei moduli e con gli stream, una feature potentissima (presente per la verità anche in altri runtime e linguaggi) che permette di creare delle pipeline, stile appunto “pipe” unix. In pratica è possibile scrivere software sotto forma di moduli node e comporli alla necessità come se fossero comandi di una shell.

Un’altra cosa che oggi va molto in auge, è la programmazione funzionale. Anche qui, non esattamente un’idea nuova[4], ricordo benissimo quanto mi colpì il LISP quando lo studiai all’esame di linguaggi (erano gli anni 90). Qualche anno fa notai l’entusiasmo sulla programmazione funzionale proprio perché mi resi conto che in realtà non c’era nulla di nuovo. Incontravo persone che mi parlavano di “closure” come se fosse una nuova magia informatica, mentre è qualcosa che è stato pensato e implementato quasi 50 anni fa.

Per non parlare poi di MVC, oggi utilizzato come base concettuale di decine di framework JS, il cui paper originale risale al 1978 [4].

Quindi in pratica, dopo più di 3 lustri che faccio questo mestiere, la cosa di cui mi rendo conto è che…più o meno non ho imparato nulla. O meglio, ho capito che le cose che pensavo e conoscevo sin dall’inizio erano corrette, solo che non avevo l’esperienza e la sicurezza per esserne sicuro fino in fondo. Alla fine in sintesi sono arrivato a tecnologie “nuove” che però si basano su idee “vecchie”…ma giuste. Per questo, oggi mi diverto ancora a programmare come quando avevo 15 anni, e ancora oggi programmare è una delle cose che riesco a fare per ore senza stancarmi.

Poi ho vissuto abbastanza per vedere Microsoft mettere bash su Windows, e mi basta.

“Siediti lungo la riva del fiume e aspetta, prima o poi vedrai passare il cadavere del tuo nemico.” (proverbio cinese)

 

 

[1] Il titolo è estratto da “Il Gattopardo”, Giuseppe Tomasi di Lampedusa

[2] Cosa comunque vera, però oggi si possono fare casini molto più complicati.

[3] Una delle prime cose che ho dovuto fare per lavoro è cambiare la configurazione di un server usando ssh + vi

[4] LISP è del 1958

Facebook
Twitter
LinkedIn
Marco Piraccini

Marco Piraccini

Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/

Marco Piraccini

Marco Piraccini

Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica). Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/
Tutti gli articoli
Nello stesso numero
Loading...

Dinosauri e Jedi

Ere geologiche, dinosauri, programmatori Java e Cobol

I miei 20 anni con MokaByte

Anni passati molto velocemente anche se poi sono successe un sacco di cose.

MokaAmarcord

Nascita e crescita di una filosofia social quando non c'erano i social

Due decadi di MokaByte

I venti anni di MokaByte passati insieme ad Andrea Gini

20 anni di informatica sono tanti

Storia di una sistema che negli anni ha vissuto molteplici trasformazioni

Dalle portlet ai tablet

Un lungo viaggio, non ancora terminato

How I did it

Storia di Java vista dall'università

I tre moschettieri… venti anni dopo

Storia raccontata da uno dei fondatori della rivista

Dal Symantec Café all’intelligenza artificiale

Un punto di vista imprenditoriale sulla vita della rivista

Ottobre 1996 – come tutto ebbe inizio (e come poi è proseguito)

La storia di MokaByte dai primissimi vagiti ad oggi

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte