Beta version

Pulse

Come un battito del cuore, qui raccogliamo i flussi che vengono dalla rete per raccontare dnsee e la sua idea di Web.

28.11.2011 By Alessandro Lombardi

OSI days 2011 e il paradosso indiano

Non era un luminoso pomeriggio d’agosto, come dicevano Elio e le Storie Tese, bensì un sabato, caldo, d’autunno: un numero imprecisato di ore, inflazionato dal fuso orario, e ”improvvisamente” una domenica mattina mi sono ritrovato a Bengaluru, semiaddormentato in un taxi malridotto e dai vetri scuri, diretto verso il Nimhans Convention Center, per gli Open Source India Days 2011.
OSI days 2011
Un impatto spiacevole con una città sporca e malmessa, un susseguirsi di detriti e traffico caotico che neppure un abitante di Roma può capire.
Baracche e insegne, pubblicità invadenti del mondo delle telecomunicazioni e dell’informatica che, dopo gli inglesi, colonizza l’India.
Un clima caldo ma piacevolmente mite, aria fresca e sole deciso, con tanta polvere e fumi inquinati.
Per fortuna, come ho avuto modo di raccontare, nei giorni successivi ho potuto conoscere il fascino più profondo dell’India.

Ma nei tre giorni di conferenza si tocca con mano l’orgoglio e l’ambizione indiana, nella loro “Silicon Valley”, per i progressi
della loro industria informatica. Per essere la più grande conferenza dell’Asia sul tema FOSS, è un po’ deludente.
Negli auditorium del Nimhans la cosa più evidente è che, a dispetto degli investimenti delle major IT, il livello di preparazione e di
partecipazione debba essere alzato.
Il livello dei talk non è sempre male, e le sponsorship sono quelle dei grandi nomi: Microsoft, Google, Yahoo!, tanto per citarne tre noti a chiunque.
Tuttavia, agli OSI days non manca soltanto il giusto livello di partecipazione (erano attese tremila persone, con la sala più
grande delle tre a disposizione, milleduecento posti a sedere, quasi sempre popolata da poche decine di persone), ma anche una maggiore attenzione ad identificare l’audience. Gli argomenti dell’open source, visti dal punto di vista prettamente tecnologico piuttosto che dal punto di vista più tipicamente business, si mescolano un po’ confusi nelle varie track.
Le track stesse non mi sono sembrate molto convincenti, si passava dalla track monotematica sul PHP (quella per cui Alessandro Nadalin è stato invitato nei suoi due speech) a quella generica sul web development. Passando per una database track, una sul FOSS e una sull’IT infrastructure.
Per quanto abbia gradito i panel condotti da alcuni speaker dell’industria del software occidentale unitamente agli outsourcer
indiani, e l’intervento in videoconferenza di Zeev Suraski, su resto ho visto più che altro un tentativo di improvvisare un corso di tecnologie open ai programmatori e studenti indiani. Come se l’intento principale fosse evangelizzare una forza lavoro mai abbastanza consapevole di ciò che le gira attorno, e un po’ imbarazzata e poco coinvolta nei talk (con poche eccezioni, e la pessima lingua inglese parlata dagli indiani non facilita il networking).
La tecnologia al momento è tutta rivolta al consumer finale, e quindi l’attenzione è tutta sulle major del web, ma perché coinvolgere solamente la comunità PHP? Non ho visto nessuna presenza rappresentativa dell’Apache Software Foundation, ad esempio. Peraltro mentre le tecnologie basate su PHP si stanno evolvendo, e ne sono personalmente contento e convinto della loro evoluzione, sembra che non ci sia abbastanza osmosi per permettere alle differenti parrocchie tecnologiche di parlarsi fra loro e recuperare tempo prezioso. Mi aspetto che questa consapevolezza sia presente negli speaker presenti a conferenze di questo tipo, mentre continuo a notare un bias eccessivo che porta a prediligere certe persone ogni approccio che è proprio del loro mondo, e quindi non solo del loro linguaggio preferito, ma di ogni cosa che è al momento lo stato dell’arte che loro conoscono.

