che cos’è la continuous integration ?

martin fowler nel suo articolo spiega:

continuous integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

da queste poche righe si apre la finestra verso un mondo: fowler non parla di strumenti o tecnologie, bensì di pratica.

il problema dell’integrazione non è banale: quando due o più sviluppatori lavorano contemporaneamente sullo stesso progetto non è raro che, al momento di mettere tutto insieme, si presentino problemi come conflitti o incompatibilità. troppo spesso si assiste allo scenario in cui la data di consegna al cliente è vicina  ed il software è più o meno pronto: << manca solo l’integrazione finale e gli ultimi fix >>, si direbbe, così facendo però solitamente ci si imbuca in un tunnel dentro il quale difficilmente si farà un bel viaggio, ma soprattutto sarà impossibile conoscerne a priori la lunghezza.

i bug e gli imprevisti sono per definizione non stimabili, né in numero né in complessità di risoluzione: come pretendere di stimare un tempo di integrazione, quando non si ha nemmeno una predizione a livello locale dei problemi emersi ? siamo finiti nel tunnel, nell’integration hell: la scadenza è sempre più vicina e non abbiamo idea di quando il software sarà correttamente funzionante. lo stress nel team aumenta con l’avvicinarsi della deadline, si rimane in ufficio fino a tardi e la stanchezza ed il malumore accumulati portano inevitabilmente all’introduzione di nuovi bug per risolvere quelli precedenti.

è proprio nel momento di mettere tutto insieme che la continuous integration interviene: l’integrazione del software non dovrebbe avvenire alla conclusione del processo di sviluppo, in cui tutti i problemi vengono identificati e risolti in una sola volta, ma dovrebbe essere parte di questo processo ed intervenire continuamente. la motivazione di ciò è semplice: rendere questo processo continuo limita il numero e la gravità degli errori rilevati, perché effettuare piccoli cambiamenti ed integrarli subito significa dover correggere al più bug recenti e non interi moduli dipendenti da anomalie introdotte molto tempo indietro e mai rilevate.

vediamo ora le pratiche fondamentali che ci permettono di fare continuous integration correttamente e come esse influenzeranno il nostro processo di sviluppo.

utilizzare un version control repository

l’utilizzo di un sistema di controllo di versione come subversion, git o CVS è il primo mattone con il quale costruire il nostro ambiente di continuous integration. tralasciando le differenze che i vari sistemi di controllo di versione hanno tra loro, è di fondamentale importanza avere un “repository” che permetta di gestire e monitorare i cambiamenti che avvengono sulla nostra code base. in questo modo si ha inoltre la possibilità di effettuare rollback dei cambiamenti: tramite strumenti di questo tipo infatti viene tenuta traccia della storia di ogni file.

nel repository deve essere presente tutto il necessario

non meno importante è l’avere tutto il nostro software, compresi framework, librerie e dipendenze esterne, all’interno del nostro repository: esso dovrà fungere da unica fonte del codice ed il nostro software dovrà essere in grado di funzionare solamente con quello che vi è contenuto, senza interventi esterni o aggiunte manuali.

eseguire una “commit” almeno una volta al giorno

come regola empirica, ci si impone di inviare il proprio lavoro al repository almeno una volta al giorno, anche se è vivamente consigliato puntare ad un numero di integrazioni maggiore. questo è necessario per rispettare il principio dei piccoli cambiamenti precedentemente introdotto. naturale conseguenza di ciò è la suddivisione del proprio lavoro in piccoli task atomici, che favorisce inoltre la scrittura di un codice più snello, pulito e mediamente privo di inutili complessità. in una sola parola, rispettare il KISS principle.

automatizzare le build

il processo di build non è solo la compilazione del codice (che non sempre avviene, come ad esempio nel linguaggio PHP) ma significa compiere un determinato numero di azioni che permettono al software di essere correttamente “costruito” e reso funzionante. rendere questo insieme di passi automatico attraverso un singolo script di building (come ant o phing) porta con sé vari vantaggi. primo: limita l’intervento umano e di conseguenza la probabilità di errori ed omissioni (lo sviluppatore lancia un singolo comando “build”). secondo, ma non meno importante: la riproducibilità ottenuta che permetterà a tutti gli sviluppatore di eseguire gli stessi passaggi in maniera identica (a meno di eventuali parametri di configurazione) mitigando la famosa, odiata frase “but it works on my machine”.

self testing build

non si fa continuous integration senza scrivere test automatici. tali test devono essere inoltre inglobati nei build script. a build completata lo sviluppatore conoscerà il risultato del proprio lavoro e solo tramite test automatici sarà in grado di averne confidenza sulla bontà. non è pensabile eseguire tali test manualmente perchè inevitabilmente qualcosa prima o poi verrà omesso, soprattutto nel modello di sviluppo che stiamo introducendo, in cui il software viene integrato (e quindi necessita di essere ritestato) ad ogni cambiamento.

è facile dire “il modulo b non necessita di essere testato perché ho modificato solo il modulo a” ma quante volte, nella realtà, sono emersi problemi derivanti da certe assunzioni? i test automatici sono la nostra rete di salvataggio e sono perfettamente riproducibili: ad ogni build ritesteranno tutte le funzionalità per cui sono stati scritti, più velocemente e più affidabilmente di qualsiasi sviluppatore o team, anche il più volenteroso, veloce e competente. nessuno riuscirà mai ad eseguire un gran numero di volte la stessa batteria di test senza ogni volta introdurre piccole differenze, soprattutto a fine giornata, quando la stanchezza si fa sentire. i build script, invece, non si stancano, usiamoli.

eseguire delle build private nelle workstation locali

