Post

Visualizzazione dei post da 2013

Chrome Development : RESTful Stress

Negli ultimi mesi sto lavorando sempre più spesso nello sviluppo di applicazioni "service oriented". Sviluppare piattaforme di servizi web è sicuramente una delle cose che preferisco, perchè mi permette di lavorare molto a livello funzionale ed architetturale, e meno sulla parte front-end; quest'ultima...beh, diciamo che non è "nelle mie corde". Mi considero una capra (con tutto il rispetto per gli ovini) nella realizzazione di interfacce uomo macchina e, in generale, in tutto quello che va sotto la definizione di "user experience". In realtà con il "gusto per l'estetica" ci devi nascere; se non se ne è dotati, meglio limitarsi delle cose semplici ed essenziali, lasciando la gloria ai colleghi "web designer"... Quello che è fondamentale tenere in considerazione quando si lavora ad una piattaforma di puri servizi web, è che è necessario esporre pubblicamente solo le informazioni e le operazioni strettamente necessarie al corret

IUserType: serializzazione di un oggetto singolo

Per completezza di informazione mi sembra utile fare una piccola integrazione al mio ultimo post relativo ai custom "IUserType" di NHibernate. Quella particolare implementazione prendeva in esame una lista di oggetti da serializzare in JSON; tuttavia le situazione in cui è necessario salvare un tipo complesso "singolo", sono altrettanto significative. Per questo motivo, senza ulteriori indugi vi lascio il codice della classe "JsonObjectTypeBase di T" che permette il suo corretto trattamento. Aggiungiamo al modello "GeoLocation" di esempio una ulteriore proprietà "Data", di tipo "LocationData" che servirà per integrare delle informazioni addizionali sull'oggetto principale. Chiaramente la situazione è sempre la medesima del precedente articolo: non si vogliono eseguire operazioni di filtro su queste informazioni, ma semplicemente visualizzarle a titolo informativo. La mappatura NHibernate dell'oggetto dovrà essere a

NHibernate IUserType in combinazione con JSON.NET

Nel precedente articolo ci siamo lasciati con la definizione del nostro dominio applicativo. Abbiamo introdotto l'interfaccia "IUserType" di NHibernate, utilizzata per "insegnare" all'OR/M come trattare tipi di dati non nativi e persisterli sulla base dati. Non è mia intenzione spiegare tutte le peculiarità e le sfaccettature dell'utilizzo di IUserType: ci sono moltissimi tutorial in rete (molti dei quali veramente ben scritti) che spiegano in dettaglio ogni singolo aspetto. Tuttavia, per completezza di informazione ripoterò una brevissimo estratto della definizione dell'interfaccia nuda e cruda: Essenzialmente, quello che deve essere fornito all'OR/M, per renderlo in grado di trattare il dato, è la specifica del tipo di colonna su cui dovrà persistere l'informazione stessa. Nel nostro caso l'obiettivo è salvare un oggetto strutturato in formato JSON sulla base dati: quale miglior (e conveniente) scelta se non un campo "stringa&q

NHibernate e Json: semplice e funzionale

