Artifactory

W chwili, gdy mamy dockera, to instalacja artifactory wydaje się bajecznie prosta. Tworzymy bazę danych, podajemy namiary na nią w konfiguracji docker compose i gotowe. Nie do końca. Artifactory działa z własnym UID i GUID ( 1030:1030). To oznacza, że jeżeli chcemy przechowywać wolumen artifactory poza domyślnym (lub skonfigurowanym odgórnie) katalogiem dockera, to trzeba pobawić się z odpowiednimi dostępami.

Tu mamy dwie opcje. Najpierw możemy uruchomić całość z użytkownikiem root tak jak zrobiłem to z nexusem, pozwolić się temu skonfigurować i potem zrobić chown. To zadziała, ale jest duża szansa, że po restarcie już z właściwym użytkownikiem nie wstanie. Dlaczego? Problem leży gdzieś między / a katalogiem docelowym. Gdzieś nie ma odpowiednich uprawnień, czegoś brakuje itd. Po dwóch wieczorach walki z tym rozwiązaniem stwierdziłem, że jebać to zrobię konfigurację domyślną. I ta, druga opcja zadziałała. Co prawda, oznacza to, że późniejszy backup całości będzie upierdliwy, ale jakoś przeżyję. Przynajmniej miałem takie założenie.

To, co jednak nie chciało działać, to sklejenie ze sobą proxy nginx i artifactory działającego w ścieżce /artifactory. Tutaj poległem po całości, ponieważ nie udało mi się tak skonfigurować tego wszystkiego, żeby chciało działać. Nie wiem, może głupi jestem. Artifactory wystawia dwa porty 8081 i 8082. Oba powinny być mapowane na localhost/artifactory, a w konfiguracji samego artifactory wystarczy dodać odpowiednią ścieżkę i powinno działać… no nie. Po prostu nie chciało to tak zadziałać. Albo wywalało zwykłe 404, albo doklejało do URL-a dodatkową ścieżkę budując localhost/artifactory/artifactory. Żeby jednak nie było, to da się to zrobić, ale trzeba mieć większą kontrolę nad własną siecią (i wiedzieć, jak nią zarządzać), ponieważ „sztuczka” polega na użyciu odpowiednich domen. Jak nie masz DNS, to nawet nie podchodź.

Poddałem się i pierdolnąłem to w kąt. Zainstalowałem Nexusa…

npm

… i na tym Nexusie skonfigurowałem sobie lokalne proxy repozytorium npm. Pomysł jest niezły, bo przy moim talencie do JS, wielokrotnie usuwam node_modules i wykonuję npm install. Zatem oszczędzanie transferu jest całkiem niezłym pomysłem. Jednak nie do końca.

Skonfigurowałem zatem sobie proxy na nexusie, a następnie w /etc/hosts dodałem:

Listing 1. Konfiguracja hosts

127.0.0.1 view-localhost localhost koziolek koziolek.home

Pierwsza instalacja za pomocą npm trwała wieki, ale kolejne poszły już bardzo szybko i zgrabnie. Mogłem odtrąbić sukces. Do czasu…

Github action i dziwny błąd

„Dla jednego z moich klientów, lidera na rynku…” w każdym razie potrzebuję czasami coś zbudować za pomocą Github Actions (GHA). Wypchnąłem kod, poszedłem na kawusię, wracam, a tam niespodzianka. Build wyłożył się na etapie npm install. Jednak sam komunikat był mocno enigmatyczny. Npm nie mógł znaleźć pakietu. Sprawdziłem lokalnie i działa. Dodałem pakiet bezpośrednio, ale GHA mówi, że nie może znaleźć. Nosz kurwa mać, twoja krzemowa. Termin goni, klient pyta, co się stało, że się zesrało, a ja nie mam pojęcia. Dżepetto podsuwa rozwiązania, które powodują jeszcze większe fakapy (nie działa lokalnie), a jeszcze człowiek chce skończyć pracę na dziś. Koniec końców usunąłem node_modules, lockfile npm i yarn wypchnąłem i po kolejnej nieudanej próbie zacząłem analizować, czego tak naprawdę npm szuka.

Okazało się, że w package-lock.json mam wskazane moje domowe domeny. Po prostu npm działa inaczej niż maven i zaszywa informację o pochodzeniu pakietu w pliku. Czy to ma sens? Moim zdaniem nie do końca, bo utrudnia pracę z wieloma repozytoriami pakietów. Jednocześnie rozumiem motywacje twórców, którzy wyszli z założenia, że bezpieczeństwo pakietów JS i powtarzalność procesu jest ważniejsza niż wygoda użycia.

Dlaczego działa to w twojej firmie?

Ponieważ cały proces zarówno lokalnego budowania, jak i CI/CD masz ogarnięty w ramach sieci wewnętrznej. Twój Jenkins, TeamCity, czy inne narzędzie widzi wszystkie potrzebne adresy. Względnie twoje firmowe repozytorium jest wystawione na świat i można się do niego dobić z zewnątrz.

Podsumowanie

Domowe środowisko pozwala na samodzielne przejście przez pewne procesy, których nie widzimy w codziennej pracy. Nie oznacza to jednak, że będziemy mieli łatwo. Odkręcenie błędu z npm zajęło mi dłuższą chwilę, ale udało się to ogarnąć. Pomysł na użycie Artifactory zarzuciłem, ale kiedyś wrócę do niego w ramach ćwiczeń z dockera. Na razie jednak czas na hardware.

Co chcę mieć – minimum?

Pomysł jest następujący. Na docelowej maszynie uruchomimy dockera, a następnie w ramach tego dockera uruchomimy:

• Postgresa do zarządzania różnymi bazami
• Jakiegoś menadżera repozytoriów do lokalnej pracy z mavenem, dockerem itp.
• Sewer www do domowych rzeczy (współdzielenie plików, linków itd.)
• NAS

NAS jest już hardwarowym tematem, więc na razie musi poczekać. Cała reszta nadaje się do przetestowania na moim obecnym komputerze, by później nie mieć fakapów i nie tracić czasu na duperele.

Jak zacząć?

Najlepiej od początku, ale wbrew pozorom nie jest to takie oczywiste. W tym przypadku podejście „odpal docker compose i nara” nie do końca zadziała. Inaczej. Zadziała, ale tak naprawdę tracimy z oczu całe tło, które przy migracji na docelową maszynę będzie bardzo istotne. Przecież sama migracja będzie gdzieś w połowie wakacji, więc też część wiedzy „wyparuje”.

Jeżeli nie jest się pełnoetatowym administratorem lub nie pracuje się w zespole hołdującym zasadom DevOps (DevOps to podejście do pracy, a nie stanowisko!), to też nie ma się wprawy w takich administracyjnych zadaniach. Zatem warto spędzić chwilę i zaplanować sobie pracę. Dodatkowo warto całość na koniec gdzieś wypchnąć, żeby później na środowisku docelowym nie musieć klepać wszystkiego od zera.

