Qui di seguito la copertina del libro :)

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.

Quello che segue è il pesce d’aprile 2013… grazie per aver abboccato :)

Per ora non ho deciso il titolo, ma sono già abbastanza avanti con trama ed intreccio delle storie. Ogni capitolo infatti vedrà la storia raccontata da un diverso personaggio, usando punti di vista differenti per lo stesso avvenimento. Nel romanzo si parlerà di tecnologia (futuribile e futuristica), intrigo ed un sano humor nero il tutto scritto in un incrocio stilistico tra Matt Ruff, Douglas Adams e Christopher Moore…

Il primo capitolo-racconto è scaricabile gratuitamente.

Al prossimo anno ;)

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.

Con ideato, nonostante la fuga di cervelli e una sempre più evidente crisi del mercato, abbiamo aumentato fatturato e profitto (anche se con risultati sotto le aspettative) e reinvestito gran parte dello stesso all’interno dell’azienda per tentare la via della realizzazione di startup/prodotti. Eppure, lavorativamente parlando, ho sempre una sensazione di amaro in bocca che non mi fa godere a pieno dei risultati ottenuti.

Il lavoro ben fatto in Italia non paga, paga quello che costa meno #emigriamoXPUG #fail

— Massimo Azzolini (@massimoazzolini) January 3, 2013

Ho sempre pensato che il modo migliore per fare impresa fosse di fare un’impresa migliore. Evidentemente mi sbagliavo.

Gran parte del mio personale effort è concentrato su far si che chi lavora per me (e con me) sia soddisfatto ed abbia tutti gli strumenti necessari al fine di poter ottenere buoni risultati. Il famoso 20% di tempo decantato da Google per fare autoformazione o progetti personali in ideato si è trasformato in un investimento effettivo di circa 24 giorni pro-capite spesi tra conferenze, eventi, corsi interni all’azienda e sessioni di hacking (più o meno riuscite). Ho coinvolto altri professionisti in serate dedicate ad argomenti utili al team per aprire la mente ascoltando nuovi punti di vista (non da ultimo un tinktank sull’emigrazione scaturito in un gruppo facebook che ha fatto 225 proseliti in un giorno).

Eppure, nonostante tutto, il clima che vivo è quello dell’impresa che è considerata di ottimo livello ma che stenta a decollare.

Colpa (probabilmente) di una miopia da parte del mercato verso i temi della qualità del settore tech, colpa (altrettanto probabilmente) di una mia mancanza di coraggio ad aggredire quest’ultimo con una rete commerciale più ortodossa (ma vendendo soluzioni ritagliate su specifiche esigenze è tutto un dire cosa sia ortodosso).

La frase più angosciante di ieri sera: “vendere online in Italia è un delirio” @fullo @pracucci #emigriamoXPUG #nazionedemenziale

— ziobrando (@ziobrando) January 4, 2013

Colpa (sicuramente) della difficoltà di creare un’impresa che possa (dal giorno zero) lavorare in, e con, tutto il mondo senza doversi porre eccessivi problemi burocratici-amministrativi, litigare con clienti che fanno di tutto per non pagarti (o di farlo in ere geologiche) e che possa, in Italia, offrire stipendi degni senza soccombere ad una pressione fiscale non indifferente.

@cphp peccato che ci sia di fatto una scappatoia per far pagare anche a più di 60 gg tra aziende, v. comma 3 art. 2 normattiva.it/uri-res/N2Ls?u…

— Alex Pagnoni (@alexpagnoni) January 3, 2013

Più passa il tempo e più mi accorgo che le attività che facciamo sempre più di frequente sono quelle di risolvere problemi dovuti, sostanzialmente, a mancanza di metodo di lavoro da parte di altri. Insomma, mi pare che si faccia poco di veramente innovativo e che nella penisola l’innovazione piaccia poco, ma che tutti siano concentrati nel metterci una pezza, a creare gruppi di discussione (e non d’azione) o a creare startup senza un business model.

“Apri una inc/ltd/ghmb” mi dicono. Eppure continuo a chiedermi che senso abbia aprire all’estero per poter fare un lavoro che, potenzialmente, potrei fare in Italia? E perché devo sentirmi obbligato ad emigrare per poter fare il mio lavoro con soddisfazione e piena legittimazione?

Quando nacque ideato abbiamo ponderato la scelta di rimanere a Cesena piuttosto che spostarci in una città come Milano proprio perché volevamo vivere, lavorare e farci famiglia in una cittadina a misura d’uomo. “Lavoriamo con internet” ci dicevamo “non ci sono barriere a quello che possiamo fare“. Ed invece, per crescere professionalmente pare obbligatorio andarsene, dall’Italia.

Non che nell’immediato voglia farlo, ma la prospettiva di doverlo fare mi fa incazzare. Ecco si.. incazzare.

