Il pattern "catena di montaggio"

Applicabilità:

quando a fronte di una sorgente di dati più o meno complessi, occorre effettuare una catena di operazioni condizionate dal contentuto degli eventi stessi, operazioni che possono anche essere condizionate l'una dall'altra rispettando però la sequenza temporale. La catena di montaggio può prevedere instradamento multiplo per il prodotto in elaborazione, ed inoltre in macchine che dispongono di più unità di elaborazione, ogni stazione di montaggio può lavore su un Thread separato utilizzando il meccanismo del pipelining.

Struttura:

il pattern è composto da un oggetto "costruttore della catena" il cui compito è quello di assemblare la catena di montaggio, un oggetto "catena di montaggio" il cui compito è quello di eseguire il ciclo di montaggio, ed una sequenza di oggetti implementanti l'interfaccia "stazione di montaggio", che effettuano le operazioni necessarie per assemblare la soluzione finale.

Implementazione:

Stazione di montaggio
Una stazione di montaggio è un thread che effettua operazioni su dati prelevati da un unico input (una coda FIFO sincronizzata) e che può, in funzione del contenuto del dato da elaborare, instradare in output su una o più code il prodotto della sua elaborazione verso altre stazioni.

Catena di montaggio
questo oggetto si occupa dell'instradamento del "semilavorato" all'interno delle stazioni, fornendo la struttura, il percorso ed i meccanismi di trasporto dei semilavorati.

Costruttore della catena
Ovviamente questo à l'oggetto più importante: ha il compito di costruire la catena di montaggio, cioè interpretare correttamente la configurazione richiesta e posizionare le specifiche stazioni nell'ordine corretto. In questa situazione si può utilizzare un Factory Method delegando quindi alle implementazioni della factory la logica di assemblamento della catena di montaggio.

Un esempio

Ho utilizzato questo pattern per un applicativo di monitoring di una rete: ogni sessione di monitoring ha le sue caratteristiche particolari, per cui viene costruita una catena di montaggio ad hoc in funzione di una configurazione presente in un database; al passaggio di un pacchetto di dati, viene effettuata una sequenza di operazioni:

• Calcolo di una funzione di valorizzazione di una parte del pacchetto determinata dal valore dell'intestazione del pacchetto e da dati contenuti nel DB


• Aggiornamento di una cella di una tabella, la cui posizione e contenuto vengono calcolati dalla prima stazione di montaggio


• Trace su un file in funzione dell'intestazione del pacchetto


• Entry in un report HTML o XML


• Aggiornamento di un grafico

Utilizzando la costruzione "al volo" della stazione di montaggio ho semplificato drasticamente il codice di interpretazione degli eventi, rimosso gran parte delle istruzioni condizionali e, cosa più importante, ho la possibilità di estendere a piacere le operazioni da svolgere al variare della configurazione.
Inoltre, utilizzando una catena di montaggio "multilinea", dove cioè gli eventi vengono instradati verso direzioni diverse ad ogni stazione, sono riuscito ad ottenere la variazione di comportamento in funzione dell'evento in modo molto semplice.

Sun catame lo strument!

"Mag-nifico!". Un piccolo gioiello di liuteria!
Un meraviglioso basso 4 corde fretless, manico in acero e wenge, tastiera in palissandro, corpo in frassino con un meraviglioso colore "natural", 2 pickups Bartolini, elettronica attiva, ponte in ottone, meccaniche Hipshot.
Detto tutto? Bhe.. no... manca il "suona da dio!"

Inheritance in SQL

While having a brief look at PostgreSQL, I saw a very interesting feature: table inheritance.
(Please refer to the documentation for a more precise description.)

This brilliant feature can lead to a very easy and efficient object to relational mapping!

Open source e modelli evolutivi

