[EN] My last year on pluralsight

I have been enjoying my  pluralsight MVP license for a year now.  Let me share with you some of the courses you should also see:

Web

JavaScript for C# Developers: best course to start learning javascript. I stopped reading javascript as C# code after this course. Now javascript is no more a mystery for me

jQuery Fundamentals:  this is the logic next course. Very important course to see if you want to start web development

ASP.NET MVC 5 Fundamentals: have seen a lot of ASP.Net MVC courses, but this is the last one. I decided to watch it for the Web API 2 and SignalR parts at first.

Data

SQL Server: Why Physical Database Design Matters: Every .Net developper should watch this one. Very interresting.

MDX Fundamentals: As javascript: to stop reading MDX like SQL.

Programming & Langages

The xUnit.net Testing Framework: simple and powerful test framework. even better if you use it with nfluent.

Clean Code: Writing Code for Humans: to watch on a regular basis, to be sure to write awesome code.

C++ Advanced Topics & Modern C++ Libraries: I tried to refresh my old c++ skills. Need to practice now!

@+

[EN] Git, TFS & access rights: leave my master branch alone!

Where are my access rights!?

If you switched from TFVC to Git, you’ll notice that there is no access control at file level. This is because the Git model is not adapted to have this kind of access rights. Git is still a secured source control system and TFS/VSO have a large set of access rights to configure.

image

From a developer’s point of view, the most important rights are:

  • branch creation (repo level):  with this right you can control who can create branches on the server repo. That does not mean that developers cannot create branches locally (branch and repo level):  they just cannot push them to the server without this right.
  • Rewrite and destroy history: very dangerous, but can be useful to avoid already synced commit rebased and pushed to the server
  • Tag creation (repo level): as branch creation, this right is useful to manage the repository structure

If you have several repositories, you can also define the default behavior for all repositories at project level:

image

By default, contributors can push new branches and tags to the repo. You can change that directly at project level and define a specific group for these operations.

Limited access to the master branch

Another possible scenario is to isolate the master branch: no developers are allowed to push commits on it. A dedicated team is in charge of merging developers branches into the master branch: very useful if you have feature teams. This scenario can be applied to any branch of your repository.

How to switch to Git if you have different access level per directories?

The git approach is different. In this case you should create several repository with specific access rights for each one.  Git submodules is maybe your solution. Submodules are not handled by Visual Studio, but you can change that.

@+

[EN] How to configure notepad++ with git as default editor

The multisession mode of notepad++ can create some issue with git when Git needs to open a temporary file. notepad uses the current opened instance and closes the one opened by Git. This behavior makes Git think that you have finished to update the file. The best thing to do is to modify the default editor with a specific instance of notepad++

Start by opening the configuration file: here the system one:

git config --system –edit

Now add this line in the “[core]” part:

editor=\"c:/program files (x86)/Notepad++/notepad++.exe\" -multiInst -nosession

The “-multiInst” flag forces notepad++ to open a new instance for the file and the “-nosession” flag is used to not retrieve the files of the previous session. The “-notabbar” can also be used.

[EN] Wilinq 0.1.1.1–Generated classes & queries

With the last version of Wilinq, you can now generate classes that are mapped to your workitems types (how to here):

if (scrumProject.IsSupported<bug>()) 
{ // this query only works for Scrum template 2.0 
  var bugQuery = from bug in scrumProject.SetOf<bug>() 
                 where bug.Title == "Build Failure in Build: MonApp_20130328.2" &amp;&amp; bug.AssignedTo == QueryConstant.Me 
                 select bug; 
  var bugResult = bugQuery.ToList(); 
} 

Wilinq is available on nuget and uses the TFS 2012 object model.

[FR] 2 semaines avec Here Drive + et CR-200

Mon précédent GPS m’ayant lâchement abandonné en me laissant un simple message: “assert.c failed assertion… (je vous passe les détails)”, j’ai décidé de franchir le pas en me servant de mon téléphone (Lumia 920) comme GPS. J’ai donc commandé le socle CR-200 qui permet un rechargement via induction. Me voilà donc équipé d’un GPS grand écran d’un socle simple à utiliser et en plus avec une prise USB supplémentaire qui permet de charger un autre téléphone. Le trajet était le suivant: partir de Paris et arriver à coté de Montpellier et m’en servir pour se balader dans la région.

Dans l’ensemble je suis satisfait: Here Drive + fonctionne très bien. J’ai adoré la possibilité de naviguer dans la carte et de revenir sur la position courante juste avec des gestures simples. Les voix sont claires et précises (sauf peut être sur les sorties ou entrées d’autoroute). Mais quelques détails sont venus un peu gâcher la fête:

Détail #1: l’induction c’est bien, mais pas suffisant.

J’ai eu la désagréable surprise de découvrir que Here Drive + consommait plus de courant que le socle fournissait. Techniquement je n’aurais pas pu faire 4h de trajet avec le GPS allumé. Heureusement que 97% de mon trajet était de l’autoroute. C’est vraiment désagreable de faire un trajet en voiture et d’avoir son téléphone déchargé

Détail #2: bien attacher le téléphone et vérifier 2 fois.

Le CR-200 utilise 2 bras avec de la mousse qui enserre le téléphone. La fois où j’ai mal vérifié le serrage, le téléphone est tombé à la première accélération

Détail #3: Here Drive + connait pas le “faites demi-tour le plus tôt possible”

En campagne, m’engageant dans la mauvaise route, Here Drive a préféré me faire rouler 10km dans le mauvais sens plutôt que me dire de faire demi-tour

Détail #4: Les cartes pourraient être meilleures

