Minden, amit tudni akart a ShouldProcess-ről

A PowerShell-függvények számos olyan funkcióval rendelkeznek, amelyek jelentősen javítják a felhasználók interakcióját. Az egyik fontos funkció, amelyet gyakran figyelmen kívül hagyunk, az a -WhatIf-Confirm támogatás, és könnyen hozzáadható a függvényekhez. Ebben a cikkben részletesen bemutatjuk, hogyan valósítható meg ez a funkció.

Ez egy egyszerű funkció, amelyet engedélyezhet a funkciókban, hogy biztonsági hálót nyújtson a rászoruló felhasználóknak. Semmi sem rémisztőbb, mint egy olyan parancs futtatása, amelyről tudja, hogy első alkalommal veszélyes lehet. A -WhatIf használatának lehetősége jelentős különbséget eredményezhet.

KözösParaméterek

Mielőtt megvizsgáljuk ezeknek a gyakori paramétereknek a implementálását, szeretném gyorsan áttekinteni a használatuk módját.

A -WhatIf használata

Ha egy parancs támogatja a -WhatIf paramétert, láthatja, hogy a parancs mit tett volna ahelyett, hogy módosításokat végezne. Ez egy jó módszer a parancsok hatásának tesztelésére, különösen mielőtt valami romboló műveletet végez.

PS C:\temp> Get-ChildItem
    Directory: C:\temp
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         4/19/2021   8:59 AM              0 importantfile.txt
-a----         4/19/2021   8:58 AM              0 myfile1.txt
-a----         4/19/2021   8:59 AM              0 myfile2.txt

PS C:\temp> Remove-Item -Path .\myfile1.txt -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".

Ha a parancs megfelelően implementálja a ShouldProcess-t, az összes módosítást meg kellene jelenítenie. Íme egy példa, amely egy helyettesítő karaktert használ több fájl törléséhez.

PS C:\temp> Remove-Item -Path * -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
What if: Performing the operation "Remove File" on target "C:\Temp\myfile2.txt".
What if: Performing the operation "Remove File" on target "C:\Temp\importantfile.txt".

A "-Confirm" használata

A támogatott -WhatIf parancsok szintén támogatják -Confirma parancsokat. Ez lehetőséget ad egy művelet megerősítésére a művelet végrehajtása előtt.

PS C:\temp> Remove-Item .\myfile1.txt -Confirm

Confirm
Are you sure you want to perform this action?
Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Ebben az esetben több lehetőség közül választhat, amelyek lehetővé teszik a folytatást, a módosítás kihagyását vagy a szkript leállítását. A súgó az ilyen lehetőségek mindegyikét ismerteti.

Y - Continue with only the next step of the operation.
A - Continue with all the steps of the operation.
N - Skip this operation and proceed with the next operation.
L - Skip this operation and all subsequent operations.
S - Pause the current pipeline and return to the command prompt. Type "exit" to resume the pipeline.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Lokalizáció

Ez a kérés honosított a PowerShellben, így a nyelv az operációs rendszer nyelvétől függően változik. Ez még egy dolog, amit a PowerShell kezel.

[switch] Paraméterek

Vegyünk egy gyors pillanatot, hogy megnézzük, hogyan adhatunk át értéket egy [switch] paraméternek. Ennek fő oka az, hogy gyakran szeretne paraméterértékeket átadni a hívott függvények számára.

Az első megközelítés egy olyan paraméterszintaxis, amely minden paraméterhez használható, de legtöbbször a [switch] típusú paraméterek esetén alkalmazzák. Meg kell adnia egy kettőspontot, amely egy értéket csatol a paraméterhez.

Remove-Item -Path:* -WhatIf:$true

Ugyanezt megteheti egy változóval is.

$DoWhatIf = $true
Remove-Item -Path * -WhatIf:$DoWhatIf

A második módszer, hogy egy kivonattáblával szétosztjuk az értéket.

