venerdì 23 aprile 2010

Ancora sull'OpenSource...

Si lo so, sto diventando monotono. O forse sto diventando fanatico.
Parlo ancora una volta dell'OpenSource. Ricordo quando qualche mese fa qualcuno mi disse che la propria azienda si appoggiava a prodotti commerciali (non faccio nomi, anzi pubblicità) perché la grossa azienda che forniva la piattaforma non sarebbe mai fallita. E di come in fin dei conti fosse necessario fornire ai clienti soluzioni funzionanti, anchen se closed, piuttosto che abbozzi con funzionalità instabili ma open.
Come spesso accade, è tutta una questione di compromessi. L'ultima parola spetta sempre al cliente, che è anche quello che paga per avere la soluzione e che quindi pretende che la soluzione sia conforme il piu' possibile alle sue specifiche. Però le scuse "la XXX è così grossa che non fallirà", "la XXX è così grossa che non smetterà di produrre la piattaforma YYY" sono per me frasi di comodo, lanciate da chi non osserva bene cosa succede nel mercato IT e non si rende conto di cosa voglia realmente dire appoggiarsi ad una soluzione closed.
Spero che quello che sta succedendo con il caso Sun-Oracle apra gli occhi a quegli stolti che ancora assorbono quanto c'è da prendere dai framework e le librerie free per poi farne prodotti commerciali, a volte senza nemmeno tenere in considerazione le licenze.
E' vero, è una questione di compromessi. Funziona ma non è OpenSource, va bene lo stesso? Spesso la risposta è si, visto che si tratta di ottenere il risultato finale: funziona. Poi però le aziende crollano in borsa, vengono scalate e acquisite da altre piu' grosse, e magari non nello stesso settore di appartenenza (e c'è ancora chi si stupisce anche di questo, come che il monopolio fosse solo in una direzione). Cambiano le politiche, cambiano i contratti, cambiano le forniture, cambiano i costi.
La stessa storia vista con PostgreSQL: sponsorizzato da Sun, perché in fin dei conti Sun voleva vendere l'hardware, non il software. Poi ci si rende conto che anche il software puo', nel suo piccolo, portare soldi, e allora si cambia politica. E l'unico modo per un progetto di rimanere a galla è quello di avere una community open alle spalle, in modo che nessuna azienda possa decretarne il futuro a tavolino o sulla base di qualche budget.

Quindi le soluzioni closed sono cattive? Si.
Andrebbero evitate? Si.
Io le evito? Si, quando posso. Quando non posso anche io devo piegarmi, e l'unica cosa che posso fare è porre quanti piu' limiti possibili all'interferenza fra azienda e prodotto, in modo da poter prevedere e arginare eventuali disastri futuri.

giovedì 15 aprile 2010

Lupu ululà....

Frankenstein Jr. è un capolavoro assoluto di Mel Brooks.
Scritto nel 1974, ambientato nel castello originale del Frankenstein originale del 1931 (che ho visto in videocassetta) e interpretato dall'affascinantissimo Gene Wilder (ma non solo, chi ricorda Gene Hackman?) è sicuramente il mio film preferito.
Se da piccolo, quando lo guardavo nel lettono con i miei genitori, questo film mi faceva un po' paura, da grande ho iniziato ad apprezzarlo progressivamente di piu', fino ad arrivare alla sua visione in inglese e alla mitica gag "werewolves...there....what?...there wolves, there castle!"

E quello che oggi mi fa tristezza è che spezzoni di questo film siano usati nella pubblicità di un automobile.

A mio avviso questa pubblicità ha preso alcuni degli spezzoni meno adatti per il prodotto in reclamizzato, oltre a storpiarne le voci e i contenuti, per riuscire in un aberrante mix di immagini in bianco e nero.

Insomma, la parodia di un film per la parodia di una carrozza!

mercoledì 14 aprile 2010

DisastrOSX

Generalemente non mi lascio guidare da motivazioni non tecniche quando devo valutare un sistema operativo o una tecnologia. Però devo ammettere che nel tempo mi si è sviluppata una sorta di allergia ai prodotti Apple, specialmente al suo sistema operativo OSX (qualsiasi tipo di gattaccio specifico).
L'Apple ha seguito le orme di altri progetti e prodotti, creando una versione sempre piu' semplificata del suo sistema in modo da far sentire a proprio agio utenti trattati sempre piu' da utonti.
Lavorando con degli OSX ho trovato diversi problemi non compatibili con la filosofia e la mentalità Unix. Ad esempio il fatto che una configurazione di rete con DHCP e indirizzo manuale non consente di specificare il gateway da usare se il DHCP non funziona. Dopotutto l'utonto non è abbastanza ferrato per sapere questi dettagli, quindi anche un amministratore non deve poter impostare agilmente un computer affinché possa lavorare come una vera workstation.
Vogliamo poi parlare dei vendor di periferiche? Spesso obbligano gli utenti a collegare solo una periferica di un tipo (i driver degli scanner Epson ne sono una prova), come che se l'utonto non possa essere così tonto da voler collegare apparati ridondanti.
Insomma, tutta la potenza di una workstation Unix e tutta la non flessibilità di un PC DOS. Chissà se l'Apple, invece che usare l'effetto sanguisuga sulla comunità OpenSource si fosse interessata maggiormente alle esigenze degli utenti e degli sviluppatori dove sarebbe OSX oggi. Non posso fare a meno di pensare a cosa sarebbe successo a progetti come Gnome e KDE se avessero avuto un feedback sostanzioso dalla casa della mela.

giovedì 8 aprile 2010

Echo char in un campo password

SWT utilizza un normale campo di testo (Text) per il prompt utente di una password. L'idea è simile a quella usata in AWT: si usa un campo testo con un echo char differente (ad esempio *) per impedire la lettura dei caratteri digitati.
Lo stile SWT.PASSWORD imposta un campo di testo con il carattere di echo della piattaforma, che corrisponde a 0x25cf su molte piattaforme. Di conseguenza, se si deve reimpostare il carattere di echo di un campo password (ad esempio perché è stato precedentemente impostato a '\0' per visualizzare i dati in esso contenuti) è sufficiente impostare il carattere di echo come segue:


char echoChar = 0x25cf;
passwordField.setEchoChar( echoChar );

mercoledì 7 aprile 2010

Modifiche invisibili a plugin.xml

Ho scoperto per caso che il file plugin.xml di una applicazione RCP non viene letto ad ogni avvio della stessa, ma solo ad ogni "avvio pulito". Di conseguenza, se è necessario apportare delle modifiche al file di una applicazione della quale è già stato fatto il deployment, occorre fare un riavvio dell'applicazione con l'opzione -clean al fine di ordinare alla piattaforma di rileggere le proprietà del file.

Stallman e la sua visione (esasperata?) sul Free Software

Qualche mese fa il progetto Gnome è stato investito da un treno merci a tutta velocità: sostanzialmente parte una discussione sul planetgnome relativa ad un post di Miguel De Icaza (e altri) collegati a software proprietari. Nel caso specifico Miguel postava relativamente a Silverlight di Microsoft, mentre altri autori postavano relativamente a VMWare.
a questo punto il planet inizia ad interrogarsi sul codice di condotta dei membri Gnome, ovvero se sia lecito usare il planet per postare (e quindi fare pubblicità) argomenti relativi a software proprietario. Entra quindi in campo Richard Stallman, che scrive un messaggio degno di nota:


GNOME is not connected with the anti-hunting movement; there's no
reason it should have any position on the question.  But GNOME is part
of the GNU Project, and it ought to support the free software
movement.  The most minimal support for the free software movement is
to refrain from going directly against it; that is, to avoid
presenting proprietary software as legitimate.

Ora Stallman ha, per forza di cose, ragione: il software free non dovrebbe promuovere l'utilizzo di software proprietario. Però io ritengo che questa sua visione del mondo informatico sia eccessiva ed esasperata: Gnome stesso viene usato in sistemi operativi commerciali, come ad esempio Solaris. Allora se uno sviluppatore Gnome scrive un post relativo ad una patch o altro circa Solaris deve essere censurato? In fin dei conti sta scrivendo relativamente a Gnome, quindi ad un progetto FSF/GNU, ma per farlo deve passare (parlare) di un software proprietario. Fermo restando che non tutto quello che è GNU deve essere obbligato a rimanere nei canoni e nelle volontà di Stallman. Insomma, è un film già visto, Gnome stesso nasce come anti-KDE nella mente di Stallman. Inevitabilmente facendo free software ci si deve sporcare le mani con il software proprietario, anche solo per trarre idee e spunti. Miguel De Icaza dimostra di avere un senso pratico piu' sviluppato, e nonostante non sia in completo accordo con il suo post relativo alla collaborazione fra software free e software proprietario, su una cosa ha ragione:

  For open source to win, we do not need Microsoft, Apple or proprietary software to lose. The industry is not a zero-sum game, not only we enrich each other's platforms by exploring different ideas, but it is also incredibly healthy for the industry to have a blend of different approaches to computing. 

 Alla fine Mono è stato proprio questo: l'implementazione di una buona idea (.NET) senza il pregiudizio che fosse cattiva solo perché in mano ad un partner non free-software (Microsoft). E tanti ancora non l'hanno capito: il free software può vincere la battaglia, ma per farlo deve dimostrare di essere migliore di quello proprietario, e per essere migliore deve essere almeno equivalente. 
E sono anche piu' ottimista su questa affermazione di Miguel:

It has been 15 years since the rise of the first large open source companies and by now we should know that our dream of a pure open source stack ruling the world is not going to happen any decade now.

Io penso che si possa arrivare ad uno stack interamente OpenSource (e nel caso Free Software), ma sono convinto che non ci si arriverà mai seguendo solo i canoni GNU. In sostanza la FSF deve lasciar circolare anche altre licenze senza emarginarle. Se tutte le licenze non GNU fossero state bandite (come Stallman vorrebbe), tanti progetti interessanti (a partire da quelli Apache, al codice donato da IBM, a quello donato da Sun) non farebbero parte del panorama OpenSource.

Aethera morto...Mailody nuovo nato...KMail domina ancora

Quando inizia ad usare il desktop KDE venni attratto da una applicazione per la posta elettronica molto promettente: Aethera. All'epoca l'applicazione era gratuita, almeno mi pare di ricordare, poi venne inglobata nel lavoro di TheKompany e divenne un client di posta concorrente a KMail. All'epoca KMail era ancora agli albori, mentre Aethera aveva un look and feel decisamente piu' professionale, forse anche perché all'epoca KMail era solo una applicazione di posta senza tutta quella infrastruttura PIM che oggi compone Kontact. 
Purtroppo il progetto Aethera sembra defunto, gli ultimi aggiornamenti sono fermi al 2005 e anche l'aspetto del client sembra alquanto "antiquato". Peccato, perché sicuramente il progetto meritava molto, e una unione con il branch ufficiale del progetto PIM di KDE avrebbe portato giovamento ad entrambi.
Sembrerebbe quindi che KMail sia e rimanga in carica come client di posta assoluto per l'ambiente KDE, e invece qualche giorno fa mi sono imbattuto in un progetto interessante e promettente: Mailody. Quest'ultimo è un client di posta specificatamente pensato per server IMAP, tanto è vero che non supporta affatto il protocollo POP. A prima vista la scelta appare coraggiosa: moltissimi utenti ancora usano il protocollo POP con la maggior parte delle caselle e-mail gratuite, mentre il servizio IMAP rimane confinato ad una fornitura di servizi maggiormente professionale. Tuttavia, a detta dell'autore di Mailody:


The year before starting Mailody I got generally annoyed by all available mail clients. There are a bunch of email clients available, but none seems to fit the way I work with email.

L'intenzione è buona: si vuole superare una limitazione nelle applicazioni esistenti. Eppure si nota, continuando a leggere, un problema relativo a molti sistemi OpenSource:

I first tried to get KMail to do what I wanted, but soon I noticed how lost I felt while looking at the code. Probably my lack of thorough c++ knowledge. But it prevented me to start implementing the things I need in KMail.

L'autore afferma di aver iniziato il progetto per una sua mancanza di comprensione dei sorgenti di KMail. Sicuramente, essendo KMail un client molto complesso, la lettura del suo codice non puo' essere semplice, ma la cosa importante per me nella frase citata sopra è che essa rispecchia molto bene l'andamento di tanti progetti OpenSource. Spesso infatti gli autori, invece che fornire patch o modificare una code base comune, iniziano un progetto da zero per una semplice "pigrizia" nella comprensione del codice esistente. Quanti progetti simili esistono su Sourceforge? E quanti di questi sono ancora in stato beta? Non sarebbe meglio unire le forze e ottenere un risultato comune e che soddisfi tutti? Certo, questo non è sempre possibile, e la possibilità di scelta tipica dell'OpenSource è importante per poter attrarre quanti piu' utenti (ciascuno con differenti necessità). Però prima di lanciarsi in un progetto occorre considerare attentamente se i propri sforzi non vadano a sovrapporsi con gli sforzi di altri programmatori esistenti. Nel caso di Mailody purtroppo il progetto si è fermato al 2008.
E intanto Kmail continua ad evolversi e a dominare il panorama dei client di posta per il desktop KDE.

venerdì 2 aprile 2010

WebCalendar: impedire l'inserimento di un appuntamento fuori da un range di date

WebCalendar è un ottimo strumento per la gestione rapida degli appuntamenti condivisi, tuttavia a volte è opportuno limitare l'inserimento degli appuntamenti in un range predefinito di date. La modifica piu' rapida e semplice per ottenere questo consiste nel modificare il file edit_entry.php, repsonsabile dell'editazione/inserimento di una entry nel calendario: se tale file PHP impedisce all'utente di editare un nuovo appuntamento allora il gioco è fatto.

Per questo motivo basta modificare il codice del file in questione, inserendo il seguente blocco per il calcolo della data attuale (che viene passata al file con il metodo GET) e la creazione di un avviso qualora si sfori oltre al range stabilito:


<?php

// non abilito date successive a $endDate o precedenti $startDate.

if( ! isset($_GET['id']) ){

    $thisyear = (int) ( $date / 10000 );

    $thismonth = ( $date / 100 ) % 100;

    $thisday = $date % 100;

$startDate = date( 'm/d/y', mktime(3,0,0, "04", "06", "2010") );

$endDate   = date( 'm/d/y', mktime(3,0,0, "07", "06", "2010") );

$nextDate  = date( 'm/d/y', mktime ( 3, 0, 0, $thismonth, $thisday , $thisyear ) );

if( $nextDate > $endDate  || $nextDate < $startDate ){

    $can_edit = false;

    echo "<H3 align=center>ATTENZIONE: non sono ammessi appuntamenti fuori dal range ($startDate - $endDate)</H3>";

    echo "<P align=center>Non puoi inserire appuntamenti nel giorno selezionato ($nextDate)</P>";

}

}

?>







<?php



 if ( $can_edit ) { // qui continua il codice normale di webcalendar