Conferenze DotCSS && DotJS @ Parigi 2014

Il team FrontEnd di Venere.com a metà Novembre è partito alla volta di Parigi per assistere a due dotConferences organizzate in location spettacolari, con relatori di alto livello e contenuti che si sono rivelati all’altezza delle aspettative, insomma un’esperienza da ripetere.

20141128_174734(2)

Il team FrontEnd di Venere, sono il secondo dal fondo :D
Team Selfie, da davanti, Daniele Amurri, Fabio Bucci di Monte, Claudio Corridore, Simone Rescio (io), Giorgio delle Grottaglie.

dotCSS

Nonostante la cruciale importanza che il CSS riveste nella costruzione delle moderne web application la conferenza, tenutasi il 14 Novembre, ha avuto difficoltà nel reperire degli sponsor, problema che ha determinato una notevole scarsità di gadgets e l’accorciamento della conferenza stessa da 8 ore a mezza giornata nel pomeriggio, ma l’accoglienza riservata agli spettatori nel Théâtre des Variétés situato nella centralissima Boulevard Montmartre è stata eccezionale.

Il teatro all’interno è maestoso, a fatica ha contenuto tutti gli sviluppatori accorsi per la conferenza nelle sue comode file e spalti. Gli organizzatori hanno svolto un ottimo lavoro nella divisione dei tempi tra i relatori e le pause ristoro con degli ottimi rinfreschi.

Ma bando al cibo parliamo dei contenuti della conferenza.

Daniel Glazman

Copresidente del CSS Working Group, Daniel ha esposto in che modo lavora il gruppo che definisce gli standard del futuro per il CSS, prediligendo una struttura orizzontale dove la voce di ciascuno abbia lo stesso peso, un gruppo il cui scopo fondamentale è quello di orchestrare i diversi interessi delle grandi società di tecnologia che lo presiedono.

Con malcelata insofferenza ha anche spiegato quali sono i problemi più frequenti a cui va incontro il gruppo durante il processo decisionale che investe gli stessi nomi delle proprietà future, nel tentativo di creare nomi semanticamente validi ma al tempo stesso contenuti evitando acronimi poco comprensibili, citando come caso da non imitare la proprietà flex che sta subendo diverse rivisitazioni per raggiungere un buon compromesso.

Perchè appunto di compromessi si tratta, nel mediare interessi diversi si giunge a delle vie di mezzo che accolgano in maniera ragionevole le necessità contingenti di tutti i partecipanti, motivo per il quale il risultato non sarà mai perfetto ed il lavoro rimarrà in perenne divenire.

Kaelig Deloumeau-Prigent

Sviluppatore FrontEnd presso FT Labs, Kaelig ha descritto il lavoro che ha svolto con il suo team nella creazione del nuovo sito del The Guardian creando un sistema di griglie e breakpoint per un sistema basato sul RWD (Responsive Web Design).

Al di là degli interessanti accorgimenti tecnici esposti nella definizione dei breakpoint ciò che è stato più interessante apprendere è il processo di lavoro instaurato tra le diverse figure che cooperavano sul progetto, il cui fulcro consiste nel mettere il design al centro del processo creativo ed incentrare su di esso i feedback tra gli sviluppatori ed i creativi.

La parte più importante sta nella definizione di un vocabolario condiviso tra le parti, allo scopo di facilitare sviluppatori e creativi nella discussione delle diverse parti di un progetto, e al fine di creare anche delle strutture SASS che rispecchino il più possibile questo vocabolario rendendo anche le modifiche future molto più semplici.

Harry Roberts

Lavorare a contatto con più sviluppatori e realtà aziendali per diversi anni permette di saggiare problematiche del mestiere che non sono sempre direttamente legate al codice bensì a come gli sviluppatori si relazionano tra loro, alla percezione del proprio lavoro e alle altre figure coinvolte nei progetti, esperienze che Harry ha codificato nei suoi 10 principi per sviluppare in maniera efficiente un progetto FrontEnd.

Sono dei consigli che si possono applicare a vario titolo anche ad altre tipologie di progetti, in senso lato il consiglio è di codificare dei propri principi in base alle proprie esperienze.

  1. The simplest option is usually the best
  2. Reduce the amount of moving parts
  3. Understand the business
  4. Care less, care appropriately
  5. Pragmatism trumps perfection
  6. Think at product level
  7. Do not design systems around edge-cases
  8. Do not make decisions based on anecdotal evidence
  9. Don’t build it until you’ve been asked for it
  10. Expect and accommodate change