Tanto per fare un esempio a me noto, non mi sembra che ci sia la giusta consapevolezza delle soluzioni e degli standard tecnologici propri del mondo Java, che nascono per esigenze proprie delle integrazioni B2B enterprise, e che sono spesso viste come sovraingegnerizzazioni nella comunità PHP. Lo sono, se ci si rapporta con soluzioni web di tipo diverso. Ma è innegabile che molte soluzioni proprie del mondo Java sono lì da almeno cinque o più anni, perché ci è voluto tanto per vederle transitare nel mondo dell’elefante blu?  La conferenza parlava di modelli di business sostenibili e basati sull’open source, e chi ne parla dovrebbe andare un po’ oltre la solita scontata ideologia di base del software libero, valorizzato dalla comunità, come se per l’industria IT l’open source fosse meglio a prescindere. Per quanto sia da dieci anni un convinto sostenitore dell’open source, inizio a essere stanco della superficialità di questo approccio (e credo che approfondirò su questo blog l’argomento). Per fortuna alcune persone più illuminate, come Gil Yehuda di Yahoo!, e non solo lui, hanno in parte affrontato.

Durante la visita che ci è stata offerta al dipartimento R&D di Dell (in un’area industriale dominata dai palazzi delle major, tra cui
spiccava il bellissimo complesso di Yahoo!) ho avuto modo di parlare con uno degli sponsor dell’organizzazione, dipendente Dell, e fargli notare questi aspetti. Peraltro, anche quella visita è incominciata con il tentativo da parte del nostro ospite di coinvolgere i dipendenti Dell da lui convocati in una presentazione sul modo in cui gli speaker dell’OSI days si rapportavano con il mondo Open Source: partendo dall’abc.

Ora, aggiungerei qualche considerazione forse più banale, ma al solito certe banalità non sono tali quando le si tocca direttamente con mano.

Il Nimhans è un grande complesso ospedaliero. Arrivandoci puoi passare accanto a posti in cui la gente vive per strada e campa come può.
Strano ritrovarsi poco dopo a parlare di open source e sviluppo di tecnologie, quando a stento così tante persone sopravvivono e
soddisfano i loro bisogni primari.
L’India ha vissuto una rivoluzione industriale condotta con ben poca attenzione alla sostenibilità. Sembra siano arrivati direttamente alla rivoluzione informatica, e vogliono colmare in fretta il gap. Un terzo mondo che ha creato un’economia in crescita basandosi sulla propria forza lavoro, ma per fare outsourcing alle aziende di IT occidentali.

Non so dire se tutto questo è giusto o sbagliato: sicuramente vorrei che gli investimenti che il resto del mondo sta facendo sull’India (come sugli altri paesi del gruppetto BIRC, a discapito della crisi finanziaria Europea), fossero usati per colmare il gap con uno sviluppo sostenibile, e non soltanto per permettere a quella parte di India informatizzata di raggiungere subito le comodità occidentali.
Hanno la possibilità di apprendere direttamente dai nostri errori, e di contribuire a un “flat world” libero da barriere sfruttando la
fiducia che le opportunità finanziarie stanno creando.
Bengaluru è un cantiere aperto, le infrastrutture sono in costruzione (strade, metropolitana) e le pubblicità di nuovi appartamenti che invogliano al sogno di una casa si stanno moltiplicando. L’urbanizzazione è testimoniata dal fatto che Bengaluru stessa è una delle città con il tasso di crescita più alto del mondo.

Nessuna grande verità rivelata, ma non posso che essere curioso di sapere cosa sarà Bengaluru fra alcune decine d’anni, e come l’India avrà gestito queste enormi opportunità.

29.04.2011 By Alessandro Lombardi
Job, dnsee 0

Così agile che sfugge

Non ho mai parlato qui di metodologie agili, ma questa volta ho un punto ben preciso da indicare, alla luce della mia diretta esperienza, sia nel rapporto con i clienti che nell’organizzazione dei vari team di lavoro sui progetti in ambito web e mobile.