Non nego di aver trascurato un po' il blog in questi ultimi tre mesi; il tanto lavoro e niente vacanze, hanno influito negativamente sulla mia vena creativa. Nonostante tutto, ancora una volta, un "meraviglioso" lavoro con cui mi sto cimentando in questo periodo é fonte dell'ispirazione di questo post. Definiamo lo scenario di lavoro: ammettiamo di avere un elenco di elementi, tuttosommato semplici, che posseggono una serie di oggetti collegati. Per fare un esempio calzante, definiamo un certo numero di locazioni geografiche ("GeoLocation"), ciascuna delle quali contiene una lista di risorse ("RemoteResource"). La locazione possiede una serie di attributi (che sono di nessuna rilevanza per la questione), mentre le risorse sono composte solamente da un url assoluto, e una data di registrazione della risorse stessa. Normalmente, per la persistenza dei dati su un database, si procederebbe alla creazione di una tabella per le locazioni ("GeoL

Sfruttare le Action ASP.NET MVC da Silverlight: dalla teoria alla pratica

Come detto, in alcuni scenari legati a Silverlight, è possibile sostituire le funzionalità di WCF Ria Services con delle più “snelle” action ASP.NET MVC. L’obiettivo dichiarato è rimuovere la complessità di una piattaforma di servizi che, a volte, può risultare eccessivamente pesante da utilizzarsi in situazioni tutto sommato semplici. Se non si fa un massiccio uso del “tracking” (cioè del tracciamento dello stato di ogni modello emesso dal server), l'uso dei WCF Ria Services è rimpiazzabile con una soluzione, a mio parere, semplice e performante; una soluzione che rappresenta il giusto compromesso tra produttività e innovazione, orientata a tecnologie più moderne. Se siamo in una situazione in cui l'applicazione Silverlight (come detto, basata su WCF Ria Services) è già completa e funzionante - certo, se non volete farvi del male - vi esorterei a domandarvi se esiste una reale necessità di cambiare il meccanismo per migliorare le performance. Se invece l'applicazi

Sfruttare le Action ASP.NET MVC da Silverlight

Sto scrivendo questo post da San Leonardo in Passiria (in Südtirol...uno dei posti piú belli al mondo, a mio parere), usando il mio smartphone; ogni giorno mi sorprendo sempre di più come l'informatica fa passi da gigante, come nascono nuove tecnologie o nuove tecniche per sfruttare meglio quelle esistenti. E in questo post, nel mio piccolo, voglio condividere la mia recente esperienza in questo senso. Poche settimane fa stavamo lavorando ad una nuova versione di un applicativo rilasciato inizialmente nel 2008, basato su Microsoft Silverlight e su WCF Ria Services; naturalmente la primissima versione era basata su SL2 e .NET DataServices, poi ripetutamente aggiornato a SL3/4 e WCF Ria Services. Le revisioni successive non hanno minimamente modificato l'approccio architetturale iniziale, pur introducendo quanto di meglio era disponibile per semplificare la vita dello sviluppatore. Ma con il crescere dei dati gestititi, nel corso degli anni, il sistema ha sempre piú dato segni

Sfruttare IDisposable per realizzare un misuratore di tempistiche di esecuzione (Parte 2)

Dicevamo (nel post precedente )... L'interfaccia IDisposable ci permette di controllare il ciclo di vita di una classe, dal suo istanziamento, fino alla completa distruzione; l'uso congiunto di questa interfaccia (o meglio, di classi che implementano questa interfaccia) e la keywork "using", ci permette di controllare questo ciclo vitale in maniera molto più rigida, ottenendo quindi un controllo completo sulla classenquando essa viene effettivamente dealocata dalla memoria del processo. Partendo dall'helper "Tracer", che funge da "entry-point" della funzionalità che stiamo realizzando, possiamo accedere al metodo che ci permetterà di generare una nuova instanza della classe materialmente responsabile dell'attività. La banalità dell'implementazione del metodo lascia veramente pochissimo spazio ai commenti: un semplice passaggio dei parametri previsti dal metodo (uno dei quali opzionale), iniettati immediamente nel costrutture della n

Sfruttare IDisposable per realizzare un misuratore di tempistiche di esecuzione (Parte 1)

Sicuramente almeno una volta nella vostra carriera di sviluppatori vi sarà capitato di dover misurare la durata di esecuzione di un'istruzione oppure di un gruppo di istruzioni. La cosa più semplice da fare è dichiarare due variabili di tipo "DateTime", dove saranno registrate la data di inizio dell'operazione, e la data di fine; quindi eseguire una banale "end.Subtract(start)" per ottenere il "TimeSpan" che rappresenta l'effettiva misurazione della durata. Non vi ho detto niente di nuovo, quindi. Ma ammettiamo che dobbiate misurare diverse porzioni e funzioni del vostro sistema. Se poi si tratta di un sistema che processa "batch" un quantitativo di dati considerevole, la cosa è un tantino dispersiva, e si rischia di sporcare tutto il codice con variabili come quelle sopra citate. La domanda che mi sono posto è la seguente: ho modo di ottenere il medesimo risultato evitando di inquinare il mio codice con vagonate di istruzioni che

Maggiore espressività in un'applicazione console

Nell'ultimo periodo mi sono concentrato non su architetture tradizionali (web o desktop), ma su processori ed elaboratori che macinano grossissime quantità di informazioni in background in modo asincrono. In questo genere di progetti, l'interazione utente non è la cosa più importante; lo sono invece la gestione degli errori, il tracciamento dei vari step applicativi in tutte le fasi dell'elaborazione e, più di tutto, le prestazioni. Lo scopo finale è ottenere un sistema che sia in grado di completare il workflow attraverso una sequenza ben definita di semplici passi logici, tutti tracciabili e ben evidenti anche in fase di analisi dei log. Un'applicazione console è la scelta più indicata per iniziare a sviluppare (e testare) un elaboratore massivo, perchè rimuove i "fronzoli" di un sistema tradizionale, permettendo di concentrarsi sul lavoro che deve essere portato a termine. Ben presto ci si rende però conto che la semplice "WriteLine" della c

Inversion of Control e Dependecy Injection fatti in casa (3)

Finalmente siamo giunti all'ultimo capitolo della saga iniziata con i precedenti due post riguardanti l'introduzione all'IoC e l'implementazione dei plugins ; finalmente siamo giunti al nocciolo della questione; finalmente, senza indugio, passiamo a vedere qualche cosa di interessante... Il pezzo che manca a completare il puzzle è capire come dare la possibilità alla nostra applicazione di generare un'istanza di un particolare oggetto, che implementa l'interfaccia "IFinder", utilizzando una semplice stringa di testo. La struttura che permette la "magia" è la classe statica "FinderIoc", e il suoo metodo "CreateProvider". Come visto in precedenza, l'utilizzo della stessa è estremamente banale; l'implementazione nasconde qualche piccola insidia, dovendo fare uso di tecniche quali "Activation", "Reflection" e "Dynamic Type Generation". Dopo una sana validazione dell'argomento in

Inversion of Control e Dependecy Injection fatti in casa (2)

Nella precedente puntata eravamo rimasti alla descrizione del service layer di accesso alle funzionalità applicative. Inoltre, la definizione dell'interfaccia "IFinderProvider" permette di esporre il contratto condiviso tra i differenti plugin di ricerca: share, local e webservice. Come detto, prima di passare alla descrizione del "container", responsabile della gestione modulare operata da Dependency Injection, vediamo l'implentazione reale del modulo "Local". Il codice riportato è una banalissima implementazione di "mockup" che emette dei sample data. In una situazione reale la logica applicativa eseguirebbe una ricerca sul disco locale, magari scansionando le directoy secondo una struttura definita, e partendo da un percorso "radice" definito da configurazione applicativa. La cosa importante è che il modulo "Local" è implementato dalla classe "LocalFinderProvider", che rispetta i termini del contratt