Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Fathi Bellahcene

.Net m'a tuer!

Premiers pas avec AkkaDotNet

Akka.net est un framework qui vous permettra de faire des programmes distribués et scalable assez simplement en se basant sur le pattern “Actors Model”.

c’est également un portage de la librairie Akka assez connu des développeurs java et surtout Clojure.

Nous vous proposons donc de vous faire une petite présentation de ce sympatique framework à cet endroit.

Mobile Day : c’est le 25 et c’est chez Microsoft!

Le mobile est devenu un marché incontournable, celui ci est également plus complexe à adresser:

  • plusieurs plateformes (IOS, Android et WP)
  • plusieurs types de devices (montre connecté, smartphone, tablette,..)
  • les ergonomies sont spécialises par plateforme et format de devices
  • les utilisateurs sont de plus en plus exigeant

une fois que l’on a dit cela, on se rend compte que faire du mobile est beaucoup plus complexe que les bonnes vielles applications web ou client lourd des années 2000!

Nous vous proposons donc de vous présenter lors d’une journée quelles sont les solutions existantes pour faire du mobile, quand les utiliser et comment utiliser les outils proposé par Microsoft pour les développer.

Pour plus de détail et pour vous inscrire, c’est ici:

http://www.cellenza.com/mobileday

Qualité de code & Indentation

Depuis quelques temps, j’ai entrepris l’écriture de quelques blog-posts autour de la qualité du code en programmation orienté objet. C’est dans cette esprit que j’en ai écris un nouveau qui parle de l’indentation du code; l’idée était de montrer qu’au dela de la lisibilité, la forme que prend votre code indenté vous permet d’identifier quelques défaut dans vos programme…

 

c’est ici que ca se passe!

[Clean Code] les commentaires…

Je viens de publier sur le blog de ma société un nouveau blog post liée à la qualité du code et qui parle des commentaires. Je tente de catégoriser les différents types de commentaires existants (les bons, les brutes et les truands) et de donner mon humble avis sur le sujet.

Vous trouverez cela ici

[Clean Code] règles de nommage

sur le blog de Cellenza, j’ai initié une série de billet autour du thème Clean Code : écrire du code pour les humains.

Dans ce premier billet, je précise mes objectifs: clean code c’est d’abord du bon sens et du professionnalisme avant d’être une question de skills. Et ensuite; je l’attaque à un sujet extrêmement simple qui est la manière dont on nomme nos variables: chose extrêmement simple et qui a un impact important sur la lisibilité de notre code et donc de sa maintenance.

 

la suite se trouve ici, bonne lecture!

BDD/TDD + Javascript

Vous faites du Javascripts et vous voulez faire du TDD/BDD mais vous ne savez pas comment vous y prendre? venez nous rejoindre dans nos locaux le 27 novembre pour découvrir comment vous y prendre!

le programme complet est disponible ici mais l’idée est de présenter les deux pratques de dev que sont le TDD et le BDD qui commencent à devenir des standards pour la POO et qui pointent leurs nez pour le dev Javascript. Nous verrons donc:

  • un rapide rappel de ce qu’est le [T/B]DD et pourquoi en faire
  • un workshop TDD
  • un workshop BDD

Nous vous présenterons également l’outillage nécessaire pour tout faire fonctionner proprement.

Nous organisons cet event avec nos amis de Xebia et bien sûr, le buffet sera de la partie à la fin!

 

pour les inscriptions, cela se passe ici

Bien évidement, cet évènement s’adresse à tous les dev web/mobile qui souhaitent faire du javascript proprement.

Xamarin : From Zero to Hero

Hello,

le jeudi 02 octobre nous organisons une présentation publique de Xamarin dans les locaux de ma société Cellenza.

 

Si vous êtes intéressé par le dev mobile, la technologie Xamarin, n’hésitez pas et venez nous rejoindre pour voir à quoi ca ressemble!

PS: il y aura comme d’habitude, a boire et à manger.

Pour les inscriptions, c’est par ici.

 

A jeudi!

TypeMock: mock everything!

Tester du code Legacy

Il y a quelques temps, j’ai initié une série de blog post sur un sujet toujours d’actualité : comment tester unitairement une application Legacy quand les techniques de bases ne sont plus suffisantes.

Le problème qui se pose était le suivant :

  1. j’ai besoin d’un code testable pour faire du TDD et donc le modifier de manière safe.
  2. mon code Legacy n’est pas testable et je ne peux donc pas le modifier sans prendre de risque.

Bref, on boucle et on est bloqué (le fameux serpent qui se mord la queue).

L’idée était donc de casser cette boucle en utilisant un outil assez puissant pour intégrer un filet de sécurité (harnet tests) sans faire la moindre modification pour ensuite remettre le code dans un état propre.

