AlessioSaltarin WebLog

Lezioni di leadership da Flo Rida

noreply@blogger.com (Guildenstern70) — Fri, 21 Aug 2015 12:39:00 +0000

Nell'ultimo video del rapper nero Flo Rida, c'è una scena che secondo me insegna almeno quattro punti fondamentali nell'esercizio di una leadership vera.

Nel video, Flo Rida è seduto per strada con i suoi amici - il suo team, potremmo dire - e a un certo punto succede qualcosa di notevolmente straordinario.

Passa un ambulante di gelati (54") e Flo Rida si alza e offre il gelato ai suoi amici. Fin qui, niente di strano. E' il come lo fa, che è straordinario.

Ordina un gelato per ciascuno dei suoi amici, poi se lo fa dare di persona, poi lo porge, con cura, personalmente a ciascuno dei suoi: Ecco questo è per te, Alessio, Questo è il tuo, Daniela. Non è notevole? Avremmo fatto lo stesso?

In questo brevissimo passaggio, il rapper esercita la leadership in quattro importanti modi: il vero leader:

ti indica la via e ti spiana la strada
ti coinvolge personalmente e ti chiama per nome
si prende cura di te, assicurandosi che tu abbia tutto il necessario per proseguire
si spende in prima persona e ci mette la faccia

Nella mia carriera ho lavorato con tanti leader, veri o presunti tali, leader naturali o imposti dall'alto. Ho notato nei primi, sempre rispettati, i quattro punti di cui sopra.

Cercare in un file in Windows 8

noreply@blogger.com (Guildenstern70) — Thu, 28 Aug 2014 08:17:00 +0000

Vi sarà sicuramente capitato di ricercare i contenuti di un file in Windows 8... e di non trovarli mai! Fate il vostro bel "swype" come vi hanno insegnato, andate sulla lente di ingrandimento, mettete la parola da cercare e... mai che vi trovi il documento che contiene quella parola!

Avrete sicuramente mandato a quel paese gli ingegneri del software della Microsoft, e avrete pensato che quelli che dicono che Windows non funziona hanno ragione!

No, in realtà la ricerca indicizzata di Windows 8 (e 8.1 ovviamente) funziona molto bene, peccato che occorra personalizzarla - e questa è una delle prime cose che andrebbe fatte dopo aver installato il sistema operativo.

Per ovvi motivi, Windows appena installato indicizza solo alcune (poche!) cartelle, perché altrimenti le operazioni di indicizzazione sarebbero molto lunghe, e il file che contiene l'indice potrebbe diventare enorme.

Tuttavia, è molto semplice personalizzare le opzioni di ricerca e ottenere un'indicizzazione dei vostri contenuti, in modo da poterli trovare immediatamente.

Per prima cosa, swype (cioè passare il mouse sulla parte destra dello schermo), selezionare "Impostazioni" ("Settings") e poi "Pannello di Controllo" ("Control Panel").

In alto a sinistra nel box di ricerca scrivete, se avete Windows in inglese "index", altrimenti in italiano "indicizzazione". Verrete portati a questa schermata:

Attraverso questa schermata, premendo "Modify" ("Modifica"), è possibile selezionare le cartelle del PC i cui contenuti verranno indicizzati e saranno quindi disponibili per una ricerca veloce.

Unico consiglio: non esagerate! Immettete solamente le cartelle dove effettivamente archiviati i vostri documenti.

Se, come me, avete due dischi, e sul primo mettete solamente il sistema operativo, è buona norma cambiare la posizione del file di indice in modo che questo risieda sul vostro disco più capiente.

Per farlo andate su "Advanced" ("Impostazioni avanzate"):

Selezionate la cartella che conterrà i file di indice, e poi premete il tasto "Rebuild" ("Ricostruisci"). In questo modo, i vecchi file indice verranno cancellati, e quelli nuovi verranno salvati nella nuova posizione.

Infine, valutate se vi interessa che le ricerche fatte con lo swype includano o meno risultati dal Web. Per personalizzare quest'ultima opzione potete agire su: "Settings" ("Impostazioni"), "Change PC Settings" ("Cambia impostazioni"), "Search and Apps" ("Ricerca e App"), e poi mettete a "Off" (oppure "On") l'impostazione "Use Bing to search online" ("Usa Bing per cercare online").

Clonare un repository da GitHub

noreply@blogger.com (Guildenstern70) — Wed, 14 May 2014 17:12:00 +0000

Ecco una breve guida per effettuare il clone di un repository di codice sorgente da GitHub, modificarlo e poi sottomettere le modifiche. Il tutto direttamente da linea di comando. Com'è ovvio, occorre aver installato in locale git.

Per prima cosa occorre creare una directory e posizionarvisi sopra.

Quindi occorre effettuare il 'cloning':

git clone https://github.com/guildenstern70/cpp11learn.git
git status

Questa operazione crea un'esatta replica di tutti i file sul repository, non solo i sorgenti ma anche tutti i file ancillari, ad esempio la 'History'.

'git status' mi dà un feedback delle operazioni effettuate.

A questo punto posso cominciare a modificare i miei file. Quando ho finito il lavoro, occorre mettere in 'stage' le modifiche, che saranno così pronte per essere committate: lo si fa con il comando 'add':

git add <files...>
git status

Con il comando 'add' aggiungo i file che non erano presenti, oppure indico quali file esistenti sono stati modificati - esatto, è lo stesso comando per entrambe le operazioni.

Quando sono pronto per rendere operative le modifiche, effettuo il commit in locale:

git commit
git status

Ora occorre dare un nome al branch remoto, ad esempio: github. In questo modo posso indicare su quale repository lavorare, quello in locale, che normalmente è indicato come 'master' e quello in remoto, che qui chiamo 'github', ma che normalmente si indica come 'origin':

git remote add github https://github.com/[username]/[projectname].git
git remote -v

L'indirizzo https del repository si trova sul sito github del repository stesso.

Infine, per sincronizzare il repository locale con quello remoto, cioè in un certo senso per fare l'upload delle modifiche si dà il comando 'push':

git push -u github master

Viene chiesta la nostra username e password su GitHub, e dopo averle inserite, il gioco è fatto.

Di che tipo è una Funzione Lambda?

noreply@blogger.com (Guildenstern70) — Tue, 29 Apr 2014 12:37:00 +0000

Le funzioni lambda sono balzate agli onori delle cronache soprattutto perché l'ultima versione di Java le supporta direttamente, mentre sono molti altri i linguaggi che le integrano nella loro sintassi, ad esempio Ruby, Python e Scala.

Nel campo della programmazione una funzione lambda è una funzione anonima che può essere chiamata e passata direttamente, senza cioè essere nominata con un identificatore, come lo è una funzione normale, che ha un suo nome che rende possibile chiamarla nominalmente.

Ad esempio, in Scala, una funzione lambda ha questa sintassi:



val circleArea = (radius: Double) => 
                     { radius * radius * Math.PI }

in questo caso il nome "circleArea" non è il nome della funzione, ma è il nome dell'oggetto a cui si associa la funzione lambda. La differenza è sottile ma sostanziale: una funzione lambda può essere associata a molte diverse variabili con diverso nome, mentre una funzione normale ha uno e un solo nome.

Perché mai un programmatore dovrebbe usare funzioni senza nome? Il motivo principale risiede nell'immediatezza: sono parti di codice di facile scrittura, tipicamente formule matematiche, il cui uso è in porzioni di codice "vicine" a quello in cui vengono definite. Oppure ancora si tratta di shortcut, cioè di un modo veloce per passare mini-funzioni ad una super-funzione che le richiama all'interno di se stessa - il caso, nell'esempio sotto in Java8, della gestione degli eventi nei controlli:

// Lambda in Java 8
button.addActionListener( (e) -> {
        System.out.println("The button was clicked. From lambda expressions !");
});

C'è però una questione: quando passo una funzione anomima ad un'altra funzione, qual è il "tipo" con cui la identifico? In altre parole: se scrivo un metodo che prende come input una funzione lambda, come sarà la "firma" di quel metodo? Qual è insomma il tipo di una funzione lambda?

La questione è cruciale nei linguaggi fortemente tipizzati, dove è necessario identificare sempre il tipo di un oggetto per poterlo passare.

In Scala, che è un linguaggio fortemente tipizzato, la cosa viene risolta in modo elegante, cioè dando al tipo "funzione" una sintassi propria. Di seguito l'esempio di una High Order Function, cioè di una funzione che prende in input un'altra funzione:

function def highOrderFunction(func: Double => Double, v: Double ):String = {
        
        val result = func(v)
        result.toString();
        
}

Il primo parametro dice che deve essere passata una "funzione" che ritorna un numero decimale Double e prende in input un altro Double. Quindi, in Scala, la domanda non ha molto senso: il tipo di una funzione non è necessario specificarlo, perché il linguaggio ha una sintassi propria per definire un placeholder di funzione, che è il seguente:

(Input Parameters) => (Expression)

Però in altri linguaggi la questione si pone eccome. Ad esempio in C#. In questo linguaggio una funzione lambda viene definita come segue:

(double radius) => { radius * radius * Math.PI}

Ma se voglio "tradurre" la funzione Scala che abbiamo visto sopra (highOrderFunction) in C#, ho bisogno di sapere di che "tipo" è la funzione lambda.

Bene, in C# esistono due tipi (in realtà sono delegates) che rappresentano procedure e funzioni, sia che queste siano normali, e quindi nominali, sia che siano anonime, o lambda. Consideriamo di avere una procedura "VoidProcedure", che prende in input un intero, e una funzione "SimpleFunction" che prende in input un intero e ritorna un decimale:

static void VoidProcedure(int i)
{
    Console.WriteLine(i);
}

static double SimpleFunction(int i)
{
    return (double)i/2;
}

I tipi che le possono rappresentare sono:

Action
Func

Per cui si può scrivere un programma per invocarle indirettamente attraverso questi due nuovi tipi (delegati):

static void Main(string[] args)
{
    Action myAction = new Action(VoidProcedure);
    myAction.Invoke(123);           // Prints out "123"

    Func myFunc = new Func(SimpleFunction);
    Console.WriteLine(myFunc(5));   // Prints out "2.5"

    Console.ReadKey();
}

Ora, utilizzando al posto delle funzioni, le funzioni lambda, lo stesso programma diventa:

static void Main(string[] args)
{
    Action myAction = new Action(

        // Lambda procedure
        (i) => Console.WriteLine(i)

        );
    myAction.Invoke(123);           // Prints out "123"

    Func myFunc = new Func(
               
        // Lambda function
        (i) => (double)i/2
                
        );
    Console.WriteLine(myFunc(5));   // Prints out "2.5"

    Console.ReadKey();
}

In Java, i tipi lambda sono addirittura sei:

Predicate: una funzione che torna un booleano (normalmente per fare query)
Consumer: simile alla Action di cui sopra
Function: simile alla Func di cui sopra
Supplier: una funzione factory, che genera oggetti di tipo
UnaryOperator: funzione unaria che trasforma un oggetto
BinaryOperator: funzione binaria che trasforma due parametri in un valore di ritorno.

Cosicché il nostro esempio, in Java8, può scriversi come:

package lambdajava;

import java.util.function.Function;

public class LambdaJava {

    public static void main(String[] args) {

        byte[] ch = null;
        Function<Integer, Double> myFunc = i -> (double)i/2;
        System.out.println(myFunc.apply(5));
        
    }
      
}

Funzioni "First Class" e "Higher Order" nella Programmazione Funzionale

noreply@blogger.com (Guildenstern70) — Tue, 20 Aug 2013 09:19:00 +0000

In un recente post ho parlato della Programmazione Funzionale (FP) come di un paradigma di programmazione per computer che è sostanzialmente esente da side-effect, cioè a dirla in modo un po' brutale: è esente da comportamenti anomali a run-time.

In pratica, un programma scritto in FP pura si comporta come un foglio Excel. Si è mai visto un foglio Excel avere comportamenti anomali? Ci sono dei valori in input, ci sono delle formule e tutto quello che si ottiene sono dei valori di output che derivano dall'applicazione di quelle formule.

In modo simile, un programma FP è una funzione che prende come input una funzione - quindi, si potrebbe dire: una formula - e dà in output un certo risultato. A complicare le cose, c'è il fatto che una funzione FP solitamente prende in input una funzione che a sua volta prende in input una funzione e così via, fin quando ce ne sia bisogno per realizzare lo scopo del programma.

Per indicare questo tipo di comporamento, si dice che un generico linguaggio FP supporta le First Class Functions.

Una funzione, per essere "First Class", deve avere questa caratteristica: può essere passata ad un'altra funzione come qualsiasi altro valore.

Facciamo un esempio. (L'esempio in basso è scritto in linguaggio Scala, che è un linguaggio di programmazione che supporta molto bene il paradigma funzionale).

val areaDelCerchio = (raggio: Double) => { 
    raggio*raggio*Math.PI 
}
    
def printResult(result: Any) {
    println("L'area del cerchio e' : " + result.toString)
}
    
printResult( areaDelCerchio(10.0) )

La formula dell'area del cerchio viene memorizzata come valore (val). Questo basta per far sì che Scala possa dirsi un linguaggio dove le funzioni sono First Class, cioè vengono trattate come valori di prima classe, come lo sono solitamente gli interi o le stringhe. Significa che qualunque funzione può prendere come parametro un valore di prima classe: quindi, tipi elementari, oggetti e funzioni.

La funzione printResult è una funzione che si dice di ordine superiore, Higher Order Function, perché può prendere come parametro un qualsiasi valore e - anche! - una funzione.

Da un punto di vista di controllo dei tipi, la funzione/valore areaDelCerchio prende come parametro un Double (raggio, un valore decimale a doppia precisione) e ritorna un Double.

Qualsiasi oggetto in Scala - e quindi un Double, o una First Class Function - può essere convertito in Stringa. Ed ecco che printResult prende come parametro Any, cioè qualsiasi tipo o funzione, che possa essere rappresentato come stringa - che possegga il metodo .toString.

Poichè la funzione areaDelCerchio non mantiene variabili di stato e non accetta input dall'esterno che potrebbero modificarla, il suo comportamento è predicibile a priori ed esente da side-effect.

Una funzione Higher Order che prende come input tipi semplici o funzioni o funzioni di funzioni, ha un comportamento sempre predicibile e, una volta compilata, sarà esente da bug a run-time. Detto in altri termini: se un programma funzionale puro si compila - quindi non dà errori a compile-time - sarà esente da bug.

La capacità di esprimere un programma per computer, anche complesso, in termini di Higher Order Functions è dunque una garanzia che lo stesso, se si compila, avrà un comportamento predicibile e senza malfunzionamenti.

Se si pensa alle ingenti risorse che vengono impiegate normalmente in informatica per il test e il controllo della qualità del software, le implicazioni economiche di un simile approccio alla programmazione sono del tutto evidenti.

Programmazione asincrona in C# 5

noreply@blogger.com (Guildenstern70) — Thu, 07 Mar 2013 11:37:00 +0000

C# versione 5 rende l'utilizzo della programmazione asincrona piuttosto agevole attraverso l'utilizzo di un pattern molto semplice e di due keyword: async e await.

Utilizzare codice "asincrono" è una necessità non solo quando si vuole parallelizzare l'esecuzione di procedure, ma anche quando si vuole rendere la logica di business indipendente dal codice che gestisce e muove l'interfaccia grafica. L'idea è che nessuna operazione debba "stoppare" l'esecuzione del codice deputato a gestire l'input dell'utente o a fornirgli un feedback.

Tanto più urgente è questa necessità quanto più il device ha processori poco potenti: che è il caso tipico dei device mobile. Ad esempio, il framework di programmazione di Windows Phone, WinRT, si basa pesantemente sul concetto di programmazione asincrona, ed il suo uso è obbligatorio. Non è possibile, giusto per citare un caso, in WinRT, leggere un file in sincrono: è invece necessario predisporre il codice asincrono, in modo che mentre le operazioni di lettura del file sono in esecuzione, l'interfaccia e il resto del programma continuano a funzionare in parallelo.

La gestione della programmazione asincrona, benché semplice, è piuttosto controintuitiva. Su MSDN si legge che "l'operatore await dice al compilatore che il metodo marcato async non può continuare dopo quel punto fino a che il processo asincrono che si aspetta non è terminato". Cerchiamo di capire cosa significa con un esempio.

Supponiamo di avere una ipotetica funzione di business che ci impiega molto tempo per completare. Ad esempio questa, che su un portatile non troppo vecchio impiega qualche secondo:

static long LongRunningComputation(int i)
{
    Random cycleSeed = new Random();
    long result = 0; int rnd = 0;
    for (long j = 0; j < cycleSeed.Next() * 1E5 + 3E6; j++)
    {
        rnd = cycleSeed.Next(11);
        result += (rnd % 2 == 0) ? rnd : -rnd;
    }
    return result;
}

La prima cosa che occorre fare è incapsulare questa funzionalità in un metodo asincrono. Ogni metodo asincrono è tale se ritorna un oggetto Task. Un oggetto Task si costruisce con una Factory che si chiama Task.Run e prende in input una funzione lambda qualsiasi, con questa sintassi:

static async Task LongTaskAsync(int i)
{
    Task longOperation = 
            Task.Run(() > LongRunningComputation(i));

    return await longOperation;
}

La prima istruzione serve per costruire l'oggetto Task. Questo è un oggetto che mantiene lo stato e le informazioni sul processo asincrono che è in corso. Il fatto che la nostra operazione ritorni un intero viene riflesso nel fatto che Task è di fatto un contenitore generico (di un intero lungo).

La funzione lambda è in grado di "leggere" i parametri che sono in scope nel momento in cui è definita, quindi non c'è bisogno di specificare che intendiamo passargli l'intero "i" - questa cosa io ci ho messo francamente un po' per capirla... io avrei messo

((i) => LongRunningComputation(i))

però il parametro di Task.Run è un delegato che non accetta parametri!

La norma vuole che ogni funzione "asincrona" abbia un nome che termina in "Async" e non ci adeguiamo. La parola "await" significa che questo metodo deve aspettare il termine dell'operazione "LongRunningComputation" prima di tornare un valore che abbia senso! Infatti il codice LongRunningComputation viene lanciato in asincrono, e quindi la linea di codice successiva viene eseguita immediatamente.

Senza la programmazione asincrona, si potrebbe pensare di costruire una funzione che esegue due chiamate all'operazione lunga e somma i loro risultati, così:

static long GoInLineNormally()
{
    Console.WriteLine("Going in sequence, normally");
    long x1 = LongRunningComputation(11);
    Console.WriteLine("X1 (NORMAL) = " + x1);
    long x2 = LongRunningComputation(22);
    Console.WriteLine("X2 (NORMAL) = " + x2);
    return (x1 + x2);
}

Siccome abbiamo detto che l'operazione lunga ci mette grossomodo due secondi, la procedura di cui sopra ci metterebbe circa quattro secondi per essere eseguita.

Ma abbiamo la programmazione asincrona, e quindi è lecito pensare che le due possano essere lanciate sue due thread differenti, e quando ciascun thread esce con un risultato, sommarli e stamparli a video.

static async Task GoInParallelAsync()
{
    Console.WriteLine("Going in parallel");

    var t1 = LongTaskAsync(11);
    var t2 = LongTaskAsync(22);

    await Task.WhenAll(t1, t2);

    Console.WriteLine("X1 (PARALLEL) = " + t1.Result);
    Console.WriteLine("X2 (PARALLEL) = " + t2.Result);
    return (t1.Result + t2.Result);
}

Per farlo abbiamo lanciato LongTaskAsync e poi, attraverso la funzione Task.WhenAll, abbiamo "aspettato" che entrambi finissero per raccogliere i risultati. L'esecuzione totale, come ci aspettavamo è di circa due secondi invece che quattro.

Ricapitolando. Se un metodo asincrono viene lanciato con l'operatore "await", l'esecuzione si ferma finché il metodo non ha ritornato un risultato - ma questo metodo viene comunque lanciato su un thread differente rispetto al programma che lo ha lanciato, il quale può ad esempio continuare così ad aggiornare l'interfaccia grafica e a rimanere in ascolto di eventuali eventi. Se invece un metodo asincrono viene lanciato senza l'operatore await, la linea successiva di codice viene eseguita immediatamente, e il controllo sull'esecuzione del task asincrono è demandato ai metodi della classe Task.

Infatti, se lanciamo con:

static async Task GoInLineAsync()
{
    Console.WriteLine("Going in sequence, but async");
    long x1 = await LongTaskAsync(11);
    Console.WriteLine("X1 (SEQUENCE) = " + x1);
    long x2 = await LongTaskAsync(22);
    Console.WriteLine("X2 (SEQUENCE) = " + x2);
    return (x1 + x2);
}

il codice esegue prima LongTaskAsync(11) e solamente dopo aver ottenuto il risultato (ciò che è espresso dall'operatore await), lancia il LongTaskAsync(22).

Questo codice, benché funzionalmente identico a GoInLineNormally è molto diverso dal punto di vista del comportamento! Il primo infatti è rigorosamente sincrono: ogni linea di codice viene eseguita solo e soltanto se quella precendente è terminata. Il secondo, invece, attraverso l'operatore "await" dice al compilatore: adesso esegui in asincrono su un thread differente LongTaskAsync, e aspetta che il metodo asincrono sia terminato prima di proseguire con la prossima linea di codice.

E' da notare in particolare il codice entry point, Main, che richiama le procedure scritte sopra:

static void Main(string[] args)
{
    Console.WriteLine("AYNC/AWAIT TEST v.1.0");
    Console.WriteLine();

    //long r = GoInLineNormally();
    var t = GoInLineAsync();
    //var t = GoInParallelAsync();

    Console.WriteLine("END TEST (Is it really ended?)");
    Console.WriteLine("Result = " + t.Result);
    Console.WriteLine();
    Console.ReadKey();

}

Domanda: quando viene stampata la linea "END TEST"?

Alla fine dell'esecuzione dei vari metodi GoIn...? La risposta è sì, se si tratta di GoInLineNormally(), ma è no in entrambi gli altri casi: si tratta di metodi asincroni che ritornano subito (non c'è await)! Quindi "END TEST" non è proprio un messaggio di End, perché viene stampato immediatamente, mentre i metodi asincroni sono in esecuzione. Viceversa, "Result =" viene stampato effettivamente alla fine dei calcoli, perché il valore di t è "awaited" da t.Result.

E se avessimo voluto "aspettare" l'esecuzione GoInLineAsync() prima di scrivere "END"? Non avremmo potuto farlo! Infatti un metodo che contiene una chiamata "await" deve per forza essere marcato "async". Ma il metodo Main non può essere "async"! Quindi non abbiamo potuto scrivere, per esempio:

var t = await GoInLineAsync()

Se avessimo marcato il metodo Main come "async", avremmo detto al compilatore che quel metodo va eseguito in asincrono e che deve ritornare immediatamente al chiamante, per poi "rientrare" quando il metodo sia terminato: due cose che un programma a console, evidentemente, non può fare.

First Class Functions in Scala

noreply@blogger.com (Guildenstern70) — Thu, 28 Feb 2013 16:47:00 +0000

A volte è necessario passare come argomenti dei metodi o delle funzioni non un parametro normale come un intero o una stringa, ma un'altra funzione. Ad esempio vorremmo scrivere un metodo che applica una somma o una moltiplicazione di due numeri, e vogliamo passargli come argomento la funzione "somma" o la funzione "moltiplicazione".

Un esempio meno banale: vorremmo scrivere una funzione di sorting che prende in input la collezione di oggetti da ordinare e l'algoritmo di sort. Questa funzione avrebbe quindi due parametri: la collezione e una funzione con l'implementazione dello specifico algoritmo.

Dunque vorremmo costruire una procedura che esegue una determinata operazione sui suoi parametri, e vorremmo passare come parametro l'operazione stessa, in modo da rendere la procedura del tutto generica, e perciò anche riutilizzabile.

Normalmente, nella programmazione orientata agli oggetti, questo si ottiene con un pattern che si chiama "Functor". Il Functor è un'interfaccia che espone un metodo che includerà la nostra funzione. Sta poi alla particolare implementazione dell'interfaccia stabilire se quella funzione è, ad esempio, una moltiplicazione o una somma.

Posto che in Scala le interfacce non esistono, ma esistono i "trait", di cui ho parlato in un altro post, si potrebbe pensare di scrivere due classi, Somma e Moltiplicazione, così fatte:

trait Functor {
  def function(x: Int, y: Int) : Int
}

class Somma extends Functor {
  def function(x: Int, y: Int) : Int = (x+y)
}

class Moltiplicazione extends Functor {
  def function(x: Int, y: Int) : Int = (x*y)
}

Cosa sono le "first class functions"? Sono una particolarità del linguaggio che ci permette di passare, come argomento di una funzione o di un metodo di classe, una funzione; esattamente quello che otteniamo con il pattern "Functor".

In questo caso però, noi non passiamo un oggetto che ha come metodo una specifica funzione: noi passiamo direttamente la funzione!

Questa è la sintassi da usare:

object FirstClassFunctions {
  val somma = (x: Int, y: Int) => (x+y)
  val moltiplicazione = (x: Int, y: Int) => (x*y)
}

La variabile "somma" non è né un tipo primitivo (intero o stringa, ad esempio), nè un oggetto. E' una funzione. La prima parte dice quali sono i tipi che la funzione manipola, e la seconda parte è la funzione vera e propria. Somma è una funzione che somma il valore x al valore y. Similmente per moltiplicazione.

object Main {

  // Functor
  val functSomma : Functor = new Somma()
  val functMoltiplicazione : Functor = new Moltiplicazione()

  def testFunctor(f:Functor, x:Int, y:Int) {
    println("Il risultato e' = " + f.function(x,y))
  }

  // First Class
  def testFirstClass(f: (Int,Int) => Int, x:Int, y:Int)  {
    println("Il risultato e' = %d".format(f(x,y)))
  }


  // Main
  def main(args: Array[String]) {

    testFunctor(functSomma, 6, 5)
    testFunctor(functMoltiplicazione, 6, 5)

    testFirstClass(FirstClassFunctions.somma, 6, 5)
    testFirstClass(FirstClassFunctions.moltiplicazione, 6, 5)

  }

}

Il codice di sopra richiama le funzioni sia sotto forma di Functor, che sotto forma di First Class Functions.
Com'è ovvio, la possibilità di passare direttamente funzioni come parametri di metodi, piuttosto che inventare una tassonomia apposita di classi, riduce la complessità del codice, aumenta la leggibilità e quindi in definitiva migliora la qualità del codice sorgente.

Aiuto mi sono scomparsi i favoriti!

noreply@blogger.com (Guildenstern70) — Fri, 08 Feb 2013 16:26:00 +0000

E' possibile che dal menù di apertura o salvataggio dei file in Windows 8 scompaia la selezione delle locazioni preferite, in inglese "Favourites", nella barra a sinistra, altrimenti detta "Places Bar"

Tra queste locazioni ci sono normalmente il Desktop, i Download e i Recent Places, in più lo shortcut è facilmente personalizzabile facendo drag'n'drop del folder che vogliamo aggiungere.

Pochi però sanno che è possibile eliminare i Favourites, anche inavvertitamente, spuntando l'opzione "Mostra Preferiti" della Places Bar.

Per ripristinarli, basta spostarsi in basso nella Places Bar e selezionare "Mostra Preferiti" (Show Favourites).

Sviluppare codice migliore con la programmazione funzionale

noreply@blogger.com (Guildenstern70) — Fri, 28 Dec 2012 13:39:00 +0000

Minimizzare gli impatti del cambiamento dovrebbe essere uno degli obiettivi prioritari nella produzione del software, soprattutto se in contesti di medio-alta complessità. Normalmente, infatti, si assiste al fenomeno dell'ingessatura del codice: nessuno si azzarda a introdurre cambiamenti migliorativi perché questo potrebbe portare a conseguenze inaspettate, potenzialmente drammatiche.

Per minimizzare gli impatti del cambiamento esistono strumenti e tecniche diverse: ad esempio il test driven development, oppure il defensive programming. Un altro metodo è quello di scrivere codice secondo il paradigma della programmazione funzionale (FP = Functional Programming).

Un programma scritto in un linguaggio FP puro è normalmente esente da "side-effect": cioè è un software che si comporta in un solo modo, predicibile, e che ha un comportamento identico una volta compilato. Questo perché si traduce sostanzialmente in una funzione che prende in input una qualunque serie di funzioni che agiscono su costanti. E' come un meccanismo di ruote e pulegge: una volta in movimento, si comporta sempre nello stesso identico modo.

Purtroppo solo una piccolissima parte di programmi può essere scritta in FP pura. Questo perché un programma per essere utile deve poter prevedere: 1) input dall'esterno e 2) mantenimento di uno stato. Queste però sono due cose che sono "inesprimibili" in FP puro.

Quello che possiamo fare è invece utilizzare un linguaggio ibrido, che permetta cioè sia la programmazione imperativa (magari ad oggetti) cui siamo abituati, sia la programmazione funzionale, cercando di minimizzare e confinare la parte imperativa in un punto noto - e ridotto - del codice sorgente. Eccellenti esempi di linguaggi ibridi sono oggi Scala e C#.

In Scala, le variabili vengono nominate in due modi diversi: var, la variabile "normale" cui siamo abituati, e val, una variabile che, una volta che abbia assegnato un valore, non lo modificherà mai per tutta la sua vita. (In C# le variabili val di Scala sono scritte come readonly) Un programma scritto in Scala che abbia molte var, è un programma che segue la logica imperativa, che crea oggetti che mantengono uno stato e che quindi è potenzialmente pieno di side-effects. Viceversa, un programma che abbia pochissime o nessuna var, e val al loro posto, è un programma scritto in logica funzionale, e che avrà pochi o nessun side-effect. Questo secondo tipo di programma è molto più facile da mantenere, dovrà essere testato di meno, e quindi avrà maggiore valore.

Come si possono scrivere normali costrutti in logica funzionale? E' difficile, perché il nostro cervello è abituato a pensare in termini di "oggetti" e di "stato", e molto poco in termini di "funzioni" e "funzioni di funzioni". Però con un po' di pratica l'obiettivo può essere centrato.

Vediamo un esempio. Supponiamo di voler scrivere una classe che prende in input una stringa e ne calcola il suo valore ASCII (il valore ASCII di una stringa è la somma dei suoi caratteri intesi secondo la codifica ASCII).

class TestClass(givenString: String) {

    require(givenString != null)

    private var gStr: String = givenString

    def getValue() = {

        this.compute()

    }

    private def compute(): Int = {

        var tempSum: Int = 0
        for(charV <- this.gStr.toCharArray()){

            tempSum += charV.toInt

        }

        tempSum

    }

}

Questo programma in Scala contiene due var: una per mantenere lo "stato", che è la variabile che contiene la stringa da trasformare in numero, e una per mantenere il numero associato alla stringa mentre viene calcolato, all'interno di un ciclo for.

Come trasformare questa classe in logica funzionale?

Dobbiamo come prima cosa far sparire lo "stato" dalla classe. La nostra classe deve comportarsi come una "funzione" e quindi non deve mantenere in memoria parametri che possono cambiare valore nel tempo. Farlo è molto semplice: invece che memorizzare givenString come variabile (var) lo memorizzeremo come costante (val). Oppure, potremmo non memorizzarlo del tutto e passarlo così com'è al metodo di calcolo compute().

Più difficile è invece sostituire il costrutto for che calcola il valore. Qui useremo invece una formula classica della FP. Creeremo un metodo che ritorna una collezione, cioè un array dinamico, di valori ASCII, ognuno per ciascun carattere che forma la stringa. Poi su questa collezione applicheremo una funzione di trasformazione: nel nostro caso "sum". Ogni collezione fornisce metodi operatore sui valori che la compongono, e in più può accettarne di nuovi appositamente scritti.

Ecco il nostro codice trasformato in logica funzionale:

class ImmutableTestClass(givenString: String) {

    require(givenString != null)

    private val gStr: String = givenString

    def getValue() = {

        this.compute(this.gStr)

    }

    private def listOfValues(valStr: String) = {
        for(j <- 0 until valStr.length())yield{

            valStr.charAt(j).toInt

        }

    }

    // 1. Convert the sequence to actual collection

    // 2. Add "mapping" to collection, example: .sum, .mkString

    private def compute(valStr: String): Int = {

        val listOfVals: List[Int] = this.listOfValues(valStr).toList

        listOfVals.sum

    }

}

Abbiamo buttato via le var e le abbiamo sostituite con val. Il codice è ora puramente funzionale. (E, tra parentesi, funzionerà molto meglio in contesti multi-threading).

Naturalmente lo stesso risultato si può ottenere con C#:

class Immutable

{

    private readonly String tString;

    public Immutable(String testString)

    {

        this.tString = testString;

    }

    public int GetSum()

    {

        return this.CharList().Sum();

    }

    private IEnumerable<int> CharList()

    {

        foreach (char ch in this.tString)

        {

            yield return (int)ch;

        }

    }

}

Masterizzare e montare una ISO su Windows 8

noreply@blogger.com (Guildenstern70) — Sat, 22 Dec 2012 10:04:00 +0000

Windows 8 supporta nativamente il formato ISO, cosicché è possibile sia montare un'immagine ISO come drive virtuale, sia masterizzarla su CD/DVD/BluRay.

ATTENZIONE: se si è installato un software che gestisce i file .ISO (ad esempio WinZip o Demon Tools), le opzioni per la gestione dei file ISO non sono più visibili da menù contestuale. Occorre modificare le impostazioni dei software di cui sopra, per togliere l'associazione con i file .ISO.

PER MONTARE UN FILE .ISO

Clickare con il tasto destro del mouse sul file .ISO e selezionare "Monta". Il nuovo drive apparirà tra le risorse del computer.

PER MASTERIZZARE UN FILE .ISO

Per prima cosa inserire un disco CD/DVD/BluRay vuoto nel masterizzatore. Quindi clickare con il tasto destro del mouse sul file .ISO e selezionare "Masterizza immagine disco". Il disco verrà masterizzato con i contenuti del file immagine .ISO

Creare un'app per Google Chrome

noreply@blogger.com (Guildenstern70) — Mon, 22 Oct 2012 13:20:00 +0000

Piuttosto sorprendentemente, non esiste in tutto il Chrome Web Store, un'app che aggiunga al browser di Google, la ricerca delle immagini attraverso il motore Google stesso.

Detto fatto, ne facciamo una noi. Con un solo, piuttosto importante limite: non potremo distribuirla sullo Store, poiché il sito in questione appartiene a Google.

La nostra "app" apparirà nella "Nuova Scheda" di default del browser, e assomiglierà all'icona col cerchio intorno:

Un "app" per Chrome è nel nostro caso - cioè se vogliamo tipicamente rendere un link - molto semplicemente l'unione di un file manifesto e di un'icona.

L'icona la potete scegliere liberamente tra le molte disponibili su Internet. Io ho scelto questa. Scaricatela come PNG e salvatela col nome di icon.png.

Create una cartella sul Desktop e nominatela "ImageSearch".

Adesso, occorre aprire un editor - a me ultimamente piace molto Sublime Text, ma il Notepad o Vim può andare lo stesso, e copiare il seguente testo.

{

"name": "ImageSearch",
"version": "1.1",
"manifest_version": 2,
"description": "Google Images",

"icons": 
{
"128": "icon.png"
},


"app": 
{
"urls": ["http://www.google.net/"],
"launch": 
{
"web_url": "http://www.google.it/imghp?hl=it&tab=wi"
}
},

"permissions": [ "http://www.google.it" ]

}

Infine, salvate il testo di cui sopra come "manifest.json". (Notate che nella sezione "urls" ho messo un indirizzo falso. Questo serve se voleste pubblicare la app su un sito di vostra appartenenza).

Per usare l'app, basta aprire il Menù di Chrome (il tasto a destra a fianco della URL) e scegliere Strumenti/Estensioni.

Dopo aver spuntato l'opzione "Modalità Sviluppatore", si clicka su "Crea Pacchetto Estensione". A questo punto basta dare in input la directory che contiene il file json e l'icona, e il gioco è fatto.

Come ti rimpiazzo iGoogle

noreply@blogger.com (Guildenstern70) — Fri, 31 Aug 2012 10:25:00 +0000

iGoogle è stato la mia home page per quasi dieci anni. Mi ci trovavo molto bene. Era veloce, gradevole da vedere, aveva la toolbar di search di Google (fondamentale) e insomma tutto quello che secondo me la home page deve avere.

Dopo anni di ottimizzazioni varie, ci avevo messo dentro tutte le cose che volevo vedere dal Web appena collegato. Per esempio ci avevo messo:

News feed dei principali giornali italiani (Corriere, Repubblica, Sole 24 Ore)
Feed dei principali siti di gaming (Kotaku, Gamespot...)
Feed dei principali siti di programming (MSDN, StackOverflow, CodeProject...)
Un traduttore online (il migliore: Google Translate)
Il meteo di Milano e dintorni
Una lista dei miei cinque link web preferiti
I blog miei e dei miei amici
Ultimi tweet che seguo

Cosa invece volutamente non ci avevo messo:

News feed sportive (terribili se per caso ho un evento "in registrazione")
Mail (troppo disturbo: meglio andarci di proposito)
Facebook (come sopra)

Poi improvvisamente una tragica notizia: iGoogle chiude! Pare che sarà a Novembre (2013, v.commenti), comunque è irrevocabile, han detto quelli di Google che chiude.

Così ho cominciato a guardarmi intorno per rimpiazzarlo, e ogni prova che facevo mi convinceva che iGoogle era meglio. Ad esempio ho provato:

Netvibes (bello, ma lentissimo)
MyFav.es (ok, ma mancano i feed)
Protopage (bruttissimo)
uStart (ha chiuso!)

Nessuno mi soddisfaceva. Allora ho cominciato a riflettere: ma insomma, cos'ha iGoogle di così speciale? O meglio, cosa deve avere una Home Page per essere una buona Home Page?

Fondamentalmente deve avere 3 cose:

Una toolbar di search (quella di Google va benissimo)
Link ai siti utili (Translate / Calendar / Mail...)
News dal mondo

Poi mi sono reso conto di una cosa: i primi due punti sono implementati direttamente dalla quasi totalità dei browser moderni. Ad esempio in Chrome la toolbar che mostra la URL di un sito, è anche una toolbar di ricerca in Google. Sempre in Chrome, la Home Page di default è una collezione di icone (apps) che portano ai siti di maggior interesse: ad esempio la mia è così:

Le "news dal mondo" sono sostanzialmente dei feed RSS. Quindi mi rimaneva solo da scegliere un buon "news reader", cioè un programma che mi mostrasse i feed RSS nel modo giusto, cioè che mi permettesse di categorizzarli (news, gaming, programming, blog...) e visualizzarli in modo piacevole.

Ne ho provati un po'. Google Reader è un po' troppo spartano, altri erano troppo "barocchi" o mancavano di funzionalità. Alla fine ho scelto Feedly e lo trovo perfetto (un po' ostica l'interfaccia utente, ma dopo qualche tentativo si riesce a fare quello che si vuole). Ecco la mia page di News:

In definitiva così ho rimpiazzato iGoogle: il browser Chrome mi toglie la necessità di partire da un sito di ricerca come Google. Come Home Page (e New Tab) ho la pagina di apps di Chrome che mi porta alla mail, a Facebook, a quant'altro mi interessa; infine per leggere le news clicko su Feedly, anch'esso disponibile come "app" di Chrome.

Convenzione invece che Configurazione

noreply@blogger.com (Guildenstern70) — Fri, 24 Aug 2012 11:51:00 +0000

Una delle rivoluzioni silenziose più importanti degli ultimi anni in informatica è l'avvento di strumenti, linguaggi e sistemi che sposano il concetto di

Convention over Configuration (CoC)

ovvero, in italiano, potremmo dire: seguire una convenzione piuttosto che configurare.

I più eclatanti risultati di questa impostazione - ovviamente solo tra quelli che ho potuto provare - sono, ad esempio:

Maven
Un tool di management dei sorgenti, che effettua l'organizzazione e la compilazione del codice e della documentazione di un progetto software
Ruby On Rails
Un famoso framework per scrivere applicazioni Web data-intensive.
SBT
Un tool per la compilazione di codice sorgente in Scala (e non solo...)

Che cos'hanno di speciale questi oggetti software che implementano la CoC? Be' è presto detto: funzionano "da soli" come per magìa, senza bisogno di:

parametri a linea di comando
file di configurazione

Li scarichi, li lanci, e funzionano. Così, senza far niente, magicamente appunto! Chiaramente, dopo una prima fase in cui il tool si comporta in default, è sempre possibile arricchire e dettagliare in modo che esso faccia esattamente ciò di cui si ha bisogno.

Faccio un esempio. Comincio a scrivere il mio codice in Scala, un progettino, niente di che, ma comunque un bel po' di file sorgenti e documentazione. Ho bisogno di compilare, e scelgo un tool CoC come SBT. Lo scarico e lo lancio, così, nudo, senza alcun parametro!

> sbt

Come prima cosa, SBT si rende conto che gli mancano delle librerie per partire. Ok, le scarica tutte dalla rete e le installa.
Poi vede che non ho l'ultima versione di Scala: me la scarica e la mette "a fianco" alla versione che uso io.
Si accorge che l'ho lanciato in una directory che contiene codice Scala: fa il parsing dei sorgenti e individua il file che contiene il metodo principale (Main)
Compila tutti i miei file
Trova le dipendenze (Scala e Java), le compila e le mette in una directory di libreria
Esegue il mio programma compilato!

Fantastico, no?

Cos'ho fatto io per permettere a SBT di funzionare così bene? Nient'altro che seguire delle "convenzioni": ad esempio, ovviamente, i miei file in Scala hanno estensione .scala, ma non molto più di questo.

Allo stesso modo, se scarico Ruby On Rails e ho il database Pippo, mi basta lanciare:

> rails pippo

perché "lui" mi sondi il database e mi costruisca un sito Web completo con tutte le funzioni di front-end per gestire il DB Pippo.

In maniera analoga, Maven, è in grado di scandagliare un progetto in Java, identificare le dipendenze, scaricarle da Internet, aggiornare il sistema e infine compilare e lanciare il progetto. Basta ovviamente che io segua delle "convenzioni" (ad esempio, le librerie sono in una directory /lib).

Questo è il futuro dei tool per lo sviluppo software, e sempre maggiormente la comunità di sviluppatori si aspetterà di avere a che fare con sistemi CoC che funzionano bene out-of-the-box, senza dover leggere quintali di documentazione o seguire passo passo noiosissimi esempi.

Non molto Agili... fin qui!

noreply@blogger.com (Guildenstern70) — Mon, 30 Jul 2012 14:38:00 +0000

Navigando sul sito http://agilemanifesto.org mi sono accorto che sono passati otto anni da quando firmai il manifesto sullo sviluppo agile.

Cos'è successo in questi otto anni? Si fa un gran parlare, è vero, delle tecniche di sviluppo agili e termini come Scrum ed eXtreme Programming sono molto di moda, ma di fatto nella realtà enterprise - specie in quella italiana - continuano a non vedersi progetti sviluppati secondo la filosofia Agile dello sviluppo del software. Viceversa, nel mondo Open Source, l'Agile è di fatto la norma.

Spesso si vedono applicate le tecniche agili, come ad esempio Pair programming o Feature Driven Programming, ma in contesti che sono quelli tradizionali, e cioè quelli dello sviluppo waterfall, che nella realtà enterprise è tuttora l'unico modello supportato.

Frequentemente ho proposto di utilizzare un approccio Agile in diversi progetti reali, ma al di là di un qualche superficiale apprezzamento non si è mai andati.

Perché dunque, nonostante l'entusiasmo, specie degli addetti ai lavori, la metodologia Agile non ha preso piede? Io credo che le cause siano principalmente tre.

1. Il sistema non recepisce processi iterativi

Quello che caratterizza principalmente l'approccio Agile rispetto al Waterfall è il suo essere iterativo by design. Il progettista Agile sa che lo sviluppo software è spesso un processo "prima volta-primo uso", caratterizzato da un altissimo grado di incertezza, per affrontare il quale deve applicarsi una metodologia di gestione del rischio che non può che essere iterativa. L'iterazione tipica dell'Agile è quella indicata in figura:

Normalmente, in un progetto complesso, le iterazioni possono essere decine. Ma il "sistema" non è in grado di gestire le iterazioni! Se da una parte il Cliente vuole subito sapere quanto costerà il suo nuovo sistema informativo e quanto durerà il suo sviluppo, anche dall'altra il Fornitore ha tutta una serie di strumenti che funzionano solo se vengono immessi valori "a preventivo": quante risorse il progetto occuperà e per quanto tempo. Come ho riportato in altri post, la stima del costo (tempo, denaro e altre risorse) di un progetto "prima volta-primo uso" è un esercizio di fantasia destinato al fallimento. Tipicamente perciò chi fornisce un servizio di sviluppo software applica dei coefficienti di rischio molto alti proprio per cercare di assorbire questa incognita. Di fatto, nei sistemi dove è "necessaria" una stima dei costi a preventivo, il metodo Agile è escluso a priori.

2. Un processo che ricicla è considerato un processo di "serie B"

Nella concezione del Project Management classico, il "riciclo" - quindi la re-iterazione - è considerato come un "difetto", o meglio come la "conseguenza di un difetto". Il progetto perfetto non presenta ricicli: viene eseguito così com'era stato pensato la prima volta. Per chi non possiede una cultura informatica (direi, una cultura informatica recente) l'idea stessa che una metodologia preveda molti ricicli è semplicemente orrenda. E' orrendo dover immaginare di avere stime riviste, nuove implementazioni e nuovi test ad ogni riciclo. Impensabile immettere ad ogni nuova iterazione nuove funzioni e quindi nuovi bug! Il Cliente percepisce il metodo Agile come una mancanza di professionalità (non sviluppano: provano a sviluppare!) e lo staff non tecnico del Fornitore la percepisce come una intollerabile mancanza di certezze: quanto ci costerà il progetto, quante risorse impiegherà e per quanto tempo.

Bisogna però fare i conti con la dura realtà: che è tanto più vera e documentata quanto più i progetti aumentano in complessità e novità: all'inizio nessuno può sapere quanto costerà il progetto, nemmeno a grandi linee. Si possono fare delle stime, sulle quali però non può essere calcolato il prezzo al Cliente. Proprio per la grande aleatorietà di queste stime "a-priori", il prezzo sarà o largamente esagerato per assorbire il rischio, o sottostimato destinato cioè ad andare in perdita. Come dicevo, i sistemi (finanziari, di controllo e gestione e via dicendo) aziendali prevedono che questo prezzo venga calcolato all'inizio, sulla base del quale verranno poi derivati tutti i driver economici dell'azienda. Un calcolo basato, il più delle volte, sulla fantasia.

3. La metodologia Agile presuppone il Time&Materials

Esistono tipicamente due modi per vendere un servizio informatico: a pacchetto (turn-key o fixed bid) o a tempo (time&materials, T&M). Nel primo, chi offre "scommette" su quanto effettivamente gli costerà il servizio: applica alla scommessa il proprio coefficiente di profitto e ottiene il prezzo. Nel secondo, semplicemente vengono erogati dei servizi e il Cliente paga "il tempo" di erogazione.
Per quanto abbiamo detto sin qui, la metodologia Agile presuppone la seconda opzione. Perché per poter vendere qualcosa turn-key occorre essere confidenti sulla stima dei costi, cosa che abbiamo visto è molto difficile nel caso di progetti complessi. E perchè l'Agile è iterativo di suo.
Il committente di un progetto informatico complesso è molto poco propenso a iniziare a lavorare T&M, perché anche lui deve fornire una stima di quali saranno i suoi costi/tempi, e questo a priori! La naturale conseguenza di questo stato di cose è che si formulerà un'offerta turn-key molto sovrastimata nei costi, ed esageratamente lunga nei tempi.

Io credo che queste tre siano le cause principali che hanno bloccato l'introduzione dei modelli Agili nella pratica dello sviluppo software a livello enterprise. Sono convinto che un approccio iterativo e T&M possa permettere significative economie sia per chi vende, sia per chi compra soluzioni software. Tuttavia, perché lo sviluppo Agile possa essere effettivamente utilizzato, occorrono notevoli cambiamenti in termini di cultura, processi e strumenti di supporto aziendali.

Ajax + Prototype + CoffeeScript

noreply@blogger.com (Guildenstern70) — Fri, 13 Jul 2012 09:51:00 +0000

In rete abbondano gli esempi CoffeeScript per chiamate Ajax con la libreria jQuery. Se uno - come me - preferisce Prototype, è abbandonato al proprio destino.

Perciò pubblico qui sotto l'esempio di una pagina CoffeeScript con chiamate Ajax in Prototype.

//= require prototype

pe = null

invitations_args =
  method: 'get'
  onSuccess: (transport) ->
    inviter = transport.responseText
    if inviter.length > 1
      $('invitation').show()
      $('proposal').update
             (inviter + ' invites you to join a game:')
      pe.stop()
      return
  onFailure: ->
    $('invitation').show() 
    $('proposal').update('Error retrieving invitation')
    return

invitations = ->
  new Ajax.Request 
      '/player/lookforinvitations', invitations_args
  
main_loop = ->
  pe = new PeriodicalExecuter( invitations, 3 )

Event.observe(window, 'load', main_loop)

La parte principale (main_loop) è invocata sull' onLoad della pagina HTML. Qui, un PeriodicalExecuter esegue una chiamata Ajax ogni tre secondi ad un metodo (/player/lookforinvitations) che cerca se sul database qualcuno ci ha invitato a giocare. Se sì la pagina mostra un messaggio: ad esempio: Pippo ti invita a giocare con lui, e ferma il processo PeriodicalExecuter. Altrimenti la pagina continua ad inviare richieste Ajax al server finchè l'utente non cambia pagina.

(Una cosa interessante e che mi ha fatto perdere molto tempo è che anche in CoffeeScript l'ordine in cui vengono definite le funzioni è importante!! Se mettete ad esempio Event.Observe all'inizio del file, otterrete un errore di oggetto undefined: l'oggetto in questione è main_loop, che viene definito solamente più sotto!)

CoffeeScript e le var locali

noreply@blogger.com (Guildenstern70) — Wed, 11 Jul 2012 10:17:00 +0000

CoffeeScript è un linguaggio moderno, sintetico ed efficace che compila in JavaScript. Nei progetti web complessi, l'uso di CoffeeScript si sta via via imponendo, perché rende la creazione e la manutenzione del codice lato client molto più veloce e snella.

Una delle prime difficoltà, tuttavia, che si incontrano quando si comincia ad usare CoffeeScript è il fatto che per convenzione tutte le variabili (e quindi anche le funzioni, che in CoffeeScript sono anonime e associate ad un nome di variabile) sono locali.

Un esempio può chiarire meglio. Supponiamo di avere questa semplice pagina in HTML5:

<!DOCTYPE html>
<html>
<head>
    <title>CoffeeScript Palestra</title>
    <link rel="stylesheet" href="css/main.css">
    <script src="js/vendor/jquery-1.7.2.min.js"></script>
    <script src="js/script.js"></script>
</head>
<body>
    <h2>CoffeeScript Scripts</h2>
    <p>Premi <a href="#" onclick="run()">qui</a></p>
    <div id="pippo">&nbsp;</div>
</body>
</html>

Se l'utente preme il link "qui" vogliamo che accada qualcosa, ad esempio compaia la scritta "Ciao Mondo!"

La prima idea che ci viene in mente è quella di scrivere due funzioni, una che ritorna "Ciao Mondo" e una che aggiorna il contenuto del DIV "Pippo" appunto con "Ciao Mondo", in questo modo:

# COFFEESCRIPT SCRIPTS

run = ->
  $("#pippo").html(helloworld)
  null


helloworld = -> 'Ciao Mondo!'

Mettiamo questo codice nel file "script.coffee" e poi lo compiliamo con CoffeeScript. Otterremo script.js che viene poi richiamato dal nostro file HTML (sotto la riga che carica JQuery).

Peccato che una volta eseguito il tutto, quando l'utente preme "qui", non accade nulla.

Il motivo è che il compilatore CoffeeScript traduce le due funzioni "run" e "helloworld" come funzioni locali, quindi di fatto invisibili all'esterno dello stesso codice. Ecco il codice compilato:

// Generated by CoffeeScript 1.3.3
(function() {
  var run, helloworld;

  run = function() {
    $("#pippo").html(helloworld);
    return null;
  };

  helloworld = function() {
    return 'Ciao Mondo!';
  };

}).call(this);

E' giusto che sia così: infatti per evitare conflitti di nomi e variabili globali che rimangono inutilmente appese, mentre in JavaScript è buona norma dichiarare tutto con "var", in CoffeeScript questa diviene la regola.

Per "esportare" il nome di una variabile all'esterno si può agire in diversi modi. Quello che personalmente preferisco è di associare allo spazio dei nomi dello script un nome che espliciti la sua funzione di "esportatore" (ad esempio: exports), e poi di dichiarare le variabili da esportare come appartenenti a questo spazio.

# COFFEESCRIPT SCRIPTS

exports = this

exports.run = ->
  $("#pippo").html(helloworld)
  null


helloworld = -> 'Ciao Mondo!'

In questo modo, la funzione run() - o meglio, la variabile 'run' associata alla funzione anonima - diventa visibile all'interno del nostro file HTML e perciò direttamente utilizzabile.

// Generated by CoffeeScript 1.3.3
(function() {
  var exports, helloworld;

  exports = this;

  exports.run = function() {
    $("#pippo").html(helloworld);
    return null;
  };

  helloworld = function() {
    return 'Ciao Mondo!';
  };

}).call(this);

Come conseguenza non banale, le funzioni ancillari come per esempio la 'helloworld', non vengono esposte, diventando di fatto 'private'.

Perle di Gantt

noreply@blogger.com (Guildenstern70) — Thu, 05 Apr 2012 12:25:00 +0000

I fautori delle teorie di Project Management, i vari aficionados dei diagrammi Gantt e CPM che ogni azienda come si deve sparacchia su vecchi template Powerpoint per giustificare ogni tipo di decisione, dovrebbero rileggersi con attenzione queste parole che Henry Gantt, che fu tra i padri delle moderne teorie di programmazione e inventore del diagramma omonimo, scrisse nel 1900:

"La programmazione è una scienza empirica

basata su teoremi inesatti

che sviluppa algoritmi approssimativi

costruiti su ipotesi sommarie.

Le persone che la praticano

tentano di concretizzare l’astratto

attraverso l’impossibile.

Per fare programmazione

non è necessario essere pazzi,

ma il fatto di esserlo aiuta"

Un font monospace per Linux

noreply@blogger.com (Guildenstern70) — Fri, 09 Mar 2012 16:24:00 +0000

Uno dei problemi "storici", diciamo così, di Linux, è che i suoi font di default sono mediamente bruttini.

La situazione si fa più drammatica quando uno in Linux ci programma. Stare ore davanti a un font brutto e per di più sfocato non è piacevole.

Ecco dunque la mia personalissima scelta come pretendente al titolo di miglior font monospace su Linux. E il vincitore è....

Droid Sans Mono

Ecco uno screenshot da Eclipse (Linux Mint 12):

Esempio di font 'Droid Sans Mono' sotto Linux Mint

Smascherare il phishing

noreply@blogger.com (Guildenstern70) — Wed, 29 Feb 2012 09:07:00 +0000

Subiamo un tentativo di phishing quando riceviamo una e-mail che:

pretende di arrivare da un'istituzione di qualche tipo (finanziaria, commerciale)
contiene un link fasullo che ci porta su un sito sul quale ci viene chiesto di inserire qualche dato privato (ad esempio: una username e una password)

Normalmente queste mail sono studiate per catturare la nostra attenzione, dicendo ad esempio che il nostro account di banca, carta di credito, o altre forme di pagamento è stato bloccato, per cui "è urgente" fare qualcosa, cioè clickare sul link fasullo.

Una volta clickato il link, arriviamo su una pagina di un sito costruito per "sembrare" il sito dell'istituzione, ci viene chiesto di inserire la nostra password e il gioco è fatto: così rubano le password di accesso, che useranno in seguito per azioni fraudolente.

Fortunatamente è facile smascherare un tale tentativo di phishing. Ecco come.

Questa di seguito è l'immagine di un'e-mail di phishing:

Gli elementi ci sono tutti:

la mail sostiene che "qualcosa di grave è successo": è stato "bloccato" l'account della carta di credito
c'è un link per "fare qualcosa per aggiustare la situazione"

Primo indizio - le banche non mandano e-mail
Nessuna istituzione seria (banche, carte di credito, siti commerciali) ci invierà mai una mail che contiene il link ad un sito. Proprio per evitare tentativi di phishing, tutte le mail che riceviamo da enti seri, non contengono link. Casomai l'invito a collegarsi autonomamente al loro sito. Ma, in generale, nessuna mail NON RICHIESTA ci verrà mai inviata.

Secondo indizio - orrori ortografici
Tutte le e-mail di phishing contengono orripilanti errori di italiano, perchè normalmente sono la "traduzione automatica" di analoghe e-mail in inglese. Leggiamo attentamente: 'Si prega di non utilizzare il link all'interno di questa e-mail a ripristinare un altro conto di quanto il tuo' oppure 'Si prega di seguire attentamente le nostre indicazioni e sarà in grado di ripristinare l'accesso al conto in pochi minuti'...

Terzo indizio - link fasulli
Come funziona il phishing? Cercando di portare la persona su un sito che "finge" di essere ciò che non è. E' facile in HTML dire che un link porta da una parte, quando invece porta da un'altra. Però è anche facile capirlo: basta posizionare il mouse sul link stesso per controllare che il link porti veramente dove dice di voler portare: la freccia in verde indica "dove" il link finge di volerci portare (su www.cartasi.it) e quella in blu dove ci porta veramente (su wiki.tenfor..com)

Quarto indizio - sender fasullo
Lo stesso giochetto viene applicato al sender della mail. La mail dice di essere stata spedita da CartaSi S.p.A. Ma se guardiamo bene nei dettagli scopriamo che invece è stata spedita da e-vendax.pop.com.br

Normalmente, in un tentativo di phishing questi indizi sono sempre presenti. Ovviamente: mai clickare sul link, e men che mai inserire informazioni personali (come username, password e numero conti) su siti che non abbiamo raggiunto "volontariamente" - ad esempio partendo da un bookmark del browser.

Cosa fare, infine quando si riceve una e-mail di phishing? Sicuramente segnalarlo al provider, in questo caso GMail:

Inoltre, è sempre possibile avvisare dell'avvenuto tentativo di truffa la sezione locale della Polizia Postale, che in Italia si occupa anche di reati informatici.

Pensare in REST (Thinking in REST)

noreply@blogger.com (Guildenstern70) — Thu, 23 Feb 2012 10:15:00 +0000

La progettazione di applicazioni Web based ha subìto una silenziosa rivoluzione quando nel 2000 Roy Fielding ha pubblicato la sua ormai celebre dissertazione dal titolo: "Architectural Styles and the Design of Network-based Software Architectures", e in particolare il capitolo cinque: "Representational State Transfer (REST)".

In cosa consiste questa rivoluzione? Esiste una modalità, diciamo così, "classica" di concepire un'applicazione per computer, e questa prevede la composizione di un algoritmo più o meno complesso che prende in input una serie di dati, li trasforma e poi li rende persistenti - ad esempio salvandoli su un database. L'essere umano interagisce con l'applicazione attraverso una "interfaccia utente" che viene aggiornata a seconda del cambiamento di stato - o dell'input o dell'output. Così, in modo appunto "classico", un'applicazione è costituita di un'interfaccia utente, una logica, e uno stato - cioè dei dati persistenti.

Le prime applicazioni Web complesse, rese possibili dalle primigenie tecnologie di trasformazione dinamica dell'HTML, lato server con ASP o PHP ad esempio e lato client con DOM/Javascript, implementavano questo modello classico. Vale a dire, presentavano all'utente un'interfaccia grafica con la quale inserire i dati, offrivano una serie di comandi associati a una logica di esecuzione, e infine persistevano i risultati su un database.

Il problema di questo approccio è che l'applicazione diventa un monolite che si può utilizzare solamente nel modo in cui è stata inizialmente concepita.

Con l'aumentare delle necessità di servizi Web, con l'aumentare dei device eterogenei che vi accedono - dai computer ai telefonini, dai videogiochi alle lavastoviglie - questo tipo di approccio è diventato controproducente: l'applicazione monolitica impedisce di utilizzare i dati e le informazioni che è in grado di veicolare appunto perché è concepita per essere utilizzata in un solo modo, che è quello inizialmente concepito dai suoi autori. La conseguenza di tutto ciò è che ogni nuova esigenza di accedere ad un dato o ad un servizio veicolato dall'applicazione necessita di un cambiamento nel codice applicativo o, peggio, nella creazione di una nuova applicazione ad hoc.

Oggi le aziende spendono moltissime risorse IT proprio perché hanno a che fare con applicazioni monolitiche che non riescono a "servire" il dato in maniera abbastanza neutra.

L'idea alla base del protocollo REST inventato da Roy Fielding è che le applicazioni Web devono essere progettate in modo tale per cui immettendo direttamente le URL (che così diventano URI) su un browser si ottengano immediatamente i dati che servono, e che queste URL possano essere "combinate" tra loro in un workflow per ottenere un'applicazione, allo stesso modo con cui nelle architetture SOA noi combiniamo i "servizi" per ottenere sempre nuove applicazioni.

La URL così richiamata deve essere in grado di rispondere in formato "neutro", possibilmente veicolando solamente "i dati", senza cioè alcuna informazione "grafica" di supporto. Le URL stesse devono specificare il formato dei dati che richiedono: se la URL finisce per ".xml" il dato verrà restituito in XML, per ".json" in JSON, e, naturalmente, di default rispondere con un HTML human readable.

Per finire un esempio. Supponiamo di scrivere un videogioco Web, magari per Facebook. Avremo da qualche parte una struttura dati che prende tutte le informazioni relative al giocatore (Player). Questa struttura dati raccoglie e persiste lo "stato" del giocatore durante il gioco. La modalità classica consiste nello scrivere un'applicazione che, a seconda dei comandi dati via web dal giocatore, cambia lo stato e aggiorna di conseguenza la tabella "Player". Esagerando, l'applicazione potrebbe essere costituita da un'unica "pagina" che, a seconda del comando HTTP ricevuto, risponde in un modo o in un altro. Ovviamente, così facendo, nessuno, ad esempio, potrebbe costruire un altro gioco a partire dai dati correnti dei giocatori: perché le informazioni di stato dei giocatori sono "chiuse", e utilizzabili solo dalla "pagina" di cui parlavamo prima.

Se volessimo applicare il protocollo REST all'entità "Giocatore" (Player), come prima cosa dovremmo definire le "URL" che accedono a ciascuna informazione del giocatore, e le URL che vanno a modificare lo stato del giocatore stesso. Ad esempio:

GET    /player/list(.:format)        player#list

POST   /player/list(.:format)        player#list

GET    /player(.:format)             player#index

POST   /player(.:format)             player#create

GET    /player/new(.:format)         player#new

GET    /player/:id/edit(.:format)    player#edit

GET    /player/:id(.:format)         player#show

PUT    /player/:id(.:format)         player#update

DELETE /player/:id(.:format)         player#destroy

Questa tabella fornisce un verbo HTTP e una URL associata. Queste URL, se chiamate con il rispettivo verbo HTTP, sono già in grado di descrivere le funzionalità di base con cui l'utente può ottenere le informazioni sui giocatori! La prima fornisce una lista dei giocatori, la seconda modifica la lista, la terza ottiene informazioni generiche, la quarta e la quinta inseriscono nuovi giocatori, la sesta permette di modificare i dati di uno specifico giocatore e via dicendo...

Se chiamo /player/list ottengo una pagina HTML, /player/list.json un array di giocatori, /player/list.xml un documento XML. Applicazioni sempre diverse accedono agli stessi dati in maniera omogenea. In questo modo, se l'applicazione è ben scritta, sarà sempre possibile immaginare nuovi modi per accedere ai dati, e produrre applicazioni nuove senza dover modificare il codice lato server.

Chiaramente, progettare un'architettura Web in modalità REST comporta un ribaltamento del modo di pensare: invece che partire dalle esigenze "funzionali", bisogna partire dai dati, e dal modo con cui si può manipolarli. Ma il vantaggio di farlo fin dall'inizio, con disciplina, produrrà significativi risparmi nella gestione evolutiva dell'applicazione, e darà l'opportunità di costruire nuovi modi d'uso di applicazioni esistenti praticamente senza sforzo.

Oggi esistono molti framework che producono applicazioni Web RESTful. Il più famoso è "Ruby On Rails". Seguono "Bowler" per Scala, "Jersey" per Java. E molti altri stanno nascendo.

Interoperabilità tra Scala e Java

noreply@blogger.com (Guildenstern70) — Tue, 24 Jan 2012 14:47:00 +0000

Scala è interoperabile con Java, poiché entrambi i linguaggi producono Java bytecode. Questo significa che tutte le seguenti frasi sono vere:

Codice Scala può essere eseguito da una Java Virtual Machine
Codice Java può essere "visto" da codice Scala
Codice Scala può esserre "visto" da codice Java

Supponiamo di avere ad esempio la seguente classe di business in Scala, una generica struttura che rappresenta l'astrazione di un numero razionale. E' costruita passando numeratore e denominatore, ad esempio Rational(2,3) è due terzi (2/3).

 package net.alessiosaltarin.rationals  
   
 class Rational(n: Int, d: Int) {  
   require(d != 0)  
   
   private val g = this.gcd(n.abs, d.abs)  
   val numer: Int = (n / g)  
   val denom: Int = (d / g)  
   println("Created " + this.toString())  
   
   def this(n: Int) = this(n, 1)  
   
   override def toString = this.numer + "/" + this.denom  
   
   def +(that: Rational): Rational =  
     new Rational(  
       this.numer * that.denom + that.numer * this.denom,  
       this.denom * that.denom)  
   
   def *(that: Rational): Rational =  
     new Rational(this.numer * that.numer, this.denom * that.denom)  
   
   private def gcd(a: Int, b: Int): Int =  
     if (b == 0) a else gcd(b, a % b)  
 }  
   
 object RationalComputer {  
   
   def performSum(r1: Rational, r2: Rational): String =  
     (r1 + r2).toString()  
   
   def performMultiply(r1: Rational, r2: Rational): String =  
     (r1 * r2).toString()  
   
 }  
   
 object RationalFactory {  
   
   def create(rationalStr: String): Rational =  
     {  
       val indexOfSlash = rationalStr indexOf '/'  
       val n = nrParse(rationalStr.substring(0, indexOfSlash))  
       val d = nrParse(rationalStr.substring(indexOfSlash + 1))  
       new Rational(n, d)  
     }  
   
   private def nrParse(nstr: String): Integer = Integer.parseInt(nstr)  
 }

Se vogliamo offrire a questo codice una user interface, che non sia Web, abbiamo ben poche possibilità, se vogliamo rimanere nell'ambito di Scala, e cioè quelle di usare il wrapping delle librerie Swing scritto in Scala, vale a dire: http://www.scala-lang.org/api/current/scala/swing/package.html Il problema di questo approccio è che alla data di questo post manca totalmente un editor visuale che generi in output un codice Scala. Quello che abbiamo, invece, sono degli editor visuali che generano codice Swing in Java, ad esempio:

Netbeans Matisse
Eclipse Visual Editor

La buona notizia è che, stanti le premesse di cui sopra, codice Scala può essere visto da Java come se fosse una "libreria" esterna (e viceversa, tra l'altro). Possiamo infatti pensare di realizzare un'interfaccia di questo tipo:

attraverso l'editor visuale che preferiamo, generare il codice Java equivalente, e poi eseguirlo. Per farlo possiamo seguire due approcci, entrambi validi: eseguire dalla macchina virtuale Scala il codice Scala e il codice Java interpretarlo come bytecode esterno, oppure eseguire da una qualsiasi macchina virtuale Java il codice dell'interfaccia grafica e da questo richiamare il bytecode compilato da Scala come una libreria esterna. Chiaramente, è il secondo approccio quello più interessante. Infatti nella pratica avremo a disposizione macchine virtuali Java, ottimizzate a seconda dell'uso. Perché questo approccio sia percorribile, occorre costruirsi un proxy Java in grado di richiamare il codice di business in Scala. Il proxy conterrà i metodi richiamati direttamente dall'interfaccia - nell'esempio, il pulsante di 'esegui operazione'. Ad esempio:

 package net.alessiosaltarin.javaproxy;  
   
 import net.alessiosaltarin.rationals.Rational;  
 import net.alessiosaltarin.rationals.RationalFactory;  
 import net.alessiosaltarin.rationals.RationalComputer;  
   
 public class ProxyLogic  
 {  
   public static String performOperation(Operation op,   
                           String rationalOne,   
                           String rationalTwo)  
   {  
     Rational r1 = RationalFactory.create(rationalOne);  
     Rational r2 = RationalFactory.create(rationalTwo);  
     String result;  
       
     switch (op)  
     {  
          case ADD:  
          default:  
               result = RationalComputer.performSum(r1, r2);  
               break;  
                 
          case SUBTRACT:  
               throw new UnsupportedOperationException();  
                 
          case MULTIPLY:  
               result = RationalComputer.performMultiply(r1, r2);  
               break;  
                 
          case DIVIDE:  
               throw new UnsupportedOperationException();  
     }  
       
     return result;  
   }    
 }

Il codice sopra richiama il codice Scala - il namespace

net.alessiosaltarin.rationals.Rational

Come fa? Semplicemente lo trova nel percorso del codice compilato come Java bytecode, a patto di avere la libreria Scala

scala-library.jar

nel classpath corrente. Supponendo che la classe RationalGUI sia quella generata dal tool visuale, il codice eterogeneo Scala/Java verrà eseguito dalla JVM in questo modo:

java -cp scala-library.jar;[jre,...] net.alessiosaltarin.javaproxy.RationalGUI

Utilizzando ad esempio Eclipse, è possibile aprire due progetti, uno in Scala e uno in Java, e in quello Java che contiene il metodo main, referenziare come libreria esterna il codice Scala custom e la libreria scala-library.jar.

Il negozio di scarpe di mio nonno

noreply@blogger.com (Guildenstern70) — Fri, 30 Dec 2011 09:10:00 +0000

"Io appartengo a una grande azienda che produce scarpe..." disse l'ingegner Carozzi. "In questi tempi di crisi, l'azienda sta andando molto male, e sta cominciando a licenziare. Io mi guardo intorno, e credo di aver capito perchè l'azienda in cui lavoro sta fallendo: è perché noi siamo dei bravi venditori, siamo degli ottimi manager, ma non ci capiamo un gran che di scarpe! Anzi, nelle riunioni aziendali si sente spesso dire con una punta di orgoglio dai nostri capi che loro non ci capiscono molto di scarpe, del resto loro sono bravi dirigenti, bravi venditori, non importa che vendano scarpe oppure lustrini natalizi. Non importerà, d'accordo, intanto però l'azienda sta fallendo." L'ingegner Carozzi si scostò un attimo per accendersi la pipa. Fuori stava cominciando a nevicare. "Io dico queste cose con cognizione di causa, sapete." Fece una pausa di riflessione, poi continuò: "Mio nonno aveva un negozio di calzature in centro. Il suo negozio era sempre pieno di gente! E tutti erano molto sorpresi che il negozio di mio nonno fosse sempre pieno. Perché dovete sapere che mio nonno aveva un carattere difficile, era un burbero, un uomo molto pragmatico, era l'esatto contrario di un buon venditore. Lui era capace di dire a un cliente che aveva messo gli occhi su una scarpa molto costosa, che quella scarpa non era per lui, di lasciar perdere, di uscire dal negozio e risparmiare i suoi soldi. Il negozio di scarpe di mio nonno era sempre pieno perché la gente sapeva che quell'uomo burbero era davvero un intenditore di scarpe! Questo perché prima di essere un negoziante era stato un calzolaio. La gente sapeva che quando andava da lui poteva chiedere un consiglio sulla scarpa adatta a lui, e ricevere una risposta del tutto sincera e competente. La gente in quegli anni doveva risparmiare su tutto: non poteva permettersi un acquisto sbagliato! E sapeva che mio nonno gli avrebbe venduto la scarpa giusta. E il suo negozio era sempre pieno! Nonostante lui fosse un burbero, avesse un carattere difficile e non fosse tagliato per il mestiere di commerciante." L'ingegner Carozzi si voltò verso i suoi interlocutori, sorrise loro con un sorriso amaro, poi si voltò e se ne andò per la sua strada.

Navigazione e geolocalizzazione

noreply@blogger.com (Guildenstern70) — Wed, 31 Aug 2011 12:38:00 +0000

Sono a P., una città a me sconosciuta, per un meeting. Ho bisogno di una farmacia - mi sono dimenticato le aspirine a casa! Fortunatamente ho con me il mio cellulare Android. Ecco cosa faccio:

1) Apro Google. Siccome ho attivato il geolocalizzatore, la pagina visualizzata riporta chiaramente che mi trovo a P.
2) Seleziono Places
3) Da lì digito "Farmacia". Appare un elenco delle farmacie, in ordine di vicinanza.
4) Scelgo la prima e visualizzo la mappa, con le informazioni in tempo reale del traffico.
5) Ok, il traffico è leggero. Maps mi dice che ci arriverò in cinque minuti in macchina e in nove minuti a piedi! Sono in macchina, ci vado in macchina.
6) Clicko sul Navigatore, che immediatamente attiva il GPS. La voce di una signorina, in bell'italiano, mi racconta la strada da fare, nominando anche le vie.