L’approccio incrementale/iterativo è bello, relativamente facile da introdurre. Anche le metodologie agili vanno affrontate con agilità, introducendo i metodi che servono ai nostri scopi e partendo dai principi in cui crediamo ma che soprattutto siamo in condizione di applicare. Niente di nuovo fin qui.
Andate però a (ri)dare un’occhiata all’agile manifesto:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Di queste quattro fondamentali cose, concentriamoci sulla terza. E non certo perchè sia la più importante.
Per quanto possiate avere peso in un’azienda (a meno che non sia vostra o possiate controllare ogni cosa, dal rapporto commerciale alla produzione), non riuscirete a imporre tutto.
Forse, con fatica, riuscirete a dare un certo peso ai restanti tre principi, ma non al terzo.

Questo perchè c’è ancora l’errata convinzione che l’agile sia qualcosa che riguarda il mondo del software, qualcosa di “tecnico” (*), che subentra solo quando si fa sviluppo software. E’ anche colpa nostra, si parla di “metodi agili di sviluppo software”: ma sembra che si debba ricordare l’ovvio, cioè che anche restando confinati al dominio dello sviluppo software questi metodi non coinvolgono soltanto persone con skill esclusivamente proprie di questo mondo.
Certo, adesso va molto più di moda che qualche anno fa, quindi non sono poche le aziende che cercano di adottare metodologie di management più efficaci, ma quanto di questo avviene in società di servizio che lavorano su commessa con clienti senza una mentalità IT e metodologica?
È più probabile che l’agile prenda piede in contesti in cui ciò che c’è oltre lo sviluppo software è molto contenuto, vuoi perché il team agile si interfaccia con interlocutori simili (una piccola squadra dedicata allo sviluppo di una parte di progetto, il cui scope finale è filtrato da un committente che non è quello finale), o perché si tratta di factory interne dedicate allo sviluppo di un prodotto o servizio.
In una società che si occupa di digital questo difficilmente accade, e farlo accadere è l’equivalente di tentare una mezza rivoluzione.

I clienti vogliono conoscere quanto costerà quel bel vestito su misura che dovranno indossare prestissimo, ma non sanno ancora se lo vorranno più chiaro o più scuro, più caldo o più freddo, sanno solo che devono mettere da parte i soldi ora per comprarsi un vestito. E forse una cravatta.
Così i clienti chiedono praticamente sempre offerte che sono, nella migliore delle ipotesi, vaghe. Il margine di commessa serve a coprire più gli errori che a fare vera profittabilità, cosa che dovrebbe incidere solo in misura minore.
Sarebbe molto più win-win per cliente e fornitore collaborare, accettare una fase a costi e tempi fissi per analizzare e progettare la soluzione, ma iniziando a costruire la soluzione, in ottica iterativa agile, per poi decidere quando definire il perimetro della soluzione finale. È una questione quantitativa, il margine di incertezza dovrebbe essere ridotto investendo e collaborando sulle prime iterazioni, e soltanto quando è quantificabile (ed è all’incirca pari alla profittabilità che si può ottenere) il cliente può contrattualizzare la parte più corposa delle lavorazioni, o decidere di interrompere il progetto con l’analisi e lo sviluppo fatto fino a quel momento, ed eventualmente sostituire la squadra.
Questo è parecchio diverso dalla tradizionale fase di preanalisi waterfall! Il fatto che le attività di analisi e di progettazione siano più preponderanti nelle prime iterazioni è perfettamente normale: serial at large, iterative at small. E attività diverse richiederanno skill e forse persone diverse, ma l’approccio resta immutato nei suoi principi e si adatta alle necessità del progetto.

