Un altro autunno che inizia

Ultimo post di Ottobre. Inizio di autunno, giornate che diventano sempre più corte e fredde. Umore che cambia, con movimenti lenti e pigri. Per me un periodo davvero frenetico e pieno di impegni, scadenze, consegne. Movimenti strani e personaggi ambigui. Voglia di crescere, dimostrare, imparare, realizzare. Tanta speranza per il futuro, sempre più incerto e scoraggiante, ma con la consapevolezza di non perder nulla rischiando.

Chiudo questo mese con una bella foto del mio amico Zєи. Buona fortuna.

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/10/31/un-altro-autunno-che-inizia/.

[Javascript] Un nuovo modo di scrivere il front-end con Backbone.js + CoffeeScript

Ultimamente sto usando il framework Backbone.js per scrivere il front-end di una web app, con un linguaggio molto minimale, e non proprio immediato, che è CoffeeScript. Non condivido appieno le implementazioni “massicce” lato front-end in Javascript, forse perché sono un convinto “accessibilista”, e forse perché non ho ancora compreso appieno quanto sia accessibile lo stesso Javascript. Comunque, sono contrario ad avere troppa logica spostata sul client e la struttura delle stesse pagine mi piace averla ben organizzata e semplice.

Tuttavia, questo Backbone, che implementa una “logica MVC” lato front-end, ho visto che è parecchio utilizzato in parecchie web app importanti.

Vi allego un ottimo tutorial, oltre al link della documentazione ufficiale e un ebook (a pagamento):

Da quanto si legge su HTML.it, per la sua architettura, Backbone.js rientra nella categoria delle librerie MV*, in quanto implementa Model e View, ma non ha un componente Controller tradizionale, delegandone i compiti alle View e ad un componente di routing. Questo approccio è abbastanza diffuso in ambito JavaScript, dove la diversa e più complessa gestione dell’interazione utente e dello stato dell’applicazione non si adattano bene ai compiti di un controller.

 

I componenti base di Backbone.js sono:

  • Backbone.Model: modelli
  • Backbone.Collection: liste di modelli
  • Backbone.View: view
  • Backbone.Router: routing e gestione centralizzata dello stato dell’applicazione

CoffeeScript, invece, non è altro che una riscrittura sintattica di Javascript, che si rifà a Ruby e Python. E’ simbioticamente legato, ma non necessario, a Backbone.js, visto che l’ha creato lo stesso Jeremy Ashkenas  (insieme ad Underscore.js ed Handlebars.js, librerie Javascript di utility, che è buono e consigliato conoscere per usare Backbone).

Eccovi un rapido tour nella sintassi CoffeeScript: CoffeeScript – perchè amarlo?

L’accoppiata Backbone+CoffeeScript ha un bel pò di vantaggi che ho potuto apprezzare:

  • semplicità e pulizia nella scrittura del codice, grazie ad una sintassi molto minimale (si richiede una conoscenza di base della sintassi Python)
  • il paradigma MVC crea una struttura di progetto ben organizzata, dove ogni cosa è al suo posto
  • propagazione di eventi e dell’aggiornamento “automatico” dello stato dei modelli e delle viste collegate
  • modalità di testing con fixture molto semplice e veloce
  • librerie di utility Javascript che implementano logiche anche complesse
  • realizzazione di Single-Page Application e di web app per il mobile (Using backbone.js with jQuery Mobile)
  • Backbone+REST=GRAVY: integrazione “nativa” di Backbone con le API REST (Vedi l’articolo sulla filosofia REST su questo blog)
  • possibilità di utilizzare tutto ciò che è Javascript (anche librerie come jQuery)
Gli svantaggi, a mio parere, sono:
  • troppa logica Javascript lato front-end
  • troppi modelli e viste possono rendere difficile la lettura e complicare la “navigazione” del progetto
  • se non si definisce un “modus operandi” e una struttura di progetto con relative “regole” e “convenzioni” prima dell’inizio della fase di sviluppo, risulta difficile lavorare in gruppo e scrivere software “manutenibile”
  • tecnologia molto evoluta e complessa, con una curva di apprendimento bassa
  • scarsa compatibilità con browser “datati”

Scritto ciò, se siete smanettoni Javascript, Backbone+CoffeeScript dovete assolutamente conoscerli ed usarli.

Vi allego un file di testo con delle note mie estratte dalla documentazione ufficiale di Backbone.

Backbonejs Notes
Titolo: Backbonejs Notes (0 click)
Etichetta:
Filename: backbones.txt
Dimensione: 25 kB

