Una delle funzionalità offerte da KDE4 a sviluppatori ed utenti è quella di gestire i lavori a lungo termine delle applicazioni mediante un componente del vassoio di sistema. L’infrastruttura mette a disposizione dell’utente un unica locazione dalla quale può controllare l’andamento delle operazioni, opzionalmente sospenderle, sbloccarle o controllarne l’esito anche dopo il loro termine. Si evita così che ogni applicazione che intende avvalersi di questa funzionalità debba implementare una interfaccia di controllo. Dal punto di vista del programmatore, la fatica di imparare una nuova serie di API è ripagato dal fatto che è l’ambiente a prendersi in carico il compito di interagire con l’utilizzatore, sia per quello che riguarda l’aspetto funzionale, sia per l’interfaccia utente. Ovviamente i soli lavori di cui dovrà essere notificato lo stato di avanzamento mediante questa caratteristica sono solo quelli a lungo termine, per evitare di confondere l’utente con una miriade di messaggi irrilevanti.

Vediamo ora come si può sfruttare questa funzionalità:

Le applicazioni che intendono sfruttare il sistema di notifica devono incapsulare direttamente o indirettamente l’attività in una struttura KIO::Job, ad esempio derivando da essa la nostra classe di esempio KJobTest.

	#include <kjob.h>
	class KJobTest : public KIO::Job

Se si desidera che l’utente, una volta comparsa la notifica, possa mettere i lavori in pausa, riprenderli o annullarli occorre, nella nostra classe, chiamare la funzione

    setCapabilities()

cui va passato come argomento un insieme di flag che ne determinano il comportamento. Con il valori Kjob::Suspendable si concede all’utente la possibilità di sospendere un lavoro, con KJob::Killable anche di terminarlo. Per abilitare entrambe le funzionalità, scriveremo:

    setCapabilities(KJob::Killable|KJob::Suspendable);

Quando si è pronti per presentare il job all’utente, lo si deve registrare presso una struttura globale:

	KIO::getJobTracker()->registerJob(m_jobTest);

Da questo punto in poi il job è visibile all’utente. Emettendo il segnale ‘infoMessage‘ si può forzare il pannello a mostrare la descrizione desiderata per indicare il proprio job.

Il job può essere attivato in modalità sincrona o asincrona. Nel primo caso tutto quello che dovrà fare l’applicazione per gestire il job sarà richiamarne il metodo ‘exec‘, definito nella classe base, che restituirà l’esito mediante un valore booleano. Dietro le quinte verrà attivato un loop di messaggi nascosto. Riporto l’esempio di utilizzo definito nella documentazione KDE:

void SomeClass::methodWithSynchronousJobCall()
 {
   KJob *job = someoperation( some parameters );
   if ( !job->exec() )
   {
       // An error occurred
   }
   else
   {
       // Do something
   }
 }

Nel caso si intenda utilizzare il job in modo asincrono, metodo preferito per la gestione di operazioni a lungo termine, occorre attivare il job attraverso il metodo start(), richiamato in modo nascosto anche nel caso sincrono, e mettersi in attesa dei risultati collegando il segnale ‘result‘ ad uno slot. Ecco l’esempio relativo, sempre tratto dalla documentazione KDE:

 void SomeClass::methodWithAsynchronousJobCall()
 {
   KJob * job = someoperation( some parameters );
   connect( job, SIGNAL(result(KJob*)), this, SLOT(handleResult(KJob*)) );
   job->start();
 }
 void SomeClass::handleResult( KJob *job )
 {
   if ( job->error() )
       doSomething();
 }

Nel metodo start(), da reimplementare nella nostra classe derivata da KJob, occorre utilizzare un meccanismo asincrono, come ad esempio un timer di tipo oneShot, per innescare il job, per evitare che un’attivazione direttamente nella funzione start() provochi un malfunzionamento della gestione sincrona del job attraverso la funzione exec(), per motivi derivanti dall’implementazione della funzione exec stessa. Se abbiamo deciso di non utilizzare mai l’interfaccia sincrona potrebbe sembrare una precauzione inutile, ma scrivendo codice che si deve integrare in un ambiente, occorre sempre rispettarne i dettami.

