Report e pubblicazioni

Sviluppo Front-End: ottimizzare le prestazioni

Riccardo Petracchini — 2013-02-18T13:00:00Z

Per quanto riguarda lo sviluppo front-end, c'è sempre più attenzione alle performances, dato che favorendo la velocità dell'esperienza utente c'è un ritorno diretto in termini di soddisfazione da parte di chi fruisce il progetto web.

E' uscito da poco un articolo molto curato sull'argomento che ha attratto la mia attenzione:

Front-end performance for web designers and front-end developers di Harry Roberts.

Nell'articolo vengono illustrati e sintetizzati molti degli argomenti relativi all'ottimizzazione dello sviluppo front-end.

Si parte dalle regole basilari: gli stili css devono essere chiamati all'inizio della pagina mentre i file javascript in fondo ad essa. Questo è un punto essenziale, dato che i browser eseguono il render della pagina progressivamente e prima hanno a disposizione il css, prima ne possono iniziare il render sulla pagina, evitando di bloccarla graficamente.

Al contrario le chiamate javascript, bloccando i browser nel processo di download parallelo delle varie risorse, devono essere posizionate in fondo alla pagina. La loro natura bloccante deriva anche dal fatto che ogni singola risorsa js deve essere caricata nell'esatta sequenza.

In generale è bene fare il minor numero di chiamate possibili a risorse, cioè scaricare il minor numero di elementi effettuando così poche HTTP Request. Ogni chiamata tecnicamente può incorrere in un "DNS lookup", in un redirect o in un errore 404 di risorsa non trovata; per questo ridurle contribuisce sensibilmente ad ottimizzare l'esecuzione.

Idealmente si dovrebbe massimizzare il parallelismo nell'ottenere risorse da domini diversi. Dato che un browser può al massimo trattare due risorse alla volta da uno stesso dominio, possiamo moltiplicare questo numero per il numero di domini dal quale possiamo servire le risorse.

Molti siti conosciuti fanno uso di domini "statici" solo per questo motivo, ottenere le risorse da più domini. In abbinamento alla tecnologia CDN (Content Delivery Network), ciò consente di diminuire ulteriormente la latenza di tempo ottenendo così le risorse anche da più luoghi dislocati fisicamente nel mondo.

Le richieste HTTP e il tempo per la risoluzione dei nomi DNS possono quindi rappresentare uno dei principali colli di bottiglia nelle prestazioni di front-end dato il limite nello scaricamento di risorse in parallelo imposto dai browsers. D'altro canto, la tecnica dell'utilizzo di sottodomini per aumentare le possibilità parallele introduce ad ogni nuovo dominio il tempo di latenza della risoluzione del nuovo nome DNS, quindi va valutato accuratamente caso per caso se sia possibile farsi carico di questo ulteriore tempo nel progetto web di cui ci si sta occupando.

Nel caso in cui servano nuovi nomi di dominio, è utile utilizzare la tecnica del DNS prefetching attraverso la quale semplicemente si comunica in anticipo al browser il nuovo dns dal quale, poco dopo, sarà necessaria una risorsa; facendo così si riescono a evitare i tempi di attesa per la risoluzione del nuovo dominio.

In realtà questo introduce il concetto di prefetching generale delle risorse; oltre ai DNS, anche le altre risorse come i web fonts o le immagini chiamate dai fogli di stile possono essere chiamate in anticipo in modo da iniziarne il download leggermente prima del loro effettivo utilizzo.

Per fare questo esistono due vie:
- una sporca e sicura, che prevede di celare in un

nascosto le immagini per averle a disposizione nell'html della pagina molto in anticipo
- una più pulita ai puristi del codice, che è sostanzialmente sempre il link prefetching già visto per i DNS.

Invece, per quanto riguarda l'ottimizzazione delle chiamate css è fondamentale sapere che non devono mai essere fatte da un un altro dns, data la loro natura bloccante sulla resa grafica della pagina; così facendo infatti si incorrerebbe nel DNS lookup, ovvero nel tempo ulteriore necessario alla risoluzione del nuovo dominio.

Oltre a servire il css il prima possibile nella pagina, bisogna concatenarli, ridurli al minimo rimuovendo commenti e spazi e comprimerli per diminuire il lavoro da parte del browser e dei vari sistemi di caching. I software di editing css contemporanei hanno tutti funzioni per controllare anche questi aspetti; in aggiunta, se si usano linguaggi di preprocessing dei css come sass si hanno a disposizione potenti strumenti per curare nei dettagli tali operazioni.

Senza entrare troppo nel dettaglio della compressione possibile usando gzip su server attraverso Apache, passiamo all'ottimizzazione delle immagini.

Si parte dalla ben nota tecnica di spriting delle immagini, ovvero del raggruppare in un'unica immagine tutte quelle che possono servire nel file css, in modo da ridurre al minimo il numero di http Request a questo tipo di risorsa. Anche se non tutte le immagini possono essere messe in uno sprite - ad esempio quelle da usare come sfondo, che vanno ripetute e che spesso vengono messe negli sprite con molti pixel vuoti attorno in modo da poter ottenere la ripetizione necessaria. Ma i pixel vuoti, non necessari, sono un problema nella velocità di esecuzione. L'articolo suggerisce di usare il classico "elemento di spriting", solitamente , che ha il solo scopo di rimanere vuoto e portare l'immagine di sprite come sfondo. Ecco l'esempio di utilizzo più comune:

Profile

L'articolo di Harry Roberts tocca anche il caso delle immagini Retina solitamente usate per i dispositivi mobile, in modo da garantire ad essi che hanno capacità di memoria inferiori, esperienze estetiche superiori, ma in generale l'autore ritiene che vadano scelte oculatamente. Tutto sommato esistono anche valide alternative alle immagini bitmap, come svg o font di icone.

Infine, l'ultimo argomento dell'articolo: le immagini JPG progressive.

Riguarda più che altro la velocità percepita nell'esecuzione, infatti a differenza dei JPG che si caricano per blocchi successivi, i jpg progressivi sono caricati interamente fin dall'inizio ma pixelati e solo progressivamente aumentano di dettaglio, un po' come accadeva per le vecchie gif. Ciò contribuisce molto alla percezione di rapidità visiva che avrà l'utente.

L'articolo portato alla vostra attenzione è ricco di approfondimenti come questo sui jpg progressivi: il mio invito è di tornare a ricercare ogni singolo approfondimento direttamente alla fonte.

Image by courtesy of: Silvia Cesari

css: riconoscere i problemi prima che sia troppo tardi

Riccardo Petracchini — 2012-12-20T10:00:00Z

Continua la rassegna di consigli per la lettura, questa volta non con un libro ma con un interessantissimo articolo nel quale mi sono imbattuto e che voglio condividere con voi.

Citiamo subito la fonte: Code smells in CSS.

L'articolo ha suscitato subito il mio interesse perché mi sono trovato nelle stesse condizioni dell'autore: lavorare per mesi in modo continuativo allo sviluppo frontend di progetti web di dimensioni rilevanti.

Nel lavoro di ogni giorno come sviluppatori css, ci si trova spesso di fronte a situazioni che non quadrano nel loro impianto progettuale: in questo articolo vengono mostrati alcuni esempi concreti di css che fanno percepire queste situazioni. Imparando a riconoscerle, possiamo riuscire a evitarle prima di arrivare a un punto di non ritorno.

Andiamo quindi a vedere nello specifico alcuni di questi passaggi di codice che possono essere la cartina di tornasole della qualità del css e della sua mantenibilità futura.

Disfare stili già impostati in precedenza
Ogni volta che siamo costretti a rimuovere uno stile già dato in precedenza abbiamo un un piccolo sentore di bruciato nell'aria. Resettare uno stile, al di là dei css di inizializzazione come i reset css, ci fa pensare al fatto che, forse, quello stile lo si era impostato troppo a monte nella cascata di ereditarietà connaturata al linguaggio css.

Un bell'esempio pratico:

h2{
font-size:2em;
margin-bottom:0.5em;
padding-bottom:0.5em;
border-bottom:1px solid #ccc;
}
.no-border{
padding-bottom:0;
border-bottom:none;
}

In questo caso, prima si definisce uno stile molto generico per gli h2, poi con una classe dal nome terribile si resettano alcune proprietà, utilizzando sostanzialmente un approccio sottrattivo.

Il caso ideale sarebbe, invece:

h2{
font-size:2em;
margin-bottom:0.5em;
}
.headline{
padding-bottom:0.5em;
border-bottom:1px solid #ccc;
}

Dimezzando il numero di righe di css si dà lo stile ai titoli di secondo livello; con una classe significativa si riprogetta l'approccio css in senso additivo, anziché dover rimuovere stili già dati precedentemente.

Questa piccola osservazione sembrerebbe cosa di poco conto, ma se la trasliamo ad un vasto progetto web che coinvolge migliaia di righe di codice css, riusciamo a comprenderne tutto il potenziale. Questo approccio ci consentirebbe di ribaltare la prospettiva dello scrivere moltissimo css per raggiungere meno stile.