Ubik ha sollevato una questione molto interessante: ihho l'open source ha la tendenza a disperdere le energie piuttosto che concentrarle in una direzione vincente, nella misura in cui lo sforzo richiesto per la comprensione del sorgente di un prodotto non banale (per non banale intendo "grande") è a volte così elevato da scoraggiarne l'acquisizione, la customizzazione, e spesso succede che piuttosto di riprendere un'artefatto già esistente ne viene creato uno ex-novo; naturalmente questo porta ad un grande dispendio di energie intellettuali ed a una non-competitività dei prodotti open nei confronti dei prodotti closed.
Sono d'accordo, più o meno.
In passato ho letto alcuni cose interessanti inerenti la teoria dell'informazione e di come essa possa eventualmente essere estesa fino a far parte della grand unification theory; in particolare, in una visione olistica, di come l'universo abbia una ben delineata ed intrinseca tendenza evolutiva, che viene attuata attraverso una precisa strategia. Per semplificare, possiamo anche prendere in considerazione la "congettura evolutiva di Darwin" meglio nota come teoria dell'evoluzione: attraverso il randomico rimescolamento genetico, le specie evolvono per meglio adattarsi all'ambiente. O meglio, vi è una naturale tendenza delle mutazioni migliori a sopravvivere a discapito di quelle peggiori, e la conseguenza a lungo termine di questo cammino selettivo è l'evoluzione - ovvero l'orientamento delle strutture complesse verso un più efficiente ed economico sfruttamento delle risorse. Nonostante questo sia un processo tendenzialmente più dispendioso se relazionato alla soluzione idealmente ottima, credo che sia comunque il più efficiente tra i processi di evoluzione a lungo termine realmente attuabili, un pò come lo può essere un algoritmo dinamico se confrontato con un algoritmo greedy.
Questo approccio all'evoluzione delle strutture complesse può essere in qualche modo accostato allo sviluppo di software open source; se è infatti vero che la dispersione delle energie intellettuali porta un singolo progetto open più o meno lontano dalla più efficiente delle realizzazioni possibili, è altresì vero che a lungo termine, e per quanto riguarda l'intero insieme dei progetti, ci sia un'importante, ed innegabile evoluzione; inoltre, esattamente come l'evoluzione biologica si appoggia sulla diversificazione, anche lo sviluppo di software open promuove lo sviluppo di più di una soluzione a fronte di una specifica problematica: anche se questo può sembrare uno sperpero di energia consente comunque una maggior probabilità di sopravvivenza ad almeno una delle soluzioni (peraltro tipicamente vi è un travaso di tecnologia tra più progetti - in natura esiste un effetto assimilabile, il rimescolamento genetico - che consente alla singola sniplet di codice di persistere anche dopo la "chiusura" di uno dei progetti in cui viene utilizzata).
Considerando i fattori ambientali, culturali, e insomma le varie condizioni al contorno che condizionano lo sviluppo di software, imho il modello di sviluppo open - nonostante le sue dispersioni di energia intellettuale - risulta comunque il modello evolutivo che a lungo termine consente la "migliore evoluzione possibile".
Fattori ambientali e culturali? Si, mi riferisco in particolare alle capacità delle macchine, alle features dei sistemi operativi, alle tendenze tecnologiche e all'integrazione con l'ambiente operativo e con altri applicativi: tutti questi fattori spingono in direzioni precise i software, senza che necessariamente la direzione intrapresa sia quella che porta alla massima efficienza di un particolare applicativo; ad esempio credo che il vecchio M$ Office 2K sia una suite per ufficio veloce ed efficiente che sostanzialmente fa tutto quello che deve fare, mentre invece la nuova versione 2007 è enorme, lenta, e non da nessun vantaggio particolare (questo è un esempio di evoluzione verso uno stato peggiore), mentre la controparte Openoffice sta diventando un ottimo software: dove una volta era lento e pensante in fatto di richieste hardware, oggi è equilibrata e brillante, oltre a supportare standard aperti (e questo è invece un esempio di evoluzione verso uno stato migliore).
Concludendo, anche se di primo acchito può non essere vero per un sottoinsieme di progetti o in un ristretto frame di tempo, credo che l'open source offra un modello evolutivo efficiente in un'ottica a lungo termine.

Powua - Il supercomputer su Internet

E' con grande piacere che vedo realizzata la mia idea di virtual super computer!
Powua è una grid di qualche centinaio di processori accessibili tramite un'interfaccia remota (Java). Molto, molto interessante:
www.powua.com