Quando l’utente decide di intervenire nella vita del job cambiandone lo stato, il pannello del vassoio di sistema richiamerà metodi doSuspend(), doResume() e doKill() del nostro job, mediante i quali si potranno realizzare le dovute azioni.

Durante il suo ciclo di vita, il job può inviare al pannello segnali riguardo il proprio stato o la percentuale di avanzamento.

Emettendo il seguente segnale:

emit infoMessage(job, messageText, messageRichText );

si può provocare la comparsa della scritta relativa allo stato puntuale del job. Allo stesso modo è possibile inviare informazioni relative alla velocità attuale ed alla unità di misura utilizzata, nel caso sia compresa tra quelle dell’enumeratore ‘Unit’ di KJob.

Come esempio di utilizzo possiamo utilizzare un semplice programma, jobsample, mediante il quale è possibile provare le tecniche esposte, configurare i parametri principali a disposizione di un job ed osservare i risultati.

I sorgenti di jobsample sono disponibili a questo indirizzo:

http://www.tsc4.com/lbell/presentazioni/src/jobsample.tgz

Finestra principale di jobsample:

job sample in esecuzione:

Con il passaggio del trunk di KDE a Qt4.6 avvenuto il 10 ottobre non è più possibile utilizzare il sistema di build basato su kdesvn-build 1.9.1, dato che i sorgenti delle librerie Qt sono affidati a git e kdesvn-build si interfaccia con Subversion, occorrerebbe gestire manualmente il modulo qt-copy. Occorrerebbe, perché è appena stata rilasciata la versione 1.10, che è in grado di gestire git per il solo modulo qt-copy. E’ disponibile nel sito ufficiale da un paio di giorni e nel repository svn di KDE in branches/work/kdesvn-build-1.10. Per usarlo, occorre modificare la sezione relativa al modulo qt-copy nel file .kdesvn-build.rc nel modo seguente nella sezione dedicata a git:

module qt-copy
	#opzioni di compilazione
	configure-flags -system-zlib -qt-gif -system-libjpeg -system-libpng \
			-no-exceptions -fast -debug -dbus \
	            -no-phonon # Phonon built separately
	make-options -j2

	# opzioni di gestione git
	branch 4.6-stable-patched
	repository http://git.gitorious.org/+kde-developers/qt/kde-qt.git
end module

Sito di kdesvn-build:

http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php

L’Apple II, il primo personal computer ad avere una diffusione ed un successo mondiali, quando nel 1977 vide la luce sembrò un miracolo di tecnologia; permetteva ad un prezzo accessibile di svolgere una quantità e varietà di compiti concreti come monitorare impianti industriali o di organizzare magazzini o di controllare le scadenze delle assicurazioni. Diciamo che gli utenti si accontentavano delle prestazioni e delle possibilità offerte, cercando di vincere le limitazioni del sistema (velocità e spazio di memoria in primis) con molta pazienza e con molto ingegno, inserendo nei programmi una serie di trucchi che oggi appaiono senza senso. Il sistema aveva 48K RAM e poteva supportarne in modo lineare al massimo 64KB.

Quando uscì il primo personal IBM la ram a disposizione era di 128 o 256KB con il codice di sistema caricato in parte di essa da disco; 640KB divennero uno standard poco dopo. All’avvento del Macintosh, il primo rivoluzionario PC con un’interfaccia grafica basata su finestre ed icone, precursore di tutti i sistemi che si usano oggi, che poteva pavoneggiarsi di una grafica di tipo interamente bitmap, si arrivò a 64K di ROM e 128K di RAM, ed in questo spazio non si trovava solo il codice per gestire la grafica, ma anche quello per permettere a tutti i programmi di terze parti di potersi adeguare ad una stessa metafora di comportamento mentre faceva timidamente la sua apparizione su sistemi di tale fascia il primo codice capace di gestire una rete.

