domenica 28 ottobre 2012

Android: fragments e UI designers

Ultimamente lavoro molto in Android, a contatto con UI designers molto bravi e meno bravi.

Premetto che sono d'accordo con questo celebre post di Jeff Atwood. Però lasciando fare tutto ai designers si rischia l'opposto: se non conosce le opportunità offerte della tecnologia, il designer potrebbe fare assunzioni sbagliate sulla possibilità di certe soluzioni o semplicemente ignorarle. Inoltre sappiamo bene come sia facile in Italia improvvisarsi in qualsiasi ruolo, soprattutto quando va di moda.

Ad esempio un designer sprovveduto potrebbe credere che un'applicazione Android dovrebbe essere uguale per tablet e smartphone, per risparmiare sullo sviluppo.
E allora via con bellissimi bottoni immensi senza testo al centro! Lo store è pieno di applicazioni che per un tablet da 10 pollici diventano così:

Questo magari perché il designer non sapeva che in Android i fragments permettono di riutilizzare le logiche del programma in modo del tutto trasparente rispetto al layout scelto per il dispositivo e ha scartato la possibilità di mostrare, per i tablet, il contenuto direttamente nell'activity principale.

martedì 29 maggio 2012

Introduzione a Flag Driven Development

Credo che ad ogni sviluppatore sia capitato di lavorare con questo approccio, dalle dinamiche molto interessanti. Generalmente un prodotto o una una logica in un software comincia con un algoritmo del tipo:

per ogni x tale che x appartiene all'insieme A
esegui l'operazione f(x)


Inizialmente va tutto bene e tutti sono entusiasti del prodotto. Inevitabilmente qualcuno fa notare che così com'è non va bene, e bisognerebbe distinguere una situazione in cui l'operazione su x non va fatta.

La soluzione a questo problema, secondo l'approccio Flag Driven Development è: aggiungere un flag su x. Il nostro algoritmo diventa:

per ogni x tale che x appartiene all'insieme A 
   se x.flag = falso
      esegui l'operazione f(x)

Qualche volta il flag indica che bisogna eseguire un'altra funzione:



per ogni x tale che x appartiene all'insieme A 
   se x.flag = falso
      esegui l'operazione f(x)
   altrimenti
      esegui l'operazione g(x)


Come si vede, l'approccio è incrementale perché è sempre possibile aggiungere il flag del flag e rendere il sistema più potente:


per ogni x tale che x appartiene all'insieme A 
   se x.flag1 = falso
      se x.flag2 = falso
         esegui l'operazione f(x)
      altrimenti
         esegui l'operazione h(x)
   altrimenti
Bandiera del Regno d'Italia Napoleonico
      esegui l'operazione g(x)


Si può evitare il flag? Sì, ma perché dovremmo? Questo approccio è un obbrobrio? Anche secondo me, ciò non toglie che è sempre molto usato.
Nei prossimi post forse ritornerò sull'argomento per esplicitare meglio certe dinamiche o forse no.

sabato 5 novembre 2011

Machine Learning e Scala al JugMarche 2

Pubblico le slide del meeting:

... e ringrazio tutti i partecipanti. Il codice delle demo sarà ufficialmente pubblicato su github ASAP :)


Stay tuned!

sabato 15 ottobre 2011

Machine Learning e Scala al JUG Marche

Sabato 29 ottobre terrò un talk di un'ora circa al Jug Marche a Falconara Marittima (AN) trattando di usi pratici di Machine Learning ed esempi in Scala. Maggiori dettagli sull'evento ed iscrizione(gratuita) qui.