La Spina nel Fianco

XUL March 16, 2006

XUL è l’acronimo di “eXtendible User interface Language”. XUL è il linguaggio utilizzato da Mozilla Suite, Mozilla Firefox, Mozilla Thunderbird, Mozilla Sunbird e Netscape per descrivere le proprie GUI (Graphical User Interface). Il sistema funziona esattamente come la coppia Glade/LibGlade delle applicazioni GTK+ (Gnome) e come il sistema di generazione delle GUI basato su XML di Qt (KDE).

XUL è una “applicazione” di XML. La sua sintassi è XML-Compliant ed è descritta da un apposito documento (DTD, cioè Document Type Definition),

XUL permette di descrivere l’intera interfaccia utente di un programma usando uno o più file XML. L’interfaccia utente di Mozilla Firefox e di Mozilla Thunderbird è appunto definita da alcuni file XUL. In questo modo, è possibile caricare una nuova interfaccia semplicemente caricando un file. Il file XUL definisce in modo completo la struttura e l’aspetto della interfaccia utente. Le azioni che vengono svolte da ogni elemento sono invece specificate da appositi file ECMAScript (JavaScript) o, più recentemente, Python.

XUL è stato l’antesignano di Microsoft XAML e può tuttora essere considerato la sua controparte “libera” e “aperta”.

Negli anni scorsi, XUL ha ricevuto una certa attenzione da parte della stampa e degli sviluppatori, fino al punto che sono stati pubblicati ben due libri (entrambi in inglese) su questa tecnologia. A quel tempo esisteva una diffusa convinzione che XUL avrebbe rapidamente cambiato il modo di creare e gestire le GUI dei programmi e, soprattutto, che XUL avrebbe dato un nuovo volto al World Wide Web. Grazie a XUL, infatti, è possibile creare “pagine web” che hanno l’aspetto ed il comportamento di vere applicazioni, proprio come se si trattasse di applicazioni scrite in C++ con Visual Studio.

Dopo quel momento inziale di entusiasmo, XUL è stato quasi del tutto abbandonato. Le ragioni sono parecchie ma sostanzialmente si possono ridurre alle due seguenti.

1. Creare una interfaccia utente con XUL, i CSS e ECMAScript è un lavoro lungo, pesante e ricco di insidie. Si fa prima a costruire una normale pagina web HTML+JavaScript+CSS od a creare una applicazione con GTK+ + Glade o con wxWidgets + wxGlade.
2. Non si è sviluppato un mercato per queste tecnologie. In parte perchè questo mercato è stato conquistato da HTML+JS+CSS=DHTML, arrivato anni prima, un po’ perchè le aziende non ne hanno colto le possibilità.

Tuttavia, è possibile che nei prossimi mesi o (pochi) anni, questa tecnologia venga riscoperta, un po’ perchè Mozilla Firefox e Thunderbird si stanno diffondendo rapidamente, un po’ perchè l’interesse corrente per Ajax (HTML+JS+CSS e connessione al sever web via XMLonHTTP invece che via POST HTTP) e per XAML potrebbe far riscoprire XUL. XUL, infatti, è molto migliore di entrambe queste piattaforme.

Se lavorate nel settore, vi consiglio di dare un’occhiata a XUL sia sul sito di Mozilla che parlando con gli sviluppatori italiani sulla mailing list di XuleX.

Linux Myth #1: Reliability March 12, 2006

Uno dei più vecchi e consolidati miti che riguardano il mondo Unix, e di conseguenza Linux, è che il software Unix, soprattutto quello Open Source sia “indistruttibile”. A sostegno di questa tesi si portano le statistiche di funzionamento dei server web (Apache) e altri servizi di rete, facendo notare i memory leak ed i crash cui vanno soggetti i concorrenti commerciali (M$ IIS, tanto per non fare nomi).

Ma è vero?

No.

Per quanto possa sembrare strano, non è così. La robustezza dei programmi Unix, in particolare quelli Open Source, non dipende affatto dalla loro natura Unix o dalla loro natura Open. Dipende da due fattori che non hanno nulla a che fare con tutto questo:

1. Si tratta di programmi relativamente semplici, in particolar modo si tratta di programmi privi di interfaccia grafica. La GUI, da sola può far triplicare le dimensioni di un programma e, con le dimensioni, il numero di bug presenti.
2. Si tratta di programmi molto vecchi e molto ben collaudati. Questo è, ad esempio, il caso di Apache (erede del server httpd di NCSA, che risale al 1991).

Non appena vengono meno questi due aspetti, il software Unix e quello Open Source comincia a creare problemi esattamente quanto il tanto vituperato “pattume” Windows commerciale.

