(le message  d’erreur vient d’un fichier en cours d’écriture)

Après avoir mis cela au point sur la ligne de commande comme ci-dessus, je met cette commande dans un fichier de script pour la réutiliser plus tard :

On peut noter dans le script la barre verticale, indiquant un pipeline. Le pipeline passe la sortie de la première commande (la liste de fichier résultant de dir) à la deuxième commande qui consiste en un foreach. Dans le bloc du foreach on référence l’objet courant (le fichier) avec la variable spéciale $_.  foreach est un alias pour ForEach-Object (et peut encore se raccourcir en « % », comme dans l’exemple ci-dessous).

Simple, non ?

Un autre exemple dans la même veine consiste à supprimer les fichiers .DATA générés par mes expériences, mais pas trop tôt afin de ne pas interférer avec les analyses en cours – j’attends donc 30 minutes par exemple. Voici un script pour faire cela (j’ai encadré en rouge le calcul sur les dates) :

Voilà le résultat sur la console :

Il restera à mieux formater le taux de génération !

Le même script sous forme de code copiable, au cas où ca vous intéresse de le récupérer :

$DELAY=60*15

$total_deleted = 0

while ($True) {
    $deleted = 0
    dir c:\data -recurse -include *.data | % { 
        if ( ((get-date)-$_.LastWriteTime).TotalMinutes -gt 30) {
                del $_ ; $deleted += 1
        }
    }
    $total_deleted += $deleted
    $generation_rate = ($deleted / $DELAY) * 60
        
    write-host (get-date), `
                "total already deleted ", $total_deleted, `
                " generation rate ", $generation_rate, " / minute"
                
    Sleep -Seconds $DELAY        
}

Voilà des exemples que j’aurais été bien incapable de réaliser en DOS, et qui sont très faciles à faire en PowerShell.

Et vous, quels sont les scripts qui vous simplifient la vie ?

Malheureusement c’est un outil bien peu ergonomique, et assez fastidieux à régler (on peut tout de même sauver les paramètres dans un fichier .msc, afin de ne pas tout recommencer à zéro à chaque fois). En particulier je déteste le choix des compteurs dans des listes déroulantes minuscules

ainsi que le choix des échelles pour lesquelles il faut compter les chiffres à la main (pas bien agréable quand les compteurs sont dans les 10000000 ou les 1000000000) :

De plus on ne peut pas faire afficher des calculs complémentaires – souvent j’aimerais voir l’écart entre deux mesures successives, afin de connaître la « vitesse » de l’évolution du compteur.

Aussi j’utilise de plus en plus PowerShell pour mes activités de surveillance de processus. Voici par exemple un petit script qui suit la mémoire utilisée.

Tout d’abord j’ai mis au point le principe directement sur la ligne de commande (le processus à surveiller est nxServer.exe) :

Notez que PowerShell manipule directement 1GB, 1MB, 1KB, xKB. Bien pratique pour ne pas se prendre la tête avec les grands nombres.

Une fois satisfait du principe, j’ai sauvé la ligne de commande dans un fichier :

fichier que j’ai ensuite édité avec PowerGUI Script Editor pour ajouter quelques fonctionnalités supplémentaires (affichage à l’écran + sauvegarde dans un fichier, calcul de la différence entre deux mesures successives) :

Et voilà :

Bon d’accord ce n’est plus très utile de diviser par 1GB, j’ai corrigé la fuite mémoire qui faisait que l’on dépassait le Giga – mais je n’ai pas envie de la réintroduire juste pour la démo !

Pour montrer comment j’utilise PowerShell (le shell remplaçant DOS, et développé par Microsoft sur .NET), voici un petit exemple de lancement de programme en boucle. C’est le script que j’utilise en ce moment pour essayer de reproduire un gel d’un de nos logiciels qui est constaté chez un client.

[Contexte : ce gel arrive 2 à 3 fois par an, et uniquement chez ce client – la fréquence d’apparition est donc très faible, c’est pourquoi je suis conduit à faire des centaines de milliers d’exécution pour essayer de le reproduire – et c’est pourquoi l’automatisation via PowerShell est très utile]

Ce script maintient en exécution simultanée x instances d’un programme donné, jusqu’à ce qu’on parvienne à un nombre donné de lancements.

Ce premier fragment de code ci-dessous montre plusieurs aspects intéressants de PowerShell :

• on peut écrire des fonctions
• on dispose d’environnements de développement modernes, comme PowerGUI par exemple
• on a un accès direct au framework .NET, comme le montre l’appel [diagnostics.process]::start : comme il n’y a pas de commande équivalent dans le shell, on fait faire le travail par .NET directement
• on manipule des objets (voir les appels de méthodes comme .Count)
• les opérateurs booléens ne sont pas très naturels : -eq, -lt, -ge etc. C’est mon seul reproche à ce langage !

