Con questo articolo cerco di rispondere ad alcune domande.

• L’azienda vuole evolvere il proprio know-how?

• Che cosa sta uccidendo molte aziende che si occupano di sviluppo?

I problemi delle grandi aziende IT è spesso ricercato nel settore sviluppo, tanto che più è grande l’azienda e piu’ si cerca di esternalizzare proprio lo sviluppo. In alcuni casi si cerca di manterenere il controllo sul know-how internalizzando i settori funzionali a scapito del development.
Detto questo non penso lontanamente che ci possa essere un problema nell’IT a causa dell’assenza di capacità professionali d’eccellenza all’interno dell’azienda, piuttosto sono convinto che il settore sviluppo sia proprio quello che concentra più cervelli interessanti; chi si dedica allo sviluppo lo fa quasi sempre per la passione nell’approfondire la conoscenza.
Per questo motivo vedo il problema dello sviluppo incentrato su come gli sviluppatori vengono messi assieme in azienda, come vengono gestiti e per quale motivo vengono assunti e con quale criterio gli vengono affidati i ruoli.

Nella  esperienza avuta ho potuto vedere risultati d’eccellenza e di qualità internazionale solo in brevi momenti  , solo in determate “isole felici” che il mercato era pronto ad assorbire. Questi gruppi di sviluppo sono evaporati nel tempo in molte delle aziende che ho conosciuto.

Le ipotesi che stanno dietro il recruiting di sviluppatori.

Per spiegare questa situazione ho intenzione di rendere espliciti alcuni dei presupposti taciti che spesso in una grande azienda sono alla base del recruiting di un team del settore sviluppo. Questo è un punto cruciale poichè, nella gran parte delle organizzazioni, chi influenza queste decisioni il più delle volte non potrà mai essere ritenuto responsabile.

Basandomi sulle idee di Ash Moran, i presupposti dell’organizzazione in questione sembrano essere i seguenti:

1. Gli sviluppatori sono fungibili
2. La produttività è proporzionale alle ore di  sviluppo
3.  I requisiti sono tutti necessari

1. Gli sviluppatori sono fungibili

Tom de Marco, nel suo “Slack – manuale per manager, imprenditori e Ceo“,  definisce “Il mito della risorsa fungibile“. Molti posti di lavoro in fabbrica e in magazzino sono ampiamente fungibili, nel senso che il tempo di portare qualcuno fino alla piena produttività è pressoché irrilevante (ore o giorni). Questo non è vero quando si parla di sviluppo, dove anche se un neo assunto conosce il linguaggio di programmazione, dato il contesto, ci vorrà  molto tempo per  l’apprendimento del codice di base e delle metodologie aziendali.

Non credo che gli sviluppatori  siano fungibili (almeno nella stragrande maggioranza dei casi), ma ho partecipato a innumerevoli meeting in cui i decision maker si comportavano come se questa ipotesi fosse valida. Ogni volta , stime alla mano, la stragrande maggioranza dei managers agisce come se un nuovo sviluppatore possa immediatamente aumentare la produttività del team.
Questa assunzione è in contraddizione con ciò che gli sviluppatori pensano espressamente in merito alla natura del proprio lavoro.

2. La produttività è proporzionale alle ore di sviluppo

Ci sono due forme degenerative di pensiero per questa ipotesi:

1) L’idea che uno sviluppatore che lavora 10 ore al giorno sarà il 25% più produttivo di uno sviluppatore di lavoro di 8 ore al dì

2) La convinzione che un team di 10 sviluppatori è del 25% più produttivo di un team di 8.

Ho parlato di degenerazione in quanto sono convinto, come Ash, che la natura dello sviluppo del software sia la creazione di nuova conoscenza, concetto che ho descrito in un precedente articolo.
Dobbiamo pensare agli svilppatori come figure che affrontano un compito creativo. Un lavoro che coinvolge costantemente il programmatore, chiamato sempre più spesso a prendere decisioni logiche.

L’ipotesi produttività-tempo si basa sull’idea che la produttività sia rappresentabile come una bilancia a squadra lineare. Questo non è vero nello sviluppo, per la semplice ragione che la complessità nella gestione di un team non è per forza relativa al numero di persone coinvolte, ma è funzione della natura del coinvolgimento e della quantità di comunicazione necessaria per svolgere un determinato compito.
Basta pensare che a volte è più semplice far svolgere un compito a molte persone, piuttosto che cercare di mettere daccordo 4 persone sulla scelta di quale film andare a vedere dopo cena.
Ovviamente dipende dal compito, così come alcuni importanti progetti informatici si possono svolgere meglio con una piccola squadra di lavoro.

La disattenzione è la causa principale di importanti bug.

Vi segnalo un interessante articolo: Do You Suffer From Decision Fatigue? ; il cervello umano ha una capacità limitata di fare scelte, e una volta stanchi, ci trova spesso a ricercare scorciatoie.

3. I requisiti sono tutti necessari

Nella maggior parte delle grandi aziende informatiche, i requisiti funzionali  vengono definiti al di fuori del team di sviluppo. A meno che il team di sviluppo non stia scrivendo software esclusivamente per se stesso, il cosidetto “Settore Funzionale” (Functionals) sarà coinvolto nel redigere un documento in cui è descritto il lavoro che deve essere svolto dal settore sviluppo. In seguito a volte accade che il 30% delle funzionalità nel software non saranno mai usate o non necessarie, quindi almeno il 30% del tempo di sviluppo diventa puro spreco.  Tuttavia, molte squadre sono contrattualmente obbligate a fornire una specifica (documento funzionale) senza un riferimento al valore delle caratteristiche della specifica stessa, questo può essere una fonte di bugs difficile da sanare.

Metodo Agile

Questo articolo nasce dopo una lunga “navigazione” tra moltissime pagine web che ho letto al fine di documentarmi meglio sulle metodologie che istintivamente ho sempre messo in essere quando ho avuto modo di gestire uno o più progetti.

Nel febbraio 2001, in una stazione scistica nel Wasatch Mountains dello Utah, diciassette persone si sono incontrate per parlare, sciare, rilassarsi, e cercare di trovare qualcosa in comune. Ciò che è emerso è stato il Manifesto Agile Software Development. I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e altri si trovavano di fronte alla necessità di un’alternativa alla documentazione che guida il processo, e alle pesanti metodologie di sviluppo software.

Quanto è emerso da questo incontro è stata la stesura simbolica di un Manifesto per il Software Agile Development firmato da tutti i partecipanti che si autonominarono “L’Alleanza Agile“. Questo gruppo di pensatori indipendenti sullo sviluppo software, a volte concorrenti tra loro, hanno convenuto sul Manifesto for Agile Software Development visualizzato sul  sito web  agilemanifesto.org/.

Propongo di seguito la traduzione fatta da Jacopo Romei aul suo sito web.

Manifesto per lo Sviluppo Agile di Software

Stiamo ricercando modi migliori di sviluppare software facendolo e aiutando gli altri a farlo.

Grazie a questa attività siamo arrivati a considerare importanti:

• Gli individui e le interazioni più dei processi e degli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione del contratto
• Rispondere al cambiamento più che seguire i piani

Ovvero, fermo restando il valore delle entità a destra, consideriamo più importanti le entità a sinistra.

I Dodici Principi del Software Agile
Vedi i firmatari (via agilemanifesto.org)
Riguardo gli autori (via agilemanifesto.org)
Riguardo il Manifesto (via agilemanifesto.org)
Riguardo questa traduzione

Processo Agile

Agile non è un processo specifico, ma piuttosto un termine generico per un gruppo di metodologie e di approcci che hanno una base simile. Questi approcci, tra cui Extreme Programming, Dynamic System Development Method, Scrum, Crystal e Lean tra gli altri, si basano sulla realizzazione di alta qualità, lavorando software presto e spesso, e la creazione di soddisfazione del cliente.

Sebbene ciascuno dei metodi che formano la famiglia dei processi agili ha un obiettivo simile, si raggiunge questo obiettivo attraverso pratiche diverse.

In questo articolo ho preso le migliori pratiche che abbiamo visto e fatto il lavoro di elencare tutti i processi e metterli insieme.

Immaginiamo una  figura a cerchi (come l’immagine dell’articolo)  come una rappresentazione di base di queste  pratiche agili che abbiamo distillato;
il cerchio più al centro  indica le pratiche che un paio di programmatori usano in quotidiano. Il successivo cerchio esterno  mostra le pratiche che vengono utilizzati da un team di sviluppatori. Il cerchio più esterno ci dà pratiche utilizzate da tutte le persone coinvolte in un progetto come “I clienti, sviluppatori, tester, analisti aziendali, ecc

Ciascuna delle pratiche nei cerchi si riferisce direttamente ai valori fondamentali della filosofia Agile mostrati ai quattro angoli: Comunicazione, Feedback, Coraggio e Semplicità. Cioè, ogni pratica ci dà un modo concreto per seguire i valori Agile e renderli parte del processo.

