Debogage à distance avec VS 2010

Les fonctionnalités de Débogage à distance sont véritablement pratiques pour savoir ce qui se passe sur un poste distant. Microsoft fournit l’installation d’un Remote Debuger (http://www.microsoft.com/downloads/fr-fr/details.aspx?familyid=60ec9d08-439b-4986-ae43-0487eb83c09e), une version « light » de ce que propose Visual Studio, pour permettre de déboguer des machines distantes, notamment des serveurs.

L’installation est on ne peut plus simple; on a le choix d’exécuter le Remote Debugger sous la forme d’un service (tournant sur un compte et pouvant aller jusqu’à accepter tout type d’utilisateur distant. Dans ce dernier mode, on ne peut toutefois que faire du debugage natif) ou sous la forme d’un programme.

Nous conseillons vivement cette dernière option pour du debugage sur des serveurs car cela ne devrait être que très occasionnel.

 

Configuration du Remote Debuger

 

Lors de l’installation/configuration, une seule option est disponible: configurer ou non le Remote Debugger en tant que service. Dans ce mode, le Remote Debugger est toujours actif et accessible à distance.

Le compte par défaut proposé est LocalSystem, ce qui est judicieux mais en même temps très ouvert.

Local System est un compte Built-In donnant des privilèges élevés sur l’ordinateur local et qui permet d’agir sur le réseau comme s’il s’agissait de l’ordinateur lui-même. Il n’y a pas besoin de mot de passe.

Lors de la configuration, il vous est possible de configurer un autre compte mais ses privilèges doivent avoir « Ouvrir une session en tant que service ». Microsoft propose par ailleurs que ce compte soit membre du groupe Administrateurs.

 

Options du Remote Debuger

Lancer le programme manuellement, puis allez dans Options. Le serveur porte un nom de la forme user@machine, plus précisément le user précise un domaine.

En mode Authentification Windows, on peut se permettre n’importe quel type de débugage ; le bouton « Autorisations » permet d’indiquer les comptes ayant le droit de deboguer.

Vous noterez l’option « Aucune authentification (natif uniquement) » et « Permettre à tous les utilisateurs de déboguer » qui permet à n’importe qui se connecter et deboguer, mais des applications natives seulement. Ce mode est à proscrire, d’autant plus que votre machine peut se trouver, pardonnez l’expression, en milieu « hostile » et soumise à attaque (en clair, faîtes cela chez vous, pas dans votre entreprise).

Par ailleurs, comme son nom l’indique, le debogage en mode natif

Classiquement, le compte qui debug sur une machine A en remote sur la machine B doit être le même… si possible. Malheureusement, ce n’est absolument pas le cas si A est dans un domaine et B dans un autre.

 

Debogage en interdomaine

Les choses se compliquent lorsque l’on veut déboguer à distance une machine hébergée dans un différent domaine. Rajoutons une contrainte qui a son importance, lorsque les deux domaines en question ne sont pas approuvés. Ce cas de figure qui peut vous sembler bizarre arrive bien plus fréquemment qu’on ne le croit.

Imaginons un environnement de test ou recette possédant son propre domaine, son propre AD, ses propres contraintes de sécurité ; ceci afin d’éviter tout télescopage possible. Il n’y a aucune raison de faire un domaine de production approuver un domaine de test/recette. Mais il est en revanche possible d’imaginer un développeur sur son réseau de développement (donc un environement réel, d’entreprise) nécessitant un débugage sur le domaine test/recette car un bug ne se produit que dans cet environement. Sans cette capacité de débogage, son bug ne peut être résolu et son application ne vas pas en prod.

Bref, lorsque les domaines ne sont pas approuvés, on peut choisir le débogage natif (non intéressant pour du débogage managé) mais celui-ci exige, pour des actions interdomaines de permettre à tout le monde de pouvoir se connecter à machine créant ainsi un trou de sécurité.

Il existe néanmoins une solution, ou plutôt 2 solutions.

Option 1

La première exige de jouer avec les Local Security Policy (Stratégie de sécurité locale). Dans le panneau de configuration, outils d’administration, si on lance l’application, il nous est possible (pour peu que l’on possède les droits suffisants) de changer la façon dont un compte local s’expose à l’extérieur en terme de sécurité.

Dans la section « Local Policies », « Security Options », changer la clé « Network access: sharing and security model for local accounts » de « Guest only – local users authentivcate as Guest » à « Classic – local users authenticate as themselves ».

En faisant ce réglage, on indique qu’un compte local à la machine sur un réseau se présente en tant que lui-même. Cette option est classique lorsque vous faite un Workgroup de machine et non pas un domaine. Pour permettre à un compte d’accéder à un partage par exemple, il suffit de dupliquer ce compte ; même user, même password; pour que l’accès soit autorisé

Le Remote Debuging exigeant une communication dans les deux sens, il vous faut faire ce réglage sur les 2 machines impliquées dans la communication.

Cette option fonctionne bien mais souffre d’une grosse limitation… On se retrouve à modifier des réglages de sécurité sur les 2 machines impliquées. Lorsque l’une d’en être elle est une serveur, c’est une sacré limitation car on augmente la surface d’attaque. Des problèmes peuvent surgir au niveau partage et DCOM et quelqu’un à distance peut s’authentifier avec votre compte plutôt qu’en Guest. Par ailleurs, il faut se soucier d’avoir un compte en double avec un mot de passe similaire pour que cela fonctionne (on peut faire correspondre un compte de domaine, même user/password, à un compte local).

Option 2

L’option 2 est beacoup plus belle… Et beaucoup plus simple aussi (sauf si l’on se met à déplacer le répertoire utilisateur AppData sur le réseau. Nous préciseronts ce point par la suite).

L’astuce consiste à utiliser une seule et unique commande : un runas ! Mais attention, ce runas est lancé dans un mode spécial.

Pour rappel, le runas permet l’exécution d’un programme sous le compte d’un autre utilisateur. Il suffirait a priori de faire un runas en précisant Visual Studio et banco, le remote debugger et VS 2010 se retrouve dans le même domaine et, comme dirait Dora, c’est gagné !!

Malheureusement, ce n’est pas aussi simple. Si on effectue un runas classique en précisant un user sur un autre domaine, malheureusement l’application que l’on lance va s’exécuter avec un compte… d’un autre domaine… et ceci en local .

Bref, vous l’aurez compris, ce n’est pas possible puisque votre machine locale respectera les contraintes de son propre domaine et n’autorisera pas un compte extérieur d’un autre domaine à lancer un programme sur votre machine.

Nous souhaiterions non seulement pourvoir utiliser notre poste local, dans son domaine et ses crédentials, tout en faisant en sorte que les communications réseaux s’effectuent sous l’identité d’un autre compte.

Si nous vous disions que la commande runas a été modifiée en ce sens par Microsoft en lui attribuant l’option netonly ?

Pour preuve, notez l’appel suivant (ligne de commande) qui permet de lancer Visual Studio sous le compte local de l’utilisateur et qui fait en sorte que les appels réseaux s’effectuent avec un autre compte sous un autre domaine.

 

runas /netonly /user:domain\user « C:\localapp\Apps\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe »

Le programme vous lancera une invite de commande vous permettant d’indiquer le mot de passe.

Votre Visual Studio va se lancer sous votre propre compte, mais tout appel réseau se déroulera sous le compte/domaine ayant été précisé via la balise netonly.

 

Attention, un bug peut se produire.

Ce bug peut se produire si votre ordinateur local, un ordinateur d’entreprise, a été configuré pour que votre profil soit sauvegardé sur le réseau. Dans ce cas de figure spécifique, Visual Studio se connectera au partage réseau avec le compte fourni par /netonly et pas votre compte de domaine.

Il en résultera l’erreur suivante :

 

Don’t panic… Là aussi il y a une astuce, modifier dans la registry le répertoire AppData

Dans « HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders », il suffit de renseigner un répertoire local temporaire de votre machine. Pensez bien à modifier cette clé de registre après coup….

Pourquoi choisir l’option 2 vis-à-vis de l’option 1 ? Ou l’inverse ?

Parce que vous ne créez pas un deuxième compte et parce que vous ne modifiez pas les stratégies de sécurité locale des machines que vous souhaitez déboguer, l’option 2 est nettement plus intéressante que l’option 1. Une simple ligne de commande…

Toutefois, dans le cas d’un répertoire AppData sauvegardé sur le réseau, c’est une histoire de préférence car les 2 solutions ont leurs inconvénients et avantages. L’option 2 reste locale mais exige des modifications de clé de registre (ce qui est sensible pour un non averti). L’option 1 demande des modifications de part et d’autre, augmente le risque de sécurité, mais aucune action sensible en base de registre n’est requise… A vous de juger.

 

Comment deboguer à distance

Toute les possibilités de debug à distance sont maintenant activées.

Lancez Visual Studio, puis vous pouvez par exemple cliquer sur Debug, puis Attach To Process

 

 

Noter le qualifier. Il correspond au compte et à l’adresse de la machine sur laquelle on souhaite se connecter.

Plus précisément, on notera qu’il s’agit de l’adresse proposée par le msvmon (le remote debugger).

 

WinRM /WsManagement sans Powershell

WinRM est l’implémentation WS-Management de Microsoft.

Fonctionnant sur SOAP, cette technologie permet l’administration de machine à distance. WinRM est en version 2 pour le moment, fonctionne sur les derniers OS de Microsoft, fonctionne sur du Windows 2003 mais possède une limitation, il faut le SP2. C’est une sévère limitation si vous souhaitez utiliser Powershell v2 qui nécessite WinRM 2.0.

Il est classique dans l’écosystème d’un SI que des serveurs Windows ne soit pas dans les derniers services pack… Heureusement, Microsoft fournit depuis peu WS-Management 1.1 spécifiquement pour cet OS et pour Windows XP.
Il y a toutefois une limitation concernant Powershell. En effet, l’avantage de WinRM ne réside pas tant dans WS-Management que dans PowerShell qui vient directement s’interfacer à lui.
PowerShell 2 couplé à WinRM 2 permet l’administration de machine distante dans le nouveau langage de shell extensible de Microsoft.

Outils
L’installation de WinRM fournit 2 outils :
– winrm pour la configuration, le traitement de tâche WS-Management y compris à distance
– winrs, un client sur winrm

Astuces d’installation

L’installation de WinRM 2 et PowerShell 2 est très aisé sur des postes configurés classiquement, de simples clics et tout y est. Idem pour WS-Management 1.1.
Toutefois, un problème de taille peut subvenir lors de l’installation. En effet, WS-Management/WinRM impose l’activation du Firewall Windows sur les machines. C’est en soi une très bonne idée, mais en même temps un très gros problème pour les machines qui ne l’active pas ; reposant sur d’autres mécanismes.

Sur une machine où le firewall est activé, il suffit de lancer la commande 1 du tableau ci-dessous. Pour information, sur une machine Windows 2008 où WinRM est installé, cela se passera sans encombre. Dans le cas de figure où il n’y a pas de firewall, il faut exécuter les commandes de la ligne 2 du tableau ci-dessous (à l’exeption de la dernière).
Information cruciale, entre WinRM 1.1 (à comprendre WS-Management 1.1) et WinRM 2.0, il y a eu des changements de ports.
Dans la première version, tout s’effectuait sur le sports standard HTTP et HTTPS, à savoir 80 et 443. Dans la seconde version, les nouveaux ports sont 5985 et 5986. Dans une communication WinRM 2 vers WinRM 1.1 (ou dans l’autre sens), il faut penser à préciser les ports

Voici donc quelques commandes à connaître :

1 winrm quickconfig Permet la configuration de WinRM en ligne de commande. Démarre le service et créé les listeners associés. Démarre le firewall windows nécessaire au fonctionnement de WinrM
2 sc config « Windows Remote Management » start=auto
net start WinRM
winrm create winrm/config/listener?Address=*+Transport=HTTP
netsh firewall add portopening TCP 80 « Windows Remote Management »
Les commandes suivantes reproduisent plus ou moins à l’identique le fonctionnement de WinRM quickconfig (en pratique winrm quickconfig ouvre le port TCP 80 et 443, je ne l’ai pas détaillé ici) .
Si la commande WinRM quickconfig ne fonctionne pas, il y a de grandes chance que le Firewall Windows ne soit pas démarré.
On pourrait lancer ce dernier mais avec le risque suivant. Nous accédons aux machines distantes via RDP (mstsc).
Le démarrage du firewall pourrait couper la connection. Les commandes suivantes indiquent précisément ce que fait winrm quickconfig.Vous remarquerez la dernière ligne de nos commandes.
Avec winrm quickconfig, si elle plante, c’est comme si les autres n’avaient pas été exécutées.
Faite une à une en ligne de commande(à l’exception de la dernière si vous n’activer pas le firewall) , vous pouvez reproduire le comportement de winrm quickconfig ^^
3 winrs -r: http://machine76:80 -u:OtherDomain\JEAN-FRANCOIS -p:password ipconfig Lance la commande ipconfig sur la machine machine76. Dans notre exemple l’appel à lieu sur le port 80 car ladite machine est installé avec WinRM 1.1 (WS-Management 1.1).
Le port est ici précisé car le client winrs a été lancé à partir de la machine machine313 équipée de WinRM2.0. Sur une machine cliente WinRM 1.1, aucune précision n’aurait été nécessaire.
4 winrm set winrm/config/client @ {TrustedHosts= »machine313, foo,bar »} Ajoute les machines machine313 , foo et bar dans la liste des TrustedHosts (pas besoin d’authentification. Pratique pour de la communication inter domaine)
5 winrs -r: http://machine76:80 -u:OtherDomain\JEAN-FRANCOIS -p:password iisweb /start MONSITE Démarre le site web MONSITE sur la machine machine76 (Pour arrêter le site web, mettre /stop à la place de /start)
6 winrm enumerate winrm/config/listener Enumère les listeners sur WinRM. Cette commande permet de vérifier l’accessibilité à distance de la machine sur laquelle on l’exécute.
7 Winrm get wmicimv2/Win32_Service?Name=spooler Cette commande permet de vérifier que WinRm fonctionne en local. On demande l’état du spooler d’impression
8 winrm get winrm/config Cette commande permet de savoir la configuration de WinRM sur la machine sur laquelle il est lancé
9 winrs -r: http://machine313:5985 -u:Domain\user -p:password ipconfig Lance la commande ipconfig sur la machine machine313. Dans notre exemple l’appel à lieu sur le port 5985 car ladite machine est installé avec WinRM 2.
Le port est ici précisé car le client winrs a été lancé à partir de la machine machine76 équipé de WinRM1.1. Sur une machine cliente WinRM 2.0, aucune précision n’aurait été nécessaire.

En cas de problème
– Essayer de configurer le TrusteHosts sur les 2 machines devant communiquer

Monitorer la santé d’un site ASP.NET

Peu connu des développeurs et architectes ASP.NET, il est possible de monitorer son site web en production sans n’avoir rien à faire.
Quand je parle de monitorer, je ne parle pas ici de regarder les performances (il y a le perfMon et les compteurs de performances pour cela) mais de monitorer la santé de votre site web !

Je ne parle pas non plus de la santé du pool IIS dans lequel votre application est hébergée ; non, je parle de vérifier s’il n’y a pas des erreurs en production !
Des erreurs sérieuses, des messages qui ne devraient pas être présentés à l’utilisateur… Et s’ils apparaissent vous devriez être les premiers prévenus.

Après tout, c’est vrai, les erreurs arrivent dans l’observateur d’évènement, mais lorsque l’on a à faire à des équipes de production en intermédiaire (en gros, quand la structure à une certaine taille et qu’on ne fait pas n’importe quoi en laissant des accès à un développeur en prod), on ne peut pas voir cet observateur d’évènement.

Idéalement, on aimerait bien être prévenu par mail (si possible bien entendu, et s’il n’y a pas des firewalls quelque part qui bloquent et s’il y a un serveur mail d’accssible). Mieux, on aimerait bien tout mettre en base de données, histoire de pouvoir analyser tout cela à posteriori.

Et si je vous disais que tout cela est disponible !!! En standard !!!

Allez, je vous file une configuration pour les mails et je vous laisse farfouiller la documentation MSDN ;-)


                  
                        
                               
                  
                  
                        
                        
                  
                  
                                             
                               
                  
            



