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

Un miglioramento necessario, negli anime a combattere il nemico più forte (la cosiddetta sindrome da DragonBall), ad affrontare i nuovi ostacoli che ci si pongono davanti con rinnovato vigore, non solo fisico ma soprattutto, psicologico.

Alcune pratiche di Extreme Programming riprendono questi concetti stravolgendoli, rimasticandoli e facendoli propri, ed ecco quindi che possiamo affermare che:

• i Kata, o meglio i Code Kata, sono espressione di miglioramento attraverso il perfezionamento di quello che si conosce,
• il Kaizen è la pratica di continuo accrescimento attraverso nuova conoscenza e riduzione degli sprechi
• ed infine il Bunkai è lo strumento di comprensione del problema suddividendolo ed affrontandolo in ogni suo più piccolo aspetto (= TDD?).

L’esperienza del Code Kata su Javascript di Gabriele, durante il JavascriptCamp, ha fatto rinascere in me la voglia di combattere il cattivo più grosso. Ma non da solo, bensì insieme ad un piccolo Dojo di Geek, in quella che potrebbe essere una nuova forma di BarCamp più vicina al mio desiderio di accrescimento.

Ho deciso quindi che i prossimi BarCamp Kaizen Dojo (letteramente “luogo del miglioramento“) che organizzerò (o a cui parteciperò), dovranno essere sullo stile del JavascriptCamp. Eventi con pochi iscritti, ma molto attivi e propositivi al miglioramento che offriranno sia presentazioni che Code Kata.

Cibo per la mente e palestra per il cervello.

ciuaz

Voglia di divertirmi e di non prendere troppo seriamente l’evento, i partecipanti e soprattutto me stesso.

ps nelle note del talk si può leggere il discorso che avevo preparato.

ciuaz

L’esercizio è abbastanza semplice e vi aiuterà a sbaragliare qualsiasi chitarrista estivo davanti ad un falò (ma non garantisco).

Prendete la vostra mano ed assegnate un numero da 0 a 4 alle dita partendo dal mignolo. Tale numero rappresenta la potenza del due che volete calcolare. Ad esempio il mignolo, al quale avete assegnato il valore 0, varrà 2^0 = 1.

Adesso chiudete la mano a pungo ed iniziate ad alzare un solo dito per volta, ecco quindi una serie di numeri facilmente calcolabili:

• 0 => pugno chiuso
• 1 => mignolo
• 2 => anulare
• 4 => medio
• 8 => indice
• 16 => pollice

Proviamo a creare ora qualche altro numero combinando le dita

• 3 => mignolo + anulare
• 7 => mignolo + anulare + medio
• 18 => pollice + anulare
• 22 => pollice + medio + anulare
• 31 => pollice + indice + medio + anulare + mignolo
• 33 => ? + mignolo

Come si può notare ogni volta che dobbiamo calcolare un numero dispari il mignolo sarà presente. Inoltre il numero raggiungibile da una singola mano è 31 (cioè 2^6 – 1).

Come calcolare il 33? Semplice aggiungendo un dito dall’altra mano che assumerà il valore di potenza 6 (e quindi di conseguenza 2^6 = 32).

Ed adesso tutti in spiaggia a mostrare le proprie doti matematiche!

ciuaz

Per installare il browser in questione basterà creare un file chiamato chromium.repo in /etc/yum.repos.d/ ed inserire al suo interno il seguente codice:

successivamente da shell eseguire:

yum install chromium

ed iniziare a godersi la navigazione.

Alternativamente potete scaricare i file RPM direttamente da http://spot.fedorapeople.org/chromium/.

Per ora Chromium è un po' più instabile che su Ubuntu, ma avere un browser che usa 100Mb invece dei soliti 600-700Mb (a parità di tab) non ha prezzo!

ciuaz

La cosa interessante è che la comunità di PHP non è rimasta con le mani in mano ed ha risposto, sul gruppo di discussione interno di Google, con una serie di smentite ed approfondimenti molto interessanti e sicuramente da leggere.

Tra le varie scuse annesse all'articolo una, a mio parere raccapricciante, alludeva al fatto che gli esempi erano stati scritti per vecchie versioni del linguaggio. La migliore risposta a tale affermazione è stata:

You talk about "older versions such as 4 and even 3".
Who is running versions of PHP that are that old on the open internet?
If you're running on PHP3 or PHP4 on a public-facing website, your
very first priority is to upgrade to PHP5 for security reasons, not to
optimize your pages.

Seguita dalla citazione di un post di Bergmann dove si fa vedere come, effettivamente, la migrazione da php 4 a php 5 abbia portato reali benefici a Flickr (e non parliamo del blog di tizio o caio). Infatti con la semplice migrazione dell'interprete, a parità di codice, l'utilizzo medio di CPU ha avuto un calo di circa il 50% (il grafico in alto).

Ad oggi l'articolo non è stato ancora corretto, il che mi farà leggere tutti gli articoli su code.google.com con un approcio un po' più critico...

ciuaz

Nulla è valsa la rimozione di gran parte delle applicazioni installate, le uniche rimaste sono google maps e gmail, e la disattivazione della sincronizzazione automatica (ora manuale) con il mio calendario tramite opensync.

Ho provato in questi giorni a rispolverare l'Xperia X1, ma purtroppo il sistema operativo non l'aiuta. Sto quindi valutando se passare al e71, già testato ed apprezzato, o cellulare con layout simile oppure se fare il salto di qualità prendere, tramite Tre, l'N97 che offre un display leggermente più grande, qualche chicca multimediale, ma ha una tastiera a scomparsa che, a vederla, non mi entusiasma particolarmente.

Altra scelta potrebbe essere un cellulare Android. Purtroppo però, le ultime generazioni di questo device, sono senza tastiera fisica, a mio parere un discreto handicap per chi come me scrive dei poemi per email.