Gli altri segnali di fumo che ci indica Harry Roberts, autore dell'articolo, sono i seguenti (li accennerò brevemente senza entrare nel dettaglio, in modo che possiate approfondirli direttamente alla fonte):

Numeri magici
sono i valori numerici utilizzati dentro al css solamente perché funzionano nella singola circostanza e risolvono momentaneamente il problema. Chi di noi non ha mai usato un numero magico, scagli la prima pietra! Spesso la fretta ci impone di trovare una soluzione veloce e che funzioni subito, ma se non estrapoliamo la specificità del numero magico dal contesto andremo incontro a problemi soprattutto quando dovremo spiegare ad altri sviluppatori il suo uso, o quando passerà del tempo e non riusciremo più a risalire al motivo del loro utlizzo. I numeri magici non sono affidabili, statene alla larga!, suggerisce l'autore

Selettori css eccessivamente qualificati
Sono quei selettori che specificano anche l'elemento html al quale si riferiscono:

ul.nav{}
a.button{}
div.header{}
è molto evidente come tali selettori inibiscano il loro utilizzo su elementi html diversi da quelli specificati; aumentano la specificità, innalzando quindi anche i tempi di lavoro del browser nel gestire tale comando css composito. E' sempre necessario ridurre la specificità dei selettori per migliorarne la portabilità, per migliorare le performance e ridurre la quantità di codice

Valori assoluti hard coded
Valori assoluti inseriti nel codice vanno sempre trattati con cautela e sospetto. Ci si deve sempre chiedere il perché del loro utilizzo e se non fosse stato meglio adottare una soluzione più flessibile verso il futuro

Forza bruta dei valori e dei selettori
In fondo, è sempre lo stesso discorso: a volte si fa prima a forzare con valori precisi o aumentando la forza della specificità, ma ciò nasconde sempre una mancanza di comprensione più generale del singolo contesto e un approccio alla sua portabilità. La conoscenza solida tiene sempre alla larga dalla forza bruta

Selettori pericolosi
Sono i selettori ad amplissimo spettro, che colpiscono tutti gli elementi di riferimento in tutti i contesti, cosa che implica il dover tenere sotto controllo gli elementi in ogni possibile contesto: es. div{ } "fai questo, div!" (perché? volete forse dirmi che voi non parlate con i vostri div??). Da qui l'assunto che selettori troppo generici possono provocare danni in contesti che attualmente non sono sotto un'attenzione vigile e costante

Direttiva !important reattiva
Si sa che la direttiva !important deve essere usata solo in certe circostanze, ma soprattutto deve essere usata in modo proattivo e non in maniera reattiva, ovvero per vincere altri selettori troppo specifici e far funzionare le cose. Un esempio classico dell'uso proattivo sono le classi di errore con colorazione rossa, si sa sempre in anticipo che esse dovranno"vincere" sulle colorazioni neutre. L'uso reattivo è un sentore di puzza di bruciato, è l'aggiramento temporaneo di un problema forse relativo a un intero impianto progettuale css che presenta criticità.

Uso degli ID nei selettori css
L'autore arriva ad affermare che gli id nel css non andrebbero mai usati. Mai. Andrebbero usati solamente come hook javascript o identificatori degli elementi html. Sappiamo bene che gli id sono univoci, utilizzabili solamente una volta nella pagina, identificano un elemento specifico invece di rivolgersi all'astrazione di una situazione più generica. Inoltre aumentano esponenzialmente la specificità dei selettori, per ogni id servirebbero 257 classi...

Nomi delle classi troppo vaghi o generici
Nomi troppo vaghi o generici ci espongono invece a rischi di fraintendimento, non dichiarano immediatamente a quale precisa situazione si riferiscono con il rischio di accavallamenti di senso con situazioni simili ma diverse. L'autore cita ad esempio .card.

Concludendo: è vitale, quando si hanno per mesi sotto gli occhi migliaia di righe di codice css, tentare di estraniarsi dai contesti specifici e cercare di avere anche una visione al di sopra di tutto, che abbia cura dell'intero impianto progettuale.

E dato che parliamo di un linguaggio, personalmente ritengo che non basti soffermarsi solamente su due versi poetici azzeccati o su un fraseggio, ma occorre considerare sempre l'atto poetico nel suo insieme.

Ripensare l'architettura dei css con smacss: un libro da Johnathan Snook

Riccardo Petracchini — 2012-11-09T13:00:00Z

Una delle frasi che più mi hanno colpito durante gli anni di studio dei css è stata questa: “css one day to learn, one life to master”.
Mi trovo in pieno accordo con questa citazione, perché una delle prime cose che si impara quando si studia css è che non si finisce mai di imparare.

Un altro libro sull'argomento di qualche anno fa titolava “Everything You Know About CSS Is Wrong!”: certo, un titolo forte, che introduceva una tecnica ben precisa proponendone un nuovo approccio, un titolo che in risonanza richiama la stessa idea alla base del libro di Johnatan Snook del quale voglio parlarvi oggi: SMACSS, Scalable and Modular Architecture for CSS.

A prescindere da quello che sapete, va ripensata l'architettura dei css, in modo da riorganizzarli in un sistema scalabile e modulare.

Snook parte proprio dalla categorizzazione dei css e della loro ri-organizzazione in 5 spazi definiti, dove scrivere linguaggio css orientato alla definizione di regole generali e alla codifica di pattern riutilizzabili, con la dovuta attenzione alle eccezioni.

Le 5 categorie che propone sono: base, layout, module, state e theme, rigorosamente abbinate a una “naming convention” strettamente autoesplicativa, ovvero spazi dedicati ai selettori semplici composti da singoli id o classi e spazi dedicati ai moduli “standalone” focalizzati al riutilizzo del codice. I moduli stessi arrivano ad acquisire funzionalità specifiche attraverso il “subclassing” del modulo di partenza, e quindi una caratterizzazione basata su un contesto più dettagliato.

Altro spazio importante è quello dedicato ai vari cambiamenti di stato raggruppati nelle loro 3 sotto-sezioni: cambiamenti di classe attivati con la complicità di javascript, cambiamenti di pseudo-classe e cambiamenti di media-query. L'intento dell'approccio smacss di Snook è sia quello di definire due categorie distinte per i moduli e per i cambiamenti di stato generici, quindi due file css distinti, ma nello stesso tempo è anche quello di accompagnare ogni singolo modulo con i suoi cambiamenti di stato specifici, ad esempio su singoli break-points definiti.

Altro punto chiave è la profondità di applicazione dei selettori che determina l'aumento della connessione fra css e html: diminuendo questa profondità si migliora la scalabilità dei moduli. Arrivando ad ottenere così un equilibrio fra il mantenimento, le performance e la leggibilità del codice css.

Un piccolo esempio semplice ma applicativo del suo ragionamento sui selettori:

#sidebar div, #footer div{
border: 1px solid #333;
}

cambierebbe in

.pod{
border: 1px solid #333;
}

In sostanza la seconda soluzione, pur facendo riferimento a una particolare struttura html ben precisa, rimane tuttavia a un livello di profondità inferiore rispetto al caso precedente; occorre traslare questo ragionamento a progetti complessi e selettori ad alta profondità, per comprendere a pieno i benefici di questa variazione di approccio.

Il libro prosegue con altri punti di approfondimento come appunto le performance dei selettori, il ruolo dei preprocessors e casi più avanzati e complicati di ereditarietà.

Un'ottima lettura ricca di spunti su cui riflettere e, per quanto mi riguarda, fare retrospettiva sui progetti di vasto respiro e dimensione sui quali si lavora quotidianamente.

BetterSoftware? BetterTeams, BetterPeople!

Massimo Azzolini — 2012-10-02T09:30:00Z

Dopo aver saltato l'edizione 2011, mercoledì scorso sono tornato a BetterSoftware. Il format dell'evento è rimasto lo stesso: speaker con profilo alto, focus sul migliorare, una due giorni intensa.

Organizzazione, gestione dei team, neuroscienza (!?), emozioni, metriche, startup: questo è stato #bsw2012

Quello che ho trovato di diverso sono stati i contenuti. Si è parlato di tecnologia e di software, chiaramente, ma i talk predominanti, quelli con tanto pubblico, quelli che ti hanno dato qualcosa da portare a casa e su cui riflettere, sono stati altri. Ho partecipato ad una conferenza sul software e si è parlato di sociologia.

Il nostro zio preferito

Conto di aggiornare il post con il link alle presentazioni su slideshare (non appena lo zio le "posterà"); per il momento accontentatevi di questo

Parto da @ziobrando, al secolo Alberto Brandolini. Due talk: "Stai guardando i dati sbagliati" e "Fare pipì controvento".

In breve il punto è:

perché stai gestendo nel peggiore dei modi i tuoi dati?

perché persone intelligenti prendono decisioni stupide?