La crisi secondo Einstein

20121020-093409.jpgNon possiamo pretendere che le cose cambino, se continuiamo a fare le stesse cose.

La crisi è la più grande benedizione per le persone e le nazioni, perché la crisi porta progressi. La creatività nasce dall’angoscia come il giorno nasce dalla notte oscura. E’ nella crisi che sorge l’inventiva, le scoperte e le grandi strategie. Chi supera la crisi supera sé stesso senza essere ‘superato’.

Chi attribuisce alla crisi i suoi fallimenti e difficoltà, violenta il suo stesso talento e dà più valore ai problemi che alle soluzioni. La vera crisi, è la crisi dell’incompetenza. L’inconveniente delle persone e delle nazioni è la pigrizia nel cercare soluzioni e vie di uscita. Senza crisi non ci sono sfide, senza sfide la vita è una routine, una lenta agonia. Senza crisi non c’è merito. E’ nella crisi che emerge il meglio di ognuno, perché senza crisi tutti i venti sono solo lievi brezze. Parlare di crisi significa incrementarla, e tacere nella crisi è esaltare il conformismo. Invece, lavoriamo duro. Finiamola una volta per tutte con l’unica crisi pericolosa, che è la tragedia di non voler lottare per superarla.

Albert Einstein

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/10/20/la-crisi-secondo-einstein/.

[REST] La filosofia REST: il Web ha già tutto quello di cui si ha bisogno!

L’argomento stavolta è REST (REpresentational State Transfer), vera e propria filosofia informatica. Infatti, la prima volta di cui se ne parlò fu nel 2000, nel capitolo 5 della tesi di PhD in Filosofia Informatica di Roy Fielding, uno dei principali autori delle specifiche HTTP, dal titolo Architectural Styles and the Design of Network-based Software Architectures.

Ma cosa è veramente REST? Uno standard, un modello o cosa? Purtroppo non è ancora un vero e proprio standard e, forse, non è neanche giusto che lo sia. Definisce un modello di progettazione di architetture software o, elegantemente, uno “stile architetturale”. L’idea di base del REST è quella di vedere il Web (ma anche altri “sistemi”)  come una piattaforma per l’elaborazione distribuita dei dati. E il Web ha già tutto quello di cui si ha bisogno, ossia l’infrastruttura che si basa sul protocollo HTTP e le informazioni, che diventano vere e proprie risorse. Non ha senso inserire un overhead ulteriore e, dunque, uno strato software come avviene con i Web Services in SOAP.

Riporto un passo estratto dalla tesi di Fielding in cui si introduce il senso di questo stile:

The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application. […]

REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. I describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles.

 

Questo stile è diventato molto in voga negli ultimi anni per la realizzazione di Web Services altamente scalabili ed efficienti. Per approfondire l’argomento e per esempi pratici, ecco il link alle lezioni di HTML.it: RESTful Web Services – La guida, da cui ho estratto gran parte delle informazioni qui di seguito riportate.

Ecco i 5 principi su cui si basa il REST:

  • identificazione delle risorse
  • utilizzo esplicito dei metodi HTTP
  • risorse autodescrittive
  • collegamenti tra risorse
  • comunicazione senza stato
Una risorsa è qualsiasi elemento oggetto su cui è possibile effettuare operazioni ed è identificabile univocamente (attraverso una URI – Uniform Resource Identifier).
Il primo passo consiste nell’individuare le risorse da esporre tramite il Web Service, dove la loro rappresentazione “esterna” verso il client non sempre rispecchia l’implementazione o il modello interno dell’applicazione web.
Gli URI devono essere autoesplicativi, per far capire di che risorsa si tratta. Dopo aver trovato il modo di identificare le risorse, occorre definire quali operazioni effettuare su di esse. Si sfrutta quello che già si ha, ossia i metodi HTTP come GET, POST, PUT e DELETE.

 

Semplici regole nella definizione delle URI:
  • preferire l’utilizzo di nomi a quello di verbi
  • contenere la lunghezza degli URI
  • preferire uno schema posizionale, ossia una struttura gerarchica di un percorso piuttosto che la presenza di più argomenti: http://www.mionegozio.com/ordini/2011/07/01 al posto di http://www.mionegozio.com/ordini/?anno=2001&mese=07&giorno=0
  • evitare le estensioni, che legano un Web Service alla sua implementazione: ad esempio, è da preferire un URI del tipo:
http://www.mionegozio.com/ordini/?id=123
ad uno del tipo:
http://www.mionegozio.com/ordini/ordine.php?id=123

 