ogni sviluppatore dovrà scaricare dal repository l’ultima versione del software che sta sviluppando. a questo punto lavorerà nella propria macchina locale, effettuando i cambiementi necessari per il proprio lavoro. una volta terminati dovrà effettuare la build del software sulla propria workstation ed osservarne i risultati. se tutto funziona correttamente, prima di inviare il proprio codice al repository, scaricherà da questo gli eventuali cambiamenti effettuati nel frattempo dagli altri sviluppatori e rilancerà di nuovo la build. se tutto va a buon fine, è stato fatto un primo passo verso l’integrazione: i propri cambiamenti sono stati integrati ed è possibile aggiornare la code-base eseguendo la “commit”.

non inviare codice difettoso al repository

in caso di fallimento dei test durante la build locale lo sviluppatore dovrà correggere i malfunzionamenti e rieseguire la build fino alla risoluzione dei problemi. non potrà, in nessun caso, inviare il proprio lavoro al repository se i test non certificano che esso è correttamente integrato.

in questo modo si minimizza la probabilità di avere software non funzionante nel repository: la copia “rotta” resterà confinata nella macchina dello sviluppatore che si occuperà di sistemarla.

eseguire una build di integrazione ad ogni cambiamento

ogni volta che il repository viene aggiornato con nuovi cambiamenti, il codice necessita di essere ritestato. successivamente alle build private, si eseguono quindi delle build di integrazione, che devono essere effettuate su di una macchina dedicata, che riproduca il più fedelmente possibile il vero ambiente di produzione. è importantissimo, inoltre, che questa ultima macchina sia priva di dipendenze e librerie spurie che non provengano direttamente dal repository: in questo modo ci si accerta che il lavoro dello sviluppatore sia ancora riproducibile e non dipenda da una sua particolare configurazione a livello locale.

l’integration build può essere manuale o effettuata automaticamente tramite un continuous integration server (come hudson o cruisecontrol). sebbene quest’ultimo componente non sia obbligatorio, è comunque raccomandato usarne uno: sarà lui per noi a rilevare i cambiamenti sul repository ed eseguire le build automaticamente, fornendo inoltre una comoda dashboard con report sui test, code coverage, strumenti di analisi aggiuntivi e documentazione auto-generata.

non scaricare codice difettoso dal repository, riparare immediatamente le build rotte

nella malaugurata ipotesi in cui la build di integrazione fallisca, nonostante siano state correttamente passate le build private, sorge il problema della “broken build”: è entrato un bug nel codice del repository e tutti coloro che andranno a scaricarlo otterrebbero del software non funzionante.  è compito dell’ultimo sviluppatore che ha eseguito la commit risolvere il problema, ma visto che questo malfunzionamento coinvolge tutto il team è meglio non scaricare affatto il codice difettoso: invece che perdere tempo nello sviluppo di eventuali workaround è preferibile aiutare gli altri a far tornare la build nello status di “green”.

build veloci e rapid feedback

è importante che il processo di build sia veloce e rapido: non è accettabile attendere più 10 minuti per il risultato dei nostri test (regola del “10 minute build”), altrimenti si perderà troppo tempo per via delle molteplici integrazioni o peggio ancora lo sviluppatore tenderà ad accumulare molto codice prima di lanciare i test. per evitare questo anti pattern è consigliabile quindi eseguire delle staged-build ossia lanciare le build private accompagnate solamente da test leggeri (unitari) e le build di integrazione divise in due: test unitari prima (per individuare subito problemi grossolani) per le build lanciate ad ogni commit e test più approfonditi (unitari e funzionali, analisi del codice, delle dipendenze, del code-style ecc) per build lanciate in un successivo momento, magari schedulate in notturna (nightly build) o in seguito al successo delle precedenti commit-build.

in questo modo si ottiene un feedback immediato che deve essere coadiuvato da meccanismi che lo rendano facilmente individuabile e  interpretabile: una lampada sempre verde che diventa rossa in caso di build rotta è uno degli esempi più tipici. è importante che il feedback sia incentrato sulle informazioni utili ed essenziali, tutto il superfluo tenderà a distrarre lo sviluppatore, che nella confusione rischia di ignorare messaggi importanti.

i pro ed i contro

il rispetto di una pratica richiede un iniziale costo dovuto dalla intrinseca curva di apprendimento che presenta. test automatici e buone pratiche di programmazione hanno un costo in termini di tempo, come pure l’acquisto e l’uso di macchine dedicate per simulare l’ambiente di produzione; tutto questo, nel brevissimo termine, potrebbe essere visto come un overhead. tali costi verranno però ampiamente ripagati durante il ciclo di sviluppo del nostro software. ne beneficerà la qualità del codice sviluppato: grazie al testing continuo infatti si ha sempre la certezza che niente è andato storto. ansia e stress caleranno: se tutto quel che viene scritto è sempre attestato come funzionante da opportuni test, automaticamente cala anche la paura di andare incontro a imprevisti ed inconvenienti. la comunicazione all’interno del team aumenterà: grazie al feedback rapido e condiviso, tutti sanno a che punto è lo sviluppo del software, quali sono i problemi emersi e le funzionalità ancora da implementare. anche il rapporto con il cliente trarrà dei benefici: la maggior tranquillità e sicurezza sul progetto verranno percepite come sintomo di puntualità e professionalità. ultima ma non  meno importante è infine la possibilità di poter effettuare continui rilasci di nuove versioni del nostro software: nel repository infatti è presente in ogni momento software perfettamente funzionante e quindi “deployable”.

questione di pratica

in questa introduzione abbiamo parlato di buone pratiche (tante) e citato alcuni strumenti (pochi) per mettere in piedi un ambiente di continuous integration. è infatti sulle pratiche di sviluppo il vero investimento che un team di lavoro dovrebbe sostenere, perchè dietro a tutte le tecnologie, anche le più valide e promettenti, ci sono sempre le persone. la continuous integration ne prende atto, facendosi carico di tutti quei compiti che rendono dura la vita dello sviluppatore, che potrà dedicarsi finalmente a compiti di più alto livello e alla vera business logic di progetto.

