Techno vs Livrable
Constamment confronté devant les deux aspects: Livraison en urgence et utilisation de la techno, je me questionnais à savoir pourquoi autant de projets informatique pouvaient souvent dépasser les délais, et même être abandonné. Est-ce là un problème causé par des chefs de projets trop ambicieux qui proposent des temps de livraison que les équipes de développement ne peuvent assumer ce sous des besoins fonctionnels plus ou moins clair ? Où est-ce que ce sont les équipes de développements qui s'attardent trop souvent à la beauté de l'utilisation de la dernière techno et de toute les "best practices" à la mode ?
Je crois que la prise de conscience doit se faire des deux côtés. Un bon chef de projet, sera à l'écoute de son équipe de développement, et saura bien guider son client afin de lui donner l'heure juste sur la charge de travail possible afin d'en arriver à répondre aux différents besoins du client.
Par ailleurs, une bonne équipe de développement, saura ce poser les questions suivantes: Qu'elles sera la méthode de travail qui nous permettra de pouvoir réellement fournir un gain sur l'échéancier du projet tout en livrant un produit de qualité ?
Ou est-ce que trop souvent les équipes tombent dans le piège de faire de faire de la techno pour faire de la techno sans ce préoccuper de répondre aux besions clients ?
La valeur d'un candidat ?
Qu'elle est ma valeur sur un marché ?
C'est une question que l'on peut souvent se demander, lorsque nous sommes en processus de recherche d'emploi, et même chez un employeur. Qu'elles sont les facteurs qui peuvent influer sur notre valeur sur le marché technologique. Comme une pièce de viande chez le marché, notre valeur flutuera en fonction de l'offre et la demande pour certains types de compétences technique, certe. Nous sommes loin de cette époque de bulle techno qu'il y avait jusqu'en 2001-2002.
Qu'est-ce que les compagnies recherche d'abords et avant tout d'un profil d'un programmeur ? Est-ce un candidat devant connaitre sans cesse les nouvelles technologies sous toutes ses coutures ? Ou plutôt un candidat ayant une connaissance général, maitrisant différent domaine d'expertise cerné et étant au fait des prochaines technologies ?
En ce sens, est-il juste de sans cesse d'exiger de la part de nos chefs de projets et de la direction que les projets utilisent les dernières techno, sous peine que l'équipe de développeur perdre de la valeur, sur un marché en constante évolution, au sens du sujet "Ressources Humaine" ? Tout est une question de rentabilité sur une période de temps estimé...
Je pose ces questions, parce qu'avec les dernières évolutions des languages de ces dernières années, il est facile d'être dépasser par ces connaissances. Est-ce qu'il est Humainement possible de nos jours de maitriser toutes les dernières évolutions d'un languages ou plutôt d'une technologie, ce tout en ayant une vie. Un des exemple que je puisse avoir est celui du passage .Net 2.0 à .Net 3.5. Microsoft avait fortement amélioré le .Net Framework et lancé de nombreuses nouvelles "façon" d'utiliser les possibilitées technologique.
Pour en revenir à la question de départ: Qu'elle est ma valeur sur un marché ?
Je dirais que notre réelle valeur sur ce marché, passerait par la combinaison de nos différentes expériences personnel et professionnel. En oubliant l'aspect des technologies, toutes ces expériences de vie (quotidienne et professionnel) forge un caractère et nous amène a penser d'une certaines façon dans notre travail, l'attitude. Des attitudes ou plutôt des aptitudes à l'ouverture d'esprit et la capacité de savoir remettre en question le travail et savoir comment faire face aux différents problèmes sans stress.
N'ayant pas la science infuse, le débat est ouvert...
Common Intermediate Language (CLI ou MSIL) Pourquoi ?
Pourquoi développer une fonctionnalités en Common Language Intermediate, soit du CLI, anciennement nommé Microsoft Intermediate Language ?
C'est un peu la question que j'avais, lorsqu'un collègue m'avait proposer lorsque nous avions évalué notre Assembly. Je connaissais la signification de MSIL, soit le langage Natif .Net. Language qui est interprété par le runtime .Net, mais j'en avais jamais fais auparavant.
La problématique, étant de concevoir un lanceur d'appel de méthode X tout en étant en mesure de pouvoir avoir un "feedback" au début et à la fin de l'appel de la méthode X. Par réflection, le système était devenue tout simplement lourd et non maintenable... mais le besoin était toujours présent, celui d'être dynamique.
La solution ? Développer notre Assembly pour notre besoin en code natif, en CLI.
Schéma du CLI:
"Compilation en MSIL
Lors d'une compilation destinée à produire un code managé, le compilateur convertit le code source en langage MSIL (Microsoft Intermediate Language), un jeu d'instructions indépendant du processeur qui est converti efficacement en code natif. MSIL inclut des instructions pour le chargement, le stockage, l'initialisation et l'appel de méthodes sur des objets, ainsi que des instructions pour la réalisation d'opérations arithmétiques et logiques, le flux de contrôle, l'accès direct à la mémoire, la gestion des exceptions et d'autres opérations. Avant d'exécuter du code, vous devez d'abord convertir le langage MSIL en code spécifique du processeur, généralement à l'aide d'un compilateur JIT (Just-In-Time). Dans la mesure où le Common Language Runtime fournit un ou plusieurs compilateurs JIT pour chaque architecture d'ordinateur qu'il prend en charge, le même jeu de MSIL peut être traité par un compilateur JIT et exécuté sur toute architecture prise en charge.
Lorsqu'un compilateur produit un code MSIL, il génère aussi des métadonnées. Les métadonnées décrivent les types contenus dans votre code, y compris la définition de chaque type, les signatures des membres de chaque type, les membres référencés par votre code, et d'autres données que le runtime utilise au moment de l'exécution. Le code MSIL et les métadonnées sont stockés dans un fichier exécutable portable (PE) qui est basé sur le fichier Microsoft PE publié qu'il prolonge et sur le format COFF (Common Object File Format) utilisé traditionnellement pour le contenu exécutable. Ce format de fichier, qui accepte le code MSIL ou le code natif ainsi que les métadonnées, permet au système d'exploitation de reconnaître les images du Common Language Runtime. La présence de métadonnées dans le fichier en même temps que le jeu d'instructions MSIL permet à votre code de se décrire lui-même, ce qui signifie que les bibliothèques de types et IDL (Interface Definition Language) ne sont pas nécessaires. Le runtime recherche les métadonnées dans le fichier et les extrait selon les besoins, au moment de l'exécution."
Source: http://msdn.microsoft.com/fr-fr/library/c5tkafs1(VS.80).aspx
Fort malheureusement, les resources fiable sur Internet sur le développement CLI (MSIL) sont très limités. En voici une qui m'aura été très utile: http://www.thefreakparade.com/2008/06/baby-stepping-into-msil-creating-an-event-recorder-using-a-dynamicmethod-and-reflectionemit