Voglio fare l’imprenditore, non credo nella politica. Non in quella italiana fatta di populismo, gente che si urla contro e che non ha un vero piano d’azione che non sia quello di vomitare bugie e rendersi bella in tv. Non credo neanche nelle attuali forze politiche (vecchie ed emergenti) che hanno la presunzione di dire di rappresentarmi e con le quali non voglio avere nulla a che fare (uno dei motivi per cui non voglio che la mia azienda lavori con istituzioni politiche, statali o simili). Probabilmente ho smesso di credere all’intero sistema-Italia da tempo, eppure voglio ancora resistere.

Ecco il prossimo tinktank lo facciamo sulla resistance.

Bah.. buon 2013… E viva la resistànce!

Starò invecchiando, e di conseguenza la mia pazienza starà (ulteriormente) riducendosi, ma di sentirmi ripete filippiche di quanto siano interessanti, stravaganti, azzardate e brillanti le Soluzioni trovate mi irrita. Non mi interessano le Soluzioni. Ancora meno mi interessano le soluzioni tecniche. Almeno, non mi interessano quanto i clienti/studenti/futuri-zuck vorrebbero.

Quello che più mi interessa è qual’è il vantaggio (inteso come unique value proposition, da non confondersi con il vantaggio competitivo descritto nel libro) che queste presunte Soluzioni riescono a portare. Spiegato possibilmente in due parole e, magari, con obiettivi (associabili anche a delle key metrics) chiari.

Supponiamo che il problema sia “raggiungere un luogo in minor tempo”. Prima ancora di pensare ad una Soluzione geniale [ie. "usiamo un jet"] è necessario, a mio parere, capire bene il perché vogliamo raggiungerlo nel minor tempo. Qual’è il vantaggio che vogliamo veramente ottenere nel risparmiare un po’ di tempo. In base a questo, semplice, principio si può decidere se ha senso investire qualche milione di euro per un jet oppure ne bastano qualche centinaia per una bicicletta. E soprattutto ci permetterà di capire se il problema è generalizzabile o meno, e come costruirci sopra un MVP efficace.

Sapere bene quali sono i risultati a cui si vuole arrivare serve anche a chiarirsi, non poco, le idee sul business in cui ci si vuole addentrare. Avrà senso sviluppare tutte le funzionalità richieste dalla Soluzione? Oppure posso limitarmi a quelle che garantiscono parte del vantaggio immediatamente?

Se Maurya mette lo studio, e la definizione (UVP), delle metriche ottenute (key metrics) come una delle ultime cose da analizzare quando si prepara un lean canvas per me, invece, è una delle prime attività da fare per capire se il dominio del problema è stato veramente studiato a fondo. Saranno proprio le metriche che vogliamo ottenere ad indicare al team di sviluppo come muoversi, e saranno sempre queste ad essere una cartina al tornasole per tutto il processo di validazione del prodotto con gli utenti finali.

La Soluzione sarà, poi, solo uno dei possibili punti di arrivo.

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

Then create a php file like this:

[code]
// issues.php
$file = fopen('./issue.json', 'r');
$content = fread($file, filesize('./issue.json'));
$issues = json_decode($content);

// I retrieve milestone, issue number, state, title and description
foreach ($issues as $i) {
echo $i->milestone->title.";".$i->number.";".$i->state.";".$i->title.";".$i->body."\n\r";
}
?>
[/code]

and execute it to have issues on a csv file

[code]
php issues.php > issues.csv
[/code]

That’s all!

Non che io stesso non ne faccia uso, o abuso. D’altronde con ideato stiamo offrendo proprio l’implementazione di idee di MVP a startupper in erba, o seriali, che vogliono validarle su un mercato più ampio.

Quello che però è difficile da far capire veramente è che il mininum viable product non è, e non deve essere, l’applicazione che vorreste (nella sua totalità) fatta con bootstrap ["che tanto risparmiamo sul design"].

Un MVP è user centered

Design non significa fare delle grafichine carine o spendere 50$ su 99design. Significa trasformare la soluzione immaginata secondo un paradigma facilmente comprensibile ed utilizzabile dai nostri, futuri, utenti. Chi prova a realizzare un qualsiasi prodotto senza pensare, prima, ai propri utenti/clienti che lo useranno sta fallendo in partenza. Provate a leggere cosa ha da dire Mucignat a riguardo.

Allo stesso tempo non bisogna credere che siccome l’MVP contiente la parola “minimo”, e potrebbe non avere al suo interno neanche una riga di codice, possa essere realizzato (o portato avanti) gratuitamente.

Un MVP non è gratis.

Prendiamo come esempio “Food on the Table” di Manuel Rosso citato da Ries in the Lean Startup. In questo caso Rosso, CEO della startup, decide di testare sul mercato reale il funzionamento della sua idea mettendosi in primo piano nell’aiutare un (unico) cliente a pianificare la spesa, portarla a casa e cucinare deliziosi manicaretti. Senza software, senza gli chef previsti nel pitch, senza grandi investimenti economici.