20141114_144802

Lightnings talks

Aspetto interessante delle dotConferences è il fatto che oltre agli slot riservati ai relatori ufficiali della conferenza una piccola sessione è riservata agli spettatori che possono mandare preventivamente la propria presentazione agli organizzatori e quindi essere presenti sul palco, in questa sessione si sono succeduti quattro interessanti interventi.

Maxime Thirouin

Un succinto riassunto di ciò che tutti gli sviluppatori FrontEnd provano con il CSS viene proposto da Maxime : frustrazione. È uno strumento potente ma a volte frustrante, i preprocessori come SASS hanno risollevato la situazione introducendo molti degli elementi presenti da tempo nei maggiori linguaggi di programmazione utili anche per la costruzione ordinata di in un linguaggio dichiarativo, come le variabili per evitare ripetizioni ed operazioni matematiche basilari.

Maxime prova a portare questo concetto ad un livello più avanzato cercando di precedere i tempi con CSSnext, un preprocessore di sua creazione che permette di scrivere in sintassi CSS4 che viene poi compilata con selettori compatibili con i browser attuali.

Victor Brito

Le web app sono sempre più visivamente accattivanti ma Victor ha voluto ricordare l’importanza che riveste l’accessibilità nello sviluppo delle applicazioni, poichè concentrarsi unicamente sulle specifiche visive di un progetto porta ad avere delle strutture HTML che mal si conciliano con l’accessibilità minima per persone diversamente abili, rendendo futuri refactoring enormente costosi. Gli attributi WAI-ARIA sono già disponibili e pronti all’uso, non ignoriamoli.

Gregor Adams

Per avere una pagina HTML con un minimo di funzionalità è possibile anche fare a meno di JavaScript in alcuni contesti, Gregor ci mostra nella sua presentazione come sia possibile creare degli elementi che seguono una logica con il solo uso di CSS, in questo caso uno strumento per disegnare simile a paint.

Guido Boman

Similmente a Gregor, Guido ha esposto come si possa fare a meno di JavaScript per creare un effetto di parallasse utilizzando una intelligente combinazione delle properità CSS tridimensionali, tecnica appresa da un articolo di Keith Clark.

Hugo Giraudel

Nella  sua presentazione intitolata Keep calm and write Sass Hugo si è concentrato sul ruolo ausiliario che SASS ricopre nella produzione del CSS, il quale non deve monopolizzare la mente dello sviluppatore portando a scrivere tutto il foglio di stile esclusivamente in SASS. Inoltre come Kaelig ha voluto porre l’attenzione sull’importanza che riveste il fattore collaborativo nella stesura dei nomi per i mixin e le funzioni, e come scrivere dei nomi autoesplicativi aiuti gli sviluppatori che collaborano su un progetto ad avere una maggiore comprensione del codice.

Un punto importante è riservato alla documentazione che, anche in presenza di funzioni e variabili sufficientemente chiare, aiuta molto nel lungo periodo a manutenere un progetto che cresce nel corso del tempo, illustrando quindi il funzionamento di SassDoc, un progetto portato avanti da Hugo che permette la produzione di una documentazione web facilmente consultabile partendo dal parsing di commenti adeguatamente formattati inseriti nei file SASS come JSDoc per JavaScript.

https://speakerdeck.com/hugogiraudel/keep-calm-and-write-sass

Estelle Weyl

Autrice di numerosi testi sullo sviluppo FrontEnd, Estelle ha esposto nella sua presentazione diverse potenzialità poco sfruttate del CSS, quali la proprietà counter utile per enumerare contenuti, e come sovrascrivere la specificità della keyword !important usando la ripetizione di uno stesso selettore o l’uso di una keyframe animation vuota che descrive la proprietà da sovrascrivere senza la keywork stessa.

20141114_162534

Nicolas Gallagher

Sviluppatore FrontEnd presso Twitter, nella sua presentazione Nicolas ha presentato in che modo l’infrastruttura UI di Twitter è stata progettata avendo in mente la scalabilità del codice in modo che gli sviluppatori riescano a lavorare in maniera sufficientemente indipendente gli uni dagli altri, evitando il più possibile di annidare inutilmente i selettori così che ogni componente possa essere incluso in diverse parti senza creare problemi.

20141114_172832

