giovedì 11 dicembre 2008

Java è morto, viva Java

C'era una volta il C++. Un linguaggio complesso, nato in un periodo in cui la OOP era in gran parte materia accademica. Il C++ (in gran parte) ha consentito di traghettare il mondo professionale dall'approccio procedurale a quello ad oggetti. Con il tempo, e con l'accumulo dei casi d'uso, il C++ è diventato sempre più ingombrante. La sua sintassi è troppo ricca di costrutti legati ad una visione a basso livello del sistema operativo, ma se devo implementare un sistema informativo e non una libreria grafica, non voglio preoccuparmi di tenere a bada allocazioni, indirizzi di memoria, buffer di file.
Così (banalizzando molto...) nacquero gli ambienti RAD, come Visual Basic e Delphi, che portarono anche importanti evoluzioni nei linguaggi. Soprattutto Delphi (derivato dal Turbo Pascal, ok) creò forse il primo vero ambiente di sviluppo per applicazioni commerciali con una visione moderna e ricca delle esperienze accumulate negli anni.
Da lì poi si passò a Java (da cui Microsoft si ispirò per il C#) che ripulì ancora di più la sintassi creando il primo vero linguaggio ad oggetti puro (non strettamente accademico).

Il C++ però non è affatto sparito, anzi. Se ci si basa sulle richieste di lavoro, il C++ arranca ma è ancora tra i primi 10. Questo perchè, in ogni caso, il C++ è ancora la crosta immediatamente successiva alle API di basso livello di quasi tutti i sistemi operativi. Fornisce le spalle solide su cui appoggiarsi con altri strumenti più adatti alle esigenze degli utenti finali.
Mi ha meravigliato scoprire quanto Python leghi bene al C++. Un linguaggio semplice, interpretato, in simbiosi con un mostro della sintassi. XBMC, un frontend per mediacenter che mi ha quasi fatto dimenticare Meedio, è scritto in C++, ma si appoggia a Python per i plugin. Un'idea semplice ed efficace, che permette a chi vuole contribuire di lavorare con un editor di testo e qualche nozione di programmazione non troppo sofisticata.

Dove voglio arrivare con tutto questo pippone? A me sembra che anche per Java sia arrivato il momento di diventare una solida spalla. Esistono ormai centinaia di piattaforme software scritte in Java e molte sono diventate ormai imprenscindibili per realizzare applicazioni data-oriented. Spring e Hibernate sono i casi più eclatanti.
Ma forse Java è diventato anche lui troppo "a basso livello" per le applicazioni moderne. Ormai quasi ogni specifica funzionale può essere soddisfatta assemblando mattoncini già esistenti. Un esempio è XML, che per anni è stato un surrogato a Java per questi scopi. Si assemblavano mattoni utilizzando XML. Però la relativa semplicità di XML ha fatto sì che assemblare mattoni sia diventato più difficile che scriverne di nuovi.
Io ho la sensazione (molto a naso, non sono un guru o un analista di mercato), che i tempi siano maturi perchè Groovy possa diventare il linguaggio della prossima generazione di applicazioni, almeno nell'ambito dei sistemi a prevalenza open source e multipiattaforma. La semplicità di Groovy unita all'efficienza (computazionale) di Java. Grails ne è l'esempio più riuscito.
Chi ha pensato a JavaFX, lasci perdere. Su quel terreno Java prenderà batoste dolorose.
Da parte mia, per l'anno nuovo mi sono prefisso di convertire a Groovy il più possibile delle mie attività (vincoli aziendali permettendo). Un primo passo potrebbe essere la scrittura dei test case di applicazioni Java, che mi permetterebbe di valutare senza rischi le sue caratteristiche di performance. Un secondo passo potrebbe essere, giusto un esempio, una portlet in Groovy.
Se poi ci fosse qualcosa di disponibile per Eclipse RCP, non sarebbe male...

lunedì 10 novembre 2008

Un tuffo in un'altra quintalata di framework

Ho avuto la felice idea di approfondire il tema delle applicazioni client (sì, proprio quelle che non richiedono un browser per girare) su Java, perchè voglio scrivere una semplice applicazione per uso personale. Nonostante le mie competenze attuali si siano spostate sui sistemi backend, ho da sempre una passione per le interfacce utente e la loro usabilità.
Da studente realizzavo qualche semplice applicazione usando Delphi di Borland, e oggi mi viene un pò da sorridere leggendo di discussioni su come realizzare bind, action, riusabilità delle interfacce, roba che già 10 anni fa Delphi gestiva in maniera egregia.
Ormai uso Java e mi trovo bene, ma la ricerca di un framework per applicazioni client non è tanto diversa che per le applicazioni web. Si trovano decine di alternative, se ne scartano altrettante per manifesto abbandono del creatore, e quelle che rimangono fanno tante cose benino, ma poche benone.
Uno dei miei punti fermi è stata la produttività: posso anche rinunciare all'editor visuale, ma il tool che cerco non si perdere in inizializzazioni inutili, o paginate XML nel tentativo di essere sempre sufficientemente generico. Ormai i pattern tipici delle interfacce utente sono assodati, al limite il lavoro in più dovrebbe essere legato a particolari esigenze.
Intanto ho dovuto affrontare la scelta ideologica tra Swing e SWT: il primo è il framework storico di Sun, da qualche anno rinnovato dall'introduzione di Swing Application Framework, che completa la creazione di interfacce con un modello MVC. Il suo punto di forza è sicuramente Netbeans, con Matisse, un editor visuale che spacca. La sua debolezza (ma per molti è un punto di forza) è il fatto di essere renderizzato in maniera indipendente dal sistema ospite. Io la considero una debolezza perché è più pesante, ma sopratutto perchè risulta alieno nel sistema ospite, anche se JGoodies ha dimostrato che non è necessariamente così.

SWT è invece la libreria su cui è basato Eclipse. E' Java, ma è un wrap sulle API native del sistema ospite per cui, da un certo momento in poi, il rendering è affidato al sistema operativo, e la resa grafica è esattamente quella nativa. Ne beneficiano anche le performance, basta confrontarne lo stack delle chiamate con uno Swing.
C'è da dire che però SWT è molto meno usato di Swing, e questo si riflette nella qualità e quantità di codice. Swing ha, oltre al citato Netbeans/Matisse, anche Spring RCP, un'altra delle perle di Spring Framework, che però mi pare stia languendo. Bene, una scelta in meno :-)
Poi ci sarebbe Groovy SwingBuilder, un'aggeggino molto interessante, oppure Griffon che promette molto bene ma è ancora alla versione 0.0.1(!!).
Sul lato SWT c'è Groovy SWTBuilder ma caliamo un velo pietoso, e JFace. Basta.
JFace non è un vero e proprio framework, ma più che altro una serie di helper class per sveltire i lavori ripetitivi con SWT. Inoltre ha JFace Databinding, per legare in maniera bidirezionale modelli e UI, che sembra fatto molto bene.

