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 :-)