Post

Visualizzazione dei post da 2012

MapReduce: do more with less...

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'

WCF RESTful service: esposizione del servizio

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

WCF RESTful service: cuocere per 5 minuti e servire

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

Cancellazione fisica vs cancellazione logica dei dati

Finalmente dopo lungo tempo trovo il tempo di bloggare qualche "inutile sbrodolata"... L'altro giorno mi trovavo presso un cliente che, giustamente, lamentava problemi di performance su un applicativo. La discussione è stata piuttosto lunga e si sono toccati tanti temi; fino a che non si arriva alla fatidica domanda che ha fatto scaturire questo post: "Ma questo software utilizza la cancellazione fisica dei dati oppure la cancellazione logica?". "Logica...", rispondo io. E lui: "Per quale motivo è stata fatta questa scelta? Non è che i motivi di questa lentezza sono causati da questa scelta?". Rapidamente ho dovuto "radunare le mie forze", e ricordarmi tutti i motivi per cui, anni fa, ho intrapreso questa strada come "default" per i miei progetti (con le dovute eccezioni). A seguire, vi riporto quello che i miei 4 neuroni sono riusciti a partorire dopo la riflessione... «Quando si esegue la progettazione di un siste

Perchè il codename è importante

“Virtualmente” faccio questo mestiere da quando avevo 12 anni; da quando I miei genitori (forse per impedirmi di fare danni peggiori) mi hanno comprato il primo PC 128 Olivetti. Fin di primissimi programmini (cavolate, niente di più) mi sono sempre divertito a dare dei nomi che potessero servire per identificarli rapidamente. Quando ho iniziato a farmi pagare per fare questo lavoro, ho capito quanto dare un nome ad un progetto fosse importante; sia per cliente che per il fornitore, era molto semplice identificare univocamente il sistema che era stato realizzato, differenziandolo dagli altri. La necessità  è certamente più sentita in aziende come la mia, dove nuovi progetti nascono di frequente, e dove spesso capita che gli argomenti trattati siano i medesimi e I flussi funzionali completamente diversi. Ogni tanto chiama qualche cliente dicendo: “Buongiorno, chiamo per il software di gestione delle paghe.” (o della “formazione”, o dei “budget”); chiaramente ne avete sviluppati 3 o 4

Sezioni custom nel file “.config”

Una delle prime cose che ho apprezzato anni addietro passando da Visuali Basic 6.0 a .NET, è la gestione dei file di configurazione; I vecchi file “.ini” presenti in VB6 avevano (finalmente, diciamocelo) lasciato spazio a file xml in grado di esprimere ben più di una sfilza senza fine di coppie “chiave/valore”. Ciononostante per lungo tempo, come molti neofiniti, ho utilizzato la sezione “appSettings” del file “.config” esattamente come prima: nessun beneficio, dato che è come “sparare alle mosche con un cannone”... La situazione sembrava essere sotto controllo fino al giorno in cui uno dei miei progetti era cresciuto a dismisura, e il livello di customizzazioni che era in grado di gestire, si aggirava nell’ordine delle centinaia. “Ma possibile che non esiste un modo più furbo (e logico) di salvare i settings?”. Chiaramente, si (solo che ero troppo “newbie” per saperlo"). Prima di tutto aggiungiamo una bellissima sezione personalizzata in “configSection"… ...dove “ch

Partiamo...

"Zen Programming", come un "carissimo" collega ha battezzato il mio stile di programmazione, rappresenta un tentativo di mettere a disposizione di tutti le mie esperienze personali nel mondo .NET e non solo. Attraverso questo blog cercherò di restituire alla comunità qualche pillola di esperienza, che in questi anni ho preso in prestito da tanti professionisti (molti dei quali straordinariamente bravi), e che mi hanno fatto crescere come sviluppatore e amante della tecnologia. Chiudo il primo post con una meravigliosa citazione di Ray Ozzie : “Adoro l’informatica perchè si può realizzare tutto quello che siamo in grado di immaginare…”