Elenchiamo le metodologie del modello “Agile”.

Agile Unified Process

Si tratta di una versione semplificata dell’IBM Rational Unified Process (RUP). Descrive un approccio semplice per lo sviluppo di software applicativo utilizzando tecniche agili e concetti propri del RUP.

Dynamic System Development Process

Si tratta di un metodo basato sul Rapid Application Development, un approccio iterativo e incrementale che enfatizza il continuo coinvolgimento di utenti e cliente.

Studiato per progetti di sviluppo di sistemi informativi caratterizzati da schedulazioni e budget ridotti e indirizza le più comuni cause di fallimento di un progetto, come il superamento del budget, il mancato rispetto delle date di consegna, il mancato coinvolgimento degli utenti finali e del top management.

Il suo obiettivo è di consegnare progetti nei tempi e costi previsti, adattando le modifiche ai requisiti in corso d’opera.

XTreme Programming

Extreme Programming (XP) è una disciplina che organizza i gruppi di lavoro verso la produzione di software di alta qualità in modo più produttivo che con metodi tradizionali. XP cerca di ridurre i costi delle modifiche ai requisiti decomponendo le attività di sviluppo in molti cicli brevi piuttosto che in un unico lungo ciclo.

Feature Driven Development

Un processo di sviluppo software iterativo ed incrementale che miscela una serie di buone pratiche in un insieme coeso. Queste pratiche sono orientate allo sviluppo di funzionalità nel rispetto delle esigenze del cliente, suddividendo l’attività di sviluppo in singole componenti (Feature) che procedono parallelamente.

Scrum

Un framework iterativo e incrementale per la gestione di progetti. Si basa su tre semplici punti: Sprint, Backlog e Scrum Meeting.
Molto simile ad Extreme Programming prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) alla fine dei quali consegnare una versione al cliente, indica come definire i dettagli del lavoro da fare nell’immediato futuro (Backlog) per averne una definizione estesa, organizza riunioni giornaliere del team di sviluppo (Scrum Meeting) per verificare cosa si è fatto e cosa si farà.

 Le sette pratiche centrali di lavoro Agile

Il lavoro Agile  si compone di 7 pratiche di base. Queste pratiche costituiscono un solido punto di partenza per qualsiasi persona, gruppo o comunità che voglia seguire la via Agile.

Self-Organizing Team

Qualsiasi gruppo di persone che desiderano essere un Team Agile ha bisogno di prendere l’iniziativa e di decidere autonomamente su come sta andando il lavoro (processo) e su come ha intenzione di fare il lavoro (prodotto). Il termine “squadra” si applica in generale a qualsiasi gruppo formato di persone che stanno lavorando insieme verso un obiettivo comune.

Il risultato più importante del team di sviluppo è lo stesso team, e non le specifiche competenze e capacità che gli individui imparano.

Se la squadra è parte di un’organizzazione più ampia, l’organizzazione deve dare alla squadra lo spazio, l’autorità e la sicurezza per riuscire ad essere auto-organizzati. Riguardo alla leadership, l’organizzazione è responsabile per la determinazione del “perché?”, Alcuni vincoli sul “come?”, Lasciando poi al team di rispondere alla necessità nel miglior modo possibile.

Questa pratica è Conosciuta anche come: Team totale (Extreme Programming), Cross-Functional Team (gestione aziendale).

Deliver Frequently

Agile utilizza brevi periodi di tempo per monitorare il processo di erogazione di valore. Ognuna di queste iterazioni o timeboxes è strutturata in modo tale, in realtà, che la squadra o il gruppo quando finisce un pezzo di lavoro lo consegna ai soggetti interessati.
Prima che i prodotti  possano essere consegnati, il valore maggiore puo’ essere ottenuto da questi prodotti. Questo valore aggiunto è derivato da opportunità quali le vendite precedenti, vantaggio competitivo, feedback , e riduzione dei rischi.

C’è un compromesso: più breve è il tempo di consegna, minore è valore che sarà dato a quel pezzo.

Conosciuto anche come: Sprint (Scrum), iterazione (Extreme Programming), timeboxing (generico), valore temporale del denaro (contabilità).

Plan to Learn

Ogni tipo di lavoro è disciplinato da un orizzonte di prevedibilità. Qualsiasi piano che si estende al di là di questo orizzonte di prevedibilità è destinato a fallire. Agile  utilizza un ciclo di apprendimento legato alla pianificazione dei lavori e accoglie questo come inevitabile.

Innanzitutto, è richiesto un obiettivo. Questo obiettivo può essere a lungo termine. Team che utilizzano lavoro Agile creano una coda di task di lavoro per raggiungere questo obiettivo. Per ogni iterazione, alcuni di questi elementi sono selezionati, finiti e quindi la coda viene regolata. I cambiamenti nella coda di lavoro si basano su fattori esterni, e che la squadra conosce.

Uno dei metodi più efficaci per la squadra per conoscere lo stato del suo lavoro è la retrospettiva. Dopo ogni consegna dei risultati, il team tiene una retrospettiva per esaminare come si può migliorare.

Conosciuto anche come: Controllare e Adattare (Scrum), Kaizen (Lean), Adaptive Planning (generico).

Communicate Powerfully

Una squadra ha bisogno di disporre di mezzi efficaci per comunicare, sia tra i membri del team e anche per le parti interessate. Per “Comunicare Potentemente” , una squadra ha bisogno di preferire la comunicazione di persona attraverso la comunicazione distribuita. Sincrono sulla comunicazione asincrona. Elevata larghezza di banda e più bassa larghezza di banda di comunicazione. Comunicazione multi-mode  su singola modalità di comunicazione.

Il risultato di non riuscire a comunicare con forza include il tempo sprecato per l’attesa, le incomprensioni che portano a difetti o re-lavoro, abbassamento della fiducia, difficoltà nel team-building, e in definitiva un fallimento.

Il mezzo più efficace per comunicare con forza, è quello di mettere tutta la squadra insieme in una stanza dove può fare il loro lavoro, ogni giorno per la maggior parte del tempo di lavoro.

Alcuni tipi di lavoro non si prestano a questo approccio (ad esempio la creazione di un video documentario), ma ogni sforzo dovrebbe essere fatto per migliorare la comunicazione.

Conosciuto anche come: Visibilità (Scrum), Team e Team intero Camera (Extreme Programming), War Room (gestione aziendale).

Test Everything

Testando tutto, guidando tutto il lavoro di un team, creando casi di test per verificare il lavoro, una squadra può raggiungere livelli qualitativi estremamente elevati. Questa capacità di prevenire i difetti è così importante che solo una decisione di livello esecutivo deve essere considerata sufficiente per consentire i difetti in un processo di lavoro. La qualità non è negoziabile.

Nel lavoro Agile, la rimozione di un difetto è l’unico tipo di lavoro che ha priorità su tutte le nuove caratteristiche / funzionalità. Se il risultato finale desiderato è quello di massimizzare il valore, rimuovendo difetti si raggiunge più facilmente un tal fine.

Ogni squadra ha un dovere etico di scoprire nuovi modi per testare efficacemente il proprio lavoro. Questo può avvenire attraverso l’uso di strumenti, meccanismi di feedback, automazione, e il buona vecchia capacità di problem solving.

Conosciuto anche come: canarino nella miniera di carbone (Scrum), Test-Driven Development (Extreme Programming), difetti per Opportunità (Six-Sigma).

Misura del valore (Measure Value)

Dal momento che la realtà è percepita, è importante per un team Agile, e per l’organizzazione, avere un metodo chiaro per descrivere e percepire ciò che è importante per l’organizzazione. Misurare il valore è un metodo critico per descrivere e percepire ciò che è importante.

Una metrica singola può essere usata per guidare tutte la misure e la definizione degli obiettivi e le ricompense di un’organizzazione. Tutte le altre misure sono secondarie e devono essere trattate come tali: limitate e temporanee.

Ci sono molte cose più facilmente misurabili rispetto al valore. Spesso è facile misurare i costi, e le ore lavorate, oppure i difetti riscontrati, o la stima ore effettive … ecc, tuttavia, tutte queste altre misure implicitamente o esplicitamente non fanno altro che portare ad un comportamento sub-ottimale.

Conosciuto anche come: Risultati di misura (Scrum), ROI (gestione aziendale), Driver economico (Good to Great), Running Caratteristiche testate (Extreme Programming).

Clear the Path (Cancellare il Percorso)

Tutti coloro i quali, in un’organizzazione, utilizzano lavoro Agile si assumono la responsabilità per la pulizia del percorso, rimuovendo (cancellando!) gli ostacoli che impediscono il lavoro venga svolto in modo efficace. Cancellare il percorso non significa solo trovare espedienti e soluzioni rapide ai problemi, ma piuttosto avere il tempo di guardare un ostacolo e fare il meglio possibile per rimuovelo in modo permanente.

Nel metodo di lavoro Agile, il Facilitatore del processo è la persona che è responsabile per tracciare gli ostacoli e garantire che il “percorso venga cancellato”. Per fare questo, il facilitatore di processo mantiene un record sugli ostacoli.

