Codemotion Rome torna dal 17 al 19 Marzo!

Come nelle edizioni passate sarà una grande festa all'insegna delle ultime novità in ambito IT.

La Call for Papers è aperta fino al 31 gennaio, se hai cose da raccontare al pubblico di Codemotion fai la tua application!
http://speaker.codemotionworld.com/c4p.php

I biglietti sono ora disponibili in Early Bird, approfitta ora del prezzo ridotto!
Per questa edizione il codice sconto per le community saranno attivate dal Regular Ticket.
http://rome2016.codemotionworld.com/

Non mancare alla festa! Riserva il tuo posto da fin da ora!

Laboratorio su Android in collaborazione con il GDG Roma

Con la collaborazione del GDG Roma, stiamo preparando una esercitazione su Android.Affinché l'esercitazione sia proficua, sarebbe meglio se, chi vuole partecipare, possa prendere confidenza con alcuni strumenti un po' prima.
Gli strumenti che si consiglia di installare e farci qualche prova sono:

• Android Studio, l'IDE ufficiale per Android, basato su IntelliJ (consigliatissimo per lo sviluppo Java anche non Android);
• Gradle, lo strumento di build, alternativo a Maven, che viene usato per compilare i progetti Android;
• Android SDK, è compreso in Android Studio, ma anche con quello è meglio fare qualche prova prima.

L'evento si trova qui:

https://metooo.io/e/laboratorio-android

PrimeFaces come API e MaterialPrime

Nell'ultimo incontro del JUG (05 Nov 2015) siamo stati ospitati da Oracle Italia che, tramite la preziosa collaborazione di Nino Guarnacci, ci ha aperto le porte alla propria eccezionale sala conferenze.

Forse colpevole l'ora o la zona poco favorevole, è stato un peccato che l'affluenza effettiva fosse ridotta, perché il tema è stato a mio avviso molto interessante, pratico e presentato con grande efficacia da Francesco Strazzullo.

Per chi non ha potuto esserci eccovi un breve riassunto.

Introduzioni

In attesa dei ritardatari abbiamo approfittato per guardarci in faccia e fare le presentazioni, in particolare Strazzullo ci ha raccontato della sua attività di sviluppatore java oramai convertito in front-end puro e quindi con una buona esperienza di javascript e del suo ecosistema. Nell'azienda di Ancona di cui è parte, e-xtrategy, si occupa infatti di realizzare design front-end per i clienti, collabora da qualche tempo con il sito di articoli online cosenonjaviste.it e fa parte del collettivo di sviluppatori delle Marche (dev.marche.it).

Infine, cosa essenziale al nostro incontro, Francesco è contributor del progetto PrimeFaces Extensions e in particolare uno degli sviluppatori di MaterialPrime, una libreria di componenti JSF, basata su PrimeFaces, che realizza il design Material di Google.

PrimeFaces, ci racconta Francesco, è la libreria di fatto più utilizzata ad oggi per la realizzazione di componenti JSF, avendo da tempo superato le alternative RichFaces e IceFaces.

La libreria, PrimeFaces e MaterialPrime

In breve, PrimeFaces è una libreria che rende disponibile tramite componenti JSF le funzionalità della onnipresente jQuery. L'utilizzo è gratuito, a patto di condividere sul repository ufficiale ogni componente personalizzato dall'utente, in modo da arricchire sempre più i componenti disponibili a chi inizia.

Altra caratteristica di PrimeFaces, come anticipa lo speaker, è che si presta bene per la creazione di componenti personalizzati, utilizzando il framework e le sue API.

Ogni componente è suddiviso in una parte client javascript, che si occupa dell'interazione lato browser, e una server, in java, divisa in un componente che esegue la logica di dominio e un renderer per la generazione di html.

Quest'ultimo aspetto purtroppo rimane poco sofisticato: il markup va scritto tramite stringhe, benché io abbia intravisto delle API che semplificano la generazione di tag e attributi.

A questo punto la presentazione passa ad un esempio dettagliato di come scrivere e integrare le diverse parti di un componente personalizzato. L'elemento chiave è il riutilizzo delle funzionalità previste dalla libreria, che garantiscono diverse cose essenziali: avere a disposizione un sistema di eventi, attributi, chiamate ajax, nonché la gestione dello stato lato server. Inoltre questo modello garantisce un'uniformità nello sviluppo e l'utilizzo, in modo che gli utilizzatori finali della libreria si trovino a proprio agio anche utilizzando componenti nuovi.

Personalmente trovo che il pregio fondamentale di questo sistema sia la possibilità di intervenire sul componente da due fronti, lavorando in java sul back-end e direttamente in javascript sul front-end. In questo modo è molto semplice integrare librerie di entrambi gli ecosistemi, in modo essenzialmente trasparente.

Tanto per chiarire questo punto, Strazzullo ci spiega come MaterialPrime non faccia altro che richiamare internamente alla parte client dei suoi componenti una libreria javascript di nome materializecss, la quale si occupa di realizzare la parte grafica e la logica secondo le linee guida dello stile di Google.

Difetti

Ovviamente non ci sono solo lati positivi, ma anche qualche pecca. In particolare Francesco segnala che il codice del framework è poco documentato essendo essenzialmente uno strumento interno. Per lo stesso motivo, ad ogni rilascio di qualche aggiornamento c'è sempre il rischio che vengano introdotte modifiche non compatibili, da cui la necessità di eseguire dei controlli di regressione ogni qualvolta si aggiorna la versione su cui basare i propri componenti.

Conclusioni