A proposito di dati, dobbiamo ragionare meglio sul dominio in cui questi dati esistono (non a caso il DDD è uno dei suoi ambiti preferiti). Non si tratta solo di memorizzare byte, ma di salvare semantica, stati, eventi.

Sì, semantica, perché una bozza di offerta non è un contratto: l'una è modificabile mille volte, ha un modello di accesso ai dati prettamente RW, l'altro - una volta firmato - non lo tocchi più, ma lo leggi molte volte.

Il modello di sviluppo ad eventi (see Greg Young) può essere molto utile: quello che le macchine sono in grado di fare benissimo è ricordare e ripetere. Notificare al mondo l'evento "ho creato un contratto" e lasciare che altre applicazioni specifiche agiscano di conseguenza è molto preferibile rispetto a far sì che la nostra applicazione si prenda carico di compiti non suoi.

Ma soprattutto, nella fase di definizione dei modelli logici, la semantica che diamo alle parole varia in base all'ambito. Ciò che ha un senso per il marketing non lo ha per la produzione.

Nello spiegare come le persone prendono decisioni Alberto, ma anche altri, ha fatto riferimento a Kahneman (un buon disegno spiega molto). Alberto mi ha lasciato due aspetti su cui sto riflettendo: l'essere umano è una macchina pensante e funziona in due modi (veloce/senza riflettere o viceversa) e che c'è un motivo se è "sempre colpa dell'IT".

lo zio ha postato le prime slide "Fare pipì controvento" e qui sotto quelle del secondo talk:

Giochi che fanno pensare

Roberto "taz" Bettazzoni e Gaetano Mazzanti hanno deliziato la platea (proprio così, deliziato: raramente ho visto facce così felici) con due allegri "giochini": cynefin lego game e kanban pizza game.

La ricetta è semplice: prendi delle ignare vittime, illudile che sarà divertente (pizza..., lego...) e mettile in situazioni di gestione del team e del lavoro sempre più complesse. Se ne andranno divertite, ma non smetteranno di pensare a come potevano gestire meglio la situazione.

Il lego game è un gioco molto adatto a mettere in difficoltà i manager.

Ci sono 4 tipi di situazioni in cui ti puoi trovare: semplice, complicata, complessa e caotica. Le prime due situazioni sono gestibili, le altre due devono essere ricondotte ai casi precedenti. Pena il fallimento.

Puoi molto velocemente passare dalla prima all'ultima, mentre è estremamente difficile ritornare indietro. Devi imparare a sopravvivere, ma soprattutto a capire quando ti trovi in quella situazione. E' quello che il Taz chiama spesso "puzza".

Il pizza game, invece, insiste più sulle logiche di team, sul capire il valore della velocità di realizzazione (più produco, più guadagno) di un compito, ma anche sul bilanciare questo fattore con lo spreco dato dalla produzione e sulla qualità di quanto si è prodotto.

Oltre a questo è difficile spiegare a parole: va provato.

Andrea "o' diplomatico" Pernici

I siti devono andare più forte, e devono farlo oggi perché domani sarà ancora più difficile. L'aspetto positivo è che siamo fortunati: si può fare.

Dire che è stato un tornado è dire poco. E' entrato a gamba tesa su tutto. E ha ragione su tutto.

Il suo messaggio è stato semplice e disarmante al tempo stesso: "caro programmatore, scegli pure il tuo linguaggio preferito, il db ottimizzato, il framework "figo", ma alla fine se il 90% del tempo di attesa del tuo utente è sul browser... hai dimenticato qualcosa!"

Ecco le sue slide. Non scorrerle: leggile con attenzione, poi ripensaci con calma. E impara a memoria la numero 40.

Aho, so' Jacopo

Jacopo Romei è un grande: se ne viene fuori di tanto in tanto con "romanismi" chiarificatori passando allegramente da (ancora) Kahneman alla teoria eliocentrica con assoluta padronanza.

Due talk spassosissimi, ma densi di spunti:

Cercando il cigno giusto

Hey, il senso comune non c'entra nulla!

Il cigno giusto è quello nero raccontato da Taleb. Una letta a questo post aiuta moltissimo. L'obiettivo è quello di trovare il modo migliore di "coprirsi di soldi" facendo consulenza.

Partendo dai concetti di "mediocristan" ed "estremistan" Jacopo ci offre un modello di business che tenda a esaltare il valore di ciò che si fa in contrapposizione al tempo necessario per farlo.

Guardate anche le sue slide:

Misura le emozioni

Di Luca Mascaro e Michela Perotti vi lascio giusto il concetto di base che mi è rimasto e la loro presentazione. Ci sono spunti che devo e voglio ancora approfondire:

L'esperienza positiva è un'esperienza "mediamente" positiva. Importante che la prima impressione lo sia, che ci siano momenti "wow" e che alla fine si rimanga soddisfatti.

Impressioni?

Parlo per me, ma credo che anche per i miei allegri compari (Stefano, Irene e Andrea) è stata l'ennesima riprova che non c'è un limite alle cose che puoi imparare. Bel pippone, eh? ;-)

Beh allora guarda un po' quanto ci siamo divertiti! E il prossimo anno non mancare!

The Treasure of Frontend Island

Riccardo Petracchini — 2012-09-25T12:30:00Z

Era da marzo che aspettavo di andare al fronte, a vedere le cose dalla prima linea.

Lo so, sembra l'inizio di un romanzo di Hemingway e invece sto solamente parlando della conferenza "The Treasure of Frontend island" organizzata da “from the front” a Bologna al teatro Duse, una picaresca giornata trascorsa insieme ad alcune delle menti più brillanti di questo fantastico mestiere.

Steve Krug -YOU'RE NOT DOING USABILITY TESTING? ARE YOU… NUTS?

Si inizia subito con un mostro sacro dell'usabilità come Steve Krug, quello di “don't make me think” che introduce il suo intervento con una simpatica discussione a fumetti fra le figure del developer, del designer, del Project Manager e del Marketing.

Secondo Steve bisognerebbe fare test di usabilità più agili e semplici, concentrati in un'unica giornata mensile in cui si osservano gli utenti - che non sono come noi, non hanno le nostre basi personali - e in questo modo si potrebbe arrivare veramente a testare l'uso di ciò che creiamo. Mentre per ora, la verità è che la maggior parte dei siti non viene testata. Ce ne da' subito una dimostrazione concreta con un volontario dal pubblico al quale fa fare un test di una bellissima app per iPhone che si chiama Clear.

Emergono nozioni interessanti: non bisogna testare troppo tardi nel processo, mai alla fine dello sviluppo, ma sempre il prima possibile, quando ci si sta ancora lavorando.

Occorre pensare sempre: "What's the smallest change that might solve?", cioè identificare i possibili tweaks. Il concetto di tweak per lui è centrale e ne snocciola tutte le ragioni che lo valorizzano rispetto alle vaste operazioni di re-design, che spesso non arrivano. Sostanzialmente “cost less, less work, change sooner”, solo per dirne alcuni.

Peter Paul Koch - A PIXEL IS NOT A PIXEL (slide)

Poi prende posto sul palco, di fianco ai barili di rum, PPK, Peter Paul Koch, per me un vero mito vivente dalle prime letture su javascript a quirksmode.org (chi ancora ricorda da quale modalità di IE derivava questo nome?).

Si addentra subito nella complessità articolatissima del pixel, che non è più il pixel di una volta.

Ne esistono di 3 tipi: i css pixels (un construtto astratto), i density-indipendent pixels (Dips) e i device pixels, che aumentano costantemente nei dispositivi di nuova generazione.

Prosegue sempre con i tipi di pixels ma visti da javascript, poi introduce i viewports con un'immagine di una fessura di una chiave sul quadro della Gioconda molto esplicativa. I viewports diventano molto complessi su mobile e ce ne sono di vari tipi: visual? o layout?, soprattutto dipendono anche dai browser. PPK passa agilmente dallo zooming alle media queries, ma con un sorriso da stregatto domanda: "sì, ma quali???", quelle basate su device-width, le width queries semplici o le viewport queries basate su width = device-width?

La complessità si snoda rapida fra i suoi pensieri fino a culminare nel mal di testa, come avvertiva il disclaimer al suo intervento, quando chiude asserendo sì, ma "width of what ???". Conclude sicuro con la miglior combinazione per fare responsive oggi, derivata da questo quadro complesso.

(alcuni approfondimenti http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html)

Denys Mishunov - SCIENCE OF DESIGN (slide)

Dopo personaggi di questo calibro tocca a Denys Mishunov che risale alle radici storico-artistico-filosofiche del design e tocca tutta la classicità dell'argomento: sezione aurea, regola dei terzi, proporzioni e rapporti numerici dietro le relazioni visive e spaziali, teoria del colore.

Ma soprattutto in una delle sue dettagliate slide, una lezione sul contrasto, prendendo una foto di Ansel Adams per analizzarne la composizione, le linee e gli accurati contrasti. Un fotografo che adoro e sul quale hanno da poco fatto una personale a Modena. Applausi.