Un MVP gratuito direte voi.

Sbagliato! Perchè Rosso ha speso il suo tempo e dei suoi collaboratori, ha investito nella sua stessa persona togliendo all’azienda risorse utili a fare il prodotto. Ha quindi spostato il proprio budget per fare attività necessarie ed indispensabili: l’analisi del mercato, la customer discovery e validation. Il tutto, citando Ries, in un modo totalmente inefficiente dal punto di vista pratico ma di grande impatto per capire e studiare come far evolvere il prodotto nella giusta direzione.

Un MVP deve insegnare qualcosa.

In realtà, quello che penso, è che il termine MVP sia intrinsecamente errato o meglio porti a facili fraintendimenti (così come Agile). Dovrebbe essere più qualcosa come MVP2LS: Mininum viable product to learn something (about my own business). Se non c’è la premessa, nel realizzare un qualsiasi prodotto di test, di ottenere metriche sul mercato, sulla bontà dell’idea o su un modo ottimale di implementare la soluzione ad un problema allora si sta sbagliando qualcosa.

Lo stesso Ries, in tempi non sospetti, affermava che (enfatizzazioni mie):

MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Questo però comporta avere un’idea di fondo su cosa si sta facendo e di aver studiato un minimo il mercato su cui ci stiamo buttando a capofitto. Soprattutto significa che, dopo che ho fatto mio quello che l’MVP mi doveva insegnare, devo essere pronto ad applicarlo, anche se questo comporta stravolgere l’idea di base del mio progetto.

Significa quindi investire, di nuovo, tempo/soldi/risorse. Rientrare nel loop di build-measure-learn.

Quanto costa un MVP?

E’ una risposta che non so dare. Tecnicamente posso stimare il costo di implementazione di qualcosa o raffinare la proposta in modo che sia tecnicamente realizzabile e misurabile nei budget a disposizione.

Ma la progettazione di questa idea deve nascere dallo studio del mercato che solo lo startupper può, e deve, fare. Allo stesso modo il suo utilizzo e lo studio dei risultati al fine di capire come iterare sono attività che devono essere fatte dal team della startup stessa ed hanno un costo di difficile analisi preventiva.

Riassumendo se volete realizzare un MVP dovreste:

• investire in analisi del mercato (anche non troppo approfondite, quel giusto che serve per capire da subito che l’idea non è una ca…ta)
• fare customer discovery e validation intervistando i futuri, prossimi, utenti
• creare un prototipo del servizio (anche offline) che sia funzionale ai dati ottenuti e che volete ottenere
• pubblicizzarlo
• studiarne i risultati e validarli con le ipotesi fatte inizialmente
• provare a migliorare la user experience, possibilmente senza aggiungere funzionalità
• reiterare da capo

Quanto è costato il vostro MVP?

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.

Altro progettino estemporaneo portato avanti in nottura con Roberto, Alfredo e molti altri è Eureka! per il concorso app4italy. Si tratta di una applicazione disponibile, per ora solo, per Android che sfrutta e rielabora alcuni opendata messi a disposizione dall’istat per analizzare la qualità della vita di una certa area geografica. Cosa molto interessante è che, rispetto ad altre applicazioni simili che sfruttano gli opendata senza aggiungere nulla, noi permetteremo di crearne di nuovi usando un prototipo di rilevatore di qualità dell’aria che sarà sviluppato dai ragazzi di Frankenstein Garage. Il mio apporto in questo progetto è stato, finalmente, squisitamente tecnico. Mi sono divertito usando Mongo, Silex, Twig, Process e Buzz per importare, elaborare ed erogare gli opendata necessari alle varie visualizzazioni.

Durante questi mesi di trambusto per le conferenze ed i vari progetti più o meno personali non ho però dimenticato il mio piccolo mondo, dove tra un corso, un progetto e l’altro per clienti esterni (tenete d’occhio CasaNoi) ho affiancato Francesco per la gestione di OltreTata, iniziandomi ad occupare della parte più business del progetto, ed aiutato la nascita di DraftQ di cui ho già scritto. In questo caso il mio supporto al codice è ahimè scarso, ma ormai ho capito che il mio andazzo lavorativo sarà sempre più rivolto alle scartoffie, vedere cose e fare gente.. lasciando il lavoro sporco a persone fidate tra cui l’immancabile Francesco ‘cphp’ e, in questo caso, la new entry Roberto).

Se siete nerd, scrivete pacchi di documentazione e vi interessano gli argomenti relativi al self publishing tecnico allora DraftQ è sicuramente qualcosa che farà per voi. Intanto aspettatevi una prima alfa intorno a giugno. Per prepararvi meglio magari iscrivetevi al workshop sul selfpublishing che il buon Mauro sta organizzando in quel di Marina Romea il 15 giugno (ho anche un codice sconto IDE01 da darvi :)).

