La prima installazione di OpenSolaris 2009.11 sul mio portatile mi ha portato ad una situazione dove solo la scheda di rete Wireless era funzionante, mentre quella wired (Atheros AR8121) risultata dispersa. Nemmeno l'utility dei driver era in grado di fornirmi il driver per la suddetta scheda. Dopo qualche ricerca ho trovato che il pacchetto che fornire i driver per la mia scheda è SUNWatge, dove ovviamente at sta per Atheros mentre ge per gigabit ethernet. Il problema è che OpenSolairs 2009.11 è al ramo di sviluppo snv 111, mentre il pacchetto di cui sopra richiede il 130.
E' stato quindi necessario installare l'aggiornamento dal repository di sviluppo di OpenSolaris, facendo avanzare il sistema fino a snv 130, per poi poter installare il driver della scheda di rete. Per fare questo ho anzitutto aggiunto il repository di sviluppo, l'ho impostato come repository di default, ed ho ordinato un image-update del sistema.
lunedì 28 dicembre 2009
mercoledì 16 dicembre 2009
Un ComboBox per selezionare le viste di una applicazione RCP
In una applicazione RCP che sto sviluppando mi è capitato di avere molte viste, ciascuna che deve essere associabile ad una serie di permessi. Per permettere ad un utente amministratore di selezionare a quali viste concedere quali permessi, ho creato un semplice wrapper attorno ad un combo che contiene l'array delle viste disponibili e la loro descrizione. Il codice è abbastanza banale, ma potrebbe tornare utile in altre applicazioni.
public class ViewsCombo {
/**
* The combo that will be displayed.
*/
private Combo combo = null;
/**
* The available views in the system.
*/
private IViewDescriptor[] availableViews = null;
/**
* Initializes the combo and the map to contain the views.
* @param parent
*/
public ViewsCombo( Composite parent, String viewIDToSelect ){
super();
// create the combo
this.combo = new Combo( parent, SWT.READ_ONLY );
// fill the combo with the data
this.fillComboAndMap();
// select a view if specified
if( viewIDToSelect != null )
for( int i = 0; i < availableviews =" (IViewDescriptor[])">
public class ViewsCombo {
/**
* The combo that will be displayed.
*/
private Combo combo = null;
/**
* The available views in the system.
*/
private IViewDescriptor[] availableViews = null;
/**
* Initializes the combo and the map to contain the views.
* @param parent
*/
public ViewsCombo( Composite parent, String viewIDToSelect ){
super();
// create the combo
this.combo = new Combo( parent, SWT.READ_ONLY );
// fill the combo with the data
this.fillComboAndMap();
// select a view if specified
if( viewIDToSelect != null )
for( int i = 0; i < availableviews =" (IViewDescriptor[])">
Database Independent
La nostra soluzione è indipendente dal database, quindi possiamo usarla con qualunque DBMS preferiate.
Quante volte ho sentito questa frase pronunciata da un qualche vendor di soluzioni informatiche!
Quello che si nasconde dietro questa frase è l'illusione della portabilità, ovvero il poter riusare la soluzione informatica in contesti disparati e con DBMS differenti.
Certo, la portabilità è buona, ma va saputa usare nel modo piu' opportuno, e farsi vanto di essere indipendenti dal database non sempre è una buona cosa, anzi per me è un errore grosso e anche grossolano.
E' un errore grosso perché generalmente al cliente finale non interessa l'interoperabilità del sistema proposto con altri DBMS. Lo scopo del cliente è quello di avere una soluzione informatica funzionante e performante (quest'ultimo punto è spesso molto importante), mentre l'indipendenza dal database è un fattore di interesse generalmente per gli sviluppatori. E' pur vero che il cliente potrebbe avere già un suo DBMS installato (o preferito) sul quale vuole far girare la applicazione in questione, e quindi avere un modo per "convertire" l'applicazione ad un altro DBMS è una buona cosa. Ma la parola chiave, spesso ignorata, è appunto "conversione": un conto è avere una soluzione informatica portabile, ovvero convertibile facilmente ad un'altra architettura (ossia ad un altro DBMS) e un conto è avere un sistema che è svincolato dal tipo di DBMS e quindi è già pronta per qualunque architettura. Quest'ultima soluzione, a mio avviso, è la peggiore. I piu' staranno saltando sulla sedia vista questa mia affermazione. Per meglio capire il mio pensiero occorre valutare anche la seconda parte dell'errore circa l'indipendenza dal database: la grossolanità.
Reputo l'indipendenza dal database un errore grossolano poiché automaticamente significa escludere tutte le funzioni evolute che il DBMS puo' offrire, e che nella maggior parte dei casi sono vendor-specific. Il rifiuto di ogni cosa non assomiglia ad una query standard porta a due problemi principali:
Quello che si nasconde dietro questa frase è l'illusione della portabilità, ovvero il poter riusare la soluzione informatica in contesti disparati e con DBMS differenti.
Certo, la portabilità è buona, ma va saputa usare nel modo piu' opportuno, e farsi vanto di essere indipendenti dal database non sempre è una buona cosa, anzi per me è un errore grosso e anche grossolano.
E' un errore grosso perché generalmente al cliente finale non interessa l'interoperabilità del sistema proposto con altri DBMS. Lo scopo del cliente è quello di avere una soluzione informatica funzionante e performante (quest'ultimo punto è spesso molto importante), mentre l'indipendenza dal database è un fattore di interesse generalmente per gli sviluppatori. E' pur vero che il cliente potrebbe avere già un suo DBMS installato (o preferito) sul quale vuole far girare la applicazione in questione, e quindi avere un modo per "convertire" l'applicazione ad un altro DBMS è una buona cosa. Ma la parola chiave, spesso ignorata, è appunto "conversione": un conto è avere una soluzione informatica portabile, ovvero convertibile facilmente ad un'altra architettura (ossia ad un altro DBMS) e un conto è avere un sistema che è svincolato dal tipo di DBMS e quindi è già pronta per qualunque architettura. Quest'ultima soluzione, a mio avviso, è la peggiore. I piu' staranno saltando sulla sedia vista questa mia affermazione. Per meglio capire il mio pensiero occorre valutare anche la seconda parte dell'errore circa l'indipendenza dal database: la grossolanità.
Reputo l'indipendenza dal database un errore grossolano poiché automaticamente significa escludere tutte le funzioni evolute che il DBMS puo' offrire, e che nella maggior parte dei casi sono vendor-specific. Il rifiuto di ogni cosa non assomiglia ad una query standard porta a due problemi principali:
- si reinventa la ruota;
- non si sfrutta al massimo il DBMS.
Il primo problema è facile da capire: il DBMS ha come solo scopo la gestione dei dati, e lo fa al meglio delle proprie capacità. Se non ci si fida del DBMS e si vuole riprogettare tutto quello che potrebbe essere fatto con estensioni del DBMS stesso (ad esempio query complesse via stored procedure) allora si sta scrivendo codice per replicare le funzionalità del DBMS. Questo risulta in uno spreco di risorse, tempo e generalmente in performance cattive. Unitamente a questo si ha che non si sfrutta il database al 100%, e considerando che spesso ci si trova a pagare licenze (dal costo elevato) per il solo utilizzo del DBMS, ciò corrisponde ad una perdita economica non sempre trascurabile. In altre parole, spesso il cliente si trova a pagare un costo di licenza per uno strumento, il DBMS, che viene usato solo in parte, e paga contemporaneamente i costi della realizzazione del software che implementa quelle funzionalità che non vengono sfruttate nel DBMS stesso!
A questo punto, dovrebbe iniziare ad essere chiaro che l'indipendenza dal database non sempre è una buona cosa, almeno per il fatto che implica costi aggiuntivi sul cliente (e sul fornitore prima).
Quindi non si deve progettare il sistema in modo che sia portabile? Ovviamente no, occorre fare una scelta implementativa mirata (ovvero stabilire quale DBMS puo' fornire il miglior rapporto qualità/prezzo per il sistema) e fornire implementazioni di supporto per i DBMS che non offrono le funzionalità richieste. In sostanza, occorre legarsi ad un DBMS e cercare di fornire supporto per gli altri, ma occorre che lo sviluppo sia orientato ad un DBMS specifico! Dopotutto scelte del genere nel processo di sviluppo sono già state fatte: la scelta del linguaggio, la scelta dell'IDE, la scelta del framework MVC, ecc., allora perché il database non dovrebbe sottostare a scelte analoghe?
L'indipendenza da un componente importante come il DBMS è per me utopia; è come se si comprasse un paio di scarpe ma non si usassero i lacci, perché dopotutto non tutte le scarpe hanno i lacci e quindi non si vogliono prendere abitudini non portabili. Ma così non si riuscirà mai a correre bene! E lo stesso avviene con i DBMS, che se non vengono sfruttati non possono fornire prestazioni elevate.
Quindi occorre fare una scelta, spesso coraggiosa: legarsi ad un DBMS che offra le migliori feature per il progetto che si sta facendo. E se il database è libero, allora questa scelta non imporrà costi addizionali sul cliente e potrà essere accettata facilmente.
A questo punto, dovrebbe iniziare ad essere chiaro che l'indipendenza dal database non sempre è una buona cosa, almeno per il fatto che implica costi aggiuntivi sul cliente (e sul fornitore prima).
Quindi non si deve progettare il sistema in modo che sia portabile? Ovviamente no, occorre fare una scelta implementativa mirata (ovvero stabilire quale DBMS puo' fornire il miglior rapporto qualità/prezzo per il sistema) e fornire implementazioni di supporto per i DBMS che non offrono le funzionalità richieste. In sostanza, occorre legarsi ad un DBMS e cercare di fornire supporto per gli altri, ma occorre che lo sviluppo sia orientato ad un DBMS specifico! Dopotutto scelte del genere nel processo di sviluppo sono già state fatte: la scelta del linguaggio, la scelta dell'IDE, la scelta del framework MVC, ecc., allora perché il database non dovrebbe sottostare a scelte analoghe?
L'indipendenza da un componente importante come il DBMS è per me utopia; è come se si comprasse un paio di scarpe ma non si usassero i lacci, perché dopotutto non tutte le scarpe hanno i lacci e quindi non si vogliono prendere abitudini non portabili. Ma così non si riuscirà mai a correre bene! E lo stesso avviene con i DBMS, che se non vengono sfruttati non possono fornire prestazioni elevate.
Quindi occorre fare una scelta, spesso coraggiosa: legarsi ad un DBMS che offra le migliori feature per il progetto che si sta facendo. E se il database è libero, allora questa scelta non imporrà costi addizionali sul cliente e potrà essere accettata facilmente.
giovedì 10 dicembre 2009
I 7 peccati di Microsoft Windows 7
Non è passato molto tempo da una mia riflessione sul mondo dell'OpenSource, e ieri ho letto questo articolo molto interessante sulla mentalità (se così la si vuole chiamare) di Microsoft Windows 7.
E ancora c'è gente che mi vuole vendere la storia del se si rompe so a chi chiedere aiuto?
E ancora c'è gente che mi vuole vendere la storia del se si rompe so a chi chiedere aiuto?
lunedì 7 dicembre 2009
PGDay 2009: un altro evento di successo!
Sono molto soddisfatto del PGDay 2009 che si è tenuto a Pisa, presso l'Università.
Inizialmente ero un po' scettico, devo ammetterlo. Il fatto è che questo è stato un anno pesante, sia per i singoli soci (come me) dell'associazione promotrice (ITPug) che per l'associazione stessa. Eppure ancora una volta, i nostri sforzi hanno dato ottimi risultati.
L'atmosfera che si respirava fin dai primi momenti dell'evento era di festa, di voglia di scambiare idee e opinioni, di crescere condividendo esperienze.
L'affluenza è stata molto buona: circa 60 membri suddivisi fra aziende, privati, università ed enti pubblici. Si poteva fare di meglio, ma va anche considerato che il clima non ci ha certo aiutato (diversi sono rimasti intrappolati nel traffico e nella neve!).
Il Dipartimento di Informatica dell'Università di Pisa è bellissimo, uno dei piu' belli che abbia mai visto (e di facoltà ne ho girate diverse) e la gente è cordiale e disponibile. Le sale a nostra disposizione sono spaziose, luminose, ordinate e ben attrezzate.
Purtroppo si parte con un po' di ritardo, dovuto appunto a problemi climatici, ma poi tutta la giornata si articola in una unica discussione continua su PostgreSQL. L'interesse è alto, e piu' che nelle altre edizioni ho l'impressione che si stia realmente colpendo il pubblico. In un certo senso, era come se il pubblico fosse digiuno di PostgreSQL e rimanesse allibito vedendo con quale semplicità e velocità si potevano fare le cose di piu' alto livello.
Notevole la sezione dei lightning talks, che ha coinvolto praticamente tutti, e ha permesso di verificare che PostgreSQL non è poi un prodotto di nicchia, ma un prodotto molto utilizzato e molto apprezzato.
Penso che ancora una volta ITPug abbia mostrato, sul campo, che è capace di muovere eventi degni di nota. Certo questo non basta, si vuole crescere ancora ed essere in grado di promuovere eventi ancora piu' spettacolari o con maggiore frequenza, e per questo occorre il supporto di tutti i soci. Ma penso che, concretamente, l'associazione si stia comportando davvero bene.
Al prossimo PGDay!
Inizialmente ero un po' scettico, devo ammetterlo. Il fatto è che questo è stato un anno pesante, sia per i singoli soci (come me) dell'associazione promotrice (ITPug) che per l'associazione stessa. Eppure ancora una volta, i nostri sforzi hanno dato ottimi risultati.
L'atmosfera che si respirava fin dai primi momenti dell'evento era di festa, di voglia di scambiare idee e opinioni, di crescere condividendo esperienze.
L'affluenza è stata molto buona: circa 60 membri suddivisi fra aziende, privati, università ed enti pubblici. Si poteva fare di meglio, ma va anche considerato che il clima non ci ha certo aiutato (diversi sono rimasti intrappolati nel traffico e nella neve!).
Il Dipartimento di Informatica dell'Università di Pisa è bellissimo, uno dei piu' belli che abbia mai visto (e di facoltà ne ho girate diverse) e la gente è cordiale e disponibile. Le sale a nostra disposizione sono spaziose, luminose, ordinate e ben attrezzate.
Purtroppo si parte con un po' di ritardo, dovuto appunto a problemi climatici, ma poi tutta la giornata si articola in una unica discussione continua su PostgreSQL. L'interesse è alto, e piu' che nelle altre edizioni ho l'impressione che si stia realmente colpendo il pubblico. In un certo senso, era come se il pubblico fosse digiuno di PostgreSQL e rimanesse allibito vedendo con quale semplicità e velocità si potevano fare le cose di piu' alto livello.
Notevole la sezione dei lightning talks, che ha coinvolto praticamente tutti, e ha permesso di verificare che PostgreSQL non è poi un prodotto di nicchia, ma un prodotto molto utilizzato e molto apprezzato.
Penso che ancora una volta ITPug abbia mostrato, sul campo, che è capace di muovere eventi degni di nota. Certo questo non basta, si vuole crescere ancora ed essere in grado di promuovere eventi ancora piu' spettacolari o con maggiore frequenza, e per questo occorre il supporto di tutti i soci. Ma penso che, concretamente, l'associazione si stia comportando davvero bene.
Al prossimo PGDay!
Trenitalia e il warp temporale
A velocità diverse il tempo scorre in modo diverso (teoria della relatività).
Alla Trenitalia questa cosa la devono aver presa molto seriamente quando hanno compilato gli orari dei treni. Capita allora che, alla soglia del 2010, quando su tutte le emittenti ci sono pubblicità a raffiche sull'efficienza e l'eleganza dei nuovi servizi ad alta velocità, 15 minuti di ritardo su un treno si tramutino in circa 2 ore di ritardo sull'arrivo finale.
Mi è capitato infatti di dover andare a Pisa, per il PGDay 2009, e di aver viaggiato in ritardo di 15 minuti con il primo treno diretto a Fidenza; ritardo fatale perché mi ha impedito di prendere la coincidenza. Ho quindi deviato su un altro percorso suggeritomi dal capostazione. Ma anche il secondo treno, partito puntuale, è arrivato con circa 30 minuti di ritardo (avevo 37 minuti per prendere la terza coincidenza). Poco male, ho preso in tempo l'ultimo treno che è partito puntuale alla volta di Pisa...arrivando con 20 minuti di ritardo.
E io complessivamente sono arrivato invece che alle 21.30 (come indicato sui biglietti) alle 23.50!
Beh, se voglio viaggiare bene e puntuale posso spendere di piu' e usare la Freccia Rossa...ma perché devo pagare per avere un disservizio e arrivare con un simile ritardo?
Iscriviti a:
Post (Atom)