Jboss versus Glassfish


J’adore Jboss et depuis très longtemps. J’ai commencé à travailler avec une version 2.2.2 et ai connu le passage au clustering (v3) puis les migrations et évolutions successives. L’un des rares serveurs applicatifs que les équipes de production n’hésitent pas à déployer…
L’un des seul… Avec Glassfish ! Soutenu par Oracle (et Sun avant lui), parfaitement intégré à Netbeans, je le conseille fortement pour ceux qui veulent à partir de rien sur leur machine coder rapidement comme sur VS 2010 ;-)

Double-checked locking

Ce pattern, ou plutôt cet antipattern, est très bien connu des développeurs seniors, architectes ou tous ceux qui ont une passion certaines pour l’informatique et qui se sont penchés sur des problématiques d’optimisation en environnement multithread.

Je tiens à vous rappeler ici les principes de cet antipattern qui en réalité n’en est pas un en logique pur ! Que je m’explique, l’antipattern au sens où on l’entend classiquement, est  une violation des principes objets ou des  principes de design applicatifs. Pour l’avoir vécu, un feu EJB entity (je parle de ces bons vieux EJB entity BMP, CMP que JPA grâce à Hibernate a fini par tuer) qui appelle un EJB session est un antipattern. Pour ceux qui ne connaissent pas, on ne fait pas une couche d’accès aux données remonter au niveau de la couche de services.  Cela viole les principes de séparation des couches et de responsabilités. Cela peut également créer des  problématiques de référence circulaire contourné par des antipatterns encore plus affreux. Dans le cas des EJB entities, cela pouvait même amener des problématiques de performance…