una miglior comunicazione tra stakeholders ed un ambiente mitigato da ansia e stress sono i primi ingredienti per vivere ogni progetto come una nuova sfida, vissuta con proattività e voglia di fare: non dimentichiamo mai che il software, benché eseguito da macchine, è sempre scritto da persone

per chi volesse approfondire consiglio la lettura dell’articolo originale dal sito di martin fowler ma soprattutto dell’ottimo libro “Continuous Integration: Improving Software Quality and Reducing Risk” (http://www.integratebutton.com/).

giorgio

in questo articolo andremo ad illustrare i passi necessari per la configurazione di tripwire, uno dei più diffusi host based IDS. disponibile sia in versione open source che in versione commerciale, è un software che una volta installato e configurato ci informerà di tutte le modifiche che avvengono nel file system, rispetto ad uno stato iniziale considerato “sicuro” che verrà salvato in un database.

su un sistema operativo come ubuntu, possiamo installare il software con un semplice apt-get install tripwire

al termine dell’installazione verrà avviata automaticamente la configurazione iniziale del programma, durante la quale ci verrà chiesto di inserire la “site key” e la “local key”, con cui tripwire provvederà a creare in /etc/tripwire i file di configurazione con le policy di default, in particolare i file tw.cfg e tw.pol. è consigliato rendere questi file leggibili solo dall’utente root con il comando chmod 0600 /etc/tripwire/tw.cfg /etc/tripwire/tw.pol

da notare che questi 2 file sono binari, creati partendo dai due file plain text twcfg.txt e twpol.txt, saranno quindi questi due file che dobbiamo modificare per apportare modifiche alla configurazione. per un primo utilizzo possiamo lasciare le versioni di default; consiglio solo, nel caso in cui si voglia che i report vengano inviati per email, di aggiungere al file twcfg.txt la riga

GLOBALEMAIL   = email@miodominio.it

una volta modificato il file twcfg.txt occorre ricreare il corrispettivo file binario, per farlo possiamo utilizzare il comando twadmin –create-cfgfile -S site.key /etc/tripwire/twcfg.txt

nel caso in cui venga invece modificato il file twpol.txt per ricreare il binario tw.pol dobbiamo utilizzare il comando twadmin –create-polfile -S site.key /etc/tripwire/twpol.txt

a questo punto, possiamo creare tramite il comando tripwire –init il database iniziale che tripwire utilizzerà per confrontare lo stato del sistema ad ogni check, il file verrà creato nella cartella /var/lib/tripwire/

ora non ci resta che testare il funzionamento di tripwire utilizzando il comando tripwire –check –email-report che ci invierà per email il report con tutti i file di sistema modificati, aggiunti o cancellati dalla creazione del database iniziale. il consiglio è naturalmente quello di inserire il comando in crontab per far generare automaticamente i report quando volete.

nel caso in cui si voglia modificare il file /etc/tripwire/twpol.txt, ecco un semplice esempio di regola che possiamo aggiungere:

(
rulename = “Sito web www.miosito.it”,
severity = N, (dove N è un numero compreso tra 0 e 100, più alto è il numero più alta è la ‘criticità’ di questa sezione)
emailto = webmaster@miosito.it
)
{
/var/www/www.miosito.it                  -> $(SEC_CRIT) ;
}

nel dettaglio, questa regola provvederà ad ogni check di inviare una mail a webmaster@miosito.it con tutti i file modificati di uno specifico sito.

un ultimo consiglio: vista la comprensibile sensibilità dei file di configurazione, è buona norma non tenere i file di configurazione plain text, ma di cancellarli ogni volta che si è conclusa la configurazione. per future modifiche possiamo sempre rigenerarli utilizzando i comandi:

twadmin –print-polfile
twadmin –print-cfgfile

daniele

non solo una questione di editor, o di sistemi integrati per lo sviluppo ma un discorso di piattaforma, di sistema operativo e di applicazioni. già nel titolo del post spicca una parola mac,  inutile discutere le scelte ma di certo va ancora di moda associare questo sistema operativo solo ai lavori di “grafica”… parola che oltretutto da sola significa tutto e niente.

in questo articolo vorrei spiegare come ho creato il mio ambiente di lavoro ideale su questa piattaforma utilizzandone le potenzialità che apprezzo senza rinunciare alla personalizzazione e senza compromessi rispetto alle esigenze dell’infrastruttura aziendale. da front-end web developer necessito innanzi tutto di una suite di lavoro dalle caratteristiche web-creative che sia potente, efficace e soprattutto compatibile col gli standard utilizzati dai grafici e creativi. inutile dire che tra le migliori troviamo la adobe con la sua creative suite web premium: massima compatibilità con la piattaforma mac e possibilità di operare con la totalità dei file che provengono dagli studi grafico-creativi.

ho poi bisogno di un editor, visto che nell’ultimo periodo abbiamo cambiato modalità di lavoro optando per un sistema con controllo della versione, la scelta è stata già scremata dalle applicazioni che non rispettano queste caratteristiche. inizialmente, reduce dalla vecchia modalità di lavoro, mi sarei accontentato di un editor e da un sistema di versioning separato. ho provato coda e taco come editor testando parallelamente subversion, version e syncro SVN per il controllo della versione. risultati abbastanza soddisfacenti ma il software sopra citato non è tutto freeware.

successivamente, in base anche alle esperienze dei colleghi, ho preferito un software unico più potente (anche se più pesante), in grado di elaborare tutti i formati, con un alto livello di personalizzazione (anche per la parte di colorazione del codice), con un alto livello di utenza (e quindi una community affidabile), con una estendibilità in grado di soddisfare ogni esigenza e freeware. la scelta si è spostata su eclipse, software disponibile sia per windows, per linux e per mac che tramite il plugin subversive installa anche il sistema per il controllo della versione.

ora manca solo un web server da installare sulla macchina per lavorare in locale che in base alle caratteristiche aziendali dovrà essere LAMP (linux, apache, mysql, php), mi sono subito orientato alla scelta verso l’ambiente MAMP molto “apple formed”, gratuito ed immediato tanto che è segnalato anche tra le migliori applicazioni per mac. MAMP ha una start-up page immediata che ingloba le preferenze scelte, link alla pagina info.php e link alla gestione dei database con il pannello di phpmysql e un widget appositamente creato per la dashboard di machintosh che permette di avviare e stoppare il server in qualsiasi momento in maniera molto rapida.

potremmo essere pronti per lavorare ma vorrei soffermarmi su un aspetto più tecnico e macchinoso. lavorare in locale esige la modifica del file di hosts. questa modifica da mac non è immediata. di seguito spiego minuziosamente i passaggi da fare in modo da permettere anche ai non tecnici di poterlo effettuare autonomamente.

il file di hosts, come su linux, si trova dentro la cartella /etc. per andarci dal nostro finder scegliere il menu “vai” quindi “vai alla cartella” e scrivere /etc ci si apre la finestra dove possiamo trovare il file hosts che se apriamo con un editor o con l’applicazione di default text edit ci mostra il contenuto del database di hosts della macchina. in teoria dovremmo aggiungere una riga inserendo la regola che fa rispondere al nostro indirizzo locale la cartella di lavoro ma il problema è che il nostro utente, seppur amministratore della macchina, non ha i privilegi per modificare questi settaggi sensibili.

occorre infatti diventare utente root del nostro mac. come fare? in questo post vengono spiegati molto bene i passaggi da fare anche nel più recente sistema operativo snow leopard che ha rivisto l’organizzazione di certi menu. seguita la procedura avremo abilitato l’utente root (associando ad esso una password) ed ora dobbiamo abilitarlo utilizzando la shell. nelle “applicazioni” c’è la carella “utility” quindi l’applicazione “terminale”. digitiamo la parola “su” (per diventare super utente, appunto root) e alla pressione di invio ci verrà chiesta la password (quella che abbiamo scelta quando abbiamo abilitato l’utente root). a questo punto ci verrà restituito il prompt da utente root per quella sessione di terminale. digitiamo il comando “vim/etc/hosts” (che equivale a dire modifico il file hosts sito dentro la cartella /etc) e alla pressione di invio ci verrà aperto dentro il terminale il file hosts. premere la lettera “I” per effettuare l’editing e una volta aggiunta la riga necessaria premere il tasto ESC seguito dai due punti. ora digitare “wq” (write and quit) per uscire dall’editing.

alessandro

photo credits: apple command

guest post di alfredo morresi – software engineer

pubblichiamo con piacere un articolo nato da una riflessione di alfredo che tratta di un argomento innovativo su cui ci stiamo confrontando in questo periodo.

sovrapporre uno o piu’ strati informativi alla realta’ davanti ai nostri occhi, mostrare dati provenienti dalla rete agganciati a cio’ che stiamo vedendo: a piu’ di 20 anni di distanza, la visione dei grandi autori del cyberpunk, come gibson in “luce virtuale”, incontra una tecnologia in grado di farla diventare concreta e alla portata di tutti. nascono cosi’ interessanti scenari di realta’ aumentata: un nuovo mondo da scoprire, sempre piu’ mobile, sempre piu’ con noi anche fuori da casa e dal lavoro.

i cyborg della serie terminator poteva vedere informazioni aggiuntive in sovraimpressione a quanto i loro occhi inquadravano: nome della persona, dati sui veicoli, strada da percorrere. seppur vecchio di 25 anni, questo e’ un primo esempio di cosa si puo’ fare con la realta’ aumentata. da una fiction holliwoodiana del 1984, passiamo ai giorni nostri, dove i telefonini piu’ avanzati hanno portato questa stessa possibilita’ alle masse. basta mettere a fuoco un monumento per conoscere il suo nome e una dettagliata descrizione, presa dalle pagine di wikipedia; trovarsi davanti ad un negozio ed accedere alle recensioni scritte dagli utenti, puntare una strada e sapere che, in fondo a destra, c’e’ una pizzeria, potendo anche navigare sul suo sito internet.

ma come’ possibile questa magia? parte del merito e’ dei device mobili di ultima generazione, che da telefonini si sono evoluti fino a diventati smartphone e, oltre ad offrirci un collegamento in mobilita’ alla rete internet, sono in grado di capire esattamente dove si trovano nello spazio. il gps fornisce le coordinate, gli accelerometri l’inclinazione, la bussola la direzione. combinando questi tre fattori, e’ possibile determinare quali oggetti, con una posizione nota, ricadono nel raggio visuale della fotocamera del device. proprio questo e’ il compito di programmi come layar, wikitude, theodolite ed altri, che rielaborano il flusso di immagini riprese e lo combinano con le informazioni georeferenziate presenti nei loro database: indicazioni stradali, monumenti, dati sugli esercizi commerciali, modelli tridimensionali.

eh si, perche’ da poco queste applicazioni sanno anche ricostruire complesse forme geometriche e collocarle davanti ai nostri occhi. e’ possibile cosi’ rivedere le torri gemelle puntando un iphone su groud zero, oppure scoprire, prima della sua costruzione, come sara’ il cantiere del nuovo market hall, a rotterdam : esplorarlo, girandoci attorno ed entrandoci dentro. ancora, scovare piccoli invizimals a passeggio per la casa e scatenare poi duelli tra di loro, vedere come sara’ l’aspetto di una costruzione lego mettendo la scatola davanti ad un apposito specchio. interessante anche il concept proposto da ikea, grazie al quale si stampa un apposito codice a barre bidimensionale di un prodotto preso dal loro catalogo, ad esempio un letto, si posiziona il foglio dove questo prodotto dovrebbe andare, si inquadra con la webcam la stanza e il computer ci svela, in anteprima, come apparira’ con il letto montato e posizionato. non ci piace? nessun problema, stampiamo un nuovo codice, lo mettiamo al posto di quello vecchio e controlliamo il risultato. quando siamo finalmente soddisfatti, il computer sa gia’ con quali prodotti stiamo arredando la camera e li ordinera’ per noi.

scordiamoci anche i navigatori cosi’ come li conosciamo oggi: non piu’ una mappa con il percorso da effettuare, ma precise indicazioni sovrapposte direttamente sulla strada davanti ai nostri occhi. oggi, grazie a wikidrive su uno smartphone, domani proiettati sul parabrezza della nostra auto. dopotutto, gli aerei militari utlizzavano l’hud fin dagli anni ‘80, si vedono gia’ le prime macchine con collegamento ad internet incluso negli optional, e’ solo una questione di tempo prima che qualche casa costruttrice trovi un accordo con un fornitore di servizi e includa nella gamma top delle sue vetture un “visio-navigatore”.

un altro comparto dove la realta’ aumentata ha grandi potenzialità di sviluppo, e’ quello del mobile social gaming: pensiamo ad una caccia al tesoro collaborativa, dove gli indizi virtuali sono disseminati all’interno di un percorso urbano, dove precisi eventi innescati da un team possono cambiare il corso dell’avventura a cui anche altri team partecipano: una spia si nasconde all’angolo del parco: il primo team che la trova, inquadrandola con un telefonino, ricevera’ preziose informazioni. a questo punto la spia va via, oppure si muove e non sara’ piu’ rintracciabile nello stesso luogo, ma in un posto diverso, che i successivi team dovranno scoprire. magari potremmo anche incontrare i beatles per strada.

ovviamente anche il turismo potrebbe beneficiare di queste innovazioni. se gia’ prima si parlava della possibilita’ di sapere nome e informazioni aggiuntive su un monumento, un’opera d’arte, un luogo, pensiamo a quanto potrebbe diventare divertente, e formativa, la visita ad un sito storico se arricchita dalla possibilita’ di vedere scene di vita provenienti dall’antichita’: i fori romani ricostruiti in tutto il loro sfarzo, gli affreschi di una facciata nella loro brillantezza originaria. basta inquadrare e muoversi, per conoscere cosa c’era prima. la nuova frontiera delle guide interattive.

dobbiamo comunque precisare che questa “prima generazione” di software per la realta’ aumentata non riconosce gli oggetti che vengono messi a fuoco dalla fotocamera del dispositivo, ma, come dicevamo prima, presumono che in quello scorcio di realta’ ci sia qualcosa solamente basandosi sulla sua posizione. un limite che, un po’ alla volta, verra’ superato, come gia’ ci sta mostrando google goggles, annunciato pochi giorni fa.

in ultimo, una buona notizia per gli sviluppatori. non occorre avere decine di migliaia di euro alle spalle per realizzare uno di questi software: layar e wikitude, ognuno con le sue peculiarita’, mettono a disposizione client o api per android e per iphone che fanno quando abbiamo descritto fin qui, con la possibilita’ di integrare propri dati. anche gratuitamente.

insomma, l’hype intorno a questo settore e’ davvero alto, e non tarderanno ad arrivare applicazioni che saranno in grado di lasciarci con il fiato sospeso, ancora di piu’ rispetto a quanto visto fino ad ora. sono convinto che ci troviamo di fronte ad uno stagno appena scoperto: qualche buona idea, iniziativa e un minimo di voglia di rischiare saranno l’esca giusta per tirare su i grossi pescioni che lo popolano. cosa state aspettando?

alfredo morresi

progetto: clubtimarche.it cliente: club ti marche

l’esperienza positiva dell’evento “creare conversazione fuori e dentro l’azienda” ha portato il club ti marche a percorrere l’”innovativa” strada delle community e a rinnovare il web site dell’associazione nell’ottica dei social network.

seguendo la prospettiva dell’interazione e della condivisione, il club ha abbracciato le logiche del web sociale e si è aperto al confronto con la “parte abitata della rete” accogliendo suggerimenti, proposte, iniziative e partnership; da queste premesse è nato il progetto strategico “ti-siamo marche” che ha portato allo sviluppo di un blog per favorire la conversazione e incentivare i feedback da parte delle persone che parteciperanno alla vita quotidiana della comunità.

il nuovo sito garantisce una fruizione dei contenuti molto fluida e da ampio spazio alle sezioni che costituiscono il “cuore pulsante” della community: un’area che racchiude tutti gli articoli informativi pubblicati nel blog, un’area che ospiterà meeting, workshop, eventi in diretta streaming e sessioni di microblogging, dando la possibilità a chi ci segue di esprimersi con domande, commenti e curiosità ed un area riservata ai soci che potranno pubblicare sul sito case study, articoli e interviste.

la parte tecnica ha previsto un’installazione di wordpress personalizzata secondo le esigenze del progetto, la caratteristica distintiva predominante è senza ombra di dubbio l’integrazione del web site con i social network dell’associazione (il club è presente su twitter e su flickr): è stato sviluppato un mash-up per la gestione degli eventi live ed integrato all’interno del sito, anche questo comodamente fruibile attraverso l’utilizzo di feed rss personalizzati che permettono di rimanere sempre aggiornati sulle iniziative e le novità dell’associazione.

sono stati utilizzati alcuni plugin per arricchire di funzionalità la piattaforma:

- sendit gestisce dinamicamente l’invio di una newsletter periodica.
- cimy estendere i campi del form di registrazione al sito, personalizzando con la richiesta delle informazioni selezionate.
- user access manager permette di attribuire al post in pubblicazione la visibilità pubblica o la visibilità solo ad un particolare gruppo di utenti.
- capability manager gestisce in modo avanzato il profilo degli utenti registrati.
- sociable da la possibilità di condividere il post nei maggiori social network.
-  wp-cumulus permette di aggiungere una tag cloud in flash.
- exmashup permettere di leggere via php un mashup rss.
- clubti admin theme permette la personalizzazione del tema grafico del pannello di amministrazione di wordpress

adriano

da poco è stato pubblicato (o meglio ri-pubblicato) il web site italia.it.

un sito che ci rappresenta? no, perché non è il suo scopo quello di rappresentarci. il web site nasce per promuovere il turismo, per attirare il visitatore nel nostro paese.

un sito costato troppo? forse, da come si legge il budget era elevatissimo e in molti avrebbero potuto fare di più con quei parametri.

un sito brutto? dipende, la bellezza è soggettiva… è stato scelto un layout bianco dove foto e anteprime di video fanno da protagonisti tra elementi spaziati ed essenzialistici. alcuni creativi lo criticano. io mi soffermerei più a capire se funziona, criticare è sempre facile.

un sito con carenze tecniche? sembra. i pareri di esperti mettono alla luce quanto, oltre a non presentare innovazione, non utilizzi nemmeno buone procedure già consolidate negli ultimi anni di web, quello professionale ovviamente.

un sito accessibile? non pare, dai commenti di molti esperti le attenzioni alla legge 04, vanto di noi italiani, sono poche, a volte sembra che il problema non sia stato posto affatto.

un sito politico? nemmeno mi ci soffermo. fa chiacchierare il sito italia.it. il mio giudizio è semplicemente “si poteva fare di più”. con questa discussione, a differenza di una chiacchierata, vorrei esprimere come mi sarei mosso in un progetto come italia.it valutando le buone cose che abbiamo nel nostro paese riguardo il mondo del web. vantiamo in italia uno dei primi provvedimenti legislativi in tema di accessibilità nonché esperti qualificati che rappresentano il nostro paese in una associazione mondiale con etica di rispetto degli standard W3C e dell’accessibilità ovvero IWA italia.

se l’azienda incaricata avesse lacune (come dimostrato) in materia sarebbe stato interessante quanto proficua una collaborazione;  sempre da come si legge il budget sembrava esserci. vantiamo anche un evento ormai annuale sullo studio dell’usabilità e l’architettura dell’informazione come l’italian IA summit.

se l’azienda incaricata avesse lacune in materia avrebbe potuto interfacciarsi e collaborare con i promotori di questa iniziativa. sarebbe stato bello poter vedere soluzioni moderne, efficacia e attenzioni in un web site che porta quel dominio e che deve funzionare per attirare turismo nel nostro paese. avrei voluto vedere un buon esempio di sito web.

vince la beta version. l’idea di “non ancora completo” salva ogni giudizio, ma mi chiedo: ha senso una versione beta? qualcuno visiterebbe qualcosa che non è ancora completo? si poteva fare di più.

alessandro

progetto: cucine2000.it cliente: cucine 2000

cucine 2000 aveva bisogno di rinnovare radicalmente il sito sotto il profilo grafico, funzionale e di gestione dei contenuti, la nuova soluzione web è stata progettata per valorizzare le numerose immagini, in modo da poter apprezzare sia le due principali collezioni, che per vedere nel dettaglio la vasta gamma di dettagli tecnici delle cucine: un restyling che migliora notevolmente l’usabilità della ricerca delle informazioni.

i nuovi percorsi di navigazione del sito consentono un’efficace gestione dei contenuti, così da poter individuare fin da subito tutti i prodotti. la piattaforma realizzata fornisce un’area riservata attraverso la quale l’azienda ha il completo controllo  delle principali sezioni del sito con la possibilità di inserire autonomamente le informazioni, le gallerie di immagini.

l’interfaccia è stata studiata per focalizzare l’utente navigatore negli scatti delle cucine e dei loro dettagli, il layout dell’home page infatti lascia uno spazio importante alle foto pari al 85% circa dello spazio disponibile. questo è stato possibile grazie all’utilizzo della tecnologia flash che ridimensiona automaticamente lo scatto adeguandolo alle dimensioni della finestra di navigazione. la stessa soluzione è stata utilizzata sull’altro apposito layout della sezione collezioni unita ad una galleria immagini che consente all’utente di scorrere rapidamente tutti gli scatti.

il content management system è stato sviluppato in PHP basato su zend framework: il sistema di amministrazione gestisce un database utenti, i quali si possono iscrivere nella parte pubblica del sito. l’utente, una volta ricevuta l’approvazione dall’amministratore avrà accesso al download dei listini ed a una sezione contenente informazioni riservate.

adriano

progetto: www.teatroclaet.it cliente: teatro claet

da tempo si sente parlare sempre più dell’adozione della griglia come ripartizione degli spazi in un layout e del ritmo verticale per mantenere i testi allineati come su un quaderno a righe della scuola. l’esigenza di esprimersi al meglio, mantenere i canoni di qualità più alti, aggiornarsi alle ultime tecnologie e soprattutto lavorare con una creativa che ha già intrapreso questa filosofia di progettazione mi ha fatto approfondire questi argomenti.

primo passo: chiarire le idee.

Il “grid system” (di seguito griglia) è la suddivisione del layout in colonne verticali uguali tra loro dove, una volta stabilito lo spazio che le separa, l’unione di esse dà origine agli spazi dei macro blocchi (i nostri DIV), e sotto blocchi fino alla scomposizione minima della colonna stessa che rappresenta lo spazio minimo consentito.
il “vertical rytm” (di seguito ritmo) è il flusso del testo che segue una griglia di linee orizzontali stabilite in fase di progettazione grafica. queste linee sono come le guide di un quaderno. i testi quindi la rispettano e mantengono gli stessi allineamenti verticali tra blocco e blocco del nostro layout. seguono una giusta spaziatura proporzionale alle dimensioni del font che rispetta sempre questo ritmo e non lo sfalza.

la griglia ed il ritmo sono due concetti diversi e separabilmente implementabili anche se l’accoppiata è complementare ad un risultato più preciso ed efficace. la modularità delle due soluzioni comunque offre una versatilità di implementazione che ci lascia liberi di scegliere anche in base ai soliti problemi di tempo e budget. il ritmo può essere applicato anche ad una sola parte del layout e questo lavoro può essere fatto anche in un secondo momento: potremmo portare a ritmo anche un lavoro già realizzato dove non era previsto. la griglia invece fa parte della struttura scheletrica del layout e pertanto è una scelta da porsi ad inizio lavorazione o ne comporterà in futuro una grande rielaborazione del codice HTML e CSS.

secondo passo: capire i vantaggi.

la griglia offre a primo impatto una versatilità nei blocchi del layout rendendo molto semplice la suddivisione dei spazi e delle colonne sia per testi che per elementi decorativi. non si rischia mai di utilizzare una porzione di spazio sproporzionata o disordinata. il tutto crea un ordine nella struttura che è delizia per i creativi e semplicità per i web designer. lato codice si eliminano alcuni DIV ridondanti semanticamente poco corretti introducendone altri (da un lato sempre ridondanti) ma semanticamente corretti.
il ritmo invece, come si legge dalle teorie di pensiero, offre estremo ordine e riduce l’entropia della pagina che si traduce in leggibilità e leggerezza. altra delizia per i grafici, magari meno tangibile per i tecnici, che influisce sulla percezione cognitiva dell’utente, anche questo tema sempre più blasonato dagli studi di usabilità e architettura dell’informazione.

terzo passo: l’implementazione.

di materiale ce n’è molto online ma la maggior parte applicato ad esempi di pagine bianche con solo testo. capiterà mai a noi una pagina così? no. dunque ho voluto studiare questa tecnica su di un progetto reale che ha visto la pubblicazione qualche giorno fa: “teatro claet” un blog (basato su wordpress) di una compagnia teatrale.

in questo caso di layout fisso è stato scelto un ingombro massimo di 960px come solitamente accade e per la griglia sono state scelte colonne da 60px separate da uno spazio di 20px. Il risultato è quindi un DIV contenitore di 12 colonne (più relativi spazi) quindi 12 (colonne) * 60px (ingombro) = 720, e 12 (colonne) * 20px (spazio tra una e l’altra) = 240px, da cui 720px + 240px = 960px appunto il nostro ingombro scelto. il layout è stato poi suddiviso in due macro blocchi (contenuto e colonna 1) da 6 colonne ciascuno. a sua volta la colonna 1 è composta da due sotto blocchi da 3 colonne ciascuno.

una volta impostato il lavoro lato creativo non resta che montarlo con HTML e CSS. nulla toglie che questa spaziatura di colonne data dalla griglia sia rispettabile con una stesura del codice HTML e CSS a piacimento e personale ma la vera innovazione del grid system e i suoi vantaggi tecnici stanno proprio nel rispettare questa tecnica utilizzata anche guarda caso da due dei principali framework CSS come yui e blueprint.
il sistema a griglia prevede il DIV come elemento di blocco/struttura e fin qui non cambia niente. avremo sempre i DIV contenitore, testata e fondo come fin’ora siamo abituati a vedere ma per ogni DIV che non sarà largo quanto il contenitore (come contenuto o le colonne e tutti i sotto blocchi) subentra il sistema griglia.

infatti i DIV “addetti” a rispettare la griglia hanno una classe che li identificano in base a che tipo di ingombro sto adoperando rispetto alla griglia. lato CSS vado ad indicare l’ingombro di tali classi delle colonne e tramite un margine negativo al div contenitore della griglia e alla tecnica dei float contrari rendo l’affiancamento delle colonne con una compatibilità che parte da IE 5.5 fino alle moderne release di browser. inoltre si elimina dal codice il famoso e semanticamente scorretto DIV cleaner o pulitore (insomma il comune resettatore di float che eseguiva il clear dei blocchi flottanti) ed il DIV corpo (ovvero il contenitore dei sotto blocchi principali come contenuto e colonne).
tale sotto scomposizione dei DIV griglia è infinita fino al valore minimo della colonna stessa ovvero l’ingombro della colonna scelta che nel nostro caso è 60px, il tutto affiancato e senza problemi usando le classi nei DIV della griglia. ogni DIV non addetto alla griglia ha una classe che gli toglie le proprietà lasciandocelo quindi libero per le nostre formattazioni e utilizzi.
per quanto riguarda il ritmo verticale si è scelto un intervallo riga di 18px e un font base di 12px. con questi due dati è possibile calcolare la proporzione che deve avere ogni interlinea per ogni grandezza di font scalare ed i relativi margini. questo calcolo è macchinoso e impiega diverso tempo ma per fortuna ci sono molti tools on-line che ce lo calcolano automaticamente restituendoci quindi le proprietà CSS che ci servono espresse per il body, per le p e per tutti gli h. dando per scontato che usiamo un master CSS per il reset delle proprietà non resta che far ereditare il line-height a tutti gli elementi.

durante il montaggio incontreremo elementi blocco o speciali che non ereditano il line-height o necessità di spaziarne maggiormente altri. per effettuare questo occorre utilizzare sempre spazi multipli dell’interlinea scelta, nel nostro caso di 18px. se ci troviamo di fronte ad un’immagine, video, flash o altro elemento multimediale che non può essere ridimensionato in misura multipla all’interlinea ci aiuteremo con dei margini per portarlo ad un ingombro che segue il ritmo.

quarto passo: le considerazioni.

l’utilizzo della griglia è una buona procedura da effettuare sin dall’atto creativo. è segno di ordine, funzionalità e attenzione agli spazi. anche se non utilizzata tecnicamente ma solo presa in considerazione lato creativo porta i suoi vantaggi in quanto si riversa inevitabilmente sull’impaginazione dei contenuti. implementare la griglia con i HTML e CSS è altrettanto valido, funzionale e compatibile. cambia un po’ il modo di scrivere codice ma è questione di pratica.

da migliorare la questione nei layout fluidi in em dove ogni calcolo deve essere convertito da px ad em e la griglia varia al variare della dimensione dei font. ancora più complesso sarà per i layout fluidi in percentuale dove lo spazio è relativo alla finestra del browser e non ad una unità di misura stabilita. in casi di grafiche molto complesse dove texture o sfondi sono utilizzati come background dei macro blocchi è possibile che torni necessario il DIV cleaner per far esistere l’altezza del blocco contenitore degli elementi flottanti.

il ritmo verticale è una finezza meno percepibile all’occhio del navigatore ma che inevitabilmente comporta più leggibilità e meno sforzo nella lettura dei contenuti come ogni situazione migliore che il nostro cervello percepisce da un’esperienza cognitiva.

è positivo prevedere anche il ritmo già dal lato creativo e aiuterà anche la realizzazione lato tecnico, l’unico lato negativo è il tempo che necessariamente impiegheremo per assicurarci che il ritmo sia mantenuto in tutta la pagina che è maggiore rispetto un lavoro in cui questo sistema non è usato. nessuno vieta di utilizzare il ritmo solo nel contenuto o nel contenuto più colonne in modo da fornire maggior leggibilità ed ordine solo nelle parti più sottoposte a lettura anzi potrebbe essere un modo per implementarlo piano piano nel tempo. da valutare quando in un lavoro viene fornito un back end per l’inserimento dei contenuti. o chi popola la pagina è al corrente delle dimensioni usufruibili o il sistema deve prevedere il ridimensionamento in base al ritmo.

da migliorare le unità di misura e utilizzare sempre gli em sia come font-size che come margine di spaziatura in modo che anche al resize del font il ritmo venga mantenuto non solo dai testi ma anche da tutti gli altri elementi.

qui un’immagine del blog teatro claet ottenuta sostituendo lo sfondo grafico con la griglia che si ripete all’infinito. è possibile notare come i testi rispettino il ritmo verticale (le linee rosse) e si vedono anche le colonne della griglia (rosso scuro) intervallate dallo spazio stabilito (intervalli neri).

alessandro

da wikipedia:

in informatica, open source (termine inglese che significa sorgente aperto) indica un software i cui autori (più precisamente i detentori dei diritti) ne permettono, anzi ne favoriscono il libero studio e l’apporto di modifiche da parte di altri programmatori indipendenti. questo è realizzato mediante l’applicazione di apposite licenze d’uso.

il software libero è software pubblicato con una licenza che permette a chiunque di utilizzarlo e che ne incoraggia lo studio, le modifiche e la redistribuzione; per le sue caratteristiche, si contrappone al software proprietario ed è differente dalla concezione open source, incentrandosi sulla libertà dell’utente e non solo sull’apertura del codice sorgente.

dalla prima comparsa alla fine degli anni ‘80 i software open source ne hanno fatta di strada, ora non sono più riservati a pochi addetti ai lavori, anzi, al giorno d’oggi è difficile accendere un computer e non trovare all’interno qualche applicazione open source.

l’enorme diffusione degli ultimi anni non è da imputarsi solamente alla semplicità di condivisione (grazie ad internet) ed al costo spesso nullo dei programmi open source, ma anche alla qualità che negli ultimi anni questi software sono riusciti a raggiungere. non c’è niente di strano nel vedere questi software utilizzati in applicazioni mission critical.

nel 2008 coverity ha analizzato circa 55 milioni di righe di codice relativo a progetti “liberi” in cerca di problemi di sicurezza e vulnerabilità la conclusione è stata che: open source significa sempre più qualità e ottimi prodotti software, nonché maggiore affidabilità e sicurezza per gli utenti. la vera potenza del software open source sta nella possibilità di modificare/personalizzare il codice sorgente. questo infatti permette agli sviluppatori di basare il loro lavoro su parti di codice open source già esistente riducendo i tempi di realizzazione.

nel nostro lavoro adottiamo la filosofia open source come uno dei cardini del processo xquality, infatti tutto il software che realizziamo viene rilasciato ai nostri clienti con licenza open source. il motivo di questa nostra scelta è che non vogliamo consegnare ai nostri clienti dei prodotti ma delle soluzioni che risolvano i problemi o migliorino il loro business:  quindi il software diventa uno strumento e non il fine.

realizzare software che rispetti gli standard e rilasciarlo con licenza open source ci permette di fornire uno strumento migliore ai nostri clienti, perché avranno a disposizione uno strumento più flessibile in grado di adattarsi più facilmente alle sue necessità che probabilmente con il passare del tempo cambieranno.

contestualmente a questo post pubblichiamo su google code tre plugin per jquery che abbiamo realizzato per lo sviluppo del sito web bigelli marmi:

- e-xloading (crea dei layer di loading in attesa dei contenuti caricati via ajax)
- e-xgooglemaps (crea una mappa utilizzando il servizio di google con la possibilità di calcolare itinerari di viaggio)
- e-xmaprollover (permette un effetto rollover su immagini mappate senza dover utilizzare flash)

ogni suggerimento è ben accetto.

lorenzo

non vi spaventate se nella giornata di oggi vedrete questo blog site senza la consueta grafica.

oggi è il quarto css naked day, il giorno in cui il proprio sito web viene spogliato dagli stili per promuovere l’uso degli standard web. questo significa mostrare un uso corretto dell’xhtml, della struttura gerarchica delle informazioni e del linguaggio utilizzato per descriverle: dietro a una semplice interfaccia ci dovrebbe sempre essere del codice solido e scritto in modo che possa essere accessibile anche rimanendo solo testo e link.

aderiamo con piacere a questa giornata di sensibilizzare riguardo l’usabilità dei siti web e vi invitiamo tutti a partecipare. basta compilare il semplice form dedicato ed il vostro sito sarà incluso nella lista degli siti aderenti. a questo punto potrete rimuovere tutto il suo design.

alessandro