2010 June » SlashCode

Qt Creator IDE

Jun 282010

In questi giorni sto studiando abbastanza approfonditamente le Qt e non vi nascondo che mi sto lentamente innamorando di questo framework. Già lo apprezzavo per molti motivi, ma più scendo nel dettaglio più scopro una certa “poesia ingegneristica”. Oggi però non sono qui per parlarvi delle QT, bensì del recente rilascio della nuova versione di Qt Creator.

Qt Creator 2 è l’ultima versione di un IDE multi-piattaforma dedicato alla programmazione in Qt. L’ambiente integra tutti i classici strumenti già noti ai programmatori Qt) in un unico ambiente integrato dotato di un editor, debug e interfacciamento ai più popolari sistemi di controllo di versione. Potete vedere un piccolo tour in questo video:

QtCreator integra un editor piuttosto avanzato.

La finestra dell'editor.

Anche QtDesigner è perfettamente integrato:

QtDesigner all'interno di QtCreator

E la documentazione completa del mondo Qt è accessibile con un semplice click.

QtAssistant in QtCreator

QtCreator è disponibile nei repository delle maggiori distribuzioni anche se, al momento, è disponibile solamente la versione 1.3. Se avete fretta e voglia potete provare la versione 2 scaricandola da qui. La versione per linux è facilmente installabile eseguendo il file .bin che scaricherete. Potete anche installare QtCreator in locale senza cioè sporcare il sistema con un installazione “non ufficiale”.

QtCreator non è attualmente all’altezza di altri colossi degli IDE quali Eclipse o Visual Studio, ma la strada imboccata da Nokia sembra proprio quella di creare una valida e completa alternativa. I presupposti ci sono tutti, non ci resta che aspettare.

Buone nuove da MeeGo

Distribuzioni, News 3 Responses »

Jun 252010

Tempo fa parlai molto bene di Moblin. Ora, come molti già sapranno, Moblin è un progetto praticamente morto e risorto con il nome di MeeGo. MeeGo è il frutto della partnership di Nokia e Intel per la creazione di un sistema operativo che si adatti a tutta una categoria di device: netbook, tablet, connected tv e molto altro. Il principale sistema grafico sono le Qt (di proprietà della Nokia), cosa che rende l’intera distribuzione più appetibile ai miei occhi.

Con il rilascio della versione 1.0, ancora molto cruda ma usabile, abbiamo potuto constatare come MeeGo ricalchi molto da vicino la grafica di Moblin. Tuttavia gira in rete il video della versione per tablet, molto zuccherosa, che mostra le principali caratteristiche del sistema facendo uso della tecnologia touch.

Questo video mi ha lasciato molto affascinato sia per la fluidità delle animazioni sia per l’ottimo approccio di usabilità (senza testarlo personalmente è un giudizio affrettato, ma per ora voglio sbilanciarmi). La domanda che più mi viene spontanea è: come mai tutta questa differenza grafica fra la versione Netbook e quella tablet? Che verrà aggiornata anche la prima? Non lo so. Per ora bisogna aspettare.

Nel frattempo, chi volesse dilettarsi nella scrittura di applicazioni per MeeGo può già trovare SDK e tools di sviluppo all’interno della nuova versione di Qt Creator. Spero che questo video abbia fatto venire l’acquolina in bocca anche a voi.

Come NON si scrive del codice

Generale 6 Responses »

Jun 242010

Ultimamente, lo ammetto, sto scrivendo parecchio meno del solito. Sono oscillazioni naturali, non si possono avere sempre cose intelligenti da dire e in questo caso è meglio tacere piuttosto che scrivere diecimila post uguali sull’ultima emissione gassosa di Google o di chissà quale altro software. Ho passato le ultime settimane per lo più a studiare (anche se non al ritmo che mi aspettavo causa mancanza di fonti e concentrazione) e ad approfondire alcuni miei interessi. Siatene giulivi poiché dispenserò a breve tale conoscenza a fiotti sulle vostre menti assetate.

Ma torniamo a noi. Nell’ultima settimana mi sono trovato a mettere le mani sul sorgente di KPackageKit. Questo sorgente è un vero lavoro machiavellico di ingarbugliamento di idee, completamente privo di documentazione e saltuariamente infarcito di commenti di poco aiuto come granella di nocciola sul gelato. Allorché, in preda al deliro causato dall’essermi letto migliaia di righe di codice senza averci capito quasi nulla, se non a grandi righe, mi è venuta l’idea di buttare due righe su come NON si programma.

