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.

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.

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.

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.

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

Ovvero, come evitare di svenarsi con anni di psicanalisi uccidendo tutti quelli che ti passano per la mente. Letteralmente.

ciuaz

Per comodità ho creato una piccola bookmarklet che invoca il servizio e genera automaticamente l'immagine.

Per usarla, copiate questo codice all'interno di un bookmark:

o, più semplicemente, trascinate questa QR Code Bookmarklet sulla vostra barra degli indirizzi.

ciuaz

C'è chi lo fa perchè vuole evitare di dare lavoro ad aziende che fanno lavoro in nero, e fin qua sono in totale accordo, c'è chi lo fa per prassi (e non ricorda quando ha iniziato) e c'è chi lo fa per avere controllo su chi farà materialmente il lavoro (ma la mia interpretazione, plausibile, è di poter poi contestare il lavoro attaccandosi a qualche cavillo per ridurre la spesa finale).

Resta il fatto che il termine più (ab)usato è "per la trasparenza dei fornitori". Ecco, anche a me piace la trasparenza, pertanto ai prossimi clienti che vorranno fatto un lavoro, ma chiederanno scartoffie su scartoffie, potrei iniziare a chiedere in contropartita la Visura Camerale, lo Stato Patrimoniale e lo stato dei ritardi dei pagamenti verso i fornitori.

Vuoi mai che tutta questa chiarezza non snellisca le pratiche per iniziare a fare il vero lavoro?

ciuaz

Io pensavo ad uno fatto più o meno così: "Questo blog è frutto dell'ingegno e della fantasia del suo autore, ogni riferimento a fatti realmente accaduti e/o a persone e marchi realmente esistenti è da ritenersi puramente casuale. Ritenete tutto il testo scritto automaticamente smentito."

dite che può andare bene?

Quality assurance, or QA for short, refers to a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met.

fonte wikipedia

Sarà che sono sempre stato abbastanza sensibile all'argomento (vedi anche il mio ultimo talk al phpDay 2010) e che ho sempre pensato al mio lavoro su criteri molto simili a quelle citati nel craftsmanship manifesto, ma ultimamente (diciamo nell'ultimo anno) mi pare che sempre più persone (e personaggi) che vivono nell'enorme calderone del mondo agile/xp/dialetti-vari parlino di QA.

Il problema è che, imho, ognuno riporta la QA al proprio mondo dimenticandosi di tutte le altre sfaccettature e che spesso QA nel mondo agile venga intesa in termini di code coverage.

Più volte ho parlato con sviluppatori estremi che affermano che se un software ha code coverage superiore a X% allora la QA è un processo inutile. Come fanno notare però gli UX-ari un software può anche funzionare egregiamente ma se l'output restituisce testo rosa su sfondo rosso, o l'interfaccia sia usabile girando il monitor di 62°, si può dire di qualità? Non penso.

Parallelamente chi si occupa di UX si aspetta test funzionali e/o di accettazione (ed aspetta a lungo, perchè non li vuole scrivere) sul prodotto finito fatti più o meno automagicamente (dai poveri sviluppatori già oberati da altri compiti?). Magari facendo svolgere gli stessi test anche ad un team di persone prese dalla strada, che però non si accorgeranno mai se il computo delle tasse è stato fatto bene o meno (a meno che non siano commercialisti, ma anche in questo caso la % di incertezza è alta).

Non dimentichiamoci dei copywriter, che vorranno fare un controllo maniacale dei testi, delle label e della maggior parte delle forme di comunicazione verbali del sito, togliendo la qualità ai webdesigner, e dei sistemisti che vorranno che il server sia conforme alle specifiche dettate e che il software non usi più risorse del dovuto, alla peggio impediamo agli utenti di accedere... Infine non parliamo di chi fa SEO che ha un concetto di qualità (del codice) divergente dal resto del mondo.

