taka zabawka… skrypt destroy-AzureVM do usuwania VM wraz z zasobami powiązanymi:
przydatne zwłaszcza do LABów, żeby nie zapominać i nie płacić bez sensu za przypadkowo pozostawione śmieci.
eN.
przeglądając ostatnio changelog dla commandletów ExchangeOnlineManagement znalazłem bardzo miłą informację.
po pierwsze w końcu PS dla EXO zaczyna się normalizować. po dziwnych zawirowaniach i wydania ExchangeOnline 1.0.1 określonej jako… V2, w końcu ktoś poszedł po rozum do głowy i dał i wersję 2.x . niby drobna rzecz, ale istotna, ze względu na przejrzystość.
ponadto, pomimo że GraphAPI dla EXO jeszcze nie ma, dostarczony został [trochę wydrutowany, ale zawsze] sposób, na bezhasłowe połączenie do konsoli. nie wymaga to zbyt dużo gimnastyki, a pozwala na tworzenie skryptów w trybie nienadzrorowanym [unattended].
eN.
moja Babcia mawiała: “przyszła kryska na matyska“. może nie w takim terminalnym znaczeniu, ale i do mnie przyszło to, co nieuniknione – przesiadka na GitHub.
to oczywiście proces, każdy skrypt muszę odkurzyć a wiadomo… jak się patrzy na swój kod sprzed kilq lat, to czasem kończy się na … napisaniu od nowa. tak było np. ze skryptem, służącym do ściągania darmowych eBooków MSPress.
większość skryptów przygotowuję w ramach różnych projektów. pomimo, że staram się używać prawidłowych zasad pisania, to jednak przerobienie skryptu napisanego dla konkretnego środowiska na uniwersalny, czasem wręcz nie ma sensu. każde środowisko, każdy klient, każdy projekt – to tak specyficzna kombinacja, że nawet sens danej automatyzacji jest tak specyficzny, że nie da się go ‘zuniwersalizować’.
to dość ciekawa lekcja – wziąć coś, co uważa się za dobrze napisane i przygotować to do opublikowania. nagle okazuje się, że komentarze słabe, że jakieś zmienne głupio poopisywane, że braqje obsługi błędów, bo przecież dla siebie nie trzeba…. w sumie te tematy gdzieś przez WF się przewijają, ale z początkowego pomysłu żeby po prostu opublikować bibliotekę, już po kilq minutach wiedziałem, że to byłby duży błąd.
ale powolutq będę tą bibliotekę rozszerzał.
Visual Studio Code zagościło już na moich wszystkich stacjach. ale cały czas jest powodem wielu frustracji – to przykład szwajcarskiego scyzoryka. ma wszystko, ale jak się chce nim coś konkretnego to okazuje się że problem – za krótki, żeby chleb ukroić, za wąski i za ostry do masła, niby wszystko się da, ale w ręq nie leży dobrze… itd…
najprostsze rzeczy nagle okazują się skomplikowane… ale cóż. jak już się to dostosuje, to sporo ułatwia. jednak tak ogólnie: nie polecam. chyba, że ktoś na prawdę trzepie tych skryptów na potęgę i to nie sam tylko w teamie. z gita można korzystać ze zwykłej linii poleceń więc ISE+git też jest dobrym zestawem. ale liczę na to, że ten zainwestowany czas się kiedyś zwróci… poza tym jest challenge (;
Zadaniezadanie jest proste – napisać GUI, które pozwoli wyłączyć maszynę w Azure z opcją force. tego normalnie z interfejsu zrobić się nie da, a operacja potrzebna. chodzi o przeniesienie zadania z 2giej czy 3ciej linii wsparcia do 1szej, czyli nie ma opcji na jakąkolwiek linię poleceń. musi być GUI.
poniżej dwa skrypty, które realizują to samo zadanie. jeden napisany w tym co PS daje [z małym wyjątkiem], drugi w Formsach. przykład ma posłużyć do porównania tych metod i pozwolić się zastanowić jakie są ‘za’ i ‘przeciw’ dla obu.
pełny skrypt można pobrać z GitHuba, poniżej omówienie fragmentów.
założeniem tej wersji jest szybkość działania i uniwersalność. nie korzystam póki co z wersji PS Core ale na pewno korzystanie z biblioteki forms nie będzie możliwe. dla Core można korzystać z XAML UI, którego również jeszcze nie testowałem. jak już pisałem – jedną z bolączek pisania skryptów z GUI jest już sam dobór bibliotek i decyzja ‘gdzie ten skrypt będzie uruchamiany i przez kogo’ /:
dla tego ‘natywne’ skrypty zachowują lepszą kompatybilność i uniwersalność.
niestety natywnych kontrolek jest niezmiernie mało. najważniejszą jest out-GridView, które umożliwia wyświetlenie listy lub obiektów w postaci interaktywnej tabeli, pozwalając na sortowanie, filtrowanie etc. pozwala również na wybranie pojedynczego lub wielu elementów – czyli może być przydatny również wtedy, kiedy chcemy pozwolić użytkownikowi wybrać obiektów do dalszego przetworzenia. i choć daje wiele możliwości, to równocześnie bardzo niewielką kontrolę.
fragment kodu do którego się odwołuję to:
function select-RG {
param(
$RGList
)
write-host -ForegroundColor Yellow "Select Resource Group VM resides on"
$RG=$RGList|out-gridview -title 'Select Resource Group' -OutputMode Single
if([string]::isNullOrEmpty($RG)) {
write-host 'cancelled by user. quitting' -foreground Yellow
exit -1
}
write-host "$($RG.ResourceGroupName) chosen. reading VMs..."
return $RG.ResourceGroupName
}
w szczególności linia pokazująca listę odczytanych Resource Groups w postaci interaktywnej. Out-GridView ‘daje-to-co-daje’ czyli nie da się kontrolować wyglądu okna. to co możemy zrobić to:
siła tkwi w prostocie. chwilę później jednak można zobaczyć:
do {
#choose RG
$ResourceGroupName=select-RG -RGList $RGsInThisSub
$VMlist=get-VMList -RGname $ResourceGroupName
if([string]::isNullOrEmpty($VMlist)) {
write-host "This Resource Group do not contain any VMs. Do you want to select another RG?"
switch (
[System.Windows.Forms.MessageBox]::show($this,"Choose another Resource Group?",'CONFIRM','OKCancel')
) {
'OK' {
#do nothing - VMList is null which will trigger loop
}
'Cancel' {
Write-Host -ForegroundColor Yellow "operation cancelled by the user. quitting."
exit -1
}
}
}
} while( [string]::isNullOrEmpty($VMlist) )
czemu nagle pojawia się Forms? to niestety sqcha twórców PowerShell – o ile WScript dysponował prostym okienkiem OK/Cancel, o ile jest OGV w PS… o tyle nie ma takiego prostego okienka OK/Cancel w PS.
co ciekawe, można takie okienko wyświetlić bez Forms! w taki sposób:
Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::show("Choose another Resource Group?",'CONFIRM','OKCancel')
pomimo, że wyglądają bardzo podobnie, i dają niemal ten sam efekt, pod spodem wydarzają się trochę inne rzeczy. jeden jest częścią PresentationFramework drugi Forms, mają inne konstruktory. lepiej używać Formsowego z dwóch powodów:
jak już coś pisaliście co wymaga interakcji, powinniście zadać pytanie – czemu nie użyć readKey? natywne, nie wymaga importu bibliotek, szybsze … i tak dalej.
zgoda. ale celem nadrzędnym jest wygoda endusera i założenie, że nie jest bystrym inżynierem (; kiedy zrobiłem readKey, a skrypt miał mieć GUI, sam łapałem się na tym, że czekałem i czekałem… aż zorientowałem się, że to skrypt czeka na mnie, a nie odwrotnie. załamanie logiki – tutaj interfejs a tu linia poleceń – jest bardzo złym podejściem. albo decydujemy się robić skrypt tak, albo inaczej – ale musi być spójnie. inaczej ani nie jest łatwy w użyciu ani prosty w strukturze.
readKey to nie GUI tylko metoda na interakcję bez GUI.
całość do pobrania z GitHub . kilka uwag n00ba dotyczących pisania PS+Forms.
pierwszą rzeczą jaka rzuca się oczy to narzut ilości kodu. do wykonania mamy jedno polecenie (jedna linijka). w wersji opisywanej wcześniej wyszło 126 linii kodu, tutaj mamy już prawie 19o. jasne się staje że podstawowym problemem będzie możliwy bałagan wynikający z samej ilości. dla tego części dotyczące rysowania samego interfejsu warto oddzielić od reszty. niektórzy decydują się na utworzenie projektu, w ramach którego jest kilka oddzielnych pliqw, i definicje interfejsu wyrzuca się do takiego oddzielnego pliq. spoko, ale ze względu na spójność, przy takich małych toolach wolę trzymać wszystko w pojedynczym pliq. łatwiej go przesłać do niedoświadczonych użytkowników, wytłumaczyć że to taki plik i już, niż kazać tworzyć jakąś strukturę, czy martwić się, że ktoś kawałek usunął czy nie skopiował. ale to oczywiście kwestia wyboru – ważne, żeby sobie oczyścić kod i możliwie mocno oddzielić logikę od definicji.
nie jest to oczywiście do końca możliwe, bo tak, jak opisywałem poprzednio, logika jest de facto związana z interfejsem – trigger-action. klikniemy guzik to uruchomi się jakiś kawałek. całą sekwencyjność szlag trafia.
ja póki co przyjąłem metodę tworzenia regionów – widać znaczniki #region i #endregion które dzielą skrypt na bloki – tutaj 3 bloki – interfejs, akcje interfejsu i cała reszta. zaleta jest taka, że większość edytorów rozpoznaje ten znacznik i pozwala zwinąć tą część kodu żeby nie pasqdziła widoq.
niewątpliwie pisanie skryptów z GUI jest dużo trudniejsze i dużo bardziej czasochłonne. tak, jak przy zwykłym skrypcie 6o-8o% czasu to praca nad logiką działania, tak tutaj, ok. 9o% czasu zjadło mi badanie reguł interakcji między poszczególnymi elementami. ok, uczę się więc potem będzie łatwiej, ale nawet przy tak banalnym skrypciq sprawdzenie czy odpowiednio wyczyszczą się wartości konkretnych kontrolek, czy finalnie ustawiona/przeczytana zmienna jest prawidłowa, czy może pozostało coś z klikania usera, czy guziki są aktywne kiedy trzeba, do tego jak to zoptymalizować, że nie ładowało w kółko po pół minuty…
do tego commandlety Az są… hmm.. nie działają zbyt dobrze q: connect-AzAccount się regularnie [niedeterministycznie] zawiesza po zabiciu okna logowania [cancel], zawiesza się dużo bardziej w Vistual Studio Code, a get-AzContex nie implementuje prawidłowo ErrorAction SilentlyContinue…. żeby tak podać najważniejsze. ogólnie to dość trudna biblioteka do współpracy, bez względu na GUI.
eN.
już za tydzień ITechDay. zastanawiałem się, jak to będzie wyglądało organizacyjnie, a ponieważ jestem po spotkaniu z organizatorem, garść informacji. jeśli jesteś zarejestrowanym uczestnikiem to pewnie już dostałeś instrukcje, ale IMHO najważniejsze:
w dobie ‘wszystko zdalnie’ uczestniczyłem już w różnych eksperymentach – ten niewątpliwie będzie największym/najbardziej rozbudowanym. jedną z najcenniejszych funkcji konferencji jest networking, i ta formuła ma go umożliwić. podobnie do realnego wydarzenia będą ‘stoiska partnerów’ czyli oddzielne breakout rooms gdzie można będzie zapoznać się ofertami sponsorów i dowiedzieć czegoś na temat ich produktów, hydepark aka “wirtualna pizza” – miejsce, gdzie będzie można swobodnie sobie chatować z innymi i kilka innych ciekawych pomysłów.
…reszta już w rękach uczestników.
PS. a w tym tygodniu virtualny Ignite. tak dla porównania q:
eN.
ITD2o’już 29.IX, [przekornie] ostatni wtorek miesiąca, odbędzie się konferencja ITechDay. również będę miał zaszczyt poprowadzić jedną z sesji. niestety, nadal w atmosferze covidowym, czyli zdalnie, w postaci Teams Live Events, ale co najważniejsze – live. modne ostatnio robi się ogłaszanie ‘konferencji’, które okazują się spreparowanym portalem z sesjami offline…. nie tutaj (:
…bardzo nie lubię sesji zdalnych, brak kontaktu z publiką nie daje feedbacku… ale cóż. znak czasów. mam nadzieję, że ITD21′ odbędzie się już w pełni na żywo. jest opcja komentowania, co prawda z opóźnieniem ~3osec, ale zawsze. przynajmniej nie ma problemu z wejściówkami (;
eN.
Społeczność WGUiSW.org wraz z Partnerami gorąco zapraszają na kolejną konferencję z cyklu ITechDay.
Wydarzenie odbędzie się w formule online z wykorzystaniem platformy Microsoft Teams.
Tematami wiodącymi konferencji będą:
Sesje będą odbywały się równolegle w sześciu ścieżkach tematycznych:
Sesje poprowadzą znani prelegenci posiadający bardzo bogate doświadczenie praktyczne poparte wieloma certyfikatami zawodowym.
Udział w konferencji ITechDay jest bezpłatny.
Zapraszamy na www.ITechDay.pl oraz www.facebook.com/ITechDay.
GUI w skryptach?zasadniczo jestem przeciwny takiemu pomysłowi. celem skryptów jest automatyzacja, a ich największą zaletą jest przetwarzanie potokowe – wyjście jednego skryptu staje się wejściem dla innego. dodanie GUI łamie te zasady – przede wszystkim zakłada interakcję, podczas gdy punktem wyjścia dla skryptu jest podanie parametrów ‘up front’ dające automatyzację danego zadania.
GUI jest oczywiście niezbędny dla 1szej/2giej linii, ale również pojedyncze zadania łatwiej przeważnie wyklikać. można też wyobrazić sobie rozwiązanie ‘hybrydowe’ [takie modne słowo w dzisiejszych czasach… od paznokci poprzez samochody aż po architekturę IT] – skrypt przyjmuje parametr [np. nazwę pliq wejściowego], a kiedy go nie ma, pokazuje jakiś file-picker czy coś… nie jest to koszerne, ale koniec-końców decyduje zamawiający.
w ostatnim czasie musiałem wrócić do poważnego skryptowania [yyyeeeeey! (= ] właśnie z myślą o narzędziach dla 1szej linii. w zwizq z tym musiałem zmierzyć się z pisaniem pełnego GUI w PowerShell. w związq z tym kilka wniosków i spostrzeżeń.
w oprogramowaniu GUI jestem n00bem. ostatnie aplikacje okienkowe pisałem w Javie na studiach. do tego jeszcze moja ogólna niechęć do takiego pisania… a więc wpis cenny dla tych, którzy są na tej samej drodze.
są trzy podstawowe metody uzyskania interfejsu dla skryptów:
[System.Windows.MessageBox]::Show(MessageBody,Title,ButtonType,Image)która natywna dla PS nie jest, ale dobrze uzupełnia możliwości.
dokładniejszy opis w przyszłości, co kiedy jak i z jakim efektem, a póki co
zwykłe ISE przestaje wystarczać – nie tyle z powodu samego GUI, co ogólnie tego, że ostatnio piszę więcej. zacisnąłem zęby i po raz kolejny przesiedziałem nad odpaleniem VSCode. VSC niestety jest makabrycznym narzędziem, jednak jego potencjał i choćby możliwości integracyjne są na tyle ważne, że cóż.. płaczę, ale walczę. kiedy to było tylko hobby, odpuszczałem zniechęcony, ale kiedy trzeba bardziej na poważnie, musiałem się złamać
czemu warto pocierpieć? przy pewnej wielkości czy skomplikowaniu skryptu, nie mówiąc o projekcie w którym tych skryptów jest wiele, ale nawet kiedy po porostu trzeba przy nich popracować więcej – ISE to za mało. lepsze wyświetlanie składni, czy masy skrótów klawiszowych, znacznie przyspieszają pracę. integracja z repo, projekty… jest wiele dodatków, bez których byłoby więcej ręcznej pracy – czyli to co jest wadą, przy zainwestowaniu czasu, staje się podstawową przewagą.
jeśli więc czeka cię przesiadka – zarezerwuj sobie przynajmniej tydzień nieskończonej cierpliwości. będzie za to nagroda w postaci dużych możliwości i jeszcze większego potencjału. jeśli jednak nie korzystasz z repo, piszesz hobbystycznie lub okazjonalnie – ISE to wszystko co potrzebne i szkoda czasu i stresu.
niestety VSC nie pomaga zbytnio w pisaniu GUI. może są dodatki, których jeszcze nie znalazłem, ale ogólnie – oprogramowanie GUI w edytorze nie-wizualnym to porażka. kilka elementów i robią się setki linii kodu ciężkie do ogarnięcia. ustawianie guzików zmieniając ich położenie wartościami X/Y na czuja – makabra. interfejs najlepiej się rysuje w interfejsie, dla tego najsensowniej jest mieć coś wizualnego. chciałoby się powiedzieć Visual Studio… huh, ale VS do pisania skryptów PS, to jak instalacja Exchange on prem w pełnej redundancji do wysyłania kilq emali.
w skrócie – cały czas jestem w trakcie poszukiwania jakiegoś lekkiego designera interfejsu. te, które testowałem online były … jak to aplikacje online – siermiężne i ograniczone.
już sam wybór tego w czym ten interfejs ma być napisany nie jest łatwy. formsy wygrywają ilością dostępnych przykładów, UWP [chyba] umiera, WPF niby jest trendem, nowsze, nowocześniejsze i bardziej uniwersalne… ale czy przyszłościowe? no właśnie – nawet po przeczytaniu kilq artów, jeśli nie siedzi się w temacie, sam dobór biblioteki nie jest trywialny. jeśli się uczyć, chciałoby się nauczyć czegoś, co choć przez kilka lat się przyda. a to w obecnym tempie zmian niełatwe zadanie.
osobiście póki co zdecydowałem się na formsy – stare, dobre, oklepane, dużo przykładów, a póki Microsoft nie zrezygnuje z Windows na rzecz jakiejś hybrydowej dystrybucji [chciałoby się powiedzieć Lindows, ale to już było] , zgromadzona wiedza powinna żyć przez jakiś czas.
ciekawym aspektem jest zmiana paradygmatu całej logiki działania. skrypty, poniekąd z samej definicji skryptu – przetwarzane są sekwencyjnie linia po linii. tak też logika pisania jest ‘liniowa’. GUI to z kolei ‘rozproszona logika’ pozaczepiania pod elementy interfejsu. całość nie jest już jak opowiadanie:
begin { początkiem }
process { rozwinięciem }
end { i końcem }
w zamian staje się fragmentarycznym kodem, sterowanym akcjami z kliknięć czy innych list. dla skrypciarza z krwi i kości to jest inny świat. dziwny i nie do końca logiczny.
na tym etapie nie mam jeszcze wyrobionych ‘best practice’ więc poszuqję. jednym z pomysłów było zadziałanie tak, jak to przez pewien czas projektował Microsoft [i co mi się bardzo podobało] – interfejs służył do zebrania informacji, wizualizacji elementów, ale ostateczna akcja to był po prostu skrypt uruchomiony z parametrami, których wartości były zebrane z interfejsu.
takie podejście jest świetne jednak w momencie kiedy pisze się duże, rozbudowane narzędzie, aplikację pozwalającą na wykonanie wielu zadań. jednak drobny tool, którego celem jest właśnie ograniczenie wyborów i dostosowanie do konkretnego zadania w konkretnym środowisq powoduje, że rozdzielenie na dwa niezależne skrypty [jeden to GUI do zebrania parametrów, drugi do wykonania akcji] tworzy dużą nadmiarowość. ponadto takie podejście choć ‘ładne’ i logiczne, utrudnia uruchomienie osobom, które tych skryptów się już i tak boją. to te niuanse – łatwiej komuś nieqmatemu przesłać jeden plik do uruchomienia, niż kilka, z opisem jak zrobić bibliotekę, czy jak przygotować środowisko. w regularnej aplikacji załatwia to instalator, przy skrypcie to już nie takie proste.
z kolei zaletami oddzielenia GUI od logiki jest łatwiejsze panowanie nad samym wykonaniem, no i dla osób, które GUI nie potrzebują – od razu jest narzędzie. większa uniwersalność. mam nadzieję pokazać przykłady za jakiś czas.
praktyka pokaże który sposób wygra, choć widzę coraz więcej zalet rozbicia tego monolitycznego podejścia na rzecz bardziej uniwersalnej metody…
skoro skrypty nie są do pisania GUI, przesiadka jest trudna, to czemu po prostu nie zacząć pisać np. w C#?
proste: mimo-wszystko łatwiej nauczyć się oprogramowania samych Formsów, niż całego języka. na drugi dzień byłem w stanie narysować prosty interfejs, podpiąć logikę i zbudować jakiś działający skrypt. a to dla tego, że cała faktyczna logika, aktywna część działania była tym, co znam, w postaci commandletów. nauczenie się napisania tego w C# i poznanie całej specyfiki samego języka, zajęła by znacznie więcej czasu. choć podobny do PS – jest czyś zupełnie innym. no i podstawowa rzecz – nie zamierzam być developerem [może kiedyś, hobbystycznie] a tego rodzaju zadania są ‘szybkim wsparciem’, a nie moim codziennym zajęciem. póki co nauka C# byłaby stratą czasu.
jak mawiają: ‘życie składa się z kompromisów’. kompromisem jest tutaj wyważenie efektu i czasu. pozostają zalety skryptu: kod nie jest kompilowany, łatwo go przeczytać a w razie potrzeby zmodyfikować ‘gdziekolwiek’, bo bez konieczności rekompilacji, commandlety dają obszerne biblioteki o olbrzymich możliwościach, a równocześnie można dopiąć kawałek GUI – i to wszystko w bardzo krótkim czasie.
może Frankenstein, ale żywy i myślący.
eN.
w-files’om strzeliła w tym rokq piętnastka… czas w IT liczy się trochę inaczej – 15 lat to kilka epok. jeśli przypomnieć sobie jak wyglądał ten świat w 2oo5… trochę sobie przypomniałem przeglądając stare artyqły… długa droga to była i wyboista ale jakże emocjonująca. praca (i po części hobby) zajmuje większość życia – więc ten nLog, choć przez pryzmat technologii i zawodu, ale opowiada ciekawą historię – zarówno o ewolucji technologii jak i mnie samego.
<chwila nostalgii>
wszystkiego naj, wfilesowicze! z tej okazji drobny refresh strony – lżejszy, kompatybilny z aktualnymi wersjami i wyświetla się prawidłowo na mobilu… które w czasach tworzenia poprzedniego szablonu nie służyły za codzienne narzędzie do oglądania treści w Internecie. no i bezpieczniejszy. mam nadzieję, że wytrzyma następną epokę.
pro publico bono.
eN.
nazwy pliqwnazewnictwo pliqw wyjściowych wydaje się sprawą trywialną. w najprostszej wersji, wygodnej zwłaszcza dla pliqw tymczasowych można to zrobić tak:
[System.IO.Path]::GetRandomFileName()
generuje to unikalne nazwy pliqw z uniknięciem konfliktów, tego pokroju: “4toqskhi.qbk”.
ale w przypadq logów lub wyjścia, które będzie dalej wykorzystywane, pliki muszą mieć bardziej konkretne nazwy, i pomagać nie pogubić się w przypadq wielu uruchomień i konieczności kontroli co-do-czego. większość skryptów, odruchowo, zaopatruję w funkcję logowania, a sam plik logu, aby wiadomo było czego dotyczy, ma nazwę skryptu:
$logFile="_$( ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName )-$(Get-Date -Format yyMMddHHmm).log"
dzięki temu logi zaczynają się podkreślnikiem (wygodne sortowanie i wyróżnik), zawierają nazwę skryptu (wiadomo czego log dotyczy) oraz daty (dzięki czemu łatwiej zorientować się, o który chodzi). np tak:
skrypt: new-CloudUser.ps1 log: _new-CloudUser-202008051001.log
ale log to jedno, a wyjście do dalszego przetwarzania to inna para kaloszy. podstawowym typem pliq z jakim pracuję to CSV – głównie ze względu na łatwość w dostarczaniu wyników dla biznesu (w postaci xlsx) oraz oczywiście – niezmierną łatwość w pracy z tym formatem. okazuje się, że w wielu scenariuszach, przy których plik jest przetwarzany przez biznes i ma do niego z powrotem trafić po obróbce, najlepiej, żeby nazwa odzwierciedlała nazwę pliq wejściowego. a przy kilqkrotnym przetwarzaniu powinna być jakaś inkrementalna wartość liczbowa. można to oczywiście osiągnąć na wiele sposobów, ale lubię eleganckie sztuczki, wykorzystujące fajne mechanizmy – np. takie jak regex.
choć z wyrażeń regularnych korzystam od bardzo dawna i wkładam wiele wysiłq, żeby je okiełznać, to nadal pozostają dużym wyzwaniem. są IMHO jedną z najtrudniejszych do opanowania technik i nadal czuję się n00bem, nie potrafiąc ogarnąć backreferences czy wykorzystania pewnych elementów w ramach przetwarzania regex. to jest świetna gimnastyka dla umysłu, więc często tworzę regexy tak, jak niektórzy grają w sudoq. oczywiście przy wielu zastosowaniach lepszej metody ani bardziej wydajnej nie ma. inaczej trzeba by pisać setki pozagnieżdżanych IFów czy switchy, a w niektórych przypadkach nawet to nie da rezultatu.
Ale często chodzi o zwykły “challange” – bo jak się czegoś nauczyć inaczej, niż korzystając z tego?
a więc w celach edukacyjnych, przeanalizuję taką funkcję:
$fileInput=get-Item $inputCSV
if($fileInput.BaseName -match '-prepped(?<inc>\d{0,2})') {
$outputCSV=$fileInput.BaseName -replace '-prepped\d{0,2}-[\d]+',"-prepped$( if($Matches.inc) { (([decimal]$Matches.inc)+1).toString("00") } else { "02" } )-$(Get-Date -Format yyMMddHHmm).csv"
} else {
$outputCSV="{0}-prepped01-{1}.csv" -f $fileInput.BaseName,(Get-Date -Format yyMMddHHmm)
}
założenie: chcę aby przetworzony plik miał suffix ‘prepped‘ z numerkiem dopełnionym zerami, wskazujący na liczbę przetworzeń.
algorytm jest taki:
tutaj w sukurs przychodzą wyrażenia regularne. w PowerShell można stosować je niemal wszędzie, a każdym razie wszędzie tam, gdzie używamy funkcji ‘match’ lub ‘replace’ (ale pozwala na to również wiele poleceń). klauzula ‘if’ zawiera:
$fileInput.BaseName -match '-prepped(?<inc>\d{0,2})'
a ciekawym fragmentem jest oczywiście “(?<inc>\d{0,2})“, który oznacza:
czyli ciągi spełniające definicję szablonu i zwracające ‘True’ to np:
w zmiennej $Matches, pod nazwą ‘inc’ będzie przechowywana liczba… a w zasadzie ‘ciąg znaków składający się z cyfr’ bo będzie to [string]. chyba, żeby nie. bo jeśli mamy tylko “-prepped-” to element ‘inc’ się nie pojawi (będzie $null) – czyli w pierwszym prezentowanym przykładzie, wartość “$Matches.inc” będzie $null.
po przejściu ‘IF’ wykonywany jest ‘replace’, który również korzysta z regex. tutaj pojawia się dodatkowo “[\d]+” i nie ma nawiasów okrągłych:
$outputCSV=$fileInput.BaseName -replace ‘-prepped\d{0,2}-[\d]+‘,”-prepped$( if($Matches.inc) { (([decimal]$Matches.inc)+1).toString(“00”) } else { “02” } )-$(Get-Date -Format yyMMddHHmm).csv”
ciąg spełniający szablon opisany pogrubioną czcionką, zostanie zastąpiony wyliczeniem, opisanym na pomarańczowo. a co się tam dzieje?
C:\_scriptz> [regex]$rxz='[abc]'
C:\_scriptz> $rxz.Matches('zaba')|select index,value
Index Value
----- -----
1 a
2 b
3 a
PS C:\_scriptz> [regex]$rxz='[abc]+'
PS C:\_scriptz> $rxz.Matches('zaba')|select index,value
Index Value
----- -----
1 aba
co się dzieje w funkcji generującej wynik?
"-prepped$(
if($Matches.inc) {
( ([decimal]$Matches.inc)+1 ).toString("00")
} else {
"02"
}
)-$(Get-Date -Format yyMMddHHmm).csv"
ciąg spełniający opisane wcześniej warunki, zostanie zastąpiony:
już sam fakt tego, ile trzeba zrobić opisu, żeby wyjaśnić malutkiego regexa pokazuje jaką kryje w sobie moc… a więc zamiast sudoq – proponuję przerobić sobie jakieś wyszukiwanie na wyrażenie regularne (:
eN.
125. WGUiSW – VSC okiełznane
na najbliższym WGUiSW, we wtorek 1.XII, będę miał SNACKa (krótka prezentacja, 2o min), na której pokażę czemu, pomimo niestabilności i dość wysokiego progu wejścia w VSC, jednak warto zainteresować się tym edytorem.
oczywiście to tylko przekąska do właściwych prezentacji – Krzyśka i Roberta oraz Hobby Marcina. czyli jak zwykle: warto poświęcić popołudnie na trochę wiedzy (:
eN.