Ci sono infatti una manciata di cose che un programmatore non deve mai fare. Una lista di COSE DA NON FARE che troppo spesso vengono fatte al grido di “tanto funziona” e “tanto si capisce”. Risulta quindi più facile spiegarvi cosa non fare piuttosto che insegnarvi il contrario.

1) NON DOCUMENTARE IL CODICE

La risposta del tizio di KPK alla richiesta di documentazione è stata:

I don’t create documentation for KPackageKit because I think libs needs to be docummented, and if you read the lib’s docs you will understand KPackageKit

Permettetemi di dissentire. E’ normale che un programmatore debba conoscere la documentazione delle librerie Y alla base di un progetto X, ma ciò non toglie che anche il progetto X debba essere documentato! La documentazione di X infatti serve, come minimo, a spiegare come viene utilizzata la libreria Y all’interno di X. La documentazione serve per aiutare chi mette le mani sul codice per la prima volta, fornisce un filo rosso da seguire per muovere i primi passi all’interno del codice senza perdersi e in modo efficiente, spiega quali sono i moduli, il loro funzionamento e come sono relazionati fra di loro. Tutte cose che si possono apprendere dal codice ma che necessita di un enormità di tempo.

Questo fa quindi perdere tempo al novello programmatore e spesso perdere tempo significa far perdere la voglia.

2) DESCRIVERE IL CODICE

Altro errore frequente è quello di descrivere il codice nei commenti. I commenti devono descrivere le intenzioni di un passaggio non tutti i dettagli. Dovete infatti assumere che chi legge il codice conosca il linguaggio e gran parte delle librerie sottostanti.

/* COMMENTO ERRATO:

 * Se a è maggiore di b restituisce a, altrimenti b.

 */



/* COMMENTO GIUSTO:

 * Restituisce il più grande fra a e b.

 */

if (a &gt; b)

    return a

else

    return b

Ora, quello sopra era un esempio piuttosto idiota ma spero sia chiaro il concetto. In sintesi i commenti dovrebbero descrivere tutto ciò che non è chiaramente intuibile leggendo il codice nei dintorni.

3) USARE CONVENZIONI AD-PERSONAM

Questo si traduce in un semplice usate le convenzioni del linguaggio. Questo va fatto sempre. Anche se una cosa è sintatticamente corretta non vuol dire che lo sia. Se nel linguaggio le classi cominciano per maiuscola NON fate classi che non cominciano per maiuscola. Questo serve a far subito capire ad altri programmatori il significato di una parola all’interno del codice. Se io leggo in un codice C++ la parola supereroe io penso che sia una variabile e non una classe. Se invece scrivete SuperEroe allora è chiaro che tale parola si riferisce ad una classe. Semplificando di molto il mio lavoro.

Oltre a questo le convenzioni di un linguaggio indicano la via corretta per molti altri aspetti. Se avete intenzione di infrangere delle convenzioni documentatelo. Come, ad esempio, fa Google con le linee guida per python.

4) NON MANTENERE UNA COERENZA INTERNA

Cosa più semplice a farsi che a dirsi ma che spesso viene del tutto ignorata. Un esempio di coerenza interna è la posizione dei parametri di un metodo o di una funzione oppure il nome delle funzioni. Se decidiamo che tutte le funzioni che accettano in ingresso un vettore finiscano con la lettera v allora dobbiamo accertarci di seguire questa regola per tutto il progetto. Se decidiamo che il primo parametro delle funzioni che si riferiscono ad una Persona sia il nome allora dobbiamo accertarci che sia sempre così.

5) LASCIARE BOLLE DI CODICE SOTTO COMMENTO

Può capitare che, nel corso della scrittura di un programma si commentino grandi parti di una funzione o interi metodi. Questo può servire ad isolare del codice buggato o a nascondere funzionalità incomplete. Tuttavia, sebbene questo vada bene in rami locali personali non dovrebbe mai essere lasciato in rami pubblici. Se una funzione funziona bene, altrimenti la togliamo. Queste bolle di codice creano gran confusione e soprattutto un programmatore intento a modificare il codice se le ritrova in mezzo alle scatole senza sapere se le può togliere oppure no.