Bert Bos

Può essere definito come il padre del CSS, esponendo gli scopi principali per i quali nacque il CSS, ovvero la formattazione dei testi, Bert espone alcune delle sfide che l’internazionalizzazione pone al fine di una formattazione semantica dei contenuti, evidenziando alcune differenze che esistono tra varie lingue nel posizionamento della punteggiatura per esprimere enunciati interrogativi, citazioni ed esclamazioni.

Scopo dell’intervento non è stato di dare una soluzione assoluta ai problemi esposti ma sollecitare la partecipazione degli spettatori al processo decisionale del gruppo, perché l’unico modo di influenzare l’evoluzione degli strumenti che usiamo quotidianamente è far sentire la nostra voce.

20141114_174625(0)

Ana Tudor

Come la maggior parte dei suoi esperimenti in materia di CSS, Ana ha saputo stupirci con una presentazione ad elevato contenuto tecnico nella quale illustrava come è possibile utilizzando Compass effettuare dei calcoli aritmetici per eseguire la distribuzione di una quantità configurabile di punti su un cerchio, avendo a diposizioni pochi elementi noti e ricavando con diverse formule matematiche quelli mancanti.

20141114_181919

 


 

dotJS

A causa di una serie di sfortunati eventi che saranno discussi più avanti non ho potuto assistere all’intera conferenza, tuttavia quel “poco” a cui potuto assistere è valso la pena della corsa.

Tenutasi due giorni dopo dotCSS, il 17 novembre nell’imponente Théâtre de Paris in una zona più a nord in Rue Blanche, con 900+ spettatori, dotJS ha avuto decisamente maggiore successo di sponsor, con WordPress, Zengularity e molte altre società che oltre alla location hanno finanziato dei rinfreschi di tutto rispetto per i numerosi spettatori.

Il formato è stato identico a quello di dotCSS, con 15-20min per ogni presentatore con massimo quattro presentazioni di seguito, quanto basta quindi per mantere alto il livello di attenzione, gli interventi hanno oscillato tra il molto tecnico e l’ispirazionale, seguiti da una breve pausa ristoro, questa volta resa un pò più difficoltosa dal numero quasi doppio di spettatori.

Ma di  nuovo, bando al cibo andiamo ai contenuti.

James Halliday

Con una shell proiettata sul grande schermo, James ha dato dimostrazione in diretta di come si possa rendere usabile una web application anche senza connessione una volta scaricati i contenuti principali usando la cache HTML5 e gestendo il sistema di autenticazione tramite il sistema asimettrico offerto dalle API HTML 5 crypto, in modo da continuare il proprio lavoro offline e sincronizzare i dati sul server appena possibile.

Il tutto viene illustrato in un suo progetto open source su GitHub chiamato KeyBoot che combina questi elementi.

20141117_102837

Charlie Robbins

Sul tema della giungla di dipendenze delle moderne web app, Charlie ha esposto il suo lavoro di analisi in merito a quale siano i sistemi di feedback più utilizzati dagli autori dei moduli per interagire con gli utilizzatori, ovvero la community, e in che modo gli sviluppatori mantengono aggiornate le dipendenze dei propri progetti illustrando il funzionamento del comando npm outdated per trarne delle statistiche su quali siano i pacchetti maggiormente utilizzati in produzione.

Justin Meyer

Autore di numerose librerie JavaScript open source e attualmente CEO di Bitovi, per Justin Il termine “best practice” può essere sinonimo di “lista di controllo”. Prendendo come esempio l’incidente B-52 nel 1994 ed il fatto che introducendo controlli all’aderenza dei protocolli di sicurezza prima di ogni operazione chirurgica si sono ridotti i problemi post operatori del 50%, spiega come l’attenersi al controllo di una semplice lista di domande con una risposta fatto/non fatto aiuta a mitigare rischi dovuti a banali dimenticanze, formalizzando una sua checklist basati sull’esperienza pregressa dei progetti a cui ha partecipato, della quale per ciascun punto è possibile valutare il fattore di rischio con la seguente formula :

se il valore è inferiore a 0 la scelta comporta potenzialmente più rischi che benefici, se uguale a 0 sarebbe neutrale in termini di costi, sopra lo 0 sarebbe ottimale per il progetto; ad esempio i test utente hanno un peso positivo di 0.45.

Domenic Denicola

Membro del developer team di Chrome, Domenic inizia la sua presentazione con una battuta esplicativa del suo progetto :