Il tutto con un Android senza nessuno speciale software a pagamento, con una configurazione "out-of-the-box". Niente male!

Il prossimo passo è andare in un supermercato, fare la spesa, e uscire senza pagare alla cassa - ma ritrovandosi il conto esatto addebitato sulla carta di credito. (Il che non è propriamente fantascienza...)

Fammi ripetere con parole mie

noreply@blogger.com (Guildenstern70) — Fri, 24 Jun 2011 17:25:00 +0000

Come Software Architect, la lezione più preziosa è stata imparare che io e lo sponsor del progetto - o meglio, si dovrebbe dire gli stakeholder - parliamo lingue differenti.

Abbiamo del resto una formazione differente, esperienze differenti, e significative difformità nei punti di vista.

Per questo la chiave del successo di un progetto software, oggi, è la chiarezza di comunicazione tra chi fornisce la tecnologia - l'Architect, appunto - e chi intende utilizzarla per raggiungere i suoi scopi di business.

Ecco perché è fondamentale che l'Architect si chieda sempre: ho capito quali sono gli obiettivi di questo progetto? Esiste uno strumento formidabile: dopo aver letto un documento, aver partecipato a una riunione, avere ascoltato le parole degli stakeholder, fermarsi un attimo e dire: "Ok, ora fammi ripetere con parole mie". Vediamo cosa ho capito davvero.