Plan

Plan był taki jak zawsze, czyli, że kiedyś to zrobimy. Jednak jakieś ~1,5 tygodnia temu stwierdziłem, że potrzebuję lokalne repo Artifactory, żeby ogarnąć jeden z moich projektów. I postanowiłem zrobić to dobrze :D

Plan był zatem następujący.

1. Stawiamy Artifactory jako kontener
2. Stawiamy bazę Postgres, jako kontener
3. Całość „zasłaniamy” nginx.

Niby proste, ale jak zwykle okazało się, że chciałem zrobić to dobrze, więc będzie pod górkę.

Przygotowania

Na moim GH znajdziecie repozytorium, w którym trzymam różne swoje konfiguracje. Jest to jedno z tych miejsc, które kiedyś sprzątnę, ale nie teraz :D Jakoże jest to taki „zakwas” dla moich komputerów, więc naturalną rzecz jest umieszczenie wszystkiego właśnie w tym repo. Nie chcę teraz dokładnie omawiać, co i jak w tym repo, bo to zupełnie osobny temat. W skrócie, mamy część w katalogu services, która będzie zawierać potrzebne mi rzeczy.

Postgres

Najprostszym do ogarnięcia wydawał się postres. I rzeczywiście, konfiguracja w kontenerze jest bardzo prosta, o ile nie chcesz nic zmieniać. Jedyne co dodałem, to init.sql, który sprawdza i w razie czego tworzy kilka baz danych. Ale…

Jeżeli chcemy przykryć wszystko za pomocą nginx, to mamy „mały” problem. Do takiej bazy danych nie dostaniemy się z zewnątrz. Należy zatem zrobić kilka rzeczy. Po pierwsze mapowanie portu 5432 na port hosta. To jest standardowe podejście, jeżeli używamy dockera. Jednak w docelowym systemie, nie możemy sobie pozwolić na dostęp do tego portu nikomu spoza wyznaczonej listy hostów. Hosty możemy zdefiniować na dwa sposoby:

1. Możemy utworzyć sieć dockerową, zakładając, że wszyscy zainteresowani będą łączyć się z tej sieci.
2. Możemy wystawić port, a następnie na hoście zablokować ruch do tego portu spoza naszej sieci za pomocą firewalla.

I tak źle i tak niedobrze. Pierwsze rozwiązanie pozbawia nas dostępu do bazy z aplikacji działających na innych maszynach. Ten postgres ma służyć do pracy, a nie do udawania, więc trzeba inaczej. Druga opcja jest lepsza, bo domowe komputery będą mogły się połączyć, ale nie mam dostępu „jakby co” spoza domu. Nie mamy dostępu do portu. Trzeba zatem postawić pgadmina i w nim skonfigurować dostęp do bazy. Zwykły obraz wystarcza. Kontener z pgAdminem działa w tej samej sieci dockerowej co postgres, więc formalnie łączy się z hostem postgres:5432. Komputery w LAN-ie będą łączyć się z hostem po IP_HOST:5432. Firewall załatwi resztę. Więcej nie potrzeba, bo poważne awarie i tak będe musiał obarnąć z domu.

nginx

Okazał się prostszy niż postgres :D Co jednak warto zrobić, to trzymać konfiguracje poszczególnych usług w osobnych plikach oraz nazwać serwer inaczej niż localhost. To przyda się później jak postawimy DNS, który ułatwi dostęp do maszyny innym komputerom w domowej sieci. Ale to później.

Artifactory, a w zasadzie Nexus

Największym problemem okazała się konfiguracja Artifactory. I nie mówię tuo prostej konfiguracji obrazu, ale o odpowiedniej konfiguracji proxy. Po kilku dniach wojowania stwierdziłem, że Artifactory nie jest moim must have, a Nexus też jest OK. Koniec końców zainstalowałem nexusa. Tutaj jedna sztuczka – przy pierwszym uruchomieniu należy to zrobić jako root ustawiając user: root w docer-compose.yml. Po wstępnym skonfigurowaniu hasła administratora należy zaaplikować chown -R 200:200 na pliki nexusa i zrestartować kontener. Ta magia jest potrzebna, jeżeli chcemy trzymać pliki poza domyślnym katalogiem z wolumenami dockera. Czyli w praktyce zawsze :D O tym dlaczego kiedy indziej.

Po skonfigurowaniu nexusa warto też sprawdzić, czy nasze lokalne buildy działają, jak należy. Pierwsze uruchomienie może być znacznie dłuższe, bo nexus będzie zaciągać pliki z głównego repozytorium.

Podsumowanie

Zabawa jest przednia. Dżepetto i Klaudyna pomagają pisać żmudne rzeczy, ale nie można im ufać. Modele AI mają wiedzę, która nie zawsze jest aktualna i odnosi się do starszych wersji narzędzi. Nie warto też walczyć, jeżeli coś nie chce działać, a nie mamy przymusu użycia. Zmarnowałem kilka dni an potyczkę z Artifactory, teraz wiem, że było to zbędne.

W miarę rozwoju projektu będę wrzucać kolejne opisy.

Czy słyszeliście o niedawnym zamachu i zabójstwie Melissy Hortman ^W? Nie? Cóż nie dziwota, bo sprawa została przykryta napadem Izraela na Iran. W dodatku pani Hortman, była zajomowała się polityką na poziomie stanowym, a nie krajowym. A może słyszeliście, że zamachowiec zaatakował też ( stanowego) senatora Johna Hoffmana ^W? Zapewne też nie. Jeżeli jednak coś tam słyszeliście i wasza wiedza ogranicza się, że zamachowiec to ultraprawicowy zwolennik pro-life (hehehe), to już dużo. Jeżeli jednak chcecie zrozumie DLACZEGO w USA dochodzi do tego typu zamachów, DLACZEGO w Kalifornii są tak silne protesty przeciwko deportacją i ogólnie rządom Trumpa, to polecam waszej uwadze książkę Piotra Tarczyńskiego pt. „Rozkład. O niedemokracji w Ameryce”.

Książka ta zabiera czytelnika w fascynującą podróż przez czas i przestrzeń historii USA. Zaczyna się niewinnie, od trochę dokłądniejszego opisania co stało się 6 stycznia 2020 roku w czasie tzw. „Szturmu na Kapitol”. Następnie autor zadaje pytanie, dlaczego do tego doszło w „nalepszej demokracji na świecie” (ponoć). I przystepuje do dekompozycji systemu politycznego USA.

