Pezzetti di conoscenza, frammenti di idee, argomenti indifiniti ed indefinibili appartengono alla categoria di tutto un po’
Anche se con un po’ di ritardo siamo in dirittura d’arrivo con il secondo libro della serie Best Practices edita da FAG. Si tratta di Javacript Best Practices e ne farò la presentazione durante il jsDay a Verona distribuendone, in anteprima, un capitolo gratuitamente.
Qui di seguito la copertina del libro :)
Se lo scorso anno, con il GrUSP vi abbiamo deliziato con il nostro primo libro su PHP, quest’anno lo faremo con quello su Javascript. Infatti per FAG Edizioni, insieme ad altri autori, sto scrivendo Javascript Best Practices. Se tutto va bene, ed i ritardatari finiranno per tempo i loro capitoli, vedrete il libro a Verona durante il prossimo JsDay. Così come per PHP Best Practices anche questo libro è un cookbook dove ogni capitolo affronterà uno specifico argomento legato a Js. Si parte quindi dai LocalStorage, a me molto cari, passando dagli ambienti di test automatico, a CoffeeScript, Node.Js e Pattern di sviluppo.
Affiancato a questo libro, ed all’organizzazione di tre conferenze diverse (anzi quattro), ho iniziato a lavorare (grazie alla mancanza di sonno indotta da cause esterne) a qualcosa di diverso.
I would never imagined to write a post on OSX, moreover in english, but time changes everything.
After I installed the new version of Zend Server 6 I had some issue with phpMyAdmin. A laconic
#2002 - Connection refused
The server is not responding (or the local server's socket is not correctly configured).
is shown up on chrome with no mercy.
The fix is quite easy as it subtle, open
/usr/local/zend/var/apps/http/__default__/0/phpmyadmin/3.5.6.0/config.inc.php
and change
$cfg['Servers'][$i]['host'] = '127.0.0.1';
with
$cfg['Servers'][$i]['host'] = 'localhost';
that’s it.
Fa caldo, e con il caldo la parte di cervello che si occupa di pensiero laterale (ed odio verso il prossimo) va sempre a mille. Soprattutto quando mi fanno indispettire.
Se un paio d’anni fa avevo ipotizzato
un social network per identificare possibili clienti insolventi (idea da subito interdetta dal mio avvocato di fiducia) oggi dopo l’ennesima chiamata di un call center sky/fastweb (risponde ai numeri 01179191 e 01179190) e dall’impossibilità di reindirizzare le chiamate (a costo loro) su un 899 di mia proprietà al fine di rendere la scocciatura, almeno, lucrativa ho iniziato a fantasticare su attività di vendetta sociale.
Una specie di legge del taglione 2.0.
C’è un call center particolarmente fastidioso (come quello di sky/fastweb)? Volete vendicarvi delle chiamate ricevute a qualsiasi ora? Beh fare uno script twilio che continui a chiamarlo in ingresso bloccandogli la linea non è particolarmente complesso. E cosa sono 5€ di autotassazione via paypal per avere ulteriore credito di vendetta?
Quasi quasi faccio un pitch su kickstarter…
revengeful,
fullo
Manca ormai una settimana all’evento che con gli altri ragazzi del GrUSP abbiamo iniziato ad organizzare a Novembre: jsDay e phpDay. I programmi di entrambe le conferenze sono saturi di relatori di gran calibro e parlare nella stessa conferenza insieme a Douglas Crockford mi fa sentire un po’ un privilegiato *.
Cosa interessante è che se lato jsday il trend è quello dei videogiochi, tra le oltre 100 proposte molte vertevano sullo sviluppo di giochi per browser, lato phpday uno dei problemi più sentiti è quello del deploy (e successivo mantenimento) del codice. Insomma due mondi che, nonostante siano molto vicini concettualmente (sempre di “web” si parla), si stanno allontanando molto dal punto di vista delle problematiche degli sviluppatori.
Sempre con/per il GrUSP ho coordinato la scrittura (a 2 dozzine di mani) del libro PHP Best Practices, edito da FAG Editore, che verrà presentato al phpDay. Il libro è un cookbook di circa 400 pagine che tratta svariati argomenti, dalla partecipazione alla community di PHP fino a come fare deploy con Ant… Prendete un assaggio dal sito ufficiale e ricordatevi che parte dei proventi vanno all’associazione.
Ho tenuto questo speech all’ottimo php.to.start di Torino, ricevendo molti feedback interessanti.
Preparandolo mi sono accorto come in ideato le idee cardini della filosofia lean fossero presenti prima ancora che quest’ultima diventasse un qualcosa di mainstream. Tutto quello che abbiamo fatto negli ultimi anni infatti è basato sul concetto di fare, analizzare quello che (ci) succede e far evolvere (pivotare) il nostro modo di lavorare e collaborare con i clienti.
L’idea è venuta fuori un po’ così per scherzo durante una sessione di release planning (e mentoring) con una startup: “Perchè non creiamo un cowo dove ospitare le proto-startup e le startup che di volta in volta ci vengono a chiedere supporto nel metodo e nella tecnologia?“. Dopo 30 minuti stavamo già discutendo con il buon Brando e Nicolò per capire come aprire qualcosa tra un cowo ed un talentgarden a Cesena.
Ad oggi abbiamo trovato (proprio sopra al nuovo ufficio di ideato) un openspace da 400mq (300mq open e 100mq in sala riunione/corsi) ad un ottimo prezzo, siamo circondati da facoltà tecniche (informatica, ing. informatica, ing. biomedica, ing. elettronica, architettura ed agraria) ed umanistiche (psicologia ed scienze del comportamento) che ogni anno sfornano alcuni ottimi esemplari che poi “emigrano al nord” e possiamo fornire esperienza “sul campo” da condividere.
Quello che ci manca è un investitore (serio) interessato al progetto e feedback dai cowo che non vivono in zone popolose come Milano, Roma o Firenze. Chi è interessato?
Parlando con alcuni clienti che avevano letto “The lean startup” di Ries mi sono accorto come sia stato mal interpretato il discorso di “ridurre gli sprechi” percependolo come non faccio nulla e vedrò quello che succede con quello che ho già.
A mio parere, quello che dovrebbe essere assimilato dal messaggio lasciato dal libro è che la riduzione degli sprechi (l’essere lean) è solo una conseguenza di un’attività costante basata sul fare.
Fare MVP. Fare a/b test. Fare analisi degli stakeholder. Fare focus group. Fare pivot e scrivere nuovo codice. Fare, fare, fare!
Il fare tutte queste cose iterativamente, con critica costruttiva e guardando ai propri risultati frequentemente porterà a ridurre gli sprechi ed a migliorare il tiro facendo la scelta giusta. Il non fare invece porterà il lavoro fatto precedentemente ad essere esso stesso uno spreco non creando nessun valore.
ciuaz
Era da un anneto abbondante che non mi capitava di fare una tournè su tutto il territorio italiano con talk che spaziano da html5 fino al lean, ed invece pare proprio che metà-fine Marzo sarà un periodo molto impegnativo a riguardo.
Si inizia il 21 marzo con il php.to.start a Torino, organizzato dal PUG Torinese (sono sempre più orgoglioso di aver contribuito alla nascita dei pug locali) dove parlerò di come vivere su internet senza essere (per forza) una web agency.
Il 22 pomeriggio sarò invece a Bologna ad un Meetup organizzato da Intel nel programma Intel AppUp University come relatore sulle potenzialità di HTML5 ed un piccolo intervento/tutorial sui sistemi di storage client side (ormai mio cavallo di battaglia).
Stesso argomento tratterò il 24 a Roma durante il CodeMotion nel talk che ormai sto portando in giro da un annetto e che, pare, sia abbastanza richiesto.
Vi ricordo inoltre che il 13 Aprile ci sarà il Mobile PHP a Milano evento/barcamp gratuito ed aperto a tutti che verterà sull’utilizzo di PHP a supporto del mondo mobile.
Ci vediamo in giro!
Passando molto più tempo a gestire la (follia della) gente che sul codice ho iniziato a rivedere alcuni concetti a me cari durante la mia precedente, e forse futura, vita da sviluppatore. Uno di questi è la riusabilità del codice.
Il primo tarlo sull’argomento si è presentato quando, durante l’Agile Day di Roma, mi è stato chiesto se in ideato reinventavamo la ruota ogni volta e per ogni progetto. In quell’occasione la mia risposta, data di getto e senza pensarci troppo, fu: “utilizzeresti del codice (anche tuo) scritto 4 anni fa?“. Il principio di base è che in 4 anni la tecnologia (sul web) evolve tantissimo, ed allo stesso modo evolvono le competenze dei team, riutilizzare quindi codice obsoleto e potenzialmente legacy non fa altro che limitare le potenzialità di uno sviluppatore (riducendo in alcuni casi la qualità globale del progetto).