Infine abbiamo iniziato, finalmente, a dare supporto alle startup che hanno bisogno di staff tecnico per produrre MVP con un piano d’azione rapido e ben preciso. Questa nuova business unit di ideato, se così vogliamo chiamarla, sarà gestita da Jacopo e ne parleremo più approfonditamente in altri luoghi…

* e vabbè lo sono.. la conferenza l’organizzo io…

Fortunatamente DreamHost permette di personalizzare la versione del PHP.ini che gira sul proprio account abilitando (o compilando) i moduli mancanti.

Ecco come ho fatto a risolvere i vari problemi che mi affliggevano.

PHAR

PHAR è già incluso nell’installazione CGI di PHP 5.3.x di DreamHost quindi tutto quello che c’è da fare è abilitarlo. Anzi… quasi tutto. Infatti, il modulo è in blacklist di Suhosin e pertanto bisognerà configurarne la whitelist per permetterne l’uso esplicito.

Nello specifico per abilitare il modulo, e configurare Suhosin, bisogna aprire il file (creandolo se non presente) /home/PROPRIO_USER/.php/5.3/phprc ed aggiungere le seguenti linee di codice.

[code]
extension=phar.so
detect_unicode = Off
phar.readonly = Off
phar.require_hash = Off
suhosin.executor.include.whitelist = phar
[/code]

riavviando PHP (o aspettando qualche minuto) avremo PHAR (e quindi Silex) perfettamente funzionanti.

Per riavviare PHP bisognerà eseguire killall php53.cgi

Mongo

L’installazione del driver mongodb risulta invece un pochino più complessa.

Ricordatevi che DreamHost permette di installare il driver Mongo ma non di far girare un’istanza del server sul vostro account pertanto dovrete crearvi un account su un servizio come MongoLab o MongoHQ.

Per installare il driver Mongo di PHP bisogna scaricarlo dal repository ufficiale su GitHub e successivamente compilarne i sorgenti e copiare il modulo preparato per il nostro ambiente in una directory da noi selezionata.

[code]
unzip mongodb-mongo-php-driver-archive.zip
cd mongodb-mongo-php-driver
phpize-5.3
./configure --with-php-config=/usr/local/php53/bin/php-config
make
cp modules/mongo.so /home/PROPRIO_USER/.php/5.3/
[/code]

A questo punto per abilitare il driver bisognerà, come in precedenza, modificare il file /home/PROPRIO_USER/.php/5.3/phprc indicando, in questo caso, il path completo dell’estensione compilata.

[code]
extension=/home/PROPRIO_USER/.php/5.3/mongo.so
[/code]

Attendete che l’interprete PHP faccia re-spawn e giocate con la vostra nuova applicazione :)

E’ quello di abbandonare il pc e dedicarsi a qualcosa di più concreto. Era da qualche anno che pensavo al “piano b” e finalmente se ne è mostrata l’occasione. Ecco a voi il mio agriturismo! Rallenterò con startup, web 2.0, agile e lean per dedicarmi all’orto ed al sano vivere.

Dopo un paio di mesi di trattativa oggi ho finalmente chiuso l’acquisto di uno stupendo agriturismo con tanto di laghetto e pesci sul retro. Si trova nelle colline tosco-romagnole e prevedo di aprire al pubblico prossimamente, magari per qualche mangiata con i vari pug/xpug/etc e per organizzare i corsi di ideato in un ambiente diverso dal solito.

Il nome? Pensavo a qualcosa come “La carpa d’oro“…

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.

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?

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

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!

Nel libro, piuttosto che affrontare tutta la teoria dietro ai database documentali, si spiegano, capitolo per capitolo, le funzionalità che questo database NoSQL mette a disposizione degli sviluppatori e come possano essere sfruttate in piccoli progetti.

Ogni capitolo infatti tratta uno specifico aspetto di MongoDB, tralasciando i primi due capitoli più introduttivi alle funzionalità di base del sistema viene spiegato come usare Mongo per gestire (trasparentemente) le sessioni di PHP, geolocalizzazione di dati, storage di file con GridFS ed i log/analitiche del proprio sito. Viene dato anche un po’ di spazio alle pratiche di Map/Reduce anche se avrei approfondito il capitolo con qualche esempio più complesso.

Il libro è scritto abbastanza bene, e stranamente, gli esempi di codice PHP sono ad oggetti e vengono illustrati alcuni dei pattern usati. Unico limite del libro è che non vengono descritte le funzionalità avanzate di Mongo come sharding, load balancing e replicazione, ma da una beginners guide non ci si poteva aspettare altro.

Insomma, un buon punto di inizio, ma non di arrivo, per chi si vuole avvicinare a MongoDB.

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).

Da li in avanti è stato un susseguirsi di discussioni sull’argomento in azienda su come interpretarlo al fine da ridurre gli sprechi e, contemporaneamente, non indurre una eccessiva complessità nei basecode che vengono gestiti.

