Tous les développeurs savent qu’il faut être prudent lorsqu’on est en Corée du Nord ou lorsqu’on s’amuse avec les Winforms dans un contexte multi-threads. On ne doit pas, plus précisément, accéder à un contrôle graphique à partir d’un thread différent de celui dans lequel il a été créé. Ceux qui ont essayé (tous, je crois) ont découvert qu’une InvalidOperationException était levée :

Opération inter-threads non valide : le contrôle ‘MyControl’ a fait l’objet d’un accès à partir d’un thread autre que celui sur lequel il a été créé.

Enfin, à partir de VS2005 et en debug mode uniquement. Par exemple, dans une Form le code suivant affecté à l’évènement Click d’un bouton suffit à provoquer une telle exception :

private void myButton_Click(object sender, EventArgs e)
{
    var thread = new Thread((ThreadStart) delegate { this.Text = "Yeah"; });
    thread.Start();
}

L’accès à la propriété Text de la fenêtre (qui est un contrôle) s’effectue dans un thread différent du thread d’affichage principal.

Si je vous demande comment arranger ça, vous allez me répondre naturellement qu’il faut écrire quelque chose comme :

private void myButton_Click(object sender, EventArgs e)
{
    var thread = new Thread(ChangeFormCaption);
    thread.Start();
}

private void ChangeFormCaption()
{
    if (this.InvokeRequired)
    {
        this.Invoke((MethodInvoker) ChangeFormCaption);
    }
    else
    {
        this.Text = "Yeah";
    }
}

On teste via la propriété InvokeRequired si on est dans le thread ayant créé la fenêtre. Si ce n’est pas le cas, alors on utilise la méthode Invoke pour exécuter le délégué passé en paramètre (ChangeFormCaption) dans le bon thread : celui à partir duquel la fenêtre a été créée.

Ca fonctionne, hourra.

Maintenant, un autre exemple :

public partial class MyForm : Form
{
    public MyForm()
    {
        this.InitializeComponent();

        // New background thread started from the form constructor
        var thread = new Thread(DoSomething);
        thread.Start();

        Thread.Sleep(100);
    }

    public void DoSomething()
    {
        if (this.InvokeRequired)
        {
            this.Invoke((ThreadStart) this.DoSomething);
        }
        else
        {
            Thread.Sleep(100);

            // Access to the control (the form itself, actually)
            // from the background thread
            this.Text = "Yeah";
        }
    }
}

A priori, ça fonctionne, puisqu’on prend bien garde d’utiliser la méthode Invoke lorsque nécessaire. Mais en fait - et c’est bien là tout l’intérêt de ce billet si tant est qu’il y en ait un - ça ne fonctionne pas toujours. On continue d’obtenir plus ou moins aléatoirement l’InvalidOperationException liée à l’interaction cross-thread condamnée plus tôt.

Mais pourquoi ?

Un nord-coréen répondrait sans doute “parce que”, mais je ne suis pas nord-coréen. La MSDN non plus, faut croire, puisqu’après avoir halluciné quelque temps j’y ai trouvé une ligne spécifiant le comportement de la propriété InvokeRequired lorsque le handle du contrôle sur lequel elle est appelée n’est pas encore créé : elle retourne false.

C’est fâcheux, et c’est aussi ce qu’illustre l’exemple précédent. Dans certains cas, en lançant le background thread durant la construction de la fenêtre, le handle de cette dernière peut ne pas avoir été créé lors de l’accès à la propriété InvokeRequired. Cela entraine logiquement la modification de la fenêtre directement à partir du background thread, et l’exception est levée. Notez qu’effectuer la modification en appelant systématiquement la méthode Invoke n’arrange rien : cette dernière nécessite également que le handle du contrôle soit créé, et lèvera une autre InvalidOperationException si ce n’est pas le cas.

Le SynchronizationContext permet de régler ça. En fait, c’est une solution disponible à partir du framework 2.0 qui peut complètement remplacer le pattern if(InvokeRequired) Invoke(...), et qui gère les handles correctement. C’est ce qu’utilise le BackgroundWorker, pour info. Voilà ce que ça donne à l’utilisation :

public partial class MyForm : Form
{
    private readonly SynchronizationContext syncContext;

    public MyForm()
    {
        this.InitializeComponent();

        // Getting the synchronization context from the
        // form constructor
        this.syncContext = SynchronizationContext.Current;

        // New background thread started from the form constructor
        var thread = new Thread(this.DoSomething);
        thread.Start();

        Thread.Sleep(100);
    }

    public void DoSomething()
    {
        this.syncContext.Post(delegate
                              {
                                  Thread.Sleep(100);

                                  // Access to the control from the
                                  // synchronization context
                                  this.Text = "Yeah";

                              }, null);
    }
}

Lors de la construction de la fenêtre, avant tout, on récupère le contexte de synchronisation correspondant au thread courant, et on conserve sa référence. Dans le background thread (méthode DoSomething) on accède à la fenêtre via la méthode Post du SynchronizationContext. Et voilà.