Les étapes sont donc les suivantes :

  1. introduire des tests et couvrir le SUT (system Under Test) sans le modifier pour ne pas faire de régression
  2. modifier le code pour le rendre plus propre
  3. introduire des tests s’appuyant sur des tests doubles classiques (fake, mock, stub,…)
  4. supprimer les premiers tests

J’ai tenté de démontrer cette méthode en utilisant l’outil proposé par Microsoft, le Fakes framework et au final je dois dire que je reste assez mitigé : l’approche choisie par MS de générer des proxies qui ont des noms de type « FakesXXX » ou « ShimXXX » est pénible car elle nous empêche d’utiliser des outils de refactoring lorsque l’on souhaite renommer une méthode ou une classe et nous force à régénérer toutes nos « fakes assemblies »…

Donc, l’approche est pas mal mais l’outil présente des défauts qui le rendent difficilement utilisable dans un « vrai projet ».

TypeMock

J’ai eu l’occasion de tester TypeMock ces derniers jours et je dois dire que j’ai été agréablement surpris ! Il permet de faire quasiment les mêmes choses et même plus tout en gommant les éléments qui me gênaient avec le FakesFramework !

TypeMock Isolator (dans sa version essential…qui n’est pas gratuite…) comme le fakeFramework va vous permettre de faire de la redirection d’appel au runtime (runtime interception) : en gros, si vous appeler une méthode ou instancier une classe, il va vous permettre de rediriger l’appel vers du code spécifique à votre tests. Cela signifie donc : plus besoin d’avoir du code découplé pour les tests…car on est en mesure de quasiment tout rediriger et donc de tout isoler !

A première vue, cela parait cool mais c’est très dangereux car l’objectif du TDD est aussi d’aboutir à un design de qualité. Utiliser TypeMock nous permet d’avoir du code crade et testé…c’est pourquoi je recommande vivement de supprimer tous les « super » mock à la fin du cycle décris ci-dessus.

Quelques exemples ici :

Vous avez des singletons (le diable du test unitaire):

clip_image001

Dans votre SUT, vous instancier un objet :

J’ai une méthode à tester et elle instancie un objet à l’intérieure de celle-ci :

clip_image003

On fait appel à des objets/méthodes du framework .net…comme la classe ConfigurationManager :

clip_image005

Et vous pouvez en faire encore plus (je vous invite au passage d’aller regarder la doc officielle)!

Pour finir, c’est un excellent outil (payant) pour des cas extrême et à mettre uniquement entre les mains de personnes ayant une bonne pratique du TDD et qui souhaitent s’attaquer à la problématique d’intégrer des tests sur du code Legacy bien crado.

Mes vidéos autour des nouveautés VS 2013

Juste un post pour vous informer qu’avec mon acolyte (alcoolique également) Michel, nous avons publié quelques vidéos pour le compte de Microsoft et Cellenza.

Vous retrouverez nos vidéos ici:

Visual Studio 2013 : Code Map

https://www.youtube.com/watch?v=8whQoLVcFMw

Visual Studio 2013 : CodeLens

https://www.youtube.com/watch?v=g4SuPIIBB6o

Intégration de Git dans TFS 2013

https://www.youtube.com/watch?v=0zIAJj3JSRo

 

Vous pourrez également trouver celles de mes petits camarades (Guillaume et Pierre Henri ) de Cellenza ici:

Visual Studio 2013 : Team Room

https://www.youtube.com/watch?v=jE2Jed8iP9w

Visual Studio 2013 : Portfolio Agile

https://www.youtube.com/watch?v=T_SLr5WmXtw

[Event] Hands-on TypeScript avec David Catuhe chez Cellenza!!!

 

Avec nos amis de Xebia (des devs perdu java) et mon acolyte de toujours Michel Perfetti, nous organisons dans nos locaux un Hands-on sur le langage TypeScript (le challenger du Javascript poussé par Microsoft).

Cet évènement aura lieu le 15 mai à 19 heures et nous aurons la chance d’avoir un invité de choix en la personne de David Catuhe (Senior Programm Manager en charge des technologies Web à Microsoft Corp) en live depuis Redmond!

Il nous parlera de la migration de BabylonJs de javaScript vers TypeScript

Plus d’infos ici:

http://blog.cellenza.com/evenements/hands-on-typescript/

Venez donc nous rejoindre en vous inscrivant ici:

https://www.eventbrite.fr/e/billets-hands-on-typescript-11412939409

NFluent & Data Annotations : coder ses propres assertions

Nfluent fait beaucoup de choses…mais pas tout: il ne codera jamais à votre place, ne fera pas le café…mais on peut l’aider à faire des “Assert” custom pour rendre encore plus lisible nos tests unitaires.

