Pour un travail scolaire, nous avons eu la tâche d'analyser l'architecture du projet open source Protobuf de Google. Protobuf est le protocole de communication utilisé par Google pour communiquer entre les proccessus (voir le site officiel). Le projet est livré avec des compilateurs pour générer les classes d'accès dans plusieurs langages comme Java, Ruby, C#, etc. Étant un développeur .Net depuis des années, il était naturel pour moi en mon coéquipier de nous concentrer sur la librairie C# de Protobuf. Pour analyser l'architecture du module C#, nous avons utilisé un outil vraiment intéressant, NDepend. NDepend est une suite sophistiquée d'outils d'analyse pour les projets .Net qui donnent énormément d'information sur l'architecture et la qualité du code.

Ce que nous avons découvert

En utilisant les différents graphiques fournis par NDepend, nous avons noté certains faits intéressants :

1. Le niveau d'abstraction du projet semble adéquat (voir graphique 1)
2. Les auteurs ont été capables de bien gérer les inter-dépendences avec seulement 2 références croisées entre 2 namespaces (il n'y a qu'un seule assembly dans ce projet) (voir graphique 2).

Mon expérience avec l'outil a été agréable et je compte bien continuer de l'utiliser tout au long de mes études. Je prévois également le proposer à mon employeur car ce produit en offre beaucoup pour améliorer la qualité de nos applications.

Essayez NDepend et remerciez-les pour la grande qualité de leurs produits.

Graphique 1

Graphique 2

Graphique 3

Pour un nouveau projet, j'ai décidé de faire un essai avec MongoDB. Ça fonctionne très bien mais je n'arrive jamais à me rappeler comme faire l'installation de MongoDB en service Windows alors comme rappel pour moi (et pour vous chers lecteurs), voici les étapes :

• Télécharger MongoDB au https://www.mongodb.org/downloads
• Exécuter l'installation
• Créer un dossier pour les données. Il peut se trouver n'importe où sur le disque mais pour des besoin de dévelopement, je le mets dans le même dossier que l'installation de mongo. À l'intérieur, créer 2 sous-dossiers pour les DB et les logs.
• Créer un fichier de configuration (par exemple c:\devtools\mongodb\mongod.cfg) pour configurer les chemins d'accès pour les bases de données et les logs. Ex:

systemLog:
    destination: file
    path: C:\DevTools\MongoDB\data\log\mongod.log
storage:
    dbPath: C:\DevTools\MongoDB\data\db

Dans le billet précédent, j'ai parlé de Git, un gestionnaire de version distribué. La façon classique d'utiliser Git est via la ligne de commande bash. Mais si vous utilisez Visual Studio, il y des extensions que vous pouvez installer pour intégrer toutes les bonne choses de Git dans votre IDE préféré. Même si je continue à utiliser la ligne de commande pour certaines tâches comme synchroniser avec mon serveur Subversion, la plupart des tâches quotidiennes durant le développement sont disponibles dans l'IDE. 

Git source control provider

Cette extension (downloadable à partir du visual studio extension gallery) configure Git comme votre source control provider. Cet outils est assez limité mais offre 3 fonctionnalités intéressantes :

• Elle affiche le nom de la branche courante en haut du Solution Explorer
• Elle montre le statut des fichiers dans le Solution Explorer (ajouté, modifié ou inchangé)
• Elle donne un raccourcis pour ouvrir une fenêtre Git bash dans un dossier spécifique.

Cette extension par elle-même ne donne que des fonctionnalités de base mais combiné avec Git extensions, ça devient plus intéressant.

Git Extensions

Cette extension peut être téléchargée de Google code et ajouter plusieurs commandes Git commands dans Visual Studio et dans Windows Explorer. Vous pouvez voir dans l'image ci-haut que Git source control provider inclut un raccourci vers Git Extensions mais vous pouvez l'utiliser seul.