Note : quand je fais ces essais directement sur mon PC, j’ai constaté qu’il  était très utile de baisser un peu la priorité des processus, afin de garder un certain contrôle sur le PC. Voici comment faire :

Voici maintenant le reste du script qui utilise les fonctions ci-dessus, une simple boucle :

Le langage fournit donc tout ce que que l’on peut espérer d’un langage de programmation moderne. Il est sans doute possible de faire tout cela en DOS, mais explorer DOS m’a toujours paru au dessus de mes forces ! Dans le passé j’ai toujours préférer travailler avec cygwin pour profiter des possibilités de scripts à la Unix – ce n’est plus justifié aujourd’hui avec PowerShell, une bonne solution native sous Windows !

Note 27 janvier 2010 : merci à Laurent Dardenne de m’avoir signalé les liens erronés vers les images.

Vous savez sans doute que je suis un fan des langages de scripts : Python (utilisé avec succès dans certains satellites de nos applications comme un outil d’export générique, ou des extensions de calcul spécialisées), Ruby (pour apprendre le BDD avec Cucumber), mais ces derniers sont peu pratiques quand il s’agit d’interagir avec Windows.

C’est pourquoi je poursuis mon apprentissage de PowerShell : c’est un langage de script moderne complètement intégré à Windows, notamment parce qu’il accède facilement à .NET.

L’exemple du jour : je dois souvent nettoyer le journal d’événements Windows « Custom » (créé durant l’installation de nos logiciels pour permettre à nos applications de centraliser leurs événements).

Or c’est assez fastidieux depuis l’application Windows standard (et même avec l’application spécialisée Event Log Explorer que nous utilisons dans l’équipe Support) : il faut un clic droit, puis répondre Non à la question « voulez-vous sauver le journal avant de l’effacer ? ». Quand vous faites ca toute la journée c’est fatiguant. et puis on finit par oublier de faire ces opérations, le journal d’événements devient difficile à analyser, etc.

C’est là que PowerShell intervient : comme .NET fournit une classe EventLog bien pratique pour interagir avec les journaux d’événements, on peut y accéder en PowerShell :

J’ai utilisé Get-Member simplement pour me persuader que j’avais bien sous la main ce que je cherchais :

et donc ensuite j’ai appelé Clear() qui m’évite de faire l’opération à la main.

En fait il y a encore plus simple que mon idée de faire appel à une classe .NET. En effet PowerShell dispose directement de commandes pour interagir avec les journaux d’événements. Ce n’est pas étonnant car c’est quand même un outil d’administration Windows.

Voici donc la méthode la plus directe :

Et c’est donc la commande que je vais insérer au début de mes scripts de tests ! Fini les clics inutiles !

Note : j’ai trouvé l’idée du Clear-EventLog grâce à cet article sur ITPro.fr : Powershell, une ligne de commande qui a su se faire désirer – c’est aussi un très bon article pour démarrer avec PowerShell.

AutoHotkey est un logiciel gratuit qui me permet quotidiennement de simplifier certaines tâches répétitives. Par exemple saisir les dates dans notre format normalisé, taper les formules de politesse dans les mails, taper plus vite les expressions courantes lors des traductions, écrire des macros pour répéter un test de logiciel des milliers de fois, insérer des bouts de code pendant la programmation, insérer certains commentaires pour respecter nos normes de codage… Bref, une sorte de couteau suisse. Evidemment il y a des outils spécialisés pour tout ca : dans Office on peut écrire des macros, dans les environnements de programmation aussi, etc. Mais comme j’utilise beaucoup de logiciels, je ne maîtrise pas forcément les particularités de chacun, et un couteau suisse est bien utile dans mon cas.

Dans AutoHotkey on réalise tout cela grâce à des fichiers de script que l’on exécute soit en permanence, soit ponctuellement. Un fichier de script peut également être compilé en un exécutable Windows que l’on peut faire tourner sur n’importe quel PC, même si AutoHotkey n’est pas installé. Bon j’en ai déjà marre d’écrire AutoHotkey sans arrêt, avec les majuscules bien placées, alors je vais automatiser ca ! J’édite le script principal, via la barre d’icônes, cela lance Notepad (il y a des modes AutoHotkey disponibles dans des éditeurs plus avancés), et il me suffit d’insérer la ligne :

::ah::AutoHotkey

pour que maintenant dans n’importe quelle application Windows, le fait de taper ah insère automatiquement AutoHotkey. Quand je travaillais sur la traduction de Scrum et XP depuis les tranchées, j’avais défini des abréviations comme :