Pertanto la QA è appunto una valutazione dei vari aspetti di un progetto e significa che è un processo MULTIDISCIPLINARE, COSTOSO, (spesso) WATERFALL e per alcuni aspetti difficilmente AUTOMATIZZABILE. E soprattutto è un processo di MEDIAZIONE che necessita di un know-how sufficiente ad anticipare i problemi. E solo ad anticiparli in quanto risolverli è compito degli sviluppatori.

Bisogna ricordare che la Quality Assurance, attività da svolgere durante lo sviluppo per ridurre il rischio di difetti, non è il Quality Control, attività focalizzate a validare il (codice) prodotto subito prima del rilascio, e che oggi molte aziende confondono i due processi. Denny Stevens spiega molto bene cosa significa in un suo articolo intitolato "we are doing QA all wrong".

Pertanto mettetevi l'animo in pace, se dovete (e vi assicuro che dovete) fare QA armatevi di pazienza e fatela, possibilmente con il cliente ed un team ad essa dedicata, su tutte le sfaccettature del progetto e durante tutto il processo di lavoro.

Non c'è nessuna scorciatoia, esistono solo limiti dati dal budget e dalla capacità di lavorare bene (ed in questo caso appoggio in pieno tdd, hudson, selenium, fitness e tutto il resto) per ridurre i possibili problemi.

Le scarpe, che premetto non sono da trekking ma per terreni urbani, sono state testate decisamente a fondo avendomi seguito nel viaggio di nozze in Giappone. Quello che seguirà sarà quindi una piccola recensione, nata da esperienza diretta, utile (spero) a tutti i futuri acquirenti di MBT.

Prima di lasciarvi alla recensione ricordo a tutti che: non sono uno scarparo ma un informatico, pertanto non aspettatevi termini tecnici su questo o quel pezzo della scarpa, non sono pagato da MBT per questa recensione né ho ricevuto da quest'ultima scarpe da provare. Se non vi piacciono i miei criteri di valutazione... cavoli vostri.

Km percorsi

Non ho scritto 100Km per dare solo un titolo altisonante, ma perché, nei 21 giorni di escursioni ho calcolato una media di circa 5-6 Km al giorno di passeggiate. Non dimentichiamo inoltre che le scarpe erano già state usate per il mese precedente e che quindi la soglia dei 100Km è stata abbondantemente superata. I terreni percorsi sono stati per lo più urbani, anche se mi è capitato in qualche occasione di camminare su strade sterrate o con ciottoli, inoltre le condizioni atmosferiche sono state tra le più disparate, da caldo afoso a pioggia torrenziale, mi è mancata solo una bella nevicata, e quindi l'esperienza di utilizzo posso dire che sia stata completa.

Grip

Proprio a fronte di questa esperienza sconsiglio a tutti di utilizzare le Tembea quando piove. Le suole delle scarpe, nonostante un minimo di scanalature, sono decisamente lisce e pericolose sul bagnato. Se state scendendo, o salendo dei gradini, con le suole bagnate dovrete fare non poca attenzione per non rischiare di rompervi l'osso del collo, cosa che potrebbe avverarsi anche su pavimenti di marmo (ie. stazione di Milano) o particolarmente lisci. Ovviamente un altro modello, magari con suole più elaborate, potrebbe ridurre (o eliminare) il problema, le Tembea però rimangono, a mio parere, troppo scivolose.

Qualità dei materiali