6) CHIAMARE LE VARIABILI CON UNA LETTERA O CON NOMI A CASO

I nomi delle variabili dovrebbero essere piuttosto esplicativi. Ad esclusione di contatori ed iteratori, una variabile non dovrebbe mai avere un nome di una sola lettere. A meno che l’oggetto a cui si riferisce non sia proprio un qualcosa identificabile da una lettera (ad esempio le coordinate x e y di un punto). Non vedo dove sia il problema a scrivere variabili di una decina di caratteri considerando che tutti gli editor hanno l’auto-completamento.

7) ORGANIZZARE IL CODICE SENZA CRITERIO

Il codice va diviso e organizzato in macro-moduli (o package, come si chiamano in molti linguaggi) che siano coerenti fra loro. Questo per consentire un rapido accesso all’insieme dei moduli che gestiscono una data funzionalità. Questi macro-moduli vanno assolutamente documentati.

8 ) SCRIVERE CODICE SENZA PROGETTO

Questo è il punto fondamentale. I programmi vanno prima scritti a computer spento. Non fatevi prendere dalla fretta di scrivere e compilare perché al 90% esce un casino. Questo può andare bene per piccoli progetti e roba semplice ma per qualunque cosa di complesso è un suicidio. Programmate tutto su carta. Scrivete le classi di cui avete bisogno, le relazioni fra le stesse, le operazioni salienti, i moduli da fare e i package in cui suddividerli. Dopo un paio di giorni di analisi a computer spento vedrete che con mezza giornata scriverete migliaia di righe di codice come se fossero sonetti in rima baciata.

Ovviamente mentre scriverete e proverete il codice sul serio salteranno parecchie cose di cui non avevate tenuto conto o errori di progetto. Ma non fa nulla. Questa è la prassi, è il modo in cui vanno fatte le cose.

CONCLUSIONE

Ora spero che appenderete questi 8 punti sulla vostra parete perché io non ho più voglia di impiccarmi mentre leggo del codice scritto e documentato da un macaco. Se seguite i miei consigli e non fate questi 8 punti (in realtà potrebbero essere di più ma oggi sono buono) vedrete che sarà tutto più facile per voi, sia per chi ha intenzione di aiutarvi.

Buona giornata.

Qt: Segnali e Slot

C/C++, Guide, Varie No Responses »

Jun 192010

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.

Come integrare GIT e SVN

CVS No Responses »

Jun 182010

Git non è l’unico sistema di controllo di versione esistente (aimè! xD). Ad esempio SVN è il sistema utilizzato ufficialmente dal progetto KDE (anche se c’è l’intenzione di passare a Git nel prossimo futuro). A questo punto sorge spontaneo chiedersi come si possa fare per partecipare a questi progetti ma, allo stesso tempo, continuare ad utilizzare il nostro (mio) amato Git?

La soluzione, ovviamente, esiste. Basta installare il pacchetto git-svn che offre un comodo layer di interfaccia fra Git e Svn. Ma vediamo come usarlo:

La prima cosa da fare è di clonare il repository svn. Questo può essere fatto semplicemente con il comando:

git svn clone  ?optional-directory-name?

Lo svantaggio di questa operazione è data però dalla lentezza. Questo perché la cronologia di git viene riempita scaricando dal repo svn ogni commit singolarmente. Quindi è meglio che eseguiate questo comando solamente quando avete un po’ di tempo da perdere.

Il prossimo comando serve a tenere aggiornata la nostra copia locale rispetto al trunk remoto. Il corrispettivo, in pratica, del comando svn update.

git svn rebase

Per ultimo, vediamo invece come inviare il nostro ramo locale nel ramo remoto:

git svn dcommit

Per tutto il resto del tempo potete continuare ad utilizzare i classici comandi git, potete creare rami locali, riunirli, fare tutto ciò che vi pare come se il progetto fosse nativamente gestito da git.

Un vantaggio niente male eh?

Git: Configurazioni Utili

CVS, Guide No Responses »

Jun 162010