Je vous propose donc de voir comment customiser NFluent pour valider des objet qui utilisent les attributs de validations se trouvant dans le namespace System.ComponentModel.DataAnnotations.

DataAnnotations, c’est quoi?

c’est un ensemble d’attribut permettant de spécifier des contraintes sur les propriétés d’une classe.

Par exemple, pour les classes suivantes vous avez le Nom et l’ID qui sont obligatoire, l’ID qui doit avoir une valeur comprise entre 5 et 10 et la propriété FooProperty qui à une longueur maximale de 15 caractères.

public class User
{
 
    [Required]
    public string Name { get; set; }
 
    [Required]
    [Range(5, 10)]
    public int Id { get; set; }
 
}
 
 
public class Foo
{
 
    [StringLength(15)]
    public string FooProperty { get; set; }
 
}

Les DataAnnotations sont réellement utiles et s’intègrent parfaitement à vos applications (MVC et EF utilisent ces attributs pour valider les objets par exemple) et vous trouverez plus de détail ici car ce n’est pas le sujet principal de ce post.

 

Customiser NFluent pour s’assurer qu’un objet est valide

Il y a deux manière pour ajouter de nouvelles méthodes de validation à NFluent selon le cas d’utilisations:

  1. c’est une validation simple et qui ne s’enchaine pas avec d’autre méthodes de validations. On va donc avoir une assertion du type :
Check.That(user).DataAnnotationsAreValid();
  2.  c’est une validation qui va s’integrer dans une chaine de
 validation, un truc du genre:
Check.That(user).IsOk().And.DataAnnotationsAreValid().And… ;

 

On va s’intéresser au second ca, le premier étant simple et limité, il n’y a pas de grand intérêt à l’expliciter ici.

1- Ecrire une méthode d’extension sur nos objets.

public static class NFluentExtention
{
 
    public static ICheckLink<ICheck<Object>> DataAnnotationsAreValid
(this ICheck<Object> check)
    {
        var runnableCheck = ExtensibilityHelper.ExtractChecker<Object>
            (check);
 
        return runnableCheck.ExecuteCheck(
            () =>
            {
                //vérifier que mon objet est OK
            },
            "Mon user est valide alors qu'il ne devrait pas l'être");
    }
}

Notre Methode est générique et renvoi un objet de type ICheck<T> ou T est un Object…ce qui n’est pas terrible mais comme tout objet peut avoir des attributs de validation, on est obligé de prendre le plus petit dénominateur commun: la classe Object.

La première ligne de la méthode se charge de récupérer l’objet ciblé par la validation de votre méthode. Ensuite, dans le ExecuteCheck, vous allez avoir deux paramètres:

  1. le premier vérifie que votre objet est “valide” dans un cas normal.
  2. le second renvoi le message d’erreur dans le cas ou votre objet est valide alors que le résultat attendu est qu’il ne le soit pas. Comme par exemple quand on va avoir un Not avant notre méthode :

Check.That(user).Not.DataAnnotationsAreValid()

2- Ecrire le code liée à la validation de l’objet:

Il nous suffit pour cela de l’insérer à l’endroit adéquatadequat comme cela.

public static ICheckLink<ICheck<Object>> DataAnnotationsAreValid
(this ICheck<Object> check)
{
    var runnableCheck = ExtensibilityHelper.ExtractChecker<Object>
    (check);
 
    return runnableCheck.ExecuteCheck(
        () =>
        {
            var myUser = runnableCheck.Value;
 
            var context = new ValidationContext
                (myUser, serviceProvider: null, items: null);
            var results = new List<ValidationResult>();
 
            var isValid = Validator.TryValidateObject
                (myUser, context, results, true);
            var errorMessages = string.Empty;
            if (!isValid)
            {
                foreach (var validationResult in results)
                {
                    errorMessages += 
                        validationResult.ErrorMessage;
                }
                throw new FluentCheckException
                  ("Mon user n'est pas valide :" + errorMessages);
            }
 
 
        },
        "Mon user est valide alors qu'il ne devrait pas l'être");
}

Ici, rien de bien compliqué,  on utilise les classes du framework prévu à cet effet pour s’assurer de la validité de notre objet. Dans le cas d’une erreur, on va générer une exception de type FluentCheckException.

 

Comment on l’utilise?

Aussi simplement qu’un autre type de validation!

 

[TestMethod]
public void TestMonUtilisateur_OK()
{
    var user = new User();
    user.Id = 6;
    user.Name = "toto";
 
    Check.That(user).DataAnnotationsAreValid();
 
}
 
[TestMethod]
public void TestFoo_OK()
{
    var foo = new Foo();
    foo.FooProperty = "ddddd";
 
    Check.That(foo).DataAnnotationsAreValid();
 
}
 