E tutta questa meraviglia in soli 64K di ROM, più il software di sistema in un dischetto da 400K. La ram a disposizione dei programmi applicativi, al netto di quella necessaria al funzionamento del Macintosh stesso era di soli 90K (http://www.folklore.org/StoryView.py?story=Monkey_Lives.txt).

E oggi? Se consideriamo le dimensioni del kernel di Linux rispetto ai tempi dell’Apple II troviamo non solo una crescita esponenziale del software di sistema ma la nascita di una nuovo filone, quasi sconosciuto al mondo visto in precedenza; il sottosistema di rete con relativa infrastruttura di sicurezza, che tramite protocolli di tutti i tipi si avvia a rappresentare una gran parte del codice di sistema. La directory del kernel Linux occupa, con varie versioni installate, da 120 a 475MB sul mio sistema e l’installazione complessiva del sistema e dei programmi applicativi più comuni quasi 10GB.

Questa crescita è avvenuta in in pochi decenni e ricalca la legge di Moore a proposito della crescita delle capacità dell’hardware (http://en.wikipedia.org/wiki/Moore%27s_law). Il fatto è che mentre l’hardware spesso è stato progettato in scala, il software di sistema in questione è stato scritto da zero, praticamente riga dopo riga. Ogni sistema operativo sul mercato ha proposto il proprio server web, il proprio stack di protocolli di rete, con tonnellate di sorgenti spesso inutilmente riscritti solo per esigenze commerciali. I computer non sono più solo strumenti nelle mani di artigiani, ma diventa sempre più difficile sapere cosa li fa effettivamente funzionare e quanto sono sicure le basi cui cui poggia il software applicativo.

Le Scienze sta pubblicando una interessante collana di DVD aventi come tema gli incontri avvenuti al festival della matematica di Roma dello scorso anno. In quello di questo mese vi si trova l‘intervento di Thomas Banchoff focalizzato su Salvator Dalí. Il relatore parla avendo alle spalle uno schermo gigantesco su cui sono mostrate le opere del pittore catalano mentre sono citate. La cosa strana è che, tanto più si parla di un’opera, tanto più il regista zooma sul relatore, stringendo l’inquadratura e non mostrando mai l’argomento del discorso.

Nel numero de ‘Le Scienze’ di questo mese viene svelato il mistero: ci sono problemi di licenza sul materiale video riguardante le opere.

Al di la dell’irritazione per l’assenza dei contenuti video principali in un DVD in vendita, è un po’ surreale che si parli per un’ora di qualcosa che non si può vedere, pure se si sa che esiste.

Una situazione perfettamente in tema con il surrealismo delle opere di Salvator Dalí.

Computers are very versatile tools, used in a variety of situations, to work, listen music, write documents, but it is very difficult to create a comfortable user environment for each task. When working to an important document, mail notifications are very annoying, but turning off completely notifications is not the ideal solution, mails related to the activity are welcomed. What is missing is the possibility that the computer adapts his environment to different activities.

Virtual desktops are the more advanced solution to implement activities today, but this is only a start.

There is a difference between a virtual desktop and an activity: virtual desktop is a collection of resources (windows mainly), an activity is a collection of related resources. You can work for a project, read documents, contact people, receive mails and so on and all these items can stay associated to the activity you are currently operating.

We can roughly consider an activity on top of a collections of virtual desktops.

A ‘recent document’ menu can contain a lot of unrelated documents, a personal letter written in a pause together with work documents and worst, it has a finite length, so new documents of unrelated activities are pushing into oblivion very important bookmarks.

Activities are useful to categorize and filter environment items, but it is not practical to manually label each resource that can reside in an activity, so the workspace should automatically collect informations, like the mylyn plugin in Eclipse world

http://www.ibm.com/developerworks/java/library/j-mylyn2/

When in an activity you can associate not only documents related to that activity, but also contacts, sites, and so on.

We work on different projects and we use the computer for personal activity each day. Computers are universal devices and can be used for different purposes.

As a further example, it is an annoyance to receive mail notifications from people not related to projects ( with obvious exception for emergencies ) in working hours. An activity can filter what that can distract, without hiding information, but focusing out of view not relevant factors.

It is important to have a simple ‘relations’ manager to handle what resources are related to an activity and move or copy them from a workspace to another (maybe using the KDE plasmoid zoom interface).

It is important to have multiple activity configurations, you can use same laptop at work and at home, even applications menu can change in different situations.

Activities attributes and resources should be shared between teams.

There are two types of applications: specialized ones (video, audio, graphics editor for instance ) and generics ones ( word processors, time tracker, etc) that should have different behavior. How horizontal applications like file browsers should behave? Why not filter activity related directories in ‘Open File’ dialogs? Currently this dialog supports only a simple filter that maps to file type (a word processor filter documents, a spreadsheet csv and so on)

How to save data in application specific format and not using specialized Desktop Environment routines? How to integrate, for example, Open Office? We should use the metadata we are using for browsers: the tags, but there is the problem to maintain metadata in sync with data when moving files, doing backups and so on. All the files that user opens or write should be logged, but the metainformations should be stored in the document or in the filesystem?

Even phones have different modes: mute, normal, meeting etc.

Tags and activities are separate concepts, tags are traversal and additive, activities are thematic.

Desktop Environment should leads the user how to enter and how to exit from an activity. We should decrease normal desktops visual clutter that confuses the user about his state.

Another problem is how to include external resources if the filter are restrictives, maybe by adding a button in each “Open File” dialog that let us choose to stay in the current activity environment or see all the resources.

Other open problems are how to integrate in this vision externals resources like network infrastructure, network, printers, etc.

Talking about concrete cases, like the recent documents menu, why not make it central for a desktop or expand it to order it for ( I often need this ) creation date, write date, access timestamp or access frequency, category?

Why not display this menu in a cloud representation? More, the vertical list used is a very short and useless representation. A timeline can be more useful.

Different activities can be created for different purposes even using same programs.

In a desktop system I can save programs state on disk passing from an activity to another one, but not on phone system for device limits.

Anyway each journey begins with a single step, and Plasma is a good one.

http://techbase.kde.org/Projects/Plasma

Scrivendo una piccola utility per Plasma mi sono fatto tentare dall’uso della nuova versione di WebKit per gestire l’interfaccia utente.

In effetti integrare WebKit in un programma QT o KDE non è troppo difficile, grazie all’uso degli slot e delle metainformazioni che QT aggiunge alle classi. E’ possibile richiamare direttamente i metodi di oggetti residenti nel nostro programma, sfruttando il meccanismo dei segnali e degli slot, dalla pagina HTML via Javascript. Per prima cosa occorre inserire nelle pagine HTML riferimenti agli oggetti C++ della nostra applicazione come se fossero variabili Javascript native, utilizzando un identificatore che verrà mappato sugli oggetti fisici a tempo debito. Fatto ciò possiamo codificare funzioni Javascript che sfruttino i metodi dichiarati come slot, in corrispondenza di determinati eventi, come la pressione di un pulsante. Possiamo quindi dalla pagina HTML eseguire metodi dei nostri oggetti passando quali parametri entità definite al livello HTML, come ad esempio i valori di un form.

Ogni collegamento tra WebKit e la nostra applicazione avverrà sempre tramite funzioni Javascript, quindi sarà WebKit ad iniziare le operazioni.

Facciamo un esempio:

Supponiamo che il nostro obiettivo sia di richiamare da Javascript il metodo ‘reload’ di un’istanza di una classe C++ descritta in questo modo:

class DBusApplet : public
Plasma::PopupApplet
{
    Q_OBJECT
    ...
public
slots:
    void reload(const QString &selection);
private:
    ...
};

in Javascript la nostra istanza può essere mappata come segue, assumendo che sia stata associata all’identificatore ‘appletInterface’:

function execute(selection)
{
    appletInterface.reload(selection);
}

Dato che la conversione dei tipi di base è automatica, quello che occorre fare è ‘iniettare’ gli oggetti C++ all’interno del componente WebKit, ma è necessario attendere che sia il componente ad avvertirci del momento più opportuno.

Al termine del caricamento di una pagina HTML, che la si assegni direttamente da programma o attraverso un URL, il frame corrente emette infatti il segnale “javaScriptWindowObjectCleared”, che occorre avere cura di catturare nel solito modo che QT ci mette a disposizione:

connect(page()->mainFrame(),

SIGNAL(javaScriptWindowObjectCleared()), this, SLOT(populateJavaScriptWindowObject()));

Alla ricezione del segnale possiamo, attraverso il metodo collegato (nell’esempio precedente ‘populateJavaScriptWindowObject’), passare finalmente il riferimento dei nostri oggetti a WebKit attraverso il metodo addToJavaScriptWindowObject, i cui argomenti sono il nome della variabile Javascript associata e l’indirizzo dell’oggetto stesso.

page->mainFrame()->addToJavaScriptWindowObject(“appletInterface”, this);

Se tentassimo di associare i nostri oggetti prima che la pagina sia stata effettivamente caricata, il collegamento non avrebbe successo.

http://doc.trolltech.com/4.4/qtwebkit.html

http://webkit.org/

http://code.google.com/p/dbusapplet/

]]> http://lbell.wordpress.com/2009/03/19/un-viaggio-in-webkit-transitando-per-plasmaland/feed/ 0 lbell http://lbell.wordpress.com/2009/02/09/in-perfetta-forma/ http://lbell.wordpress.com/2009/02/09/in-perfetta-forma/#comments Mon, 09 Feb 2009 22:51:24 +0000 lbell http://lbell.wordpress.com/?p=132 ]]>

