Quando si decide di progettare un’App è sempre necessario seguire i principi di base della progettazione industriale.
Molte persone  pensano di commissionare un’app, ma quando si trovano a dover descrivere l’applicazione e quindi come la loro idea possa essere tradotta nell’esperienza dall’utente e nell’interfacia grafica (User Experience & User Interface),  si trovano impreparati e si nascondono molto spesso dietro frasi del tipo “non saprei questo è un lavoro per tecnici, pensateci voi tecnici!”.
Inutile aggiungere che quando poi i cosidetti “Tecnici” si mettono al lavoro queste persone, che non hanno vuluto delegare il concept, inizieranno a chiedere modifiche sostanziali dispensando consigli e ragguagli di ogni genere e quasi sempre solo dopo che l’app e’ arrivata alla fase finale del suo sviluppo.
E’ ben noto il concetto secondo il quale i “tecnici”, e gli ingenieri, prima costruiscono il cuore dell’applicazione e poi ci adattano il design e fanno il contrario, loro malgrado, solo se il commitment e’ valido e convincente e, sopratutto, quando questo è deciso fin dall’inzio delle fasi di progettazione.
Di norma con l’approccio “fate voi che poi vediamo” , voluto dai professionisti distratti e poco preparati,  il risultato estetico finale può risultare quantomai scadente dato che ogni ingeniere sa bene che, prima di mettersi a scrivere codice, bisogna aver chiari i principi dell’interfaccia utente unitamente alla descrizione delle funzionalità legate all’esperienza dell’utente stesso.

Alcuni sofisti mi potranno criticare per l’uso della parola “utente”, che a volte risulta poco accattivante se si pensa che alla fine gli utenti non sono altro che persone, ovvero individui utilizzatori. Questa differenza di significato delle parole mi è molto chiara, ma per semplicità comunicativa e sopratutto per necessità di traduzione preferisco usare la parola “utente” o “utilizzatore” al posto dell’ “individuo“.

10 principi per un buon design di un’app e di un prodotto

Inanzi tutto,  per citare Steve Jobs,  propongo  una delle definizioni di design che più mi ha convinto:
“Il design è l’anima che si trova al cuore di un oggetto creato dall’uomo e che gradualmente si estrinseca ai piani esteriori.”

Di certo lo stesso Jobs si ispirava ai principi di Dieter Rams, ex-designer della Braun, che ha enumerato i suoi 10 principi per un  buon design di un prodotto:

Dieter Rams e i suoi prodotti di design

• Un buon design deve essere innovativo.
• Un buon design deve rendere il prodotto utile.
• Un buon design deve essere dotato di estetica.
• Un buon design deve aiutare a capire il prodotto.
• Un buon design non deve essere invasivo, mancare di riservatezza.
• Un buon design deve essere onesto.
• Un buon design deve essere durevole.
• Un buon design è la conseguenza dell’ultimo dettaglio.
• Un buon design si deve preoccupare dell’ambiente.
• Un buon design deve contenere il minor design possibile.

Naturalmente è facile capire che questi principi si adattano sia al design dei prodotti industriali, ma anche per il design delle Applicazioni, sopratutto se queste verranno utilizzate sui prodotti che sono stati costruiti proprio secondo i buoni principi del design industriale, come lo sono tutti i prodotti Apple.

Progettare meglio, lavorare meno

Dieter Rams, creatore dei 10 principi, ha sempre espresso il suo approccio al design con la frase: “Weniger, aber besser” , ovvero “Meno, ma meglio” .
Il minimalismo , oltre ad essere molto elegante, è sicuramente il modo migliore per permettere a tutti gli utenti-utilizzatori di comprendere d’istinto il prodotto e le sue funzionalità e rende il prodotto stesso, o l’App,  amichevole all’uso (user friendly) e “puro”.

Di seguito riporto i commenti , tradotti dall’inglese, dello stesso Rams sui principi da lui stesso enunciati:

1.  Le possibilità d’innovazione non sono esaurite. Lo sviluppo tecnologico offre sempre nuove opportunità per il design innovativo. Ma il design innovativo si sviluppa sempre assieme alla tecnologia innovativa, e non può mai essere fine a se stesso.
   (The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself )
2. Un prodotto viene acquistato per essere utilizzato. Esso deve soddisfare determinati criteri, non solo funzionali, ma anche psicologici ed estetici. Un buon design sottolinea l’utilità di un prodotto, mentre trascura tuuto ciò che potrebbe sminuirla.
   (A product is bought to be used. It has to satisfy certain criteria, not only functional, but also psychological and aesthetic. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it. )
3. La qualità estetica di un prodotto è parte integrante della sua utilità, perché i prodotti che utilizziamo ogni giorno influiscono sulla nostra persona e il nostro benessere. Ma solo gli oggetti ben costruiti possono essere belli.
   (The aesthetic quality of a product is integral to its usefulness because products we use every day affect our person and our well-being. But only well-executed objects can be beautiful.)
4. Chiarifica la struttura del prodotto. Meglio ancora, si può far parlare il prodotto. Meglio se esso è auto-esplicativo.
   (It clarifies the product’s structure. Better still, it can make the product talk. At best, it is self-explanatory.)
5. I prodotti che soddisfano un fine sono come strumenti. Non sono né oggetti decorativi, né opere d’arte. Il loro Design dovrebbe quindi essere sia neutrale che sobrio, per lasciare spazio all’auto-espressione dell’utilizzatore.
   (Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.)
6. Non costruire il prodotto in modo da farlo apparire più innovativo, potente o importante di quanto sia realmente. E non tentare di manipolare il consumatore con promesse che non possono essere mantenute.
   (It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.)
7. Evita di seguire la moda ma non appare mai antiquato. A differenza del design “alla moda”, il prodotto deve durare per molti anni – anche nella società dell’usa e getta di oggi.
   (It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.)