Je vous laisse lire la documentation pour en apprendre plus, car il y a plus à apprendre. Je voulais surtout mettre en avant aujourd’hui le comportement éventuellement troublant de la propriété InvokeRequired, qui peut facilement faire perdre du temps dans ce scénario bien particulier.

Vous devez être nombreux à utiliser Subversion comme outil de contrôle de code source. Même si on entend parler de plus en plus des VCS distribués comme Git, Bazaar ou Mercurial, Subversion reste une excellente solution. C’est en tout cas celle que j’utilise quotidiennement depuis un moment. Si vous avez l’habitude d’intervenir au niveau de la gestion de configuration de vos projets, vous vous êtes probablement déjà posés tout un tas de questions relatives aux “bonnes pratiques svn”.

J’ai envie aujourd’hui de vous parler de l’une d’elles, concernant la propriété svn:externals, qui permet de créer des dépendances entre projets versionnés.

Au niveau de l’utilisation, c’est très simple. Je ne vais d’ailleurs pas m’étaler sur le sujet - ce n’est pas le but - mais je vous invite tout de même à jeter un coup d’oeil aux nouvelles fonctionnalités supportées par la version 1.5 de Subversion quant aux externals. Non, la question qui m’intéresse est précise :

Faut-il ou non spécifier systématiquement la révision vers laquelle pointe la référence externe ?

Mais ouais !

Si vous pensez le contraire, vous avez sans doute d’excellentes raisons (n’hésitez alors pas à m’en faire part), mais peut-être aussi avez-vous été abusés (comme moi) par les deux mythes suivants :

• Ne pas spécifier la révision d’une dépendance externe et toujours pointer sur la dernière, c’est plus pratique.
• Editer les externals pour mettre à jour les révisions tout le temps, c’est chiant.

Je pense que ce n’est pas exact.

Lorsque vous travaillez sur un projet et que vous utilisez la propriété svn:externals, vous matérialisez une dépendance de ce dernier vers un ou plusieurs autres projets tiers. Il se peut que vous soyez en charge de leur développement - c’est d’ailleurs fréquemment le cas - mais ils restent indépendants de votre projet. Cela signifie qu’ils sont susceptibles d’évoluer de leur côté ou bien d’être référencés et utilisés par d’autres projets dépendants. Si ce n’est pas le cas, remettez en cause leur existence.

Vous pouvez référencer les sources d’un projet indépendant via la propriété svn:external pour plusieurs raisons. Par exemple, pour débugger plus facilement, pour mieux comprendre comment la dépendance fonctionne, ou tout simplement parce que vous contribuez également sur le projet dont vous dépendez. Quoi qu’il en soit, à partir du moment où vous référencez un projet externe, gardez bien en tête que n’importe qui est susceptible de le faire évoluer sans même savoir qu’il est référencé par votre projet. Vous me répondrez qu’il est très improbable que cela arrive : vous savez précisément qui fait quoi dans votre équipe. OK, admettons ; après tout il s’agit d’une objection valide. Je doute cependant que le projet externe soit uniquement référencé par un seul projet. Si c’est le cas, il ne peut s’agir que d’une mauvaise idée ou d’une solution temporaire : vous anticipez des dépendances futures. Et s’il y a plusieurs projets qui affichent une dépendance vers un même projet externe, alors chaque évolution de ce dernier concerne tous les projets dépendants.

Surtout si vos projets dépendants référencent en permanence la dernière révision du projet dont ils dépendent.

C’est le comportement par défaut de la propriété svn:externals lorsque vous n’utilisez pas l’option -r pour spécifier vers quelle révision donnée pointe votre référence externe.

Pour revenir au premier mythe, celui de la facilité, il est vrai qu’avoir toutes les évolutions du projet externe poussées vers tous les projets dépendants (à chaque update de ces derniers) peut sembler pratique. “Au moins, on est sûr de profiter des dernières évolutions”. C’est déjà plus discutable lorsque les évolutions du projet externe impactent sa surface publique et nécessitent que certains projets dépendants soient adaptés, modifiés, corrigés.

Imaginons 4 projets : Project1, Project2, Project3, et Hourra. Imaginons que ces 4 projets dépendent d’un 5ème projet externe : SharedProject. Imaginons enfin que pour répondre à un besoin du projet Hourra, on fasse évoluer SharedProject en introduisant au passage un breaking change. La conséquence est aussi évidente que l’exemple est trivial :

Henri, qui doit faire un commit sur le Project2 (Henri ne travaille que sur ce projet, et ça lui convient bien) se fait avertir par Tortoise qu’il n’est pas à jour, et qu’il doit faire un update avant de publier ses modifications. Henri grogne un peu, son méchant manager (Brigitte) lui met la pression pour que le QA puisse récupérer via TeamCity une build de Project2 incluant son travail récent (la fenêtre About). Il met donc à jour sa copie locale, puis fait son commit. 2 minutes plus tard TeamCity notifie tout le monde d’une erreur de compilation sur la build de Project2. Le pauvre Henri vient de se manger le breaking change de SharedProject, et quoi qu’il fasse, il perdra du temps.

Je pourrais vous raconter l’histoire de Gustave sur Project1 et de Catherine sur Project3, mais je ne pense pas que cela soit nécessaire.