Quando frequentavo le superiori, durante le lezioni di italiano mi era difficile accettare, nonostante gli sforzi degli insegnanti, che la forma di uno scritto potesse avere altrettanta importanza del suo contenuto.

Ora che lavoro nel campo dell’informatica, una disciplina il cui scopo è produrre risultati concreti sotto forma di programmi, strumenti che svolgono una precisa funzione, mi trovo ad apprezzare l’importanza della forma con cui si producono i programmi stessi. E non intendo la forma con cui si presenta il prodotto al cliente, ma quella che viene impiegata nel processo di produzione.
La forma, impersonata da regole, procedure e, appunto, formalismi come l’uso di UML, assume un’importanza in sé durante la stesura del software, anche se entra in gioco solamente come ausilio. Nella produzione di un programma la cura della forma, ironicamente, è indispensabile per la solidità del prodotto.
Il formalismo nell’informatica serve a definire come realizzare un programma e per meglio comprendere in che modo il programma assolve al suo scopo. L’uso di un formalismo si sposa con il vecchio trucco dell’informatica di risolvere i problemi introducendo un nuovo livello di astrazione (il quale a sua volta genera ulteriori problemi).
Il livello di astrazione più basso corrisponde all’utilizzo di un linguaggio di programmazione come strumento per impartire comandi al calcolatore. Si tratta di un linguaggio specialistico che ha molte analogie con il linguaggio comune, ma che è studiato per essere immune da tutte quelle ambiguità e doppi sensi di cui quest’ultimo è dotato e che ne costituiscono la ricchezza. Il linguaggio di programmazione viene utilizzato per fare in modo che il computer possa svolgere in modo del tutto controllato e prevedibile un determinato compito, come ad esempio aprire un cancello, tenere sotto controllo una centrale elettrica o pilotare un aereo. L’uso di un linguaggio in cui un ordine può essere interpretato con ambiguità in modi diversi, causando potenzialmente comportamenti imprevedibili, renderebbe la vita molto meno monotona agli utenti finali, ma forse un tantino più difficile.
Ogni linguaggio di programmazione, e ne esistono a decine, per dar vita ad un programma funzionante viene tradotto con varie modalità in linguaggio macchina, l’unico realmente compreso dal computer. Durante questa operazione quello che era un complesso insieme di idee descritto attraverso l’astrazione del linguaggio, si trova ricondotto a nulla più che una lunga sequenza di banali operazioni logico aritmetiche, e di spostamento di dati, nello stesso modo in cui un libro come “Moby Dick” si trova ricondotto al momento della sua stampa ad una semplice sequenza di lettere e di segni di interpunzione.
L’approccio riduzionistico al software, pur se formalmente corretto, non è certo in grado di restituire la ricchezza di intenti con cui è stato progettato il programma originale, se non al costo di impegno e fatica abissali. Tutti i programmi alla fine si riducono ad una ripetizione di sequenze di pochi tipi di istruzioni in linguaggio macchina, ma una sequenza di “move” o “jmp” ha poco a che vedere con la complessità dell’architettura dei programmi che da tali istruzioni sono costituiti come, ad esempio, un word processor. Dopo tutto quest’ultimo ha a che fare con concetti quali paragrafi, frasi, stili e capitoli. Risalendo nella scala delle astrazioni, una serie di sorgenti scritti in un linguaggio di programmazione non hanno l’espressività immediata di uno schema che descrive il funzionamento di un sistema. Partire a leggere un programma, direttamente dal codice macchina che pure lo costituisce e ne descrive il comportamento, è come esaminare con una lente d’ingrandimento un transatlantico centimetro per centimetro; possibile ma arduo.
Il substrato programmabile grazie al linguaggio macchina è il cuore di un sistema di calcolo, su di esso si costruiscono, mediante un’opera di astrazione, strati successivi di strutture per poter espandere la sua funzionalità. Ogni livello, nonostante sia collegato agli altri, vive di vita propria. Difficile immaginare che la teoria relazionale dei database, un sistema di telecomunicazioni ed un videogioco siano legati tutti dagli stessi codici di base, ma in effetti ciò che li differenzia è solo lo strato di astrazione o l’idea che li ha concepiti. Se si redigesse una statistica sulla base delle istruzioni effettive in linguaggio macchina che compongono tali programmi, probabilmente essi risulterebbero caratterizzati dalla stessa distribuzione.
Ciò che rende speciale l’informatica è il fatto che il calcolatore è uno strumento programmabile e non specializzato nell’eseguire un unico compito. L’hardware stesso di cui fisicamente è composto il calcolatore non esprime preferenze sul tipo di programmi che può far funzionare. Per la macchina un foglio elettronico od un browser internet sono la stessa cosa. Anche le informazioni sono memorizzate in modo da essere indipendenti dalla particolare locazione di memoria ove sono memorizzate e nulla garantisce che la volta successiva che un programma viene lanciato i suoi dati si trovino esattamente nelle stesse locazioni fisiche. La programmabilità della macchina permette l’elaborazione continua di nuovi concetti.
I formalismi sono uno strumento che, sfruttando questa possibilità di plasmare l’informazione, permette l’introduzione di successivi livelli di astrazione e ci permette di concentrarci sul modo migliore di risolvere un problema piuttosto che sui dettagli della modalità di soluzione problema stesso. La forma porta all’astrazione e quindi alla comprensione; per una delle solite strane contraddizioni di questo mondo capita di riuscire a risolvere un problema più facilmente quando ci si allontana da esso.
Nel caso che un livello di astrazione non ci soddisfi appieno, possiamo costruirne un altro sulle basi del precedente in modo da estenderlo e colmare eventuali lacune; cosa allora impedisce una ricorsione infinita? Nel mondo reale le risorse disponibili (tempo, programmatori e ovviamente denaro) sono limitate e quelle impiegate per curare il formalismo vengono sottratte alla soluzione concreta del problema, formando una naturale forza d’attrito che smorza il regresso all’infinito di Zenone.
In matematica, di cui l’informatica è figlia, si possono costruire diversi formalismi che estendendo quelli precedenti permettono di dimostrare proposizioni non decidibili nel formalismo precedente. Nell’informatica, più prosaicamente, attraverso l’uso del formalismo si cerca di aumentare la comprensione delle idee che stanno alla base dell’architettura di un programma. Tra i vari livelli di astrazione si instaura un feedback, dato che la modifica effettuata ad un livello del formalismo si propaga agli altri attraverso le modalità proprie di ogni livello, realizzando uno di quegli anelli di retroazione tanto cari a Hofstadter.
Purtroppo in informatica il formalismo si è spesso trasformato in un mito: l’idea che nella produzione di software basti seguire pedissequamente un formalismo di moda, Agile Programming, UML ecc…, per produrre un programma funzionante e affidabile indipendentemente dalla difficoltà del contenuto o dal suo contesto, è diventata una tentazione irresistibile, ed assomiglia al mito tutto italiano secondo il quale per risolvere un problema basta solamente emanare una legge.

