www.fabiobeta.itSu queste pagine potete trovare esperienze, idee ed esperimenti di un programmatore in cerca di metodi per lavorare meglio e meno.
Questi sono i post più apprezzati del sito, dateci un'occhiata:
SFTP automatico e natalizio con ANT
La mia cassetta degli attrezzi: Il portatile
III: Tu non commenterai invano
Eclipse: Propaganda a suon di keystroke
Gli altri sono qui.
Milano Cyberpunk
28 Settembre 2009
Era stata una giornata particolare. Invece delle solite corse tra codice e clienti da buon consulente IT, il pomeriggio era scivolato via seguendo le presentazioni di una telco che si era accorta di dover reagire ad un mondo di iPhone e motori di ricerca onnipresenti. Idee sensate, e buon potenziale. Chi controlla il tuo cellulare può far leva sulla tua rubrica in mille modi: i contatti più fisicamente o psicologicamente vicini presentati in coloroso 3D. Contatti legati con le loro anime on-line: chat, social netowrk, caselle e-mail...
Fuggito da lì e dalla tempesta di potenziali clienti e mal di testa, aveva raggiunto la sua ragazza: cenetta in centro. Cenetta pianificata senza fare i conti con un oste ingombrante: la settimana della moda di Milano. Piazza del Duomo circondata di impalcature. Musica tutt'intorno. Modelle che sgambettano con videocamere che le seguono da almeno tre direzioni contemporaneamente.Proiezioni con la facciata della chiesa come schermo, abilmente innestate nelle linee geometriche del gotico stratificato negli ultmi 400 anni.
E passando davanti alla Rinascente, il centro commerciale che in vetrina sta mostrando live le passeggiate della passerella, la finale pugnalata alla sua privacy. Il cellulare vibra: è arrivata un'e-mail. Un'e-mail da D&G, in cui una Claudia Schiffer digitalmente ringiovanita lo invita all'evento di moda del giorno dopo, dentro il centro commerciale.
Il motore di ricerca aveva osato fare l'ultimo passo, era uscito dai cavi e dai monitor, per entrare nella realtà e nello spazio.
Era, ovviamente, il 24 Settembre 2009.
send a feedback to fabio
Google Developer Day - Report
24 Ottobre 2008
Open Reply mi ha gentilmente fornito un invito per il Google Developer Day di Milano.
Con altri colleghi ci siamo spartiti le numerose sessioni da seguire per massimizzare l'assorbimento di informazioni, quindi faccio il mio dovere e annoto cosa ho visto durante la giornata :)
OpenSocial & The Social Web
Facendola corta, questo mondo si sta sovrappopolando di social network che hanno si delle differenze tra di loro (c'è il social network dei colleghi, quello delle tipe con cui vorresti uscire, quello dei manager, quello degli elfi oscuri), ma condividono tutta una serie di informazioni (quanti profili ho già compilato con la mia data di nascita? In quanti social network ho già dichiarato di conoscere Luca?).
Open Social nasce come semplificazione a questo caos: un'interfaccia comune di esposizione dei dati di un profilo e della sua rete, così si aumenta l'interoperabilità.
Google ovviamente lo piazza sul suo Orkut (che non si sa bene perchè, ma lo usano solo i brasiliani).
Che dire, son contento che si spinga per una maggiore interoperabilità tra i Social Network (l'idea di dover esportare la mia lista di contatti di linkedin al momento mi fa ancora rabbrividire).
Gears
Forse la sessione più bella. Brad Neuberg è veramente in gamba.
Gears è una cosa un po' strana. Di fatto google ha deciso come vorrebbe che fosse l'html 6 (stiam ancora aspettando il 5) e si è messo al lavoro. Gears si aggangia a Firefox e Internet Explorer (e nasce già dentro a Chrome) e va ad aggiungere funzionalità:
- un SQLlite
- funzioni di ricerca client side
- il worker pool: quando deve partire un nuovo processo, va a metterlo in un thread separato (un po' come fanno i tab di chrome)
- mashup cross domain sicuri
- desktop api: una pagina web può essere "trascinata" sul desktop e diventare un'applicazione indipendente
- local server: un sito può trsferire parte di se stesso sul tuo pc, e renderti disponibile parte delle funzionalità anche off-line (esempio: prima o poi potrò usare gmail anche in aereo, magari con solo l'ultimo giga di mail disponibile in locale)
- gestione di blob. In pratica una migliore gestione dell'upload dei file
- API di accesso al file system (il minuscolo esperto di sicurezza che è in me rabbrividisce)
- la geolocalizzazione: avete presente quelle mappe che tentano di scoprire dove vi trovate a partire dal vostro IP e concludono che vi trovate a Ivrea? Gears tenta di migliorare la cosa. Consulta il GPS se c'è. Poi prova con le wireless (fighissimo!). E infine si arrende e usa l'IP. In un mondo che va verso gli 8 milinoni di I-Phone e che ha già preordinato 1.5 Milioni di "G-phone" è uno sviluppo interessante :)
Per ora il limite di Gears è che richiede l'installazione di un altro cazzillo/plugin nel browser, ma come rispondeva Brad alla mia fetente domanda, la speranza è che HTML 5 (e di conseguenza i browser moderni) recepisca il più possibile dello sviluppo di Gears, rendendolo parte integrante della nostra vita di navigatori in pochi anni.
Chrome V8
Su Chrome si è già detto troppo. La mia curiosità era per V8, il motore di javascript iperveloce che fa correre Chrome nei test di performance.
Veramente interessante il ragionamento fatto per V8: il motore "deduce" dinamicamente che due oggetto javascript implementano la stessa classe nascosta, e li gestisce di conseguenza con le tipiche ottimizzazioni OO, spingendo pure un po' sulla garbage collection.
Finito il rispetto reverenziale per V8, Chrome. Bellino. Il tecnicaccio che è in me gioisce a veder funzionare i tab come processi indipendenti (così il primo che si pianta non blocca tutti gli altri), ma per ora non vedo di che conquistare il mondo dei browser.
Android
Sono andato alla sessione per curiosità personale: Reply ha partecipato alla Challenge di Google e ho pure firmato un articolo a riguardo.
La sessione era la semplice esecuzione dell'HelloWorld che ti spiega il tutorial, però presentato con l'esperienza dello sviluppatore del team.
La sessione era da remoto (erano le 7 e 30 oltreoceano quando l'eroico relatore arrivava in ufficio) per un buon motivo: il resto del team stava rilasciando tutto il progetto in Open Source!
In complessivo: bella giornata che aggiorna rapidamente e facilmente sulle ultime novità, forse così facilmente che sul momento ero un po' insoddisfatto...
le presentazioni erano mirate a far usare i prodotti di google alla platea di sviluppatori, ma la sensazione "noi scriviamo il codice, voi impilate i cubetti" mi dava un po' il prurito :)
send a feedback to fabio
Guerrilla Meeting: 6 idee per sopravvivere ad una riunione
9 Gennaio 2008
Ieri sera ho riletto con soddisfazione questi due articoli su come soprevvivere alle riunioni. E mi sono accorto che qualche idea buona l'avevo anche io :)
1
Appena arrivato al tavolo, fai una mappa del territorio. Specialmente in quei meeting in cui ti trovi a incontrare qualcuno per la prima volta. Fatto uno schizzo del tavolo, piazza i nomi dei partecipanti in corrispondenza di dove sono seduti. Se riesci aggiungi i dettagli significativi: il ruolo, la società per cui lavora, la data delle nozze...
Quando, mezz'ora dopo, vorrai interrompere quel tizio che sta parlando a vanvera, potrai chiamarlo per nome. Spiazzandolo. Mentre tu spiegherai perché la sua idea non funziona, lui starà chiedendosi chi sei, per quale società lavori e perché sei li, invece di ascoltarti per ribattere. E darai alla stanza la sensazione di sapere veramente a cosa serve la riunione, visto che conosci gli invitati.
2
Una riunione può nascere per molti motivi... spesso troppi. Io cerco sempre di avviarmici con due liste di punti da affrontare:
- quelli che servono a me e sono in argomento
- quelli che servono a me e NON sono in argomento.
Se anche la riunione comincia a deragliare, posso provare a riportarla in pista almeno per i punti che mi riguardano.
Le belle riunioni, quelle che funzionano, hanno un facilitatore focalizzato che fa rispettare una scaletta. Le altre purtroppo no, ma è comunque lavoro nostro cavarne il più possibile.
La lista dei punti NON in argomento? E' lì perchè non si sa mai: magari ti trovi al caffè con qualcuno, o la discussione deraglia...e si presenta l'occasione per portarsi un po' avanti con il lavoro.
Per alcuni progetti sono arrivato anche a segnarmi i punti che mi conveniva venissero sbloccati per altri team... perchè
- un po' di karma positivo non fa mai male
- certe volte hai maledettamente bisogno che anche gli altri vadano avanti nel loro lavoro.
3
Segnati tutto. Tutto.
Qualcuno dichiara la sua e-mail o il suo numero di telefono? Segnateli. Potrebbero essere del tizio che un venerdì alle 17.59 sarà l'unico sopravvissuto con la password del db di produzione.
Qualcuno dichiara una password? Segnatela. Beninteso, nessun incorraggiamento ad infrangere la legge, ma se quel tizio poi non risponde al telefono...
Il cliente accenna al fatto che le licenze del software scadranno nel marzo 2010? Segnatelo. E poi riportalo sull'agenda. E a febbraio 2010 manda una mail al cliente.
Qualcuno ti chiede di dire qualcosa ad un tuo collega? Segnatelo, altrimenti dopo due ore di riunione riuscirai solo a dire "Ah, Paolino voleva dirti qualcosa, sentilo poi eh?".
Questo consiglio (arrivato da colleghi più scafato) mi è stato incredibilmente utile nei miei primi incarichi "di responsabilità". Magari come sviluppatore e basta puoi ricordarti tutto quel che riguarda il tuo lavoro. Male che vada se non ti segni un'informazione sprechi del TUO tempo per recuperarla.
Invece, appena cominci a sprecare il tempo degli altri ti senti un idiota.
4
Ti senti l'unico che non ha capito qualcosa mentre gli altri annuiscono? Sicuramente non sei solo. Tira fuori un po' di faccia tosta ed esordisci "Giusto per vedere se ho capito..." e ripeti il ragionamento fino al punto in cui si inceppa. Fermati. Tanto qualcuno ti avrà già interrotto e starà discutendo con il tizio seduto accanto a lui. Hai fatto al figura del tonto per qualche secondo, poi sei diventato l'unico che aveva notato la falla :)
5
Per suppotare i punti precedenti, non dimenticare quaderno e penna :)
6
Neanche troppo ironicamente: evita le riunioni. Una buona mail, due passi all'ufficio accanto, una telefonata sono sempre soluzioni migliori.
send a feedback to fabio
Surrender to Reality
12 Novembre 2007
Ammettilo a te stesso e al mondo:
Il cliente cambierà idea. Le specifiche non sono stabili.
Questo succede perché il cliente non sa ancora cosa vuole. Arrenditi. Arrabbiarsi per cambiamente grandi o piccoli è come arrabbiarsi perchè piove. Capita.
Tutto quel che puoi fare è tener d'occhio le nuvole e nel caso portarti dietro l'ombrello.
E l'ombrello nel nostro mondo lo ottieni se:
Stai a contatto con questo benedetto cliente. Più ci parli più è facile capire se ti sta chiedendo di costruire uno shuttle per attraversare la strada o se si è dimenticato qualcosa di palesemente indispensabile.
Inoltre aiuta a sviluppare un dizionario comune. Se sia gli sviluppatori che il cliente chiamano la nuova funzionalità nello stesso modo, eviterai di trovarti a reimpaginare l'interfaccia per farci stare il nome business (di 42 caratteri) del prodotto ACME2. Qusto tende a capitare la notte prima della consegna finale...
Fai demo e rilasci frequenti. Più spesso rilasci, meno ti allontani dai desideri del cliente prima di accorgertene.
Cos'è meglio, un cliente che mugugna oggi perché gli bruci due ore tutte le settimane o un cliente che bestemmia tra 3 mesi?
Parti dal presupposto che il cliente non sappia cosa vuole. E' parte integrante del tuo lavoro portarlo a questa comprensione. Davvero. E se lo si fa consapevolmente ci si demoralizza molto meno e ci si diverte di più.
Prenditi dei margini.
Lavori in modo agile e le storie da sviluppare vengono scelte in base alla velocità che dichiari? Alloca una percentuale della velocità a cuscinetto, e mettici esplicitamente un paio di storie che se saltan fuori grane puoi rimandare.
Campi a Gantt? Usa quei benedetti Slack invece di mangiarli per accorciare le stime.
Una nota collaterale: per cliente intendo un essere umano dotato di neuroni e con il diritto di prendere decisioni. Se ti rifilano lo stagista o il peso morto dell'ex-ufficio conteggio fagioli, non stai parlando con il cliente, stai parlando con una perdita di tempo. Fallo presente subito, ribellati.
Piuttosto tendi agguati alle persone che veramente contano e cava da loro più informazioni possibili.
send a feedback to fabio
ESSAP 2007!
6 Luglio 2007
Nei giorni scorsi sono stato alla ESSAP. Un po' per dare una mano al prode organizzatore Matteo, un po' per "sfruttare" le idee ed esperienze di studenti (sia laureandi che sviluppatori di professione) e docenti. E' sempre spettacolare rendersi conto di quanti problemi in comune hanno persone che lavorano nell'IT, agendo nel contempo in situazioni e ambienti diversi.
Prima di dimenticarmene, riporto i concetti che più mi hanno intrigato:
Personas: Introdotta da David Hussman e Rick Mugridge, la "semplice" idea di usare "personaggi" (Cathy the chatter) invece che omini stilizzati in stile UML ("Utente della chat") per raccogliere storie e requisiti è ottima. Semplifica molti dialoghi. Crea un dizionario comune tra sviluppatori e clienti. Permette di inquadrare anche utenti formalmente uguali, ma con obiettivi diversi (es. Betty la compulsive-shopper e Tim il taccagno).
Programmazione Parallela: è un'idea che sento rimbalzare in giro da un po' (ma se cerco swarm programming su google l'unico riferimento è su questo blog :) ). L'abbiamo usata l'anno scorso all'xpug per migliorare l'esperienza di collaborazione sui nostri progetti-esperimento. Io la uso per il bug-fixing. Matteo la riportava da altri team di sviluppo.
L'idea è semplice: se c'è fretta di ottenere un risultato (es. finire una funzionalità in ritardo o correggere un baco), la letteratura spiega che aggiungere risorse al processo tipicamente ha un effetto contrario al desiderato, ostacolando l'avanzamento per via dell'aumentato overhead di comunicazione. Però, se si hanno i soldi da spendere per aggiungere persone al progetto, una possibilità c'è. Si fanno lavorare in parallelo più persone/coppie/team per lo stesso obiettivo, scommettendo sul fatto che qualcuno finirà prima o meglio degli altri.
Immaginiamo di avere il 70% di probabilità che un pair finisca un lavoro in tempo. Attivando in parallelo 2 coppie la probabilità di successo sale al 91% e al 97% con 3. Ovviamente è un metodo da usare con consapevolezza. L'obiettivo non è mettere in competizione i membri del team, e il team deve essere abbastanza maturo da poter metabolizzare il concetto.
L'importanza, in ogni situazioni in cui si desidera avere condivisione di conoscenza ed esperienza, di spazi "liberi" di scambio. Matteo ha organizzato il primo pranzo della scuola in stile pic-nic nel fantastico giardino di Villa Toepliz, e i gruppetti che si formavano spontaneamente per parlare di linguaggi, pattern, clienti pazzi e buzzwords varie erano veramente una bella immagine :)
Un grosso ringraziamento a tutti i partecipanti e organizzatori!
send a feedback to fabio
Passaggio di consegne: corto è meglio!
13 Giugno 2007
Ci sono tante situazioni in cui serve un passaggio di conoscenza: qualcuno viene promosso, va in ferie, cambia lavoro, magari vuole introdurre nel team un nuovo tool o linguaggio di programmazione di cui è l'unico esperto..
Saltando spesso di progetto in progetto, a volte passando le consegne, a volete ricevendole, il mio personale metodo è evoluto verso misure drastiche. Il passaggio di consegne che funziona è breve e fulminante.
E' ragionevole che chi lascia qualche competenza scoperta dia un'introduzione e una panoramica a chi erediterà il suo ruolo, correlate con i dettagli essenziali (per esempio: la password del repository!). Poi però deve SPARIRE. E' sopportabile un po' di reperibilità telefonica, ma senza esagerare.
Il nuovo martire si trova così a dover sviluppare il suo approccio ai problemi: la necessità aguzza l'ingegno no? La reazione dell'intelligenza di una persona quando non ha più nascondigli è fenomenale :)
Quando si a guida le prime volte, sono più istruttive le guide accompagnati da qualcuno o quelle in solitudine? Finché non si comincia da soli a scegliere quale strada percorrere e non ci si assume la piena responsabilità del controllo dei freni, non si impara.
A incoraggiarmi in questo approccio draconiano ci sono anche le abitudini sociali: se il vecchio referente è in zona, tutti continueranno a rivolgersi a lui nei momenti di necessità o di crisi. Meglio forzare la mano anche in questo caso. Se il cliente vuole che sia fissato un baco nell'applicativo di Ugo, gli si dirà che Ugo è irreperibile, e può rivolgersi a Gino. Anche se Ugo è nella stanza accanto.
Il passaggio di consegne lungo di solito lo vedo strisciare verso l'inutilità: il ricevente si abitua ad avere il precedente referente a portata di mano, e il suo cervello SMETTE di memorizzare i dettagli, perché sa a chi chiederli. O peggio ancora, si scava una nicchia di competenze, diventando una specie di assistente di chi invece dovrebbe mollare l'osso, rimandando l'inevitabile sfida con l'ignoto.
Addirittura, se vogliamo attaccare un problema di un passaggio di consegne di codice spinoso con il PairProgramming, è una buona idea, dopo pochissime ore di Pair, che il custode del sapere sia allontanato da suo tesoro: il fatto che sia diventato l'unico esperto sul funzionamento di un componente è già un brutto segno. Meglio mettere due teste fresche a lavorare sulla matassa, così da generare rapidamente due persone in grado di sbrogliarla nel momento del bisogno.