Rivista della provincia di Milano

La Provincia in Casa ha scelto di entrare nel mercato mobile e tablet con i3Factory utilizzando il sistema editoriale i3F Editorial, una soluzione tecnologicamente all’avanguardia senza alcun costo di gestione. La tecnologia avanzata di i3F Editorial permette agli editori di pubblicare nuovi numeri della rivista o magazine senza alcun costo. Appare incredibile ma è vero.

La versione per i dispositivi iOS Apple, tutti gli iPhone e iPod Touch (iPhone 3, iPhone5, iPhone 5) e iPad (iPad 3 Retina, iPad 4 Retina, iPad 1, iPad2) la trovate al seguente link:

https://itunes.apple.com/it/app/la-provincia-in-casa/id606239216?mt=8

La versione Android per tutti gli smartphone e tablet android (Samsung , Kindle, Sony, Asus, etc..):

https://play.google.com/store/apps/details?id=org.imaginor (GOOGLE PLAY- Android Market)

http://www.amazon.com/Provincia-Casa-Milano-italian-Magazine/dp/B00BUL9THS (Amazon App Store – Kindle fire)

iPhone5 ha uno schermo più grande rispetto ai suoi precedessori. Gli sviluppatori di iOS6 devono supportare risoluzioni di 640 x 1136 px al posto di 640 x 960 px dell’iPhone4.
Ma anche in questo caso se si segue la logica Apple il lavoro da fare non è per nulla complicato.

Il blog http://blog.mugunthkumar.com/coding/supporting-the-iphone-5/ propone di seguire quattro fasi:

Fase 1:

iPhone 5 richiede un nuovo set di istruzioni, le armv7s. Solo nell’ultima versione Xcode ( 4.5) supporta la generazione del set istruzioni armv7s. Doa notare che, Xcode 4,5 non supporta più armv6 e depreca iPhone 3G e i dispositivi più vecchi. Quindi bisogna ora sviluppare le nostre applicazione utilizzando Xcode 4,5

Fase 2:

Il passo successivo è quello di aggiungere una immagine di lancio (Default-568h@2x.png). Quando si genera il progetto con Xcode 4.5, viene visualizzato un avviso, “Missing Retina 4 launch image”. Fare clic su “Aggiungi” per aggiungere un immagine di default al progetto.

Al lancio dell’ app apparirà in full screen on iPhone 5

Fase 3:

Tuttavia, la maggior parte dei nib file non sarà ancora in scalata correttamente. Il passo successivo è quello di controllare la maschera ridimensionamento automatico (auto resizing mask) di tutti i file nib e assicurarsi che la vista (view) all’interno del file nib si dimensioni automaticamente in base alla nuova altezza della vista.

Le proprietà che si usano sono:

UIViewAutoresizingFlexibleTopMargin,
UIViewAutoresizingFlexibleBottomMargin,
UIViewAutoresizingFlexibleHeight.

Si utilizza la UIViewAutoresizingFlexibleHeight per la visualizzazione on top in modo che auto dimensioni con la finestra principale. Si utilizza il UIViewAutoresizingFlexibleTopMargin e / o UIViewAutoresizingFlexibleBottomMargin per subviews.

UIViewAutoresizingFlexibleTopMargin viene utilizzato se si desidera che la visualizzazione secondaria eimanga “inchiodata” alla parte inferiore (il margine superiore è flessibile) e UIViewAutoresizingFlexibleBottomMargin viene utilizzato se si desidera che la visualizzazione secondaria sia “inchiodata” alla parte superiore (iò margine inferiore è flessibile).

Se invece si utilizza Cocoa auto Layout, questo passaggio diventa facoltativo. Tuttavia, l’auto Layout non è supportato su iOS 5.

Fase 4:

Infine, qualsiasi Layer che avete aggiunto alla vista dovrà essere ridimensionato manualmente. Il codice seguente mostra come eseguire questa operazione. Usiamo patternLayer per aggiungere un pattern per tutti i view controller. È necessario ridimensionare  nel metodo viewWillLayoutSubviews.

-(void)viewWillLayoutSubviews {

self.patternLayer.frame = self.view.bounds;
[super viewWillLayoutSubviews];
}Step 5 (if you were a messy coder):

Fase 5

Se l’altezza della view è stata codificato  a 460 o 480, potrebbe essere necessario cambiarle tutte  iinsrendo bounds. Ad esempio,

self.window = [[UIWindow alloc] initWithFrame: [[mainScreen UIScreen] bounds]];

invece di

self.window = [[UIWindow alloc] initWithFrame: CGRectMake (0, 0, 320, 480)];

Creare immagini con le nuove dimensioni