8. Nulla deve essere arbitrario o lasciato al caso. La cura e la precisione, nel processo di progettazione, mostrano il rispetto nei confronti dei consumatori.
   (Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.)
9. Il Design offre un importante contributo alla salvaguardia dell’ambiente. Esso conserva le risorse e riduce al minimo l’inquinamento fisico e visivo durante tutto il ciclo di vita del prodotto.
   (Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the lifecycle of the product.)
10. Meno, ma meglio – questo perchè ci si concentra sugli aspetti essenziali, e i prodotti non sono appesantiti da elementi non essenziali. Torna alla purezza, torna alla semplicità.
    (Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials.Back to purity, back to simplicity.)

Valutazione Euristica

A questo punto non mi resta che descrivere anche la cosidetta valutazione euristica.
La Valutazione Euristica è un metodo ispettivo che viene effettuato esclusivamente dagli esperti di usabilità  e consente di valutare se una serie di principi generali di progettazione sono stati applicati correttamente nell’interfaccia utente.
Le linee guida (“Ten Usability Heuristics”) su cui si basa questo tipo do valutazione sono state sviluppate negli anni 1990 da Jakob Nielsen e Rolf Molich e sono state pensate per i desktop software , ma anche in questo caso questi principi sono ancora validi per le applicazioni studiate per touchscreen, come le App iOS per iPhone e iPad ,  per le  app Android e Window Mobile.

Ancora una volta la stampa pubblica frasi d’impatto per far credere che anche il sistema Apple sia stato infettato da un Virus.

Sicuramente un tipo di infezione c’e’ stata ma come già avevamo spiegato in un precedente articolo , i sistemi basati su unix molto difficilmente possono essere infettati da virus veri e propri.

Quel che sta succedendo in questi giorni è che un Malware, e non un virus, ha infettato alcuni mac i cui utenti hanno disgraziatamente istallato una falsa estensione per flash, che di norma non andrebbe istallata senza le dovute precauzioni.

Chi possiede un Mac sa benissimo che il proprio sistema funziona a dovere e che prima di istallare aggiornamenti al di fuori dei metodi automatici e tradizionali bisogna informarsi in quanto si può rischiare qualche sorpresa.

Spiegheremo ora come rimuovere questo malware denominato Flashback, ma prima di farlo vi proporrò ancora una volta la differenza tra Virus informatico  e malware.

