For a couple of months two german guys, Ralf Westphal and Stefan Lieser lanched a great  initiative called CCD for Clean Code Developer. They try to answer a quite simple question :

What makes a professional software developer?

Is it  someone who earn money with software ? Somenone who have a  diploma, Phd in computer science ... ? I guess you will not be surprised that it is not what they have in mind  !

Professionalism = Consciousness + principles

The starting point  is the book of Bob C. Martin Clean Code (a must read).  They extract from it principles and try to build a system of values. This System is made of rules, principles and best practices and is  in the form of successive  degrees like in martial art (but in the other way round). Black to white, from the dark side to the light side of the force.

I really think that this initiative goes in the right direction in term of education and some how it is another step in the direction "software development will become an industry".

I do not know if someone tries inside a team to work with those armbands. It can be a source of motivation to learn more or it can be seen as a rank :  bad developer and good developer...

PS : For the not german readers the Google translation bar works quite well ;o)

For one and half years, we have started experimenting NDepend in our daily work at siemens healthcare and now we can see the benefits of using it in terms of:

• avoiding breaking the build,
• Impact estimation,
• Software quality.

The choice of NDepend came after one team developing a basic layer in the system did some behaviors and API changes without controlling correctly the impact. "No one is using this" or "just one line changed" ... The result was a real tsunami the system was not usable and not deliverable during 3-4 weeks!

How did we avoid that such scenarios will come again?

The idea is quite simple before submitting his public changes the developer shall

• Check for the impact, answering the simple question: who is using me?
• Inform the affected component responsible
• Agree with them in which build the change will be submitted
• Collect the modifications and run the affected smoke tests
• Submit the overall changes into the main build

You can say it is too much. For sure for a team of 3-4 people it is overkill but for more than 100 developers dispatched all over the world it can help them to always deliver a running system.

To allow the developer to check the dependencies, we generate the NDepend repository in our main build. I can remember with the first version (2.6) we used to use a 3.2GHz 64bit 8GB RAM machine and the overall generation took about 25 min from a Clear Case virtual file system (a classical file system it was about 10-12 min). The performances increase continuously and with the latest NDepend version 2.11.2, I can generate all the project on my 2GHz 32bit 3.2GB RAM laptop in less than 6 min always from a clear case virtual file system. This increase of performance opens new perspectives for the developer, he can always work with the latest repository, because he just has to generate it locally. And let imagine while coding that NDepend informs you in real time about the impact 88|

Back to the reality of finding the code impacted by a change. It is a kid's stuff with CQL. With the following queries you will be able to avoid breaking compilation in your main build:

SELECT TYPES WHERE IsDirectlyUsing "YourType"


SELECT TYPES WHERE DeriveFrom "YourType"


SELECT TYPES WHERE Implement "YourInterface"


CQL also allows you to query on Assemblies, Methods and Properties level but from my experience the TYPE level is a good compromise. Assemblies are a little bit too macroscopic and Methods/Properties is too microscopic (sometimes). Now we are able to find all code affected by a change to avoid compilation errors. But is it enough? I guess not, we have to provide a running system! Compilation is unfortunately not enough to declare a system running... It is also important to run some tests ;D.
When you work on big code base you are always facing to the test execution timing issue. It is not always possible to run all test cases after each change. We have to find a way to execute only the most relevant test cases corresponding to the change.
I propose to execute the following query:

SELECT ASSEMBLIES WHERE IsUsing "YourType" AND !IsDirectlyUsing "YourType"

You will find only the indirect dependency. That means those assemblies will not be affected at compilation time but potentially at runtime with a behavior change. Running the smoke tests of the found assemblies/components, you will be more confident of delivering a running system.

Impact Estimation & Quality

NDepend also helps us to estimate our back log items during the iteration planning. When you plan or you have experiment some refactoring it can help you to see the real impact on the whole product using the build comparison feature it is really easy (more info).

We are also using the different metrics provided by NDepend in our in-house metric framework to qualify each sub-system.

This is just a sub-set of the capabilities offered by NDepend and CQL! They can really more. Thereby to the NDepend Team keep up the good work!

PS: I am a little bit late for the Santa claus order but perhaps with the time difference between Erlangen and Nice it can be possible to obtain :)):

• Plug-in mechanism for Runtime dependency check (private, spring.Net, …)
• Multi language support (Java seems to be on track with www.xdepend.com)
• CQL complex Query support (multi select in one query)
• In the visualNDepend class browser the possibility to apply some filter, (a CQL filter perhaps). If you have a lot of assemblies you can easily find the targeted one without scrolling through the whole list.
• Plug-in mechanism for the NDepend project. You are currently supporting VisualStudio but what’s about MonoDevelop, SharpDevelop eclipse or others…

Je viens de recevoir (bon il y a quelques mois déjà :roll:) mon nouveau Laptop préinstallé avec Vista.
Il m'arrive parfois d'ouvrir une command shell! Et ce fut assez rigolo de voir que pour accèder à un fichier dans le répertoire c:\Benutzer\Seb

Et bien en fait il faut utiliser ce chemin d'accès

Alors non je suppose que ce n'est pas un bug c'est une Feature :>> (J'ai déjà entendu cette justification quelque part.... :crazy:)

Alors en attendant l'année prochaine einen Guten Rutsch !

Je profite de ce jour férié en Allemagne (et aussi en Alsace :crazy:) 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 88|

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 :roll: ... Oui Seb il y aura surement quelque chose sur les outils Exxx :))

@+
Seb