[TestMethod]
public void TestFoo_KO()
{
    var foo = new Foo();
    foo.FooProperty = "ddzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzddd";
 
    Check.That(foo).Not.DataAnnotationsAreValid();
 
}
NFluent : l’outil indispensable pour vos tests unitaires

Qu’est-ce que NFluent

C’est une libraire d’Assertion que vous pouvez utiliser avec les principaux framework de tests unitaires (xUnit, NUnit, MsTest,…) et dont le but est de vous faciliter l’écriture et le debug de vos tests unitaires.

Pourquoi l’utiliser

By design, le développeur a peur des tests unitaires, même quand il est convaincu du bien-fondé de la chose et qu’il est à l’aise avec l’écriture de code testable…il reste toujours une petite appréhension.

Personnellement, ma phobie sur ce sujet c’est quand je tombe sur des trucs comme ça :

[TestMethod]
public void TestMethod1()
{     var o = new Foo();     var a = o.Add(1, 2);     Assert.AreEqual(a, 4);
}

clip_image001

Je n’ai même pas commencé à débugger que ma tête me fait mal pour les raisons suivantes :

· Le nom de la méthode de test : TestMethod1. Alors oui, j’abuse un peu…dans la vraie vie on rencontre plutôt : TestTraitementOK1, TestTraitementOK2, TestTraitementOKWithParams ce qui fait beaucoup avancer le problème.

· Pas de message custom et je sais juste que j’attends une valeur qui est 3 et que mon traitement renvoi 4. A ce stade, on est obligé de rentrer dans la méthode de test pour savoir ce qui est testé (le SUT) et le cas de test.

· A la lecture du test, on se rend compte que l’Assert est inversé : la valeur attendue est inversé avec la valeur calculé. C’est beaucoup plus sournois et grave que ce que l’on pense car cette erreur est très courante et nous rend méfiant envers le message d’erreur du test.

NFluent (malheureusement) ne va pas faire sortir un coup de poing pour frapper le développeur qui nome mal ses méthodes mais il va vous aider pour les autres points…et aussi pour plein d’autres.

Une syntaxe « naturelle» qui lève toute ambigüité :

Si on reprend l’exemple précédent et qu’on le transcrit en NFluent on a :

Check.That<int>(a).IsEqualTo(4);

Ce qui nous donne en langage humain : « vérifie que mon entier ‘a’ est égal à 4 ». De plus, plus aucune ambiguité entre la valeur testé et celle attendue.

Quelques autres exemples que vous comprendrez sans explications (Je ne mets volontairement pas le reste du test pour vous prouver qu’avec uniquement le « Check » vous comprenez ce que fait votre test en mode « BRAIN OFF ») :

Check.That<User>(u).IsInstanceOf<User>();
Check.That(integers).IsOnlyMadeOf(3, 2, 1).And.HasSize(4);
Check.That(integer).IsPositive().And.Not.IsGreaterThan(100);
Check.That(() => { throw new Exception("test"); }).Throws<Exception>().WithMessage("testX");

Vous comprendrez aussi la différence entre :

 Check.That<User>(u).IsEqualTo<User>(v);  (on compare les references)

Et

Check.That<User>(u).HasFieldsWithSameValues(v); (on compare les propriétés)

Un message d’erreur clair sans effort

C’est la première chose qui m’a frappé et juste pour ça, ça vaut le coup de l’utiliser, et là pareil : je ne vous mets que les messages d’erreurs et vous verrez que les infos remontés sont riches :

The checked enumerable has 3 elements instead of 4.

The checked enumerable: [1, 2, 3]

The checked value is greater than the threshold.

The checked value: [5]

The expected value: less than [4]

The checked enumerable has 3 elements instead of 4.

The checked enumerable: [1, 2, 3]

The checked enumerable does not contain exactly the expected value(s).

The checked enumerable: ["toto", "titi", "tata"] (3 items)

The expected value(s): ["toti", "titi", "tata"] (3 items)

Des Features sympas:

Sur les types :

 Check.That<User>(u).IsEqualTo<User>(v);  (on compare les références)

Check.That<User>(u).HasFieldsWithSameValues(v); (on compare les propriétés)

Sur les collections :

var integers = new int[] { 1, 2, 3 };
Check.That(integers).IsOnlyMadeOf(3, 2, 1).And.HasSize(4);
list.Add(new User() { Name = "toto", Id = 1 });
list.Add(new User() { Name = "titi", Id = 1 });
list.Add(new User() { Name = "tata", Id = 1 });
Check.That(list.Properties("Name")).ContainsExactly("toto", "titi", "tata");

Simple à étendre…mais on verra cela dans un prochain billet.