Che fare quindi.. boh... altre idee o suggerimenti? (e no, l'Iphone non lo compro!)

ciuaz

Innanzitutto, TwitOrNot migra dalla versione 1.1 alla 1.2.x di symfony, nel suo piccolo implementa l'autenticazione oAuth di Twitter non salvando in locale le password ma gestendo tutto tramite le API di quest'ultimo. Altra miglioria è stata la sostituzione, indolore visto l'esiguo numero di tabelle, di Propel con Doctrine, usando per quest'ultimo gli script di migrazione per gestire future implementazioni.

La cosa su cui però mi sono divertito di più è stata l'ottimizzazione dell'applicazione per l'utilizzo su un hosting come DreamHost utilizzando ySlow come calibro del mio lavoro.

Utilizzando lo script di analisi di Yahoo!, l'applicazione, nuda e cruda, presentava un bel D (a volte E) come risultato. Successivamente portato, tramite tweak del file di default .htaccess di symfony ad un onestissimo B (a volte C).

Vediamo in dettaglio i passaggi fatti.

Settiamo come prima cosa nel file settings.yml della nostra applicazione il parametro etags a true proseguiamo l'opera di ottimizzazione modificando il file .htaccess presente nella directory web della nostra applicazione symfony così come segue.

Fortunatamente DreamHost mette a nostra disposizione i moduli mod_expires, mod_headers e mod_deflate per Apache già abilitati, altrimenti se state usando un vostro server darò per scontato che siano stati abilitati. Inoltre DreamHost utilizza FastCGI, purtroppo però con APC disabilitato (anche se è possibile, con qualche trick, abilitarlo).

Vediamo punto per punto quello che è stato fatto.

Innanzitutto, dopo aver controllato che il modulo mod_expires sia stato attivato, disabilito la generazione degli ETAG di Apache in modo da forzare il browser a credere agli header che saranno passati dal server senza controllare nella sua cache. Altra conseguenza del disabilitare gli ETAG è che, se la nostra applicazione prevede l'accesso a molti file contemporaneamente (non è il caso di TwitOrNot) viene ridotto il carico di lavoro di I/O in quanto non vengono controllate, ad ogni richiesta, le informazioni sulle risorse richieste.

Ecco quindi che inviamo gli header modificati in modo che il browser sappia cosa, e come, mettere in cache. E' molto importante fare un attento tuning degli expire header da configurare. Infatti se è abbastanza sensato far si che la favicon sia salvata in cache per lunghi periodi di tempo ( ExpiresByType image/x-icon "access plus 90 day" ) lo è un pò di meno per i file html che potrebbero essere modificati anche più volte al giorno. Nel caso specifico di TwitOrNot ho preferito configurare l'expire ad 1 giorno, ma avrei potuto benissimo abbassare la soglia a qualche ora, così come avrei potuto alzare la soglia di javascript e css a valori più alti.

Sconsiglio di usare Modified come metodo di default di expire, in quanto se non modificate le immagini per lunghi periodi di tempo i browser cercheranno di riscaricarle ogni volta.

Dopo aver modificato gli header e gli expire, in modo da ottimizzare la cache del browser, è tempo di concentrarsi sulla riduzione della banda utilizzata. Per farlo ho usato mod_deflate, ottima alternativa al vecchio mod_gzip e (cosa importante) supportato pienamente anche su sistemi non LAMP. La configurazione proposta per il metodo è abbastanza banale, forzo che tutti i file di testo serviti dal server siano compressi. Se pensate che da 140kb di prototype (puro) si può passare a meno di 30k la soluzione è più che soddisfacente.

Usare mod_deflate è sicuramente un'ottima soluzione se la vostra applicazione offre delle API JSON, o genera un gran numero di pagine HTML di cui volete ridurre il bandwidth footprint. Se però avete solo qualche file javascript potreste limitarvi al solo YUI compressor per ridurre voi stessi le dimensioni degli stessi, piuttosto che andare ad incidere sulla CPU della vostra macchina.

Un altro trucchetto, da usare con symfony, consiste nell'inserire all'interno di una action particolarmente pesante, e che non deve essere aggiornata troppo di frequente il seguente comando:

questo forzerà all'interno dell'output di symfony l'inserimento di un header con valore Last-Modified uguale al $timestamp dichiarato. Se ad esempio la vostra action invoca un oggetto che ha l'attributo automagico updated_at, potreste usare quest'ultimo come valore del timestamp da applicare all'header.

Come ultimi approfondimenti, lato symfony, vi suggerisco di leggere il capitolo 18 della guida definitiva a symfony ed a dare un occhio alla documentazione di memcached (a cui, forse, dedicherò un post in futuro).

ciuaz

ciuaz

Ebbene si, dopo l'esperienza CampCAMP non potevo non replicare con il tormentone del barcamp parallelo. Nasce quindi il BARbar, bar camp il che fregia il motto "nessuno spettatore, tutti ubriachi!".

L'evento si terrà durante il RomagnaCamp '09 subito prima e dopo i talk di quest'ultimo, e continuerà nelle, speriamo calde, nottate romagnole.

Ovviamente ci stiamo già adoperando per far partire partnership con le forze dell'ordine locali... per indicare i BARbarisisti più attivi... altro che "niente sponsor"! ;)

ciuaz

Dopo aver partecipato al WorkingCapital a Catania ed al BetterSoftware a Firenze, domani andrò al phpDay per un weekend dedicato a PHP (ps un grazie di cuore ai 150 iscritti!).

Poi, la prossima settimana dopo un paio di giorni di riposo (lunedì e martedì), partirò per Milano per partecipare experienceCamp e WordCamp infine domenica aereo diretto per la phpConference a Berlino.

Meno male che, appena tornato da Berlino, prenderò l'aereo e tornerò 3 giorni in sicilia per rilassarmi...

ci si vede su Flickr e Twitter.

ciuaz

La scusa del barcamp era quella di portare alla luce alcuni progetti, più o meno innovativi, e di discuterne con i rappresentanti di Telecom che avrebbero dovuto presidiare le due aulee dove si svolgevano gli interventi. Peccato che questi ultimi, forse scoraggiati dall'eccessivo entusiasmo del pubblico, non abbiano partecipato attivamente al barcamp, ma si siano limitati a rilasciare interviste in giardino, lasciando alcuni relatori delusi di questa indifferenza per il loro lavoro.

Resta da dire che alcuni interventi sono stati molto interessanti, tant'è che seguendoli non ho sofferto particolarmente la mancanza del wifi, ed è un piacere vedere come la Sicilia sia attiva nello sviluppo di progetti innovativi.

Nel seguito le slide del mio intervento.

Per maggiori informazioni fate un giro sul sito dell'UAAR

ciuaz