Domande ai relatori

 

Sacrifical Architecture by Francesco Strazzullo

In quale contesto credi sia utile questo tipo di architettura?
Secondo me un modo di capire se è giusto utilizzare questo tipo di approccio è dividere i problemi in Complicati e Complessi. Un sistema complicato è un sistema in cui ci si affida ad esperti perché si è certi che la soluzione esiste anche se ci è oscura. Invece un sistema in un sistema complesso non è possibile prevederne con certezza lo sviluppo. In questi casi abbiamo sicuramente bisogno di cambiare direzione al volo e l'architettura sacrificale ci può aiutare in questo senso
Quanto è applicabile la SA ad un progetto e codice esistenti?
Sinceramente non mi è mai capitato, ma credo sia fattibile. Un esempio potrebbe essere quello di considerare tutta la base di codice "legacy" come uno shared module. Attorno a questo si possono creare dei nuovi moduli e spostare di volta in volta il codice all'interno degli stessi.

React vs Angular2 by Alessandro Mantione

Cosa mi potreste dire delle performance di angular2 e react in rendering e re-rendering?
Di react che e' eccellente: e' costruito in modo da fare il re-rendering modificando il minimo indispensabile del DOM gia' presente sulla pagina (ed e' uno dei suoi punti di forza). Facebook inoltre sta lavorando per fare avvenire il rendering in "fibers", in modo asincrono ed incrementale, in modo che eventuali update "massivi" del DOM non blocchino l'event loop troppo a lungo (il rendering "pesante" verrebbe distribuito su piu' frame). L'idea e' che non dovrebbe mai piu' succedere di "perdere" un frame a causa di un re-render troppo grosso.
Per quello che so tecnicamente di angular, la sua performance rispetto a quella di react e' penalizzata da due cose:
[1] la change detection, che e' agevolata dalle "zones" ma e' comunque presente
[2] dubito che il suo modello di "DOM update" sia altrettanto mirato di quello di react ma non ne sono sicuro

Anche in angular 2, come in react, si possono usare valori immutabili per agevolare la change detection.

Detto questo la performance di angular 2 e' sicuramente piu' che ragionevole per ogni caso "comune". Se cercate di fare tabelle con 100k rows dovrete fare attenzione in ogni caso, indipendentemente dal framework...
Se react gestisce "solamente" le view, è possibile integrare react in un app angular, quindi farli coesistere ?
Due risposte: tecnica e di buon senso.

[1] Tecnicamente react ha bisogno di un nodo DOM su cui agganciarsi per fare render di un component. Immagino che angular permetta di accedere direttamente ai nodi del DOM che gestisce, quindi tecnicamente credo che si possa fare.
[2] Buon senso: ha veramente senso pagare il prezzo di entrambi i framework (download size)? Ha senso lavorare con due framework cosi' complessi nella stessa application (problemi di skill del team e complessita' del codice)? Io probabilmente lo farei SOLO se volessi migrare da angular a react in modo incrementale (o vice-versa), un po' come passare da angular 1 al 2.
React è pronto per l'utilizzo in produzione nel contesto italiano?
Si, e' pronto: ha un buon ecosistema ed e' ben documentato. Non vedo in che modo il contensto italiano debba essere diverso da quello mondiale :-)
Ciao, il data binding è uno dei punti di forza di Angular JS ma alcune persone lo ritengono bello tanto quanto pericoloso. Posso avere un parere di entrambi su questo argomento?
Distinguo 2 way da 1 way.
Secondo me il problema del 2 way data binding e' che al crescere della complessita' dell'applicazione cominciano a verificarsi casi in cui un update all view causa un update al model che a sua volta si deve riflettere su un altro component della view, diventa difficile ragionare su cause ed effetti, ed in pratica il comportamento dinamico del codice diventa piu' difficile da comprendere e manutenere (mentre lo scopo del data binding sarebbe ren derlo piu' semplice).
Per il 1 way data binding il problema e' normalmente legato alla "magia" che fa si' che avvenga la change detection e quindi si inneschino gli "effetti" del binding (update della view o altro).
Queste "magie" sono delle astrazioni, ma le implementazioni sono tali per cui invariabilmente si ha una "leaky abstraction".
Quando l'astrazione "salta" e si hanno problemi o di performance, o di "glitch" (un singolo update ne causa due nel tempo, di cui uno "spurio", non credo avvenga in nel data binding di angular ma e' normale con RxJS).

