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.

Si definisce Stage Driven Development, o SDD, quel processo di sviluppo, tipicamente estivo e delle PMI italiane, che usa stagisti, normalmente senza competenze ed esperienze sul campo, per creare software business critical che poi dovrà essere rifattorizzato, o nel peggiore dei casi riscritto sottocosto, «che abbiamo già investito ed il budget è poco», da fornitori terzi.

Giusto per riagganciarmi a quanto detto da Luca sull'argomento stage.

ciuaz

ciuaz

Ebbene si, manca solo un mese al prossimo phpDay!

Anche quest'anno il lavoro fatto è stato veramente tanto, soprattuto per avere una scaletta così ricca di relatori provenienti dall'estero (senza togliere nulla a quelli italiani). La scelta di svolgere il tutto a Corropoli, anche se un po' criticata per la relativa scomodità, ci ha dato la possibilità di concentrare gran parte del budget sui relatori riuscendo a portare a casa un gran bel numero di "vecchi lupi di mare" delle convention internazionali ma poco conosciuti da noi.

E proprio per questo ho deciso che, per la prima volta, cercherò di tenere un talk in inglese [così se devo essere sputtanato preferisco che venga fatto direttamente su scala globale ;)]. Pensate che per prepararmi psicologicamente è già un annetto abbondante che preparo tutte le slide dei miei speech in inglese, ma ancora non avevo avuto il coraggio di fare il grande passo di presentarli nella stessa lingua. Speriamo bene... e se avete qualche suggerimento sulla migliore traduzione per "qualità, cortesia ed ampio parcheggio" in modo che ne sia comprensibile il senso anche a chi non conosce Aiazzone siete i benvenuti!

A già... Vi siete iscritti?

PS
Come ogni anno l'appello di spargere la notizia dell'esistenza del phpDay a tutti i vostri conoscenti informatici, datori di lavoro, imprenditori ed appassionati è sempre valida! Parlatene ovunque e con chiunque! Mi raccomando!

Fortunatamente questa azienda la ho.

La cosa che mi rende contento dell'ITDevCon, è che parteciperò ad un evento su quello che è l'evoluzione di uno dei linguaggi che più mi ha divertito ai tempi delle medie, il Turbo Pascal e che tuttora si porta dietro qualche strascico come il tema per Zend Studio con sfondo blu... :)

Al ritorno dall'ITDevCon farò un salto in quel di Karlsruhe per partecipare all'edizione invernale della phpConference 2009, uno dei più importanti eventi europei per PHP che ogni anno vede le migliori teste del globo a cercare (riuscendoci) di farmi ubriacare parlare di tutto ciò che gravita intorno al mondo dello sviluppo su web ai massimi livelli.

Infine a Bologna, si terrà il 20 novembre, la nuova edizione dell'AgileDay, che quest'anno mi vedrà nei panni di relatore durante un breve talk intitolato Agile === Dinamico . Onestamente partecipare a questa conferenza attivamente, e non come spettatore, mi spaventa un po' ma cercherò, nel mio (ph)piccolo di svecchiare qualche preconcetto sull'agile e sui linguaggi interpretati ;).

Che dire.. ci vediamo in giro! :)

Ideato presenta il primo coding dojo su HTML5, durante l'evento verrà presentato il linguaggio ed realizzato un kata sui web workers di javascript risolveremo il secondo problema del progetto Eulero.

La giornata inizierà alle 14.30 con 4-5 mini interventi su HTML 5 proposti dai partecipanti per poi proseguire con il kata sull'esercizio tratto dal progetto Eulero, consiglio a tutti di provare a risolverlo con javascript o altro linguaggio per poi poterlo ri-affrontare usando i workers.

L'evento è aperto al pubblico ma a numero chiuso, sono gradite birre e cibarie da condividere con gli altri partecipanti.

Per prepararvi all'evento vi consigliamo la lettura di Dive into HTML 5!

Devo dire che sono particolarmente fiero del lavoro fatto perchè, premi a parte, è stato il mio primo vero libro tecnico scritto. Una specie di sogno nel cassetto che avevo da un po' di tempo.

Il libro è una guida che punto per punto spiega come installare, configurare e creare un sito usando gli strumenti di base messi a disposizione dal CMF e con un minimo di personalizzazione. Niente di fantascientifico, ma molto pragmatico per chi vuole, da subito, avere un prodotto utilizzabile.

Nello specifico si parla di:

* Install and configure an eZ Publish CMS
* Manage content classes and create a content structure for your site
* Leverage the extensibility of the eZ Publish CMS to create extensions thereby making projects reusable and portable
* Handle a powerful subscription system that allows your users to subscribe to site updates
* Learn the basics eZ Publish's templating system and the design override feature
* Make use of the Online Editor to edit objects through an easy-to-use interface
* Manage the templates and styles in your system through web-based management
* Customize custom class views through the override system and the template engine
* Tweak your server to bring out the full power of the CMS
* Use the powerful RSS module that allows you to create RSS feeds from any part of your content tree
* Optimize the performance with APC and cache optimizer

Se lavorate con eZ Publish e volete una copia del libro per recensirlo sul vostro blog, sito o portale fatemi un fischio, sarò più che contento di passare il vostro contatto alla Packt.

ciuaz