Pour s’éviter la peine de réfléchir, et de maintenir les références externes, on perturbe tout le processus de développement. L’exemple est grossier, mais je pense qu’il a le mérite de bien faire comprendre que la seule chose qui devient plus facile lorsqu’on référence la head revision d’un external, c’est de fragiliser le cycle de construction du projet. Cela peut ne pas arriver souvent, mais à chaque fois que cela arrive, le temps perdu et l’approximation des méthodes de résolution font regretter de ne pas avoir pris la peine de gérer finement la configuration.

Que nécessite le fait de spécifier la révision du projet externe dont on dépend ?

• Un peu de concentration : on doit savoir qu’on dépend d’une révision spécifique d’un projet.
• Un peu de discernement : on décide de faire dépendre son projet de la nouvelle version du projet externe.
• Un peu de talent Une minute pour éditer la propriété svn:external et mettre à jour la révision.

Il ne faut pas toujours penser que l’on peut tout simplifier. La gestion de configuration est une discipline délicate, caractérisée notamment par l’évolution exponentielle de sa complexité lorsque le nombre de projets augmente. Je parle dans mon exemple de 5 projets, mais on peut en imaginer plus, avec différents niveaux de dépendances, plusieurs branches, des versions déployées, taguées, etc.

Toute complexité n’est pas forcément compressible, et constater qu’on dispose d’une solution simple à un problème compliqué peut aussi bien faire penser que ladite solution est géniale ou carrément douteuse.

Quant à la pénibilité de la tâche consistant à mettre à jour une propriété svn, et bien, je ne sais pas trop quoi dire. Il me semble qu’il s’agit d’une chose évidente, et terriblement simple. Je veux dire : si vous êtes capable d’avoir un avis au sujet de la bonne utilisation de votre VCS, vous êtes évidemment en mesure de mettre à jour un argument d’une propriété svn sans souffrir.

A la rigueur, si vous devez gérer un certain nombre de projets ayant de multiples références externes, ou si vous désirez convaincre les différentes membres de votre équipe, vous pouvez passer quelques heures à réaliser un petit outil rendant le monitoring et la mise à jour des externals ridiculement simples.

Après tout, vous êtes des geeks, non ?

Evidemment, il est possible de ne jamais spécifier de révision dans la propriété svn:externals sans pour autant être un crétin ; ce n’est certainement pas ce que je dis. J’ai pendant très longtemps négligé l’option -r, et mes projets n’ont pas été compromis outre mesure à cause de ça. Je cherche juste à attirer l’attention sur le fait que cette pratique me semble être conceptuellement plus juste, plus sûre, et qu’elle n’est pas si contraignante qu’on le pense souvent au premier abord. Un soupçon de rigueur à ce niveau, même sur de petits projets, peut donner à votre gestion de configuration une stabilité et une solidité rassurantes.

Lorsque toutes les références externes d’un projet pointent sur les head revisions de chaque dépendance et qu’il est temps de tagger une version, ne trouvez-vous pas la tâche à la fois pénible et risquée ? Vous aurez d’un coup à fixer chaque dépendance externe vers une révision spécifique, ce qui est laborieux dès lors qu’il y a plusieurs niveaux de dépendances. Prendre l’habitude de fixer les révisions en permanence est selon moi une bonne chose, une sorte d’investissement rapidement rentable et encore une fois, pas vraiment coûteux.

J’ajouterai juste une remarque suite à un commentaire pertinent de Julien sur le groupe de discussion ALT.NET :

Par exemple, en mode agile avec de petites équipes et de l’intégration continu en place, ca passe très bien. Apres tout, le but de l’intégration continue est justement d’intégrer les dernières modifications et de detecter les breaking changes.

Effectivement, l’intégration continue permet de détecter les problèmes de ce genre, mais selon moi ce n’est pas suffisant. L’intégration continue ne permet pas d’éviter ce genre de problème. Dans mon histoire, Henri aurait préféré décider du moment où il allait devoir intégrer les breaking changes. C’est un peu comme lorsqu’on décide de migrer de Rhino.Mocks 2.x à Rhino.Mocks 3.x : il s’agit d’une tâche que l’on veut planifier, sur laquelle on veut avoir le contrôle. On choisit d’utiliser une version plus récente d’une dépendance externe, on évite de subir la mise à jour en la découvrant parfois au mauvais moment.

Lorsque je travaille sur un projet, et que je décide d’utiliser la dernière version d’une dépendance externe :

1. Je mets à jour la propriété svn:externals de ma copie de travail locale (avec mon super outil) pour qu’elle pointe vers la dernière révision de la dépendance.
2. Je fais un update pour récupérer les sources correspondant à cette dernière révision.
3. Je fais la migration (si besoin), toujours dans ma copie locale. Je m’assure que tout fonctionne avec la dernière révision de la dépendance externe.
4. Je fais un commit pour publier à la fois la propriété svn:externals mise à jour, et les éventuelles modifications nécessaires à l’intégration de la nouvelle version de la dépendance.
5. Si je suis responsable d’autres projets dépendants, je recommence le même processus.