Le seul truc que j’ai à lui reprocher est qu’il s’arrête à la première erreur  et n’exécute pas toutes les validations pour renvoyer toutes les faillures :

var maboite = "Cellenza est une boite trop cool";

Check.That(maboite).Contains("AAAA").And.StartsWith("X").And.Contains("CSC");

J’aurais aimé avoir les 3 erreurs plutôt qu’uniquement la première :

The checked string does not contains the expected value(s): "AAAA"

The checked string: ["Cellenza est une boite trop cool"]

The expected substring(s): ["AAAA"]

Vous pourrez trouver beaucoup plus d’infos ici et il est disponible via Nuget…que demande le peuple !

[Event] Janvier : “ASP.net MVC from zero to hero”

Cellenza se propose de démarrer l’année avec un évènement autour du développement web et en particulier ASP.net MVC. Le pattern MVC etant devenu un standard pour le web, nous vous proposons de venir découvrir son implémentation dans l'écosystème MS.

Nous vous proposons donc de venir en discuter avec nous et de découvrir ce qui se cache sous le capot d’ASP.net MVC.

Le programme est le suivant:

  • Présentation d'ASP.NET MVC 4
  • Présentation des nouveautés MVC 5
  • DOJO d'un projet amorce MVC
Pour plus de détail et vous inscrire, ca se passe ici:

ASP.NET MVC

Design pattern : Pattern Strategy et Agilité

 

Pourquoi parler du pattern strategy? parce que c’est, a mon avis, le pattern que vous allez le plus souvent utiliser lorsque vous faites des projets agiles: qui dit projet Agile, dit projet ayant des tests unitaires, donc Injection de dépendance…et donc le pattern Strategy (dans BEAUCOUP de cas) !

C’est un pattern que j’aime beaucoup car il vous permet également de respecter deux des principes solides : SRP et OCP. De plus, c’est un pattern du GoF (de la catégorie comportementale)  qui est extrêmement simple à comprendre et à mettre en place…ce qui n’est pas forcément toujours le cas.

A quoi sers stratégie ?

prenons la définition donnée par wikipedia :

En génie logiciel, le patron stratégie est un patron de conception (design pattern) de type comportemental grâce auquel des algorithmes peuvent être sélectionnés à la volée au cours du temps d'exécution selon certaines conditions, comme les stratégies utilisées en temps de guerre.

Le patron de conception stratégie est utile pour des situations où il est nécessaire de permuter dynamiquement les algorithmes utilisés dans une application. Le patron stratégie est prévu pour fournir le moyen de définir une famille d'algorithmes, encapsuler chacun d'eux en tant qu'objet, et les rendre interchangeables. Ce patron laisse les algorithmes changer indépendamment des clients qui les emploient.

On a donc la possibilité d’utiliser un traitement spécifique à un endroit donné du programme en fonction de nos besoins et du contexte.

Prenons un exemple concret :

J’ai ici une classe DataHandler qui doit charger des données et les écrire. Il y a donc deux traitements distincts sur lesquelles nous souhaitons utiliser le pattern strategy car dans un cas, je souhaite écrire dans la console, et dans l’autre dans un fichier.

image

Pour la partie « écriture », j’utilise donc une interface IDataWriter comme couche d’abstraction utilisée par la classe DataHandler. J’ai deux classes permettant de mettre en œuvre mes stratégies : FileWriter & ConsoleWriter.

    public interface IDataWriter
    {
        void WriteData(List<string> messages);
    }



    public class ConsoleWriter:IDataWriter
    {
        public void WriteData(List<string> messages)
        {
            messages.ForEach(m => Console.WriteLine(m));
        }
    }


    public class FileWriter : IDataWriter
    {
        private readonly string _fileName;

        public FileWriter(string fileName )
        {
            _fileName = fileName;
        }

        public void WriteData(List<string> messages)
        {
            if (File.Exists(_fileName))
            {
                File.WriteAllLines(_fileName, messages);
            }
        }
    }

J’utilise l’injection par constructeur dans la classe DataHandler pour appliquer la stratégie choisie dans mon traitement.

    public class DataHandler
    {
        private readonly IDataWriter _dataWriter;
        private readonly IDataProvider _dataProvider;

        public DataHandler(IDataWriter dataWriter, IDataProvider dP)
        {
            _dataWriter = dataWriter;
            _dataProvider = dP;
        }

        public void GetAndPrintMessages()
        {
            var messages = _dataProvider.GetMessages();
            _dataWriter.WriteData(messages);
        }
    }

Lors de l’exécution de mon programme je n’ai qu’à construire mon objet DataHandler avec les bonnes stratégies et exécuter mon traitement.

