\n\n\n\n

Qui le slide:

\n\n\n\n
\n\n\n\n

Flowing nasce il 19.02.2019 da ideato e extrategy, ecco perché nelle slide trovi uno di questi brand! Scopri di più sul nostro speciale percorso di co-creazione di Flowing.

\n","slug":"webdeldn-frameworkless-frontend-development","created":"2018-04-17 15:33:56","categories":[{"id":86,"slug":"talk","label":"Talk","url":"https://wp.flowing.it/category/talk/","parent":0}],"services":[{"id":93,"slug":"development","label":"Development","url":"https://wp.flowing.it/services/development/","parent":0}],"tags":[{"id":106,"slug":"frameworkless","label":"frameworkless","url":"https://wp.flowing.it/tag/frameworkless/","parent":null},{"id":64,"slug":"javascript","label":"javascript","url":"https://wp.flowing.it/tag/javascript/","parent":null}],"people":[{"id":14,"name":"Francesco Strazzullo","role":"Development","description":"Appassionato developer dal 2005, mi occupo anche di training e consulenza legata al mondo JavaScript. Ho deciso che da grande avrei fatto lo sviluppatore dopo aver visto in azione il primo mitico Tomb Raider. Credo fermamente che condividere le proprie conoscenze sia una parte integrante del mestiere dello sviluppatore, quindi dedico molto tempo a prepare talk, scrivere libri e post su vari blog. Nel tempo libero rimasto probabilmente sono ai fornelli (o ad un barbecue) o davanti all'amata PlayStation.","image":"https://static.flowing.it/wp-content/uploads/2019/08/09104406/francesco-strazzullo.jpg","isSurfer":true,"social":{"facebook":"","twitter":"https://twitter.com/TheStrazz86","linkedin":"https://www.linkedin.com/in/francescostrazzullo/"},"slug":"francesco_strazzullo"}],"featuredImage":"https://static.flowing.it/wp-content/uploads/2018/04/09092940/Frameworkless__eventbrite-cover-031.png","links":[],"seo":{"title":"","metadesc":"Talk al WEBdeLDN, user group londinese che si occupa di sviluppo web a 360 gradi: il tema è l'approccio Frameworkless nello sviluppo frontend.","keywords":[],"social":{"facebook":{"title":null,"description":null,"image":null,"imageId":null},"twitter":{"title":null,"description":null,"image":null,"imageId":null}}},"additionalFields":{"holdDate":["17/04/2018"]}}],"total":10},"status":200,"headers":{}},"blogResp":{"data":{"items":[{"id":497,"title":"Frameworkless Frontend Development","content":"\n

Lo scorso anno è apparso su Medium un articolo intitolato How it feels to learn JavaScript in 2016. Il post è un divertente J’accuse a tutto il mondo dello sviluppo frontend moderno. Il post è diventato in breve tempo abbastanza virale, rimbalzando su vari profili Twitter dedicati al mondo JavaScript. Questo è solo uno dei tanti post / talk / video che trattano dell’argomento JavaScript Fatigue

\n\n\n\n

La JavaScript Fatigue è un termine che si usa per indicare la difficoltà di stare al passo con tutte le novità del mondo JavaScript. Ci sono ad oggi una pletora di framework e tool da padroneggiare per potersi definire un frontend engineer. Personalmente vivo questa cosa non come un fastidio ma come un’enorme opportunità. Da grande appassionato di software architecture ogni volta che ho la possibilità di analizzare un nuovo framework cerco di cogliere a quali pattern o paradigmi fa riferimento e cerco poi applicare le stesse metodologie nei casi d’uso che ritengo opportuni.

\n\n\n\n
\"\"
\n\n\n\n

Ma è un dato di fatto che ogni riga di codice scritta oggi rischia di diventare obsoleta dopo appena un anno. Per questo motivo in Flowing stiamo un utilizzando un approccio “difensivo” rispetto ai framework, quando questo si sposa con gli obiettivi di business del cliente. Per approccio difensivo intendiamo l’attenzione ad utilizzare di un framework solo le parti di cui abbiamo effettivamente bisogno in quel momento. Questa metodologia si ricollega al concetto di Sacrificial Architecture che ho trattato in maniera approfondita in vari talk lo scorso anno. Il framework quindi deve sempre essere una dipendenza il più possibile sacrificabile quando non risponde più alle esigenze di un progetto.

\n\n\n\n

