Sono impressionato dalla chiarezza espositiva di questo fumetto che parla di AES!
Un fumetto in tre atti che mostra le caratteristiche di Rijandael (che ho scoperto finalmente che si pronuncia reindal, ho sempre emesso dei vocalizzi inquietanti finendo per dire: “beh, AES, ci siamo capiti, no?” :).
Lavorando con NHibernate in architettura S#arp finisco spesso sul Wiki di Ayende Rahien, un programmatore molto attivo nella comunità, noto soprattutto per aver scritto l’eccellente libreria Rhino Mocks, adesso alla sua versione 3.5 RTM. Ha pubblicato anche Rhino NHibernate Profiler, unico nel suo genere.
Spulciando tra i tanti progetti che ha messo a disposizione mi ha incuriosito Rhino Commons, che ha tutta l’aria di essere quel genere di libreria dove i programmatori mettono il frutto della loro esperienza. (la stdlib nasce così, o no?)
(continua…)
Che eccezione lancio quando viene richiesta l’esecuzione di un metodo prima che avvenga la giusta procedura di login e inizializzazione del servizio WCF che sto esponendo?
Prima di scrivere la mia classe che deriva da Exception, voglio essere sicuro che non esista qualcosa di accettabile e riutilizzabile già nel framework.
MSDN mette a disposizione le linee guida per la scelta delle eccezioni da lanciare, purtroppo limitata ad un insieme di tipi molto ristretto.
La lista di tutte le eccezioni presenti sul framework è divisa in due pagine, a seconda che derivino da SystemException o ApplicationException.
Eventuali nuove eccezioni definite nelle applicazioni devono derivare da Exception.
Torniamo al mio caso:
System.UnauthorizedAccessException oppure mi scrivo una mia classe NotYetLoggedInException ?
Jon Skeet pensa che LINQ to Object abbia bisogno di qualche aggiunta. Come dargli torto? :-)
La Beta 1 contiene un insieme interessante di estensioni a IEnumerable, di chiaro interesse.
(continua…)
Ho trovato un bell’articolo pratico su come implementare alcune funzioni di ordine superiore che si incontrano sempre nei linguaggi funzionali. In particolare faccio riferimento alle implementazioni di Haskell: Curry, Zip, ZipWith.
Ho aggiunto Map, Filter, FoldR e FoldL e qualche test case.
Quello che intendo per “programmazione” è variato enormemente negli anni. Agli inizi saper scrivere un algoritmo mi era sufficiente per sentirmi un vero programmatore, poi mi aspettavo di esserlo perché ho imparato un paio di linguaggi ad oggetti e un paio di sistemi operativi. Arriva poi il momento in cui ho colto il significato di pattern e il concetto di programmazione è passato ad un livello di astrazione superiore.
Ora mi rendo conto della necessità di salire di un nuovo livello di astrazione e cominciare a discutere e a ragionare in termini di architetture.
(A questo punto comincio anche a chiedermi quando e se sarò davvero un buon programmatore…)
Devo progettare un nuovo sistema software, ci sono diversi client, diversi server, diversi sistemi operativi coinvolti.
Per mettere tutto insieme e proporre una soluzione coerente e adeguata devo spingermi a guardare dall’alto, in modo da avere una visione generale delle parti che devo sviluppare. Dovrò approfondire le dinamiche che il cliente si aspetta, acquisire il suo linguaggio, disegnare un modello adeguato, usare tecnologie possibilmente indipendenti dalle variabili che incontrerò, verificare che tutto funzioni.
Ho deciso, dopo settimane di studio, indirizzate da Matteo Migliore, e approfondite con “Architecting Applications for the Enterprise” un testo eccezionale di Esposito e Saltarello, ho deciso di adottare una metodologia architetturale Domain Design Driven, con una forte presenza dei test fin dalle primissime fasi dello sviluppo (Test Driven Design). Subito mi sono posto un problema tecnologico: come implemento la metodologia DDD? C# 3.5, Visual Studio 2008 di sicuro. Ma quali tecnologie di contorno devo adottare? NUnit o MSUnit, tanto per dirne una? Entity Framework o NHibernate?
Cominciare a sviluppare una nuova architettura è difficile, esistono decine di tecnologie plausibili, non mi resta che affidarmi a chi l’ha già fatto. Ho valutato NSK, Spring.NET, Entity Framework su VS 2010 e S#arp.
Alla fine della valutazione, necessariamente sommaria, ho deciso di adottare il framework S#arp, che si basa su C# .NET 3.5 sp1 e incorpora un insieme estremamente affascinante di tecnologie, le stesse che avrei scelto io per cominciare qualcosa di nuovo. Mi ha ispirato il fatto che, pur essendo un framework architetturale nuovo le tecnologie sottostanti sono tutte consolidate.
Ho esteso l’ottima libreria uNhAddIns per avere l’inflector in italiano.
In questo modo è possibile, dato un sostantivo singolare, ottenerne il plurale.
Segue la patch per la versione 696 di unhaddins:
(continua…)
Supponiamo di avere la necessità di allocare un certo numero di oggetti in un array, ovviamente l’approccio standard è di usare un ciclo for:
Whatever[] whateverVector=new Whatever[1000]; for(int i=0;i < 1000;i++) whateverVector[i]=new Whatever(i);
Esiste anche un modo diverso, più lento ma per certi versi più elegante, che usa la list comprehension di C#3: LINQ
Whatever[] whateverVector= Enumerable.Repeat(0, 1000).Select(i => new Whatever(i)).ToArray();
Ho dovuto controllare che non fosse il primo aprile, ho dovuto rileggere due volte.
Microsoft contribuisce al codice di Linux importando i driver per Hyper-V: i Linux Integration Components.
Tratto da dal blog di Hank Janssen dell’Open Source Community di Microsoft:
Microsoft developed the Linux device drivers to enhance the performance of Linux when virtualized on Windows Server 2008 Hyper-V. My team and I were responsible for testing and validating the driver components that were contributed for this first release.
This code is designed so that Linux can run in an “enlightened mode” on top of Hyper-V (enlightened mode is roughly the Hyper-V equivalent of “paravirtualized mode” for the Xen hypervisor). Without this driver code, Linux can run on top of Windows, but without the same high performance levels. It is this device driver code that we are releasing today, directly to the Linux Kernel.
We’re not talking a few hundred lines of code here; we’re talking about roughly 20,000 lines of code.
Sempre di Janssen c’è una spiegazione tecnica di cosa siano i Linux Integration Component.
In questi giorni ho chiesto aiuto a Matteo Migliore, un consulente di Architetture software. Mi ha mostrato alcune evidenze che mi stanno facendo cambiare il modo di pensare la costruzione del software. Uno dei modelli che mi ha consigliato si basa sul DDD: il Domain Driven Model.
Sto guardando un intervento di Eric Evans, presentato alla conferenza JAOO del 2007, dal titolo DDD: putting the model to Work. L’intervento ha una seconda parte.
Eric Evans è un esperto di Architetture Software e in particolare è l’autore del libro “Domain-Driven Design” (Addison-Wesley, 2003).
Il modello che propone parte dall’assunto che la parte più complessa di un programma è scritta nel layer di dominio, il cosiddetto Business.
Il Dominio è l’argomento e il mondo dell’attività che il programma è chiamato a fare. Gli elementi che lo compongono sono reali, sono i veicoli e le strade in un sistema di tracking, sono gli aerei e le persone in un sistema di prenotazioni.
Il Modello, in una definizione molto larga, è un sistema di astrazioni che descrive una porzione di aspetti del dominio che può essere usata per risolvere problemi di quel domiino. Quindi per il dominio dell’applicazione occorre definire almeno un modello, usato nella scrittura del codice.
Il modello non deve essere realistico: deve semplificare la descrizione del Dominio da parte del software, tanto che la parte di modello che non si riflette nel software è irrilevante. Quindi la domanda che ci si deve porre quando si disegna un modello ci si deve chiedere:
Quale astrazione è più utile?
La risposta è che è meglio scegliere quella più concreta. Quella più vicina ai concetti di chi ci lavora, agli esperti del dominio. Lavorando con il modello si deve poter mappare, in sostanza, le frasi e i concetti che gli esperti del dominio usano nelle loro attività.
Quel linguaggio deve essere presente ovunque: il linguaggio comune degli esperti del dominio (che a volte non sono tecnici), agli sviluppatori e al software.
Tuttavia a volte non può essere così: qualora si attinga a modelli diversi, magari perché si decide di acquisire una libreria di terze parti, oppure si deve integrare del legacy, o delle tecnologie nuove, ci si può trovare ad avere più modelli, ognuno con un linguaggio potenzialmente diverso dagli altri.
I concetti di modelli diversi vengono separati in contesti differenti (Context).
Quando ci sono quindi più modelli dello stesso dominio, questi definiscono una “Context Map”.
Occorre definire all’interno di questa mappa di contesti le “translation map” che permettono di definire le relazione tra gli elementi dei modelli.
Il disegno non può essere preciso e completo.
Anzi, più è preciso e più è fragile.
Quando cambiano i requisiti rimane facile modificare i modelli relativi. Occorre successivamente verificare ed eventualmente modificare le “translation map”.