La cancellazione del percorso è  a volte un doloroso lavoro che ci espone a cose che preferiremmo non affrontare. Di conseguenza, è fondamentale che le persone costruiscano la loro capacità di veridicità e lavorino per accrescere la fiducia tra di loro. Costruire una capacità di veridicità non è qualcosa che può essere fatto usando un processo esplicito.

Conosciuto anche come: eliminazione degli ostacoli (Scrum), fermare la linea (Lean).

E l’Acqua Calda?

Tutte le pratiche e le metodologie Agile sono destinate ad aumentare la produttività dei team che le adottano. In un certo senso si può pensare ad essa come “team + pratica  = migliore”, ciò che andreamo ad esplorare è la natura di “+”.

Se si vuole fare un piatto di pasta, mettiamo l’acqua a bollire in pentola e, la nostra acqua, inizialmente sarà fredda. Facciamo un intervento per correggere questo stato indesiderabile: accendiamo il fuoco. Mettiamo la pasta a mollo? Voglio dire, adesso? A meno che non vogliate mangiare della pasta scotta, che farà rabbrividire un italiano, la risposta è no: l’acqua deve ancora bollire. C’è un ritardo tra il momento in cui accendiamo il fuoco sotto la pentola e la bollitura dell’acqua, più o meno di 15 minuti. Ciò è significativo: significa che abbiamo il tempo andare a sfogliare un magazine su iPad. Ciò significa anche che, se l’acqua (gia salata?) non è ancora in ebollizione dopo mezz’ora, c’è qualcosa di sbagliato. Forse arriva poco gas, o non abbiamo girato bene la manopola. Qualunque cosa accada, intuitivamente sappiamo come utilizzare questo ritardo per gestire “pentola + manopola gas  in esecuzione = ….”.

La stessa idea è altrettanto – se non più – importante all’interno di un team di sviluppo software. Senza un senso del ritardo tra lo stato originale e lo stato desiderato dato un certo intervento, è facile sotto o sovrastimare.

Durante il riscaldamento della vostra acqua per la pasta, non c’è bisogno di aspettare fino alla fine per vedere se è in bollitura: controllando di tanto in tanto, si può vedere se i tempi vanno come previsto. Si può essere in grado di vedere se l’acqua ha iniziato il processo di ebollizione ed è quasi tutta evaporata, oppure si riscalda lentamente e ti rendi conto che la manopola del gas è al minimo. Questo feedback aggiuntivo consente di gestire in modo più efficace. Ma se l’acqua bolle dopo 15 minuti in condizioni ideali, e siete a soli 10 minuti, non aspettatevi che sia eveporata.

Conclusioni

Ancora una volta, non spegnere il gas e  esclamare: “L’acqua non bolle! Non abbiamo bisogno di mangiare dopo tutto! “.

Stimare i costi e definire il processo di un'app è come rivedere Tempi Moderni

Perché gli sviluppatori non riescono a stimare di stimare il tempo di produzione?

Questa, come altre domande, sono lo spunto per scrivere un articolo che mi è stato ispirato dopo la lettura di un post di  Ash Moran mentre navigavo per il Patch Space Blog.

Introduzione
In passato, mentre ero dirigente (settore di Sviluppo) di grandi gruppi italiani, ho cercato molte volte di comunicare al vertice aziendale che determinare su un documento (Plan) le esatte tempistche delle diverse fasi di lavoro dello sviluppo di un software è un attività abbastanza inutile e che, semmai, serve solo a far lievitare drammaticamente i costi.
Con questo non voglio affermare che le pianificazioni, e i diversi report che ci impongono le grandi aziende, sono  inutili; questi report servono a fornire date di scadenza e di rilasco delle componenti in relazione ad un budget definito.
Il problema nasce quando ti capita come capo la classica persona (top-manager?) che non avendo mai neppure sviluppato un “hello world!” si ostina a cercare di voler capire cosa esattamente farai con la tua squadra e ti imporrà dei lunghi meeting in cui sarai costretto a dire numerose baggianate perchè le domande che ti faranno saranno talmente idiote da non poter far altro che costringerti a dettagliare le varie fasi del processo che tanto non comprenderanno del tutto.

Cercare di spiegare e dettagliare in anticipo le fasi di uno sviluppo software, come definire i tempi di  tutte queste singole fasi (o task) a un “Manager” che si ostina a voler capire come poter fare/controllare/comprendere il tuo lavoro è come chiedere ad un compositore musicista di spiegargli come farà a comporre una canzone e quando e come arriverà alla prima , alla seconda o alla terza strofa…
Sappiamo con certezza che ad un compositore si puo’ affidare la scrittura di un’opera e l’artista al massimo potrà dirci quando ce la consegnerà ma di certo nessuno con la testa sulle spalle potrà pensare di chiedergli esattamente cosa farà , quando lo farà e di fornirgli una data esatta in cui sarà arrivato all’ ennesima nota sullo spartito.

A questo punto uno dei tanti miei ex colleghi, che casualmente leggerà questo articolo, si dirà: “bhe ma in azienda a noi non servono grandi artisti come Mozart, ma solo mediocri esecutori che devono fare esattamente quel che diciamo”.
La mediocrità è ovviamente una componente essenziale di molti cosidetti “managers” della grande o media azienda italiana, quella mediocrità che ha portato un paese di artisti e navigatori ai margini dell’impero economico e culturale.
E’ quindi abbastanza facile intuire che il mio pensierò ha basi culturali completamente diverse, poichè lo sviluppo è a mio parere sinonimo di creatività e solo la creatività applicata, unitamente alla genialità, può portare risultati duraturi e tenere alti quei fattori che fanno di un’azienda un motore economico-sociale che non si arresta neppure con le crisi.
Semmai, per parafrasare Einsten, è solo con la crisi che si sviluppa la genialità.

Stimare il tempo o il rilascio?

Non possiamo stimare il tempo per ogni singola attività nello sviluppo di software in quanto la natura del lavoro è la creazione di nuova conoscenza.

L’obiettivo di sviluppo del software è quello di automatizzare i processi. Una volta che un processo è automatizzato, esso può essere eseguito ripetutamente, e nella maggioranza dei casi, in un tempo prevedibile.

Il codice sorgente è come un progetto di produzione, il computer è come una vera e a se stante azienda, gli ingressi (dati) sono come materie prime, e le uscite (dati o programmi) sono come prodotti finiti. Quindi la chiave di volta sta nella progettazione del processo, che è un compito complesso e costoso. Una volta che il processo è stato definito e reso efficente non c’è più bisogno di riscoprire questo processo, basta acquisire il modello.

Non è in realtà sempre un problema il fatto che i tempi di sviluppo sono in parte  imprevedibili, perché il rovescio della medaglia è che così è il valore restituito sarà maggiore; un software di successo può creare o salvare molto più del suo costo. Tom DeMarco, sempre citato da Ash,  sostiene la necessità di concentrarsi sui progetti di alto valore proprio per questo motivo. Si noti che questo approccio ha valore come generazione di un nuova mentalità, che porterà a superare l’attuale  prevalente mentalità basata quasi esclusivamente sul controllo dei costi . Questa è una questione tutt’altro che banale.

Una delle migliori spiegazioni della variabilità, e come sfruttarla per creare valore, è  nei “Principi del flusso di prodotto per lo sviluppo” di Don Reinertsen.

Regola generale: prendere le stime di uno sviluppatore, raddoppiare e aggiungere un po’

Il doppio-and-add-a-bit è una regola interessante. Quando i manager fanno questo, spesso  le attività vengono completate in tempo.