Le double-checked locking, lui, ne viole aucun principe de design ou objet. Quelqu’un qui maîtrise le threading peut réussir à le mettre en oeuvre par pure réflexion, sans penser une seconde qu’il se trompe. Et le pire, c’est qu’il n’y a pas de problématique de raisonnement ; il faut simplement connaître le problème, sinon on ne le contourne pas.

Bon, de quoi parle-t-on ? Qu’est-ce que le double-checked locking ?

Pour le comprendre, commençons par créer un Singleton en Java

public class MonSingleton {
    private static MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null) {
            instance = new MonSingleton();
        }
        return instance;
    }
    // Méthodes
}

En multithread, un bug peut se créer au niveau du getInstance. Imaginons 2 threads, thread 1 et thread 2 qui se retrouvent en simultanée dans la méthode getInstance. Iml’ginons que thread1 soit juste avant l’appel à new MonSingleton que l’ordonnanceur donne le contrôle à thread 2. Il rentre dans la méthode getInstance, « instance » est toujours nul donc il rentre dans le if. L’ordonnanceur donne le contrôle à thread 1 qui fait sont new MonSingleton(), retourne ensuite une instance… Puis thread 2 s’exéute, créé son instance  et retourne donc un nouveal object, pas le même que thread 1. Nous n’avons donc pas créé un singleton en multithread. Pour info, ceci n’est pas obligatoirement gênant mais vous pourriez être dans un ccas de figure où ça l’est.