Come ho potuto constatare sul blog http://redth.info/get-your-monotouch-apps-ready-for-iphone-5-ios-6-today/ , purtroppo, la convenzione di denominazione di immagini-568h @ 2x.png sembra solo di essere utilizzata per l’immagine di default, ma non viene applicata per le altre immagini dell’ applicazione. Ciò significa che se si sta utilizzando un’immagine di sfondo personalizzata per la visualizzazione (ad esempio: UITableView background), è probabile che sia necessario creare una nuova immagine di sfondo alla risoluzione corretta, e determinare nell’applicazione quando utilizzare ciascuna immagine.
Sarebbe bello se Apple avesse esteso nel nuovo SDK il supporto al nuovo schermo per mezzo del metodo:
[UIImage imageNamed:@"my-image"]
Attualmente possiamo indicare per “my-image” il nome della mia immagine (anche senza estensione) e il sistema operativo effettua la ricerca dell’immagine nell’application bundle secondo questo criterio: se lo schermo è di tipo retina cerca un’immagine con il suffisso @2x nel nome, se non la trova va a cercare l’immagine senza suffisso. Ci saremmo aspettati da parte di Apple l’estensione dell’algoritmo includendo la possibilità di cercare per il suffisso -568h@2x nel caso di schermo da 4″. Purtroppo non è così e per questo motivo dovremo codificare la cosa espressamente nel nostro codice.

Per esempio, nella nostra app non-4inch  compatibile, ho due immagini:

Images / TableViewBackground.png – 320×358
Images / TableViewBackground@2x.png – 640×716

Con la nuova risoluzione, ho bisogno di creare una terza immagine (abbiamo deciso di utilizzare l’opzione-568h @ 2x.png convenzione di denominazione, anche se non è processata da Apple):

Images/TableViewBackground-568h@2x.png

Un approccio elegante è quello di creare una nuova categoria per la classe UIImage (che definiamo con poca fantasia UIImage+Retina4), e effettuare a runtime all’interno della categoria una sostituzione del metodo “imageNamed:” con uno che gestisca la nuova convenzione:


// all'interno di UIImage+Retina4.h
#import

@interface UIImage (Retina4)

@end

// all’interno di UIImage+Retina4.m
#import “UIImage+Retina4.h”
#ifdef TARGET_MAC_OS
#import
#else
#import
#endif

static Method origImageNamedMethod = nil;

@implementation UIImage (Retina4)

+ (void)initialize {
origImageNamedMethod = class_getClassMethod(self, @selector(imageNamed:));
method_exchangeImplementations(origImageNamedMethod,
class_getClassMethod(self, @selector(retina4ImageNamed:)));
}

+ (UIImage *)retina4ImageNamed:(NSString *)imageName {
NSMutableString *imageNameMutable = [imageName mutableCopy];
NSRange retinaAtSymbol = [imageName rangeOfString:@"@"];
if (retinaAtSymbol.location != NSNotFound) {
[imageNameMutable insertString:@"-568h" atIndex:retinaAtSymbol.location];
} else {
CGFloat screenHeight = [UIScreen mainScreen].bounds.size.height;
if ([UIScreen mainScreen].scale == 2.f && screenHeight == 568.0f) {
NSRange dot = [imageName rangeOfString:@"."];
if (dot.location != NSNotFound) {
[imageNameMutable insertString:@"-568h@2x" atIndex:dot.location];
} else {
[imageNameMutable appendString:@"-568h@2x"];
}
}
}
NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageNameMutable ofType:@”png”];
if (imagePath) {
return [UIImage retina4ImageNamed:imageNameMutable];
} else {
return [UIImage retina4ImageNamed:imageName];
}
return nil;
}

@end

Quel che fa questo codice è in fase di inizializzazione sostituire l’implementazione di Apple di “imageNamed:” con la nostra “retina4ImageNamed:” (e viceversa). Nel momento stesso in cui il runtime chiama “imageNamed:” in realtà andrà a richiamare la nostra funzione che andrà a caricare l’immagine ottimizzata per lo schermo a 4″ a condizione che sia presente e che stiamo eseguendo l’app su un device con tale schermo (incluso il simulatore). Nel caso l’immagine non fosse presente o lo schermo fosse il tradizione 3.5″ allora verrebbe chiamata la funzione originale (rinominata a causa dello scambio iniziale).
Ovviamente questa implementazione non può essere usata nel caso il caricamento delle immagini avvenga esplicitamente per mezzo di chiamate del tipo
[UIImage imageWithContentsOfFile:...]
in cui il nome del file va costruito in maniera esplicita.

Il fuggitivo dello spazio, missione a Roma.
Disponibile su App Store

Il fuggitivo e’ arrivato!

Il fuggitivo dello Spazio e’  il primo gioco cinematografico interamente dedicato alle bellezze di Roma.
E’ un  movie game interattivo e divertente dedicato alle famiglie o a tutti coloro che si vorranno cimentare in questa interessante avventura,  compresi bambini e adolescenti.
Interamente girato nella città di Roma, in Italia, è un gioco divertente e didattico. Vi permetterà di scoprire le meraviglie della città eterna e contemporaneamente seguire la storia e le avventure del protagonista, il nostro Fuggitivo nello Spazio.

Scaricalo su App Store