Se vuoi capire bene come funziona qualcosa, riscrivilo in JavaScript

jsDOM, progetto open source su GitHub, replica la struttura del DOM di una pagina al fine di renderla fruibile da Node.js, senza l’ausilio di strumenti intermedi come VM, selenium o phantomJS.

Un appunto interessante è stato apprendere come le specifiche del linguaggio JavaScript vengono definite, overro in WEBIDL che è un linguaggio vicino a quello umano ma traducibile direttamente in C++, sistema che Domenic ha replicato per portare buona parte del DOM in Node.

Lightning talks

Dopo una ricca pausa pranzo, si sono succedute quattro presentazioni relative a :

  • JSON Web token: un sistema di autenticazione basato su JSON sviluppato da Auth0
  • meteorJS: un framework open source per la costruzione di moderne web app in JavaScript che sta riscuotendo molto successo
  • pouchdb: un sistema JavaScript per la memorizzazione veloce dei dati ad uso delle applicazioni per facilitare la sincronizzazione quando si lavora offline
  • npm package quality: uno strumento per misurare la “qualità” dei pacchetti npm

Julien Lecomte

Team lead di YUI presso Yahoo!, Julien iniziato la sua presentazione sottolineando l’ossimoro del suo job title perchè proprio nel periodo in cui entrò a far parte della compagnia YUI era in proncinto di iniziare la sua fase di dismissione, e ciò che ha illustrato è proprio la strategia di migrazione che Yahoo! adotterà nel 2015 per abbandonare la sua vecchia libreria di elementi grafici per migrare ad un sistema modulare più snello e moderno.

La nuova versione di questa libreria si basera fin da subito su ES6, creando una CDN di polyfill che saranno serviti al browser in base all’user agent dell’utente se necessari, usando come libreria di support ReactJS.

Per evitare che la notizia dell’abbandono dell’attuale liberia creasse il panico tra i vari sviluppatori frontend della compagnia, portando ad una frammentazione determinata dal fiorire di una costellazione di iniziative difformi, Julien mise le mani avanti creando un woking group interno prima dell’ufficializzazione della decisione, in modo tale da affrontare in maniera unita la transizione e le decisioni da prendere per il futuro della libreria.

FormatJS sarà lo strumento principale per gestire l’internazionalizzazione delle UI, open source su GitHub e scritto in ES6, ma non tutte le web app di Yahoo! useranno gli stessi stack, per esempio nelle app B2B continuerà ad essere usato Ember.

Angus Croll

Senza nulla togliere agli altri presentatori, per me la presentazione di Angus è stata la più interessante. Facendo un parallelo con la letteratura classica ha messo in discussione una delle tendenze dure a morire nel campo della programmazione, ovvero quella di demonizzare a periodi alterni determinate parti di un linguaggio definendole “dannose”, argomento che ho trattato per le CSS table.

Nel corso del tempo sono diventati tanti e tali i costrutti JavaScript pontenzialmente dannosi, dalle variabili globali, l’uso della keyword this e molto altro, che seguendo alla lettera tutte queste indicazioni finiremmo per non poter scrivere neanche un riga di codice.

Al contrario ciò che la letteratura insegna è di abbracciare tutto il linguaggio, senza limitarsi a poche strade predefinite, perché il modo migliore di imparare è appunto sperimentare cose nuove.

Nell’approfondire questo tema Angus ha scritto un libro intitolato If Hemingway Wrote JavaScript, una raccolta di problemi comuni di JavaScript che vengono risolti con lo stile di diversi scrittori famosi riferendosi alle loro opere letterarie.

 


 

Perché presenziare?

Non avendo mai partecipato ad una conferenza di questo tipo è una domanda che mi sono fatto.

Nel giro di qualche mese i video delle conferenze saranno disponibili sul sito The dot Post che raccoglie tutti i materiali delle dotConference organizzate a Parigi, e molte delle slides presentate sono già disponibili online, in buona parte incorporate in questo articolo, quindi perché pagare il prezzo della conferenza oltre quello del viaggio e pernottamento?

Può sembrare banale ma il valore aggiunto è proprio quello di esserci, volendo fare un paragone la differenza è come quella che intercorre tra vedere uno spettacolo al teatro e vedere un film a casa. Vedere così tante persone, che condividono la tua stessa professione, i tuoi dubbi e i tuoi interessi, numerose e nello stesso posto, crea una forte sensazione di comunità e condivisione.