Dans Visual Studio, Git extensions ajoute une barre d'outils et un nouveau menu dans l'IDE. Par ceux-ci, vous pouvez faire à peu près tout le travail quotidien avec Git (vous pouvez voir la nouvelle barre d'outils encerclé en rouge).

Pour être honnête, je ne sais pas encore ce que toutes ces options font mais voici un aperçu rapide de quelques-unes :

• Checkout branch : passe de la branche courante vers une autre branche. Plus de détails sur les branches dans un post futur.
• Commit : envoie les changements de la branche courante dans le dépôt local. Voir l'image de la fenêtre ci-dessous.
• Edit .gitignore. Permet de modifier le fichier .gitignore pour le dépôt local. Vous pouvez le faire manuellement mais si vous êtes un développeur .Net, je vous suggère d'utiliser le modèle par défaut fourni qui exclut tous les fichiers temporaires générés par .Net. À date, tous les fichiers requis sont conservés et je n'ai pas de fichiers non voulus.
• Pour tout le travail sur les dépôts distants (Manage remotes, pull, push, rebase, etc.), je ne les ai pas encore essayé puis que n'ai pas eu à utiliser de dépôts Git distant pour le moment.

Quelques explications sur le processus d'envoie (commit). Quand vous voulez envoyer vous changements, vous ouvrez la fenêtre de commit:

Dans la partie en haut à gauche, vous choisissez les fichiers que vous voulez envoyer et cliquez sur "Stage selected file” pour les inclure dans l'envoie. Vous devez entrer un commentaire et cliquer “Commit” pour confirmer. Si le fichier a un statut “Untracked”, ça veut dire que c'est un nouveau fichier et la partie code (en haut à droite) montrera le source. Si le statut est “Modified”, la partie code montre la différence entre les 2 versions. Très pratiqueé Si vous voulez annuler un changement que vous avez fait, choisissez les fichiers à annuler et cliquez “Reset changed”.

Je crois que c'est assez pour l'instant. Prochain post, je parle des branches et fusions avec Git Bash et Git Extension.

Merci et bonne programmation.

Comme vous le savez déjà si vous lisez ce blog religieusement, j'ai maintenant un serveur de développement à la maison pour mes expérimentations. J'utilise Visual SVN Server comme gestionnaire de code source car il est gratuit et simple d'utilisation. Toutefois, je travaille de plus en plus sur mon laptop et dans plusieurs endroits où je n'ai pas nécessairement un accès Wifi. Je peux passer plusieurs heures (ou plusieurs jours) sans pouvoir faire un commit et je n'aime pas vraiment ça car ça complexifie beaucoup le retour en arrière en cas d'erreur. J'avais entendu parlé de Git qui est un gestionnaire de version décentralisé et qui permet d'avoir une copie complète du dépôt (repository) localement sur votre ordinateur. Vous pouvez faire de multiple commits, branches et fusions de branches localement pour ensuite "pousser" vos changements sur le serveur central lorsqu'il est disponible. Vous pouvez également télécharger les changements faits par les autres développeurs dans le dépôt central et les intégrer dans votre version.

Ce qu'il y a d'encore mieux pour un utilisateur de subversion comme moi c'est qu'on peut utiliser Subversion comme dépôt central et Git comme dépôt local. C'est ce que j'ai essayé et voici les différentes étapes pour utiliser Git comme gestionnaire de code source sur ma machine en Windows 7 et l'intégration dans Visual Studio.

Premièrement, vous devez télécharger installer for Git et l'installer. Prenez soin de cliquer sur Git Bash et Git GUI pour l'intégration dans windows explorer, c'est très pratique. Git Bash est très utile pour toutes les tâches administratives et les commandes complexes. Git GUI est supposé aider avec une interface graphique pour les commit et les branches mais je préfère Git extensions pour Visual Studio pour ces tâches. Plus d'information sur cela dans les prochains posts.

Maintenant que vous avez Git, vous pouvez cloner votre dépôt Subversion localement. Utilisez Git Bash, naviguez dans le dossier où vous voulez créer votre dépôt et utiliser la commande suivante : 

git svn clone –s https://mysuberversionserver/svn/myrepository/trunk

Bien sûr, vous remplacez l'URL par celui de votre projet Subversion. À ce stade, it est recommandé de configurer votre fichier .gitignore. Ce fichier contient tous les fichiers ou les dossiers que vous voulez exclure du suivi de version par Git. Il y a plusieurs pages sur le web sur la façon de configurer ce fichier alors je ne m'étendrai pas sur le sujet ici (d'autant plus que les Git extensions pour Visual Studio contiennent un modèle de base pour les développeurs .Net qui exclu déjà tous les fichiers temporaires qui ne devraient pas être dans le gestionnaire de code source).

Vous avez créer votre dépôt local, maintenant, téléchargez le code source :

git svn fetch

Cette commande n'est requise que la première fois. Après cela, vous ne faites que les mises à jour, c'est beaucoup plus rapide. Vous commencez maintenant votre travail, vous faites des changements et git va suivre vos modifications. Quand vous avez terminé, vous pouvez utiliser la commande commit pour enregistrer la version localement : 

git commit

Il y a plusieurs paramètres à la commande commit. Je ne les mentionne pas tous mais en voici 2 pour vérifier le contenu de votre commit sans le faire réellement : 

git commit –v –dry-run

Quand vous êtes prêt à envoyer vos commit sur le dépôt Subversion central, vous faites la commande suivante :

git svn dcommit

Ici encore, il y a une commande pratique pour vérifier les différences entre votre copie locale et votre dernière version du dépôt central. Elle affiche le nom et le status de tous les fichiers différents :

git diff ..remotes/git-svn --name-status

Vous pouvez finalement obtenir les changements des autres contributeurs au dépôt central en utilisant :

git svn rebase

Ok, c'est tout pour ce petit tutorial git svn. Dans les prochains posts, Je vais parler des extensions pour Visual Studio qui simplifient les tâches usuelles avec Git. Je vais également parler des branches et des personnalisations qui peuvent améliorer votre cycle de travail.

Merci, bonne programmation.

Je voulais faire quelques modifications à l'engine de blog hier. J'ai donc pris mon code de production qui roule très bien en IIS 6 chez mon hébergeur et je l'ai mis sur mon serveur de développement qui est sur IIS 7.5. Rien ne fonctionnait ! Erreur 401 (authentication) à toutes les fois que je voulais accéder une page et ce, même si le site accepte les requêtes anonymes. Après plusieurs tentatives et recherches, voici ce que j'ai trouvé pour le faire fonctionner. J'espère que cela vous sera utile :

• Premièrement, j'ai créé l'application et je l'ai mis dans le app pool Classic .Net AppPool
• J'ai vérifier que le document par défaut était bien default.aspx. Ce n'était pas le cas, j'ai donc ajouter la page en haut de la liste
• Ensuite, je me suis assurer que l'utilisateur du appPool avait bien les droits sur les fichiers. C'est cependant plus complexe avec IIS 7 car il y a un utilisateur différents par AppPool, créé dynamiquement. Il faut s'assurer que le groupe IIS_IUSRS a les droits nécessaires sur le répertoire et c'était mon cas.
• Ça ne fonctionnait toujours pas. J'ai alors vu sur un blog qu'il fallait non seulement donner le droits à l'utilisateur anonyme d'accéder le site mais également déterminer quel est l'utilisateur anonyme. C'était là mon erreur car il faut soit lui donner un nom d'utilisateur précis ou prendre celui du AppPool. En le mettant à Application Pool Identity, boom, tout s'est mis à fonctionner parfaitement.

Il ne me reste qu'une seule erreur, facilement contournable mais que je ne comprends pas. Lorsque j'entre l'url http://myservername/blog (avec un b minuscule), ça ne fonctionne pas mais lorsque j'entre http://myserbername/Blog (avec un B majuscule), ça fonctionne ? Le nom de l'application dans IIS est bien "Blog" mais je ne pensais pas qu'IIS était case sensitive sur les URL. Je vais continuer mes recherches plus tard sur ce sujet.

Merci, bon développement.