E le modalità commerciali lo dovrebbero supportare, perché altrimenti il cliente tenterà di vincolare il fornitore a impegnarsi su un prezzo e su un perimetro di progetto che non è definibile, e il fornitore farà di tutto per non restare in un recinto troppo stretto.
Le trattative commerciali dovrebbero vertere sulla capacità di un fornitore di offrire qualità, rapidità, affidabilità, e prezzi competitivi giocando sulla sua profittabilità percentuale e sulla sua redditività su larga scala, e non sul tentativo di indovinare il prezzo che copre il margine di incertezza: nessuna delle due parti ha da guadagnarci.

(*) non so se l’avete notato, ma il termine “tecnico” viene utilizzato come il demarcatore delle cose con le quali certe persone non vogliono sporcarsi le mani: in pratica una definizione operativa soggettiva.

13.03.2011 By Alessandro Lombardi

Symphonie de Paris (Symfony Live 2011)

E’ passata più di una settimana dal symfony live 2011, ed è tempo che tiri giù almeno due impressioni su questo evento.

Il mio punto di vista è ormai, definitivamente, più da CTO che da sviluppatore: non ho visto quasi nulla che non fosse già tecnicamente noto e applicato (almeno vagamente), ma le sensazioni sono positive e le sintetizzerei in quattro punti:

1. Touch the change
Un evento del genere è sempre consigliato, aiuta a respirare quella sensazione di “what’s goin’ on”, a vedere come si muove e come reagisce una comunità ai cambiamenti; e in questo senso Symfony è a mio avviso decisamente uno dei fattori trainanti di questo cambiamento.

2. Good, old software engineering
Symfony ha, a mio avviso, il pregio e il valore di introdurre un po’ di sana ingegneria del software in un mondo (quello PHP) che ne sentiva la mancanza.
Ho sempre confrontato le piattaforme Java e PHP valutandone i pro e i contro con il distacco di chi ormai non ha più guerre di religione da fare ma solo problemi da risolvere. Non mi metterò a fare un confronto completo ora, ma dovendo fare una sintesi brutale direi che mentre le verticalizzazioni sul web su piattaforma LAMP si sono sprecate, facendo leva sul largo uso e sulla semplicità di queste soluzioni, le standardizzazioni e i buoni, vecchi sani principi OOP non sono stati molto considerati. Non serve parlare di “enterprise”, stiamo parlando di semplice qualità del software.
Per non parlare del fatto che la produzione reale ha bisogno di vero software configuration management, per gestire il ciclo di vita di una soluzione software.

Symfony sta, in parte, facendo quello che ha fatto Spring in Java; non si sta inventando nulla di nuovo, naturalmente, ma tanto di cappello (anzi, chapeau) a Sensio per aver raccolto un po’ di soluzioni e averle reimpacchettate per noi, in un contesto sicuramente più “KISS” rispetto a quello Java (che ha però anche uno scope naturalmente più ampio).
Non mi sono certo esaltato vedendo concetti come l’Inversion Of Control, l’Aspect Oriented Programming, l’Attribute Oriented Programming, il Behaviour Driven Development e così via: ma ho tirato un sospiro di sollievo!
Mi domando solo perchè ci abbiano messo tanto.

3. Content management framework
Symfony è già di suo un framework che offre uno scaffolding per fare web application: è già una buona base di per sé, ma in fondo stiamo parlando di PHP, più web di così. Però finora i tempi non erano ancora maturi per un vero CMF, mancavano (appunto) le basi. Certo, in un certo senso prodotti come Drupal ed EZ Publish sono CMS con dentro un CMF, ma sono sempre prodotti che possono essere usati “out-of-the-box” via software configuration.
Si è parlato di Symfony CMF, e per me è stato un piacere vedere che le mie idee hanno trovato riscontro. Dato che su questo fronte io e i ragazzi in Dnsee ci stiamo già lavorando, non può che essere incoraggiante sapere che c’è qualcosa in comune. E non aggiungo altro sul perchè a volte è meglio un CMF o un CMS, o su come vedo io l’argomento: farò un articolo appositamente.