http://it.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach_-_Un%27eterna_ghirlanda_brillante

http://it.wikipedia.org/wiki/Anelli_nell%27io

http://it.wikipedia.org/wiki/Macchina_di_Turing

http://it.wikipedia.org/wiki/Paradossi_di_Zenone

http://it.wikipedia.org/wiki/Entscheidungsproblem

http://it.wikipedia.org/wiki/Argomento_diagonale_di_Cantor

]]> http://lbell.wordpress.com/2009/02/09/in-perfetta-forma/feed/ 1 lbell http://lbell.wordpress.com/2009/01/19/movimentare-sorgenti-con-subversion/ http://lbell.wordpress.com/2009/01/19/movimentare-sorgenti-con-subversion/#comments Mon, 19 Jan 2009 21:39:31 +0000 lbell http://lbell.wordpress.com/?p=124 ]]>

Subversion è uno strumento utilissimo nel gestire i sorgenti di progetti anche complessi, con molti punti a favore (e qualche difettuccio).

Può succedere di avere la necessità di dividere un archivio che sta diventando troppo corposo, di dover promuovere un sottoprogetto ad avere una propria dignità, oppure semplicemente di dover cambiare il server.

E’ molto semplice farlo, prima di tutto esportando i dati contenuti nel repository originale mediante il comando svnadmin dump, tuttavia occorre avere serve l’accesso fisico al filesystem del server che ospita il repository.