Riprendendo un vecchio articolo di youtek.it (http://youtek.it/differenza-tra-virus-e-malware/)  cerchiamo di capire le differenze , che a volte sembrano dei veri e propri rompicapo dei tecnici;

Cos’è un virus?

E’ un frammento di software, che una volta avviato infetta file,cartelle, registro di sistema insomma tutto cio’ che trova sul nostro pc! Ovviamente piu’ e’ potente il virus piu’ danni causa.

Spesso quelli di alta’ pericolosita’ sono difficilmente rintracciabili dall’utente.

Cos’è un Malware?

E’ un qualsiasi software creato per danneggiare un computer o un sistema informatico. Dove esso puo’ causare vari danni di varie identita’. Non a caso il nome MALWARE che significa letteralmente “Programma Malvagio” o piu’ corretto chiamarlo Codice Maligno.

Cio’ che non mi piace è che molti autorevoli testate giornalistiche hanno aperto la sezione tecnologia con titoli e sottotitoli che inneggiavano al fatto che Apple avesse un virus, che avesse perso la verginità e che addirittura questo suddetto virus fosse pericolosissimo.

Risulta totalmente inutile cercare di capire il motivo di tanta superficialità, ignoranza e poca innocenza da parte di quei giornalisti che, senza pudore, scrivono di cose si cui non capiscono quasi nulla o peggio hanno solo voglia di confondere le idee , già peraltro confuse, dei tanti lettori che si definiscono non tecnici.

La verità e la decenza

Ovviamente la verità non è a disposizione di tutti ma cercherò comunque di definire l’argomento e di spiegare come rimuovere questo malware.

L’allarme infezione viene lanciato da Dr. Web, un’azienda russa di antivirus, e prontamente Apple ha già rilasciato il codice (patch) per evitare di incappare in questo pericolo poiché Flashback viene istallato nel sistema utilizzando una vulnerabilità Java dei browser internet Safari camuffandosi da estensione per Flash che viene chiesto di istallare.

Per evitare che il proprio mac sia esposto a rischi, è necessario installare quanto prima la patch Java proposta da Apple.

Queste le note di rilascio da Cupertino:

Java per Mac OS X 2012-001 fornisce una migliore compatibilità, sicurezza e affidabilità aggiornando Java SE 6 alla versione 1.6.0_31.

Chiudi tutti i browser e le applicazioni Java prima di installare questo aggiornamento.

Consulta: http://support.apple.com/kb/HT5055?viewlocale=it_IT  per ulteriori dettagli su questo aggiornamento.

Consulta: http://support.apple.com/kb/HT1222?viewlocale=it_IT  per informazioni sul contenuto di sicurezza di questo aggiornamento.

oppure

e’ stata rilasciata un’ applicazione  di terze parti che, vi permette in due fasi il controllo:

1. Scaricate FlashbackChecker – Download -
2. Decomprimere ed eseguire l’applicazione FlashbackChecker e cliccate sul pulsante “Check for Infection Flashback”

Se viene visualizzata la voce “No Signs of infection were found”(Nessuna infezione è stata trovata) significa che le probabilità che il vostro Mac sia infetto sono bassissime. Se invece appare un messaggio “Potential Issue found” (Trovato Potenziale problema) il vostro Mac potrebbe essere infetto.

Rimozione Manuale

Di seguito riportiamo rimozione del malware come redatta da F-Secure.

1 – Aprire il terminale e digitare “defaults read /Applications/Safari.app/Contents/Info LSEnvironment”
2 – Prendere nota dei codici DYLD_INSERT_LIBRARIES e premere nuovamente invio
3 – Se si riceve un messaggio d’errore simile a “The domain/default pair of (/Applications/Safari.app/Contents/Info, LSEnvironment) does not exist” non si è infetti.
4 – Se i file vengono effettivamente trovati, digitare “grep -a -o ‘__ldpath__[ -~]*’ %percorso_del_punto_2% ” e prendere nota del valore di fianco a “__ldpath__”
5 – Eseguire i comandi “sudo defaults delete /Applications/Safari.app/Contents/Info LSEnvironment” e “sudo chmod 644 /Applications/Safari.app/Contents/Info.plist”, cancellando poi i file trovati nel secondo punto e nel quarto.
6 – Eseguire il comando “defaults read ~/.MacOSX/environment DYLD_INSERT_LIBRARIES” e, se si riceve un messaggio come “The domain/default pair of (/Users/joe/.MacOSX/environment, DYLD_INSERT_LIBRARIES) does not exist” il trojan è stato correttamente rimosso. In caso contrario, eseguire nuovamente “grep -a -o ‘__ldpath__[ -~]*’ %percorso_del_punto 4% “, prendendo nota dei valori.
7 – Dopo aver eseguito “defaults delete ~/.MacOSX/environment DYLD_INSERT_LIBRARIES launchctl unsetenv DYLD_INSERT_LIBRARIES”, cancellare i file indicati nei punti precedenti.

Scheda del Malware 

Come riportato da F-Secure il malware viene definito come trojan (cavallo di troia)

Detection Names:Trojan-Downloader:OSX/Flashback.K

Category :Malware
Type:Trojan-Downloader
Platform:OSX

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

Il costo di un' App per iPhone & iPad

Riportiamo la traduzione integrale dell’articolo Dear business people, an iOS app actually takes a lot of work!, scritto da Kent Nguyen che ringraziamo per averci concesso il permesso.

This is the italian translation of the article Dear business people, an iOS app actually takes a lot of work!, written by Kent Nguyen. Thanks Kent for giving us permission to publish this translated article.

Il grande quesito: quanto costa un’app per iPhone?

Questa è una domanda estremamente comune che viene sempre chiesta da un sacco di persone che lavorano nel mondo degli affari oppure da clienti non molto esperti di tecnologia. Senza dubbio, ogni volta che ho fornito una stima iniziale prima ancora di formalizzare e analizzare in dettaglio le specifiche, ho potuto vedere sui loro volti l’espressione di shock a causa della inaspettatamente alta quotazione.

Inoltre nessuna delle mie quotazioni si è lontanamente avvicinata ai valori discussi in, nel quale vengono discussi i costi di sviluppo dell’app Twitterific. Nonostante il fatto che la domanda originale fosse stata posta nel 2008 e la migliore risposta (da uno degli sviluppatori di Twitterific) fosse arrivata nel 2010, è ancora molto precisa all’inizio del 2012 ed è facile prevedere che lo sarà almeno fino alla fine dell’anno.

Cosí, con il crescere del numero di imprese che desiderano avere un’app per iOS, penso che sia una buona idea spiegare perché i costi siano effettivamente alti cercando di dividere i vari passi e spiegare le variabili coinvolte. Spero che questo articolo sia di beneficio per i non sviluppatori e gli uomini d’affari che devono prendere delle decisioni o semplicemente vogliono comprendere il processo. Le idee in questo articolo ovviamente non sono ristrette al solo mondo iOS ma possono essere estese ad altre piattaforme (Android, Windows Mobile, forse Blackberry).

Checklist: prepararsi ad un’app per iPhone

Il procedimento non è affatto semplice e cerco innanzitutto di informare il cliente a fare tutte le considerazioni guidandolo attraverso questi passi:

PRIMO: Una delle maggiori scoperte che ottengo parlando con i clienti è quanto siano inconsapevoli delle grande infrastruttura necessaria per un’app per iPhone. Dato che essi assumono che un’app sia semplicemente un’app, si aspettano che gli venga fornito il prezzo di fare qualunque cosa con l’app senza tener conto di problematiche quali: avere un server di supporto col quale l’iPhone comunichi, dove immagazzinare i dati dell’utente. La prima volta che incontrai un tale cliente ero furioso ma in seguito ho realizzato il fatto che il concetto di client-server non deve essere dato per scontato tra i non programmatori. Avevo sbagliato, i manager di solito non hanno il senso-tecnico comune che noi programmatori ci attendiamo.

Perciò, cari lettori non tecnici: è necessario che disponiate di un server nel quale memorizzare i dati per qualunque tipo di app che come minimo debba fare qualche autenticazione (login) o qualunque tipo di personalizzazione che volete cambiare in seugito o comunque qualunque operazione che richieda il recepimento di informazioni dall’utente (sto cercando di usare il linguaggio il più semplice possibile).

SECONDO: Dato che avete bisogno di un server, bisogna fare in modo che l’iPhone possa comunicare con tale server, inviando e ricevendo dati. Non esiste una maniera standard, non esiste nessun componente plug-and-play per fare questo, ogni cosa va customizzata. Questo è analogo a creare il vostro linguaggio personalizzato: non volete che gli altri comprendano ciò che state dicendo ma le due estremità, telefono e server, devono capirsi.

Questo processo consiste nella creazione di API (Application Programming Interface) per la vostra app. Queste API devono esistere prima che si proceda con lo sviluppo dell’app. Perché? perché prima di cominciare a comunicare occorre definire il linguaggio! Questo ci porta al prossimo passo, come creare queste API.

TERZO: Non prendere questo passo alla leggera, le API hanno un’importanza pari al 50% dell’intera soluzione. Fare un’API è come mettere in piedi un sito web. Prima devi definire i dati, quindi la logica di business, quali sono i parametri di ingresso a tale logica, come interagiscono fra loro i vari moduli quando accade un evento. Per semplificare, il risultato finale è un sito web completo dove però le pagine non mostrano risultati grafici ma solamente del testo che verrà compreso dalla nostra app: ad esempio una pagina di autenticazione conterrà, in caso di successo, la semplice parola YES.

L’iPhone quindi farà una serie di richieste a questi punti terminali predefiniti (pagina di login) usando il formato di ingresso predefinito dall’API (nome utente + password) e quindi interpreterà il risultato fornito da queste pagine in risposta alla sua richiesta (YES/NO). L’app senza questo non potrà mai registrarsi e fare il login magicamente da sola.

Ci sono *un sacco* di variabili che devono essere prese in considerazione in questa fase, come preparare un server, selezionare il linguaggio di programmazione con cui scrivere le API, dove immagazzinare i dati per minimizzare i tempi di comunicazione, ecc.

QUARTO: Queste API o sono già pronte e ben documentate dal vostro team interno per essere fornite allo sviluppatore iPhone oppure preparatevi a pagare di più che solo per la pura app. In funzione delle conoscenze dello sviluppatore che avrete contattato per farvi l’app, egli/ella potrebbe avere o meno le capacità per fare ciò di cui avete bisogno. Se lo sviluppatore è in grado di fare questo lavoro, allora vi consiglio fortemente di affidargli anche questa parte del progetto dato che egli sa esattamente quali API servono per far funzionare l’app al meglio.

Nel caso abbiate già le API dovrete dare allo sviluppatore la possibilità di parlare apertamente e liberamente con il vostro team di back-end e non limitarvi a dargli la documentazione; questo perché il più delle volte egli richiederà che venga fatto del lavoro in più (più API) per supportare l’applicazione mobile in maniera appropriata.

Adesso, la parte iPhone

Caspita, tutto questo per essere appena pronti a sviluppare l’app e non siamo ancora partiti! In generale, qualunque cosa riguardo iOS è molto restrittiva. Dovete quasi sempre aver definito circa il 100% dello scopo e del design prima che lo sviluppatore possa partire con la programmazione; diversamente dallo sviluppo di siti web, lo sviluppo di un’app per iOS sotto contratto ha pochissimi margini di cambiamento:

Disegnare l’interfaccia: La scelta se si devono utilizzare i componenti grafici standard o personalizzati deve essere presa già dall’inizio, dato che l’architettura dell’intera app dipende da come si vuole l’interfaccia e da come la utilizzeranno gli utenti.Un esempio è la Tab Bar in basso: se si vogliono i bottoncini colorati invece di quelli monocromatici standard, la modifica al codice è sostanziale!

Il codice è fortemente integrato: Con i siti web voi potete aggiungere semplicemente una pagina in più, quindi create un link a quella pagina ove richiesto. Non potete fare questo con un’app per iOS, dato che ogni cosa va decisa all’inizio e ogni cambiamento può risultare in cambiamenti significativi in altre parti dell’app. Il modo in cui il codice iOS è strutturato è come quello di una breadboard (le basette sperimentali per circuiti elettrici), dove ogni cosa è collegata con fili: voi potete sempre cambiare delle cose qui e là ma se tocchi il filo sbagliato allora l’intero circuito smetterà di funzionare. Anche se viene usato del codice estremamente ben strutturato la flessibilità non aumenterà molto. L’aggiunta di un bottone email addizionale nella schermata “About” potrebbe richiedere un ridotto numero di linee di codice addizionali, ma l’aggiunto di un bottone “Facebook Like” sulla stessa pagina è una cosa completamente differente e non ci può attendere che venga fatto in poche ore.

Convertire un’app per iPhone in un’app iPhone/iPad universale: Questa è la peggiore ‘funzionalità aggiuntiva’ presente nei contratti di sviluppo di app per iPhone. Questo perché un’app per iPad non è una banale funzionalità aggiuntiva. Le app per iPad sono di solito molto più complesse delle app per iPhone e il più delle volte sono richiesti un’interfaccia e un meccanismo di interazione completamente differenti. Non solo quello, dato che anche le API potrebbero essere diverse: l’app Denso, che ho sviluppato (e quindi conosco), ha alcune funzionalità esclusive dell’app per iPad che richiedono dati addizionali dal server. Inoltre l’iPhone e l’iPad richiedono esperienze utente differenti.

Dunque siete pronti a partire?

Spero che dopo aver letto questo abbiate un’idea più chiara di quel che è necessario alla vostra ditta per sviluppare un’app per il mondo mobile. A meno che non facciate un’app completamente offline (come una Calcolatrice!) che non raccoglie dati dagli utenti, non potrete pretendere che questa vi venga sviluppata a un prezzo basso. Dopo aver considerato le variabili elencate sopra, se non potrete giustificare lo sviluppo a contratto allora l’altra opzione è assumere a tempo determinato dei progettisti a tempo pieno che lavorino a tempo pieno per l’intera durata del progetto.

D’altro canto, se decidete di andare avanti e affidare in outsourcing il lavoro, c’e’ un’altra cosa da aggiungere: le lungaggini burocratiche. Se lavorate in una grande azienda o in un ambiente molto regolamentato, il vostro lavoro sarà essenzialmente di aiutare lo sviluppatore ad evitare le lungaggini burocratiche che potrebbe incontrare lungo la strada e talvolta avrete necessità di aggirare un pochino le regole. Ho parlato con molti clienti e ho potuto notare il loro scetticismo quando ho cercato di saperne di più sulle loro API, dato che essi o non desideravano esporsi maggiormente per non violare le loro regole di segretezza, e non potevo biasimarli, oppure non possono portare certi dati al di fuori del perimetro aziendale, oppure semplicemente (e questa è la cosa peggiore) le regole di branding aziendale richiedono che ogni singola pagina dell’app presenti il logo dell’azienda (!!!). Alla fine ho preferito non lavorare con questi clienti dato che non potevo immaginare quando a lungo avrei penato per ottenere anche un minimo supporto sulle API di cui avrei avuto bisogno.

P.S. Avrete bisogno di tempo, un sacco, per cui siate pazienti.

• 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.

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)

