JSON, graphs and Apache Sling

Yesterday I was looking an interesting javascript library, JIT (JavaScript InfoVis Toolkit), that is really useful to create some cool rappresentation of your data with graphs, trees, charts and so on.

This toolkit creates different data rappresentation using JSON as input, so I thought it could be funny to integrate with Apache Sling to have a new rappresentation of my repository.

Unfortunately JSON translation in Apache Sling is a bit different from the one used in JIT, because it needs children node rappresented as an array (not in every demo contained in JIT but in the one I want so integrate with Sling).

So I modified org.apache.sling.commons.json.jcr.JsonItemWriter , to encapsulate the nodes in a JSON array

Iterator children = resource.listChildren();
if (children.hasNext()) {
	w.key("children");
	w.array();
	while (children.hasNext()) {
		Resource n = children.next();
		log.info("Giro "+n.getName());
		dump(n);
	}
	w.endArray();
}

Now I have to load some data on my instance of Apache Sling, so I create a simple JSON.

{
	"id": "node01",
	"name": "0.2",
	"data": "",
	"jcr:primaryType":"sling:Folder",
	"node11": {
		"id": "node13",
		"name": "1.3",
		"data": "",
		"jcr:primaryType":"sling:Folder",
		"node111": {
...
...

Finally I have to load this data into JIT, so I modified an example to load JSON data from an external source

function init() {
	$.ajax({
		url: "http://localhost:8080/repository.infinity.json",
		success: postInit
	});
}

So I got a very cool rappresentation of my data stored with JCR

Venus-de-Milo lost both arms…

You know, when you have a program that does something really cool, and you wrote it from scratch, and it took a significant part of your life, you grow fond of it. When it’s finished, it feels like some kind of amorphous sculpture that you’ve created.

It has an abstract shape in your head that’s completely independent of its actual purpose. Elegant, simple, beautiful. Then, only a year later, after making dozens of pragmatic alterations to suit the people who use it, not only has your Venus- de-Milo lost both arms, she also has a giraffe’s head sticking out of her chest and a cherubic penis that squirts colored water into a plastic bucket.

The romance has become so painful that each day you struggle with an overwhelming urge to smash the fucking thing to pieces with a hammer.”

Nick Foster (”Life as a programmer”)

Via: Napolux

Oops i did it again

Se vi capita di andare in edicola, con un bisogno impellente di leggere qualcosa riguardante Java e Database (chi non va in edicola con questo bisogno?!!), allora potete trovare in allegato alla rivista ioProgrammo il mio libro “Java & Database”.

E’ il secondo libro che scrivo e devo dire che rispetto al precedente (”Imparare J2ME” sempre pubblicato da Edizioni Master) è stato molto più impegnativo, perchè ho parlato di differenti tecnologie, la maggior parte delle quali richiederebbero libri da migliaia di pagine.

Nel libro vengono illustrati i seguenti argomenti

• JDBC
• Hibernate
• iBatis
• db4o

Non posso chiaramente farmi una recensione da solo, quindi se qualcuno lo dovesse leggere sono benvenute critiche e/o commenti.
Nel prossimo libro parlerò di cucina giuro

Extreme programming

De rerum bug fixing

Quando si arriva finalmente nel momento di consegna in un progetto software, tutti bravi programmatori si rilassano. Le ultime fatiche, nottate, righe di codice, discussioni hanno portato al tanto desiderato rollout in produzione del vostro progetto.
Tutti i libri di progettazione del software parlano anche di una parte del ciclo di vita del progetto che può risultare molto urticante: il bug fixing!!!

Non esiste una vera e propria letteratura che vi permette di apprendere i rudimenti essenziali di questa fantasticafase del ciclo di vita del software. Ognuno affronta la cosa come meglio crede, quindi in questa umile sede mi permetto di delineare qualche linea guida che potrebbe risultare utile…

Punto 1. Quando c’è un’anomalia bisogna subito capire il contesto funzionale dove si verifica, per capire il corretto funzionamento che dovrebbe avere

Punto 1 nella realtà. Secondo la sempre giusta legge di Murphy, se te conosci il 70% delle funzionalità di un progetto, l’anomalia che ti verrà assegnata è nel rimanente 30%. Inizia quindi una laboriosa ricerca nei meandri di documenti di specifica e di dettaglio che dovrebbero farti capire come la cosa funziona (o almeno dovrebbe).

Punto 2. Talvolta potrebbe essere utile confrontarsi con la persona che ha sviluppato una certa funzionalità per poter accelerare i tempi di risoluzione dell’anomalia

Punto 2 nella realtà. Tendenzialmente la persona che scritto una determinata funzionalità, specialmente se colpevole di un’anomalia tende a dimenticarla poco dopo la consegna. Praticamente tutta la conoscenza che aveva accumulato casualmente vola via a tal punto che può anche dirti “Ma sei sicuro che l’abbia fatta io ’sta cosa?”. In tale circostanza bisogna armarsi di tanta pazienza e cercare di ristudiarti tutta la funzionalità da solo o cercare l’aiuto di qualche anima santa che talvolta viene in tuo aiuto

Punto 3. L’utilizzo di pattern noti nello sviluppo e di un flusso generalmente ben definito dell’applicazione può aiutare molto per identificare il punto in cui si verifica un problema

Punto 3 nella realtà. Purtroppo la parte che non funziona non è quasi mai in un punto del codice “pulito”, altrimenti sarebbe troppo semplice. L’anomalia è malefica, cattiva, annidata vicino a quel pezzo di codice che in teoria quasi non dovrebbe essere usato perchè deprecato o che comunque pure il compilatore quasi ignora.

Punto 4. Gli strumenti di sviluppo sono il migliore amico dello sviluppatore e ti vengono incontro nel momento del bisogno

Punto 4 nella realtà. Troppe volte succede che sono propri alcuni maledetti tool di sviluppo che creano problemi durante lo sviluppo e che poi “ricicciano” soltanto nel momento della produzione (solo a titolo d’esempio potrebbe essere un bellissimo prodotto della Serena Software). Oltre a questo come non nominare il simpaticissimo problema del DISALLINEAMENTO, che magari avviene tra diverse versione del vostro software e che quindi manda allegramente a puttane pezzi di codice.

Punto 5. Durante il test di alcune funzionalità il vostro cliente potrebbe inavvertitamente dimenticare alcuni aspetti delle feature richieste e quindi aprire anomalie che non esistono

Punto 5 nella realtà. Tu paghi, tu decidi, quindi voglio sperare che quando vai a testare una cosa conosci l’applicazione e quello che deve fare. Invece questo potrebbe non verificarsi e quindi può capitare che il simpaticissimo cliente apre anomalie, facendoti perdere tempo (vedi altri punti precedenti) per arrivare alla conclusione che non è un problema del software consegnato ma semplicemente il cliente nemmeno sa quello che vuole.

Si potrebbe continuare ancora a lungo ma sento che almeno con questo piccolo post ho dato sfogo a qualche settimana di BUG FIXING!!!!!

P.S.

Un saluto al carissimo Roberto che in questo momento affronta in prima linea il cliente tutto solo soletto

LWUIT, Lightweight UI Toolkit…WOW!!!

LWUIT, ovvero un nuovo modo di disegnare interfacce grafiche per JavaME.
Ne avevo sentito parlare ma non mi ero interessato più di tanto, poi ultimamente visto che trovavo riferimenti di questa libreria in diversi siti mi sono incuriosito e guardate che cosa ho trovato

La libreria è molto interessante, sia per come è sviluppata sia per le potenzialità. Creare un effetto grafico con questa libreria è di un semplice che quando l’ho visto non ci credevo. Ancora non ho provato tutte le funzionalità ma leggendo il tutorial ho fatto al volo una stupida applicazione e posso dire che sicuramente baserò i prossimi programmi javame su LWUIT.

Animazioni, temi, layout, transizioni…insomma un vero gioiellino questo LWUIT.

Grafici con JavaME

Non se sia una malattia, una perversione o qualcosa di simile, ma mi sono sempre piaciute librerie che permettessero di generare grafici et similia (graficofilia?).
Anche in ambito mobile i grafici potrebbero tornare utili in molti programmi per far visualizzare all’utente un riassunto su un set di dati quindi tanto perchè non ho niente da fare (pare vero aho!!) ho trovato questa semplice ed interessante libreria, MeChart, che permette con poco lavoro di realizzare dei grafici nella applicazioni java mobile.

In questa libreria, nella versione 2.0 disponibile qui, è possibile utilizzare tre diversi tipi di grafici: LineChart, PieChart e BarChart. Questi grafici possono essere inclusi in due modi differenti nel nostro progetto, visto che per ognuno c’è implementato nella libreria un CustomItem e una classe che ci permette di generare l’immagine per includerla in una classica Canvas.

Con poche righe di codice si possono creare dei grafici come il seguente

Qualche app sfiziosa? Stay tuned

Ruby on Rails vs Java

Quanto sono simpatici gli sviluppatori Ruby

WTFs/minute

Un nuovo ed interessante metodo per stimare la bontà del nostro codice

Via: Christian Castelli

L’attimo fuggente…

weblogic.utils.NestedError: This address was valid earlier, but now we get: – with nested exception:
[java.net.UnknownHostException….