Tutti gli indizi portano a scegliere razionalmente Swing. Così ho scelto JFace/SWT :-)
I miei primi esperimenti non mi stanno deludendo, anche se la mancanza di un editor visuale si fa sentire. Però c'è MigLayout, e la sensazione è che forse un tool visuale fa più danni che altro. Basta dare un'occhiata al codice generato da Matisse (non per la qualità, ma per la quantità).
All'inizio si risparmia molto tempo, a lungo andare il codice diventa un papocchio.

Non è finita: per chi ha voglia di emozioni forti ci sono Netbeans Platform e Eclipse RCP. In pratica si prendono gli scheletri base dei due ambienti (concepiti alla base per essere contenitori generici di plugin di vario tipo, per capirci l'intero Java IDE di Eclipse è un grosso insieme di plugin) e si arricchiscono con i vari plugin forniti assieme per creare software di qualsiasi livello (non certo i gestionali per la pizzeria, comunque). Entrambi gli ambienti snocciolano esempi di tutto rispetto.

Dietro i già molti prodotti che ho citato ne ho visto almeno altrettanti, alcuni interessanti (Java Builders, UFace) alcuni decaduti.
Non voglio fare il classico reazionario informatico (ah! il Clipper...ah! il Commodore 64...ah! l'Assembler), ma un pò mi manca il buon vecchio Delphi...

Il tecnofilo colpisce ancora

Approfittando di un viaggio negli Stati Uniti di un mio amico, ho preso il lettore dei lettori: il Cowon A3 con 60 GB di disco.
Grazie al cambio Euro/Dollaro la spesa complessiva è stata di € 270. Non mi dilungo sulle caratteristiche, dato che in giro si trovano recensioni a iosa. Sottolineo solo alcuni punti:
  • Il display lascia senza fiato
  • Anche l'audio
  • Anche la dotazione di cavi (non c'è collegamento che non sia contemplato da uno dei cavi inclusi)
  • Il software è ridicolmente spartano
  • La ricarica via USB è una chimera (e il caricabatterie è troppo ciccione per un dispositivo portable)
  • Però l'USB Host è una figata

venerdì 19 settembre 2008

Adoro lo spam


Adoro lo spam, inserito originariamente da Pietro Bonanno.

Alcuni, perlomeno :)

lunedì 1 settembre 2008

BeanKeeper, si diceva...

Con questo triste tentativo di riagganciarmi a quanto scritto 3 mesi fa, parlo un pò di BeanKeeper. Si trova poco in rete, e mi spiace. Questa libreria è semplice, razionale, con qualche chicca non facilmente ottenibile con le librerie più blasonate. Faccio qualche esempio: BK gestisce in maniera assolutamente trasparente il versioning del modello, ma anche dei dati (historical data). Ciò vuol dire che BK tiene traccia delle modifiche al modello (es. aggiunta o rimozione di property), ma anche delle modifiche ai dati. Come spiega la documentazione, le operazioni non avvengono mai sovrascrivendo dati esistenti, bensì aggiungendo i nuovi dati assieme ai vecchi. Con una banale sintassi, è possibile poi interrogare il DB nello stato in cui si trovava ad una certa data e ora nel passato. Niente male, anche se, pare, è un meccanismo non disattivabile e quindi sarebbe una ridondanza, dove non richiesto. Poi, gestisce nativamente cluster di webserver con la stessa applicazione che accede ad uno stesso DB:
L'oggetto Store che si occupa della persistenza, in un Web server, gira in un thread separato quindi è esso stesso un servizio raggiungibile dagli altri Store del cluster. Il più vecchio viene assunto a coordinatore del gruppo e gestisce transazioni e lock degli oggetti. Ancora una volta non serve nessun intervento da parte dello sviluppatore. In realtà c'è un piccolo effetto indesiderato: ogni volta che si fa un deploy della web application, si deve intercettare il servizio Store e chiuderlo. Chi usa Spring, può approfittare del ContextLoaderListener, necessario a inizializzare Spring MVC. Io ho definito una classe derivata, e ridefinito il metodo public void contextDestroyed(ServletContextEvent event):
    public void contextDestroyed(ServletContextEvent event) {

super.contextDestroyed(event);

XmlWebApplicationContext context = (XmlWebApplicationContext)WebApplicationContextUtils.getWebApplicationContext(servletContext);

context.refresh();

// A questo punto si recupera lo Store dal proprio context di Spring
Store store = ...

store.close();
}
L'utilizzo di tutti i giorni è veramente banale: qualsiasi JavaBean può essere salvato su DB con la semplice istruzione
store.save(theBean);
non serve altro. BK si collega al DB, crea le tabelle se non esistono (tra cui un discreto numero di tabelle di supporto), e inserisce i dati. Se il vostro bean contiene una legame 1-M con un altro bean (per esempio una proprietà di tipo List), BK si occupa della persistenza anche di questa (e di tutti i bean contenuti). Al caricamento, la lista verrà gestità come una LazyList, un'implementazione di List che carica gli oggetti a lotti di 30, solo se fisicamente richiesti. Tanta semplicità ha i suoi lati oscuri:
  • le operazioni di lettura e scrittura in genere coinvolgono più operazioni (dettagliatamente descritte nella documentazione), necessarie a mantenere tutta una serie di metadati
  • molte funzionalità non sono configurabili (es. il lazy loading, il clustering, ...)
  • i caricamenti dei bean soffrono del problema N+1 SELECT: se una classe A ha una relazione 1-M con una classe B, il caricamento di un'istanza della classe A comporta 1 SELECT per essa più N SELECT per le N istanze di classe B (totale N+1 SELECT). Se si carica poi una lista di K istanze di classe A, il numero di query diventa K*(N+1) il che diventa rapidamente ingestibile. Hibernate, per esempio, permette di gestire il problema attraverso outer join (un solo gigantesco caricamento). Purtroppo BK non offre alternative...
  • il supporto è ottimo, ma la comunità è inesistente. La mailing list conta una decina di post al mese. Di conseguenza l'uso in software critici ne viene scoraggiato e qualche baco di tanto in tanto affiora.
Io l'ho usato in un progetto non particolarmente complesso, con piccole esigenze di persistenza. In queste condizioni BK si sta comportando ottimamente, risparmiandomi ore di lavoro senza nessuna reale contropartita. Per progetti Web non vitali e per software client gestionali medio-piccoli è l'ideale. Lo stesso autore Robert Brautigam ne incoraggia l'uso in problematiche semplici, mentre non lo reputa adatto a progetti complessi. Tanto di cappello alla sua onestà intellettuale.

Prova di invio da Google Documenti

Questo post è scritto su Google Documenti e poi postato attraverso la funzione Pubblica. E' abbastanza semplice: dalla pagina di scrittura del documento, si preme su Condividi>Pubblica come pagina web... Qui, la prima volta che si usa il servizio, bisogna specificare la posizione del proprio blog (sia hosted che sul proprio spazio) e le credenziali di accesso. Le volte successive, basta tornare su Condividi>Pubblica come pagina web... e premere su Pubblica sul blog. Se poi servisse una modifica a livello più basso, ad esempio per modificare il CSS, basta andare sul menù Modifica>Modifica HTML. In questo modo posso abilitare i CSS per i frammenti di codice che pubblico:
<prova>
<di>
<formattazione>
<XML/>
</formattazione>
</di>
</prova>

Questo potrebbe consentirmi di togliermi dai piedi l'editor di Blogger, scomodo e (almeno mi sembra) bacato.

Update: Qualche ritocco da Blogger serve cmq, a livello di formattazione del testo (molto poco) e di inserimento delle etichette, ma direi che l'esperimento è riuscito :-)

venerdì 30 maggio 2008

Prêt-à-portlét

Il progetto su cui sto lavorando adesso prevede un portale B2B da cui un fornitore può offrire dei microservizi ad altre, fornendogli i relativi moduli per la configurazione e l'inserimento dei dati necessari al servizio stesso.
Dopo un giro tra le alternative ho optato per Liferay, un prodotto che conoscevo ma che non immaginavo fosse arrivato al livello a cui è.
Probabilmente è anche sovrabbondante per gli scopi del progetto, però supporta lo standard JSR-168, che consente di scrivere portlet indipendenti dal portale in cui vengono pubblicati.
Per chiarire meglio, un portale JSR-168 consente di ospitare nelle proprie pagine delle portlet, ovvero delle porzioni di pagina Web autonome che implementano un servizio (news, quotazioni di borsa, ma anche un blog, un wiki o un forum).
Un esempio di portlet è questo.

Scelta la tecnologia e il portale, mi mancava ancora il framework per implementare le portlet. Liferay ha un proprio approccio, ma lo trovo pesante e di certo non orientato a produrre portlet indipendenti dal portale.

Così ho scelto Spring MVC Portlet. Non conoscevo Spring MVC, ma conosco Spring. Spring è Il Framework. E' l'infrastruttura più leggera ed elastica che abbia mai provato. Migliora in maniera drastica la produttività e la qualità del codice pur rimanendo leggero e discreto. E' come Alfred per Bruce Wayne :).

Spring MVC Portlet è stata l'ennesima conferma. Dopo una configurazione iniziale non banale, ma logica, scrivere portlet è stata un'esperienza gratificante.
Spring MVC Portlet è organizzato come Spring MVC e ne riutilizza delle parti:

L'immagine è tratta dalla documentazione di Spring MVC, ma per grandi linee descrive bene anche Spring MVC Portlet.
Il gestore di tutto è il Front Controller (chiamato DispatcherPortlet nel framework) che riceve le richieste e le smista ai Controller o alle View.
Le regole di smistamento sono gestite in maniera limpida attraverso la configurazione XML.
Uno dei problemi è stato interagire con Liferay. E' vero che esiste lo standard, ma tanti servizi, come la gestione degli utenti, la fase di autenticazione, ecc sono lasciate ai vendor. Così ho seguito lo Spring-pensiero: ho implementato una interfaccia PortalSupport con le varie richieste di servizio al portale, e poi una sua implementazione LiferaySupport, che è definita nel context della portlet:


<bean id="portalSupport" class="example.theportlet.portal.liferay.LiferayPortalSupport">
</bean>


In questo modo, una classe che deve interagire con il portale dichiara una proprietà di tipo PortalSupport:


private PortalSupport portalSupport;

public PortalSupport getPortalSupport() {
return portalSupport;
}

public void setPortalSupport(PortalSupport portalSupport) {
this.portalSupport = portalSupport;
}


e dal context posso iniettare la particolare implementazione dove serve:


<bean id="baseControllerTemplate" abstract="true">
<property name="portalSupport" ref="portalSupport"/>
</bean>


Semplice, elegante, chiaro. Che è anche l'essenza di Spring.

Infine mi sono occupato della persistenza. Nei tipi di servizi da realizzare, il dominio dei dati è molto semplice, non più di 5-6 entità, con le classiche associazioni una a molti, uno a uno, ecc.
Non mi andava di usare Hibernate, francamente troppo complesso per un problema del genere, ma neanche SQL puro con tutti i suoi problemi di dialetti, script di DDL ecc.
Così, cercando, ho trovato Beankeeper. Signori, che ne dite di una libreria a cui basta dire:


store = new Store("org.hsqldb.jdbcDriver","jdbc:hsqldb:file:testdb");

Person person = new Person();
person.setFirstName(firstName);
person.setLastName(lastName);
store.save(person);


per salvare su DB il bean Person? Nota bene, non c'è codice nascosto né operazioni a priori. Si prende un DB vuoto, si prende il primo bean che passa, lo si passa a BeanKeeper e lui crea le tabelle analizzando il bean e lo salva. Punto. Stop.
Supporta automaticamente relazioni, ereditarietà, caricamento lazy, e ha un semplice linguaggio OQL.

Non è tutto rose e fiori, ma ne scriverò in un post a parte.

venerdì 23 maggio 2008

Geotagging di una nuvola


Geotagging di una nuvola, inserito originariamente da Pietro Bonanno.


Questa nuvola è stata geotaggata utilizzando Nokia Location Tagger con il mio Nokia N80 e un ricevitore GPS Bluetooth accoppiato.
L'utilizzo è abbastanza semplice. Si installa il programmino, si esegue e si lascia girare in background. Ogni foto scattata con il normale software della fotocamera verrà completato con le indicazioni di georeferenziazione. Attenzione, non funziona con la fotocamera secondaria.

Purtroppo su Flickr qualcosa sembra non funzionare: le coordinate vengono arrotondate a 38°0' 00" N, 13°0' 00" E. Basta vedere la pagina dei metadati per accorgersi che in realtà sono 38° 9' 27" N, 13° 18' 56" E, per cui l'immagine da Palermo va a finire ad Alcamo!

Nei forum si sostiene che ciò sia dovuto al software di upload Nokia Online Share. Non so neanche cosa sia, io ho usato il normale form di upload di Flickr.

L'assistenza mi ha dato l'improbabile risposta che il problema sia dovuto ad errori nelle mappe, fornite da terzi. E' abbastanza assurdo perchè si vede benissimo l'errore di troncamento.

Infine, la stessa foto su Picasa Web è georeferenziata correttamente.

venerdì 11 aprile 2008

Eccolo!

Eccolo qua, la tentazione è stata troppo forte... il cambio Euro-Dollaro ha fatto il resto.

Acquistato a $ 280 + $ 40 di spedizione (UPS, impeccabili) su B&H Photo, al cambio sono poco più di € 200, esattamente il mio punto di rottura per cedere all'acquisto.

E' come me l'aspettavo, un prodotto funzionale, comodo ma non ancora allo stato dell'arte.

Il problema è sopratutto nella tecnologia E-ink, ancora troppo giovane. Il contrasto è perfetto e sembra di leggere una vera pagina cartacea, ma i tempi di refresh sono nell'ordine del secondo.

Questo non rende difficoltosa la lettura, ma le modalità d'interazione. Non ho la certezza, ma da sviluppatore posso pensare che un tempo di refresh così lungo abbia creato non pochi problemi a chi ha concepito l'interfaccia utente. Infatti mancano funzioni come la ricerca testuale (né dei titoli, né all'interno del testo), o segnali visivi di feedback quando premi i vari pulsanti. Invece hanno utilizzato una fila di 10 pulsanti per selezionare l'elemento corrispondente in una lista.

Una soluzione che è un buon compromesso, comoda e intuitiva.

I pulsanti per scorrere le pagine sono sia a destra che a sinistra, quindi è facile leggere un libro nelle più svariate posizioni (con un libro cartaceo servirebbero tutte e due le mani :-) ).

Uso libprs500 come applicazione per caricare e catalogare gli ebook, non ho neanche provato a usare quello fornito da Sony. Questo software è open source, immediato e ricco di funzioni (tra cui l'utilissima conversione nei vari formati per ebook). Indispensabile.

Il problema più grave è il supporto ai PDF. Per dare un'idea, questa è la resa di una pagina in PDF al massimo ingrandimento:

Questo è invece un ebook in formato LRS (un formato proprietario Sony), al minimo ingrandimento:
Il problema dei PDF è noto, ed esiste anche qualche soluzione (che non ho ancora provato).

In ogni caso per € 200 è senza dubbi un buon acquisto.

martedì 8 aprile 2008

Perchè il mio tavolo di Google cerca il Internet del contatto?

Ora, capisco che i traduttori automatici sono un modo semplice ed economico per attirare qualche lettore nel proprio sito. La traduzione è quella che è, ma anche il proprio sito è quello che è.

Ma perché farlo in un blog che parla di programmazione??

Magari perchè vendo un software di traduzione automatica? Spero di farmi pubblicità con traduzioni del genere?

Hai cercato Master-Master replica (bi-direzionale di replica master-slave), per MySQL? Io sono me stesso e trovare una posizione in cui ho bisogno di avere questa replica a sostenere il carico sul mio blog e siti.

Openfire (assistente di Jabber/XMPP) per difetto si lega su orificio 8080 che inoltre è usato da Tomcat. Ciò induce Tomcat a venire a mancare quando il openfire è iniziato prima di esso. (orificio?? NdPB)

La comunicazione fra i Java applei È stata un soggetto interessante dai giorni in anticipo di Java. Ci sono parecchi sensi esoterici comunicare come usando il Javascript come ponticello. Tuttavia esamineremo il metodo attendibile più semplice e della comunicazione del intra-applet.


Usi un codice categoria con i metodi statici degli incastonatori e dei degasatori per passare i dati intorno.

Avete saputo che persino l'adobe Photoshop funziona in Linux usando il vino?
Il vino può eliminare il vostro dolore di espansione da Windows (a Linux).

venerdì 28 marzo 2008

Ma sanno leggere?


Ho intenzione di acquistare un EBook Reader Sony PRS-505, un aggeggino che sembra ben riuscito, a leggere i giudizi un pò ovunque.

Purtroppo pare che non sia commercializzato fuori USA, così ho fatto la solita incursione su EBay.

Ora, esiste una logica per cui io dovrei acquistare su EBay a prezzi più alti che nel sito Sony? NB: ci sono dei pezzi a 270$ venduti da un certo hypatiaway, ma gli ho scritto e non ha risposto. Non rischio 300$ così...

Capisco il desiderio di averne uno da chi non abita negli USA, ma l'alternativa c'è eccome...

venerdì 7 marzo 2008

Evidenziazione della sintassi su Blogger

Mi sono finalmente deciso a configurare Blogger per visualizzare blocchi di codice formattato. Ho utilizzato SyntaxHighlighter, un ottimo tool javascript che agisce tramite CSS.


Ho seguito le istruzioni sul blog Morten Lyhr e tutto ha funzionato egregiamente. L'unico piccolo problema è individuare lo spazio web dove sistemare gli script da utilizzare poi nei post.

Lui ha preferito utilizzare le directory SVN di Google Code.
Io trovo più naturale utilizzare invece lo spazio dedicato a Google Pages. Con una semplice interfaccia Web si caricano sullo spazio i vari script e si includono poi nel template in maniera diretta (per es. http://piebonanno.googlepages.com/shCore.js).

Per festeggiare, ho riconvertito il mio post su Hibernate e dialetti SQL. Il risultato non è ancora ottimale, ma è già un passo avanti.

update 30/05/2008: Ho sostituito SyntaxHighlighter con Prettify, mi piace di più.

giovedì 6 marzo 2008

...



Non ce la faccio. Non ci riesco. Svengo.

giovedì 10 gennaio 2008

Bibliografia essenziale


Bibliografia essenziale, inserito originariamente da Pietro Bonanno.

martedì 8 gennaio 2008

Post autoreferenziale

Con una notevole faccia tosta, dopo un'assenza di settimane da questo blog, pubblico il mio Curriculum Vitae.

Essendo questo (almeno nelle intenzioni) un blog tecnico che riguarda la mia professione, mi sembrava una mancanza non da poco.
Spero anche di scrivere qualcosa, in particolare sulla pratica del continuous integration che vorrei mettere in piedi anche per piccoli progetti (team da 2-4 persone).
Intanto sto assemblando i vari tool che aiutano nel processo: in breve, Maven 2, un server SVN, Continuum e, almeno per i test, un semplice SMTP server. Mi pare non serva altro, a parte i framework di test.
Anzi se qualcuno volesse chiaccherarne (anche in privato), ne sarei lieto.