Voglio precisare che la pratica di stimare ogni task, o building block (come lo chiamano alcuni consulenti) puo’ portare alla richiesta di budget di gran lunga piu’ elevati del necessario; a questo proposito voglio fare un’esempio su un fatto che mi è accaduto realmente:
Qualche anno fa un grandissimo gruppo industriale mi chiese di dirigere un progetto per un portale intranet, che sarebbe stato utile ai dipendenti. Dopo le prime stime sull’utilità di un nuovo portale intranet e sopratutto dopo l’analisi degli eventuali costi risparmiati dal Gruppo con l’introduzione del self-service per i dipendenti, si cerco’ di stimare tempi e costi dello sviluppo.
Consegnai un breve rapporto, basato sulla forte esperienza pratica sul campo, in cui stimavo a spanne un budget di X euro e il rilascio graduale dei servizi entro un anno. Mi chiesero allora di dettagliare uno per uno i task , fino al singola piccola applet, e di definirne per ognuno tempi di rilascio e costi per task . Facendo questo mi ero accorto, seguendo il loro modello di stima, che in ogni singola pagina web potevano essere presenti anche una trentina di building blocks (…). Evidentemnte ho cercato di fargli capire che questa era una pratica del tutto superflua e che bastava proiettare delle medie rispetto alle esperienze pregresse e sopratutto in base al materiale disponibile e alle caratteristiche professionali del team di sviluppo.
Sono stato costretto a lasciare l’incarico quando un gruppetto di giovani consulenti d’azienda , che mai nella loro vita avevano neppure lavorato su un sisterma di sviluppo, hanno presentato un piano ben dettagliato in un mastodontico file power point (ppt) con bella grafica e in cui si definivano tutti i piccoli building block, uno per uno e si proiettavano scadenze e costo per ognuno di essi: risultato un budget da 7X euro in tre anni. Decisi di lasciare l’incarico sopratutto dopo che il mio sguardo si era soffermato su una decina di slides dedicate al servizio “calcolatrice” il cui costo era di alcuni giorni di lavoro. Ogni sviluppatore degno di questo nome sa che un building block “calcolatrice” lo si ottiene gratis e neppure si deve mostrare in un piano del genere… e questo non era neppure il fatto piu’ eclatante.
Inutile proseguire , poiche’ evidentemente il mio approccio non era piaciuto e mi sarei dovuto adattare a quello dei consulenti che hanno lasciato l’azienda qualche anno dopo, in fallimento, e con nessun portale intranet funzionante… dopo 4 anni la stessa azienda ha dovuto riaccendere il sistema precedente , e questo dopo aver speso piu’ del previsto e senza risparmiare alcun costo.
Questo racconto è importante per far capire ai decision maker che un software , come un’app per iPhone o un sito web è frutto di esperienza sul campo e questa non potrà essere mai sostituita da stime dettagliate e del tutto astratte , che spesso costringono al rispetto stretto dei tempi intermedi non curando il senso del progetto stesso.
A mio parere è proprio l’insistenza  ,da parte dei top manager, ad adottare modelli di stima basati sul modello finanziario e fondato sul controllo del prodotto che hanno portato l’industria informatica italiana ad una crisi cosi’ profonda che oramai parlare di industria informatica italiana non ha neppure piu’ senso…

Non sono solo agli sviluppatori a far male le stime.

Tutti prima o poi inprovviseranno perché gli sarà affidato un compito che non hanno mai fatto prima e non saranno in grado di effettuare con successo una vera stima fino a quando non hanno acquisito esperienza.
Se non sappiamo, non sappiamo, e dobbiamo dirlo. I clienti o i capi che vedono i progressi compiuti e sono stati messi al corrente  del rischio dei task (e hanno scelto di investire ) hanno molto di più fiducia nel proprio team ripetto ai clienti o ai capi che basano il loro controllo su stime.

La stima è una abilità molto importante e dovrebbe essere insegnata sopratutto a figure “junior”

Ciò che dobbiamo fare è insegnare a tutti gli sviluppatori junior il significato della parola “fatto” o “terminato”. Se un cliente o un capo viene a scoprire nel futuro, a un certo punto imprecisato,  che qualcosa è stato consegnato incompiuto (possibilmente in fretta per venire incontro alla stima) cio’ non solo rende la stima controproducente, ma rende inaffidabile tutto il calendario di lavoro con l’attuale processo. Questo problema è molto comune, e può causare una significativa perdita della capacità di un team di sviluppo.

Agile Developing

Nessuna grande e consolidata azienda ha avuto risultati straordinari come quelli avuti dalle società create da adolescenti o giovani imprenditori che non avevano, fortunatamente, alcuna idea dei modelli di lavoro , e di pensiero, che erano imposti dall’establishment e dall’economia finanziaria. Pensiamo a Mark Zuckerberg | Facebook, a Larry Page e Sergey Brin | Google, Sean Parker | Napster, Plaxo, Causes e Facebook.. pensiamo a Jeff Bezos, Bill Gates o a Steve Jobs e tanti altri.
Tutti questi personaggi hanno creato il nostro futuro e,  con tutta probabilità, non si sono mai adattati (per fortuna!) ai modelli aziendali e alla moda.

Negli ultimi anni , probabilmente a causa degli enormi Flop,  tutte le grandi aziende  hanno tentato di cavalcare l’onda della new economy e ora si ritrovano a terra, parlano molto di “Agile Developing“.
Il nome “Agile” ci arriva dall’ingegneria del software che differenzia i metodi e i modelli di sviluppo in:  Metodologie pesanti per i vecchi metodi basati sul Modello a cascata,  Metodologie iterative per i metodi basati sul Modello a spirale e  Metodologie agili per i metodi basati sui principi definiti nell’Agile Manifesto.
Leggendo Wikipedia si scopre che il termine “Metodologie Agili” fu coniato nel 2001 proprio quando il Manifesto Agile è stato formulato e che:
” La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione (planning), analisi dei requisiti, progetto, implementazione, test e documentazione.
Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto”.

Se si utilizza l’approccio agile si dovrà comunicare sempre in tempo reale, preferibilmente faccia a faccia, puttosto che fare report o documenti. Componenti di un team agile sono solo le persone necessarie per portare a termine il progetto.

Mi aspetto che qualcuno mi dirà: bella scoperta , quella dell’acqua calda…

Molto probabilmente parleremo nei prossimi articoli di questo metodo che molte aziende stanno implementando , anche perche’ importato da molte società di consulenza.

• English

Secondo i diversi rumors e sopratutto in base alle dichiarazioni di Richard Shim (DisplaySearch),  i principali fornitori di display e LG, Samsung e Sharp avrebbero inziato la produzione del Retina Display per iPad3 con risoluzione doppia da 2048×1536 pixel. Lo schermo apparirà delle stesse dimensioni dell’attuale iPad, LCD da 10 pollici (non AMOLED)  con aspect ratio di 4:3.
Apple potrebbe quindi avviare la commercializzazione della nuova generazione di iPad 3 nel primo quarter del 2012.

Siamo soliti consigliare ai  grafici di creare gli elementi grafici destinati alle applicazioni con una risoluzione molto elevata in modo da poter , in futuro, essere facilmente riadattate a tutti i dispositivi iOS. Ad esempio nel caso del disegno di un’icona o di una splash page , ciò che continuo a riferire agli sviluppatori grafici è che non conviene mai partire da icone a bassa risoluzione, che potrebbero risultare sgranate su dispositivi con una risoluzione più elevata.
L’esperienza ci insegna cha Apple punta molto sulla qualità grafica e quindi è prevedibile che nei futuri modelli vengano istallati schermi con una densità di punti (dpi) sempre piu’ elevata. Ma spesso i grafici e le agenzie preferiscono non consegnare files con queste caratteristiche in modo da ridurre al massimo il carico di lavoro, pratica che non si troverà mai in linea con la filosofia di i3Factory le cui linee guida sullo sviluppo cercano sempre di prevedere le prossime mosse del mercato.

Come sappiamo le immagini utilizzate per le applicazioni destinate ai dispositivi Apple si distinguono per mezzo una convenzione data ai nomi files delle immagini stesse che prevede che tutte le immagini destinate ai Retina Display devono terminare il proprio nome  con i caratteri @2x.
Questa convenzione indica proprio un file immagine al doppio della risoluzione, che nel caso dell’iPhone4 è di 960 x 640 pixel, mentre nel caso dell’iPad 3 sarà di 2048 x 1536 pixel.
Notiamo, ad esempio, che il file “image.png” per iPad avrà un canvas di dimesioni 1024 x 768 pixels mentre lo stesso file per retina display “image@2x.png” , destinato ad iPad 3, avrà un canvas di risoluzione 2048 x 1536 pixel.

Riprendendo un’articolo di melabog scopriamo che tra i file della nuova app iBooks 2 (Presentato Durante l’evento Apple del 19 gennaio 2012) sono state trovate alcuni elementi grafici realizzati per una risoluzione di 2048 x 1536 pixel, come nella precedente versione di iBooks.

Uno dei motivi per cui gia da tempo eravamo certi sulla produzione di un dispositivo  iPad dotato di Retina Display fu proprio la scoperta di queste immagini ad alta risoluzione gia nella prima versione di iBooks, e poichè anche la stessa Apple raccomanda agli sviluppatori di lavorare con immagini in alta risoluzione, possiamo essere certi che le seguenti immagini scovate da melabog in iBooks 2 come una conferma sulla presenza del Retina Display nell’ iPad 3.

• English

Approccio HTML(5)
In questa 5a e ultima parte dell’articolo del CTO di i3Factory rappresenta l’ultima tecnica che vi mostreremo.
L’HTML5 è qualcosa che sta emergendo negli ultimi tempi, soprattutto grazie ai grandi miglioramenti in termini di stabilità e velocità introdotte dalla nuova versione di IOS per l’in-app viste web.
Un paio di buoni esempi di questo approccio sono l’Ars Technica app (link) e la rivista Bloomberg Businessweek + (link).

• English