Altrettando fondamentale è chiarire fin dall'inizio che cosa la tecnologia può offrire, e che cosa non può offrire. E' bene fin da subito spianare il campo da miti e leggende. (E lo so che è difficile: è bello all'inizio avere uno sponsor che ci guarda come Bilbo Baggins guardava Gandalf nello Hobbit!)

Direi quindi che sono due le chiavi importanti per il successo di un progetto software enterprise:

1) Voglio capire bene quali sono gli obiettivi da ottenere con il sistema
2) Voglio comunicare bene cosa un sistema è in grado di offrire (e cosa no)

Le questioni tecniche, i disegni architetturali, i dettagli implementativi vengono molto dopo.

Basta Database!

noreply@blogger.com (Guildenstern70) — Fri, 17 Jun 2011 14:26:00 +0000

Una domanda che non fareste mai ad un Cliente, che ha un sistema informativo con un suo potentissimo sistema di RDBMS (database relazionale, normalmente Oracle o MS Sql Server), è: "Ok, ma a cosa ti serve?"

Come a cosa serve un database? (Ti guardano come un poveretto, con tanto di occhi sgranati)... Ma non lo sai che in un database ci sono tutti i dati aziendali? Ma non lo sai che è il cuore del sistema informatico? Ma non lo sai che nessuno nemmeno osa pensare di non averne uno...

