Otwarty kod naprawdę działa!
PowerShell od wersji szóstej ma dwie cechy, których nie posiadał nigdy przedtem: działa na różnych systemach i jest projektem o otwartym kodzie. I o ile ta pierwsza cecha nie sprawiła, by nagle pojawiły się dystrybucje Linuxa z PowerShellem jako podstawową powłoką systemową (jeszcze?
), o tyle otwarty kod naprawdę działa, o czym przekonałem się ostatnio, gdy zachciało mi się podłubać nieco przy schematach plików JSON.
Zacznijmy jednak od początku. Szukając narzędzi do pracy ze schematem plików JSON, które działałyby pod kontrolą PowerShella, trafiłem na informację o nowym poleceniu: Test-Json, wbudowanym w PowerShell 6.1+.
Polecenie to nie tylko miało sprawdzać poprawność plików JSON w ogóle, miało też weryfikować ich zgodność z narzuconym schematem. Niestety, szybko okazało się, że nawet to pierwsze nie działa (lub raczej: nie działało) jak należy.
Pierwsze testy wypadły pomyślnie: testowy plik z danymi, testowy plik schematu, odpalamy polecenie – wszystko śmiga!
$schema = @' | |
{ | |
"$schema": "http://json-schema.org/draft-07/schema", | |
"type": "object", | |
"properties": { | |
"foo": { | |
"type": "string", | |
"pattern": "^.{3}$" | |
} | |
}, | |
"required": ["foo"] | |
} | |
'@ | |
'{ "foo": "bar" }' | Test-Json -Schema $schema | |
# True | |
'{ "bar": "foo" }' | Test-Json -Schema $schema | |
# PropertyRequired: #/foo | |
# False | |
'{ "foo": "baaaar" }' | Test-Json -Schema $schema | |
# PatternMismatch: #/foo | |
# False |
Skoro działa u mnie w domu, to i w pracy z pewnością zadziała. Pierwszy plik – znów, pełny sukces. Plik drugi: porażka. Sprawdzam dla pewności bez podawania schematu: wynik ten sam, marudzenie o nieprawidłowym pliku JSON:
'[ { "foo": "bar" }, { "foo": "nob" } ]' | Test-Json | |
# Test-Json: Cannot parse the JSON. | |
# False |
Dla pewności (i potwierdzenia zdrowia umysłowego) sprawdzam jeszcze za pomocą ConvertFrom-Json – pełen sukces.
'[ { "foo": "bar" }, { "foo": "nob" } ]' | ConvertFrom-Json | |
<# | |
foo | |
--- | |
bar | |
nob | |
#> |
Następny krok? Szukamy, czy ktoś na GitHubie podobnego problemu nie zgłosił.
Ano zgłosił. Inna osoba przejrzała kod i znalazła dziurę w całym. Ktoś jeszcze inny usunął ten swoisty włos z zupy, informując, że łata ta załapała się na wersję nieco nowszą niż ta, której używamy w pracy. Tam 7.2.6. U mnie – 7.3.1. Sprawdzam u mnie – istotnie, działa tak samo w obu przypadkach. Bez otwartego kodu z pewnością usunięcie tej usterki:
- zajęłoby więcej czasu
- jeśli nie byłoby dostatecznie wysoko na liście priorytetów – może nigdy nie zostałoby poprawione
- wymagałoby zaangażowania pracowników Microsoft zarówno w trakcie szukania usterki, jak i w trakcie jej usuwania
Szczególnie frustrujące jeśli uświadomimy sobie, że zmiana obejmowała… trzy linijki kodu (reszta zmian to dodatkowy test).