Remy Sharp - MOBILE DEBUGGING (slide)

E' il turno di Remy Sharp; questo, fra tutti i talk, era quello che mi aveva più incuriosito, già dalla sua descrizione: “mobile debugging is a bitch !”. In realtà è una vera e propria dichiarazione di amore verso l'arte del debug, della quale Remy va ad elencare i sacri principi: replicare, isolare & eliminare.

Il suo filo conduttore rimane sempre “expect the unexpected” e soprattutto non usate simulatori ma dispositivi reali. Uno degli scrigni del tesoro trovati in questa giornata di studio è sicuramente in questo intervento: infatti Remy lancia dobloni preziosissimi, nuovi tool e strumenti per il debugging mobile ancora poco conosciuti. Eccone alcuni da annotare:

jsconsole.com | Charles | fiddler | weinre | iwebinspector | jsbin.com | shadow di adobe con la plugin browser | Chrome for android | :6000 e remote debugging in FF mobile | remote-tilt.com | slowly.app | sloppy

Blaine Cook - INVENTING THE NEW WORLD

Blaine non lo conoscevo; con il suo intervento la mia attenzione parte un po' in sordina, anche a causa del mancato coffee break, ma mi rendo subito conto che dall'intervento tecnico di prima siamo passati a una pura visione astratta di pensiero.

Per Blaine abbiamo assunzioni cieche che ci impediscono la scoperta di nuovi territori. Bisogna innanzitutto rimuovere la paura di avventurarsi, perché è tutto sotto i nostri occhi, occorre solo saperlo vedere. Il suo stimolo punta direttamente al non accontentarsi delle strade già percorse ma al trovare nuove mappe. E quale posto migliore per dirlo ad una conferenza che si chiama così? La sua sensibilità di viaggio è una piacevole scoperta così come il suo divertimento a cliccare su una mucca colorata! (click.cow)

Linda Sandvik - MAKING THINGS BETTER

Linda è qui sul palco del Duse ed è la prima volta nella sua vita che fa una conferenza così; quando lo dice lascia il pubblico ammutolito, è la prova vivente del suo talk, come uscire dalla propria “confort zone” e provare tutto nella vita, facendo qualcosa di diverso ogni giorno, anche se piccolo. Perché la prima cosa da fare per Linda è imparare a fallire: "fail, fail fast, fail often", ovvero avere confidenza con il fallimento, e lei è qui anche per raccontare i suoi.

Una volta impostato un ambiente di lavoro che non teme il fallimento, anzi è confidente con esso, si ha la serenità necessaria per l'innovazione, per la sperimentazione, per l'invenzione. Linda tiene un "crash course" di vita sul provare cose nuove, sull'imparare ad imparare, sul creare una propria strada all'innovazione basata anche sulla fortuna, la fortuna di scoprire cose che gli altri non hanno ancora scoperto, proprio perché siamo partiti facendo le cose nel modo sbagliato, ma il nostro modo sbagliato.

Jake Archibald - APPLICATION CACHE: DOUCHEBAG

Jake presenta application cache, un modulo html5 che permette di far funzionare siti web senza il bisogno di una connessione, appunto sfruttando un sistema di caching per scaricare parti del sito e averle poi sempre disponibili.

L'intervento è lucido, appassionato e tecnico. Quando tenta di spiegare tutte le fasi di configurazione di questo approccio, trasforma ogni parola in verbo, come "Offling", "Offlinerifying" e risulta molto simpatico. Mette subito in guardia anche dalle criticità della cache estrema, per cui Application Cache può fare cose molto potenti, ma se utilizzato con moltissima cautela.

Jonathan Snook - STATE-BASED DESIGN (slide)

Un altro attesissimo ospite è snook.ca che ha appena pubblicato SMACSS, un bel libro sulla scalabilità, il mantenimento e la modularizzazione dei css. Ritengo che i suoi studi sulla categorizzazione delle regole css siano molto importanti, soprattutto perché impongono una visione d'insieme e di lunga prospettiva sul futuro del css che si sta scrivendo; la sua citazione migliore è "code css for a system not for a page".

Anche lui pone l'accento sullo spostare il nostro pensiero fuori dall'abitudine, sul pensare modularmente e sul pensare a tutto tondo, per arrivare all'innovazione e anche alla riorganizzazione css. Il codice css dovrebbe essere chiaro a prescindere del contesto. In particolare approfondisce lo state-based design, le classi, gli attributi, le pseudoclassi e le mediaqueries di stato. Fornisce anche esempi divertenti come la sprite animation del lemmings che corre all'indietro grazie alle webkit keyframes animation.

Denise Jacobs - RESPONSIVE STORYTELLING

Denise è qui per raccontarci una storia, nel modo più tradizionale dell'oralità. La storia di un cervello e della sua avventura verso la creatività, quasi una favola di viaggio, del ricongiungimento fra emisfero sinistro e quello destro, in fuga da Cubicalia - il regno delle regole grigie e dell'abitudine.

Il focus di Denise è proprio sulla storia e sul raccontare storie: infatti, oltre a tutte le tecniche per adattarsi a piattaforme e device della user interface, è anche la storia che ci sta dietro che conta e la lealtà che essa ispira. Con Denise chiudiamo gli occhi, respiriamo, ci rimettiamo in contatto con il nostro emisfero destro; è un invito alla conoscenza di se stessi e dei propri ritmi, è un invito a invadere i parchi durante le riunioni di lavoro, un ritorno al contatto profondo con la nostra interiorità. Credo che Denise abbia citato anche Tom Waits, ma credo anche di essermi perso il passaggio preciso oppure me lo sono sognato, dato il volgere della giornata verso l'ultimo talk.

Aral Balkan - DESIGNING FOR HUMANS

Pensavamo di avere già visto e sentito l'incredibile in questa giornata - ve invece no, c'è il gran finale affidato non a caso ad Aral. Un uomo di spettacolo che prende posto sul palco ed è subito un clima incredibile di rapimento. Inizia con la migliore definizione di sviluppatore che esista: "developers make things for People".

Ci sono le persone dietro tutto quello che facciamo, non si deve mai smettere di pensare a loro nella progettazione, ai loro problemi quotidiani e a come risolverli, e non il contrario. L'experience design aiuta a capire loro, le persone, emotive, irrazionali, imprevedibili; l'usabilità di ciò che progettiamo è rivolta a loro. Una pioggia di esempi partendo dai bagni dove non è sempre scontato che la prossimità implichi relazione.

Alcuni esempi tragicomici, altri intelligentissimi, ovviamente da Oslo dove si sa già che "the best UI is not a UI","there is not BUT in design" e "Great design is about to say NO way more than saying YES". E' solo l'esperienza utente che conta, occorre tornare al minimalismo piuttosto che alle mille funzionalità e agli infiniti accessori. E il suo prototipo di lavatrice è veramente perfetto per l'esperienza utente, l'andrei a comprare subito e possiede un solo bottone... Ogni esperienza è un granello di sabbia in una clessidra limitata di momenti, e ogni granello deve rendere migliore la nostra vita.

Una giornata decisamente fuori dall'ordinario, in un luogo meraviglioso nel pieno centro di Bologna; l'organizzazione è stata impeccabile, a parte i noti problemi di wifi, i ringraziamenti vanno davvero a tutti loro, una squadra affiatata. Non vediamo l'ora di tornarci l'anno prossimo. Fra circa un mese dovrebbero uscire anche i video della conferenza, sarà un piacere riguardarne alcuni attimi.

Tre concetti dal libro Adaptive Web Design

Riccardo Petracchini — 2012-08-02T07:00:00Z

Oggi si parla molto di Responsive, parola utilizzatissima nell’ambito della progettazione web contemporanea, non sempre collocata nel modo corretto o con l’accezione giusta. A questa parola qualcuno preferisce invece il termine Adaptive come Aaron Gustafson in Adaptive Web Design, edito da Easy Readers.

Proprio in questo libro Aaron focalizza l’attenzione su tre concetti teorici che stanno alla base di questa tecnica di progettazione, fondamentali per coglierne la portata. Dunque, al di là della terminologia adottata, vediamo quali sono queste tre nozioni.

Progressive Enhancement: “miglioramento progressivo”

E' una filosofia in cui la creazione di esperienze è rivolta agli utenti mirando a dare loro accesso ai contenuti senza restrizioni tecniche di alcun tipo. Quindi non si tratta solamente di servire correttamente i contenuti agli utenti, ma fornire loro anche un’esperienza di fruizione fantastica a prescindere dal tipo di browser o di dispositivo essi stiano utilizzando per accedere. Per capire meglio il progressive enhancement serve a supporto un altro concetto sul quale esso fa leva, la tolleranza ai guasti.

Fault Tolerance: “tolleranza ai guasti”

Si tratta dell’abilità di un sistema di continuare a operare quando si riscontra un errore inaspettato. E' il classico caso di html & css, infatti, come prescritto dalle specifiche di questi due linguaggi, i browser devono ignorare qualsiasi cosa essi non riescano a capire.