$RemoveSplat = @{
    Path = '*'
    WhatIf = $true
}
Remove-Item @RemoveSplat

Ha még nem ismeri a hashtáblákat vagy a splattingot, van egy másik cikkem, amely mindenről, amit tudni szeretne a hashtáblákról, szól.

Támogatja a ShouldProcess-et

A(z) SupportsShouldProcess megadása a(z) CmdletBinding a függvényében az első lépés a -WhatIf és a -Confirm támogatás engedélyezéséhez.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Remove-Item .\myfile1.txt
}

A(z) SupportsShouldProcess ilyen módon történő megadásával most meghívhatjuk a függvényt -WhatIf (vagy -Confirm).

PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".

Vegye észre, hogy nem hoztam létre egy -WhatIf. Az az opció megadása automatikusan létrehozza számunkra a SupportsShouldProcess. Amikor megadjuk a -WhatIf paramétert a Test-ShouldProcess-on, bizonyos dolgok is végrehajtanak -WhatIf feldolgozást.

Bízz, de ellenőrizz

Fennáll annak a veszélye, hogy bármelyik általad hívott függvény örökli a -WhatIf értékeket. A további példákban azt fogom feltételezni, hogy ez nem fog működni, ezért nagyon egyértelmű leszek, amikor más parancsokat hívok meg. Azt javaslom, hogy ugyanezt tegye.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Remove-Item .\myfile1.txt -WhatIf:$WhatIfPreference
}

Jóval később újra megvizsgálom az árnyalatokat, ha jobban megérted az összefüggéseket.

$PSCmdlet.ShouldProcess

A implementálást SupportsShouldProcess lehetővé tevő módszer az $PSCmdlet.ShouldProcess. Ön felhívja $PSCmdlet.ShouldProcess(...) , hogy eldöntse, fel kell-e dolgoznia némi logikát, és a PowerShell gondoskodik a többiről. Kezdjük egy példával:

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $file = Get-ChildItem './myfile1.txt'
    if($PSCmdlet.ShouldProcess($file.Name)){
        $file.Delete()
    }
}

A $PSCmdlet.ShouldProcess($file.Name) hívás ellenőrzi az -WhatIf (és -Confirm paraméter) értékét, majd ennek megfelelően kezeli azt. A -WhatIf hatására a ShouldProcess kiír egy leírást a változásról és visszatér $false:

PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".

A szkriptet használó -Confirm hívás szünetelteti a szkriptet, és felkéri a felhasználót a folytatásra. Visszaadja $true, ha a felhasználó kiválasztotta Y.

PS> Test-ShouldProcess -Confirm
Confirm
Are you sure you want to perform this action?
Performing the operation "Test-ShouldProcess" on target "myfile1.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Ennek az egyik nagyszerű funkciója $PSCmdlet.ShouldProcess az, hogy részletes kimenetként szolgál. Gyakran támaszkodom erre, amikor implementálom ShouldProcess.

PS> Test-ShouldProcess -Verbose
VERBOSE: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".

Túlterhelések

A(z) $PSCmdlet.ShouldProcess több különböző túlterheléssel rendelkezik, amelyek különböző paraméterekkel testreszabják az üzenetküldést. A fenti példában már láttuk az elsőt. Nézzük meg közelebbről.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    if($PSCmdlet.ShouldProcess('TARGET')){
        # ...
    }
}

Ez olyan kimenetet hoz létre, amely tartalmazza a függvény nevét és a célt (a paraméter értékét).

What if: Performing the operation "Test-ShouldProcess" on target "TARGET".

Ha egy második paramétert ad meg, a művelet a művelet értékét használja az üzenetben szereplő függvénynév helyett.

## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".

A következő lehetőség három paraméter megadása az üzenet teljes testreszabásához. Ha három paramétert használ, az első a teljes üzenet. A második két paraméter továbbra is használatos az -Confirm üzenet kimenetében.

## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE

Gyorsparaméter-referencia