Comment éviter ceci ? Premier réflexe, utiliser synchonized en Java ou lock en C#.

public class MonSingleton {
    private static MonSingleton c = null;
    public static synchronized MonSingleton getInstance() {
        if (instance == null) {
            instance = new MonSingleton();
        }
        return instance;
    }

L’inconvénient de cette méthode, qui marche très bien, est qu’elle dégrade les performances. En effet, l’appel à getInstance se fait en série. Il n’est pas possible à 2 threads d’obtenir l’instance même si celle-ci a été créée.

Le double-checked locking peut alors être mis en place

public class MonSingleton {
    private static MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null {
              synchronized (Singleton.class){
                 if (instance == null) {
                      instance = new MonSingleton();
                 }
              }
        }
        return instance;
    }

Aucun problème de logique ici. On décale au plus tard la phase de lock et on ne synchronise que la partie qui nous intéresse. En faisant ainsi on pense avoir trouvé la solution idéale… Mais il y a un hic !! Ce hic est la façon dont fonctionne les compilateurs et les processeurs qui réordonnent les instructions. Les processeurs  utilisent également leurs registres pour accéder plus rapidement aux variables plutôt qu’en les lisant en RAM.La solution ne tient pas à grand chose. En C#(depuis le début) et Java (depuis Java 5), le mot clé « volatile » est la solution.

public class MonSingleton {
    private static volatile MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null {
              synchronized (Singleton.class){
                 if (instance == null) {
                      instance = new MonSingleton();
                 }
              }
        }
        return instance;
    }

Bug TF215097

Je suis tombé sur un bug assez étrange avec TFS aujourd’hui, l’erreur TF215097.

 

J’ai personnalisé un workflow TFS et créer des CodeActivities spécifiques pour pouvoir déployer des applications en fonction d’environnement. J’ai même équipé mon build de CustomEditor

 

 

 

 

Sauf que ça ne marche pas quand je lance. Ce qui est bizarre, c’est que cela fonctionnait très bien avant j’ai juste effectué des modifications mais tout à pourtant l’air ok.

 

 

Sous TFS 2005 tout était stocké au niveau de la définition des builds, dès TFS 2008 une partie a migrée en base… Et depuis TFS 2010, tout est en base de données. Pour s’en assurer, il suffit de se connecter à la base de données SQL Server de TFS pour votre Team Project Collection (attention, ne modifier pas cette base sinon c’est votre garantie qui n’est plus valide). La petite requête suivante fait apparaître la colonne ProcessParameters

 

Si on effectue la requête suivante…

… et que l’on clique sur le lien proposé, on obtient le résultat suivant (j’ai formaté les éléments)

 

 

On constate ainsi que seul les valeurs non par défaut sont sauvegardées en base. On remarque également que tout n’est pas à jour.

J’avais malencontreusement supprimé des paramètres, TFS n’arrivait pas à se configurer car ses paramètres de base de données ne correspondaient pas à mes paramètres…

La solution consisterait donc simplement à cliquer sur Refresh^^

Et voilà… Ca n’a pas marché… Ptdr !!! LOL x 1000 !!

Vous vous attendiez à ce que ça fonctionne du premier coup ? Allez quoi, dans la vie vrai de l’informaticien ça ne marche que rarement du 1er coup.

Je vous rassure, je ne suis pas taré (quoique…). Ce que je viens de vous expliquer plus haut correspond au problème que vous rencontrerez dans 99% des cas avec ce numéro d’erreur TFS.

Dans mon cas de figure, non seulement j’avais ce problème (et je ne l’aurais vu qu’après avoir réellement réparer mon autre  bug) , mais également un autre… Un tout bête… Un tout simple… Sauf que TFS ne nous indique pas clairement son erreur.

Mon assembly contenait non seulement des Code Activity mais également des editors comme je l’ai dit tantôt. Ces editors devaient récupérer des valeurs de paramétrage d’autres champs de mon Build Definition. Ne sachant pas initialement comment faire, je suis parti côté VsPackage et autres EnvDTE (ce qui n’est pas une bonne idée, car on a déjà tout avec TFS. Je vous expliquerai cela dans un prochain post).

Bref, ces ajouts ont des dépendances vers Visual Studio !! Or les Dll de Visual Studio ne sont pas installées sur vos serveurs de Build. Dans mon cas de figure, ayant trouver comment faire sans les VsPackage et EnvDte, il m’a suffit d’enlever ces références, de tout rebuilder et de tout « chek-iner » pour que cela fonctionne. Si je n’avais pas pu faire cela, si votre assembly possède des  dépendances, il suffit de les archiver en même tant que votre assembly dans le  contrôleur de source pour que le serveur de build les récupère.

 

Pourquoi j’attends Java 8…

Parce que s’il l’on fait du C#, que l’on parle en langage pur, il faut avouer que Microsoft a pris une belle longueur d’avance…

C’est mon point de vue, et je vous jure qu’il n’est pas pollué par des querelles de bas étage.

Java en terme de plateforme est juste gigantesque, sa communauté opensource est phénoménale, les frameworks, les outils disponibles et même les IDE n’ont pas de commune mesure côté Microsoft même si c’est en bonne voie.

Côté langage, que de retard !! Assurément parce que le JCP exige d’avoir plusieurs interlocuteurs, mais pas seulement.

Le rachat de Sun par Oracle… Probablement.

Mais aussi cette confiance sans faille dans un langage… Pour attendre la version 5 pour lui amener quelque chose de véritablement nouveau. Merci à Microsoft sur ce point. Je suis heureux que Java soit sorti de sa torpeur. Vivement Java 8 pour ratraper ce retard face à C# 4… Et vivement Java 9 pour valloir ce que promet C# 5… Voire mieux ; c’est tout ce que je lui souhaite …

Stylecop, Fxcop et compagnie

La qualité de code ne doit pas être laissée à la légère… Pour être franc avec vous, c’est un peu l’hopital que si fout de la charité. Plus précisément, c’est « faîtes ce que je dis, pas ce que je fais ».

Je n’avais pas prévu d’utiliser ce blog pour faire mes confessions intimes, mais maintenant que j’y suis…

Bref, la qualité de code est l’affaire de tous. A quoi ça sert ?

Et bien disons que lorsque l’on  programme, sauf si on le fait pour soi, et que pour soi, il faut absolument commenter son code et faire en sorte qu’il puisse être repris ! Ca ne marche assurément pas à tous les coups car il arrive parfois, lorsque l’on utilise des concepts avancés, que propre ou non, commenté ou non, la section de programme que l’on réalise est juste « compliquée » ; on la documente comme on peut sans pour autant arriver à quelque chose d’idéal.

Architectes de SI

Passionné d’informatique et de plusieurs autres choses que je passerais sous silence :-)… J’ai enfin décidé de créé mon blog technique.