Mentre sento queste cose mi aggiro curioso tra gli utenti (solitamente disperati) di un tale eccellente sistema: sono lì che combattono con infinite tabelle, piene di dati ridondanti e infinitamente inutili, che per essere tirati fuori hanno bisogno di uno stranissimo linguaggio, perlopiù incomprensibile alle logiche umane, chiamato SQL.

La maggior parte delle aziende, per cercare di tirar fuori qualcosa da quei mostri lì, compra sistemi di Datawarehouse e Business Intelligence che costano loro un ordine di grandezza in più...

Mi aggiro tra sistemisti che sognano vacanze ai Caraibi e mondi senza computer - soprattutto senza database - e tra manager che guardano fuori dalla finestra cercando di capire con quali soldi pagare l'espertone Oracle (o quello che volete) che gli risolverà il loro maggior problema, e cioè: perché ho milioni di dati inutili e non trovo mai quelli che mi servono?

A cosa serve un database? "Ad archiviare i dati". Sono scettico. "A gestire le transazioni..." ok, ci avviciniamo. "Ad estrarre dai miei dati le informazioni che servono per il mio business..." Ah no! Ecco il punto!

Il punto è che la tecnologia delle basi di dati è nata quando i computer erano relativamente lenti, soprattutto i dischi, poco capienti e le applicazioni molto costose da scrivere, perché difficili da creare e debuggare. Perciò si è inventato un sistema altamente efficace nell'archiviare i dati (scrittura) e nel recuperarli (lettura), e questo a scapito della loro intelligibilità e facilità d'uso.

