Librerie esterne ed svn: gli externals ci aiutano

Perché includere i sorgenti di librerie esterne quando potremmo comodamente utilizzare gli svn messi a disposizione dai maintainer?

Per esempio, potrebbe capitare di lavorare ad una web application che utilizza la libreria javascript dojo, 20 Mb e più di sorgenti che sarebbe inutile includere nell’svn del nostro progetto.

Impariamo come utilizzare gli svn externals per collegare percorsi del nostro repository a repository “esterni” al nostro.

Facciamo un esempio, la nostra webapp ha la seguente struttura (è già una working copy svn):

/web-root
  /js
  /js/dijit
  /js/dojo
  /js/dojox
  /css
  pagina1.html
  pagina2.html

Dentro la folder js vorremmo includere le librerie dojo. Invece di effettuare un download manuale dei file e poi effettuare un commit che inserirebbe nel nostro repository i file, possiamo istruire il server svn a fornirci le risorse direttamente dall’svn di dojo.

Eseguiamo il comando (i vari externals sono separati da newline):

svn propset svn:externals "js/dijit    http://svn.dojotoolkit.org/src/tags/release-1.3.2/dijit
  js/dojo    http://svn.dojotoolkit.org/src/tags/release-1.3.2/dojo
  js/dojox    http://svn.dojotoolkit.org/src/tags/release-1.3.2/dojox" /web-root

A questo punto basterà lanciare:

svn update /web-root

per avere a disposizione i file della libreria, senza “intasare” l’svn con sorgenti che non dobbiamo manutenere.

E il gioco  fatto :)

Per approfondire, fate riferimento alla bibbia sull’svn:

http://svnbook.red-bean.com/en/1.0/re23.html

http://svnbook.red-bean.com/en/1.0/ch07s03.html

KISS: bacia e abbraccia la semplicità

Quante volte siete tentati dal pensare in anticipo a tutte le potenziali future evoluzioni di una scelta architetturale o di codifica del vostro software?

Quante volte cedete a questa tentazione?

Quante volte questo approccio si rivela efficace?

Queste domande mi offrono l’occasione per parlarvi della regola KISS (Keep It Simple Stupid): falla semplice, stupido/a.
Dovrebbe essere una regola dettata dal buonsenso e dalla logica. Invece, troppo spesso si cade nella tentazione, in pieno delirio di onnipotenza, di predirre il futuro facendo delle assunzioni che potrebbero rivelarsi errate. Il dover pensare a tutte le possibili implicazioni di una scelta alla fine porta a sviluppare codice contorto, difficile da comprendere dopo pochi giorni anche per chi lo ha scritto, figuriamoci per chi lo deve manutenere.

Utilizzare soluzioni semplici offre grandi vantaggi: sono semplici da capire, sono semplici da manutenere e probabilmente sono soggette a meno errori nella loro realizzazione.

Ciò che va assolutamente evitato è l’approccio KICK (Keep It Complex Kamikaze).

E allora, vediamo quali sono le complicazioni da kamikaze che andrebbero evitate:

  1. Applicare pattern complessi troppo presto: se la funzionalità da implementare è ancora ad un livello di semplicità tale da non giustificare l’adozione di un design pattern probabilmente la soluzione più semplice è evitare di usarlo. Si potrà sempre decidere di applicare il pattern quando le condizioni muteranno.
  2. Eccedere nel progettare l’architettura del software per supportare potenziali richieste future: chi è in grado di predirre il futuro? Nessuno. Per tenere il software semplice basterà limitarsi a sviluppare le funzionalità richieste. E’ chiaro che nel corso dello sviluppo arriveranno altre richieste, che andranno valutate solo quando si presenteranno (ripetete con me: il futuro non si può predirre! il futuro non si può predirre! il futuro non si può predirre!).
  3. Sviluppare un’infrastruttura software complessa: spesso si cade nell’errore di lanciarsi nello sviluppo di gerarchie di classi o di interi framework sin dall’inizio di un progetto. Abbiamo veramente bisogno di sviluppare un sotto-sistema di logging o di interazione con il database sin dal principio, con il rischio che poi venga utilizzato poco (e vada comunque manutenuto)? Non è il caso di aspettare che diventi un’esigenza che aggiunga valore al software? Non è il caso di usare qualcosa di già pronto?

