Per la serie “Un paese senza”, vengo a sapere che ad oggi non è pos­si­bile svi­lup­pare appli­ca­zioni basate su Android in Italia.

Altre info in que­sto post.

Sto cer­cando di farmi un’idea sulle carat­te­ri­sti­che di Android, in par­ti­co­lare sulla vir­tual machine(VM)  usata per le appli­ca­zioni Java.

La par­ti­co­la­rità ruota intorno al fatto che la VM per i cel­lu­lari non è rila­sciata in open source quella stan­dard e Google, essendo quello che è, ha tro­vato la sua solu­zione: Davik. 

Davik è una VM che usa un suo byte­code e può anche usare le libre­rie di Java SE ma, gra­zie ad Android, per­mette agli svi­lup­pa­tori di con­ti­nuare ad usare la sin­tassi di Java. Il sor­gente viene prima com­pi­lato nel byte­code Java e poi convertito. Dire che è bril­lante è dir poco, anche se certo un approc­cio così inva­sivo ha anche le sue controindicazioni.

Infine, una nota “per­so­nale” sul tema Android vs iPhone. Nella mag­gior parte dei blog che ho letto prima o poi salta fuori il con­fronto con l’iPhone; tipi­ca­mente seguendo un’equazione del tipo: “Adroid = aperto = bene” “iPhone = chiuso = male”. C’è del vero, anzi molto. Tuttavia biso­gna notare due cose: 1) sono i risul­tati che con­tano. Il primo cel­lu­lare su Android uscirà a metà del pros­simo anno e voglio vedere come sarà e quali van­taggi tan­gi­bili per l’utente finale ci saranno. 2) Non è detto che ci sia una qual­che forma di “por­ting” verso l’iPhone che, non dimen­ti­chia­molo, è pro­dotto com­pleto e non “solo” una piat­ta­forma soft­ware – lo so, lo so: una piat­ta­forma è più impor­tante di un pro­dotto ma voglio enfa­tiz­zare il fatto che gli utenti vedono e com­prano il secondo e non la prima; que­sto può avere un suo peso, resta da capire quanto. References:

• Dalvik: how Google rou­ted around Sun’s IP-based licen­sing restric­tions on Java ME;
• Google’s Android — Architected for Participation;
• Dalvik — Google’s twea­ked, non-standard JVM for Andriod!!!!
  

Anche se sono mesi che non apro Eclipse, le novità dell’ultima ver­sione di JUnit sono ben­ve­nute. Ad es. adesso, al pari di altri fra­meworks – JMock, se non ricordo male – è pos­si­bile scri­vere cose del tipo:

assertThat(x, is(3));
assertThat(x, is(not(4)));
assertThat(responseString, either(containsString("color"))
    .or(containsString("colour")));
assertThat(myList, hasItem("3"));

Altra aggiunta utile e, soprat­tutto, che può cam­biare l’approccio ad alcuni sce­nari di test è la pos­si­bi­lità di espli­ci­tare gli assunti rite­nuti validi durante lo sviluppo:

assertThat(x, is(3));
@Test public void filenameIncludesUsername() {
       assumeThat(File.separatorChar, is('/'));
       assertThat(new User("optimus").configFileName(),
           is("configfiles/optimus.cfg"));
}

Ad oggi que­sti assunti non fanno fal­lire il test se si rive­lano falsi.

Per esten­sione sono state intro­dotte le teo­rie. Ad es:

assertThat(x, is(3));
@RunWith(Theories.class)
public class UserTest {
  @DataPoint public static String GOOD_USERNAME = "optimus";
  @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";

  @Theory public void filenameIncludesUsername(String username) {
    assumeThat(username, not(containsString("/")));
    assertThat(new User(username).configFileName(),
        containsString(username));
  }
}

La teo­ria espressa da filenameIncludesUsername viene veri­fi­cata per ogni @DataPoint e il test fal­li­sce se, per un @DataPoint che con­ferma l’assunto, l’asserzione è falsa.

Grazie ai data point è ora pos­si­bile scri­vere test su insiemi in maniera più natu­rale; TestNG rimane ancora avanti in que­sto set­tore ma la distanza si è accorciata.

Una mac­china vir­tuale dei pro­cessi (PVM, Process Virtual Machine) defi­ni­sce un’astrazione per model­lare dei flussi di lavoro, in modo indi­pen­dente dal lin­guag­gio usato. La PVM per­mette di valo­riz­zare quelle astra­zioni che i flussi di lavoro hanno in comune tra di loro, sia quelli più comuni, legati mondo azien­dale, sia quelli legati allo svi­luppo software.

In que­sto modo si pos­sono risol­vere alcune limi­ta­zioni degli attuali sistemi per la gestione dei flussi di lavoro: foca­liz­za­zione esclu­siva sull’ambiente azien­dale, fram­men­ta­zione dell’offerta, inte­gra­zione dif­fi­col­tosa nell’ambiente di sviluppo.

Le astra­zioni prin­ci­pali di una PVM sono: nodi, tran­si­zioni, ese­cu­zioni. Un nodo rap­pre­senta uno dei pos­si­bili passi com­piuti durante il pro­cesso ed è asso­ciato ad un’interfaccia:


public interface Executable {
void execute(Execution execution) throws Exception;
}