Problème de vitesses, routes qui n’existent pas sur les cartes… Mais j’imagine que c’est le problème de tous les fournisseurs de cartes

Détail #5: le manque de POI

A part les POI de base, rien ne s’affiche sur la carte. Exemple: chercher une station “Total Access”: pas réussi.

Détail #6: la prise en compte et la visualisation du traffic

C’est surtout ce détail que j’ai regrété par rapport à mon ancien GPS. Ce genre de chose d’évite un gros “fail” qui se caractérise par un amboutteillage lors des retours de vacances.

Malgré cela, je suis satisfait. J’espère que le traffic arrivera bientot!

@+

Pas de build? Et vous, quelle est votre excuse?

La build est la clé de voute du processus d’industrialisation de vos développements. Sans build vous êtes à la merci de la compilation hasardeuse de votre logiciel sur un poste de développeur. En gros ne pas faire de build est un pari perdu.

Alors pourquoi ne pas faire de build? Il y a beaucoup de raisons. Voici certaines que j’ai croisées et qui reviennent souvent:

Je ne sais pas ce que c’est qu’une build et on m’a appris à livrer mon logiciel par mail ou dans un zip (ou les deux)

Corolaire: on ne m’a pas appris du tout à livrer mon logiciel. Donc je l’envoie par email.

De ce que je me souviens de mes études, l’ALM et encore moins la build était au programme. Mais on a changé de siècle depuis, il faut évoluer avec son temps!

J’ai des gens pour ça: interne, presta, etc…

L’éternel combat de la machine contre l’humain. Mais cette fois-ci la machine gagne. Demandez à un gars de lancer la compilation à 3h du mat, de déployer les binaires et de lancer des tests pendant 1h: vous verrez.

Ça coute trop cher, c’est une perte de temps.

Généralement ça ne coute pas plus de temps que de configurer un poste de développement. C’est également le bon timing pour décrite la procédure d’installation d’un poste de développeur où d’une build.

J’en ai une, elle est cassée, personne ne la répare donc on l’a laissé tomber.

C’est qui le chef?

C’est trop compliqué.

C’est souvent aussi compliqué que de compiler le logiciel sur un nouveau poste. C’est surtout le signal d’alarme qu’il y a quelque sorte qui ne va pas et qu’il faut corriger.

C’est pas la priorité, la build ça sera quand il n’y aura plus de problèmes.

Au contraire la build permet de rapidement et de façon fiable un logiciel près à tester. Ça serait dommage de s’en passer quand cela ne  va pas.

Pour compléter ma liste: quelles excuses avez vous eu ?

@+

Nant Episode 1 – Présentation

NAnt est un langage de script adapté à la compilation de projets. les scripts NAnt sont simplement des fichiers XML. NAnt possède 3 concepts de base:

  • les “targets” (cible): les targets rassemblent des ensembles de tâches. On peut dire très naïvement que ce sont les “méthodes” du script. La “target” lancée au démarrage est soit la target par défaut, soit celle définie lors du lancement (il peut aussi y en avoir plusieurs à lancer)
  • les taches
  • les propriétés: elles peuvent être définies en dehors du script lors du lancement

Tous ces éléments se retrouvent sous un noeud principal, le projet.

Si l’on s’arrète à cela, NAnt ressemble trait pour trait à MSBuild. Nous allons voir que non. Nant se détache de MSBuild sur plusieurs points. En particulier:

  • On peut imbriquer les tâches dans des tâches, pour par exemple reproduire un graphe d’appel et pas seulement une séquence.
  • la gestion des erreurs est plus simple
  • la syntaxe des expression est très puissante et très extensible

On peut lancer un script via la ligne de commande de NAnt, ou embarquer nant dans une application (nous verrons plus tard comment et pourquoi).

NAnt est écrit en .Net, et vient de Ant son frère de Java. Toutes les tâches NAnt sont écrites en .Net est NAnt doc est très extensible.

Commençons par un script simple:

 
<?xml version="1.0" encoding="utf-8"?>
<project name="hello" default="main_target">
  <target name="main_target">
    <echo message="Hello from nant" />   
  </target>
  <target name="other_target">
    <echo message="Hello from nant (other)" />
  </target>
</project>

La ligne de commande est la suivante: nant -buildfile:HelloFromNAnt_1.build

image

Changeons un peu la ligne de commande: nant -buildfile:HelloFromNAnt_1.build other_target

image

La cible a changé, par défaut le script pointe sur “main_target”, mais il est possible de choisir.

On peut aussi appeller une cible d’une autre cible:

 
<?xml version="1.0" encoding="utf-8"?>
<project name="hello" default="main_target">
  <target name="main_target">
    <echo message="Hello from nant" />
    <call target="other_target" />
  </target>
  <target name="other_target">
    <echo message="Hello from nant (other)" />
  </target>
</project>

Lançons ce script:

image

Le prochain script montre une partie de la puissance de NAnt: les propriétés

 
<?xml version="1.0" encoding="utf-8"?>
<project name="hello" default="main_target">
  <target name="main_target">
    <echo message="Hello from nant" />
    <call target="Target_${cible}" />
  </target>
  <target name="Target_A">
    <echo message="Hello from A" />
  </target>
  <target name="Target_B">
    <echo message="Hello from B" />
  </target>
</project>

image

j’ai créé une propriété via la ligne de commande “cible”. et j’ai appellé la target “Target_${cible}” la syntaxe ${} permet d’executer une expresssion et pas seulement lire une variable. la chaîne résultante est devenue Target_B d’où le résultat.

Dans le prochain billet nous verrons les tâches les plus interessantes de NAnt.