Zen Programming.it

Qualche giorno fa stavo lavorando ad un piccola applicazione con un collega e ci siamo dovuti subito confrontare con una scelta architetturale che mi ha ispirato la scrittura di questo post. Prima di mettere troppa carne al fuoco, meglio spiegare i requisiti di questo mini-sistema; chiaramente lo spoglierò di tutte le cose che "fanno solo volume", e che non sono significative in questo frangente. Problema: data una bellissima GUI (WPF, Windows Forms, fate voi...) con una casella di ricerca "Google style", è richiesto che l'applicativo esegua una ricerca di tutti documenti, di un formato definito, che contengono nel nome del file oppure nel contenuto del documento stesso, il testo digitato. La richiesta particolare è che la ricerca debba essere fatta sia sul computer locale, che in una locazione remota utilizzando un servizio web (opportunamente disegnato per l'occasione) in grado di erogare le informazioni. Sembra tutto facile, quindi mettiamo un bel pu...

"Nell'ingegneria del software, un design pattern (schema di progettazione) può essere definito una soluzione progettuale generale a un problema ricorrente.". Questa è la prima frase che riporta Wikipedia quando si cerca la voce "Software Design Pattern". I più arguti avranno già capito che questo post non è di natura empirica (quindi condito da tanto "succoso" codice); più che altro è l'ennesima "sbrodolata" concettuale-filosofica a tema informatico. Si, perchè essere appassionati di informatica è un po' essere filosofi e teorici della materia, capire i principi ispiratori, farli propri ed applicarli alla pratica quotidiana. Ritengo che il nostro mestiere sia una di quelle professioni che più richiedono dedizione e passione. Si studia per anni ciò che hanno fatto quelli che sono venuti prima di noi; si fa esperienza sul campo, versando sangue e lacrime ogni giorno. Alla fine ci si sveglia una mattina convinti di sapere (più o meno...

Dove eravamo rimasti? Ah, si...all'implementazione concreta della classe astratta che permette l'esecuzione dell'algoritmo di MapReduce... Come dicevamo nel precente puntata, per portare a termine il nostro scopo, ci faremo dare una mano dalla libreria "Task Parallel Library", o TPL. Tale libreria, in precedenza rilasciata come estensione del .NET Framework, a partire dalla versione 4.0 è stata incorporata nel framework stesso, ponendosi come approccio più efficace per la gestione di processi multi-thread e asincroni in generale. Ma non perdiamo ulteriore tempo e vediamo il codice, per poi illustrare come sia nata la sua implementazione. Naturalmente la classe astratta deve implementare i requisiti dell'interfaccia "IMapReduceProcessor"; esporre le proprietà che servono per "osservare" lo stato, e il metodo di "Execute" che rappresenta il cuore dell'algoritmo. Come detto in precedenza, affichè MapReduce possa essere a...

Nel precedente post ho illustrato la "teoria" che si cela dietro all'algoritmo di "MapReduce". Ora veniamo al lato pratico della cosa. Prima di tutto è necessario pensare a come implementare i personaggi che partecipano alla nostra scenetta: il nostro palazzo, il coordinatore, e gli assistenti. Il palazzo, ovviamente non può essere che un dato enumerabile; il coordinatore è la classe che implementa fisicamente l'algoritmo di MapReduce; e, per finire, i nostri assistenti saranno delle entità che possono lavorare contemporaneamente: dei banalissimi thread. Il concetto di "thread" e "parallelismo" è molto comune nell'informatica. Negli ultimi anni, cioè da quando ci si è avvicinati troppo al limite fisico della velocità dei processori, si è cercato di migliorare la potenza dei sistemi andando nella direzione di aumentare il numero delle CPU, piuttosto che spingere ulteriormente sull'acceleratore del "clock". Con la pa...

Recentemente mi sono trovato a dover ristrutturare una applicazione parecchio datata; e con "datata" intendo che sono passato circa tre anni dalla sua prima implementazione (che nell'informatica sono equiparabili ad una era geologica). Diciamo anche che l'applicazione in oggetto ha sempre sofferto delle conseguenze della formula magica "il cliente ha fretta" e "ci metto una pezza". Il prodotto che ne è uscito è la classica "palla di pezze", composta da una miriade di soluzioni cervellotiche, dove è evidente che non si è fatto un utilizzo adeguato della materia cerebrale in momenti di elevata pressione. Tutto considerato, la soluzione soddisfa i requisiti: i risultati attesi dal cliente sono quelli sperati e non ci sono intoppi particolari; se non che si arriva al fatidico giorno dove l'utente di turno vuole processare un file con circa una "mezza milionata" di elementi. Il povero applicativo ce la mette tutta, ma non c...

Previously on "Zen Programming"... Nel precedente post abbiamo visto come realizzare un servizio RESTful basato su WCF; ma ci siamo fermato al più bello, cioè a come "hostare" il servizio web su IIS. Prima di tutto abbiamo bisogno di un file ".svc"...eh, ma sarebbe troppo facile...no? Quindi ho colto l'occasione per illustrarvi un'altra meravigliosa caratteristica di WCF, detta "service activation": l'handler del servizio sarà generato utilizzando solo la configurazione dell'applicazione, senza un file reale che funga da endpoint per l'invocazione. Per far questo abbiamo bisogno di un "service host factory", cioè una classe che eseguirà la generazione (la "produzione", essendo "factory") dell'istanza del servizio basato sull'interfaccia "ISimpleRestService". Il codice è autoesplicativo: basta derivare la classe base "ServiceHostFactoryBase" ed eseguire l'over...

Spesso mi capita di lavorare con soluzioni architetturalmente articolate, che magari prevedono l'esposizione di servizi web in grado di permettere una certa interoperabilità o comunicazioni con sistemi esterni. Sempre più di frequente l'interoperabilità di cui parlo si applica anche all'interno della stessa piattaforma software, tra moduli divesi; tutte queste entità devono collaborare insieme con lo scopo prefissato dal flusso funzionale. Quando l'obiettivo è creare un servizio web, la scelta che nella maggior parte delle volte si fa è quella di SOAP, cioè quella di un web service "standard", che si basa su un contratto che l'utilizzatore deve "accettare" prima di poter dialogare con l'entità che "offre" il servizio. Naturalmente io non ho mai fatto eccezione a questa regola, se non quando mi sono dovuto confrontare con una soluzione che basava sulla comunicazioni tra servizi web, la maggior parte del proprio source code. Con i...