Android 4  caratteristiche, funzioni, differenze e novità del nuovo OS Google.

Presentato con nome in codice “Ice Cream Sandwich“, il nuovo Os mobile Android 4.0 presenta importanti novità.
Con questa versione google ha operato una revisione non totale dell’interfaccia e del multitasking, rispetto alla precedente Honeycomb.

Lo scope degli sviluppatori di Android 4.0 appare quindi quello di rendere più facile, immediato ed intuitivo l’uso dei cellulari e tablet Android rendendo il loro utilizzo ad una esperienza di uso più simile all’ iOS di iPhone e iPad. Siamo quindi propensi a credere che Google stia continuando a seguire Apple, ma con un certo distacco.

Ora vediamo le principale caratteristiche dal punto di vista degli utilizzatori (users), nel prossimo articolo esamineremo il punto di vista degli sviluppatori (developers).

Android 4.0 per utenti

Android 4,0 si basa su quegli aspetti che la gente ama: il  multitasking facile, le notifiche arricchite, home screen personalizzabile, widget ridimensionabili, e l’interattività . Questa versione aggiunge potenti nuovi modi per comunicare e condividere.

Interfaccia utente raffinata ed evoluta
Android 4.0 permette agli utenti di navigare con gesti semplici e intuitivi e presenta animazioni raffinate con un carattere completamente nuovo ottimizzato per schermi ad alta risoluzione che migliora la leggibilità assieme ad un brillante aspetto moderno per l’interfaccia utente.