Pour quoi faire ?

 Et bien parce qu’il n’en existe pas !!!

Quoi ? Je mon trompe ?

Il en existe beaucoup

Je ne suis probablement pas doué avec Google alors… A moins que je n’ai mal cherché…

Ok, ok, j’avoue tout… C’est tout simplement pour poster toutes les choses, c’est-à-dire, techniques, logiciels, progiciels que je peux croiser… Mais également bout de codes, expertise et conseil que je peux prodiguer dans mon travail

Qui suis-je ?

Un architecte technique, évidemment… J’aurais pu être plombier, commerçant ou encore infirmier… Mais je ne suis pas certain que j’aurais pu parler aussi bien de technologies comme JEE, .NET, WCF, EJB, de langages tels C#, Java, C++, Ruby, d’outils comme les ETL, les EAI, la Business Intelligence, etc. Car tout ceci fait parti de mon environnement quotidien…

Plus de détail ?

C’est que vous êtes curieux quand même !! Mais bon, je me plie à l’exercice de bon coeur !! Personne ne m’a forcer à faire un blog :-D

Mon prénom est Fabrice et mon nom de famille JEAN-FRANCOIS… Et on peut s’amuser avec. M’appeler Fabrice, Jean ou encore François, faire des mélanges, réordonner !!! C’est ça lorsque son nom est composé de prénom dont un qui est composé (vous suivez encore ?).