Dawno na lekcjach WOS-u w moim najukochańszym VI LO psor Małgorzata Tudek (dziś Pani Dyrektor) opowiadała nam o różnych systemach politycznych. Jednym z nich był system USA. Zdawał się banalnie prosty, bo poza systemem elektorskim w wyborach prezydenckich, całość ma konstrukcję cepa. No nie koniecznie…

Po omówieniu wydarzeń z 2020r. Fundowana nam jest podróż w czasie. XIX wiek, XX wiek i historia dwóch głównych sił politycznych we współczesnym USA – Demokratów i Republikanów. Dla Europejczyka zaskakujące wydaj się, że jeszcze w latach 60-tych XX wieku, to Demokraci byli „tymi złymi”, którzy wspierali segregację rasową w wersji „hard”, a Republikanie byli ostoją liberalizmu. Nagle okazuje się, że nie kto inny, jak turbo-republikanin Regan podpisuje jedną z najbardziej liberalnych ustaw aborcyjnych (jako gubernator Kalifornii). I takich przykładów jest więcej. Podróż kończymy historią zmian jakie zaszły w GOP w latach 90-tych, gdy partia ta zaczęła się radykalizować.

Kolejne rozdziały, to „rozbiór” systemu wyborczego. Jak to jest możliwe, że prezydentem zostaje ktoś, kto ma niższe poparcie? I o ile jesteśmy to w stanie sobie wytłumaczyć na poziomie wiedzy wyniesionej ze szkoły (Elektorzy + zwycięzca bierze wszystko), to już odkrycie, że ten system jest wynikiem „dżentelmeńskiej umowy”, oraz wielu zgniłych kompromisów, jest pewnym zaskoczeniem. Podróżujemy też przez Senat, który z izby zadumy stał się cmentarzyskiem ustaw, bo w wyniku różnych sztuczek prawno-regulaminowych nie ma możliwości przeprowadzenia przez niego ustawy w sensowny sposób. I nagle odkrywamy, że Kongres ma wiele cech świetnie nam znanej demokracji szlacheckiej. Po czym autor funduje nam kolejny zestaw zaskakujących faktów o… prawach wyborczych.

Prawa te nie są aż tak powszechne, jak nam, z perspektywy Starego Kontynentu się wydaje. Co więcej, okazuje się, że cały system jest tak skonstruowany, że pozwala na wyeliminowanie „niewygodnego” elektoratu. I to nie tylko przez gerrymandering. Możemy odkryć, z pewnym przerażeniem, że w USA rasizm ma się całkiem nieźle i federalny Sąd Najwyższy go w sumie wspiera. Zresztą o tej instytucji też możemy dowiedzieć się wielu ciekawych rzeczy.

Autor kończy książkę próbą odpowiedzi na pytanie co będzie po wyborach w 2024r. Dziś wiemy, że jego predykcja jest nietrafna, bo nie założył „jeszcze gorszego scenariusza”. Jest też trochę o wewnętrznym terroryźmie, i to nie jest optymistyczny opis.

„Rozkład” to książka o amerykańskim systemie politycznym i o tym, jak wiele jego elementów, to tylko dżentelmeńska umowa. Jak w ciągu istnienia USA, poszczególne „prawa” były przedmiotem zmian i niepisanych umów. Książka jest ponura i z dzisiejszej perspektywy jeszcze bardziej zmusza do przemyślenia naszej wizji świata.

Prezydent to jakaś kiepska wersja polskiego króla.

THOMAS JEFFERSON W LIŚCIE DO JOHNA ADAMSA, 13.11.1787

No cóż…

Od wielu czynników, m.in. tego jaki jest stan początkowy. I o tym dziś opowiem.

W piątek pojawił się cotygodniowy newsletter od unteam, w którym był link do narzędzia pozwalającego na wydobycie ze strony tzw. Critical CSS. Pobawiłem się nim trochę przy współpracy Dżepetto i mam kilka wniosków. Po kolei…

Critical CSS, co to?

Założenie jest następujące. Przeglądarki wczytują i renderują kontent od góry do dołu, inaczej mówiąc, przetwarzają HTML strumieniowo. Jeżeli natkną się na plik CSS, to go pobiorą. Jak trafią na nieznany plik z fontami, to go pobiorą. I tak też będą renderować zawartość strony. Najpierw wyrenderują to co jest widoczne, potem przejdą dalej. Procesem tym możemy sterować na wiele różnych sposobów. Możemy używać cache, możemy używać prefetch i preload. Możemy w końcu zadbać o to, żeby zasoby potrzebne do wyrenderowania strony były dostępne jak najwcześniej. I tu właśnie wchodzi Critical CSS. Jest to podzbiór reguł CSS używanych na danej stronie, które aplikują się do tej części strony, która będzie widoczna jako pierwsza.

Jak umieścić CSS na stronie?

Mamy dwa wyjścia (poza stylowaniem elementów ad-hoc). Możemy użyć tagu <style> w kodzie html lub możemy użyć <link> i wskazać plik z arkuszem stylu. Jeżeli wykorzystamy pierwszą metodę, to style zostaną przesłane wraz ze stroną, to zwiększa objętość dokumentu, ale zmniejszy liczbę żądań ( pomijam użycie cache). Kłopotliwe może być jednak utrzymanie spójnych styli pomiędzy różnymi dokumentami, ale to pomijalna kwestia, bo zakładam, że wykorzystujemy jakiś generator, a nie lecimy z palca w notepadzie. Druga metoda ładnie nam separuje style i dokument. Pozwala na użycie cache i całkiem zgrabne zarządzanie całością. Wadą jest ten nieszczęsny dodatkowy request, który czasami chcemy wykonań, a czasami niekoniecznie.

Ważne jednak jest też to w którym miejscu w kodzie stony umieścimy nasze znaczniki.

Critical CSS, jak działa?

Pomysł jest następujący. W nagłówku dokumentu, czyli w <head> umieszczamy znacznik <style> zawierający nasz krytyczny arkusz stylów. Przeglądarka, przystępując do renderowania, nie musi czekać na zewnętrzny arkusz. W dodatku jest to „minimal effective sheet”, czyli arkusz zawierający tylko potrzebne style w dodatku w ich efektywnej postaci, czyli w czasie ich aplikacji nie będzie następować nadpisywanie (cascade). Nasze właściwe style w postaci <link> umieszczmy przed znacznikiem </body>. Zostaną pobrane na samym końcu, zmniejszając „First Contentful Paint”, czyli czas jaki upływa do momentu wyrenderowania pierwszego elemantu na stronie. Mówiąc po ludzku, czas, po jakim użytkownik zobaczy, że coś się załadowało.

Praktyka