Come spero sappiate amo Git con tutto il mio cuore. Volevo quindi appuntare una serie di configurazioni che trovo utilissime. Una piccola nota nel caso vi dimentichiate alcuni pezzi di sintassi (e io lo dimentico spesso).

1 – UTENTE

Inserire l’utente è fondamentale per fare in modo che i commit non escano con nomi casuali e irriconoscibili.

git config --global user.name "Il vostro nome"

git config --global user.email tuaemail@dominio.it

2 – COLORI

Per migliorare la leggibilità è cosa buona e giusta abilitare i colori nell’output dei comandi di git.

git config --global color.branch auto

git config --global color.diff auto

git config --global color.interactive auto

git config --global color.status auto

3 – MERGE

Prima cosa da fare è configurare lo strumento che useremo per risolvere i conflitti del merge. Io su KDE uso kdiff3 ma per GNOME esiste un alternativa altrettanto valida di nome meld.

Per Kdiff3 bisogna però aggiungere una configurazione ulteriore. Andate a Settings, Configure KDiff3, Integration. Nella casella ‘Command line options to ignore’, aggiungete il parametro ‘;–’.

A questo punto vi basta configurare git.

git config --global merge.tool kdiff3

4 – EDITOR

Potete anche configurare l’editor che git userà quando avrà bisogno di farvi editare del testo.

git config --global core.editor vim

Potete sceglierne anche uno con interfaccia grafica.

Applicazioni Web-Side e Open Source

News No Responses »

Jun 092010

Ho già parlato del cloud in precedenza. Sento però la necessità di ribadire alcuni concetti e di darvi qualche spunto di riflessione su quello che sembra la deriva inevitabile dei prossimi anni. Non perché mi piaccia essere ripetitivo bensì perché penso di poter offrire una visione più pulita del fenomeno e inoltre l’irruzione del “cloud selvaggio” mi spaventa poco a poco sempre di più. Mi sembra infatti che il cloud stia pian piano strappando via la mia possibilità di maneggiare le applicazioni, di sentirle “mie” e di poterne avere sempre e comunque accesso.

Viviamo infatti in un mondo fatto di bande larghe, di spostamenti frenetici, computer che si rimpiccioliscono, telefoni che si ingrandiscono e connettività sempre più estesa e radicata (tranne in Italia, ovviamente). E’ chiaro quindi che, in una struttura sociale e tecnologica del genere, diventa sempre più importante la possibilità di collocare dati e applicazioni personali in luoghi virtualmente sempre accessibili.

Un professionista può svolgere il proprio lavoro nel suo ufficio e andare a casa sicuro che, nel caso abbia la necessità di modificare urgentemente un documento, può benissimo accedere agli stessi strumenti e agli stessi documenti del posto di lavoro. Uno studente può scrivere la sua tesi su qualunque dispositivo, portatile, computer dell’università, computer di casa, senza doversi porre il problema di dover sincronizzare le varie versioni del suo lavoro. O più semplicemente, chi come me scrive circa diecimila caratteri al giorno fra guide e altri testi e è sistematicamente connesso da computer diversi, non deve più preoccuparsi di non poter accedere ai suoi documenti.

Questo si chiama Cloud Computing. Tale parola vuole proprio rappresentare lo stato di vaporizzazione che assumono dati e applicazioni in questo sistema di networking. I documenti e i dati dell’utente sono a nuvola per l’intera rete internet, perdono cioè la loro collocazione fisica per rinascere come la fenice in una forma di pura essenza di dati.

In realtà una collocazione fisica ce l’hanno e come essendo, per forza di cose, immagazzinati in centinaia di server sparsi per il mondo, in molteplice copia, insieme ai dati di migliaia di altri utenti. Un pensiero che può far rabbrividire alcuni di voi a primo impatto ma che, in realtà, è uno scenario piuttosto normale. Tenere dei dati in server cloud non è più pericoloso che tenerli nel nostro pc e, anzi, forse lo è anche meno.

Ma tralasciamo il concetto della privacy, tema caldo e complesso, e concentriamoci su altri aspetti legati alle libertà digitali a me tanto care. Il punto da cui partiamo è semplice: le applicazioni cloud servono. Indipendentemente dai nostri gusti e visioni del mondo la comodità di utilizzare sistema cloud è indubitabile. Le utilizzo anche io anche se, come vedremo, rischiano di essere un grave intralcio alle mie libertà digitali.

