C’è un principio molto noto dell’informatica che spesso viene dimenticato dagli sviluppatori tutti. Tale principio recita più o meno così: se una cosa è a 3 schermate di distanza allora non esiste. È un principio basilare nell’usabilità del computer per l’utente medio: se una cosa necessita di più di 3-4 click e si trova oltre i 3 passaggi allora, indipendentemente da quanto sia importante, per l’utente finale, non esiste.

Al riguardo ci sono un po’ di considerazioni da fare.

Perché viene dimenticata?

Il motivo è semplice: i programmi vengono scritti dai programmatori. Non è un gioco di parole, è la verità. Ai programmatori piace la soluzione arguta, l’opzione contorta, l’arzighigolo programmativo. Non possono farci nulla, è più forte di loro. Non di rado quando parli dell’usabilità d’uso di un programma con un programmatore ricevi come risposta cose tipo “vabbè è semplice. Basta che aggiungi /percorso/assurdo nella variabile ENV e avvii il programma con nomeprogramma -opzione1 -opzione2 -opzionen=boh e ottieni quello che vuoi!”. E tutto ciò è normale: se non gli piacessero le cose complicate non sarebbero programmatori.

Tutti se le dimenticano?

No. Ovviamente in molti programmi ci sono persone incaricate appositamente di frenare l’indole complicatrice degli sviluppatori. Ma allora perché troviamo ancora questi grossolani errori? Alcune volte per disattenzione e altrettante per malafede. Un esempio? Le impostazioni della privacy di Facebook. Quanti click servono per arrivarci? Sono tre per visualizzarle e 4 + n per modificarle a piacimento, tutto questo attraversando 2 schermate e un menù piuttosto dimenticato.

Solo malafede?

No. A volte nascondere una possibilità oltre la soglia dei 3-4 passaggi è una “features” che permette allo sviluppatore di evitare la scrittura di complicati meccanismi di blocco, criptaggio, ecc, contando sui grandi numeri.

Un esempio è dato da un applicazione Android per impostare lo sfondo del terminale. L’applicazione da accesso a una sterminata galleria di sfondi ma, ovviamente, non da la possibilità diretta di scaricare tali sfondi. Il motivo è che, giustamente, lo sviluppatore vuole che tu apra il programma ogni volta che vuoi cambiare sfondo: se te li facesse scaricare facilmente l’utente se ne scaricherebbe 30 nel giro di due minuti e poi si dimenticherebbe dell’applicazione!

Tuttavia per impostare uno sfondo è necessario scaricare l’immagine. Come fa il programma? La scarica e la imposta. Quando cambiate sfondo, cancella la precedente e la sostituisce con la nuova.

Ora capirete che è ancora teoricamente possibile scaricarsi 30 sfondi e buttare l’applicazione, basta copiarsi in una cartella l’immagine scaricata ogni volta che il programma la scarica. Ma quanti passaggi necessita? Troppi. Non tanti, ma troppi, più di 3-4. E così statisticamente il 99% delle persone utilizzerà il programma nel modo voluto dallo sviluppatore nonostante sia teoricamente fare diversamente.

Altri esempi?

Google. Fate una ricerca su Google e notate a che pagina desistete dalla ricerca. Sono quasi sicuro che smettete di cercare entro la 3° 4° pagina, se arrivate a 6 siete parecchio insistenti, a 10 significa che siete disperati (come io quando cerco tutorial su roba strana).

Se il vostro blog cade oltre la 4° pagina non esistete. È come se fosse alla pagina 100 mila.

Quindi?

Quindi pensateci. Tutto qui. Se programmate qualsiasi cosa che non sia destinata ad altri programmatori, fate caso a non collocare nulla oltre la soglia dei 4 click/schermate. I vostri utenti ne gioveranno e voi pure.

 

Se avete visto l’ultimo articolo sui venti linguaggi di tendenza forse avete notato una triste assenza. Nella top-50 infatti manca completamente l’accoppiata Vala/Genie. Se non l’avete notata allora è il momento che vi presenti questi due giovani virgulti.

Chi o cosa sono Vala e Genie?

Vale e Genie sono due linguaggi di programmazione OpenSource ad alto livello ed orientati agli oggetti portati avanti dalla fondazione di GNOME. La raison d’etre di questi due linguaggi, la loro missione, consiste nel limitare la diffusioni di linguaggi controversi come C# e le librerie Mono nel mondo Linux. Non credo serva ripetere quali sono i problemi di Mono in un ambiente open con Linux.

Oh no! L’ennesimo linguaggio fotocopia!

In realtà Vala e Genie sono qualcosa di più che una copia di C#. Ma partiamo dall’inizio.

La sintassi di Vala è presa quasi interamente da C# ma adattata alla struttura degli oggetti GObject (strutture dati ancestrali della programmazione Gnome). La sintassi di Genie invece ricopia la sintassi del Python.

Quali sono i vantaggi rispetto a usare C# o python?