Le informazioni che ricevi vedendo il presentatore che si destreggia in diretta davanti ad una folla di persone tra le luci che lo accecano e vari piccoli incidenti tecnici di percorso (che nei video che saranno postati online non saranno presenti), rimangono impresse in maniera più vivida nella memoria.

Una tendenza di moltissimi, se non tutti, gli sviluppatori è di passare moltissimo tempo, anche dopo il lavoro, a studiare nuovi framework o linguaggi per rimanere costantemente aggiornati dimenticandosi di dedicare un tempo congruo ad attività “offline” o semplicemente riposarsi. Per una persona poco avvezza ai viaggi all’estero, magari non abituata a programmare visite per musei e monumenti, può essere un buon modo per staccare la spina, ma  non troppo.

Inoltre il modo migliore per sfruttare questo tipo di eventi in cui si radunano molti programmatori è fare networking, conoscere persone. In realtà si tratta di un obbiettivo più difficile di quello che sembra perchè:

  • I partecipanti generalmente vengono da nazioni diverse per cui parlano una lingua diversa dalla tua
  • Approcciare degli sconosciuti può farti sentire invadente, soprattutto se sei tendenzialmente introverso, come lo sono io

Mettendo insieme i problemi di natura caratteriale e linguistica, che si risolve grosso modo con l’inglese,  è abbastanza facile che ciascuna “comitiva di viaggio” interagisca solo con se stessa. Per prepararsi meglio il terreno può essere utile cercare di socializzare sui social network, generalmente twitter, dove vengono pubblicizzate queste conferenze in modo da “pianificare” in anticipo di conoscere degli sviluppatori che parteciperanno alla conferenza dove andrai.

Il fattore costo chiaramente non si può ignorare, una conferenza in una paese estero che richieda volo ed albergo è chiaramente una spesa importante, ma le conferenze tecnologiche si stanno diffondendo un pò ovunque a macchia di leopardo ed è possibile che ci siano degli incontri che si tengono anche in luoghi a portata di treno dalla tua residenza, infatti buona parte degli spettatori di dotCSS e dotJS erano francesi, di Parigi e comuni limitrofi. Un sito da tenere d’occhio per verificare la presenza di una conferenza abbordabile in termini di distanza/costo è Lanyrd.com dove è possibile filtrare per diversi criteri che vanno dagli argomenti trattati, la data o l’area geografica.

La sfiga™

Per quanto concerne la serie di sfortunati eventi che hanno determinato il mio ritardo all’inizio della conferenza, i fatti si sono svolti come segue :

Rientro in albergo il 15 sera dopo un’intera giornata passata camminando per visitare la città, mi spengo nel letto alle 21.

Risveglio al mattino il 16 : portafogli introvabile, con esso documenti di identità, carte di credito, biglietti aereo e della conferenza dotJS per il giorno dopo, probabilmente “smarrito” nel tragitto di rientro la sera prima.

Blocco telefonico di tutte le carte, stampa alla reception dell’hotel della copia della carta d’identità fatta all’atto del checkin e dei biglietti dell’aereo e della conferenza, santo Google Drive.

Prima tappa alla polizia francese, con l’aiuto del mio collega Claudio (terzo dal fondo vicino a me) che non esita un attimo a prestarmi una somma ingente per far fronte alla sparizione delle mie carte e dunque della mia liquidità, andiamo per effettuare la denuncia di smarrimento con la quale poi effettuare la richiesta del foglio di imbarco provvisorio, il poliziotto mi scrive su un foglio l’indirizzo dell’ambasciata, che sarà aperta solo lunedì (giorno della conferenza).

20141116_151254

Lunedì 17, mi sveglio prestissimo per fare tappa all’ambasciata italiana, edificio imponente con cancelli altissimi, solo per scoprire che svolgono solo compiti di tipo politico/istituzionale, pare che la polizia sia solita fare confusione tra ambasciata e consolato, sono le 8:10, la conferenza inizia alle 9 e devo andare praticamente dall’altra parte della città, ormai temo che la conferenza per me sia saltata, ho il volo di rientro alle 18 dall’aeroporto di Orly.

20141117_081115(2)