In questi giorni sto usando OpenOffice 2.01 e KOffice su KDE 3.5 su Mandriva, SuSe, Debian e su un vecchio laptop con VectorLinux 5. Sto riscontrando dei problemi che, un tempo, avrebbero fatto pensare a M$ Office su Windows:

• OpenOffice e KWord che vanno in crash, senza preavviso.
• OpenOffice che si rifiuta di aprire alcuni dei suoi stessi documenti, senza nessuna apparente ragione.
• KWord che, senza apparente motivo, si mette a funzionare al rallentatore

Si tratta, sia ben chiaro di problemi tecnici risolvibili, in alcuni casi già noti agli sviluppatori ed in via di soluzione ma… sembra ugualmente di avere per le mani M$ Office e Windows (quelli di diversi anni fa, oltretutto, perchè quelli più recenti sono decisamente più affidabili).

Che sta succedendo?

Semplicemente sta succedendo che OpenOffice e KOffice sono programmi da milioni di righe di codice, sviluppati cooperativamente da migliaia di persone e dotati di una pesantissima GUI che, da sola, rappresenta il 70% del codice. Il altri termini si tratta di oggetti di complessità paragonabile ad uno Space Shuttle o, per fare un’altro esempio, all’impianto FIAT di Mirafiori. Non si tratta più di programmi a linea di comando da qualche decina di migliaia di righe di codice, sviluppati quasi completamente da un singolo geniale programmatore, come un server web. Come se non bastasse, si tratta di programmi “giovani”, almeno in confronto alla loro complessità. Non c’è ancora stato il tempo di incappare in ogni singolo bug e di correggerlo, nemmeno lavorando in modalità “Open Source”.

Questo dovrebbe insegnare una cosa fondamentale agli sviluppatori del mondo “open”: non ci sono pallottolle d’argento con cui combattere il lupo mannaro dei bug. L’unico modo di costruire programmi affidabili consiste nel lavorare duramente sopra di essi per anni. Non basta una licenza GPL per trasformare un programma in una fortezza inviolabile e non basta un numero di release superiore a 1.0 per avere un programma stabile.

L’esperienza che tutti abbiamo fatto a suo tempo con Windows e MS Office, insieme a quello che sta succedendo ora a OpenOffice e KOffice, ci dovrebbero avere insegnato già una cosa: il software GUI-based comincia a diventare realmente stabile dopo la release 3.0. Fino ad allora, avremo a che fare con qualcosa di poco affidabile.

Di questo bisogna tenere conto. Il software Unix/Linux, specialmente quello Open Source è già adesso più che utilizzabile per le normali applicazioni d’ufficio e per moltissime applicazioni industriali, ma va trattato con un minimo di intelligenza.

La mia personale speranza è che la comunità di sviluppatori riesca a concentrare i propri sforzi su questi programmi “cruciali” ed a renderli stabili nel minore tempo possibile. Se c’è qualcosa che può ammazzare sul nascere l’entusiasmo dei singoli e delle aziende per il mondo Open è proprio una scarsa affidabilità dei programmi.

Imparare a programmare January 31, 2006

Fino a qualche anno fa, programmare era un mestiere rivendibile, a volte persino ben pagato. Dal 2001 a questa parte le cose sono molto cambiate, sia a causa dell’esplosione della bolla speculativa sulla new economy che per altre ragioni. Come conseguenza di questo, ora farei molta fatica a consigliarvi di imparare a programmare (od a fare molte altre cose legate all’informatica) come attività di “sviluppo della professionalità personale”. Tuttavia, c’è ancora una ragione molto seria per cui dovreste imparare a programmare un computer se ancora non lo sapete fare: è il modo migliore per capire, una volta per tutte, come funziona un computer dietro le quinte. Dato che dovrete comunque avere a che fare con questi diabolici aggeggi, conquistare questo grado di conoscenza è comunque un vantaggio.

Ma come si impara a programmare? Quale linguaggio è meglio usare? Su quale piattaforma? E con quale ambiente di sviluppo? Qui di seguito trovate le mie personalissime risposte a queste domande.

Come si impara a programmare

Orientativamente, la procedura “corretta” è la seguente.

1. Si decide su quale piattaforma si vuole lavorare, con quale linguaggio e quale ambiente di sviluppo (vedi sotto).
2. A computer rigorosamente spento (meglio se dovete ancora comprarlo), si legge (senza studiarlo) un manuale introduttivo adeguato. Lo scopo di questa operazione è quella di farsi una prima idea di massima dell’ambiente che si deve affrontare.
3. A computer acceso, si comincia con scrivere qualche semplice esercizio fornito dal libro, diciamo i primi 2 o 3.
4. Una volta capito come si tratta un piccolo programma di 10 o 12 righe, si cerca di sviluppare un piccolissimo programma di propria progettazione, diciamo un aggeggino che apre un file di testo, sostituisce tutte le ricorrenze di “governo” con “manica di ladri” e salva nuovamente il file, magari con un nuovo nome.
5. Una volta capito come si costruisce un programmino generico come questo, si torna sui libri, questa volta su un manuale più serio e più approfondito. Lo scopo è quello di cominciare a conoscere la piattaforma su cui si sta lavorando (vedi sotto).
6. Ci si sceglie un “tema” (interfacce grafiche, networking, text processing, quello che vi pare) e si cerca di sviluppare un programma di quel tipo.
7. Da qui in poi, solitamente, si è in grado di procedere da soli.