Nel campo dell'evoluzione animale l’esempio di tolleranza ai guasti citato nel libro è quello relativo ai fringuelli delle Galapagos, la cui popolazione si ridusse dell’85% nel 1977 a causa di scarsità di piccoli semi, solo i fringuelli con i becchi più larghi riuscirono a sopravvivere.

Il parallellismo sta nel fatto che sia html-css, sia i fringuelli dal becco più largo sono compatibili in avanti, capaci cioè di adattarsi al cambiamento: sostanzialmente, ciò che viene scritto oggi funzionerà anche domani. La tolleranza ai guasti è la ragione per cui il miglioramento progressivo funziona e rende possibile assicurare che i contenuti siano accessibili e disponibili a tutti.

Graceful Degradation: “degradazione armoniosa”

Graceful degradation è invece una filosofia sorta per i primi 10 anni dopo la creazione del web, quindi nella generazione precedente a quella attuale. Potrebbe essere intesa come il concetto di Fault tolerance però applicato solo alla superficie del web.

Durante l’era Graceful degradation, l’attenzione era focalizzata ad assicurare che il sito funzionasse nei browser moderni stabiliti in base alla diffusione sul mercato, il testing per il supporto ai browser più datati era semplicemente relegato alla fine della lista delle priorità. Il ragionamento che stava alla base era semplice: html e css erano tolleranti ai guasti, così l’utente avrebbe avuto qualcosa da visualizzare anche sui browser più datati.

Sui browser più datati, l'esperienza di fruizione sarebbe stata comunque inferiore. Questo giustificava l'approccio verso le tecnologie precedenti: il sito doveva essere privo di errori, ma non valeva la pena spendere il tempo per garantire che fosse anche decente. Il controllo degli errori, in più, era limitato a quelli principali. A parte questo, gli utenti erano lasciati a se stessi.

In sostanza ci si è accorti che l’era della Graceful degradation stava minando sia la disponibilità dei contenuti, sia la loro stessa accessibilità. Per alcuni progettisti era molto chiaro che il web doveva distribuire e permettere la fruizione dei contenuti. Con questo cambio di prospettiva, vennero rifocalizzati gli sforzi per abbracciare la natura fault tolerant dei linguaggi html e css e per aggiungere a Javascript le precauzioni necessarie per ovviare all’assenza di questa sua natura.

In sostanza, con il nuovo approccio (content-out approach) le tecnologie web vengono applicate come livelli sovrapposti uno all’altro, in modo da creare interazioni ed esperienze migliori. Nel libro questa prospettiva viene spiegata con la bellissima metafora di una nota marca di noccioline zuccherate.

Il contenuto del nostro sito deve poter essere fruito anche in assenza di abbellimenti, a un secondo livello si utilizza la presentazione grafica di css per organizzare i contenuti anche attraverso le potenzialità della grafica, infine, si applica un ultimo livello in cui si migliora l’esperienza di interazione utente.

Se si può affermare che il progressive enhancement riguarda l’accessibilità questo approccio porta il discorso a un passo ulteriore riconoscendo che tutti abbiamo esigenze particolari e che esse cambiano nel tempo e a seconda dei diversi contesti.

Navigando un sito via smartphone siamo limitati dalla risoluzione schermo. La nostra capacità di interazione è quindi limitata dalla maggiore imprecisione delle nostre dita rispetto a un dispositivo di puntamento.

Per eliminare ogni possibile confusione si può affermare che tutte le esperienze create con progressive enhancement degradano armoniosamente, mentre non tutte le esperienze costruite con la graceful degradation sono costruite in miglioramento progressivo.

Quindi: contenuti ben scritti da professionisti del settore, elementi di markup semantico per aggiungere significati di contesto, un'esperienza visiva ottimizzata grazie a css, un livello di interazione focalizzato a migliorare l'esperienza utente e infine, come ciliegina, una spolverata di semantica aggiuntiva come il lessico WAI-ARIA utilizzato in concomitanza di best practices consolidate.

Questi gli ingredienti del miglioramento progressivo e dell'adattamento. Be Adaptive!

Traning with Jarn: Much more than training!

Federica D'Elia — 2012-03-28T07:00:00Z

I liked the enthusiasm of Denys Mishunov. He gave us many suggestions, tips and tricks that we needed to improve our daily work. This is the most important thing to me.Thanks to Jarn guys, I discovered the importance of enjoying my work. These tools can really make us work more quickly and easily, and make it more fun.

I liked so much Yiorgis Gozadinos approach: he is always looking for the cleanest and simplest way to solve problems. For example, we talked about the importance to follow Design Patterns, reusable solutions that can be applied to commonly occurring problems. This patterns lead you to result, with a lower effort and no waste of time.

Passion and enthusiasm shown by my teachers made me once more realize that the best way to reach professional growth is loving what you do.

Among the many other topics we discussed during training, we spoke about tests, that allow you to increase your work quality.

Besides learning useful and interesting tools, we also made a comparison between our and their way of working. In some cases, we found most effective approaches.

Thank you, Jarn guys, not only for what you taught us on a technical level, but also for the emotional charge you gave me!

Plone Konferenz 2012

Massimo Azzolini — 2012-02-29T17:05:00Z

The Konferenz

From February 22nd to 24th the PloneKonferenz took place in München. There was a bunch of smart guys talking about their experiences with Plone. I really give thanks to the organizers for their invitation.

Since it was localized conference, the majority of the speakers were german so I had to interview some of them just after they finished their speech. I would suggest you two talks I really appreciate: Matt Hamilton and Bernhard Bühlmann's ones.

Focus your attention on his explanation about relationships and the best way to start them.

Here some other inspiring talks:

Old dogs and new tricks (@eleddy)

the other @hammertoe's talk about belron's social intranet

You may also want to take a look at Fulvio Casali's blog for a more detailed report.

We also proudly presented our use cases

Andrew Mleczko presented the new project management platform we are about to introduce in RedTurtle. Its name is Penelope since every web project never really ends. We integrated Plone, Trac and GoogleApps within a Pyramid application.

Project management software of your dreams:

View more presentations from Andrew Mleczko

I also had my two minutes of glory talking about how Plone can fit both town-wise sites to regional-wise portals and intranets.

Plone Konferenz 2012:

View more presentations from Massimo Azzolini

Photos photos photos

Enjoy some PloneKonf photos from us and some other participants:

On RedTurtle Facebook Page

Matt on Flickr

Stefan Antonelli on Flickr

Stati Generali dell'Innovazione: perché abbiamo voluto esserci

Cesare Brizio — 2011-11-29T13:30:00Z

Innovazione: come?

Senza un approccio organico e inclusivo, innovazione diventa una parola vuota

L'innovazione a macchia di leopardo, l'innovazione che riparte sempre da zero, l'innovazione "a modo mio", l'innovazione non innovativa. E ancora: l'innovazione "ingessata", l'innovazione fuori contesto, l'innovazione a parole, l'innovazione chiusa, l'innovazione irripetibile, l'innovazione (solo) dei soliti noti, l'innovazione pre-elettorale, l'innovazione con barriera di ingresso. C'è altro? L'innovazione a fuga in avanti, l'innovazione senza Legge, la Legge senza innovazione, l'innovazione inapplicabile, l'innovazione sovranormata e quella sottonormata, l'innovazione settoriale o di casta, e potrei continuare.

Fin qui la rassegna delle storture osservabili non solo qui in Italia, ma in particolare nel nostro Paese. Un'innovazione spesso solo parlata, spesso polverizzata in iniziative magari eccellenti, ma tuttora alla ricerca di una visione di assieme, di un sistema, di una strategia, di una cabina di regia.

Ecco come!

Per correggere questo stato di cose, per valorizzare un talento che il mondo ci riconosce proprio nel creare e innovare sul piano tecnico, organizzativo e culturale, nasce l'associazione Stati Generali Innovazione, cui RedTurtle ha aderito dal primo istante, portando un importante contributo al gruppo di lavoro che si occupa in particolare di Pubblica Amministrazione. I nostri valori sono la natura di PMI, il sapere sul software libero, il patrimonio di esperienze e best practices dei nostri Clienti, ben rappresentato da PloneGov Italia.

Dal documento del Gruppo di Lavoro Open Government:

"...consapevole del valore delle esperienze di innovazione già in essere, l’Associazione intende censire ed aggregare tali esperienze, riconducendole a un unica visione multipolare, condivisa, armonica, coordinata, saldamente radicata nel contesto normativo esistente."

Gli Stati Generali (SGI) nascono per iniziativa dei più importanti poli di innovazione reale nel Paese (la lista dei promotori è realmente impressionante), di rappresentanze di tutte le categorie di stakeholder (Pubblica Amministrazione, Industria, Accademia, Ricerca, Terzo Settore) e sono aperti all'adesione di singoli, aziende e associazioni.