I Pulsanti virtuali nella barra di sistema consentono agli utenti di navigare istantaneamente :  Back, Home e applicazioni recenti. La barra di sistema e tasti virtuali sono presenti in tutte le applicazioni, ma possono essere oscurati dalle applicazioni per la visualizzazione a schermo intero. Gli utenti possono accedere alle opzioni contestuali di ogni applicazione nella barra delle operazioni, visualizzata nella parte superiore (e talvolta anche nella parte inferiore) dello schermo.

Il multitasking è un punto di forza di Android ed è reso ancora più semplice e naturale su Android 4.0. Il pulsante  “applicazioni recenti” consente agli utenti di passare istantaneamente da un task all’altro utilizzando l’elenco nella barra di sistema. La lista si apre per mostrare le immagini in miniatura delle applicazioni utilizzate di recente – toccando una miniatura si passa all’ app.

le “Rich and interactive notifications” permettono agli utenti di tenersi in contatto costante con i messaggi in arrivo, riprodurre brani musicali, vedere gli aggiornamenti dalle applicazioni in tempo reale , e molto altro. Sui dispositivi più piccoli, le notifiche vengono visualizzate nella parte superiore dello schermo, mentre sul grande schermo dei dispositivi appaiono nella barra di sistema.
All Apps launcher (a sinistra) e widget ridimensionabili (a destra) vi daranno accesso alle applicazioni e contenuti multimediali direttamente dalla schermata principale.

Home screen folders e favoriti
Nuove cartelle nella schermata iniziale offrono un nuovo modo di raggruppare le proppie applicazioni e gli shortcut logici, baterà solo trascinarne una su un altra. Inoltre, in tutti gli Apps launcher , gli utenti possono semplicemente trascinare un app per avere informazioni su di essa o disinstallare o disattivare un app pre-installata .

Per dispositivi più piccoli la schermata iniziale ora include un vassoio personalizzabile di preferiti. Gli utenti possono trascinare applicazioni, collegamenti, cartelle e altri elementi prioritari dentro o fuori del “favorites tray” per l’accesso immediato da qualsiasi schermata iniziale.

Widget ridimensionabile
Le schermate Home in Android 4.0 sono progettate per essere ricche di contenuti e personalizzabili. Gli utenti possono incorporare contenuti live di applicazione direttamente tramite widget interattivi. I Widget consentono agli utenti di controllare la posta elettronica, sfogliare un calendario, ascoltare musica, controllare i social networks, e altro – direttamente dalla schermata iniziale, senza dover lanciare le applicazioni. I widget sono ridimensionabili, così gli utenti possono espandere per visualizzare più contenuti o ridurle per risparmiare spazio.

New lock screen actions
Il blocco schermo ora consente agli utenti di fare di più azioni senza sbloccare. Dalla schermata di blocco a scorrimento, gli utenti possono saltare direttamente alla fotocamera per una foto o tirare giù la finestra per controllare le notifiche e per i messaggi. Durante l’ascolto di musica, gli utenti possono anche gestire brani musicali e vedere le copertine degli album.

Risposte rapide per le chiamate in arrivo
Quando arriva una chiamata, gli utenti possono ora rispondere rapidamente tramite SMS, senza la necessità di rispondere alla chiamata o sbloccare il dispositivo. Nella schermata di chiamata in arrivo, gli utenti devono semplicemente far scorrere un controllo per visualizzare un elenco di risposte testo e poi toccare per inviare e terminare la chiamata. .

Swipe per respingere le notifiche, le attività e le schede del browser
Android 4.0 consente la gestione delle notifiche, delle applicazioni recenti e le schede del browser con un metodo ancora più facile. Gli utenti possono ora licenziare le notifiche individuali, le applicazioni dalla lista delle Apps recenti , e le schede del browser con un semplice tocco di un dito.
Un correttore ortografico permette di trovare gli errori e correggerli rapidamente.
Un potente motore di input vocale consente di dettare in modo continuo.