La Storia

Il giovane Fuggitivo è appena arrivato sul pianeta Terra e si trova a passeggiare per la splendida città di Roma vicino al Colosseo, tra le rovine romane.
E’ arrivato dal suo pianeta NubiriX utilizzando il tele-trasporto. E’ fuggito dal proprio pianeta d’origine perchè non voleva sposare una ricca e potente principessa del suo regno alla quale era stato promesso sposo.
Essendo il nostro amico sempre stato un tipo romantico e dato che l’aspetto della sua promessa sposa non poteva ispirare il vero amore, decide di scappare sulla Terra seguendo l’istinto e il proprio cuore.
Purtroppo la brutta principessa, dopo aver saputo della fuga,  ha ingaggiato il capo delle Guardie Reali per dare la caccia al suo promesso sposo con la speranza di riportarlo a casa.
Il cattivo, assieme al suo equipaggio, parte nell’iperspazio seguendo le tracce lasciate dal tele-trasporto così da portare la navicella spaziale aliena nel sistema solare e poi sulla Terra.
Gli inseguitori non hanno però informazioni affidabili sul nostro amato pianeta Terra e sopratutto, durante il viaggio,  riescono a visualizzare sul computer di bordo delle Guardie Reali solo alcune immagini della città di Roma che, essendo il pianeta Nubirix a più di 2000 anni luce dalla terra, si riferiscono alla Roma Imperiale di 2000 anni fa…

Riuscirà il nostro Fuggitivo a sfuggire ai suoi inseguitori e a trovare il vero amore sulla Terra?

La sorte del Fuggitivo è ora nelle vostre mani.

Clicca Qui per il download su App Store

RSS: http://itunes.apple.com/it/rss/customerreviews/id=506689674/sortBy=mostRecent/xml

Alcune immagini:

i3Factory ha sviluppato e  pubblicato per conto di ISNART e per il Ministero delle Politiche Agricole e Forestali e di Unioncamere ,sugli App store Apple e Android queta interessante e utile applicazione applicazione:

10Q Ricette Italiane

Yahoo! lancia Axis (http://axis.yahoo.com/) , sia  come plugin per computer che come app iOS per iPhone e iPad.

Il nuovo browser permette la navigazione in modalità del tutto grafica, praticamente il web appare come un magazine , una vera e propria rivista per il web.

Yahoo! propone Axis per PC o Mac come estesione (plug-in) di Safari, Chrome e Firefox, e si limita ad apparire in un box in basso che visualizza una barra per ricerca alternativa, che e’  basata su Bing. Inoltre Axis permette la sincronizzazione automatica tra PC e dispositivi smartphone (per il momento iOS Apple ma presto anche per Android), come i segnalibri, cronologia e le ricerche possono essere condivise tra i diversi dispositivi (iPhone e iPad  e iPod Touch).

Rapidià:
Yahoo! cerca di stupire con la rapidità della risposta. L’app è in grado di offrire dei risultati mentre si scrive, con priorità sulle informazioni meteo e dati su mappa, oppure offre dei semplici sugerimenti visivi delle pagine a cui porterebbe il completamento della digitazione. Quet’ultimo aspetto, ad alcuni, sembra essere stato ispirato dal progetto di motore di ricerca italiano Volunia (http://www.volunia.com).

Privacy:
I risulati suggeriti sono mostrati in base alle precedenti navigazioni effettuate dall’utente. Rumors in rete sostengono che alcuni sviluppatori abbiano già individuato un bug all’interno dell’estensione Chrome di Axis, che renderebbe poco sicuri i dati di navigazione degli utenti. Tale bug avrebbe già costretto Yahoo! a disabilitare il plugin per  Google Chrome .

Il web è un’immagine:
Esplorare la rete con  Axis equivale, di fatto, a navigare sfogliando un magazine illustrato del web con particolare attenzione all’argomento di ricerca.
Axis è incentrato su due punti chiave: la ricerca – affidata per accordo a Bing di Microsoft, nonostante il search sia stata, storicamente, la funzione primaria di Yahoo! – e le immagini, che sono lil modo in cui vengono visualizzati i risultati.
Un’esperienza simile a quella presentata da alcune estensioni per browser come ad esempio Cooliris (http://www.cooliris.com/).
Cio’ che pero’ sembra essere molto valido in Axis è proprio la sincronia, rendendo la navigazione contigua su tutti i dispositivi che adremo a registrare; il risultato è che possiamo interrompere una sessione sul computer per poi prendere il tablet e continuare esattamente dal quel punto.

Yahoo! si rilancia:
Yahoo comprende che gli utilizzatori di internet hanno molta dimestichezza con i tablet , sopratutto con iPad di Apple.
Axis si presenta in maniera intuitiva e semplice e se Yahoo riuscirà ad integrarla con i servizi di cui già dispone, potrebbe rilanciarsi a sorpresa in quella new economy nata dal modello dell’app store.

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 ingegnieri, 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 ingegniere 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.