Question 2011 Scripting Games : Advanced Events 1

Bonsoir,

Un grand merci pour vos commentaires et vos remarques

Pour que nous puissions continuer à être constructif, je vais trouver le temps pour poster les autres scripts que j'ai posté lors des 'Scripting Games 2011'.





@ +

Matthew

Laurent Dardenne écrit:

Salut,
je viens juste de lire ton post, alors je me permets qq remarques, en sachant que c'est tjr plus facile que de réaliser

Tes remarques permettront à toutes les personnes qui passeront par là et qui le désirent, d'en apprendre plus

D'aprés un post du blog MS PowerShell, cette usage est le plus lent (un cmdlet opère de multiples contrôles), entre la redirection vers $null ou l'affectation à $null :
[code:1]
$objSearcher.PropertiesToLoad.Add(\"name\"«») | Out-Null
[/code:1]

Information reçue 5 sur 5

Puisqu'il n'y a pas de bloc process on est assuré que $MyComputersList est à null
[code:1]
$MyComputersList = $null
$MyComputersList = @()
[/code:1]

Tu as parfaitement raison.

Là tu as du perdre des points ! Un appel à Write-Error ou mieux un appel àThrow ( new-object System.ArgumentException ...) est préférable.
L'appelant ne sait pas ce qui se passe, sauf une fin de fonction :-/
[code:1]
if(!(Test-Path $Filepath)){
Write-Host \"The file $Filepath can not be found !\" -ForegroundColor Red
exit
}
[/code:1]

Oui, je l'ai compris par la suite : toujours penser que la fonction doit être réutilisable et renvoyer dans ce cas une exception me paraît être une excellente pratique.

Si c'est un prérequis à l'exécution de la fonction, on peut utiliser sur ce paramètre un attribut ValidateScript.
Ensuite la gestion du ParameterSetName n'est pas explicite, j'en déduit que l'usage du switch détermine le jeux de paramètre 'ComputersFromAD'.
Du coup je me dis que le jeux de paramètre n'a qu'un usage documentaire.

Je notes.

Si j'ai bien compris le code suivant, je pense qu'ici aussi tu as du perdre des points :
[code:1]
Start-Process notepad
$NotepadProcess = Get-Process notepad
[/code:1]
Le paramètre -PassThru du cmdlet Start-Process pouvait suffire.

Je n'utilisais pas souvent le paramétre -PassThru jusqu'à présent, mais j'en prends bonne note pour mes futurs scripts !

Et j'ai l'impression que tu supposes que tu ne peux avoir qu'un seul process Notepad d'actif.
Et de ce que j'ai compris, d'après ton commentaire \"Windows PowerShell Remoting\", pour moi il n'était pas possible d'exécuter à distance une appli GUI.
Donc là j'ai doute.Mais si tu l'as codé ainsi c'est que ça marche !
Ceci dit je veux bien que tu me le confirmes

Oui je l'ai supposé, mais aussi parce que j'ai cherché à faire 'simple'. Mais cela m'a effectivement traversé l'esprit lors de l'écriture du script...
Dans le scénario il était bien précisé qu'on devait utiliser un process notepad... Alors je n'ai pas cherché midi à quatorze heure
Je confirme que cela fonctionne, ayant testé le script avant de le poster... A moins que quelqu'un me prouve le contraire

Sinon je lis que tu utilises pour les constructions d'objet la syntaxe de la v1, celle de la v2 est plus concise :
[code:1]
New-object PSobject -property @(Nom=$Valeur}
[/code:1]
Sur une classe dotnet quelconque elle permet également d'appeler des méthodes dans la foulée, voir la doc en ligne.

Je l'ai compris il n'y a que quelques mois.
J'utilise les PSobject à présent tout le temps : c'est le top, et je ne vois pas pourquoi j'ai mis autant de temps à m'y mettre
Pourquoi faire compliqué quand on peut faire simple ?

Et ici comme convention de valeur nulle, autant se satisfaire de $null, car ici ton choix t'oblige à la documenter
[code:1]
$MyComputerInfos.ModuleName = \"?\"
[/code:1]

... Effectivement, toujours penser que le code doit être réutilisable.
Mon utilisation du \"?\" est archi personnelle et n'est finalement pas du tout explicite...

Pour la construction de collection le code suivant facilite l'écriture, mais n'est pas efficiente :
[code:1]
$ResultsList += $MyComputerInfos
[/code:1]
L'usage, par exemple, d'un arraylist est déjà plus performant.

Ok je notes

[code:1]
- IL n'y a pas de \"Command based help\", pour la réutilisation du code par d'autres administrateurs ;
[/code:1]
De mon côté je préfére un code qui n'est pas documenté, mais qui est robuste, à son contraire.
D'avoir les deux, c'est de la gourmandise...

Oui : Jusqu'à présent, dans le cadre de mon travail, j'écrivais des scripts qui n'étaient utilisés que par moi.
Depuis que d'autres admin se mettent progressivement à PowerShell (là où je travaille, il était temps ), je ne dois plus me le permettre.
Comme cela a bien été expliqué lors des Scripting Games, nous devons penser \"code réutilisable\".
L'aide et les commentaires sont donc très importants.
Qui plus est, cela m'aurait permis de gratter encore quelques points

En tout cas c'est agréable de lire du code structuré, et c'est aussi ce qui permet d'en voir les faiblesses, et donc de le rendre plus fort.
Un autre aspect du dynamisme

je suis complétement d'accord avec toi