REST, quindi, non fa altro che mappare uno a uno le tipiche operazioni CRUD (creazione, lettura, aggiornamento, eliminazione di una risorsa) e i metodi HTTP:
  • POST –> Create (Crea un nuova risorsa)
  • GET –> Read (Ottiene una risorsa esistente)
  • PUT –> Update (Aggiorna una risorsa o ne modifica lo stato)
  • DELETE –> Delete (Elimina una risorsa)
Il tipo di rappresentazione di una risorsa inviata dal Web Service al client è indicato nella stessa risposta HTTP tramite un tipo MIME e il client stesso può anche richiedere una risorsa in uno specifico formato sfruttando l’attributo Accept di una richiesta HTTP di tipo GET. Grazie alla possibilità di rappresentazioni multiple possiamo progettare una applicazione web offrendo un gli output di un servizio in formati differenti a seconda del client. Formati più utilizzati sono XML, (X)-HTML e JSON. Su quest’ultimo trovate anche un articolo su questo sito: [JSON] Introduzione al diffuso formato di scambio dei dati
Alcuni framework sono in grado di gestire in automatico la cosiddetta content negotiation, cioè la fornitura di una rappresentazione nel formato richiesto dal client.

 

Le interazioni tra client e server devono essere senza stato, rispettando la comunicazione stateless nativa del protocollo HTTP. La gestione dello stato (se necessaria) avviene sul client, ottimizzando le prestazioni del server che non deve curare lo stato di una sessione e può essere effettuato con l’uso di chiavi di sessione, come i cookie.
Il fatto che i principi REST escludano la gestione dello stato della comunicazione non deve però far pensare che i Web Service RESTful siano senza stato. L’acronimo REST sta per REpresentational State Transfer, sottolineando proprio la centralità della gestione dello stato in un sistema distribuito. Lo stato che REST prende in considerazione è però quello delle risorse e dell’intera applicazione.

  • Lo stato delle risorse è dato dall’insieme dei valori delle caratteristiche di una risorsa in un dato momento. Un Web Service è responsabile della gestione dello stato delle risorse. Un client può accedere allo stato di una risorsa tramite le diverse rappresentazioni della risorsa stessa e contribuire a modificarlo per mezzo dei metodi PUT, POST e DELETE dell’HTTP.
  • Lo stato del client è rappresentato dall’insieme del contesto e delle risorse ottenute in uno specifico momento. Il server può influenzare le transizioni di stato del client inviando differenti rappresentazioni in risposta alle sue richieste.
  • Lo stato dell’applicazione, cioè del risultato dell’interazione tra client e server, è dato dallo stato del client e delle risorse gestite dal server. Lo stato dell’applicazione determina le modalità di modifica dello stato delle risorse e del client.

A differenza di quanto avviene in buona parte delle applicazioni Web, dove lo stato dell’applicazione viene spesso mantenuto dal server insieme allo stato della comunicazione, lo stato dell’applicazione in un’architettura RESTful è il frutto della collaborazione di client e server, ciascuno con i propri ruoli e responsabilità.

Come da acronimo, una applicazione passa da uno stato all’altro, principio noto come HATEOAS, usando i collegamenti ipertestuali: una applicazione è intesa come rete di risorse in cui un client naviga seguendo i collegamenti ammissibili tra una risorsa e l’altra, come una macchina a stati finiti.

Un bel articolo sulle differenze tra SOAP e RESTful, lo potete leggere sempre su HTML.it:

RESTful VS. SOAP. REST propone una visione del Web incentrata sul concetto di risorsa mentre i SOAP Web Service mettono in risalto il concetto di servizio.

  • Un Web Service RESTful è custode di un insieme di risorse sulle quali un client può chiedere le operazioni canoniche del protocollo HTTP
  • Un Web Service basato su SOAP espone un insieme di metodi richiamabili da remoto da parte di un client

L’approccio dei SOAP Web service ha mutuato un’architettura applicativa denominata SOAService Oriented Architecture, a cui si è recentemente contrapposta l’architettura ROAResource Oriented Architecture, ispirata ai principi REST. SOAP utilizza HTTP come protocollo di trasporto, ma non è limitato né vincolato ad esso, dal momento che può benissimo usare altri protocolli di trasporto. SOAP non sfrutta a pieno il protocollo HTTP, utilizzandolo come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di livello applicativo, e ne utilizza a pieno le potenzialità.