Paradosso: i governi che si sono succeduti nel tempo, hanno intrapreso le loro politiche di innovazione senza coinvolgere tutte le realtà innovative per missione, competenze e filosofia, senza censirle, aggregarle e valorizzarle: spesso si sono limitati a nomine con criteri di contiguità partitica, spesso hanno affossato anziché valorizzare quanto fatto in precedenza, sempre è mancato il momento "sistemico" di aggregazione degli stakeholder.

Modus operandi

"...Tale struttura di liberi saperi sarà gestita strutturando (con criteri trasparenti) una Consulta Permanente super partes e qualificata, partecipata dagli stakeholder dell’innovazione, che divenga il naturale referente delle istituzioni innovative della PA, e che sappia fornire linee guida, per evitare gli errori del passato ed orientare le future scelte in un approccio multidisciplinare al tema dell’innovazione."

In SGI si è partiti da subito con il piede giusto, a cominciare dalla connotazione "a-partisan" fortemente voluta dal Presidente Flavia Marzano e dagli altri fondatori. L'evento costitutivo dello scorso fine settimana, oltre a confermare le migliori impressioni maturate nelle settimane di lavoro che lo hanno preceduto, ha offerto al mondo un'immagine confortante della combinazione di voglia e capacità di cambiare, e un senso di fiducia per la coincidenza nel tempo tra la disponibilità di queste forze coese, una crisi da risolvere, e un nuovo governo tecnico, interlocutore predestinato per SGI.

Ponendosi a disposizione del Paese sia per definire una serie di interventi immediati a costo basso o nullo, sia per portare avanti nel tempo la propria piattaforma programmatica distillato delle migliori competenze del mondo reale, SGI si candida a rivestire un ruolo chiave.

Impressioni

Personalmente, ho atteso l'evento con le aspettative accumulate in alcune settimane di collaborazione (un po' in remoto, un po' in presenza) al Gruppo di Lavoro per l'innovazione nella PA. Tutto è fluito ragionevolmente liscio, con l'aula magna di Università Roma 3 a fare da cornice.

Critiche soprattutto costruttive, proposte e una confortante rispondenza tra le linee di azione di SGI e le esigenze e opportunità evidenziate dai relatori. Gli SGI *sono* la soluzione che serve

Più che fare una telecronaca (il programma è stato rispettato con modeste sbavature, tipiche di una "prima" molto affollata), mi importa confermarvi che il clima costruttivo e partecipato che si è respirato in Aula Magna è proprio quello che Flavia descrive sul suo blog.

Il Venerdì, più istituzionale e strutturato, integralmente trasmesso in webcast su www.statigeneralinnovazione.it, ha visto succedersi relatori di alto profilo, e a fine mattinata anche parlamentari, ognuno a portare il proprio contributo sul tema sotto una pioggia incessante di tweet che scorrevano sullo schermo alle spalle del palco, alcuni ripresi in tempo reale dai moderatori per stimolare i relatori.

Al pomeriggio, le sessioni parallele hanno consentito di riaprire il dialogo tra i gruppi di lavoro e la base dell'Associazione per discutere gli specifici position paper.

Il Sabato mattina, arricchito dal contributo di ascolto e proposta di Mario Campolargo (Responsabile EC "Emerging Technologies and Infrastructures") e Franco Accordino (EC, Task Force Digital Futures), in teleconferenza da Bruxelles per parlare di Agenda Digitale Europea, ha culminato nel dibattito necessario per confezionare in modo sintetico la piattaforma da offrire all'interlocuzione con il Governo, che (senza negare l'obiettivo chiave di SGI, collaborare a tempo pieno con il sistema-Paese) si è deciso, tanto per iniziare, di basare su una proposta di otto azioni immediate e a costo tendente allo zero.

Noi e gli Stati Generali

RedTurtle, sponsor dell'iniziativa, si è accreditata come portatrice di forti competenze e di utili esperienze sul software libero: la nostra posizione aziendale si è manifestata nei contributi che ho offerto alla discussione, alcuni dei quali integrati nel Position paper del gruppo Open eGovernment e nel documento finale, e certamente intendiamo anche in futuro porre a disposizione di SGI la nostra competenza e la nostra visione.

Ci si è lasciati con una collaborazione ancor meglio avviata e numerosi compiti a casa, sul cui svolgimento gli Stati Generali intendono usare la stessa congenita trasparenza e apertura mostrata fin dall'inizio.

Seguiteci e coinvolgetevi!

Agile day - Roma, 19 novembre 2011

Irene Capatti — 2011-11-23T11:05:14Z

Ore 19:30 di sabato. In treno, di ritorno dalla giornata agile di Roma...

"dai Nicola, scrivi il post!"
"(...)"

Già, lo capisco. Ci sono cosi tante cose da raccontare e uno spritz di happy ending da smaltire :-)

Una signora seduta di fronte a noi ha appena esclamato "siete mitici!" dopo aver condiviso la nostra euforia e le nostre gag da agilisti dell'ultima ora.

Nel mentre passa accanto al nostro sedile il Taz che intima a Max di smettere di twittare ogni tre secondi la cronaca in tempo reale dei nostri spostamenti... è la sindrome dell'agilista sociale (una mutazione del morbo agilista difficilmente curabile con le terapie convenzionali).

Raccontare i singoli talk a cui abbiamo assistito sarebbe riduttivo. Basta una facile ricerca su twitter di #iad11 per rendersene conto (il topic è stato tra le hit di twitter della mattina).

Twitter... Una vera magia: in presenza di quattro track parallele ti consente di seguirne fisicamente una e partecipare alle altre tre

Benissimo, i miei compagni di viaggio mi stanno offrendo un altro modo per raccogliere gli appunti sparsi di oggi... Provo a catturare alcuni frammenti di conversazione.

Max chiede a Ste di spiegare il business model di RT in 30 secondi (Un po' alla "Startup senza falldown" del mattino). 30 secondi ?! Ardua impresa.

Ecco che viene riproposto anche qualche accenno del talk di @ziobrando (Volevo solo scrivere codice), nostalgico e velatamente malinconico. Una sua citazione che merita di essere tramandata ai posteri è:

Dopo un metodo di 1500 righe non devi mettere la parentesi graffa ma "e vissero tutti felici e contenti" @paolopolce #iad11

Io potrei parlare di "varchi attivi", "panini freschi" e "tomtom diabolici" per ricordare il talk di @yvonnebindi (L’usabilità delle parole).

Stefano ricorda Spaghetti DevOps, Overcoming self-organization blocks e Kanban = Pillola Viola.
Nicola invece non manca di segnalarci Capire e gestire il debito tecnico e La professione dello sviluppatore.
Max chiude il cerchio con il talk su eXtreme Programming, Timeboxing and Kanban e quello del "commerciale agile".

Ok, Nicola ha iniziato a parlare di python, javisti e ide... La signora del sedile di fronte credo abbia dato forfait. L'indole dei satanici programmatori sta prendendo il sopravvento.

Il tempo di un pomodoro e dal sedile accanto non proviene più alcun segno di vita... Ops! Morfeo (o lo spritz della foto) ha avuto il sopravvento! La signora è salva.

Del resto la sveglia alle 3:30 di stamattina è stata tutt'altro che agile. Son serviti 4 caffè per arrivare fin qui e almeno un altro si renderà necessario dopo la cena (agile anch'essa) che ci aspetta a Bologna con gli amici che non hanno potuto partecipare.

Torniamo stanchi ma decisamente arricchiti di esperienze, condivisioni e tanta energia. Maaaaa... mi chiedo: gli agilisti sono esseri umani comuni che hanno visto la luce (come il nostro Nicola stamattina alle 5:30 al bar quando un semplice faretto acceso ha avuto ai suoi occhietti stretti dal sonno l'effetto di un'apparizione mistica) o sono una nuova razza di New Type di Gundamiana memoria?

Un giorno, forse, troverò anch'io La Risposta.

See you all'Agile Day 2012!

attori protagonisti: @massimoazzolini, @nicolasenno, @stemrc, @nekorina
attrice non protagonista: la signora del sedile di fronte
attori non protagonisti: @bettazzoni, @ziobrando, @ilbonzo, @gaunilone, @guandalf, @yoghi
guest star: la bimba di 10 anni (a occhio) che ha seguito tutti i talk della giornata
premio della critica: all'ottima organizzazione romana (e non) dell'intero Agile Day, ai relatori, ai reporter (twitters... si dice cosi?) e alla torta alle spezie del buffet di rinfresco!

Se vuoi vedere foto dell'evento, vai al nostro album su Facebook.

PloneConference 2011: novità e conferme

Massimo Azzolini — 2011-11-09T23:05:00Z

Ancora una volta: "the best conference... ever" (cit.)
Tre track parallele, numerosi openspace, meeting in e out la conference, social party(!) ogni sera e per finire l'usuale sprint

Le 3D, ma molto altro

Il leitmotif di quest'anno è stato senz'altro il tris di Diazo, Deco e Dexterity. E' già un po' di tempo che se ne parla e non vi nascondo un po' di delusione nel vedere che sono ancora temi importanti.

