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
  • 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

Nel numero:

119 giugno
, anno 2007

Maven: Best practice applicate al processo di build e rilascio di progetti Java

V parte: un esempio pratico

Luca Vetti Tagliati
Luca Vetti Tagliati

Luca è un professionista esperto che ha ricoperto ruoli di alto profilo a Londra, New York e in Svizzera per banche di primo livello, tra cui UBS, Credit Suisse, Goldman Sachs, Lehman Brothers, Deutsche Bank e HSBC.

È pienamente qualificato per lavorare come Enterprise Architect, CTO e Technical Program Manager riuscendo a gestire i progetti con un'ottica multiruolo. La profonda comprensione della tecnologia, combinata con mirate strategie di gestione, ha permesso a Luca di gestire brillantemente programmi complessi con tempistiche aggressive.

La sua strategia di pensiero è un mix di visione e pragmatismo. Il suo background accademico, che include un dottorato di ricerca, è solidamente integrato da una vasta esperienza pratica, avendo completato tutti i suoi percorsi universitari mentre lavorava a tempo pieno nell'industria.

Negli ultimi anni, Luca ha riscoperto la sua passione per l'intelligenza artificiale, grazie alla sua posizione di Global Head for AI for Data Analytics and Innovations.

È anche autore di numerose pubblicazioni, tra cui

  • UML e l’ingegneria del software: dalla teoria alla pratica (2004)
  • Java Best Practices (2008)
  • Verso Java SE 8: Note per lo sviluppatore in Java 7 (2013)

Luca ha anche pubblicato numerosi articoli sull'IA e altri argomenti disponibili in riviste IT e sul web.

 

MokaByte

Maven: Best practice applicate al processo di build e rilascio di progetti Java

V parte: un esempio pratico

Picture of Luca Vetti Tagliati

Luca Vetti Tagliati

  • Questo articolo parla di: Java, Processi di sviluppo

I file pom.xml (Project Object Model, modello ad oggetti del progetto) contengono i meta-dati del progetto memorizzati secondo il formato xml. Abbiamo visto quanto sia importante una loro corretta configurazione. Vediamo in questo articolo una serie di utili esempi.

Introduzione

Come visto nel corso degli articoli precedenti, i file pom.xml (Project Object Model, modello ad oggetti del progetto) contengono i meta-dati del progetto memorizzati secondo il formato xml. Pertanto, è importante dar luogo ad una loro corretta configurazione, non solo per consentire una efficace gestione del progetto, ma anche per minimizzare l‘impiego di tempo destinato per la relativa manutenzione.
Gli esempi presentati in questo articolo sono stati selezionati per una serie di motivi. In primo luogo, corredando con la dimensione pratica le illustrazioni teoriche degli articoli precedenti, dovrebbero concorrere ad aumentare il grado di comprensione della struttura del file pom.xml, molto articolata e non sempre di immediata comprensione, soprattutto in relazione ad un utilizzo in progetti di medie-grandi dimensioni. Inoltre, dovrebbero evidenziare come, anche per progetti non semplici ed abbastanza articolati, non sia assolutamente necessario impostare tutti gli elementi di questo file ed anzi, come i vari file tendano ad essere piuttosto semplici, soprattutto dopo aver impostato correttamente il pom genitore. Infine, le varie configurazioni riportate dovrebbero prestarsi ad essere riutilizzate, con minime variazioni, in altri progetti, magari in quelli in cui lavorano i vari lettori che, attualmente, non fanno uso di Maven. In effetti, è assolutamente normale preparare i vari file POM per un primo progetto, è poi, con minime variazioni, riutilizzarli in progetti successivi.
I vari file pom riportati sono stati corredati con pochissime informazioni supplementari, questo perché la struttura del file è stata abbondantemente discussa nel corso degli articoli precedenti (cfr.: [7] e [8]). Pertanto si rimanda a questi per maggiori informazioni. Inoltre, sebbene i vari file pom riportati di seguito sono stati attinti da un progetto reale, alcune informazioni, come per esempio gli indirizzi URL dei vari server, sono state volontariamente alternate per ovvi motivi di sicurezza/privatezza. Infine, viste le dimensioni dei singoli file pom, per ovvi motivi di spazio, in questo articolo è stato possibile presentarne solo una piccola selezione.