Spero di aver offerto uno spunto di riflessione. Proviamo, con uno sforzo di umiltà, a ripensare al nostro approccio nell’affrontare i problemi. Abbandoniamo l’orgoglio e gli esercizi stilistici e abbracciamo il KISS!

Fatemi sapere cosa ne pensate.

JUnit TestSuite: avviare le classi di test in un colpo solo

Nei nostri progetti abbiamo decine di classi di Test (VERO CHE LE ABBIAMO?).

Quando diventano così tante può essere molto comodo avviarle con un solo click dal nostro IDE preferito (PER ORA, ECLIPSE) o da un buildfile ant.

JUnit (almeno nella versione 4) mette a disposizione la classe TestSuite che consente di invocare in modo automatico tutti i metodi di una classe che estende TestCase.

Per esempio, abbiamo le classi

public class it.babel.test.TestClass1 extends TestCase {...}

public class it.babel.test.TestClass2 extends TestCase {...}

Ognuna delle due classi fornisce l’implementazione di alcuni metodi per il test unitario.

Per eseguire tutti i metodi delle due classi basterà definire la classe

import it.babel.test.*;

import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests {

public static Test suite() {
  TestSuite suite = new TestSuite("Tutti i test per it.babel.test");

  suite.addTestSuite(TestClass1.class);
  suite.addTestSuite(TestClass2.class);

  return suite;
  }
}

Le cose semplici vanno una spada: JSON

json Finalmente quacosa si muove!
Finalmente si può fare in modo che le applicazioni web non siano più macigni inusabili e lenti.
Finalmente si può fare a meno di framework che portano inevitabilmente ad un “effetto bradipo”.
Finalmente si possono mandare in pensione Struts e affini.
La soluzione esisteva da tempo… attendeva solo di essere utilizzata.
La soluzione è AJAX.

Ajax rende possibile molte cose interessanti ma lascio a chi legge scoprirle. Comunque, la caratteristica fondamentale è la possibilità di effettuare richieste HTTP senza aprire una nuova pagina.
In questo modo risulta possibile ricevere dati da una fonte senza dover eseguire un antiestetico ed inutile reload della pagina.
Una questione resta irrisolta: in che formato tali dati saranno restituiti al chiamante? XML? E’ una soluzione. Plain text? E’ un’altra possibilita. Ma con che formato? Non esiste uno standard.
E invece si, lo standard esiste ed è sfruttato appieno da JSON.
JSON consente lo scambio di dati in un formato che sfrutta lo standard Standard ECMA-262 e javascript. E’ possibile ricevere strutture dati anche complesse che siano facili da interpretare e performanti.
Facciamo un esempio. Supponiamo che la nostra applicazione debba prendere una lista di contatti dal server salvati in un database. Il nostro oggetto Contatto avrà due proprietà, nome e cognome e una lista di numeri di telefono.
Dalla nostra pagina HTML si effettua una chiamata HTTP tramite ajax al componente server(Servlet/JSP/CGI) che fornirà i dati, per esempio nel seguente modo:

[
{nome:Mario,cognome:Rossi,numeritelefonici:[3331111,3332222,3334444]},
{nome:Giovanni,cognome:Verdi,numeritelefonici:[061234567]}
]

Accidenti, e ora chi la parsa questa stringa? E qui viene il bello. La stringa è in formato standard ECMA che javascript è in grado di interpretare. Per esempio l’interprete sa che quello che c’è tra le {} rappresenta un oggetto e che avrà dei membri identificati tramite chiave:valore. Le [] invece identificano un array.
Quindi basterà utilizzare la funzione eval(strCodice) di javascript, che esegue il codice in strCodice e il gioco è fatto.

In pratica:
var oggettoJSON = [{“nome”:”Mario”,”cognome”:”Rossi”…];
var contatti = eval(‘(‘ + oggettoJSON + ‘)’); // contatti sarà un array di oggetti Contatto

Per motivi di spazio non posso continuare… spero di aver solleticato la vostra curiosità.
Per la serie: le cose semplici VANNO UNA SPADA!!!