Il punto cruciale sta nel fatto che negli anni passati è stata tentata una rivoluzione, che avrebbe però avuto un impatto troppo importante su tutto l'ecosistema Plone. Questo ha portato a una serie di complicazioni e di refactoring.

Ora si sta ragionando in termini di add-on per Plone che ne migliorino l'esperienza, senza introdurre stravolgimenti.

Diazo & CMSUI

E' ormai un sistema maturo utilizzato in produzione da molto tempo.

L'idea è di:

semplificare la fase di skinning di Plone limitandola al frontend, più facilmente gestibile da Diazo,

demandare a CMSUI tutta la fase di gestione del backend mantenendo il tutto contestuale, ma indipendente dal layout.

Direi che questi due video da soli sono sufficientemente esplicativi.

Diazo Theme Manager:

CMSUI:

Deco

Sta raggiungendo anche lui la maturazione e si sta lavorando sulla user experience. L'idea in questo caso è quella di sostituire prodotti come PortletPage

o Collage. Questa una preview realizzata dai colleghi di FourDigits.

Dexterity

Sugli scudi infine anche Dexterity, di cui parlammo ancora due anni fa come promessa e che ora sta raggiungendo il suo compimento. Sull'interfaccia c'è ancora da lavorare e non è uno strumento per tutte le stagioni, ma è sicuramente estremamente interessante.

Gli altri temi caldi

I miei talk preferiti sono stati:

Clone to Plone

Multiplayer Plone

Make plone search work like Google

Il primo racconta l'utilizzo di FunnelWeb per migrare portali da un altro sistema a Plone.

Nota mentale: ogni migrazione è un'isola, ogni migrazione è "painful"

Il secondo è stato tenuto da Geir Baekholt su istigazione di Yiorgis Gozadinos e permette di utilizzare Plone un po' alla GoogleDocs con tanto di chat e status:

Infine l'uso di Solr al fine di ottimizzare gli indici permette anche di aumentare le funzionalità "googlesche" di Plone:

Pyramid

La track "Related Tech" è stata fortemente monopolizzata da Pyramid. E' la tecnologia "sorella" di Plone che abbiamo sposato da tempo. Ne abbiamo parlato qui, qui e anche qui. Senza contare il talk di Andrew che ormai è un bestseller alle varie conferenze.

Pyramid è in diretta concorrenza con Django (framework di cui viceversa non si è parlato). E' da sottolineare il fatto che praticamente tutti i Plonisti a S. Francisco avessero fatto la stessa scelta e questo ci conforta sapendo di aver scelto a suo tempo nel modo corretto, ma soprattutto di essere in buona compagnia.

Il Keynote

Quest'anno l'usuale keynote è stato tenuto da P.J. Onori. Personalmente l'ho trovato di particolare ispirazione: è un inno alla crescita professionale, al capire l'usabilità delle cose, alla condivisione di esperienze tra developer e designer.

Più volte mi sono ritrovato a dire "si! si! si!".

I nostri talk

Avrete modo di leggere di più nei prossimi giorni sui talk (e lighting talk) di Andrew e Stefano. Mi limito a segnalarvi le presentazioni:

Bootstrap your app in 45 seconds (slideshare)

Plone in the Public Sector: Business and Sustainability Models (slideshare)

RuPy 2011 - Strongly Dynamic Conference

Andrew Mleczko — 2011-10-20T07:50:00Z

Last weekend (14-16 Oct 2011) I've attended RuPy (Ruby + Python), a strongly dynamic conference held in Poznań (Poland) and organized by GIK Association. I had a great opportunity to share RedTurtle's "Pyramid and Plone" integration use case with wider audience. It was truly an open source event and a great opportunity to meet geeks from the Ruby community.

It was RuPy's 3rd 4th edition and apart it was the biggest (ca. 300 attendees) I must say - it was the best (I was attending all previous editions). The GIK have chosen Poznań International Fairs as the conference venue which was a damn good idea. During 3 days of the conference there was ca. 30 events (talks, workshops and sprints). Most of them was related to Ruby which is a problem each year. Getting more support from Python community is highly appreciated!

What I think is notable is the speaker feedback system. Each room had 3 containers marked: :-) :-| and :-(. After each session the speaker was receiving his anonymous feedback from the audience. From the speaker point of view (so also mine) it's surprisingly easy and gives you great opportunity to check if what you've just said wasn't a completely bullshit. What I would suggest is to make bigger effort in promoting it after each talk.

Interesting talks

my subjective list of notable talks

Programmer Anarchy

by Fred George

Writing your own programming language

by José Valim

Tradeoffs and Choices: Why Ruby Isn't Python

by Yehuda Katz

I didn't find the slides but I hope RuPy team will publish them soon. In the mean time - short abstract:

"When a Pythonista first dives into Ruby, he is confronted with a strange and unusual world. Multiple kinds of functions, implicitness everywhere, violations of the Zen of Python galore! In this talk, Yehuda will talk about the tradeoffs in Ruby's language design: why, in many ways, Ruby couldn't be more like Python even if it wanted to."

Summary

It was an amazing weekend with some interesting discussions with people from Python and Ruby world. Thanks RuPy, hope to see you next year!

Last but not least the organization committee followed best practices and shared their website source code to wide public.

ZEA, come una fenice, rinasce da Arnhem

Massimo Azzolini — 2011-09-28T18:10:00Z

Dopo la rifondazione che abbiamo attuato nei mesi scorsi, abbiamo deciso di tenere una serie di incontri trimestrali. Vogliamo approfondire al massimo la conoscenza reciproca, raccontarci le nostre esperienze e dare/ricevere dai colleghi spunti e opportunità. Una specie di micro-conferenza con cadenza molto ravvicinata.

Questa edizione è stata organizzata da Four Digits presso la loro sede ad Arnhem (Olanda). Per questo semestre, infatti, Rob Gietema è il nostro presidente.

Erano presenti 8 partner oltre a noi:

Four Digits (NL)
Abstract (IT)
Jarn (NO)
Gocept (DE)
Infrae (NL)
Greenfinity (HU)
Startifact (NL)
Netsight (UK)
RedTurtle (IT)

I talk

La giornata era organizzata in modo da avere talk ma anche spazio per discussioni aperte e lighting talk.

Evito di entrare nei dettagli: c'è un ottimo post di Matt Hamilton (Netsight) che vi invito a leggere.

Primo meeting: un sacco di cose da decidere!

Allo scorso Sorrento sprint è stato eletto un board (Kit Blake, Geir Baekholt e il sottoscritto) e in questo senso eravamo ora chiamati a proporre una strategia da seguire per i prossimi anni.

Questo è un cambiamento importante rispetto alla passata gestione. Abbiamo una strategia, condivisa tra il board e i membri che possono approvarla, emendarla, aggiungere nuove proposte.

Il presidente, e il suo vice che lo affiancherà fino a sostituirlo dopo 6 mesi, hanno l'incarico di metterla in pratica. Il board supervisiona in modo light i vari presidenti nell'arco di 5 anni. Giusto per garantire un minimo di continuità nelle iniziative.

La nostra proposta è fondamentalmente basata su due capisaldi.

ZEA sarà molto più leggera: poca burocrazia, quote di partecipazione contenute (400€ per le aziende oltre i 3 componenti, 100€ per gli altri e try-before-buy fino a tutto dicembre), nessun vincolo di azione o partecipazione da parte dei membri. ZEA agevola le opportunità: non le crea e non le impone.
ZEA sarà molto più comunitaria e coesa: una meta-company di 100+ persone, con gli skill derivati dalle competenze di 20+ aziende. Agiremo ognuno come sede locale di ognuno degli altri. Ancora una volta saremo a diffondere il verbo di Plone, come sempre secondo la nostra mission, e lo faremo in modo coordinato e condiviso.

Le azioni pratiche che contiamo di intraprendere nel breve e nel medio periodo sono:

partecipare a eventi transnazionali a livello europeo per far conoscere Plone e il nostro brand;
spingere sull'organizzazione e sulla partecipazione a sprint e tune up per continuare a evolvere (evolution not revolution) il nostro CMS preferito;
organizzare un Transnational Exchange Programme durante il quale sviluppatori di un'azienda andranno a lavorare in altre aziende del gruppo per qualche tempo;
ehm... sì, avremo anche un nuovo website

E non sarà solo Plone. Pyramid e Django già da un po' lo stanno affiancando. E non sarà solo tecnologia, in diversi abbiamo evidenziato competenze consulenziali che finora erano rimaste colpevolmente taciute.

Questa proposte, che come board abbiamo avanzato, sono state apprezzate dai membri e nei prossimi mesi proveremo, appunto, a metterle in pratica.

Mi aspetto un periodo di rodaggio: il livello di collaborazione e interazione cui stiamo tendendo è sicuramente superiore e dovremo oliare ogni singolo meccanismo.

La community

Lo so. Mi ritrovo spesso a ripetere come un mantra la parola "community": nei post, nei talk, nelle serate con i colleghi, nelle presentazioni ai clienti.

Ancora una volta son qui a sottolineare questo aspetto: essere parte di una comunità.

Questa volta però non è una comunità di persone, ma una comunità di aziende. L'idea di base non cambia: in fondo le persone che guidano queste aziende sono le stesse che negli anni hanno sviluppato e evangelizzato il mondo su plone. Abbiamo ancora la stessa idea fissa (potevo dire meravigliosa).

Quello che cambia è il punto di vista. Un'azienda deve produrre reddito per sé e per tutte le persone che vi lavorano. E deve farlo in modo continuativo, organizzato, pensato.

Questo è un bene per Plone. E un bene per i nostri clienti (l'esperto della funzionalità che serve al mio cliente è sempre stato a un colpo di telefono, ma lo conosco molto meglio)

Personalmente, l'essere parte di una comunità di imprenditori mi aiuta a semplificare questa fase: tutti tendiamo a rendere le nostre aziende floride e stabili nel tempo, non dovrò più inventarmi in solitudine il modo migliore per farlo, potrò anche mettere a frutto suggerimenti e mediare iniziative già intraprese con successo da altri.

E' stata una 2 giorni impegnativa, carica di aspettative e con molte speranze per il futuro. Come lo stesso Matt nel suo post, anch'io "look forward to the next meeting in January…" ovunque sarà. :-)

Appunti sparsi dalla seconda conferenza dei sindaci di Foursquare

Stefano Marchetti — 2011-07-21T13:42:41Z

Alla prima edizione della Conferenza dei Sindaci di Foursquare siamo venuti in incognito, ma c’è piaciuta così tanto che quest’anno abbiamo deciso di tornare, partecipando come sponsor. Ed eccomi qua, degno rappresentante delle tartarughe.

L’impressione è buona fin dall’accoglienza, calorosa e ricca di gadget. Francesca mi dà il benvenuto con tanto di fascia tricolore e foto celebrativa (!). La location è molto luminosa e aiuta a creare un clima disteso e informale.

Noto subito che molti partecipanti già si conoscono e scatta la gara a scoprire chi si cela dietro ai vari nickname di twitter. Perché qui si twitta a ritmi da capogiro e tutti sono impegnati a contribuire alla conversazione #4sqconf.

Io sono un utente attivo di Foursquare, faccio check-in e sono sindaco di ben (!) due venue. Ma qui vorrei davvero approfondire il lato business della faccenda.

Tutti gli interventi sono stati molto interessanti, ma quello che più ha trattato questo aspetto di Foursquare è stato lo “scontro” tra Vincenzo Cosenza (@vincos), l’avvocato della accusa, Gianluca Diegoli (@gluca), quello della difesa. Il dibattito ha ruotato intorno alla domanda: “Ma 4sq è solo per le grandi aziende?”.

La risposta più istintiva è: “Certo, è ovvio, servono varie decine di migliaia di euro al mese per stringere accordi forti sulle venue con 4sq”. In realtà, come suggerisce l’ottimo @gluca, questo non è vero: anche la piccola realtà commerciale può creare iniziative, tra l’altro con costi contenuti.

Una preoccupazione condivisa anche dai partecipanti alla conf è il rischio che le grosse aziende usino 4sq in maniera impropria. Ad esempio, usandolo come semplice strumento di promozione, trascurando completamente le dinamiche (anche ludiche) che muovono strumenti social come questo.

A proposito di aspetti ludici: interessante l’intervento di Fabio Cristi incentrato sulla gamification. Fabio ha messo in evidenza luci e ombre di 4sq: la classifica a punti appare poco interessante per molti utenti, mentre “rubare” la majorship a un amico o a un altro utente è una sfida che piace molto : )