Un altro approccio è quello di evitare del tutto l’utilizzo di framework di qualsiasi tipo. Questo approccio lo abbiamo chiamato Frameworkless Frontend Development. Al contrario di quanto si possa pensare, scrivere un’applicazione senza framework non è né un’operazione eccessivamente complessa, né un’operazione eccessivamente costosa. Ovviamente però avrete bisogno di un team di frontend engineer esperto e che conosca come manipolare efficacemente il DOM. Se siete curiosi potete dare un’occhiata a questo progetto su GitHub fatto senza nessun tipo di dipendenza. Noterete che in realtà il codice è assolutamente leggibile anche se scritto senza l’ausilio di nessuna libreria di terze parti.

\n\n\n\n

Ma a parte la possibilità effettiva di poter scrivere un’applicazione in maniera Frameworkless, quando è giusto questo tipo di approccio? Oppure in maniera più generica come si sceglie un framework e soprattutto come capire da quali features è saggio “difendermi”? Se ad esempio scegliamo di “reinventare la ruota” nel progetto o con il team sbagliato il nostro progetto potrebbe finire così:

\n\n\n\n
\"\"
Photo By Falk2 (Own work) [CC BY-SA 4.0], via Wikimedia Commons
\n\n\n\n

Questo tipo di problema non si può risolvere solo con analisi tecniche, ma occorre soprattutto un dialogo con il cliente. Per poter prendere questo tipo di scelte strategiche bisogna avere chiaro in mente quali sono gli obiettivi di business del progetto. Proprio per questo riteniamo indispensabile la nostra discovery per poter dare le risposte giuste ai nostri clienti. Personalmente poi trovo molto utile un piccolo esercizio che utilizziamo spesso proprio durante la discovery: il gioco delle leve.

\n\n\n\n

Lo svolgimento è abbastanza semplice: chiediamo ai nostri clienti di mettere in ordine di importanza queste 4 voci, senza la possibilità di parimerito.

\n\n\n\n
\"\"
il gioco delle leve
\n\n\n\n

Come capite il framework scelto non può essere lo stesso se il cliente afferma che il suo ordine di importanza è Qualità/Scope/Budget/Deadline o se invece vi dice Deadline/Qualità/Budget/Scope. Utilizzare questo tipo di informazioni diventa quindi fondamentale per conosce il contesto che ruota intorno al nostro software, e il contesto è una variabile che non possiamo ignorare nella scelta di una tecnologia.

\n\n\n\n

Ovviamente tutte queste scelte non devono essere scolpite nella pietra ma devono essere messe in discussione in continuazione. In questo ci viene in aiuto il nostro metodo iterativo. Al variare degli obiettivi del cliente, devono variare le specifiche e attorno a queste nuove specifiche dobbiamo costruire la migliore architettura possibile. Perché il codice che scriviamo è esclusivamente uno strumento che deve generare valore per i nostri clienti.

\n\n\n\n

Per uno dei nostri clienti più importanti stiamo virando verso un approccio Frameworkless. La nostra applicazione è stata costruita con il framework AngularJS per i primi anni di sviluppo. Questo perché d’accordo con il nostro cliente l’obiettivo era ottenere il prima possibile un prodotto testatbile per avere un feedback da parte degli utenti. Oggi il progetto è un asset portante dell’azienda e quindi abbiamo dovuto cambiare prospettiva, in questo momento l’obiettivo primario è garantire che il software cresca in maniera sana per altri molti anni. Abbiamo quindi deciso di iniziare a scrivere una Strangler Application basata su EcmaScript 6 e Web Components. Dato che dobbiamo tenere in considerazione una visione di lungo periodo – anzi lunghissima se teniamo in considerazione il ciclo di vita di applicazioni frontend – abbiamo deciso di abbandonare il maggior numero di librerie esterne che fra qualche anno potrebbero non essere più utilizzata o mantenute.

\n\n\n\n

Ho condensato tutti questi ragionamenti in un talk che ho portato al Codemotion Berlino di quest’anno e che sto per portare a Codemotion Milano. Ovviamente l’argomento è vasto e complesso quindi, per chi volesse approfondire, stiamo preparando un workshop di due giorni per Avanscoperta di cui potete leggere tutte informazioni sulla scheda formazione del loro sito ufficiale.