La mia opinione è che, macroscopicamente, la riusabilità del codice, in un breve lasso di tempo (diciamo 1-2 anni), sia da incentivare.

Macroscopicamente significa però che vada incentivata per quella classe di strumenti che aiutano a scrivere codice (framework, CMF o set di librerie) facilitando, di conseguenza, la condivisione del knowhow e delle metodologie di lavoro all’interno del gruppo di lavoro. La scelta però di voler riutilizzare a tutti i costi un metodo, una classe, un particolare modello o un tool ben preciso è da sconsigliare perchè implica il voler forzare uno strumento a fare qualcosa per cui non è stato, inizialmente, concepito.

L’esempio più banale è quello di voler usare per ogni cliente un unico CMS (quindi uno strumento già specializzato in qualcosa). In questo caso il lavoro di personalizzazione di un modulo di pubblicazione di una pagina può risultare molto più costoso che limitarsi a fare uno scaffolding dei modelli da gestire che con semplici pagine hanno ben poco da spartire. Il codice riutilizzato forzatamente crea spreco e complessità invece che dare un vantaggio effettivo.

Quindi, penso che, il vero concetto che debba passare sia della riusabilità della conoscenza.

Così come i design pattern della GoF aiutano ad affrontare schematicamente problemi ben noti, allo stesso modo, acquisita una certa compentenza su una particolare classe di problemi è importante utilizzare quest’ultima per definire nuovi application pattern che possano essere utilizzati a loro volta per risolvere problemi attigui.

Un esperimento del genere fu fatto nel 2009 da Yahoo! che nel proprio Developer Network cercò di raccogliere pattern per il design di applicazioni utili alla definizione di funzionalità per rappresentare/definire concetti di reputazione, engagement o anche semplicemente paginazione dei dati (altro esempio molto interessante di archivio di design pattern è quello di Welie).

Il semplice design pattern però è troppo limitato per uno sviluppatore e dovrebbe racchiudere anche un po’ di informazioni utili all’implementazione di codice, una buona soluzione potrebbe quindi essere quella di sfruttare i pattern esistenti definendone però anche esempi di codice. Prendendo il design pattern dello “store locator” l’informazione essenziale per lo sviluppatore, più che la forma che il widget dovrà assumere, è sapere che le funzionalità di calcolo della vicinanza tra due punti sfruttano le librerie geospaziali presenti in molti database (MySQL, Postgres o MongoDB) o che l’intorno di un dato punto è calcolato usando funzioni trigonometriche. Con queste poche dritte (magari affiancate da link a risorse più esaustive o a codice pre-esistente fatto in casa) si riescono a ridurre ore di ricerce su internet e stress per esempi non utili o inapplicabili.

Definire un application pattern come quello per lo “store locator” comune a tutto il team di sviluppo, faciliterà l’identificazione del problema, della risoluzione e delle possibili implementazioni. Riducendo, non tanto il tempo di scrittura del codice, quanto quello di ricerca di una soluzione ottimale ed il numero di implementazioni radicalmente diverse.

Che ne dite?

Ogni volta rimango sbalordito di come, tralasciando l’esagerazione puramente da reality, queste persone vivano in letamai fatiscenti semplicemente accettando il fatto che “tanto è così e non ci possiamo fare nulla“.

Un giorno però un pensiero mi è balenato più o meno così nel cervello: “macchecaz saranno in 20 in quella casa, vuoi che uno di loro non possa prendere una pinza a pappagallo e chiudere il tubo che gli sta allagando la cantina da 2 anni…” tutto questo mentre osservavo le immagini di uno scantinato con 40cm d’acqua dove alcuni mobili navigavano allegramente.

Passato questo momento di stizza verso persone così pigre da rovinarsi la salute e farsi i debiti con la bolletta dell’acqua piuttosto che prendere la situazione di polso e reagire per tempo e così abituate ad una situazione tanto assurda da non farci neanche più caso, sono andato in bagno (ho fatto quel che c’era da fare) e guardando il rubinetto con appoggiato li vicino il nuovo filtro da cambiare (da circa 6 mesi) ho iniziato a prendermi a schiaffi da solo.

Se la pigrizia è un grande nemico, l’assuefazione alle situazioni che ne derivano lo è ancora di più.

Qualche tempo dopo una applicazione, la cui una suite contava oltre 1000 test, è schiattata miseramente durante una build in produzione di routine. Nulla di grave, abbiamo fatto un rollback e poi iniziato ad indagare. Non trovando nulla di errato nella suite di test, che per di più copriva gran parte del codice ed era scritta a regola d’arte in base alle procedure interne, abbiamo iniziato a far reverse engeneering del problema scoprendo che alcuni test, perfettamente leciti e sicuramente indispensabili, non prendevano in considerazione alcuni aggiornamenti marginali portati sulle macchine di staging e di produzione ma non su quella di continuous integration.