Ainsi, tous les projets restent sains, et les équipes gardent une bonne maitrise de la gestion de configuration. Je n’arrive pas à voir quel pourrait être le réel avantage à fonctionner différemment.

J’ai terminé il y a quelques semaines la lecture d’un des seuls livres publiés au sujet du langage intermédiaire de la plateforme .NET. J’ai nommé CIL Programming, Under the hood of .NET de Jason Bock.

Je me suis appliqué, un parfait cover to cover, mais je le regrette un peu. Il ne doit pas être évident d’écrire un livre sur un sujet aussi chiant particulier, donc je ne peux raisonnablement pas être aussi acerbe que déçu. Car j’ai été assez déçu.

Si on ne s’attend pas à mourir de rire à chaque page lorsqu’on entame la lecture d’un livre du genre (avez-vous déjà essayé de faire une blague sur le CIL ?), on espère au moins en tirer quelque chose, ou plus exactement, quelque chose que l’on n’aurait pas pu - ou pas mieux pu - apprendre ailleurs. CIL Programming m’a donné l’impression d’être trop souvent approximatif à plusieurs niveaux : structure, rédaction, exemples, blagues (oui, Jason a essayé), références, etc. Pour être honnête, j’ai abordé cette lecture avec pour objectif d’acquérir une meilleure compréhension du langage intermédiaire de la plateforme .NET et plus particulièrement des possibilités offertes aux langages de plus haut niveau quant à sa génération/manipulation ; mais j’avais déjà une compréhension globale du langage ainsi qu’une expérience assez modeste de l’API System.Reflection.Emit.

C’est peut-être pour cette raison que j’ai été déçu. Quoi qu’il en soit, il serait dommage qu’en ayant une connaissance superficielle du sujet on en sache déjà trop pour trouver la lecture profitable. On parle bien d’un livre, hein, pas d’un article de blog ou d’un post dans le forum de codes-sources.com.

Le livre progresse doucement, trop doucement ; il frôle parfois le formalisme soporifique d’une spécification de langage sans pour autant parvenir au même niveau de complétude et de concision. Beaucoup de questions sont laissées en suspens malgré l’abus de références croisées (assez fatigantes), et cela conduit inévitablement le lecteur à se demander s’il n’a pas été trompé lorsqu’il arrive aux annexes.

Outre les chapitres qui listent les différents codes d’opérations du langage, vous pourriez éventuellement trouver un intérêt à lire en diagonale au moins les chapitres 5, 6 et 7 (cf. liste ci-dessous). Le chapitre 8, qui aurait pu être le plus intéressant pour les développeurs voulant générer dynamiquement du CIL est finalement compromis par la qualité de l’exemple lui-même (pourtant pertinent).

Pour le contenu, voici la liste des chapitres :

• Chapter 1: Language Interoperability
• Chapter 2: ILASM Directives and Attributes
• Chapter 3: CIL Opcodes
• Chapter 4: ILASM and CIL in Practice
• Chapter 5: Debugging CIL
• Chapter 6: .NET Languages and CIL
• Chapter 7: Emitting Types
• Chapter 8: Dynamic Proxies in .NET
• Chapter 9: CIL Tips
• Appendix A The Future of CIL
• Appendix B .NET

Au risque donc de paraitre déraisonnable, je vous déconseille assez franchement ce livre.

Je vous en avais parlé : la troisième rencontre ALT.NET Parisienne elle a eu lieu mercredi dernier, en (très) petit comité. Nous étions seulement trois : Robert Pickering, Mathias Kluba, et moi-même. La faute à l’été et aux congés ; il n’y avait pas de foot ce soir là.

Pas facile de dresser un bilan significatif dans ces conditions. Si je devais tenter je dirais que la soirée a été intéressante, et qu’elle nous a permis d’avoir une conversation diversifiée : choix des langages, Resharper, les différents frameworks ORM, les suites de composants Winforms, Spring.NET, OCaml, intéropérabilité, C# 3.0, l’inférence de type, F#, SharpDevelop, WPF, ALT.NET (oui oui), Entity Framework, Java, TFS, les missions de consulting, Emacs, Subversion, la politique d’ouverture de Microsoft, héritage vs composition, Codeplex, et j’en oublie pas mal.

Si on peut considérer qu’il s’agit d’un début modeste, c’est plus à cause du nombre restreint de participants que du manque de sujets. Du coup, j’ai assez hâte de voir ce que peuvent donner les rencontres de ce type lorsqu’elles regroupent plus de monde passionnés. Je suis heureux d’avoir fait la connaissance de Rob, et impatient de pouvoir rencontrer d’autres personnes aussi intéressantes avec qui échanger et de qui apprendre.

Je vous renouvelle donc mon invitation : n’hésitez pas à venir faire un tour à la prochaine rencontre, et n’hésitez pas non plus à faire passer le mot autour de vous. Il existe également un groupe de discussion auquel vous pouvez participer, et où vous trouverez en temps et en heure toutes les infos relatives à l’organisation des rencontres ALT.NET Parisiennes.

Les développeurs passent souvent du temps à configurer et personnaliser leur environnement de travail (système, outils, etc.). On peut même croire parfois qu’ils en font trop.