Lo "zen del Python" dice che "explicit is better than implicit".
In react il "data binding" si innesca in modo esplicito: avviene al render (e al setState, che triggera un render), e non ci sono mai sorprese (non su questo, almeno!).
In angular e' implicito: fino a che non ci sono stranezze tutto e' piu' semplice, ma quando ci sono bisogna comunque capire fino in fondo come funziona il framework e aggiungere workaround. (nota: il "binding" e' esplicito anche in angular, e' quando *agisce* che e' implicito!!!).
React è ricco di libreire e componenti quanto lo era angular1?
Piu' o meno di angular 1 non lo so... ma e' molto, molto ricco, al punto da innescare la "javascript fatigue" :-) In breve: ci sono piu' collezioni di componenti di quanti uno sviluppatore ne possa imparare a conoscere a fondo in tempi ragionevoli.

Migrazione ad Angular2 by Alessandro Giorgetti

Typescript ci regala qualcosa. ma ci fa perdere una programmazione funzionale. gli stessi pasticci di angular1 nn li faremo anche nel 2 forzando una programmazione oop?
TypeScript non ti obbliga ad abbandonare la programmazione funzionale, è un superset di JavaScript che aggiunge feature altrimenti mancanti (come il controllo di tipo) ma non essenziali. Decidi tu sviluppatore a che 'livello' adottare TypeScript. Il concetto di classe non viene introdotto nel linguaggio da TypeScript, è proprio dello standard ES2015 di JavaScript. Adottate uno stile funzionale o OOP è preferenza dello sviluppatore. Angular 2 (ma in generale qualsiasi framework che utilizzi Inversion of Control o Dependency Injection) utilizza stile OOP per mera convenienza: la strutturazione / modularità dell'applicazione, con tutti i vantaggi che ne conseguono. Quanto ai 'pasticci' se ne possono fare con qualsiasi linguaggio e qualsiasi framework, è tutta una questione di competenza e disciplina del programmatore.
Allo stato attuale della community, in quali casi consigli di partire con un progetto nuovo in Angular2? In quali altri è preferibile scrivere in Ajs1 e valutare la migrazione successiva?
Partire in Angular 1 con l'obiettivo di migrare poi è 'da pazzi'. La migrazione è una procedura pensata per colo che vogliano aggiornare le proprie applicazioni già pensate per Angular 1. Valuta le dimensioni del progetto, se e per quanto tempo andrà manutenuto ed il time to market. Con Angular 1 sicuramente la tua produttività sarà più alta (maggiori competenze, più librerie di terze parti, etc...). Se il progetto è 'piccolo' e necessiterà di poca manutenzione nel futuro probabilmente utilizzare Angular 1 ti garantirà risultati immediati. Tuttavia potrebbe anche essere utilizzato come palestra per Angular 2. Tutto dipende da criticità del progetto e da quanto tempo / risorse si hanno a disposizione.
For a big project is it worthy migrating the project with risk of breaking at every step or should we just start from the bottom and rewrite everything?
"It Depends" like the DDD community is used to say. Rewriting from the ground up has one big advantage (the solution will be specifically designed with Angular 2 in mind, no compromises) and some disadvantages (two codebases to maintain, an excessive slowdown in the development of the old solution, more resources required). The migration process will be slow (it can take months if done correctly and the project is very big), but you will never stop the project development and you will keep delivering value to the customers. You'll have to face some critical points but nothing that cannot be fixed (or rewritten). If, along the way, you'll decide that the migration process will just take too much or is not doable, you will not throw away all the work done; because all the code already migrated can be reused in a new 'I'll do a complete rewrite' project.

Angular CLI by Andrea Chiarelli

So che al momento non e possibile aggiungere moduli ad hoc tipo postCss che tu sappia sara una cosa possibile in futuro?
La versione attuale di Angular CLI è ancora in beta e diverse modifiche sono in corso (basti pensare alla recente sostituzione di SystemJS con Webpack). L'esigenza di aggiungere moduli ad hoc nella pipeline di building, come ad esempio postCSS, è molto sentita dalla comunità e sono sicuro che il team di Angular CLI troverà una soluzione per bilanciare la necessità di nascondere la complessità dell'ecosistema e la sua flessibilità. A tale proposito può risultare interessante la seguente discussione sulla personalizzazione di Webpack: https://github.com/angular/angular-cli/issues/1656