La routine portata troppo avanti nel tempo ci può fare perdere di vista alcune cose essenziali, come il fatto che nulla è veramente marginale.

Ultimamente discutendo con alcuni imprenditori d’oltralpe (e future speranze italiane) è emerso il discorso che i pagamenti delle fatture siano fatti in Italia sulla metodologia aBM e che siccome è la normale routine per le grosse aziende pagare con tale tempistiche è diventata abitudine, per le piccole aziende loro fornitrici, chiedere direttamente quel genere di pagamento lamentandosi, dopo, come sia tutto molto più difficile per chi vuole solo fare il proprio lavoro.

La morale è chiara.

Ho finalmente partecipato ad un vero evento (non tecnico) per il (e sul) web (che comunque aveva i suoi angoli patinati dove tutti erano cool e si facevano i complimenti l’uno con l’altro o dove ceo di grosse multinazionali banfano di avere il miglior prodotto sul mercato per sicurezza e velocità) dove l’interazione con (veri) imprenditori era (finalmente) alla portata di mano (e prometto che al prossimo giro userò molto meglio Presdo).

Niente standiste gnocche e seminude che recitavano a memoria depliant, ma gente vera e con una certa esperienza che ti ascoltava, diceva la sua e cercava (veramente) di comprendere il tuo punto di vista su come è complesso lavorare su un mercato dove i prezzi sono falsati al ribasso o dove il valore portato non è realmente percepito.

Ho parlato con imprenditori che non riuscivano a capire i miei problemi perchè vivono in un mondo dove un’azienda che risolve problemi tecnici è pagata per quel che vale, senza trattative da 1 ora per spuntare pochi euro, e dove se il pagamento è concordato a 30 giorni significa che entro (e non oltre) il trentesimo giorno incassi la fattura.

Startupper e Business Angels che sono rimasti affascinati dal modo di lavorare che abbiamo scelto e contemporaneamente mi hanno “sgridato” perchè sito e comunicazione della mia azienda sono solo in italiano (se la tua azienda parla solo italiano perchè sei venuto a LeWeb?).

Tornare a casa mi ha lasciato un po’ di amaro in bocca, ma niente autocommiserazione solo tanta voglia di fare nuovo e meglio e possibilmente fuori da questi confini ormai troppo stretti…

Mi sono fatto un’idea di com’è e di come vorrei che fosse, idea che per il momento non condividerò ma che cercherò di spiegare durante un talk all’AgileDay ed approfondire successivamente qui.

Prima di tale data mi piacerebbe però raccogliere qualche parere in più. Quindi vorrei sapere cos’è per voi un commerciale (dal generico a quello per una azienda che vive di web) e quale dovrebbe essere il suo tratto saliente (o quali dovrebbero essere se ne avesse più d’uno) e perché. Insomma per voi un buon commerciale dovrebbe avere compentenze tecniche? O essere un grande affabulatore? O limitarsi a vendere il più possibile?

Ciuaz

Dopo tante conferenze (molto) tecniche sono veramente curioso di vedere come, al di fuori dell’Italia, vengano affrontate tematiche (innovazione, imprenditoria, startup e ovviamente web) che da noi finiscono, immancabilmente, tradotte in ragazze svestite in stand ricchi di gadget.

A seguito della notizia ne è arrivata una, a mio parere, più triste: HP sta valutando di dismettere anche la linea di produzione PC.

Se su web si parla molto della scelta come necessaria a seguito del calo di vendite di PC (solo 1 miliardo di $ di marginaltà in più rispetto allo scorso anno) e dell’avvento dell’epoca post-PC. In realtà, a me pare che in ambito professionale il mercato desktop sia tutt’altro che in calo, semplicemente nel mondo home-appassionati si è affiancato un nuovo mercato. Quello della “mobilità” che ha rallentato il normale aggiornamento tecnologico del primo. Giustamente, per un’azienda come HP, la linea di produzione deve essere ammortizzabile e fruttuosa nella somma dei due mercati e da qui la possibile scelta di cederla (così come fece IBM con Lenovo) mantenendo quelle più produttive (non si è parlato infatti di cessioni dei reparti Server e Printing).

Quello che però non tutti hanno notato è che quello che vedremo (e stiamo già vedendo) è una convergenza dei device domestici (pc, cel, tablet, tv, console), dove punto cruciale è la condivisione di informazioni usando servizi cloud in primis, ma anche media server locali (iTunes?). Ed è per questo che tutti i big del settore stanno investendo su questi strumenti a modo loro.

