Fede Ranghino

Grazie a Ludo scopro SLOCCount, software per calcolare i costi dei software a partire dalla stima delle linee di codice.

A questo punto mi viene il prurito e la curiosità  di macinare i sorgenti di t.nes, il nostro framework di sviluppo web realizzato in Java, per valutarne il costo. Ecco i risultati.

• Linee di codice totale (SLOC) = 33.367
• Stima tempi di sviluppo, anno-uomo (mese-uomo) = 7,95 (95,43)
• (Basic COCOMO model, mese-uomo = 2,4 * (KSLOC**1,05))
• Stima del riascio, anni (mesi) = 1,18 (14,13)
• (Basic COCOMO model, mesi = 2,5 * (mese-uomo*0,38))
• Numero stimato di sviluppatori medi (tempi di sviluppo/rilascio) = 6,75
• Costo totale stimato di sviluppo = € 610.765
• (stipendio medio lordo = € 32.000/anno, overhead = 2.40).

Ho seguito con attenzione il keynote di Steve Jobs al WWDC di San Francisco.

Sto seguendo i commenti degli utenti, che come al solito mettono in piazza una guerra. Su cosa? Sul dock in prospettiva tridimensionale (che ricorda il fallito esperimento di Java Desktop di Sun Looking Glass), su cover flow, sul desktop verdino e la trasparenza della menu bar.

Ma siamo scemi o cosa?

Io vorrei che ci si rendesse conto che Mac OS X non é nato in tre anni dopo il ritorno di Jobs in Apple, ma é il frutto di uno sviluppo continuo dal 1986 quando era ancora NeXT Step: 21 anni per arrivare al sistema operativo odierno. E solo grazie a molti, moltissimi contributi dal mondo BSD lo sviluppo é potuto essere così veloce, perché proprio dal mondo BSD Unix deriva molta della sua stabilità .

Quando la comunità  ha urlato all’innovazione alla presentazione di Mac OS X nel 2001, ci si rendeva conto che alle spalle c’erano 15 anni di sviluppo? , diventati visibili praticamente in un colpo solo?? (NeXT e NeXT Step penso la conoscessimo in 10 ai tempi e sicuramente non erano utenti Mac).

Dalla release di Tiger sono passati 21 mesi. Mesi! Non anni.

Ci si aspettava un sistema operativo nuovo? Ma in che mondo? Come era fattibile? Aspettativa un po’ miope. Ci si poteva solo aspettare un update del sistema operativo, così come lo sono state le precendenti.

Inoltre Leopard le maggiori innovazioni le porta a basso livello:

• 64 bit pieni,
• ottimizzazione della gestione multicore a livello di sistema (tutte le applicazioni ne traggono vantaggio),
• nuove librerie (core animation) per gli sviluppatori.

Anche solo queste tre feature “invisibili” fanno fare un salto generazionale al sistema operativo in termini di performance ed efficienza. A tutto vantaggio sia di chi sviluppa applicazioni sia di chi usa ad alto livello un Mac: editing video, fotografico, ambienti server, etc.

E queste tre feature sviluppate in 21 mesi sono un miracolo, da decine di migliaia di ore uomo di lavoro, frutto anche della collaborazione Apple e Intel.

Al WWDC Apple ha portato 1.250 ingegneri per assistere e introdurre alle nuove tecnologie 5.000 sviluppatori accorsi all’evento. I WWDC non si ferma al keynote di Steve Jobs: si faccia una veloce ricerca su YuoTube. Decine di video sui vari approfondimenti tecnici seguiti (e sempre applauditissimi) dagli sviluppatori.

Risultato: le software house tornano a sviluppare su Mac (entertainment in testa con EA e ID) e la comunità  degli sviluppatori aumenta di 200.000 persone. Conseguenza: più software, più possibilità  di scelta, più qualità  per noi utenti finali Mac.

Apple ha ottimizzato le basi del sistema operativo, per adattarlo al massimo al nuovo modo di fare hardware (multi-core e concorrenzialità  dei processi, altrimenti anche gli 8 core del Mac Pro sono poco o niente sfruttati) e per prepararsi alle applicazioni e all’interattività  del futuro.

Questo é il messaggio tra le righe del WWDC: potenzialità .

I fuochi d’artificio? Sono da cercare al MacWorld Expo, non ad una conferenza di sviluppatori.

Per poter accedere alla API di YouTube é necessario ottenere un Developer ID e la documentazione é abbastanza completa, anche se mi aspettavo qualche metodo in più. Le metodologie di accesso sono due: REST e XML-RPC.

Obiettivo del post é fare una panoramica di come implementare una classe Java che, dati DEV_ID e una lista di VIDEO_ID, acceda alle API di YouTube, ne scarichi i dettagli, provveda a costruire una cache su filesystem. Non entrerò in dettagli che uno sviluppatore Java conosce sicuramente meglio di me.

Metologie di caching:

• la più semplice in Java é serializzare l’oggetto ottenuto dall’XML su filesystem;
• per palati più raffinati, si possono utilizzare ottime librerie open source come
  • EHCache oppure
  • OSCache.

REST Interface

Interfaccia estremamente semplice si basa su una chiamata http che come risultato restituisce un file xml. Un esempio.

http://www.youtube.com/api2_rest?
method=youtube.videos.get_details&dev_id=YOUR_DEV_ID
&video_id=YOUR_VIDEO_ID

dove:

• method é il parametro in cui si indica il metodo delle API YouTube a cui si vuole accedere;
• dev_id il proprio id di sviluppo;
• video_id é l’id univoco del filmato su YouTube.

La nostra classe:

1. scorre la lista di VIDEO_ID;
2. verifica se esiste già  una cache per quel video (o verificando su filesystem se esiste l’oggetto serializzato o interroganto EHCache/OScache);
3. se non esiste una cache:
   • farà  la chiamata http alle API di YouTube
   • riceverà  l’xml di dettaglio del video per quel determinato VIDEO_ID
   • elaborerà  l’xml trasformandolo in un oggetto strutturato nel modo che ci viene più comodo e utile
   • creerà  la cache per quell’oggetto
4. se esiste l’oggetto cachato, la classe si preoccuperà  soltanto di recuperarlo;
5. viene restituita una lista di oggetti contenenti i dettagli dei nostri video.

Per effettuare una chiamata http é necessaria una libreria che implementi un client http, va benissimo l’HttpClient del progetto Jakarta Commons. La chiamata può essere fatta in GET o in POST: in questo senso la documentazione di YouTube non dice nulla (l’esempio sopra simula una GET) ma penso che l’API accetti entrambi i metodi (preferibile il POST).

Il codice (plausibilmente un metodo privato della classe) dovrà  essere strutturato più o meno così:

HttpClient client = new HttpClient();
PostMethod method = new PostMethod(”http://www.youtube.com/api2_rest”);
method.addParameter(”method”, “youtube.videos.get_details”);
method.addParameter(”dev_id”, YOUR_DEV_ID);
method.addParameter(”video_id”, YOUR_VIDEO_ID);
try {
// eseguo la chiamata
int statusCode = client.executeMethod(method);
if (statusCode != HttpStatus.SC_OK) {
System.err.println(”Method failed: ” + method.getStatusLine());
}
// leggo la risposta
byte[] responseBody = method.getResponseBody();
// utilizzo la response.
// Attenzione: assicurarsi che l’encoding sia corretto ne non siano dati binari
String myXML = new String(responseBody));
} catch (HttpException e) {
… // gestione dell’eccezione
} catch (IOException e) {
… // gestione dell’eccezione
} finally {
// chiudo la connessione.
method.releaseConnection();
}

Le possibilità  di ottimizzazione sono svariate, come per esempio creare un unico client e sfruttare un’unica connessione per evitare overhead inutili: a voi la scelta. La response che si otterrà  sarà  simile a questa.

Per elaborare l’xml e trasformarlo in un più comodo oggetto, possiamo utilizzare uno dei moltissimi parser a disposizione della piattaforma Java. La scelta in questo caso é più orientata su considerazioni di gusto (riguardo l’API del parser), di leggerezza del parser e della sua velocità  di elaboarzione.

Per un utilizzo leggero e snello consiglio di utilizzare un pull-parser anche senza feature di validazione (che in questo caso servono a poco e non avremmo comunque il DTD su cui lavorare). Un elenco veloce di alcuni:

• Woodstox
• XP
• kXML 2
• VTD-XML

Alla prossima puntata farò una panoramica su come può funzionare l’approccio via interfaccia XML-RPC.

Qualche giorno addietro Yahoo news ha pubblicato una notizia attesa da molti sviluppatori Java: entro un mese o due il framework sarà  rilasciato sotto licenza open-source. Ragionando sulla data di scadenza, molto probabilmente la prima release open source sarà  Java 6.

Voci di corridoio correvano già  da sei mesi, con il cambio al vertice e l’ascesa di Jonathan Schwartz a CEO di Sun.

Il mondo Java é già  estremamente ricco di software ed iniziative open source e con Java 5 la possibilità  di redistribuzione, oltre che di ottenere la maggior parte dei sorgenti della piattaforma, era già  diventata reale.

Il rischio che, a mio avviso, stava correndo il framework era di eccessiva parcellizzazione. Ad oggi esistono

• le soluzioni commerciali (principalmente quella di IBM e di Bea, JRun dell’ex Macromedia ora Adobe),
• il progetto Classpath, intorno al quale ruotano decine di Java Virtual Machine open source,
• GCC
• il progetto Harmony della Apache Software Foundation, con forti contributi da IBM.

Sicuramente mi dimenticherò qualche progetto importante, ma la veloce panoramica serviva solo ad osservare che troppi, troppi sviluppatori sono concentrati nel replicare le funzionalità  di Java su progetti open, risorse che invece potrebbero concentrarsi sul migliorare funzionalità  e prestazioni della piattaforma.

Il rilascio open source non fa male neache dal punto psicologico e commerciale: nell’ultimo periodo ho trovato resistenze su Java da parte di alcuni integralisti dell’open source. In realtà , quando nel 1999, Blue Studio ha scelto Java come sua piattaforma preferenziale, già  speravo che il percorso sarebbe stato verso l’apertura piuttosto che la piattaforma proprietaria.

Da un annetto abbondante Sun ha rilasciato open source anche Solaris, il suo sistema operativo. Il progetto é Open Solaris e dal rilascio sono nati progetti paralleli dalle caratteristiche decisamente interessanti:

• Nexenta, sistema operativo che unisce il kernel Solaris all’ambiente GNU,
• Balenix, distribuzione Open Solaris alternativa a quella ufficiale.

Solaris é un sistema operativo della famiglia Unix sullo stile BSD. Nella sua impostazione di base ha molto in comune con i cugini, più o meno lontani, FreeBSD. NetBSD, OpenBSD e Darwin/MacOS X.

I punti di forza del sistema operativo di Sun sono:

• l’innovativo filesystem ZFS,
• ottimo supporto industriale,
• buone performance sia paragonato a Linux che a Windows,
• ottime capacità  di isolamento (per zone) delle applicazione a favore della stabilità  e della sicurezza.

La piattaforma Open Solaris / Java sembra estremamente interessante.

Ma il punto che continuo a ritenere fondamentale, nell’apertura dei sistemi proprietari all’open source, sta nel costante aumento della libertà  di scelta dello strumento migliore in relazione agli obiettivi che ci si pone.