\n","slug":"frameworkless-frontend-development","created":"2019-09-18 17:24:07","categories":[{"id":1,"slug":"blog","label":"Blog","url":"https://wp.flowing.it/category/blog/","parent":0}],"services":[],"tags":[{"id":106,"slug":"frameworkless","label":"frameworkless","url":"https://wp.flowing.it/tag/frameworkless/","parent":null},{"id":64,"slug":"javascript","label":"javascript","url":"https://wp.flowing.it/tag/javascript/","parent":null}],"people":[{"id":14,"name":"Francesco Strazzullo","role":"Development","description":"Appassionato developer dal 2005, mi occupo anche di training e consulenza legata al mondo JavaScript. Ho deciso che da grande avrei fatto lo sviluppatore dopo aver visto in azione il primo mitico Tomb Raider. Credo fermamente che condividere le proprie conoscenze sia una parte integrante del mestiere dello sviluppatore, quindi dedico molto tempo a prepare talk, scrivere libri e post su vari blog. Nel tempo libero rimasto probabilmente sono ai fornelli (o ad un barbecue) o davanti all'amata PlayStation.","image":"https://static.flowing.it/wp-content/uploads/2019/08/09104406/francesco-strazzullo.jpg","isSurfer":true,"social":{"facebook":"","twitter":"https://twitter.com/TheStrazz86","linkedin":"https://www.linkedin.com/in/francescostrazzullo/"},"slug":"francesco_strazzullo"}],"featuredImage":"https://static.flowing.it/wp-content/uploads/2019/09/19160559/Schermata-2019-09-19-alle-16.04.08.png","links":[],"seo":{"title":"Frameworkless Frontend Development - Flowing - Blog","metadesc":"La JavaScript Fatigue, la difficoltà di stare al passo con tutte le novità del mondo JavaScript. Ci sono ad oggi una pletora di framework e tool da padroneggiare per potersi definire un frontend engineer: fastidio o enorme opportunità?","keywords":[],"social":{"facebook":{"title":null,"description":null,"image":null,"imageId":null},"twitter":{"title":null,"description":null,"image":null,"imageId":null}}},"additionalFields":{"holdDate":["20/10/2017"]}},{"id":976,"title":"Pattern giornalieri in Javascript: gestisci il caos delle applicazioni","content":"\n

In questo articolo vorrei parlarti di alcuni semplici pattern che ci potrebbero aiutare nell’organizzazione e nella scrittura di codice Javascript per le nostre applicazioni. Pattern facili da applicare e utili sia in applicazioni sviluppate interamente in Javascript che in applicazioni backend dove Javascript viene utilizzato per migliorare l’esperienza utente.

\n\n\n\n

Single Var Pattern

\n\n\n\n

Questo pattern ci dice di dichiarare tutte le variabili all’inizio della nostra funzione mettendole tutte in un unico var. Cosi facendo, definiamo un’unica ‘zona’ dove poter trovare tutte le variabili locali favorendone il reperimento, la leggibilità e prevenendo possibili errori di utilizzo di una variabile prima della sua dichiarazione (vedi hoisting). Inoltre questo pattern ci aiuta a ricordare di definire le variabili evitando l’utilizzo inconsapevole di globali.

\n\n\n\n
var changeTotal = function (editStatusButton) {\n    var editStatusButton = $(editStatusButton),\n        orderId = editStatusButton.attr('data-order-id'),\n        total = 0;\n    \n    ...\n};
\n\n\n\n

Vediamo ora due pattern fondamentali che ci aiutano a organizzare il nostro codice e circoscrivere il ‘caos’.

\n\n\n\n

Namespace Pattern

\n\n\n\n

Lo scopo di questo pattern è quello di ridurre l’utilizzo di globali, evitare naming collision (anche con librerie di terze parti) e l’utilizzo di prefissi. Javscript non supporta nativamente i namespace e quindi vedremo un modo per implementare questo pattern.

\n\n\n\n

Partiamo da questo semplice esempio:

\n\n\n\n
var pippo = 3,\n    pluto = function() {\n        // … fa cose vede gente …\n    },\n    paperino = function() {\n        // … inventa situazioni, coccola startup\n    };
\n\n\n\n

Possiamo fare refactoring di questo codice utilizzando il namespace pattern. Creando un unico oggetto globale (ad esempio ‘ideato’) e attaccando tutte le nostre funzioni, variabili e oggetti su questo oggetto, facciamo si che diventino proprietà del singolo oggetto globale.

\n\n\n\n
var ideato = {}\nideato.pippo = 3\nideato.pluto = function() {\n// … fa cose vede gente …\n}\nideato.paperino = function() {\n// … inventa situazioni, coccola startup\n}
\n\n\n\n

Un altro modo per definire il namespace è mostrato nel seguente esempio:

\n\n\n\n
var ideato = ideato || {};
\n\n\n\n

Come puoi vedere, se l’oggetto ideato esiste allora viene assegnato alla variabile ideato altrimenti viene inizializzato con un oggetto vuoto. Questo idioma è utile a preservare l’eventuale esistenza di un namespace definito precedentemente nella nostra applicazione.

\n\n\n\n

Module Pattern

\n\n\n\n

Con questo pattern possiamo suddividere il nostro codice in moduli che rappresentano oggetti – i quali definiscono proprietà – metodi e quindi comportamento. L’obiettivo del pattern è quello di emulare il concetto di ‘classe’ e quindi di visibilità di proprietà e metodi.

\n\n\n\n

Con il module pattern riusciamo ad incapsulare la logica all’interno del modulo e ad esporre un interfaccia pubblica utilizzabile dal resto dell’applicazione. Riusciamo quindi ad organizzare il codice in maniera pulita, separando le responsabilità tra i vari moduli ed abbassando la probabilità di avare conflitti tra i nomi delle nostre funzioni e quelli di altre funzioni definite altrove.

\n\n\n\n

Come dicevamo Javascript non è in grado di definire la visibilità di una proprietà o metodo. Per emulare questo concetto utilizziamo lo scope delle funzioni. Tutte le variabili e/o metodi dichiarati localmente all’interno del modulo sono visibili solo al modulo stesso mentre quelle definite dentro l’oggetto di ritorno vengono rese disponibili all’esterno. Chiariamo con un po’ di codice:

\n\n\n\n
var pomodoro = (function () {\n \n  var seconds = 1500;\n \n  return {\n \n    decrease: function () {\n      return --seconds;\n    },\n \n    reset: function () {\n      seconds = 1500;\n      console.log(seconds);\n    }\n  };\n \n})();\n  \nconsole.log(pomodoro.decrease()); // 1499\npomodoro.reset(); // 1500
\n\n\n\n

La variabile seconds è visibile solo all’interno della funzione pomodoro che rappresenta il modulo. pomodoro espone i metodi decrease e reset tramite la restituzione di un oggetto. Questi metodi posso essere utilizzati dall’esterno.

\n\n\n\n

Revealing Module Pattern

\n\n\n\n

Una variante del module pattern è il ‘revealing module’ pattern.

\n\n\n\n

La parte di revealing è puramente sintattica in quanto nel modulo tutte le variabili sono create privatamente e tramite la restituzione di un object literal mostriamo al mondo esterno solo proprietà e metodi che vogliamo.

\n\n\n\n

Riprendiamo l’esempio precedente. Definiamo namespace e modulo tutto all’interno di un singolo file:

\n\n\n\n
var ideato = ideato || {};\nideato.pomodoro = ideato.pomodoro || {};\n\n(function(namespace) {\n namespace.create = function() {\n     var seconds = 1500,\n         decrease,\n         reset;\n\n     decrease = function() {\n         return --seconds;\n     };\n\n     reset = function() {\n         seconds = 1500;\n         console.log(seconds);\n     };\n\n     return {\n         decrease: decrease,\n         reset: reset\n     };\n };\n})(ideato.pomodoro);
\n\n\n\n

Tramite l’utilizzo della keyword var abbiamo definito seconds, decrease e reset in modo tale che siano visibili solo all’interno del modulo. Successivamente il modulo ritorna un oggetto che espone la sua interfaccia pubblica rivelando al mondo esterno solo i metodi che vuole.

\n\n\n\n

Come puoi vedere con pochissimo sforzo riusciamo a suddividere logicamente il codice in veri e propri moduli utilizzabili in ogni punto dell’applicazione.

\n\n\n\n

Per utilizzare il modulo basta includere il file e:

\n\n\n\n
var myPomodoro = ideato.pomodoro.create();\n\nconsole.log(myPomodoro.decrease()); // 1499\nmyPomodoro.reset(); // 1500\nconsole.log(myPomodoro.seconds) // undefined
\n\n\n\n

Organizzare il codice in questa maniera ci permette di facilitare il passaggio delle dipendenze tra moduli, mitigare l’utilizzo di oggetti globali e proteggere i metodi da sovrascritture involontarie.

\n\n\n\n

Callback Pattern

\n\n\n\n

Continuando il discorso sulla gestione delle dipendenze, un altro pattern che potrebbe essere nostro amico è il ‘callback pattern’ con il quale riusciamo a disaccoppiare le responsabilità tra i nostri oggetti.

\n\n\n\n

In Javascript le funzioni sono oggetti. Questo significa che una funzione f1 può essere passata come parametro della funzione f2 ed utilizzata al suo interno.

\n\n\n\n

Vediamo un esempio:

\n\n\n\n
var f2 = function(callback){\n    // … fa cose vede gente …\n    callback()\n    // … fa cose vede gente …\n}\n \nvar f1 = function(){\n    // … fa cose vede gente …\n}\n \nf2(f1);
\n\n\n\n

f1 viene passata senza parentesi dato che non vogliamo eseguirla ma passare una referenza alla funzione stessa. Sarà poi f2 che eseguirà f1.

\n\n\n\n

Come puoi vedere, invece di ‘harcodare’ la logica di f1 dentro f2, possiamo racchiuderla in una funzione che f2 eseguirà in maniera agnostica disaccoppiando le responsabilità delle due funzioni. Il testing si semplifica e il riutilizzo aumenta.

\n\n\n\n

Ecco un altro esempio:

\n\n\n\n
var myPomodoro,\n    initApp;\n\nmyPomodoro = ideato.pomodoro.create();\n\ninitApp = function (resetPomodoro) {\n\t// … fa cose vede gente …\n\tresetPomodoro();\n};\n\ninitApp(myPomodoro.reset);\n
\n\n\n\n

Patterns per la creazione di oggetti

\n\n\n\n

Chiudiamo con alcuni consigli sulla creazione degli “oggetti”.

\n\n\n\n

In Javascript ci sono diversi modi di creare oggetti. I più comuni sono:

\n\n\n\n
var movie = { title: \"back to the future\", year: \"1985\", ...}\n
\n\n\n\n
var movie = new Movie(\"Back to the future\");\n
\n\n\n\n

Personalmente preferisco il primo approccio perché enfatizza il fatto che un oggetto può essere visto come un hash chiave:valore dove la chiave definisce il nome della proprietà e il valore ne definisce il contenuto. Nel caso in cui il contenuto sia una funzione allora potremmo parlare di metodo.

\n\n\n\n

Utilizzando librerie o comunque lavorando su codice di altri mi capita di trovare l’utilizzo del new e quindi trovo utile comunque conoscere meglio il significato di questo approccio:

\n\n\n\n
var Movie = function(title){\n    this.title = title;\n    this.printSummary = function(){\n        return \"Summary for \" + this.title + \" ...\";\n    }\n}\n\nvar movie = new Movie(\"Back to the future\");\nmovie.printSummary();\n
\n\n\n\n

Con la keyword new invochiamo il costruttore Movie, che al suo interno genera un oggetto this al quale potremo attaccare proprietà e metodi. Il this rappresenta l’oggetto che verrà implicitamente restituito alla fine del costruttore.

\n\n\n\n

Il metodo printSummary viene aggiunto ad ogni nuova istanza dell’oggetto Movie occupando memoria che potrebbe essere risparmiata dato che il metodo printSummary non cambia per ogni singola istanza.

\n\n\n\n

Un modo migliore per gestire questo comportamento è descritto nel codice seguente:

\n\n\n\n
Movie.prototype.printSummary = function(){\n    return \"Summary for \" + this.title + \" ...\";\n}
\n\n\n\n

Attaccando il metodo al prototype dell’oggetto, printSummary verrà creata una sola volta in memoria.

\n\n\n\n

Un altro aspetto pericoloso dell’utilizzo del new è il seguente:

\n\n\n\n
var movie = Movie(\"Back to the future\");\n
\n\n\n\n

Hai visto? Probabilmente no dato che nessun errore o segnalazione vi verrà notificata. Ho appena dichiarato un oggetto globale dato che mi sono dimenticato di scrivere la parola chiave new. this dentro Movie verrà attaccato all’oggetto window se siamo nel browser e questo potrebbe causarvi tutte quelle simpatiche cose che possono succedere con gli oggetti globali (comportamenti inaspettati, namespace pollution, ecc).

\n\n\n\n

C’è un pattern che ci aiuta ad evitare questo problema:

\n\n\n\n
function Movie(title) {\n     \"use strict\";\n\n     if (!(this instanceof Movie)) {\n\t\treturn new Movie();\n     }\n\n     this.title = title;\n     this.printSummary = function(){\n        return \"Summary for \" + this.title + \" ...\";\n     }\n\n     return this;\n}
\n\n\n\n

Lo ‘strict mode’ scatena un eccezione del tipo “Uncaught TypeError: Cannot set property ‘title’ of undefined” se proviamo ad attaccare e valorizzare una proprietà al this. Il controllo sul tipo ci garantisce di istanziare un oggetto Movie con l’utilizzo del new.

\n\n\n\n

In conclusione

\n\n\n\n

Nonostante sia uno sviluppatore backend, in tutte le applicazioni che scrivo c’è sempre una bella fetta di codice Javascript.

\n\n\n\n

L’utilizzo di questi pattern mi evita semplicemente di spargere snippets di codice Javascript in giro per i template dell’applicazione, aiutandomi a contenere il caos che comunque si verrebbe a formare  anche in applicazioni dove la UI è più o meno semplice.

\n\n\n\n

Li ho chiamati ‘pattern giornalieri’ appunto perché ogni qual volta che scrivo codice Javascript applico alcuni di questi pattern. Mi trovo spesso a programmare applicazioni PHP che utilizzano Javascript nei template per l’arricchimento della UI. Spesso non mi serve un framwork Javascript ma mi basta utilizzare le librerie più comuni per il raggiungimento degli obiettivi (jquery, underscore, moment, ecc).

\n\n\n\n

Applicare questi pattern è utile per migliorare design, leggibilità, testabilità e manutenibilità del codice. Non ho mai riscontrato casi in cui l’applicazione di questi pattern fosse un overkill o comunque un over-ingegnerizzazione del codice applicativo.

\n\n\n\n

Se vuoi approfondire l’argomento, ti consiglio queste due risorse:

\n\n\n\n

Javascript patterns di Stoyan Stefanov

\n\n\n\n

Learning JavaScript Design Patterns di Addy Osmani

\n","slug":"pattern-giornalieri-in-javascript-gestisci-il-caos-delle-applicazioni","created":"2019-10-22 15:27:37","categories":[{"id":1,"slug":"blog","label":"Blog","url":"https://wp.flowing.it/category/blog/","parent":0}],"services":[{"id":93,"slug":"development","label":"Development","url":"https://wp.flowing.it/services/development/","parent":0}],"tags":[{"id":242,"slug":"code-pills","label":"code pills","url":"https://wp.flowing.it/tag/code-pills/","parent":null},{"id":215,"slug":"pattern","label":"pattern","url":"https://wp.flowing.it/tag/pattern/","parent":null},{"id":64,"slug":"javascript","label":"javascript","url":"https://wp.flowing.it/tag/javascript/","parent":null}],"people":[{"id":6,"name":"Riccardo Franconi","role":"Partner","description":"Sviluppatore, papà e musicista. Adoro costruire cose in maniera creativa e collaborativa. \r\nLe mie più grandi passioni sono la musica e lo sviluppo che fortunatamente occupano costantemente le mie giornate.","image":"https://static.flowing.it/wp-content/uploads/2019/06/14122844/riccardo-franconi.jpg","isSurfer":true,"social":{"facebook":"","twitter":"https://twitter.com/ricfrank","linkedin":"https://www.linkedin.com/in/riccardofranconi/"},"slug":"riccardo_franconi"}],"featuredImage":"https://static.flowing.it/wp-content/uploads/2019/10/22152724/patterns-javascript.jpg","links":[],"seo":{"title":"","metadesc":"Patterns giornalieri in Javascript: alcuni pattern che aiutano nell’organizzazione e scrittura di codice javascript per le applicazioni.","keywords":[],"social":{"facebook":{"title":null,"description":null,"image":null,"imageId":null},"twitter":{"title":null,"description":null,"image":null,"imageId":null}}},"additionalFields":{"holdDate":["02/12/2014"]}},{"id":970,"title":"AngularJs e Silex: la giusta coppia per architetture REST","content":"\n

Da alcuni mesi abbiamo accettato un’interessante sfida per nuovo cliente Neomobile entrando a far parte del team di sviluppo del nuovo pannello di amministrazione, di verifica e reportistica per Onebip, la loro piattaforma di pagamento su credito telefonico.

\n\n\n\n

Dopo una prima macro analisi delle esigenze del cliente, abbiamo ritenuto fondamentale l’implementazione di un software amministrativo semplice da utilizzare per gli utenti, dove l’usabilità e la facilità di integrazione con la loro base dati fosse il punto di forza di tutto il software.

\n\n\n\n

La scelta tecnologica

\n\n\n\n

Vista l’esigenza di raggiungere risultati in tempi brevi, la nostra proposta è stata fin da subito di implementare una Single Page Application (SPA) che comunicasse con la business logic del cliente attraverso un architettura REST. Il cliente ha accettato entusiasta e siamo scesi nel dettaglio della scelta tecnologica.

\n\n\n\n

Forti delle nostre competenze sia nello sviluppo frontend che backend, abbiamo fatto cadere la scelta tecnologica su due prodotti software Open Source, secondo noi irresistibili: AngularJs e Silex.

\n\n\n\n

Come interfaccia grafica, dopo una votazione interna al team, si è scelto di utilizzare Flex Admin, un tema responsivo sviluppato sul framework css Bootstrap. Questo ci ha dato la possibilità di sviluppare con molta velocità le funzionalità avendo già a disposizione un set di oggetti UI pronti all’uso.

\n\n\n\n

AngularJs e Silex

\n\n\n\n

AngularJs è l’innovativo framework sviluppato dalla famosa azienda di Mountain View, framework che ha rivoluzionato il modo di sviluppare Single Page Application, introducendo concetti provenienti da altri linguaggi come il data binding, la dependency injection e sviluppando addirittura un framework di test end to end, che permette di facilitare il test delle applicazioni stesse.

\n\n\n\n

“HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications. AngularJS lets you extend HTML vocabulary for your application. The resulting environment is extraordinarily expressive, readable, and quick to develop.”

\n\n\n\n

Silex, invece, è un micro framework php leggero e performante che appoggiandosi sulle spalle dei giganti – i componenti di Symfony – offre la possibilità di sviluppare servizi restful attraverso un sistema di routing semplice e potente che permette di definire rotte su tutti i verbi del protocollo HTTP, implementare autenticazioni stateless e definire dinamicamente i servizi attraverso la dependency injection.

\n\n\n\n

“Silex is a PHP microframework for PHP 5.3. It is built on the shoulders of Symfony2 and Pimple and also inspired by sinatra. A microframework provides the guts for building simple single-file apps. Silex aims to be:

\n\n\n\n

Concise: Silex exposes an intuitive and concise API that is fun to use.

Extensible: Silex has an extension system based around the Pimple micro service-container that makes it even easier to tie in third party libraries.

Testable: Silex uses Symfony2’s HttpKernel which abstracts request and response. This makes it very easy to test apps and the framework itself. It also respects the HTTP specification and encourages its proper use.”

\n\n\n\n

Siamo abituati a scegliere solo prodotti software che siano coperti da test automatici e che consentano facilmente a loro volta di testare in maniera unitaria ed efficiente le nuove funzionalità sviluppate per i nostri clienti. AngularJs e Silex rispettano questo requisito fondamentale. Per noi testare il codice non è solo il minimo necessario per garantire sicurezza e continua affidabilità ai nostri clienti ma ci aiuta, attraverso il Test Driven Development (TDD), anche a far emergere il design più appropriato del nostro software.

\n\n\n\n

Se vuoi sapere di più sul TDD abbiamo scritto un libro, Pro PHP Refactoring, su come eseguirlo se sviluppi in PHP.

\n\n\n\n

Sviluppare una Single Page Application

\n\n\n\n

Sviluppare una Single Page Application significa sviluppare un software con architettura a micro servizi dove tutta la logica di view viene servita dal browser, mentre la logica di business viene gestita esclusivamente dal server attraverso API REST, che servono tutte le funzionalità per l’accesso e la gestione di ogni risorsa. La comunicazione tra browser e API avviene attraverso richieste XHR. Tutta la comunicazione avviene scambiando dati in formato JSON che vengono poi analizzati e rappresentati dal browser utilizzando specifiche funzioni del framework Javascript.

\n\n\n\n

Di seguito un piccolo tutorial su come sia possibile implementare una semplice Single Page Application che stampa il noto “Hello world” con AngularJs e Silex.

\n\n\n\n

Per prima cosa creiamo una nuova cartella “helloworld”. Entriamo nella cartella e installiamo Silex utilizzando Composer, per farlo scarichiamo Composer e lanciamo il comando “php composer.phar require silex/silex”.

\n\n\n\n

Successivamente creiamo una cartella “web”, entriamo nella cartella e installiamo AngularJs utilizzando Bower. Per farlo installiamo Bower attraverso npm e lanciamo il comando “bower install angular”.

\n\n\n\n

A questo punto, rimanendo nella cartella “web” creiamo il file “api.php” che sarà il punto di accesso alla nostra api.

\n\n\n\n
<?php\n// web/api.php\nrequire_once __DIR__.'/../vendor/autoload.php';\n\n$app = new SilexApplication();\n\n$app->get('/helloworld', function () use ($app) {\n    return 'Hello World';\n});\n\n$app->run();
\n\n\n\n

Alla riga 7 abbiamo definito la rotta /helloworld che restituisce semplicemente la stringa “Hello World”. Questo sarà il servizio che utilizzeremo per stampare la nostra scritta attraverso AngularJs.

\n\n\n\n

Nella stessa cartella “web” creiamo il file “index.html” che conterrà la nostra Single Page Application in AngularJs.

\n\n\n\n
<!doctype html>\n<html lang=\"en\" ng-app=\"hwApp\">\n<head>\n  <meta charset=\"utf-8\">\n  <title>Hello World</title>\n  <script src=\"bower_components/angular/angular.js\"></script>\n</head>\n<body ng-controller=\"hwCtrl\">\n  <h1>{{ serverData }}</h1>\n\n  <script type=\"text/javascript\">\n    angular.module('hwApp', [])\n    .controller('hwCtrl', function($scope, $http){\n        $http.get('/api.php/helloworld').success(function(data){\n            $scope.serverData = data;    \n        })\n    });\n\n  </script>\n</body>\n</html>
\n\n\n\n

La chiamata al nostro servizio avviene alla riga 14, utilizzando il servizio $http di AngularJs. Se la chiamata va a buon fine assegniamo al parametro dello $scope serverData il valore che ci ha restituito il servizio. Attraverso il data binding automatico di AngularJs vedremo comparire nella nostra pagina la scritta “Hello World” all’interno del tag h1 alla riga 9.

\n","slug":"angularjs-e-silex-la-giusta-coppia-per-architetture-rest","created":"2019-10-22 14:59:24","categories":[{"id":1,"slug":"blog","label":"Blog","url":"https://wp.flowing.it/category/blog/","parent":0}],"services":[{"id":93,"slug":"development","label":"Development","url":"https://wp.flowing.it/services/development/","parent":0}],"tags":[{"id":243,"slug":"rest","label":"rest","url":"https://wp.flowing.it/tag/rest/","parent":null},{"id":244,"slug":"silex","label":"silex","url":"https://wp.flowing.it/tag/silex/","parent":null},{"id":242,"slug":"code-pills","label":"code pills","url":"https://wp.flowing.it/tag/code-pills/","parent":null},{"id":42,"slug":"angularjs","label":"angularjs","url":"https://wp.flowing.it/tag/angularjs/","parent":null},{"id":64,"slug":"javascript","label":"javascript","url":"https://wp.flowing.it/tag/javascript/","parent":null},{"id":8,"slug":"php","label":"php","url":"https://wp.flowing.it/tag/php/","parent":null}],"people":[{"id":13,"name":"Francesco Trucchia","role":"Partner","description":"Imprenditore pragmatico dal 2008, sviluppatore software dal 1998, socio fondatore di Flowing. Aiuto le aziende a creare software capace di evolvere seguendo i bisogni di business e supporto i team tecnici nell'organizzarsi nel modo migliore per espandere tutto il potenziale.","image":"https://static.flowing.it/wp-content/uploads/2019/06/14122854/trucchia.jpg","isSurfer":true,"social":{"facebook":"","twitter":"","linkedin":"https://www.linkedin.com/in/trucchia/"},"slug":"francesco_trucchia"}],"featuredImage":"https://static.flowing.it/wp-content/uploads/2019/10/22145903/angularjs2.jpg","links":[],"seo":{"title":"","metadesc":"Per un nostro cliente abbiamo fatto cadere la scelta tecnologica su due prodotti software Open Source, secondo noi irresistibili: AngularJs e Silex.","keywords":[],"social":{"facebook":{"title":null,"description":null,"image":null,"imageId":null},"twitter":{"title":null,"description":null,"image":null,"imageId":null}}},"additionalFields":{"holdDate":["07/08/2014"]}}],"total":3},"status":200,"headers":{}}}})}catch(_){}