Corsa forsennata per fare tre cambi di metro ed arrivare al consolato Italiano, che sembra una scuola media in periodo di elezioni adibita a seggio elettorale, dove un sosia di Lino Banfi da una guardiola insonorizzata mi abbaia di lasciare fuori il mio bagaglio a mano, in un cortile con cancello aperto senza vigilanza, perplesso e confuso obbedisco per non creare inutili attriti, mi consegna un modulo da compilare, chiedo se posso avere una penna per compilare però mi fa cenno di entrare quindi entro.

20141117_091314(2)

Passato il gabbiotto sono dentro a quello che invece sembra un piccolo ufficio postale con cinque sportelli, poche sedie spoglie e poca gente in fila, sono quindi fiducioso di fare in tempo. Mi rivolgo di nuovo a Lino per chiedere di nuovo gentilmente una penna per compilare il modulo che mi ha dato, risposta: “Insomma che voi? Na penna? Basta chiede eh!”, dirotto tutte le mie energie mentali sul mantenere insieme i cocci della mia maschera di cortesia ormai prossima a crollare in mille pezzi, sfodero un luminoso sorriso mentre mi porge burberamente quella maledetta penna, compilo e mi metto ad aspettare.

Pochi minuti e finalmente vengo chiamato, ma ad un passo dalla compilazione del tanto agognato foglio di imbarco lo sportellista si ferma e non me lo rilascia perché nota che la compagnia di andata e rientro combaciano e trattandosi di EasyJet con cui sono in vigore accordi internazionali in caso di furto/smarrimento dei documenti la denuncia di smarrimento fatta alla polizia è sufficiente, faccio notare che parlando al telefono il giorno prima con il customer care di EasyJet mi era stato precisato che è a discrezione dello scalo accettare il passeggero con la sola denuncia mentre per la certezza matematica dell’imbarco serve quel foglio, ma lo sportellista non ne vuole sapere.

Dubbioso e preoccupato di cosa potrà succedere al gate guardo l’orologio, sono le 9:35, se corro faccio ancora in tempo, altra corsa con il trolley a seguito per ritornare alla stazione della metro, arrivo al Théâtre de Paris, sono le 10:10, conferenza semi-salva 🙂

20141117_101607(2)

Dopo aver assistito ai talk di cui sopra, sono dovuto scappare alla volta di Orly per arrivare in tempo per il volo di ritorno, passati tutti i controlli di sicurezza con la sola denuncia alla mano arrivato al gate, è il momento della verità, chiedo se ci sono problemi e…no non ce ne sono, ho potuto baciare la pista di Fiumicino alle 20:30.

Come evitare di rimanere bloccati all’estero

Come al solito la vita prima ti da il test e con la mazzata impari la lezione, quindi quello che segue è la lezione che ho imparato “the hard way” per non rimanere inguaiati oltre i propri confini :

Non portare il portafoglio, telefono o altri oggetti sensibilissimi nelle tasche posteriori dei pantaloni, sempre e solo nelle tasche interne della giacca o altro posto difficilmente accessibile da mani invadenti. In cinque anni a Roma mai successo niente, cinque giorni a Parigi e il mio portafoglio non ce l’ha fatta…

Tieni nel portafoglio solo l’indispensabile, un documento di riconoscimento, una carta di credito e poco contante, qualunque altra cosa deve restare o a casa prima della partenza o in valigia.

Nella valigia deve esserci almeno una seconda carta di credito ed un secondo documento d’identità valido.

Se per l’imbarco hai usato la carta d’identità portati dietro il passaporto, così che se riuscissero a scippartelo avresti comunque il documento principale per il ritorno salvo, lo stesso vale per le carte, che devono essere rigorosamente due prepagate.

Rifare il bancomat di un conto corrente è una trafila diabolica e senza di esso sarai impossibilitato a compiere operazioni basilari come i bonifici, mentre per i prelievi potrai solo andare agli sportelli fisici con un libretto di assegni legato al tuo conto e fare un assegno a te stesso per ritirare.

Ultimo ma non per importanza, verifica sempre le informazioni che ti vengono date anche se la fonte è “autorevole”, una telefonata all’ambasciata mi avrebbe evitato di correre come un matto con un trolley a seguito di lunedì mattina per raggiungere il consolato.

Foto di Parigi

Sfruttando i due giorni di buco tra le due conferenze ho avuto l’occasione di farmi una bella passeggiata per la città, nel bene e nel male, au revoir Paris!

20141115_174940

SmartCamera_1416004358994

https://sresc.io/4cf

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.