Tutto questo almeno in teoria. In realtà, ogni programmatore segue una propria strada per imparare. Pensare che una strada sia migliore di un’altra sarebbe segno di stupidità e di intolleranza. Sentitevi liberi di fare come vi sembra meglio.

Quale linguaggio

Sto per dire una cosa per cui verrò scorticato vivo ma devo comunque dirvela: ci sono alcuni linguaggi che, in questa prima fase della vostra carriera di programmatori, dovreste evitare accuratamente. Li elenco qui di seguito, spiegando il motivo per cui non dovreste usarli.

Basic (e soprattutto M$ Visual Basic): Viene suggerito agli utenti alle prime armi dicendo loro che è “semplice”. Nella realtà è molto più complesso ed irregolare di altri linguaggi e, nel caso di Visual Basic è molto, molto più complicato del necessario (e del ragionevole) a causa della costruzione delle interfacce grafiche (GUI), da cui non è praticamente possibile prescindere. Come se non bastasse, permette di fare la stessa cosa in molti modi diversi. Questo vuol dire che una persona che legge il codice di un’altra spesso non riesce a capire cosa faccia quel codice a causa delle diverse “abitudini” di programmazione. Persino la stessa persona, che rilegga il proprio codice a distanza di settimane o di mesi, può trovarsi in difficoltà. (In realtà, in VisualBasic si possono creare programmi privi di interfaccia grafica ma tutta la pressione dell’ambiente tecnico/sociale del VB va verso la creazione di programmi GUI-based.)
Perl: Valgono tutte le considerazioni appena fatte per il Basic. Per fortuna, Perl non vi obbliga da subito a trattare con le interfacce grafice.

Java: Java è molto semplice ed elegante, al punto che viene largamente utilizzato nelle scuole superiori e nelle università per insegnare a programmare. Tuttavia, devo sconsigliarvelo (anche se siete professori e lo usate per insegnare!). Il motivo è che Java costringe il programmatore ad organizzare il codice in maniera piuttosto fiscale ed innaturale (una classe per ogni minima cazzata, un file per ogni classe, un archizio compresso per ogni progetto, etc.) e questo introduce nel discorso “programmazione” un elemento di “gestione del file system” che francamente non è proprio necessario. Ci sono linguaggi, come Python, che offrono gli stessi vantaggi di chiarezza ed eleganza e non rompono i coglioni in questo modo.

La mia personalissima e discutibilissima opinione è, che per cominciare (ed anche “per finire”), dovreste usare Python.

Python: Python è un linguaggio molto simile a Java ma che non impone nessuna delle follie organizzative di Java. Python è talmente semplice ed elegante che viene largamente ritenuto dagli specialisti “il” linguaggio con cui insegnare a programmare (o con cui imparare a programmare da soli). Python è molto simile a C, il linguaggio più usato in assoluto per la programmazione professionale, e quindi è un ottimo modo di prepararsi alla carriera da professionista.

In ogni caso, tutti i linguaggi che abbiamo citato sono linguaggi interpretati: i programmi che si possono scrivere con questi linguaggi richiedono l’interprete installato sulla macchina per l’esecuzione. Non possono funzionare da soli. In altri termini, un programma Python deve essere lanciato in questo modo:

python mioprogramma.py parametro1 parametro2

Non può essere lanciato senza l’interprete, in questo modo:

mioprogramma.py parametro1 parametro2

(Questo non è del tutto vero ma per il momento fate finta che lo sia). Questo comporta un vantaggio ed uno svantaggio: il vantaggio è che il vostro programma gira dovunque sia disponibile l’interprete, lo svantaggio è che è leggermente più lento di un programma C. Un programma Python può essere scritto ed eseguito su queste piattaforme:

• Windows (tutte le versioni)
• McOS (Tutte le versioni)
• Unix (Tutte le versioni)
• Linux (Tutte le versioni)
• BSD (Tutte le versioni)