Pagine pre-renderizzate da immagini
Questa tecnica è molto utilizzata all’interno delle riviste altamente interattive pubblicate utilizzando ambienti come Adobe Digital Solutions: esempi ben noti sono le riviste di Condé Nast (Wired è uno degli esempi più famosi).
Il modo in cui sono implementate queste riviste inizia con la suite dei ben noti strumenti di Adobe Digital Publishing (link), In Design in primis. Questi strumenti sono utilizzati da molti editori in tutto il mondo e le ultime versioni offrono la possibilità di esportare il progetto, oltre all’onnipresente formato Pdf, anche in un pacchetto adatto per la distribuzione attraverso iPad. Gli output di questi file possono essere testati utilizzando l’ App gratuita Viewer Adobe Content scaricabile da App Store, ma naturalmente l’applicazione finale, insieme con l’infrastruttura server necessaria per servire i contenuti, richiede una licenza di livello superiore (e costo…).

Ciò che caratterizza questo tipo di riviste è che al momento della creazione del progetto tutte le pagine vengono pre-renderizzate come jpeg o png e poi gli effetti speciali vengono sovrapposti successivamente.
Ciò significa che la sezione centrale (Core reader) del lettore rivista è essenzialmente un visualizzatore di immagini. Certo queste immagini si estenderanno per una superficie leggermente più grande dello schermo iPad, in modo che saranno inserite all’interno di una visione a scorrimento (scroll view), ma sono ancora solo immagini.
Tutto sommato la scelta tecnicamente non è male: l’iPad è molto veloce nel rendering delle immagini rispetto ai file PDF,  i calcoli necessari per trasformare i dati del  Pdf in bitmap non vengono fatti in questo caso, mentre la CPU sarà sufficiente veloce a decomprimere l’immagine e inviarla all’hardware grafico. Esattamente come abbiamo fatto nel caso PDF, possiamo applicare la tecnica di sovrapposizione e imporla su alcuni contenuti che richiedono l’interazione dell’utente sulla parte superiore dello strato di bottom-rendering.

Mentre questa tecnica è altamente efficiente dal punto di vista del tempo di rendering, ed è semplice da implementare in quanto tutte le complessità del layout di pagina sono state prese in considerazione e risolte con gli strumenti di desktop publishing, offre alcune forti limitazioni che devono essere prese in considerazione:

• ogni singola pagina richiede molto più spazio su disco e il tempo di download di questo tipo di riviste è aumentato  in confronto con una pagina pdf, lo spazio occupato è molto più grande e l’informazione di ogni pixel del testo deve essere fornita nel file e non possiamo neppure alleggerirlo forzando l’immagine con alti rapporti di compressione, se non vogliamo introdurre sfocatura nel testo. La pagina pdf, in particolare quelle pagine fatte di solo testo, è molto più leggera in quanto il testo non è pre-renderizzata e si presenta in formato vettoriale.

• lo zoom o il ridimensionamento dei font non è fattibile: invece, PDF e Core Text ridisegnano il testo utilizzando algoritmi vettoriali e rappresentano i font per dimensioni, questo ovvimente non si puà ottenere se si lavora su un’immagine jpg o png statica. Ciò significa che la rivista ha bisogno di essere disegnata con i tipi di carattere specifici e dimensioni prestabilite, i caratteri che sono adatti per la compressione jpeg (senza sfocatura) e per la risoluzione dello schermo (iPad 1 e 2 hanno 132 dpi, non è poi così alto; le cose andranno meglio con il prossimo iPad schermo retina !)

• Ricerca testo, con la rivista fatta d’ immagini non abbiamo la possbilità evidenziare il testo , e quindi la selezione del testo è impossibile, a meno che gli strumenti di pubblicazione digitale per fare le esportazioni  . insieme all’immagine forniscano anche uno schema  della pagina pre-renderizzata con una mappa completa delle coordinate del testo, qualcosa che non francamente non abbiamo ancora visto ma che noi stessi abbiamo implementato , su richiesta, per alcuni clenti del nostro sistema editoriale i3F Editorial.

Adobe non è il solo sistema con cui è possibile a pubblicare questo tipo di riviste con immagini statiche: ci sono diverse applicazioni personalizzate sul mercato che seguono esattamente lo stesso approccio.
Non è male, ma non sfruttano i grandi framework editoriali che Apple sta offrendo ai propri sviluppatori. Inoltre l’approccio basato sull’immagine ha anche molti altri limiti se confrontato con altre tecniche. Di sicuro un editore che è ha la padronanza degli strumenti dell’editoria digitale può trarre vantaggio da questo approccio, la qualità finale è indubbia e il time to market è il più breve, e al tempo stesso permette di fornire un contenuto adatto per l’iPad , e non solo un pdf adattato sullo schermo.

Ma vorremo raccomandare a tutti gli sviluppatori, che stanno facendo prodotti personalizzati e non stanno utilizzando speciali strumenti di composizione pagina (composition tools) di stare lontano da tale metodologia.

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

• English

Core Text  (in breve: CT) è un’altra di quelle tecnologie sviluppate per Mac e in seguito convertita per iOS.
Il framework Core Text è dedicato alla disposizione del testo e alla gestione dei font. Giusto per riassumere le capacità di questo framework, si consideri che è alla base della rivoluzione del desktop publishing che ha reso celebre il Mac in questo settore professionale.
Come Quartz Core Graphic (CG), anche CT (Core Text) ha un API basata su C, esistono comunque diversi wrapper open source di terze parti  che contengono le funzionalità più comuni con un alto livello d’interfaccia Objective-C.
Core Text (CT) non deve essere utilizzato per sostituire il rendering basato sul web a base di Html e Css, questo è un campo troppo complesso
che è meglio lasciare ai componenti di sistema dedicati, come la UIWebView che può essere utilizzata per rendere efficiente un rich text.
CT “comunica” con CG , infatti il rendering del testo è dato contemporanemente al rendering di una view basata su Quartz.
Le due API hanno convenzioni  e regole di gestione della memoria molto simili, per cui lo sviluppatore già abituato con un modello di programmazione “Core Foundation”  non trovera ostacoli nella comprensione della API Core Text.
Questo dà la possibilità allo sviluppatore di mescolare il rendering del testo e le immagini nella fase di rendering stesso (CT è limitata al solo testo, non ha capacità di disegnare l’immagine).

Il motivo principale per usare Core Text è perché questo esegue il rendering del testo direttamente sulla pagina, senza intermediari.
Si differenzia dai formati PDF che considerano ogni pagina come un’intero, si differenzia anche dalle tecniche web di base in quanto non possiede un linguaggio intermedio (come ad es. html) e nemmeno l’interpretazione del layout (css). Con CT si può scrivere direttamente nella pagina.

I componenti di base dietro CT sono oggetti del layout, che sono la traduzione diretta di caratteri in glifi (glyphs), “linee” di caratteri e di “frames”, che corrispondono ai paragrafi. La traduzione dei caratteri in glifi è fatto da “typesetters” e il testo da plottare viene dato attraverso l’utilizzo di stringhe di attributi, che sono stringhe comuni arricchite con informazioni attributo (dimensione del font, colore, ornaments).

Si decide di utilizzare Core Text per una rivista il cui schema sarà principalmente basato su un Testo con layout standard, in modo che si adatterà bene anche per i giornali. Probabilmente non è la scelta migliore per le riviste glamour, dove layout grafico cambia in ogni pagina e potrebbe essere piuttosto complesso.
Un chiaro vantaggio della soluzione basata su Core Text è che, con questo framework, non c’è bisogno di applicare la tecnica di sovrapposizione di cui abbiamo parlato nel paragrafo dedicato al Pdf. Con CT si divide direttamente la pagina in cornici (frames) e ciascuno di questi frames conterrà testo (reso da CT) o elementi multimediali.
Essenzialmente è possibile definire il layout della pagina, definendone la dimensione (che può andare bene per lo schermo iPad oppure può essere con scorrimento pagina verticale o orizzontale), poi si deciderà la dimensione e la posizione dei contenuti multimediali di questa stessa pagina e, infine, si definiranno i frames (diverse cornici rettangolari) che conterranno il testo.
L’organizzazione delle cornici di testo può essere di qualsiasi genere, una compatta struttura a singola colonna, due layout multicolonna o cornici di varie dimensioni. All’interno dei frames dovremo renderizzare il testo e Core Text vi aiuterà a gestire interruzioni di riga per questi paragrafi.
A questo punto si può facilmente fornire all’utente la possibilità di modificare il tipo e la dimensione di font  e lo stesso codice di rendering  può essere riutilizzato per riorganizzare rapidamente il testo all’interno dei frames (cornici).

La rappresentazione del layout di pagina può essere fornita in qualsiasi forma preventivamente decisa dallo sviluppatore assieme all’editore; la scelta migliore sarà il formato XML (tutto sommato è la base di qualsiasi formato di markup!) e che sarà inviato all’applicazione assieme con i testi (ancora in XML) e gli asset in un pacchetto zip file.