var dh = new DataHandler(new ConsoleWriter(),
                          new DataProvider());
dh.GetAndPrintMessages();
Console.ReadKey();

Cet exemple montre bien que ce pattern est extrêmement simple, accessible par tous et que l’on peut l’utiliser pratiquement dans tous les cas de figure.

Pour résumer:

Vous remarquerez également que j’ai fait la même chose pour la partie chargement des données avec l’interface IDataProvider et la classe DataProvider et cela malgré le fait de n’avoir qu’une seul stratégie:

 

    public interface IDataProvider
    {
        List<string> GetMessages();
    }
 
    public class DataProvider : IDataProvider
    {

        public List<string> GetMessages()
        {
            return new List<string>(){"a","b","c","d"};
        }
    }

C’est ici que le pattern strategy est réellement pratique dans vos développements Agile (avec beaucoup de refactoring en vue) :

· Respect du principe OCP : Si vous souhaitez ajouter une nouvelle stratégie, pas de problème : il vous suffit d’implémenter l’interface IDataProvider sans toucher à la classe DataHandler

· Respect du principe SRP : vous avez isolé la partie chargement du reste du traitement tout en vous assurant que les prochaines stratégies de chargement respecterons ce plan.

· Respect du principe DIP : vous n’avez pas de couplage entre la classe DataHandler & DataProvider…car vous faites de l’injection de dépendance.

Du coup, votre code est testable car facilement mockable !

Strategy est donc un pattern simple qui n’a que des avantages, vous n’avez donc aucune raisons de ne pas l’utiliser !

[MS] Visual Studio 2013 Paris Summit: nous y serons!

 

Microsoft organise le 26 novembre le lancement officiel de VS 2013 dans leur locaux. Cellenza (la société dans laquelle je travail) présentera une session liée à git et VS 2013 (Michel Perfetti ) et je serai présent sur le stand de ma société.

Si vous voulez savoir ce que nous réserve MS pour ce cru 2013, n’hésitez pas!

 

VS 2013 Paris Summit

Workshop Continuous Deployment TFS/Deploy it : ca se passe ici!

 

Hello,

Nous organisons un workshop Continuous Deployment avec les outils TFS & Deploy it à Cellenza.

Deploy-it est un acteur important et connu dans l’écosystème Java pour les aspects touchant à la gestion des environnements et des process de déploiement et il commence a être utilisé dans notre écosystème.

Michel Perfetti à pas mal bossé sur la manière de le plugger à TFS et donc d’automatiser la chaine complète; nous nous sommes donc dit qu’il serait utile de vous présenter tout cela.

SI vous le souhaitez, cet atelier sera interactif et vous pourrez utiliser concrètement ces outils…pensez donc à apporter un PC portable.

Nous vous invitons donc à nous rejoindre le 07 novembre dans nos locaux pour une présentation de ces deux outils et la manière de les utiliser conjointement pour faire du  déploiement continue!

Pour cela, vous pouvez réserver une place ici:  https://workshop-deployit-tfs.eventbrite.fr/

Code Map Debugger : en quoi cela va changer ma vie de développeur

 

Il y a quelques temps, Cellenza a présenté les nouveautés incluses dans TFS 2013 et VS 2013 présenté lors de la Build.

J’ai eu l’occasion de faire une rapide démonstration de « code map debugger » : outils déjà présent dans VS 2012 sous forme de pluggin et intégré dans la version 2013 de notre IDE favori.

Après cette présentation, je ne vous cache pas que je me suis mis (forcé) à l’utiliser pour voir si les promesses entrevues étaient tenues en mode « professionnel » ; pour faire simple : étais-ce un simple gadget ou y a-t-il un véritable intérêt à l’utiliser et si oui, en quoi ?

Tout d’abord, un rapide rappel de ce qu’est « Code Map Débugger » :

Pour moi : c’est un outil graphique d’aide à la navigation dans le code idéal pour le débug…mais pas que !!

Vous trouverez pas mal d’explication ici mais je vous encourage vivement de le tester vous-même : vous verrez que la prise en main est quasi immédiate !

clip_image002

Je pense qu’il existe plusieurs manières d’exploiter cet outil comme par exemple :

· Assistant de Debug qui déchire : vous pouvez lancer code map à partir d’une session de debug en cours et faire en sorte qu’apparaisse dans votre graphe les différentes entités (classe, méthodes, interfaces,…) impliqué dans votre parcours. Vous avez donc une vision graphique de votre arbre d’appel que vous pouvez compléter/alléger/commenter/…

clip_image004

· Graphe d’objet dé normalisé : le fait que le graphe ne respecte aucun formalisme rigide (comme UML par exemple) vous permet de très vite entrer dans la fonctionnalité et de l’adapter à votre vision : vous pouvez donc visualiser dans la même boite deux méthodes de classes différentes, ne faire apparaitre que certains sous appel…bref une flexibilité absoulue !