Il sistema relazionale inventato da Cobb è un sistema efficace con computer poco potenti e capienti, esattamente il contrario dei computer di cui disponiamo oggi.

Oggi possiamo tranquillamente immaginare (e realizzare!) un sistema informativo complesso senza database sotto. "E come fai ad archiviare i tuoi dati?" Li scrivo sul disco, ovvio. Sì ma in che formato?

Ecco una buona domanda. Le cui risposte possono essere almeno tre, e ricoprire con ciò gran parte delle necessità di archiviazione di un'applicazione anche di media/grande complessità.

Prima possibilità: flat file. Salviamo tutti i nostri dati in file di testo in formato flat. Esempi: il win.ini, YAML, SQLite, TextDB ecc. ecc. (http://en.wikipedia.org/wiki/Flat_file_database)

Seconda possibilità: chi ha necessità di immagazzinare relazioni gerarchiche di tipo padre-figlio, o strutture fortemente innestate, può usare il formato di testo più potente in assoluto: XML. Il che è però fin troppo per la stragrande maggioranza delle applicazioni.

Terza possibilità: ok, proprio non potete fare a meno di Oracle! Almeno lasciatelo scrivere a chi lo sa fare, e voi non sporcatevi le mani. Utilizzate dunque uno strumento di ORM - object relational mapping - che ha il compito di serializzare, deserializzare e ricercare i vostri oggetti di business in un normale database relazionale.

Quest'ultima possibilità è quella secondo me più interessante, e che spero prenda piede nelle applicazioni enterprise del prossimo lustro. L'articolo che più concisamente descrive la tecnica è questo.
Seguito dall'ottima voce su Wikipedia.

In soldoni, nelle applicazioni moderne, le attività di DDL (Data Definition Language) e DML (Data Manipulation Language) debbono essere demandate ad un apposito strato software (l'ORM appunto) che le svolge al meglio e in modo "trasparente" per l'utente. In questo caso ciò che conta maggiormente nell'applicativo non è più il modello concettuale dei dati, ma il modello concettuale degli oggetti (sottinteso, di business, cioè a dire: web services, remote procedure calls e quant'altro). Il vantaggio consiste, di fatto, nella drastica diminuzione delle risorse necessarie al disegno e allo sviluppo della base dati - fino quasi ad annullarle.

Per Java, il miglior strumento ORM è senz'altro Hibernate, mentre per il mondo Microsoft è l'Entity Framework

Entrambi sono ottimi punti di partenza per dire definitivamente addio agli odiati database.