A questo punto però ci troviamo di fronte a due scenari del tutto contrapposti. Da una parte abbiamo la necessità di utilizzare facilmente applicazioni cloud, dall’altra le minacce di inaccessibilità dei dati in caso di disconnessione, l’impossibilità di accedere al sorgente dell’applicazione (e, nel caso fosse disponibile, l’impossibilità di verificare che il software eseguito sia esattamente quello corrispondente ai sorgenti) e altre magagne ci spingono a vedere il cloud come una seria minaccia a tutto quello che abbiamo: programmi liberi, dati privati, ecc…

Esiste però un modo per conciliare le due cose? Si. Una sorta di cloud leggero che non è completamente decentralizzato: invece di decentralizzare dati e applicazioni permanentemente si effettua una delocalizzazione parziale. Ma andiamo a vedere i punti fondamentali.

DATI

Punto primo. I dati non sono tenuti in remoto ma vengono sincronizzati a due tempi (file modificato -> aggiornamento su server remoto -> aggiornamento su altra piattaforma). Questo problema risolve di colpo due bei problemi:

I dati sono su un server remoto come nel caso di un cloud puro. Tuttavia utilizzando tecnologie Zero-Knowledge, attuando cioè un processo di codifica/decodifica solo sui terminali finali, è possibile offuscare i dati sul server in modo matematicamente sicuro.
I dati sono sempre accessibili. Il meccanismo garantisce che almeno su un terminale dell’utente sia presente la versione super-aggiornata dei dati. Il server non può quindi “sequestrare i dati” per nessun motivo. Inoltre i dati sono anche gestibili come file tradizionali e quindi, in caso di mancata connessione ad internet in uno dei terminali è possibile effettuare la sincronizzazione “alla vecchia maniera”.

Quest’approccio è già utilizzato da molti servizi come UbuntuOne o Dropbox. Questi servizi sono un ottima alternativa, per il momento, al cloud puro.

APPLICAZIONI

Le applicazioni cloud non sono comode solamente perché ci permettono di accedere ai dati in qualunque momento e in qualunque luogo ma anche perché la stessa applicazione è disponibile ovunque con le stesse configurazioni, sempre aggiornate e funzionanti.

Qui la faccenda è più complicata. Si potrebbe infatti attuare un meccanismo di sincronizzazione per le configurazioni e le applicazioni analogo a quello dei dati. Le configurazioni infatti sono fondamentalmente dei file. La soluzione semplicistica è quindi:

Creare un architettura che sincronizzi dinamicamente anche le configurazioni dell’utente nelle varie applicazioni. Una cosa simile sembra sarà implementata da OwnCloud, progetto per KDE e permetterà di sincronizzare tutte le configurazioni della galassia applicativa di KDE.
Creare un architettura che sincronizzi dinamecamente le applicazioni. Questa cosa non è molto difficile da implementare su GNU/Linux in quanto si tratta solamente di opportune chiamate ai vari gestori pacchetti.

Quest’approccio ha però limiti evidenti. In primis il sistema è OS-Dipendent. Secondo devo avere la possibilità di installare applicazioni sul mio sistema. Questo non è un problema per utenti che utilizzano il computer solamente da terminali di proprietà ma può diventare problematico in alcuni casi frequenti: non è possibile utilizzare le proprie applicazioni se si accede ad internet da computer di cui non si è proprietario (università, hotel, casa di un amico e roba simile) oppure da computer in cui si è, per scelta o per necessità, installato un sistema operativo differente ed incompatibile con quello installato nella nostra macchina principale.

SOLUZIONI?

Qui si va nella pura speculazione di idee. Non ho soluzioni ma semplicemente alcune domande la cui risposta potrebbe essere un buon inizio.