clip_image005

· Bibliothèque de cas de débug : vous pouvez sauvegarder vos shéma de débug et les partager avec votre équipe. Ainsi, si une autre personne doit travailler sur un bug qui possède déjà une map, celle-ci va permettre de rapidement rentrer dans le code et de trouver le problème plus rapidement.

· Spécifications : vous pouvez aussi utiliser différentes map comme spécifications fonctionnelles en ne faisant apparaitre que les grandes étapes de votre traitement.

· Marque page : lorsque vous travaillez sur des grosses applications avec énormément d’interaction, une bonne map peut vous permettre de naviguer plus simplement vers n’importe quel type d’entité (classe, méthode, propriété)…mine de rien c’est tout de même un gain de productivité non négligeable.

clip_image006

Design pattern Decorator (décorateur)

 

 

Très souvent, lorsque l’on souhaite ajouter des fonctionnalités à une classe on pense : héritage – et c’est un bon réflexe.

Mais - très souvent également- la solution n’est pas forcément adapté : on peut souhaiter ajouter plusieurs fonctionnalités à la même classe de manière dynamique (runtime) et non pas à l’écriture du programme (ajout de fonctionnalité statique) en choisissant les nouvelles fonctionnalités pour chaque instance et non pas pour la classe. Dans ces cas, on doit faire appel au pattern Decorator (pattern du GoF de type structure).

Prenons un exemple simple pour illustrer ce pattern trop peu utilisé dans notre écosystème.

Prenons, par exemple, la modélisation de glaces :

· il en existe plein de types :à l’eau, italienne, avec des boules,…

· et tous ces types de glace on en commun des gouts : chocolat, vanille, citron, etc…

On souhaite donc pouvoir avoir un modèle permettant d’avoir une glace Italienne au chocolat et à la vanille. On va donc pouvoir utiliser l’héritage avec par exemple : la classe Italienne (qui hérite de glace) et qui a comme propriété une liste de gouts

Sauf que si on ajoute des options tels que des amandes grillés dessus ou autre chose, on complexifie le modèle et surtout on risque de ne plus respecter le principe SOLID « open close principle ».

Voyons comme le pattern Decorator peut nous aider de manière élégante :

Dans ce pattern, on va identifier deux parties de l’arbre d’éritage:

1. la partie classique ou l’on va retrouver nos classes Glace (abstraite) GlaceItalienne et GlaceALeau.

2. La partie liée aux ajouts de fonctionnalités avec

a. une autre classe abstraite GlaceDecorator qui servira de base pour tous les décorator (ie fonctionnalités)

b. les décorateurs concrets : GoutVanille & GoutChocolat qui en héritent.

clip_image002

Pour le code, on va juste compléter la description de la glace :

public abstract class Glace
    {
        public virtual string Description
        {
            get
            {
                return "Glace virtuelle";
            }
        }
    }

    public class GlaceItalienne : Glace
    {
        public override string Description
        {
            get
            {
                return "glace italienne";
            }
        }
    }

    public class GlaceALeau : Glace
    {
        public override string Description
        {
            get
            {
                return "glace a l'eau";
            }
        }
    }

    public abstract class GlaceDecorator : Glace
    {
        protected Glace _glace;

        public override string Description
        {
            get
            {
                return _glace.Description;
            }
        }

    }

    public class GoutChocolat : GlaceDecorator
    {
        public GoutChocolat(Glace glace)
        {
            _glace = glace;
        }

        public override string Description
        {
            get
            {
                return _glace.Description + " avec du chocolat ";
            }
        }

    }

    public class GoutVanille : GlaceDecorator
    {

        public GoutVanille(Glace glace)
        {
            _glace = glace;
        }

        public override string Description
        {

            get
            {
                return _glace.Description + " avec de la vanille ";
            }
        }
    }

Et donc, à l’utilisation j’ai juste a instancier une glace italienne et ajouter mes options  vanille et chocolat par exemple :

static void Main(string[] args) 
        { 
            Glace maglace = new GlaceItalienne(); 
            maglace = new GoutChocolat(maglace); 
            maglace = new GoutVanille(maglace); 
            Console.WriteLine(maglace.Description); 
            Console.ReadKey(); 
        }

J’ai le résultat suivant à la console :

clip_image004

De cette manière, avec un arbre d’héritage peu complexe, on a la possibilité d’avoir des compositions dynamiques très complexes tout en respectant le principe « open close ».

Un des avantage de ce pattern est l’aspect dynamique et optionnel des fonctionnalités que l’on ajoute et, mine de rien, si on le met en place suffisamment tôt lorsque l’on développe la solution reste simple et élégante.

