Question Start-Job avec plusieurs functions

usopp écrit:

comment ca?

Lors du dev, soit tu intégres des appels à Write-Debug (usage sur la console uniquement) :
[code:1]
$PSCmdlet.WriteDebug(\"ParameterSetName :$($PsCmdlet.ParameterSetName)\"«»)
#Manipule-t-on une chaîne ou un objet ?
[Switch] $AsObject= $PSBoundParameters.ContainsKey('Property')
$PSCmdlet.WriteDebug(\"AsObject: $AsObject\"«»)
[/code:1]
soit tu utilises des traces fichier, un exemple d'inventaire de mailbox :
[code:1]
process {
try {
#S'il n'existe aucune SMB pour le user on ne renvoi aucun objet
$EmailAdress=$EmailAdress.Trim()
If (Test-EmailAddress $EmailAdress)
{
try {
$Logger.Info(\"Get-MailBox for $EmailAdress\"«»)
$UserMailBox=Get-MailBox -Identity $EmailAdress -WarningVariable gmbxsWarning -EA Stop
foreach( $warn in $gmbxsWarning)
{ $Logger.Warn(\"[Get-MailBox] $Warn\"«») }
}
catch {
$Logger.Fatal(\"The cmdlet Get-MailBox has thrown an exception\",$_.Exception)
return
}

$Logger.Debug(\"DN=$($UserMailBox.DistinguishedName)\"«»)
$request=$LDAPRequest.UserAccountFromEmail -f $EmailAdress

$Logger.Debug(\"Première passe sur les FullAccess\"«»)
$Logger.Debug(\"Récupère le compte utilisateur (via l'email)\"«»)
$MasterAccount=Get-ADSIObject $request (Get-RootHosting) -properties 'msexchmasteraccountsid'
if ($MasterAccount -eq $null)
{ $logger.Warn(\"The attribut msexchmasteraccountsid is not set.\"«») }
[/code:1]
C'est verbeux, mais en cas de bug dans le code ou d'un serveur posant pb, le suivi est tout de suite plus facile. Et si tu n'as pas la possibilité de consulter le fichier de log, l'envoi par mail d'un zip est aussi possible.

usopp écrit:

mais après des grosses journées stressantes

Oui, dans ce cas c'est pareil pour tout le monde.

usopp écrit:

$Logger dans ton exemple c'est quoi ?

Un objet de log spécialisé, issu de la librairie citée dans mon message du 26/10/14 13:54.

Je pense qu'il manque qq exemples d'usage basique dans la doc
J'ai documenté le fonctionnement qui a du en faire fuire plus d'un/une, si ce n'est pas tous/toutes

usopp écrit:

ils étaient très dur

C'est vrai que ce n'est pas pour conforter les débutants que PS c'est simple...
J'ai forcé le trait lors de la rédaction de ses quizz, ce n'était peut être pas une bonne idée.
Comme je l'ai dit à des collègues \"Je peux simplifier et vous donner l'impression de vous apprendre qq chose\".

usopp écrit:

tu utilises un vocabulaire super précis

Oui, c'était aussi pour tirer le lecteur vers le haut.
usopp écrit:

que tres peu de personnes ont surtout les non développeur comme moi

Rien n'empêche de rechercher le sens
ça marche aussi pour ceux qui ne travaillent pas dans l'infra
usopp écrit:

j'ai surtout répondu par élimination pour pas mal de questions

Oui, si on a le temps de réfléchir, on peut beaucoup de chose.
usopp écrit:

si je montre les questions a mes collègues ils vont tous rien comprendre déjà quand je parle de collection ils me font collections ?

Oui, c'est fort probable.
Un exemple :
[code:1]
$h=@{}
$t=@()
$S='Test'

# est-ce un tableau ?
$T -is [System.Array]
#True

$h -is [System.Array]
#False

$S -is [System.Array]
#False
#Pourtant on peut indexer
$S[0]

# est-ce une collection ? Un objet contenant des datas
$h -is [System.Collections.IEnumerable]
#True
$T -is [System.Collections.IEnumerable]
#True
$S -is [System.Collections.IEnumerable]
#True
[/code:1]
Le terme 'Collection' permet de préciser si l'objet est conteneur (en général), celui de 'Tableau' précise le type du conteneur (en particulier).
Ceci est évidement une considération de développement qui prête attention à la structure de donnée.
Je peux aussi parler avec un vocabulaire restreint, comme les journalistes
usopp écrit:

dans tout les livres de base de powershell que j'ai pu survoler les termes que tu utilises ne sont pratiquement jamais utilisé il me semble ?

[/quote]
Oui, parce que les auteurs se mettent au niveau des débutants et simplifie leur discours. Cela encourage à l'apprentissage.
Donc, pour moi, ce principe est \"Moins on dit de choses, moins on en a expliquer\"

De mon côté je passe du temps a expliquer comment cela fonctionne, en tout cas de ce que j'en ai compris, et pas seulement comment utiliser des cmdlets.
Je ne dis que l'approche de ces auteurs est mauvaise, j'en ai choisi une autre qui n'est peut être pas approprié.

Tes remarques sont justes et je suis d'accord avec toi sur le fond.

Une question, tes collégues savent-il interpréter le contenu du texte suivant issu de l'aide en ligne et savent-ils en tirer partie ?

SYNTAXE
Get-ChildItem -Path -Filter [-Exclude] [-Force] [-Include] [-Name] [-Recurse] [-UseTransaction
[<SwitchParameter>]] [<CommonParameters>]

Get-ChildItem -Filter [-Exclude] [-Force] [-Include] [-Name] [-Recurse] -LiteralPath [-UseTransaction
[<SwitchParameter>]] [<CommonParameters>]


DESCRIPTION
...

PARAMÈTRES
-Exclude <String[]>
...

Obligatoire ? false
Position ? named
Valeur par défaut
Accepter l'entrée de pipeline ? false
Accepter les caractères génériques ? true

-Path <String[]>
...

Obligatoire ? false
Position ? 1
Valeur par défaut Current directory
Accepter l'entrée de pipeline ? true (ByValue, ByPropertyName)
Accepter les caractères génériques ? true

-LiteralPath <String[]>
...

Obligatoire ? true
Position ? named
Valeur par défaut
Accepter l'entrée de pipeline ? true (ByValue, ByPropertyName)
Accepter les caractères génériques ? false

Note : Les ... représentent du texte

Message édité par: Laurent Dardenne, à: 12/11/14 20:11<br><br>Message édité par: Laurent Dardenne, à: 12/11/14 21:37