eric.lemerdy

Aller au contenu | Aller au menu | Aller à la recherche

mardi 9 septembre 2008

Aperçu sur IBM Rational Team Concert

jazz.net: l'indispensable site d'information sur la plate-forme.
jazz.net/blog : le blog de l'équipe dont le leader est actuellement Erich Gamma (l'un des co-inventeurs des Designs Patterns, excusez du peu)
L'équipe à l'origine de jazz est aussi celle qui a vécu le développement d'eclipse. L'IDE étant un succès et quasiment un sujet clos, l'idée du repository central était le dernier sujet à implémenter chez Rational. Ce fut pour cette équipe l'occasion de faire persister la même ambiance d'équipe ainsi que la collaboration avec des entités extérieures. Au sein d'IBM, les équipes qui testaient les premières version de jazz sont longtemps restées isolées pour maintenir le "secret" autour du projet, une façon de protéger les équipes de développement afin qu'elles puissent donner le meilleur d'elles mêmes.
Côté bonnes nouvelles, RTC est une application eclipse RCP mais basée sur les bundles eclipse.org et non pas ibm.com.
RTCabout.png
Ce qui permet d'utiliser dans RTC des plugins compatibles Eclipse.
Pour l'auditoire orienté 'management' ou les clients finaux, l'application web a beaucoup séduit. En effet, l'organisation de l'application lourde sera réservée aux développeurs habitués à eclipse tandis que l'application web assez soignée permet de bien visualiser les métriques et les indicateurs. A noter que les dashboards ne sont pas inclus dans la version express.
blog-dashboard1.png
Au niveau du scope, la solution est clairement adressée aux PME et aux petites équipes. RTC adresse la phase de développement : la gestion des changements, la gestion de configuration, la collaboration et la gestion du build continu. L'outil est fonctionnellement déjà puissant. Mais comment fournir de si nombreuses fonctionnalités sans tomber dans les travers de l'usine à gaz ? IBM avait en effet du mal à recruter des consultants capables d'installer et de configurer ses produits ! La lourdeur des produits était un handicap à leur adoption. L'idée derrière RTC est que si l'on ne peut pas convaincre avec des produits certes puissants mais trop lourds, il faut alors simplifier et rendre accessible sa technologie en repoussant les limites de l'utilisabilité. Les "early adopters" semblent conquis mais il s'agit déjà d'aficionados d'eclipse et autres experts des plug-ins. Etant moi-même développeur d'application RCP, j'avoue avoir trouvé le produit assez affuté.
Tout l'enjeu de RTC sera de poser des concepts suffisamment simples et consensuels (work items, stream, etc.) afin que leur implémentation dans l'outil ne reproduise pas les lourdeurs des produits maison dont il est l'héritier.

vendredi 22 août 2008

TDR Applied

Last week, we used TDR[1] to help us understand a problem and the solution finally emerges.

The problem

This is an eclipse RCP application that uses the well known MVC pattern. The data model is hierarchic and several editors can be opened at different levels. The problem is that we have some transversal data that can be viewed along the tree structure. How can a view be always updated against users editions ?
Considering the following structure:
  • root
    • node1 - use transverse data X, Y
    • node2 - use transverse data X, Z
Description of the scenario:
  1. Editor on node 1 is opened
  2. Editor on node 2 is opened
  3. Some changes are made in editor 1 on transverse data X
    The editor is "dirty".
  4. Some changes are made in editor 2 on transverse data X
    The editor is "dirty".
  5. Editor 1 is saved.
How can the changes on transverse data X made in the first editor be reflected in the second one ?

Solving the problem

We shortly came to the fact that an event should be fired when the data model is changed. Editors are registered to listen for those events to make them aware that they should reflect changes. This is not the complicated part of the problem.
The "reconciliation" algorithm that the editor should implement is not trivial.
This was the time to stop trying to code it, step up the team in front of a blank white board and use TDR[1] to help us specify with some examples.

The white board

After a short discussion, we found a notation to represent data attached to an editor:
Saved
saved data before any edition
Modified
modified data during edition. This is typically a bean that is tied on UI components
Data model
the new data model that is embedded in the event to alert editor that data changed
Output
the output of the algorithm: the reconciliated data
(Our data are indexed list of objects.)
Then we started to scratch on white board. The white board has been "saved" on this sheet:
TDR_applied.png
Then we set up test cases from simple to complex (1.). For each of them, we specify data (2.) as couples: CA, DA (Clé (key), Data) and CA', DA' for modified data.
The final algorithm emerges in the box (3.). The result is simple:
  • if the "Saved data" is the same than "Modified data"
    • "Output" should be set to "Data model"
  • otherwise
    • "Output" should be set to "Modified data"
