PowerShell po polsku

Zleciało już sporo czasu od mojego ostatniego posta, zanim jednak zacznę się tłumaczyć (który to już raz?) z tak długiego okresu ciszy chciałbym wspomnieć o dwóch sprawach, które z mojego punktu widzenia są istotniejsze niż moje marudzenie…

Przede wszystkim: nie udało mi się nawet “rozpędzić” w cyklu opisującym nowinki w PowerShellu v3, a tu już dostępna jest v4. Chciałbym przypomnieć gdzie do znajdziecie, skąd możecie pobrać i na co powinniście zwrócić uwagę przy ew. instalacji. Druga sprawa to MTS. Znów miałem przyjemność tam występować, co prawda planowo w duecie, ale wyszło jednak inaczej. Nie opiszę dlaczego wyszło, jak wyszło: zamiast tego postaram się przybliżyć temat i wskazać, gdzie można znaleźć materiały związane z tym co pokazywałem.

PowerShell vi cztery

Wiele osób jeszcze nie “okrzepło” po zmianach, których byliśmy świadkami w wersji trzeciej a tu, ledwie rok po poprzednim produkcie, dostajemy znów nowszy, świeższy i zmieniony PowerShell. Czemu skok wersji? Przyczyna kryje się pod skrótem DSC. Jeśli ktoś z Was pracowałem z produktami takimi jak Puppet, czy Chef to prawdopodobnie wie doskonale, na czym DSC polega. Tym razem Desired State Configuration zawitało do PowerShella i może być tworzone przy wykorzystaniu znanej nam już dobrze składni. Możliwości ma DSC o wiele więcej, z całą pewnością nie da się tego zamknąć w kilku zdaniach.

To zmiana najważniejsza, ale nie jedyna. Pamiętacie workflow z wersji trzeciej? Swoim zwyczajem PS Team usprawniło ten nowy produkt, dzięki czemu nieco łatwiej będzie tworzyć workflowy w wersji czwartej. Nadal jest to technika, z której korzystać będą wszyscy, plus jest jednak taki, że jeśli ktoś się zdecyduje, to bariera będzie nieco niższa.

Dla mnie zaś wisienką na tym torcie jest nowy wspólny parametr: PipelineVariable. Korzystaliście kiedyś z OutputVariable, ErrorVariable…? Jeśli nie, zachęcam by spróbować. PipelineVariable jest podobna w działaniu, daje jednak niesamowite możliwości wewnątrz “rurki”. Weźmy przykład w miarę prosty:

ls | ForEach-Object {            
    $pvFile = $_            
    $pvFile | get-acl | ForEach-Object { $_.Access } |             
        select @{            
            Name = 'Path'            
            Expression = { $pvFile.FullName }            
        }, IdentityReference, AccessControlType, FileSystemRights            
                    
            
}

Problem? “Rurka” z mojego pliku (ls) zrobiła najpierw ACLkę (get-acl) a następnie ACE ($_.Access) – niestety, oryginalny plik przepadł, muszę więc zapisać go najpierw w jakiejś zmiennej. Finał? Muszę użyć ForEach-Object by “przechować” plik w pośredniej zmiennej. I tu właśnie wchodzi PipelineVariable (alias pv):

ls -pv pvFile | acl -pv pvAcl | % Access |             
    select @{            
        Name = 'Path'            
        Expression = { $pvFile.FullName }            
    }, @{            
        Name = 'Owner'            
        Expression = { $pvAcl.Owner }            
    }, IdentityReference, AccessControlType, FileSystemRights

Jak widać: dorzuciłem kolejną właściwość, a mimo to nie musiałem użyć żadnego ForEach-Object, PipelineVariable przechował wynik bloku “process” każdego z poleceń w odpowiednich zmiennych ($pvFile, $pvAcl) i mogłem śmiało użyć ich w kolejnych poleceniach. Niby mała rzecz, a (mnie bardzo) cieszy.

To oczywiście nie wszystko, co wersja czwarta ma do zaoferowania. Postaram się troszkę szerzej opisać wszystko to, co uważam za ważne/ przydatne.

A skąd go wziąć? PowerShell 4 jest wbudowany w Windows 8.1 i Windows Server 2012 R2. Dodatkowo można ściągnąć paczkę na starsze systemy – Windows Management Framework 4. Wspierany jest Windows 7, Windows Server 2008R2, Windows Server 2012. Jedna uwaga, bo wiele osób się o to potyka: zanim zaczniecie instalować WMF sprawdźcie, czy macie na docelowej maszynie .NET Framework 4.5. Wymóg ten jest wymieniony na stronie, ale instalator warunku tego nie sprawdza. Więc instalacja się “powiedzie”, ale dodatek nie będzie zainstalowany. Trzeba samemu sprawdzić, czy Wasza maszyna ten warunek spełnia, na instalatorze w tym względzie polegać nie można.