Korzystając z narzędzia z newslettera oraz przy małej pomocy Dżepetto przystąpiłem do wdrożenia tej techniki na blogasku. Pierwszym krokiem było określenie stanu obecnego. W tym celu wykorzystałem PageSpeed Insights i przygotowałem pierwszy raport. Jest bardzo dobrze. FCP na poziomie 0,4s dla desktopa i 1,5s dla mobilków, to dobry wynik. Kolejnym krokiem były wygenerowanie zestawu styli oraz podpięcie ich do bloga. Wygenerowałem więc zestaw dla strony głównej i kilku pierwszych artykułów. Następnie Dżepetto przetworzył je, wybierając część wspólną, sotrując wg. kolejności użycia, a na koniec zminifikował całość. Wysłałem i gotowe. Po chwili przygotowałem kolejny raport. I dupa. Okazało się, że wydajność strony spadła. FCP nie zmienił się, ale pojawił się problem z „Cumulative Layout Shift”.

Cumulative Layout Shift, co to?

Jest to metryka, która mówi, jak bardzo wygląd strony, zmienia się w czasie jej ładowania. Po ludzku, jak bardzo strona skacze „po załadowaniu”, czyli jak bardzo wkurza użytkownika. Tutaj wkurzał bardzo. Wartość 0,648 dla desktopu i 0,399 dla mobilki są dalekie od akceptowalnych. Szczególnie, że wcześniej wynosiły 0.

W efekcie wycofałem zmianę i parametry wróciły do normy.

Jeszcze inne podejście.

A co jeżeli potraktować cały arkusz css jako krytyczny? Korzystam z Jekylla, więc przynajmniej teoretycznie nie powinno być problemu z osadzeniem styli na stronie w elemencie <style>. Powtórzyłem więc zabawę, tym razem wstawiając cały css w nagłówek. Spowodowało to znaczne powiększenie wielkości dokumentu, co jest takie sobie. Z 15kb mamy nagle 35kb, a w dodatku średnio możemy używać cache, ale jakoś to ogarnę definicjami <meta>. Efekty były… cóż średnio zadowalające, o ile na dektopie raport nie wykazał zmian, to już na wersji mobilnej wydajność spadła. Zmianę wycofałem.

Podsumowanie

Dobra wiadomość jest taka, że z blogaska już zbyt wiele nie wycisnę, jeśli chodzi o wydajność :D Critical CSS jest ciekawym rozwiązaniem, ale trzeba mierzyć, mierzyć i jeszcze raz mierzyć, bo zamiast polepszyć, można popieprzyć. Wiem też, że brakuje mi wiedzy o nowoczesnych narzędziach, choć nie boli to aż tak bardzo. Nie jestem webmasterem ani frontasiem. Z rzeczy do zrobienia jest jeszcze ogarnięcie trackingu, ale to już zupełnie inna bajka.

Wraz z systemem typów w parze idzie też opis widoczności, czyli to w jaki sposób poszczególne typy mogą wchodzić ze sobą w interakcje. Opis ten to sławetne „modyfikatory dostępu”, które mogą, ale nie muszą, istnieć w danym języku. Jak to działa w Javie wiadomo. Problem pojawia się, gdy z jakiegoś powodu musimy dołożyć jeszcze jedną „warstwę” widoczności związaną z umiejscowieniem i rolą danego typu w naszej architekturze. I tu na pomoc przychodzą… interfejsy. Przynajmniej w Javie, bo założenie jest takie, że pomiędzy pakietami komunikujemy się za pomocą interfejsów. Stąd też domyślna widoczność metod jest publiczna. Jeżeli do tego dołożymy rekordy, które zdefiniujemy w ramach tych interfejsów, to mamy bardzo ładnie zdefiniowane API.

A co z konkretnymi klasami? Słuszne pytanie, bo przecież nie można stworzyć instancji interfejsu. Tu mamy tą straszną AbstractBeanFactoryFactory, czyli wzorce kreacyjne. Opakowaliśmy je jakieś 23 lata temu w Springa, a jeszcze chwile wcześniej w JEE. Zatem nie jest źle, prawda? No nie do końca, ponieważ nadal mamy problem z dostępem na poziomie architektury. Jeżeli interfejs Repository jest publiczny, to zarówno Service jak i Controller będą mieć do niego dostęp. Niby mamy moduły, ale… nikt nam nie zabroni wpisać requires repository w module-info kontrolera :D

Tu z pomocą przychodzi ArchUnit, czyli narzędzie do „testowaina architektury”. Nawet kiedyś dawno temu mówiłem o tym na SegFaulcie. Definiujemy kilka prostych regułek, które mówią które pakiety, gdzie powinny być używane i pora na CSa. I tak mniej więcej 95% programistów używa ArchUnita. Pozostałe 5% używa go jeszcze do sprawdzenia czy nie wołamy jakiś głupot w stylu System.out.println. Jednak to nie rozwiązuje wszystkich naszych problemów.

Publiczne, ale pakietowe, ale nie w testach

Mamy sobie taką biblioteczkę jak Quarkus Mailer. Definiujemy sobie interfejs za pomocą którego, będziemy wysyłać maile.

Listing 1. MailerService do wysyłki maili

public interface MailerService {

	boolean sendPasswordReset(PasswordReset passwordReset);

	record LostPassword(String passwordResetToken, String expirationDate) implements MailTemplate.MailTemplateInstance {
	}
}

I wszystko byłoby fajnie, gdyby nie ten nieszczęsny MailTemplate.MailTemplateInstance. Biblioteka wymaga, żeby rekordy implementujące ten interfejs były publiczne, żeby biblioteka mogła się do nich dostać bez problemów. Jednocześnie takie upublicznienie powoduje, że możemy wysłać maila z dowolnego miejsca w kodzie, bo interfejs zawiera m.in. metody do obsługi wysyłki. Co można z tym zrobić?

Napisać dużo kodu

Usuwamy z definicji rekordu implementację interfejsu. Następnie w niepublicznej implementacji MailerService definiujemy statyczny, publiczny rekord, który już będzie implementować interfejs MailTemplate.MailTemplateInstance. Następnie za pomocą MapStructa lub z palca piszemy maper, który zmienia rekord z interfejsu na rekord z implementacji. Biblioteka jest zadowolona, mechanizm mailingu niewidoczny, a i liczba linii kodu się zgadza. Problem rozwiązany za pomocą systemu typów i ich przepakowywania.

Tylko, że w ten sposób powstaje nam ciężki do przetestowania kod, bo w testach musimy czasami tego maila wysłać z pominięciem serwisu i niekoniecznie z poziomu pakietu z mailingiem.

Napisać regułkę ArchUnit

To jest trochę bardziej skomplikowane, ale możemy pokusić się o napisanie generycznej reguły, która będzie brzmieć:

Sprawdź, czy dany rekord jest tworzony jedynie w klasach implementujących interfejs w którym zdefiniowano ten rekord lub w metodach oznaczonych jako @Test.