svnadmin dump path_del_repository >file_risultato.dump

nelle opzioni del comando vi è la possibilità di esportare anche solamente un range di revisioni.

Per importare i dati nel nuovo repository, occorre posizionarsi nel filesystem del nuovo server e utilizzare svnadmin load

svnadmin load path_del_repository <file_risultato.dump

Se il repository non esiste già, occorre crearlo.

Nel caso occorra importare solo rami del sorgente esportato, prima del comando di load si può utilizzare svndumpfilter che agisce, come fa sospettare il nome, da filtro.

Pertanto se si desidera includere solamente la directory src ed il file NEWS del nostro ipotetico repository scriveremo:

svndumpfilter include /NEWS /src < esportazione.dump > dati_filtrati.dump

Attraverso l’opzione –parent-dir possiamo caricare i sorgenti in una data sottodirectory nel nuovo repository.

svnadmin load newrepository --parent-dir nome_directory <dati_filtrati.dump

I comandi hanno molte opzioni, ma la documentazione presente nel nel sito dedicato al libro on line http://svnbook.red-bean.com/ non solo è dettagliata ed esaustiva, ma discute anche del modo migliore di progettare ed usare un repository di Subversion.

]]> http://lbell.wordpress.com/2009/01/19/movimentare-sorgenti-con-subversion/feed/ 1 lbell http://lbell.wordpress.com/2008/09/09/a-chi-interessa-la-matematica/ http://lbell.wordpress.com/2008/09/09/a-chi-interessa-la-matematica/#comments Tue, 09 Sep 2008 21:05:14 +0000 lbell http://lbell.wordpress.com/?p=117 ]]>