Inserimento di testo migliorato e il controllo ortografico
La tastiera in Android 4.0 rende l’immissione di testo ancora più veloce e più accurata. La correzione degli errori e il suggerimento delle parole sono migliorati attraverso una nuova serie di dizionari predefiniti e una più accurata gestione euristica , come doppio caratteri digitati, salto di lettere e spazi. Il Suggerimento delle parole è migliorato e la striscia di suggerimento è stata semplificata per visualizzare solo tre parole alla volta.

Per correggere più facilmente le parole errate, Android 4.0 aggiunge un correttore ortografico che individua e sottolinea gli errori e suggerisce le parole in sostituzione. Con un solo tocco, gli utenti possono scegliere tra molteplici suggerimenti ortografici, eliminare una parola, o aggiungerla al dizionario. Gli utenti possono persino toccare per vedere i suggerimenti di sostituzione per le parole che sono state digitate correttamente. Per le funzioni specialistiche o in altre lingue, gli utenti possono ora scaricare e installare dizionari di terze parti , spell-checker, e altri servizi di testo.

Potente motore di riconoscimento vocale
Android 4.0 introduce un nuovo e potente motore di input vocale, che offre un ‘esperienza a “microfono aperto” con il riconoscimento vocale in streaming. Il nuovo motore di input vocale consente agli utenti di dettare il testo, per tutto il tempo che si desidera, usando il linguaggio naturale. Gli utenti possono parlare ininterrottamente per un tempo prolungato, anche con pause per gli intervalli, se necessario, e dettare la punteggiatura per creare frasi corrette. Mentre il motore entra in input vocale del testo, sottolinea gli errori di dettatura in grigio. Dopo la dettatura, gli utenti possono selezionare le parole sottolineate per sostituire rapidamente da un elenco di suggerimenti.

Controllo sui dati di rete
I dispositivi mobili possono fare ampio uso di dati di rete per lo streaming di contenuti, la sincronizzazione dei dati, il download di applicazioni e altro ancora. Per soddisfare le esigenze degli utenti, Android 4.0 aggiunge nuovi controlli per gestire l’utilizzo della rete dati.

Nelle Impostazioni, grafici colorati mostrano il consumo totale di dati su ogni tipo di rete (mobile o Wi-Fi), così come quantità di dati utilizzati da ciascuna applicazione in esecuzione. Sulla base dei loro piani dati, gli utenti possono facoltativamente impostare i livelli di allarme o limiti sull’utilizzo dei dati o disabilitare del tutto i dati mobili. Gli utenti possono anche gestire i dati di base utilizzati dalle singole applicazioni, se necessario.

Progettato per l’accessibilità
Una varietà di nuove caratteristiche  migliorano notevolmente l’accessibilità di Android 4.0 per utenti non vedenti o ipovedenti. Più importante è una nuova modalità by-touch che permette agli utenti di navigare senza dover vedere lo schermo. Toccando lo schermo si innesca una volta un feedback acustico che identifica il componente UI sotto; un secondo tocco della componente  attiva un evento full touch. La nuova modalità è particolarmente importante per supportare gli utenti sui nuovi dispositivi che utilizzano i pulsanti virtuali nella barra di sistema, piuttosto che pulsanti hardware dedicati o trackball. Inoltre, le applicazioni standard sono aggiornate per offrire una migliore esperienza di accessibilità. Il browser supporta uno script basato su screen reader per la lettura di contenuti Web preferiti e navigare i siti. Per migliorare la leggibilità, gli utenti possono anche aumentare la dimensione del carattere predefinito utilizzato in tutto il sistema.

Persone e profili
Tutto il sistema, i social groups di un utente, i profili ei contatti sono collegati tra loro e integrati per una facile accessibilità. Al centro vi è una nuova applicazione “Persone” che offre informazioni sul profilo più ricche, tra cui una foto del profilo di grandi dimensioni, numeri di telefono, indirizzi e account, aggiornamenti di stato, eventi, e un nuovo pulsante per la connessione su social network integrati .

Le informazioni di contatto personali dell’utente vengono memorizzate in un nuovo profilo “Me”, che facilita la condivisione di applicazioni e persone. Tutti i contatti integrati dell’utente vengono visualizzati in una lista di facile gestione, compresi i controlli su cui vengono visualizzati i contatti da un account integrato o social network. Ovunque l’utente naviga attraverso il sistema, toccando una foto del profilo vengono mostrati i Contatti rapidi, con immagini del profilo di grandi dimensioni, i collegamenti ai numeri di telefono, messaggi di testo e altro ancora.

Unified calendar, Visual Voicemail
Per aiutare ad organizzare appuntamenti ed eventi, un app Calendario aggiornata riunisce gli appuntamenti personali, lavoro, scuola, agende e social. Con il permesso degli utenti, altre applicazioni possono contribuire agli eventi del calendario e gestire i promemoria, per una visione integrata tra diverse versioni di calendario realizzate da terze parti. L’applicazione è stata riprogettata per consentire agli utenti di gestire gli eventi più facilmente. I calendari sono colorati e gli utenti possono scorrere a sinistra o a destra ,  cambiare date e “pizzicare” per ingrandire o ridurre l’ordine del giorno.

Nell’ app Telefono, la nuova funzionalità Visual Voicemail integra i messaggi in arrivo, voce, trascrizioni e file audio da uno o più provider. Le applicazioni di terze parti in grado di integrare con l’applicazione Phone possono aggiungere i loro messaggi vocali , trascrizioni, e altro nella la casella di posta vocale visiva.

Funzionalità per fotocamera ricca e versatile
L’applicazione fotocamera include molte nuove funzionalità che consentono agli utenti di catturare momenti speciali con grandi foto e video. Dopo l’acquisizione di immagini, si possono modificare e condividere facilmente con friemds.

