Ci ho pensato più volte di mettermi alla tastiera e raccogliere qualche idea da pubblicare sul mio blog ma causa mancanza di tempo e soprattutto stimoli ho lasciato perdere. Visto questi risultato ho deciso di fare un passo indietro. Lascio perdere il sito/blog basato sul OCTOPRESS – A blogging framework for hackers per tornare al classico wordpress.com . Credo e spero che questa decisione mi agevolerà nel pubblicare nuovi contenuti sul questo sito.

Ma cosa ho fatto negli ultimi 12 mesi? Beh tecnicamente forse non ho fatto nulla di cutting-edge, non ho usato tecnologie dei ultimo grido. Con piacere ho usato tecnologie consolidate cercando di spremerle fino in fondo in un ambiente enterprise cercando contemporaneamente di spingere l’adozione di alcune novità tecniche che posso migliorare il lavoro del gruppo di cui faccio parte. Ora spero solo di trovare il tempo  di raccontare un po’ cosa ha funzionato e cosa no.

Proprio in questi giorni purtroppo uno dei più grandi imprenditori dell’informatica contemporanea,Steve Jobs, ci ha lasciato. La sua dedizione al lavoro era cosa risaputa e mi piace ricordarlo con una frase del suo celebre discorso tenuto presso l’unversita di stanford

You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.

e concludere questo post con la sua frase di commiato

Stay Hungry. Stay Foolish.

Purtroppo però quando si ricorre all’utilizzo della programmazione concorrente i problemi non si fermano qui. Un’altro importante capitolo, e non ceto semplice, è quello relativo alla sincronizzazione dei diversi thread che operano in concorrenza.

Lo scenario più semplice lo troviamo quando abbiamo 2 thread: il primo lancia il secondo e resta in attesa che il secondo termini il suo lavoro. Ma spesso le cose non sono così semplici. Quando le operazioni da eseguire in contemporanea sono molte la faccenda si può complicare parecchio. Quando poi l’esecuzione di una operazione dipende dal termine di altre operazioni concorrenti che al loro volta sono il risultato di altre operazioni asincrone ed in mezzo a tutto questo si inseriscono anche varibili condivise le cose possono facilmente sfuggire di mano.

In questi casi l’approccio migliore è evitare l’improvvisazione: esistono diversi pattern per affrontare in modo corretto questi scenari. La prima cosa da fare è conoscerli e capire come sono implementati nei linguaggi di programmazione che usiamo quotidianamente.

Node.js è un framework event-driven I/O per il motore JavaScript V8. Si tratta di un framework relativo all’utilizzo server-side di Javascript per realizzare applicativi scalabili e real-time. È simile come funzionalità a Twisted in Python, Perl Object Environment in Perl o a Event machine in Ruby.Node.js è in questo momento una delle tecnologie più discusse in rete. Sicuramente Node.js avrà un ruolo fondamentale nei prossimi anni nello sviluppo di applicativi web data la continua e pressante richiesta di applicativi real-time e scalabili. Inoltre il linguaggio utilizzato è JavaScript, linguaggio ampiamente utilizzato e conosciuto dagli sviluppatori web.

Node.js, rispetto agli altri web server disponibili oggi sul mercato, ha un grande vantaggio: offre prestazioni molto elevate ed un consumo di risorse molto limitato. Node.js ha un’altra caratteristica peculiare: è un processo mono-thread.

L’obiettivo di Node.js è quello di fornire un modo semplice per costruire software di rete scalabili. Basta guardare il classico esempio “Hello world” per capire la radicale differenza rispetto agli altri web-server:

1
2
3
4
5
6
7

Node.js mostra tutta la sua efficienza nella gestione della memoria con carichi di lavoro elevati rispetto ai sistemi che per ogni connessione allocano 2MB di thread stack. Inoltre, gli sviluppatori di Node.js sono liberi da preoccupazioni di dead-lock del processo perchè non ci sono lock. Quasi nessuna funzione di Node.js esegue direttamente operazioni di I / O, così che il processo non si blocca mai. Visto che nessuno blocca nulla, anche programmatori meno esperti sono in grado di sviluppare sistemi molto performanti con il minimo sforzo. Altra nota interessante: utilizzando un solo thread per tutte le richieste gli sviluppatori non devono preoccuparsi del’accesso concorrente alle risorse perchè questo caso semplicemente non può avvenire: c’è un solo thread quindi solo una connessione accede ad un risorsa in un determinato istante.