I tego już żaden system typów nie ogarnie. Dlaczego? Ponieważ nie istnieje język, którego system typów pozwoliłby na jednoczesne sprawdzenie:

• miejsca użycia typu – tylko w klasach implementujących dany interfejs
• kontekstu wywołania – lub metodach oznaczonych jako @Test

Dlaczego? Ponieważ systemy typów co do zasady są pomyślane tak, żeby sprawdzać poprawność danych i zgodność interfejsów (w szerszym znaczeniu – co możemy użyć). Nie są jednak przeznaczone do weryfikowania kontekstu wywołania. Do weryfikacji kontekstu wywołania służy analiza statyczna. Do analizy statycznej posłuży nam ArchUnit, w którym napiszemy taka oto regułkę:

Listing 2. Nasz weryfikator

import static com.tngtech.archunit.lang.SimpleConditionEvent.violated;

import com.tngtech.archunit.core.domain.JavaClass;
import com.tngtech.archunit.core.domain.JavaConstructorCall;
import com.tngtech.archunit.lang.ArchCondition;
import com.tngtech.archunit.lang.ConditionEvent;
import com.tngtech.archunit.lang.ConditionEvents;
import java.util.Arrays;
import java.util.List;
import org.junit.jupiter.api.Test;

class NoInnerRecordsAreUsedOutsideOfItsOwnerOrTest extends ArchCondition<JavaClass> {
	private static final String TEST_FULL_NAME = Test.class.getName();

	private final Class<?> owner;
	private final List<String> forbiddenNames;

	public NoInnerRecordsAreUsedOutsideOfItsOwnerOrTest(Class<?> owner) {
		super("Use %s defined records only in %s", owner.getSimpleName(), owner.getSimpleName());
		this.owner = owner;
		this.forbiddenNames = Arrays.stream(owner.getDeclaredClasses())
			.filter(c -> c.isRecord())
			.map(Class::getName)
			.toList();
		if (forbiddenNames.isEmpty()) {
			throw new IllegalArgumentException("Class " + owner.getName() + " has no inner classes");
		}
	}

	@Override
	public void check(JavaClass javaClass, ConditionEvents events) {
		javaClass.getConstructorCallsFromSelf()
			.stream()
			.filter(call -> isInNames(call) && isNotImplementOwner(javaClass) && isNotCallInTestMethod(call))
			.map(this::createViolationEvent)
			.forEach(events::add);
	}

	private ConditionEvent createViolationEvent(JavaConstructorCall call) {
		final String calledName = call.getOrigin().getOwner().getFullName();
		final String calledPlace = call.getOrigin().getFullName();
		return violated(call, "Invalid call of " + calledName + " in " + calledPlace);
	}

	private boolean isNotCallInTestMethod(JavaConstructorCall call) {
		return !call.getOrigin()
			.getAnnotations()
			.stream()
			.anyMatch(a -> a.getRawType().getName().equals(TEST_FULL_NAME));
	}

	private boolean isInNames(JavaConstructorCall call) {
		return forbiddenNames.contains(call.getTarget().getOwner().getName());
	}

	private boolean isNotImplementOwner(JavaClass javaClass) {
		return !javaClass.getAllRawInterfaces().stream()
			.anyMatch(i -> i.getName().equals(owner.getName()));
	}
}

Co tu się dzieje?

Po pierwsze w konstruktorze pobieramy listę rekordów zdefiniowanych w danej klasie. Jeżeli nie ma rekordów, to leci wyjątek. Następnie w metodzie check dzieje się „magia”. ArchUnit uruchamia tę metodę dla każdej klasy w naszym kontekście weryfikacji (o tym za chwilę) i pobiera z niej wszystkie wywołane w tej klasie konstruktory » javaClass.getConstructorCallsFromSelf(). Dla każdego wywołania konstruktora sprawdzamy, czy jest to wywołanie konstruktora naszego rekordu » isInNames i czy klasa wywołująca nie implementuje interfejsu » isNotImplementOwner i czy wywołanie nie nastąpiło w testach » isNotCallInTestMethod. Jeżeli wszystkie te założenia są prawdziwe, to tworzymy (map) i zgłaszamy (forEach->add) naruszenie.

Czym jest kontekst weryfikacji?

Jest to zbiór klas, które chcemy zweryfikować. W naszym przypadku chcemy zweryfikować wszystkie klasy z pakietu bazowego naszego projektu, więc możemy wywołać test w następujący sposób:

Listing 3. Wywołanie testu

class MailerServiceRecordsUsageArchTest implements ArchTestTrait {

	@Test
	void recordsInMailerServiceShouldBeCreatedOnlyInSpecificClasses() {
		classes()
			.should(innerRecordUsage(MailerService.class))
			.check(new ClassFileImporter()
					   .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)
					   .importPackages("pl.koziolekweb.."));
	}
}

Przy czym tutaj jest to trochę preoptymalizowany, ponieważ ArchUnit udostępnia filtr ImportOption.Predefined.DO_NOT_INCLUDE_TESTS, który na podstawie ścieżki do pliku odsiewa klasy testowe. Uwzględnia jednak jedynie domyślną strukturę mavena, gradle i IntelliJ, więc w przypadku gdy używamy inne IDE, lub zmieniliśmy konfigurację, to będzie problem.

Tak przygotowana regułę możemy spakować w paczkę i wystawić w firmowym repo.

Podsumowanie

ArchUnit, podobnie jak inne narzędzia do statycznej analizy kodu dopełnia system typów o weryfikację kontekstu wykonania. Pozwala to na ograniczenie ilości kodu, którego jedynym zadaniem mapowanie typów, by zaspokoić potrzeby związane z izolacją poszczególnych modułów. Niby niewiele, ale jednak bardzo dużo.

Czasami wstajesz rano, pijesz jedną kawę, drugą – i nic. Nadal zamuła i ogólnie niski poziom wszystkiego. Normalnie w takiej sytuacji należałoby walnąć energola, który pozbawiony jest dodatków uspokajających (kawa ma takowe) poczekać 10 minut i gotowe. Co prawda chęć do życia nadal niska, ale przynajmniej masz energię, by ją wyrazić.

Jednak istnieje alternatywą i jest nią lektura „Patopaństwa” Janka Śpiewaka. I podnosi ciśnienie lepiej niż kawa zalana redbullem i posłodzona amfą.

W tej książce wkurwia wszystko. Jednak po kolei.

O czym mówimy?