Par contre, contrairement à l’héritage nous n’avons pas accès aux propriétés et méthodes privés de l’objet que l’on décore.

C# 5 : Caller Info Attributes.

 

Avec C#5, Microsoft n’a pas seulement ajouté le support de l’Asynchronisme avec les mots clés Async/Await…il y avait également les « Caller Info Attributes ».

Pourquoi en parler ?

Parce que dans certains cas, comme nous allons le voir, cela peut être très utile…et que ca n’est pas une feature très connue dans la communauté des développeurs .NET.

Qu’est-ce que c’est ?

Ce sont trois nouveaux Attributs qui se trouvent dans le namespace System.Runtime.CompilerServices utilisable par les paramètres de vos méthodes :

· CallerFilePath : donne le nom du fichier source d’où provient l’appel à votre méthode

· CallerLineNumber : la ligne dans le fichier

· CallerMemberName : le nom de l’  « objet » (Méthode, propriétés, constructeur, lambda,…) qui appelle votre méthode.

A quoi ça peut bien servir ?

Faire des Traces !

 

 
    public class Foo
    {
        public void Execute()
        {
            Trace.WriteError("Error!");
        }
    }
    
    public static class Trace
    {
        public static void WriteError(string message, 
                             [CallerFilePath] string callerFilePath = "",
                             [CallerLineNumber] int callerLineNumber = 0,
                             [CallerMemberName] string callerMemberName = "")
        {
            var formattedError = string.Format("{0}/{1}/{2}  --> {3}",
            callerFilePath, callerLineNumber, callerMemberName, message);
            Console.WriteLine(formattedError);
        }
    }

Nous avons ici une classe Trace avec une methode WriteError qui permet d’écrire sur la console un message formaté contenant les informations issues de nos nouveaux attributs.

Et une autre classe Foo qui contient une méthode Execute qui execute la trace. Comme vous pouvez le voir, nous n’avons besoin de passer uniquement le message d’erreur (les autres paramètres ont des valeurs par défaut mais sont renseignés au runtime).

Notre ami INotifyPropertyChanged !

 

public class Foo : INotifyPropertyChanged
    {
        private string _name; 
        public string Name
        {
            get { return _name; } 
            set { _name = value; RaisePropertyChanged(); }
        } 
        
        protected void RaisePropertyChanged([CallerMemberName] string member = "")
        {
            var propertyChanged = PropertyChanged; 
            if (propertyChanged != null)
            {
                propertyChanged(this, new PropertyChangedEventArgs(member));
            }
        } 
        public event PropertyChangedEventHandler PropertyChanged; 
        
        public void Execute()
        {
            Trace.Write("Error!");
        }
    }

On utilise notre attribut MemberCaller pour la méthode RaisePropertyChanged, ainsi, nous n’avons plus à passer un string contenant le nom de la propriété qui a été modifiée !

 

Il existe bien sûr plusieurs autres cas d’utilisations pour ces attributs (n’hésitez pas à les mettre en commentaire du post si vous en avez) et il est bien dommage de voir qu’ils sont si peu utilisés.

API Restrinction Exception après migration du process template de Build de TFS 2010 vers TFS 2012.

Suite à une migration de tfs 2010 vers 2012, j’ai eu à faire un upgrade des différents template de builds.

On en a également profité pour activer quelques mesures pour améliorer la qualité telle que les tests unitaires dans les builds…et là ce fut le drame :

clip_image002

Cet exception est liée au fait que nous avons des dlls de tests qui sont référencés par d’autres dlls de tests et que nous avons activé la feature de MSBuild (présente dans le framework 4.5) permettant d’avoir un répertoire par projet compilé dans la drop location. Donc, lorsque le process charge les composants de test…bah certains sont détectés en double car dans plusieurs répertoires différents.

Après avoir fait un test rapide sur le template de base proposé par tfs 2012 et je n’ai pas eu l’exception, j’ai compris que le problème était liée à la migration.

Après avoir analysé les process templates et quelques recherche sur google. J’ai réussi à voir que le problème était liée au Test Runner :

Par défaut, sur le template 2012, il utilise le test runner de visual studio :

clip_image003

Or, lorsque vous faites une migration, cette valeur est disponible uniquement si vous avez le paramètre suivant dans votre template de build :

<this:Process.BuildProcessVersion>11.0</this:Process.BuildProcessVersion>

Avec bien sûr la déclaration qui va bien :

<x:Property Name="BuildProcessVersion" Type="x:String" />

Une fois ce paramètre ajouté, vous aurez la possibilité de faire tourner vos tests unitaires avec le runner adéquat et vous n’aurez plus l’exception.

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01