Oggi sono passati alcuni anni da quella lungimirante sessione e di questo topic se ne parla sempre di più. Basti pensare a quale sia l’hype per node.js ovvero un web-server che si programma in javascript dove tutto il codice non è bloccante: il risultato è una estrema scalabilità rispetto ad altri web-server “tradizionali”

Per quanto riguarda i diversi framework per lo sviluppo applicativo , sia web sia desktop, tutti di questi tempi hanno investito molti sforzi per agevolare la programmazione concorrente. Per esempio in un Ruby è stato introdotto Event machine mentre per il .NET framework, che fin dalla versione 1 supporta questo tipo di programmazione, sono stati introdotti la Task Parallel Library e Reactive Extensions

Insomma ogni piattaforma ha introdotto e/o sta introducendo funzionalità che hanno l’obiettivo di rendere semplice la creazione di applicazioni che sfruttano al 100% tutti i core presenti sui personal computer odierni e futuri. Già l’obiettivo è rendere semplice un compito che negli anni passati non era certo un argomento entry-level. La ragione fondamentale a mio avviso era la mancanza di conoscenze chiare in materia ma fortunatamente oggi la conoscenza in materia si è evoluta e perlomeno sono chiare una serie di problematiche comuni a tutti i linguaggi quando si parla di programmazione concorrente.

Patterns of parallel programming

Per chi vuole capire completamente cosa significa la programmazione concorrente (o multi-thread) il primo punto è capire quali sono gli schemi/scenari (ovvero i pattern) che si incontrano in questo mondo.

Al di la del tettaglio tecnologico questo documento di ben oltre 100 pagine dedicate all’attuale versione del .NET Framework è una buona lettura per chi vuole capire quali sono i pattern e gli anti-pattern da utilizzare o meno per creare software multi-thread di qualità.

Fonte: Patterns of parallel programming – Understanding and applying parallel patterns with the .net framework 4 and Visual C#

Parallel programming “for real”

Visto che nei prossimi mesi passerò la maggior parte delle mie giornate lavorative sviluppando un sistema che eroga informazioni in “real-time”, quindi fa largo uso della programmazione multi-thread, vorrei cercare di riassumere con alcuni post quelli che sono i problemi reali che si incontrano facendo un utilizzo quotidiano della programmazione concorrente.

The key to success is to understand which are the many configuration points of ConfORM: IDomainInspector and Mapper. This two pieces can be described as the head and the tail of the mapping process.
IDomainInspector is the entry point and also the mapping driver. This object is used to describe our domain model and currently there is only one concrete implementation of it: ObjectRelationalMapper. ObjectRelationalMapper class use ORM terminology to descride domain: TablePerClass, TablePerConcreteClass, ManyToMany, ManyToOne, OneToOne, Set, Bag, List, Poid, Component are just some of the methods you’ll find in it (they are also grouped inside the IObjectRelationalMapper interface but this is an implementation details). Another important thing to consider is that IDomainInspector is just an interface and this means that if don’t like the current implementation (ObjectRelationalMapper) you can write your own and use with ConfORM. For example you could create a DomainDrivenDesignMappper that has method like RootAggregate, ValueObjec an so on.
The other important object is the the Mapper.

namespace ConfOrm.NH
{
    public class Mapper
    {
        public Mapper(IDomainInspector domainInspector);
        public Mapper(IDomainInspector domainInspector, ICustomizersHolder customizerHolder);
        public Mapper(IDomainInspector domainInspector, IPatternsAppliersHolder patternsAppliers);

        public Mapper(IDomainInspector domainInspector, ICustomizersHolder customizerHolder,
                      IPatternsAppliersHolder patternsAppliers, ICandidatePersistentMembersProvider membersProvider);

