Sébastien Andreo

Je profite de ce jour férié en Allemagne (et aussi en Alsace ) pour vous annoncer avant David Pujadas ou PPDA que oui aujourd'hui c'est le printemps!

Comme d'ailleurs en témoignent ces photos ...

Et les prévisions des jours à venir sont sympas aussi (les connaisseurs appréciereont l'information "gefühlt wie:")

Two weeks ago, I released the library ExecOptions.Net on CodePlex.

ExecOptions.Net is a library providing an easy handling of console application arguments.

Every developer will have to deal a day or an other with Console arguments, like checking a file existence, some string patterns matching (I hope that there is not only GUI developers ).
And because writing such a code it is really boring I developed this library.

Currently there is a minimal set of features:

• Defining an options as mandatory or optional
• Checking file existence
• Validating an XML file against its XML schema
• Defining regular expression matching

A cool feature is the possibility to define your options as .Net attributes (like Mono.Options.dll ). The code should be something like that

[OptionDelimiter('-')]
internal class TestOption
{
    private bool m_Usage;
    [Option("h",
            OptionCategory.Optional,
            "print program usage"
            OptionType.Usage)]
    public bool Usage
    {
        get { return m_Usage; }
        set { m_Usage = value; }
    }
    private bool m_Verbose;
    [Option("v",
            OptionCategory.Optional,
            OptionType.Empty,
            "activate verbose mode")]
    public bool Verbose
    {
        get { return m_Verbose; }
        set { m_Verbose = value; }
    }
    private String m_XmlFile;
    [Option("input",
            OptionCategory.Optional,
            OptionType.Xml,
            "input file",
            "..\..\test.u\schema.xsd")]
    public String XmlFile
    {
        get { return m_XmlFile; }
        set { m_XmlFile = value; }
    }
    private String m_RegEx;
    [Option("pattern",
            OptionCategory.Mandatoy,
            OptionType.RegEx,
            "regular ex", "[a-z]{0,}")]
    public String RegEx
    {
        get { return m_RegEx; }
        set { m_RegEx = value; }
    }
}

Your application Main will be really simple.

class Program
{
    [STAThread]
    static int Main(string[] args)
    {
        OptionManager mgr = new OptionManager();
        TestOption opt = new TestOption();
        mgr.ProcessArgs<TestOption>(args, opt);
        if(opt.Usage)
        {
            Console.WriteLine(mgr.Usage());
            return 0;
        }
        /* Your Business Code */
    }
}

I hope that such a library can help you.

Feedbacks ,bugs or features are welcomed !

Voilà une conférence qui pourra intéresser nos spécialistes de l'AOP ici.

I did not have the chance to take part in the last European TechEd But I found some really funny videos about agile process, continuous integration… Thanks to Roy Osherove !
And this is the other one : Deep Reflection (Always Roy)

@Sami: for the DNG symposium will you also prepare some songs ?

Juste un lien sur le blog d'un collegue, Alois qui se propose de présenter la problématique de la gestion des shutdowns d'application.

All good things have to end even your perfectly working managed executable. But do you know in what circumstances the CLR will terminate your program and much more importantly when do you have a chance to run some finalizers and shutdown code? As always in live it depends. Lets have a look at the reasons why program execution can be terminated.

Pour continuer dans les desktops qui bougent voila une petite video bien agreable ici

Il y a quelques semaines de cela j'ai fait tourner Reshaper 2.0 sur mon code afin de supprimer les namespaces non utilisés, variables initialisées inutilement et autres petites choses, résultant de refactorings successifs sans cleanup.

Tout se passe pour le mieux jusqu'à ce que mon collègue qui développe une partie de l'assembly me dit : "Ton outil c'est très bien mais il a changé la sémantique de ma fonction..."

En effet Resharper avait changé ce type de code:

public enum BufferType
{
    Stream,
    Buffer,
    Undefined
}
public void Read(out int length , out BufferType type)
{
    length = 0;
    type = BufferType.Undefined;
    Byte[] buff = new Byte[256];
    length = this.DoSomething();
    if(...)
       type = BufferType.Stream;
    else
        type = BufferType.Buffer;
}

en

public void Read(out int length , out BufferType type)
{
    Byte[] buff = new Byte[256];
    length = this.DoSomething();
    if(...)
       type = BufferType.Stream;
    else
        type = BufferType.Buffer;
}

Et oui resharper avait supprimé les 2 affectations en début de méthode. Et là commenca une longue et âpre discussion....

Son argumentation était basée sur le fait que l'utilisation du keyword out obligeait de fournir une valeur de retour correcte dans tous les cas. Donc pour le garantir ca il fallait qu'il initialise ces 2 paramètres dès le début de la méthode. Ceci n'est effectivement pas tout à fait faux.

Mais le compilateur C# vérifie que toutes les branches de code de la méthode vont garantir l'affectations des variables out, donc à priori pas besoin d'affecter d'entrée celles-ci.

Et là tombe l'argument massue! Et oui mais en cas d'erreur, plus précisement la méthode DoSomething lève une exception.... Si tu n'as pas affecté tes variables en début de méthode et bien au sortir tes variables ne le seront pas... Je suis resté dubitatif

Comment peut on imaginer initialiser des variables (toutes out quelles soient) lorsqu'une erreur se produit. Lorsqu'une exception est levée (et qu'elle ne peut pas être traitée dans la méthode) c'est forcément une rupture de contrat. Vouloir transporter des informations grâce aux parametres out pour traiter l'erreur est forcément en opposition avec les bonnes pratiques de gestion d'erreur

Donc pour résumer on laisse le compilo faire son travail et en cas d'erreur c'est à l'appelant de traiter l'erreur et donc d'initialiser les valeurs comme son context le lui indique.

D'autres avis sur la question?

Alors oui je vais vous parler de la road map de Visual Studio. Mais pas en termes de functionalités révolutionaires ou d'intégrations, mais en terme de Codename ou nom de code. Je vois déjà comme un scepticisme grandir en vous ....

Si on fait un bref historique des noms de code de VS:
en 2002 Everett
en 2005 Whidbey
en 2007-8 Orcas
en 2009-10 je le connais pas encore mais ca serait drôle de le découvrir!

Qui s'est déjà posé la question : Mais d'où viennent ces noms ? A mon avis personne mis à part moi.

En fait la réponse est à chercher avec notre outil de cartographie préféré.
Et voila comment commence l'enquête : Situons d'abord notre acteur VS ou plutôt Microsoft



Rien de bien neuf sous le soleil, les US, Redmond, microsoft. Zoomons un peu pour voir un peu plus au nord



Et oui Everett est une ville de l'état de washington, et si on continu comme ca en allant cette fois ci au nord ouest on découvre Whidbey island



Et enfin Orcas Island



alors quel sera le prochain nom de code de visual studio?
Mayne, Galiano, Thetis, Valdes

et la version ultime ? ne serait ce pas Attu ? (ou avec la prononciation allemande "a tout")

Donc bilan, avec visual studio tu codes plus vite en plus tu apprends la géographie

Salut

Je me suis enfin décidé à plonger dans la blogosphère. Je tiens à remercier Sami et Seb Ros de m'héberger sur DNG !

Pour me présenter brièvement,
Je travaille en Allemagne (certains diront: "il est fou !") pour Siemens Medical Solutions, plus particulièrement sur la couche résau DICOM. Si sur DNG on a notre umlguru , il y a également le dicomguru David Clunie .

J'ai déjà eu l'occassion de publier quelques petits articles sur DNG,
Managed C++
Gestion des erreurs sur la plateforme .NET

Je vais essayer de poster régulièrement en fait sur une multitude de sujets: comme l'AOP, les process de developpement, la modelisation, un peu d'architecture, quelques tools, mon humeur du jour ... Oui Seb il y aura surement quelque chose sur les outils Exxx

@+
Seb