4. Fabien Potencier
Beh, ha un po’ la sindrome di protagonismo di Steve Jobs, ma devo dire che se l’è venduta bene. Anche considerando “l’effetto demo” che lo ha colpito nel corso del talk di giovedì, quando il suo keynote (un “hands on symfony 2″) non ha funzionato proprio a dovere. Tra l’altro, devo purtroppo ammettere che è stato un po’ deludente, ma non tanto per l’inconveniente tecnico (può capitare a chiunque), ma perchè mi sarei aspettato un talk dal taglio tecnico un po’ più alto, in cui si descriveva il framework da un punto di vista di di design quanto di produzione. Invece ha puntato tutto sulla “propaganda” del prodotto, per mostrarne la semplicità a coloro che forse non sono abituati a certe soluzioni (leggi “scrivono codice procedurale”).
Decisamente più d’effetto “marketing” invece il talk finale, “one thing more”, in cui (con una buona dose di autoironia francese) ha lanciato di fatto il suo www.symfony.com.
Per chi come me sta facendo convergere una software factory su PHP prima, e su Symfony poi, non può che essere un promettente segnale.

16.02.2011 By Alessandro Lombardi

Cloud is loud

Il titolo non è un granché, ma chiacchierando durante la pausa-cena di lavoro con una certa persona ho ampliato le riflessioni fatte nell’ultimo articolo tra system integrator e web agency.
Si parlava della differenziazione dei servizi: come dicevo le due realtà si collocano ortogonalmente l’una nel dominio dei servizi di consulenza sulla comunicazione, l’altra sul dominio dei servizi di consulenza sui processi aziendali.
E solitamente non è realistico offrirsi come consulenti con le spalle larghe su entrambi i fronti, considerato anche che si parla con interlocutori che hanno tempi ed esigenze diverse, per quanto collegate.
In entrambi i casi, l’offerta di un’azienda di servizi è suddivisa per verticalizzazioni.
Nel mondo dei servizi IT puri, i servizi on the cloud sono una realtà relativamente recente (sebbene ancora poco utilizzata in Italia): basti pensare a esempi come Microsoft Azure, o salesforce.com e al suo database.com. Per non parlare di Google, naturalmente.
Le soluzioni di collaboration, poi, abbondano.

Le virtualizzazioni stanno diventando sempre più verticali, e c’è già chi sta cominciando a fornire CMS on the cloud (potevo pensarci qualche mese prima a cercare “CMS on the cloud” su Google, però!)

Nel mondo della comunicazione pura, all’altro estremo, i servizi offerti sono in fondo legati all’immagine corporate, ai siti di prodotto, e a tutte le attività “social” a contorno. Anche in questo caso, però,  tutto ciò che è “social” è sempre più legato a realtà “esterne” al perimetro del sito web che viene venduto come soluzione di comunicazione digitale.

Ma in fondo Facebook e simili non offrono anche servizi on the cloud? Facebook ha delocalizzato i servizi di promozione della persona, del prodotto, offre una vetrina per tutte le identità sul web più piccole e frammentate.

In conclusione, quindi, quello che mi aspetto dalle evoluzioni tecnologiche dei prossimi anni è qualcosa di simile in entrambi i due mondi: soluzioni per i processi di business e soluzioni per la comunicazione e il marketing, in entrambi i casi fortemente integrate con soluzioni on the cloud eclettiche e variegate, che scaleranno e abbasseranno i costi di esercizio (proibitivi per realtà non sufficientemente grandi).

A pensarci bene, mi viene in mente proprio ora che chiudo questo post: non è forse Google il primo esempio di soluzioni on the cloud per l’azienda (Google Apps) e soluzioni cloud per la comunicazione (come Wave e Buzz)?

La distinzione fra i due mondi è sempre più sfumata, da un punto di vista di tecnologie abilitanti: in entrambi i casi, stiamo diventando sempre più services integrator, quello che cambia è l’enfasi sul tipo di consulenza.

10.02.2011 By Alessandro Lombardi

System Integrator Vs Web Agency

Mi stavo arrovellando su tutte le differenze che si possono riscontrare fra un’azienda di servizi IT e una web agency (per quanto sia completamente contrario a questo nome, preferisco più prolissamente parlare di leggi