Quando si scattano foto, la messa a fuoco è continua, zero ritardo allo scatto, e una diminuzione shot-to-shot contribuisce ad accelerare la cattura d’immagini chiare e precise. Lo Zoom con stabilizzazione delle immagini consente agli utenti di comporre foto e video nel modo che desiderano, anche mentre il video è la registrazione. Per la nuova flessibilità e praticità, mentre si eseguono riprese video, gli utenti possono scattare fotografie con risoluzione video full semplicemente toccando lo schermo mentre il video continua a registrare.

Per rendere più semplice scattare belle foto di persone, e’ integrata la Face Detection che individua i visi presenti nell’inquadratura e imposta automaticamente la messa a fuoco. Per un maggiore controllo, gli utenti possono toccare per concentrare in qualsiasi punto dell’immagine di anteprima.

Per l’acquisizione di grandi scene con la telecamera viene introdotto un unico movimento in modalità panorama. In questa modalità, l’utente inizia l’esposizione e poi gira lentamente la fotocamera a comprendere la più ampia prospettiva. La telecamera raccoglie l’intera gamma di immagini in continuo in una singola foto panoramica.

Dopo aver scattato una foto o girato un video, gli utenti possono rapidamente condividerlo via e-mail, sms, bluetooth, reti sociali, e altro ancora, semplicemente toccando l’anteprima nei controlli della fotocamera.

App Gallery ridisegnato con photo editor
L’applicazione Gallery rende ora più semplice da gestire, visualizzare e condividere foto e video. Per la gestione di collezioni, un layout ridisegnato album mostra molti album e offre grandi anteprime.  Per far apparire al meglio le immagini, la Galleria ora include un potente editor di foto. Gli utenti possono ritagliare e ruotare le immagini, i livelli di impostare, rimuovere gli occhi rossi, aggiungere effetti e molto altro ancora. Dopo il ritocco, gli utenti possono selezionare una o più immagini o video da condividere istantaneamente via email, sms, bluetooth, reti sociali, o altre applicazioni.

Una migliore widget di Pinacoteca consente agli utenti di guardare le immagini direttamente sullo schermo a casa. Il widget è in grado di visualizzare immagini da un album selezionato, le foto casuale da tutti gli album, o mostrare una sola immagine. Dopo aver aggiunto il widget alla schermata iniziale, gli utenti possono sfogliare le pile foto per individuare l’immagine che vogliono, quindi toccare per caricarla nella Galleria.

Live Effects per trasformare il video
Live Effects (Effetti dal vivo) è un insieme di trasformazioni grafiche che aggiungono interesse e divertimento ai video catturati con l’app Fotocamera. Per esempio, gli utenti possono modificare lo sfondo dietro qualsiasi titolo o un’immagine personalizzata, solo per il giusto assetto durante le riprese video. Disponibile  per il video è Faces Silly, una serie di effetti di morphing che l’uso del riconoscimento facciale e filtri GPU per trasformare i tratti del viso. Ad esempio, è possibile utilizzare effetti come occhi piccoli, bocca grande, naso grande, spremere viso e altro ancora. Al di fuori dell’app Fotocamera,  Live Effects è disponibile durante la video chat in app di Google Talk.

Condivisione con gli screenshot
Gli utenti possono ora condividere ciò che hanno sui loro schermi più facilmente prendendo screenshot. Un Pulsante  fa scattare uno screenshot e lo memorizzarla localmente. In seguito, si possono visualizzare, modificare e condividere la schermata in Galleria o un’applicazione simile.

Esperienza Cloud-connected
Il menu del browser schede (a sinistra) consente di passare rapidamente le schede del browser. Il menu delle opzioni (a destra) vi offre nuovi modi per gestire la navigazione.

Android è sempre stato cloud-connected, consentendo agli utenti di sfogliare le foto e la sincronizzazione Web, applicazioni, giochi, e-mail e contatti – ovunque si trovino e attraverso tutti i loro dispositivi. Android 4.0 aggiunge nuove funzionalità di navigazione e posta elettronica per consentire agli utenti di prendere ancora di più con loro e mantenere la comunicazione organizzata.

Navigazione sul web potente
Il browser Android offre una esperienza che è così ricca e conveniente come un browser desktop. Si consente agli utenti di sincronizzare istantaneamente e gestire i segnalibri di Google Chrome da tutti i loro account, salta i propri contenuti preferiti velocemente, e li salva per la lettura in seguito nel caso in cui non ci sia rete disponibile.

Per ottenere il massimo di contenuti web, gli utenti possono ora richiedere le versioni desktop di siti web, piuttosto che la loro versione mobile. Gli utenti possono impostare la loro preferenza per i siti web separatamente per ogni scheda del browser. Per i più contenuti, gli utenti possono salvare una copia per la lettura offline. Per trovare e aprire le pagine salvate, gli utenti possono sfogliare un elenco visivo che è incluso con i segnalibri del browser e la storia. Per una migliore leggibilità e accessibilità, gli utenti possono aumentare i livelli di zoom del browser e ignorare le dimensioni di testo predefinito di sistema.

In tutti i tipi di contenuto, il browser Android offre migliorameni sostanziali sulle prestazioni di rendering delle pagine attraverso le versioni aggiornate del WebKit core and the V8 Crankshaft compilation engine for JavaScript. Nel benchmark eseguiti su dispositivo un Nexus S, il browser Android 4,0 hanno mostrato un miglioramento di quasi il 220% rispetto al browser di Android 2,3 nella suite di benchmark V8 e più del 35% nel benchmark SunSpider 9,1 JavaScript. Quando questo viene eseguito su un dispositivo Galaxy Nexus, il browser Android 4,0 ha mostrato un miglioramento di quasi il 550% nel benchmark V8 e quasi il 70% nel benchmark SunSpider.