È evidente che l’approccio adottato dai Web Service basati su SOAP è derivato dalle tecnologie di interoperabilità esistenti al di fuori del Web e basato essenzialmente su chiamate di procedura remota, come DCOM, CORBA e RMI. In sostanza questo approccio può essere visto come una sorta di adattamento di queste tecnologie al Web.

Inoltre i Web Service basati su SOAP prevedono lo standard WSDLWeb Service Description Language, per definire l’interfaccia di un servizio. Questa è un’ulteriore evidenza del tentativo di adattare al Web l’approccio di interoperabilità basato su chiamate remote. Infatti il WSDL non è altro che un IDL (Interface Description Language) per un componente software. Da un lato l’esistenza di WSDL favorisce l’uso di tool per creare automaticamente client in un determinato linguaggio di programmazione, ma allo stesso tempo induce a creare una forte dipendenza tra client e server.

REST non prevede esplicitamente nessuna modalità per descrivere come interagire con una risorsa. Le operazioni sono implicite nel protocollo HTTP. L’approccio REST tende a conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l’elaborazione distribuita. Quindi, non è necessario aggiungere nulla a quanto è già esistente sul Web per consentire ad applicazioni remote di interagire.

La Notte dei Musei a Roma 2012

Sabato 6 ottobre torna a Roma “La Notte dei Musei”

Da quest’anno potete seguire la diretta Twitter dell’evento su #NDMroma12.

20121005-175622.jpg

Dopo il rinvio dello scorso maggio, La Notte dei Musei torna a Roma sabato 6 ottobre per una quarta edizione ancora più ricca di eventi.
La manifestazione, che avrebbe dovuto svolgersi lo scorso 19 maggio in concomitanza con altri Paesi europei e che è stata rinviata dall’Amministrazione Capitolina in segno di lutto e cordoglio per l’orribile attentato avvenuto la mattina stessa alla scuola Morvillo-Falcone di Brindisi, si svolgerà con aperture straordinarie fino a notte inoltrata dei musei e degli spazi culturali più importanti della città accompagnate da spettacoli e iniziative completamente gratuite.

L’evento è dedicato alla memoria di Melissa Bassi, la studentessa quindicenne che ha perso la vita nell’attentato.
La Notte dei Musei di Roma coinvolgerà quest’anno oltre 60 importanti spazi culturali ed espositivi della città, per una “no-stop” di 6 ore con circa 150 eventi e iniziative gratuite, tra musica, danza, cinema, teatro, letture.
I musei civici, i musei statali, i musei storici dell’esercito italiano, gli spazi privati, le biblioteche comunali, le accademie e le istituzioni culturali straniere, gli istituti e le case di cultura, della Capitale, saranno aperti straordinariamente e gratuitamente dalle 20 di sera fino alle 2 di notte. Sarà possibile visitare gratuitamente le mostre permanenti e temporanee ospitate dai musei interessati, assistere a concerti e performance, e partecipare ai tanti eventi in programma.
Tra gli spazi espositivi e culturali che apriranno gratuitamente al pubblico durante la Notte dei Musei, segnaliamo:

  • Musei Capitolini;
  • Centrale Montemartini,
  • Chiostro del Bramante,
  • Galleria d’Arte Moderna di Roma Capitale
  • Macro,
  • Maxxi,
  • Mercati di Traiano,
  • Museo dell’Ara Pacis,
  • Museo dell’Emigrazione – Complesso del Vittoriano,
  • Galleria Nazionale d’Arte Antica Palazzo Barberini,
  • Museo Nazionale Romano in Palazzo
  • Altemps,
  • Palazzo delle Esposizioni,
  • Planetario e Museo Astronomico,
  • Scuderie del Quirinale,
  • Casa del Cinema,
  • Casa del Jazz,
  • Casa delle Letterature.

Ecco il link al sito ufficiale con il programma completo:
notte dei musei 2012 roma

Informazioni

Luogo: Vari luoghi
Orario: dalle 20.00 alle 02.00 (ultimo ingresso ore 01.00)
Biglietto d’ingresso: Ingresso gratuito
Gratuito: Sì
Informazioni: 060608 tutti i giorni dalle 9.00 alle 21.00

Altre informazioni
La manifestazione promossa dall’Assessorato alle Politiche Culturali e Centro Storico di Roma Capitale, in collaborazione con la Presidenza del Consiglio dei Ministri – Dipartimento della Gioventù, il Ministero per i Beni e le Attività Culturali, la Camera di Commercio di Roma, e Il Gioco del Lotto. Main Sponsor Acea. Il progetto e il coordinamento organizzativo sono a cura di Zètema Progetto Cultura

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/10/05/1760/.