Prendiamo ad esempio Microsoft. Dopo aver investito non pochi soldi nella messa online dei propri prodotti cloud, ha fatto si che i dispositivi mobile si integrassero con il vero prodotto di punta di Redmond: l’X-Box. Inoltre MS ha, finalmente, deciso di investire seriamente in tecnologie web prima testando sul campo ie9/10 per poi annunciare che Win8 supporterà nativamente js ed html5 per il rendering a video e che il futuro sistema operativo nascerà per supportare un ampia fascia di piattaforme. Vedremo quindi, magari per l’utenza domestica, sparire il PC sostitutito da una piattaforma di gaming più avanzata che virtualizzerà il futuro sistema desktop su un terminale dislocato in casa (dal tablet connesso wireless, allo specchio del bagno come in qualsiasi b-movie di fantascienza)?

Apple sta più o meno facendo lo stesso, con iCloud tutti i device in mano ad un utente condivideranno gli stessi dati e le stesse applicazioni. Probabilmente con le perdite di libertà a cui gli utenti Apple ormai non fanno più caso. Se mettiamo in gioco anche un media server (iTunes) sempre più presente e l’interesse, sempre più evidente, verso il gaming abbiamo trovato un pattern simile.

Google, gaming a parte, sta facendo gli stessi passi. Cercando però una via ancora più estrema spostando tutto sui propri servizi.

E’ probabilmente per questi motivi che HP preferisce (oggi) dedicarsi più sui servizi a corredo (ed eventualmente su hardware dedicato allo scopo). Però è anche vero che HP che si ritrova in casa con un sistema operativo che può virtualmente girare su ogni piattaforma (oggi è presente su cellulari, tablet, stampanti e netbook). Facilmente virtualizzabile e distribuibile e per di più basato su standard aperti e con costi di produzione software relativamente bassi. Avrà fatto bene a dismetterlo? Mhh… io non penso… [ma sono anche un Palm-fanboy...].

Resta il fatto che se un produttore di PC di qualità come HP svende il proprio brand ci si ritroverà, in ambito professionale, sempre di più senza scelta riguardo alla qualità (con scelte discutibili sulla grande distribuzione come Asus, Toshiba, Dell) o dell’apertura della piattaforma (Apple).

Brutti tempi quelli di transizione…

ciuaz

Una di queste è la contrattazione delle modalità di fornitura dei servizi con i clienti, attività che porta via, proporzionalmente alla grandezza del cliente, tempo e sanità mentale. Se volete sapere quanto manca ad un mio possibile ricovero, considerate che ultimamente le trattative (se così possono essere definite) sono portate avanti con multinazionali che cubano quanto piccoli stati e che prima di dare una qualsiasi risposta (tipo: “bella giornata, eh?“) passano le domande al vaglio di un pool di avvocati…

Ogni tanto, durante un colloquio o uno scambio di email abbastanza acceso, mi arrivano frasi e concetti, espressi quasi come se rappresentassero La Verità Assoluta, a cui ci si aspetta una accettazione passiva.

A seguire, per mio e vostro diletto, alcune delle chicche che reputo come rappresentanti di un modo di lavorare vecchio e sorpassato.

Se non è possibile farlo entro un mese, mettici qualche sviluppatore in più.

Non è possibile paragonare la produzione di software con gli standard dettati da un’economia basata sulla produzione di beni materiali. Quando si parla di produzione di beni immateriali si è nel mondo dei servizi, accettare questa piccola, sacrosanta, verità ed aprire un attimino gli occhi aiuta a comprendere l’insensatezza di una richiesta del genere. Il costo di produzione (e replicazione) di un bene immateriale (software) non è direttamente associabile al numero di persone che ci stanno lavorando. Così come la compentenza di queste persone non può essere sostituibile da un aumento di manodopera.

Se continuate ad applicare un modello Fordista è giusto che i vostri progetti falliscano e che falliscano dopo aver investito 10 volte il budget in consulenti extra.

Le tempistiche di pagamento fanno parte del tavolo di negoziazione e non sono legate alle percentuali di sconto

Questa frase mi fa capire tendenzialmente due cose:

1. non avete capito cosa significa garantire una tempistica di pagamento a lungo termine.
2. agite con malafede nei nostri riguardi.

Nel primo caso considerate che se vi allungo i tempi di pagamento, significa che ho una esposizione finanziaria per pagare i miei dipendenti ed eventuali fornitori. Quindi sto tendenzialmente riducendo il mio profitto, ergo vi sto facendo, indirettamente, uno sconto.

Inoltre se consideraste la cosa da un lato squisitamente bancario con il mio “prestito”, vi permetto di far fruttare ulteriormente i vostri soldi (se re-investiti bene). Perchè quindi dovrei garantirvi anche uno sconto?

Nel secondo caso c’è poco da dire, volete spostare il vostro rischio di impresa su di me. Inaccettabile. Se volete pagare tardi, dovete accettare il fatto che riceverete tardi.

Dal momento che non è il reparto XXX a gestire i pagamenti, deve essere rimossa la frase ‘in caso di ritardi nei pagamenti verrà immediatamente persa la scontistica acquisita’