Chi ha sviluppato il protocollo X11, 23 anni fa, è stato tremendamente lungimirante. Tale protocollo come ben sapete permette infatti di rendere disponibili finestre che mostrano l’interfaccia di programmi che girano in remoto! È possibile, quindi, rendere disponibile un database remoto di applicazioni da cui un utente può, in caso di emergenza, eseguire il programma senza averlo installato?
È possibile far si che le applicazioni leggano le configurazioni che si trovano memorizzate in un server remoto (di quelli che sincronizzano le configurazioni fra pc di cui abbiamo parlato sopra)? Questo permetterebbe alle eventuali applicazioni remote del punto 1 di essere sempre correttamente configurate.
È possibile creare un unica applicazione web-side che “emuli” un sistema X/SSH in modo da eseguire il protocollo X attraverso un browser? Questo permetterebbe di utilizzare tali applicazioni anche su sistemi non dotati di Xorg (vedi Windows).
Nel caso in cui la risposta ad alcune domande sopracitate fosse no, sarebbe possibile adattare il protocollo grafico, le librerie o inserire un layer di astrazione fra le due, per rendere possibili queste cose?

Se la risposta a queste domande fosse si avremmo un corrispettivo completamente OpenSource e basato su applicazioni “reali” e locali che spaccherebbe le ossa al Cloud proprietario e completamente decentralizzato. Tuttavia non conosco la risposta di nessuna di queste domande. Spero comunque di avervi dato alcuni spunti di riflessione.

Sux – Quando Sudo non c’e’

Distribuzioni No Responses »

Jun 092010

Questo post è un piccolo “how-to” per chi utilizza distribuzioni che non supportano nativamente sudo. In questi casi, come ben sapete, si utilizza il comando su per ottenere i privilegi di amministratore.

Il problema di questa procedura è che, nel momento che si entra nella shell di root, non si è più l’utente “utente” ma si è l’utente “root”. Questo con sudo non accade perché utilizzandolo non si “diventa root” ma si “si utilizza un applicazione come se fossi root”.

Cosa comporta essere l’utente root? La pecca più vistosa è l’inabilità di lanciare un applicazione grafica. Se ci si prova, infatti, si ricevono errori come:

Session bus not found

o che non è possibile accedere a Xorg.

A questo c’è una soluzione molto semplice: sux. Sux, è perfettamente analogo a su con l’importante differenza che permette di avviare applicazioni grafiche.

Una soluzione pratica, veloce e indipendente dal sistema desktop.

PS: Per le applicazioni di KDE spesso è necessario precedere il nome dell’eseguibile dal comando dbus-launch per agganciare l’applicativo al sistema DBus della sessione corrente.

Kubuntu alla resa dei conti

Distribuzioni 4 Responses »

Jun 042010

Come saprà già chi frequenta questo blog non ho mai risparmiato a Kubuntu aspre critiche. Sono critiche nate dal mio amore per KDE e che quindi vorrei veder valorizzato nella distribuzione più utilizzata e pubblicizzata degli ultimi anni. Tuttavia la situazione attuale non sembra migliorare sensibilmente.

Per questa ragione mi sento in dovere mio malgrado di continuare a punzecchiare il sistema e il gruppo di sviluppo di Kubuntu. Anche perché, dato il periodo di forti innovazioni che ha vissuto e vivrà Ubuntu, la K rischia veramente di perdersi per strada. Siamo quindi alla resa dei conti finale.

Basterebbe molto poco per riportare Kubuntu ad un livello di distanza da Ubuntu accettabile:

Creare uno stile grafico caratteristico.
Integrazione di Ubuntu One con Dolphin.
Una versione Qt del Software Center.
Un plugin di Amarok per Ubuntu Music Store.
Integrazione di vari strumenti di comunicazione in un unico plasmoide in stile MeMenù

E con queste cinque cose saremmo già un bel pezzo avanti.

Questa discussione è anche portata avanti dal sito http://www.k-it.it/ che vi consiglio caldamente di visitare. Il sito raccoglie le proposte di migliorie varie da apportare a Kubuntu che verranno proposte poi al team che si occupa del mantenimento del progetto.

Appunto. Anche qui ci sarebbe da ridire. Ad esempio perché il team contact del gruppo locale italiano è un avvocato londinese? Ho provato a cercare informazioni su chi fossero i responsabili dello sviluppo del gruppo italiano, ma dopo essere stato sballottolato da vari link in duemila pagine diverse non sono riuscito a cavare un ragno dal buco.

Così, mentre il sito Kit attua un azione propositiva, io vorrei adoperarmi in qualcosa di attuativo. Radunare un manipolo di sviluppatori per abbozzare questi 5 punti che reputo fondamentali e presentarsi ai mantainers di Kubuntu con qualcosa di più che un centinaio di proposte scollegate.