Potrei elencare una lista di piccoli vantaggi. Tuttavia preferisco dirvene uno enorme: Vala e Genie sono compilati in C. Nessuna macchina virtuale, nessuna interpretazione del linguaggio, bensì tutta la potenza binaria del C. Volendo Vala e Genie vi forniscono anche il file .c e l’header .h in modo tale da poter integrare librerie in Vala all’interno di progetti in C.

Ovviamente il codice è meno prestante di un codice scritto in C nativamente (e scritto per bene) ma è comunque più veloce di una versione interpretata da una macchina virtuale.

Bellissimo! Un esempio?

Vala nasce dal progetto GNOME ed è quindi naturale che integri un supporto praticamente nativo con le librerie Gtk. Le Qt purtroppo non sono ancora supportate. Come esempio creiamo quindi una bella finestra in Gtk (l’esempio è preso da Wikipedia).

using Gtk;
 
int main (string[] args) {
    Gtk.init (ref args);
 
    var window = new Window (WindowType.TOPLEVEL);
    window.title = "First GTK+ Program";
    window.set_default_size (300, 50);
    window.position = WindowPosition.CENTER;
    window.destroy.connect (Gtk.main_quit);
 
    var button = new Button.with_label ("Click me!");
    button.clicked.connect ((source) => {
        source.label = "Thank you";
 
    });
 
    window.add (button);
    window.show_all ();
 
    Gtk.main ();
    return 0;
}

Il programma può essere compilato con:

valac --pkg gtk+-2.0 gtkexample.vala -o gtkexample

Il risultato sarà un file binario perfettamente funzionante.

Mi piace! Ma funziona solo su Linux?

Vala e Genie sono nati per Linux. Esiste tuttavia un porting sperimentale per Windows.

E come mai questi due linguaggi tanto promettenti non sono nella top 50?

La risposta è una: gioventù. Il fatto che sia un linguaggio nato per linux da poco più che un anno sicuramente non aiuta. Tuttavia le premesse sono ottime.

Sono interessato. Da dove comincio per programmare in Vala?

Il vala non è molto diffuso e informazioni specifiche scarseggiano. Potete innanzitutto cominciare dal sito ufficiale.

Io, personalmente, non ho in programma di scrivere nulla su Vala e Genie. Per SlashCode nel prossimo periodo ho intenzione ancora di trattare Lua, l’AI e alcune cose di simulazione fisica. Comunque, se mi capiterà di trovare libri, siti e guide interessanti non mancherò di linkarle.

Buon Vala a tutti. :)

 

Molti conosceranno sicuramente le Librerie QT: esse sono infatti il principale tool-kit grafico della suite desktop KDE nonché di molti altre applicazioni e sistemi embedded. In quanto tali, quando si parla di Qt, molti pensano ad esse solamente come mere librerie grafiche, in realtà, tali librerie vanno ben oltre la semplice gestione e visualizzazione di finestre e widget: esse sono infatti una libreria che racchiude un gran numero di layer che semplificano lo sviluppo software in generale. In questo breve articolo infatti mostrerò uno dei tanti modi in cui l’uso delle librerie può Qt semplificare la vita agli sviluppatori: il meccanismo Meta-Object System (moc) e l’accoppiata signals e slots.
Segnali (signals) e slot (slots) sono due elementi fondamentali della programmazione con le Qt. Essi permettono di legare insieme due oggetti senza che nessuno dei due sappia nulla dell’altro. È possibile, ad esempio, costruire due classi A e B e fare in modo che ad un evento di A corrisponda un azione di B e viceversa senza doversi minimamente preoccupare di inserire in A riferimenti di B (e rispettivamente in B riferimenti ad A).
Un segnale è infatti un avviso emesso da un oggetto al verificarsi di determinate condizioni. Ad ogni segnale è collegato uno slot che non è nulla di diverso da una comune funzione C/C++: non appena è emesso il segnale X viene automaticamente eseguita la funzione Y.
Per collegare un segnale ad uno slot si usa il comando

connect(sendre, SIGNAL(signal), receiver, SLOT(slot));

dove sender e receiver sono puntatori a due oggetti (oggetti “qt” per la precisione) e signal e slot non sono altro che dichiarazioni di funzioni senza il nome dei parametri. Possiamo avere varie forme di connessioni:
  • PIÙ SEGNALI COLLEGATI AD UN SOLO SLOT. In questo caso la stessa funzione viene lanciata in corrispondenza di due o più segnali differenti.
  • UN SOLO SEGNALE COLLEGATO A PIÙ SLOT. Viceversa, in questo caso, l’arrivo di un segnale avvia l’esecuzione di più funzioni. Tali funzioni vengono eseguite una dopo l’altra in un ordine indefinito (fate quindi molta attenzione alla sincronizzazione di tali funzioni).
  • UN SEGNALE COLLEGATO AD UN SEGNALE. In questo caso l’arrivo di un segnale causa semplicemente il lancio di un nuovo segnale (che può essere la propagazione del primo o un segnale del tutto diverso).