J’en fais sans doute trop, mais peu me chaut. Après tout c’est mon environnement de travail.

Aujourd’hui je vous donne un aperçu du thème que j’utilise dans Visual Studio. En fait je le rends même disponible en téléchargement, bien que je ne sache pas vraiment s’il s’agit d’un cadeau. Il est basé sur l’excellente font de Damien Guard : Envy Code R et c’est un grey background theme. Pour ceux qui codent en plein écran, c’est assez reposant.

Aperçu C#

Aperçu XML

Aperçu ASP.NET

Aperçu CSS

Aperçu SQL

Les screenshots ne rendent pas vraiment hommage au thème, je conseille donc aux plus courageux de l’essayer directement. C’est une tentative modeste conçue pour fonctionner avec Resharper sur des projets C#. Pas mal de petits trucs moches peuvent apparaitre si vous essayez autre chose.

Notez au passage que la font utilisée (Envy Code R VS.ttf) permet d’avoir de l’italique dans Visual Studio, ce qui est impossible par défaut. En effet, lors du paramétrage des polices et couleurs, Visual Studio permet uniquement l’utilisation du gras. La version d’Envy Code R sus-citée trompe Visual Studio en dessinant ses caractères en italique lorsqu’on les lui demande en gras. Il suffit donc de cocher la case bold dans Visual Studio pour utiliser l’italique, hourra.

Téléchargements :

1. Envy Code R (preview 7) de Damien Guard
2. Codingly Visual Studio Theme Beta 1

Commentaires, remarques et suggestions sont bienvenus.

David Laribee a laissé un message sur le groupe de discussion ALT.NET, indiquant que plusieurs personnes avaient travaillé à la rédaction d’une lettre ouverte à Microsoft, au sujet de sa solution ORM en devenir : Entity Framework.

Cette lettre, qui prend forme d’une pétition, a pour but d’attirer l’attention sur les principales faiblesses du framework. Il ne s’agit pas d’une condamnation, mais plutôt d’une synthèse argumentée qui tente de regrouper les critiques ayant mobilisé le plus de voix au cours des derniers mois.

Si vous pensez que les remarques sont pertinentes, et gagneraient à être considérées par le géant, alors vous pouvez laisser votre signature :

ADO.NET Entity Framework vote of no confidence

• Inordinate focus the data aspect of entities leads to degraded entity architectures
• Excess code needed to deal with lack of lazy loading
• Shared, canonical model contradicts software best practices
• Lack of persistence ignorance causes business logic to be harder to read, write, and modify, causing development and maintenance costs to increase at an exaggerated rate
• Excessive merge conflicts with source control in team environments

Toutefois, sachez que Microsoft est déjà à l’écoute, comme en atteste un post de Danny Simmons (de l’équipe ADO.NET). On y apprend qu’un concile consultatif aura lieu en Juillet pour faire le point sur les récentes productions de l’équipe Data Programmability chez Microsoft : Entity Framework, LINQ to SQL, ADO.NET Data Services, etc. Plusieurs personnalités de la communauté seront invitées (et consultées, donc), parmi lesquelles Martin Fowler, Eric Evans ou encore Jimmy Nilsson.

On peut donc douter de l’impact d’une telle pétition dans un ce contexte. Je trouve pour ma part qu’il s’agit d’un bon résumé, dont la lecture ne peut qu’être instructive.

Si vous avez l’habitude de lire les blogs nord-américains de la communauté .NET, vous avez très certainement déjà rencontré un post traitant du sujet, ou au moins y faisant allusion. Il est même probable que vous sachiez parfaitement en quoi consiste le mouvement ALT.NET. Si vous n’avez pas l’habitude de trainer sur ces blogs et que vous avez tout de même entendu parler de la communauté ALT.NET, c’est bon signe.

Malheureusement, cela fait de vous une exception. En France, ALT.NET reste globalement très méconnu.

Que signifie être ALT.NET ?

Il existe déjà de bons posts qui décrivent le mouvement, je pense donc pouvoir me contenter ici de paraphraser approximativement David Laribee qui est en quelque sorte l’initiateur du mouvement :

Que signifie être ALT.NET ? En quelques mots :

1. Vous êtes un développeur .NET qui a l’habitude d’utiliser ce qui fonctionne, mais qui garde un œil ouvert en permanence pour découvrir des moyens de faire mieux.
2. Vous êtes capable de regarder au delà des dogmes Microsoft pour vous inspirer du meilleur de chaque communauté : Open Source, Agile, Java, Ruby, etc.
3. Vous vous satisfaites rarement du statu quo. Les choses peuvent toujours être mieux exprimées, plus élégantes et simples, plus évolutives, de meilleure qualité, etc.
4. Vous reconnaissez les avantages et l’utilité des outils, mais vous savez que ce qui compte vraiment réside dans les principes et la connaissance. Les meilleurs outils sont ceux qui tirent partie de ce savoir, et qui encouragent la mise en œuvre des principes.

Je vous invite également à consulter les liens suivants, qui devraient vous permettre d’avoir une bonne idée de ce qu’est ce mouvement, et peut-être même de répondre à la question initiale :