Altra cosa che mi ha infastidito, non poco, delle MBT è la qualità dei materiale. Il fatto che la punta delle scarpe (in Cuoio pieno fiore) si sia macchiata pressoché immediatamente e che la vulcanizzazione della stessa abbia iniziato a cedere nell'ultimo periodo di utilizzo mi lascia abbastanza perplesso, ma il fatto che alla prima pioggia la tinta rossa dell'imbottitura abbia perso colore, tingendomi piedi e calzetti non l'ho proprio digerito. Ho delle Nike da mercatino che resistono da anni senza problemi del genere e mi aspetto che un paio di scarpe da oltre 200 € non risentano minimamente di un po' d'acqua, e soprattutto che non perdano così tanto colore. Le scarpe si sono perciò sporcate sulla tomaia e sui lacci di tinta con un effetto "sangue" poco piacevole, ingrandite la foto per vedere voi stessi, e le relative istruzioni per la cura, seguite scrupolosamente fin dall'inizio, sono servite a ben poco. La qualità della pelle è comunque molto buona (è sempre rimasta molto morbida al tatto), e la soletta ortopedica e sempre rimasta al suo posto senza deformarsi (cosa che molte Nike Air tendono a fare) tenendo il piede nella "postura MBT".

La postura MBT

Chiudo quindi la recensione con la risposta alla domanda che tutti si fanno prima di comprare una MBT: Ma funzionano veramente?.
Devo direi che, per questo aspetto, sono molto contento. 100Km e passa e mai un dolore al ginocchio o alla schiena. MAI. Sono stato fermo in piedi per ore aspettando autobus, o in conferenze, mi sono arrampicato per un migliaio di gradini, o camminato per Km per trovare ristoranti di ramen che ci soddisfacessero e non ho MAI avuto un singolo doloretto al ginocchio. Sicuramente il prossimo paio di scarpe sarà di nuovo un paio di MBT, questa volta però eviterò i modelli bianchi, con interno colorato e con suola eccessivamente liscia...

ciuaz

Grazie a tutti i partecipanti!

Un grazie di cuore agli amici e ai parenti (e perchè no, anche agli imbucati) per aver reso un giorno speciale ancora più speciale. Un grazie ai nostri genitori, a quelli che hanno ballato ed a quelli che sono fuggiti dalla sala, che ci hanno sostenuto in tutto dalla preparazione delle bomboniere fino agli addobbi degli autobus per il parentame.

Grazie a chi si è macinato km e km in auto con figli appena sfornati, o comunque al primo viaggio impegnativo, e grazie ai suddetti figli per la pazienza dimostrata rimanendo buoni e sorridenti durante tutta la serata.

Grazie ai testimoni, ed all'orrido segreto ahi-noi svelato.. A chi si è fatto viaggi in solitaria in notturna e a chi ha fatto un tour de force in moto. Grazie a chi ha avuto il coraggio di buttare la sposa in piscina completamente vestita, e grazie a chi ha avuto il coraggio di buttarsi in piscina per controllare che la sposa non annegasse. E grazie a chi ha organizzato gli scherzi e giochi decisamente nerd e coinvolgenti!

E grazie alla 500 che nonostante tutto ci ha portani sani e salvi da Jesi all'agriturismo.

Ci sentiremo al rientro dal viaggio di nozze in Giappone, intanto godetevi le foto su flickr!

Dare una stima dei costi per il refactoring di un progetto, senza prima averlo analizzato sarebbe come cercare di curare una malattia senza investire tempo e denaro in analisi mediche.

Sempre più spesso in Ideato ci arrivano richieste per riprogettare, rifattorizzare ed ottimizzare software già in produzione. Ovviamente chi chiede informazioni sui costi si ferma ad un misero «ma quanto mi costa?» senza però ascoltare le due/tre cose che sappiamo sull'argomento (mica ci abbiamo scritto un libro sul refactoring per hobby, no?).

Uno degli ultimi casi che mi è capitato riguarda la riprogettazione (a tutti i livelli, dall'UX alla sistemistica) di un portale da fare in partnership con altre aziende con cui stiamo lavorando già da tempo. Solo la fase di preventivazione di massima è costata a tutti parecchio tempo perchè, come al solito, non c'erano idee chiare da parte del cliente che è stato accompagnato mano nella mano in tutta l'attività.

Il quale, però, è ovviamente caduto dal pero vedendo che nel preventivo di analisi mancava la stima dei costi per il refactoring.

Ecco quindi spiegata la metafora che introduce questo post.