Sabato scorso, sfruttando un colpo di fortuna e una favorevole congiunzione astrale, ho potuto assistere all’intervento di Odifreddi al Festivaletteratura di Mantova. Confrontando la quantità di persone che hanno assistito all’evento, posti a sedere esauriti, con la popolarità che la matematica gode nella scuola, qualche dubbio viene alla mente. Quasi tutti gli spettatori comunque sono certamente intervenuti per ascoltare Odifreddi più che per sentire argomentare di “MATEMATICA DELLA CONOSCENZA” come recitava il cartellone. Per inciso lo sponsor dell’evento è stato “il gioco del lotto”, una scelta piuttosto ironica, che sarebbe potuta diventare da solo tema per una conferenza sul calcolo delle probabilità. L’evento ha invece ha riguardato come al solito il rapporto tra matematica e letteratura, ormai tema fisso di quasi tutti i discorsi di Odifreddi, tirando in ballo come sempre il povero Perec. I problemi della matematica, è stato confessato, sono sempre e comunque di due tipi: descrizione e classificazione.

Approfittando dell’uscita dei volumi sulla storia della matematica curati da Odifreddi e Bartocci per Einaudi si è parlato anche di stili e pluralità di voci in matematica a proposito sia di singole persone che di diverse culture. I volumi a dire il vero sembrano molto interessanti, dedicati a grandi temi, molto voluminosi, come importante è il loro prezzo (a tre cifre in euro).