Breve presentazione del progetto

I file pom presentati di seguito appartengono al progetto del sistema Sentinel disegnato per fornire servizi di sicurezza necessari alla gestione di sistemi software di medie grandi dimensioni costituiti da una rete di sistemi cooperanti.  I principali servizi forniti, sono:

  • autenticazione: il sistema verifica che l‘utente/sistema (subject) connesso sia veramente chi/cosa dichiara di essere;
  • autorizzazione: il sistema verifica che il profilo del subject precedentemente autenticato sia abilitato ad eseguire il determinato servizio (o insieme) richiesto;
  • data-privacy: il sistema verifica che il subject riceva o tenti di manipolare solo il sottoinsieme di dati di cui possiede l‘autorizzazione.

Figura 1 – Organizzazione del progetto in sotto-progetti. Le linee tratteggiate rappresentano relazioni di dipendenza. Come si può notare, la versione non è specificata in quando la relativa gestione è demandata a Maven.

Il progetto Sentinel è stato organizzato nei seguenti sotto-progetti mostrati in figura 1:

  • sentinel-security-dto: questo progetto contiene le classi DTO (Data Transfer Object). Questi non sono altro che normali POJO con specifico significato architetturale. In particolare sono utilizzati come parametri dell‘interfaccia business del sistema. Trattandosi di un sistema di sicurezza, in questo contesto i servizi business sono i quelli della sicurezza descritti poc‘anzi. Questi DTO possono essere utilizzati direttamente dai vari client (invocazione RMI) o per mezzo di serializzazioni/deserializzazioni XML/ Web Service (invocazioni: JMS, HTTP);
  • sentinel-client-api: la libreria prodotta da questo progetto incapsula i DTO del punto precedente e vi aggiunge una serie di servizi messi a disposizione dei sistemi client, come per esempio il marshalling e unmarshalling dei messaggi XML. Ciò permette ai vari client di interagire con il sistema Sentinel impostando una serie di oggetti Java (i DTO del punto 1) e quindi trasformarli da e verso XML attraverso i servizi offerti da questa libreria;
  • sentinel-admin-dto: è un progetto molto simile al primo (sentinel-security-dto), con l‘eccezione che i DTO contenuti in questo sono utilizzati dai servizi di amministrazione del sistema Sentinel. I due insiemi di DTO sono stati separati in quanto i client business del sistema (gli altri sistemi che necessitano di usufruire dei servizi di sicurezza), tipicamente, non sono assolutamente abilitati ad eseguire i servizi di amministrazione, riservati ai sistemi UI di Sentinel;
  • sentinel-admin-ui: contiene il codice necessario per l‘implementazione dell‘interfaccia grafica di Sentinel. La tecnologia utilizzata è AJAX, tramite il framework Echo2. Questo progetto, il cui obiettivo è consentire agli utenti abilitati di configurare Sentinel, utilizza gli stessi servizi di Sentinel per risolvere i propri requisiti di sicurezza. Sebbene Sentinel riesegua al proprio interno i vari controlli di sicurezza, questi sono utilizzati anche dalla GUI per migliorare l‘esperienza dell‘utente. Per esempio, servizi di cui l‘utente non possiede i necessari permessi non sono mostrati, i dati vengono pre-filtrati, etc. Questo progetto quindi necessita sia dei DTO amministrativi sia quelli relativi alla sicurezza.
  • sentinel-server: questo progetto non richiede ulteriori spiegazioni: si tratta dell‘implementazione server side del sistema di Sentinel. Come si può notare si tratta di un jar giacchà© è stato implementato utilizzando Spring. Qualora si fosse deciso di utilizzare un application server, sarebbe stato necessario dar luogo ad un ear file;
  • sentinel-security-endpoint: questo progetto include la servlet invocata dai sistemi client per accedere ai servizi Sentinel qualora il protocollo utilizzato sia HTTP (precisamente HTTPS);
  • sentinel-test-client: l‘obiettivo di questo progetto dovrebbe essere auto-esplicativo.