• Post original de David Laribee
• Le site ALT.NET
• AltNetPedia, le wiki ALT.NET
• Présentation d’ALT.NET par Jeremy D.Miller sur MSDN Magazine
• Article de Martin Fowler au sujet de la première conférence ALT.NET
• Article de Laurent Capin

ALT.NET en pratique

Il faut bien comprendre qu’ALT.NET n’a pas pour but de créer des développeurs .NET d’un nouveau type.

Il s’agit simplement d’un tag qui permet de désigner l’ensemble des développeurs .NET qui n’embrassent pas sans discernement les outils, les préceptes et les modèles de développement provenant de Microsoft. Etre ALT.NET ne signifie pas être anti-Microsoft, mais plutôt être capable de prendre du recul et d’exploiter pleinement la plateforme .NET en ayant un regard critique et objectif sur les différentes solutions et méthodes qui proviennent ou non de Microsoft, qui proviennent ou non du monde .NET.

Un développeur ALT.NET est capable de choisir une solution alternative, si cette dernière est meilleure que la solution officielle. Et c’est justement parce qu’il est assez terrible de parler de solution officielle que la communauté ALT.NET cherche à se faire entendre, et à promouvoir par la même occasion un certain nombre de bonnes pratiques, de modèles et d’outils qui ne font pas forcément partie du courant Microsoft.

Un développeur revendiquant l’appartenance à la communauté ALT.NET est souvent un développeur :

• Qui ne se limite pas au Data Driven Design, et qui est familier avec l’OOP, les patterns, le Domain Driven Design, l’IoC, la SoC, etc.
• Qui a eu l’occasion de profiter de la puissance de certains outils et frameworks tiers comme Castle, NHibernate, Spring.NET, StructureMap, NUnit, RhinoMocks, Selenium, NDepend, Resharper, etc.
• Qui est habitué aux VCS et qui ne pourrait plus travailler sur un projet sans solution d’intégration continue.
• Qui est séduit par les méthodes agiles, qui comprend l’intérêt du TDD et du refactoring.
• Qui aime bien .NET

Ce ne sont que des exemples, évidemment, et la-liste-n’est-pas-exhaustive. En résumé, il s’agit d’un développeur ouvert, pragmatique et curieux, soucieux de développer des solutions de qualité le plus facilement possible. Vous pouvez correspondre à l’esprit ALT.NET sans même savoir qu’ALT.NET existe. D’ailleurs, bien avant que le mouvement ait un nom, de nombreuses communautés étaient déjà fidèles aux mêmes principes. Je pense notamment à celle de dotnetguru.org, littéralement tractée par plusieurs personnes de talent dont le discours et les initiatives ont toujours été très similaires à ceux des figures éminentes de la communauté ALT.NET actuelle.

Et le mouvement s’organise à Paris !

Suite à une initiative de Robert Pickering, déjà deux rencontres ALT.NET françaises ont eu lieu à Paris. La prochaine est déjà prévue :

Mercredi 2 Juillet, 20H00
Le Manoir
34, Boulevard Haussmann
75009 PARIS

J’essaierai d’y être, et je vous invite vraiment à en faire de même, ne serait-ce que par curiosité. Si vous ne pouvez vous déplacer, que vous êtes indisponible ce jour là ou que vous êtes encore un peu trop timide, il y a toujours le groupe de discussion Paris ALT.NET sur Google Groups qui vous permettra de rester informé et éventuellement d’échanger autour du sujet. N’hésitez pas non plus à suivre le blog de Julien qui soutient activement l’initiative.

Même si beaucoup ne jurent encore que par les datasets, sachez que la communauté .NET est en train d’évoluer, et que les valeurs portées par le mouvement ALT.NET commencent même à être reconnues par Microsoft. Tout le monde a quelque chose à y gagner…

Si certains d’entre vous trouvent pénible le fait de devoir s’assurer qu’un évènement est non null avant de le lancer, voici une idée :

Profitez de la contravariance sur les delegates et initialisez votre event de la sorte :

public event MyEventHandler MyEvent = delegate{};

Ca vous permettra d’être sûr qu’il y a au moins un handler lorsque vous voudrez déclencher MyEvent, et vous n’aurez donc plus besoin d’écrire par exemple :

if(MyEvent != null)
{
    MyEvent(this, new MyEventHandler(someParam));
}

Vous pourrez directement lancer l’événement sans tester :

MyEvent(this, new MyEventHandler(someParam));

Notez que le handler (inutile) ajouté via le variable initializer à l’event ne pourra plus être retiré, ce qui peut ici être vu comme une sécurité. Cependant, l’avantage de cette astuce est à relativiser :

• Il y a un coût (négligeable la plupart du temps) au niveau des performances.
• Il est parfois plus judicieux d’écrire une méthode chargée d’encapsuler le test de non nullité, et qui pourra souvent être invoquée plus simplement que l’événement lui-même.

Par exemple :