Redux by Gian Marco Toso

Perchè ho bisogno di una entità che crea l'azione? non posso importare e "dispatchare" direttamente l'azione stessa?
Visto che l'azione può essere chiamata potenzialmente in più punti dell'applicazione è meglio utilizzare un action creator, per evitare ripetizioni di codice;
Avrebbe senso far coesistere il 2 way data binding di angular 2 con redux?
Potrebbe avere senso, nel momento in cui si vuole utilizzare il 2-way data binding per gestire lo stato interno dei componenti Angular2 e Redux per lo stato applicativo. Naturalmente va valutato di caso in caso se la cosa può o meno essere sensata;
Ci sono prassi consigliate per la persistenza dello stato/store?
Lo Store non diventa un collo di bottiglia? Come scala?
Non è tanto un problema di quanti dati sono presenti nello store ma piuttosto di quanti reducer intercettano le actions. Su store parecchio complessi si può usare https://github.com/omnidan/redux-ignore per mitigare il problema e far arrivare le azioni solo a reducer specifici. In ogni caso uno store può, ma non necessariamente deve, contenere una rappresentazione completa dello stato applicativo. Si possono adottare delle politiche di cleanup per mantenere i dati memorizzati nello state al minimo indispensabile!

Ionic by Gabriele Mittica

Ionic è buono per realizzare applicazioni mobile ma non è ancora possibile realizzare facilmente un'interfaccia sia per smartphone che per tablet. Ti è già capitato di affrontare una problematica simile?
Sì, purtroppo come anticipato la responsività di Ionic 1 non è a mio parere al momento sufficiente. E' valida, ma avrebbero potuto fare uno sforzo maggiore (come per esemnpio fatto da Bootstrap 3 e 4). Ad ogni modo esistono molti temi in Ionic ed essendo la view puro HTML e CSS non è impossibile, anzi, ampliare il proprio set per supportare pienamente anche i tablet.
Escludendo la questione performance quali sono le tipologie di progetto per i quali non raccomanderesti affatto ionic o simili e perché?
In generale sconsiglierei uno svilupo ibrido nel caso in cui ci siano forti interazioni con il dispositivo a livello hardware. Il comparto di plugin Cordova è nutrito e ampio, ma se in progettazione ci accorgiamo che i plugin disponibili non supportano in pieno i nostri obiettivi, vale la pensa valutare l'opzione 'sviluppo nativo'.
A che punto è Ionic con Angular 2?
Ionic 2 è basato su Angular 2 ed è attualmente in fase di Release Candidate (prossimo al rilascio), è presumibile quindi pensare che Ionic 2 sbarcherà presto.
Cosa ne pensi della concorrenza tipo NativeScript / Telerik ecc. ?
La Telerik produce strumenti di grande qualità e NativeScript è uno strumento molto potente in grado di offrire alte prestazioni ad una applicazione Angular (o in generale app js) in ambiente mobile. Lo scoglio è strutturale e di apprendimento, in quanto bisogna aggiungere un'ulteriore tecnologia al proprio bagaglio di competenze.
Vantaggi ionic rispetto a cordova ?
Non sono comparabili. Ionic è un framework JS, Cordova una piattaforma di integrazione plugin per lo sviluppo di app ibride. Possono essere usati insieme ovviamente. Un confronto più sensato è quello tra Ionic.com, la parte commerciale di Ionic che offre anche servizi di build (cioè di produzione delle applicazioni compilate) con PhoneGap Build, cioè il "Cordova hostato by Adobe". Entrambe piattaforma valide, la prima in particolare più interessante da un punto di vista di servizi offerti nonostante più giovane.
Cosa ne pensi delle prestazioni visto che l'applicazione è ospitata all'interno di un WebView? Avendolo utilizzato ho notato che, se si "esagera", è facile incorrere in questo problema.
Sicuramente. Le prestazioni sono un capitolo motlo importante specie quando si desidera una forte reattività con modelli grafici e transizioni. Un primo consiglio è quello di minificare e ottimizzare correttamente l'intero codice js, css, html. In secondo luogo valutare attentamente l'adozione di plugin che possono aiutare le performance (come native transiction della telerik).
Quanto è importante per uno sviluppatore ionic passare a ionic 2?

AngularConf 2016 - an event by Corley srl