File pom genitore

Una caratteristica molto potente e unica di Maven, come visto abbondantemente nel corso degli articoli precedenti, è la possibilità  di relazionare tra loro i progetti con veri e propri legami di ereditarietà . Questo permette di definire tutta una serie di impostazioni comuni nel file pom genitore e di ereditarle automaticamente nei vari file pom discendenti. La conseguenza è che è possibile sia centralizzare la gestione di molte informazioni (non si tratta solo di evitare una serie di copy&paste, ma anche di assicurarsi che i vari sotto-progetti utilizzino determinate librerie, che le relative versioni sia quelle selezionate, ecc.), sia di semplificare la stesura dei vari pom per i sotto-progetti. Ciò fa sì che questi ultimi, per la maggior parte dei casi, si possano limitare ad accettare le impostazioni del pom genitore.
Progetti di dimensioni medio-grandi richiedono di predisporre il file system destinato ad ospitare i vari progetti secondo una determinata gerarchia di directory, in cui la prima, in questo caso denominata sentinel, è la radice dell‘intero progetto. Proprio in questa va memorizzato il file pom genitore. Da questa directory poi è possibile dar luogo una sub-directory per ogni sotto-progetto. Per esempio: …sentinelsentinel-client-api, nella cui root va memorizzato il relativo file pom.

Ed ecco un lungo listato: il pom genitore.