Devo dire che data la mia maggiore esperienza con librerie più recenti, quali GWT e Vaadin, sono rimasto piacevolmente sorpreso di vedere come una tecnologia che a causa di un pregiudizio avevo considerato sorpassata fornisca in realtà una buona flessibilità e una serie di strumenti validi per costruire interfacce utente di tutto rispetto. In effetti MaterialPrime dimostra questo: che JSF non deve essere per forza associata ad una grafica scadente o ad un design "da svecchiare".

Questa mi sembra un'ottima notizia, soprattutto per tutti gli sviluppatori che, lavorando su prodotti legacy o con lo standard JEE, possono aver immaginato di non avere speranze per quanto riguarda la possibilità di realizzare un front-end al pari con gli strumenti più attuali sul panorama.

Grazie ancora a Francesco Strazzullo e al suo collega Michele Focanti che ci hanno raggiunto da Ancona per condividere con noi la loro esperienza.

Ivano Pagano

Ecco il link con le slide della presentazione

http://slides.com/francescostrazzullo/jug-roma-primefaces-as-an-api

Per ulteriori informazioni vi rimando al sito di Francesco e al progetto su github

http://www.francescostrazzullo.info/

http://www.materialprime.com/

Prossimo incontro: DevOps for Dev

A meno che tu non stia salvando il mondo, non sprecare il tuo tempo installando cose, vedendo gente, facendo altre cose.

https://metooo.io/e/dev-ops

Infinispan: Distributed Cross-Application Caching il 30 settembre

Quando: 30 settembre
Dove: Red Hat Roma - Via Andrea Doria, 41M scala B Metro A Ottaviano o Cipro.
Per iscriversi: http://jugevents.org/jugevents/event/show.html?id=56448

Programma

18:30 – 19:00

Speaker: Tristan Tarrant

Title: Infinispan: Distributed Cross-Application Caching
Infinispan is a Java library for embedded caching. It is also a server for remote caching. It can run as a local cache. It can also scale to hundreds of distributed nodes. You can use it to store, retrieve, query, compute and listen to changes in your data.

In this talk Tristan will provide an overview of the variety of uses to which you can put Infinispan in your applications, from simple Java applications, to cross-language, cross-platform application ecosystems.

19:00 – 19:30
Speaker: Gustavo Fernandes
Title: Infinispan and Apache integrations
Besides being Apache licensed, Infinispan also integrates nicely with some important Apache projects, such as Lucene, Spark and Hadoop. This talk will walk through each one with use cases and code samples.

19:30 – 20:00
Speaker: Adrian Nistor
Title: Querying Infinispan, beyond the Map API

Infinispan is a transactional, distributed, in-memory key/value store mainly exposing the ubiquitous Map-Like API. But the key/value view is almost never enough. Infinispan provides powerful search APIs which allow you to perform complex on-demand or continuous searches on your rich domain model. A tight integration with Hibernate Search and Apache Lucene enables fast indexing and searching for your Java objects or your platform-neutral data encoded in Google’s Protocol Buffers format. It provides a simple and expressive native query DSL but can also run Lucene queries equally well.

Basi dati non relazionali e transazioni

Autore: Davide Lorenzo Marino

Oggi ci sono molti database nosql che gestiscono sia transazioni ACID, sia foreign key e quindi integrità referenziali.
Ad esempio:

• OrientDb
• Neo4j
• Titan
• ArangoDb (solo transazioni ACID)
• Blazegraph
• FoundationDb (transazioni ACID, con foreign key solo sul layer SQL, si tratta di un db multimodello)

Più in generale direi che i database basati su un modello a grafo generalmente supportano le foreign key (in fondo sono disegnati per gestire le relazioni fra nodi) e anche alcuni nosql multi modello.

Per il modo in cui sono implementati internamente quasi sicuramente nessun document db,  key value db e wide column db dovrebbe avere le foreign key. Alcuni di questi però supportano le transazioni.

Per quel che riguarda i constraints non legati a foreign key (lunghezza del campo, tipo del campo, non nullabilità) credo che i db nosql ne siano generalmente provvisti se permettono di definire uno schema base (eventualmente espandibile con altre colonne). Sicuramente OrientDb che ho avuto modo di studiare un pochino ne è provvisto ed anzi mi sembra che abbia addirittura più constraint dei db relazionali classici (ad esempio ha controlli sulla lunghezza minima di un campo che in molti db relazionali come mysql può essere gestita solo con un trigger).

Sicuramente una grande differenza fra db relazionali classici e db nosql è che i db nosql sono schema less, mentre un db relazionale puro non lo è.
Questo garantisce una maggiore flessibilità perché aggiungere una colonna su una tabella che ha molti milioni di record può essere veramente pesante e non gestibile in un ambiente che non ammette tempi di manutenzione elevati.

Un'altra grande differenza non citata (almeno mi pare) nei precedenti interventi è che i db nosql utilizzano dialetti personalizzati per l'accesso ai dati. Questo vuol dire che migrare da un db all'altro può essere molto complesso, mentre i db relazionali, pur con piccole differenze, utilizzano tutti l'SQL per l'accesso ai dati. Alcuni dei dialetti NoSql sono abbastanza semplici, altri decisamente più complessi, soprattutto nei db a grafo e riuscire a padroneggiare tutti gli aspetti sulle possibili query di estrazione può essere molto difficile.

Ad ogni modo tieni conto che i db NoSql sono molto diversi tra di loro. Alcuni hanno delle caratteristiche, altri ne hanno delle differenti. Esistono per esempio alcuni db NoSql che non permettono la replicazione su più nodi (ad esempio MemCached) e quindi non si può nemmeno affermare che i db NoSql scalano meglio dei db relazionali (anche se nella stragrande maggioranza dei casi questo è vero).

A chi interessasse approfondire potete trovare informazioni interessanti su questo sito: http://db-engines.com/en/

Video su Haskell ed Entando

---