Una limitazione del Core Text è che si tratta di una tecnologia per il disegno di testo e non è ottimizzata per la modifica e l’interazione con l’utente, anche se non ne abbiamo bisogno in questa fase. Questo significa che se vogliamo , ad esempio, evidenziare il testo o selezionare e copiare le caratteristiche del testo stesso avremo bisogno di implementarle scrivendo codice.
Il framework ci fornisce alcune API per facilitare questo compito, ma in ogni caso il codice per implementare queste funzionalità deve essere scritto da uno sviluppatore in grado di gestire ogni singolo dettaglio. In ogni caso tutti questi compiti saranno notevolmente semplificati rispetto al PDF: qui, con CT,  si ha il controllo pieno del testo e la sua posizione di schermo, mentre fare quueste operazioni con il Pdf è ancora  piuttosto opaco poichè  il tutto è nascosto dietro una complessa struttura di dati che non si può controllare nella sua interezza.

Concludendo questa terza parte, la nostra raccomandazione è che se si deve implementare una rivista digitale, senza requisiti di layout estremo, con alcuni contenuti multimediali e un controllo veloce e potente di testo,  Core Text è la prima tecnologia da considerare.

Un ottimo tutorial su questo argomento è disponibile a questo link su Ray Wenderlich blog:
http://www.raywenderlich.com/4147/how-to-create-a-simple-magazine-app-with-core-text

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

NDR.
Per approfondimenti sul wrapper di Core Text segnaliamo un articolo: http://akosma.com/2010/07/08/core-text-objective-c-wrapper/

• English

La Rivista / Magazine è un file PDF

Qualora vogliate  impegnarvi a sviluppare una magazine app per iPad, che vi piaccia o meno,  la rivista che avrete a disposizione dall’editore vi sarà consegnata – con molta probabilità -  un file PDF.
Poiché non c’è modo di “sfuggire” da esso, alla fine sarà necessario sviluppare il vostro proprio lettore pdf o integrare qualche libreria gratuita o commerciale esterno. i3Factory ha a questo proposito sviluppato un reader propietario che possiede tutte le caratteristiche necessarie per pubblicare una magazine app alquanto performante.

Il motivo per cui pdf è ancora il formato dominante nel mondo dell’editoria e quindi e-publishing  ci appare chiaro:
la maggior parte degli editori fanno semplicemente il porting delle loro pubblicazioni esistenti e stampate su carta per iPad e iPhone. Questo per sia per ragioni di bilancio, dato che è ovvio che desidera riutilizzare l’investimento fatto nella creazione delle proprie testate e sia perchè gli editori – tranne rare eccezioni -  non possiedono ancora un modello di produzione volto alla piena fruizione multimediale dei propri contenuti.

Pertanto, come sviluppatori, non sarete ancora in grado di sfuggire al formato Pdf con l’eccezione di due casi:
1) la pubblicazione è nuovo di zecca e solo digitale, quindi non ci sono precedenti inparamenti per guidare la scelta finale

2) L‘editore ha grandi budget e / o è una forte esperienza utente (UX), è quindi un reale possessore di capacità di vision futura e crede nella nostra visione  e accetta di allocare il budget extra per ricreare un formato diverso per le proprie pubblicazioni.

In entrambi i casi non sono così rari incontri con quegli editori che hanno già  fatto lo sforzo di portare i propri prodotti sul web (con la notevole eccezione di quelli che ha fatto in Flash!), ma la gran parte delle case editrici piccole e medie imprese sarà ancora bloccata con in formato Pdf.

Purtroppo il Pdf non è il modo migliore per portare un magazine su iPad o altri tablet. E questo per diverse ragioni:

• La pagina di una rivista stampata ha dimensioni solitamente più grande dello schermo iPad o di un Tablet tradizionale: questo significa che quando la pagina si adatta allo schermo, tutti i caratteri appaiono più piccoli e quindi qualcosa di leggibile nella carta stampata potrebbe diventare illeggibile senza zoom, ma lo zoom non è sempre efficiente ed in particolare non è amato da tutti i lettori che possono perdere il loro “orientamento” all’interno la pagina.

• Le pagine di riviste stampate  non hanno le stesse proporzioni dello schermo iPad: questo significa che una pagina che si adatta allo schermo sarà delimitata da righe vuote in alto / basso o destra / sinistra.

• I layout di una pagina stampata spesso sono ottimizzati per lunghezza, per esempio un immagine panorama che si sviluppa
tra due pagine, quando il dispositivo viene tenuto in orientamento verticale, i dettagli grafici andranno persi, invece se il dispositivo è tenuto in orizzontale si sarà in grado di apprezzare le due pagine di layout, ma i caratteri saranno troppo piccolo per essere letti comodamente.

• I file forniti dall’editore non sono ottimizzati per il digitale, normalmente i contorni (tabella dei contenuti) e le annotazioni (Collegamenti a pagine o risorse esterne) non vengono esportati; questo significa che anche se il vostro lettore Pdf è consapevole di queste informazioni, nella maggior parte dei casi non è disponibile e quindi è necessario definire un divero modo di fornirle.

• Il formato ufficiale PDF supporta contenuti multimediali; purtroppo l’IOS non è in grado di gestirlo, per cui  tutti i contenuti interattivi devono essere fornite al di fuori del file pdf e associati ad esso.

Il rendering delle pagine è realizzato in iOS (e anche in OSX) attraverso il Quartz 2D API, cono Core
Graphics framework (CG). Quartz 2D è il motore grafico bidimensionale su cui si basano molte (ma non tutte)  funzionalità di disegno di IOS. Il
PDF API è un sottoinsieme del grande CG API. Questa API è “vecchio stile “e non si basa su Objective-C, ma è in puro vecchio C; oltre a tutte le regole di gestione della memoria che seguirà il Core Foundation (CF) con regole che sono diverse da Obj-C:
questo significa che particolare attenzione deve essere fornita al fine di evitare perdite di memoria, come ad ogni manipolazione la pagina PDF può pesare diversi megabyte e può facilmente innescare il memory watchdog, in tal modo la vostra applicazione potrà crashare.

In ogni caso se si è abituati con i concetti Quartz 2D sarà semplice renderizzare una pagina PDF seguendo questi passaggi fondamentali:

1. Ottenere il riferimento CG alla pagina pdf da trarre;
2. Ottenere il contesto grafico corrente per la vista che contiene la pagina;
3. Istruire Quartz a disegnare la pagina Pdf per il contesto.

Come potete vedere, a parte le fasi necessarie per il disegno del modello Quartz, il rendering completo è compiuto dal sistema e non c’è bisogno di avere alcuna conoscenza del formato dei dati di un file pdf. Quindi per voi il processo di rendering Pdf  è solo una scatola nera, e questo è chiaro quando si nota che tutte le strutture dati CG sono infatti opache e il loro contenuto interno si può accedere solo tramite API.
Ma un reader valido per una rivista in Pdf non può limitarsi al rendering, per cui vi sarà richiesto di supportare ad esempio lo zoom;
ora, il livello massimo di zoom può essere teoricamente molto elevato (non dimenticate che i caratteri nel file Pdf sono come i font
nel computer, non potranno mai perdere in precisione, anche per estremi zoom-in), è impossibile rendere l’intera pagina ingrandita in un canvas molto più alto dello schermo del dispositivo:
Qui abbiamo pixel ,non  vettori, e sarebbe immediato il crash dell’applicazione, perché la memoria è esaurita per una sola pagina. Quindi saremo costretti a introdurre tecniche per limitare il rendering e renderlo efficace per la solo parte visibile della pagina, questo nonè  sempre un compito facile.

Più complessa è l’analisi del documento: questo è necessario se si desidera estrarre contorni,  annotazioni, fare qualche ricerca di testo
ed evidenziare. In tal caso a parte un paio funzioni per estrazione di meta-dati, quello che ti fornisce l’API è un insieme di funzioni che vi permetterà di esplorare le strutture dati all’interno del documento. Non saremo in grado di ottenere qualsiasi informazione dal file se non si esplora l’albero dati (data tree) correttamente e se non si seguono le specifiche del documento PDF.
Ciò è aggravato dalla molte versioni che le specifiche PDF hanno ottenuto negli anni e dal fatto che molti editori usano ancora del vecchio software che esporta il contenuto in vecchi formati.

Carlo ha sviluppato un generico PDF Explorer, questo è stato parte di un impegno per un cliente che ha chiesto di sviluppare un generale lettore PDF. E’ risulato davvero difficile applicare tutte le specifiche di riferimento ufficiale del formato PDF, il mio suggerimeto è di concentrarsi sulle funzionalità più utilizzate e test con molti documenti. Come ho detto prima, CG naviga l’albero dei dati (data tree), ma non la interpreta per noi!

L’ultima sezione di questa parte, la spiegazione lunga ma necessaria, data l’importanza del tema, è come fornire contenuti multimediali sulla cima di un file PDF: tutti in tutti i
iPad è un dispositivo così versatile che noi non possiamo limitarci al semplice rendering delle pagine. Con l’aggiunta di contenuti extra per la pagina stampata è possibile sfruttare le caratteristiche del dispositivo
e ancora in vantaggio per l’investimento fatto nella creazione rivista.