MTS: Będę^H^H^Hyłem prelegentem

To był mój drugi raz na MTS, drugi raz w roli prelegenta. Tym razem jednak byłem na nim wyjątkowo krótko: nie doczekałem nawet końca sesji Pauli o hasłach (wolałem dotrzeć na lotnisko przed czasem, niż się spóźnić). Przy okazji: umieszczanie sesji Pauli w małej sali (dla niej 400 osobowa jest zdecydowanie malusia) to kiepski pomysł, wiadomo jaki będzie finał (brak miejsc stojących). Oprócz tego “załapałem” się na sesję Marka Minasi. Nie zawiodłem się w obu przypadkach. Oczywiście, byłem też na sesji w tej samej sali, którą wciśnięto w tę gwiazdorską “kanapkę”, ale ponieważ sam ją prowadziłem, wyboru za bardzo nie było. Mam wrażenie, że na takim tle człowiek z moim doświadczeniem był skazany na pożarcie, jak przyjdą oceny sesji będę się mógł przekonać, czy jednak udało się wyjść “na tarczy” (przy okazji: przypominam, że nadal można wypełniać ankiety na stronie konferencji, jak sądzę dostępnej po zalogowaniu). Sesja zatytułowana “Pogromcy (PowerShellowych) mitów” skupiała się na wszystkim tym, co o PowerShellu można usłyszeć, a co niekoniecznie jest prawdą. Prezentację i dema możecie oczywiście ściągnąć. Od razu uprzedzam, że nie wszystkie Wam zadziałają (szczególnie ostatnie demo, w czasie którego posługiwałem się OMI).

Kilka elementów o których wspomniałem/ prezentowałem w trakcie sesji, lub w ramach pytań już po jej zakończeniu:

• moduł TabExpansion++ (postaram się go opisać wkrótce nieco szerzej) – tab w netsh
• moduł PSReadLine – czyli powershell.exe ulepszony (j.w. – planuję go opisać)
• OMI (linkuję do cyklu postów na moim angielski blogu, którego finał prezentowałem)

Reszta, jak sądzę, nie wymaga żadnych dodatkowych linków. Osobiście jestem raczej zadowolony z przebiegu sesji: udało się opowiedzieć o wszystkim, skończyłem przed czasem (dając miejsce na pytania) co w przypadku 30-minutowej sesji może się wydawać niemożliwe (tak założyłem w zeszłym roku, przez co oceny za “pytania” ankietowani opatrzyli odpowiednim komentarzem ). Troszkę żałuję, że nie miałem możliwości zostać na całej konferencji (uwaga do organizatorów: wybór terminu w środku tygodnia zdecydowanie komplikuje sprawę…). Cóż, zawsze pozostaje następny rok.

Zmiany lub krajobraz post-nuklearny.

A teraz to, o czym obiecałem napisać na samym początku: zmiany (czyt. wywrócenie życia do góry nogami), przez które w ostatnim czasie nie mogłem niestety oddać się pisaniu na tym blogu. Otóż w czerwcu/ lipcu zeszłego roku pojawiła się oferta pracy w Amsterdamie. Oferta o tyle ciekawa, że moje zadania w znacznym stopniu wiązałyby się z korzystaniem z PowerShella (lub innych narzędzi do automatyzacji). Minus? W Amsterdamie. Może nie do końca minus… raczej niedogodność, szczególnie dla faceta żonatego i dzieciatego. Dodatkowo w tym samym czasie szukaliśmy (a nawet wg naszej oceny – znaleźliśmy) dom, do którego zamierzaliśmy się przeprowadzić (oczywiście, szukaliśmy w Wwie). Sprawa z domem się posypała, oferta pracy stała się bardzo konkretna (po rozmowie telefonicznej, zdaniu testu na inteligencję i całodziennym interwju w siedzibie w firmy). Po obgadaniu sprawy z żoną zdecydowaliśmy się spróbować. I tak to od miesiąca pracuję w firmie Optiver w Amsterdamie, mieszkam w mieście pod Amsterdamem (Hoofddorp) i mam wreszcie czas i energię, by nadrabiać zaległości powstałe w wyniku detonacji tej małej “bomby” w moim życiu prywatnym i zawodowym. To właśnie dlatego na MTS byłem tak krótko. Ale i tak jestem przekonany, że gra jest warta świeczki i w ostatecznym rozrachunku na tej decyzji skorzystam zarówno ja sam, jak i cała moja rodzina.

~ - autor: Bartek Bielawski w dniu 27 października, 2013.

Napisane w PowerShell
Tagi: MTS, OMI, Optiver, PowerShell v4, PSReadLine, TabExpansion++