        public IPatternsAppliersHolder PatternsAppliers { get; }

        public void Class<TRootEntity>(Action<IClassMapper<TRootEntity>> customizeAction) where TRootEntity : class;
        public void Subclass<TEntity>(Action<ISubclassMapper<TEntity>> customizeAction) where TEntity : class;

        public void JoinedSubclass<TEntity>(Action<IJoinedSubclassMapper<TEntity>> customizeAction)
            where TEntity : class;

        public void UnionSubclass<TEntity>(Action<IUnionSubclassMapper<TEntity>> customizeAction) where TEntity : class;
        public void Component<TComponent>(Action<IComponentMapper<TComponent>> customizeAction) where TComponent : class;

        public void Customize<TPersistent>(Action<IPersistentClassCustomizer<TPersistent>> customizeAction)
            where TPersistent : class;

        public void AddPoidPattern(Predicate<MemberInfo> matcher, Action<MemberInfo, IIdMapper> applier);
        public void AddPropertyPattern(Predicate<MemberInfo> matcher, Action<IPropertyMapper> applier);
        public void AddPropertyPattern(Predicate<MemberInfo> matcher, Action<MemberInfo, IPropertyMapper> applier);
        public void AddCollectionPattern(Predicate<MemberInfo> matcher, Action<ICollectionPropertiesMapper> applier);

        public void AddCollectionPattern(Predicate<MemberInfo> matcher,
                                         Action<MemberInfo, ICollectionPropertiesMapper> applier);

        public void AddManyToOnePattern(Predicate<MemberInfo> matcher, Action<IManyToOneMapper> applier);
        public void AddManyToOnePattern(Predicate<MemberInfo> matcher, Action<MemberInfo, IManyToOneMapper> applier);
        public void AddRootClassPattern(Predicate<Type> matcher, Action<Type, IClassAttributesMapper> applier);
        public void AddSubclassPattern(Predicate<Type> matcher, Action<Type, ISubclassAttributesMapper> applier);

        public void AddJoinedSubclassPattern(Predicate<Type> matcher,
                                             Action<Type, IJoinedSubclassAttributesMapper> applier);

        public void AddUnionSubclassPattern(Predicate<Type> matcher,
                                            Action<Type, IUnionSubclassAttributesMapper> applier);

        public void AddRootClassPattern(Predicate<Type> matcher, Action<IClassAttributesMapper> applier);
        public void AddSubclassPattern(Predicate<Type> matcher, Action<ISubclassAttributesMapper> applier);
        public void AddJoinedSubclassPattern(Predicate<Type> matcher, Action<IJoinedSubclassAttributesMapper> applier);
        public void AddUnionSubclassPattern(Predicate<Type> matcher, Action<IUnionSubclassAttributesMapper> applier);
        public HbmMapping CompileMappingFor(IEnumerable<Type> types);

        protected virtual Mapper.ICollectionElementRelationMapper DetermineCollectionElementRelationType(
            MemberInfo property, PropertyPath propertyPath, Type collectionElementType);

        public IEnumerable<HbmMapping> CompileMappingForEach(IEnumerable<Type> types);
        public void TypeDef<TComplex, TUserType>() where TUserType : IUserType;

        #region Nested type: ICollectionElementRelationMapper

        protected interface ICollectionElementRelationMapper
        {
            void Map(ICollectionElementRelation relation);
            void MapCollectionProperties(ICollectionPropertiesMapper mapped);
        }

        #endregion

        #region Nested type: IMapKeyRelationMapper

        protected interface IMapKeyRelationMapper
        {
            void Map(IMapKeyRelation relation);
        }

        #endregion
    }
}

If you look carefully at the namespace of this class you’ll notice the is “ConfOrm.NH” and if you analize the contructors you’ll understand that the ConfOrm.NH.Mapper class takes always an IDomainInspector and than analize and compile it to a HbmMapping instance via CompileMappingFor or CompileMappingForEach methods (read this post if you need a real sample of this usage)

With the methods on Mapper you can customize its behavior. For example you can customize the table name mapped to a class with this line of code:

mapper.Class<Answer>(cm => cm.Table("a_dummy_table_name"));

or set the Length of the properties using this expression:

mapper.Customize<Name>(name =>
{
             name.Property(np => np.First, pm => pm.Length(20));
             name.Property(np => np.Last, pm => pm.Length(35));
});

This two tasks (table names and property length) aren’t detail of the domain model. They are questions related to the database that’s the reason why the are handled by the Mapper class and not by the IDomainInspector.

Last but not least in the future someone could be interested in using ConfORM with another ORM. All you need to do is to write your own Mapper.

Are you ConfORM ?

NHibernateMappingsExtensions usage it very simple. Copy & paste this class inside your test project and write down a test that set up ConfORM correctly

and finally call the method AsString() if you want to see all the xml in the output console like this

or call the method WriteAllXmlMapping() if you want a single .hbm.xml file for each domain object on the disk

You could find more samples of this two methods in the ConfOrm.UsageExamples project.

The very first step is to create a valid configuration object for NHibernate. Using NHibernate.Cfg.Loquacious feature from NHibernate version 3 this can be done with this lines of code.

            Configuration configure = new Configuration();
            configure.SessionFactoryName("Demo");
            configure.Proxy(p =>
            {
                p.Validation = false;
                p.ProxyFactoryFactory<ProxyFactoryFactory>();
            });
            configure.Properties["current_session_context_class"] = _context;
            configure.DataBaseIntegration(db =>
            {
                db.Dialect<MsSql2008Dialect>();
                db.Driver<SqlClientDriver>();
                db.KeywordsAutoImport = Hbm2DDLKeyWords.AutoQuote;
                db.IsolationLevel = IsolationLevel.ReadCommitted;
                db.LogFormatedSql = LogSqlInConsole;
                db.LogSqlInConsole = LogSqlInConsole;                
                db.ConnectionString = "yuor connection string goes here";
                db.Timeout = 10;
                db.HqlToSqlSubstitutions = "true 1, false 0, yes 'Y', no 'N'";
            });

Once configuration object is ready we must setup mapping for our domain. Now it’s time to use ConfORM. I decided to wrap all mapping stuff inside the class shown below.

    public class ConfOrmDomainMapper
    {
        public ConfOrmDomainMapper()
        {
            orm = new ObjectRelationalMapper();         
            orm.Patterns.PoidStrategies.Add(new NativePoidPattern());
            var patternsAppliers = new CoolPatternsAppliersHolder(orm);

            mapper = new Mapper(orm, patternsAppliers);

            DefineDomain();
            DefineMapping();
        }

        private void DefineMapping()
        {           
        }

        private void DefineDomain()
        {
            orm.TablePerClass(GetTypes());
        }

        public HbmMapping Mapping
        {
            get { return mapper.CompileMappingFor(GetTypes()); }
        }

        IEnumerable<Type> GetTypes()
        {
            var type = typeof(BaseEntity);
            return type.Assembly.GetTypes().Where(t => t.BaseType == type);
        }
        private readonly ObjectRelationalMapper orm;
        private readonly Mapper mapper;
    }

Since all the classes in my domain model inherit from a common class called BaseEntity I can use reflection to get all types with a single line of code. This is not mandatory for ConfORM but as you can the result is very nice. In this simple sample I don’t need to customize the mapper but if you need to do you can use the Mapper class instance. Now all the mapping is already done. Since I used CoolPatternsAppliersHolder ConfORM already create a complete mapping to start working with NHibernate (I’ll blog some details about it in the future)

To finish I need to join ConfORM mappings and NHibernate configuration. This task is done with this few lines of code:

ConfOrmDomainMapper domainMapper = new ConfOrmDomainMapper();

configure.AddDeserializedMapping(domainMapper.Mapping, "MyAppDomain");

After this I’m ready to create a SessionFactory with

configure.BuildSessionFactory();

and start using NHibernate a usual.

This was just the beginning. I hope to find some more time to write again about ConfORM.

I want also thank Fabio Maulo for sharing with community this another piece of great code!