Ci sono molte ragioni per giustificare questa scelta: ad esempio un messaggio pubblicitario stampato in grado di offrire un video al posto di un’immagine statica, o un link stampato su una pagina web può essere sostituito da un collegamento attivo ad una vista web, o infine possiamo mostrare il tempo corrente utilizzando un widget HTML5. Come ho già detto non è consigliabile introdurre tutti questi contenuti all’interno del file pdf: non sarà reso da quarzo e sarà comunque
costretti ad attraversare la struttura dei dati per estrarre il riferimento all’oggetto CG per ulteriori manipolazioni. Infine, non tutti gli editori sono a conoscenza di queste funzionalità o dei loro software di pubblicazione digitale è troppo vecchio per loro pieno sostegno.

Quindi la soluzione migliore è basata sulla “tecnica di sovrapposizione”.
Questa metodologia consiste nel rappresentare le pagine in due strati:

• il livello inferiore (“layer rendering”) conterrà il rendering PDF, in modo che conterrà l’immagine bitmap della pagina;
• lo strato superiore (“layer overlay”) attirerò tutti sovrapposizioni ed è sensato touches.More utente difficile è l’analisi del documento: questo è necessario se si desidera estrarre contorni, le annotazioni, fare qualche ricerca di testo ed evidenziare. In tal caso a parte un paio di meta-funzioni di estrazione dei dati, che cosa ti dà l’API è un insieme di funzioni
che vi permetterà di esplorare le strutture dati all’interno
il documento. Non sarà in grado di ottenere qualsiasi informazione
dal file se non si esplora l’albero dati in modo corretto
e se non si seguono le specifiche del documento PDF.
Ciò è aggravato dalla molte versioni le specifiche PDF ottenuto
negli anni e dal fatto che molti editori usano ancora
vecchio software che esporta il contenuto in vecchi formati.
Ho sviluppato un generico PDF Explorer, questo è stato
parte di un impegno di un cliente che mi ha chiesto di sviluppare
un generale lettore PDF scopo, ma in quanto è davvero difficile
applicare tutte le specifiche di riferimento ufficiale in formato PDF, il mio suggerimento è di concentrarsi sulle funzionalità più utilizzate e test
con molti documenti. Come ho detto prima, CG naviga
l’albero dei dati, ma non la interpreta per noi!

L’ultima sezione di questa parte – la spiegazione lunga ma necessaria data l’importanza del tema – è come procurare i contenuti multimediali di un file PDF:
l’iPad è un dispositivo così versatile che noi non possiamo limitarci al semplice rendering delle pagine. Con l’aggiunta di contenuti extra alla pagina stampata è possibile sfruttare le caratteristiche del dispositivo.

Ci sono molte ragioni per giustificare questa scelta: ad esempio un pubblicità in grado di offrire un video al posto di un’immagine statica, o un link su una pagina web può essere sostituito da un collegamento attivo ad una vista web, o, infine, possiamo mostrare le previsioni meteo utilizzando un widget in formato HTML5.
Come abbiamo già detto ,  non è raccomandato introdurre tutti questi contenuti all’interno del file pdf:
non sarà reso da quartz e saremo comunque costretti ad attraversare la struttura dei dati per estrarre l’oggetto CG di riferimento per ulteriori manipolazioni. Infine, non tutti gli editori sono a conoscenza di queste funzionalità o quelle loro software di pubblicazione digitale è spesso troppo vecchio per loro pieno sostegno.

Quindi la soluzione migliore è basata sulla “tecnica di sovrapposizione” (overlay technique).
Questa metodologia consiste nel rappresentare le pagine in due strati:

• il livello inferiore (“layer rendering”) conterrà il Rendering PDF, in modo che conterrà l’immagine bitmap della pagina;
• lo strato superiore (“layer overlay”) disegnerà le sovrapposizioni e sarà sensibile al tocco dell’utente.

Lo strato superiore di overlay è tipicamente costituito da componenti UIKit, quindi dovremo aggiungere un UIWebView html per i widget, si introducono una UIScrollView per visualizzare una galleria di immagini scorrevoli, o faremo aggiungere una vista Media Player per l’esecuzione video.
Di solito le descrizioni in sovrapposizione sono forniti da un file separato, ad esempio, uno di formato XML, JSON o plist, e sara inserito iinsieme  con il file pdf e tutte gli altri (filmati, immagini, file html, file musicali) in un unico file zip.
L’applicazione quindi scaricherà il file zip, lo scompattarà e  utilizzerà la pagina Pdf per riempire il rendering layer, aggungendo le informazioni associate in sovrapposizione a quella pagina per costruire un “overlay layer“.
Si noti che questa tecnica può essere applicata anche nelle altre tecniche di rendering  di cui parleremo nei prossimi articoli, in tal caso ciò permette di superare molti limitazioni del formato pdf.
Il requisito principale per lo sviluppatore è quello di definire un formato adatto, controllare tutte le pagine soggette a zoom e rotazioni con una trasformazione e corrispondente sovrapposizione e, infine, fornire alla casa editrice  gli strumenti e le linee guida necessarie per creare facilmente sovrapposizioni del genere.

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

• English

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