Big letters in output column learns us that algorithm applied for list comparison can be also be applied for list elements themselves when the case become more complex.

Lesson learned

  • TDR[1] is helping emerging conception
  • Examples from a TDR[1] session are capitalized in unit tests (in our case)
  • This TDR[1] session became the technical documentation (because the client want a technical documentation)
  • Our examples remains generic because we found it useless to represent real data (a collection of objects
  • TDR[1] is helping to make the implementation of a solution simpler
  • The client were intrigued to see programmers out of their usual 'behind-the-screen' position ! It helps our team to show what we were working on.


[1]: Test Driven Requirements ou spécifications dirigées par les tests.

mardi 29 juillet 2008

Overview of Eclipse RCP UI testing tools

-All datas collected during Summer 2008-
Product Type Licence Source Status
Abbot framework (AWT/SWT) open source Sourceforge alpha for SWT (but seems pretty stable)
Costello recorder (AWT) open source Sourceforge not ready for SWT
GUI Dancer recorder commercial Bredex GmbH new version in july 2008
JDemo framework open source Sourceforge 2008
Mercury WinRunner recorder commercial Mercury End of support (feb 2008)
QF-Test recorder (XML/Jython) commercial Quality First Software GmbH - Kapitec (FR) 2008
Rational Functional Tester recorder commercial IBM
SWTBot framework (SWT) open source ThoughtWorks not fully SWT compatible but ThoughtWorks can be considered as trustable.
TPTP Automated GUI Recorder (AGR) recorder (XML/Java) open source Eclipse.org maintained ? but "as-is" component
WindowTester hybrid (java) commercial / free for opensource commiters Instanciations high quality product
This matrix is based on this article from the WindowTester architects ; this product list is enforced with the following post comments where people chat about their uses.
Feel free to visit the del.ico.us links where I store framework's related ressources on the fly. I am working on this subject until a satisfying product can be identified, so I will add some new links soon (screencasts and tutorials are the forthcomming waited material). I am glad that the Eclipse community is doing a substantial effort in 2008. For exemple, there was less submissions on this subject for EclipseCon2007 last year.

lundi 28 juillet 2008

De retour de la session TDR

En avant première, Gilles Mantel a réuni les praticiens de Paris ce soir pour nous faire partager sa session "Test-Driven Requirements: beyond tools" qu'il donnera le 5 août 2008 à Toronto à l'occasion de la conférence Agile 2008.
A travers deux expériences ludiques et leurs rétrospectives, il nous montre en quoi les exigences dirigées par les tests peuvent aider les clients à obtenir avec moins d'efforts ce qu'ils veulent vraiment.

TDR - Le jeu

Le premier jeu montre la distorsion du besoin initial exprimé par le client lorsqu'il passe par un cycle de développement d'un produit:
TDR.png (src)made with the lego tag in openclipart.org
Le produit est ici un parcours de billes et de dominos que seuls les utilisateurs vont pouvoir bâtir. Le 'product owner' (ou client) fait alors son apparition et doit étudier le modèle. Le développeur entre à son tour et doit reproduire le modèle sur les seules indications orales du product owner qui ne voit bien sûr pas le travail en cours du développeur. Le testeur doit quant à lui écouter les informations et c'est lui qui qualifie la livraison finale du développeur aux utilisateurs.

TDR - Expérimentations

Le second jeu permet au public d'expérimenter l'expression de besoins et les spécifications par les tests:
Un memo vient de tomber: une idée géniale a germée dans le service R&D et il faut recueillir ce besoin et le spécifier le plus efficacement possible afin d'intégrer cette idée au système d'information de la société ! Une réunion est donc organisée entre le porteur du message et l'équipe d'analystes et de développeurs réunie pour l'occasion.

Par l'expérimentation sur ce cas concret, on adopte intuitivement une démarche ou chacun est poussé à griffonner sur son papier pour comprendre le problème. Une fois le problème mieux cerné, on cherche à trouver un accord sur le formalisme à employer pour la spécification et les tests associés (les exemples de cette spécification). C'est un exercice enrichissant qui laisse le formalisme émerger à la différence des tests fonctionnels actuels où un outil en impose souvent la forme (par exemple des tableaux pour FIT ou du texte illustré d'exemples pour Concordion).

Je suis toujours enthousiaste après les réunions des praticiens. C'est un groupe où l'on découvre toujours énormément de choses par la pratique, une expérience toujours unique. Merci à Gilles qui va pouvoir assurer une animation au top niveau à Toronto.

vendredi 20 juin 2008

Technology Readiness Levels

A l’extérieur de votre organisation est le chaos, les technologies naissent et meurent en fonctions de facteurs incontrôlés et incontrôlables (les effets de mode, la réglementation en vigueur, la volatilité des marchés, etc.).
A l’intérieur de votre organisation règne l’ordre, la maîtrise technologique, mais c’est aussi le royaume du « legacy-qui-marche-bien-pourquoi-on-le-changerait ». L’obsolescence des applicatifs vous guette, vous êtes fan des nouvelles technologies mais l’entropie de votre organisation ressemble à des sables mouvants qui ensevelissent toute action pour tenter d’y échapper. Comment alors stabiliser la technologie alien qui serait propre à sauver votre organisation de la décrépitude numérique ?
Il existe pour cela la méthode des Technology Readiness Levels (TRLs) pour vous sauver. C’est une méthode qui permet d’évaluer une technologie nouvelle pour la qualifier apte à supporter le développement de vos nouveaux produits. Voici les degrés d’avancement de la méthode (Origine: DOD (2006), Defense Acquisition Guidebook) :
  • TRL 1: Principes de base observés et signalés
  • TRL 2: Concepts et/ou applications de la technologie formulés
  • TRL 3: Fonction critique analysée et expérimentée et/ou « proof-of-concept » la caractérisant
  • TRL 4: Validation de l’artefact produit en conditions expérimentales
  • TRL 5: Validation de l’artefact produit en conditions de pré-production
  • TRL 6: Démonstration du modèle du système/sous-système ou du prototype en conditions de pré-production ou de production
  • TRL 7: Démonstration du prototype du système en conditions de production.
  • TRL 8: Complément du système résultant et « qualification » pour la production à travers des tests et des démonstrations (environnement de pré-production ou production)
  • TRL 9: Exécution du système résultant « prouvée » à travers le succès de la version en production
NASA_TRL_Meter.jpg Plus on avance dans la méthode et moins on doit avoir de technos candidates qui passent les conditions nécessaires. C’est un peu comme cela que fonctionnent les organismes de recherche qui ne font pas aboutir toutes leurs recherches avec une application fonctionnelle et encore moins industrialisable.
Cette méthode a été développée par la NASA. J’ai adapté les termes à un produit logiciel. Par exemple, citons cette analogie : leur environnement de pré-production est le sol et celui de production de l’espace. Je pense que si c’était le cas en informatique, il y aurait sûrement plus de candidats à aimer la prod…
Ce processus est « outillé ». Un calculateur d’avancement réalisé avec Excel permet de suivre l’avancement au sein de la méthode. Attention, les couleurs piquent un peu les yeux… On peut décider de s’évaluer au choix avec le TRL, le Manufacturing Readiness Level et les Programmatic Readiness Level. Cela ajoute plus ou moins de questions au formulaire pour calculer l’avancement.
Voici la fiche de ce programme excel à télécharger (et sa documentation pdf - 16 pages)
TRL_Calculator.png
Cette méthode est utilisée dans la société de ma mission actuelle comme base au processus de travail de l’équipe R&D. Ils ont des jalons à chaque degré avec des documents types à produire. Cette méthode qui a fait ses preuves aide effectivement à atteindre l'objectif qu'elle se fixe. On ne peut malheuresement pas tout rendre agile. Par contre l'agilité peut permettre de gagner en rapidité sur les "proof-of-concept" ce qui peut augmenter la taille de l'échantillon des technologies candidates et ainsi renforcer la fiabilité et la pertinence du choix final.

jeudi 15 mai 2008

ParisJUG - Productivité, Maven

productivité des développements

Productivité des développements Java

On pourrait résumer la session de Guillaume Duquesnay ainsi : la productivité des développement Java, ou comment adopter des pratiques qualité sans prononcer ce mot qui fait peur.
Une démonstration des tâches avilissantes et peu créatrices de valeur auxquelles s'est plié chaque développeur dans sa carrière au moins une fois a été exécutée par l'orateur. Il a expliqué que pas à pas, on peut améliorer la productivité de tous les membres de l'équipe. Simplement en étant à l'écoute des souffrances et des plaintes, on détecte les failles du processus de développement à corriger.
En effet, la productivité ne devrait pas être vue comme un mot taboo, mais devrait pouvoir remplacer dans la vision des managers le centre de coût que représente la qualité en une source de valeur. Là où le mot productivité dans l'industrie classique est associé à l'augmentation des cadences de travail, pour le développeur, cela rend son travail quotidien moins laborieux et plus agréable.
Du point de vue pérénité de la démarche, les procédures de qualité sont les premières pratiques à être abandonnées lorsque les contraintes projet se tendent. On peut penser au contraire que les pratiques visant a améliorer la productivité sont adoptées pour de bon.
pragmatic.jpg

Clés du succès

  • pas de religion : ne pas croire aux miracles : la solution universelle n'existe pas. Au contraire, les solutions d'amélioration de productivité doivent être adaptées au niveau de maturité de l'équipe.
  • pas de révolution : un changement progressif à petits pas est le garant de l'adoption des pratiques.
  • pas de procrastination : les tâches d'amélioration de la productivité ne doivent pas être remises à plus tard, l'expérience montre qu'on perd plus de temps à continuer une pratique improductive que de passer le temps qu'il faut à la résoudre.
J'ai retrouvé dans cette présentation une mise en pratique de nombreux conseils lus dans le livre : The Pragmatic Programmer: From Journeyman to Master. Paru il y a un peu moins de 10 ans déjà, la démarche décrite reste d'actualité et est en accord avec le discours de Guillaume.

maven à la demande

Une scéance de réponses aux questions préalablement posées par les inscrits à Arnaud Héritier.
Ce qui m'a particulièrement étonné dans l'intervention d'Arnaud fut la coloration très "commerciale" du discours. On pouvait entendre notamment les termes : Concurrence, challenge, rester sur ses acquis, niveau de service ergonomique. On a plus l'habitude d'entendre ça de la part de commerciaux ! Le cliché du développeur open-source s'est envolé immédiatement.
Il a aussi évoqué les problèmes relationnels au sein du projet. J'ai toujours supposé qu'il pouvait y avoir des tensions au sein d'une communauté Open-source. Avec maven, on est servit : un chef despotique et intransigeant (Jason van Zyl), des sociétés rivales qui se créent... Arnaud lui-même a parlé de projet à la Dallas ; ne mentionnons pas le terme "jasonification des équipes" qui m'a fait bien sourire.
filthyrichclients.jpg Il a rappelé que l'influence des entreprises est vraiment non négligeable. En effet, comment rivaliser contre des personnes qui travaillent 8h rémunérées sur le projet là où les développeurs bénévoles donnent deux heures de minuit à 2h pas très frais (attention, cliché ;-) ). Ce fut l'objet de ma question (qui m'a vallu le livre Filthy Rich Clients offert par ParisJUG et dédicacé par Chet Haase) sur ce qu'apportait au niveau personnel à Arnaud sa participation à ce projet. Pour lui, le moteur premier est la récompense d'avoir trouvé une solution satisfaisante au problème du build.
Côté infos, j'étais venu pour me renseigner sur un support du build des plug-in eclipse par Maven. Arnaud nous a renvoyé vers l'expert maison Carlos Sanchez qui a exposé ses slides durant 2h sur le sujet à la dernière eclipsecon.
Je résumerai également la rivalité des deux projets qui entrent en concurrence pour devenir le plugin de référence apportant (enfin) le support de maven dans eclipse. Notez qu'IBM a toujours mis des bâtons dans les roues à maven pour s'intégrer (à la différence d'IntelliJ ou NetBeans dans lesquels maven est très bien supporté). Ils utilisaient ant et ne voyaient pas de raisons d'en changer.
Q4em2eclipse
+ support WTP+ support WTP
pas JasonJason
+ ergonomie- peu intégré
+ support eclipse 3.3 (sous modules maven = sous projets eclipse)+ support de Nexus (indexation artefacts)
La course est féroce entre les deux projets qui sont au coude à coude. Impossible pour l'instant de les départager... Comme toujours dans ce cas là, les essayer et juger par soi même.

Une session très intéressante, encore un succès pour ParisJUG.

lundi 12 mai 2008

XP Days France 2008 : En vrac

Voici un tour d'horizon du web une semaine après le grand succès des XP Days France 2008 (ordre chronologique) :
  • Photos Flickr : tag xpday : un peu facile ce lien là, mais toujours fructueux...
    Voir aussi l'album Flickr très riche de Yannick Ameur.
  • eXtreme-Programming, 2ème édition : Emmanuel Chenu nous présente l'eXtreme Programming dans le magazine Programmez. J'en profite pour vous conseiller son blog très bien illustré.
  • XP Day France 2008 : Day 1 : Le parcours d'Anthony sur sa première journée, post bloggé au fil de la journée et dans le tram sur le chemin du retour !
  • XP Day France 2008 : Day 2 : La seconde journée d'Anthony aux XP days : un bon retour de son éxpérience pendant cette conférence.
  • Soyez aussi sérieux que des enfants qui jouent : Xavier de Labouret nous livre un billet utile pour approfondir son expérience après sa participation au leadership game (S851).
  • XP Days France 2008 part 1 - Games : Pascal Van Cauwenberghe nous rend compte (et en photos) de sa participation en tant qu'animateur sur les sessions interactives du premier jour. Au XP Game, il a joué le rôle de client pour assister Olivier Lafontan qui courait dans tous les sens pour arréter les chronos !
  • XP Days France 2008 part 2 - Interviews : Seconde partie du compte -rendu de Pascal sur la méthode "9 boxes"
  • XP Days France 2008 part 3 - Space Game : Troisième et dernier retour de Pascal sur son "Space Game". Portia et lui sont vraiment originaux et leurs sessions ont vraiment eu beaucoup de succès.
  • XPDay France: Une rétrospective : Une rétrospective illustrée d'une photo sur l'ambiance des XP Days par Portia Tung.
  • XP Day France 2008 : Jean-Michel Garnier livre sa présentation sur RSpec. C'est un post enthousiaste sur l'avenir de Ruby on Rails en France et la communauté agile.
  • Spring TDD : les ressources de la démonstration de Jean-François Hélie sur Spring TDD
  • (Feed)Back from XP Day France 2008 : Gilles Mantel nous adresse son feedback sur l'événement : un très bon résumé !
J'ai utilisé Yahoo pipes pour aggréger les blogs sur les XP days : flux XP Days france 2008.
Si j'ai oublié des retours, vous pouvez également consulter ce widget qui recherche dans les blogs : Add to Netvibes

mardi 29 avril 2008

Découvrir Windows PowerShell

powershell.png
Petit sondage :
Qui travaille sous Microsoft Windows ?
- tout le monde ?
Qui a besoin de cmd.exe ?
- tout le monde (maven, scripting, etc.) ?
Qui trouve l'invite de commande facile à utiliser ?
- personne ?
C'est par ce rapide sondage qu'a commencé la démonstration de Cédric Rup sur la nouvelle console de Microsoft : le PowerShell.

En effet, en novembre 2006, Microsoft réagit en sortant la première version de sa nouvelle interface d'administration ultime. Il ne s'agit pas d'une interface graphique très recherchée, mais bien d'un nouvel interpréteur de commandes.

Pour télécharger la dernière version, vous devez posséder le framework .NET installé sur votre machine, et télécharger l'installation du PowerShell. Juste après cette installation, vous pourrez tester l'exécution de ces commandes bien connues :
dir
cd
ls
Surprise, les alias des commandes unix fonctionnent !
Pour avoir de l'aide en ligne sur la commande dir par exemple :
dir -?
Avec PowerShell, une commande s'appelle une commandlet. C'est l'unité de base du scripting. Il y en a 129 de base. La syntaxe est une convention : VERBE-NOM -argument param. Par exemple, la commande dir est un alias de : Get-ChildItem -Path ..

Fonctionnalités

  • Complétion sur les arguments (tab)
  • Trouver les alias d'une commande. Ex. : Get-Alias dir
  • Gestion des variables.
    Ex. :
    $dir = Get-Children
    $dir // évalue la variable
    
  • Tout est objet (là où tout est chaîne de caractère en shell unix.
    Ex. :
    $dir.* // <- utiliser la complétion pour lister les
              variables d'instance de l'objet (ses pro-
              priétés)
    $dir.getType() // on a bien affaire à un objet .NET
                      !!! avec l'accès a ses méthodes
  • Le pipe est un flux d'objets.
    Ex. :
    $dir | Get-Member // permet de lister les variables
                         d'instance de l'objet en les
                         faisant passer à travers le
                         pipe.
    // démarrer plusieurs instances de notepad
    Get-Process -Name no*
    (Get-Process -Name no*).Kill() // termine les pro-
                                      cessus notepad par
                                      appel de la mé-
                                      thode kill.
    Get-Process no* | Stop-Process // termine tous les
                                      processus notepad
                                      en passant par le
                                      pipe.
    
    Avantage : Le pipe crée un flux d'objets et n'attend pas que la liste soit totalement instanciée. Alors que l'instanciation d'une variable stocke l'objet en mémoire.
    On peut passer du code dans un pipe (inspiration perl) : c'est une méthode anonyme. Ex. :
    Get-ChildItem | Where-Object { $_.Length -gt 1Mb }
    // La variable $_ est l'object considéré lors de
       l'itération sur les résultats.
    
    On peut trier avec Sort-Object
    On peut grouper sur une propriété avec Group-Object Par exemple pour afficher les fichiers groupés par extension.
  • Il y a un certain nombre d'arguments en commun sur les objets .NET donc auquels on a naturellement accès par Power Shell:
    verbose, debug, ErrorAction (que faire en cas d'échec, voir la variable $ErrorActionPreference), ErrorVariable, WhatIf (simulation de l'éxécution, très utile), ? (aide), etc.
  • En regardant de plus près les possiblités des arguments de commande, on observe :
    • Une notion de position d'argument par défaut (si l'argument n'est pas spécifié, on présume que l'argument est daonné dans cette position dans la liste d'args)
    • Une notion d'acceptation d'argument paar le pipe...
    • Une notion de paramétrage de l'acceptaiton des wildcards.
  • La gestion des droits ext supportée par la commande : Get-Credentials. Elle permet d'acquérir une identité et de s'en servir pour l'éxécution sous une autre identité que celle du lanceur de la commande.
Pour toujours s'y retrouver, n'hésitez pas à utiliser ces commandlet "point d'entrée" : Get-Command, Get-Help, Get-Member. On peut aller plus loin en filtrant les résultats : Get-Command -Noun Item (cherche les commandes qui contiennent Item)

La puissance du Shell

On a accès à TOUT .NET. Notamment les classes du framework :
[TYPE] <- accès au type .NET
On peut donc accéder aux méthodes statiques d'une classe. Ex. :
[System.DateTime]::Now // La date actuelle.
Mais on peut aussi instancier un objet .NET. Ex:
$webclient = New-Object System.Net.Webclient // un client web !
$string = $webclient.DownloadString("http://eric.lemerdy.free.fr/dotclear/index.php?feed/atom") // on télécharge un flux rss...
$string.ToString() // ...qu'on peut afficher à l'écran !
Les variables non typées par défaut, on peut stocker un entier puis une chaîne par exemple :
$a = 12
$a.GetType()
$a = 'Eric'
$a.GetType()
Par contre, on peut forcer le typage d'une variable
[Int32]$x = 12
$x = 'YES' // Error
$x = 12 // ok
On peut donc "caster" notre chaîne xml :
[XML]$xml = $string
$xml.rss.channel.item | Select-Object title
Et accéder directement au contenu du XML !!! Ici, rss, channel et item sont des éléments (au sens XML) du contenu XML.

Extension du shell

On peut charger ses propres classes en constituant une assembly. C'est l'unité packagée de code éxécutable, l'équivalent d'un jar en java. Ex. :
[Reflexion.assembly]::loadFile(myfile)
Cette extensibilité permet de créer des API pour vos applications .NET et d'y accéder par PowerShell.
Pour ajouter des commandlet, on va constituer un snappin. C'est simplement une assembly qui contient des commandlets.
Pour l'installer : InstallUtil.exe. C'est un utilitaire également utilisé pour déclarer un service Windows.
Get-PSSnapin -Registered // les snapins installés
                   mais pas enregistrés
Add-PSSnapin  // enregistrer les snapins
On bénéficie donc des même services qu'une commandlet du package de base, comme la complétion sur les commandes par exemple.

Une uniformité fournie grâce aux providers et aux drives

Un provider est le moyen uniforme de parcourir des objets organisés hiérarchiquement. Depuis le début de l'article, on on travaille avec le provider du filesystem.
Pour connaître les providers disponibles :
Get-PSProvider // Variables d'environnement, filesystem, registre Windows, etc.
Alors que les drives sont les éléments parcourables par leur provider.
Pour connaître les drives disponibles :
Get-PSDrive // Env, C:, D:, HKLM (HKEY_LOCAL_MACHINE)
Chaque drive est donc associé à son provider. Il existe d'autre providers de la communauté : LDAP, S3 (amazon), etc.
Pour changer le drive courant :
Set-Location variable: // choisit le drive des variables
dir // liste les variables !

Instrumentation

L'instrumentation est fournie par WMI pour Windows Management Instrumentation. C'est l'équivalent de JMX sur la JVM. On peut tout savoir sur une machine : l'heure, les users loggés - en lecture/écriture ! On peut donc éditer un point de configuration du poste à partir de Powershell sans problème à condition d'avoir le niveau de droit suffisant.
Il est possible de lancer des service : Start-Service

Gestion des scripts

L'extension est : *.ps1.
Pour exécuter un script : Get-Cat | & .\out-grid.ps1
On peut appeler du Windows Forms dans powershell ce qui permet d'afficher un tableau d'objets dans une interface graphique en cinq lignes de code.
Bien-sûr, l'éxécution de scripts étant une fonctionalité convoitée par de nombreux virus, Microsoft était attendu sur l'aspect sécurité de la chose. Pour adresser ce besoin fort de sécurité, il existe la notion d' : Execution policy (politique d'éxécution).
Get-ExecutionPolicy
Set-ExecutionPolicy
Niveaux :
unrestricted : tous ok
all signed : tous signés
RemoteSigned : tous les scripts externes doivent être signés
Le niveau par défaut ne permet pas l'éxécution du tout !
Tout objet qui n'est pas "utilisé" (affectation dans une variable ou utilisé par une fonction) sort du script (console). Pour éviter ça, on redirige vers null : macommande >$null; Sinon, ça resort dans le pipe externe. Cela peut être un avantage car tout ce qui sort du pipe est traîté immédiatement par la commande suivante comme nous l'avons vu plus haut.

L'avenir

Microsoft semble prêt à ouvrir les API de ses logiciels serveurs à travers PowerShell (Exchange par exemple). Cela sera d'autant plus facilité si ces logiciels sont écris en .NET. En tant que développeurs d'applications .NET, il est aussi bénéficiable de profiter de cette ouverture qui peut faciliter la configuration et l'administration de son logiciel.
Le produit évolue. Les nouvelles fonctionnalités attendues sont : les aspects éxécution à distance, l'éxécution en parallèle, une nouvelle interface graphique, de nouveaux snappins.
Sous Linux, le projet Mono, le portage de .NET, permet à l'initiative "pwash" de ne pas repartir de zéro dans son intention de porter la ligne de commande sous Linux.
Au cours de cette petite démonstration des possibilités de la nouvelle console de Microsoft, nous avons tous été impressionés par l'expressivité de la platte-forme. Les concepts de pipe objet et d'accès à la platte-forme .NET sont des apports inconstestables à la productivité et l'efficacité du scripting.

Notons pour conclure que ce produit marque un tournant dans la démarche Microsoft qui constituait auparavant à tout doter en interfaces graphiques. Cédric nous a d'ailleurs révéllé que les développeurs de PowerShell n'avaient pas très bonne presse au sein des équipes Microsoft qui ne comprennaient pas alors le changement de stratégie de la société.
Ce changement permet à Microsoft d'élargir sa cible d'administrateurs Windows en adressant aussi les adeptes de la ligne de commande. C'est donc une attaque en règle des serveurs *nix en dotant son système d'exploitation d'une console plus puissante qu'un bash unix ?

jeudi 10 avril 2008

Le ParisJUG parle anglais avec Kirk Perperdine

C'est le "Java Champion" de la performance qui est venu se présenter devant les utilisateurs Java de Paris avant hier soir. Le moins que l'on puisse dire, c'est que Kirk Pepperdine sait de quoi il parle. A travers une présentation dynamique et pleine d'humour, il nous a fait part de sa vision sur le monde de l'IT sous le prisme de l'optimisation des programmes. Je ne vais pas paraphraser ici David, dont le billet résume parfaitement l'essence de l'intervention du Canadien.
J'ai bien aimé son explication basée sur sa théorie "The Box", sur les différences entre le développeur et le profileur de problèmes de perfo. thebox Il pense que le développeur reste trop focalisé sur la brique application (le code) tandis que le profileur aura une vision plus globale qui l'aidera à trouver la vrai source du problème. Evidemment, ça peut être la même personne mais cela demande une culture plus approfondie sur la JVM ou même le hardware. Combien de développeurs java connaissent bien leur JVM (je connais des questions pièges à l'embauche sur la JVM) ? Le point de vue de Kirk permet effectivement de prendre conscience de l'importance de la JVM et des optimisations de compilation. Sans nous demander d'aller plonger dans l'étude d'architecture physique de la machine, il nous a conseillé de toujours prendre en compte la plate-forme d'éxécution cible et de ne jamais totalement abstraire le hardware.
Pour aller plus loin :
The Box (via InfoQ)
Le post de Kirk sur la soirée Galerie photos
ParisJUG - Présentation 08/04/2008

mardi 25 mars 2008

Coding Dojo Ruby

Pourquoi ces trois mots apparemment sans lien ? Pour vous parler d'une séance dont le dojo était Valtech et l'objectif était de découvrir par la pratique le langage Ruby. La première partie de la séance fut un...

Kata Randori

Les postes de développement Ruby ont été constitués sur le vif (l'environnement Ruby pour Windows mis en place à l'aide d'un installeur). Le moins que l'on puisse dire, c'est que les configurations hétérogènes nous ont quelque peu pimenté la tâche : MacBook, PC sous XP et Linux !
Nous avons ensuite choisi le kata (i.e. l'énoncé de l'exercice) à effectuer : "Missing word in dictionnary". Un exemple vaut mieux qu'un long discours ici :

dictionnaire : ["a", "big", "white", "cat"]
entrée : "a tiny black cat"
sortie : ["tiny", "black"]

Le principe retenu fut de positionner deux rôles par poste : un développeur (à gauche) et un copilote (à droite). Il est possible d'ajouter un troisième rôle : l'observateur dont la fonction est juste d'observer... sans communiquer.
Le "Time-boxing" requiert un décalage de rôle toutes les cinq minutes. Le copilote devient développeur et le développeur devient copilote sur le poste de gauche ! On passe donc cinq minutes sur chaque poste.

coding-dojo-time-boxing.png
(src)

Bien entendu, cette mobilité contraint la méthode de développement :

coding-dojo-tdd-babysteps.png
(src)

C'était la première fois pour une majorité d'entre nous : Ruby, coding dojo, pair programming et dans une moindre mesure, TDD (Test Driven Development). Pour moi, cela a changé la façon de voir le TDD car en "solo programming", je n'appliquais pas les baby tests. J'avais toujours tendance à vouloir implémenter l'algorithme que j'avais dans la tête, et pas celui induit par les tests. Le pair force à ne pas brûler les étapes et réduit le gaspillage en implémentant le strict nécessaire aux tests.
Au final, au cours de la rétrospective qui a suivi, on a pu faire le point pour trouver de meilleures façons de travailler. Le point crucial pour terminer une implémentation correcte fut la connaissance des API du langage Ruby qui permet évidemment de raccourcir le code à écrire.
Cette forme de développement abolit de manière assez spectaculaire la propriété du code. Une chose amusante à constater est la diversité des solutions choisies de poste en poste. Cependant, le niveau de test et leur complétude est comparable car tout le monde avance en parallèle sur le sujet, ce qui est troublant et donne un côté magique... On a tellement l'habitude de trouver un code au même stade où on l'a laissé.
Après une discutions a posteriori, nous avons tout de même laissé de côté une phase préliminaire : la spécification des tests. En effet, au lieu que chaque binôme définisse incrémentalement les tests, une liste de tests ou une "spécification" peut être préparée pour savoir où on veut en venir...

Kata Préparé

coding-dojo-prepared.png
(src)

La rétrospective ayant fait remarqué notre méconnaissance de Ruby, la deuxième session fut un kata préparé effectué par celui qui connaissait le mieux le langage, Etienne Charignon. Ce fut l'occasion de choisir un sujet riche en apprentissage : le comptage du nombre de lignes de code dans un programme Java (hors commentaires et lignes vides).

Pour conclure, je dirais que le coding dojo permet de pratiquer, une très bonne façon de comprendre et d'assimiler la méthode et les concepts sous-jacents. Il est une chose d'en parler mais le vivre est encore mieux. On apprend aussi sur soi-même pendant le codage en pair. Ce n'est pas un moment où on est jugé par son pair mais bien une façon d'avancer ensemble et de tirer le meilleur parti des deux "cerveaux"... C'est un challenge à la fois amusant et instructif qui peut permettre de souder une équipe très rapidement.


Liens : les slides coding dojo.

- page 2 de 3 -