In questi giorni, io ed un mio amico, stiamo preparando un nuovo progetto sf. E' il lavoro che abbiamo fatto per l'esame di Sistemi Distribuiti (che mi è valso un 30L ed una collaborazione di 6 mesi in università..).
Il risultato finale è piuttosto difficile da spiegare in poche parole, ma ci proverò lo stesso, senza entrare troppo nei dettagli: una libreria javascript per gestire strutture dati ad albero con metodi per accedere alla struttura e modificarla (getNode, openNode, addNode, removeNode ..)in "java style". Infatti abbiamo cercato di imitare la struttura degli alberi java, prevedendo per esempio la presenza di uno UserObject associato ad ogni nodo.
L'albero inoltre è in grado di usare una libreria ajax (ajaxLoader, scritta ad hoc) per caricare il sottoalbero e notificare eventuali modifiche effettuate dall'utente. Altra caratteristica importante è la possibilità di rappresentare e tenere allineate una struttura dati java lato server con la visualizzazione javascript lato client (condivisa tra più utenti).
E qua si arriva al problema grosso: gestire le modifiche in ambiente distribuito. La soluzione è la seguente: come ogni sistema di controllo di versione non facciamo altro che affidarci ad un revisionNumber incrementale; visto che su http non è prevista l'opzione 'push' (con il server che avvisa di sua spontanea volontà il client) abbiamo implementato gli altri modi possibili: il polling e la notifica dei cambiamenti al momento della risposta di un messaggio del client.
Abbiamo inoltre preparato diverse classi java atte alla gestione dell'albero e degli accessi in modifica. Per cui esistono classi base da estendere e interfacce da implementare per poter adattare la libreria alla propria situazione: per esempio in alcuni casi la struttura ad albero deriva da query ricorsive su database piuttosto che da un file xml o altro
Nel package trovano posto anche delle taglib JSP per velocizzare la stesura delle pagine jsp che utilizzano questa libreria.
Il nome del progetto originariamente era jsTreeView, che su sourceforge è già presente, per cui abbiamo usato le iniziali dei nostri cognomi.. per cui il risultato è szTreeView.
Vista la dimensione che ha raggiunto, è un progetto a cui teniamo molto, per cui spero di riuscire a dedicargli abbastanza tempo da tenerlo vivo ed utilizzabile. A breve il primo commit e se qualcuno ha intenzione di utilizzarlo mi contatti senza problemi
mercoledì 19 dicembre 2007
lunedì 17 dicembre 2007
u4j2rsf: First Commit
Ho finalmente effettuato il primo commit su svn del mio progetto.
A causa di una leggera forma di influenza sono rimasto decisamente indietro. Ho cominciato a committare più che altro perchè mi serve poter accedere da più computer (per ora sviluppavo questo progetto sul portatile, che sta letteralmente cadendo a pezzi), ed un ottimo sistema di controllo di versione è la cosa ideale.
il fatto che automaticamte il repository sia pronto rende tutto più semplice: infatti non dovendo fare l'svn import, per iniziare a sparare i sorgenti su sf, non ho dovuto fare altro che:
ora ricreo il progetto eclipse, setto i vari svn:ignore ed è tutto pronto :)
A causa di una leggera forma di influenza sono rimasto decisamente indietro. Ho cominciato a committare più che altro perchè mi serve poter accedere da più computer (per ora sviluppavo questo progetto sul portatile, che sta letteralmente cadendo a pezzi), ed un ottimo sistema di controllo di versione è la cosa ideale.
il fatto che automaticamte il repository sia pronto rende tutto più semplice: infatti non dovendo fare l'svn import, per iniziare a sparare i sorgenti su sf, non ho dovuto fare altro che:
svn co https://u4j2rsf.svn.sourceforge.net/svnroot/u4j2rsf u4j2rsf
mkdir trunk
[ aggiunta di tutti i miei file dentro questa cartella ]
svn add trunk
ora ricreo il progetto eclipse, setto i vari svn:ignore ed è tutto pronto :)
lunedì 10 dicembre 2007
L'importanza di loggare
Visto che sto cercando il modo migliore per utilizzare il package java.util.logging (JUL) per il mio progetto u4j2rsf, spendo due secondi per sottolineare l'importanza di usare una infrastruttura di logging all'interno delle applicazioni.
Da tempo ormai uso log4j per java e devo dire che mi trovo davvero bene. Ho usato anche commons logging ed ora sto provando ad usare direttamente il package JUL, già incluso nella jdk.
Il concetto alla base è il seguente: nel codice inserisco dei comandi di questo framework per tracciarne l'esecuzione e verificare il contenuto degli oggetti o delle variabili centrali su cui si svolge l'esecuzione del programma.
Questi comandi definiscono una priorità, per esempio log4j ha trace, debug, info, warning, error e critical, il JUL usa altri termini: finest, finer, fine, config info, warning e severe, ma il concetto è lo stesso.
In base ad un file di configurazione, posso decidere fino a quali messaggi stampare, per cui in fase di sviluppo vorrò leggere almeno i debug, se non proprio i trace, mentre in produzione posso limitarmi ai warning, in caso di problemi posso abbassare la priorità e monitorare meglio i file di log.
Ma ovviamente non finisce qui la questione: posso definire diverse destinazioni per i log. Per esempio posso stamparli in console, su file o addirittura (log4j) spedirli via mail.
Framework del genere esistono per tutti i linguaggi (pure javascript, per intenderci..), non appesantiscono più di tanto l'esecuzione del programma ma rendono la fase di debug meno stressante e, secondo me, l'attività di log è un fattore importante per valutare la qualità di un software.
Da tempo ormai uso log4j per java e devo dire che mi trovo davvero bene. Ho usato anche commons logging ed ora sto provando ad usare direttamente il package JUL, già incluso nella jdk.
Il concetto alla base è il seguente: nel codice inserisco dei comandi di questo framework per tracciarne l'esecuzione e verificare il contenuto degli oggetti o delle variabili centrali su cui si svolge l'esecuzione del programma.
Questi comandi definiscono una priorità, per esempio log4j ha trace, debug, info, warning, error e critical, il JUL usa altri termini: finest, finer, fine, config info, warning e severe, ma il concetto è lo stesso.
In base ad un file di configurazione, posso decidere fino a quali messaggi stampare, per cui in fase di sviluppo vorrò leggere almeno i debug, se non proprio i trace, mentre in produzione posso limitarmi ai warning, in caso di problemi posso abbassare la priorità e monitorare meglio i file di log.
Ma ovviamente non finisce qui la questione: posso definire diverse destinazioni per i log. Per esempio posso stamparli in console, su file o addirittura (log4j) spedirli via mail.
Framework del genere esistono per tutti i linguaggi (pure javascript, per intenderci..), non appesantiscono più di tanto l'esecuzione del programma ma rendono la fase di debug meno stressante e, secondo me, l'attività di log è un fattore importante per valutare la qualità di un software.
sabato 8 dicembre 2007
WebService per cambio valute
Io adoro i web service. L'idea che Internet venga usato come rete di servizi invece che rete di informazioni la trovo interessante.
E non per niente, su questo argomento, ci ho fatto la tesi della laurea di primo livello.
Ed ora, dopo tre anni, mi trovo ad usarli per la prima volta in ambito lavorativo. Altri progetti in cui avevo proposto di utilizzarli non sono mai partiti. Invece ora devo accedere al più classico dei web service: il cambio di valuta.
Dopo un po' di giri per la rete ecco qui quello che fa al caso mio: http://www.webservicex.net/WS/WSDetails.aspx?CATID=2&WSID=10.
c'è anche, ovviamente, il link al descrittore del webservice: il WSDL.
In pochi step riesco ad accedervi dal mio codice java:
- scaricare apache axis
- dare in pasto il descrittore a WSDL2Java, che genera classi java per accedere al web service lì descritto: java org.apache.axis.wsdl.WSDL2Java http://www.webservicex.net/CurrencyConvertor.asmx?WSDL (dopo aver messo i jar di axis nel classpath)
- importare le classi generate nel mio progetto
- utilizzare le classi:
CurrencyConvertor convertor = new CurrencyConvertorLocator();
double rate = convertor.getCurrencyConvertorSoap().conversionRate(Currency.EUR, Currency.USD);
Ed il gioco è fatto: attraverso il contenuto del WSDL, axis ha generato il metodo conversionRate che effettua (su un protocollo condiviso in formato xml, SOAP) la chiamata "ConversionRate" al webservice passandogli due Currency come parametri, e ricevendo come risposta un double.
In questo modo io non so com'è la logica dietro all'esecuzione del metodo, ma so che ci posso accedere tranquillamente ed essendo tutto basato su XML, ho l'interoperabilità tra linguaggi, per cui, per esempio, posso scrivere un web service in Java ed accedervi da Perl.
E non per niente, su questo argomento, ci ho fatto la tesi della laurea di primo livello.
Ed ora, dopo tre anni, mi trovo ad usarli per la prima volta in ambito lavorativo. Altri progetti in cui avevo proposto di utilizzarli non sono mai partiti. Invece ora devo accedere al più classico dei web service: il cambio di valuta.
Dopo un po' di giri per la rete ecco qui quello che fa al caso mio: http://www.webservicex.net/WS/WSDetails.aspx?CATID=2&WSID=10.
c'è anche, ovviamente, il link al descrittore del webservice: il WSDL.
In pochi step riesco ad accedervi dal mio codice java:
- scaricare apache axis
- dare in pasto il descrittore a WSDL2Java, che genera classi java per accedere al web service lì descritto: java org.apache.axis.wsdl.WSDL2Java http://www.webservicex.net/CurrencyConvertor.asmx?WSDL (dopo aver messo i jar di axis nel classpath)
- importare le classi generate nel mio progetto
- utilizzare le classi:
CurrencyConvertor convertor = new CurrencyConvertorLocator();
double rate = convertor.getCurrencyConvertorSoap().conversionRate(Currency.EUR, Currency.USD);
Ed il gioco è fatto: attraverso il contenuto del WSDL, axis ha generato il metodo conversionRate che effettua (su un protocollo condiviso in formato xml, SOAP) la chiamata "ConversionRate" al webservice passandogli due Currency come parametri, e ricevendo come risposta un double.
In questo modo io non so com'è la logica dietro all'esecuzione del metodo, ma so che ci posso accedere tranquillamente ed essendo tutto basato su XML, ho l'interoperabilità tra linguaggi, per cui, per esempio, posso scrivere un web service in Java ed accedervi da Perl.
venerdì 7 dicembre 2007
Nuovo progetto su sourceforge: u4j2rsf
La mia latitanza dal blog, anzi da internet in generale, attualmente è dovuta ad un progetto che mi serve per un esame: u4j2rsf.
Praticamente: visto che non si è trovato un modo per tradurre i report generati da Understand for Java al formato Rigi Standard Format necessario ad ARMIN, ho deciso di provare a scriverne uno.
Mi sono appoggiato a sourceforge per poter avere una serie di strumenti necessari a me e a chi dovrà usare il software in futuro, per segnalare bug, fornire documentazione e seguire l'andamento dello sviluppo.
Ed ho scelto sourceforge ovviamente perchè credo nel software libero e sono sicuro che questo sarà solo il primo mio contributo alla causa. Ben presto, infatti, arriverà anche la libreria javascript per la gestione di strutture dati ad albero, a cui ho dedicato un sacco di tempo e di cui vi parlerò un'altra volta..
Praticamente: visto che non si è trovato un modo per tradurre i report generati da Understand for Java al formato Rigi Standard Format necessario ad ARMIN, ho deciso di provare a scriverne uno.
Mi sono appoggiato a sourceforge per poter avere una serie di strumenti necessari a me e a chi dovrà usare il software in futuro, per segnalare bug, fornire documentazione e seguire l'andamento dello sviluppo.
Ed ho scelto sourceforge ovviamente perchè credo nel software libero e sono sicuro che questo sarà solo il primo mio contributo alla causa. Ben presto, infatti, arriverà anche la libreria javascript per la gestione di strutture dati ad albero, a cui ho dedicato un sacco di tempo e di cui vi parlerò un'altra volta..
Iscriviti a:
Post (Atom)