private void FirePropertyChanged(string propertyName)
{
    if (PropertyChanged != null)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

A l’appel, on se retrouve avec :

FirePropertyChanged("Firstname");

Contre :

PropertyChanged(this, new PropertyChangedEventArgs("Firstname"));

Source : C# in Depth: What you need to master C# 2 and 3, de Jon Skeet.

UPS est passé vendredi matin pour livrer deux gros cartons chez moi. L’un contenant mon nouveau PC monté, l’autre avec toutes les boites des composants ainsi que les pièces et accessoires non utilisés. Pour info, j’avais passé commande online samedi matin. Cela signifie qu’en moins de 5 jours, ma commande a été préparée, montée, et livrée. Je pense que la performance est saluable : merci materiel.net.

Je vais essayer de vous livrer mes premières impressions, à tiède.

Les petits gars de materiel.net

Non, mon fils ne travaille pas chez materiel.net, et non, je n’ai pas d’actions dans la boite. J’ai juste envie de partager ma satisfaction. Car non seulement les petits gars de materiel.net vont vite, mais ils font également du bon travail. Je vous avais parlé de l’option montage. Au final :

• Un message collé sur le boitier indique qu’en raison de sa taille et de ses 770 gr, le ventirad CPU a été retiré pour le transport, et qu’il faut donc le remettre en place avant de démarrer la machine. De toute façon, et c’est précisé aussi, le boitier est bourré de papier à bulles. Notez bien que le support du ventirad est déjà en place, il ne reste donc plus qu’à ajouter une pointe de pâte thermique, et fixer le radiateur à l’aide de deux vis.
• Les différents câbles sont tous regroupés et fixés, ils passent tous au bon endroit. L’intérieur du boitier est plus clean que ce que j’imaginais possible. L’alimentation modulaire y est sans doute pour quelque chose.
• Comme je l’avais demandé, le ventirad original de la carte graphique a été remplacé par le Zalman VF 1000LED. Là encore, c’est niquel, le fan mate a été ajouté et intelligemment fixé au boitier de façon à être directement accessible.



• Les disques durs sont bien rangés dans leur compartiment, et encore une fois les cables SATA et d’alimentation se font oublier.
• Le bios de la carte mère a été mis à jour.
• Les deux disques de 250 Go ont bien été configurés en RAID 0.
• Durant le montage du PC, on m’a averti que les barrettes de mémoire choisies étaient défectueuses, et qu’il s’agissait des dernières disponibles. En 3 mails échangés et 20 min, le problème a été réglé : j’ai choisi un autre kit G.Skill, un avoir correspondant au prix de l’ancien a été généré puis directement utilisé pour financer le nouveau. J’ai pu suivre tout ça en direct depuis mon compte utilisateur.
• Absolument toutes les boites, tous les CD, toutes les pièces, tous les accessoires non utilisés sont envoyés. Ca parait normal, mais il est tout de même bon de le signaler.

Bref, pour 30 euros :

• J’ai gagné une demie-journée de bricolage.
• J’ai évité un aller-retour SAV pour mes barrettes mémoire.
• Ma configuration a été mieux monté que si je m’en été occupé moi même, aussi perfectionniste et méticuleux que je puisse être.
• La configuration a été réellement testée, et pré-configurée.

Je vous conseille donc la prestation.

Il y a juste un truc chiant (et facultatif) : le décollage de l’autocollant “materiel.net” sur la façade du P182. C’est ce qui m’a pris le plus de temps.

Le silence

Peut-être vous en souvenez-vous, je cherchais à avoir une configuration silencieuse. D’où l’alimentation de luxe, le boitier Antec, et les deux ventirads d’overclocker. Ca pèse sur le budget, donc il est assez légitime d’avoir une certaine appréhension lorsqu’on fait booter la machine pour la première fois.

Personne ne veut d’un aspirateur à 1500 €. (Ni même à 500€)

Lorsqu’on cherche à construire une configuration silencieuse, il faut commencer par choisir un boitier digne de ce nom, et non pas une pauvre boite en tôle mal isolée. Ensuite, il faut trouver une alimentation discrète, qui ne se prendra pas pour un réacteur dès qu’on lui demandera de sortir plus de 200 Watts. Quant au reste, tout est lié aux ventilateurs. Les systèmes de refroidissement fanless pour les cartes graphiques et les processeurs sont souvent peu efficaces, et parfois inexistants.

J’ai donc choisi un gros ventirad pour remplacer celui fourni par Intel avec le CPU, et un autre gros ventirad pour remplacer celui de la GeForce. L’idée était de pouvoir profiter du meilleur pouvoir dissipateur de ces radiateurs pour réduire sans risque la vitesse de rotations de leurs ventilateurs.

Et ça fonctionne plutôt bien.

Je n’ai pas eu besoin de réguler la vitesse du Noctua, il est quasiment inaudible à 1300 tr/min. J’ai configuré le ventilateur de la carte graphique pour qu’il tourne au minimum, ce qui est largement suffisant. Et on obtient un PC silencieux. Certes, il n’est pas complètement silencieux (ce n’est pas un iMac), mais il se fait oublier sans problème même lorsque l’environnement est calme. Notez que les ventilateurs 120 mm fournis avec le P182 (il y en a 3) sont assez bruyants, et qu’en attendant de les remplacer, je les fais tourner au minimum.

Avec ces réglages, les températures sont les suivantes, en moyenne :

• CPU (Idle) = 41°C
• CPU (100%) = 55°C
• GPU (Idle) = 42°C
• GPU (100%) = 60°C
• Carte mère = 36°C

Les performances

Peut-être vous en souvenez-vous, je cherchais à avoir une configuration performante. D’où le Q9300, la DDR3 1600Mhz, la 8800 GT et les Barracuda ES.2 en RAID 0. Là, j’avais déjà moins d’appréhension. Généralement, on peut assez facilement deviner quelle sera la puissance d’un PC en fonction des quatre composants suivants :

• Processeur
• Mémoire
• Carte Graphique
• Disque dur

On est souvent tenté de faire des compromis quelque part. Jusqu’à présent, j’avoue que je faisais surtout attention au processeur et à la carte graphique en privilégiant pour le reste la quantité à la qualité. Hop, 2 barrettes Samsung pas trop chères, et un bon gros disque 7200 tr/min milieu de gamme.

C’est mal. Les performances d’un disque dur, qu’elles soient bonnes ou médiocres, vont vraiment influencer celles de la configuration complète. Vous vous en rendrez surtout compte si vous êtes un développeur. De même, choisir 2Go de mémoire de marque, c’est très souvent bien mieux que d’acheter 4 Go de noname.

Enfin… Je ne vais pas m’improviser Guru Hardware. Je laisse quelques indicateurs conclure le post :

• Vista note donc ma configuration 5.9
• Il me faut 19 secondes pour faire un rebuild all sur la solution contenant les 60 (soixante) projets de SharpDevelop.
• 19 secondes, c’est également le temps qu’il me faut pour extraire d’une archive rar un fichier unique d’1.4 Go
• Unreal Tournament 3, en 1280*1024, détails au maximum : +60 fps garanties.
• Crysis, même résolution, very high = 20/25 fps, high = 40/45 fps.
• La première ouverture de Visual Studio 2005 ou 2008 prend une ou deux secondes. Les ouvertures suivantes sont quasi-instantanées.

Dernièrement, je vous expliquais que je devais absolument changer mon PC, et que j’avais sérieusement envisagé de commander un Dell XPS. Ca me semblait être une idée honnête puisqu’à l’époque je voulais éviter de perdre du temps à choisir mes pièces et à monter un DIY PC.

Mais j’ai été piégé. Heureusement.

Je pensais ne plus être l’étudiant geek qui bricole son PC. J’avais raison. Je pensais que je pouvais faire confiance à un constructeur et sélectionner une configuration toute faite sans me prendre la tête. J’avais tort.

Il faut dire que chez Dell - ce n’est pas le cas de tous les constructeurs - on peut déjà pseudo-configurer la machine qui nous intéresse avant de la commander. Du coup, on se prend un peu au jeu. On commence à comparer le prix des pièces, à étudier les différentes configurations RAID, à regarder les reviews sur le net pour savoir ce que vaut la GeForce FX 9900 GTS Utra 2 SilentMax de Teksys, et on finit par penser que les options du configurateur qui nous donnaient une bonne impression de maitrise constituent en fait une sacrée limitation. Le composant qu’il vous faut, le composant, Dell ne le propose pas. Pire, pour certaines pièces maitresses de la configuration, non seulement vous n’avez aucun contrôle, mais en plus la visibilité dont vous disposez et relativement restreinte :

Alimentation
375 W (standard), 425 W (avec carte graphique nVidia GeForce 8800GTX)

Ce que vous saviez avant, vous vous en souvenez d’un coup : pour un budget de 55000 roubles, le meilleur PC que vous puissiez avoir est celui que vous concevez pièce par pièce. Et vous oubliez le Dell XPS et sa DDR2 à 600 Mhz.

J’ai donc passé commande sur materiel.net de toutes les pièces nécessaires à la construction de mon Ultimate Developer Rig. Puisque je ne suis plus l’étudiant geek qui bricole son PC j’ai aussi choisi l’option montage : si quelqu’un détruit ma 8800 GT en y fixant un nouveau ventirad, autant que ce ne soit pas moi.

Je détaillerai mes choix dans un prochain post, et si UPS est passé d’ici là, j’en profiterai pour faire un petit point au niveau des performances, du silence, etc.

En attendant, voici les caractéristiques de la machine :

	Boitier : Antec P182 Noir
	Alimentation : Corsair HX 620 W
	Carte mère : Asus P5E3 Deluxe/WiFi-AP@n
	Processeur : Intel Core 2 Quad Q9300
	Radiateur CPU : Noctua NH-U12P
	Mémoire : G.Skill DDR3 2 x 1 Go PC12800 (1600Mhz)
	Carte graphique : GeForce 8800 GT Gigabyte GV-NX88T512HP
	Ventirad GPU : Zalman VF1000-LED
	Disques système : 2x Seagate Barracuda ES.2 S-ATA - 250 Go - 32 Mo ( en RAID 0)
	Disque données : Seagate Barracuda 7200.11 S-ATA - 500 Go - 32 Mo