E-mail migliorata
In Android 4.0, è più facile da inviare e-mail , leggerle e gestirle. Per la composizione di e-mail, il miglioramento auto-completamento dei destinatari aiuta a trovare e aggiungere i contatti frequenti più rapidamente. Per facilitare l’immissione di testo frequente, gli utenti possono ora creare risposte rapide e memorizzarle in app, poi entrare da un comodo menu durante la composizione. Quando si risponde a un messaggio, gli utenti possono ora passare il messaggio Rispondi a tutti e avanti senza cambiare schermata.

Per facilitare la navigazione tra i conti e le etichette, l’applicazione aggiunge un menu integrato di conti ed etichette recente. Per aiutare gli utenti a individuare e organizzare IMAP e-mail di Exchange, l’applicazione e-mail ora supporta le sottocartelle di posta annidate, ognuno con le regole di sincronizzazione. Gli utenti possono anche cercare tra le cartelle del server, per risultati più rapidi.

Per le imprese, l’applicazione e-mail supporta EAS V14. Supporta l’autenticazione dei certificati EAS, fornisce stringhe ABQ per tipo di dispositivo e la modalità, e permette la sincronizzazione automatica di essere disabilitata durante il roaming. Gli amministratori possono anche limitare le dimensioni degli allegati o disabilitare gli allegati stessi.

Per tenere traccia delle e-mail in arrivo, un widget ridimensionabile  permette agli utenti di sfogliare email recenti dalla schermata iniziale, poi saltate in app-mail per comporre o rispondere.

Android Beam NFC-based per la condivisione
Android Beam è un  caratteristica innovativa, utile per la condivisione tra due dispositivi abilitati alla tecnologia NFC, che consente alle persone di scambiarsi istantaneamente le applicazioni preferite, contatti, musica, video – ovvero quasi tutto. E ‘ semplice e comodo da usare – non c’è nessun menu per aprire, per lanciare l’applicazione, o per accoppiamento necessario. Basta toccare un telefono Android-powered  con un altro, quindi toccare da inviare.

Sblocca faccia
Android 4.0 introduce un approccio completamente nuovo per garantire un dispositivo, rendendo il dispositivo di ogni persona ancora più personale – Sblocca Face è un nuovo screen-lock opzione che consente agli utenti di sbloccare i dispositivi con i loro volti. Si avvale del dispositivo fotocamera frontale e state-of-the-art tecnologia di riconoscimento facciale per registrare un viso durante l’installazione e poi di riconoscere di nuovo quando lo sblocco del dispositivo. Gli utenti basta tenere i loro dispositivi di fronte a loro facce da sbloccare, o utilizzare un codice PIN di backup o un pattern.

Wi-Fi e Bluetooth diretto HDP
Il supporto per Wi-Fi Direct permette agli utenti di collegarsi direttamente a dispositivi vicini via Wi-Fi. Nessuna connessione Internet o tethering è necessario. Attraverso le applicazioni di terze parti, gli utenti possono connettersi a dispositivi compatibili e di sfruttare nuove funzionalità come la condivisione istantanea dei file, foto o altri media, lo streaming video o audio da un altro dispositivo, oppure il collegamento a stampanti compatibili o altri dispositivi.

Android 4.0 introduce anche il supporto integrato per il collegamento al Device Profile Health Bluetooth (HDP). Con il supporto di applicazioni di terze parti, gli utenti possono connettersi senza fili a dispositivi medici e sensori di ospedali, centri fitness, case, e altrove. Inoltre, per il collegamento a dispositivi Bluetooth una qualità audio superiore, Android 4.0 aggiunge il supporto per il profilo Bluetooth Hands Free (HFP) 1.6.

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

• English

No virus

Probabilmente alcune software house che producono Anti-virus o Anti-malware cercano di ri-lanciare la notizia di un pericoloso Virus trovato, finalmente, anche per Mac.
Un  centro di ricerca, che qualche quotidiano sostiene di aver contattato, dichiara di aver scovato un Virus proprio per quei sistemi operativi, Mac OSX o Linux, che per loro natura sono immuni da questi sofisticati software virulenti che sfruttano le carateristiche di insicurezza insite nella progettazione di alcuni sistemi operativi.
Sappiamo che Steve Jobs  aveva chiesto a tutti i suoi ingegneri di progettare un sistema operativo (OSX) basandosi sulle caratteristiche dei sistemi Unix/Linux che hanno un radicato un modello di gestione dei permessi di scrittura/lettura ed esecuzione di ogni componente software presente sulla memoria.

In questi giorni nei quotidiani di tutto il mondo, come nelle pagine web di alcuni produttori di Antivirus, viene  pubblicata la notizia relativa alla scoperta di un Virus Malizioso denominato “OSX.Tsunami” che progettato per sistemi Linux starebbe infettando anche il mondo Apple.

Scrivo questo articolo sopratutto in rispetto degli ingegneri Apple che hanno lavorato assiduamente proprio per fornirci un sistema operativo che non si infetta a differenza degli altri sistemi distribuiti su i tanti Pc.

Infatti il cosidetto OSX.Tsunami  non puo’ essere considerato un Virus, ma è un codice che viene classificato come Trojan di Risk Level:1 Very Low (Rischio molto basso)

Vedimo ora come debellarlo senza spendere nulla, con un semplice passo visto che questo “Cavallo Troiano” sfrutta le oramai note pericolosita’ dei canali IRC e dei quali pochi utenti Mac fanno uso.

Sebbene girando per la rete si leggano sedicenti giornalisti ed esperti che consigliano di “stare in campana” e suggeriscono di acquistare questo o quell’antivirus, ritengo che istallare un’antivirus su un sistema Mac sia pressochè inutile, a meno di stallarlo pel solo fatto di poter verificare se alcuni files posseggono dei virus per sistemi Winows e che comunque non avrebbero alcun effetto sul nostro sistema Apple ma che potrebbero infettare un eventuale Pc collegato allo stesso network.

Vediamo quindi come Symantec , una tra le piu’ note aziende di antivirus, classifica questa minaccia Tsunami:

OSX.Tsunami