Mówimy o historii najnowszej naszej Najukochańszej Rzeczpospolitej i o patologiach jakie w pocie czoła wypracowaliśmy. A czego tu nie ma. Począwszy od naszej radosnej codzienności z wariatami za kierownicą i wkurwiajacymi szefami, poprzez trochę większe patologie w szkole, na uczelni, w urzędzie, czy u lekarza, a na grubych kończąc. Mamy zatem opowieść o tym, co na co dzień widzimy i o tym, z czym niektórzy z nas już się musieli zmierzyć (kredyty frankowe), albo zmierzyć będą się musieli (wychowanie dzieci), albo nie powinni się mierzyć (wypadki drogowe, uzależnienia). I każda opisana w książce historia powoduje wkurw, bo jednak widzisz, że to dzieje się dookoła ciebie.

Struktura

Na początek mamy małą dawkę historii. Źródła naszego państwa z gówna i patyków sięgają drugiej połowy lat 70-tych i rodzącego się wtedy ruchu robotniczo-inteligenckiego. Z niego wyrosły nasze współczesne elity, które w wyniku przemian ustrojowych zafundowały nam… no cóż… całkiem fajne miejsce do życia. Fajne – o ile miałeś trochę farta i prawidłowo wybrałeś rodziców, bo poza tym to już nie do końca.

Sam autor opisuje swoje korzenie w sposób, który dobrze obrazuje, z jakiego rodzaju elitami mamy do czynienia. Mam nieodparte wrażenie, że w którymś momencie życia dostał o po głowie i go trochę otrzeźwiło. Dzięki temu krytycznie podchodzi do otaczającej nas rzeczywistości, ale też bardzo odważnie opisuje „swoje” plemię.

Nie do końca rozumiem co kierowało nim, przy takiej, a nie innej organizacji treści, bo o ile pierwsze trzy-cztery rozdziały mają sens (elity, inteligencja, transformacja, polityka). Pokazują, jakie są historyczne i społeczne przyczyny obecnego stanu rzeczy, to późniejsze „bloki tematyczne” są trochę pomieszane. I choć czytając, miałem wrażenie, że każdy rozdział kończy się swoistym wprowadzeniem do kolejnego, to jednak coś mi tu zgrzyta. W niektórych miejscach brakuje też tego jednego sensownego przypisu. O ile źródeł autor podał dużo, to jednak czasami brakuje tego odnośnika, do wspominanych badań, książki, artykułu.

Ta książka wkurwia

I to nie tylko treścią, ale też formą. I teraz się będę czepiał. Wspomniana przed chwilą pewna losowość poruszanych spraw nie jest aż tak męcząca, jak samo przedstawienie treści.

Książka ma strukturę, którą można opisać w skrócie jako „zrzut z bloga”. Stosunkowo krótkie podrozdziały, czasami suche przedstawienie faktów. W dodatku im dalej, tym gorzej. W pewnym momencie czułem się, jakbym czytał blogaska, a nie książkę. Cóż… taka współczesna moda albo ja jestem przewrażliwiony po lekturze amerykańskich reportaży Czarnego i Herezji Horusa.

Z punktu widzenia e-czytelnika męczący jest też pomysł z zamieszczeniem korespondencji i komentarzy z sieci w postaci nieobrobionych screenshotów. Sam pomysł super, ale forma nie na moje zmęczone oczy. Parafrazując klasyka „większa czcionka!”, bo inaczej nie idzie tego czytać. No i już zupełnie technicznie – od tego książka „spuchła” do nieprzyzwoitej wielkości prawie 10MB.

Dla kogo?

Powiem tak. Przyjmowanie krytyki to sztuka. Współczesne czasy uczyniły z niej bardzo trudną sztukę, bo pierwsze co robimy, słysząc krytyczne uwagi pod naszym adresem, to „ustawienie” krytykującego na drabinie hierarchii społecznej (często w określonej w dodatkowym kontekście). Dlatego wiele osób, które „odniosły sukces” może czuć się źle, czytając tę książkę. Po prostu ciężko przeskoczyć z myśleniem w niektórych kwestiach.

Mnie osobiście wkurwia moja bezsilność. Możesz robić, starać się, albo rozumieć, że coś nie działa tak, jak powinno, a pomimo to nie mieć możliwości naprawienia.

Jednak jestem optymistą, może za mojego życia uda się naprawić większość z opisywanych patologii. W końcu patologię drogową zaczęliśmy ogarniać i mamy efekty. Może uda się i na innych polach…

Ostatnio skończyliśmy na tym, że majątkowe prawa autorskie to prawo do rozporządzania programem komputerowym na wszystkich polach eksploatacji oraz do wynagrodzenia za korzystanie z utworu. Aby taka umowa była ważna, musi mieć formę pisemną - i tą formą pisemną zajmiemy się dzisiaj.

Co to w ogóle znaczy, że umowa musi mieć formę pisemną?

Forma pisemna oznacza, że dokument musi mieć formę papierową i zostać podpisany odręcznie. Umowa może też zostać podpisana elektronicznie pod warunkiem, że będzie to kwalifikowany podpis elektroniczny (ten z certyfikatem).

Wysłanie skanu podpisanej umowy nie spełnia warunku formy pisemnej - skan oczywiście można wysłać, ale ponadto należy wysłać również papierową wersję dokumentu podpisanego odręcznie. Pamiętajcie przy tym o odpowiedniej ilości egzemplarzy (są wskazywane na końcu umowy), żebyście też mieli swoją umowę z podpisami wszystkich stron (a nie tylko ze swoim).

Wszelkie zmiany umowy (aneksy) również muszą mieć formę pisemną.

A jak nie ma formy pisemnej, to co?

Zgodnie z art. 53 ustawy o prawie autorskim i prawach pokrewnych umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej * *pod rygorem nieważności. Jeżeli nie dopilnujecie formy pisemnej, albo uznacie, że jej nie potrzebujecie, bo przecież ufacie drugiej stronie, to konsekwencje poczujecie, gdy dojdzie do jakiegoś sporu. Pamiętajcie, że **wszystkie umowy pisze się w czasie pokoju na wypadek wojny ;) Jeżeli będziecie chcieli zmienić jakieś warunki umowy (np. wynagrodzenie), a druga strona nie będzie chciała Wam pójść na rękę, to wtedy może posłużyć się argumentem, że umowa nie została zawarta w formie pisemnej, więc umowa jest nieważna (lub aneks jest nieważny, jeżeli to aneks nie został podpisany w prawidłowej formie).

Jakie są konsekwencje tego, że umowa jest nieważna?

Jeżeli jedna ze stron wykonała swoje obowiązki wynikające z umowy, to może żądać zwrotu swojego świadczenia. Na przykład: jeżeli kontrahent zapłacił Wam za przeniesienie na niego majątkowych praw autorskich do programu komputerowego, ale umowa okazała się nieważna, to może żądać zwrotu wynagrodzenia, które zapłacił z tego tytułu. Wy natomiast możecie w takiej sytuacji żądać zapłaty za bezumowne korzystanie programu komputerowego.