Arra az esetre, ha csak azért jött volna ide, hogy megtudja, milyen paramétereket kell használnia, az alábbi rövid útmutató bemutatja, hogy a paraméterek hogyan módosítják az üzenetet a különböző -WhatIf forgatókönyvekben.

## $PSCmdlet.ShouldProcess('TARGET')
What if: Performing the operation "FUNCTION_NAME" on target "TARGET".

## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".

## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE

Az egyiket általában két paraméterrel használom.

FeldolgozásiOk

Van egy negyedik túlterhelési probléma, amely fejlettebb a többinél. Ez lehetővé teszi, hogy megtudja, miért történt ShouldProcess. Csak a teljesség kedvéért adom hozzá, mert helyette csak ellenőrizhetjük, hogy $WhatIfPreference a $true-e.

$reason = ''
if($PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION',[ref]$reason)){
    Write-Output "Some Action"
}
$reason

A $reason változót a negyedik paraméternek [ref] referenciaváltozóként kell átadnunk. ShouldProcess megtölti $reason az értékkel None vagy WhatIf. Nem mondtam, hogy ez hasznos, és nem volt okom arra, hogy valaha is használhassam.

Hol helyezze el?

ShouldProcess Ezzel biztonságosabbá teheti a szkripteket. Ezért akkor használja, amikor a szkriptek módosításokat végeznek. A hívás elhelyezését a $PSCmdlet.ShouldProcess változáshoz a lehető legközelebb szeretem elvégezni.

## general logic and variable work
if ($PSCmdlet.ShouldProcess('TARGET','OPERATION')){
    # Change goes here
}

Ha egy elemgyűjteményt dolgozok fel, minden elemhez hívom. A hívás tehát a foreach hurokba kerül be.

foreach ($node in $collection){
    # general logic and variable work
    if ($PSCmdlet.ShouldProcess($node,'OPERATION')){
        # Change goes here
    }
}

Azért helyezem szorosan a ShouldProcess jelet a módosítás köré, mert szeretném, ha a lehető legtöbb kód végrehajtásra kerülne, amikor -WhatIf meg van adva. Ha lehetséges, futtassa a beállítást és az ellenőrzést, hogy a felhasználó láthassa ezeket a hibákat.

Ezt is szeretem használni a Pester-tesztjeimben, amelyek ellenőrzik a projektjeimet. Ha van egy olyan logikám, amelyet nehéz mockolni Pesterben, gyakran becsomagolhatom ShouldProcess-ba, és meghívhatom -WhatIf tesztjeimben. Jobb, ha a kód egy részét teszteli, mint egyiket sem.

$WhatIfPreference

Az első preferenciaváltozónk a $WhatIfPreference. Ez alapértelmezés szerint így van $false . Ha $true-ra állítja be, akkor a függvény úgy fut, mintha -WhatIf-t adott volna meg. Ha ezt a saját munkamenetében állítja be, az összes parancsot -WhatIf végrehajtásra kerül.

Amikor meghív egy függvényt -WhatIf, a $WhatIfPreference értéke a függvény hatókörén belül be lesz állítva $true-re.

ConfirmImpact

A legtöbb példám a -WhatIf vonatkozik, de minden eddig működik a -Confirm is a felhasználó ösztönzésére. Beállíthatja a ConfirmImpact függvény beállítását magasra, így a rendszer megkérdezi a felhasználót, mintha -Confirm-vel hívták volna meg.

function Test-ShouldProcess {
    [CmdletBinding(
        SupportsShouldProcess,
        ConfirmImpact = 'High'
    )]
    param()

    if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }
}

Ez a Test-ShouldProcess hívás végrehajtja a -Confirm műveletet a High hatás miatt.

PS> Test-ShouldProcess

Confirm
Are you sure you want to perform this action?
Performing the operation "Test-ShouldProcess" on target "TARGET".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
Some Action