Questo mi è capitato, fortunatamente, solo un paio di volte ed ho potuto farci poco. A mio parere però è come ammettere che “siccome l’azienda è incapace a gestire i propri flussi interni, il costo di questa incapacità te lo devi accollare tu”.

Sarebbe interessante ribaltare il punto di vista: la prossima volta che il mio “reparto pulizie” mi lascerà i PC staccati mi riterrò autorizzato a rilasciare il prodotto con una settimana di ritardo.

La mia tabella interna dei costi fatta sulle aziende di consulenza e aggiornata al ribasso mi dice che costate troppo. Fateci un ulteriore sconto.

In questi casi quello che mi passa per la testa è: “è ovvio che costiamo tanto, la tua tabella l’hai fatta vessando aziende il cui unico scopo è piazzarti in casa gente raccolta per strada e venduta come sviluppatori senior.”

Purtroppo, vuoi per eccessi di cortesia o per non dover passare agli insulti, constato tranquillamente che: “si, costiamo un po’ di più degli altri ma se non stai contattando gli altri ci sarà un motivo? E questo motivo porta valore aggiunto alla tua azienda? Perchè quindi non dovresti pagare questo valore?”.

Se il progetto non dovesse andare a buon fine ci teniamo autorizzati a non pagare.

L’ho visto 3-4 volte, soprattutto in startup portate avanti da imprenditori, normalmente analfabeti informatici, che grazie a qualche giochetto finanziario non proprio pulito si sono ritrovati liquidità da investire e con “tanta voglia di fare”. Progetti che partono con queste premesse non sono mai stati minimamente considerati, cosa interessante è che se chiedo però i dividenti nel caso il progetto vada a gonfie vele vengo guardato come se avessi chiesto la luna…. mah…

E voi? Avete qualche altra perla da condividere?

Questo avviene perchè il primo, non potendo comunicare al secondo la modifica di una pagina (ad esempio dovuta ad un commento), riceve dal sistema di caching sempre e solo lo stesso contenuto. Dopo un paio d’ore di studio delle API dello Zend Server e delle action di WordPress è emerso un simpatico snipplet che permette di usare direttamente il CMS in situazioni di grosso carico di lavoro senza doversi appoggiare a plugin di caching (come ad esempio il pur sempre ottimo W3 Total Cache) e lasciando quindi l’installazione di WordPress la più pulita possibile.

Qui di seguito il proof-of-concept (funzionante) del codice in questione.

[code]
add_action('comment_post', 'clear_zend_cache');
function clear_zend_cache($comment_id, $comment_status)
{
//if the comment is approved clear the cache
if ($comment_status == 1)
{
$comment = get_comment($comment_id);

// use the Zend Server Page Cache API
if (function_exists('page_cache_remove_cached_contents'))
{
page_cache_remove_cached_contents(get_permalink($comment.post_id));
}
}
}
[/code]

Il seguente snipplet va copiato nel file functions.php del proprio tema e si occupa di cancellare la cache di una pagina quando un utente lascia un commento.

Come si può ben vedere lo script in questione è limitato ai commenti, ma si potrebbe estenderne il funzionamento anche alle action relative alle modifiche di un post da backend o addirittura utilizzare il Data Cache system per estendere, più o meno come fa W3 Total Cache, il sistema di caching standard di WordPress relativo ai risultati delle query.

Happy hacking :)

ciuaz

Il piano d’azione dell’evento è semplice, riunirsi, studiare insieme come fare una lobby, applicarne le regolette. Magari sensibilizzando il pubblico grazie ad una nazionale di calcio.

Una cosa però non mi è chiara.

Se i web designer hanno il grave compito di decidere le sorti del web italiano, allora tutte le figure professionali su cui queste persone dovrebbero basare il proprio lavoro (analisti, esperti di ux, architetti dell’informazione, etc), da cui il lavoro deve poi evolvere in qualcosa di concreto (copy, frontend developers, sistemisti, server side developers, etc) e con cui devono colloquiare (project managers, account, etc) che ci stanno a fare?

Vi prego. Smettiamola di considerare la categoria alla quale apparteniamo come indispensabile ed iniziamo a capire che per fare prodotti di qualità bisogna avere un team multidisciplinare formato da professionisti.

Piuttosto che un evento di sensibilizzazione del mercato, fate un evento serio in cui parlate di come migliorarVI. Discutendo magari delle nuove tecniche e tecnologie che potete usare nel lavoro di tutti i giorni, di come integrarvi in un flusso di lavoro di un team o anche semplicemente facendo una analisi (anche retrospettiva) di come e perchè è evoluto il web-design all’estero e perchè qui da noi i veri web designer si contano sulle dita di una mano.

Non capisco perchè in Italia tutte le altre comunità di professionisti hanno eventi del genere, e voi NO.

Ecco… magari durante la tavola rotonda, prendete spunto dal FOWD ed organizzatevi un evento come si deve…

ciuaz