Jeżeli zachowaliście formę pisemną dla umowy, a dla aneksu nie - to nieważny jest tylko aneks. Jeżeli nie zachowaliście formy pisemnej dla umowy, a aneks zawarliście w formie pisemnej - to oba dokumenty są nieważne (nie może być ważnego aneksu do nieważnej umowy, bo jej po prostu nie ma).

r. pr. Joanna Kuczyńska

Po pierwsze mamy taką usługę jak Uprawnienia Kierowców, gdzie mając imię, nazwisko i numer blankietu PJ/pozwolenia na kierowanie tramwajem, możemy sprawdzić czy dokument jest ważny.

Po drugie problemem nie jest sama usługa (o tym za chwilę), co brak sensownego API do tej usługi. W dodatku korpy chcą mieć coś więcej, czytaj chcą, żeby państwo zrobiło (prawie)wszystko za nich i poniosło większość kosztów.

Po trzecie stan prawny jest „ciekawy”. W dodatku jego zmiana nie jest aż tak trywialna, jak wydaje się na pierwszy rzut oka. Dotykamy tutaj kilku aspektów m.in. relacji pomiędzy firmą kurierską, a kurierem, czyli sposobu zatrudniania kurierów, odpowiedzialności za poprawność i prawdziwość informacji, a to wszystko w kraju, w którym prezes UODO na bezczelnego łamie prawo (o tym też będzie).

Zacznijmy jednak od tego czego mniej więcej oczekują firmy.

„O takie API nic nie robiłem” – prezes na kurierce

Jak wspomniałem we wstępie w ramach mObywatela istnieje usługa pozwalająca na sprawdzenie statusu dokumentu – Prawa Jazdy lub Pozwolenia na Kierowanie Tramwajem. Podajemy dane, klikamy „Sprawdź uprawnienia” i dostajemy informację co i jak. Każda pani Kasia w dziale HR przy zatrudnianiu kierowcy może mając jego dane zweryfikować faktyczny stan uprawnień. To teoretycznie wystarczy. Problem pojawia się gdy tych kierowców mamy dziesiątki, setki czy tysiące. Ręczne wklepywanie danych będzie problemem. Zostawmy to jednak na chwilę i skupmy się na oczekiwaniach.

O oczekiwaniach mówił Brzoska, ale gdzieś po drodze wbił się jeszcze (były)minister Cieszyński ze swoim nie da się. Jest jednak jeszcze drugie dno tej całej sytuacji. Z różnych dyskusji na ten temat wnioskuję, że korposy, to by najchętniej chciały jakieś PUSH-API, które automatycznie będzie powiadamiało ichnie HR-owe końcówki, że dany delikwent utracił uprawnienia.

„Zmiana niemożliwa, bo…” – minister na mObywatelu

Może nie tyle niemożliwa, co wymagająca pewnej „inteligencji prawnej” ze strony ustawodawcy. A o to, jak powszechnie wiadomo, może być ciężko. Tu wchodzi cały na biało nasz chory system prawny, który powoduje, że kierowców zatrudnia się na JDG, często przez pośrednika. Tak działają kurierzy, taksówki, transport kołowy. NO dobra, ale w czym problem? Ano w tym, że „zatrudniając” kogoś na B2B tak naprawdę kupujesz usługę. Jako konsumenta usługi nie powinno cię interesować, jak to działa pod spodem. Na takiej samej zasadzie w spożywczaku nie pytasz każdej ekspedientki o książeczkę sanepidu, czy nauczyciela w szkole o przygotowanie do wykonywania zawodu. Oczywiście firmy mogą trochę więcej i zawierając umowę zazwyczaj proszą kontrahenta odpowiednie dokumenty potwierdzające umiejętności, uprawnienia, edukację.

W przypadku umów b2b, trzeba by na dłuższą metę ogarnąć nie tylko samo dostarczanie danych, ale też zgodność z przepisami o ochronie danych osobowych. I problem ten poruszyła, co prawda pośrednio, posłanka Anna Maria Żukowska tutaj. Niestety jest prawniczką, co oznacza, że potrafi identyfikować problemy, ale nie potrafi syntezować posiadanej wiedzy w celu wytworzenia odpowiedniego rozwiązania (nie polegającego na obejściu przepisów). Czysto teoretycznie wystarczy ukazać uzasadniony interes prawny, żeby móc swobodnie przetwarzać informacje o statusie PJ.

I tu na białym koniu wjeżdża płodo z uodo, czyli prezes nad UODO. Urzędnik ten przypomina mi dolnośląskiego konserwatora zabytków. Zrobi wszystko, żeby nie dopuścić do przebudowy i unowocześnienia ulicy/usługi w imię źle pojętego interesu. Pamiętajmy, że ten orzeł zakazał geoportalowi publikacji numerów ksiąg wieczystych (i przywalił 100 koła kary), co jest w jawnej sprzeczności z ustawą o księgach wieczystych. Oczywiście nie przeszkadzają mu firemki z Seszeli, które za te numery biorą hajs.

Podsumowując, zmiana prawa będzie cholernie ciężka. Szczególnie, że będą robić to prawnicy.

„Co się nie, da jak się da” – Ja

Bycie hakerem, to nie tylko uruchamianie pociągów, ale przede wszystkim nieustanna ciekawość. Chcesz wiedzieć jak coś działa czy jak rozwiązać dany problem. I coś mnie podkusiło, żeby zobaczyć jak działa ta usługa. Jakie komunikaty tam latają, co dzieje się, gdy naciskam przycisk.

W efekcie spłodziłem takie maleństwo. Bierzcie i forkujcie z tego wszyscy, albowiem na licencji MIT jest to wam dane.

Następnie napisałem tweeta z linkiem do „mięska” i mini-bluzgiem na lenistwo korporacji. Dyskusja jaka się wywiązała jest ciekawa i wyłania się z niej kilka aspektów.

Co na to UODO?

IMO, nic, bo usługa działa jest wystawiona publicznie. Mój skrypt pomija webową część i uderza bezpośrednio do serwisu. Dzięki temu można go nakarmić plikiem z danymi i pobrać odpowiedź.

Czy odpowiadam za błędy?

Nie. W dodatku ludzie nie mają pojęcia, że większość softu z jakiego korzystają ma w licencji wyłączenie odpowiedzialności.

Przecież można ręcznie…

To napisał prawnik… po czym poprawił i trochę racji ma, bo Kodeks Pracy dotyczy UoP, ale nie do końca, bo przepisy BHP dotyczą wszystkich niezależnie od formy zatrudnienia. Zatem wydanie pojazdu kierowcy bez uprawnień jest chyba lekko „nie teges”.

Ale było też kilka sensowniejszych głosów.