A nyilvánvaló probléma az, hogy most már nehezebb más szkriptekben használni anélkül, hogy a felhasználót kéri. Ebben az esetben átadhatunk egy parancsot $false a kérés letiltásához -Confirm .

PS> Test-ShouldProcess -Confirm:$false
Some Action

Egy későbbi szakaszban bemutatom, hogyan adhatok hozzá -Force támogatást.

$ConfirmPreference

$ConfirmPreference egy automatikus változó, amely szabályozza, amikor ConfirmImpact a végrehajtás megerősítésére kéri. Íme a lehetséges értékek mindkét $ConfirmPreference és ConfirmImpact esetében.

• High
• Medium
• Low
• None

Ezekkel az értékekkel különböző hatásszinteket adhat meg az egyes függvényekhez. Ha $ConfirmPreference a beállítás értéke magasabb, mint ConfirmImpact, akkor a rendszer nem kéri a végrehajtás megerősítését.

Alapértelmezés szerint a $ConfirmPreference értéke High, és a ConfirmImpact értéke Medium. Ha azt szeretné, hogy a függvény automatikusan kérje a felhasználót, állítsa be a ConfirmImpact a(z) High értékre. Egyéb esetben állítsa be Medium, ha az romboló, és használja Low, ha a parancs mindig biztonságosan futtatható éles környezetben. Ha a none értéket állítja be, nem jelenik meg kérés akkor sem, ha a -Confirm meg van adva (de továbbra is biztosítja a -WhatIf támogatást).

Függvény meghívásakor a $ConfirmPreference értéke Low lesz beállítva a függvény hatókörén belül.

Beágyazott megerősítési kérések letiltása

Az ön által hívott függvények átvehetik a $ConfirmPreference-t. Ez olyan forgatókönyveket hozhat létre, amikor megerősítési kérést ad hozzá, és a hívott függvény is kér egy visszaigazolást a felhasználótól.

Amit általában teszek, az az, hogy megadom a -Confirm:$false a parancsokra, amelyeket akkor használok, amikor már kezeltem az utasításokat.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $file = Get-ChildItem './myfile1.txt'
    if($PSCmdlet.ShouldProcess($file.Name)){
        Remove-Item -Path $file.FullName -Confirm:$false
    }
}

Ezzel visszatérünk egy korábbi figyelmeztetéshez: Vannak árnyalatok, amelyek azt jelzik, hogy mikor -WhatIf nem adhatók át függvényeknek, és mikor -Confirm kerülnek át egy függvényre. Ígérem, hogy később visszatérek ehhez.

$PSCmdlet.ShouldContinue

Ha a megadottnál ShouldProcess több vezérlőre van szüksége, a parancssort közvetlenül a következővel ShouldContinueindíthatja el: . ShouldContinue $ConfirmPreference figyelmen kívül hagyja a ConfirmImpact, -Confirm$WhatIfPreference, és -WhatIf-t, mivel minden alkalommal kéri, amikor végrehajtásra kerül.

Egy gyors pillantással könnyen összezavarható ShouldProcess és ShouldContinue. Általában emlékszem, hogy használom ShouldProcess, mert a paraméter neve SupportsShouldProcess a CmdletBinding. Szinte minden forgatókönyvben érdemes használni ShouldProcess . Ezért foglalkoztam először ezzel a módszerrel.

Nézzük meg ShouldContinue-t működés közben.

function Test-ShouldContinue {
    [CmdletBinding()]
    param()

    if($PSCmdlet.ShouldContinue('TARGET','OPERATION')){
        Write-Output "Some Action"
    }
}

Ez egyszerűbb kérést biztosít, kevesebb lehetőséggel.

Test-ShouldContinue

OPERATION
TARGET
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

A legnagyobb probléma ShouldContinue az, hogy a felhasználónak azt interaktívan kell futtatnia, mert mindig felkéri a felhasználót. Mindig olyan eszközöket kell összeállítani, amelyeket más szkriptek is használhatnak. Ennek módja a implementálás -Force. Később újra megnézem ezt az ötletet.