“Fantastico!” direte voi, ma cosa è necessario per poter usufruire di tale meraviglia? La cosa è ancora più semplice. Il primo requisito è che sia gli oggetti che lanciano e ricevono segnali sia quelli che definiscono gli slot  ereditino dalla classe QObject e definiscano al loro interno la macro Q_OBJECT. Secondo, quando connettiamo un segnale ad uno slot dobbiamo assicurarci che contengano lo stesso numero di parametri, dello stesso tipo e nello stesso ordine. Se le nostre classi rispondono a questi due requisiti siamo pronti ad utilizzare segnali e slot.

Questo meccanismo è usato massicciamente nello sviluppo di applicazioni grafiche in Qt, tuttavia possiamo vedere dall’esempio seguente come esso possa essere applicato in classi che non hanno nulla a che vedere con il lato “grafico” delle Qt.
class Impiegato : public QObject {
    Q_OBJECT
    public:
        Impiegato() { miosalario = 0; }
        int salario() const { return miosalario; }
    public slots:
        void setSalario(int nuovo);
    signals:
        void salarioCambiato(int nuovo);
    private:
        int miosalario;
};

void Impiegato::setSalario(int nuovo) {
    if (nuovo != miosalario) {
        miosalario = nuovo;
        emit salarioCambiato(miosalario);
    }
}
Da questo stralcio di codice possiamo ricavare due osservazioni interessanti. La prima è che le funzioni slot sono del tutto identiche a classiche funzioni C++ e questo significa che possono tranquillamente essere invocate nel modo tradizionale. Il secondo punto è l’introduzione di alcune nuove parole chiave come signals, slots e emit. Queste parole chiave in realtà non sono altro che macro definite nella libreria Qt ma che svolgono un ruolo molto importante nel Meta-Object System.
Un altra cosa che è bene precisare è l’implementazione di setSalario: essa è infatti progettata in modo tale da cambiare solamente se nuovo è diverso da miosalario in modo tale da evitare che si cada in un ciclo infinito in caso di connessione ciclica (ad esempio connettere il segnale salarioCambiato ad un istanza di Impiegato).
L’uso di questo meccanismo crea però un anello in più nella fase di compilazione. Per assicurare che il processo moc vada a buon fine è necessario generare il file di compilazione (makefile) tramita un applicazione ad-hoc: qmake. L’uso di qmake è eccessivamente semplice quindi non approfondirò l’uso di questo tool.
A questo punto avete a disposizione uno strumento meravigliosamente efficiente per la comunicazione fra oggetti della vostra applicazione, sia essa con interfaccia grafica sia senza. Non vi resta che approfondire questa tecnologia con qualche manciata di tutorial.

 

FirefoxTutti conoscono Firefox. Tutti conoscono l’infinito numerabile dei suoi plugin. Pochi sanno però come cominciare a sviluppare tali plugin. E a questo serve questo piccolo tutorial. Non vedremo ora quali sono i passi per sviluppare un plugin ma vi mostrerò i passi e gli strumenti preliminari che servono a semplificare lo sviluppo. Ma cominciamo subito senza perderci in chiacchiere.

CONFIGURARE L’AMBIENTE

La prima cosa da fare, per evitare di incasinare le configurazioni originali, è quello di creare un nostro profilo di sviluppo. Possiamo lanciarlo semplicemente con:

/usr/bin/firefox -no-remote -P dev

In questo modo avvieremeno un’altro profilo di firefox chiamato dev.

Adesso dobbiamo impostare alcune opzioni che ci permetteranno di ottenere un maggior numero di informazioni sulle attività di firefox e un maggior controllo su di esse. Apriamo il classico about:config e all’interno impostiamo le seguenti variabili:

  • javascript.options.showInConsole = true. Abilita il Log di molti errori.
  • nglayout.debug.disable_xul_cache = true. Disabilita la cache XUL in modo tale che modifiche alla finestra e ai messaggi di dialogo non necessitino di un riavvio dell’applicazione.
  • browser.dom.window.dump.enabled = true. Abilita l’uso di dump() per stampare messaggi sulla standard consol.
  • javascript.options.strict = true. Abilita i warning JavaScript nella Error Console.
  • extensions.logging.enabled = true. Questo invia una valanga di informazioni sulle estensioni alla Error Console.

E’ anche molto utile questa estensione. Essa offre una comoda interfaccia grafica per accedere ad alcune impostazioni nascoste di Firefox.

STRUMENTI UTILI

  • DOM Inspector: Questo strumento ci permette di navigare e modificare strutture XML-Based come lo XUL delle interfaccie di Firefox.
  • Venkman: Un semplice debugger per JavaScript.
  • Console: Una potente console JavaScript.
  • ChromeList: Tool per navigare nei file in chrome://
  • ViewAbout: Permette l’accesso ai vari about: tramite una comoda interfaccia grafica.
  • CrashMe!: Uno strumento per analizzare i report di debug dei chrash di firefox.

© 2008-2012 SlashCode Suffusion theme by Sayontan Sinha