Nello stesso intervento ha passato in rassegna alcuni giochi basati su 4sq: Foursqwar, World of Fourcraft, Booyah, Gowar (gioco italiano!), Gbanga.

Davvero interessante anche la discussione finale con Lorenzo Sfienti, che ha sviluppato con 4sq ,che, a mio parere, evidenzia un punto molto, ma molto, importante. Si tratta di capire se 4sq intenda dare maggiore libertà d’uso dei dati e delle API del sistema agli sviluppatori.

Questo potrebbe fare concretamente la differenza nella diffusione del sistema: basti pensare a cosa ha fatto Google con le mappe (ok, le mappe sono decisamente una cosa diversa, lo so bene, però…). API facilissime da usare, con funzionalità che si sono arricchite nel corso del tempo, molto ben documentate e senza vincoli particolari nel loro uso. Non è poco.

Questo ha consentito una diffusione enorme e a reso di fatto le mappe Google lo standard sul web. E’ vero che dietro c’è un colosso come Google, ma questo approccio ha dato eccellenti risultati anche in una realtà più piccola come Disqus.

Che dire, una giornata piena di stimoli su cui riflettere e di persone interessanti. Grazie ai mimuli e a tutto lo staff per l’ospitalità e l’eccellente organizzazione.

B-R-A-V-I!

Europython 2011: aftermath

Marco Mariani — 2011-06-29T13:25:00Z

It has been a tiring but exciting week in Florence.

After four years of national PyCon Italy, the team has been excellent and set up an event that clearly shows the level of maturity of the community.

Over the years since the first EuroPython conference, the big change is that we don't have to justify our language choice anymore.

Actually, I would not even be a programmer it where was no Python. I was a system administrator, more like a plumber than an internal decorator.
Python has taken me by hand, teaching and letting me write things I would not have attempted in other languages available at the time.

For me, Python was an easy choice, but... difficult to master.

As programmers, we make trade-offs and take compromises several times per day, while we design and write applications.
Very often we take a different road than we did the day before, because we've seen what lays ahead and want to avoid it, or the customer has changed his mind, or we have a better understanding of the whole.

As a matter of fact the right answer to a programming question is often "it depends", because the architectures, markets and business models are getting more and more complex, and we as software craftsmen have none of the certainties than mathematicians or computer science people take for granted.

Fortunately for us and our customers, software can be easily changed, and nothing prevents experimenting with different approaches if time allows.
But once in a while - typically at the start of a development cycle - we have bigger choices, the decisions that make room for the following ones: the basic architecture.

What language(s) are we going to use? (that's easy, Python. but it depends)
Light framework or a heavy, full featured one?

Relational or non-relational database? And if non-relational, which of the many?

Is our application process or data driven, or both? (this is vague. it's usually both)

Browser or server side processing?

How will it scale to many concurrent users?

and so on, and on.

At this point, if we pick the wrong road, the application could still be delivered, hopefully in time and the customer will be happy (at first), but the program itself might be a lot more complicated than it needs to be, and hard to change. The price will be paid over time, as new needs come and maintenance is required.

Unfortunately for us, some of these are hard questions, also subject of fashions and marker pressure, and it is very hard to have a comprehensive picture just by following technical blogs.

That's why I long for conferences like EuroPython, where the scope of the talks is as wide as can be, while still remaining highly technical.
Where the authors are ready to discuss about it over the lunch, and everybody is smart for having chosen Python :-)

Best talks.. ever :-)

A few of the talks tackling old problems in light of new tools and experiences:

Relate or !Relate (Mark Ramm-Christensen)

Mark explains the difference between the forest of NoSQL databases, and shows that a good SQL DBMS can scale surprisingly well.
This is a dear topic to me, because direct approaches in one side require complex contraptions on the other one, and vice-versa.
As a side note, lately the MySQL - Postgres debate seems to be over. The latter one has sharply won, if not the market, the minds of the programmers.

How to build complex web applications having fun? (Andrew Mleczko)

If the user wants both, give them both. Instead of fitting every requirement in a single architecture, try deploying a full-featured
CMS along with a light, flexible framework and divide the tasks -- a little like loading a bike on your camper.
You can go anywhere and they integrate well.
This is easier today (in the post-WSGI world) thanks to Pyramid, a highly refined foundation for web applications that lets a lot
of freedom: should the architecture be modeled after Zope, Plone, Pylons, Turbogears, Rails or Django? With Pyramid, "it depends" is the main concept :)

Other worth mentioning

Challenges in developing a large Django site (Simon Willison)
An iPhone-Python love affair: Building APIs for mobile (Anna Callahan - Nate Aune)

I also had fun with Raymond Hettinger, the only developer I've known that adds a +1 charisma bonus within a 10mt radius.

In his training track, he tore apart core concepts of Python (classes, decorators, properties, descriptors, dictionaries) and as he spoke rebuilt them using lists only. MacGyver couldn't do better!

But really, I could list half of the talks in the schedule, they are that good, and they kept a good balance of more and less advanced matters.

and the plone-ish stuff?

Sure, I would have liked a few more talks about Zope, Plone, BlueBream or Grok, especially highlighting how they have changed in the latest years, becoming more powerful, easier to extend and deploy, and there should be some effort communicating that to new developers.

They are coming to the conference to look for directions, and might go after some fashionable, but less capable tools.