Uno dei grandi miglioramenti per tutti i proprietari di iPad è la possibilità di portare ovunque le propie rivista preferite o libri, grazie alle dimensioni dello schermo e il peso leggero dispositivo, che permette una  facile lettura. In particolare le relazioni sulle vendite  hanno dimostrato che in un momento di diminuzione mercato della stampa delle pubblicazioni vi è un enorme aumento del numero di abbonamenti alle versioni digitali degli stessi prodotti (il lettore interessato può leggere questo rapporto da MPA: http://www.magazine.org/association/press/mpa_press_releases/mag-mobile-reader-study.aspx)

Apple sta seguendo questa tendenza con grande interesse, e ciò è abbastanza chiaro se diamo uno sguardo alla evoluzione della
le caratteristiche di iOS che sono state introdotte dopo il rilascio della versione dedicata a iPad, che è di 3,2.
In particolare le tappe che sono state raggiunti sono tre, in comune tra i tre principali releases del sistema operativo:

• iOS 3.2 è stata arricchita dal framework CoreText, una tecnologia dedicata al rendering del testo sul display disponibile da tempo su Mac OSX e mai portati nelle versioni precedenti di iPhone OS.

• iOS 4.x ha introdotto il concetto di abbonamento auto-rinnovabile, in aggiunta allo standard di  Acquisti In App, questa funzione è stata
introdotto dopo lunghe discussioni tra Apple, che applica la commissione del 30% su ogni In App venduta e vieta a qualsiasi altro store esterno più economico l’accesso all’interno dei suoi dispositivi, e gli editori in cerca per le tecniche di fedeltà dei clienti.

• infine iOS 5.0 ha aggiunto la funzione di Edicola (Newsstand), che fornisce un luogo centrale, una vera e propria app App,  per raccogliere tutte le pubblicazioni e le  magazine  app compatibili e allo stesso tempo fornire una push notification per i nuovi contenuti e automaticamnte fornire a tutti gli abbonati la possibiltà di scaricare automaticamente i nuovi numeri, permettendo di leggere immediatamente le novità e  far risparmiare i tempi (A volte lunghi) necessari per il download.

Quello che Apple non ha fornito invece è un unica piattaforma di sviluppo per la creazione di applicazioni dedicate ai consumi di riviste. Questo ha portato a numerose iniziative dedicate per aiutare gli editori ad entrare nel mercato iPad con le proprie riviste . Queste iniziative, come ad esempio il nostro sistema editoriale i3F Editorial,  sono state preso da società importanti e ben noti, come ad esempio Adobe con i suoi affari Digital Publishing, e un sacco di molte start-
up, ognuno con una propria soluzione.

Come già detto, Apple non fornisce una soluzione unica, ma i developers hanno la disponibilità di una serie di frameworks e tecniche, con diversi livelli di complessità, che prevedono diversi modi di rappresentare la pagina sullo schermo.

Non c’è una scelta ottimale, poiché la decisione finale deve considerare aspetti che vanno oltre la pura tecnica.

In questo articolo cercheremo di descrivere queste soluzioni principalmente dal punto di vista dello sviluppatore di applicazioni, ma non dimentichiamo di enumerare i pro e i contro che possono influenzare la decisione dell’editore , come l’agency,  su quale tecnologia adottare.

Panoramica sul page rendering

Diamo per scontato che voi, lo sviluppatore, siate ad una certo dello  sviluppo di un  applicazione in cui la rivista è stato acquistato, scaricato ed è pronto per essere letta.
I dati del vostro documento, a questo punto vengono conservati nel file system del dispositivo e possono essere rappresentati da un unico file pdf, o da un insieme di file html e css o una directory contenente files di diversi formati, quali immagini, video, widget HTML5, file di testo.
Stai quindi per affrontare il problema di prendere una pagina (che nosrmalmente si estende oltre i limiti dello schermo) e la presentazione nello spazio vuoto del vostro UIView dedicato al rendering della pagina.

Nei prossimi paragrafi il nostro Carlo (CTO di i3factory)  presentera le seguenti metodologie per ottenere questo risultato:

• il rendering documento pdf
• pre-rendered visualizzazione delle immagini
• libero formato di rendering CoreText
• approccio basato sul web

Continua a leggere il prossimo articolo su Parte 2: Tecniche di Page Rendering #parte 2 : Riviste e Magazine in PDF

Questo articolo e’ stato pubblicato dal nostro CTO , Carlo Vigiani,  su icoder magazine, una validissima rivista per gli sviluppartori iOS.

Come abbiamo segnalato nel precedente articolo  di seguito trovate le principali caratteristiche di “Ice Cream Sandwich“ , dal punto di vista dello sviluppatore. Abbiamo tradotto alcuni importanti passi dal portale Android developer sul nuovo Os mobile Android 4.0,  che presenta importanti novità per il developer.

Unified UI framework per i telefoni, tablet e altro

Android 4.0 possiede una struttura unificata per l’interfaccia utente. L’Unified UI  framework include tutti gli elementi dell’interfaccia gia presenti in Android 3.x e API , così come nuovi elementi e le API.

Per gli sviluppatori, il framework di interfaccia utente unificata (Unified UI  framework) in Android 4,0 significa lavorare su nuovi strumenti di interfaccia utente con un metodo di progettazione coerente, codice e risorse semplificate e lo sviluppo diretto su tutta la gamma di dispositivi Android che istallano Android.

Comunicazione e condivisione

Android 4.0 estende le caratteristiche sociali e la condivisione di tutte le applicazioni presenti sul dispositivo. Le applicazioni possono integrare con i contatti, i dati dei profili e gli eventi nel calendario da qualsiasi attività dell’utente o social network.

Le principali API sono:

• Social API
• Calendar API
• Visual voicemail API
• Android Beam
• Modular sharing widget

New media capabilities

Low-level streaming multimedia
Android 4.0 possiede un diretto ed efficente percorso per il low-level streaming multimedia. Questo risulta ideale per applicazioni che necessitano un completo controllo sui media data prima di passarli alla piattaforma per la  presentation. A esempio, mediae  applicazioni possono ora ricevere dati da qualsiasi fonte, applicare  encryption/decryption proprietarie, e quindi inviare i dati al sistema per mostrarli.

Supporta il format multiplexed stream per audio/video in MPEG-2.

Per ll supporto a questo low-level streaming, viene introdotta  una nuova API nativa basasta su Khronos OpenMAX AL 1.0.1.
Questa API è implementata su gli stessi servizi di base della piattaforma esistente OpenSL ES API, così gli sviluppatori possono usufruire di entrambe le API insieme, se necessario. Strumenti di supporto per lo streaming multimediale di basso livello saranno disponibili in una prossima release del NDK Android.

Nuova caratteristica della telecamera

Gli sviluppatori possono usufruire di una serie di nuove funzioni della fotocamera in Android 4.0. ZSL esposizione, messa a fuoco continua, e lo zoom dell’immagine permettono alle vostre apps di cogliereal meglio le immagini statiche e video, anche durante la cattura video.

Media effects per trasformare le immagini e video

Un insieme di filtri di trasformazione ad alte prestazioni  consentono agli sviluppatori di applicare effetti  a qualsiasi immagine che viene  passata come una texture OpenGL ES 2.0. Gli sviluppatori possono regolare i livelli di colore e luminosità, cambiare sfondi, affilare, ritagliare, ruotare, aggiungere la distorsione della lente, e applicare altri effetti. Le trasformazioni vengono elaborate dalla GPU, quindi sono abbastanza veloci per l’elaborazione dei frame immagine caricate dal flusso di disco, una fotocamera o video.

Audio remote controls

New media codecs and containers

Android 4.0 aggiunge il supporto per ulteriori tipi di codecs e containers per permettere agli sviluppatori di accedere ai formati di cui hanno bisogno. Per le immagini di alta qualità compresse, il media framework aggiunge il supporto per i contenuti WebP. Per il video, il framework ora supporta lo streaming di contenuti VP8. Per il multimedia streaming, il framework supporta i protocolli HTTP Live streaming versione del protocollo 3 e la codifica di ADTS-contained contenuto AAC. Inoltre, gli sviluppatori possono ora utilizzare Matroska container per Vorbis e contenuto VP8 .

Nuovi tipi di connettività

• Wi-Fi Direct
• Bluetooth Health Device Profile (HDP)

Nuove UI components

• Layout enhancementse
• OpenGL ES texture views
• Hardware-accelerated 2D drawing

Tutti i dispositivi  con sistema operativo Android 4.0 devon osupportare un’accelerazione hardware per il disegno 2D. Gli sviluppatori possono trarre vantaggio da questo per aggiungere effetti all’ interfaccia utente, pur mantenendo prestazioni ottimali su schermi ad alta risoluzione, anche su cellulari. Per esempio, gli sviluppatori possono contare su scaling accelerato, la rotazione e altre operazioni 2D, così come i componenti dell’interfaccia utente accelerati come TextureView e le modalità di composizione come il filtering, blending, and opacity.

New input types and text services

• Stylus input, button support, hover events
• Text services API for integrating spelling checkers

Android 4.0 consente alle applicazioni di interrogare i servizi di testo disponibili, come dizionari, spell checker,  suggerimenti per le parole, correzioni, e dati simili. I servizi di testo sono esterni al IME attivo, per cui gli sviluppatori possono creare e distribuire dizionari e motori di suggerimento che si inseriscono nella piattaforma. Quando un’applicazione riceve i risultati di un servizio di testo – per esempio, suggerimenti per le parole – che possono essere visualizzati in una finestra popup dedicata al suggerimento direttamente all’interno della vista del testo, piuttosto che basarsi su l’IME per visualizzarli.

Enhanced accessibility APIs

Android 4.0 aggiunge nuove caratteristiche di accessibilità e  una enhanced API  per consentire agli sviluppatori di migliorare l’esperienza utente nella proprie applicazioni, in particolare su dispositivi che non dispongono di pulsanti hardware. Per i servizi di accessibilità come gli screen reader, in particolare, la piattaforma offre nuove API per fare query al contenuto nella finestra , per facilitare la navigazione, migliorare il feedback, e interfacce utente più ricche.

• Accessibility API
• Text-to-speech API

Uso Efficente della rete -  network usage

In Android 4.0, gli utenti possono visualizzare la quantità di dati in rete delle loro applicazioni in esecuzione. Essi possono anche impostare i limiti per l’utilizzo dei dati per tipo di rete e disabilitare l’utilizzo dei dati per applicazioni specifiche. In questo contesto, gli sviluppatori devono progettare le loro applicazioni per funzionare in modo efficiente e seguire buone pratiche per la verifica della connessione di rete. Android 4.0 fornisce network API per consentire alle applicazioni raggiungere questi obiettivi.

Come gli utenti passano da reti o limiti stabiliti su dati di rete, la piattaforma permette di interrogare le richieste di tipo di connessione e la disponibilità. Gli sviluppatori possono utilizzare queste informazioni per gestire in modo dinamico le richieste di rete per garantire la migliore esperienza per gli utenti. Gli sviluppatori possono anche costruire una rete su misura e dati di utilizzo delle opzioni nelle loro applicazioni, poi esporle agli utenti direttamente da Impostazioni per mezzo di un nuovo system Intent.

Sicurezza per apps e contenuto

Management delle credenziali

Android 4.0 rende più facile, per le applicazioni, gestire l’autenticazione e le sessioni protette. Un nuovo keychain API e lo storage criptato permette alle applicazioni di memorizzare e recuperare le chiavi private e le loro catene di certificati corrispondenti. Qualsiasi applicazione può utilizzare l’API portachiavi per installare e memorizzare i certificati utente e CA in modo sicuro.

Address Space Layout Randomization

Android 4.0 fornisce ora Address Space Layout Randomization (ASLR) per proteggere applicazioni di sistema e la terza dallo sfruttamento a causa della gestione della memoria.

Miglioramenti per l’Impresa

VPN client API

Gli sviluppatori possono ora creare o estendere le proprie soluzioni sulla piattaforma VPN utilizzando un nuovo VPN API e alla base di memorizzazione sicura delle credenziali. Con il permesso dell’utente, le applicazioni possono configurare gli indirizzi e le regole di routing, il processo di pacchetti in uscita e in entrata, e stabilire tunnel sicuri su un server remoto. Le imprese possono inoltre usufruire di un client VPN standard integrato nella piattaforma che fornisce l’accesso ai protocolli L2TP e IPSec.

Device policy management for camera

La piattaforma aggiunge un nuovo controllo della politica per gli amministratori che gestiscono i dispositivi con un installato Device Policy Manager. Gli amministratori possono ora disabilitare da remoto la fotocamera su un dispositivo gestito per gli utenti che lavorano in ambienti sensibili.

Questo articolo è basato da una libera traduzione dal’Andorid developer Portal (android-4.0-highlights)