Quel âge ?

L’âge de la raison !!! Mais non pas 7 ans… Quoique… Bon, disons que j’ai dépassé les 30… Même la moitié de la 30aine… Mais je n’en dirais pas plus !! JE NE DIRAIS RIEN !!!

Je bosse où, je vais quoi ?

Je travaille 5 jours sur 7, parfois 6 sur 7, voire 7 sur 7 quand il le faut… Chez… Chez… Asset !!! Vous ne connaissez pas ? C’est probablement parce que vous n’êtes pas ingénieur informatique, consultant maîtrise d’ouvrage ou expert dans la finance.  Asset  , connu autrefois sous le nom d’Asset-Technology , est l’un des grands spécialistes de la place parisienne dans les marchés financiers. Beaucoup de sociétés ont des branches finances, mais peu sont véritablement dédiés. La société a fusionné avec Talan, un spécialiste de la prestation de services dans le domaine des nouvelles technologies…

J’arrête là, on va me taxer de pub :-D. Mais si ça vous intéresse, je vous conseille d’aller y jeter un coup d’oeil. Le groupe Talan en général et Asset Talan Group en particulier sont tout simplement des entreprises où il fait bon travailler…

Je m’égare, je m’égare. Et moi dans tout ça ? Et bien je suis , côté expertise technique. Je vais encore jeune sur ce lien, j’ai un poil vieilli (mais pas dans ma tête, c’est l’essentiel). Si vous savez lire (je pense que oui, sinon vous ne seriez pas à cette phrase), je suis consultant manager. Pour faire bref, je suis consultant, expert en technologie avancé… Et manager car je manage d’autres consultants, junior ou senior dans leur problématiques techniques et pour leur suivi de carrière en général. Enfin, par ailleurs, je suis co-responsable du système d’information de la société…

Architecte technique, c’est clair. Des missions d’expertises sur des sujets plus ou moins ardus. Mettre en place des outils, architecturer des logiciels, penser aux problématiques de sécurité, de performance, d’entropie du système d’information, maîtriser les processus d’ingénierie logiciel dans leur exemple, connaître des technologies de développement, savoir les appliquer, exceller en la matière pour pouvoir accompagner. Le multithreading, la répartion de charge, le transactionnel, la gouvernance d’entreprise.

Et on peut s’amuser !! Quelques exemples de termes ! CMMI, XP, FDD, SCRUM, MTS, COM+, CORBA, RMI, IIOP, JMX, WPF, WWF, C++11, FLEX, SOA, Silverlight, C#, Java, JMS, MSMQ, ITIL, SPICE… LOL, c’est un vrai bordel l’informatique en fait :-D

Que va-t-on trouvé dans ce blog ?

Et bien un peu tout et n’importe quoi sur tous ces sujets (sachant que j’en ai cité qu’une goutte d’eau :-P)… Si d’autres architectes, ingénieurs ou passionnés d’informatiques, sont intéressés par le sujet… Come here, avec grand plaisir ^^