::sp::sprint
::cad::c’est-à-dire
::éq::équipe
::mb::membre de l’équipe 
::mbs::membres de l’équipe
::ped::programmation en duo
::pta::phase de tests d'acceptation

Ce qui peut être intéressant c’est de limiter le comportement de remplacement à une fenêtre particulière, au cas où le comportement global soit indésirable (je peux souhaiter continuer à taper ah dans des mails par exemple). C’est possible comme ceci :

#IfWinActive, Windows Live Writer 
::ah::AutoHotkey 
#IfWinActive

La directive #IfWinActive permet de filtrer sur le titre de la fenêtre, et donc de limiter le comportement à Windows Live Writer que j’utilise pour rédiger ce billet.

Pour accélérer la rédaction des mails, j’utilise diverses abréviations comme :

::bst:: 
SendInput Best regards{Enter}Bruno 
Statistics("bst") 
return        

::hic:: 
SendInput Hi Charles,{Enter} 
Statistics("hic") 
return        

Ces exemples montrent qu’on peut associer plusieurs lignes de code à une abréviation, lui faire taper des touches particulières avec la syntaxe {Enter}, et même appeler des fonctions comme Statistics, que j’ai programmée pour tracer dans un fichier mon utilisation de ces abréviations :

Statistics(id)
{
    FormatTime, vdate, ddMMyyyy
    FileAppend,%vdate% | %id% `n , F:\hotkeys.txt
}

Mon fichier de stats indique que j’ai utilisé 3000 fois ces abréviations en deux ans.

Voici une autre des mes fonctions qui retourne une date dans le format normalisé 15 MAY 2009 défini par notre système qualité (format non ambigu pour tous nos collègues qu’ils soient français, américains, anglais etc.) :

DateNormalisee()
{
    AbbrevMonths:="JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC"
    FormatTime, CurrentMonth,,M ;
    StringMid, OutputMonth, AbbrevMonths, (CurrentMonth-1)*4+1, 3
    FormatTime, OutputDay,, dd
    FormatTime, OutputYear,, yyyy
    OutputDate:=OutputDay . " " . OutputMonth . " " . OutputYear
    return OutputDate
}

Il me suffit alors d’associer cette fonction à la touche de mon choix.

L’exemple ci-dessous montre comment chercher dans google n’importe quelle chaîne sélectionnée dans n’importe quelle application (la boîte de dialogue étant pré-remplie avec le contenu du presse-papier Windows grâce à la variable Clipboard) :

DemandeAGoogle()
{
    InputBox, ToSearch, Enter your google search,,,,90,,,,,%Clipboard%
    if ErrorLevel != 1
    {
        GoogleRequest:="http://www.google.fr/search?hl=fr&q=" . ToSearch 
        Run %GoogleRequest%
    }
}

^!g::
DemandeAGoogle()
Statistics("^!g google")
return

Je ne suis jamais allé plus loin que l’utilisation de la fonction InputBox, mais on peut aussi réaliser des interfaces graphiques complètes avec AutoHotkey !

Enfin, mon autre grande utilisation de AutoHotkey est la réalisation de macros pour tester des logiciels de manière répétitive, typiquement pour arriver à reproduire des bugs à faible fréquence d’apparition mais néanmoins très problématiques pour des clients. AutoHotkey est très pratique car il contient un utilitaire d’enregistrement de macros (AutoScriptWriter.exe) qui capture tout ce que l’on fait avec la souris et le clavier, et donc génère une bonne partie du code de test pour nous. Voici par exemple ce que ca donne quand j’enregistre une séquence du type cliquer dans Windows Live Writer, cliquer sur « Insert Hyperlink », taper une URL dans la boîte de dialogue qui apparaît, et cliquer sur le bouton Cancel :

WinWait, Untitled - Windows Live Writer, 
IfWinNotActive, Untitled - Windows Live Writer, , WinActivate, Untitled - Windows Live Writer, 
WinWaitActive, Untitled - Windows Live Writer, 
MouseClick, left,  517,  4
Sleep, 100
MouseClick, left,  1150,  481
Sleep, 100
WinWait, Insert Hyperlink, 
IfWinNotActive, Insert Hyperlink, , WinActivate, Insert Hyperlink, 
WinWaitActive, Insert Hyperlink, 
Send, http:{SHIFTDOWN}//{SHIFTUP}ceci{SHIFTDOWN}.{SHIFTUP}est{SHIFTDOWN}.{SHIFTUP}test{SHIFTDOWN}.{SHIFTUP}fr
MouseClick, left,  388,  84
Sleep, 100

Ce code peut alors être inséré dans n’importe quel script. Typiquement j’utilise une boucle infinie du type suivant :

Loop {

  IfWinExist, Windows Task Manager
  {
    ;ne rien faire si le task manager est affiché,
    ;afin d'éviter la perte de contrôle du PC en cas d'erreur dans le script
   Continue
  }
 

  ; insérer ici le code généré par AutoScriptWriter 

  ; .......................... 
}

Bien sûr ce genre de code est assez fragile, car il dépend de la position des boutons. Je me limite en général à des scripts de quelques dizaines de lignes. Mais ils rendent déjà de nombreux services.

Ma seule critique sur AutoHotkey est qu’il utilise un langage de programmation ad-hoc, hyper-spécialisé, avec une sémantique pas toujours très claire, ce qui fait un peu grincer des dents les gens comme moi qui apprécient les langages bien définis. Il faut souvent se référer à la documentation, qui par contre est complète et bien faite, avec beaucoup d’exemples. Il y a également une communauté très active qui fournit des scripts tout prêts pour diverses tâches, et on peut obtenir de l’aide dans des forums. Alors malgré ce langage de programmation un peu particulier je vous invite à essayer AutoHotkey !

Cette idée d’un rôle asymétrique des deux hémisphères du cerveau ne semble pas avoir de réalité neurologique (voir par exemple Cerveau droit, cerveau gauche : le mythe).  Il n’empêche que je me retrouve dans la description du mode « cerveau gauche » (verbal/analytique/séquentiel), et je me suis aperçu qu’il m’était utile de faire travailler délibérément un mode « cerveau droit » (visuel/perceptif/simultané). C’est particulièrement vrai en résolution de problèmes informatiques, comme le développement de nouveaux algorithmes ou l’investigation de problèmes mystérieux.

Dans ce billet je décris une technique moins dangereuse que la méthode américaine basée sur la voiture, à savoir l’utilisation de cartes mentales.

Pour la résolution de problèmes (et pour d’autres usages aussi), justement je trouve très utile les cartes mentales (ou mindmaps). Les cartes mentales sollicitent naturellement le mode « cerveau droit » grâce à leur caractère spatial, les couleurs, les frontières, les relations entre sujets, les formes des branches.

En particulier les cartes permettent de suivre simultanément plusieurs branches de raisonnement, et de les restructurer très facilement au fur et à mesure que l’on découvre de l’information. Mais il arrive souvent un moment où il semble impossible d’aller plus loin. J’ai constaté que solliciter plus fortement le « cerveau droit » en manipulant en plus des images dans une carte permettait parfois de trouver de nouvelles idées. J’utilise deux sources d’images. D’une part des copies d’écran relatives au problème en cours. D’autre part une bibliothèque de cliparts (souvent obtenus via Microsoft Office) comme ceux que j’ai organisés dans la carte ci-dessous :

Cette carte illustre en outre une autre technique pour fonctionner plus en mode « cerveau droit » : améliorer la structure spatiale l’aspect, l’équilibre) de la carte sans chercher à ajouter de nouvelles informations. Voici la même carte réorganisée :

(vous pouvez télécharger la carte au format pdf ou au format MindManager).

Et vous, quelles sont vos techniques pour fonctionner en mode « cerveau droit » ?

En ce qui me concerne j’utilise depuis longtemps l’excellent freeware Agent Ransack, il est raisonnablement rapide (il mémorise les fichiers scannés dans sa première recherche, les recherches suivantes sont alors beaucoup plus rapides) et raisonnablement puissant (il supporte des expressions régulières dignes de ce nom, avec un wizard pour aider à les construire).

Je l’utilise un peu moins ces dernières années, depuis que je suis passé à l’indexation de tous mes fichiers, y compris (et surtout) mes fichiers de code source, comme je l’ai expliqué dans un article sur le principe DRY (Do not Repeat Yourself). Mon outil préféré est maintenant X1 – il n’est pas gratuit, mais 50$ ca vaut pour le coup pour avoir toutes mes réponses à mes questions sur mes fichiers ou mes mails en une minute environ.

Mais il y a encore plus rapide en ce qui concerne la recherche sur le nom des fichiers (pas sur leur contenu toutefois). Mes deux informateurs d’outils (freewaregenius et Gizmo’s Best-ever Freeware ) viennent de l’annoncer tous les deux. Il s’agit d’un tout petit programme appelé Everything, et il est ultra-rapide car il ne parcours pas les fichiers comme le font tous les autres outils. A la place, il exploite les informations de la Master File Table des volumes NTFS – cette table contient des données sur tous les fichiers et dossiers d’un disque formaté en NTFS. Evidemment cela ne fonctionne que pour les disques NTFS, mais cela n’est guère gênant à l’heure actuelle.

Essayez-le, le temps de réponse est de l’ordre de la seconde !