Il nodo ha accesso allo stato cor­rente attra­verso l’esecuzione, pas­sata come para­me­tro, ed è respon­sa­bile della tran­si­zione che risul­terà dal com­ple­ta­mento dell’esecuzione non­ché dell’aggiornamento dello stato dell’esecuzione.

Link: The Process Virtual Machine

Con hot­pat­ching si intende la pos­si­bi­lità di sosti­tuire una classe già cari­cata nel run­time con una nuova ver­sione. In que­sto arti­colo, Jack Shirazi dimo­stra come sia pos­si­bile modi­fi­care un’applicazione in ese­cu­zione usando le nuove API messe a dispo­si­zione in Mustang (Java 6).

Elliotte Rusty Harold parte da una pro­po­sta di sin­tassi per le clo­su­res in Java e fini­sce per doman­darsi come mai così spesso il loop di for diventa il ber­sa­glio di così tante cri­ti­che e, di con­se­guenza, di così tante alter­na­tive. In effetti, nem­meno io ci sono molto affezionato… :-/

Il punto più impor­tante, però, riguarda il fatto che i loop senza indice – ma in par­ti­co­lare si parla di clo­su­res – pos­sono anche non essere sequen­ziali e que­sto potrebbe por­tare ad un’esecuzione paral­lela. Viceversa, il for è stret­ta­mente sequen­ziale. Ovviamente, in alcune situa­zioni è pre­fe­ri­bile il primo, in altre il secondo.

Ma que­sto vuol dire che il for e la ver­sione con la clo­su­res non sono equivalenti.

Spinto dalla neces­sità di testare delle pro­ce­dure di migra­zione di un data­base, ho pen­sato bene di fare una sma­net­tata con  TestNG. Beh, direi che è una manna dal cielo!!

Ci sono diverse cose che a mio parere ren­dono TestNG net­ta­mente migliore di JUnit:

• Un set di anno­ta­zioni più esteso
• È molto più fles­si­bile nel clas­si­fi­care i test
• È pos­si­bile sta­bi­lire delle dipen­den­denze fra i test
• È con­fi­gu­ra­bile tra­mite file
• È pos­si­bile ripe­tere lo stesso test con un set di dati a pia­cere. I dati pos­sono essere pas­sati dalle con­fi­gu­ra­zioni o dai @DataProvider. Con que­sta anno­ta­zione ho potuto auto­ma­tiz­zare i test in modo molto più esaustivo.
• Di default, TestNG ri-esegue solo i test fal­liti dal lan­cio precedente

Credo che basti a far venire un po’ di appe­tito… Altri links:

• JUnit vs TestNG: un con­fronto fra i due frameworks
• Statistical testing: uso di TestNG in sce­nari dif­fi­cil­mente testa­bili da JUnit

Al posto di usare syn­chro­ni­zed:
private static Singleton _INSTANCE;
public static synchronized Singleton getInstance() {
if(_INSTANCE == null) {
//initialize...
}
return _INSTANCE;
}

O, ancora peg­gio, il Double Checked Locking, è meglio usare un idioma del tipo:

static class SingletonHolder {
static Singleton INSTANCE = new Singleton();
}


public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}

Links:

• Lazy Loading Singletons
• Effective Java

Bruce Eckel rompe gli indugi e dice senza mezzi ter­mini che Java a livello del client è sostan­zial­mente un fal­li­mento. Cita anche la ormai famosa frase di Jobs sul per­ché Java non sarà inclusa nell’iPhone. Jobs ha ragione, ma ha sem­pli­ce­mente detto quello che tutti sanno e comun­que la frase va messa nel con­te­sto di un tele­fono cel­lu­lare: una JVM solo per far girare un applet è un prezzo un troppo da pagare.

Il post di Eckel, tut­ta­via, non parla di cel­lu­lari; il suo discorso è molto più gene­rale. ora, sono d’accordo con lui che le applet sono state un fal­li­mento, anche se per que­sto non ci voleva Bruce Eckel: come dicevo prima, il re dal quel lato è nudo da un pezzo.

Non con­cordo nel dire che il web sia un casino solo per­ché le pagine sono diverse a causa dei font diversi. Sarebbe come dire che la tele­vi­sione è un disa­stro per­ché io vedo lo stesso pro­gramma in bianco e nero e il mio vicino in alta defi­ni­zione. È vero, Ajax è già troppo abu­sato e spinto oltre i limiti del ragio­ne­vole ma il punto fon­da­men­tale è che cer­care di con­trol­lare in maniera asso­luta la GUI, su web, è futile. Il web fun­ziona per­ché è un casino: è sem­pli­ce­mente irrea­li­stico pen­sare che tutti i client vedano esat­ta­mente la stessa cosa, allo stesso modo.

Il web, anche prima di Ajax e com­pa­gnia bella, ha dimo­strato di essere un medium estre­ma­mente fles­si­bile e agli utenti non impor­tava poi molto se l’interfaccia era legnosa e poco fles­si­bile. Anzi, la GUI spar­tana rende più sem­plice agli utenti pas­sare da un sito/applicazione ad un altro.

Questo non vuol dire che sistemi come flex non abbiano meriti, tutt’altro. Ma forse è il caso di con­te­stua­liz­zare un po’ di più il discorso.

Altri links:

• http://www.flex.org/
• f3

L’ultima new­slet­ter di Java Performance Tuning è uno spe­ciale sui miglio­ra­menti appor­tati alla ver­sione 6 della JVM.