Igen az összesre

Ez automatikusan kezelve van ShouldProcess, de egy kicsit több munkát kell befektetnünk ShouldContinue. Van egy második metódustúlterhelés, ahol néhány értéket referenciaként kell átadnunk a logika irányításához.

function Test-ShouldContinue {
    [CmdletBinding()]
    param()

    $collection = 1..5
    $yesToAll = $false
    $noToAll = $false

    foreach($target in $collection) {

        $continue = $PSCmdlet.ShouldContinue(
                "TARGET_$target",
                'OPERATION',
                [ref]$yesToAll,
                [ref]$noToAll
            )

        if ($continue){
            Write-Output "Some Action [$target]"
        }
    }
}

Hozzáadtam egy hurkot foreach és egy gyűjteményt, hogy működés közben megjelenítsem. Kihúztam a ShouldContinue hívást az if utasításból, hogy könnyebben olvasható legyen. Négy paraméterrel rendelkező metódusok meghívása elkezdhet bonyolulttá válni, de megpróbáltam olyan tisztán megvalósítani, amennyire csak tudtam.

Implementálás –Force

ShouldProcess és ShouldContinue különböző módokon kell implementálniuk -Force . Ezeknek az implementációknak az a lényege, hogy ShouldProcess-t mindig végre kell hajtani, de -Force megadása esetén ShouldContinue-et nem szabad végrehajtani.

ShouldProcess –Force

Ha ConfirmImpact-t high-be állítja, az első dolog, amit az ön felhasználói megpróbálnak, az az, hogy letiltsák -Force. Amúgy is ez az első dolgom.

Test-ShouldProcess -Force
Error: Test-ShouldProcess: A parameter cannot be found that matches parameter name 'force'.

Ha visszaemlékeznek a ConfirmImpact szakaszból, valójában így kell hívniuk:

Test-ShouldProcess -Confirm:$false

Nem mindenki veszi észre, hogy meg kell tennie, és -Force nem tiltja el ShouldContinue. Ezért a felhasználói élmény érdekében kell megvalósítanunk -Force. Tekintse meg ezt a teljes példát:

function Test-ShouldProcess {
    [CmdletBinding(
        SupportsShouldProcess,
        ConfirmImpact = 'High'
    )]
    param(
        [switch]$Force
    )

    if ($Force -and -not $PSBoundParameters.ContainsKey('Confirm')) {
        $ConfirmPreference = 'None'
    }

    if ($PSCmdlet.ShouldProcess('TARGET')) {
        Write-Output "Some Action"
    }
}

Paraméterként saját -Force kapcsolót adunk hozzá. A -Confirm paraméter automatikusan hozzáadódik, amikor a SupportsShouldProcess-t használjuk a CmdletBinding-ban. Ha azonban használja SupportsShouldProcess, a PowerShell nem adja hozzá a változót $Confirm a függvényhez. Ha szigorú módban fut, és a definiálás előtt próbálja meg használni a $Confirm változót, hibaüzenet jelenik meg. A hiba elkerülése érdekében tesztelheti $PSBoundParameters , hogy a paramétert a felhasználó adta-e át.

if ($Force -and -not $PSBoundParameters.ContainsKey('Confirm')) {
    $ConfirmPreference = 'None'
}

Ha a felhasználó megadja -Force, a $ConfirmPreference értékét None-re állítjuk a helyi hatókörben. Ha a felhasználó megadja a -Confirm, akkor a ShoudProcess() tiszteletben tartja a -Confirm paraméter értékeit.

if ($PSCmdlet.ShouldProcess('TARGET')){
    Write-Output "Some Action"
}

Ha valaki mindkettőt -Force-WhatIfmegadja, akkor -WhatIf elsőbbséget kell élveznie. Ez a megközelítés megőrzi a -WhatIf feldolgozást, mert a ShouldProcess mindig végrehajtásra kerül.