Ovviamente adesso subentra il problema principale: radunare una discreta cerchia di contatti per cominciare ad attuare seriamente questo proposito. Ma di quanto sia scoraggiante questo punto ho già parlato altrove.

La posta di Slashcode – Come iniziare a programmare

Generale 12 Responses »

Jun 032010

A parte il titolo stupido di questa “rubrica” volevo pubblicare la risposta ad una domanda che mi è arrivata da Facebook. La domanda è la tradizionale “Come faccio a programmare come un Dio?”. Domanda la cui risposta basterebbe da sola a riempire corsi e tonnellate di guide. Tuttavia ho scritto un mezzo poema e, unito al fatto che la risposta può servire anche ad altri, mi sembra sprecato lasciarla nella mia casella di posta in uscita.

La domanda era la seguente:

io avrei bisogno di un consiglio se possibile: vorrei sapere come sei arrivato e dove hai imparato a fare queste cose cosi complesse?io provo provo e provo ma fallisco miserabilmente.

Ed ecco la risposta.

Mi fanno in molti questa domanda e difficilmente riesco a dare risposte soddisfacenti.

Per primo credo che sia necessario apprendere una forma mentis che va al di là del linguaggio usato per programmare. Questo permette di passare facilmente da un linguaggio ad un altro e di “progettare” un applicazione ancor prima di scrivere una sola riga di codice.

Tale impostazione è la cosa a mio avviso più importante. Bisogna imparare a trattare le cose che vogliamo fare come entità matematiche perché , fondamentalmente, i computer sanno fare solo calcoli matematici.

Il problema è, come sempre, trovare il modo per entrare in quest’ottica. Il primo modo è avere una preparazione matematica basilare: la matematica è di per se un “linguaggio” e conoscerlo aiuta molto. Secondo c’è il lato puramente informatico. Riguardo a questo ci sono un paio di consigli che con l’esperienza mi sento di dare:

1) Scegliersi un linguaggio e concentrarsi su quello. Non cambiare quindi linguaggio nella speranza che vada meglio: le basi concettuali sono sempre le stesse.

2) La scelta del linguaggio è molto importante: linguaggi troppo “severi” rischiano di farti concentrare troppo sul lato “macchina” del linguaggio, linguaggi troppo “di bocca buona”, al contrario, astraggono talmente tanto la programmazione che difficilmente si imparano i suoi aspetti fondamentali. Io quindi solitamente consiglio delle buone vie di mezzo come C# o Java (tanto per usare i più famosi). Python è molto facile ma lo trovo “poco istruttivo”: è molto più facile passare da C# o Java ad un altro linguaggio piuttosto che passarci da Python.

3) Perseverare. Una volta appresa la sintassi di un linguaggio non si sa programmare. A programmare si impara programmando: piazzarsi un obbiettivo non troppo elevato e iniziare a portarlo avanti. Anche abbandonarlo se si rivela troppo alto ma l’importante è provarci. Il 90% delle cose che ho imparato le ho imparate sbattendoci la testa, cercando soluzioni su Google, chiedendo a gente più esperta. Quindi ti consiglio caldamente di imparare la sintassi di un linguaggio e di usare quello per realizzare piccoli progetti personali. Roba anche inutile ma utile per imparare. Ad esempio scoprirai che è molto istruttivo cercare di implementare una specie di rubrica da terminale.

4) Ultimo consiglio: le librerie. Quando si padroneggia un linguaggio è giunge il momento di imparare qualche libreria: interfacce grafiche (Gtk o QT ad esempio), sistemi audio (gstreamer o Xine), per l’interazione col web, e così via… Questa è l’unica parte veramente difficile E a questo punto non puoi far a meno di chiedere e domandare in giro e dovrai pensarci solo a tempo debito.

Mi sono dilungato anche troppo. Ti ringrazio per la domanda che mi ha spinto a una piccola riflessione e spero che tu possa continuare a provarci. Per ogni domanda che ti verrà in mente durante il tuo percorso puoi sempre trovarmi su Slashcode o chiedere sul forum di LinuxQualityHelp.

Page 1 of 212 »