Odifreddi si ascolta sempre molto volentieri e si è arrivati all’ora dell’aperitivo senza grossi cali di attenzione, ma è anche vero che la minaccia di assegnare compiti in classe non è stata messa in pratica.

La causa principale della scomparsa di Netscape secondo Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000069.html) sarebbe imputabile alla decisione di riscrivere da zero il codice su cui si basava l’ex browser, decisione che lo ha praticamente fatto uscire dal mercato in favore del suo concorrente Internet Explorer e questo fatto costituisce una lezione di vita per i project manager.

In effetti l’articolo di Spolsky è pieno di buon senso e si può senz’altro condividere.

Tuttavia nel campo del software, come più ingenerale nella vita, le conseguenze di una azione assumono a distanza di tempo un significato diverso da quello che hanno avuto nel breve.

Quali reali alternative aveva Netscape davanti a se per rimanere leader del mercato, posizione che era riuscito a raggiungere? Praticamente nessuna, si trovava a competere di colpo con un prodotto gratis (ed è difficile competere con qualcosa che è gratis) e già installato su tutti i computer. L’utente non doveva nemmeno fare la fatica di scegliere quale browser installare, se tutto quello che stava cercando era un semplice accesso ad internet.

Netscape avrebbe dovuto inseguire ogni modifica proprietaria che MS avesse introdotto nel proprio programma appositamente per distinguerlo dalla concorrenza. Si tratta di una battaglia persa comunque in partenza, come ben sanno i produttori di qualsiasi programma da ufficio che si sia scontrato con prodotti MS da Word ad Excel.

Per avere qualche possibilità in una lotta con un colosso, occorre scrivere un prodotto che sia molto migliore della concorrenza, rinnovando totalmente la base di codice se necessario e le procedure per svilupparlo. Si tratta di un investimento a lunga scadenza che richiede uno sforzo gigantesco per chi non ha risorse praticamente infinite, ma è una scommessa fatta per vincere, non per crogiolarsi placidamente in un tramonto inevitabile e tranquillo, come invece scelse di fare la Venezia del 700. Il risultato? Firefox.

Ad onor del vero Firefox sembra effettivamente nato per caso dal caos di Netscape, ma non è questa la forza dei progetti Open Source?

Link:

http://www.joelonsoftware.com/articles/fog0000000069.html

http://en.wikipedia.org/wiki/Netscape

]]> http://lbell.wordpress.com/2008/09/01/joel-ha-quasi-sempre-ragione/feed/ 0 lbell