http://maven.apache.org/POM/4.0.0" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation= "http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/maven-v4_0_0.xsd">
 4.0.0
 com.mb.security.sentinel
 sentinel
 1.4-SNAPSHOT
 Sentinel Security System
 http://mbit0164570.develop.mb.net:8085/display/security/home
 pom
 
  
  vettitlu
  Luca Vetti Tagliati
  LucaVT@gmail.com
  
   Project Lead
   Lead Architect
   Senior Developer
  

  
  
  
  pulitig
  Giovanni Puliti
  gpuliti@mokabyte.it
  
   Project Manager
   Senior Developer
  

  
  
  
  saliolaf
  Francesco Saliola
  fsaliola@mokabyte.it
  
   Relationship Manager
  

  
  

 
 
  scm:svn:https://subversion.mb.it/svn/security/trunk/sentinel/
  
  scm:svn:https://subversion.mb.it/svn/security/trunk/sentinel/
  

  https://subversion.mb.it/svn/security/trunk/sentinel/
 
 
  
  
   org.apache.maven.plugins
   maven-site-plugin
  

  
   org.apache.maven.plugins
   maven-jxr-plugin
  

  
   org.apache.maven.plugins
   maven-surefire-report-plugin
  

  
   org.apache.maven.plugins
   maven-clover-plugin
  

  
   org.apache.maven.plugins
   maven-project-info-reports-plugin
   
   
    
    index
    dependencies
    project-team
    scm
    

   

   

  

  
   org.apache.maven.plugins
   maven-pmd-plugin
   
   true
   utf-8
   100
   1.5
   

  

  
   org.apache.maven.plugins
   maven-javadoc-plugin
  

  
   maven-assembly-plugin
   
   
     ${basedir}/src/assemble/devDeploy.xml
   

   ${artifactId}
   ${basedir}/target/release
   false
   

  

  
   maven-release-plugin
   
   https://subversion.mb.it/svn/security/tags
   

  

  

 
 
  constraint-lib
  security-dto
  security-endpoint
  admin-dto
  admin-ui
  test-client
  client-api
  server
  system-test
  security-infrastructure
 
 
  
  
  junit
  junit
  3.8.1
  test
  
  
  
  com.mb.pd.jakarta-log4j
  log4j
  1.2.13
  jar
  

 
 
  
  security-repo
  http://mb0935dap.it.mb.it:8500/mavenRepo
  
   true
  

  

  
  central
  http://hammer.mb.it:5201/runtimeRepo
  default
  
   false
  

  

  
  xtools-hufs
  http://hammer.mb.it:5201/hufsRepo
  
   false
  

  
   never
  

  

 
 
  
  security-repo
  http://mbit0935dap.ldn.mb.it:8500/mavenRepo
  
   true
  

  

  
  central
  xtools-plugins
  http://hammer.mb.it:5201/runtimeRepo
  
   false
  

  
   never
  

  

  
  xtools-hufs
  http://hammer.mb.it:5201/hufsRepo
  
   false
  

  

 
 
 
  
  
   org.apache.maven.plugins
   maven-compiler-plugin
   
   1.5
   1.5
   

  

  
   org.apache.maven.plugins
   maven-surefire-plugin
   2.1.3
   
   once
   false
   -Xmx512M
   
     **/*Test.java
   

   

  

  
   org.apache.maven.plugins
   maven-clover-plugin
   
   
  
   com.mb.pkgs.SPP
   build-tools
   1.0-SNAPSHOT
  

   
   
   clover-teamedition.licence
   1.5
   true
   
   
   
    pre-site
    
    instrument
    aggregate
    

   

   

  
  
   org.apache.maven.plugins
   maven-deploy-plugin
   
   file:///home/sppdev/webserver/htdocs/mavenRepo
   

  

  
 
 
  
  
  security-ci-repo
  Security Continuous Integration Repository
  file:///home/sppdev/webserver/htdocs/mavenRepo
  
  
  
  website
  file:///home/sppdev/webserver/htdocs/Sentinel
  

 
 
 

Il file riportato nel precedente listatino non dovrebbe presentare novità  rispetto a quanto illustrato nel corso degli articoli precedenti. Pertanto, per eventuali delucidazioni si rimanda ai precedenti articoli di questa serie ([7] e [8]). Ciò nonostante, è possibile evidenziare alcuni interessanti elementi. In primo luogo, è possibile notare che si tratta di un progetto “genitore” in quanto il campo packaging è impostato al valore POM. Inoltre, tutta una serie di impostazioni come quelle relative al scm (software configuation management, software per la gestione della configurazione), ai vari repository, alla gestione delle distribuzioni (distribution management), etc. sono impostate nel solo pom genitore ed ereditate, così come definite, da tutti i file pom discendenti. Mentre per quanto attiene la sezione build, come lecito attendersi, le impostazioni riportate nel file pom genitore tendono a subire alcune variazioni necessarie alla natura del relativo progetto.

Sotto-progetto admin-DTO

Questo progetto è destinato alla produzione della libreria (file JAR) con incluse le classi necessarie all‘interfaccia amministrativa del sistema Sentinel.

Ecco il file pom del sottoprogetto admin-dto

 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
     http://maven.apache.org/maven-v4_0_0.xsd">
 4.0.0
 
 
  com.mb.security.sentinel
  Sentinel
  1.4-SNAPSHOT
 
 
 sentinel-admin-dto
 Admin DTO
 jar
 http://mbit0164570.develop.mb.net:8085/display/security/home
 
  This project includes the DTOs (POJOs) used by the Sentinel architecture.
  They represent the object graphs used in the admin services
  exposed by the system itself.
 
 
  
  com.mb.pd.jakarta-commons
  commons-lang
  2.1
  test
  

 
 
  
  
   org.apache.maven.plugins
   maven-jar-plugin
   
   
     Build test-jar
    
    test-jar
    

   

   

  

  

 

Come si può facilmente notare, il file pom presentato nel listatino precedente è piuttosto semplice, questo sia per via delle limitate esigenze intrinseche del progetto (si tratta esclusivamente di una serie di classi POJO), sia per la presenza del file pom generatore. Questo è dichiarato nella sezione parent definita nelle primissime righe del file.

Sotto-progetto server

Questo progetto è destinato alla produzione del lato server del sistema Sentinel. Come è possibile evincere dalle impostazioni relative alle risorse, alle dipendenze, etc. la tecnologia selezionata è il framework Spring con Hibernate utilizzato per il mapping con il database.

Ecco il file pom del progetto server side.

 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
     http://maven.apache.org/maven-v4_0_0.xsd">
 4.0.0
 
 
  com.mb.security.sentinel
  sentinel
  1.4-SNAPSHOT
 
 
 sentinel-server
 Sentinel Server
 jar
  1.4-SNAPSHOT
 http://mbit0164570.develop.mb.net:8085/display/security/home
 
  
  
   org.apache.maven.plugins
   maven-jar-plugin
   
   
    Build test-jar
    
    test-jar
    

   

   

  

  
  
  
   src/main/spring-config
   
   **/*.xml
   

  

  
   src/main/hibernate
   
   **/*.xml
   

  

  
   src/main/resources
   
   **/*
   

  

  
   src/main/script
   
   **/*.sql
   

  

  

 
 
  
  com.mb.tp.JavaMail
  mail
  1.3.2
  

  
  com.mb.pd.mx4j.lib
  mx4j
  3.0.1
  

  
  com.mb.pd.mx4j.lib
  mx4j-impl
  3.0.1
  

  
  com.mb.pd.mx4j.lib
  mx4j-jmx
  3.0.1
  

  
  com.mb.pd.mx4j.lib
  mx4j-tools
  3.0.1
  

  
  com.mb.pd.springframework
  spring
  1.2.6
  

  
  com.mb.pd.springframework
  spring-mock
  1.2.6
  test
  

  
  com.mb.pd.hibernate
  hibernate3
  3.1.3
  

  
  com.mb.pd.hibernate
  hibernate-tools
  3.2.0.beta6
  

  
  com.mb.pd.jakarta-commons
  commons-logging
  1.0.4
  

  
  com.mb.pd.jakarta-commons
  commons-dbcp
  1.2.1
  

  
  com.mb.pd.jakarta-commons
  commons-pool
  1.2
  

  
  com.mb.pd.jakarta-commons
  commons-beanutils
  1.7.0
  

  
  com.mb.pd.jakarta-commons
  commons-collections
  3.1
  

  
  com.mb.pd.hibernate.lib
  jta
  3.1.3
  

  
  com.b.pd.hibernate.lib
  antlr
  2.7.6rc1
  

  
  com.mb.pd.hibernate.lib
  asm
  3.1.3
  

  
  com.mb.pd.hibernate.lib
  cglib
  2.1.3
  

  
  com.mb.pd.hibernate.lib
  dom4j
  1.6.1
  

  
  com.mb.pd.hibernate.lib
  ehcache
  1.1
  

  
  com.mb.pd.easymock
  easymock
  2.2
  test
  

  
  com.mb.tp.oracle
  ojdbc14
  10.2.0.2.0-32bit
  
  
  ${project.groupId}
  sentinel-constraint-lib
  ${project.version}
  

  
  ${project.groupId}
  sentinel-security-dto
  ${project.version}
  

  
  ${project.groupId}
  sentinel-admin-dto
  ${project.version}
  

  
  ${project.groupId}
   security-infrastructure
  ${project.version}
  
 

Conclusioni

In questo articolo abbiamo presentato un esempio pratico di utilizzo di Maven al fine di fornire una proiezione operativa ai due precedenti articoli riguardanti il file pom.xml. In particolare, si è deciso di utilizzare i file pom preparati per un progetto commerciale denominato Sentinel, il cui scopo è quello di fornire una serie di servizi di sicurezza per sistemi di dimensioni medio-grandi.
Per ovvie esigenze di spazio, è stato possibile riportare solo una minima selezione di questi file. In particolare, sono stati selezionati il file pom genitore, quello del sotto progetto relativo ai DTO di amministrazione e quello relativo all‘implementazione server-side. Questi listati, lunghi ma esemplificativi, sono stati scelti per mostrare una serie di importanti caratteristiche di Maven, come per esempio la relazione di ereditarietà , le dipendenze tra file pom, la semplicità  con cui è possibile inserire plug-in e così via.
La lettura di questo articolo dovrebbe aver facilitato la comprensione sia della struttura dei file pom, sia del loro funzionamento. Inoltre, dovrebbe aver evidenziato come, sebbene la struttura del file pom sia piuttosto articolata e non sempre di facile comprensione, non è assolutamente necessario impostarne tutti gli elementi; anzi, in progetti reali spesso è sufficiente utilizzare un sotto-insieme piuttosto limitato. Pertanto la complessità  del file pom è un‘assicurazione di completezza, è l‘ereditarietà  di un ampio grado di maturità  e non una limitazione di utilizzo. Infine, i vari file pom rappresentano un‘ottima base di partenza per l‘adozione di Maven per progetti attualmente sprovvisti di tale risorsa.


Riferimenti

[1] Giovanni Puliti, “Ant, La Formica Operosa che beve Caffè”, Mokabyte 112 e 113

[2] Luca Vetti Tagliati, “Java Quality Programming”, Mokabyte

[3] Maven
http://maven.apache.org/

[4] Jelly
http://jakarta.apache.org/commons/jelly/

[5] Vincent Massol – Jason Van Zyl, “Better Builds With Maven”, Mergere
http://www.mergere.com/m2book_download.jsp

[6] Luca Vetti Tagliati “Maven: “Best practise applicate al processo di build e rilascio di progetti Java. Parte: I”, Mokabyte 114, Gennaio 2007

[7] Luca Vetti Tagliati “Maven: “Best practise applicate al processo di build e rilascio di progetti Java. Parte II”, Mokabyte 115, Febbraio 2007

[8] Luca Vetti Tagliati “Maven: “Best practise applicate al processo di build e rilascio di progetti Java. Parte III”, Mokabyte 117, April 2007

[9] Luca Vetti Tagliati “Maven: “Best practise applicate al processo di build e rilascio di progetti Java. Parte IV”, Mokabyte 118, Maggio 2007

[10] Maven Enforcer Plugin
http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireOS.html

Luca Vetti Tagliati
Luca Vetti Tagliati

Luca è un professionista esperto che ha ricoperto ruoli di alto profilo a Londra, New York e in Svizzera per banche di primo livello, tra cui UBS, Credit Suisse, Goldman Sachs, Lehman Brothers, Deutsche Bank e HSBC.

È pienamente qualificato per lavorare come Enterprise Architect, CTO e Technical Program Manager riuscendo a gestire i progetti con un'ottica multiruolo. La profonda comprensione della tecnologia, combinata con mirate strategie di gestione, ha permesso a Luca di gestire brillantemente programmi complessi con tempistiche aggressive.

La sua strategia di pensiero è un mix di visione e pragmatismo. Il suo background accademico, che include un dottorato di ricerca, è solidamente integrato da una vasta esperienza pratica, avendo completato tutti i suoi percorsi universitari mentre lavorava a tempo pieno nell'industria.

Negli ultimi anni, Luca ha riscoperto la sua passione per l'intelligenza artificiale, grazie alla sua posizione di Global Head for AI for Data Analytics and Innovations.

È anche autore di numerose pubblicazioni, tra cui

  • UML e l’ingegneria del software: dalla teoria alla pratica (2004)
  • Java Best Practices (2008)
  • Verso Java SE 8: Note per lo sviluppatore in Java 7 (2013)

Luca ha anche pubblicato numerosi articoli sull'IA e altri argomenti disponibili in riviste IT e sul web.

 

Facebook
Twitter
LinkedIn
Luca Vetti Tagliati
Luca Vetti Tagliati

Luca è un professionista esperto che ha ricoperto ruoli di alto profilo a Londra, New York e in Svizzera per banche di primo livello, tra cui UBS, Credit Suisse, Goldman Sachs, Lehman Brothers, Deutsche Bank e HSBC.

È pienamente qualificato per lavorare come Enterprise Architect, CTO e Technical Program Manager riuscendo a gestire i progetti con un'ottica multiruolo. La profonda comprensione della tecnologia, combinata con mirate strategie di gestione, ha permesso a Luca di gestire brillantemente programmi complessi con tempistiche aggressive.

La sua strategia di pensiero è un mix di visione e pragmatismo. Il suo background accademico, che include un dottorato di ricerca, è solidamente integrato da una vasta esperienza pratica, avendo completato tutti i suoi percorsi universitari mentre lavorava a tempo pieno nell'industria.

Negli ultimi anni, Luca ha riscoperto la sua passione per l'intelligenza artificiale, grazie alla sua posizione di Global Head for AI for Data Analytics and Innovations.

È anche autore di numerose pubblicazioni, tra cui

  • UML e l’ingegneria del software: dalla teoria alla pratica (2004)
  • Java Best Practices (2008)
  • Verso Java SE 8: Note per lo sviluppatore in Java 7 (2013)

Luca ha anche pubblicato numerosi articoli sull'IA e altri argomenti disponibili in riviste IT e sul web.

 

Picture of Luca Vetti Tagliati

Luca Vetti Tagliati

Luca è un professionista esperto che ha ricoperto ruoli di alto profilo a Londra, New York e in Svizzera per banche di primo livello, tra cui UBS, Credit Suisse, Goldman Sachs, Lehman Brothers, Deutsche Bank e HSBC. È pienamente qualificato per lavorare come Enterprise Architect, CTO e Technical Program Manager riuscendo a gestire i progetti con un'ottica multiruolo. La profonda comprensione della tecnologia, combinata con mirate strategie di gestione, ha permesso a Luca di gestire brillantemente programmi complessi con tempistiche aggressive. La sua strategia di pensiero è un mix di visione e pragmatismo. Il suo background accademico, che include un dottorato di ricerca, è solidamente integrato da una vasta esperienza pratica, avendo completato tutti i suoi percorsi universitari mentre lavorava a tempo pieno nell'industria. Negli ultimi anni, Luca ha riscoperto la sua passione per l'intelligenza artificiale, grazie alla sua posizione di Global Head for AI for Data Analytics and Innovations. È anche autore di numerose pubblicazioni, tra cui
  • UML e l’ingegneria del software: dalla teoria alla pratica (2004)
  • Java Best Practices (2008)
  • Verso Java SE 8: Note per lo sviluppatore in Java 7 (2013)
Luca ha anche pubblicato numerosi articoli sull'IA e altri argomenti disponibili in riviste IT e sul web.  
Tutti gli articoli
Nello stesso numero
Loading...

Portlet API

II parte: la programmazione delle portlet

UML va a teatro

e la drammaturgia diventa Object Oriented

WEKA: l‘approccio intelligente all‘esplorazione dei dati

IV parte: distribuire il processo di classificazione

Semantic Web

I parte: Introduzione a RDF, principi e Data Model

JavaOne 2007

Reportage dalla JavaOne Conference 2007

Spring e integrazione

III parte: Integrazione EJB

Flex 2 e Java per sviluppare Rich Internet Application

Le chiamate remote con Flex 2 SDK

Ruby

IV parte: Rails... non solo Web Services

Nella stessa serie
Loading...

Maven: Best practice applicate al processo di build e rilascio di progetti Java

VII parte: Maven e Ant

Maven: Best practice applicate al processo di build e rilascio di progetti Java

VI parte: i Repository Server

Maven: Best practise applicate al processo di build e rilascio di progetti Java

IV parte: Approfondimenti sul POM

Maven: Best practice applicate al processo di build e rilascio di progetti Java

III parte: POM.xml, un componente centrale

Maven: best practices applicate al processo di build e rilascio di progetti Java

II parte: l‘archetipo

Maven: best practices per il processo di build e di rilascio dei progetti in Java

I parte: panoramica e filosofia d‘uso

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