Ne adjon hozzá tesztet a $Force utasításon belüli if értékhez a ShouldProcess következővel. Ez egy anti-mintázat ebben a konkrét esetben, habár ezt mutatom a következő szakaszban ShouldContinue.

ShouldContinue -Force

Ez a helyes módja annak, hogy implementáljuk -Force a következővel ShouldContinue: .

function Test-ShouldContinue {
    [CmdletBinding()]
    param(
        [switch]$Force
    )

    if($Force -or $PSCmdlet.ShouldContinue('TARGET','OPERATION')){
        Write-Output "Some Action"
    }
}

Ha az $Force operátor bal oldalán helyezi el az -or értéket, először kiértékeli azt. Ezzel a módszerrel, ahogy most írja, megszakítja az if utasítás végrehajtását. Ha $Force$true, akkor ShouldContinue nem kerül végrehajtásra.

PS> Test-ShouldContinue -Force
Some Action

Nem kell aggódnia -Confirm vagy -WhatIf miatt ebben a forgatókönyvben, mert ShouldContinue nem támogatja őket. Ezért kell másképpen kezelni, mint ShouldProcess.

Hatókörrel kapcsolatos problémák

A -WhatIf és -Confirm alkalmazása a függvényeken belül és mindig az általuk hívott összes elemre is érvényes. Ezt úgy hajtják végre, hogy a függvény helyi hatókörében beállítják a $WhatIfPreference értékét $true-ra/-re, vagy a $ConfirmPreference értékét Low-ra/-re. Amikor egy másik függvényt hív meg, a ShouldProcess hívások ezeket az értékeket használják.

Ez az idő nagy részében helyesen működik. Bármikor működik, amikor meghív egy beépített parancsmagot vagy egy függvényt ugyanabban a hatókörben. Akkor is működik, ha szkriptet vagy függvényt hív meg egy szkriptmodulban a konzolról.

Az egyetlen hely, ahol nem működik, ha egy szkript vagy egy szkriptmodul meghív egy függvényt egy másik szkriptmodulban. Ez nem hangzik nagy problémának, de a PSGalleryből létrehozott vagy lekérhető modulok többsége szkriptmodul.

Az alapvető probléma az, hogy a szkriptmodulok nem öröklik az olyan értékeket, mint a $WhatIfPreference vagy $ConfirmPreference (és még több másik), amikor más szkriptmodulok függvényeiből hívják őket.

Ennek általános szabályként történő összegzésének legjobb módja, ha ez megfelelően működik bináris modulok esetében, és soha nem bízik benne, hogy szkriptmodulok esetén is működni fog. Ha nem biztos benne, tesztelje, vagy csak feltételezze, hogy nem működik megfelelően.

Személy szerint úgy érzem, hogy ez nagyon veszélyes, mert olyan forgatókönyveket teremt, amelyekben -WhatIf támogatást nyújt több modulokhoz, amelyek elszigetelten megfelelően működnek, de nem működnek megfelelően, amikor kölcsönösen hívják meg egymást.

Egy GitHub RFC dolgozik a probléma megoldásán. További részletekért lásd: Végrehajtási beállítások propagálása a szkriptmodul hatókörön túl.

Befejezésül

Meg kell néznem, hogyan kell használni ShouldProcess minden alkalommal, amikor szükségem van rá. Sokáig tartott megkülönböztetni a ShouldProcess-t a ShouldContinue-tól. Szinte mindig meg kell néznem, hogy milyen paramétereket kell használni. Szóval ne aggódj, ha még mindig összezavarodsz időről időre. Ez a cikk akkor jelenik meg, amikor szüksége lesz rá. Biztos vagyok benne, hogy magam is gyakran hivatkozom rá.

Ha tetszett ez a bejegyzés, kérjük, ossza meg gondolatait velem a Twitter segítségével az alábbi linket. Mindig szeretem hallani azokat az embereket, akik értéket kapnak a tartalomból.