Per qualche tempo ho girato intorno a Maven, senza capire bene cosa fosse e come potessi usarlo per i miei progetti: poi ho provato ad usarlo, e me ne sono letteralmente innamorato.
Intanto diciamo cosa è Maven: "Apache Maven é un tool per la software project management and comprehension. Basato sul concetto di Project Object Model (POM), Maven può gestire build, reporting e documentazione di un progetto, da un punto centrale di informazione" Questa è la definizione (magari mal tradotta) dal sito Apache Software Foundation. Ma in pratica, cosa fa Maven? Gestisce, da un solo file di configurazione, la struttura e le dipendenze di progetto ed aiuta ad automatizzare le fasi di build, test, documentazione e in alcuni casi deploy di un progetto.
Facciamo un esempio: a me piace usare Spring per il mio sviluppo. E' un framework potente, flessibile, ma ha una grossa complicazione. La gestione delle dipendenze. Non è facile ricordarsi di includere tutte le dipendenze, se si usa una repository non è comodo aggiungere i jar o definire un posto dove metterli. Maven risolve proprio questo aspetto: nel file descrittore del progetto basta indicare come dipendenza Spring e maven si occuperà di scaricare tutte le dipendenze dal repository appropriato, compilare i sorgenti e impacchettarli nel modo corretto. Inoltre, ed ancor prima di questo, definisce una struttura standard per i progetti: si può quindi lavorare allo stesso progetto con Eclipse piuttosto che con Netbeans senza dover stravolgere la struttura dei sorgenti.
E questo è solo l'inizio. Se avrò tempo mi piacerebbe fare un esempio su come usare Maven per i progetti GWT, perché ci sono piccoli accorgimenti da usare.
martedì 27 dicembre 2011
martedì 13 dicembre 2011
domenica 6 novembre 2011
venerdì 28 ottobre 2011
venerdì 21 ottobre 2011
giovedì 13 ottobre 2011
martedì 4 ottobre 2011
giovedì 8 settembre 2011
Il corretto uso dell'If
Molto spesso mi trovo a leggere codice di altri. Personalmente ritengo che scrivere codice sia come scrivere in lingua, a parte i formalismi. Per quanto mi riguarda sono molto coinciso nello scrivere frasi, periodi brevi, poche subordinate. Allo stesso modo, quando scrivo codice, mi piace essere il più coinciso possibile.
Riguardo all'uso di if preferisco non farne in cascata, se non strettamente necessario, ritenendo questo tipo di codice brutto da vedere e lento da eseguire.
Del mio stesso avviso sono quelli di AntiIfCampaign, al grido di "less if, more power!"
E voi, quanti if usate?
Riguardo all'uso di if preferisco non farne in cascata, se non strettamente necessario, ritenendo questo tipo di codice brutto da vedere e lento da eseguire.
Del mio stesso avviso sono quelli di AntiIfCampaign, al grido di "less if, more power!"
E voi, quanti if usate?
martedì 30 agosto 2011
venerdì 26 agosto 2011
Un tranquillo sabato di fanatismo informatico.
Sabato scorso era caldo, ero in città e per trovare un po' di fresco sono andato a vedere il nuovo negozio di una famosa marca appena inaugurato.
Entro e due commessi mi augurano il buongiorno. Finalmente un po' di civiltà in un mare di ignoranza, penso: non capita spesso infatti che i commessi diano il buongiorno al cliente.
Comincio a girare fra i tavoli, vedo che ad uno c'è una dimostrazione di prodotto ma non ho voglia di ascoltarla e gironzolo un po', tanto per capire che aria tira. Ad un certo punto sento partire un applauso, mi giro e vedo che i commessi stanno applaudendo ad un nuovo possessore. Penso che, essendo di natura timido, mi vergognerei di essere applaudito, ma evidentemente quando acquisti un prodotto della famosa marca entri a far parte di una famiglia e vieni acclamato per questo.
Ad un tavolo vedo un portatile libero, mi metto a guardare le caratteristiche e a provare ad usarlo. Un commesso gentile mi si avvicina e mi chiede se ho bisogno di informazioni
Io: "Volevo capire se è possibile aprire il terminale"
C.: "Si, lanci il finder e lo apri, si fa così. Ma tu usi molto il terminale?"
Io: "Sai, sono uno sviluppatore, il terminale è comunque la mia ancora di salvezza"
C.: "Ah bello, e in cosa sviluppi?"
Io: "Java, C#..."
C.: "Allora hai fatto anche qualcosa per Android?"
Io: "Niente di concreto, ma ho guardato gli esempi e fatto qualche prova"
C.: "Hai provato a sviluppare per iPad?"
Io.: "Ho visto gli esempi anche li, ma niente di più"
C.: "A livello di Look&Feel avrai visto che è migliore."
Io: "Si certo, però ObjectiveC è un linguaggio più difficile da gestire che non il Java, i tempi di sviluppo sono più lunghi"
C.: "Beh, però in questo caso forse sei tu che non sei abbastanza esperto, devi studiare di più"
Io: "Può darsi. Ora ti saluto, grazie di tutto"
C.: "Grazie a te, buona giornata"
Ora, io non sono esperto di ObjectiveC, però tra un linguaggio dove devo ricordarmi di disallocare i puntatori e uno dove me ne frego altamente di liberare la memoria perché viene gestita dalla macchina virtuale, quale pensate che sia più produttivo?
Bisognerebbe forse dare una maggiore infarinatura ai tecnici su come funzionano le cose, ed essere un po' più obbiettivi.
Entro e due commessi mi augurano il buongiorno. Finalmente un po' di civiltà in un mare di ignoranza, penso: non capita spesso infatti che i commessi diano il buongiorno al cliente.
Comincio a girare fra i tavoli, vedo che ad uno c'è una dimostrazione di prodotto ma non ho voglia di ascoltarla e gironzolo un po', tanto per capire che aria tira. Ad un certo punto sento partire un applauso, mi giro e vedo che i commessi stanno applaudendo ad un nuovo possessore. Penso che, essendo di natura timido, mi vergognerei di essere applaudito, ma evidentemente quando acquisti un prodotto della famosa marca entri a far parte di una famiglia e vieni acclamato per questo.
Ad un tavolo vedo un portatile libero, mi metto a guardare le caratteristiche e a provare ad usarlo. Un commesso gentile mi si avvicina e mi chiede se ho bisogno di informazioni
Io: "Volevo capire se è possibile aprire il terminale"
C.: "Si, lanci il finder e lo apri, si fa così. Ma tu usi molto il terminale?"
Io: "Sai, sono uno sviluppatore, il terminale è comunque la mia ancora di salvezza"
C.: "Ah bello, e in cosa sviluppi?"
Io: "Java, C#..."
C.: "Allora hai fatto anche qualcosa per Android?"
Io: "Niente di concreto, ma ho guardato gli esempi e fatto qualche prova"
C.: "Hai provato a sviluppare per iPad?"
Io.: "Ho visto gli esempi anche li, ma niente di più"
C.: "A livello di Look&Feel avrai visto che è migliore."
Io: "Si certo, però ObjectiveC è un linguaggio più difficile da gestire che non il Java, i tempi di sviluppo sono più lunghi"
C.: "Beh, però in questo caso forse sei tu che non sei abbastanza esperto, devi studiare di più"
Io: "Può darsi. Ora ti saluto, grazie di tutto"
C.: "Grazie a te, buona giornata"
Ora, io non sono esperto di ObjectiveC, però tra un linguaggio dove devo ricordarmi di disallocare i puntatori e uno dove me ne frego altamente di liberare la memoria perché viene gestita dalla macchina virtuale, quale pensate che sia più produttivo?
Bisognerebbe forse dare una maggiore infarinatura ai tecnici su come funzionano le cose, ed essere un po' più obbiettivi.
mercoledì 10 agosto 2011
giovedì 4 agosto 2011
Run Jetty Run
"running a web application in Eclipse should be as simple as 'clicking run' "
Anch'io l'ho sempre pensata così, e la gestione dei server in Eclipse mi era sempre sembrata tanto pesante. E' vero, strutturata in quel modo puoi incastrarci dentro qualsiasi server anche molto complesso, tipo JBoss o WebSphere, ma manca molto di immediatezza.
Se si vogliono fare cose semplici, o si decide di usare piattaforme di base, non c'è un modo "veloce" in Eclipse per configurare il tutto.
Con Run Jetty Run, invece, con un semplice click si può far partire una applicazione web in maniera semplice e leggera.
L'ho trovato veramente molto comodo, e usando maven per creare l'archetipo di progetto mi permette di fare veramente in un batter d'occhio.
Anch'io l'ho sempre pensata così, e la gestione dei server in Eclipse mi era sempre sembrata tanto pesante. E' vero, strutturata in quel modo puoi incastrarci dentro qualsiasi server anche molto complesso, tipo JBoss o WebSphere, ma manca molto di immediatezza.
Se si vogliono fare cose semplici, o si decide di usare piattaforme di base, non c'è un modo "veloce" in Eclipse per configurare il tutto.
Con Run Jetty Run, invece, con un semplice click si può far partire una applicazione web in maniera semplice e leggera.
L'ho trovato veramente molto comodo, e usando maven per creare l'archetipo di progetto mi permette di fare veramente in un batter d'occhio.
giovedì 14 luglio 2011
JasperSoft rilascia il nuovo JasperSoft Studio, ora basato su Eclipse
https://plus.google.com/103382324948491753575/posts/315NP6NVHJP
sabato 2 luglio 2011
WCF Basic Authentication
Ultimamente ho avuto a che fare con un WebService che richiede esplicitamente la Basic Authentication.
Il mio client è in C# .Net 4.0, e quindi usa le Windows Communication Foundation.
Il protocollo HTTP, per quanto riguarda la Basic Authentication assume che il client debba authenticarsi con una username ed una password per ciascun realm (vedi qua). In pratica deve essere aggiunto, in modo esplicito uh Header alla chiamata HTTP contenente username e password encodate in base64.
Per un WebService client pensavo che fosse sufficiente impostare il tipo di autenticazione (Basic) e settare le credenziali. Purtroppo, facendo la chiamata, ottenevo sempre un errore di autenticazione. Verificando con un proxy http il messaggio che viene composto, mi sono accorto che l'Header non viene aggiunto automaticamente alla chiamata. Non ho verificato, lo ammetto, se questo è un bug del framework .Net o se è il comportamento standard.
Il problema si risolve comunque aggiungendo l'Header "a mano" nella chiamata. Per i WebServices WCF non si usa direttamente l'oggetto client, ma si lavora sull'operation scope, acquisendo da qui la request ed aggiungendo a questa l'autenticazione. L'esempio me lo ha dato questo articolo, che ringrazio dal profondo del cuore.
English translation here
Il mio client è in C# .Net 4.0, e quindi usa le Windows Communication Foundation.
Il protocollo HTTP, per quanto riguarda la Basic Authentication assume che il client debba authenticarsi con una username ed una password per ciascun realm (vedi qua). In pratica deve essere aggiunto, in modo esplicito uh Header alla chiamata HTTP contenente username e password encodate in base64.
Per un WebService client pensavo che fosse sufficiente impostare il tipo di autenticazione (Basic) e settare le credenziali. Purtroppo, facendo la chiamata, ottenevo sempre un errore di autenticazione. Verificando con un proxy http il messaggio che viene composto, mi sono accorto che l'Header non viene aggiunto automaticamente alla chiamata. Non ho verificato, lo ammetto, se questo è un bug del framework .Net o se è il comportamento standard.
Il problema si risolve comunque aggiungendo l'Header "a mano" nella chiamata. Per i WebServices WCF non si usa direttamente l'oggetto client, ma si lavora sull'operation scope, acquisendo da qui la request ed aggiungendo a questa l'autenticazione. L'esempio me lo ha dato questo articolo, che ringrazio dal profondo del cuore.
English translation here
lunedì 16 maggio 2011
martedì 10 maggio 2011
venerdì 6 maggio 2011
mercoledì 4 maggio 2011
Quale sarà la fine di Mono?
Dopo l'acquisto di Novell da parte di Attachmate, sono stati "liberati" un numero imprecisato di sviluppatori che lavoravano al progetto Mono. Quale sarà ora il suo destino?
http://blog.internetnews.com/skerner/2011/05/attachmate-lays-off-mono-emplo.html
http://blog.internetnews.com/skerner/2011/05/attachmate-lays-off-mono-emplo.html
giovedì 28 aprile 2011
lunedì 18 aprile 2011
domenica 17 aprile 2011
Gestire il file Upload con Spring
Fare del file upload non è mai stata un'operazione facile, o comunque abbastanza automatica. Si deve creare una servlet e scodare il file dai parametri di request del form.
Usando Spring ho visto che è stato molto semplificato il file Upload, e l'operazione si incastra nel meccanismo della DispatcherServlet e dell'ApplicationContext.
In pratica nell'Application Context basta aggiungere un'istanza della classe org.springframework.web.multipart.commons.CommonsMultipartResolver
Questa classe, quando intercetta una post action con encoding attribute multipart/form-data, la gestisce e trasforma il file in un request parameter di tipo MultipartHttpServletRequest o MultipartFile
Così trasformata la request viene passata al controller, dichiarando come parametri di input il file e gli altri parametri dichiarati nella form.
Usando Spring ho visto che è stato molto semplificato il file Upload, e l'operazione si incastra nel meccanismo della DispatcherServlet e dell'ApplicationContext.
In pratica nell'Application Context basta aggiungere un'istanza della classe org.springframework.web.multipart.commons.CommonsMultipartResolver
Questa classe, quando intercetta una post action con encoding attribute multipart/form-data, la gestisce e trasforma il file in un request parameter di tipo MultipartHttpServletRequest o MultipartFile
Così trasformata la request viene passata al controller, dichiarando come parametri di input il file e gli altri parametri dichiarati nella form.
giovedì 14 aprile 2011
lunedì 11 aprile 2011
Si diventa internazionali
Ho deciso di tradurre quegli articoli che secondo me sono di maggior interesse anche in inglese.
Per me è una sfida, sia per la lingua che per i contenuti, speriamo porti soddisfazione.
Questo il link
Per me è una sfida, sia per la lingua che per i contenuti, speriamo porti soddisfazione.
Questo il link
mercoledì 6 aprile 2011
martedì 5 aprile 2011
Five Predictions for your Database in 2011
http://cloud.dzone.com/news/five-predictions-your-database
lunedì 4 aprile 2011
Stampanti HP con supporto Google Cloud Print
http://www.ictbusiness.it/cont/news/stampanti-hp-con-supporto-google-cloud-print/26473/1.html
domenica 3 aprile 2011
Google Datastore e l'annotation @Unique
E' ormai ufficiale che mi sto gingillando da un bel po' con La Google App Engine. Qundo avrò qualcosa di minimamente presentabile vi dirò anche perché.
Devo dire che trovo un bel po' di problemi a lavorare con il Datastore. Sarà che non sono capace, oppure sarà che il prodotto è ancora giovane, ma ogni tanto ci scappa fuori il bug.
L'ultimo è stato l'uso della annotation @Unique nelle entità. Secondo le specifiche JDO questa annotation serve a creare una chiave univoca sulla proprietà a cui si applica. Ad esempio se ho la classe Author fatta così
Come fare quindi? Per fortuna la Key può anche essere generata, non solo calcolata automaticamente: si può quindi seguire questo metodo. Se si segue il pattern Dao si avrà sempre una classe per gestire le entità. Nel mio caso la classe si chiama, con molta fantasia, AuthorDao e, prima di salvare l'entità sarà sufficiente calcolare la chiave nel seguente modo
In questo modo la chiave sarà la stessa a parità di nome, e quindi sarà garantita l'univocità.
Devo dire che trovo un bel po' di problemi a lavorare con il Datastore. Sarà che non sono capace, oppure sarà che il prodotto è ancora giovane, ma ogni tanto ci scappa fuori il bug.
L'ultimo è stato l'uso della annotation @Unique nelle entità. Secondo le specifiche JDO questa annotation serve a creare una chiave univoca sulla proprietà a cui si applica. Ad esempio se ho la classe Author fatta così
@PersistenceCapable
public class Author {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key id;
@Persistent
@Unique
private String name;
... omessi getters e setters
}
il Datastore dovrebbe creare una chiave univoca sulla proprietà Name. Facendo qualche test mi sono accorto che questo non succede. Ho cercato un po' per vedere se qualcuno ha avuto i miei stessi problemi ed ho trovato questo. Il comportamento riscontrato è quindi un bug riconosciuto.Come fare quindi? Per fortuna la Key può anche essere generata, non solo calcolata automaticamente: si può quindi seguire questo metodo. Se si segue il pattern Dao si avrà sempre una classe per gestire le entità. Nel mio caso la classe si chiama, con molta fantasia, AuthorDao e, prima di salvare l'entità sarà sufficiente calcolare la chiave nel seguente modo
In questo modo la chiave sarà la stessa a parità di nome, e quindi sarà garantita l'univocità.
mercoledì 30 marzo 2011
martedì 15 marzo 2011
Google App Engine e le relazioni
Visto che voglio capire di più su come sono fatte le api Google App Engine per il DataStore mi sono chiesto: "come si gestiscono le relazioni?"
La pagina che spiega tutto è questa. In pratica la limitazione più forte che ho riscontrato è che, per creare una relazione tra due entità queste devono avere come chiave primaria un oggetto di tipo Key: questo perché l'oggetto Key supporta le informazioni sulla parent key. Leggendo la documentazione su Key si legge che "If the class is used as a "child" class in a relationship, the key field must be of a type capable of representing an entity group parent: either a Key instance, or a Key value encoded as a string." Evidentemente il meccanismo di storage delle informazioni ha bisogno di creare legami tra le classi, e questo è l'unico modo che ha per farlo.
Speriamo in futuri miglioramenti.
La pagina che spiega tutto è questa. In pratica la limitazione più forte che ho riscontrato è che, per creare una relazione tra due entità queste devono avere come chiave primaria un oggetto di tipo Key: questo perché l'oggetto Key supporta le informazioni sulla parent key. Leggendo la documentazione su Key si legge che "If the class is used as a "child" class in a relationship, the key field must be of a type capable of representing an entity group parent: either a Key instance, or a Key value encoded as a string." Evidentemente il meccanismo di storage delle informazioni ha bisogno di creare legami tra le classi, e questo è l'unico modo che ha per farlo.
Speriamo in futuri miglioramenti.
martedì 8 marzo 2011
lunedì 28 febbraio 2011
Come migrare da Weblogic o Websphere a Tomcat
sabato 26 febbraio 2011
Google AppEngine e le Query in Java
Ho giocato un po' con Google App Engine.
In particolare ho cercato di capire come funziona la gestione del database da un'applicazione Java.
Google App Engine store i suoi dati su quello che viene chiamato Datastore. Il Datastore azzera totalmente per l'utente la gestione di replica, bilanciamento di carico e backup, che è tutta a carico dell'infrastruttura.
L'accesso ai dati viene quindi fatto attraverso un set di API, rese disponibili da Google. Sopra queste API è stato creato un meccanismo che permette di accedere ai dati in due modi standard: o via JPA, le Java Persistence API delle specifiche J2EE, o via JDO, i Java Data Objects di Apache.
Queste due tipologie di accesso vengono rese disponibili attraverso il framework DataNucleus, che si occupa di tradurre (fra l'altro in fase di compilazione) la gestione degli oggetti di persistenza.
La documentazione di Google focalizza i suoi esempi sull'uso di JDO, che non conoscevo, e che quindi mi ha stuzzicato l'appetito.
Per fare un test ho provato a creare una classe Author, con le sole proprietà id e name, fatta così
In particolare ho cercato di capire come funziona la gestione del database da un'applicazione Java.
Google App Engine store i suoi dati su quello che viene chiamato Datastore. Il Datastore azzera totalmente per l'utente la gestione di replica, bilanciamento di carico e backup, che è tutta a carico dell'infrastruttura.
L'accesso ai dati viene quindi fatto attraverso un set di API, rese disponibili da Google. Sopra queste API è stato creato un meccanismo che permette di accedere ai dati in due modi standard: o via JPA, le Java Persistence API delle specifiche J2EE, o via JDO, i Java Data Objects di Apache.
Queste due tipologie di accesso vengono rese disponibili attraverso il framework DataNucleus, che si occupa di tradurre (fra l'altro in fase di compilazione) la gestione degli oggetti di persistenza.
La documentazione di Google focalizza i suoi esempi sull'uso di JDO, che non conoscevo, e che quindi mi ha stuzzicato l'appetito.
Per fare un test ho provato a creare una classe Author, con le sole proprietà id e name, fatta così
Le annotations contenute in questa classe consentono a DataNucleus di mappare la classe su una tabella.
Le chiavi primarie per il DataStore sono di tre tipi: Long, Key (un tipo dati custom del DataStore) o String: questo tipo di dati in particolare deve essere gestito dall'applicativo, non viene mai calcolato automaticamente.
Il DataStore richiede che un oggetto abbia una chiave primaria.
Nel mio esempio non volevo usare una String come chiave primaria, ma volevo però che il nome fosse univoco, ed ho quindi taggato con l'annotation @Unique la proprietà name.
Per salvare un oggetto è sufficiente, ottenuto quello che si chiama un PersistenceManager, invocare il metodo makePersistent(Object o).
Ora, supponiamo di aver salvato una serie di autori che iniziano con la A, ad esempio Asimov, Aristotele, Alighieri e di volergli ritrovare.
Se stessi usando Hibernate recupererei una Session, aggiungerei Criteria e Restrictions oppure farei una Query in HSQL.
Con JDO, guardando la documentazione, si ottiene un oggetto Query e su quello si può usare il metodo setFilter o il linguaggio JDOQL, simile a HSQL.
Vediamo quindi come scrivere una query che trovi tutti gli autori che cominciano per A
Dall'esempio si vede che, recuperato il PersistenceManager attraverso una classe si utilità, si crea una Query e su quella, dichiarato che si stanno facendo query sulla classe Author, si applica un filtro.
La clausola SQL LIKE si esprime in JDOQL con.startsWith() e poi si dichiarano i parametri con la sintassi ;
Il metodo execute() della query recupera gli oggetti precedentemente salvati. Google App Engine ha un bug in questa operazione: quando gli oggetti vengono sganciati ("detached") dal DataStore, se si tenta di scorrere la List, viene lanciata un'eccezione. Bisogna quindi chiamare il metodo .size() prima di chiudere il PersistenceManager, per permettere il corretto caricamento di tutto l'array.
Tutto qua, per ora, il prossimo step sarà capire come gestire le relazioni 1-n e soprattutto come recuperare entità partendo dalla relazione figlia.
See You Next Time!!!
Le chiavi primarie per il DataStore sono di tre tipi: Long, Key (un tipo dati custom del DataStore) o String: questo tipo di dati in particolare deve essere gestito dall'applicativo, non viene mai calcolato automaticamente.
Il DataStore richiede che un oggetto abbia una chiave primaria.
Nel mio esempio non volevo usare una String come chiave primaria, ma volevo però che il nome fosse univoco, ed ho quindi taggato con l'annotation @Unique la proprietà name.
Per salvare un oggetto è sufficiente, ottenuto quello che si chiama un PersistenceManager, invocare il metodo makePersistent(Object o).
Ora, supponiamo di aver salvato una serie di autori che iniziano con la A, ad esempio Asimov, Aristotele, Alighieri e di volergli ritrovare.
Se stessi usando Hibernate recupererei una Session, aggiungerei Criteria e Restrictions oppure farei una Query in HSQL.
Con JDO, guardando la documentazione, si ottiene un oggetto Query e su quello si può usare il metodo setFilter o il linguaggio JDOQL, simile a HSQL.
Vediamo quindi come scrivere una query che trovi tutti gli autori che cominciano per A
Dall'esempio si vede che, recuperato il PersistenceManager attraverso una classe si utilità, si crea una Query e su quella, dichiarato che si stanno facendo query sulla classe Author, si applica un filtro.
La clausola SQL LIKE si esprime in JDOQL con
Il metodo execute() della query recupera gli oggetti precedentemente salvati. Google App Engine ha un bug in questa operazione: quando gli oggetti vengono sganciati ("detached") dal DataStore, se si tenta di scorrere la List, viene lanciata un'eccezione. Bisogna quindi chiamare il metodo .size() prima di chiudere il PersistenceManager, per permettere il corretto caricamento di tutto l'array.
Tutto qua, per ora, il prossimo step sarà capire come gestire le relazioni 1-n e soprattutto come recuperare entità partendo dalla relazione figlia.
See You Next Time!!!
giovedì 17 febbraio 2011
eXtreme Programming: le regole della semplicità
http://www.c2.com/cgi/wiki?XpSimplicityRules
Che altro dire? Magari si riuscisse a fare sempre un lavoro del genere! :-D
Che altro dire? Magari si riuscisse a fare sempre un lavoro del genere! :-D
lunedì 14 febbraio 2011
GWT 2.2 ed Eclipse Plugin ora disponibili
Google ha appena rilasciato una nuova versione di GWT e del plugin per Eclipse.
La notizia di maggior rilievo è che è stato integrato il GUI Designer nel plugin.
Inoltre sono stati migliorati il supporto per Html5 e le Api per CellTable
Creare partizioni in tempo reale: un errore comune
Josh Berkus, tra i fondatori di PostGreSQL, ci dice perchè, a suo avviso, è meglio non creare partizioni attraverso i trigger, ma schedulare, da bravi DBA, la creazione.
http://it.toolbox.com/blogs/database-soup/partition-at-insert-time-a-smart-mistake-44294?rss=1
http://it.toolbox.com/blogs/database-soup/partition-at-insert-time-a-smart-mistake-44294?rss=1
Iscriviti a:
Post (Atom)