Non pensiate che Python sia un linguaggio per studenti o che sia in qualche modo limitato: dispone delle librerie necessarie per trattare qualunque (dico proprio qualunque) problema che si possa presentare nella vita professionale, dalla creazione di interfacce grafiche con vari toolkit su qualunque (ripeto qualunque) piattaforma fino alla creazione di interpreti di linguaggi. Python viene usato da molti anni da schiere di programmatori professionali che con esso hanno creato una moltitudine di programmi di ogni tipo, alcuni dei quali sono persino dei successi commerciali (come Komodo di theKompany). Da ogni punto di vista, è un rispettabile linguaggio di programmazione professionale come il C, solo che è interpretato.
Quale piattaforma

Quasi certamente state usando Windows, in una delle sue molte versioni. Lo posso dire con una buona probabilità di prenderci perchè Windows occupa ben il 93% del mercato. Restate fedeli a Windows, se vi trovate bene.

Se non vi trovate bene con Windows, passate a Linux o BSD (FreeBSD, OpenBSD o NetBSD). Questo vi costerà un po’ di fatica ma ne vale la pena.

Se siete fortunati possessori di un MacIntosh, restategli fedeli. Se non ne possedete uno, non fate la voglia inutilmente: installate Linux conKDE o Gnome e non pensateci più.

La piattaforma sui cui è in assoluto più semplice e più gradevole programmare è probabilmente Linux, per molte ragioni. Tuttavia, tenete presente che su Windows e su MacIntosh sono disponibili degli ambienti di sviluppo veramente molto raffinati e molto avanzati che su Linux non sono disponibili, in particolare, su Windows è disponibile (a pagamento) il fantastico ambiente “Visual Studio” di M$.

Quale ambiente

L’ambiente di lavoro, noto come IDE (Integrated Development Environement) è un programma che include tutto il necessario per scrivere codice e che, soprattutto, si occupa della manutenzione dei “progetti” (l’insieme dei file che scrivete). Un buon IDE può semplificare di molto la vita ad un programmatore, soprattutto se inesperto (o terribilmente pigro, come me).

Su Windows, lo abbiamo detto, esiste la Rolls-Royce degli IDE: il gigantesco, potentissimo e raffinato “Visual Studio” di M$. Costa come uno scooter, e nei primi 3 mesi vi farà impazzire, ma può valere la pena imparare ad usarlo se pensate di programmare a livelli non solo dilettanteschi.

Ambienti come questi esistono anche su MacIntosh ma per questo dovete chiedere consiglio a qualcuno che usa MacIntosh. Io non ho pratica di questo ambiente.

Su Linux (e su tutti gli Unix) sono disponibili vari ambienti di sviluppo molto raffinati, tra cui il mitico “meta-IDE” “Eclipse” di IBM ed il raffinato “KDevelop” di KDE. Sono tutti piuttosto validi.

Il mio personalissimo consiglio è che stiate alla larga dagli IDE per i primi mesi e vi limitate ad usare un editor di testo (NotePad o simili). Dopo aver capito come si programma, provate i due o tre IDE più diffusi nel vostro ambiente e scegliete quello che vi piace di più.

Personalmente, ne ho provati diverse dozzine nell’arco di molti anni ed alla fine ho deciso di usare… KEdit di KDE (Su Linux), un piccolo e scarno editor di testo simile a NotePad di MS Windows.

Altri consigli

Non lavorate da soli: se vi è possibile, cercate di lavorare con un amico od almeno iscrivetevi ad una mailing list di programmatori e restate in contatto con loro.

Non ponetevi obiettivi prima di 6 mesi: lo so che fremete dalla voglia di fare qualcosa di vostro ma cercate di avere pazienza. Ci vuole un po’ di esperienza prima di maturare la competenza necessaria per mettere in cantiere un progetto orginale. Tentare di farlo prima del tempo può portarvi ad un fallimento frustrante e farvi passare la voglia di imparare.

Tenete presente che qualunque progetto di un qualche interesse reale richiede molto, a volte moltissimo lavoro e quindi sarete quasi certamente costretti a trovarvi almeno un compagno di avventura.

Leggete molto: gran parte del problema della programmazione è in realtà un problema legato alla conoscenza della piattaforma (Windows o Linux) e delle tecniche di programmazione specifiche dei vari ambienti (text processing, GUI, networking). Per questo è importante leggere molto.

Il modo in cui si studia in informatica è qualcosa che probabilmente farebbe inorridire molti professori di fisica o di matematica ma per fortuna è molto piacevole: si tratta quasi sempre di curiosare nei libri e nei siti web seguendo il filo delle proprie esigenze, senza farsi problemi di organicità delle conoscenze apprese. Rovistate dentro il web senza farvi troppi problemi e fate qualche esperimento pratico. Dopo poco vi renderete conto da soli di cosa vi serve e di come dovete organizzare le vostre conoscenze.
Questo è tutto. Nella pagina “libri” troverete presto qualche titolo interessante per approfondire.