Pośrednicy i model zatrudnienia w PL

To jest trochę szerszy problem. Choć @IntelijG drąży w odpowiednim kierunku. Mając całe stadko pośredników trzeba zadbać o odpowiednie przekazywanie informacji. Co ciekawe, skoro od pewnego czasu kierowcy spoza UE muszą mieć polskie PJ, to odpada problem zagranicznych dokumentów.

Podsumowanko

Skrypt będzie rozwijany i mam nadzieję, że nie skończy się wojną na podobieństwo tej, którą prowadzi Informatyk Zakładowy z Min. Sprawiedliwości w sprawie losowarki sędziów. Chcę w ramach zabawy z Rustem dopisać kilka wersji „gotowców” w różnych językach. Takie Hello World, ale nic na siłę. I to chyba tyle :)

Dwa rodzaje bezpieczeństwa

W języku polskim ciężko wyrazić jednym słowem różnicę pomiędzy angielskim safe a secure. Oba te słowa tłumaczy się jako „bezpieczny”, co powoduje pewne zamieszanie. Spróbuję je trochę wyprostować.

safe, czyli bezpieczeństwo i higiena pracy

Słówko safe można rozumieć jako bezpieczne zachowania. Postępowanie w sposób bezpieczny, nie narażając siebie i innych. W przypadku wytwarzania oprogramowania będzie to odpowiedni dobór narzędzi i praktyk. Wśród nich znajdą się takie, jak testy, czy code review. Jeżeli mamy testy, to możemy powiedzieć, że sprawdzamy nasz kod pod względem działania. Raczej nie powinniśmy zostać zaskoczeni przez oczywiste błędy. Podobnie CR pozwala na wyłapanie różnych baboli. Jednak to nie tylko te dwa zachowania. Na tego rodzaju bezpieczeństwo aplikacji wpływają różne czynniki. Jeżeli mamy dokumentację dla użytkownika końcowego, to duża szansa, że nie zepsuje nam aplikacji. Wykorzystanie CI/CD pozwala na dbanie o kod. Tak samo jak wzorce projektowe, które ułatwiają zrozumienie aplikacji.

Czasami są to duże rzeczy jak na przykład odpowiedni projekt architektury. Czasami są to małe rzeczy, jak użycie odpowiedniego typu danych. Wszystko to na co mamy wpływ tworząc i zarządzając aplikacją można wpisać w ten kontekst.

W tym kontekście działa policja. Chroni obywateli wewnątrz kraju.

secure, czyli bronić i chronić

Inny aspekt bezpieczeństwa reprezentuje słówko secure. Oznacza ono bezpieczeństwo wobec czynników zewnętrznych. Ataki hakerskie, ale też niestabilność zasilania w serwerowni, bo bezpieczeństwo, to nie tylko software. W świecie chmur trochę na dalszy plan zeszły różne problemy związane z zabezpieczeniem przed czynnikami zewnętrznymi. Cloudflare chroni nas przed DDoSami, aplikacje umieszczamy na serwerach wirtualnych, które zarządzane są przez odpowiednie oprogramowanie. W dodatku komunikujemy się z API, a nie z fizyczną maszyną. I to wszystko jest obłożone backupami, które robi dostawca rozwiązania. W teorii wystarczy zatem odpowiednio przechowywać hasła, łączyć się po HTTPS i wykonywać regularnie kopie bezpieczeństwa.

A przecież czynniki zewnętrzne bywają różne. Przeniesienie się OVH do chmury w 2021, czy przypadkowe skasowanie gitlaba przez gitlaba w 2017, to tylko dwa przykłady gdy coś idzie nie tak. I na takie przypadki też musimy być gotowi. Tylko problem polega na tym, że nie przygotujemy się na wszystko. Po prostu jest to niemożliwe.

W tym kontekście działa wojsko. Chroni obywateli przed zagrożeniem z zewnątrz.

A jak zaatakują zombie?

Atak zombie, czyli jeden z najbardziej przeruchany przez kino, gry i literaturę motywów niespodziewanego, niebezpiecznego i nieprzewidywalnego zdarzenia… i jednocześnie podstawowe pytanie, gdy tworzysz modele bezpieczeństwa. Zarówno w kontekście safe jak i secure. Nie przewidzisz wszystkiego. Nie jesteś w stanie zabezpieczyć się na każdą ewentualność. Jednak warto na bieżąco dbać o oba rodzaje bezpieczeństwa, żeby potencjalny problem nie wyrządził nam aż takiej krzywdy.

Co to znaczy, że program komputerowy jest chroniony prawem?

Wierzcie lub nie, ale programy komputerowe są szczególnie chronione prawem autorskim i to już od 30 lat! A w prawie Unii Europejskiej jeszcze dłużej, bo nasza polska ustawa o prawie autorskim i prawach pokrewnych z 1994 r. dokonuje wdrożenia dyrektywy 91/250/WE z 1991 r. w sprawie ochrony prawnej programów komputerowych. W dodatku programy komputerowe zostały wymienione w ustawie już na samym początku i otwierają katalog utworów będących przedmiotem prawa autorskiego.

Ale co to w ogóle znaczy, że program komputerowy jest chroniony prawem?

Ochrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia (kod źródłowy i wynikowy, a inne elementy tylko wtedy, gdy na ich podstawie jest możliwe napisanie programu). Natomiast idee i zasady będące podstawą jakiegokolwiek elementu programu komputerowego nie podlegają ochronie.

Prawo chroni prawa twórcy (osoby, która napisała oprogramowanie) oraz osób, którym twórca sprzedał prawa do programu lub udzielił im licencji. W przypadku licencji prawa autorskie nadal należą do twórcy, który zgadza się, żeby ktoś inny odpłatnie lub nieodpłatnie korzystał z jego programu komputerowego. Jakie są prawa do programu komputerowego?

Twórcy przysługują dwa rodzaje praw: osobiste i majątkowe.

Osobiste prawa autorskie są niezbywalne i na stałe łączą twórcę z jego programem. Są to: prawo do autorstwa utworu oraz do oznaczenia utworu swoim nazwiskiem lub pseudonimem albo do udostępniania go anonimowo. Możecie spotkać takie zapisy w umowie, gdzie jako twórca zezwalacie na udostępnienie programu bez podania swojego nazwiska. Dopóki twórca nie ujawnił swojego autorstwa, w wykonywaniu prawa autorskiego zastępuje go producent.

Z kolei majątkowe prawa autorskie to prawo do rozporządzania programem na wszystkich polach eksploatacji oraz do wynagrodzenia za korzystanie z utworu. Pamiętajcie, że aby umowa była ważna, musi mieć formę pisemną - ale to już dłuższa sprawa, więc opowiem Wam o tym innym razem.

r. pr. Joanna Kuczyńska