Blog Wilda Software https://wildasoftware.pl Blog prowadzony przez Wilda Software o tworzeniu oprogramowania i przybliżający branżę IT spoza niej. Sat, 23 May 2026 06:00:02 +0000 pl-PL Inwestowanie i oszczędzanie dla (naprawdę) początkujących https://wildasoftware.pl/post/inwestowanie-oszczedzanie-naprawde-poczatkujacych?ref=rss https://wildasoftware.pl/post/inwestowanie-oszczedzanie-naprawde-poczatkujacych?ref=rss Thu, 17 Jul 2025 17:30:00 +0000 ("uROJenia" to cykl tekstów (często o charakterze publicystycznym), które są zwykle zamieszczane poza obowiązującym harmonogramem artykułów i dotyczą spraw ważnych dla jego autora, a więc Jakuba Rojka. Czasem ich związek z tematyką IT jest bardzo swobodny, podobnie zresztą jak styl.)

(Dla tych, co już widzę mały pasek przewijania - spokojnie, niżej jest spis treści, a jeśli wolicie poczytać sobie ten artykuł na czytniku, to na dole w załącznikach znajdziecie wersje w postaci plików PDF i EPUB. I tak, pamiętam, że to blog o IT - spokojnie, to się nie zmienia, to prawdopodobnie jednorazowy wyskok, chyba że będzie zapotrzebowanie.)

Edukacja finansowa w Polsce leży i kwiczy. To dość dobitne zdanie opisuje przynajmniej moje doświadczenia sprzed kilku lub kilkunastu lat, kiedy człowiek chciał sobie dorobić, ale nikt wokół nie umiał jasno wyjaśnić pewnych kwestii na tyle, aby taki panikarz jak ja mógł się odważyć. Owszem, w szkołach są przedmioty związane z podstawami przedsiębiorczości (i bardzo dobrze, że są), ale nie kojarzę, aby uczono mnie tam podatków, wypełniania PITa, obligacji, podstaw giełdy (choćby po to, aby ostrzegać przed ewentualnymi naciągaczami). Wiadomo, że wynika to z przeładowania materiału, ale też zapewne tego, że kiedyś nie było tylu "cudownych" sposobów na wzbogacenie się, a ponadto nauczyciele też musieliby być edukowani w tym względzie. Te segment edukacji przenoszony jest więc do domu, gdzie już wszystko zależy od opiekunów - większość z nas nie miała tego szczęścia i rodzice nie byli w stanie za dużo powiedzieć o tym, jak np. kupić obligacje. Ja nawet dostawałem przestrogi, aby unikać inwestowania i lepiej oszczędzać, trzymając pieniądze spokojnie na koncie. I o ile to lepsza rada niż "zezwolenie" na trwonienie pieniędzy, to bynajmniej dobrą wskazówką nie jest.

Z drugiej strony, jeszcze jakiś czas temu nie było tyle wiedzy pisanej i do obejrzenia dostępnej na wyciągnięcie ręki - giełda kojarzyła się z czymś odległym, do której zrozumienia trzeba było mieć odpowiednie wykształcenie i brawurę, na produkty inwestycyjnie patrzyło się nieufnie, a dom maklerski to przecież pewnie jakaś firma poza Polską, więc trudno będzie skorzystać z jej usług. Teraz sytuacja zmieniła się diametralnie - materiałów edukacyjnych jest mnóstwo, banki pozwalają kupować obligacje na kliknięcie, większość rzeczy możemy zrobić bez Internet, nie wychodząc z domu, a do tego pojawiły się sposoby na to, aby nie tylko nie stracić na giełdzie, ale w miarę spokojnie zyskać, nawet bez głębokiej wiedzy o rynku. Nie zmieniło się tylko jedno - sporo osób nadal tego wszystkiego się obawia i nie tylko nie inwestuje, ale nawet nie oszczędza w “poprawny" sposób. I przyznaję, że sam do niedawna taki byłem i w końcu w wieku 35 lat (późno), obserwując sporo młodszych kolegów, którzy wcale nie mają certyfikatów maklerskich, a mimo to spokojnie sobie zarabiają, stwierdziłem, że coś z tym trzeba zrobić.

To nie będzie artykuł o tym, jak osiągać sukcesy w inwestowaniu. To nie jest też tekst dla kogoś, dla kogo pieniądze już pracują, bo większość wiedzy, jaką będę starał się przekazać, już mają opanowaną. To nie jest też opowiastka dla osób, które w dużej mierze opierają się (choć nie tylko) na analizie technicznej i generalnie bardzo szczegółowym przyglądaniu się spółkom. Choć takie osoby zachęcam do kontaktu z nami, gdyż jest duża szansa, że potrzebują odpowiednich narzędzi wspomagających analizy, a my możemy je przekształcić w aplikację.

To materiał o następujących rzeczach:

  • dlaczego trzymanie pieniędzy na koncie to nie oszczędzanie,
  • jakie mamy formy inwestowania/oszczędzania i dla kogo one są,
  • czy można "bezpiecznie" inwestować, tzn. bez większego ryzyka,
  • gdzie można wykonać "techniczne" kroki, aby w coś zainwestować,
  • czego lepiej unikać jako początkujący.

Krótko mówiąc, jest to artykuł dla zielonych w temacie, którzy np. od lat mają odłożone środki i nic z nimi nie robią. Albo nawet chcieliby, aby te pieniądze pracowały, ale nie wiedzą, jak do tego podejść i boją się np. formalności podatkowych. Albo nie do końca wiedzą, co to są te całe akcje lub obligacje ("a dziadek kiedyś kupił, trzymał i w końcu one straciły wartość!"). Podobnie jak wiele innych osób, znacznie bardziej rozumiejących temat ode mnie, chciałbym dołożyć swoją cegiełkę do zainteresowania Polaków robieniem "czegoś" z pieniędzmi (nawet niedużymi), zwłaszcza, że zainteresowanie jest (co widzę po znajomych, dopytujących o to, jak w ogóle zacząć i gdzie się zarejestrować). Mówiąc bardziej wprost - chciałbym napisać artykuł, który sam chciałbym przeczytać te np. 10 lat temu, z którego dowiedziałbym się, czy moje obawy są słuszne, czy nie. To nie jest jednak tekst dla osób, które z inwestowania chcą zrobić swój etat.

Zanim zaczniemy, chciałbym nadmienić jeszcze o ważnej rzeczy:

Informacje, które są przedstawione w tym artykule, nie są rekomendacjami inwestycyjnymi w rozumieniu Rozporządzenia Ministra Finansów z dnia 19 października 2005 roku w sprawie informacji stanowiących rekomendacje dotyczące instrumentów finansowych, ich emitentów lub wystawców (Dz. U. z 2005 roku, Nr 206, poz. 1715). Ten tekst stanowi zbiór przemyśleń autora na temat inwestowania i oszczędzania, natomiast decyzje czytelnika są podejmowane na jego/jej własną odpowiedzialność.

Niby to tylko formalność, ale faktycznie nie jestem tutaj po to, aby Wam doradzać w wyborze. Jestem tutaj po to, abyście zobaczyli różne możliwości i mieli więcej informacji, aby podjąć decyzję, czy chcecie z tym coś dalej robić.

A ponieważ tekst jest bardzo długi, to wyjątkowo zamieszczę tutaj spis treści, abyście mogli ominąć oczywiste dla siebie sekcje i przejść do tych, które nurtują Was najbardziej:

  1. Czy będę miał(a) miliony po tym, gdy zacznę inwestować?
  2. Inwestowanie, oszczędzanie oraz inflacja
  3. Co muszę mieć, aby zacząć inwestować lub oszczędzać?
  4. W co można inwestować?
  5. Od czego zacząć i czy opłaca się startować od 100 zł?
  6. A co z podatkami?
  7. Na co uważać i jakie są mity?
  8. Aplikacje pomagające w oszczędzaniu
  9. Kogo śledzić w poszukiwaniu materiałów edukacyjnych?
  10. Słowniczek pojęć
  11. Podsumowanie

Czy będę miał(a) miliony po tym, gdy zacznę inwestować?

Miejmy to za sobą - najprawdopodobniej nie. Gdy pojawia się hasło "giełda" oraz "inwestycje", zaraz przed oczami mamy osoby pokroju Warrena Buffeta, którzy śpią na pieniądzach i w ich wykonaniu wszystko wydaje się tak proste. Zaraz jednak zestawiamy to z opowieściami znajomych o tym, jak ktoś zbankrutował po nieudanych transakcjach. Prawda, jak zwykle, leży gdzieś pośrodku, a w tym wszystkim zapominamy o tym, że obok “inwestowania" jest jeszcze już wspomniane "oszczędzanie".

Większość obszarów, w których można inwestować, może nam pomóc walczyć z inflacją i trochę zarobić, np. kilka procent rocznie, po prostu utrzymując nasz majątek. Ale zapomnijmy o tym, że wkładając 1000 zł już za miesiąc będziemy widzieli na koncie kilka zer więcej - gdyby tak to działało, to nikt by niczego innego nie robił, tylko dokładał pieniądze do kont maklerskich. Słowem - nadal będziesz musiał(a) pracować, a odkładanie pieniędzy metodami, które dzisiaj sobie omówimy, traktować jako dodatek. A trzeba jeszcze pamiętać o jednej rzeczy - działania inwestycyjne to nie sprint, tylko maraton. Jakiegokolwiek doradcy nie zapytacie, nikt Wam nie powie, że wystarczy włożyć pieniądze na tydzień na jakąś spółkę i potem opływać w luksusach. Nie bez powodu np. przy funduszach inwestycyjnych pojawia się sugerowany horyzont inwestowania, który nierzadko jest określany w latach. Tak to działa - pieniądze muszą mieć czas, aby wypracować odsetki i o ile po nawet kilku dniach może będziemy widzieli zyski, to będą na tyle śmieszne, że nikt nie wypłaci pieniędzy po takim czasie. Po roku też nie.

Czy zatem opowieści o szybkim dorobieniu się i milionerach po wejściu na giełdę są fikcją? Nie do końca, ale trzeba pamiętać o dwóch ważnych czynnikach:

  • a) im więcej pieniędzy włożysz, tym obfitszy zysk da Twoja inwestycja. Osoby, które mają teraz miliardy, wiele lat temu nie inwestowały tysięcy, tylko miliony.
  • b) istnieją ryzykowne instrumenty lub niecodzienne sytuacje, które pozwolą nagle wywindować zysk, ale to już albo wiąże się wręcz z zakładami, szczęściem (znacznie przewyższającym umiejętności analityczne) czy dojściem do wewnętrznych informacji.

Szczególnie na pierwszy punkt warto zwrócić uwagę - wiadomo, że im więcej zainwestujemy, tym (potencjalnie) więcej można zyskać. Z tego powodu dla znakomitej większości z nas (w tym dla mnie) pomnażanie majątku w ten sposób nie stanie się sposobem na życie i nadal będziemy musieli pracować w "normalnej" pracy. Choćby po to, aby mieć co dokładać do giełdy lub obligacji i sukcesywnie budować nasz tzw. potencjał inwestycyjny.

Oczywiście, są osoby, które rok po roku notują zyski rzędu 20% lub nawet więcej. Ale pamiętajmy, że mówimy tutaj o osobach, które przez cały czas zajmują się rynkami finansowymi (nierzadko mając wykształcenie w tym kierunku) i inwestują aktywnie, tj. rzeczywiście analizując dziesiątki spółek, śledząc informacje i traktując to po prostu jako pracę połączoną z hobby. Większość z nas nie może sobie na to pozwolić i... bardzo dobrze, bo trzeba też robić inne rzeczy, zwykle znacznie mniej stresujące. Jeśli wszyscy zajmowaliby się inwestowaniem na pełen etat, to nie miałby kto pracować, aby wypracowywać zysków dla tych inwestorów.

Inwestowanie, oszczędzanie oraz inflacja

W tym tekście już kilka razy użyłem dwóch pierwszych terminów. Oba są związane z poprawą swojej sytuacji finansowej, jednak w różny sposób. Warto przy tym wyjaśnić sobie ich znaczenie gdyż mimo, że wydaje się oczywiste, to warto sobie z tego zdać sprawę.

Inwestowanie to umieszczanie pieniędzy w instrumentach finansowych lub spółce (jeśli po prostu wchodzicie do jakiejś firmy) z nadzieją, że po pewnym czasie przyniesie ona zysk, czyli mówiąc wprost - wyjmiemy więcej niż włożyliśmy. Jest to ta bardziej "ekscytująca" czynność, która skupia się na pomnażaniu kapitału i maksymalizacji jego wyniku. Nie oznacza to jednak, że jesteśmy zmuszeni inwestować aktywnie, czyli śledzić poczynania spółek, analizować je i na bieżąco śledzić kurs akcji. Istnieje też tzw. inwestowanie pasywne, czyli celowanie bardziej w całe obszary rynku niż poszczególne spółki oraz zdanie się na specjalistów w kwestii szczegółów. Do tego jeszcze dojdziemy w tym tekście, kiedy będziemy mówić o tzw. ETF-ach.

Z kolei oszczędzanie kojarzy się z czymś odmiennym - zredukowaniem wydawanych środków, odkładaniem ich na przyszłość, a w skrajnym przypadku nawet ze skąpstwem. Formalnie faktycznie na tym może polegać oszczędzanie, gdyż minimalizacja wydatków na pewno jest w cenie (choć nie musi być drastyczna), ale warto przyswoić sobie jeszcze jeden aspekt - ta czynność powinna pomóc nam utrzymać wartość posiadanych pieniędzy, a więc ochronić przed zwiększającymi się cenami. To właśnie powód, dla których trzymanie środków w skarpecie czy na nieoprocentowanym koncie nie jest wcale "wystarczającym" oszczędzaniem - zapominamy o inflacji.

Jak pewnie wiecie, ten termin oznacza spadek wartości pieniądza. Czyli jeśli za posiadane dzisiaj 100 zł możemy kupić 16 bochenków chleba, to za rok to samo 100 zł pozwoli nam na zakup np. tylko 12 bochenków. Gdy rośnie inflacja, to rosną ceny w sklepach (czasem niewspółmiernie i nie tylko z tego powodu). A gdy inflacja spada, to... ceny nadal rosną, ale wolniej. To zależność, o której czasem zapominamy - dodatnia inflacja zawsze sprawia, że wydatki stopniowo rosną, natomiast wysokość tego procentu mówi na tym o tym, jak szybko to następuje. Z tego powodu musimy pamiętać, że 1000 zł przechowywane na zwykłym koncie bankowym przy rocznej inflacji 5% po roku będzie warte ok. 950 zł. Oczywiście, nie spadnie nam liczba na koncie, ale zmniejszy się wartość towarów, które kupimy za ten tysiąc.

Co ciekawe, odpowiednio niska inflacja może być zjawiskiem... pozytywnym. Gdy pieniądz traci na wartości (ale nie za szybko), to nie zależy nam specjalnie na tym, aby go trzymać w portfelu - lepiej kupić coś za niego, czyli utrzymać wartość w innej rzeczy. W tym przypadku ludzie są skłonni wydawać pieniądze, która poprzez przedsiębiorstwa trafia do gospodarki, rozwijając ją. Niektórzy z kolei wydają pieniądze na inwestycje, co również pozwala rosnąć społeczeństwu i rozwijać wszystko dookoła nas (oczywiście, trochę idealizując). To też oznacza, że odwrotne zjawisko, a więc deflacja (ujemna inflacja), które rzeczywiście wzmacnia wartość pieniądza, może wręcz skłaniać ludzi do ograniczenia wydatków z myślą, że z czasem te monety i banknoty w portfelu będą cenniejsze. To dobrze dla obywateli, ale gorzej dla gospodarki.

Natomiast tego typu rozważania zostawmy dla ekonomistów. Dla nas istotne jest to, aby chronić swoje pieniądze przed inflacją i można to robić także poprzez oszczędzanie. Ale w odpowiedni sposób.

Co muszę mieć, aby zacząć inwestować lub oszczędzać?

W ostatnich latach znacznie obniżyła się bariera wejścia w świat inwestowania - informacja o tym, jak to zrobić, jest zdecydowanie łatwiej dostępna, w sieci można znaleźć tutoriale, a materiałów edukacyjnych też jest bardzo dużo (do czego wrócimy pod koniec tekstu). Jednak w tym akapicie powiemy też sobie o nastawieniu, jakie trzeba mieć.

Z kwestii technicznych, to - w zależności od tego, w co będziemy chcieli inwestować - może wystarczyć konto w banku (szczególnie PKO BP lub Pekao S.A.). Jeśli chcemy wejść trochę głębiej, nie obejdzie się bez konta w domu maklerskim, które również może istnieć przy banku lub jako osobna firma. Jeśli jesteśmy obywatelami Polski i tutaj płacimy podatki, to warto, przynajmniej na początek, zdecydować się na podmiot zarejestrowany w naszym kraju i podlegający naszym regulacjom - pełną listę znajdziecie na stronie KNF i z pewnością znajdziecie tam nazwy, które kojarzycie z reklam w Internecie lub telewizji. Pamiętajcie, że nie jesteście ograniczeni do jednego banku lub domu maklerskiego - warto co jakiś czas zerkać na warunki w każdej firmie i w razie czego dzielić swoje środki, gdyż już nabierzecie wprawy.

Należy też mieć świadomość, że zyski z inwestowania podlegają opodatkowaniu. Jest to m.in. słynny podatek Belki, o którym pewnie się nasłuchaliście, ale który jest jednym z dwóch możliwych “kosztów" osiągania zysków. Wiele osób jednak zapomina o tym, że są dwa zobowiązania, gdyż obecnie (stan na 13.07.2025 r.) oba wynoszą 19%. To oznacza, że po sprzedaniu czegoś z zyskiem, w następnym roku będziemy musieli złożyć PIT-38, przy okazji którego zapłacimy 19% od samego zysku. Nie jest to takie trudne, jak się wydaje - poradników w sieci jest coraz więcej, a wszystko można zrobić w znanym od wielu lat portalu podatki.gov.pl. Jeśli w dodatku wybraliśmy polski dom maklerski, to ułatwi nam on zadanie, przesyłając druki PIT-8C (analogicznie, jak zakłady pracy przesyłające PIT-11 do standardowego PIT-37). Oczywiście, nadal istnieją pewne wyjątki i kwestie wymagające nieco większych obliczeń, ale zostawmy to, gdyż podejrzewam, że większość z Was nie będzie chciała utrudniać sobie życia. Zresztą, do podatków jeszcze wrócimy w tym tekście.

Jednak jeszcze ważniejsze jest są pewne cechy człowieka, które pozwolą mu właściwie podejść do omawianego tematu. O ile to bowiem zajęcie dla każdego, to nie wszystkie formy inwestowania będą odpowiednie dla wszystkich. Niezależnie od typu papierów wartościowych, które zakupimy, w cenie są przede wszystkim:

  • cierpliwość - efektów nie ujrzymy od razu, a często po wielu, wielu latach,
  • ciekawość dotycząca tego, co właściwie kupujemy - niby oczywiste, bo trzeba wiedzieć, co się nabywa, a jednak bywa różnie,
  • świadomość, że nie zawsze będziemy widzieć zielone zyski i przyjdzie nam też zmierzyć się z czerwonymi stratami,
  • uporządkowanie własnych finansów osobistych - co z tego, że będziemy zyskiwać, skoro jesteśmy obciążeni masą kredytów i niepotrzebnych subskrypcji.

I tutaj dobra informacja - jeśli naprawdę boimy się ryzyka, nadal istnieją aktywa, które można kupić relatywnie "w ciemno". Oczywiście, nie są to rzeczy, które dadzą nam te upragnione miliony, ale pozwolą nam utrzymać się powyżej inflacji. Nie jest też prawdą, że trzeba mieć tysiące na start - owszem, im większy kapitał włożymy w dane papiery wartościowe, tym więcej możemy zyskać, ale prawdę mówiąc, zacząć można już nawet od 100 zł, a nawet mniejszej kwoty. Dobrze byłoby uczynić z tego swój nawyk i co miesiąc lub kwartał odkładać pewną pulę pieniędzy, którą będziemy inwestować. Stąd jak najbardziej możliwe jest dojście do czegoś, odkładając na cele oszczędnościowe np. 500 zł miesięcznie - co prawda, w sieci znajdziecie clickbaitowe poradniki, że to nie ma sensu, ale prawda jest taka, że lepsze to niż nic i po prostu na efekty przyjdzie nieco dłużej poczekać.

Warto podzielić swój majątek na kilka sekcji:

  • bieżące pieniądze - tyle, ile potrzebujemy na codzienne i comiesięczne wydatki + pewna rezerwa na większe wydatki raz na jakiś czas. Naprawdę nie ma sensu trzymać na koncie setek tysięcy złotych, chyba że faktycznie tyle wydajemy co miesiąc.
  • poduszka finansowa - pewna pula pozwalająca nam czuć się bezpiecznie w sytuacji bardzo dużych, niespodziewanych wydatków, długotrwałego bezrobocia itd. Tę część już warto bezpieczne inwestować.
  • reszta - to, co zostanie, warto przeznaczyć właśnie na spokojne inwestowanie.

To nie jest tak, że inwestowanie to wyczyszczenie się do zera tylko po to, aby mieć szansę na parę procent zysku na giełdzie. To zamiana na papiery wartościowe tych pieniędzy, których z dużym prawdopodobieństwem i tak byśmy nie wykorzystali w długim czasie. Jednocześnie, nie wolno zapominać o “defensywie" i zabezpieczeniu się na wszelki wypadek. Papiery wartościowe nazywają się właśnie tak dlatego, że potrafią nam utrzymać wartość, więc de facto pieniądze nadal z nami zostają, tylko w innej formie, którą możemy z powrotem zamienić w dogodnym momencie. To też nie oznacza, że powinniśmy na rynku inwestować pieniądze, które posłużyłyby nam np. do rozwoju osobistego - wiem, że to utarte stwierdzenie, ale warto przeznaczać środki na swój rozwój.

Natomiast przestrzegam przed traktowaniem giełdy jako źródła "emocji" - to zdecydowanie nie jest dobre miejsce dla hazardzistów. Inwestowanie lub oszczędzanie powinno być wręcz nudne. Z jednej strony dlatego, aby nie kusiło nas ciągłe zaglądanie i przejmowanie się chwilowymi spadkami, a z drugiej po to, aby zredukować nasz czas, który możemy poświęcić na przyjemniejsze kwestie. Najważniejsze to ustalić strategię na początku i się jej trzymać - im bardziej będziemy traktować giełdę jako widowisko, tym częściej będziemy naruszać nasze własne ustalenia ze szkodą dla swojego majątku. I to jeszcze zwykle na gorąco, kiedy emocje są złym doradcą.

W co można inwestować?

To będzie najdłuższy rozdział w tym tekście, prawdopodobnie windujący ten artykuł w gronie najobszerniejszych materiałów na tym blogu. Ale właśnie to są te informacje, o które pyta wiele osób dopiero chcących zaoszczędzić lub zyskać trochę pieniędzy. Szczególnie dotyczy to obligacji i mówiąc szczerze - rozumiem ich, gdyż sam, karmiony opowieściami o tym, jak to "dawno temu Dziadek kupił obligacje, a potem nic za nie nie dostał" wcześniej podchodziłem do tego wszystkiego jak pies do jeża. A prawda jest taka, że wystarczy trochę doczytać, tylko właśnie - wiele osób skupia się na tym, jakie są np. rodzaje obligacji, a nie mówi o tym, czym one właściwie są i na ile są bezpieczne.

Poniżej przyjrzymy się formom inwestowania oraz oszczędzania, z którymi najczęściej mieć do czynienia i każdą opiszemy z kilku perspektyw:

  • czym właściwie są (aby rozumieć, w co się inwestuje i na jakich zasadach),
  • co jest potrzebne do nabycia danego aktywa (czasem służą do tego inne, mniej bezpośrednie środki),
  • czy jest to bardzo ryzykowne,
  • jakie są zalety (niekoniecznie dotyczące zysku).

Nie będziemy oceniać "skuteczności" danych rodzajów aktywów, gdyż zazwyczaj widniałoby przy tym "to zależy". Poza tym, przypominam, że nie chcemy tutaj doradzać - chcemy jedynie pokazać możliwości i choć w niektórych przypadkach powiemy sobie, że coś jest bez sensu w danym przypadku, to każda forma ma pewne zalety, które mogą być decydujące akurat w Twoim przypadku. Natomiast później wspomnimy o tych typach, które są już albo wybitnie ryzykowne, albo zwyczajnie za trudne dla kogoś, kto dopiero zaczyna przygodę z oszczędzaniem i być może nie chce w ten temat wnikać tak głęboko. Zaczynamy i pamiętajmy, że to tekst dla początkujących. Ważne, abyście czuli się dobrze i pewnie ze swoimi wyborami, aby odszedł Wam stres wynikający z niepewności.

Konta oszczędnościowe

Co to jest: Jest to nic innego, jak konto bankowe, które jednak różni się od zwykłego ROR (Rachunek Oszczędnościowo-Rozliczeniowy) tym, że jest oprocentowany oraz są z nim związane pewne dodatkowe regulacje, np. wyższe opłaty za przelew. Raczej nie jest to konto do codziennego uiszczania płatności - to po prostu miejsce, w którym możemy trzymać nasze środki, których aktualnie nie potrzebujemy, ale z drugiej strony nie chcemy ich "zamrażać". Z konta oszczędnościowego bowiem możemy wypłacać pieniądze w każdej w chwili w razie potrzeby. Obok często mamy zwykłe konto ROR.

Niestety, jak się pewnie domyślacie, jeśli coś jest łatwe i przyjemne, to pewnie nie jest zbyt zyskowne - oprocentowanie kont oszczędnościowych jest bardzo niskie, nawet rzędu 1-1,5% w skali roku (ogólnie: gdy będziemy mówili o oprocentowaniu, to zawsze w skali 12 miesięcy). Krótko mówiąc - nie przekroczymy inflacji, choć z drugiej strony zawsze jest to wartość większa niż 0. Owszem, różne banki mają promocje i w chwili, gdy to piszę, dostępne są oferty z nawet 8% zyskiem (w skali rocznej), jednak to czasowe propozycje i to po spełnieniu określonych warunków (zwykle wymagających nowego konta i/lub środków), które nierzadko są po prostu niewygodne. Obecne okazje możecie zobaczyć np. w tym rankingu. Niektórzy wręcz skaczą ze swoimi pieniędzmi po tych promocjach, aby mieć prawie cały czas solidne zyski, a potem kończą z kontami w kilkunastu bankach.

Co jest potrzebne: Wypełnienie formularza na stronie banku lub udanie się do oddziału. Zakładanie konta przebiega podobnie do otwarcia zwykłego rachunku. Procedura jest prostsza, gdy już mamy jakąś usługę w danym banku.

Ryzyko: Żadne. Wiadomo, bank może upaść, ale po pierwsze mówimy już o katastroficznym scenariuszu, a po drugie - istnieje coś takiego, jak Bankowy Fundusz Gwarancyjny (BFG), który w przypadku problemów finansowych instytucji gwarantuje każdemu klientowi do 100 tys. euro zwrotu (w zależności od ilości posiadanych środków). Przed założeniem konta warto zerknąć, czy wybrany przez nas bank podlega tym regulacjom, bo nie wszystkich polskich instytucji to dotyczy.

Zalety: Mimo bardzo kiepskiego oprocentowania, jest to coś, co warto mieć, jeśli lubimy trzymać gotówkę na koncie i potrzebujemy jej trochę więcej, aby czuć się bezpiecznie. Wówczas na nieoprocentowanym koncie ROR można mieć tyle, aby "wystarczyło na życie", a na oprocentowanym oszczędnościowym przechowywać resztę. Zawsze to jakiś comiesięczny zysk, nawet jeśli kilkunasto- lub kilkudziesięciozłotowy. Dodatkową zaletą, nie taką oczywistą w innych formach jest fakt, że praktycznie cały czas mamy dostęp do pieniędzy, gdyby coś się działo. Można też ciągle dokładać środki, co jest różnicą choćby w stosunku do lokat, o których za chwilę.

Lokaty bankowe

Co to jest: To również bardzo bezpieczna forma, jednak tym razem zamrażająca nasze środki. Wygląda to tak, że otwierając lokatę, ustalamy pewną pulę pieniędzy, które przelewamy na z góry określony czas (np. 3 miesiące). W tym momencie tracimy do nich dostęp, który odzyskamy automatycznie po założonej liczbie miesięcy, uzyskując z powrotem nasze pieniądze i niewielki zysk. Jest to taka delikatnie powiększają się świnka skarbonka i znamy moment jej rozbicia. Owszem, możemy wcześniej wycofać nasze środki, ale wiąże się to po prostu z powrotem startowej wartości, nawet jeśli zrobiliśmy to na 1 dzień przed planowym rozwiązaniem lokaty.

Lokaty także nie są wysoko oprocentowane (3-4% w skali roku), ale pod kątem czystego zysku jest to lepsza oferta niż w przypadku kont oszczędnościowych. Ponownie można zerknąć do rankingów i szukać promocji. Warto też pamiętać o podatku 19% - zostanie on pobrany automatycznie, ale trzeba wziąć to pod uwagę, gdy będziemy obliczać sobie, ile nadmiarowych pieniędzy dostaniemy.

Co jest potrzebne: Podpisanie umowy (także często wystarczy online) z bankiem i przelanie pieniędzy. Jeśli już mamy konto w banku, to warto zerknąć do ich oferty lokat, ale nie wszystkie lokaty wymagają posiadania konta.

Ryzyko: Podobnie, jak w przypadku konta oszczędnościowego, jest ono praktycznie żadne, a jeśli nasz bank podlega BFG, to do 100 tys. euro jesteśmy bezpieczni. Jedyne co się stanie, to tracimy dostęp do naszych pieniędzy na czas lokaty - możemy go odzyskać przed czasem, ale bez korzyści materialnych oraz z pewnym opóźnieniem.

Zalety: Prostota, praktycznie pewny zysk i bezpieczeństwo - to jedna z najbardziej znanych wśród laików forma oszczędzania i akurat teraz jesteśmy w takim czasie, że niektóre oferty lokat przebijają inflację (w chwili, gdy to piszę, wynosi ona 4%).

Obligacje (detaliczne Skarbu Państwa)

Na wstępie podkreślam, że będziemy mówić o detalicznych obligacjach naszego polskiego Skarbu Państwa, czyli tych oficjalnych, emitowanych przez Polskę jako państwo. To ważne, ale dlaczego - o tym nieco później.

Co to jest: Wyobraź sobie, że potrzebujesz pieniędzy. Możesz wziąć kredyt, natomiast możesz też być bardziej "przebiegły" - emitujesz obligacje o ustalonej cenie na określony czas i dajesz ludziom możliwość: jeśli kupisz teraz ode mnie obligację, to za X lat odkupię ją od Ciebie, dodając coś od siebie. Krótko mówiąc - jako emitent zaciągam dług u osób nabywających ode mnie obligacje (obligatariuszy). Co prawda, za te X lat zapłacę odsetki (jak w kredycie), ale za to mam pewne pieniądze już teraz i mogę je wydać np. na inwestycje.

Jak się pewnie domyślacie, w tym przypadku emitentem jest Skarb Państwa, a obligatariuszem może zostać każdy z nas. Każda obligacja ma pewne oprocentowanie lub warunki oprocentowania (jeśli jest zmienne) i jest na z góry założony czas. To taka lokata, ale o określonej kwocie, zwykle na dłuższy czas i nieco lepiej oprocentowana (zazwyczaj ponad inflację, co jest wręcz wpisane w warunki niektórych typów, jak COI czy EDO). Co więcej, gdy zerwiemy ją przed czasem, to po 5 dniach nie tylko odzyskamy pieniądze, ale też wypracowane dotąd odsetki minus kara za wcześniejsze zerwanie. Nadal trzeba pamiętać o podatku (automatycznie pobieranym), ale to bardzo dobra oferta, jeśli możemy pozwolić sobie na zamrożenie pieniędzy. U niektórych dochodzi też dodatkowy aspekt, a mianowicie poczucie patriotyzmu poprzez finansową pomoc Państwu (jakby podatki to było za mało...) - w końcu za kupione obligacje może wybudować drogi czy coś innego. A przy okazji właśnie się dowiedzieliście, co oznacza, że dany kraj jest zadłużony. Wbrew pozorom, nie jest to takie straszne zjawisko, mimo że politycy i dziennikarze mają niewyczerpywalne źródełko wygłaszania katastroficznych opinii i chętnie z niego korzystają.

Co jest potrzebne: Wystarczy mieć konto w banku, ale w tym przypadku musi to być jedna z państwowych firm - PKO BP lub Bank Pekao S.A. W obu wariantach dostępnych jest kilka rodzajów obligacji różniących się oprocentowaniem, długością trwania, warunkami naliczania odsetek, procentami i karami ze zerwanie. Dodatkowo w pierwszym z tych banków, jeśli jesteście osobami pobierającymi 800+ na dziecko, możecie kupić dodatkowe, nieco lepiej oprocentowane rodzaje obligacji rodzinnych (ROS i ROD). Wszystko macie na stronie obligacjeskarbowe.pl - warto tam zerkać, gdyż warunki mogą zmieniać się co miesiąc z uwagi na sytuację gospodarczą kraju (nawiasem mówiąc, po zalogowaniu interfejs tej strony przypomniał mi moje początki z HTMLem…). Kupować możecie tyle obligacji, ile chcecie i nic nie stoi na przeszkodzie, aby dokładać je z czasem. Jak zresztą wiele osób robi.

Technicznie w PKO BP obligacje kupuje się właśnie na stronie obligacjeskarbowe.pl, natomiast w Bank Pekao S.A. robi się to bezpośrednio z poziomu interfejsu webowego banku (podpisując dodatkową umowę). I trzeba przyznać, że w tym drugim przypadku cały proces jest przyjaźniejszy, a ponadto w przypadku przepisania papierów wartościowych na inną osobę (np. w wyniku spadku) opłaty znacznie mniejsze.

Ryzyko: Też praktycznie minimalne, przynajmniej jeśli mówimy o Skarbie Państwa. Mówiąc wprost, Polska musiałaby upaść lub musiałby się zmienić ustrój, aby obligacje były bezwartościowe (co zresztą miało miejsce w historii naszego kraju i to nawet w XX wieku). Natomiast całkiem realne jest ryzyko obniżenia (ale też podwyższenia) oprocentowania w wyniku zmian gospodarczych - przykładowo, kupując dzisiaj obligacje roczne ROR mamy zysk rzędu 5,25% na rok (z dnia 6 lipca 2025 r.), ale wiadomo już, że przy obniżającej się referencyjnej stopie procentowej ten procent w kolejnych miesiącach będzie niższy.

Zalety: Obligacje skarbowe są naprawdę elastyczne - w polskiej ofercie znajdziemy rodzaje dla osób chcących mieć odsetki wypłacane co miesiąc, propozycje stałoprocentowe, a także takie, które kumulują się w procencie składanym przez 10 lat i zawsze dają odsetki powyżej inflacji. Dodatkowo, kupujemy obligacje przy pewnych warunkach, które są zachowane przez cały okres trwania (np. jeśli dzisiaj kupiliśmy EDO, którego oprocentowanie w danym roku wynosi 2% + inflacja, to nie interesuje nas to, że np. za 4 lata będzie to 1% + inflacja). Mamy tutaj możliwości dobrze przemyśleć naszą strategię (zwykle skupioną wokół przewidywanego poziomu inflacji lub stóp procentowych), a jednocześnie nie ryzykujemy zbyt wiele.

Dodatkowe informacje: A teraz wróćmy do kwestii obligacji Skarbu Państwa. Jak pewnie podejrzewacie, termin "obligacja" jest szerszy i obejmuje nie tylko środki pożyczane polskiemu państwu. Co więcej, nie musi być to Polska - istnieje możliwość (zwykle niebezpośredniego) inwestowania w obligacje innych krajów.

Jednak istnieją też typy obligacji nieco bardziej ryzykownych - są to np. te notowane na rynku (i podlegające wahaniom giełdowym), które jednak często są domeną instytucji takich jak towarzystwa funduszy inwestycyjnych lub po prostu firm. I tak - można na nich stracić. Podobnie jak na obligacjach korporacyjnych, w których emitentem jest tym razem nie państwo, tylko firma. Często są to ciekawe oferty, które kuszą odbiorców, natomiast trzeba zdawać sobie sprawę z tego, iż firmy to nie państwo - tutaj ryzyko upadku emitenta (a co za tym idzie - naszych pieniędzy) jest już nieco większe. No i np. cena nominalna obligacji Orlenu wyniosła nie 100 zł, tylko… 100 tys. zł.

Na koniec warto wspomnieć, że w obligacje nie musimy inwestować bezpośrednio - popularne są fundusze inwestycyjne i ETF-y, które polegają właśnie na odnoszeniu zysków z tych papierów zwanych dłużnymi (gdyż opierają się na długu). Z założenia nie przynoszą one takich kokosów, jak te akcyjne, ale mają dużo mniejsze ryzyko. Może to być ciekawa alternatywa, kiedy np. kiedy chcemy odnosić zyski nie tylko z detalicznych obligacji, z góry zakładamy szybsze pozbycie się inwestycji (dostęp do środków z funduszy czy ETF-a jest krótszy) i nie boimy się pewnej prowizji.

Fundusze inwestycyjne

Co to jest: Załóżmy, że chcemy inwestować, ale jednak blokuje nas kilka rzeczy. Po pierwsze, nie wiemy jak to technicznie zrobić. Po drugie, boimy się, że coś zepsujemy i kupimy kompletnie bezwartościowe papiery. Po trzecie, nie mamy czasu na samodzielne dyrygowanie naszym portfelem (a więc interesuje nas daleko posunięta pasywność). Czy wówczas jesteśmy ograniczeni do obligacji? Nie - jak w każdej branży możemy zdać się na specjalistów, którym powierzymy pieniądze, a oni, wykorzystując swoją wiedzę i doświadczenie, zainwestują za nas. Tym właśnie są towarzystwa funduszy inwestycyjnych (TFI).

Najłatwiej myśleć o tym, jak o pośrednikach, którym dajemy tylko pewne wskazówki - po wybraniu instytucji, mamy do wyboru zwykle kilkanaście propozycji "programów" (a więc właśnie funduszy inwestycyjnych), które różnią się typem, ryzykiem, a także profilem inwestowania. Zazwyczaj mamy do wyboru różne fundusze dłużne (inwestujące np. w obligacje, a więc papiery oparte na długu), akcyjne, mieszane, nieruchomości itd. Co więcej, ta dywersyfikacja idzie znacznie dalej - są propozycje inwestycji w obrębie spółek amerykańskich, polskich, bardziej ryzykowne obligacje itd. Nie musimy ograniczać się do jednego typu - możemy wpłacić pieniądze na różne oferty. Po drugiej stronie są specjaliści, którzy mniej lub bardziej aktywnie zarządzają takim funduszem, robiąc co mogą, aby jak najlepiej zainwestować środki powierzone przez klientów.

Brzmi pięknie, ale jak zwykle, są wady. Po pierwsze, fundusze wiążą się z dość wysoką prowizją, znacznie wyższą niż w przypadku ETF-ów, o których zaraz sobie trochę napiszemy. To oznacza, że nasz zysk jest pomniejszony o wynagrodzenie dla specjalistów po stronie instytucji finansowej. Niby nic dziwnego, ale te opłaty, mimo że oscylują wokół 2%, mogą być znaczące. Po drugie, to nie jest tak, że ci specjaliści zawsze świetnie obrócą naszymi pieniędzmi - oni też mają swoje ograniczenia, swoje szczęście lub nieszczęście w analizach, lepsze lub gorsze dni.

Trzeba też przyznać, że fundusz inwestycyjny nie jest aktywem jako takim - jest pośrednikiem, za pomocą którego możemy zerkać na inne rynki (mówiąc bardziej fachowo - mieć na nie ekspozycję i to słowo, którego użyję jeszcze kilka razy, a potem wyjaśnię w słowniczku terminu).

Co jest potrzebne: Ponownie - większość banków ma swoje towarzystwa funduszy inwestycyjnych i po podpisaniu odpowiedniej umowy można zacząć z nimi przygodę w ramach posiadanego konta. Ale fundusze są dostępne także w innych instytucjach finansowych, niebędące bankami (co nie znaczy, że są mniej zaufane). Przed podjęciem decyzji zawsze poczytajcie informacje i opinie.

Ryzyko: Jest już większe niż w poprzednio opisanych formach. Dużo zależy od rodzaju funduszu, w który decydujemy się inwestować (jest to siedmiostopniowa skala, w której im wyższa wartość, tym większe ryzyko utraty środków, ale zwykle też prawdopodobieństwo większych zysków), natomiast trzeba powiedzieć wprost - tak, istnieje teoretyczna szansa utraty wszystkich środków. A już na pewno trzeba liczyć się z tym, że jakiś fundusz przez pewien czas będzie na minusie - sam to obserwowałem w swoich funduszach akcyjnych, ale będąc przy tym spokojny, bo rozumiałem, z czego to wynika (zawirowania związane z cłami). Wcześniej wspomniany też Bankowy Fundusz Gwarancyjny nie obejmuje swoim zasięgiem środków w funduszach inwestycyjnych, nawet jeśli oferuje je bank.

Zalety: Przede wszystkim spokój przy jednocześnie większym udziale w rynku - dajemy pieniądze i wierzymy w umiejętności inwestycyjne osób, które opiekują się funduszem. Oczywiście, ma to zalety i wady, ale potencjalnie faktycznie umożliwia wyższe stopy zwrotu bez potrzeby zakładania konta maklerskiego (które do niedawna dla niektórych było barierą nie do przejścia, owianą pewnym mistycyzmem).

Dodatkowe informacje: Fundusze inwestycyjne to pierwsza forma inwestowania, w której nie tylko obowiązuje podatek od zysków, ale też sami musimy go odprowadzać i wypełniać PIT-38. Przed 2025 rokiem robiło to TFI, jednak teraz to klient sam musi o to zadbać. Oczywiście, jest to niedogodność i pewien stres, ale prawda jest taka, że obliczeniowo jest to lepsze rozwiązanie, gdyż umożliwia sytuację, w której strata w jednym funduszy przykryje zysk w innym, w efekcie czego podatek zostanie zredukowany.

ETF (Exchange Traded Fund)

Co to jest: Aby zrozumieć, czym są ETF-y, trzeba zrozumieć, czym są indeksy giełdowe. Na szczęście, jest to dość proste zagadnienie, więc postaram się je krótko przedstawić.

Wyobraź sobie, że śledzisz polską giełdę, czyli - mówiąc bardziej precyzyjnie - śledzisz wyniki spółek notowanych na polskiej giełdzie. Na naszej Giełdzie Papierów Wartościowych (GPW), w chwili, gdy to piszę, jest ponad 400 takich firm i wiadomo, że nie za każdą możemy (i chcemy) podążać - interesują nas tylko niektóre przedsiębiorstwa, ale przede wszystkim chcemy wiedzieć, jaka jest orientacyjna "siła" całej giełdy lub jego kawałka. Czy musimy wówczas brać wyniki każdej firmy i je uśredniać, aby uzyskać końcowy rezultat? Otóż, nie - indeksy giełdowe robią to za nas. To są właśnie przybliżenia pewnego wycinka rynku, dzięki któremu możemy się dowiedzieć, jak dobrze sobie radzi dany obszar czy segment. Indeksy mogą być tak naprawdę dowolnie skonfigurowane, ale zazwyczaj dotyczą całego kraju (u nas jest to WIG), największych spółek danego regionu (u nas WIG20, w Stanach Zjednoczonych np. S&P 500) lub konkretnego segmentu (np. WIG-Banki).

I właśnie ETF możemy sobie wyobrazić, jako akcje nie na spółkę, tylko indeks. Krótko mówiąc - gdybyśmy chcieli zainwestować całościowo w polską giełdę, to nie musimy wkładać pieniędzy w każdą spółkę osobno, tylko możemy znaleźć odpowiedni ETF, który to zrobi za nas i zautomatyzuje. Istnieją też bardziej wyspecjalizowane ETF-y, które śledzą wyjątkowo dobrane indeksy i spółki, jak np. te o najwyżej dywidendzie, zajmujące się danymi surowcami itd. Jest naprawdę dużo możliwości i jest to bardzo wygodne. Przykładowo - jeśli wiemy, iż np. wzrosty w USA są wysokie, ale nie mamy czasu sprawdzać, które dokładnie przedsiębiorstwa za to odpowiadają, to możemy po prostu wrzucić pieniądze w ETF śledzący USA. Dochody nie będą tak duże, jak przy starannie wyselekcjonowanych spółkach, ale oszczędzamy bardzo dużo czasu i nerwów, zwłaszcza, jeśli się na tym do końca nie znamy.

ETF-y są bowiem czymś w rodzaju wcześniej omawianych funduszy inwestycyjnych, ale z paroma różnicami:

  • wymagają konta maklerskiego,
  • zwykle nie są aktywne zarządzane, tzn. "ślepo" podążają za danym indeksem lub segmentem rynku, a kontrola specjalisty jest w tym marginalna (zapewne poza pewnymi wyjątkami),
  • mają dużo niższe opłaty za zarządzanie.

I przede wszystkim ten ostatni aspekt sprawił, że to one, a nie fundusze inwestycyjne (które, żeby nie było, też mogą być warte uwagi) stały się narzędziami, które pozwalają inwestować pasywnie i wręcz zrewolucjonizowały taki sposób działania, zachęcając tym samym mniej doświadczonych inwestorów do spróbowania swoich sił. Są bowiem dużo prostsze - nie trzeba analizować spółek, tylko, jeśli już, to całe rynki. A nawet to bywa niepotrzebne, jeśli chcemy zainwestować w... cały świat, bo tak, takie ETF-y też istnieją. I są one co jakiś czas wewnętrznie rebalansowane (później wyjaśnimy ten termin), przez co skład ETF-a jest ciągle dostosowywany do sytuacji na rynku.

Przy kupowaniu ETF-a należy wziąć pod uwagę, czy jest oparty o dywidendy (ang. distributing), czy akumulację (ang. accumulating). W pierwszym przypadku zyski z inwestycji są wypłacane cykliczne właśnie w formie dywidendy. W drugim przypadku zyski są reinwestowane, zwiększając tym samym potencjał dalszych wzrostów, korzystając z magii procentu składanego. Na początku zdecydowanie warto się zainteresować tymi drugimi i to z dwóch powodów - po pierwsze, same się "napędzają", przez co w teorii mają szanse na coraz lepsze wyniki, a po drugie - odpada problem z rozliczaniem podatku z dywidend.

Co jest potrzebne: Konto maklerskie - ETF-y możemy technicznie traktować jak akcje, więc potrzebujemy brokera, za pomocą którego będziemy mogli je kupić. Nie jest to trudne, ale tutaj już bank nie wystarczy (choć większość banków też ma swoje domy maklerskie). Warto zwrócić uwagę, że nie każdy broker ma w swojej ofercie wszystkie ETF-y, a nawet trudno znaleźć takiego, który ma cały wachlarz w swojej ofercie. Tym niemniej, możliwości w Polsce i tak są duże i jeśli nie chcecie inwestować w dość innowacyjne lub niecodzienne twory (przykładowo - w czasie, gdy to piszę, żaden polski dom maklerski nie oferuje ETF-a na spółki działające na rynku komputerów kwantowych), to raczej nie będziecie mieli problemu.

Ryzyko: Tak, jak fundusze inwestycyjne, ETF-y wiążą się z ryzykiem, które zależy to od rodzaju aktywów, w które inwestujemy. Warto przy tym spojrzeć na tzw. kapitalizację ETF-a (ilość pieniędzy, którą ludzie w niego zainwestowali) - im większa, tym trudniej ETF-owi się zupełnie załamać, aczkolwiek spadki zawsze są możliwe. Wyższa kapitalizacja sugeruje (aczkolwiek nie jest równoważne temu) w dodatku, że dany instrument jest bardziej płynny, tj. nie będzie większego problemu z kupnem i sprzedażą. Zazwyczaj też ETF-y są uznawane za bardziej bezpieczne aktywa niż akcje konkretnych spółek (a jeśli weźmiemy jakieś związane z szerokim rynkiem, to już w ogóle ewentualne spadki nie powinny być ogromne).

Zalety: Wygoda, cena (w stosunku do funduszy inwestycyjnych) przy jednoczesnej ekspozycji na konkretny fragment rynku, czasem bardzo dziwny. ETF-y naprawdę są uznawane za jeden z najważniejszych wynalazków inwestycyjnych ostatnich lat, gdyż ułatwiają "cieszenie się" giełdą takim typowym Kowalskim, jakim jestem ja czy (być może) Wy. Nie muszę bowiem np. decydować, czy lepiej zainwestować w Microsoft, Google, Apple czy Amazona oraz w jakich proporcjach - biorę ETF na indeks Nasdaq-100 i po prostu czekam, a sam analizuję tylko to, czy np. technologiczna część Stanów Zjednoczonych jest obecnie warta uwagi, czy nie.

Dodatkowe informacje: Gdy będziecie przeglądać oferty biur maklerskich, możecie natknąć się na dodatkowe skróty: ETC (od "Commodity") oraz ETN (od "Note"). Również można traktować je jako ETF-y, ale różnią się pewnymi cechami związanymi m.in. z ryzykiem (np. ETN zwykle są dość ryzykowne), a przede wszystkim rodzajem aktywów, w które pozwalają inwestować. ETC związane jest zazwyczaj z surowcami (np. złotem, ropą naftową, platyną itd.), a ETN - z mniej dostępnymi aktywami, bardziej "nienamacalnymi" i tutaj przykładem może być ETN na kurs danej kryptowaluty. Nadal możemy traktować je jako ETF-y, ale technicznie pod spodem wyglądają trochę inaczej.

Akcje

Co to jest: To walory najbardziej kojarzące się z giełdą i przepychającymi się oraz krzyczącymi maklerami w czerwonych szelkach na parkietach Wall Street. Każda spółka akcyjna (która może być notowana na giełdzie) dzieli swój pakiet właścicielski na akcje. Zwykle jest to duża liczba - np. 100 milionów. Wchodząc na rynek, część akcji może zostać sprzedana zwykłym inwestorom (od spółki zależy, ile) i to one właśnie są kupowane oraz sprzedawane na rynku. Mówiąc wprost - tak, kupując akcję, stajemy się współwłaścicielami choćby największej spółki na świecie. Teoretycznie, kupując 1 akcję CD Projektu, możecie się zapowiedzieć i wejść na Walne Zgromadzenie Akcjonariuszy, dostać herbatę oraz wymądrzać się o kolorze włosów Ciri (ale nie róbcie tego, błagam). Przy czym mało kto z nas ma środki, aby kupić tyle tych papierów, aby rzeczywiście mieć znaczenie dla działań spółki - taką inwestycję liczy się w milionach (i to raczej niejednocyfrowych) lub miliardach.

A na czym właściwie się zarabia kupując akcje?

  • a) na wzroście spółki, czyli wzroście wartości jednej akcji. Krótko mówiąc, gdy kupimy akcje za 100 zł, to celujemy w to, że za jakiś czas będą warte np. 150 zł i wtedy je sprzedamy.
  • b) na dywidendach - w określonych momentach (zwykle raz w roku) spółka ogłasza czy osiągnęła zysk i jeśli tak, to czy zysk zostanie zainwestowany, czy podzieli się nim z akcjonariuszami. W tym drugim przypadku na każdą akcję przypada pewna kwota dywidendy i inwestor normalnie ją dostaje na swoje konto maklerskie.

Od obu form płaci się podatek 19% - pozornie ten sam, gdyż tak samo oprocentowany, ale w praktyce są to dwa różne podatki. Jedna uwaga - jeśli już teraz zapaliła się Wam w głowie lampka, że z tak wypłacanych dywidend można spokojnie żyć, to wiedzcie, że być może tak, ale musielibyśmy kupić akcje za… dziesiątki milionów złotych. Poza tym ta forma zyskiwania na spółkach ma kilka wad (szczególnie istotnych dla prawdziwych rekinów giełdy), więc przyjmijmy, że w większości jednak interesuje nas pierwszy sposób (mimo że niektórym zgrzyta on ideologicznie).

Ponieważ to materiał dla początkujących, to ominę tutaj shortowanie (zarabianie na spadkach) itd. Natomiast muszę nadmienić, że zazwyczaj kupowanie akcji konkretnych spółek, mimo że może być bardziej zyskowne, to jest trudniejsze niż kupno ETF-a. Musimy (albo powinniśmy) bowiem ocenić zyskowność spółki, przeanalizować jej wyniki, rentowność, fundamenty, cenę i wiele innych elementów, aby właściwie zdecydować w sprawie włożenia danych akcji do portfela. Poważniejsi inwestorzy posuwają się wręcz do pytania pracowników lub szefów firmy o pewne kwestie przed inwestycją. Ale w tym przypadku mówimy o ludziach, którzy kupują tyle akcji, że niemalże stają się ważnymi osobistościami na zgromadzeniach wspólników i pojawiają się w oficjalnych zestawieniach akcjonariatu. Lub zarządzają funduszami inwestycyjnymi czy nawet hedgingowymi.

Co jest potrzebne: Konto maklerskie. Zwykły śmiertelnik nie może bezpośrednio kupić akcji - musi to zrobić poprzez licencjonowanego brokera, czyli zlecając kupno (lub sprzedaż) akcji. Natomiast istnieje możliwość wybrania funduszu inwestycyjnego, który inwestuje właśnie w akcje, jednak taki pośrednik notuje swoją prowizję (niemałą). Teoretycznie można też uzyskać akcje poza giełdą, ale nie będziemy wchodzić w ten temat.

Ryzyko: Tak - jeśli zainwestujemy w złą spółkę, możemy stracić nasze pieniądze, przy czym utrata wszystkiego to bardzo rzadka sytuacja. Natomiast początkujący muszą pamiętać, jeśli firma generalnie jest zyskowna i pnie się do góry, to dzieje się to sinusoidalnie, więc podczas naszej kariery inwestora napotkamy wzrosty, ale też spadki i to często wynikające z nieracjonalnych przyczyn (plotki, pogłoski, pożyczki na shorty itd.), jak i racjonalnych (pogarszające się wyniki firmy, konkurencja). Możemy spodziewać się większych wahań niż przy ETF-ach, choć z drugiej strony możemy też więcej zyskać. Tu jednak wchodzimy już w trochę psychologię inwestowania, więc napiszę krótko - tak, jest ryzyko i dlatego warto dobrze dobierać spółki, a nie rzucać się na wszystko, co mignie nam na zielono. Mimo że to bardzo, ale bardzo kuszące.

Tutaj warto też wspomnieć o tym, co dzieje się z akcjami i ETF-ami, gdy upada dom maklerski. W przypadku banków wiemy, że część z nich (większość w Polsce) uczestniczy w Bankowym Funduszu Gwarancyjnym. W przypadku brokerów też istnieje podobny fundusz, ale ta kwota jest mniejsza, bo wynosi do 22 tys. euro. Jednak to nie powinno być drogowskazem, bo chodzi w tym przypadku o wolne środki pieniężne przechowywane u maklera, a tych powinniśmy mieć mało (w końcu po co je trzymać jako wolne, skoro można zainwestować). O wiele bardziej interesuje nas kwestia posiadanych akcji i tutaj dobra informacja - tak naprawdę rejestr tego, co kupiliśmy, nie jest tylko u brokera, ale także w Krajowym Depozycie Papierów Wartościowych (KDPW) i w przypadku takiego nieszczęśliwego incydentu, nasze papiery są po prostu przenoszone gdzie indziej, zgodnie z naszą decyzją. Niestety, nie ma róży bez kolców - nie dotyczy to instrumentów, w których stroną jest upadający dom maklerski, a więc omawianych później CFD, a także akcji ułamkowych (niektórzy brokerzy umożliwiają kupno części akcji). Więcej informacji o tej procedurze znajdziecie w tym artykule.

Zalety: Zdążyłem już wspomnieć - akcje mogą być bardzo zyskowne, jeśli dobrze "trafimy" w spółkę. Natomiast dają nam też poczucie bycia współwłaścicielem (nawet, jeśli bardzo, ale to bardzo mniejszościowym) i prawo do dywidendy. Niektórzy wręcz tak budują swoje portfele, dywidendami wypracowując sobie dodatek do pensji.

Dodatkowe informacje: Przy okazji można wyjaśnić tutaj jedną rzecz - to akcje w większości odpowiadają za to, że ktoś jest tak "obrzydliwie" bogaty. W chwili, gdy to piszę, sprawdziłem, że majątek Elona Muska jest szacowany na 342 miliardów dolarów. Ale to nie oznacza, że Musk ma w swoim domu ogromny skarbiec z monetami i niczym Sknerus McKwacz z bajki nurkuje w złocie. W znakomitej większości środki wliczane do tej statystyki to właśnie całościowa wartość posiadanych przez niego akcji (akurat tutaj głównie spółki Tesla). Z tego też wynikają sensacyjne nagłówki typu "Po tej decyzji miliarder stracił 12 miliardów dolarów!!! [HIT][ZOBACZ MEMY]" - zwyczajnie nastąpił spadek cen akcji jego spółek (zwykle gwałtowny). Ale sam Elon nadal ma co włożyć do garnka na obiad.

Surowce (złoto)

Co to jest: Jeśli nie chcesz inwestować w rzeczy, których nigdy na oczy nie zobaczysz (bo istnieją tylko w zapisach formalnych ksiąg i formie cyfrowej), to istnieje szansa, że zainteresujesz się fizycznymi, namacalnymi aktywami. Widzisz bowiem, co kupiłeś i co sprzedasz. Ma to swoje duże zalety - masz "coś" w kieszeni, nikt Ci tego nie odbierze np. poprzez zgadnięcie hasła u maklera i jest zabezpieczeniem w krytycznych sytuacjach (np. podczas ucieczki z kraju). Są też pewne wady - jako że posiadasz dany surowiec fizycznie, to musisz go przechowywać, dbać o niego, a sprzedaż wiąże się z fizyczną transakcją. Tak, trzeba rozmawiać z ludźmi twarzą w twarz. Koszmar introwertyka.

Z tego grona to złoto ma największą renomę i nie bez powodu - szlachetny kruszec ma opinię ciągle rosnącego (co nie jest do końca prawdą, ale rzeczywiście raczej można się spodziewać wzrostu z czasem), długoterminowego aktywa, która ma w dodatku pewną "historię" za sobą. Złota inwestycyjnego (to ważne - nie mówimy tutaj raczej o złocie w postaci biżuterii) nie kupuje się na pół roku czy rok - nierzadko są to przedmioty przekazywane z pokolenia na pokolenie. Zwłaszcza, że zawsze nabywa się je z pewną marżą i sprzedaje z pewną stratą i trzeba się z tym pogodzić - nie sądzę, abyśmy przy transakcjach uzyskiwali ceny rynkowe.

Dlaczego ciągle mówi się o złocie? Gdyż inne kruszce są już bardziej chwiejne (choć okresowo potrafią być bardziej dochodowe), a surowce innego typu są problematyczne w przechowywaniu.

Co jest potrzebne: Złoto można kupić w postaci sztabek (zabezpieczonych specjalnym certyfikatem) oraz monet (które warto od razu włożyć do kapsla numizmatycznego) w mennicach lub sklepach ze złotem. Potrzebne jest podanie PESELu. Warto wybierać zaufanych dostawców (przy tych cenach nie możemy pozwolić sobie na niepewne zakupy) oraz przedmioty o masie co najmniej 1 uncji, a więc standardowej jednostki notowań kursu kruszcu. Powód jest prosty - mennica i tak dodaje pewną marżę, a jest ona tym większa, im mniej waży przedmiot. To oznacza, że teoretycznie najbardziej opłacalna jest kilogramowa sztabka złota, ale umówmy się - mało kto sprzeda mieszkanie, aby taką nabyć. Uncjowe sztuki są rozsądne.

Ekspozycję na surowce można też osiągnąć poprzez odpowiednie fundusze ETF (a właściwie ETC) - stanie się to wygodniejsze, ale wartość będzie trochę niższa, choćby przez prowizję. No i wymaga to wówczas już konta maklerskiego.

Ryzyko: Relatywnie niskie, choć złoto też potrafi spaść (nie że z biurka, tylko cena). Tutaj ryzyko może być bardziej fizyczne - co prawda, uszkodzone monety też są wartościowe, ale wiadomo, że zabezpieczenie fizycznych przedmiotów jest po naszej stronie i to może trochę stresować. W przypadku innych surowców ryzyko utraty wartości jest nieco większe, choć to już zależy od konkretnego rynku - warto śledzić opinie specjalistów.

Zalety: Częściowo już je wymieniłem - stanowią fizyczną własność i długo, ale stabilnie nabierają wartość. Dodatkowo, złoto jest pozbawione podatku VAT, a w wielu przypadkach zwolnione z podatku ze sprzedaży. Wielu inwestorów odradza złoto, ale równie wielu (szczególnie tych “spokojnych") potwierdza, że jest dobrym dodatkiem do portfela inwestycyjnego. Jednak posiadanie większości swoich zasobów w postaci złota to już zdecydowana przesada, chyba że prowadzimy bank centralny danego kraju.

Nieruchomości

Co to jest: Czym są nieruchomości, chyba każdy z nas wie - domy, mieszkania, ziemia, kawalerki, mikrokawalerki, mikrokawalerki przypominające chów klatkowy... No dobra, żarty na bok, gdyż niektórym na pewno nie jest do śmiechu. Wiadomo też, że kwestia nieruchomości jako inwestycji jest dość kontrowersyjna i nacechowana dyskusjami światopoglądowymi oraz wręcz moralnymi. Nie chcę się do tego odnosić i na tym skupiać, natomiast rzeczywistość wygląda tak, że można je traktować jako inwestycje w ramach obowiązujących reguł prawa i własnej moralności.

Bardzo drogie inwestycje - doskonale wiemy, że w ostatnich latach ceny mieszkań poszybowały w górę, niejedna rodzina ma problem z kupieniem na własność swojego lokum, a kwoty wynajmu też do niskich nie należą. Niejeden mieszkaniec dużego miasta irytuje się też, gdy stawiają mu obok nowy blok, a ktoś za gotówkę kupuje od ręki 15 lokali. Tym niemniej, trzeba przyznać, że jest to inwestycja dość pewna, opierająca się na rosnących wartościach oraz dochodu z wynajmu. Wiąże się to z formalnościami, koniecznością współegzystencji z ludźmi (wynajmującymi i kupującymi), radzeniem sobie z trudnymi “przypadkami", ale nie da się ukryć, że z jakiegoś powodu ludzie się na to decydują - to się po prostu opłaca (oczywiście, w dłuższym terminie). Zresztą, każdy z nas pewnie w podstawowym stopniu ma kontakt z tym rynkiem lub czytał o tym w gazetach.

Co jest potrzebne: Pieniądze i umiejętność załatwiania odpowiednich formalności. To w pewien sposób też dobro fizyczne, ale zbyt duże, aby je schować do kieszeni.

Ryzyko: Teoretycznie wartość mieszkania może spaść ze względu na czynniki makroekonomiczne, nowe regulacje prawne lub nawet w wyniku działań wojennych. Co do prawdopodobieństwa wystąpienia tych sytuacji - nie będę tutaj zgrywał eksperta i wypowiadał się na ten temat.

Zalety: Wymienione wcześniej i rozumiane intuicyjnie przez każdego. Ale też nie jest to sposób inwestowania dla każdego i jeśli mimo porad inwestycyjnych znanych osób nie jesteście chętni zaciągać kolejne kredyty hipoteczne, aby kupić nawet dobrze usytuowane mieszkanie na wynajem lub sprzedaż - nie przejmujcie się, bo macie się czuć komfortowo ze swoimi inwestycjami, a nie kupować nieruchomość dlatego, że "wszyscy tak robią i są bogaci". Lepiej skupić się na kupieniu swojego wymarzonego lokum, takiego po prostu do życia. Czego Wam życzę.

Co jeszcze jest dostępne na rynku?

To nie wszystkie rodzaje aktywów, w które można inwestować, jednak to są te, które nie wymagają ogromnej wiedzy, szperania w poszukiwaniu szczegółowych informacji lub nie wiążą się z ogromnym stresem po kupieniu. Owszem, to nie znaczy, że kupując akcje nie należy się interesować lub nawet martwić, ale są też takie rodzaje ulokowania pieniędzy, w których omawiane trudności występują w większym natężeniu. Dlatego myślę, że początkujący mogą spokojnie je pominąć, chyba że wyjątkowo coś im wpadnie w oko. Ale wiedzieć o nich warto.

W tym miejscu też notka dla osób bardziej doświadczonych, którzy przeczytają ten fragment, zobaczą swoje ulubione formy inwestowania i już będą chcieli mnie krytykować - pamiętajcie, że to artykuł dla początkujących, którzy prawdopodobnie nie chcą podejmować dużego ryzyka i nie mają dużo czasu.

  • Inne surowce - wspominałem o złocie, ale istnieją też inne kruszce lub surowce. Jednak, o ile w przypadku srebra, palladu czy platyny "trudnością" są wahania cen (trzeba się po prostu bardziej interesować tym rynkiem), o tyle w przypadku innych dóbr dochodzi np. problem magazynowania. Wytłumaczcie np. drugiej połówce, że właśnie musicie opróżnić piwnicę, bo kupiliście 200 kg zboża na handel. Oczywiście, perspektywa zmienia się, gdy jesteście rolnikami lub macie ogromne przestrzenie. W surowce często inwestuje się w formie CFD, ale to inna bajka, o której za chwilę.
  • CFD (ang. Contract for Difference - bardzo ryzykowne instrumenty pochodne, opierające się nie na samym aktywie, ale różnicy jego ceny. Krótko mówiąc - możemy obstawić, że w danym czasie cena danej spółki, surowca itd. wzrośnie lub spadnie. Ale jest jeszcze coś - dźwignia finansowa, a więc mnożnik naszego zysku lub straty. Jak pewnie się spodziewacie, nie jest to instrument, w który spokojnie się wkłada pieniądze i wyciąga np. za rok, zwłaszcza, że płacimy za każdy dzień utrzymania CFD. Zdecydowanie nie polecam tego początkującym, ale także inwestorom, którzy nie lubią nadmiernego ryzyka.
  • Opcje - gdy porozmawiacie z bardziej doświadczonymi inwestorami (wręcz takimi, którzy z tego żyją i pracują na rynkach finansowych), to być może usłyszycie, że opcje są świetną - nomen omen - opcją, gdyż niejako blokują nam cenę, po której kupimy lub sprzedamy. Jednak jest to koncepcja bardzo, ale to bardzo zawiła dla początkujących, a do tego dostępna tylko u niektórych brokerów. W tym przypadku nie tyle chodzi o ryzyko, co o bardzo trudny do zrozumienia mechanizm dla kogoś, kto dopiero zaczyna lub nie chce inwestować na pełen etat i przejmować się szczególami. Jednak samą koncepcję warto poznać, np. za pośrednictwem serii krótkich filmów od Tomasza Treli.
  • REIT (ang. Real Estate Investment Trust) - są to specjalne spółki (często amerykańskie, ale nie tylko), które żyją z wynajmu nieruchomości i z uwagi na pewne korzyści prawne (podatki) są zobowiązane do wypłacania częstych i licznych dywidend. Oznacza to, że jest to sposób na czerpanie korzyści z rynku nieruchomości bez kupowania nieruchomości i to nie tylko mieszkań, gdyż są REITy dające ekspozycję np. na przestrzenie biurowe czy naukowe. W tym przypadku trudność wynika z braku takich spółek w Polsce i braku regulacji prawnych (i znowu wchodzimy w kwestie światopoglądowe) - jak najbardziej można w nie inwestować na rynku amerykańskim, natomiast dochodzi trudność rozliczenia podatków z dywidend. Tutaj też musimy mieć na uwadze, że raczej nie zarobimy na sprzedaży samych REITów - to regularny podział zysków jest tym, co przyciąga inwestorów.
  • Kryptowaluty - chyba każdy słyszał o Bitcoinie, ale nie jest to jedyny przedstawiciel kryptowalut, choć rzeczywiście najbardziej "uznany" i najdroższy. Ten rodzaj aktywa jest niezwykle gorącym tematem, ale też nie dla wszystkich jasnym od strony technicznej (choćby pod kątem przechowywania ich - sam niedawno dowiedziałem się o istnieniu tzw. cold walletów). Giełdy krypto i sama tematyka często pojawia się przy akompaniamencie jakichś oszustw, niepewnych stron (mimo że sama idea krypto “scamem" absolutnie nie jest), a do tego jest to aktywo WYBITNIE spekulacyjne i ryzykowne. Na pewno słyszeliście o dużych wzrostach lub spadkach Bitcoina - są one spektakularne i... w sumie czasem wiadomo, z jakiego powodu nastąpiły. Dodatkowo, nie wszystko wokół kryptowalut jest dopięte na ostatni guzik pod kątem prawnym - ten proces dopiero trwa i np. w chwili, gdy to piszę, w Polsce wkrótce nastąpi premiera ETF-a opartego o Bitcoina, ale nie samą kryptowalutę, a kontrakty na nią - właśnie ze względów nienadążającego polskiego prawa. To nie jest tak, że ten typ aktywa jest zły - on jest po prostu bardzo niepewny z takiego czystego analitycznego punktu widzenia, a już na pewno jest nieodpowiedni dla osób stroniących od ryzyka. I nie, przebywanie w sektorze IT nie daje przewagi w finansowym zrozumieniu elektronicznych walut, choć rzeczywiście z czysto informatycznej perspektywy jest to ciekawy mechanizm, mający też wpływ na inne dziedziny życia.
  • Forex - czyli giełda głównie dotycząca transakcji przeprowadzanych na zmianach kursach walut. Zmianach - czyli mamy tutaj podobną historię, jak w przypadku wcześniej omawianego CFD i te same problemy. Bardzo, bardzo ryzykowna i spekulacyjna zabawa, w której wiele osób po prostu traci swoje pieniądze. Nie mówię, że nie można na tym zyskać, ale powiedzmy, że to już działka dla osób lubiących, gdy dużo się dzieje i trzeba reagować. Zdecydowanie nie jest to odpowiednia droga dla początkujących osób chcących inwestować lub (tym bardziej) oszczędzać. Jest to też rynek z dużą liczbą botów, gdyż wszystko dzieje się tutaj tak szybko i na tak małych wartościach, że człowiek bez wspomagania technicznego raczej nie dałby rady.

Czy to oznacza, że jako początkujący koniecznie masz unikać powyższych form? Nie, ale na pewno nie są one tak "proste", jak te rodzaje oszczędzania i inwestycji, o których wspominałem wcześniej. Najważniejsze, abyś czuł(a) się komfortowo ze swoimi inwestycjami - nie daj sobie wmówić, że robisz błąd nie wkładając pieniędzy w X, jeśli tak naprawdę nie rozumiesz X lub masz wobec niego wątpliwości. Oczywiście, zawsze warto poszerzać swoją wiedzę, ale nie oznacza to, że np. masz kupować złoto, bo "wszyscy tak robią". Cytując mojego nauczyciela WF-u, gdy skróciłem sobie drogę podczas biegu podczas lekcji, bo inni uczestnicy tak postąpili - jeśli wszyscy skoczą do studni, to też to zrobisz?

Od czego zacząć i czy opłaca się startować od 100 zł?

Wspominałem o tym, że ten artykuł nie jest materiałem doradczym - to przedstawienie tematu z własnej perspektywy, aczkolwiek też próba edukacji i obalenia pewnych mitów (oraz podtrzymanie innych). Dlatego to, co teraz napiszę, proszę traktować jako moją opinię i to, jak ja bym zaczynał, gdybym robił to jeszcze raz.

Osobiście startowałbym ostrożnie, od obligacji skarbowych i już wyjaśniam, dlaczego. Jeśli czytasz ten artykuł i dotarłeś(aś) aż tutaj (za co bardzo dziękuję), to jest duża szansa, że masz awersję do ryzyka lub ograniczone środki i nie chcesz ich głupio stracić - gdyby było inaczej, nie potrzebował(a)byś tego tekstu. Jednocześnie zastanawiasz się, co możesz zrobić z przynajmniej niektórymi odłożonymi pieniędzmi, zanim stracą swoją wartość i zostaną "zjedzone" przez inflację, a w najbliższym czasie raczej nie masz widoków na kupienie np. własnego mieszkania. Dodatkowo, jeszcze nie jesteś pewny(a) tego tematu i trochę obawiasz się wkładać pieniądze w coś, co dzień po dniu będzie przekręcało się z zysku w stratę i mimo że w długim terminie jest duża szansa, że zyskasz, to przy braku doświadczenia nerwy będą napięte jak postronki.

Dlatego uważam, że obligacje Skarbu Państwa pozwalają bezpiecznie zacząć swoją przygodę z pomnażaniem kapitału. Przede wszystkim, nie stracisz na tym, o ile inflacja nie poszybuje nagle w chmury lub nie zerwiesz inwestycji za wcześnie. Dodatkowo, nie jest wymagane do tego zakładanie konta maklerskiego - wystarczy konto w PKO BP lub Pekao S.A. Nie musisz też decydować się na długi okres - oczywiście, jeśli jesteś młody/młoda to warto wybrać 10-letnie obligacje EDO zyskujące na procencie składanym lub krótsze, ale stałoprocentowe 3-letnie TOSy (też mające w sobie procent składany). Ale równie dobrze możesz wybrać 1-roczne RORy, które co miesiąc będą zwracały Ci małe, ale jednak odsetki, a po 12 miesiącach odzyskasz wkład z powrotem.

Takie spokojne cykliczne oszczędzanie ma tę zaletę, że stosunkowo niewielkim kosztem (100 zł lub kilka setek co miesiąc) powoli budujesz sobie poduszkę finansową, która na początku nie robi wrażenia (umówmy się - obligacje nie sprawią, że będziesz milionerem), ale gdy wejdzie Ci to w nawyk, to ta pula zaczyna rosnąć, a Ty czujesz, że robisz coś odpowiedzialnego i ważnego. A z czasem możesz nabrać ochoty (oraz odwagi), aby spróbować z innymi rodzajami aktywów.

A czy można zacząć od akcji? Oczywiście i to czasami nawet za mniej niż 100 zł (o ile dana akcja jest tania). Natomiast nie ukrywam, że na początku zdecydowanie nie rekomendowałbym inwestowania w pojedyncze spółki, chyba że jesteście absolutnie pewni tego, co robicie - to jest po prostu ryzyko, które nie musi się opłacić, a wymaga solidnej analizy, którą - nie oszukujmy się - trudno przeprowadzić na początku. Wiadomo, że są przedsiębiorstwa, które można określić “pewniaczkami", ale nawet one potrafią płatać psikusy i przyprawić o szybsze bicie serca osobę mniej doświadczoną. O wiele bezpieczniejszym wyborem jest odpowiedni ETF, jak np. ten na cały świat. Niezależnie od wyboru (akcji lub ETF-ów), będziesz potrzebować konta w domie maklerskim. Miej tylko świadomość, że tak, jak w przypadku obligacji obserwowany zysk będzie cały czas rósł, o tyle w przypadku walorów akcyjnych będzie on się poruszał falą - górą i dołem. Tak, pewnie czasami zobaczysz stratę na swoim koncie.

I tutaj chciałem zaznaczyć bardzo ważną rzecz. Młodzi początkujący wchodzący w świat inwestowania często słyszą, że skoro są młodzi, to powinni bardziej ryzykować, gdyż mają mały kapitał, więc strata wszystkiego nie będzie tak bolała, a można zyskać więcej na późniejsze podboje rynku. Są też modele typu 80-20, 60-40 itd., które podają procentowe proporcje akcji do obligacji i sugerują, że im ktoś jest młodszy, tym bardziej powinien iść w kierunku 80-20 (80% akcje, 20% obligacje). Nie chcę jednoznacznie zaprzeczać tym poradom, ale apeluję - miej swój rozsądek i dobierz takie aktywa, abyś czuł się komfortowo z ulokowanymi pieniędzmi. Jeśli masz trudną sytuację finansową lub wyjątkowo dużą awersję do ryzyka, to wcale nie musisz ładować się w akcje tylko dlatego, że tak powiedział youtuber i dobrze mu patrzy z oczu, a on się chwali nowym mercedesem. Nie musisz też wcale wrzucać większości swoich pieniędzy w aktywa - odpowiedz sobie na pytanie, ile pieniędzy potrzebujesz widzieć na koncie na co dzień, aby czuć się bezpiecznie z zakupami, opłaceniem rachunków, niespodziewanych większych wydatków itd. Stwórz swoją poduszkę finansową (częściowo w formie obligacji), która będzie Twoim zabezpieczeniem. Nie musisz od razu ruszać z tysiącami i kupować walory o potencjalnie wyższych stopach zwrotu. Nie o to chodzi w tej “zabawie", aby na starcie doznać porażki i dołączyć do osób, którzy odradzają giełdę, bo solidnie na niej stracili. O czym zresztą jeszcze będę pisał w dalszej części tekstu.

Z drugiej strony mamy pytanie - ile możesz odłożyć miesięcznie, aby zainwestować. W tytule rozdziału podałem 100 zł, ale to tylko przykład, gdyż często jest to 500-1000 zł lub więcej. Ale każdy ma swoją specyficzną sytuację - młody człowiek może nie wysupłać więcej niż stówy, a osoby w wyjątkowo trudnej sytuacji żyją od pierwszego do pierwszego. Dlatego w pierwszej kolejności warto uczciwie przejrzeć swoje wydatki domowe i zobaczyć, czy naprawdę wszystkie są uzasadnione. Widuję wokół siebie osoby, które wcale nie mają malutkich przychodów, ale ciągle sprawiają wrażenie, że brakuje im pieniędzy (po czym narzekają, że nowo kupione meble są brzydkie, a na zagranicznych wakacjach za mocno świeciło Słońce). Warto zastanowić się nad uszczelnieniem wydatków, być może ograniczyć przyjemności i znaleźć te zaskórniaki (nawet nie co miesiąc), które można przeznaczyć na coś, co da zysk za pewien czas. Pomijam tutaj sytuacje naprawdę trudne (choroby wymagające drogich lekarstw itd.) i szczerze współczuję. Natomiast w “standardowych" przypadkach większa dyscyplina dotycząca swojego budżetu pozwoli nie tylko zacząć oszczędzać, ale też odzyskać kontrolę nad swoim życiem i poczuć się bardziej niezależnym. I nie chodzi tutaj o skąpstwo oraz zaciskanie pasa, ale np. jeden abonament miesięcznie mniej, jeden koncert mniej, imprezy z mniejszą pompą itd.

A czy opłaca się startować ze stówą na takie wydatki? Jasne - opłaca się w ogóle startować z jakąkolwiek kwotą pieniędzy. Zwłaszcza, że dopłacając systematycznie, po pewnym czasie zauważycie, że faktycznie to wszystko zaczyna się kręcić, a pewnie z czasem zwiększycie nakłady. I Wasze wcielenie za 10-15 lat podziękuje Wam za ten ruch. Tak, jak już wspomniałem - jako 35-latek wściekam się na 25-letniego Kubę, że bardziej nie zainteresował się tematem.

A co z podatkami?

Pośrednio już o tym wspomniałem, ale warto zrobić to jeszcze raz, gdyż to temat, który przynajmniej mnie blokował przez długi czas, dopóki ktoś mi tego porządnie nie wytłumaczył. Bałem się, że nie będę wiedział, jak to formalnie załatwić i wyląduję w więzieniu, a wiadomo, co tam robią z takimi przystojnymi chłopakami, jak ja.

Tymczasem nie jest tak źle, a dodatkowo z czasem procedury zostały uproszczone. To, co opisuję poniżej, jest aktualne na stan 10 lipca 2025 r.

Przede wszystkim warto wiedzieć, że podatek z inwestycji lub oszczędzania nie zawsze wymaga jakichkolwiek dalszych działań. Gdy dostajemy odsetki z lokaty, konta oszczędnościowego lub obligacji skarbowych, to temat dodatkowego PITu (ważne - dodatkowego, o czym zaraz) w ogóle nas nie interesuje, mimo że jest nam automatycznie potrącane 19%. Sytuacja zmienia się w momencie, kiedy sprzedamy akcje, ETF-y lub udziały w funduszu inwestycyjnym - podatek nadal wynosi 19%, ale już powstaje obowiązek wypełnienia dodatkowego PITu i samodzielnego uiszczenia opłaty.

Ważne jest tutaj sformułowanie "sprzedamy" lub w jakiś sposób pozbędziemy się naszych papierów wartościowych. Nie musimy bowiem przejmować się PITem w latach, kiedy tylko kupujemy lub po prostu trzymamy dane aktywa. Dopiero sprzedaż (choćby częściowa) powoduje, że za rok, w którym to zrobiliśmy, musimy rozliczyć PIT-38. Wówczas też dopiero płacimy podatek - jeśli sprzedaliśmy akcje w 2025 roku, to rozliczenie czeka nas w 2026 roku, do 30 kwietnia. Ważne jest to, że nie musi być to wcale sprzedaż z zyskiem - jeśli straciliśmy na transakcji, to nadal mamy obowiązek wypełnienia formularza PIT-38, choć niczego nie zapłacimy, gdyż nie zarobiliśmy.

Wspomniałem już o tym, że podatek od zysków wynosi 19%. Formalnie są to dwa różne podatki (z czego jeden jest tym słynnym "podatkiem Belki"), ale to będzie lepiej wytłumaczone w materiałach, które zaraz podlinkuję. Warto też wyjaśnić, dlaczego piszę o PIT-38 - to jest inny formularz niż PIT-37, który większość z nas składa co roku. Nic się nie zmienia w sprawie PIT-37 - ten nadal nas obowiązuje, a PIT-38 jest dodatkowym papierkiem, który trzeba wypełnić, jeśli mieliśmy zysk/stratę z naszych inwestycji w roku poprzedzającym i pociąga za sobą osobną wpłatę do Urzędu Skarbowego, niezależną od niedopłaty/nadpłaty z PIT-37.

Czy jest to trudne? To zależy. Właśnie tutaj bardzo przydaje się wybranie polskiego domu maklerskiego (tzn. podlegającego regulacjom Komisji Nadzoru Finansowego (KNF)), gdyż tego typu instytucje bardzo nam pomogą, wysyłając formularz PIT-8C - podobnie, jak to się dzieje z PIT-11 i naszym miejscem pracy. I to wszystko też dzieje się w znanym wszystkim serwisie podatki.gov.pl.

Niestety, nie zawsze jest tak łatwo - ciut więcej gimnastyki i potrzeby zrozumienia może być z dywidendami, ale też sytuacją, kiedy korzystamy z zagranicznego brokera. Jednak te i dodatkowe porady w szczegółach znajdziecie w dwóch wspaniałych materiałach:

Ale nie wiem, czy wiecie, że istnieje też możliwość uniknięcia zarówno podatku, jak i wypełniania formularzy. Co by nie mówić o polskim Państwie, to potrafi od czasu do czasu przygotować różne programy, które brzmią skomplikowanie, ale ułatwiają obywatelom życie. Takimi są m.in. Indywidualne Konto Emerytalne (IKE) oraz Indywidualne Konto Zabezpieczenia Emerytalnego (IKZE), które pozwalają na redukcję lub wręcz zignorowanie podatku od zysków, o ile zostaną spełnione różne wymogi. Jak same nazwy mówią, są one związane z oszczędzaniem na emeryturę - to dobre rozwiązanie dla osób, które chcą zabezpieczać pieniądze z myślą o tzw. jesieni życia (zwłaszcza, że przy obecnej zapaści demograficznej na państwową emeryturę liczą głównie najwięksi optymiści). Więcej szczegółów możecie poczytać w wielu miejscach w sieci, jak np. w tym artykule.

Na koniec tej sekcji chciałbym nawiązać jeszcze do jednej rzeczy - czy warto bać się podatku? Jeśli nie chcemy płacić podatku (a nie korzystamy z IKE lub innych form parasolowych), to oznacza, że nie możemy mieć zysku. A czy na pewno nie chcemy mieć zysku? No właśnie - boimy się płacić większą “dolę" Skarbowi Państwa, ale z drugiej strony oznacza to, że sami mamy więcej środków, które możemy wypłacić lub zainwestować. Jednocześnie warto pamiętać, że na koniec roku sumujemy nasze zyski i straty z inwestycji - może być tak, że nawet mając bardzo duży sukces na jednej inwestycji, nasz podatek może być mniejszy, jeśli w kilku innych inwestycjach ponieśliśmy straty. Jeśli na sprzedaży A zyskaliśmy 100 zł, a na sprzedaży B straciliśmy 40 zł, to podatek płacimy od 60 zł.

Na co uważać i jakie są mity?

Poza podatkami, oszczędzanie, a zwłaszcza inwestowanie może niektórym kojarzyć się ze złożonymi kwestiami finansowymi, nie do ogarnięcia dla zwykłych szaraczków, co może wzniecać poczucie oszukania nas lub przynajmniej wpłynięcia w niekoniecznie dobrej wierze lub przez niesprawdzone osoby. Nie da się ukryć - tam, gdzie pojawiają się pieniądze, pojawią się różne pokusy do robienia przekrętów i muszę przyznać, że, niestety, można się na nie natknąć także w polskim Internecie. Ale nie tylko oszustwa mogą zniechęcać - także niektóre mity lub stwierdzenia okupujące nasze umysły dotyczące inwestowania mogą sprawiać, że będziemy patrzeć na operacje finansowe nie jak na szansę, ale jak na zaplątany labirynt, w którym nie znajdziemy wyjścia. A dodatkowo na to wszystko przychodzą rady ekspertów, którzy może i ekspertami są, ale nie zawsze rozumieją stan wiedzy osoby początkującej lub takiej, która po prostu chce dorobić, ale nie być inwestorem na pełen etat. Wyjaśnijmy sobie zatem kilka rzeczy, które - mam nadzieję - pozwolą Wam się uspokoić lub zrozumieć specyfikę pewnych sytuacji.

Nie kupisz akcji spółek na "niesamowitych okazjach" w Internecie

Jeśli widzisz gdzieś reklamę internetową, że “tutaj możesz kupić obligacje lub akcje firmy X taniej niż zwykle i jest to nieprawdopodobna wręcz okazja, po której zyskasz 20% w ciągu roku" (albo i lepiej - miesiąca), to możesz spokojnie założyć, że to oszustwo. Także polskie spółki padają ofiarą tego typu praktyk - przykładem jest PKN Orlen, który nawet ma specjalną stronę z ostrzeżeniem.

To nie jest tak, że nie można dostać czy kupić akcji w inny sposób niż przez dom maklerski. Ale na pewno nie dzieje się to przez reklamę internetową pojawiającą się nam losowo na różnych stronach, w dodatku prowadzącą do podejrzanego linku (którego nie powinniśmy nawet poznać, ponieważ nie powinniśmy w to kliknąć). A dodatkowo, oferty akcji nie mogą zawierać gwarancji czy przynajmniej zachęty, że zyskasz X% procent. Jedyne miejsce, gdzie możesz normalnie kupić akcje np. Orlenu to giełda, do której możesz mieć dostęp za pomocą domu maklerskiego. I nikt nie reklamuje akcji w sposób "już dzisiaj poniżej 60 zł" albo "nie przegap okazji, kliknij już teraz - 3 akcje w cenie 2".

Także, jeśli zobaczymy gdzieś reklamy zachęcające do inwestowania na "lepszych" warunkach (i nie jest to reklama faktycznie uznanego brokera - jeśli czytacie ten tekst w 2025 roku, to na pewno kojarzycie choćby Zlatana Ibrahimovica reklamującego znany i uznany dom maklerski, co jest w pełni normalne) lub które są promowane przez znane twarze (najczęściej nie mających tego świadomości i potem składających pozwy w sądzie), to praktycznie na pewno jest to coś podejrzanego.

"Gdy rośnie, to kupuję, a gdy spada, to panikuję i sprzedaję"

To bardzo częsty błąd, który łączy się z psychologią człowieka i wymaga odwrócenia sposobu myślenia. W tym miejscu pozdrawiam i dziękuję pani Agnieszce, mojej doradczyni z banku, która tłumacząc mi nieco inne zagadnienia, uświadomiła mi parę dodatkowych rzeczy jeszcze zanim w ogóle pomyślałem o inwestowaniu i dzięki temu od początku byłem trochę spokojniejszy.

Lojalnie uprzedzam - w tym punkcie zahaczymy o nieco trudniejszą rzecz, ale ważną i trzeba o tym wspomnieć. Być może robię to za wcześnie, ale niektórym może to otworzyć oczy na pewne sprawy. Między innymi na to, dlaczego tacy typowi inwestorzy kupują więcej w trakcie paniki.

Łatwo ulec pokusie kupowania czegoś, co rośnie, a rośnie, bo inni to kupują. Można pomyśleć, że skoro inni to chcą mieć, to jest to wartościowe i jest duży popyt. Poniekąd jest to racja, tylko problem w tym, że gdy coś już rośnie, to bardzo często rynek właśnie się nasyca i przez to my kupujemy to po zawyżonej cenie. Mówiąc wprost - wydajemy za dużo pieniędzy. Idąc w drugą stronę - jeśli coś spada (a zwykle dzieje się to gwałtowniej niż wzrosty), to możemy ulec panice i sprzedaży w dołku. Co z kolei oznacza, że dostaniemy mało pieniędzy za nasze walory. Jednak tak działa psychologia ludzka i jest to naturalne. Ale, jak przed każdą operacją giełdową, trzeba się najpierw zastanowić. Bo to nie oznacza, że jeśli coś jest drogie, to nie należy kupować, a jeśli tanie, to nie należy sprzedawać.

W świecie inwestowania istnieje parę fajnych powiedzeń znanych osób i wiele z nich pasuje do tematu tego rozdziału. Są to np.:

  • "Bój się, gdy inni są chciwi, a bądź chciwy, gdy inni się boją" (Warren Buffett)
  • "Kupuj, gdy na ulicach leje się krew" (Baron Rotshchild)
  • "Okazje biznesowe są jak autobusy, zawsze przyjedzie następny" (Richard Branson)
  • "Nigdy nie trać pieniędzy" (Charlie Munger)

I wbrew pozorom nie są to maksymy zarezerwowane dla aktywnych inwestorów, którzy dzień w dzień "siedzą" na rynku. Z tych powiedzeń także my, spokojni i nudni amatorzy, możemy wyciągnąć dla siebie ważną lekcję. Czysto teoretycznie powinniśmy kupować w minimach (dołkach), gdyż wtedy jest najtaniej i za naszą kwotę kupimy więcej akcji lub jednostek danego aktywa. I odwrotnie - sprzedawać powinniśmy w maksimach (górkach), bo wtedy dostaniemy najwięcej pieniędzy. Ale oczywiście, najłatwiej powiedzieć - nigdy nie wiemy, kiedy wystąpią dołki czy górki ("czy to już?"), a ponadto nie zawsze opłaca się czekać i warto kupić nawet przy nieco niekorzystnych warunkach. Lub odwrotnie - czasem wręcz należy "przeczekać" i nie martwić się, że okazja nam przeszła koło nosa. Oczywiście, przy tym wszystkim trzeba uważać na rzeczywiste bankructwa spółek lub ich pogarszającą się sytuację i dlatego, gdy widzimy spore spadki, warto znaleźć informacje, z czego prawdopodobnie to wynika (często zwyczajnie z paniki i jest to krótkotrwałe). Rzeczywiste zniknięcia z rynku są naprawdę rzadkie, szczególnie w przypadku bardzo dużych firm z już ugruntowaną pozycją.

Jednak jeszcze inną kwestią jest to, że większość takich niedzielnych inwestorów, jak my, nie powinna się zanadto przejmować dynamiką wykresu. Zamiast tego powinniśmy skupiać się na dobieraniu właściwych, perspektywicznych aktywów i nudnym dokładaniu pieniędzy, licząc po prostu na wzrost rynku w długim terminie. Jest to nudne, mało satysfakcjonujące na krótką metę, ale tak właśnie powinno wyglądać inwestowanie kogoś, kto nie chce poświęcić temu całego wolnego czasu.

"Mam za mało pieniędzy, aby inwestować"

Już zdążyłem wspomnieć o tym, że można zacząć mając 100 zł, a nawet mniej, choć wiadomo, że dużo lepiej byłoby odkładać nawet 1000-2000 zł miesięcznie - porównanie, jak to się przekłada, znajdziecie w tej prezentacji. Inwestowanie to też dobra okazja, aby trochę zrewidować swoje domowe wydatki i zobaczyć, czy uda nam się zatrzymać więcej środków, aby mogły dla nas pracować.

Natomiast trzeba pamiętać, że im mniejszy wkład możemy zapewnić, tym mniej będą wynosić nasze zyski - nie możemy oczekiwać, iż z tysiąca złotych zrobimy milion, gdyż zwyczajnie zabierze to za dużo czasu. Dobre informacje są natomiast dwie - zawsze można dopłacać do naszej "kupki" (i warto sobie wyrobić taki nawyk), a ponadto nawet małe kwoty “coś" nam dadzą.

A gdy myślicie, że za 100 zł (nawet miesięcznie) efekty będą takie, że szkoda zachodu, to pomyślcie o tym, że każda taka stówa po 10 latach inwestowania w obligację EDO (według dzisiejszego oprocentowania - ono pewnie trochę się zmniejszy), nawet przy niskiej inflacji (2%) da Wam dodatkowe 41 zł (policzone tym kalkulatorem). Magia procentu składanego za każdą obligację da 41% zysku na czysto po tym czasie. Nadal mało? A przecież nie kupicie jednej obligacji - 10 sztuk da Wam 410 zł zysku. I to z pieniędzy, których prawdopodobnie i tak byście nie wykorzystali przez te 10 lat. A jakby jednak były potrzebne, to można je wcześniej wyciągnąć.

"Będę bogaty i rzucę pracę!"

Będę brutalnie szczery - jeśli miał(a)byś do tego zadatki, to nie potrzebowałbyś tego tekstu. Oczywiście, nic nie stoi na przeszkodzie, abyś rozwinął(-ęła) się w tym kierunku i szczerze Ci życzę ogromnych sukcesów. Ale osób żyjących "z procentów" jest naprawdę mało, gdyż wymaga to zarówno ogromnego kapitału, jak i doskonałych wyborów wynikających z głębokiej analizy i dużej dozy szczęścia. A później umiejętnego zarządzania swoimi aktywami, aby jednocześnie nie tracić “pędu", ale też coś z tego życia mieć.

Zdecydowanie trzeba przyjąć założenie, w którym oszczędzanie lub inwestowanie stanie się po prostu rutyną, dzięki której człowiek ma poczucie zabezpieczenia i dodatkowych dochodów, jednak stanowiących miły bonus w stosunku do właściwej pensji wynikającej z "normalnej" pracy. Natomiast nie jest wykluczone, że takie systematyczne inwestowanie przez całe życie sprawi, że przed emeryturą uda Wam się osiągnąć FIRE (ang. Financial Independence Retire Early), a więc stan, w którym mamy tyle pieniędzy, że spokojnie wystarczy nam do końca życia. To zresztą bardzo szeroki temat, gdyż każdy z nas ma inne wyobrażenie "wystarczających pieniędzy" - dlatego warto przemyśleć swój cel inwestowania i tzw. kamienie milowe, do których dążymy. Niekoniecznie musi być to FIRE, ale np. perspektywa posiadania pieniędzy na otwarcie biznesu za 15 lat lub przygotowania finansowej poduszki ratunkowej. Oj tak, oszczędzanie i inwestowanie zdecydowanie uczą planowania. Musimy wiedzieć, do czego tak naprawdę dążymy.

Przy okazji, jeszcze jedna rzecz - nawet, jeśli zostaniesz bogaty (czego Ci życzę), to nie stanie się to w krótkim czasie. Między bajki można włożyć plany o tym, że w rok urośnie nam fortuna. Inwestowanie i oszczędzanie to maraton, a nie sprint.

"Widziałem doskonałą strategię, pewniaczek!"

Na giełdzie nie ma "pewniaczków" i nie ma idealnych strategii. Owszem, są takie, które w ogólności są ciekawe i potrafią się ustawić, ale nie ma czegoś takiego, jak niezawodny sposób na osiąganie samych wzrostów. Gdyby tak było, to wszyscy by się do tego stosowali. Dlatego nie należy ślepo podążać za trendami, ale uzbroić się w pokorę, cierpliwość i ustalić swoją, komfortową dla siebie metodę oraz układ portfela. Znowu - nie jest to ciekawe i ekscytujące, ale pozwala ograniczyć straty. A ograniczanie strat jest ważniejsze niż staranie się o bardzo duży procent zysku. Dlatego np. moja poduszka finansowa (pieniądze, które zachowuję w bezpiecznych aktywach na ciężkie czasy) ma za zadanie przebijać inflację i wyłącznie to - ona nie służy do tego, aby poczuć się bogatym, tylko zabezpieczeniu przyszłości w minimalnym, ale stabilnym stopniu. Ale nawet mój "normalny" portfel inwestycyjny nie stara się o kilkudziesięcioprocentowy zysk za wszelką cenę, tylko nadal dba o bezpieczeństwo pieniędzy (co nie znaczy, że nie liczę się, ze stratami).

Dlatego warto też dbać o dywersyfikację i nauczyć się (z czym ciągle sam mam problem) nie ulegać emocjom. Lepiej nie kupić "pewniaczka" trzy razy niż raz popełnić błąd. Lepiej trzymać się jednej strategii i analizować ją w dłuższym odcinku czasu niż co chwilę zmieniać podejście.

"Nie mam na to czasu, musiałbym się na tym znać"

Tutaj trochę prawdy jest, ale tylko trochę. Rzeczywiście, nie powinno się rozpoczynać swojej przygody zupełnie bez żadnej wiedzy (po to zresztą jest ten artykuł) i bez przygotowania, gdyż łatwo wówczas ulec złym poradom lub po prostu stać się ofiarą swojej nieświadomości, jak niewiele wiemy. To oznacza, że trzeba się nieco dokształcić, ale też nie mówmy, że wymaga to np. jakiegoś kursu, roku czytania książek czy wręcz certyfikatu.

Aby zrozumieć i zacząć inwestować np. w obligacje, nie trzeba nawet tygodni - osobiście wytłumaczyłem każdemu chętnemu znajomemu tę koncepcję w 20 minut. Aby zacząć z ETF-ami, to owszem, warto trochę poczytać i wybrać, ale jeśli przyjmiemy nudne założenie, że inwestujemy np. w rynki rozwinięte (które zwykle rosną i są stabilne), to też próg wejścia trochę spada. Mówiąc wprost - aby inwestować pasywnie, a więc nie analizując za bardzo tego, co się dzieje na rynku, nie potrzeba dużej wiedzy. Warto jednak przyzwyczaić się do interesowania się tym, co się dzieje w polityce i ogólnie na świecie - możemy się zżymać, że nas to nie dotyczy, że nie chcemy widzieć tych zakazanych twarzy, czytać o kolejnych kryzysach itd., ale jednak oszczędzanie uczy wielu rzeczy, w tym pewnej ciekawości o tym, co się dzieje na naszym globie. Jedna czy druga ustawa to nie tylko teatr polityczny, ale też coś, co istotnie może wpłynąć na nasze dochody, nawet za pomocą długiej sekwencji klocków domina.

Jeśli jednak chciał(a)byś inwestować aktywnie, a więc rzeczywiście przerzucać pieniądze tak, aby ciągle jak najwydajniej pracowały, szukać perspektywicznych spółek itd., to próg wejścia jest już wyższy i takie działanie wymaga więcej analizowania, a także poświęconego czasu. Dlatego w przypadku niedzielnego inwestora takie podejście to raczej ciekawostka niż główna droga.

Osobną kwestią jest znajomość teorii finansów i ekonomii. Ona też nie jest potrzebna poza absolutnymi podstawami, typu inflacja, podatek, zysk itd. Natomiast jest prawdopodobne, że z czasem sam zaczniesz doczytywać lub śledzić, choćby pobieżnie, newsy. Wówczas mimochodem poznasz pewne sformułowania i elementy teorii, które mogą Ci pomóc w podejmowaniu decyzji. Natomiast absolutnie nie jest wymagana wiedza rachunkowa, księgowa, poznawanie masy skrótów typu FCF, CARG itd. Nawet jeśli doszłoby do analizy sprawozdań finansowych spółki, to zazwyczaj w formie zautomatyzowanej, przyjaźniejszej dla laika. Chyba że będziesz rzeczywiście chciał(a) bardziej aktywizować się na rynku, ale to inna kategoria.

"Giełda to kasyno"

Słyszałem to zdanie już kilka razy i sugeruje ono, że rynek zachowuje się w sposób totalnie nieprzewidywalny i wszystkie zyski oraz straty zachodzą tak naprawdę losowo. Nawet ostatnio na Mastodonie miałem o tym dyskusję (pozdrawiam rozmówców), którzy starali się mnie przekonać, że inwestowanie na giełdzie to właściwie hazard. Dla zachowania obiektywizmu, aby każdy mógł wyciągnąć wnioski samodzielnie, poniżej zamieszczam przywołane przez nich artykuły:

Żeby było jasne - tak, na giełdzie nie wszystkie ruchy są logiczne i nie wszystko można przewidzieć. Czasem dzieją się rzeczy niespodziewane (katastrofy, problemy, działania konkurencji itd.), a inwestorzy nie reagują wyłącznie analizując wszystko na spokojnie, tylko wyprzedając lub gwałtownie kupując akcje, bo ulegli emocjom lub owczemu pędowi. Jest to bardziej zauważalne w krótkim terminie lub u osób, które ekscytują się i poważnie biorą pod uwagę małe zmiany. Wtedy tak - to będzie przypominało kasyno, o czym czasem mówią mi koledzy w biurze słysząc o moich utyskiwaniach na osiągane wyniki (kolegów pozdrawiam i uspokajam, że to, co często piszę i mówię, robię dla żartów. Jak to młodzież mówi - “dla contentu"). To jest też bliższe popularnemu stwierdzeniu “gra na giełdzie".

Giełda w dłuższym terminie zdecydowanie mniej przypomina kasyno, a właśnie o takim inwestowaniu powinniśmy myśleć - rynek ma naturalną tendencję do wzrostu, gdyż za tym wszystkim stoją firmy, które się rozwijają, gdzie zarządy i pracownicy się starają i doprowadzają do zysków, gdyż to jest po prostu w ich interesie. Nie jest to zupełnie losowe - to nie jest tak, że Apple nagle powie "teraz dla jaj ogłosimy naszą porażkę sprzedażową, aby były emocje na giełdzie i wystąpiła panika". Chwilowe spadki są normalne (są to tzw. korekty) i wynikają z różnych, czasem bardzo logicznych rzeczy (np. gorsze wyniki w danym kwartale), ale lepiej spojrzeć na wykresy kilkuletnie i samemu ocenić, jak wygląda trend w takiej perspektywie. Zresztą, to kolejny argument za inwestowaniem w ogólne ETF-y, jeśli nie czujemy się pewni w analizie poszczególnych spółek i sektorów - spójrzcie choćby na ETF MSCI ACWI, który jest funduszem "patrzącym" na cały świat (głównie USA). Oczywiście, znajdziecie miejsca, gdzie nastąpił dołek, nawet trochę głębszy, ale ogólna tendencja na przestrzeni wielu lat jest i będzie wzrostowa. A z taką myślą powinniśmy inwestować.

Warto też dorzucić jeszcze jeden wątek - boty. Nie jest tajemnicą, że przynajmniej za część transakcji na giełdzie odpowiadają wyspecjalizowane algorytmy (teraz już korzystające nawet ze sztucznej inteligencji), które z oczywistych względów będą szybsze od człowieka. Jaki to procent rynku? W 2018 roku było to ok. 60 procent, a można spokojnie założyć, że obecnie jest to już wyższa wartość.

"Wszyscy, których znam, stracili na giełdzie pieniądze"

Powiem więcej - ja też znam takie osoby. To był zresztą powód stojący za tym, dlaczego bardzo unikałem inwestowania przez tyle lat. Zresztą, nie tylko ja - starsi koledzy z firmy, znający mój dość gwałtowny i emocjonalny charakter, mówili, że jest większe prawdopodobieństwo, iż stracę niż zyskam. Z drugiej strony, widziałem też dużo młodszych kolegów ode mnie, którzy systematycznie wkładali pieniądze w różne aktywa i w ten sposób powoli zabezpieczają się na "stare lata". To zresztą było zapalnikiem, przez który i ja zacząłem interesować się tematem oraz patrzeć na zjadane przez inflację oszczędności mojego życia w nieco inny sposób. Oficjalnie. Bo nieoficjalnie, to po prostu zdenerwowałem się, że młodzi znowu mnie w czymś wyprzedzili ;)

Dlaczego tak wiele osób ma złe doświadczenia z giełdą i zawsze zna kogoś, kto zbankrutował? Z kilku powodów, ale jednym z "najefektowniejszych" jest taki, że jeśli ktoś dużo stracił, to wiele się o tym mówi w takim małym środowisku jak paczka znajomych czy rodzina. Z kolei, jeśli ktoś zarabia, to zwykle siedzi spokojnie, zgodnie z zasadą "pieniądze lubią ciszę". Ja bym jeszcze dodał: "i cierpliwość".

Tak, jak już wspomniałem, kiedyś inwestowanie było trudniejsze - nie było tylu (darmowych!) materiałów edukacyjnych, aplikacje brokerskie nie były tak przyjazne, nie było ETF-ów i ogólnie dostęp do pomocy był trudniejszy. Co za tym idzie - ludzie inwestowali nieprzygotowani, bez wiedzy, myśląc, że prawidłowo robi się to poprzez ciągłe obserwowanie wykresów i reagowanie natychmiast, bo tak widzieli w filmach. Możliwe, że jestem teraz okrutny i przykry, ale bez odpowiedniego zrozumienia i analiz, ludzie nie do końca rozumieli, co robią. Teraz jest dużo łatwiej, a młodsi, mając lepsze narzędzia, są odważniejsi, ale jednocześnie rozważniejsi. Oczywiście, bardzo to teraz spłycam, gdyż powody bankructw są różne i niewykluczone, że wśród Waszych znajomych są tacy, którzy stracili majątki inwestując rozsądnie, w przemyślany sposób, ale zwyczajnie stało się coś, co ich pogrążyło i nie wytrzymali tego psychicznie.

Zresztą, to nie jest tak, że teraz jest bezpiecznie - nadal można stracić dużą część kapitału i choćby dlatego należy dobrze przemyśleć i spokojnie podejść do sumy pieniędzy, którą chcemy wprowadzić do inwestowania. W żadnym wypadku nie powinien być to majątek naszego życia i warto najpierw odłożyć odpowiednią sumę pieniędzy lub zacząć oszczędzać poprzez bardziej bezpieczne formy (konta oszczędnościowe, lokaty, obligacje). Jeśli po tym wszystkim okaże się, że na giełdę nie wystarczy pieniędzy lub będą to małe kwoty - trudno, ale lepsze to niż utrata osobistej płynności.

Trzeba też przyznać, że teraz takim aktywem, który bardzo kusi i może czasem zaboleć, są kryptowaluty, szczególnie te "alternatywne" (altcoiny). Dlatego ponawiam apel - ostrożność i myślenie “co jeśli…" przede wszystkim. Jeśli ktoś wrzuca 100 tys. złotych w tak ryzykowne obszary, traci 80% i wycofuje się z rynku ogłaszając wszem i wobec, że ta giełda to jakiś szwindel, to powiedzmy, że nie jest dla mnie wiarygodnym źródłem opinii. Zawsze trzeba przeanalizować, co się nie udało i z jakiego powodu straciliśmy pieniądze (lub zyskaliśmy, aby powtarzać to w przyszłości).

Natomiast tak - sama giełda nie jest dla wszystkich i jeśli należymy do tej drugiej grupy, to nie czujmy się z tego powodu źle, pamiętając jednocześnie o istnieniu bezpieczniejszych form.

"Trzeba słuchać analityków, czytać prognozy, a analiza techniczna jest wspaniała"

Tutaj specjalnie pomieszałem kilka wątków, ale myślę, że można je rozwinąć w formie jednego dużego punktu. To nie jest tak, że inwestorzy są zostawieni bez opieki - różne firmy, banki i domy maklerskie mają swoich analityków, którzy w profesjonalny sposób starają się odpowiadać na pytania o trendy, co ma przed sobą przyszłość (a co nie), a nawet, jaką cenę akcji prognozują w danym terminie, co ma potem przełożenie na różne statystyki analityczne, jak np. Price Target oraz Upside. Z drugiej strony, są osoby, które wprost twierdzą, że nie warto czytać tych analiz, ponieważ przyszłości nie da się przewidzieć i lepiej robić to samodzielnie, a parametry typu Price Target są wróżeniem z fusów. Szczególnie w polskich warunkach, gdzie rynek jest stosunkowo mały i podatny na wahania.

Zacznijmy od końca - rzeczywiście, to nie jest tak, że wyznaczone Price Targety (a więc spodziewane ceny docelowe akcji danej spółki w danym okresie, zwykle roku) sprawdzają się co do joty i należy je traktować jak wyrocznię. One są wyłącznie sugestiami spodziewanej wartości spółki na podstawie analizy prognoz, konkurencji, rynku i innych czynników, a nie dość, że nawet najlepszy analityk nie przewidzi wszystkiego, co zdarzy się na rynku, to jeszcze sami inwestujący mogą sobie robić "psikusy", sprzedając akcje w momencie dotarcia do ceny docelowej lub nerwowo reagując na wzmiankę o niespodziewanych sytuacjach. W bardzo niestabilnych środowiskach nawet z pozoru głupie wydarzenia mogą mieć znaczenie (np. cena akcji dystrybutora truskawek może chwilowo wzrosnąć po tym, jak Iga Świątek na Wimbledonie wspomni, że lubi makaron z truskawkami).

Z drugiej strony, analitycy są analitykami nie bez powodu - pracują w obrębie rynku, zajmują się nim na co dzień, żyją z tego, mają kontakty i siłą rzeczy wiedzę oraz warunki odpowiednie do tego, aby ocenić możliwości giełdowe danej spółki. Oczywiście, nie znają wszystkich szczegółów (te są w głowach wyłącznie zarządów notowanych firm), ale o ile rzeczywiście na wskazania cenowe można patrzeć z lekkim przymrużeniem oka, tak na sam opis wniosków i analizy można zerknąć, o ile inwestujemy aktywnie i zastanawiamy się nad daną spółką. Być może taki specjalista zwrócił uwagę na coś, o czym w ogóle byśmy nie pomyśleli i co wpłynęłoby na nasze postrzeganie danej inwestycji.

Istnieje jeszcze drugi wątek - niektórzy pełnoetatowi inwestorzy, którzy żyją praktycznie w całości z giełdy i siłą rzeczy interesują się nią "trochę głębiej" niż my, "normalsi", od czasu do czasu piszą o swoich przewidywaniach i ilustrują to parametrami z tzw. analizy technicznej (AT). Jest to metoda analizy, która na warsztat bierze dotychczasowy przebieg ceny akcji i na podstawie różnych metryk ocenia potencjał wzrostu lub spadku w danym terminie. Nie bierze za to pod uwagę czynników ważnych z perspektywy analizy fundamentalnej, która z kolei opiera się o sprawozdania finansowe i analizę rynku. Z tego powodu AT pasuje bardziej do krótkoterminowych prognoz, a jak już sobie wspomnieliśmy, początkujący (i nie tylko) powinni unikać tak krótkiego horyzontu inwestowania i nie przejmować się chwilowymi turbulencjami. Co z tego, że wskaźniki pokazują, iż przez ostatnie 14 okresów były spadki, więc teraz też będą spadki, skoro np. cisza ze strony spółki, która to spowodowała, zaraz zostanie przerwana przez dużą zapowiedź nowych usług i znowu kurs poszybuje w górę.

Żeby było jasne - nie twierdzę, że analizą techniczną nie należy się w ogóle przejmować. Może być ciekawa w stosunkowo krótkich okresach, a zwłaszcza, że jeśli spogląda na nie wiele osób, to mogą być samospełniającą się przepowiednią. Ale jeśli myślimy o inwestowaniu w długim terminie (jak np. robi Warren Buffett), to AT nam nie pomoże - jeśli już samodzielnie analizujemy sytuację, to powinniśmy raczej patrzeć na analizę fundamentalną, bo ona potencjalnie pomoże nam w określeniu, czy coś za 10 lat będzie w lepszym miejscu niż teraz. Techniczne metryki mogą być uzupełnieniem i pewną ciekawostką. A że badanie fundamentów jest trudne, to już inna sprawa.

"Ci wszyscy youtuberzy ciągle mają lepsze wyniki niż światowe indeksy, dlaczego ja nie mogę"

Tutaj działają dwa czynniki. Po pierwsze, patrzymy na osoby, które same siebie określają mianem "inwestorów" i żyją z tego lub materiałów o tym. Chwała im za to, że chce im się edukować ludzi. Natomiast pamiętajmy, że są to ludzie, którzy prawie cały swój czas poświęcają na to zagadnienie i niejedno przeżyli (także spektakularne wpadki). To oczywiste, że mają większe doświadczenie, wiedzę, umiejętności i potrafią więcej znieść, ale też lepiej ocenić sytuację, zwłaszcza, że historia lubi się powtarzać.

Po drugie, ludzie lubią się chwalić dobrymi wynikami. A nie każdy umie się przyznać, że jego ostatnia inwestycja była nietrafiona i stracił - chwała tym, którzy to robią, dając możliwość uczenia się na ich błędach. Dlatego często słyszymy o spektakularnych sukcesach, ale rzadko o porażkach. Wiem, że stoi to w sprzeczności z tym, o czym pisałem przy okazji bankructwie znajomych (gdzie częściej komentuje się negatywne sytuacje jako przestrogę), ale tutaj bardziej mówimy o sferze publicznej, tj. osobach, które wypowiadają się o giełdzie na szerszym forum i które w pewien sposób muszą “zachować twarz", bo inaczej ludzie przestaną im wierzyć.

Osoby, które inwestują amatorsko, wyłącznie po to, aby ochronić swoje pieniądze przed inflacją lub mieć szansę na podreperowanie części domowego budżetu, nie powinny przejmować się takimi wynikami u de facto nieznanych sobie osób. Mało tego - nie powinny przejmować się tym, że w danym roku miały stratę - jeśli zależy nam na długim terminie, to liczy się to, co pojawi się na końcu, a nie teraz. Stopa zwrotu powyżej inflacji będzie satysfakcjonująca. Wynik rzędu 10% - świetny. Wyższe rezultaty - doskonałe, ale przy spokojnym oszczędzaniu lub inwestowaniu będą raczej wypadkową szczęścia.

Pamiętajmy też, że ci wszyscy blogerzy, youtuberzy itd. często mają większość swojego majątku właśnie w akcjach, które faktycznie mogą zapewnić solidne stopy zwroty, wyższe niż obligacje. Oni liczą się z ryzykiem, że dana spółka nie wypali, ciągle szukają nowych perspektyw i żyją tym tematem. Z tego powodu, gdy słyszycie od twórcy internetowego, że młoda osoba powinna inwestować wyłącznie w akcje, bo jest młoda, ma mniej kapitału, więc łatwiej przełknąć stratę, to radziłbym jednak się zastanowić. Ma to sens matematyczny, ale niekoniecznie egzystencjalny. Szczególnie, jeśli nie chcecie żyć rynkiem, a jedynie spokojnie dorobić i do tego wiecie, że nerwowo reagujecie na porażki. Nie ma niczego wstydliwego w spokojnym robieniu "swojego" (np. w pracy programisty) wiedząc, że gdzieś tam, bez naszego aktywnego udziału, rośnie część pieniędzy o kilka procent. Nie każdy musi w pocie czoła opracowywać strategię pozwalającą osiągnąć 40% rocznego zysku, choć wiadomo, że jest to miłe. To trochę tak, jak próbować skoczyć 180 metrów w Willingen kosztem swojego zdrowia, a nawet życia - 140 metrów też wystarczy, aby zająć dobre miejsce w konkursie. Czy więc namawiam do obniżania swoich zysków? Nie - namawiam do ostrożności, szczególnie początkujących.

"Chcę wejść na giełdę, aby poczuć emocje"

Niech Was ręka Boska broni przed szukaniem emocji w ten sposób. Równie dobrze możecie faktycznie iść do kasyna - tam jeszcze szybciej i mocniej poczujecie przypływ adrenaliny. Przy czym zdaję sobie sprawę, że to zdanie, które kiedyś usłyszałem od kolegi, nie miało mieć takiego wydźwięku i było bardziej żartem (a kolegę pozdrawiam, bo cały czas mamy kontakt), ale na wszelki wypadek wolę tutaj się do tego odnieść, zwłaszcza, że wiele osób faktycznie wyobraża sobie inwestowanie jako emocjonowanie się rosnącym lub spadającym kursem akcji.

Wiecie, jak najlepiej zadbać o swoje pieniądze? Nudą. Nie żartuję - inwestowanie powinno być nudne niczym oglądanie schnącej farby na ścianie, o czym mówi między innymi przywoływany już parę razy Marcin Iwuć. Dla znakomitej większości osób to nie powinno być coś, czym muszą codziennie się przejmować. Ba - nie powinni nawet codziennie sprawdzać wyników i nerwowo przeglądać wykresów. Nie powinni też z palcem w telefonie wyczekiwać na okazję wejścia lub wyjścia z danej inwestycji. Krótko mówiąc - powinni tak ustawić swój portfel, aby przede wszystkim mieć tam bezpieczne aktywa, czyli takie, które w dłuższym terminie stabilnie (aczkolwiek nie zawsze szybko) rosną. Oczywiście, to nie oznacza, że w ogóle nie powinniśmy się tym interesować ani unikać giełdy (wręcz przeciwnie), ale opieranie swoich ruchów na tym, co się dzieje danego dnia, to prosta droga do stresu, poczucia porażki i zawalenia innych, często ważniejszych aktywności w swoim życiu.

W tym miejscu serdecznie pozdrawiam moich kolegów z Wildy Software, którzy nie mogą znieść tego, gdy piszę coś w stylu "o, szkoda, że kupiłem to wczoraj, dzisiaj już spadło". Emocjonowanie się tym jak widowiskiem sportowym to jedno i jeszcze mnie nie znudziło, ale podejmowanie decyzji na tej podstawie to druga rzecz. I tutaj ponownie pomogło uprzednie przeczytanie odpowiednich materiałów edukacyjnych - inaczej nie siedziałbym tak spokojnie np. w sytuacji, kiedy po 2 kwietnia 2025 r., czyli ogłoszeniach Donalda Trumpa w sprawie ceł na tzw. "Liberation Day" przez kilka tygodni widziałem czterocyfrowe straty po świeżym zainwestowaniu pieniędzy na przełomie marca i kwietnia. Nie powiem, że moja krew nie buzowała, ale jednocześnie sam siebie uspokajałem, bo wiedziałem, że sytuacja unormuje się po paru miesiącach, a wręcz takie spadki to okazja, aby dołożyć trochę więcej. Ale przyznam, że to wymaga wiedzy lub stalowych nerwów i znowu - nie ma niczego wstydliwego w nieposiadaniu tych przymiotów. Ja po prostu trafiłem na dobrych ludzi podczas swoich początków i jest im za to wdzięczny.

Aplikacje pomagające w oszczędzaniu

Działamy w branży IT, więc nie możemy pominąć tego tematu. Rynki finansowe od dawna wymagają infrastruktury IT i to niezawodnej - już legendarne są opowieści o tym, jak duzi gracze wstawili swoje serwery bliżej Wall Street, aby ich algorytmy wykonujące operacje mogły zareagować o tysięczne sekundy szybciej przed konkurencją. Ale nie o tym tutaj chcę pisać, tylko o oprogramowaniu, które realnie może pomóc śledzić swoje wydatki. Jeśli bowiem włożyliśmy pieniądze w kilka różnych miejsc, a do tego co jakiś czas dokupujemy kolejne jednostki, to siłą rzeczy nie zobaczymy wszystkiego na stronie jednego banku czy brokera, a po jakimś czasie po prostu się pogubimy. Dodatkowo, pewnie chcielibyśmy raz na jakiś czas sprawdzić, jak nam ogólnie idzie i zobaczyć wykresy.

Polscy inwestorzy i oszczędzający mają szczęście mieć dostęp do takigo serwisu jak MyFund, który pozwala śledzić swoje walory, analizować je i robić raporty, a do tego abonament jest śmiesznie tani (od 5 do 20 zł za miesiąc, w zależności od planu). Żeby tego było mało, od czasu do czasu można uzyskać darmowe miesiące na początek. To, co zwróci uwagę wielu osób, to - nie bójmy się tego powiedzieć - niedzisiejszy interfejs. MyFund jest dość nieładny oraz nieintuicyjny i to zarówno na polu aplikacji webowej, jak i mobilnej (tak, są wersje na Androida i iOSa, a do tego widżety na telefon). Natomiast, po pierwsze, pojawiają się pewne zmiany w tym kierunku, gdyż ostatnio liftingowi uległ np. kokpit, który teraz cieszy oko. Po drugie, po początkowym szoku, zauważycie, jak niesamowicie rozległe możliwości ma ten system i jak wiele rodzajów aktywów potrafi obsługiwać. Zawiera sporo rodzajów raportów, wykresów, zestawień, skanerów, a do tego informuje nas o komunikatach ze spółek, które posiadamy i parametrach technicznych instrumentów finansowych. Wierzcie mi, że gdybyście chcieli napisać coś podobnego na swoje potrzeby, to zajęłoby to Wam lata. Backend tej aplikacji to królestwo i choćby z tego powodu warto rozważyć jej używanie przy inwestycjach w różnych miejscach.

Jeśli z kolei jednak chcemy analizować spółki w sposób fundamentalny, to nie musimy koniecznie sprawdzać poszczególnych sprawozdań finansowych - są takie aplikacje jak Scrab, które zawierają dane finansowe firm, pozwalają szukać ich po wyznaczonych parametrach, mają modele scoringowe (czyli ważoną ocenę sensu inwestycji w daną spółkę). To nie jest tak, że tego typu serwisy same nam podpowiedzą, w co inwestować - one po prostu przyspieszają ten proces. I to w tym przypadku za 0 zł - Scrab ma całkiem dużo możliwości w darmowej wersji i jeśli chcemy zorientować się w twardych wynikach danego podmiotu, to skróci nam pracę. Z polskimi spółkami jest różnie - dla większych, jak najbardziej, w tym programowanie można znaleźć dane oraz prognozy, ale tych drugich czasem brakuje dla nieco mniejszych podmiotów. A jeśli chcielibyście zobaczyć, jak ocenić daną spółkę i wykorzystać do tego to oprogramowanie, to polecam długi, ale wartościowy (i zrozumiały dla laika - ja zrozumiałem) materiał od Tomasza Treli, jednego ze współtwórców omawianej aplikacji i jednocześnie doświadczonego zarządzającego funduszami inwestycyjnymi.

Wiele razy wspominałem o ETFach, więc nie można pominąć serwisów, w których możecie poczytać o nich trochę więcej, ale przede wszystkim wyszukać interesujące fundusze i przejrzeć związane z nimi informacje - prowizja, w co inwestują, jaka była stopu zwrota w danym okresie, inwestowane spółki lub instrumenty oraz kapitalizacja (im większa, tym lepsza, bo ETF ma bardziej ugruntowaną pozycję). Służą do tego takie serwisy jak polski atlasETF oraz zagraniczny justETF. Sam często z nich korzystam, gdy wiem, że chcę zainwestować w dany szeroki obszar, ale szukam odpowiedniego ETF-a do tego celu.

Czasem pragniemy po prostu zobaczyć kurs akcji w pewnym ujęciu czasowym, bez dodatkowych informacji... lub właśnie z nimi. Najprostszy serwis tego typu to polski Stooq, który zawiera po prostu "mięso", bez dodatkowych ozdobników (dosłownie - grafika przywołują wspomnienia o początkach Internetu). Te z kolei znajdziemy w serwisach Bankier.pl oraz Money.pl, które przede wszystkim są portalami newsowymi, ale mają też wykresy z dodatkowymi informacjami. I to dosłownie, bo np. w wykresie złota w Bankierze możecie włączyć zaznaczenie wydarzeń, co nada kontekst poszczególnym ruchom. Jeśli chcecie z kolei nieco dokładniejsze dane dotyczące wahań kursu, to możecie zerknąć do Yahoo! Finance, a szczególnie do zaawansowanych wykresów (ang. Advanced Chart) dla danych pozycji.

Jeśli chcecie od czasu do czasu popatrzeć na analizę techniczną i prognozy analityków, to mogą Was zaciekawić serwisy typu TradingView, BiznesRadar czy Investing.com - to serwisy zawierające również wyliczenia różnych wskaźników, które mogą pomóc rozeznać się w oczekiwaniach od danego podmiotu. Dziwnym trafem, gdy wchodzę tam na rekomendacje dotyczące spółek, które posiadam, to dostaję odpowiedź "sprzedaj"...

Wreszcie, jeśli po prostu chcesz się rozeznać w aktualnych promocjach i ofertach kont oszczędnościowych oraz lokat, to warto zerknać do rankingów, jak np. te u Marcina Iwucia, czyli na blogu "Finanse bardzo osobiste".

Kogo śledzić w poszukiwaniu materiałów edukacyjnych?

Na wstępie trzeba powiedzieć, żenależy ostrożnie dobierać sobie ekspertów, których słuchamy. Trzeba mieć świadomość, że nie zawsze mają rację, natomiast mogą mieć siłę przekonywania, która sprawi, że uwierzymy w coś, w co nie powinniśmy, a nasza niedostateczna wiedza nie pozwoli tego zweryfikować. Tym niemniej, w polskiej blogosferze znajdziemy kilka osób, które z różnych przyczyn warto poznać (a właściwie ich materiały).

Przede wszystkim, zanim przejdziemy do osób stricte zajmujących się edukacją finansową, to chciałbym podziękować i pozdrowić Tomasza Dunię, który swego czasu przeszedł podobną drogę jak ja i starał się zebrać swoją wiedzę na blogu. To jest to, co sam starałem się tutaj zrobić - spokojnie omówienie różnych form oszczędzania z perspektywy (prawie) początkującego. Tomek zrobił to dużo dokładniej niż ja, a na pewno w bardziej ułożony sposób. Myślę, że jeśli zaczynacie, to warto zerknąć do jego artykułów, gdyż to właśnie taki człowiek, jakim w większości jesteśmy - ktoś, kto zaczął inwestować, aby zabezpieczyć finansowo siebie i swoją rodzinę na przyszłość.

A teraz przejdźmy do osób i serwisów, do których warto zaglądać chcąc się nieco dokształcić. Z portali mamy wybór spośród kilku serwisów, z których każdy ma swoich dziennikarzy i ulubione tematy. Ja akurat preferuję wspominanego już Bankiera, który trzyma rękę na pulsie, a do tego codziennie dostarcza podsumowanie tego, co działo się na polskiej giełdzie. Poza tym ma wiele felietonów, inicjatyw (np. konkurs inwestycyjny) i po prostu jest wartościowym źródłem informacji.

A co z rzeczonymi ekspertami? Nie o wszystkich z polskiej blogosfery wspomnę, ale kilka nazwisk na pewno muszę wyróżnić i opisać, czego możecie się po nich spodziewać.

Przede wszystkim warto wrócić do przywoływanego już tutaj Marcina Iwucia, który jednocześnie jest autorem chyba najbardziej polecanej książki o własnych finansach dla początkujących, czyli "Finansowej fortecy". Czytałem i polecam, bo z perspektywy amatora można stamtąd naprawdę dużo się dowiedzieć w strawnie podany sposób i ciekawostkami historycznymi. To nie jest jedyna polecana pozycja literaturowa, gdyż np. dobre opinie słyszałem też o Mateuszu Samołyku (Inwestomacie) o jego "Inwestowaniu dla każdego". Wracając do Iwucia, to za cel postawił sobie finansowe edukowanie Polaków. To bloger, ale też (chyba ostatnio przede wszystkim) youtuber, gdzie na jego kanale mała ekipa omawia różne kwestie związane z oszczędzaniem. To przykład osoby, która namawia do spokojnych, nudnych i dobrze zaplanowanych inwestycji - tutaj znajdziemy nie tylko materiały o tym, w które aktywa inwestować, ale jak np. uszczelnić swoje finanse, które bezpieczne formy się opłacają, czy warto nadpłacić kredyt, jak rozliczyć podatki, jak przygotować poduszkę finansową itd. Jeśli oczekujecie emocji i memów, to zdecydowanie nie w tym miejscu - zamiast tego dostaniecie bardzo dużo spokojnej (a ostatnio nawet defensywnej) merytoryki ogólnofinansowej, nie tylko giełdowej. To nie znaczy, że u następnych twórców tego nie uświadczycie, ale nie bez powodu p. Marcin jest najczęściej wspominanym polskim twórcą z tego poletka.

Drugą rekomendacją jest Paweł z "Zawodu Inwestor", który jest warty uwagi z paru powodów. Po pierwsze, prowadzi serię o publicznym portfelu, ale przede wszystkim też inwestowaniu 500 zł miesięcznie. A ponieważ ten eksperyment trwa już paręnaście miesięcy, to można w praktyce zobaczyć efekty takich dopłat i co można dzięki nim osiągnąć. Po drugie, lubi omawiać polskie spółki, ale też różne podejścia do inwestowania i niekoniecznie namawia do agresywnych ruchów. Po trzecie - jest tutaj sporo humoru i kolokwializmów ukrytych zarówno w prostych graficznie filmach, jak i wypowiedziach. A to wszystko omawiane kojącym głosem i bez przykrywania formą merytoryki. Czasem słyszę opinie, że Zawód Inwestor jest zbyt optymistycznie nastawiony do polskiego rynku, natomiast potrafi to uzasadnić. Ma też tutoriale o XTB i ogólnie to dobry twórca dla początkujących. Jest również wielkim fanem spółek wypłacających dywidendy. Te filmy się po prostu dobrze ogląda.

Dalej mamy wspomnianego już Inwestomata, którego znam przede wszystkim z blogu, choć ma również kanał na YouTube. To także źródło materiałów dla początkujących, ale już znacznie bardziej opisanych, z większą liczbą detali i o szerszym spektrum zainteresowań. Powiedzmy, że długość artykułów jest tam porównywalna do tego, co czytacie teraz. Tym niemniej, można tam zobaczyć co nieco o prowizjach polskich domów maklerskich, obligacjach (także zagranicznych) i masie innych rzeczy już bardziej specjalizowanych. Ale nadal jest to blog do polecenia dla kogoś, kto dopiero startuje.

Kolejna osoba to Piotr Cymcyk, twórca portalu DNA Rynków. W tym przypadku to bardziej kontrowersyjna rekomendacja ze względu na fakt, iż Piotr ma cięty język, a jego materiały mogą być niezjadliwe dla kogoś, kto nie lubi nowoczesnego montażu na YT (krótkie ujęcia, stabilizatory obrazu na twarz (nie wiem, jak to się naprawdę nazywa), memy itd.). Jest to też twórca, który skupia się na aktywniejszym inwestowaniu i żywym interesowaniu się rynkiem finansowym, daleko sięgającym poza byciem hobby. Ale to nie zmienia faktu, że to również specjalista, który wytłumaczy wiele zagadnień dotyczących ETF-ów, trendów, surowców (mimo że ich nie lubi), wyjaśnień zjawisk ekonomicznych itd. I co najważniejsze - zrobi to dobrze i merytorycznie. Do tego mamy regularną dawkę newsów, trochę humoru i mimo clickbaitowych miniaturek i tytułów uważam, że warto czasem zerknąć, gdyż można sporo się dowiedzieć.

Ostatnią moją rekomendacją jest Tomasz Trela, wspomniany już były zarządzający dużymi zagranicznymi funduszami inwestycyjnymi i człowiek, który zdecydowanie aktywnie inwestuje. Z tego powodu to niekoniecznie jest twórca dla każdego początkującego - jeśli chcesz spokojnie wkładać pieniądze w ETF-y i obligacje, to tutaj możesz wejść bardziej w ramach ciekawostek. Za to możesz tutaj poznać np. wcześniej podlinkowane zasady analizy fundamentalnej czy odczytywania wskaźników analityków. To już kanał (i blog) znacznie bliższy giełdy wyobrażanej sobie na wzór Wall Street.

To nie znaczy, że nie ma innych wartościowych twórców. Natomiast skupiłem się na tych, których nieco dłużej oglądam lub czytam i rzeczywiście ich materiały pomogły mi w rozwoju. Zapoznanie się z nimi nie oznacza też, że nagle staniesz się aktywnym(ą) inwestorem(ką), ale po prostu rozszerzysz swoje horyzonty i wiedzę.

Istnieją też nie tyle osobistości internetowe, co inwestorzy regularnie dzielący się swoimi spostrzeżeniami i przewidywaniami na Twitterze. Można też znaleźć newslettery, dzięki którym co tydzień lub dwa tygodnie na Waszą skrzynkę mailową wpadną różne przemyślenia osób regularnie zajmujących się giełdą. Natomiast nie podaję odpowiednich linków tutaj nie z tego powodu, że nie są warci uwagi, tylko że materiały tam zamieszczone mogą być trochę zbyt specjalistyczne dla osoby, która dopiero zaczyna.

Słowniczek pojęć

Zdaję sobie sprawę, że podczas pisania tego artykułu użyłem kilku terminów, które niekoniecznie muszą być zrozumiałe. Niektóre z nich wyjaśniłem, inne pominąłem, a jeszcze są takie, o których nie wspomniałem, ale na pewno pojawią się przy czytaniu lub oglądaniu różnych materiałów. Dlatego krótko omówmy sobie je w sposób zrozumiały dla każdego.

Portfel - bynajmniej nie chodzi o to, co nosimy w kieszeni i gdzie trzymamy karty oraz pieniądze. Portfel w znaczeniu inwestycyjnym to zbiór aktywów w odpowiednich proporcjach, określonym celu i "zasadach". Wspominałem np. o tym, że warto mieć poduszkę finansową, która jest typowym portfelem "obronnym", wykorzystywanym w trudnych sytuacjach życiowych, ale też niespecjalnie zyskownym. Inne zasady będą cechowały np. portfel agresywny, jeszcze inne ten nastawiony na spółki technologiczne lub na określony rynek.

Rebalancing portfela - ustalając strategię w portfelu, ustalamy m.in. procentową wartość danych aktywów. Może to być np. 80% akcji i 20% obligacji (z pewną tolerancją w obie strony). Co jakiś czas śledzimy te proporcje i jeśli zauważamy, że odbiegają one od ustaleń (np. akcje stanowią teraz 90% portfela), to robimy rebalancing, czyli doprowadzamy do właściwych proporcji. Pomaga to w utrzymaniu strategii właściwej na różne sytuacje w gospodarce, kiedy inne aktywa są lepsze przy dużej inflacji, inne w recesji, inne podczas wzrostu itd. Więcej o tym znajdziecie w tym artykule Inwestomatu.

Aktywo, instrument finansowy i walor - są to trzy podobne, ale jednak inne rzeczy. Aktywem jest coś, co ma wartość ekonomiczną. Może być to złoto, dostęp do zysków spółkii X, mieszkanie itd. Natomiast instrument finansowy to kontrakt pomiędzy dwiema stronami lub - mówiąc prościej - pewien środek do upominania się o swoje zyski, odsetki itd. Jeszcze jest walor, które ponownie jest czymś cennym, co ma wartość, jak np. akcja czy obligacja, ale też obraz znanego artysty. Mówiąc szczerze, na "naszym poziomie" można spokojnie odpuścić sobie rozróżnianie tych terminów i najwyżej traktować “instrument“ jako sposób na zdobycie aktywa.

Ekspozycja - w artykule kilka razy pisałem o tym, że nie musimy np. kupować obligacji, aby odnosić korzyści z obligacji - możemy nabyć instrument, który daje ekspozycję na obligacje, tj. pod spodem sam w nie inwestuje, trochę jak pośrednik. Innym przykładem są ETF-y na Stany Zjednoczone lub nowe technologie - po dodaniu takiego funduszu do portfela, zyskujemy ekspozycje na Nvidię, Amazona, Apple itd. bez kupowania bezpośrednio rzeczonych spółek.

Dywersyfikacja - inwestowanie w jedną rzecz jest ryzykowne. Dlatego powinno się dzielić swój kapitał pomiędzy kilkoma aktywami, różniącymi się pod kątem branży, regionu, ryzyka i/lub typu. Jest to zrealizowanie powiedzenia "nie wkłada się wszystkich jajek do jednego koszyka" - zabezpieczamy się przed różnymi zdarzeniami politycznymi lub gospodarczymi. Odwrotnością dywersyfikacji jest koncentracja, czyli skupienie kapitału na konkretnym aktywie.

Zrealizowanie zysku lub straty - jest to po prostu sprzedanie czegoś i osiągnięcie z tego powodu realnego zysku lub straty. To czynność, która wymusza na nas obowiązek podatkowy, ale także powoduje, że możemy faktycznie cieszyć się dodatkowymi pieniędzmi lub smucić ich stratą.

Inwestowanie aktywne i pasywne - aktywność polega na ciągłym szukaniu najlepszych pozycji do zainwestowania, żywym przekładaniu kapitału i bieżącym interesowaniu się swoimi inwestycjami. To nie oznacza, że w pasywnym podejściu nie musimy tego robić, ale w tym przypadku z góry wybieramy dość "pewne" instrumenty, które pracują sobie dla nas "w tle" i tylko co jakiś czas kontrolujemy, czy jest w porządku. Pasywne inwestowanie to coś, czym powinny interesować się osoby, które nie chcą poświęcać dużo czasu i traktują to jako sposób na wypracowanie zysku bez czynnego udziału.

Dywidenda - część zysku wypracowanego przez spółkę, wypłacana jako "dola" dla akcjonariuszy. Zwykle dzieje się to raz do roku i jest to kilka procent ceny akcji. Nie wszystkie spółki wypłacają dywidendy.

Spekulacja - inwestowanie oparte nie o realną, "twardą" ocenę wyników spółki, ale o jej potencjał i "wyczucie" rynku. Zwykle dotyczy krótkiego terminu, kiedy osoba celuje we wzrosty akurat w tym okresie. Ryzykowna gra, która może mieć pewne uzasadnienie w doświadczeniu inwestora, ale zdecydowanie wymagająca żelaznych nerwów i nie dla osób chcących spokojnie pomnażać swój kapitał. Z naszej, amatorskiej perspektywy, powinniśmy unikać spekulacji i lokować pieniądze w uznanych wyborach, nawet jeśli są mniej zyskowne.

Hossa lub rynek byka - długotrwałe wzrosty na giełdzie, oznacza, że dany rynek (rzadziej jedno konkretne aktywo) radzi sobie dobrze. “Rynek byka" jest synonimem, a to określenie pochodzi od rogów byka, które podczas ataku są skierowane do góry (dlatego przed wieloma budynkami giełd w różnych krajach znajdują się właśnie posągi byka - przed warszawską GPW również). Hossy zwykle ujawniają się po dłuższym czasie - z natury wzrosty są stopniowe, wolniejsze niż spadki.

Bessa lub rynek niedźwiedzia - długotrwałe spadki na giełdzie, odwrotność hossy. Umownie przyjmuje się, że o bessie mówimy, gdy na dłuższym odcinku czasu obniżenie wartości nastąpiło o ponad 20%. “Rynek niedźwiedzia" to synonim - nazwa pochodzi od tego, że niedźwiedź atakuje łapą w dół.

Korekta - jeśli cena instrumentu jest wysoka, to jest szansa, że spadnie, gdyż osoby mające go wcześniej w swoim portfelu, realizują zyski (sprzedają go). Jeśli jednak spadek kursu nie jest długotrwały, to mówimy nie o bessie, ale korekcie, czyli naturalnym wahaniu się ceny.

Analiza fundamentalna - analiza danej spółki opierająca się o jej wyniki finansowe, prognozy, aktualną sytuację na rynku, konkurencję, opinie, potencjał rynku, a nawet rozmowy z zarządem i pracownikami. Ma na celu ustalenie wartości danej firmy, co pozwoli przewidzieć odpowiednią cenę. Zalecane przy długoterminowym inwestowaniu, ale trudne, gdyż wymaga odpowiedniej wiedzy i czasu.

Analiza techniczna - analiza spółki lub innego aktywa opierająca się wyłącznie o wykres zmiany cen, uznająca, że wszystko, co wpływa na wartość, jest już w historycznych danych kursu akcji. Polega na wyliczaniu wielu parametrów, próbujących przewidzieć siłę dalszego wzrostu lub spadku. Odpowiednie tylko w krótkim terminie, uwielbiane przez spekulantów.

Ticker - oznaczenie danego instrumentu na giełdzie, zwykle poprzez 3-5 liter i 2 litery po kropce z nazwą giełdy. Przykładowo, CD Projekt to CDR.WA ("WA" od giełdy w Warszawie, a "R" w nazwie zostało prawdopodobnie z czasów, kiedy był to CD Projekt Red Studio).

Podsumowanie

Uff, dotarliśmy do końca. Zdaję sobie sprawę, że mimo objętości, ten artykuł jest wprowadzeniem w temat. Mam jednak nadzieję, że wprowadzeniem na tyle rozległym, że odpowiada na większość pytań i wątpliwości osób, które wcześniej z systematycznym oszczędzaniem i inwestowaniem nie miały nic wspólnego i trochę się bały związanych z tym konsekwencji. Zdaje sobie jednak sprawę, że nie wszystkie wątki mogą być jasne, a niektóre zostały pominięte. Polecam wówczas sekcję komentarzy (przez Fediverse, np. Mastodona - wystarczy założyć tam konto i odpowiedzieć na post, który informuje o tym tekście), w których możecie dać upust swoim niejasnościom.

Chciałbym podziękować wszystkim koleżankom i kolegom, którzy również oszczędzają lub inwestują i z którymi od dłuższego czasu mogę przeprowadzać wiele, inspirujących rozmów, podczas których wymieniamy się doświadczeniami. Wcześniej widzieli ten tekst i pomagali w jego tworzeniu - przyznaję, że nie ze wszystkich rad skorzystałem, ale możliwe, że w pewnych miejscach widzicie swoj wkład. Dzięki jeszcze raz.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Kiedy potrzebujesz oprogramowania w firmie? https://wildasoftware.pl/post/kiedy-potrzebujesz-oprogramowania-firmy?ref=rss https://wildasoftware.pl/post/kiedy-potrzebujesz-oprogramowania-firmy?ref=rss Thu, 12 Jun 2025 17:30:00 +0000 Są takie momenty w prowadzeniu biznesu, kiedy mówisz sobie "przydałoby się nam..." i tutaj następuje wymienienie różnych narzędzi lub zasobów. W wielu przypadkach jest to coś w rodzaju "gdybyśmy tylko mieli aplikację, która zrobi to za nas". Jednak czasem po tym nadchodzi "a w sumie to czy warto", "a ile to czasu i pieniędzy będzie nas kosztowało" lub "przecież wdrożenie się w to zajmie wieki" i kończy się zdaniem "w sumie ten Excel nam wystarczy". W efekcie firmy lub instytucje, mimo że widzą wyraźną potrzebę biznesową, nie starają się jej zaspokoić, zainwestować i nie rozwijają swoich procesów, a co za tym idzie - przedsiębiorstw. A szkoda, gdyż ciągłe ulepszanie funkcjonowania jest czymś, co poprawia działanie całej sfery zawodowej, a co za tym idzie - społeczeństwa. A co mi tam - tak górnolotnie napiszmy. A mniej górnolotnie można rzec, iż zwyczajnie zapewnia oszczędności w długim terminie i umożliwia łatwiejsze skalowanie biznesu.

Zejdźmy jednak na ziemię. Faktem jest, że informatyka już nie tyle weszła do biznesu, co zadomowiła się w nim na dobre, zajęła najlepszy fotel i wręcz potrzeby IT dominują wśród nowych wymagań stawianych przedsiębiorstwom. Nawet, jeśli firma należy do branż uznawanych za tradycyjne lub związane z dobrami fizycznymi, to trudno sobie dzisiaj wyobrazić, aby obyła się bez rozwiązań cyfrowych. Niekoniecznie muszą być to wyrafinowane narzędzia, wprowadzające rewolucję w działalności, przed którymi drżą wieloletni pracownicy przyzwyczajeni do pewnego sposobu pracy - w naszej praktyce rozmawialiśmy z wieloma firmami, wśród których były też takie, które do tej pory obywały się bez wspomagających aplikacji i ograniczały swoją cyfryzację do choćby arkusza kalkulacyjnego oraz programu do fakturowania ("bo musiały"). Ale również spotykaliśmy (i nadal spotykamy) na swojej drodze przedsiębiorstwa, które wprowadzają usługi IT na dużo większą skalę, tworząc wręcz wewnętrzne zespoły wdrożeniowe. Także dlatego, że są bardziej świadome tego, co chcą i co mogą uzyskać od takiego software house'u jak my, Wilda Software.

W tym tekście prześledzimy sobie sfery, w których każda firma powinna rozważyć, czy nie warto wprowadzić aplikacji ułatwiających, uprzyjemniających lub przyspieszających pracę. I spokojnie - pod koniec będzie trochę o AI, choć niektórzy pewnie już przewracają oczami. Ale będzie krótko, obiecuję.

Zarządzanie zamówieniami

Jest to potrzeba, którą zauważa praktycznie każdy biznes i która najczęściej łączy w sobie inne obszary, omawiane w dalszej części tekstu. Znakomita większość przedsiębiorstw żyje ze zleceń od klientów, odpowiadania na zapytania ofertowe i musi monitorować, co właściwie z takim zamówieniem się dzieje, na kiedy ma być zrobione oraz za ile. Wbrew pozorom, nie jest to takie oczywiste - im lepiej firma sobie radzi, tym więcej zleceń obsługuje w jednym momencie i śledzić to wszystko bez odpowiedniego narzędzia staje się nie tylko męczące, ale i podatne na zwykłe, ludzkie błędy.

Tak naprawdę rzadko kiedy pojedynczy system pozwala zarządzać tylko zamówieniami - najczęściej łączy się to z obszarami wymienionymi dalej w tekście, jednak warto też wspomnieć, że samo monitorowanie stanu obecnych prac to nie wszystko. Takie narzędzie umożliwia też najczęściej podsumowanie działalności firmy w postaci różnorakich wykresów, raportów czy diagramów. Jakich? To właśnie zależy od klienta - w naszej historii nie zdarzyli się chyba dwaj zlecający, którzy chcieliby identyczny pakiet raportów, nawet jeśli byli z podobnych branż. Oczywiście, pewne rzeczy są wspólne - każdy chce zobaczyć procent zamówień zakończonych sukcesem czy opóźnionych, a także łączny zysk, ale jeśli chcemy wejść głębiej (a zwykle chcemy), to mamy już do czynienia ze statystykami "szytymi na miarę". Nie bez powodu systemy IT robione na zamówienie są bardzo spersonalizowane i przez to skuteczniejsze od aplikacji kierowanych na szerszy rynek (choć te drugie mają inne zalety).

Tutaj warto też zauważyć, że poprzez "zamówienia" niekoniecznie trzeba rozumieć prośby o realizację czegoś w dłuższym terminie - przecież choćby salon fryzjerski, przyjmujący klientów o danej godzinie, również musi tym zarządzać. Nierzadko są to bardziej specyficzne potrzeby, mające dodatkowo uatrakcyjnić markę w oczach klienta i pozwalające wybrać konkretną porę na odwiedziny, a specjalistów poinformować, kiedy będą mieli zajęcie. Jednak co do zasady sytuacja jest taka sama - jest to usługa, która musi zostać wykonana i należy się do niej przygotować. Im więcej zleceń, tym większa szansa, że papierowy terminarz trzeba będzie zamienić na kalendarz w aplikacji.

Jaki jest jeszcze jeden argument za posiadaniem takiego systemu? Rzadko kiedy jedna osoba w firmie robi wszystko - od przyjęcia zamówienia, po realizację, aż dochodząc do czynności wdrożeniowych lub odbiorczych. Zazwyczaj każdym elementem zajmuje się osobny człowiek lub zespół i muszą przekazywać między sobą informacje. Jeśli zlecenia są przyjmowane na papierze, poprzez prosty formularz internetowy lub arkusz kalkulacyjny, to tylko w małej grupie można zachować wysoki poziom "osmozy wiedzy" - w każdym innym przypadku bez systemu, do którego (z różnymi uprawnieniami) mają dostęp różne działy, istnieje wysoce prawdopodobna możliwość popełnienia pomyłki wynikająca ze zwyczajnej niewiedzy, gdyż przyjmujący zlecenie zapomniał coś przekazać. Oczywiście, nawet z najlepszym systemem może tak się stać, ale szansa, że nigdzie to nie zostanie zapisane, jest znacząco mniejsza.

Zarządzanie relacjami z klientami (CRM)

Wspomnieliśmy o przyjęciu zamówienia, jednak przed tym etapem istnieje jeszcze proces pozyskiwania klienta. Z zewnątrz czasem wydaje się, że zleceniodawcy sami przychodzą znikąd, od razu chcą zlecić realizację i potem płacą. Firmy z taką sytuacją są przeszczęśliwe - w znakomitej większości jednak:

  • z grona potencjalnie zainteresowanych klientów tylko część dochodzi do etapu rozmów analitycznych,
  • z tej części kolejny procent rzeczywiście zleca realizację projektu,
  • proces, zanim ktoś stanie się zainteresowany, może być naprawdę długi i wyboisty,
  • oprócz tego istnieją tzw. leady (potencjalni odbiorcy, którzy mogą stać się klientami), którymi też trzeba zarządzać.

Nieco czymś innym jest zarządzanie konkretnym zamówieniem czy produkcją, a czym innym zarządzanie klientami czy przebiegiem rozmów z nimi. W tym drugim przypadku interesuje nas bardziej sam klient - jego dane (przydatne przy sporządzaniu umów), osoby kontaktowe, preferencje, ustalenia, historia spotkań, źródło pozyskania, statystyki mogące wyróżnić naszych najlepszych handlowców, daty urodzin w celu wysłania życzeń lub prezentów itd. Szczególnie w przypadku firm nastawionych na tzw. prospecting lub generalnie mających dużo zapytań (wynikających z kolei z marketingu), gdzie w dodatku zespół handlowców i kadry zarządzających są większe, taki system CRM (ang. Customer Relationship Manager) jest na wagę złota.

Podejścia są różne - od gotowych płatnych rozwiązań dostępnych w chmurze, self-hostowane aplikacje dopasowywane do klienta (np. Dolibarr), aż po tworzenie takich systemów od podstaw. I tak, też to robiliśmy, więc wiemy, ile danych po drodze można zbierać i analizować.

Zarządzanie produkcją i zadaniami

Wróćmy jednak do sytuacji, w której zamówienie już wpłynęło i trzeba realizować konkretną partię produktów lub usługę. W przypadku, kiedy ten proces jest prosty, sytuacja też jest prosta - zwyczajnie liczymy wykonane sztuki i w ten sposób oceniamy, czy zlecenie już jest do odbioru. Jednak zazwyczaj nie jest tak prosto i proces produkcyjny składa się z wielu kroków, które mogą się zmieniać w zależności od przedmiotu zamówienia, dostępności personelu, maszyn, wybranej alternatywy i wielu innych czynników. Są też takie realizacje, jak choćby w naszym przypadku, kiedy projekty dzielą się na wiele etapów i dziesiątki, jeśli nie setki zadań. Tego nie da się ogarnąć na piechotę - konieczne jest rozwiązanie z obszaru IT.

Jednak w tym przypadku mamy też prawdopodobnie największy wachlarz potrzeb klientów. Zupełnie czegoś innego będą wymagali producent elementów drewnianych, software house, firma od wykończeń wnętrz oraz biuro architektoniczne. Dodatkowo, niektóre przedsiębiorstwa potrzebują systemu nie tylko do zarządzania realizacją usługi, ale także w ogóle jej projektowaniem czy działu R&D, który dopiero przygotowuje fundamenty pod przyszłą produkcję. Zresztą, nie tylko liczby (np. sztuk) są analizowane - tego typu funkcjonalność pozwala też śledzić czas poświęcony na zagadnienia i porównywać go z założonym oszacowaniem lub dostępną pulą. Nierzadko są to dane bezpośrednio przekładające się na rozliczenia - mieliśmy do czynienia z sytuacją, kiedy takie rozwiązanie pomogło w pozbyciu się papierowych kart pracy zbieranych codziennie lub co tydzień w zakładzie i drobiazgowo wprowadzanych do systemu przez pracowników klienta.

Chyba nie skłamiemy, jeśli powiemy, że to często najbardziej skomplikowane elementy systemów (ponownie - zazwyczaj połączone z wcześniej wymienionymi aplikacjami do zarządzania zamówieniami), gdyż bardzo zależą od danego środowiska i choćby w przypadku firm typowo produkcyjnych trudno jest dopasować już istniejące rozwiązanie. Owszem, jest to możliwe, ale nie bez powodu praktycznie każde przedsiębiorstwo, dla którego tworzyliśmy takie oprogramowanie, chciało czegoś innego. Wszystko da się zrobić, nawet jeśli jest to powiązane z innymi obszarami, łącznie z systemem wdrożeniowym, odbiorczym czy dystrybucyjnym, które należą do kolejnych grup potrzeb klientów.

Oczywiście - sama realizacja to nie wszystko. Dodatkową zaletą zbierania danych w takim systemie jest możliwość ich analizowania, doglądania wykorzystania zasobów, progresu wykonania, a to pozwala reagować odpowiednio wcześniej na wszelkie zakłócenia. Tak, jak w przypadku zamówień, tak i tutaj raportowanie i monitorowanie statystyk (a nawet samo zbieranie danych, które nie zawsze jest proste u podstaw bez systemu IT) jest gigantyczną pomocą dla kierowników działów technicznych. Nie mówiąc o podsystemach ułatwiających szeregowanie zadań, aby zoptymalizować wykorzystanie zasobów.

Obsługa finansów

Zrealizowaliśmy zamówienie i dostarczyliśmy je klientowi lub jesteśmy w trakcie - super. Teraz trzeba zadbać o odpowiednie wystawienie faktury i kontrolę tego, aby została ona zapłacona. Jest to część trudna i niekoniecznie jest to spowodowane złożonością implementacji takiego rozwiązania, a raczej zadbaniem o bycie zgodnym z prawem, nie zawsze jednego kraju. Finanse wiążą się bowiem z księgowością, a to obszar ściśle regulowany, w którym każde odstępstwo od normy może pociągać za sobą skutki w postaci kontroli i kary nałożonej przez Urząd Skarbowy.

W dzisiejszych czasach jednak już mało która firma wystawia faktury w sposób ręczny - na rynku dostępne są rozwiązania podążające za nowymi wymogami i umożliwiające realizację tego procesu w sposób bardziej zautomatyzowany oraz ograniczający błędy. Prawdę mówiąc, nie widzieliśmy firmy, która nawet, jeśli nie została zinformatyzowana, to nie posiadała choćby tego komponentu w postaci programu do fakturowania. Natomiast realizacja zobowiązań klientów to nie wszystko - firmy wydają pieniądze na wiele różnych sposobów, ponosząc określone koszty, które też trzeba śledzić, a co ważniejsze - optymalizować.

Zarządzanie magazynem

Firmy wykonujące usługi w postaci wykonania pewnych fizycznych elementów lub dystrybuujące towar doskonale znają problem polegający na zdobyciu wiedzy, czy mają produkt na stanie. I jeśli tak, to ile konkretnie, gdzie i w jakim stanie. A jeśli nie, to na kiedy i w jakiej cenie mogą go zamówić. A jeśli magazyn to nie pomieszczenie gospodarcze na tyłach sklepu tylko kilka wielkich hal...

Na rynku istnieją wielkie systemy magazynowe WMS (ang. Warehouse Management System), które umożliwiają kompleksową obsługę takich miejsc i ich utrzymywanie. Nierzadko są to kolosy, które mogą zostać wykorzystane tylko przez naprawdę duże przedsiębiorstwa - większość potrzebuje nieco mniejszych rozwiązań, które zapewnią katalog produktów, kontrolę stanu magazynowego, zarządzanie operacjami (w tym dostawami i wydaniami) i generowanie odpowiednich dokumentów. I owszem, tego typu narzędzia również mieliśmy przyjemność tworzyć i wiemy, że inaczej wygląda zarządzanie stanem w zakładzie produkcyjnym, inaczej w sklepie, a jeszcze inaczej w firmie medycznej, która musi uważać na dawki oraz daty ważności.

Pamiętajmy też o tym (a co rozwiniemy w kolejnym punkcie), że zarządzanie magazynem nie musi dotyczyć wyłącznie produktów oferowanych klientowi czy służących do ich wytworzenia. Każda osoba opiekująca się biurem wie, że np. niespodziewanie kończąca się kawa może doprowadzić do rebelii, a liczne prośby poszczególnych członków zespołu o małe rzeczy lubią się zapominać. W bardzo dużych biurach systemy magazynowe na pewną skalę można także wykorzystać do takich potrzeb, aby uzupełniać materiały lub sprzęt. Ciekawostka - u nas lista zakupów i zapotrzebowania członków zespołu są zbierane poprzez Feedybacky.

Obsługa infrastruktury

Jednak nie tylko sferę operacyjną można zautomatyzować - w poprzednim rozdziale wspomnieliśmy o tym, że firma to też utrzymanie biura, zasobów ludzkich i sprzętowych, a także innych aspektów, o które trzeba dbać, ale nie zawsze jest to... ekscytujące. Mowa o przeglądach i kontrolowaniu choćby stanu sprzętu. Firmy mają różne potrzeby w tym zakresie - od zwykłej kontroli urządzeń, do sprawdzania legalności oprogramowania, kontroli sieci wewnętrznej, floty samochodów, centrali telefonicznej... Może być tego bardzo dużo. Często się nie docenia tego tematu, gdyż te kwestie nie przynoszą bezpośredniego dochodu, ale niezadbanie o ten obszar może skutkować czymś znacznie gorszym - utratą wydajności pracowników, ich niezadowoleniem, brakami infrastrukturalnymi, a to wszystko w końcu będzie rzutować na uzyskiwane zyski.

Stąd warto pochylić się nad tym, czy można wygenerować oszczędności lub zabezpieczyć swoją firmę przed nieprzewidzianymi zdarzeniami właśnie poprzez oprogramowanie ułatwiające monitoring zasobów, zbliżające się daty ważności różnych elementów czy przeglądów. Nie zawsze są to łatwe przedsięwzięcia, ale pamiętajmy, że odpowiednio wdrożone narzędzie automatyzujące dany proces pozwala wygenerować oszczędności w długim okresie czasu, a czasem wręcz nawet odzyskać radość życia lub powiadomić o realnych problemach, z których nie zdawaliśmy sobie sprawy, a w pewnym momencie mogłyby zachwiać podstawami funkcjonowania firmy. Tak, nadal mam na myśli między innymi tę kawę.

Obsługa zgłoszeń serwisowych od klientów

Od czasu do czasu klienci mają uwagi do zrealizowanej pracy - czasami są to znalezione błędy, które muszą być obsłużone gwarancyjnie, niekiedy dodatkowe małe zlecenia lub sugestie. Bywają też firmy, które z racji charakteru prowadzonej działalności potrzebują Biura Obsługi Klienta (BOK), czyli help desku, dzięki któremu będzie możliwe załatwienie różnych spraw.

Z łatwością możemy wskazać firmy, których taka potrzeba dotyczy najbardziej - są to wszelkie rodzaju dystrybutorzy energii, mediów, usług oferowanych wielu małym klientom, z którymi relacja nie jest taka personalna, ale za to idącą w masę, a do tego sama realizacja jest ustandaryzowana i może się wiązać z problemami technicznymi lub obsługą regularnych faktur. Prawda jest jednak taka, że każde przedsiębiorstwo ma lub powinno mieć coś w rodzaju działu wsparcia (tzw. support). Czasem rzeczywiście wystarczy kilka osób z telefonem lub wręcz szef, który dalej przekazuje sprawę. Niekiedy jednak skala działalności jest na tyle duża, że potrzebni są osobni ludzie, a co za tym idzie - system do obsługi zgłoszeń.

Z tego powodu wykiełkowało u nas wspominane już dzisiaj Feedybacky, które działa nie tylko w naszym interesie, ale też jest stosowane przez naszych klientów. Jest to przykład systemu, które możemy udostępnić w postaci chmurowej lub dostosować i zainstalować osobną wersję dla konkretnego odbiorcy. Istnieją też inne kawałki oprogramowania tego typu, a także całe systemy w modelu SaaS (Software as a Service). Nie zmienia to faktu, że jest to zaskakująco często powtarzająca się potrzeba w różnych przesiębiorstwach, a dobry system tego typu pozwala zaoszczędzić czas, nerwy, a jednocześnie pokazać, że firma jest zaawansowana technologicznie. Zwłaszcza, że to widać na zewnątrz.

Kadry

Wróćmy na chwilę do sekcji z finansami i infrastrukturą. Gdy rozmawiamy o księgowości, to często też pojawia się temat kadr. A gdy myślimy o zasobach, to należy pamiętać, że są tam też te ludzkie.

W zależności od wielkości firmy (aczkolwiek tych stosunkowo niewielkich też to dotyczy), przydaje się system do zarządzania danymi pracowników - ich stawkami, uprawnieniami, a także monitorowaniem terminów ważności wszelkiego rodzaju, jak choćby badań medycyny pracy, szkoleń BHP itd. Wbrew pozorom, łatwo się w tym pogubić, gdy prezes robi wiele rzeczy naraz, a firma nie jest na tyle duża, aby mieć osobną osobę od kadr. Nie mówimy tutaj o stricte formalnej odsłonie tego aspektu prowadzenia firmy, ale też o takim "ludzkim" - kto ma kiedy urodziny, jakie są nasze uwagi w różnych okresach współpracy, a także przydział do poszczególnych zadań lub projektów. Można tutaj też wymienić oprogramowanie do monitorowania frekwencji, ustawiania urlopów i wielu innych spraw, z którymi do czynienia ma każde przedsiębiorstwo.

I ponownie - są do tego duże pakiety, których wdrożeniem może sie zająć firma IT. Ale prawda jest też taka, że przedsiębiorstwa nie zawsze potrzebują bardzo rozbudowanego rozwiązania i niekiedy wystarczy takie pokrywające najczęstsze zapotrzebowanie. O tym też warto pamiętać i zapytać software house, czy może taki system wykonać.

Strona firmowa

Klasyka, ale o niej również trzeba wspomnieć - większość firm powinna posiadać swoje miejsce w sieci, do którego może linkować, pozycjonować i przedstawiać swoją ofertę w formie wygodnej dla każdego. Nie jest to rozwiązanie stricte pomagające firmom działać operacyjnie, ale za to jest piekielnie istotne w zdobywaniu klientów i stanowi przyczółek do budowania tzw. mediów własnych.

W tego rodzaju przedsięwzięciach mniej się liczą potrzeby firmy, która zleca zrobienie strony, a bardziej to, czego oczekują jej przyszli klienci. Samo zrobienie witryny to jedna sprawa - w tym przypadku szczególnie istotny będzie wkład specjalistów UX czy osób zajmujących się SEO. Nawet jednoosobowe działalności gospodarcze opierają się często na profilach w mediach społecznościowych oraz wszelkiego rodzaju agregatorach wykonawców, natomiast mimo wszystko warto przemyśleć zlecenie i wypromowanie swojego adresu w Internecie, który można podawać, skupiać na nim klientów, zaprezentować się i potencjalnie zebrać kontakty w bardziej bezpośredni sposób. A także uniezależnić się od awarii znanych dużych mediów społecznościowych.

Pomysł na nowe usługi dla klientów

Wreszcie, po omówieniu tych bardziej standardowych rodzajach potrzeb, warto pamiętać, że firmy mają też oczekiwania mniej standardowe. Najczęściej związane są one z prowadzeniem konkretnego rodzaju działalności, czasem są to bardzo specyficzne pragnienia, a niekiedy po prostu pomysł na nowa gałąź biznesu.

Przykładowo, sieć punktów sprzedaży może potrzebować systemu lojalnościowego lub po prostu sklepu internetowego. Placówka edukacyjna może chcieć w łatwiejszy sposób obsługiwać plany zajęć. Firma posiadająca wiele maszyn może potrzebować regularnych odczytów ze swoich urządzeń. Agencja rekrutacyjna - obsługi spływających danych kandydatów. A prawie każde przedsiębiorstwo wraz ze wzrostem powinno pomyśleć o narzędziu pozwalającym znaleźć oszczędności lub analizować różnorakie dane.

Wróćmy jeszcze na chwilę do "nowej gałęzi biznesu" - istnieją firmy, które zajmują się konkretnymi rzeczami i robią to dobrze. Jednak mogą z łatwością rozszerzyć swoją działalność, udostępnić klientowi określoną aplikację i w ten sposób przyciągnąć nową grupę docelową bądź - jak to się mówi - wypłynąć na szerokie wody. Firma zajmującą się księgowością i kadrami może stworzyć rozwiązanie ułatwiające zgłaszanie danych swoim klientom, aby pozbyć się choć części niewygodnej papierowej lub mailowej części pracy. Firma usługowa lub produkcyjna, która do tej pory obsługiwała klientów telefonicznie czy mailowo, ma możliwość uruchomienia serwisu do składania zamówień bądź szacowania wycen. Muzeum może uatrakcyjnić swoje wystawy poprzez aplikacje ułatwiające zwiedzanie. Możliwości istnieją w większości branż - trzeba tylko je znaleźć.

Dodatkowo, nowe oprogramowanie może być użyte w stricte marketingowym celu. Przykładowo, szkoła językowa może zachęcać do skorzystania ze swoich usług poprzez wypuszczenie mobilnej gry edukacyjnej uczącej słówek. Schronisko dla psów (choć to mniej biznesowy przykład) może uruchomić akcję charytatywną, gdzie za kliknięcie zapewnia się karmę zwierzętom (przykład wspaniałej inicjatywy "Nakarm Psa"). Firma zajmująca się obsługą infrastruktury IT może zyskać na uruchomieniu serwisu z poradami na temat cyberbezpieczeństwa. I tak można długo wymieniać.

AI, LLM itd.

Tego tematu nie może zabraknąć. Wraz z pojawieniem się powszechnych rozwiązań stosujących zaawansowane narzędzia uczenia maszynowego, przedsiębiorcy od razu zainkorporowali je do swoich firm i wykorzystują do mniej lub bardziej właściwych celów. Trzeba uczciwie przyznać, że głosy mówiące, że AI zmienia prowadzenie biznesu, wcale nie są wyssane z palca i nawet, jeśli komuś się to nie podoba, to trzeba to przyjąć do wiadomości (i postępować etycznie).

Firma może zautomatyzować swoje procesy (np. obsługę klientów) poprzez chatboty korzystające ze sztucznej inteligencji. Jest ona również zdolna streszczać i tworzyć transkrypcje nagrań ze spotkań, co oszczędza czas. LLMy (takie jak ChatGPT) mogą być stosowane do tworzenia wewnętrznych baz wiedzy, wspomagania realizowania projektów, podsuwania pomysłów na różne kwestie, analizy raportów itd. Niektórzy biorą się nawet za instalowanie modeli językowych w swoim środowisku.

Możliwości jest bez liku i są firmy, które zajmują sie tylko i wyłącznie wdrażaniem rozwiązan AI do firm. Oczywiście, trzeba mieć świadomość, że sztuczna inteligencja nie rozwiąże i nie zastąpi ludzi w każdej kwestii (choć próby były i pewnie jeszcze będą). Natomiast nie można przejść koło tego obojętnie. Z tego powodu w cenie może być też możliwość kontaktu z ośrodkami naukowymi, choćby takimi jak Politechnika Poznańska. A zgadnijcie, kto może Wam pomóc w tym kontakcie.

I wy nam w tym pomożecie?

Oczywiście - oferujemy szeroką gamę usług. Swego czasu, nowy potencjalny klient zagadnął niżej podpisanego o to, jakie są specjalizacje Wilda Software i nieco się zdziwił, gdy okazało się, że tworzyliśmy aplikacje webowe i mobilne (ale nie tylko) dla wielu różnych gałęziach przemysłu i usług. Oczywiście, są obszary, z którymi mieliśmy zdecydowanie większy kontakt, jak firmy produkcyjno-usługowe, branża technologiczna czy help deski, natomiast w swojej historii mamy przedsięwzięcia z dziedzin, które trudno ubrać w konkretne ramy. Zachęcamy zresztą do przeczytania tekstu, w którym napisaliśmy o tym nieco więcej.

Mając dwie bazy produktów (ComMan oraz Feedybacky) możemy z większą łatwością zająć się kwestiami zarządzania zamówień, klientami, produkcją, magazynem, kadrami czy biurem obsługi klienta. Dodatkowo, nasz poziom zrozumienia środowiska akademickiego i związanego z innowacjami pozwala pomagać we wprowadzaniu nowych rozwiązań wymagających "dotknięcia" naukowego.

Pamiętajcie też, że nie zawsze software house taki, jak nasz, musi coś zrealizować - czasem wystarczy konsultacja lub analiza. Nierzadko z takiego, początkowo niepozornego kontaktu, kiełkowała bardzo dobra współpraca, kontakt i realizacje, więc nie należy się wahać pisać, nawet z pozornie prostą sprawą.

Podsumowanie

Każde przedsiębiorstwo, instytucja czy organizacja ma potrzeby w zakresie IT - wydaje się to oczywiste, ale niektórzy nie spodziewają się, że nawet w klasycznych branżach, opartych o siłę mięśni czy bezpośredni kontakt międzyludzki rozwiązania informatyczne też się przydają, a nawet bywają niezbędne. Im prędzej firma to zrozumie i zainwestuje choćby w konsultację z software housem, tym szybciej może osiągnąć przewagę rynkową, potencjalnie pozwalającą pchnąć swój biznes do przodu lub przynajmniej go porządkując. Czego Wam wszystkim życzę i mam nadzieję, że znaleźliście w tym tekście coś z obszarów, które Was najbardziej nurtują.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Gumowa kaczuszka na ratunek https://wildasoftware.pl/post/gumowa-kaczuszka-ratunek?ref=rss https://wildasoftware.pl/post/gumowa-kaczuszka-ratunek?ref=rss Thu, 08 May 2025 17:30:00 +0000 Dzisiaj zajmiemy się pewną legendą i żartem w gronie programistów. Ale czy powinienem w sumie nazywać to legendą? Istotnie, w społeczeństwie osób pracujących nad rozwiązywaniem problemów IT pojawia się ta praktyka i mimo że jest często traktowana z przymrużeniem oka, to ma swoje uzasadnienie. I nie mówimy tutaj o konkretnym narzędziu instalowanym na komputerze, dostępnym online czy elektronicznym sprzęcie, ale o zwykłym przedmiocie, który można chwycić w rękę, a nawet się z nim wykąpać.

Tak, dzisiejszy artykuł będzie o gumowej kaczuszce w kontekście programowania lub - jak ktoś woli - metodzie gumowej kaczuszki. Nie zwariowałem - poważnie, to tekst o tym zagadnieniu. Na blogu poważnej firmy IT.

Jak w ogóle... Skąd?!

Najpierw może powiedzmy sobie, o co w ogóle chodzi w tym dość zabawnym zagadnieniu. Programiści - jak każda grupa specjalistów i w ogóle ludzi - trafiają na błędy i problemy, które spędzają im sen z powiek. Nie chodzi tutaj często o jakieś bardzo skomplikowane wyzwania, które wymagają ogromnej wiedzy i czasu poświęconego na planowanie. Mowa głównie o kłopotach, które nazwalibyśmy "drobnymi, aczkolwiek denerwującymi", a te tym bardziej irytują, gdy intuicyjnie czujemy, że są proste w pozbyciu się, ale nijak nie możemy trafić na właściwą ścieżkę. Czasem wynika to z braku informacji, niekiedy z zapomnienia o konkretnym aspekcie, ale bywa, że działa tutaj także kolokwialne "zaćmienie umysłu". Krótko mówiąc - może być tak, że wszystko idzie wspaniale, ale natrafiamy na pozornie prostą przeszkodę, której przez długi czas nie możemy ominąć lub nawet porządnie przeanalizować. Warto też zaznaczyć, że skupimy się tutaj na błędach programistycznych.

Najczęstszym sposobem na rozwiązywanie takich błędów jest tzw. debugowanie (po polsku zwane "odpluskwianiem", gdyż to słowo rzeczywiście pochodzi od owadów gnieżdżących się w starych komputerach wielkości szafy). To proces polegający na krokowym uruchamianiu programu (wręcz linijka po linijka) i obserwowaniu, co dzieje się pod spodem, czyli jakie wartości przyjmują zmienne oraz w które miejsca kodu wchodzimy. Ten proces umożliwiają specjalne narzędzia dostępne w zintegrowanych środowiskach programistych (ang. Integrated Development Environment, w skrócie IDE), choć w prostszych sytuacjach można również sięgnąć do klasycznego i oficjalnie niepolecanego "debugowania printfami", czyli wypisywania komunikatów w odpowiednich miejscach i obserwowania logów. Poza debugowaniem istnieje też możliwość analizy statycznej, kiedy po prostu czytamy kod i rewidujemy potencjalne czynniki ryzyka lub w ogóle pomysł na rozwiązanie danego zagadnienia. Tego tematu jednak nie będziemy poruszać w tym artykule.

Bywa jednak, że debugowanie nie daje rezultatów - mimo że widzimy wszystko i wydaje nam się, że mamy wszystkie dane, to nie rozumiemy, jak może dochodzić do błędu. Nie pomaga też ani Stack Overflow, ani ChatGPT, ani żadna inna techniczna pomoc. Zaczynamy wręcz podejrzewać, że nie rozumiemy istoty rzeczy (do tego zdania jeszcze wrócimy). Słowem - utknęliśmy. Co wówczas robi taki stereotypowy programista, gdy zawiodą wszystkie środki techniczne? Bierze gumową kaczuszkę i zaczyna jej opowiadać o sytuacji - omawia problem, dane wejściowe, oczekiwany wynik, uzyskiwany rezultat, przechodzi przez ideę stojącą za poszczególnymi fragmentami kodu i nagle... pojawia się metaforyczna żarówka nad głową, a rozwiązanie staje się proste. Programista wówczas dziękuje kaczuszce, odkłada ją, naprawia problem i idzie grać w CS-a.

Brzmi niedorzecznie, prawda? Ale... działa. Przy czym, oczywiście, nie trzeba się ograniczać do kaczuszki lub w ogóle jakiegokolwiek przedmiotu. Ważne, aby rozumieć istotę tej koncepcji, nawet jeśli nie chcemy wchodzić stricte w zagadnienia psychologiczne i neurologiczne. Czego zresztą nie będziemy tutaj w szczegółach robić, ale podamy po drodze parę interesujących linków.

Myślenie na głos

Jesteśmy przyzwyczajeni do tego, że gdy czytamy, robimy to po cichu - po pierwsze, tak jest szybciej, a po drugie, nie przeszkadzamy innym. Podobnie jest z myśleniem, gdzie zwykle nie werbalizujemy tego, co układamy sobie w mózgu. Jest to zwyczajna oszczędność naszego aparatu mowy oraz otoczenia, a ponadto zazwyczaj wystarczy do poradzenia sobie z tym, co spotykamy w życiu. Ale nie zawsze tak jest - czasem trzeba zaangażować inne obszary naszego zbioru szarych komórek.

Osoby, które przez lata robiły notatki w sposób odręczny, a później przeszły na formę cyfrową, pewnie powiedzą, że zrobiły to ze względu na szybkość (faktycznie, jest szybciej, a po latach pisania na komputerze, tradycyjne ręczne zapiski są często niechlujne), dostępność technologiczną i łatwość kopiowania. To zrozumiałe i w większości przypadków jak najbardziej pożądane i wystarczające. Jednak wykorzystanie tradycyjnego przyrządu do pisania i kawałka papieru (od biedy rysika i tabletu) w większym stopniu zaprzęga do pracy mózg, aktywując bardziej złożone połączenia nerwowe i pobudzając pamięć. Angażuje rękę (specyficzne ruchy, które możemy potem odtworzyć), kreatywność (za każdym razem piszemy literki troszkę inaczej, co niekiedy zapamiętujemy), a także wymaga koncentracji (co ponownie pomaga w zapamiętywaniu). I faktycznie, gdy przypomnę sobie momenty, kiedy uczyłem się do egzaminów na studiach, to bardzo dużo korzystałem z przypominania sobie okoliczności, w których dana odręczna notatka powstała, a podczas samego sprawdzenia wiedzy, poza zrozumieniem tematu, miałem przed oczami nawet całe kartki papieru z moimi charakterystycznymi gryzmołami. W wersji cyfrowej (czyli "cichej", bardziej mechanicznej) też można zauważyć tego typu procesy, ale mają one słabszą moc.

Dlaczego w ogóle wspominam o pisaniu? Gdyż wypowiadanie swoich myśli na głos opiera się na podobnej idei - angażujemy kolejne partie ciała, koncentrujemy się na tym, co mówimy (werbalizacja myśli, szczególnie w obecności kogoś, wymaga zrozumiałego mówienia), "czyścimy" nasze myśli, a to sprzyja analizie informacji i ich poskładaniu, gdyż zwyczajnie nie możemy skrócić naszego wywodu i pominąć "niewygodnych" fragmentów, których wcześniej nie wyobrażaliśmy sobie jako "niewygodne".

Wróćmy teraz do zdania, które pojawiło się kilka akapitów wcześniej - jak sprawdzić, czy faktycznie rozumiemy nasz problem? Starajmy się znaleźć lub wyobrazić sobie laika i wytłumaczyć mu/jej (na głos) to zagadnienie. W ten sposób przy okazji analizujemy temat i uświadamiamy sobie luki w naszej wiedzy. Na pewno znamy osoby, o których powiedzielibyśmy, że "znają się na danym temacie, ale nie potrafią go wyjaśnić" - może to świadczyć o niedostatecznych umiejętnościach interpersonalnych (od razu powiem - nie jest to nic karygodnego), ale także o niewystarczająco dogłębnym zrozumieniu obszaru. Cała idea polega bowiem na tym, że gdy staramy się coś przekazać nowicjuszowi i okaże się, że czegoś nie umiemy wyrazić słowami bądź znaleźć analogii, to warto się zastanowić, czy tak naprawdę nie musimy sami się czegoś dowiedzieć i później ponowić "wykład". Im bardziej złożone zagadnienie, tym lepiej to widać - jeśli będziemy umieli je wytłumaczyć tak, że każdy to zrozumie, to oznacza, że naprawdę glęboko sami je rozumiemy, gdyż po drodze wiele fragmentów musi rozłożyć na czynniki pierwsze. Nie jest to nowa koncepcja - to wszystko nazywa się techniką Feynmana, gdyż właśnie wybitny fizyk, noblista z 1965 roku był propagatorem tej metody.

A co, jeżeli faktycznie komuś coś tłumaczymy i ten ktoś zadaje nam jeszcze pytania? Albo sami sobie zadajemy pytania podczas wykładu, prowadząc wyimaginowany dialog? Tym lepiej - zaczynamy otwierać się na aspekty, o których wcześniej nie pomyśleliśmy i które też musimy jakoś wytłumaczyć lub wziąć pod uwagę w projektowaniu. Przy okazji, istnieje taka koncepcja jak aktywne słuchanie, które polega na pełnym skupieniu na rozmówcu oraz tym, co mówi - wówczas więcej zapamiętujemy, lepiej przyswajamy informacje, a nawet uwzględniamy mowę ciała, emocje i rozwijamy więź z rozmówcą, co pomaga w dalszej relacji. To w mniejszym stopniu dotyczy naszego przypadku, chyba że jesteśmy na tyle empatyczni, że potrafimy wcielić się w nieistniejącego rozmówcę i kierować wobec siebie wątpliwości, z których wcześniej sobie nie zdawaliśmy sprawy.

Podsumowując ten fragment, rozmawianie z gumową kaczuszką podczas rozwiązywania problemu to niekoniecznie objaw choroby psychicznej, ale wytoczenie kolejnych dział umysłowych w celu zrozumienia trudności i pozbycia się jej. Zestawiamy się z drugą stroną i tłumacząc jej sytuację, sami zaczynamy dochodzić do rozwiązania lub przynajmniej identyfikujemy kwestie do dalszego sprawdzenia. Brak solucji nie musi bowiem oznaczać, że sami nie wiemy, czego szukamy - być może podczas tego procesu uświadomimy sobie, które obszary są dla nas niejasne i musimy o nich dowiedzieć się czegoś wiecej.

Nawiasem mówiąc, po przeczytaniu ostatniego zdania niektórym może przypomnieć się znane powiedzenie przypisywanie Sokratesowi, czyli "wiem, że nic nie wiem", a także tzw. efekt Dunninga-Krugera, które mowią o tym, że im głębiej drążymy daną dziedzinę, tym bardziej uświadamiamy sobie, ile wiedzy jeszcze mamy do zdobycia. Nie jest to jednak związane z gumowymi kaczuszkami - wspominam o tym w ramach ciekawostki oraz aby artykuł wyglądał na nieco mądrzejszy niż jest w rzeczywistości.

Czy musi to być gumowa kaczuszka?

Oczywiście, nie - gumowa kaczuszka jest tylko pewnym konceptem, memiczną wręcz ilustracją drugiej strony naszego dialogu, która pomaga w rozwiązaniu problemu. Ten sympatyczny (albo i nie) ptak wykonany z materiału pochodzenia chemicznego utarł się w powszechnej świadomości z uwagi na publikację "The Pragmatic Programmer: From Journeyman to Master" autorstwa Andrew Hunta i Davida Thomasa, gdzie pojawiła się technika "rubber duck debugging".

Tak naprawdę, najlepszym partnerem do rozwiązywania problemu byłaby druga osoba, najlepiej programista, w dodatku świeży w danym temacie, który nie jest "skażony" naszym procesem myślowym i spojrzy na sprawę bez uprzedzeń, z zupełnie innej perspektywy. To jest zresztą jeden z argumentów za inną metodą, programowaniem w parach, o ile partnerzy nawzajem się uzupełniają. Wiemy jednak dobrze, że czasem nie da się poprosić o pomoc innego człowieka lub nawet istoty ludzkiej (psy mądrze patrzą, gdy tłumaczy się im, co znajduje się w pętli lub ifie). W takim układzie zostaje przedmiot, którego wartość wzrasta, gdy choć trochę przypomina żywy organizm realnie nami zainteresowany - pluszowy miś sprawdzi się równie dobrze, choć gumowa kaczuszka ma dodatkowy ładunek pełen żartu, a także po prostu sympatyczny wygląd.

Można też mówić w przestrzeń, wyobrażając sobie rozmówcę lub stawiając w tej roli samego siebie. Jeśli ktoś ma dużą wyobraźnię oraz empatię, to jest to możliwe, choć prawdopodobnie mniej skuteczne niż przelanie tej "energii" w konkretny obiekt, do którego możemy mówić, spojrzeć na niego i wyobrażać sobie, że nam odpowiada, podczas gdy tak naprawdę to my sami w swojej głowie rozkładamy problem na części pierwsze, próbując złożyć rozwiazanie.

Czy to realnie działa?

Tak - zdarzają się sytuacje, w których programista utknął i trudno mu ruszyć dalej "normalnymi" metodami, choć, na szczęście, należą one do rzadkości. Gdy jednak się pojawiają, warto pamiętać o metodzie gumowej kaczuszki, choć czasem trzeba się przełamać, aby skorzystać z tego triku psychologicznego. Warto to jednak zrobić, gdyż wówczas można też się dowiedzieć więcej o sobie samym i tym, jak realnie rozumujemy to, co piszemy w kodzie (i nie tylko).

Sama gumowa kaczuszka jako przedmiot przedstawiający pociesznego ptaka jest też znakomitym pomysłem na prezent dla programisty, wywołujący uśmiech na twarzy i stanowiący ozdobę biurka. A w razie potrzeby można go nawet wziać do wanny.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Rodzaje firm programistycznych https://wildasoftware.pl/post/rodzaje-firm-programistycznych?ref=rss https://wildasoftware.pl/post/rodzaje-firm-programistycznych?ref=rss Thu, 27 Mar 2025 17:30:00 +0000 W dzisiejszym tekście skrótowo opiszemy sobie rodzaje firm zajmujących się programowaniem, a przy okazji odniosę się do jednej cechy takich firm jak choćby Wilda Software, która niezmiernie mnie zawsze cieszy, gdy o niej myślę (ta cecha, ale też i firma). I nie tylko mnie - na tę charakteryczną rzecz zwracają uwagę też np. osoby zajmujące się consultingiem dla różnych branż czy specjaliści oferujący opracowywanie strategii marketingowych.

Firmy programistyczne możemy podzielić na kilka głównych kategorii:

  • zajmujące się konkretną aplikacją lub ich zbiorem,
  • tworzące i oferujące różne oprogramowanie na rynek,
  • software house'y tworzące dla klientów z różnych dziedzin,
  • software house'y specjalizujące się w konkretnej branży,
  • tworzące małe projekty, nierzadko powiązane z działaniami okołomarketingowymi,
  • wdrażające i dostosowujące konkretne oprogramowanie (partnerzy technologiczni, autoryzowane serwisy, dystrybutorzy),
  • świadczące usługi bodyleasingowe.

Poniżej omówimy sobie każdy z tych rodzajów, przedstawiając bardzo ogólny profil działalności i przykłady tam, gdzie jest to możliwe. Nie będzie to szczegółowa analiza, a raczej uświadomienie osobom spoza branży, że firma programistyczna nie musi być równa innej pozornie tożsamej firmie. Warto zauważyć, że artykuł traktuje o podmiotach oferujących tworzenie lub rozwój oprogramowania - to zawężony obszar w stosunku do ogólnie firm IT, które mogą uwzględniać np. usługi sprzętowe, administracyjne, serwisowe itd. Nie dzielimy tutaj też realizatorów ze względu na rozmiar - wiadomo, że firma mająca 15+ będzie różniła się możliwościami i ceną od takiej posiadającej 60+ specjalistów, a ta z kolei nie będzie mogła być przyrównywana do molocha z setkami czy tysiącami osób.

Należy też pamiętać, że przedstawiony podział nie jest sztywny - wiele spółek łączy cechy pochodzące z kilku obszarów działalności. To oznacza, że nie trzeba zakładać z góry, że wybrana przez nas firma czegoś nie zrobi - warto zapytać, gdyż często może się okazać, że wykonawca może dla nas przygotować dodatkową ofertę lub wskazać zaprzyjaźnionych partnerów, którzy mogą nam pomóc.

Startupy

Rozdziały będę nazywał nieco inaczej niż powyższe punkty i często troszeczkę "clickbaitowo", ale chodzi o to, aby w treściwy sposób nazwać poszczególne typy firm. Mam nadzieję, że mi wybaczycie.

Na pierwszy ogień idą firmy zajmujące się konkretną aplikacją lub ewentualnie całymi systemami wiążącymi wiele programów. Często są to startupy, tzn. innowacyjne firmy, które wyrosły właśnie z chęci wprowadzenia czegoś swojego, zyskały na to budżet (czasami w postaci dofinansowania) i probują podbić kawałek świata. Jak wiemy, jest to trudna sztuka i szacuje się, że znakomita większość (nawet 90%) takich przedsięwzięć po prostu upada, jednak te, którym się udaje, skupiają się później na utrzymaniu i rozwoju takiej aplikacji. Czasem takie firmy stają się naprawdę duże i każdy z nas zna przykłady - Spotify, Netflix, nasz rodzimy XTB czy nawet Google (jako gigant mający pod sobą stowarzyszone ze sobą usługi) to jedne z pierwszych przedsiębiorstw, które każdemu przychodzą do głowy. Ale, oczywiście, samo określenie "startup" najczęściej kojarzy się z małymi zespołami, które w pocie czoła próbują zawładnąć ludzkością ze swojego garażu w Dolinie Krzemowej.

Czasem firmy innego typu również wprowadzają swoje aplikacje na rynek (jak np. my robimy z Feedybackym), ale działa to też w drugą stronę - startupy, które orientują się, że los ich przedsięwzięcia jest bardziej niepewny niż myśleli, mogą zdecydować się na przyjmowanie dodatkowych zleceń od klientów.

Specyfiką pracy w takiej organizacji jest to, że pracownik zajmuje się stricte jedną aplikacją lub nawet konkretnym komponentem całego ekosystemu. To sprawia, że jest w nim całkowicie "zanurzony", przywiązuje się do swojego obszaru i staje się w nim specjalistą, nierzadko śledząc też pozatechniczne aspekty tego, co robi, a nawet będąc swoistym ambasadorem swojego dzieła. Wadą dla niektórych może być to, że pracując przez wiele lat nad jedną aplikacją, taka osoba może się wypalić, "zastać" w danej technologii i zwyczajnie znudzić, choć to zdarza się także w innego rodzaju spółkach. W tego typu firmach mamy też więcej osób zajmujących się kwestiami biznesowymi, marketingowymi itd. - w końcu starają się sprzedać coś na rynek, więc potrzebny jest np. product manager.

Producenci

Nazwa dość dziwna w tym kontekście, gdyż kojarzy się z firmami wytwarzającymi fizyczne dobra. Tym niemniej, trudno tutaj o lepszy termin.

Jest to rozwinięcie poprzedniego punktu, często zresztą zaczynające się od niego i dotyczące firm, które zostały pozytywnie przyjęte na rynku, w związku z czym planują dalszą ekspansję, uruchamiając kolejne usługi lub patronując zewnętrznym aplikacjom. Mogą to być firmy działające w konkretnym segmencie (jak np. Autodesk z narzędziami dla projektantów), ale często ten punkt kojarzy się ze znacznie szerszym zakresem. Tutaj od razu narzuca się Microsoft, który oprócz Windowsa ma w swoim portfolio chociażby Office'a, programy do modelowania, systemy zarządzania bazami danych, wyszukiwarki, przeglądarki, komunikatory, ale też choćby gry.

I właśnie producenci gier mogą być kolejnym dobrym, a nawet lepszym przykładem firm z tego obszaru, gdyż te większe wydają wiele tytułów, czasem pracując równocześnie nad kilkoma i celują w większy segment rynku, zyskując zainteresowanie graczy, a więc klientów. Oczywiście, branża rozrywki elektronicznej już dawno przestała być romantyczna i z czasem stała się po prostu biznesem, często (choć, na szczęście, nie zawsze) nastawionym wyłącznie na zysk, stosując brutalne prawa rynku, o czym co jakiś czas się boleśnie przekonujemy, czytając o przejęciach lub zamknięciu kolejnych studiów.

Wróćmy jednak do pozytywnej strony takich firm - łączą one zalety startupów oraz software house'ów (do których zaraz przejdziemy) z tego względu, że pracując w nich specjaliści mogą poruszać się pomiędzy projektami (oczywiście, w zależności od ustaleń i potrzeb), a jednocześnie mają poczucie, że robią coś, co jest wykorzystywane przez wiele osób. Z drugiej strony, opieranie działalności firmy na proponowaniu swoich produktów rynkowi jest ryzykowne - wymaga doskonałego marketingu, renomy, świetnej analizy biznesowej lub łutu szczęścia. Przypomina to trochę branżę filmową, muzyczną czy literacką.

Software house'y

Dochodzimy do obiecanego we wstępie fragmentu, w którym opowiemy trochę o takich firmach, jak nasza, czyli Wilda Software. Software house'y to firmy, które żyją głównie ze zleceń klientów i tworzą oprogramowanie na zamówienie. To nie oznacza, że nie mogą oferować rynkowi swoich produktów, ale zdecydowanie częściej mamy tutaj do czynienia ze zdobywaniem zaufania w segmencie B2B (rzadziej B2C), spersonalizowaną analizą wymagań oraz architektury, a także niekiedy dostosowania swojej technologii do potrzeb danego projektu. Krótko mówiąc, takie firmy mają wiedzę i środki, aby stworzyć oprogramowanie marzeń klienta, gdzie to ten ostatni jest pomysłodawcą. Jest to usługa bardzo podobna do tych znanych z innych branż - nie należy obawiać się kontaktu z software housem - rozmowa nic nie kosztuje, a tam też pracują ludzie :)

Największa zaleta pracowania w firmie o takim profilu to różnorodność projektów. Muszę Wam się przyznać, że w czasie mojej praktyki programistycznej, dzięki funkcjonowaniu w software housie mogłem dowiedzieć się wielu rzeczy o:

  • serwisowaniu i odczycie danych urządzeń drukujących,
  • procesie produkcyjnym elementów metalowych, szyb hartowanych, artykułów papierniczych, rur kanalizacyjnych,
  • branży reklamowej i kulisach działalności kierownictwa bardzo dużych firm,
  • rekrutacji i zagranicznym rynku pracowników,
  • formach podpisywania umów,
  • zwyczajach japońskiej pomocy technicznej,
  • lekcjach jeździectwa,
  • moczniku,
  • przygotowywaniu długotrwałych i obciążających zasoby renderów 3D,
  • domofonach,
  • klubach sportowych,
  • branży kosmetycznej,
  • branży kolekcjonerskiej,
  • kontrolerach do gier.

A to zaledwie skrawek obszarów, o których ja bądź moje koleżanki i koledzy mieli okazję porozmawiać lub realizować na przestrzeni wielu lat. Tworząc lub analizując oprogramowanie dla różnych branż, człowiek musi choć w podstawowym stopniu poznać terminologię, którą operuje klient, poczytać o fundamentach działania branży, poznać różne wzory i ogólnie zainteresować się domeną klienta. To nie oznacza, że musimy stać się specjalistami np. w produkcji kolorymetrów i klienci też tego nie oczekują. Ale pragnąc lepiej zrozumieć środowisko, w którym będziemy się obracać, należy choć trochę je zrozumieć, co zresztą często dzieje się samoistnie, podczas realizacji.

Tego typu doświadczenia mają też między innymi wcześniej wspomniane firmy consultingowe czy agencje marketingowe - mamy tutaj do czynienia z bardzo dużą różnorodnością i przekrojem branż, dzięki czemu rzadko dotyka nas nuda, a i człowiek może sie dowiedzieć czegoś nowego. Różne osoby w firmie pracują nad różnymi projektami, wymieniają się doświadczeniami i sprawiają, że wokół jest ciekawiej. Można też swobodniej przechodzić z jednego przedsięwzięcia do drugiego, co ma zresztą miejsce w przypadku zintensyfikowania prac nad danym projektem w momencie, kiedy jest to potrzebne. Dodatkowo, nierzadko konkretne aplikacje wymagają specyficznego podejścia bądź technologii, co też wymusza rozwój w postaci poznawania narzędzi spoza stosu technologicznego firmy. W startupach też to ma miejsce i dodatkowo jest tam więcej miejsca na eksperymenty, ale jednak w software house'ach motywacja bywa większa z uwagi na chęć współpracy ze zleceniodawcą.

Co więcej, nic (poza czasem) nie stoi na przeszkodzie, aby software house rozwijał także swoją odnogę produktową, proponując pewne rozwiązania "od siebie" - w naszym przypadku jest to wspomniany już Feedybacky, a także ComMan. Jednak, w przeciwieństwie do wcześniej opisywanych typów firm, tutaj nie ma na to nacisku - jest to dodatkowy kierunek, którym można podążać, ale nie coś, od czego zależy istnienie spółki. Priorytetem są zlecenia od klientów.

Wady? Oczywiście, też można je znaleźć. Należy pamiętać, że duża różnorodność i rozpiętość klientów sprawia, iż programiści mniej utożsamiają się z danym projektem. To niekoniecznie musi być słabość, ale nie wszystkim pracownikom IT to pasuje - trzeba to uszanować, gdyż są osoby, które lepiej czują się w środowisku startupowym, jak i takie, które prędzej odnajdą się w firmie "żyjącej" ze zleceniodawców. Należy też pamiętać, że atmosfera w obu typach firm jest inna - o ile w startupach czy u producentów następuje większa kumulacja "wizjonerstwa" (w pozytywnym aspekcie) i skupienia na jednym lub kilku aplikacjach, tak w software house'ach rozwój jest bardziej wszechstronny, choć ukierunkowany w celu zarządzania dobrem firmy, a nie tylko produktu.

"Dedykowane" software house'y

Pewną odmianę software house'ów stanowią takie, które skupiają się na konkretnej gałęzi przemysłu czy usług lub nawet konkretnych typach projektów. Istnieją firmy specjalizujące się np. w aplikacjach dla branży hotelowej, mieszkaniowej, prawniczej lub sportowej. Wielu z nas dobrze też kojarzy firmy wspomagające swoimi usługami placówki edukacyjne. Coraz częściej też na rynku ujawniają się zespoły specjalizujące się w automatyzacji procesów (mimo że tak naprawdę może to oznaczać tworzenie "zwykłych" aplikacji wspomagających pracę firm), a także w sztucznej inteligencji.

Co to oznacza? To, że takie firmy IT często posiadają osoby będące bliżej deklarowanej specjalizacji, nierzadko wręcz jej przedstawicieli (np. prawników, hotelarzy), którzy swoim zrozumieniem domeny biznesowej mogą jeszcze bardziej pomóc klientom o konkretnym profilu. Tutaj trzeba pamiętać, że to, co jest oczywistą zaletą (czyli ukierunkowanie software house'u na dany temat niosące potencjalnie większą skuteczność), może też być wadą - jeśli w jakiejś branży jest zastój, to i firmy ją obsługujące mają problemy, o czym czasami, niestety, przekonują się podwykonawcy z przeróżnych branż produkcyjnych. Dodatkowo, czasem spojrzenie na sprawę firmy zupełnie z "innej bajki", niedziałającej na co dzień w danej branży, może pomóc w zaplanowaniu zupełnie nierozważanych, ale potrzebnych zmian. Pamiętajcie zresztą, że swój wymarzony pomysł na projekt IT warto konsultować z kilkoma firmami, aby poznać różne perspektywy.

Prawda jest taka, że każdy software house, nawet jeśli świadczy swoje usługi firmom w różnych branżach, ma swoje obszary, w których specjalizuje się z racji swojej historii oraz posiadanej załogi. W naszym przypadku są to głównie większe systemy wewnętrzne, mające optymalizować i wspomagać pracę pracowników konkretnej spółki, zarządzanie zakładami produkcyjno-usługowymi, a także zasobami uczelni wyższych. Jednak, jak już pisałem wyżej, obsługiwaliśmy i nadal obsługujemy bardzo różne projekty, nierzadko o profilu kompletnie odbiegającym od tych z poprzedniego zdania.

Agencje interaktywne

Teraz wejdziemy na trochę inną ścieżkę. Wyżej wspominałem o systemach wewnętrznych, które są naszą domeną, ale dobrze wiemy, że praktycznie każda działalność potrzebuje (i to co najmniej jedną) publiczną stronę, na której może przedstawić swoją ofertę, zaprezentować się i zachęcić do kontaktu. Krótko mówiąc, na rynku potrzebni są wykonawcy realizujący strony o charakterze marketingowym, landing page, a także różne witryny e-commerce. Tutaj dochodzimy między innymi (bo, oczywiście, nie tylko one się tym zajmują) do agencji interaktywnych.

Są to firmy (zwykle mniejsze, ale niekoniecznie), które mogą skupić się na tego typu platformach także dlatego, że poza specjalistami IT posiadają osoby zajmujące się na co dzień marketingiem, PR-em, pozycjonowaniem i innymi kwestiami, które są nierozerwalnie związane z oprogramowaniem, ale niekoniecznie mieszczą się w technicznej dziedzinie. Z perspektywy programistycznej można bardzo stereotypowo powiedzieć, że tego typu firmy tworzą strony dużo ładniejsze, skupiają się na frontendzie i przygotowaniu pod marketing, ale zwykle są to mniejsze, krócej trwające zlecenia. Jasne, że nie musi być to prawda, a tak samo, jak "zwykły" software house poradzi sobie z landing pagem, tak agencja interaktywna może zgromadzić zasoby wymagane do uruchomienia ogromnej platformy newsowej czy społecznościowej.

W tym segmencie często działają też freelancerzy, czyli pojedyncze osoby będące wolnymi strzelcami, którzy pracują na własny rachunek i świadczą usługi programistyczne. Z racji bycia takim samotnym wilkiem, nie mają takich możliwości, jak cały zespół, ale jak najbardziej mogą pomóc przy zaplanowaniu i przynajmniej częściowej realizacji infrastruktury aplikacyjnej mniejszego biznesu. Nierzadko też takie osoby (a przynajmniej tak wynika z mojego doświadczenia) mogą pomóc w zaprojektowaniu działań bardziej marketingowych, choć to zależy już od konkretnego przypadku.

Autoryzowani partnerzy

Na pewno kojarzycie firmy, które jak najbardziej świadczą usługi programistyczne, ale przede wszystkim skupiają się na wdrażaniu i dostosowywaniu konkretnego oprogramowania lub systemów jakiejś firmy. Taki model jest często spotykany w firmach IT związanych ze sprzętem, które są autoryzowanym partnerem i serwisem np. danej marki drukarek. Jednak w branży programistycznej również to działa - pierwszym przykładem, który przychodzi na myśl, to Comarch, ich pakiet Optima i wiele firm, które "namaszczone" przez krakowską korporację świadczą usługi wdrożeniowe oraz konsultingowe w tym zakresie. Podobnie rzecz się ma z firmami dostosowującymi Microsoft Dynamics NAV, SAPem. Istniejąteż np. firmy będące certyfikowanymi partnerami Microsoftu i tutaj od razu nasuwa mi się CodeTwo, które wielu z nas doskonale kojarzy z sympatycznego kanału na YouTube o nazwie "HRejterzy".

Body leasing

Jakby nie patrzeć, software house'y to grupy najemników - można wynająć część ich zasobów do stworzenia upragnionego oprogramowania. Można też pomyśleć o tym, jak o "wyjęciu" programistów do swojego zespołu, zwłaszcza, jeśli klient już ma swoich specjalistów tworzących oprogramowanie i pion kierowniczy, tylko zwyczajnie brakuje im ludzi na pewien okres. Czy jest to możliwe? Ależ, oczywiście.

Taka usługa nazywa się "body leasing" i choć brzmi, jak określenie z fantastyki, horroru czy działalności przestępczej (a może to już wpływ mojego umysłu zwichrowanego rozmaitą literaturą kryminalną), to jest jak najbardziej normalnym biznesem, w którym można wynająć programistów "na godziny", w celu zwiększenia swojej mocy sprawczej. Oczywiście, w tym przypadku te godziny należy raczej rozumieć jako tygodnie lub miesiące, natomiast co do zasady działa to tak, jak np. uruchomienie większej liczby serwerów w chmurze podczas większego obciążenia serwisu.

Ten tryb działania software house'u różni się od wcześniej omawianego kilkoma aspektami:

  • programiści pracują nie w stałym zespole firmy, tylko bezpośrednio dla swojego klienta, z nowymi kolegami i koleżankami,
  • kierownictwo projektu zlokalizowane jest u klienta, a nie w software housie (choć, oczywiście, ten ma pewną kontrolę nad swoimi podopiecznymi i samym przedsięwzięciem),
  • programiści zazwyczaj mają jeszcze szersze horyzonty technologiczne, zważywszy na różne potrzeby klientów.

Bywa tak, że "normalne" firmy IT, oprócz standardowych usług, dopuszczają body leasing jako jedną z form usługowych, ale są też na rynku spółki, które działają tylko w taki sposób.

Podsumowanie

Jeśli chcesz wynająć firmę programistyczną do urzeczywistnienia swojej wizji oprogramowania, to oprócz tego, że bardzo się z tego cieszymy (i zapraszamy do kontaktu), to zwracamy uwagę, że w przestrzeni firm IT istnieją ich różne rodzaje. Podobnie, jak z lekarzami, do innej firmy pójdziemy z potrzebą ogromnego systemu dla milionów osób, gdzie indziej w celu zaplanowania procesu marketingowego wspieranego przez narzędzia IT, a jeszcze gdzieś indziej, gdy szukamy narzędzia dla siebie.

Należy też pamiętać, że w przeważającej większości firm konsultacja nic nie kosztuje - warto rozmawiać z wieloma dostawcami w celu wybrania najlepszego i zapoznania się z różnymi spostrzeżeniami oraz strategiami rozwiązania naszego problemu biznesowego.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Idealny Product Owner https://wildasoftware.pl/post/idealny-product-owner?ref=rss https://wildasoftware.pl/post/idealny-product-owner?ref=rss Thu, 20 Mar 2025 17:30:00 +0000 Z góry przyznaję, że tytuł tego artykułu jest... kłamstwem. Nie będzie on opowiadał o ideale, który jest receptą każdego software house’u na doskonałe prowadzenie projektów (a właściwie produktów - do tego jeszcze wrócimy). Powód jest prosty - ideały nie istnieją. Nawet jeśli jakimś cudem bylibyśmy w stanie wyróżnić najlepsze osoby w branży w jakiejkolwiek dziedzinie, to i tak zawsze znajdą się elementy, w których mają coś do poprawy lub znajdzie się lepszy specjalista od nich. Nawet najlepszy proces rekrutacji okraszony masą szczęścia oraz samorozwój nie doprowadzą nas do perfekcji. Ale to nie oznacza, że nie można się starać.

Nie jest tajemnicą, że w Wilda Software mamy managerów - nie jest to dziwne z uwagi na to, że zawsze, nawet w stosunkowo niewielkiej firmie, osoby kierujące pracami są potrzebne, a poza tym widzieliście pewnie nasze ogłoszenia, w których poszukiwaliśmy osobę na rolę Product Ownera. Przez ten czas mieliśmy kontakt z różnymi stylami prowadzenia projektów lub produktów, z dobrymi i złymi momentami, więc siłą rzeczy wypracowaliśmy wnioski, z którymi chcielibyśmy się z Wami podzielić.

Jaki zatem powinien być idealny Product Owner? Żeby odpowiedzieć na to pytanie, musimy najpierw zdefiniować sobie, o kim właściwie mówimy.

Kim jest product owner?

Zacznijmy nietypowo - zapytajmy najlepszego (niestety) przyjaciela wielu z nas o definicję tej roli. Oczywiście, mowa o ChatGPT:

Product Owner (PO) to kluczowa rola w ramach metodyki Scrum, odpowiedzialna za maksymalizowanie wartości produktu. PO działa jako łącznik między interesariuszami a zespołem deweloperskim, dbając o to, aby produkt spełniał wymagania biznesowe i użytkowników.

Jest to właściwa definicja, to znaczy rzeczywiście w taki sposób określa się ten zakres obowiązków w zespole. To termin ściśle związany z metodyką scrum, gdzie rozróżnia się właśnie PO oraz Scrum Mastera (SM). Do tego jeszcze dzisiaj przejdziemy - na razie skupmy się na naszym ownerze.

Człowiek pełniący tę rolę zarządza powstawaniem produktu i jest odpowiedzialny za dostarczanie płynącej z niego wartości. Jednak teraz musimy wyjaśnić sobie jeszcze jedną rzecz - dlaczego "produktu", a nie "projektu"? Z jednej strony jest to kwestia stricte terminologiczna, gdyż zazwyczaj zespół pracujący zwinnie tworzy właśnie produkt, a więc jeden kawałek oprogramowania lub przynajmniej pewien spójny ekosystem, który jest oferowany klientowi - projekt to szersze zagadnienie i cały proces powstawania produktów oraz ich projektowania. Z drugiej strony, często kojarzymy produkt jako coś, co jest przeznaczone do radzenia sobie w pewnym środowisku i trzeba tak umiejętnie sterować jego rozwojem, aby wpasował się w oczekiwania użytkowników, a przede wszystkim klientów. Czyli niekoniecznie jest to zarządzanie w sensie harmonogramu, budżetu i czymś, co zostało określone z góry i po prostu trzeba to doprowadzić do końca - tutaj mówimy o zarządzaniu w sensie analizy i zaproponowania czegoś, czego być może klient nie zdefiniował wprost (nakreślając jedynie swoje oczekiwania), ale my jesteśmy odpowiedzialni za zaproponowanie i dostarczenie odpowiedniego rozwiązania. W tym miejscu niektórzy mogą skojarzyć określenie "Product Manager", które pewnie nieraz widzieliście na profilach na LinkedInie - to określenie z kolei jest bardziej związane z produktami, które są proponowane na rynku, a nie powstają na zamówienie. Co za tym idzie - tutaj taka osoba musi również śledzić trendy i umieć proponować rozwiązania bez jasnych wskazówek, opierając się na analizie biznesowej, technicznej, ale też marketingowej. Lub być wizjonerem, tak jak Steve Jobs.

"Ale to zagmatwane", pewnie niektórzy powiedzą. I co ciekawe, zgadzamy się - tak naprawdę główny czynnik odróżniający typowego Project Managera od Product Ownera to fakt, że ten drugi zarządza powstawaniem produktu i jest "bliżej" go, ale w zamian nie jest aż tak zaangażowany w sprawy budżetowe. Co nie oznacza, że nie powinien rozumieć, że niektóre działania mają też podłoże bardziej biznesowo-finansowe, a dodatkowo wypada, żeby zainteresował się harmonogramem. W mniejszych firmach, gdzie nie ma wielopoziomowej drabinki zarządzania, siłą rzeczy owner jest trochę managerem, ale w mniejszym stopniu odpowiada za kwestię rozliczeń - te nadal przechodzą przez wyższe kierownictwo.

Proponuję również nie zastanawiać się, czy bardziej powinniśmy nazywać taką osobę "Product Ownerem", czy "Project Ownerem" - dlatego u nas często mówimy po prostu "owner", co pewnie będzie gryzło purystów scrumowych, ale jakby nie patrzeć, scruma, jak każdą metodykę, też się dostosowuje pod swoje potrzeby.

Zarządzanie backlogiem

W dawnych czasach, gdy uczyłem się zarządzać projektami najpierw teoretycznie, a później w praktyce (dzięki programowi SDS) na specjalności Software Engineering na Politechnice Poznańskiej, dzieliło się zarządzających na:

  • kierownika projektu - pilnował harmonogramu, dbał o komunikację, reprezentował zespół na zewnątrz, miał najszerzej zakrojone umiejętności miękkie.
  • analityka - zarządzał wymaganiami, analizował oczekiwania klienta i przekładał je na język techniczny, potrafiąc ocenić nie tylko poprawność obliczeń, ale też stopień spełnienia wizji odbiorcy.
  • architekta - projektował architekturę oprogramowania, był głównym konsultantem technicznym i dbał ogólnie o technikalia, wraz z konsekwencjami wyborów.

Z oczywistych względów Product Owner nie jest architektem, gdyż tym zajmuje się CTO lub inna wyznaczona osoba w danym projekcie. Natomiast - czy bliżej mu do kierownika projektu, czy analityka? W pewnym stopniu posiada cechy jednego i drugiego, ale na pewno umiejętności analityczne są bardzo mile widziane u takiej osoby. Zwłaszcza, że o analityku można powiedzieć, że jest "proxy klientem", czyli kimś, kogo można zapytać o to, co klient by powiedział w danej sytuacji.

Właściciel produktu to ktoś, kto ma pełną wiedzę o tym, czym produkt ma się stać, jakie są cele klienta i całego projektu, a także nad czym aktualnie mają trwać prace i w jaki sposób są realizowane. To na ownerze spoczywa odpowiedzialność za:

  • ustalenie z klientem zakresu sprintu (oraz, szerzej, projektu),
  • opis i zrozumienie wymagań (zarówno funkcjonalnych, jak i pozafunkcjonalnych),
  • konsultację z klientem w sprawie wybranych wersji wymagań oraz ich zakres godzinowy (czyli, mówiąc wprost, zarządzanie wyceną),
  • priorytety zadań,
  • analizę różnych opcji i doradzanie zespołowi w przypadku wątpliwości,
  • walidację zrealizowanych zadań pod kątem biznesowym,
  • kontrolę zadań, które czekają na realizację, a chwilowo zostały wstrzymane,
  • dystrybuowanie zadań wewnątrz zespołu, także biorąc pod uwagę zgłoszenia serwisowe.

Krótko mówiąc, owner ma wiedzę o wszystkich zadaniach, które były realizowane, obecnie są wykonywane lub tych, które czekają zespół w przyszłości. To ta osoba jest często adresatem pytań programistów w stylu "czym się teraz warto zająć?" lub "jak to powinno być zrobione?" albo "co klient powiedziałby na to?", co wymaga odpowiedniego stopnia samoorganizacji i doboru odpowiednich lub wykorzystania istniejących narzędzi. Owner często żongluje też poprawkami serwisowymi lub gwarancyjnymi w taki sposób, aby z jednej strony nie kazać klientowi długo czekać, ale z drugiej też nie zaniedbać aktualnie zleconych prac. Dodatkowo, musi tak ułożyć zadania, aby w razie niemożliwości skończenia wszystkiego w terminie, zrobić jak najwięcej realnie potrzebnych i wartościowych rzeczy.

Takie jest właśnie zadanie ownera - doprowadzić zespół do dostarczenia wartości biznesowej dla odbiorcy. To siłą rzeczy wymaga wiedzy i umiejętności kolejkowania zadań w backlogu (a więc rejestrze zadań), a czasem nawet bycie swoistą bazą wiedzy o produkcie, nierzadko uwzględniającą historię rozmów ze zleceniodawcą. Różni właściciele produktu podchodzą do tego w różny sposób - ci bardziej techniczni lepiej radzą sobie z niuansami każdego zadania i są bliżej myślenia programistów, natomiast są osoby, których kwestie techniczne mniej interesują, natomiast potrafią lepiej zrozumieć nietechniczny punkt widzenia klienta. Oczywiście, bardzo to upraszczam, ale faktem jest, że każdy ma trochę inne doświadczenia i predyspozycje.

Wśród powyższych punktów pojawił się temat walidacji i spokojnie - nie chodzi o to, aby product owner był najbardziej wytrwałym członkiem zespołu QA, natomiast fakt jest taki, że powinien w miarę możliwości przeklikiwać oprogramowanie i to z co najmniej trzech względów. Po pierwsze, uspokaja się przy tym, że wszystko działa, a to owner jest główną osobą, która w razie czego dostanie "bęcki" od klienta (ale też pochwałę, gdy ten będzie zadowolony). Po drugie, siłą rzeczy w ten sposób uczy się systemu, co bardzo ułatwia późniejsze prezentacje lub generalnie rozmowy o rozwoju, zyskując zaufanie w oczach zleceniodawcy. Po trzecie i najważniejsze - w ten sposób może wyłapać błędy nie na poziomie technicznym, ale w zrozumieniu oczekiwań klienta. Zdarza się bowiem, że programista realizuje wymaganie w pełni zgodnie z kryteriami funkcjonalnymi i obliczeniowymi (weryfikacja przeszła poprawnie), ale to wszystko jest widoczne w systemie w taki sposób, że użytkownik na pewno z tego nie będzie mógł wygodnie korzystać (walidacja wykazała błędy). Product Owner, jako osoba mająca wiedzę o tym, jak użytkownicy będą korzystali z systemu i jakie mają kompetencje techniczne, może zareagować i to w dwojaki sposób:

Szczególnie na DoDy warto zwrócić uwagę, gdyż owner jest naturalną osobą, które może rozpisać takie punkty, dodatkowo określając powiązania logiczne pomiędzy różnymi zadaniami. Jednak bywa też tak, że owner musi stworzyć prościutką, amatorską makietę, aby pokazać programiście "tak to ma wyglądać".

Wizja produktu i jego cele

Wyżej wspominałem już o tym punkcie, ale trzeba powtórzyć - Product Owner ma pełną wiedzę o tworzonym produkcie, nawet większą pod kątem biznesowym niż technicznym. On najlepiej z całego zespołu rozumie, do czego klient chce dotrzeć i jak wyobraża sobie narzędzie, które dla niego tworzymy. Nie ma z tym problemu, gdy jest to w miarę standardowe przedsięwzięcie, gdyż software house wie, jakie są pewne trendy na rynku. Gorzej, jeśli klient daje do zrozumienia, że on będzie korzystał z oprogramowania w inny sposób niż standardowy lub ma bardzo specyficzne wymagania (wynikające czasem z branży). Może też zaistnieć sytuacja, że do tej pory korzystał ze starszego systemu, do którego się przyzwyczaił lub z którego trzeba przenieść dane o pewnej strukturze.

Product Owner musi to wszystko wiedzieć i - co ważniejsze - rozumieć. Jeśli nawet coś wydaje się mniej szablonowe niż w innym oprogramowaniu, to konieczne jest zrozumienie, czy to bardziej niewiedza zleceniodawcy dotycząca tego, jak teraz się rozwiązuje pewne kwestie (bywa i tak), czy przemyślane, rzeczywiste wymaganie, które trzeba spełnić. W pierwszym przypadku owner ma większą swobodę propozycji zrealizowania określonej kwestii lub nawet zapunktowania tym, że wychodzi naprzeciw klienta i jest kreatywny. W drugim - musi przyjąć wizję odbiorcy jako wymaganie pozafunkcjonalne i wokół tego ułożyć inne rzeczy.

Zespół musi wiedzieć, że może polegać na ownerze jako osobie, która zawsze wie, czego chce klient, a jeśli nawet nie wie, to potrafi o to "efektywnie" dopytać, tj. pokazać, że rozumie ideę, ale potrzebuje jej uszczegółowienia. Umie też odfiltrować rzeczy, o których zleceniodawca mówi, że "fajnie by było" od tych, które realnie są mu potrzebne (nawet, jeśli nie zostaną powiedziane wprost). W razie potrzeby umie pokazać inne możliwości i w ten sposób upewnić się, czego klient rzeczywiście chce. O te aspekty zahaczymy w kolejnych punktach tego artykułu.

Klienci mają często tendencje do przypominania, po co tak naprawdę uruchomili projekt i trudno im się dziwić - to są konkretne pieniądze, które wydają w celu doprowadzenia do sukcesu w postaci przyspieszenia pracy, zmniejszenia kosztów, wyskalowania firmy lub po prostu dostarczenia wartości użytkownikom. Dlatego niedopuszczalną sytuacją jest brak zrozumienia tych celów przez ownera oraz sugerowanie, że jest nimi zaskoczony, zdezorientowany lub zapomniał o wcześniejszych wysokopoziomowych ustaleniach (pomijając sytuacje, kiedy owner w projekcie pojawił się po czasie i dopiero go poznaje). Z drugiej strony, warto umieć rozpoznać, kiedy klient chce zmienić kurs lub nieświadomie to robi i upewnić się, czy taki jest rzeczywiście jego zamiar.

W przypadku produktu, który ma trafić na rynek z inicjatywy firmy, której częścią jest Product Owner, taka osoba powinna też być świadoma obecnie panujących rozwiązań i umieć rozpoznać, które funkcje rzeczywiście są pożądane przez użytkowników, a które będą “selling pointem". Natomiast to jest raczej sfera wychodząca poza "ownerowanie", bardziej wchodząca w sferę obowiązków wspominanego wcześniej Product Managera.

Współpraca i komunikacja

To z kolei aspekt, który bardziej kojarzy się z kierowaniem projektem. Wspominałem o tym, że Product Owner jest najczęściej pierwszą osobą, która dostaje pochwałę lub burę od klienta, gdyż też jest niejako reprezentantem zespołu na takich spotkaniach, a także głównym reżyserem procesu oddawania prac. To nie oznacza, że jako jedyny w nich uczestniczy i koresponduje, ale na pewno jest tym, który powinien uczęszczać we wszystkim, co dzieje się w związku z danym przedsięwzięciem.

To oznacza, że właściciel produktu powinien:

  • umieć przygotować rozsądnie brzmiącego maila i mieć pewną łatwość w formułowaniu swoich myśli (niekoniecznie posiadać “lekkie pióro", ale też nie być totalnie niepiśmienny),
  • umieć rozmawiać w taki sposób, aby osiągać cele - to nie oznacza, że musi być duszą towarzystwa, ale trudno wyobrazić sobie mrukowatą osobę na tym stanowisku,
  • nie bać się odezwać na spotkaniu z klientem, ale jednocześnie wiedzieć, kiedy należy słuchać,
  • robić dobre notatki i trzymać je w jednym miejscu, dostępnym dla wszystkich, którzy potrzebują,
  • umieć proponować rozwiązania i argumentować je,
  • umieć się zachować, w tym wiedzieć, kiedy żartować, a kiedy być poważnym (podstawowa sprawa, ale warto o tym wspomnieć, zwłaszcza, że niektórzy spojrzą tutaj znacząco na mnie),
  • rozwiązywać różnice zdań, zarówno w zespole, jak i pomiędzy klientem oraz zespołem.

Ważna uwaga - to nie oznacza, że te cechy mają przeważać i Product Owner powinien być nie tylko analitykiem, ale też literatem, negocjatorem policyjnym i ekstrawertykiem. Natomiast nie należy ukrywać, że osoba w tej roli będzie dużo rozmawiać, korespondować i - mówiąc kolokwialnie - ogarniać komunikację wewnętrzną i zewnętrzną, choćby po to, aby wytyczne były znane i klarowne. Także sam opis zadań, mimo że jest kwestią bardziej techniczną, wymaga pewnej biegłości w pisaniu. Podobnie rzecz się ma z opowiadaniem o projekcie i jego celach, co przecież czeka ownera choćby przy przyjmowaniu nowej osoby do zespołu.

Natomiast to, co osobiście bardzo cenię w Product Ownerach, to coś, co młodzież by nazwała "poczuciem vibe'u klienta". Doskonale wiemy, że każda osoba ma swoje przyzwyczajenia, poziom akceptacji żartu, temperament, sposób wypowiadania się, styl rozmowy itd. Krótko mówiąc - każdy jest inny. Umiejętność dostosowania się do komunikacji z daną osobą jest według mnie bardzo ważna, a przynajmniej przydatna. Inaczej pisze się maile do osoby, która ma ułożoną wizję projektu, inaczej do “wizjonera", a jeszcze inaczej do kogoś, kto wyraża się bardzo precyzyjnie i analizuje każde zdanie. Inny "klimat" panuje podczas rozmów z pasjonatami w swojej dziedzinie, typowymi biznesmenami oraz osobami technicznymi. Wiedząc, na co klient zwraca uwagę, na jakie terminy lub wątki reaguje alergicznie, jak wysoką tolerancję na ewentualne błędy w zrozumieniu jest w stanie znieść, możemy lepiej zaplanować komunikację i dostroić ją do warunków. To, oczywiście, nie oznacza, że Product Owner musi być przy tym wszystkim jeszcze aktorem i niczym kameleon dostosować się do sytuacji, natomiast musi mieć świadomość, że szybciej osiągnie porozumienie rozmawiając w konkretny sposób i rozumiejąc, jak przebiegają negocjacje. Są klienci, którzy machną ręką na informację wysłaną z kilkudniowym opóźnieniem, ale też tacy, dla których będzie to powód do wzmożonych negocjacji na temat przyszłości współpracy. Będą momenty, w których Product Owner będzie mógł postawić na swoim, ale też takie, gdzie będzie musiał się ugiąć - umiejętność podjęcia właściwej decyzji to coś, co niektórzy mają lub potrafią "przykryć" pewnością siebie, a inni muszą nauczyć się jej w praktyce. Nie zapominajmy, że w tym wszystkim są jeszcze osoby stojące “wyżej", czyli szefowie firmy lub pion biznesowo-sprzedażowy, który często bierze na siebie trudniejsze rozmowy dotyczące poważniejszych wątpliwości klienta.

Ustalanie priorytetów

Wróćmy na chwilę do backlogu oraz wizji produktu - wspominałem już o tym, że Product Owner ma w głowie wyobrażony przez klienta projekt i zorganizowane to, co trzeba zrobić, aby to wyobrażenie ziścić. To naturalnie oznacza, że często będzie potrzeba ustalania priorytetów, zarówno przy udziale klienta (tak jest najlepiej), jak i samemu koncypując drogę do upragnionego celu. To owner, przy wsparciu zespołu technicznego, dysponuje wiedzą, że jeśli celem jest A i B, ale łatwiej je osiągnąć najpierw robiąc C, to warto tak zaplanować prace i przekonać do tego mocodawców. Cały czas zachodzi balansowanie pomiędzy dostępnym czasem, zasobami, celami długo- i krótkoterminowymi projektu, a także zdrowiem relacji pomiędzy zleceniodawcą oraz wykonawcą (temat bardzo szeroki, którego tutaj nie będę rozwijał, ale tutaj warto przypomnieć, że to bardziej odpowiedzialność wyższego pionu kierownictwa, a nie tylko PO).

Samo ustalanie sprintu wymaga dobrej wiedzy o tym, co warto zrobić wcześniej, ale jednocześnie przy wzięciu pod uwagę, czego klient się spodziewa. A ten nie zawsze umie wyrazić swoje potrzeby w odpowiedni sposób i z tym też trzeba się pogodzić - wówczas na głowie Ownera jest takie przestawienie klocków, aby odbiorca był jak najbardziej zadowolony. A jeszcze do tego pozostaje kontrola tych priorytetów podczas realizacji i albo klarowne ich przedstawienie zespołowi (dzięki czemu ma “samograj"), albo stałe monitorowanie tego, które zadania są aktualnie wykonywane.

Usuwanie przeszkód na drodze zespołu

To kolejna kwestia, która jest bliższa typowym managerom, ale nawet w Scrumie jest to raczej powinność innej roli, czyli Scrum Mastera. Tym niemniej, Product Owner również powinien mieć baczenie na to, co blokuje zespół w realizacji sprintu, szczególnie jeśli ma to związek z samymi wymaganiami. Może się bowiem zdarzyć, że:

  • nie ma zasobów (np. osób), które mogą się danego zadania podjąć,
  • zadanie nie jest jasne lub - co gorsza - już jest realizowane w sposób odbiegający od założeń,
  • brakuje materiałów od klienta,
  • nie wiadomo, jak testować dane wymaganie.

Dlatego PO ma do dyspozycji kilka narzędzi, którymi może się posługiwać - system do zarządzania zadaniami (u nas Feedybacky), wspomniane DoDy, SUMy, testy akceptacyjne, a także po prostu dokumentacja w różnej formie, która pozwoli przypomnieć sobie o ustaleniach, uspokoić i naprostować sytuację. Czasem blokady mają źródło w zewnętrznych dostawcach, ale bywają też w samej firmie - umiejętność szybkiej identyfikacji i realizacji takiego problemu również jest bardzo cenioną cechą Product Ownera. Podobnie jak proaktywność - mało jest gorszych i bardziej demotywujących widoków niż PO, który wie, że jest problem i biernie czeka, aż sam się rozwiąże. Bo "jakoś to będzie". Otóż, nie zawsze.

O harmonogramie i budżecie

O ile PO rzeczywiście nie jest od tego, aby przejmować się pieniędzmi, to warto, aby wiedział, które zadania są szczególnie wartościowe także z tego punktu widzenia oraz jakie są ustalenia dotyczące finansowania projektu. To również wpływa na decyzje dotyczące ułożenia zadań, sprintu, a także relacji pomiędzy software housem i klientem. Owner nie jest od tego, aby ustalać stawkę za godzinę, ale powinien być świadomy tego, jak rozliczany jest projekt.

Natomiast harmonogram to trochę bajka - właściciel produktu powinien mieć najbardziej aktualną wiedzę o tym, które zadania są nie tylko istotne, ale też kiedy mają zostać oddane, biorąc pod uwagę np. dodatkowe zobowiązania klienta (np. plany kampanii marketingowej), granty czy zwyczaje panujące na rynku. Oczywiście, ta wiedza ma posłużyć do prawidłowego określenia priorytetów, ale też monitoringu realizacji, gdyż pewne zadania stają się szczególnie istotne pod tym kątem.

Pewnie Was nie zdziwi, że kontrola na koniec sprintu nie jest wystarczająca - najlepiej byłoby śledzić sytuację na bieżąco, jednak zajmuje to czas i też demotywuje, gdy postępy nie zawsze są zauważalne, szczególnie dla osoby nietechnicznej. W naszym Feedybacky mamy do tego specjalny raport, który pozwala określić postęp wykonania poszczególnych fragmentów projektu - spokojnie, opiszemy go niebawem.

Podsumowanie

Biorąc to wszystko pod uwagę, idealny Product Owner:

  • doskonale orientuje się w celu projektu oraz zleceniodawców,
  • rozumie wizję przedsięwzięcia, ale też potrafi spojrzeć na nią krytycznie,
  • dobrze organizuje wymagania i zadania,
  • umie wyznaczać priorytety i monitorować je,
  • trzyma rękę na pulsie, walidując to, co robi zespół techniczny,
  • dobrze się komunikuje, umie słuchać i notować,
  • "czuje atmosferę" relacji z klientem,
  • zauważa kłopoty i przeciwdziała im, jeśli może,
  • umiejętnie dobiera narzędzia do prowadzenia projektu.

Oczywiście, nie istnieje ktoś, kto jest perfekcyjny w każdym z tych elementów, choć na pewno praktyka czyni mistrza i pozwala takiej osobie być świadomym swoich ograniczeń oraz umieć z nimi walczyć. Nie jest to łatwa rola - to jedna z tych, które trudno wyćwiczyć samemu w domu (jak programista lub inna techniczna specjalizacja), a wiedza z książek może być niewystarczająca, gdy pojawią się realne problemy, a zespół liczy, że dasz mu spokój i zadziałasz. Tym niemniej, warto próbować, gdyż satysfakcja z dobrze poprowadzonego projektu jest wspaniałym uczuciem i mam szczęście, że mogę mówić o tym z doświadczenia.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Blaski i cienie self-hostingu https://wildasoftware.pl/post/blaski-cienie-self-hostingu?ref=rss https://wildasoftware.pl/post/blaski-cienie-self-hostingu?ref=rss Thu, 06 Mar 2025 17:30:00 +0000 Muszę Wam (czytelnikom, ale też współpracownikom) do czegoś się przyznać. Gdy obejmowałem funkcję CTO (Chief Technology Officer) w Wilda Software i pracowałem między innymi nad infrastrukturą oraz wewnętrznymi systemami wykorzystywanymi w zespole, cały czas miałem na uwadze, że powinniśmy stawiać na self-hosting, czyli samodzielne hostowanie rożnych kawałków oprogramowania. Powodem było przekonanie, że w ten sposób będziemy mieli większą kontrolę, unikniemy problemów wynikających z braku dostępów do usług, możliwych naruszeń bezpieczeństwa (mimo że jak najbardziej korzystamy z zewnętrznych serwerów), ale był jeszcze jeden argument - "przecież jesteśmy firmą IT, a w tej branży się tak robi, bo to świadczy o profesjonalizmie". Prawda? Otóż, nie do końca.

Po kilku latach i nabyciu większego bagażu doświadczenia, dotarło do mnie (i generalnie nas jako zespołu), że owszem, self-hosting ma swoje duże zalety oraz jest po prostu ciekawy dla osób z zewnątrz, ale, niestety, posiada też swoje wady i o ile w wydaniu bardziej amatorskim lub bez planów zarabiania część słabości ma mniejsze znaczenie, o tyle w działającej na rynku organizacji stanowią duże wyzwanie, a czasem nawet i blokują przedsięwzięcia. Słowem - self-hosting nie jest idealnym rozwiązaniem w każdym przypadku, a nawet tam, gdzie wydaje nam się, że jest najlepsze, sytuacja może się zmienić, kiedy mówimy o zespole mającym dostarczać rozwiązania biznesowe dla swoich klientów, których przecież nie interesuje, jaką infrastrukturę ma software house - on ma po prostu wykonać swoją pracę i przynosić wartość.

Zdaję sobie sprawę, że są osoby, które czytając te słowa rwą sobie włosy z głowy, gdyż self-hosting jest szczególnie istotny w kontekście prywatności, uniezależnienia od Big Techów itd.. Przepraszam takich czytelników - dzisiaj będę adwokatem diabła, ale też będę bazował na swoich doświadczeniach. Omówmy sobie dzisiaj zatem problemy, które dotyczą samodzielnego gospodarowania aplikacjami, a o których niektórzy zapominają, entuzjastycznie myśląc, że staną się odporni na wszelkie zło świata technologicznego.

Czym jest self-hosting?

Zacznijmy jednak od kwestii podstawowej, ale być może nie wszystkim znanej - o czym w ogóle dzisiaj będziemy rozmawiać? Self-hosting to korzystanie z oprogramowania, które sami hostujemy, tj. sami je wdrażamy na serwer i konfigurujemy pod nasze potrzeby. Jest to opozycja w stosunku do modelu chmurowego SaaS (Software as a Service), w którym zakładamy konto w usłudze udostępnianej przez zewnętrzną firmę, najczęściej płacąc za to abonament. Najprostszym przykładem może być posiadanie systemu zarządzania zadaniami - można założyć konto na serwerze Jiry i w ten sposób prowadzić projekty w zespole. Ale można też pobrać Redmine'a i postawić go na swoim serwerze. Nieco wybiegając w przyszłość - akurat w tym aspekcie w Wilda Software postawiliśmy na self-hosting, choć poszliśmy jeszcze dalej.

Takie "samogospodarowanie", jak wcześniej napomknąłem, zwykle dotyczy oprogramowania, a więc jest to self-hosting software'owy. W tym modelu bierzemy gotowe oprogramowanie do wdrożenia (najpopularniejszym systemem tego typu jest Wordpress do tworzenia stron), instalujemy zgodnie z instrukcją, a później - w zależności od potrzeb i możliwości - konfigurujemy i modyfikujemy. Zdarzają się jednak sytuacje, w których organizacja chce tak bardzo uniezależnić się od innych dostawców, że decyduje się na self-hosting hardware'owy, przynajmniej częściowy - zwykle oznacza to, że firma kupuje fizyczny serwer i sprowadza go do swojej siedziby, mając nad nim także bardziej manualną kontrolę, nierzadko odcinając go od Internetu. Krótko mówiąc - firma robi sobie małą serwerownię. To zdecydowanie mniej popularna "zabawa", gdyż wiąże się z większymi kosztami, zapewnieniem warunków oraz potrzebną wiedzą, aby to wszystko obsłużyć. Sami spotkaliśmy w trakcie naszych karier i obsługi dziesiątek lub setek klientów bodajże cztery przypadki, w których współpracujące firmy zdecydowały się na taki ruch, co wynikało albo z posiadania odpowiedniego komputera na miejscu i chęci jego wykorzystania, albo konkretnych wskazań związanych z cyberbezpieczeństwem. Natomiast zazwyczaj mówimy wówczas o klientach posiadających swoich specjalistów IT i administratorów na miejscu. Trzeba też jasno powiedzieć, że w niektórych przypadkach kupno takiego serwera było nieuzasadnione.

Zdecydowanie najczęstszym przykładem self-hostingu jest jednak pobranie wersji instalacyjnej gotowego oprogramowania i wdrożenie go na kupiony gotowy serwer w chmurze - i tak już wtedy mamy dużą kontrolę nad danymi, gdyż zazwyczaj posiadamy dostęp do bazy danych, a z drugiej strony sam serwer jest zabezpieczany przez specjalistów w swoim fachu, czyli firmy hostingowe. Jeśli nie cechują nas jakieś bardzo szczegółowe wymagania lub dane o wysokim stopniu poufności, to w większości przypadków hardware'owy self-hosting będzie zbyt ciężką kulą u nogi.

Co nie znaczy, że software'owy self-hosting (na którym się skupimy w artykule) też nie może być taką kulą.

Self-hosting wymaga zasobów

Na początek dość oczywista rzecz, którą zresztą już wyżej zasygnalizowałem. W przypadku usług SaaS abonament za korzystanie z nich pokrywa wynagrodzenie dla zespołu, ale też koszty stałe i niestałe, które usługodawca ponosi, w tym utrzymanie serwerów. W zamian jako użytkownicy nie musimy przejmować się takimi rzeczami jak konserwacja komputerów, dostawy energii elektrycznej, wymianę dysku itd. Oczywiście, trochę przepłacamy, ale to też trzeba zrozumieć - w zamian kupujemy sobie spokój. To trochę tak, jak inwestowanie w gotowe fundusze, gdzie tylko dajemy pieniądze, a specjaliści za nas nimi zarządzają i biorą za to prowizję.

Gdy decydujemy się na self-hostowanie jakiegoś oprogramowania, to odpowiadamy za instalację, konfigurację oraz monitorowanie danej aplikacji. O tym będzie nieco więcej w kolejnym punkcie, natomiast musimy też mieć serwer, na którym to wszystko uruchomimy. A taką maszynę (wirtualną lub fizyczną) trzeba opłacać niezależnie od tego, ile kosztuje sama obsługa oprogramowania. Jeśli dodatkowo decydujemy się na tzw. zarządzany VPS (ang. VPS managed), to znowu zyskujemy trochę spokoju, ale opłacamy administratorów, którzy za nas wykonują pewne zadania. Krótko mówiąc - musimy zadbać o zasoby na własną rękę, podczas gdy w przypadku usług chmurowych taki koszt może jest większy, ale rozkłada się na większą grupę osób.

A jest jeszcze kwestia plików - wiele aplikacji pozwala je wgrywać i jeśli nie doszacujemy ogromu informacji, które chcemy przechowywać, może się okazać, iż zabraknie nam przestrzeni dyskowej. Wówczas należy albo zrobić przegląd i czyszczenie (czas, nerwy, niepewność), albo dokupić miejsce na dysku u dostawcy (co nie zawsze jest możliwe u wszystkich hostingodawców i czasem trzeba...), albo przenieść się na większy serwer (koszty), albo przerzucić pliki na tzw. storage, czyli "teoretycznie nieograniczoną" przestrzeń dyskową (koszty i czas potrzebny na przekonfigurowanie). Gdybyśmy korzystali z usługi chmurowej, to zajmuje się tym administracja tej usługi i nie musimy się o to martwić (chyba że z góry są postawione limity, ale najczęściej można je zwiększać).

Dlatego self-hosting ma więcej sensu, kiedy i tak kupujemy serwer lub serwery, na których skonfigurujemy więcej usług, a nie tylko jedną, chyba że jest ona szalenie istotna. A zauważcie, że cały czas mówimy tutaj o samogospodarowaniu oprogramowaniem - jeśli w grę wchodzi postawienie fizycznych maszyn w naszej siedzibie, to koszty (i stres) diametralnie rosną.

Self-hosting wymaga wiedzy i czasu

To chyba najbardziej niedoceniany punkt w zabawie polegającej na hostowaniu usług na swoich zasobach. Wiele osób myśli, że są gotowe kawałki oprogramowania, przygotowane paczki i instrukcje do ich wgrywania, więc wystarczy postępować według kroków na swoim serwerze i mamy piękną usługę, nie musząc płacić tym krwiopijcom ze swoimi usługami w chmurze. Brzmi pięknie? Do czasu.

Pamiętajcie bowiem, że:

  • jesteśmy całkowicie odpowiedzialni za oprogramowanie, które hostujemy - nie mamy supportu, który nam pomoże, a jeśli takowy istnieje, to trzeba z nim kontaktować się indywidualnie w ramach naszego planu,
  • gotowe paczki czasami są w technologii, w której na co dzień nie działamy, więc wypada ją poznać, na co potrzeba czasu,
  • od czasu do czasu trzeba zaktualizować oprogramowanie, co oznacza np. restart usług i wykonywanie określonych komend. A jeśli dana technologia nie jest naszą domeną, to: patrz poprzedni podpunkt,
  • prawie nigdy instrukcje dostarczone z oprogramowaniem nie przekładają się idealnie na każde środowisko, szczególnie w przypadku bardziej skomplikowanych systemów (tutaj pewnym ratunkiem jest konteneryzacja) - to oznacza, że trzeba stać się specjalistą od danego systemu, który hostujemy, a z tym jest zawsze trudniej niż w przypadku oprogramowania, które sami sobie napiszemy lub usługi, na którą się zdajemy w chmurze,
  • to wszystko wymaga czasu, chęci pracowników (czasem oddelegowania kogoś do opieki) i nierzadko odrywa od właściwej działalności firmy.

I teraz przyznam się do czegoś, do czego nie powinienem, szczególnie jako CTO i współwłaściciel software house'u, ale szczerość jest w cenie. Tak, jak pisałem, w momencie, kiedy rozpoczynaliśmy działalność, nie wyobrażałem sobie, że nie będziemy korzystać z self-hostowanych usług, wśród których było między innymi narzędzie do zarządzania repozytoriami Gogs oraz Redmine do zarządzania projektami (więcej o naszym stosie technologicznym można przeczytać w tym artykule). W tym akapicie pomijamy, czy to były dobre wybory pod kątem jakości - bardziej skupmy się na aspekcie technicznym. Gogs (co też widać po nazwie) został zbudowany w oparciu o język Go, a Redmine - o język Ruby. Tymczasem my w zespole skupiamy się na technologiach związanych z PHP oraz JavaScriptem (w tym Node.js). Oczywiście, jak w większości software house'ów, jesteśmy w stanie przenosić się pomiędzy różnymi językami i frameworkami, jeżeli wymaga tego dany projekt klienta, natomiast nie da się ukryć, że - ponownie, jak każdy zespół - mamy swoje preferencje i punkty, w których jesteśmy najbardziej efektywni. To oznacza, że wsiąkanie w technologie i frameworki związane z Go oraz Ruby tylko po to, aby w razie potrzeby móc naprawić dwa self-hostowane narzędzia (co zdarza się może raz na rok) nie jest czymś opłacalnym. To z kolei sprawia, że wszelkie podbramkowe sytuacje i awarie wiążą się z pewnym stresem, nie tylko ze względu na niedziałającą usługę, ale też niepewność w kwestii samodzielnej obsługi.

Jeśli nie umiemy sami złożyć trzyrzędowej szafy i spędzilibyśmy nad tym wiele godzin, które moglibyśmy spożytkować w inny sposób (np. zarobić na tym, na czym się znamy), to często lepiej jest zapłacić firmie, który zrobi to szybciej, sprawniej i za nas. Tak samo jest z oprogramowaniem i między innymi ze zmianą Gogsa na chmurowego Githuba - po drodze rozważaliśmy choćby samodzielnie postawienie Gitlaba, ale licząc wszystkie koszty oraz konieczność obsługi oprogramowania napisanego nie w naszym macierzystym języku, zrezygnowaliśmy.

Oczywiście, to tylko jedna strona medalu - czasem warto wyjść ze strefy komfortu, poznać coś nowego, nabyć dodatkowe umiejętności, a także zwrócić uwagę na inne aspekty niż pieniądze (np. prywatność danych), jednak generalnie należy rozważyć wszystkie punkty i wziąć pod uwagę, do czego nam to będzie służyć. Gdyż, jak już pisałem, perspektywa zmienia się w momencie, kiedy mówimy o profesjonalnym środowisku, w którym nie chodzi już tylko o dobrą zabawę i naukę, ale o zawodowe świadczenie usług, do których trzeba posiadać pewne i funkcjonalne środowisko.

Self-hosting nie jest dostępny dla wszystkich rozwiązań

Wróćmy na chwilę do kwestii Gogsa - rozważenie jego zmiany nie wiązało się tylko z technologią, w której powstał, ale też ograniczonymi możliwościami względem Gitlaba czy Githuba, które zwyczajnie zaczęły nam ciążyć wraz z rozwojem firmy (z tego powodu w grę nie wchodziła też np. Gitea). Do tego dochodzą wymagania zespołów technicznych części klientów. To prowadzi nas do kolejnego punktu - w większości obszarów znajdą się odpowiedniki możliwe do self-hostowania, ale czy zawsze będą równie funkcjonalnym zamiennikiem względem komercyjnych usług? Szczerze mówiąc, rzadko.

Oczywiście, nie każda firma potrzebuje rozwiązania najlepszego i najbardziej rozbudowanego w swojej klasie. Nie każdy dział sprzedażowy wykorzystuje wszystkie moduły swojego CRM-a, nie każda firma IT potrzebuje wszystkie fajerwerki Gitlaba, a nie każdy duży zespół potrzebuje komunikatora "all-in-one". Nie bez powodu istnieją różne plany abonamentowe czy zwyczajnie inne usługi, gdyż po prostu każdy ma swoje potrzeby. Jak to się wiąże z self-hostingiem?

To prawda, że nie wszystkie tego typu usługi są darmowe, ale duża część z nich faktycznie jest. Czasem są to uproszczone wersje znanych aplikacji dostępnych w chmurze, a czasem oprogramowanie open source tworzone przez pasjonatów z nadzieją na osiągnięcie czegoś więcej. I choć nie można tego przekładać jeden do jednego, to jednak nie bez powodu najbardziej dopracowane pod kątem biznesowym rozwiązania są dostępne w formie abonamentowej i obsługiwane przez większe firmy. Prawda jest taka, że jeśli budżet jest większy, to (przy dobrym zarządzaniu i chęciach) można robić większe rzeczy. Ale też wówczas oczekiwana jest za to odpowiednia gratyfikacja.

Tutaj uwaga - to nie oznacza, że self-hostowe rozwiązania nie są godne rozważenia, bo z automatu wszystkie są gorsze. Absolutnie nie - ich przewagą często jest to, że są opensource'owe i rozwijane przez społeczność, która wzajemnie poprawia oprogramowanie i wskazuje sobie rzeczy do rozwoju. Dobry CRM udostępniony do self-hostowania jest lepszy niż kiepski CRM w chmurze. Tym niemniej, trzeba mieć świadomość, że nikt pracujący tysiące godzin nad czymś, co wypuści potem do samodzielnego postawienia, nie będzie tego robił za darmo, chyba że kierują nim bardziej szczytne idee (którymi, niestety, nie da się nakarmić rodziny). Wiem, że jestem teraz cyniczny, bo w życiu nie chodzi tylko o pieniądze i to też jest prawda. Ale na palcach jednej ręki można policzyć rozwiązania, które realnie, pod każdym (funkcjonalnym i pozafunkcjonalnym) względem dorównują tuzom każdego obszaru. Są takie systemy, a i nawet te prostsze ich wersje są często wystarczające, ale umówmy się - nie bez powodu w większości firm widzimy np. Jirę, Asanę, Monday.com czy coś podobnego, a nie OpenProject oraz Redmine. Większym wzięciem cieszy się Slack czy Microsoft Teams niż Rocket.Chat.

Wreszcie, są obszary, w których własnoręczne hostowanie wiąże się naprawdę z dużymi zasobami. Przykładem może być własna instancja PeerTube, czyli fediwersowa wersja YouTube'a, w której - jak można się domyślić - hostujemy też nasze filmy. A biorąc pod uwagę ich rozmiar, w tym przypadku naprawdę trzeba dobrze przemyśleć krok w kierunku self-hostingu.

Self-hosting wymaga zabezpieczeń technicznych i prawnych

Wiemy już, że self-hosting wymaga odpowiednich zasobów, większych lub mniejszych w zależności od oprogramowania i stopnia self-hostingu. To też automatycznie pociąga za sobą konieczność odpowiedniego zabezpieczenia tych zasobów - reguły firewalla, prawa dostępu, czasem VPN i generalnie coś, co nazywa się "hardeningiem". Niby wszyscy o tym wiedzą, choć czasem lekceważą. Natomiast nie łudźmy się - nie każdy informatyk jest w stanie prawidłowo ustawić całe środowisko serwerowe i zadbać o nie. Czasem wynika to z braku wiedzy (co nie jest niczym wstydliwym, gdyż ta dziedzina jest ogromna, a będzie coraz większa), a czasem z przywoływanego już często braku czasu. Wybierając usługę w chmurze, zawierzamy usługodawcy, że potrafią dbać o nasze dane oraz odpowiednio je chronić. Oczywiście, często robimy to nie mając pojęcia, jak wyglądają realne procedury wewnątrz zespołu i to jest argument fanów self-hostingu. Niebezpodstawny, dodajmy. Tym niemniej, komuś trzeba zaufać i należy przy tym wziąć pod uwagę zarówno chęci, jak i umiejętności.

Bywają też sytuacje, w których występują konkretne obostrzenia prawne dla organizacji udostępniającej usługę. W przypadku, kiedy self-hostujemy coś nie tylko dla siebie, ale także osób trzecich, dotyka to także nas. Jeszcze bardziej dotyczy to sytuacji, w której udostępniamy własnoręcznie wykonany system. W zależności od poziomu zabezpieczeń prawnych, które są potrzebne, self-hosting może się wiązać ze zbyt dużym ryzykiem pod kątem regulaminowym.

Self-hosting wymaga szybkiego działania w przypadku awarii

Ten wątek został wspomniany przy okazji poprzednich punktów, ale powiedzmy to sobie jasno - oprogramowanie czasem przestaje działać. Może mieć to związek z błędami w samej aplikacji, może to być kwestia zewnętrznych usług (np. serwera pocztowego), czasem problem wynika z samej maszyny, na której działa aplikacja. Ostatnio mieliśmy też przypadek, kiedy koparka działająca niedaleko klienta, przy okazji kopania w ziemi (co zwykle takie pojazdy robią), przecięła światłowód i z tego powodu przestały działać usługi hostowane w infrastrukturze tej firmy. Przypadki są różne, ale łączy je jedno - trzeba coś z tym zrobić.

W momencie, kiedy hostujemy taką usługę, to na nas spada obowiązek naprawienia jej. Czasem jest to proste i wystarczy zrestartować maszynę lub odpowiedni serwis... o ile wie się, jak to zrobić. Często w dokumentacji znajdują się recepty na najczęstsze problemy. Ale niekiedy konieczne jest diagnozowanie czegoś bardziej specyficznego i wówczas bez wiedzy o technologii i samym systemie IT taka osoba jeszcze bardziej przeklina pomysł o self-hostingu.

Oczywiście, przedstawiam to trochę w czarnych barwach, ale nadal pamiętajmy, że nie każdy jest administratorem i ma wystarczająco dużo czasu, aby oprócz podstawowych obowiązków ogarnąć jeszcze obce oprogramowanie. Owszem, może się to przydać (o czym za chwilę), ale pamiętajmy, że awarie się zdarzają i lepiej być wówczas po stronie tylko narzekających na to, a nie próbujących w pocie czoła sobie z tym poradzić.

Czy zatem self-hosting jest zły?

Absolutnie nie. Ten artykuł nie ma na celu udowodnienia, że samodzielne hostowanie oprogramowania wiąże się tylko i wyłącznie z negatywami, bo tak nie jest. Są też pozytywne strony, gdyż w końcu z jakiegoś powodu takie rozwiązania nadal powstają. Natomiast chciałbym zwrócić uwagę, że nie należy przesuwać wajchy w drugą stronę - self-hosting to nie tylko cud, miód, orzeszki i uniezależnienie się od wszelkich fluktuacji w dużych firmach. To po prostu wzięcie na siebie obowiązku, na który nie wszyscy są i będą gotowi. W teorii posiadanie wszystkiego na swoich serwerach brzmi fantastycznie, ale istnieją też praktyka i - przede wszystkim - warunki, w jakich działamy.

Tym niemniej, na pewno można wymienić zalety self-hostingu:

  • uniezależnienie się od zewnętrznej firmy lub (częściej w dzisiejszych czasach) zmian w oprogramowaniu w usłudze chmurowej,
  • kontrola nad danymi, zarówno w bazie, jak i plikach,
  • psychologiczne poczucie niezależności (tak, to też bywa ważne),
  • potencjalnie niższe koszty (zależnie od usługi i formy zorganizowania jej działania),
  • możliwość wykorzystania tego PR-owo,
  • kontrolę nad aktualizacjami i potencjalnie bardziej stabilne oprogramowanie - jeśli coś postawimy i działa, to sami decydujemy, kiedy zmodernizować wersję systemu.

Jest też inna potencjalna przewaga, którą można wziąć pod uwagę w momencie, kiedy mówimy o środowisku firmowym - znajomość konkretnego oprogramowania, które można samemu skonfigurować, pozwala świadczyć dodatkowe usługi dla klientów. Wyobraźmy sobie sytuację, w której ktoś widzi w naszym środowisku całkiem sympatycznie wyglądający system CRM (ang. Customer Relationship Management) i dowiaduje się, że też może mieć taki u siebie. Wówczas pada sakramentalnie pytanie "a zrobicie to też u nas? Zapłacimy wam za to!". Jeśli zespół ma odpowiednią wiedzę na temat danego oprogramowania i jest w stanie nim zarządzić, to zyskuje potencjalną przewagę konkurencyjną w postaci możliwości konfigurowania pewnego typu oprogramowania (a czasem nawet modyfikacji) u klienta lub po prostu udostępnienia swoich zasobów.

Self-hosting na przykładzie Wilda Software

Wspominałem o tym, że o ile na początku działalności mieliśmy ściśle self-hostingowe zacięcie i poczucie, że "tak się po prostu robi", tak z biegiem lat zaczęło się to u nas zmieniać. Spędzając lata nad projektami klientów zaczęliśmy mieć refleksje na temat tego, gdzie rzeczywiście warto było postawić na swoje, a gdzie nie. Natomiast nie da się ukryć - taka wiedza przychodzi z doświadczeniem, a to pojawia się wraz z czasem. Dlatego, jeśli czytacie teraz te słowa i wydaje Wam się, że tylko nienormalny rezygnowałby z self-hostingu, jeśli już się na niego zdecydował, to albo macie większe zacięcie do tego, albo... po prostu wszystko przed Wami.

W przypadku systemu do zarządzania repozytoriami na początku samodzielnie hostowaliśmy Gogsa, który ma tę zaletę, że jest prosty, mały, a jednocześnie funkcjonalny. Niestety, z czasem fakt napisania go w języku Go (z którym na co dzień nie pracujemy), ale przede wszystkim brak pewnych funkcji CI/CD i dotyczących pull requestów sprawił, że musieliśmy pomyśleć o alternatywie i o ile przez długi czas był rozważany self-hostowany Gitlab, to po przeliczeniu wszystkiego (nie tylko kosztów) zdecydowaliśmy się jednak na Githuba.

Komunikatorem u nas nadal jest Slack, a więc chmurowe rozwiązanie, aczkolwiek były już przymiarki do innych rozwiązań, w tym także self-hostowych. Jednakże na ten moment nadal korzystamy z oprogramowania przedstawianego białą ikonką z różnymi kolorami.

Zmiany zupełnie zaprzeczające wydźwiękowi tego artykułu dzieją się u nas w obszarze zarządzania projektami. Do tej pory korzystaliśmy z Redmine'a oraz - nieco później - z własnoręcznie napisanego Feedybacky'ego. Z czasem ten drugi, z pierwotnej funkcji systemu obsługi zgłoszeń od klientów zaczął być pierwszorzędnym narzędziem, którego potrzebujemy i wykorzystujemy do naszych przedsięwzięć. Dlatego w tym obszarze rozwijamy nie tylko self-hostingowe rozwiązanie, ale wręcz pod każdym względem nasze. Co nie oznacza, że zatrzymujemy je tylko na siebie - jeśli tylko chcesz cieszyć się z chmurowej wersji Feedybacky'ego lub postawić go i dostosować pod siebie, to zachęcamy do kontaktu.

Self-hostingowa skrzynka pocztowa to nie jest rozwiązanie, na które byśmy się zdecydowali bez posiadania solidnego działu administratorów, dlatego tutaj korzystamy z rozwiązania chmurowego. Z kolei, w przypadku strony firmowej, podobnie jak u większości firm, stworzyliśmy ją całkowicie sami i samodzielnie hostujemy. Aczkolwiek akurat tutaj inne podejście jest rzadkością (w kwestii serwera - jeśli chodzi o samo stworzenie witryny, to zleca się różnym firmom. Mamy przypomnieć, do kogo możecie się zgłosić? ;)

W przypadku CRM-a eksperymentujemy z self-hostingiem i oceniamy, na ile takie narzędzie rzeczywiście by nam się przydało. Pierwsze próby są obiecujące, a nawet mogą skutkować przynajmniej fragmentarycznie napisanym oprogramowaniem.

Pliki przechowywane i udostępniane w chmurze - po analizie i niekoniecznie pozytywnych głosach pytanych osób nie zdecydowaliśmy się na samodzielnie hostowanego Nextclouda i nadal korzystamy z komercyjnych i dobrze znanych usługodawców.

Wreszcie, serwer Mastodona - eksperyment z samym Fediverse wyszedł jak najbardziej pozytywnie, jednak początkowa decyzja o własnej instancji social.wildasoftware.pl nie okazała się właściwa dla jednego konta. Z perspektywy czasu twierdzimy, że jeśli nadal byśmy chcieli utrzymać self-hosting, to dużo lepsza byłaby instancja na np. dużo prostszym i szybszym GoToSocial. Tym niemniej, to nadal konieczność zaadaptowania dodatkowego serwera i zajmowania się oprogramowaniem w innej technologii niż nasze nominalne, a w dodatku Mastodon jako platforma jest dla nas ważna. Dlatego przeszliśmy na największy, oficjalny serwer mastodon.social (i wiemy, że niektórym zgrzytają od tego zęby, ale to była przemyślana decyzja).

Podsumowanie

Self-hosting ma swoje mocne strony, ale nie zapominajmy, że miewa również swoje słabości. Posiadanie własnych usług i umiejętności ich zarządzania to niewątpliwy powód do dumy i chwalenia się. Jednak, należy wziąć poprawkę na to, że czytając o samodzielnym hostowaniu oprogramowania, najczęściej mamy do czynienia z aż podejrzanie jednoznacznie pozytywnymi artykułami na ten temat, rekomendującymi to podejście ze względu na prywatność, uniezależnienie się od GAFAM i inne wzniosłe hasła. I o ile trudno z tym dyskutować, to każdy kij ma dwa końce, więc chciałem pokazać też cienie takiej decyzji, które nie są widoczne na samym początku i pojawiają się z biegiem czasu. Pamiętajcie też, że piszę z perspektywy software house'u, który skupia się na rozwoju oprogramowania - inaczej do tego podejdzie grupa przyjaciół prowadząca startup, inaczej organizacja non-profit, swoją opinię będzie miała instytucja publiczna, a zupełnie inne zapatrywanie na sprawę przedstawi korporacja lub firma specjalizująca się w hostingu. Jak głosi stara prawda: "punkt widzenia zależy od punktu siedzenia". Jeszcze można dodać, że także od stopnia zaawansowania i profilu krzesła, na którym się siedzi.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Dlaczego logika jest po stronie backendu? https://wildasoftware.pl/post/dlaczego-logika-stronie-backendu?ref=rss https://wildasoftware.pl/post/dlaczego-logika-stronie-backendu?ref=rss Thu, 20 Feb 2025 17:30:00 +0000 Wielu specjalistom pytanie zawarte w tytule może wydawać się absurdalne. Przecież, gdy mówimy o podziale oprogramowania na frontend i backend, to od początku powtarza się, że frontend jest od interfejsu, a backend od logiki. Skąd zatem pomysł, aby w ogóle mysleć o roszadach w tym aspekcie i dlaczego w ogóle to tłumaczyć?

Źródłem jest, oczywiście, życie i obserwacja różnych projektów spotykanych zarówno w życiu zawodowym, akademickim, jak i prywatnym. Bywa tak, że programiści, znając lepiej frontend (i do tego jeszcze w postaci konkretnego frameworka, jak np. React), wchodzą do projektów wymagających rozwijania kodu także po stronie backend i gdy napotykają trudności, to wybierają rozwiązanie, z którym czują się lepiej. Nie zawsze jednak jest to rozsądny wybór, a więc taki, który uwzględnia zalety i wady różnych podejść, a na końcu wynikiem jest właściwa, przyszłościowa opcja. Zamiast tego niektórzy idą tropem, że skoro lepiej znają frontend, to zrobią jak najwięcej we frontendzie. W końcu liczy się efekt, prawda? A w przypadku logiki i generalnie różnych obliczeń jest to zazwyczaj błąd.

Natomiast pozostaje pytanie wielu początkujących - dlaczego właściwie to jest błąd? I nie chodzi tutaj tylko o zapis wprowadzonych danych do bazy, gdyż tutaj backend jest często oczywisty. Natomiast umiejscowienie takich kwestii, jak np. obliczenie wieku na podstawie daty urodzenia czy wyciągniecie procentu z dwóch wartości - już nie zawsze. Porozmawiajmy sobie o tym.

Zalety frontendu i backendu

Powtórzmy to raz jeszcze:

  • frontend to część oprogramowania, która odpowiada za interfejs, wyświetlanie informacji użytkownikowi i bezpośrednią obsługę wywołanych przez niego zdarzeń. To jest "to, co widać",
  • backend to część oprogramowania, z którą komunikuje się frontend w celu zdobycia danych lub zapisania ich. To jest "to, czego nie widać".

W świecie aplikacji, zwłaszcza webowych (ale nie tylko), frontend zazwyczaj jest uruchamiany bezpośrednio w środowisku użytkownika, natomiast backend jest ukryty na serwerze, do którego nikt (poza administratorem) nie ma bezpośredniego dostępu. To ma swoje daleko idące konsekwencje, gdyż oznacza, że:

  • frontend jest szybszy w operacjach wykorzystujących sprzęt użytkownika, ponieważ ma do niego dostęp. Do tego może przyjąć różną formę w zależności od preferencji odbiorcy, ale jest narażony m.in. na "hakowanie",
  • backend jest bezpieczniejszy (ukryty w miejscu, do którego użytkownik nie ma wejścia), stanowi jedno źrodło prawdy, ale też przez to jest obciążony zapytaniami z frontendów uruchomionych u różnych użytkowników.

Dawniej, gdyż królowały aplikacje monolityczne, a więc oparte o jeden kawałek oprogramowania znajdujący się na serwerze, architektura była prostsza, ale systemy bardziej obciążone i mniej podatne na skalowanie. Ponadto, ograniczały wybór technologii do jednej, a wiadomo, że istnieją biblioteki czy frameworki lepsze w konkretnych zastosowaniach. Wreszcie, podział na dwie części przynosi po prostu korzyści w zarządzaniu projektem, rozwoju oprogramowania i umożliwia przypisanie odpowiedzialności za poszczególne partie.

Wydajność

Wyobraźmy sobie, że pobieramy datę urodzenia użytkownika, natomiast mamy wyświetlić nie tylko ją, ale też wynikający z niej wiek. Oczywiście, oznacza to pobranie aktualnej daty i odjęcie od niej tej urodzenia. Mechanizmy ku temu znajdują się po obu stronach technologicznych, ale jednak w większości wypadków zalecenie będzie takie, aby zrobić to w backendzie. Dlaczego?

W przypadku jednej wartości nie ma to wielkiego znaczenia. Jednak wyobraźmy sobie, że programiści przyzwyczają się do tego, aby tego typu małe obliczenia robić głównie na frontendzie. Spowoduje to, że owszem, backend będzie dość wydajny, gdyż będzie przekazywał tylko surowe dane i nie obliczał dodatkowych informacji. Natomiast przeglądarka po stronie użytkownika, który dysponuje jednak zazwyczaj gorszym sprzętem niż serwer, będzie wykonywała działania, które w dużej liczbie po prostu spowolnią stronę. Można z tym walczyć różnymi technikami związanymi z opóźnionym ładowaniem, asynchronicznością itd., jednak jest to bohaterskie rozwiązywanie problemu, który sami sobie sprowadziliśmy.

Użytkownicy w dzisiejszych czasach są przyzwyczajeni do tego, że aplikacje ładują się błyskawicznie, szczególnie strony WWW. Jest to związane z tym, że dostęp do szybkiego Internetu jest już dużo szerszy niż kiedyś (nie chcę mówić, że powszechny, gdyż nie wszyscy mają szczęście go posiadać), a przez to wymagania internautów wzrosły, szczególnie wobec usług e-commerce'owych czy portali newsowych. Jasne, że im dłużej backend będzie przetwarzał dane, tym większa szansa na to, iż zirytowany użytkownik wyłączy stronę, natomiast do tego samego doprowadzimy przenosząc obciążenie na frontend. A może być nawet gorzej, gdyż ta praca przeniesie się na silnik przeglądarki, co może nie pozostać bez wpływu na środowisko osoby próbującej uruchomić stronę.

Ale nie tylko o "zajęcie" komputera chodzi. Przeglądanie Internetu ma to do siebie, że przeglądarki, wyświetlając użytkownikowi jakąś witrynę, pobierają ją na komputer odbiorcy. Robią to tym szybciej, im mniejsze są pliki składają się na stronę WWW. Dlatego tak ważna jest optymalizacja frontendów, szczególnie w przypadku często wyświetlanych i nastawionych na zysk serwisów. Dodanie dodatkowego kodu logiki powoduje, że strony stają się większe i są wolniej zaciągane oraz wyświetlane przez przeglądarkę.

Dodatkowo, wykorzystanie backendu do obliczeń często mobilizuje do zastosowania różnych technik przyspieszających, jak np. cache'owanie. Jeśli aplikacja często jest zmuszona do wyświetlenia wieku użytkowników i pyta o to wiele osób, to szybko dojdziemy do tego, że można wiek obliczać raz, aktualizować w odpowiednich momentach (np. w nocy, za pomocą crona), zapisać w bazie danych i zwracać już obliczoną wartość. Po stronie frontendu też jest możliwe wykorzystanie pamięci podręcznej, ale u każdego użytkownika osobno i niekoniecznie tak szybko.

Przykład z datą urodzenia jest dość klarowny, natomiast w rzeczywistości "uroczy", gdyż odjęcie dwóch dat nie stanowi odpowiedniego wyzwania dla żadnego nowego komputera. Tym niemniej, ta zasada może być rozszerzona na bardziej wymagające obliczenia, jak liczenie podsumowania tysiąca obiektów, wyszukiwanie frazy w wielu długich tekstach czy inne, skomplikowane elementy logiki. Wówczas rzeczywiście urządzenie użytkownika może się "spocić".

Trzeba też nadmienić o tym, że... nie zawsze wydajność serwera jest argumentem za backendem. Jeśli wiemy, że część serwerowa będzie bardzo obciążona, chwilowo nie możemy pozwolić sobie na jej zduplikowanie, a dodatkowy kod po stronie klienta nie spowoduje żadnej różnicy, to być może warto się na ten krok zdecydować. Tutaj przykładem są sieciowe gry wideo, które muszą działać wyjątkowo szybko i sprawnie, gdyż nawet milisekundy mogą mieć znaczenie w batalii pomiędzy graczami. Tam na serwerze są wykonywane tylko absolutnie niezbędne operacje, natomiast kwestie związane z ich wizualizacją i elementy, przy których można pozwolić na pewne "rozsynchronizowanie" są już wykonywane na komputerze odbiorcy. To dlatego w strzelankach typu Valorant bywa podczas tzw. lagowania, że mimo iż poruszyliśmy się na mapie, to gra cofa nas do poprzedniego miejsca, gdyż backend przesyła informację o ostatniej uzgodnionej pozycji gracza, mimo że frontend (aplikacja na komputerze użytkownika) obliczyła już dalszą drogę.

Czytelność kodu

Gdy jeszcze większość aplikacji powstawała w architekturze monolitycznej (np. w PHP), bardzo duże znaczenie miało to, ile kodu znajdowało się w plikach widoku. Idealnie powinna być tam wyłącznie struktura HTML-owa z niezbędnymi dodatkami z danego języka, które wstawiają już przygotowane dane. Powód był dość prosty - im więcej logiki "upychało się" w widoki, tym mniej czytelny kod się stawał. Pomagały (i nadal pomagają) w tym różne silniki szablonów, natomiast jeśli ktoś bardzo chce, to można tak zamącić w warstwie widoku, że kontrolery i klasy logiki się wręcz nudzą.

Wprowadzenie javascriptowych frameworków po stronie frontendu pozwoliło na trochę więcej, gdyż one naturalnie są podzielone i separują kod logiki widoku od samego widoku. Natomiast, jeśli ktoś nie będzie uważał, to również w takiej architekturze jest w stanie napisać frontend w sposób nieczytelny i trudny w orientacji dla innych programistów. Im więcej dłuższych, logicznych fragmentów się w nim znajduje, tym większa szansa, że o danym kodzie powiemy "brzydki" i zostanie źle oceniony podczas przeglądu kodu.

Ma to też znaczenie ze względu na specjalizację programistów - frontendowcy zazwyczaj mają do czynienia z inną logiką niż backendowcy, gdyż w obecnych czasach aplikacje klienckie są na tyle skomplikowane, że - mówiąc kolokwialnie - jest w nich co robić i sporo kodu jest do upchnięcia w różnych klasach oraz komponentach. Jeśli jeszcze do tego dołożymy elementy z backendu, to może się okazać, że odnalezienie się w aplikacji będzie karkołomnym zadaniem.

Ktoś może teraz zapytać, że skoro kod logiki jest w stanie wprowadzić zamieszanie, to czy nie powoduje on bałaganu również po stronie backendu. Otóż, jak najbardziej może. Ale architektura backendu naturalnie tworzy miejsce na taki kod i jego odpowiedni wewnętrzny podział, więc można tam napisać go ładnie i składnie. Jest to też możliwe we frontendzie, ale z uwagi na jego przeznaczenie, trudniej go tam utrzymać.

Bezpieczeństwo

Moim zdaniem kluczowy powód, dla którego logika powinna znajdować się po stronie backendu lub przynajmniej to tam powinny być weryfikowane informacje wprowadzane przez użytkownika. Sprawdzałem - ChatGPT też tak twierdzi.

Wyobraźcie sobie sytuację, w której dodajecie do koszyka produkty w sklepie internetowym. Koszt nabywanych rzeczy jest sumowany i użytkownik może przejść do formularza składania zamówienia. Większość użytkowników nie pomyśli nawet o tym, że mogłaby zmodyfikować cenę, ale są też osoby, które wiedzą o tym, iż przeglądarki internetowe umożliwiają podejrzenie wielu aspektów wyświetlanej strony, w tym jej kod, zarówno HTML, jak i JavaScript. Mało tego - ten kod można zmienić, modyfikując tym samym nie tylko wygląd, ale też zachowanie witryny. Możecie zatem domyśleć się, co by nastąpiło, gdyby ktoś edytował algorytm wyliczający koszt, a backend by tego nie sprawdził.

Dlatego to właśnie część serwerowa, zabezpieczona przed bezpośrednią modyfikacją użytkowników, powinna być miejscem, gdzie znajdują się kluczowe elementy logiki. Wspomniałem wyżej o przykładzie gry wideo, gdzie tylko taki krytyczny obszar znajduje się na serwerze dyrygującym i sędziującym mecz rozgrywany przez graczy. Właśnie dlatego, że o ile nie ma problemu, aby ktoś sobie zmodyfikował kolory banerów czy zmniejszył okno, o tyle niedozwolona jest modyfikacja np. stanu punktów życia i innych elementów mogących wpłynąć na rezultat.

Oczywiście, są obliczenia mniej istotne dla bezpieczeństwa aplikacji. Przykładowo, w większosci przypadków nic by się nie stało, gdyby ktoś zmodyfikował swój wiek. Jednak, naturalne jest przechowywane logiki w jednym miejscu i backend nadaje się do tego znacznie lepiej niż frontend z uwagi na ukrycie go przed użytkownikiem. A sam wiek przecież też może być ważny, np. w operacjach wymagających 18-tego roku życia.

Jednolite środowisko

Jeśli już ktoś umieszcza logikę po stronie frontendu, to najczęściej wykorzystuje do tego najpopularniejszy język obsługiwany przez przeglądarki internetowe - JavaScript. A konkretna technologia ma to do siebie, że czasem się zmienia lub wręcz jest zastępowana. W przypadku dynamicznego świata Internetu ma to dodatkowe znaczenie.

Oczywiście, prawdopodobieństwo, że logika napisana w JavaScripcie nie będzie obsługiwana u każdego użytkownika tak samo, nie jest bardzo wysokie, ale jednak istnieje i nie jest minimalne. Wystarczy jedna nowsza konstrukcja, aby nieco starszy silnik w nieaktualizowanych przeglądarkach sobie nie poradził i albo zgłosił błąd na stronie (powodujący wściekłość i niedowierzanie odbiorcy), albo - co gorsza - spowodował tzw. cichy błąd, czyli aplikacja zadziała, ale z pomyłką w obliczeniach, co może przynieść koszmarne skutki.

Czy w backendzie też nie może to wystąpić? Oczywiście, że może. Ale jako że jako zespół IT zazwyczaj kontrolujemy serwer, na którym umieszczono tę "logiczną" część aplikacji, to mamy też wpływ na aktualizację silników, oprogramowania i konfiguracji. Co za tym idzie - na serwerze konfiguracja jest jedna i wiadomo, na co można sobie pozwolić pisząc kod oraz jaka technologia czy konstrukcje językowe zostaną prawidłowo zinterpretowane na maszynie, z której korzystają wszystkie frontendy.

Zresztą, możemy pójść dalej i przewidzieć wyłączenie JavaScriptu w przeglądarce przez użytkownika. Jest to możliwe i choć obecnie trudno znaleźć złożoną aplikację, która poprawnie zadziała bez JS, to nadal osoby wyjątkowo mocno dbające o swoje bezpieczeństwo nadal wykorzystują tę funkcję. Jeśli nasza logika była właśnie napisana w JS po stronie frontendu, to cóż...

Testowanie

Ten punkt nie ma już takiego znaczenia jak kiedyś, gdyż obecnie istnieją frameworki testujące skupione na technologiach frontendowych. Tym niemniej, nadal zautomatyzowana weryfikacja oprogramowania jest częściej kojarzona z backendem i czasami jest tam zwyczajnie prostsza. A najczęściej testowany jest właśnie kod logiki.

Podsumowanie

Czy to wszystko oznacza, że absolutnie nie można umieszczać logiki po stronie frontendu? Nie do końca - mogą istnieć sytuacje, w których zrobienie tego nie spowoduje znaczących szkód w projekcie. Tym niemniej, na pewno nie powinno być to zasadą, gdyż miejsce obliczeń (szczególnie tych "ciężkich") jest po stronie backendu, a jako główne dwa argumenty należy wymienić bezpieczeństwo (odmieniane w ostatnich latach przez wszystkie przypadki) oraz wydajność (na które zwraca uwagę choćby marketing). Dlatego, jeśli pracujecie jako programiści tzw. full stack, ale historycznie bliżej Wam do frontendu w JS, to zastanówcie się dwa razy, zanim umieścicie tam kod logiki - być może jednak warto przekonać się w tym obszarze do części serwerowej.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Nie szalejmy ze skalowaniem https://wildasoftware.pl/post/nie-szalejmy-skalowaniem?ref=rss https://wildasoftware.pl/post/nie-szalejmy-skalowaniem?ref=rss Thu, 12 Dec 2024 17:30:00 +0000 Dzisiejszy artykuł to dowód na to, że inspiracja do tekstu może przyjść z dowolnego miejsca, w dowolnym czasie. W tym przypadku przyszła z mema, który wyskoczył mi na osi czasu w portalu społecznościowym. Konkretnie chodzi o ten obrazek:

Mem pokazujący bardzo dużą kanapę, gdzie po lewej znajduje się tekst 'kube cluster with 20 nodes, 4 vCPUs each, autoscaling turned on', a po prawej mały kotek na tej kanapie z podpisem 'your app with 12 users'.

Samo zdjęcie jest stosunkowo zabawne samo z siebie - mamy dużą kanapę, która symbolizuje coś wielkiego, pojemnego, potężnego oraz małego kotka, który wygląda, jakby zgubił się na tym meblu. Gdy przyjrzymy się podpisom, to ładunek humorystyczny docenią głównie w osoby zajmujące się programowaniem i wdrażaniem oprogramowania. Mamy bowiem opis środowiska, które wymaga odpowiedniego przygotowania i bardzo dobrej, drogiej maszyny, a z drugiej strony - to wszystko z myślą aplikacji, która ma tak mało użytkowników, że równie dobrze można ją uruchomić na zwykłym "domowym" serwerze i nadal będzie dobrze działać. No, przezabawne.

Po chwili refleksji dotarło do mnie, że w tym memie jest coś więcej - to nie jest tylko internetowa krotochwila, która ma momentalnie uprzyjemnić życie smutnego programisty. To obrazek, który (być może niechcący) uchwycił podejście niektórych, szczególnie młodych, osób do warunków, jakie napotykają podczas procesu wdrażania systemu. Wiadomo, że każdy chce mieć świetny sprzęt dla swojego oprogramowania, jednak prawda jest taka, że nie zawsze "potwór" jest potrzebny i warto się na niego wykosztowywać. Niestety, nie wszyscy to rozumieją i w najgorszym przypadku niekiedy prowadzi to do niesnasek oraz bezsensownych sporów. To specyficzny przypadek bycia "pistoletem" w świecie zdominowanym przez podejście chmurowe i devopsowe.

Dzisiaj rozwiniemy sobie ten temat, co przybierze pewnie bardziej formę eseju. Jednak, aby tekst jednocześnie był edukacyjny, rozwiniemy też sobie też te dziwne skróty, o których traktuje mem będący źródłem tekstu. Być może bowiem niektórzy są zainteresowany tym, czym są te mityczne kontenery, Docker i Kubernetes, o którym kiedyś coś słyszeli.

Czym są kontenery?

Aby w ogóle zacząć wyjaśniać to, o czym wspomniałem pod koniec wstępu i dlaczego ten mem jest śmieszny, musimy opowiedzieć sobie o tym, czym są kontenery. Z góry uprzedzam, że to słowo będzie się pojawiać w tekście bardzo często.

Być może niektórzy znają pojęcie maszyn wirtualnych - są one niejako "komputerami w komputerze". Mówiąc ściślej, w naszym systemie operacyjnym (gospodarzu) możemy mieć oprogramowanie, które umożliwia wydzielenie zasobów na potrzeby instalacji dodatkowych, osobnych systemów operacyjnych, które są izolowane i stanowią same w sobie działające środowiska. W ten sposób można coś przetestować, uruchomić np. Linuksa w Windowsie (albo odwrotnie), ale także wydzielić miejsce na hostowanie konkretnej aplikacji. Oznacza to, że jeden system może tworzyć środowiska dla wielu klientów korzystając z jednego komputera - tak właśnie powstają wirtualne serwery prywatne (VPS) oferowane przez wiele firm. Te dzielą wówczas potężną fizyczną maszynę na wiele mniejszych, wirtualnych.

Zaletą maszyn wirtualnych jest to, że są izolowane i mogą mieć dynamicznie modyfikowane parametry (przynajmniej niektóre). Zwiększenie np. pamięci RAM nie oznacza bowiem faktycznego dołożenia dysku do komputera, a więc jego rozkręcenie, wmontowanie układu scalonego i ponownego uruchomienia, tylko przesunięcie suwakiem odpowiedniej wartości w narzędziu do wirtualizacji i ewentualnie restart. Jednak "wirtualki" mają jedną wadę, która od razu się narzuca osobom, które miały z nimi do czynienia nawet w domowych warunkach - są "ciężkie". To systemy operacyjne działające w ramach innego systemu operacyjnego, gdzie fakt istnienia maszyny fizycznej jest symulowany - to musi kosztować pierwotny system odpowiednie zasoby, a do tego wpływać na wydajność samego środowiska, który jest "gościem", gdyż to wszystko nie działa natywnie. Co prawda, w większości zastosowań (do czego jeszcze wrócimy i jest sednem dzisiejszego tekstu) i tak to wystarcza, ale niepokorni ludzie z IT znaleźli inne rozwiązanie.

Są nimi kontenery, które są ściśle powiązane z systemami uniksowymi. Stanowią sposób na wirtualizację, ale już na poziomie systemu operacyjnego - ten pozwala utworzyć "pudełko" z wydzielonymi zasobami i w którym instalowane są konkretne moduły. Gdzie jest zatem haczyk? Podczas gdy maszyny wirtualne symulują CAŁY komputer (łącznie ze wszystkimi podzespołami itd.), to kontenery działają w ramach systemu operacyjnego gospodarza, bez pośredników w postaci narzędzi do pełnej wirtualizacji. To sprawia, że są dużo "lżejsze", a co za tym idzie, wydajne i zarządzanie nimi jest prostsze koncepcyjnie. Fakt, że są bliżej hosta sprawia, że izolacja nie jest aż tak mocna, ale z odrobiną uwagi nie powinno to stanowić żadnego problemu dla cyberbezpieczeństwa.

Dlaczego kontenery są takie ważne i zrewolucjonizowały zarządzanie aplikacjami w wielu przypadkach? Choćby dlatego, że:

  • pozwalają przygotować środowisko wcześniej i wgrywać je w praktycznie niezmienionej formie na różne maszyny,
  • izolują się od komponentów aplikacyjnych hosta, czyli np. mogą korzystać ze swojego serwera HTTP niezależnie od tego, czym dysponuje gospodarz,
  • można dokładnie określić wersje modułów, a więc nie powinno być sytuacji, że na jednej maszynie aplikacja działa, gdyż jakiś komponent jest w wersji 3.3, a na drugiej maszynie już jest problem, gdyż tam akurat ktoś zainstalował 3.4,
  • nie wymagają instalacji wszystkich komponentów aplikacji bezpośrednio u programisty i żonglowania wersjami oprogramowania (np. programista może swobodnie pracować nad rozwojem dwóch aplikacji, z których jedna wymaga PHP 7.4, a druga PHP 8.3 - zamiast tego stawia sobie pudełko "all-in-one"),
  • wiąże się z nimi mały narzut czasowy i zasobowy, więc nie obciażają systemu w taki sposób, aby stanowiło to problem,
  • przez swoją "lekkość" można łączyć kontenery w taki sposób, aby korzystały z siebie nawzajem i nadal jest to wydajne, a jednocześnie odizolowane od reszty.

Od razu wyjaśnię jedną rzecz - tak, maszyny wirtualne także teoretycznie można współdzielić. Problem w tym, że są one tak niewydajne i duże, że nie ma to żadnego sensu praktycznego. Dodatkowym problemem staje się aktualizacja kodu przekazywanego do takiej maszyny wirtualnej - jest to wykonalne, ale po prostu niewygodne.

Kontenery stanowią podstawę metodyki DevOps i wielu procesów wdrożeniowych, ułatwiają aktualizację oprogramowania i generalnie stały się odpowiedzią na wiele problemów w wytwarzaniu software'u. Nie są bez wad - wymagają trochę wiedzy przy konstrukcji reguł, które je tworzą i zarządzają, a także odpowiedniego środowiska, które pozwala obsługiwać takie pakiety. Tutaj na scenę wkracza m.in. Docker, który jest właśnie usługą do zarządzania takimi paczkami - to za pomocą Dockera możemy uruchamiać kontenery, pobierać ich obrazy, zatrzymywać, wchodzić do ich wnętrza itd. Jednocześnie należy pamiętać, że Docker nie jest tym samym co kontener (podobnie jak Word nie jest dokumentem tekstowym), a samo oprogramowanie z charakterystycznym logiem przedstawiającym niebieskiego walenia nie jest jedynym, które potrafi obsłużyć kontenery - istnieją też choćby LXC czy Podman (często polecany zamiast Dockera ze względu na brak potrzeby uzyskania tak dużych uprawnień do systemu, choć ma też wady).

Co jest dla nas ważne w kontekście mema? Kontener to "pudełko", które zawiera jeden (zazwyczaj; może być ich wiele) komponent aplikacji, np. frontend, backend, bazę danych, system cache'ujący lub coś innego. Nie jest rzadkim przypadkiem sytuacja, że programista musi skorzystać w jednym projekcie z PostgreSQL, ale nie chce go instalować na swoim komputerze, więc uruchamia sobie kontener.

Czym jest Kubernetes?

Gdy ludzie zaczęli masowo wykorzystywać kontenery, szybko okazało się, że faktycznie powstaje ich dużo. Na tyle dużo, że same programy typu Docker przestały wystarczać, gdyż pojawiła się potrzeba zarządzania wieloma kontenerami, ich kolejnością, skalowaniem itd. I nie mówimy tutaj o komputerze programisty, który ma uruchomionych kilka takich paczek, tylko środowiskach produkcyjnych, gdzie może być ich znacznie więcej, ich obsługa jest krytyczna, są na wielu serwerach, ale przede wszystkim są skalowane. Jest to coś, co nazywa się fachowo orkiestracją, a więc można wyobrazić sobie, że potrzebny jest dyrygent, który ma pieczę nad wieloma muzykami grającymi na różnych istrumentach i decyduje, którzy włączają się w określonych momentach, jak głośno to robią i ilu wykonawców z danego obszaru jest potrzebnych, aby orkiestra pięknie grała.

Takich "dyrygentów" jest kilku na rynku i jednym z najprostszych jest Docker Compose, który ułatwia w Dockerze uruchamianie i zarządzanie kilkoma kontenerami naraz. Jednak do potężnych zastosowań serwerowych jest zazwyczaj niewystarczające, zwłaszcza, jeśli mamy do czynienia nie z jednym, tylko kilkoma instancjami połączonymi w tzw. węzły (ang. nodes). W związku z tym istnieje drugie narzędzie od twórców Dockera, które nazywa się Docker Swarm - posiada więcej możliwości oraz rzeczywiście pozwala na prowadzenie "orkiestry" stworzonej z wielu serwerów. Jednak nawet Swarm, który jest stosunkowo prosty w obsłudze (w porównaniu do kolejnego bohatera tekstu), może nie wystarczyć w bardziej zaawansowanych przypadkach - wówczas na scenę wkracza rzeczony Kubernetes, zwany też skrótowo K8s.

Jest to złożony, modułowy system, pozwalający zautomatyzować wdrażanie (ang. deployment) skonteneryzowanych aplikacji, uprzyjemnia ich skalowanie (także pozwalając zdać się na algorytmy, które automatycznie wyliczą odpowiednie ustawienie) oraz po prostu codzienne zarządzanie. Dzieli infrastrukturę na klastry, wspomniane już węzły, a także pody, które można wyróżnić w ich ramach. Co ciekawe, to projekt open source, którego początków należy szukać w Google'u, ale teraz zarządza nim fundacja Cloud Native Computing Foundation (CNCF). Co ważne, to system, który może być rozszerzany, wokół którego urosła bardzo duża społeczność oraz powstały liczne narzędzia pomagające w obsłudze. A te przydają się tym bardziej, że Kubernetes jest dość skomplikowany i jego konfiguracja nie należy do rzeczy, które robi się z marszu, między pierwszą kawą a śniadaniem.

To, co musimy wiedzieć w kontekście mema będącego bohaterem tego odcinka, to fakt, że Kubernetes jest systemem ułatwiającym zarządzanie kontenerami na potencjalnie wielu serwerach. Co ważne, kontenery możemy też uruchamiać na wirtualnych serwerach - dla orkiestratorów nie ma znaczenia, czy coś działa na fizycznej maszynie, czy zwirtualizowanej, bo serwer to serwer.

Mem ze wściekłą postacią z filmu animowanego Iniemamocni, gdzie mężczyzna zdaje się krzyczeć 'serwer to serwer'.

Jak określa się liczbę użytkowników aplikacji?

Z drugiej strony mamy informację o tym, że z aplikacji korzysta 12 osób. Wbrew pozorom, nie jest to taki rzadki przypadek - software house'y często tworzą oprogramowanie dla danej firmy, dedykowane ich potrzebom i konkretnym pracownikom, a wiadomo, że firmy mają różny rozmiar. Nawet system dla 12 osób ma sens, jeśli rozwiązuje problem, potrzebę biznesową lub zwyczajnie przyspiesza pracę, pozwalając np. obsłużyć więcej zgłoszeń od klientów.

Określanie liczby użytkowników aplikacji to zadanie niekiedy dość trudne. Prosta sytuacja to właśnie oprogramowanie dla konkretnej grupy osób, gdyż wiadomo, jak liczna ona jest. Jednak nawet w takich przypadkach trzeba pamiętać o tym, że systemy IT rozwijają się, podobnie jak potrzeby klientów. Aplikacja, która na początku była przeznaczona dla 10 osób, z czasem może być przekształcona w coś większego lub zwyczajnie firma może urosnąć. Jeszcze trudniej jest z oprogramowaniem przeznaczonym na wolny rynek, mające przyciągnąć jak najwięcej osób - określanie tak dużej grupy docelowej to zadanie już bardziej marketerów i sprzedawców, jednak zespół IT musi przewidzieć infrastrukturę, która nie załamie się przy założeniu X jednoczesnych osób.

No właśnie - o czym w ogóle mówimy w kontekście mierzenia rozmiaru użytkowników? Przede wszystkim, o ile sami użytkownicy są właściwym terminem z punktu widzenia marketingu i "zwykłych" ludzi, o tyle mierząc systemy mówimy raczej o tym, ile żądań HTTP jest w stanie obsłużyć. Zależy to od wydajności aplikacji, ustawień serwera HTTP, mocy maszyny i wielu innych czynników - określenie tego nawet w przybliżeniu jest bardzo trudne. Można za to testować wydolność oprogramowania poprzez różne programy, jak np. JMeter czy k6.

To, o czym jeszcze trzeba pamiętać, to fakt, że liczba przyjmowanych żądań może być jednoczesna lub maksymalna. Ta pierwsza wartość to średnie, realne obciążenie aplikacji przez większość czasu. Szczególnie często mówimy o tym w przypadku serwisów społecznościowych, serwerów gier, ale też aplikacji dedykowanych firmom, gdzie zakładamy, że oprogramowanie będzie wykorzystywane np. 8 godzin dziennie przez 40 osób. Natomiast w pewnych przypadkach trzeba wziąć pod uwagę możliwe "piki", a więc momenty, w których żądania nagle rosną do wyjątkowo dużej liczby i serwer musi to obsłużyć. Przykładem może być news na stronie klubu sportowego, nowy artykuł na popularnym blogu czy ogłoszenie konkursu. Także przy organizacji Rankingu "OpowiemCi" organizatorka musi się z tym zmagać, gdyż w momencie ogłoszenia otwarcia możliwości głosowania, ustawienia serwera muszą być zmienione w taki sposób, aby przez kolejne kilka dni przyjąć zwiększony ruch.

Także jedna rzecz, to temat prawdopodobnego wolumenu użytkowników korzystających z aplikacji jednocześnie i w "gorących" momentach. Drugie to określenie, jaka infrastruktura jest do tego wymagana - to już znacznie trudniejsze i często bardziej wynikające z doświadczenia lub eksperymentów.

Czy Kubernetes zawsze jest potrzebny?

I tutaj dochodzimy do pewnego - nie bójmy się tego powiedzieć - wariactwa. Nie każda aplikacja musi być przygotowana na potężną infrastrukturę, tak samo jak nie do każdego systemu IT trzeba kupować chmurę i organizować solidny pion administracyjny. Mówiąc wprost, duża część oprogramowania powstającego na co dzień może działać na normalnych, prostych serwerach, gdzie często programiści mają mniejsze możliwości niż ma root, ale też większy spokój z racji zapewnienia całej konfiguracji przez wykwalifikowane zespoły.

Natomiast czasami można spotkać się z innym podejściem osób w IT wychowujących się w czasach, kiedy mówi się tyle o chmurach, konteneryzacji itd., którzy uważają, że absolutnie każde oprogramowanie działające na serwerze musi korzystać z tych udogodnień. Aplikacja składająca się z jednego formularza widocznego dla kilkudziesięciu osób? Trzeba kupić instancję AWS! System sprzedażowy dla kilku osób? Będziemy skalować horyzontalnie na czterech maszynach! Prosta strona typu landing page w technologiach stosowanych i tak w innych aplikacjach firmy? Najpierw trzeba poświęcić cały dzień na szczegółową definicję kontenera w pliku Dockerfile! No bo przecież tak robią teraz we wszystkich startupach, w Ju-Es-Ej, Dolinie Krzemowej, więc my też musimy! Widziałem w tutorialach na YouTube!

Oczywiście, trochę sobie teraz żartuję i to, co piszę, absolutnie nie oznacza, że nie należy myśleć o przyszłości i przygotować aplikację np. na skalowanie lub do konteneryzacji (która akurat bardzo może się przydać, szczególnie przy samym rozwoju kodu). Zresztą, przykład z aplikacją z jednym formularzem może być o tyle nietrafiony, że ten formularz może być ogólnodostępny w trybie 24/7 oraz wykorzystywany przez dziesiątki tysięcy osób, a więc umieszczenie jego kopii na kilku serwerach może mieć sens. Ale właśnie - może i trzeba robić to z rozmysłem. Wszystko zależy od sytuacji i oceny architektonicznej - nie zawsze potrzebna jest solidna infrastruktura zarządzana przez doświadczonego DevOpsa, aby wdrożyć jakąś aplikację, która ma szybko przynosić efekty. Są takie, w których ma to przyszłość i wyższe koszty są uzasadnione, ale w wielu przypadkach nie ma to żadnego sensu, gdyż software house lub klient się wykosztują, a efekt nie będzie odczuwalny ani w krótkiej, ani w dłuższej perspektywie. Nie wszyscy to rozumieją i bywają z tego powodu niesnaski - to podobny przypadek, jak niechęć głównego programisty do zastosowania pewnej, modnej technologii, jeśli nie stoi za tym żaden solidny argument przeważający nad kontrargumentami. Bo uwierzcie - moda i "bo wszyscy to robią" to zdecydowanie za mało, aby np. do zespołu i projektu, którego 99% stosu technologicznego to Java, wprowadzać nagle Rusta.

To podobny przypadek, jak z zaawansowaną architekturą oprogramowania - oczywiście, zawsze dobrze jest, gdy jest ono podatne na skalowanie, rozwój, rozszerzenie i nie zamyka się na początkowe warunki. Natomiast trzeba też wziąć pod uwagę rozsądek oraz biznes - jeśli klient oczekuje aplikacji dla kilkunastu osób z kilkoma prostymi widokami i to się nie zmieni w ciągu najbliższych lat, to tworzenie architektury mikroserwisowej tylko po to, aby była, mija się z celem, gdyż więcej czasu zabierze przygotowanie odpowiednich struktur aniżeli realne napisanie funkcjonalności. Dużo lepiej w takim przypadku jest napisać to prościej, szybciej, a mając już solidnie przygotowany kod działający dla "mniejszej" infrastruktury, dostosować wszystko do większego ruchu, gdy rzeczywiście realne jest, że on nadejdzie. Natomiast - z góry uprzedzając rozjuszony tłum, który nie zgadza się z tym zdaniem - wszystko zależy od sytuacji, warunków i założeń. Są sytuacje, w których faktycznie trzeba myśleć o przyszłości. A są takie, gdzie będzie to zwykłe przepalanie budżetu, czasu i mocy przerobowych tylko po to, aby poczuć się "profesjonalnie".

Podsumowanie

Zbierając wszystko do prostego wniosku - aplikacja działająca dla 12 osób, o ile nie jest wyjątkowo skomplikowana, bez problemu powinna dobrze działać na prostym serwerze. Niepotrzebna jest infrastruktura składająca się z 20 węzłów, po 4 wirtualne rdzenie procesora każdy, samodzielnie się skalująca w zależności od potrzeb i zarządzana Kubernetesem, aby uruchomić takie oprogramowanie. To klasyczny przykład wyciągania armaty na mrówkę.

To nie oznacza, że w każdym przypadku przygotowywanie systemu IT na bardziej złożone warunki nie ma sensu - jak najbardziej warto o tym myśleć, ale też realizować wtedy, kiedy rzeczywiście opłaci się to w krótszej lub nieco dalszej przyszłości.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Oprogramowanie w służbie czytaniu https://wildasoftware.pl/post/oprogramowanie-sluzbie-czytaniu?ref=rss https://wildasoftware.pl/post/oprogramowanie-sluzbie-czytaniu?ref=rss Thu, 07 Nov 2024 17:30:00 +0000 Patrząc na profil naszej firmy, można pomyśleć, że jedyne książki, jakie czytają i śledzą nasi pracownicy, to literatura fachowa, opisy coraz bardziej zaawansowanych koncepcji IT i poradniki dotyczące nowych technologii. Ale to nieprawda - nie samą informatyką programista żyje i po pracy potrzebuje oderwania się od pisania kodu oraz analizowania struktury aplikacji. Nasi pracownicy mają różne hobby - znajdą się u nas wspinacze, chórzyści, filmowcy, miłośnicy górskich wycieczek, oddani fanatycy anime, znawcy Drogi Herbaty, zapaleńcy planszówek i wreszcie - czytelnicy. Wielu z nas czyta książki w wolnym czasie i choć króluje fantastyka, to w obszarze zainteresowania znajdą się też inne gatunki.

Dlaczego o tym w ogóle piszę? Ponieważ literatura jest hobby i dziedziną kultury, które od długiego czasu wspierane jest nowinkami technologicznymi. Dzisiejszy rynek książki nie istniałby w takim kształcie, gdyby nie rewolucja informatyczna, która dotknęła wiele obszarów, w tym także ten. I choć czytelnicy są czasem postrzegani jako osoby o dość “konserwatywnym" hobby, opierającym się na papierze i bibliotece, to nie da się ukryć, że przy pomocy rozwiązań IT można czytać więcej, sprawniej, łatwiej docierać do interesujących nas pozycji, a także dzielić się swoimi opiniami, próbując zaistnieć tym w mediach. Ale nie dotyczy to tylko odbiorców - także pisarze czy wydawnictwa nie mogą obyć się dzisiaj bez technologii. Począwszy od elektronicznego składania tekstu, poprzez e-booki, aż po marketing i śledzenie opinii czytelników w Internecie.

Wokół książek jest ogromne pole do popisu dla twórców aplikacji i to mimo że tort na rynku IT wydaje się już dawno podzielony. Natomiast zdajemy sobie sprawę, że nie wszyscy mogą wiedzieć o narzędziach, które uprzyjemnią im proces wybierania czy pozyskiwania lektur. Dlatego w tym artykule zrobimy sobie przegląd oprogramowania, jakie jest obecne w tej branży, a także zastanowimy się, czy czegoś nie brakuje.

Zanim zaczniemy, mamy jeszcze przyjemność ogłosić, że jako Wilda Software zostaliśmy partnerem Rankingu “Opowiemci" w odsłonie na 2024 rok. Czytelnicy, którzy żywo śledzą rynek książkowy lub nawet o nim dyskutują, zapewne znają inicjatywę - jest to plebiscyt organizowany co roku przez Beatę Skrzypczak (znaną w Internecie właśnie jako “Opowiemci"), którego założeniem jest uhonorowanie osób tworzących materiały o literaturze i które w ogromnej mierze robią to w ramach wolnego czasu, nie utrzymując się z tego. Nie znaczy to jednak, że nie wymaga to pracy - wręcz przeciwnie, dzielenie się wartościowymi treściami wymaga najcenniejszego zasobu, jaki posiadamy, a więc czasu. Nierzadko pozwala to odbiorcom dowiedzieć się czegoś o książkach, które mają na celowniku (i nie chcą nabywać kota w worku) lub którymi warto się zainteresować z różnych powodów. Sam nie miałbym tak potężnej (i coraz dłuższej) literackiej listy życzeń, gdyby nie praca blogerów lub osób, które są napędzane przez dyskusje pod wpisami twórców. Stąd pomysł Beaty na ranking, w którym tacy “nadawcy" są nominowani w różnych kategoriach i na których głosuje społeczność, czego efektem końcowym może być statuetka za dany rok. Idea szczytna, a wiemy, że Beata poświęca na to masę czasu, więc wierzymy, że w ten sposób możemy jej choć trochę pomóc, a Was zaciekawić samym rankingiem oraz książkową blogosferą. Kto wie - może dzięki niemu dotrzecie do twórców, których gust pokrywa się z Waszym i dowiecie się o wartościowych książkach, o których do tej pory nie mieliście pojęcia.

A swoją drogą, sama Beata też jest autorką, na ten moment znaną z powieści “El Roi" - połączeniu literatury pięknej, realizmu magicznego i powieści historycznej. Ptaszki ćwierkają, że za jakiś czas nie będzie to jedyna pozycja w dorobku tej pisarki, więc za wiele lat możecie powiedzieć, że mieliście okazję śledzić jej drogę od początku.

A teraz wracamy do technologii.

E-booki i audiobooki

Nie wiem, czy najważniejszą, ale na pewno jedną z ważniejszych nowinek technologicznych ostatnich kilkunastu lat jest możliwość czytania książek w sposób elektroniczny. I nie mam tutaj na myśli pobrania pliku PDF oraz czytania na ekranie telefonu komórkowego (w taki sposób mój kolega z liceum przeczytał całą Sienkiewiczowską Trylogię w wakacje) - ani to wygodne, ani zdrowe dla oczu, gdyż wymaga wpatrywania się w ekran LCD, który na dłuższą metę nam zwyczajnie nie służy.

Wszystko realnie zmieniło się wraz w 1997 roku za sprawą tzw. ekranu e-ink i pierwszego czytnika e-booków. Zaczęła się era urządzeń, które nie męczą nadmiernie wzroku, umożliwiają czytanie w ciemności, nie wymagają żonglowania dużymi tomiszczami, ułatwiają katalogowanie pozycji i wyszukiwanie fragmentów tekstu, a u niektórych w ogóle przyspieszają proces czytania. Nie będziemy tutaj wchodzić w szczegóły technologii, a także polecać konkretnych modeli - wszyscy wiedzą, że na tym rynku obecnie rządzi Amazon ze swoim Kindlem, ale warto też interesować się konkurencją, jak np. Pocketbookiem, Inkbookiem czy Onyxem - recenzje nowych modeli możecie poczytać w serwisie Świat Czytników. Warto też pamiętać, że takie czytniki nie obsługują tylko PDF-ów, które prawdopodobnie są w mniejszości - znacznie częściej czytelnicy sięgają po pliki EPUB oraz MOBI, z których do niedawna ten drugi kojarzył się z Kindlem, ale od pewnego czasu nawet Amazon proponuje zwrot w kierunku bardziej otwartego EPUBa.

Ciekawe z punktu widzenia tworzenia oprogramowania jest zagadnienie systemu operacyjnego na takich czytnikach. Tak naprawdę na rynku króluje jedno rozwiązanie - jest to system Linux, który przez swoją otwartość może być dostosowany praktycznie do każdej maszyny, dzięki czemu zawitał także właśnie na czytnikach. Jednak bardziej zorientowani wspomną także o Androidzie oraz Fire OS, które dają jeszcze większe możliwości (i są prawdopodobnie prostsze dla twórców aplikacji), natomiast również u podstaw mają system spod znaki pingwina.

E-booki to zwykłe pliki w formatach, które wspomnieliśmy sobie wyżej. Można zatem pomyśleć, że ich kopiowanie jest bardzo proste, co po chwili prowadzi do wniosku, że w takim razie musi tu istnieć piractwo na ogromną skalę. Cóż, nie da się zaprzeczyć temu, że sam proceder zapewne istnieje, jednak nie bez powodu w księgarniach e-booków po kupieniu pozycji:

  • trzeba zaznaczyć, iż rozumiemy, że to produkt cyfrowy, w związku z czym nie możemy go zwrócić (o prawnych aspektach poczytacie tutaj),
  • musimy chwilę poczekać na podpisanie książki unikalnym identyfikatorem.

Właśnie ta ostatnia czynność ma zabezpieczyć pobrany przez nas plik w taki sposób, aby maksymalnie utrudnić nam jego dalsze niekontrolowane powielanie lub przynajmniej wprowadzić informację, dla kogo został on wygenerowany (co, jak nietrudno się domyśleć, potem będzie krążyć po Internecie, gdyby plik wypłynął). Wreszcie, istnieje też zabezpieczenie DRM (ang. Digital Rights Management), które jednak wraz z większą ochroną przynosi większe restrykcje i z tego powodu był swego czasu przedmiotem dużych dyskusji np. w środowisku gier wideo. Same zabezpieczenia (nie tylko e-booków) to zresztą materiały na osobne artykuły z obszaru cybezpieczeństwa.

Wreszcie, na koniec tej przydługiej sekcji, trzeba wspomnieć o tym, że niektórzy nie mają jak czytać e-booków, gdyż nie mają urządzenia lub nie mogą na nie patrzeć w danym momencie. Dla takich osób opracowano audiobooki, o których można powiedzieć, że są nowoczesnym stadium słuchowisk radiowych. Możemy w ten sposób nie tyle czytać, co słuchać książek, np. podczas sprzątania, jazdy samochodem czy po prostu leżenia na kanapie. Te pliki z kolei są najczęściej zapisane w postaci plików MP3, WAV, AAC czy FLAC i ich wydawanie jest bliższe prawdziwym książkom lub płytom muzycznym. Mogą też być droższe z uwagi na to, że do ich wyprodukowania potrzeba lektora, który przeczyta całą książkę, a ktoś to nagra i zweryfikuje. No, zazwyczaj zweryfikuje.

Oferty e-booków i audiobooków

Pojawienie się e-booków zrewolucjonizowało nie tylko czytanie (choć wcale nie mają takiego udziału w rynku, jakiego można by było się spodziewać), ale przede wszystkim utworzyło nowe gałęzie na rynku książki, gdyż np. jakoś te elektroniczne wydania trzeba dystrybuować. Wspomnimy tutaj o dwóch głównych formach tego procesu.

Pierwszy to, oczywiście, księgarnie internetowe. Istnieją takie, które oferują zarówno produkty fizyczne, jak i cyfrowe, ale też takie, które zawierają wyłącznie e-booki i audiobooki. Działa to jak w każdym sklepie internetowym, jednak różnica tkwi w sposobie dostarczenia towaru. Tutaj wracamy do tego, o czym pisałem w poprzedniej sekcji - podpisanie e-booka, na co trzeba chwilę poczekać. W zamian użytkownik nabywa od razu książkę we wszystkich formatach e-bookowych. Takie pliki przegrywa się potem na czytnik z komputera za pomocą kabla USB lub przez chmurę i po prostu czyta. Warto też pamiętać, że audiobooki są nabywane osobno, gdyż to jednak inna forma “czytania" - kupując e-book nie dostaje się w pakiecie wersji dźwiękowej w tej samej cenie.

Przykłady: Virtualo, Publio, Świat Książki, Ibuk, Ebookpoint, Woblink, Gandalf, Empik i wiele innych. Do tego, jak wybierać najlepszą ofertę, jeszcze dzisiaj dojdziemy.

Drugi format dystrybucji to cyfrowe biblioteki, w których użytkownik płaci abonament i w jego ramach ma dostęp do zestawu książek. Mówiąc wprost, są to serwisy typu Netflix czy HBO Go, ale z myślą o literaturze. Co ciekawe, część takich portali oferuje zarówno formę sklepu, jak i biblioteki, jednak ceny zdecydowanie premiują wypożyczanie, gdyż biorąc pod uwagę cenę pojedynczej pozycji, to w ramach comiesięcznej wpłaty można przeczytać znacznie więcej. Jest to doskonała forma dla osób, które pochłaniają masę książek, ale nie potrzebują ich posiadać, a dostęp do Internetu i odpowiednia aplikacja nie jest dla nich problemem. Gdyż właśnie - tego typu forma dystrybucji wymaga instalacji specjalnej aplikacji danego serwisu na urządzeniu mobilnym lub czytniku (aczkolwiek wiele czytników na polskim rynku ma wbudowane oprogramowanie). Jest to, oczywiście, utrudnienie atakowania i przechwytywania plików z e-bookami i audiobookami, które byłoby nieco prostsze, gdyby był możliwy dostęp webowy, gdzie do dyspozycji są choćby opcje developerskie w przeglądarce. Dzięki konkretnym aplikacjom sprawa znacznie się komplikuje, a wręcz można powiedzieć, że ten dostęp jest zamknięty.

Jako przykłady wyróżniają się przede wszystkim dwa serwisy - Legimi oraz Empik Go. Jednak warto pamiętać, że istnieją też alternatywy, także te związane z audiobookami - Storytel, Audioteka i inne. Tam z kolei jeszcze bardziej na znaczeniu zyskuje strumieniowanie danych, a więc sukcesywne, czasowe pobieranie pliku w częściach. Samą technikę większość doskonale zna z serwisów typu Youtube lub portali stworzonych z myślą o podcastach.

Takie księgarnie, a w jeszcze większym stopniu biblioteki to duże pole do popisu dla architektów oprogramowania, którzy muszą zadbać nie tylko o aspekt sklepowy, wsparcie dla SEO, ale też przepustowość (choć w przypadku książek na pewno jest tu mniejsze zagrożenie dla serwisu niż przy filmach, serialach lub grach) oraz bezpieczeństwo, zarówno użytkowników, jak i samych produktów.

Przy tej okazji warto też wspomnieć, że nie tylko kupowanie książek stało się prostsze (klik i już możemy je pobrać, a nie czekać kilka dni na dostawę) - łatwiejsze stało się też ich wydawanie. W przypadku tradycyjnych wydań, po korekcie, redakcji, składzie i ew. opracowaniu planu marketingowego (co się nie zmieniło co do zasady, choć i te czynności stały się łatwiejsze) jest jeszcze etap drukowania, pakowania i klasycznego dostarczania książek do sklepów i odbiorców. Jeśli jednak ktoś decyduje się na publikację wyłącznie elektronicznej wersji, “wystarczy" przygotować gotowe pliki i dostarczyć do księgarni internetowych. Oczywiście, to nadal nie jest prosty proces, a i same e-booki nie zapewnią takiego zysku jako kombinacja z papierem, ale może być to rozwiązanie w przypadku początkujących autorów, którzy chcą spróbować wydać książkę bez udziału wydawnictwa (tzw. self-publishing).

Porównywarki cen

Ktoś mógłby powiedzieć, że przecież tego typu serwisy są obecne w Internecie od dawna i dotyczą wszystkich gałęzi produktów, więc dlaczego wspominamy o nich w kontekście literatury. Robimy to, ponieważ istnieją serwisy, które specjalizują się w e-bookach i porównywaniu ich cen.

To kolejny przykład na to, że wprowadzenie jednego elementu na rynek pociąga za sobą inne, współdziałające z nim. Tak jest też tutaj, gdzie serwisy takie jak Świat Czytników (będący też jednocześnie serwisem informacyjnym o e-bookach) czy UpolujEbooka pozwalają śledzić oferty dotyczące wyczekiwanych książek. A że zazwyczaj zapaleni czytelnicy mają bardzo dużo pozycji na swoich listach życzeń, to tego typu portale są na wagę złota i nie wymagają codziennego ręcznego przeglądania promocji.

A to z kolei daje możliwości marketingowe i współpracy z księgarniami internetowymi, zapewniając wsparcie dla takich serwisów, które dzięki temu mogą przyciągać większą grupę użytkowników, potencjalnie dostarczając księgarniom więcej klientów - to sytuacja korzystna dla obu stron. Tego typu kooperacja może też pomagać w pobieraniu danych o cenach - warto zatrzymać się na chwilę i przeanalizować, jak technicznie takie serwisy uzyskują informacje o nowych i zmienionych ofertach.

  • cykliczne odpytywanie API księgarń o ceny produktów (tzw. polling) - najbardziej klasyczna i najprostsza koncepcyjnie forma, ale też najbardziej obciążająca zarówno porównywarkę, jak i sprzedawców. Dodatkowo, nie rozwiązuje problemu pobierania informacji o nowych ofertach.
  • przesyłanie przez księgarnie informacji o nowych ofertach do porównywarek - czyli odwracamy komunikację i pozbywamy się okresowości na rzecz przesyłu danych dopiero w przypadku zmiany cen lub produktów. Jest to świetne rozwiązanie z punktu widzenia wydajności i obciążenia (nie jest pobierana masa danych co np. godzinę - aktualizacje są nieregularne i znacznie mniejsze, choć to zależy od implementacji), ale księgarnie czy sklepy musiałyby taki mechanizm implementować, a wiadomo, że “tyle to nie". Tym niemniej nie wykluczamy, że w przypadku mocniej zacieśnionej współpracy właśnie tak to może działać.
  • ręczne uzupełnianie cen w porównywarce - czyli porównywarka dostarcza nie tyle API, co interfejs, w którym pracownik sklepu z e-bookami może ręcznie wprowadzać produkty i ceny. Rozwiązanie najprostsze z punktu widzenia serwisu z cenami, ale prawdopodobnie najgorsze z punktu widzenia księgarni, gdyż wątpię, aby jej pracownicy mieli czas uzupełniać ceny np. w przypadku większych akcji promocyjnych. Tym niemniej, zależy to od możliwości takiego interfejsu oraz rotacji produktów, choć trzeba przyznać, że w przypadku sklepów z e-bookami bywa ona duża.
  • crawlowanie i scrapowanie stron księgarni - najbardziej “hakerski" sposób, polegający również na odpytywaniu sklepów, ale nie poprzez ładne API, tylko próbę zaciągnięcia danych poprzez analizę struktury HTML. Sposób paskudny z wielu powodów (choć niekiedy konieczny, jeśli to porównywarce zależy na wartościach, a nie księgarnia wcale tego nie ułatwia), ale wspominam o nim w ramach ciekawostki.

W przypadku porównywarek e-bookowych można domniemywać, że jako iż obu stronom zależy na rozwoju i jest to samonapędzający się mechanizm, to obie będą sobie pomagać. Świadczyć może o tym też to, że w propozycjach ofert nie występują wszystkie księgarnie, a więc twórcy serwisu mogli świadomie je odpuścić, jeśli te nie ułatwiły pozyskania cen.

Katalogowanie zbiorów

Tego typu programy znają przede wszystkim osoby, które kolekcjonują dane przedmioty (np. książki), ale nie tylko - pasjonaci literatury czytają tak dużo, że nierzadko zdarza się, że czytają lub kupują coś, co już mają na koncie, ale o tym nie pamiętają, a nie skojarzyli po autorze, tytule lub okładce. Wiadomo, że jeśli książka jest dobra i tania, to aż tak nie szkoda, ale przeważnie mamy wówczas poczucie straconego czasu lub pieniędzy. Jak się przed tym uchronić? Katalogując swoje zbiory.

I niektórzy powiedzą tutaj, że doskonale sprawdzi się w tym arkusz kalkulacyjny, co można zrozumieć, ponieważ rzeczywiście - Excel, Google Spreadsheets czy LibreOffice Calc są odpowiedzią na więcej problemów informatycznych niż podejrzewamy. Do przechowywania przeczytanych lub pożądanych książek mogą służyć też serwisy, o których opowiemy sobie w następnej sekcji. Natomiast, jeśli mamy potrzebę posiadania osobnego programu do magazynowania tego typu informacji, to istnieją choćby takie programy jak otwardoźródłowy Calibre, który po instalacji na komputerze pozwala zarządzać swoją kolekcją e-booków i szybko wyszukiwać konkretne pozycje.

Natomiast nie wszystkim przypadnie do gustu program na komputerze, w dodatku o dość oszczędnej oprawie graficznej i służący głównie do elektronicznych książek. Nie od parady byłaby też aplikacja na urządzenia mobilne, aby można było sprawdzać swój stan posiadania będąc w księgarni. Dla takich osób są aplikacje w rodzaju Bookshelf, Bookcatalogue, natomiast wiele osób poleca również LibraryThing czy TinyCat.

Nie da się ukryć, że ten typ aplikacji to często jeden z pierwszych pomysłów na napisanie swojego rozwiązania. Programy katalogujące mają to do siebie, że są często potrzebne w różnych sytuacjach, każdy ma na nie inny pomysł, a jednocześnie nie są diabelnie trudne do zrobienia, gdyż w dużej mierze opierają się na CRUDach. Cała reszta to już kwestia wyobraźni i rosnących umiejętności, gdyż jest tutaj dużo miejsca na rozszerzenie koncepcji o funkcje, które potencjalnie mogą zachęcić innych użytkowników do korzystania.

Nie bez powodu aplikacje do zarządzania różnymi obiektami (nie tylko książkami) zaraz obok list TODO są genialną okazją do rozpoczęcia swojej przygody z programowaniem - wyzwanie nie jest trudne, a jednocześnie bardzo elastyczne i rozszerzalne. I co ważne - nieograniczone praktycznie do żadnego języka programowania.

Dedykowane serwisy społecznościowe

Jednak wiele osób chce połączyć katalogowanie swojego księgozbioru (papierowego oraz elektronicznego) z upublicznianiem go, recenzowaniem i dyskutowaniem z innymi maniakami literatury. Krótko mówiąc - szukają serwisu społecznościowego, który łączy w sobie wiele funkcji dostosowanych do książek. Pozwalają one:

  • przechowywać bazę książek i filtrować je po różnych kryteriach,
  • dodawać książki na półki (przeczytane, czytane, lista życzeń) i informować o tym innych użytkowników, których można obserwować lub dodawać do znajomych,
  • oceniać książki i dodawać recenzje, aby pomóc rekomendować je (lub odradzać) innym użytkownikom, a jednocześnie pokazać swoją pozycję eksperta,
  • dyskutować o książkach,
  • pozyskiwać rekomendacje nowych książek,
  • publikować artykuły oraz newsy.

Tak naprawdę każdy taki serwis może wyglądać inaczej i w zależności od filozofii, z jaką przychodzi na rynek, może być molochem skupiającym milion funkcji lub minimalistyczną aplikacją, która robi tylko to, co niezbędne.

Na świecie panuje Goodreads i w świecie książek trudno znaleźć kogoś, kto nie słyszał o tej aplikacji - gigantyczna międzynarodowa baza z ogromną społecznością. Natomiast Polacy równie dobrze znają LubimyCzytać, które oprócz bycia serwisem społecznościowym posiada redakcję i normalnie publikuje felietony, newsy oraz wywiady. Z kolei fani Fediverse mają do dyspozycji BookWyrma, który jest najbardziej minimalistyczny z nich wszystkich, ale niektórzy właśnie tego szukają.

Jednak literackie serwisy społecznościowe to nie tylko narzędzia dla czytelników. To także aplikacje stworzone z myślą o osobach chcących publikować swoje dzieła i poddać je ocenie społeczności. Tutaj również rynek ma światowego lidera w postaci Wattpada, który dał początek wielu książkom i seriom, choć trzeba uczciwie przyznać, że raczej w dziedzinie literatury młodzieżowej. Istnieją jeszcze inne portale typu Royal Road, FictionPress, a polscy fani fantastyki mogą próbować w czasopiśmie “Fantastyka". Istnieją też inicjatywy takie, jak Zapomniane Sny, które od czasu do czasu zapraszają do nadsyłania opowiadań, z których wybrane są publikowane w darmowym e-booku o charakterze charytatywnym. Możliwości są i Internet bardzo w tym pomógł.

Czy warto samemu brać się za taki serwis? Uczciwie trzeba powiedzieć, że jest to bardzo ryzykowne, choć to także ten typ aplikacji, który nadaje się do hobbystycznego rozwoju, szczególnie jeśli mamy świeżą i innowacyjną koncepcję. Na pewno technicznie daje dużą frajdę, ale jeśli podchodzimy do tego bardziej biznesowo, to warto przemyśleć to wiele razy. I prędzej celowalibyśmy skierowany ku początkującym pisarzom niż czytelnikom, w dodatku z porządną integracją z innymi portalami.

Wspomaganie pisania

Jak to kiedyś mówiono w “Latającym Cyrku Monty’ego Pythona" - a teraz coś z zupełnie innej beczki. Wspomnieliśmy już o narzędziach dla pisarzy, ale przecież na czymś autorzy muszą pisać. I choć nadal pewnie znajdziemy artystów oddających swoim wydawcom rękopisy lub kartki zapisane na maszynie do pisania (obie formy ku rozpaczy redaktorów), to znakomita większość wykorzystuje komputerowe edytory tekstu, które od dawna ułatwiają pisanie, korygowanie tekstu i poprawianie błędów. Jednak jest jeszcze inna klasa programów tego typu - w tym takie, które nie pozwalają się rozpraszać.

Na początku jednak powiedzmy, dlaczego w ogóle szukać jakiegokolwiek innego edytora, skoro są takie zaawansowane aplikacje jak Microsoft Word, LibreOffice, Pages czy nawet Google Docs. Owszem, są to świetne propozycje, znacząco ułatwiające pisanie pod kątem technicznym, zawierające szeroką paletę opcji formatujących i udostępniające podstawowe funkcje do redagowania. Jednak mają swoje wady, wśród których można wymienić:

  • zbyt dużą liczbę opcji - uwierzcie lub nie, ale to naprawdę może przeszkadzać,
  • spowolnienie przy wielkich plikach - oczywiście, te programy nie są specjalnie wolne, ale każdy, kto otwierał w nich kilkusetstronicowy dokument, wie, z jakim ciężarem mierzy się wówczas taki edytor oraz jak to utrudnia nawigację,
  • próbę bycia mądrzejszym od piszącego - sam piszę artykuły w Notepad++ lub TextMate (rzadziej w Google Docs), ponieważ nie próbują mnie poprawiać w przypadku, kiedy napiszę słowo choć trochę różniące się od tego, które ma w słowniku. Podejrzewam, że pisarze, którzy czasami wymyślają neologizmy lub specjalnie zamieniają małą i dużą literę, odczuwają coś podobnego.

Z tego powodu powstały edytory, które mają mniej funkcji (lub bardziej je ukrywają), ale za to pozwalają sprawniej edytować duże czysto tekstowe pliki, także często ułatwiając formatowanie różnych struktur (np. dla programistów) - do takich programów należą wspomniane Notepad++, TextMate, Zettlr (do Markdowna) i parę innych.

Istnieją też edytory, które wspomagają tworzenie dużych dokumentów i generalnie pracę pisarzom oraz scenarzystom. Robią to poprzez łatwiejszą nawigację po wielu rozdziałach, robienie notatek lub odwrotnie - poprzez ukrycie wszystkiego, co mogłoby rozpraszać piszącego. Do pierwszej grupy należą takie aplikacje, jak ​​Scrivener, Dabble, Vellum (będący jednocześnie narzędziem pomagającym składać e-booki), Atticus, Ulysses, Atlantis Word Processor, Storyist czy Final Draft. Z kolei wśród blokerów rozpraszaczy znajdziemy Byword, iA Writer, OmmWriter, Poe, Prime Draft, Dark Room, Focus Writer, Write Room, Freedom (z czego ten ostatni jest wtyczką, a nie edytorem). Jak widać, opcji jest bardzo dużo i nie trzeba koniecznie polegać na najpopularniejszych rozwiązaniach. Zresztą, w przypadku pisarza i jego procesu twórczego, ważny jest całokształt narzędzia, a więc nie tylko edytor, ale też odpowiednio ustawione powiadomienia, interfejs systemu i - przede wszystkim - wygodna klawiatura, np. mechaniczna.

Zresztą, nie tylko edytorami człowiek żyje. Wspomniałem o tym, że nie lubię, gdy program próbuje być mądrzejszy ode mnie, ale czasem jednak drobne podpowiedzi się przydają. I tutaj naprzeciw pisarzom wychodzą twórcy takich programów jak Hemingway App czy Grammarly, ale można znaleźć ich więcej. To jak najbardziej dobry rynek dla kreatywnych twórców aplikacji, ale też wtyczek do już istniejących i pozwalających się rozszerzać programów - wystarczy mieć dobry pomysł lub znać potrzeby autorów i stosunkowo niedużym kosztem można przygotować coś, za co wiele osób jest skłonnych zapłacić odpowiednią kwotę.

Oczywiście, pomińmy tutaj ChatGPT czy inne interfejsy do LLM, które są w stanie za nas napisać książkę lub jej znaczne fragmenty. Brak wartości artystycznej czy po prostu wątpliwa etyka w takim przypadku jest dość oczywista (chyba że autor wprost przyznaje się do tego - można znaleźć księgarnie internetowe, gdzie właściciele chwalą się działami z książkami napisanymi przez AI), ale przede wszystkim nie tego szukają czytelnicy. Natomiast ciekawym pomysłem może być wypuszczenie w bój sztucznej inteligencji do pozyskania inspiracji na jakiś dialog, wątek czy bohatera - niekoniecznie chodzi o pełne wykorzystanie wyniku działania AI, ale dostarczenie czegoś, z czego może wykiełkować już pełnoprawny pomysł.

Narzędzia redaktorskie

Wreszcie, w profesjonalnym pisaniu nowinki nie kończą się tylko na pisarzach. Zwłaszcza, że to, co się dzieje z książką dalej, jest dużo bardziej techniczne, żmudne i wszelkie wspomaganie jest tam na wagę złota. Co mają do dyspozycji redaktorzy, korektorzy, a także osoby zajmujące się składem tekstu?

Jeśli chodzi o uwagi do tekstu, to warto cofnąć się do poprzedniego rozdziału i sprawdzić edytory przeznaczone stricte do tworzenia długich dokumentów - większość z nich posiada narzędzia do umieszczania komentarzy, uwag i wspólnej dyskusji nad tekstem. Zresztą, takie funkcje zawierają też znane wszystkim Microsoft Word oraz Google Docs.

Ciekawszy jest już program Zecer firmy Elibri (to nie jest reklama), który zresztą czasem pojawia się na kartach informacyjnych różnych e-booków. Jest to aplikacja pozwalająca utworzyć plik EPUB, MOBI lub PDF, ułatwiająca przygotowanie elektronicznej książki tak, aby była podatna na funkcje czytników dla osób np. z zaburzeniami wzroku i generalnie - wspomagająca składanie takiego pliku, który może być potem publikowany w księgarniach z e-bookami. Włączone w to jest też m.in. umieszczenie znaku wodnego.

Takich aplikacji, także działających w chmurze, jest więcej i można znaleźć je choćby w tym zestawieniu. Są wśród nich wcześniej wspomniane Vellum, narzędzie od Amazona do publikacji na Kindle, ale też choćby Canva, która jest uznanym i prostym edytorem graficznym, jaki znają też choćby marketerzy. Nie zapominajmy bowiem, że książka (nieważne, czy elektroniczna, czy papierowa) to nie tylko tekst, ale też ozdobniki graficzne i przede wszystkim okładka, o której długimi tygodniami dyskutują fanki literatury w mediach społecznościowych.

Warto pamiętać też o tym, że książki, podobnie jak czasopismo, trzeba złożyć w całość, do czego służy oprogramowanie DTP. Tutaj prym wiodą takie pakiety, jak Adobe InDesign, Serif Affinity Publisher, Microsoft Publisher, Scribus, QuarkXPress czy Xara Page. Oczywiście, na upartego składać proste książki można nawet we wcześniej wspomnianej Canvie, GIMPie czy dowolnym programie graficznym, jednak są pewne standardy branżowe do przygotowywania szczególnie bogatych wizualnie materiałów.

A czego brakuje?

Niezależnie od tego, jak nasycony oprogramowaniem jest środowisko książek, zawsze można znaleźć coś, czego brakuje. Problem w tym, że czasem trudno jest zauważyć lukę w portfolio aplikacji - od tego, czy ktoś umie to zrobić i później zrealizować, często zależy sukces narzędzia i jego autora. Jednocześnie pamiętajmy, że sama koncepcja jest ważna, ale to nie wszystko - jak się czasem mówi, pomysły są tanie i ważne jest to, czy ktoś ma wystarczająco dużo umiejętności i determinacji, aby je zrealizować. Z drugiej strony, pamiętajmy o tym, że warto pracować nad rzeczami, które są potrzebne nam samym, gdyż zawsze jest szansa, że ktoś ma podobne potrzeby.

Wyżej wspomnieliśmy o tym, że jest pewien nieurodzaj w sprawie serwisów, gdzie pisarze mogą publikować swoje prace ku uciesze tłumu, katalogów książek (wprowadzając również np. możliwość wymiany czy sprzedaży) czy narzędzi wspomagających pisanie. Ale są też inne obszary do zagospodarowania.

Jedną z rzeczy, których trochę brakuje np. mnie, zapalonemu czytelnikowi różnych serii fantasy i kryminałów, jest dobry algorytm rekomendujący kolejne pozycje warte przeczytania. Oczywiście, istnieją takie na rynku i zapewniają to chociaż serwisy typu Goodreads czy LubimyCzytać. Można też śledzić wiadomości od ulubionych autorów, influencerów, którzy mają podobny gust czy rozpytywać się wśród znajomych. Jednak czasami brakuje drogi do odkrycia czegoś, na co nie natknęlibyśmy się żadną “tradycyjną" drogą, a miałoby szansę nam się spodobać. Dobrze robi to chociażby Spotify w sferze muzycznej.

I tutaj jest pole do popisu np. dla specjalistów od uczenia maszynowego, ale także generalnie analityków danych. Już dawno bowiem minęły czasy, kiedy wystarczyło kierować się ogólnymi gatunkami typu książka obyczajowa, sensacyjna, kryminalna lub fantastyka. Już nawet zbyt ogólne stały się nurty w poszczególnych gatunkach, typu fantasy czy science-fiction. Obecnie czytelnicy szukają często pozycji z konkretnych obszarów typu “urban fantasy z czarodziejkami" lub “powieść kryminalna ze śledztwem na wsi". Praktycznym przykładem mogą być też książki, które można określić jako “podobne do Harry’ego Pottera", czyli fantastyka z młodymi ludźmi dziejąca się w szkole, w której nauka i perypetie bohaterów w zamku lub akademii są głównym wątkiem. Krótko mówiąc - koneserzy chcą dużo dokładniejszych rekomendacji, co może oznaczać bardzo konkretnie kategoryzowanie pozycji, także uwzględniające spoilery (np. kryminały, w których wyjaśnienie ma charakter paranormalny, ale w tagach musi być to ukryte). Tak samo cechą do badania może być zbieżność stylu poszczególnych autorów, charakter bohaterów czy po prostu ogólnie pojęty klimat. Istnieją już próby stworzenia tego typu narzędzi (jak np. readow.ai), ale działa to średnio i podejrzewam, że nadal jest tutaj miejsce dla kreatywnych programistów.

A Wy gdzie widzicie braki na rynku oprogramowania dla branży literackiej i czytelników?

Podsumowanie

Technologia dotarła już wszędzie i to dawno temu. Nie umknęło to pozornie tradycyjnej formy rozrywki i wiedzy, jaką są książki i bardzo dobrze się stało, gdyż rozwój nie jest możliwy (a przynajmniej staje się bardzo utrudniony) bez siły, jaką niesie ze sobą IT. Oczywiście, nie wszyscy z tego korzystają i nie wszyscy muszą korzystać, ale trudno zaprzeczać, że bardzo ułatwiają one zarówno tworzenie, jak i konsumowanie książek.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Co jest potrzebne do dobrej wyceny? https://wildasoftware.pl/post/co-potrzebne-dobrej-wyceny?ref=rss https://wildasoftware.pl/post/co-potrzebne-dobrej-wyceny?ref=rss Thu, 17 Oct 2024 17:30:00 +0000 Wycena to bardzo gorący temat w relacjach klientów z wykonawcami w praktycznie każdej branży, w tym też software house’ach. Nic w tym dziwnego - tworzenie czegokolwiek na zlecenie zazwyczaj jest spełnieniem marzeń zleceniodawcy lub po prostu ziszczeniem się jego długo skrywanego oczekiwania, a czar pryska, gdy w to wszystko wmieszane zostają pieniądze. Niestety, jest to smutna rzeczywistość, gdyż wykonawcy również muszą z czegoś żyć i nie ma co nad tym się rozwodzić, zwłaszcza, że wysokość wycen uwzględnia bardzo wiele czynników, o czym już kiedyś pisaliśmy.

Zajmijmy się zatem czymś innym - co sprawia, że software house jest w stanie lepiej ocenić pracochłonność zleconego zadania, a tym samym trafniej wyestymować czas oraz budżet potrzebny na jego wykonanie? Możemy zadać to pytanie jeszcze trochę inaczej - co musi dostarczyć zleceniodawca, aby firma IT lepiej oceniła, z czym będzie się mierzyć i dostarczyła bardziej realistyczne oszacowanie?

Wbrew pozorom, temat nie jest oderwany od rzeczywistości i nie jest to biznesowe lub coachingowe gadanie, jakich pełno w Internecie. Gdy pisaliśmy o procedurze, która ma miejsce po napisaniu do nas, podaliśmy przykład zapytania potencjalnego klienta o wycenę całego serwisu, przy czym opis zawierał się w jednym zdaniu. Tego, oczywiście, nie można dobrze wycenić. Ale tego typu sytuacje dotyczą nie tylko zupełnie nowych spraw - zdarzają się także w długotrwałych współpracach. Opowiedzmy sobie o tym, jak to wygląda ze strony software house’u.

Jak wygląda idealna wycena?

Pofantazjujmy trochę. Idealny materiał do wyceny to taki, który:

  • zawiera wszystkie potrzebne informacje dot. oczekiwanej funkcji systemu lub potrzeby klienta, w tym np. atrybuty interesujących nas obiektów,
  • wyjaśnia oczekiwane zachowanie w sytuacjach wyjątkowych,
  • definiuje osoby lub role mające dostęp do nowego wymagania,
  • zawiera uzasadnienie biznesowe wymagania,
  • określa kwestie, na których klientowi zależy najbardziej, jak i wskazuje fragmenty, które są mniej priorytetowe.

Szczególnie ostatni punkt jest interesujący, gdyż zwłaszcza w bardziej złożonych wymaganiach wyceny zazwyczaj są tak duże, że dzieli się je na punkty wyceny, które następnie sumuje się lub określa warianty (o czym jeszcze dzisiaj sobie powiemy). Wówczas klient może wybrać najbardziej interesującą go opcję, jednak aby były one sensowne, zespół IT musi wiedzieć, na czym klientowi zależy najbardziej i jaka jest jego realna potrzeba biznesowa.

Kontynuujmy nasze marzenia - software house dostaje materiał do wyceny i jednocześnie klient zapewnia, że z chęcią dłużej poczeka na ofertę, jeśli będzie ona dobra. Wówczas członkowie zespołu IT:

  • szczegółowo analizują dostarczone informacje, rozkładając je na czynniki pierwsze,
  • przynajmniej wstępnie projektują architekturę oprogramowania pod rozważane zmiany,
  • dzielą całe wymaganie na poszczególne, szczegółowe składowe, wyceniając każdą z nich osobno,
  • uwzględniają czynniki pozatechniczne, kwestie wdrożeniowe i zarządcze,
  • w przypadku wątpliwości (choć przecież mówimy o procesie idealnej wyceny, gdzie przecież nie powinno być niedomówień) układają pytania i szybko dostają na nie odpowiedzi,
  • mają czas zaprezentować wizję (lub wizje, w liczbie mnogiej) na makietach,
  • określają warianty wyceny, czyli różne opcje, jeśli jest to zasadne,
  • wewnętrznie konsultują oszacowania w zespole, poznając różne punkty widzenia (wykorzystując do tego np. metodę Planning Poker),
  • starannie opisują wszystko, co wycenili, w tym zachowanie w szczególnych przypadkach,
  • oddają wycenę do konsultacji managerom projektu,
  • wspólnie pieczołowicie ustalają nie tylko końcowy kształt wyceny, ale też możliwy deadline, biorąc pod uwagę trwające zadania,
  • dostają szybką (i najlepiej pozytywną) odpowiedź klienta.

Brzmi jak cudowna sytuacja i… dosyć nierealistyczna. Mówiąc wprost, na wyceny zawsze jest mniej czasu niż się wydaje i trudno się temu dziwić. W końcu, gdy to my jesteśmy klientami i potrzebujemy oferty np. umeblowania kuchni czy samochodu, też nie oczekujemy, iż jej wystawienie potrwa np. dwa miesiące.

Jak to wygląda w rzeczywistości?

To nie jest jednak tak, że sytuacja opisana w poprzedniej sekcji nie zdarza się nigdy. Jeśli już się pojawia, to zwykle ma ona miejsce dla bardzo małych wycen (gdyż wtedy wszystko przebiega szybciej, jako że jest mniej kwestii do analizy) lub, paradoksalnie, dla bardzo dużych (kiedy po prostu trzeba wszystko drobiazgowo przeanalizować i klient też jest tego świadomy). Często też zdarza się, że mają miejsce wybrane pozycje takiego “perfekcyjnego procesu".

Tym niemniej, trzeba uczciwie przyznać, że wyceny zazwyczaj wiążą się ze ściskiem czasowym i to nie tylko z uwagi na oczekiwaną wartość końcową, ale też samym czasem dostarczenia oferty. Klient oczekuje, że software house szybko zareaguje, nawet jeśli realizuje właśnie dużo innych wymagań. To oznacza, że zespół zazwyczaj albo zatrzymuje zadania w toku w stabilnym stanie i pochyla się nad nowymi informacjami, albo przedłuża proces wyceny. Wszystko zależy od aktualnego statusu, stabilności projektu, liczności zespołu, trudności materiału do wyceny, a także oszacowania kosztu zmiany kontekstu (czyli przejścia z jednego zadania do drugiego).

Nie da się też ukryć, że nie zawsze klient dostarcza wszystkie potrzebne informacje. To oznacza, że zespół albo musi pewne rzeczy założyć (i wyraźnie zaznaczyć to w wycenie), albo - w bardziej złożonych przypadkach - zadać dodatkowe pytania, co może przerodzić się w spotkanie. Do tego jeszcze wrócimy. Dość jaskrawym przypadkiem tego typu są prośby o wyceny np. “standardowego modułu produkcyjnego". Przy czym, większość z nas się domyśla, że po prostu nie istnieje coś takiego jak “standardowy moduł produkcyjny" (każdy rozumie to pojęcie inaczej), a do tego sama funkcjonalność produkcji jest tak duża, że nie da się tego zamknąć w jednym zdaniu. To jednak skrajności.

Wreszcie, mimo różnych zabiegów, nie zawsze jest czas i sposobność przeanalizować wszystko w dokładny sposób i jeszcze skonsultować to z kilkoma osobami wewnątrz zespołu, ponieważ zleceniodawca czekałby zbyt długo. Wówczas zespół zwykle przyjmuje dodatkowy bufor, ale i tak bywa on niewystarczający, a na dodatek na etapie realizacji mogą pojawić się dodatkowe niejasności, które czasem przeradzają się wręcz w spory.

Co robi software house, gdy ma za mało informacji?

Jak wspomniałem w poprzednim akapicie, bywają sytuacje, w których osoba wyceniająca nowe wymaganie nie ma wystarczających informacji, a czuje, że może i musi je uzyskać. Czasem jednak nie jest to możliwe z przyczyn bardziej ekonomicznych, np. kiedy wymaganie jest bardzo niewielkie. Wówczas wyceniający najczęściej przyjmuje pewne założenia i wprost opisuje je w ofercie, informując tym samym klienta o fundamentach, na których stoi oszacowanie. W takich momentach klient może zareagować i rzucić nowe światło na sprawę.

Czasem jednak sprawa jest na tyle poważna, a wymaganie na tyle duże, że potrzebne jest dopytanie się o kilka kwestii. W tym momencie wychodzi też doświadczenie wyceniającego i umiejętność takiego zadania pytania, aby uzyskać odpowiedź, naświetlić nowe horyzonty zleceniodawcy, ale też pokazać swoją wiedzę oraz przenikliwość. To nie ma wpływu na samą wycenę, ale na pewno utrzymuje dobry wizerunek software house’u w oczach klienta, który widzi, że ma do czynienia z ekspertami. Warto przy tym wspomnieć, że pytanie lub wyjaśnienie nie musi mieć formy tekstowej - bywały u nas sytuacje, kiedy łatwiej było nagrać film i rzeczywiście popychał on sprawę do przodu.

Bywa jednak, że klient nie może (lub nie chce) odpowiedzieć mailowo lub kwestie są na tyle złożone i trudne do wyjaśnienia pisemnie, że trzeba zorganizować spotkanie. To jeden z tych momentów, w których w kontakt z klientem włączani są programiści, gdyż to oni, na równi z Product Ownerem, muszą mieć pełną wiedzę o funkcjonalności, którą prawdopodobnie będą implementować. Wynik takiego spotkania może być różnoraki, choć zazwyczaj kończy się wyjaśnieniem wszystkich wątpliwości lub przynajmniej prośbą o wycenę kilku opcji. Bywają też sytuacje, w których klient uświadamia sobie, że wymaganie faktycznie jest na tyle złożone, że najpierw sam musi je dobrze przemyśleć. A czasem zdarza się, że jedna wycena przeradza się w kilka wycen.

Dokładna wycena, warianty i pula godzin

Różne zadania wycenia się w różny sposób i jest to dość oczywiste. Natomiast dobrze wiemy, że w zarządzaniu projektami istnieją takie pojęcia jak Fixed Price czy Time and Materials. Krótkie przypomnienie:

  • Fixed Price polega na tym, że zleceniodawca płaci za wycenę, niezależnie od tego, ile rzeczywiście zajęła praca,
  • Time and Materials nie zakłada z góry liczby godzin spędzonych nad realizacją - zleceniodawca płaci tyle, ile praca rzeczywiście trwała.

Oba podejścia mają swoje zalety i wady. Natomiast z naszej perspektywy ważne jest to, że przy większych wycenach (np. zbioru zadań potencjalnie składających się na sprint) czasami miesza się te podejścia.

Najprostsza sytuacja jest przy zadaniach, których założenia są znane i zespół albo ma doświadczenie z implementacją wymagań danego typu, albo jest w stanie z niezłą precyzją ocenić pracochłonność. Wówczas mamy klasyczny przykład Fixed Price - robimy “zakład", iż realizacja danej części funkcjonalnej zajmie X godzin (lub w innej jednostce) i niezależnie od tego, jak bardzo się pomylimy, klient za tyle płaci. Ważne jest określenie założeń, które obowiązują podczas wykonywania zlecenia.

Ciekawiej robi się przy bardzo dużych zadaniach lub takich, gdzie istnieje dużo “dodatków", które klient może chcieć lub też nie. Są to tzw. wyceny wariantowe, gdzie istnieje pewna baza, natomiast można do tego dobrać kolejne opcjonalne funkcje - trochę jak wybór bonusów przy zamawianiu dania w restauracji. Wszystkie wyceny nadal są traktowane jako Fixed Price, jednak końcowa wartość jest sumą opcji wybranych przez klienta. Ma to zastosowanie w momencie, kiedy niektóre “odnogi" zadania są dużo bardziej skomplikowane i software house nie jest pewny, czy zleceniodawca rzeczywiście będzie je chciał po podanej cenie lub kiedy po prostu istnieje wiele dróg, którymi można podążyć. Ta wariantowość powstaje też często, kiedy zespół IT ma wątpliwości, ale kontakt z klientem w celu ich wyjaśnienia zajmie zbyt dużo czasu w stosunku do wyceny poszczególnych dróg rozwoju. Jest to też dobra technika, gdy wymaganie można zrealizować etapowo, niekoniecznie w jednym sprincie.

Natomiast są zadania “specjalne", które mają charakter bardziej analityczny, badawczy lub zespół nie wie, czego się spodziewać podczas realizacji. Nie jest to wstydliwe - istnieją takie funkcje, które wiążą się np. z integracją z zewnętrznymi systemami, gdzie nie zawsze łatwo jest określić trudności, które będą piętrzyć się po drodze. Czasem też zespół wie, że warunki mogą się zmienić podczas trwania sprintu lub nie wszystkie materiały są dostępne na początku, a zleceniodawcy bardzo zależy na rozpoczęciu zlecenia. Wówczas zakłada się tzw. pulę godzin, która jest bliższa Time and Materials. W takim zadaniu zespół ma górne ograniczenie godzin, które może wykorzystać i zatrzymuje pracę (oczywiście, w stabilnym stanie), gdy limit zostanie osiągnięty. Jednak, gdy zdoła zrealizować zadanie w krótszym czasie, to właśnie ta rzeczywista wartość stanowi podstawę do rozliczenia. Jest to zatem rozwiązanie, które pozwala założyć pewien budżet na rozpoczęcie (ważne z punktu widzenia klienta), ale niekoniecznie skończenie prac, co może również pomóc w określeniu, ile tak naprawdę czasu wymaga dana rzecz. Im bardziej jesteśmy niepewni, tym pula jest mniejsza, aby później, mając już dodatkową wiedzę, lepiej móc określić liczbę godzin potrzebną na dokończenie.

Co może zrobić zleceniodawca?

Od razu może powiedzmy, że zleceniodawca nic nie musi zrobić - w końcu jest zleceniodawcą. Natomiast każdej stronie zawsze zależy na tym, aby współpraca przebiegała możliwie gładko,a istnieją pewne kwestie, w których klient może pomóc zespołowi IT, ale też przede wszystkim sobie.

Przede wszystkim im więcej materiałów dostarczy, tym lepiej. Oczywiście, nie chodzi o to, aby “zawalić" software house kilkusetstronicowymi opracowaniami i formalnymi dokumentami, które wyłącznie luźno wiążą się z wycenianym zadaniem. Jeśli do prawidłowej wyceny potrzebna jest wiedza dziedzinowa, lepiej umówić się na spotkanie i wyjaśnić niedostatki wiedzy software house’u w danej dziedzinie. Tym niemniej, warto napisać wszystko, co chce się osiągnąć, w tym oczekiwane zachowanie w szczególnych przypadkach, punkt początkowy, punkt końcowy itd.

To, co jest często pomijane przez klientów, to wyjaśnienie rzeczywistego celu swoich działań. Bywało w naszej historii już tak, że klient prosił o wycenę wymagania, które wydawało się… No cóż - bezsensowne w znanym wówczas kontekście. Czasem utrudniało to podanie oszacowania, więc zespół miał dużo pytań do zleceniodawcy. Skutkowało to często tym, że po odkryciu rzeczywistych intencji klienta można było zaproponować dużo lepsze, a czasem i szybsze rozwiązanie napotkanego problemu. Software house’y są świadome, że klienci nie są specjalistami w zakresie IT (w końcu dlatego są potrzebne), więc nie muszą znać wszystkich opcji dostępnych na stole - to ten aspekt konsultingowy działalności takiego wykonawcy oprogramowania.

Jeśli klient posiada wizualizację pożądanej funkcji (wbrew pozorom, czasem się to zdarza, gdyż zleceniodawcy lubią wizualizować swoje pomysły), to nawet, jeśli jest ona bardzo podstawowej jakości, warto ją załączyć. Nie bez powodu mówi się, że obraz mówi tyle co tysiąc słów i nawet, jeśli makieta dostarcza więcej pytań niż odpowiedzi, to te pytania i tak zespół kiedyś by zadał, a lepiej zrobić to szybciej niż później. Jednocześnie warto mieć na uwadze to, że czasem software house odeśle swoją wizję i z nią też warto się zapoznać, a nie odrzucać z góry. Obu stronom zależy na dojściu do satysfakcjonującego rozwiązania.

I na koniec rada dość prosta, ale o której czasem się zapomina - warto dbać o język, którym posługują się obie strony w komunikacji, w tym także klient. I nie chodzi tutaj o savoir-vivre, tylko o staranne pisanie i świadomość, że nie wszystkie skróty i branżowe określenia mogą być tak samo rozumiane po drugiej stronie kabla. Znacznie lepiej wycenia się i w ogóle pracuje, gdy obie strony pokazują, że chcą się dogadać i unikają nieporozumień, czasem wynikających po prostu z niestarannego doboru słów lub ciągłego pośpiechu i pomijania przekazywania istotnych informacji.

Podsumowanie

Wycenianie to nie tylko gorący temat - to bardzo trudny proces, nie tylko z technicznego punktu widzenia, ale także biznesowego i komunikacyjnego. Na dobrej jakości oszacowań zależy wszystkim, gdyż każda strona chce dostać to, czego pragnie, a także utrzymać dobrą relację. Warto się zatem starać i wiedzieć, jak to wygląda z drugiej perspektywy.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Czym jest maska w IT? https://wildasoftware.pl/post/czym-jest-maska-it?ref=rss https://wildasoftware.pl/post/czym-jest-maska-it?ref=rss Thu, 12 Sep 2024 17:30:00 +0000 Muszę przyznać, że jako osoba mająca poważniejszy kontakt z IT od kilkunastu lat (a jakikolwiek od ponad dwudziestu), słowa "maska" użyłem mniejszą liczbę razy niż nasi klienci na przestrzeni ostatnich miesięcy. To jest o tyle dziwne, że ten termin jak najbardziej jest używany w systemach, programowaniu oraz ogólnie informatyce i ma dość specyficzne znaczenie, natomiast słyszałem je już w takich kontekstach, o których mi się nawet nie śniło. I nie jest to złośliwość - fascynuje mnie to, że w różnych branżach można znaleźć słowa, które służą do opisywania różnych pozornie podobnych, ale jednak różnych zjawisk i na przecięciu poszczególnych obszarów powstaje wieloznaczność, której "odkowanie" sprawia pewną satysfakcję, gdyż niesie ze sobą także informację o tym, jakie są doświadczenia uczestników dyskusji. Uff, dawno nie napisałem dłuższego zdania.

Natomiast nie da się ukryć, że słysząc tu i ówdzie o masce, nie zawsze od początku wiedziałem, o co chodzi rozmówcy. Jednak tak, jak pisałem wyżej - wraz z poznawianiem kontekstu i środowiska, w którym operuje interlokutor, dowiadywałem się więcej nie tylko o tym, co oznacza to słowo w danym przypadku, ale też w czym pracowali do tej pory użytkownicy. A to często bardzo ważna informacja na etapie ustalania wymagań pozafunkcjonalnych oraz generalnie wizji funkcji w oprogramowaniu.

Postanowiłem zebrać znaczenia maski i je krótko opisać. Niektóre są bardziej "sformalizowane" i jak najbardziej mówi się o nich w informatyce, a z innymi spotkałem się w konkretnych przypadkach i możemy wspólnie zastanowić się, skąd właściwie się wzięły.

Maska jako definicja podsieci

To, z czym większość informatyków kojarzy słowo "maska" w IT, to właśnie sieci komputerowe, a dokładniej - ciąg liczb (lub liczba) określający podział adresu sieci na adres podsieci i adres hosta. I zanim zaczniecie zastanawiać się, co właściwie tutaj przeczytaliście, to polecam zrobić dwie rzeczy - po pierwsze, odświeżyć sobie informacje o adresach IP oraz włączyć konsolę (wiersz polecenia w Windowsie lub terminal w Linuksie) i wpisać ipconfig, ip a lub ifconfig. Powinniście zobaczyć coś podobnego do jednego z tych zapisów:

IPv4 Address. . . . . . . . . . . : 192.168.0.16
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
--
inet 192.168.0.16 netmask 255.255.255.0 broadcast 192.168.0.255
--
inet 192.168.0.16/24 brd 192.168.0.255

Jeśli porównacie to teraz z artykułem o adresach IP i znajdującą się tam sekcją podziału sieci na podsieci, to właśnie znaleźliście miejsce, gdzie możecie przeczytać:

  • jaki jest Wasz adres IP w sieci lokalnej,
  • jaka jest maska (zapisana normalnie, np. 255.255.255.0 lub w notacji CIDR, np. /24),
  • jaki jest adres broadcastu.

Mówiąc bardziej obrazowo: maska wyznacza granicę, gdzie kończy się bazowy adres dla całej sieci (np. lokalu), a gdzie zaczyna część, która jest unikalna dla każdej maszyny w sieci. Można to skojarzyć z numerem bloku (adres sieci) i mieszkaniami (adresy poszczególnych hostów, zwanych też klientami). Im większa maska, tym mniej adresów dla klientów jest do rozdysponowania. Im mniejsza - adres jest bardziej ogólny, a klientów może połączyć się dużo więcej - jest to związane z tzw. klasami sieci. Zapis CIDRowy, wykorzystujący slasha, pokazuje nam liczbę "jedynek" w zapisie normalnym - z formy binarnej wiemy bowiem, że tak naprawdę 255.255.255.0 to 3 grupy po 8 jedynek i 4 zera na końcu. Ile zatem mamy łącznie "jedynek"? Otóż, właśnie - 3 * 8 = 24. Oczywiście, maska zapisana w ten sposób nie musi być wielokrotnością ósemki, choć trzeba przyznać, że często tak się właśnie dzieje.

Jak pewnie się spodziewacie, rozmowy o takich maskach zazwyczaj odbywają się w gronie administratorów lub podczas konfigurowania dużej sieci w firmie, o ile klient jest (lub chce być) świadomy szczegółów infrastruktury. W przypadków rozmów o aplikacji - myślę, że wspomnienie o tym znaczeniu tego słowa byłoby dużym zaskoczeniem.

Maska jako określenie włączonych bitów

Gdy popatrzymy bardziej "filozoficznie" na powyższą sekcję o podsieciach, dostrzeżemy znaczenie słowa "maska" - tak, jak normalnie zakrywa ona twarz, ukazując to, co chcemy, tak w sieciach chowa ona jedną część, aby uwypuklić drugą. Tak naprawdę jest to nakładanie na siebie adresów złożonych z tylu samych cyfr binarnych i porównywanie, gdzie jedynki przykrywają zera lub gdzie cyfry w obu adresach są takie same. Te dość proste operacje wykorzystuje się nie tylko w podsieciach, ale czasem też np. w sprawdzaniu uprawnień.

Wyobraźmy sobie, że mamy ciąg bitów, które odpowiadają poszczególnym możliwościom użytkownika w systemie:

  • pierwszy bit (licząc od lewej) - możliwość wyświetlenia listy produktów.
  • drugi bit - możliwość utworzenia produktu.
  • trzeci bit - możliwość edycji produku.
  • czwarty bit - możliwość usunięcia produktu.

Załóżmy, że dla zalogowanego użytkownika pobierana jest maska bitowa, której wartość to 1100(2). Z kolei do wyświetlenia listy produktów potrzebne jest porównanie z ciągiem 1000(2), a dokładniej - wykonanie iloczynu bitowego. W tym przypadku bedzie on wynosił 1000(2), co oznacza, że użytkownik ma możliwość wyświetlenia listy. Ale gdybyśmy sprawdzali możliwość usunięcia (0001(2)), wynik byłby już negatywny, gdyż nie ma wspólnych jedynek na określonych pozycjach.

Oczywiście, ten przykład jest dość naiwny i sztuczny, jednak fakt, że ten sposób sprawdzania uprawnień, ról czy innych rzeczy nadal jest obecny w aplikacjach i wykorzystuje szybkość, z jaką przeprowadzane są operacje na bitach. Wadą jest to, że w przypadku bardzo dużej liczby elementów do weryfikacji, ten ciąg może być niezwykle długi, co rodzi problemy z zapisem i przetrwarzaniem. Ale i tak warto o tym wiedzieć, szczególnie przy analizie programów tworzonych przez inne firmy.

Maska jako format wprowadzanych danych

Idziemy dalej ze skojarzeniem maski z czymś, co zasłania część danych, pokazując to, co rzeczywiście chcemy, aby było pokazane. Programiści frontendów aplikacji webowych w niektórych kontrolkach wykorzystują maskowanie danych, aby nakłonić lub wręcz zmusić użytkownika do podania wartości w określony sposób. Klasycznym przykładem jest kontrolka numeru telefonu, który ma w miarę określony kształt - najpierw kod kierunkowy, a potem cyfry zgrupowane po trzy lub dwie. Innym przykładem jest kontrolka do podania daty w formacie dzień.miesiąc.rok. Dzięki temu programiści mogą też ułatwić sobie walidację podanej wartości, wiedząc, czego mniej więcej mogą spodziewać się od wprowadzającego (aczkolwiek trzeba przyznać, że użytkownicy potrafią być... bardzo kreatywni).

Jest też inny sposób maskowania w kontrolkach webowych, a mianowicie ukrywanie wpisanych znaków poprzez ich zamianę na inny, stały znak. I tutaj każdy z nas doskonale zna przykład takiego zachowania - jest to miejsce, w którym wpisujemy hasło, a które od razu jest zamienianie na gwiazdki, kropki lub inne symbole, aby nie można było go podejrzeć. Zresztą nie tylko podejrzeć - także skopiowanie tak wpisanego tekstu nie pozwoli wkleić go w inne miejsce.

Ale nie tylko w aplikacjach webowych mamy do czynienia z taką sytuacją - także w innych zastosowaniach możemy mówić o formatowaniu wpisywanych danych lub zakodowaniu miejsca, w którym może pojawić się ciąg znaków według danej reguły. Klasycznym przykładem są wyrażenia regularne, szczególnie w ścieżkach do plików. Nota bene, wyrażenia regularne to materiał na osobny artykuł, gdyż ich wykorzystanie w informatyce jest nieocenione.

Maska jako element warstwy w grafice

W tym momencie mogą się odezwać graficy, którzy też znają maskowanie i w którym znowu chodzi o oznaczenie danego obszaru, ale tym razem po to, aby nadać temu odpowiedni kolor lub efekt. Co ciekawe, maski służą do słynnych operacji wymazywania osób lub obiektów ze zdjęć albo podmiany elementów otoczenia. Można je edytować i wykonywać na nich różne dzialania, w zależności od tego, co umożliwia program graficzny oraz wyobraźnia samego grafika.

Maska jako ekran szczegółów

Bardzo ciekawym przypadkiem było użycie terminu "maska klienta", które usłyszałem podczas jednej z rozmów na temat projektu IT. Przyznaję, że przez pewien czas nie wiedziałem, o co chodzi - znając cały (dużo większy niż opisuję tutaj) kontekst rozmowy, początkowo podejrzewałem, że jest maska bitowa dołączona do obiektu klienta, jednak trudno było mi sobie wyobrazić, aby była ona widoczna w interfejsie użytkownika, a właśnie wokół tego krążyła rozmowa. Wreszcie, okazało się, że "maska" w tym przypadku to nic innego jak... ekran szczegółów.

W ogóle tego typu widoki zyskują nazwy bardzo zależne od tego, w jakim środowisku porusza się zleceniodawca projektu i z jakimi programami miał do tej pory do czynienia. Niektórzy faktycznie mówią na to "ekran szczegółów". Inni użyją słowa "detale". Jeszcze inni (szczególnie w branży medycznej) - "karta" lub "kartoteka". Są też tacy, którzy powiedzą po prostu "widok" i jeśli nie dodadzą niczego innego, to można założyć, że chodzi właśnie o ekran danych pojedynczego obiektu. Zresztą, w języku angielskim również jest pewna dowolność, gdyż w użyciu jest zarówno słowo "details", jak i "view".

Natomiast "maska" jest interesującym sformułowaniem w tym obszarze, gdyż sugeruje, że dane np. klienta (lub jakiegokolwiek innego obiektu) przysłaniają pewne informacje lub nakładają się na siebie, np. pod wpływem uprawnień. Tym niemniej, jest to bardzo dziwne słowo i prawdopodobnie wynika ze specyficznej terminologii programu, z którego korzystał zleceniodawca.

Pod maską

Wreszcie sformułowanie, którego używamy bardzo często my, programiści. Wyobraźcie sobie, że musicie wytłumaczyć osobie nietechnicznej, że wycena nowej funkcji jest bardzo duża, natomiast interfejs użytkownika będzie zaskakująco skromny. W związku z tym klient może słusznie zapytać, gdzie podziało się tak dużo godzin, skoro tak naprawdę nie widzi tych efektów, a przynajmniej tak mu się wydaje. Odpowiedzią może być np. skomplikowana logika po stronie backendu, tylko że takie sformułowanie może być dość nieszczęśliwe w przypadku, kiedy rozmawiamy z osobą bez wiedzy technicznej i która w dodatku negocjuje cenę.

W tym przypadku warto odnieść się do analogii motoryzacyjnej - problem z samochodem może być widoczny na zewnątrz, ale może też dotyczyć silnika, gdzie zwyczajowo powiemy "pod maską". Jest to zatem określenie czegoś, co dzieje się poza granicą wzroku zwykłego odbiorcy, a tak dokładnie jest z backendem - użytkownik zazwyczaj nie ma dostępu do tej części systemu i nie może podejrzeć tego, co tam sie znajduje, a zatem może nie do końca umieć sobie to wyobrazić, co z kolei rodzi frustrację. Dlatego określenie "pod maską" jest na tyle uniwersalne, że warto go używać. Oczywiście, jeśli jest to zasadne.

Podsumowanie

Mam nadzieję, że udało się zaskoczyć Was choć jednym znaczeniem tego słowa w IT, a i pewnie niektórzy znajdą jeszcze inny kontekst użycia tego sformułowania. To przykład na to, jak rozbudowaną dziedziną stało się IT i jak nowa terminologia rodzi się w wielu punktach w niezależny sposób.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Feedybacky w maju 2024 roku https://wildasoftware.pl/post/feedybacky-maju-2024-roku?ref=rss https://wildasoftware.pl/post/feedybacky-maju-2024-roku?ref=rss Wed, 29 May 2024 17:30:00 +0000 Czytelnicy zaglądający na ten blog od dłuższego czasu pamiętają pewnie, że dość często pisaliśmy o naszym autorskim systemie, Feedybacky, służącym do zarządzania zgłoszeniami serwisowymi i gwarancyjnymi, głównie w projektach programistycznych. Prawda jest taka, że od pewnego czasu rzeczywiście nie dawaliśmy znać, co się dzieje w tym obszarze - wpływ na to miały inne tematy komercyjne, a także fakt, że nie wszystkie zmiany są warte publicznego omawiania, gdyż mają bardziej znaczenie dla wewnętrznych struktur oprogramowania aniżeli funkcji dostępnych dla użytkowników. Nie zmienia to faktu, że czuliśmy się z tym trochę źle, zwłaszcza, że FyBy jak najbardziej jest wykorzystywany w praktyce i sprawdza się w przedsięwzięciach, w których został wdrożony.

Z tym większą przyjemnością wracamy dzisiaj do tematu i ponieważ w ostatnich miesiącach w projekcie działo się dość sporo, możemy to dzisiaj omówić i jednocześnie przedstawić aktualny status prac. Będziemy odnosić się przede wszystkim do samej aplikacji, dostępnej pod adresem Feedybacky.com i faktu, że system stał się potrzebny nie tylko przy obsłudze zgłoszeń, ale też całych projektów IT.

Skąd te zmiany?

Bardziej dociekliwi mogą zapytać "skąd pomysł na takie zmiany?", marudy zapytają "po co?", a malkontenci "dlaczego dopiero teraz?". Jeśli czytaliście o naszym stosie technologicznym, to być może pamiętacie, że do zarządzania samymi zadaniami stosujemy Redmine'a, a więc otwarte i samodzielnie instalowane oprogramowanie, które, co prawda, w ostatnich latach straciło nieco na znaczeniu, ale nadal jest rozwijane i personalnie pasuje nam bardziej niż np. Jira. Etapy i wymagania większości projektów rozpisane są właśnie tam, jednak w tych przedsięwzięciach, które są już po pierwszych wydaniach i użytkownicy w nich działają oraz zgłaszają uwagi, następuje pewien dualizm - zadania pojawiają się zarówno w Redminie, jak i Feedybacky. Co więcej, istnieje dodatkowa potrzeba przechowywania materiałów (w tym wycen) oraz zarządzania nimi. To czasem powoduje konieczność zaangażowania innych narzędzi, nawet tak podstawowych jak współdzielone arkusza kalkulacyjne. A żeby tego było mało, poszczególni klienci mają również swoje przyzwyczajenia i wymogi dotyczące przekazywania zakresu prac w danych momentach. To oznacza, że bywały projekty wykorzystujące nawet po pięć systemów to pozornie podobnych czynności.

Mówiąc wprost, zaczęło nas to męczyć i przeszkadzać w pracy.

Zorganizowaliśmy serię wewnętrznych spotkań oraz warsztatów, podczas których członkowie zespołu (a zdecydowana większość korzysta z Feedybacky'ego) mogli wyrazić swoje zdanie i dostać pole do dyskusji na temat dalszych prac. Wiadomo bowiem było, że FyBy musi się rozwijać, jak zresztą prawie każde oprogramowanie. Pytanie jednak dotyczyło tego, które funkcje są najbardziej priorytetowe, biorąc pod uwagę aktualne potrzeby. A kto jest ich lepszym źródłem niż osoby, które korzystają z systemu najwięcej, czyli programiści oraz członkowie linii wsparcia? Oczywiście, także klienci, a więc użytkownicy aktywnie korzystający z Feedybacky'ego, którzy również zostali włączeni do dyskusji i dostarczyli bardzo ciekawych informacji.

Na tej bazie została przygotowana lista modyfikacji oraz nowych funkcji, a także wyznaczone priorytety, które mają przybliżyć nas do jednego - ograniczenia innych systemów na rzecz jednego, którym będzie FyBy. Nie oznacza to, że ten system może zastąpić wszystko, gdyż dobrze wiemy o tym, iż nie zawsze jest sens, a jedna aplikacja do wszystkiego jest do niczego. Tym niemniej, nawet nie będąc uczestnikiem wewnętrznych dysput, stosunkowo łatwo można zaproponować zmiany, które uczynią z Feedybacky'ego nie tylko system dla help desku, ale także do codziennej pracy. Niektóre zmiany są małe i stosunkowo szybkie do wprowadzenia, a inne wymagają miesięcy wytężonej pracy. Zaplanowaliśmy te modyfikacje i właśnie pierwszymi efektami chcielibyśmy się z Wami podzielić oraz wysłuchać Waszych uwag, a także... odkryć trochę kuchni. Nie każda zmiana jest ważna z punktu widzenia funkcjonalności - niektóre mają bardziej zademonstrować sposób myślenia i w ten sposób uczyć. A my lubimy uczyć.

Trzeci sposób dodawania zgłoszeń na FyBy

Zaczynamy od czegoś prostego i oczywistego, a co już jest w systemie od dłuższego czasu, aczkolwiek nie było wcześniej okazji o tym napisać. Do pewnego momentu Feedybacky oferował dwie drogi dodawania zgłoszeń: przez wtyczkę zamieszczoną w aplikacji klienta oraz wstrzykiwalny zewnętrzny formularz Feedybacky Embedded Form. W przypadku zagadnień helpdeskowych są to wystarczające metody, jednak czas pokazał, że trudno się obyć bez ścieżki, która wydaje się naturalna, a jednak jej brakowało - zwykły formularz w samym Feedybacky.

Lokalizacja opcji umożliwiającej przejście do formularza dodania zgłoszenia - pozycja 'Issue' lub 'Zgłoszenie' w lewym górnym rogu.

Jeśli system jest wykorzystywany jako centralne miejsce do zadań, to siłą rzeczy musi umożliwiać łatwe dodawanie tych zadań. Należy wziąć przy tym pod uwagę fakt, że czasem chcemy to zrobić bezpośrednio z poziomu jakiegoś projektu, a czasem jeszcze nie wiedząc, do czego chcemy dane zagadnienie przypisać. Sam formularz jest dosyć podobny do wcześniej wspomnianego FEFa (którego zresztą też czekają zmiany, choć bardziej techniczne) i umożliwia także natychmiastowe dodanie wyceny czy przypisanie kategorii (do których jeszcze dzisiaj dojdziemy).

Widok przycisku dodania zgłoszenia nad listę zgłoszeń danego projektu.
Fragment formularza dodania zgłoszenia, gdzie widać treść do wpisania, wybór projektu, kategorii, wyceny, zrzut ekranu oraz role mogące widzieć zgłoszenie.

Grupowa aktualizacja zmian

Zanim wynik danego sprintu czy po prostu zlecona praca zostaną oddane klientowi, musi przejść przez proces weryfikacyjny. Siłą rzeczy, nie musi, ale jest on wskazany, gdyż może ujawnić pewne niedoróbki, które powinny zostać poprawione zanim oprogramowanie znajdzie się w rękach prawdziwych użytkowników. Czasem tych zgłoszonych pozycji jest na tyle dużo, że nie traktuje się ich pojedynczo, tylko poprawia masowo i równie masowo się je aktualizuje.

I tutaj wyszła potęga dyskusji, gdyż część zespołu w ten sposób nie pracowała, w związku z czym nie doświadczała tego, z czym miała do czynienia druga grupa. A ona ekstremalnie irytowała się faktem, iż chcąc oznaczyć 10-20 zagadnień jako "gotowe do wdrożenia" i nie chcąc dodawać żadnego konkretnego komentarza, musiała klikać każde osobno. W związku z tym pojawił się później zrealizowany pomysł grupowej aktualizacji statusow.

Widok listy zgłoszeń, gdzie po lewej stronie trzy pozycje mają zaznaczone checkboxy, a powyżej po prawej stronie widać rozwiniętą opcję 'Aktualizuj statusy' z listą statusów.

Osoby korzystające z Feedybacky pewnie zauważyły checkboxy po lewej stronie na liście zgłoszeń - ich zaznaczenie oraz wybranie docelowego statusu natychmiast wprowadza zmianę dla wszystkich. Jak najbardziej współgra to z raportami oraz innymi mechanizmami pozwalającymi porządkować i monitorować zgłoszenia, a przy wdrożeniach, gdzie wiemy, co właśnie wprowadziliśmy na serwer, ta droga jest znacznie szybsza.

Zmiany na liście

Będąc już na samej liście zgłoszeń, przeszła ona transformację. Na razie małą, ale możemy zdradzić Wam, że w dalekiej perspektywie mamy w planach dużo większe modyfikacje.

Przede wszystkim wysłuchanie głosu użytkowników przyniosło jeden ciekawy wniosek - nikt (albo prawie nikt) nie korzysta z wykresu, który jest położony po prawej stronie. Mówiąc wprost, jest on dość nieużyteczny w obecnej formie i o ile bywają sytuacje, w których chcielibyśmy graficznie zobaczyć rozkład grup statusów, to nie jest to regularna aktywność. Diagram mógł wręcz mylić użytkownika, gdyż pierwotnie pod uwagę brał całą historię projektu. Jednocześnie, potrzebne były dodatkowe informacje w samej tabeli. W związku z tym:

  • domyślnie wykres został ukryty, choć można go odkryć,
  • przy zakrytym wykresie, na liście pojawia się kolumna z przypisanymi osobami (do czego jeszcze dzisiaj przejdziemy),
  • wielkość fontu w nagłówkach została nieco zmniejszona, podobnie jak odstępy.

Ale to nie wszystko - z racji tego, że pojawiły się kategorie, a także nowe filtry (np. po komentarzach, właśnie kategoriach, przypisanych osobach), to kontrolki zostały przearanżowane według tego, co jest wykorzystywane najczęściej. Dodatkowo, zostały poprawione ikonki w filtrach i na liście. A żeby tego było mało, to mechanizm zapamiętywania filtrów działa dla każdego projektu z osobna. To powinno ułatwić poruszanie się po różnych przedsięwzięciach.

Widok listy zgłoszeń z wprowadzonymi zmianami.

Kategorie

Jedną z częściej podnoszonych kwestii w Feedybacky jest brak hierarchii zgłoszeń, co ponownie wynika z helpdeskowego rodowodu, zgodnie z którym wpisy są wprowadzane spontanicznie i każde jest traktowane pojedynczo. To z kolei może być ograniczające w przypadku, kiedy przechowujemy informacje o zadaniach w jakimś kontekście, np. pojedynczego sprintu - w takim wypadku większość osób wyobraża sobie hierarchiczne zarządzanie zgłoszeniami. Jednak należy pamiętać, że taka funkcja jest dużo większym fragmentem do realizacji niż wielu podejrzewa, zwłaszcza jeśli weźmiemy pod uwagę interfejs, wyświetlanie czy uprawnienia. Nie oznacza to, iż FyBy takiej funkcji nie uzyska, gdyż z dużym prawdopodobieństwem w przyszłości znajdzie się ona w naszym systemie. Jednak Feedybacky zawierał już fundamenty do innego rozwiązania, które pozwala na łatwiejsze porządkowanie zadań, a dodatkowo jest znany osobom korzystającym częściej z Githuba. Mowa o tagach, zwanych też kategoriami czy etykietami.

Widok sekcji kategorii w konfiguracji projektu, gdzie można wprowadzać dowolną liczbę tagów.

Do zgłoszeń można przypisać dowolną liczbę kategorii, których struktura jest płaska - żadna nie jest ważniejsza i zależna od innej. Ich zastosowanie ma miejsce głównie podczas filtrowania na liście, gdzie można wybrać tagi, które muszą być zawarte przez wyświetlane zagadnienia. W ten sposób można zorganizować zgłoszenia w sprinty, etapy, ale także oznaczyć zadania obowiązkowe, opcjonalne, gwarancyjne, a także związane z poszczególnymi obszarami wewnątrz danych projektów. Tym samym osoby zajmujące się np. konkretnym wycinkiem aplikacji mogą łatwo przefiltrować zgłoszenia, którymi rzeczywiście będą zainteresowani. Co więcej, po znalezieniu jednego "reprezentanta" danej grupy istnieje możliwość szybkiego wyświetlenia (lub dodania) listy z pozycjami o podobnych właściwościach.

Fragment ekranu szczegółów zgłoszenia, gdzie widać tagi powiązane ze zgłoszeniem i obok opcje dodania podobnego zgłoszenia oraz przejścia do listy z już zaznaczonymi tagami.

Kategorie są bardzo elastycznym mechanizmem, który można wykorzystać zależnie od naszych potrzeb i wyobraźni. Warto pamiętać, iż strona klienta również widzi tagi przypisane do zgłoszeń.

Lista zgłoszeń z odfiltrowanymi zgłoszeniami zawierającymi kategorię 'Mobile' oraz dostępnym filtrem 'bez kategorii', który pozwala wykluczyć zgłoszenia z danym tagiem.

Przypisane osoby

To akurat nie jest nowa funkcja, gdyż przypisywanie wykonawców do zgłoszeń zostało wprowadzone już dawno temu, jednak od tego czasu nastąpiło wiele zmian.

Po pierwsze, wykonawcy przy zgłoszeniach są widoczni dla wszystkich. Początkowe założenia były inne, jednak w miarę upływu czasu dostrzegliśmy, iż przy dużych projektach skrócenie komunikacji (a Feedybacky w dużej mierze do tego służy) wpływa dobrze na postęp prac, a znajomość osób po drugiej stronie - pozytywnie na atmosferę. Jednocześnie nadal istnieje możliwość ustawienia aliasów, w związku z czym osoba zaangażowana w zagadnienie jest widoczna pod nic niemówiącym mianem.

Widok aktualizacji zgłoszenia, gdzie w polu 'Przypisani' można zobaczyć przypisaną osobę.

Po drugie, także klient może przypisywać osoby do zgłoszenia po swojej stronie. Co ważne, kierownicy mogą ustawiać tylko kierowników, a klienci klientów, sprawiając, że system jest chroniony przed błędami wynikającymi z braku informacji o osobach po drugiej stronie. Ponownie - przy dużych projektach z zaangażowanymi użytkownikami u zleceniodawcy zazwyczaj każdy z nich odpowiada za koordynację innej części systemu, w związku z czym istnieje też potrzeba dostarczenia informacji na temat tego, kto może zaprezentować szczegóły.

Lista zgłoszeń, gdzie przefiltrowano po jednej przypisanej osobie, a także pokazano filtr umożliwiający m.in. wyświetlenie zgłoszeń przypisanych do zalogowanego użytkownika lub bez przypisanego pracownika.

Po trzecie, wspomniane już wyżej filtrowanie - przy dłuższych pracach zarówno wykonawcy, jak i klienci chcą zobaczyć, czym jeszcze muszą się zająć. Ale co więcej, kierownik projektu (czy Product Owner) również chciałby czasem zerknąć na to, jaki jest status zagadnień przypisanych do osoby X lub czy ta osoba ma jeszcze dużo pracy. To bardzo ułatwia poruszanie się po projekcie oraz śledzenie postępu.

Możliwość ukrywania zgłoszeń dla poszczególnej roli

Czasem jest tak, że wykonawcy nie chcą prezentować niektórych zgłoszeń klientowi, ale jednocześnie chcą je gdzieś umieścić dla reszty zespołu. Ma to miejsce zazwyczaj podczas etapu testów wewnętrznych, gdzie niekoniecznie wskazane jest informowanie zleceniodawcy o pewnych błędach, które na tym etapie zostały znalezione i zostaną skorygowane jeszcze przed oficjalną prezentacją. Także klienci czasem mogą chcieć zapisywać swoje pomysły i chwilowo udostępnić je wyłącznie osobom o wybranej roli.

Widok aktualizacji zgłoszenia, gdzie pod polem 'Role' widać wybraną rolę kierownika.

Cóż, teraz jest to możliwe dla każdego zgłoszenia i ponownie - kierownicy mogą udostępniać zgłoszenia tylko innym kierownikom, a klienci klientom. Z doświadczenia to bardzo ułatwia komunikację przy poprawkach wewnętrznych, a jednocześnie ogranicza natłok wiadomości u osób, które i tak pewnych zgłoszeń nie zobaczą. Należy też wspomnieć, iż standardowo, przy braku określenia ról, zgłoszenie widzą wszyscy mający dostęp do projektu.

Statusy charakterystyczne dla projektu

Przy okazji rozmów z różnymi klientami o ich obsłudze Feedybacky'ego dostrzegliśmy, jak różny może być przepływ informacji. Nie zawsze procedura odpowiada statusom, które system domyślnie oferuje i nierzadko pewne statusy były nadmiarowe lub wykorzystywane niezgodne z przeznaczeniem. Przykładem może być obecność w procesie więcej niż jednego serwera testowego lub sam proces akceptacji klienta - do tej pory odbywało się to poprzez odpowiednią odpowiedź w komentarzu. Czas to zmienić.

Widok sekcji statusów w konfiguracji projektu, gdzie można wprowadzić swoje nazwy i zmienić kolejność.

Obecnie każdy projekt ma swoją listę statusów. Grupy są stałe (z nimi są skojarzone statystyki oraz zachowanie systemu w pewnych sytuacjach), jednak kierownicy projektu mogą dowolnie modyfikować same pozycje, które można ustawić dla zgłoszeń w danym przedsięwzięciu. Jedynie status "nowy" jest obowiązkowy ze względu na bycie "wejściem" dla nowych zgłoszeń.

W ten sposób można nie tylko utworzyć stany charakterystyczne dla danego typu współpracy z klientem, ale także zmienić nazwy istniejącym pozycjom.

Inne zmiany

Oczywiście, poza większymi funkcjami, w Feedybacky został wprowadzony szereg mniejszych zmian, które zwykle nie są na tyle interesujące, aby o nich osobno mówić. W szczególności są to drobne poprawki layoutu, okna modalne pozwalające potwierdzić pewne akcje czy zmienione teksty. W tym miejscu warto wspomnieć o:

  • symbolu projektu, który jest nie tylko ciągiem znaków, ale posiada również przypisany hash, ułatwiający identyfikację projektu w systemie (a przy okazji wymuszający korzystanie z tego hasha we wtyczce),
  • przypadkowe wyjście z częściowo uzupełnionego formularza aktualizacji zgłoszenia musi być potwierdzone przez użytkownika, co nie jest wielkim kosztem czasowym, gdy nastąpiło to świadomie, ale w niektórych przypadkach pozwala zapobiec utracie długo wpisywanych danych,
  • usuwanie członków projektu było zdecydowanie zbyt łatwe i musiało zostać zabezpieczone oknem modalnym.

Co dalej?

Tempo przybywania pomysłów jest na pewno szybsze niż tempo ich realizacji, ale warto pamiętać, że nie zawsze każdy pomysł jest odpowiedni. Potwierdzi to każda osoba pracująca przy kreatywnych projektach, gdzie zbyt duże nagromadzenie różnych koncepcji nie zawsze gwarantuje spójność, a wręcz może wytworzyć chaos. Dlatego trzeba to kontrolować i nie każda idea, która pozornie wygląda na wspaniałą, jest rzeczywiście warta realizacji.

Dlatego warto wyznaczać sobie odgórne, bardziej dalekosiężne cele i takim jest np. w naszym przypadku postępująca rezygnacja z Redmine'a na rzecz Feedybacky'ego, co oznacza zagwarantowanie np. miejsca do przechowywania notatek czy lepsze raportowanie godzin. Ostatnie miesiące pokazały też, iż potrzebne są zmiany w zakresie zarządzania wycenami. W planach jest także przearanżowanie kokpitu, który w obecnej formie jest rzadko użyteczny. Z pewnością, gdy nastąpią zmiany z tym związane, doczekają się one artykułu na naszym blogu.

Tym niemniej, zapraszamy także do przetestowania obecnych zmian. Jeśli jesteście chętni do skorzystania z projektu Feedybacky (nadal w fazie beta), zachęcamy do kontaktu.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Czy każdy musi umieć programować? https://wildasoftware.pl/post/czy-kazdy-musi-umiec-programowac?ref=rss https://wildasoftware.pl/post/czy-kazdy-musi-umiec-programowac?ref=rss Thu, 16 May 2024 17:30:00 +0000 Wszyscy dobrze wiemy, że boom na bycie programistą pojawił się jakiś czas temu i nadal mocno się trzyma. I mimo że w chwili, gdy to piszę, mówi się o lekkim kryzysie zatrudnienia w branży IT, to nadal ten zawód ma przyszłość. Ale nie musimy patrzeć na to tylko z biznesowego punktu widzenia - samo programowanie bywa po prostu przyjemne i rzeczywiście może pomóc w wykonywaniu pewnych czynności na komputerze. I nie myślmy tutaj o poważnych aplikacjach czy nawet stworzeniu domowej strony internetowej - przecież można pisać skrypty pomagające np. w czyszczeniu dysku, przenoszeniu plików lub ich zliczaniu. Te czynności mogą wydawać się proste, ale są uciążliwe czasowo, więc ich przyspieszenie za pomocą krótkiego programu może być zbawienne, a przy okazji pozwolić poczuć dumę z czegoś, co zrobiło się samemu.

Idąc dalej, co jakiś czas pojawia się stwierdzenie, że programowanie niedługo będzie tak samo powszechną umiejętnością, jak choćby używanie młotka. Ba - już jest i niektórzy wręcz nawołują, iż każdy inteligentny i idący z duchem czasem człowiek powinien umieć programować. Stwierdzenie wydające się dość kontrowersyjnie i odważnie, które brzmi jak idealny nagłówek dla zbierającego kliknięcia wywiadu z ekspertem ds. rekrutacji. Zastanówmy się, na ile jest bliskie prawdy.

W czym programowanie pomaga w życiu?

Zanim na dobre zaczniemy, powiedzmy sobie jedną oczywistą rzecz - nie będziemy tutaj rozprawiać o nauce programowania w celu pracy w IT, choć pod koniec tekstu do tego nawiążę. Zajmiemy się raczej tym, czy kodowanie może być użyteczne w codziennych obowiązkach w zupełnie innych branżach lub w swoich domowych potrzebach.

Przede wszystkim warto też zwrócić uwagę, iż nie tylko programowanie, ale sam proces nauki programowania może być kształcący, gdyż siłą rzeczy rozwiązywanie kolejnych problemów pomaga w rozwijaniu zdolności algorytmicznych, logicznego myślenia i pozwala nabrać wiedzy o działaniu programów oraz środowisk, w których działają. Nie trzeba być mistrzem programowania, aby pomagało ono w rozwoju osobistym lub innych dziedzinach, wymagających tych samych lub podobnych umiejętności - wystarczy staranie się o bycie tym mistrzem.

Ale mimo to uczenie się programowania dla samego uczenia nie ma sensu, jeśli nie idzie za tym zdobycie zdolności do zrobienia czegoś konkretnego. Popatrzmy na kilka przykładów:

  • porządkowanie dużej liczby zdjęć i poukładanie ich w folderach,
  • zbiorowa zmiana nazwy plików lub folderów według konkretnego wzorca,
  • przeszukiwanie lub analiza dużego pliku tekstowego,
  • pobranie informacji o cenach wielu produktów z różnych sklepów, aby znaleźć najtańszy,
  • wykonanie często powtarzanych sekwencji kilku operacji,
  • stworzenie prostego interfejsu do bazy danych posiadanych płyt CD z muzyką.

Takich pozycji mogłoby być o wiele, wiele więcej. W większości punktów widzimy określenia typu "duża liczba", "wiele", "zbiorowa" itd. i to istota problemów, w których programowanie bardzo może nam pomóc - operowanie na dużym wolumenie danych, których ręczne przeglądanie lub modyfikacje byłyby możliwe, ale bardzo czasochłonne. Do pewnego momentu pisanie programu, który ułatwiłby nam takie zadanie, nie ma sensu - o wiele szybciej pozmieniamy nazwę 10 plików ręcznie niż napiszemy odpowiedni kod. Ale jeśli tych plików byłyby tysiące, to lepiej zdać się na automat.

W różnych rozwiązaniach bardzo często podkreśla się pomoc różnych skryptów przy powtarzalnych akcjach - zresztą, w samej informatyce nie bez powodu istnieją np. testy automatyczne, które mają tę przewagę nad testami manualnymi, że można je uruchamiać bardzo często i to stosunkowo niskim kosztem. Programowanie może nam tutaj szczególnie pomóc, zresztą tak samo, jak w pisaniu aplikacji, nawet bardzo prostych, które pozwolą wygodniej składować pewne dane.

Wiemy już, że programowanie się przydaje, nawet na poziomie bardzo amatorskim i w przypadku normalnego użytkownika komputera. Ale inna sprawa, czy jest potrzebne. I tutaj nawiążemy np. do wymienionego na liście porównywania cen z różnych sklepów.

Na wszystko jest już rozwiązanie

Niestety lub stety, w Internecie dostępna jest tak ogromna liczba aplikacji i nawet rozwiązań dostępnych bezpośrednio z przeglądarki, że właściwie wszystkie problemy zostały już "pokryte". Dociekliwy użytkownik, natrafiając na problem, który wymaga automatyzacji, znajdzie w odmętach Internetu coś, co mu pomoże. Z dużą dozą prawdopodobieństwia doszuka się także odpowiednich opcji w popularnych programach, które przynajmniej częściowo rozwiążą jego problem. Wracając do przykładu porównywania cen - większość z nas kojarzy takie serwisy jak Ceneo czy choćby Świat Czytników.

Krótko mówiąc, mamy tutaj do czynienia z dylematem - czy warto poświęcać czas na nauczenie się czegoś i osiągnięcie satysfakcji, ale jednak wyważać otwarte drzwi, czy zamiast tego szukamy gotowego narzędzia, uczymy się go i dostosowujemy do niego. Programowanie nie jest potrzebne do tego, aby ułatwić sobie pracę - może być przydatne i pozwolić stworzyć dokładnie to, co chcemy, ale nie jest to warunek konieczny do tego, aby poradzić sobie ze skomplikowanymi zadaniami przy pracy na komputerze. Do tego dochodzi częstotliwość występowania takich sytuacji oraz ich specyfika.

W każdym mieszkaniu wisi coś na ścianie, bywają zapchane rury w łazience czy przepalona żarówka. Do tego wszystkiego można wynająć fachowców, ale umówmy się - w tych i podobnych przypadkach warto choć z częścią rzeczy umieć poradzić sobie samemu. Nawet, jeśli ktoś jest taką lebiegą w pracach domowych jak ja (tak, przyznaję się bez bicia - osoby, które mnie znają, pewnie jeszcze dołożyłyby coś od siebie), to różne sytuacje są na tyle częste, że choćby z czystej oszczędności czasu i pieniędzy warto umieć coś wymienić, załatać lub przykleić. I teraz wchodzi programowanie, które pozwoli nam na to samo, ale w przypadku problemów spotykanych podczas operowania na komputerze - czy są to na tyle częste i - co ważne - poważne kłopoty, że powinniśmy sami umieć na nie zareagować, a nie tylko wiedzieć, gdzie (lub u kogo) szukać pomocy? Oczywiście, pewnie znajdą się takie scenariusze, natomiast nie zawsze wysiłek przeznaczony na naukę programowania opłaci się, aby poradzić sobie z pojedynczą sprawą.

Należy jeszcze pamiętać o tym, że tak, jak nie każdy nadaje się do prac manualnych czy zaawansowanej matematyki, tak nie każdy w lot pojmie zasady rządzące programowaniem, budowaniem i uruchamianiem napisanych przez siebie programów. I nie jest to nic złego - każdy z nas ma talent do czegoś innego, charakter pozwalający na łatwiejsze poruszanie się w jednym terenie, ale wymagający więcej pracy w innych obszarach. Podkreślam "wymagający więcej pracy", a nie "uniemożliwiający" - programowania może nauczyć się każdy. Natomiast nie należy być złym na siebie, jeśli ta dziedzina okaże się dla kogoś za trudna lub po prostu nieinteresująca.

W żadnym wypadku nie chcę zniechęcać do nauki programowania, a już na pewno nie dlatego, że sam jestem programistą i nie chcę wychowywać sobie konkurencji. Przeciwnie - bardzo rekomenduję tę zabawę, gdyż może być to fajne, pożyteczne hobby, a w dodatku dające sporo satysfakcji (gdy coś wychodzi) oraz faktycznie dające umiejętności, które na pewno się nie zmarnują i mogą zaowocować nawet czymś poważniejszym. Poczucie bycia "lepszym" użytkownikiem (a na pewno bardziej świadomym) jest bardzo cenne. Ale w życiu nie powiedziałbym, że programowanie to umiejętność, bez której człowiek jest bezwartościowy na rynku pracy - to bzdura i ktoś, kto tak twierdzi, raczej chce się popisać aniżeli realnie doradzić. Nawet w IT i w software house'ach pracują osoby, które nie umieją programować i bardzo dobrze sobie radzą - pełnią po prostu inne role, w których się realizują. Czasem słyszę od początkujących project managerów lub product ownerów prośby o wskazanie, gdzie zacząć uczyć się programować, bo "chcą zrozumieć programistów". I to jak najbardziej jest cenne, ale nie jest warunkiem koniecznym do tego, aby poradzić sobie w pracy. Nawet w związanej z technologią. Warto przypatrzeć się narzędziom sztucznej inteligencji, gdyż one dużo szerzej wchodzą do wielu popularnych branż, choć nadal jako pomoc, a nie istota pracy.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> 5 twarzy migracji https://wildasoftware.pl/post/5-twarzy-migracji?ref=rss https://wildasoftware.pl/post/5-twarzy-migracji?ref=rss Thu, 02 May 2024 17:30:00 +0000 Gdy słyszymy słowo "migracja", zazwyczaj od razu odnosimy to do transferu ludzi w społeczeństwie. Niektórzy mają w pamięci znanych Polaków, którzy w czasie zaborów lub wojny znaleźli się poza granicami naszego kraju i tam działali. Innym z kolei od razu w głowie rozbrzmiewa "eeeeemiiiiigrowałeeeem" z piosenki "Jolka, Jolka pamiętasz" Budki Suflera. Jednak dzisiaj będziemy uderzać w zupełnie inne nuty, a mianowicie melodie związane z informatyką, gdyż tam migracja jak najbardziej też występuje.

To słowo w naszej dziedzinie nie jest niespotykane, a co więcej, powtarza się dość często i nie chodzi tutaj tylko o wyjazdy programistów do ciepłych krajów, aby tam uskuteczniać home office. Co więcej, za każdym razem "migracja" może wystąpić w innym kontekście. Właśnie te dzisiaj sobie omówimy, pokazując przy okazji, jaka głębia kryje się w pewnych zagadnieniach, której osoby nietechniczne nie zawsze się spodziewają.

Migracja danych

To kontekst, który najczęściej pojawia się w rozmowach software house'u ze zleceniodawcą. Wynika to z faktu, iż oprócz nowych, świeżych projektów, istnieją też takie, które mają zastąpić system używany do tej pory przez klienta. To oznacza, że użytkownicy systemu posiadają już jakieś dane i na pewno nie będą zadowoleni z ich utraty, gdyż będą im potrzebne do pracy już w nowym oprogramowaniu. A zatem te dane trzeba przenieść, czyli zmigrować.

Nie jest to takie proste zagadnienie. Każdy (lub prawie każdy) system przechowuje dane w bazie danych o schemacie, który na pewno różni się od schematu, który będzie w nowym systemie IT. Nie chodzi tutaj tylko o układ tabelek (jeśli mówimy o relacyjnych bazach danych), ale też o sposób przechowywania informacji katalogowych, oznaczenia typów i inne specyficzne dane, które są zakodowane w określony sposób. Niejednokrotnie widzieliśmy również sytuacje, w których wartości, jakie w nowym oprogramowaniu powinny być unikalne, w dotychczasowych systemach były dość swobodnie przechowywane. Oczywiście, istnieją przypadki, w których przeniesienie takich informacji zachodzi dość sprawnie, ale są to wyjątki, a wręcz "jednorożce".

O wiele częściej zachodzi potrzeba opracowania mapowania pomiędzy dwiema bazami danych, ustalenia, które dane faktycznie muszą być przeniesione, a które można pominąć (nie zawsze jest potrzeba migracji wszystkich wartości) oraz napisania skryptu, który to zrobi w powtarzalny sposób (lub skorzystania z istniejących rozwiązań). Często potrzebne są też konsultacje z konstruktorami poprzedniego systemu w celu upewnienia się, jak interpretować pewne zapisane informacje, szczególnie, jeśli są one niespójne lub przechowywane w sposób "jedyny w swoim rodzaju" (np. typy zapisane poprzez jednoliterowe skróty znane tylko osobom mającym dostęp do starego kodu). Co więcej, wbrew obiegowej opinii, migracja zwykle zachodzi więcej niż raz - ten proces często musi odbywać się kilkukrotnie lub o różnym zakresie:

  • migracja pełna lub częściowa (np. tylko pewnych danych),
  • migracja od początku lub tylko nowych danych - tutaj rada, aby od razu to przemyśleć, gdyż gotowość ograniczenia zakresu migracji bardzo wpływa na strukturę skryptu migrującego,
  • migracja testowa, sprawdzająca "jak to będzie" po migracji właściwej,
  • migracja właściwa, po której w pełni wdrażany jest nowy system,
  • migracja uzupełniająca, kopiująca dane, które pojawiły się od czasu migracji właściwej.

Sam proces migracji to nie tylko przeniesienie danych - należy również pamiętać o plikach (np. zdjęciach przedmiotów w sklepie internetowym czy avatarów użytkowników), które często są zapisywane w bardzo zindywidualizowany sposób i pliki mają przeróżne nazwy, czasami wynikające ze sposobu ich wyszukiwania w systemie (np. zdjęcia przedmiotu o ID = 120 zawsze będą w folderze upload/item/120). Oczywiście, najlepiej jest przygotować system plików w nowym systemie tak, aby skopiowanie zbiorów dyskowych było bezbolesne, ale zazwyczaj nie jest to możliwe. Po pierwsze, nie zawsze stara struktura jest dobra i warto ją zachować za wszelką cenę. Po drugie, plików jest zazwyczaj tak dużo, że same przenosiny trochę trwają ze względów stricte "fizycznych". Po trzecie, zazwyczaj nikt o tym nie myśli na początku. I tutaj na chwilę się zatrzymamy.

Do pewnego stopnia zrozumiałe jest pomijanie tematu migracji na starcie, gdyż na początku wszyscy są zaaferowani powstającym nowym systemem i tym, aby prezentował się lepiej oraz umożliwiał więcej niż starsze oprogramowanie. Problem jednak w tym, że takie podejście może spowodować wiele nieporozumień - klient najczęściej myśli, że migracja danych to szybki proces, o którym nie trzeba za dużo mówić. Prosi też o wycenę tego elementu bez zaprezentowania obecnych struktur i sposobu przechowywania plików, co sprawia, że programiści najczęściej szacują taką pracę w ciemno, co w przeważającej liczbie przypadków (a właściwie prawie zawsze) oznacza niedoszacowanie zarówno budżetu, jak i czasu. A dlaczego nie ma dostępu? Bywa, że ze względów prawnych - klient jeszcze nie zdecydował się na współpracę, gdyż musi poznać wycenę i jest mniej chętny, aby na tym etapie udostępniać wrażliwe elementy swojej infrastruktury lub informacje. Oczywiście, to wszystko można załatwić i podpisać odpowiednie formalności, a programiści nie pójdą z tym na giełdę w darkwebie, natomiast ten etap jest na tyle specyficzny, że software house'owi też zależy na szybkim oszacowaniu pracochłonności, aby sam proces wyceny był efektywny. Także polecamy również nad tym tematem pochylić się na początku, a nie tylko zaznaczyć, że on jest i kiedyś nadejdzie.

Nie zawsze przenoszenie danych dotyczy migracji pomiędzy bazami danych - bywa również tak, iż informacje klienta znajdują się w:

  • w innych systemach informatycznych (niebędących pod kontrolą zleceniodawcy),
  • w arkuszach kalkulacyjnych (lub plikach CSV),
  • w plikach tekstowych,
  • w mailach.

Oczywiście, ostatni punkt to ekstremum, aczkolwiek kiedyś niemalże się z tym zetknęliśmy. Za to pierwsze dwa źródła danych (a szczególnie drugi) są bardzo częste. Klient nie zawsze przechowuje informacje w systemie - bywa, że są one zbierane poprzez współdzielone arkusze i właśnie nieefektywność takiego magazynowania sprawia, iż potrzebny staje się nowy system IT. Nierzadko również obecnie wykorzystywany system zewnętrzny traci wsparcie lub przestaje być wystarczający, co staje się impulsem do zaprojektowania swojego oprogramowania. Jednak istniejące dane trzeba wydobyć i tutaj wszystko zależy od tego, jak do tego podchodzi obecny dostawca oprogramowania. Z naszych doświadczeń wynika, że najczęściej mają do tego przygotowane procedury i eksportery. Ale trochę przygód zawsze jest.

Migracja wewnątrz aplikacji

Dawno już minęły czasy, w których zmiana schematu bazy danych wykorzystywanego przez aplikację wymagała ręcznego przygotowywania zapytań SQL i ich odtwarzania przez innych programistów. Od wielu lat frameworki posiadają funkcje migracji, która polega na wykorzystaniu wewnętrznych, zwykle wygodnych metod do np. dodania kolumny czy wprowadzenia stałych danych. Co jednak ważniejsze, tego typu podsystemy kontrolują również wprowadzanie zmian w różnych środowiskach i u różnych programistów poprzez zastosowanie tylko tych modyfikacji, które na danej maszynie jeszcze nie zostały wykonane, a także wspierając wycofywanie ich. To sprawia, że praktycznie jedną komendą w terminalu można zaktualizować swoją bazę danych i nie przejmować się szukaniem wpisów, których jeszcze nie mamy u siebie - moduł migracji w frameworku zrobi to za nas.

Tutaj warto wspomnieć, że zazwyczaj czymś innym jest migracja, a czymś innym tzw. seedowanie. W przypadku tego pierwszego mówimy właśnie o schemacie bazy danych, a więc ramach, w których ona działa. Natomiast seedy najczęściej odpowiadają za wprowadzanie stałych danych, które musi posiadać baza danych konkretnej aplikacji w każdym środowisku, aby móc normalnie działać i oferować wszystkie funkcje. Do tego dochodzi jeszcze coś, co po angielsku nazywa się fixtures (swoim zwyczajem nazywamy to "fiksturami"), a co jest pakietem danych, których obecność w bazie musi być zapewniona np. przed uruchomieniem testów automatycznych.

Migracja pomiędzy komputerami

Gdy każdy człowiek dostaje nowy komputer, zazwyczaj czuje ekscytację - znowu wszystko będzie działać szybko, sprawnie, a w dodatku do dyspozycji są lepsze podzespoły i uaktualniony system. Jednak niedługo później taki użytkownik zdaje sobie sprawę, że aby kontynuować pracę, najczęściej musi przenieść wszystkie swoje dane i - co gorsza - zainstalowane programy. A to już bywa bolesne lub przynajmniej długotrwałe. Witajcie w piekle migrowania z komputera na komputer.

Oczywiście, trochę żartuję i przesadzam, jednak faktem jest, że przenosiny na nowy sprzęt wiążą się zazwyczaj z poświęceniem trochę czasu i nerwów na dostosowanie nowinki do swoich potrzeb. Tutaj bardzo dużo zależy od środowiska - czasem kończy się na ręcznym skopiowaniu plików i instalacji oprogramowania od nowa, a niekiedy sami producenci ułatwiają ten proces. Pod tym kątem (przynajmniej pod tym...) rewelacyjne są komputery Apple'a, które mają wbudowaną opcję migracji pomiędzy maszynami. Jednak istnieją również inne sposoby ułatwiające ten proces, takie jak skorzystanie z chmury czy klonowanie dysku. Warto też zdać sobie sprawę z tego, że nie zawsze warto wszystko przenosić jeden do jednego - kto nigdy nie miał nieporządku na swoim dotychczasowym komputerze i mówił sobie "posprzątam przy okazji przenosin na nowy" niech pierwszy rzuci kamieniem. Au, ale nie w oko.

W przypadku programistów przenosiny na nowy sprzęt powinny być wyjątkowe sprawne, gdyż niemal natychmiast powinni oni zacząć pracę - w końcu klienci nie będą czekali, aż koder skończy wszystko kopiować. Tym niemniej, z obecnie dostępnymi narzędziami nie jest to aż tak problematyczne, zwłaszcza, jeśli mamy dobrze przygotowane procedury konfiguracji stosu technologicznego lub po prostu korzystamy z konteneryzacji.

Migracja użytkowników

Bardzo ciekawy i głęboki temat, związany nawet nie tyle z realizacją oprogramowania, co ludzką psychologią. Załóżmy, że użytkownicy przez długi czas korzystali z jednego oprogramowania i teraz muszą lub mogą przenieść się na drugie. Ewentualnie producent danej aplikacji przygotował nową wersję interfejsu i musi opracować procedurę przeniesienia osób. W obu przypadkach mówimy o migracji użytkowników.

Dlaczego wspomnieliśmy tutaj o psychologii? Z perspektywy użytkownika ten proces nie jest łatwy - musi poznać nowy interfejs, odmienne zasady rządzące oprogramowaniem i styl pracy. To wszystko sprawia, że przestawienie się na nowy sposób działania zajmuje trochę czasu, a to automatycznie zniechęca niektórych do zmiany, o ile nie widzą wyraźnych korzyści. Szczególnie jest to odczuwalne w firmach mających mniejsze związki z informatyką, które dodatkowo do tej pory pracowały według określonych procedur, a teraz mają przenieść się na nowe oprogramowanie i nie spełnia ono wszystkich oczekiwań. Konkretnie jednego - nie jest starym oprogramowaniem, nie wszystko jest w tym samym miejscu i nie można klikać "na pamięć". To powoduje duże problemy i zwykłą niechęć, z którą mierzyć się muszą nie tylko producenci, ale też szefostwo takiej firmy, w których interesie też jest zachęcić do korzystania z nowinki.

To wszystko oznacza, że takie przenosiny nie zachodzą tylko w sferze technicznej - one muszą zajść równiez w sferze mentalnej. Jak najbardziej pomagają tutaj różne tutoriale i dobrze przygotowany system pomocy, porównujący oba systemy, jednak zazwyczaj nie jest to wystarczające. Aby przełamać strach lub niechęć do nowego systemu, potrzebne są:

  • jasno wypunkowane korzyści, ale nie w biznesowy sposób typu "będziesz pracował efektywnie" - tutaj bardzo dobrze sprawują się argumenty w stylu "tego nie można było zrobić wtedy, a teraz jest to możliwe" lub "teraz zrobisz to łatwiej",
  • szkolenia - ludzki przewodnik, pomagający przejść przez trudny okres migracji, jest skuteczniejszy niż tutoriale, choć to bardzo zależy od sytuacji i charakteru współpracy,
  • wideotutoriale na konkretnych przypadkach - warto poznać najczęstsze obawy użytkowników lub problemy, z którymi muszą się zmagać i zaprezentować, w jaki sposób poradzić sobie z nimi w nowym systemie, a także... wyrazić współczucie,
  • dodatkowe zachęty, nie zawsze materialne - w przypadku nowych odsłon systemów dostępnych w chmurze dla wielu użytkowników, można odnieść się do potrzeby użytkownika, który chce poczuć się potrzebny i ważny i zapewnić go, że będzie w ścisłym gronie testerów nowego rozwiązania, dzięki czemu zostanie wyróżniony na tle innych.

Oczywiście, każdy taki proces jest inny i wymaga innych rozwiązań. Czasem migracja nie wiąże się z żadnymi trudnościami, a czasem jest wręcz blokowana i mimo długotrwałych starań nie dochodzi do skutku z różnych przyczyn.

Migracja technologii

Wróćmy do kwestii technicznych. Skoro "migracja" to ogólnie przeniesienie obiektu pomiędzy dwiema lokalizacjami lub obszarami, to także przejście programistów na nową technologię można określić tym mianem. Zmiana stosu technologicznego to poważna sprawa, zwłaszcza, jeśli zachodzi wewnątrz ogranizacji, w której programiści, przyzwyczajeni do jednego pakietu rozwiązań, muszą poznać i nauczyć się nowego frameworka czy języka. Wiąże się to z czasem oraz wysiłkiem, który przez pewien czas utrudnia rozwój oprogramowania, choć w dalszej perspektywie ma przynieść korzyści. Dlatego tego typu zabiegi nie powinny być przeprowadzane bez dobrego planu oraz bez wyraźnych powodów, podobnie zresztą jak to ma miejsce przy przepisywaniu konkretnego oprogramowania.

O takiej migracji mówimy również w przypadku, kiedy programista zmienia pracę i trafia do zespołu, w którym musi pisać w nieznanym sobie frameworku. Nie jest to nic rzadkiego - gdyby programiści przenosili się pomiędzy zespołami, w których cały czas korzystają z jednego technologii, to zakres takich "przeprowadzek" byłby bardzo ograniczony, a poza tym perspektywy rozwoju byłyby mniejsze. Natomiast nie zmienia to faktu, że każdy nowy element stosu technologicznego (i to tak poważny jak biblioteka, framework czy nawet język programowania) to duża zmiana i konieczność adaptacji.

Podsumowanie

Jak widać, migracja w IT niejedno ma imię. Najważniejsza jest procedura przenoszenia informacji z jednego systemu informatycznego do drugiego, jednak nie jest to jedyny kontekst, w którym to słowo jest używane (zazwyczaj nie bez dodatkowych przekleństw). Także, jeśli znajomi programiści powiedzą Wam o tym, iż mają do czynienia z migracją, to zazwyczaj nie mają na myśli czynników socjologicznych i nie jest to zaproszenie do rozmowy o polityce czy przeprowadzce.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Informowanie o przerwie technicznej w usłudze https://wildasoftware.pl/post/informowanie-przerwie-technicznej-usludze?ref=rss https://wildasoftware.pl/post/informowanie-przerwie-technicznej-usludze?ref=rss Thu, 18 Apr 2024 17:30:00 +0000 W życiu każdego serwisu internetowego przychodzi taki moment, że trzeba go zaktualizować lub wykonać inne zadania związane z utrzymaniem lub - jak nakazuje obyczaj nazywania wszystkiego po angielsku, aby brzmieć bardziej profesjonalnie - maintenance. W przypadku systemów IT tego typu operacje warto przeprowadzać w momencie, kiedy nie będą działy się niespodziewane operacje na danych, a więc mówiąc inaczej - użytkownicy nie będą mogli niczego zmieniać. W przypadku małych systemów można to zagwarantować bezpośrednią komunikacją, ale w przypadku dużych platform staje się to niemożliwe. Wówczas wprowadza się tzw. przerwę techniczną (ang. maintenance break), o której porozmawiamy sobie dzisiaj trochę więcej.

Nie ukrywam, że do napisania tekstu zainspirowała nas sytuacja, która miała miejsce w marcu 2024 r., a która wiązała się z czasową i lokalną niedostępnością Internetu u jednego operatora. Nie jest to nic nadzwyczajnego, gdyż takie przerwy w dostawie zdarzają się co jakiś czas w różnych firmach - ot, złośliwość rzeczy martwych, powodująca konieczność naprawienia awarii. Zawsze też warto sprawdzić połączenie w mieszkaniu lub firmie, aby upewnić się, że problem nie leży po stronie routera, który czasem wystarczy uruchomić ponownie. Jednak w tym przypadku moją uwagę zwróciło coś innego - o tym, iż awaria jest z winy operatora, dowiedziałem się z jego fanpage'a na Facebooku i to nie z postu, ale odpowiedzi na komentarz innego użytkownika. Przy okazji, tutaj trzeba przyznać, że zarządzający profilami takich firm na mediach społecznościowych mają trudne życie, gdyż wiele postów to wiadomości negatywne, pomstujące na niedziałające usługi. Ale, wracając do odpowiedzi, wynikało z niej, że... operator zaplanował prace modernizacyjne, o których wcześniej nie zakomunikował i podczas tej modernizacji wystąpiła "nieplanowana awaria". Wszystko napisane z uśmiechem i bez konkretów, co akurat łatwo zrozumieć, gdyż zwykle nie wiadomo, ile potrwa stawianie usługi na nogi. A tutaj zajęło to kilkanaście godzin, podczas których odbiorcy nie wiedzieli, jaki jest aktualny status, a oficjalnego komunikatu nie było lub był tak ukryty, że nie wszyscy do niego dotarli. Głównym źródłem informacji była strona Downdetector oraz artykuły w niektórych serwisach internetowych.

(Co ciekawe, podobna sytuacja miała miejsce kilka tygodni później, ale tym razem operator stanął na wysokości zadania i oficjalnie przyznał się na fanpage'u. Zresztą, awaria trwała trochę krócej.)

Wówczas zrozumiałem, że wśród twórców różnych usług związanych z Internetem (niezależnie od ich charakteru), informacja o zaplanowanej przerwie technicznej to nie tylko życzliwość w stosunku do użytkowników czy klientów, ale czasami wręcz obowiązek, który w dodatku może ukazać firmę jako podmiot odpowiedzialny i dbający o konsumenta. Być może nawet coś, co powinno być odgórnie regulowane w konkretnych przypadkach.

Czym jest przerwa techniczna?

Każda usługa działająca potencjalnie w trybie ciągłym (słynne 24/7), ale także w ściśle ustalonych ramach czasowych, potrzebuje przerw technicznych. Czasem wynika to z aktualizacji oprogramowania lub sprzętu, a niekiedy z zaplanowanych przeglądów konserwacyjnych w celu upewnienia się, że wszystko działa jak należy i wykrycia ewentualnych usterek, zanim spowodują realny problem. W tym przypadku mówimy o zaplanowanych momentach, w których wiadomo, iż przez jakiś czas usługa (lub jej określony zakres) nie będzie dostępna - nie dotyczy to awarii, które z oczywistych względów trudno przewidzieć.

Taka "oficjalna" przerwa techniczna powinna wiązać się z:

  • zaplanowaniem jej w sposób najmniej dokuczliwy dla odbiorców,
  • wcześniejszym poinformowaniem odbiorców o zakresie, dacie i godzinach (*),
  • wyświetleniem odpowiedniego komunikatu na stronie,
  • poinformowaniem, pod jakimi danymi kontaktowymi można zasięgnąć więcej informacji,
  • ograniczeniem dostępu do odpowiedniego zakresu systemu dla konkretnych użytkowników lub adresów IP (*),
  • podaniu informacji, gdy przerwa techniczna się przedłuża i jakie są tego powody.

Niektóre z tych punktów sa oczywiste, natomiast warto rozwinąć kilka z nich, szczególnie, te które zostały oznaczone gwiazdką, co ma oznaczać, iż są zależne od sytuacji.

O formie przeprowadzenia formy technicznej decydują przede wszystkim trzy aspekty:

  • czas potrzebny na przeprowadzenie przerwy - im dłuższy, tym bardziej przerwa powinna być "sformalizowana",
  • popularność i zasięg usługi - im większe, tym informacja powinna być lepiej widoczna oraz podana z wyprzedzeniem,
  • zapisy w umowach - są usługi, które w kontraktach ze swoimi klientami mają zagwarantowane procedury w takich przypadkach.

Nie zawsze możliwe jest zapewnienie, iż przez cały czas trwania przerwy technicznej będzie dostępna plansza z informacją - w zależności od usługi oraz sytuacji, może pojawić się moment, w którym wgrywana jest właśnie nowa wersja, a nie ma już dostępnej starej. Oczywiście, nie powinno tak być - w idealnym świecie zaistniałby nieprzerwany ciąg: stara wersja -> plansza z przerwą techniczną -> nowa wersja. Jednak nie każdy serwis musi działać 24/7, a są też takie, gdzie operacyjność nie musi wynosić 100%.

Druga sprawa, to fakt, że podczas takiej przerwy do systemu (lub wydzielonego zakresu) dostęp mają tylko wyselekcjonowani użytkownicy. Zazwyczaj są to osoby o roli administratora lub maszyny posługujące się wyznaczonymi adresami IP. Z tym drugim jest czasami problem wynikający z faktu, że mało kto ma publiczny adres IP i te ustawienia trzeba edytować za każdym razem, ale lepsze to niż zablokowanie sobie dostępu całkowicie. Istnieją też praktyki, w wyniku których obok siebie znajdują się dwie wersje systemu i w odpowiednim momencie następuje podmiana plików lub domeny. To jednak wymaga dodatkowego ograniczenia widoczności danej domeny (także dla Google'a) lub wiary w to, że nikt tej testowej domeny "nie odgadnie" (co nie brzmi profesjonalnie). Lub po prostu bogatszej infrastruktury.

Co się dzieje podczas przerwy technicznej?

Odpowiedź na to pytanie jest prosta - zazwyczaj następuje wdrożenie nowej wersji systemu lub przynajmniej zaktualizowanie pewnego modułu. Jest to czas, w którym na serwerze pojawiają się nowe pliki, ale też testowane są modyfikacje, aby upewnić się, iż wszystko działa jak należy. Dotyczy to też parametrów konfiguracyjnych, których brak nierzadko stanowi zaskoczenie po wdrożeniu, gdyż w lokalnych środowiskach nie było potrzeby ich ustawiania lub modyfikowania. Dlatego tym bardziej warto posiadać jeden lub więcej serwerów testowych, zbliżonych pod kątem ekosystemu do serwera produkcyjnego, aby wykryć taką potrzebę dostosowania konfiguracji wcześniej.

Pojawia się również czasem konieczność przeprowadzenia na systemie operacji, które mogą potrwać dłużej i są na tyle obciążające, że może to dotknąć użytkowników normalnie korzystających z oprogramowania. Przykładem są jakieś gigantyczne raporty (ale rzadko; jeśli raport blokuje system, to nie jest to dobry sygnał) lub operacje czyszczące przeprowadzane na dużych tabelach. Pomijając kwestię architektonicznego podziału oprogramowania, warto wówczas zagrać w otwarte karty i poinformować o przerwie technicznej, aby nikt nie czuł się zaniepokojony potencjalną większą awarią i nie zaczął alarmować innych osób, burząc tym samym spokój i reputację twórców. Oczywiście, jeśli jesteśmy pewni, że wszystko będzie działać należycie, można zrezygnować z oficjalnej przerwy technicznej, ale w takiej sytuacji (jak i w każdej innej) i tak warto zrobić kopię zapasową bazy danych oraz odpowiednich plików.

Przerwa techniczna może też wynikać z przeprowadzenia konkretnych testów, które obciążają system lub weryfikują jego bezpieczeństwo, choć to się również rzadko zdarza - zazwyczaj są one przeprowadzane przed oficjalnym startem serwisu lub w trakcie, ale nigdy nie słyszałem o tym, aby wymogiem ich przeprowadzenia było zatrzymanie działającego oprogramowania. Jednak domyślam się, że życie pisze różne scenariusze.

Wreszcie, w przypadku niektórych firm może zajść potrzeba przeglądu i/lub modernizacji sprzętu. I tutaj wracamy między innymi do wspomnianych operatorów internetowych, którzy co jakiś czas muszą wymienić konkretny fragment infrastruktury lub przekonfigurować ją. W tym przypadku zazwyczaj odbywa się to na danym obszarze, który potencjalnie dotknąłby określoną grupę użytkowników. Przerwy techniczne związane z hardwarem mogą też dotyczyć oprogramowania - poza przypadkami aplikacji używanych w specyficznych środowiskach na określonych maszynach (desktopowych, wbudowanych itd.), zwyczajnie czasem przenosi się aplikacje między serwerami i transferuje domeny, co również trwa i w pewnych przypadkach może wymagać ogłoszenia oficjalnej pauzy.

Jak i kiedy informować?

Tak, jak wcześniej sobie podaliśmy, to zależy od rozmiaru i warunków, w jakich działa serwis. Najprostsza, ale zaraz też czasem równie kłopotliwa sytuacja jest w momencie, kiedy aplikacja jest wewnętrzna, tj. kierowana do pracowników konkretnej firmy lub organizacji. Z jednej strony łatwiej wówczas o umówienie takiej przerwy, gdyż komunikacja następuje pomiędzy dwoma podmiotami. Z drugiej strony, bywa tak, że użytkownicy korzystają z oprogramowania w konkretnych godzinach (np. 8:00-16:00) i w tym czasie system musi być w pełni dostępny, pomijając incydenty. Wówczas aktualizacje i inne prace muszą zachodzić poza tym zakresem czasowym lub w taki sposób, aby nie zaburzyć doświadczenia odbiorcy.

Inaczej bywa z systemami, które są kierowane do szerszego grona odbiorców - wówczas, jeśli istnieje choćby cień szansy, że system nie będzie w pełni "operowalny" w zauważalnym czasie, należy to publicznie ogłosić. Zazwyczaj robi się to poprzez media społecznościowe, jednak warto przyjąć zasadę, aby tego typu zdarzenia doczekały się komunikatu także na stronie firmowej lub w innych kontrolowanych miejscach. Dotyczy to zresztą nie tylko usług internetowych, ale też innych, jak choćby wodociągi, elektrownie, instytucje publiczne czy operatorzy innego rodzaju mediów. Owszem, nie zawsze można to zrobić na stronie projektu, zwłaszcza, jeśli to właśnie ona jest modernizowana, ale należy jasno wyznaczyć miejsce, w których odbiorcy będą wiedzieli, że tam mogą przeczytać o ewentualnych przerwach lub zorientować się, że chwilowa "awaria" to właśnie wynik zaplanowanych działań i się nie denerwować. W przypadku ważniejszych dostawców, zdecydowanie warto pomyśleć też o systemie powiadomień, mailowym lub SMS-owym, aby użytkownicy z odpowiednim wyprzedzeniem wiedzieli, kiedy nie skorzystają z usługi. Oczywiście, z zachowaniem RODO, prawa odbiorców do nieotrzymywania takich wiadomości itd. Szczególnie takiego ostrzeżenia kierowanego bezpośrednio do konsumentów zabrakło mi w przypadku omawianej sytuacji z operatorem usług sieciowych.

Jeśli chodzi o czas takiej przerwy technicznej, to w miarę możliwości warto zadbać o to, aby odbyła się ona w godzinach, w których użytkownicy najrzadziej korzystają z usługi - tak to robią np. banki. Natomiast tutaj trzeba powiedzieć wprost - nie zawsze jest to możliwe, gdyż w niektórych przypadkach firma nie dysponuje odpowiednią infrastrukturą lub zasobami, aby prowadzić takie prace o niestandardowych godzinach. Dlatego tym bardziej potrzebna jest wcześniejsza informacja, która pozwoli odbiorcom odpowiednio się przygotować i nie planować korzystania z usługi w czasie przerwy.

Jak to robią duże serwisy?

Ktoś może w tym momencie słusznie zapytać o to, w jaki sposób przerwy techniczne są przeprowadzane przez duże serwisy, oblegane przez tysiące lub nawet miliony użytkowników, a u których w sumie nie widać, aby cokolwiek się zatrzymywało. Nie dotyczy to banków, które - tak, jak już wspomnieliśmy - zgłaszają wcześniej przerwy i u których ten proces jest dużo bardziej sformalizowany. Ale np. platformy aukcyjne czy sklepy internetowe wypracowały pod tym względem swoje metody, które zazwyczaj idą w parze ze skalowaniem poziomym i posiadaniem wielu serwerów, na których istnieje kopia serwisu. To, oczywiście, wiąże się z dużymi nakładami na infrastrukturę, kadrę i procedury, jednak w przypadku dużych serwisów odpłaca się:

  • większą odpornością na awarię - aktualizacja następuje krokowo, serwer po serwerze (tzw. rolling update), a więc problem zostanie zauważony wcześnie i nie u wszystkich od razu, więc będzie można łatwiej się z tego wycofać i sprawdzić dokładniej,
  • większą dostępnością usługi,
  • możliwością aktualizacji tylko konkretnej części systemu (choć to zależy również od jego architektury),
  • łatwiejszą możliwością przeprowadzenia testów A/B,
  • możliwością wprowadzania modyfikacji bez potrzeby zatrzymywania dostarczania usługi.

Dwa skrajne punkty interesują nas najbardziej - prace techniczne lub konserwacyjne nie zachodzą na wszystkich serwerach naraz, tylko na jednym lub kilku. One są faktycznie objęte przerwą, jednak reszta serwerów działa normalnie i w dalszym ciągu przyjmuje żądania. Dopiero po zakończeniu prac na pierwszych serwerach i włączeniu ich, zatrzymuje się kolejne i tam przeprowadza zmiany. Jest to, oczywiście, długotrwałe, wymaga oskryptowania i nie wszyscy użytkownicy od razu odczują pozytywne skutki, ale to również chroni całość przed negatywnymi konsekwencjami. Przynajmniej w przypadku serwisów internetowych, gdzie odbiorcy są przekierowywani między serwerami i niekoniecznie zawsze korzystają z tego samego - gorzej jest w przypadku dostarczania mediów, w tym połączenia internetowego, gdzie nieudane prace w jednym węźle "wyłączają" określoną grupę użytkowników.

Uwagi końcowe

A co w przypadku, kiedy przerwa techniczna się przedłuża lub pojawia się awaria? Pomijając procedurę diagnozy i naprawy, warto pamiętać, że w przypadku dostawców popularnych usług, należy zwyczajnie... przeprosić i poinformować. Nie powinno być tak, że odbiorcy o globalnej lub lokalnej niedyspozycji systemów dowiadują się okrężną drogą, czytając komentarze mieszczące się pod postami na Facebooku. Zabrzmi to dziwnie, gdyż wszystko zależy od kontekstu, ale awarie się zdarzają i czasem nie da się ich przewidzieć oraz uniknąć. Natomiast należy zadbać o odpowiednią informację, aby odbiorcy jeszcze bardziej się nie denerwowali, tylko poczuli, że ratunek przychodzi ze strony profesjonalistów. Taki system funkcjonuje np. u spółek wodociągowych, które na swojej stronie internetowej posiadają dział z planowanymi pracami oraz awariami, gdzie aktualizowany jest status.

Być może niektóre z przedstawionych informacji okazały się dla większości oczywiste. Czasem jednak trzeba napisać coś oczywistego, aby zasygnalizować, iż dane wytyczne nadal obowiązują i warto o nie zadbać.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Jak wygląda współpraca IT z Lechem Poznań? https://wildasoftware.pl/post/jak-wyglada-wspolpraca-it-lechem-poznan?ref=rss https://wildasoftware.pl/post/jak-wyglada-wspolpraca-it-lechem-poznan?ref=rss Thu, 04 Apr 2024 17:30:00 +0000 Na tym blogu zazwyczaj umieszczamy materiały edukacyjne z obszaru IT, poradniki, czasem publicystykę. Jednak urok takich miejsc w sieci polega też na tym, iż jest to przestrzeń na opisywanie innych rzeczy, bardziej związanych z poczynaniami autorów w danej branży. Mówiąc wprost, czasem taki blog można wykorzystać do pochwalenia się. A my mamy parę takich pozycji w portfolio, z których jesteśmy dumni i na pewno współpraca z Lechem Poznań jest jedną z nich.

W dzisiejszym artykule przyjrzymy się temu, w jaki sposób współpracujemy z tym słynnym klubem ze stolicy Wielkopolski (a więc naszego macierzystego miasta) i jakie wyzwania IT stoją zarówno przed nami, jak i samym Lechem. Dla niektórych ciekawe będzie też to, jakie zapotrzebowanie na różne usługi może mieć taki zespół. Fanów piłki nożnej lojalnie ostrzegamy, że mało tutaj będzie o samym sporcie - skupimy się na Kolejorzu jako organizacji, która - jak każda inna - ma potrzeby w zakresie usług informatycznych, a które z racji branży są czasami specyficzne i dostarczają charakterystycznych wrażeń.

Struktura Lecha Poznań - kim jest nasz klient?

Zdajemy sobie sprawę, że ta sekcja dla niektórych może brzmieć abstrakcyjnie - jak można nie znać Lecha Poznań? Faktycznie, ta nazwa jest tak powszechna, że trudno znaleźć osobę, której nic ona nie powie, nawet jeśli nie jest to fan piłki nożnej. Tym niemniej, po pierwsze są wśród nas osoby, które sportem nie interesują się tak bardzo, że zaledwie "coś kojarzą" lub do dzisiaj myślą, że Lionel Messi to Hiszpan. A po drugie, istotne jest pokazanie szerszego kontekstu.

Początki Kolejowego Klubu Sportowego Lech Poznań Spółka Akcyjna (bo tak rozwija się "KKS Lech Poznań" i stąd pochodzi określenie "Kolejorz") sięgają 1920 roku, choć formalnie wszystko zaczęło się dwa lata później. Warto wspomnieć, że nie od początku organizacja posiadała dzisiejszą nazwę - po szczegóły odsyłamy Was do rysu historycznego przygotowanego przez klub. Od samego startu była związana z piłką nożną i do dzisiaj tak jest. Jednak nie każdy wie, że nie posiada wyłącznie jednej, seniorskiej drużyny - Lech Poznań to także sekcja kobieca, rezerwy, juniorzy starsi i młodsi oraz trampkarze. To także prężnie działająca akademia, która jest znana z wyszukiwania i przyjmowania młodych talentów, stanowiących potem o sile nie tylko poznańskiego klubu, ale także zagranicznych zespołów czy reprezentacji. Wreszcie, to zespół, który w latach 2008-2010 był domem dla niejakiego Roberta Lewandowskiego, wówczas piłkarza wchodzącego do poważnej piłki, a dzisiaj gwiazdy światowego futbolu i jednego z bardziej znanych Polaków na naszym globie. Nie zawsze jednak Lech był skupiony tylko na "kopanej" - swoje miejsce w historii organizacji miały lub nadal mają m.in. koszykówka (11-krotny mistrz polskiej ligi), boks, kajakarstwo, szachy czy piłka ręczna.

Oczywiście, jak każdy duży klub, Lech Poznań posiada nie tylko sztab, zespół i cały pion sportowy, ale również działy, które zapewniają organizacji funkcjonowanie w najróżniejszy sposób. To są dziesiątki, a nawet setki osób, które odpowiadają za zarządzanie, marketing, obsługę sklepu klubowego, bezpieczeństwo, public relations i wszystko inne, o czym zwykle kibic dopingujący drużynę nie myśli na co dzień, ale z tego korzysta i potrzebuje. Bez nich Lech Poznań nie byłby Lechem Poznań, tylko "po prostu" drużyną piłkarską.

I tutaj dochodzimy do Działu Marketingu Produktowego, który jest naszym bezpośrednim zleceniodawcą. W przypadku dużych organizacji nie jest bowiem tak, że firmy współpracują bezpośrednio z zarządem - zazwyczaj odbywa się to na poziomie działów, które mają pewną autonomię. Nie oznacza to też, że kwestie IT dotyczą tylko i wyłącznie marketingu produktowego, ale o tym zaraz napiszemy.

Na czym polega opieka IT w Lechu Poznań?

Przede wszystkim należy zaznaczyć, iż Wilda Software nie jest jedyną firmą z obszaru IT, która współpracuje z Lechem Poznań. Jesteśmy jednym z kilku lub kilkunastu partnerów, z których każdy zajmuje się obsługą innego rodzaju potrzeb informatycznych. Osobny podmiot zajmuje się sklepem internetowym, jeszcze inny sprzedażą biletów. Są też firmy opiekujące się wewnętrzną infrastrukturą Lecha (np. sprzętem), aplikacją mobilną, serwerem itd. A gdzie w tym wszystkim mieścimy się my?

Naszej pracy nie zobaczycie wchodząc na stadion czy kupując bilet na mecz, ale jest duża szansa, że zobaczycie ją, gdy dowiadujecie się czegoś o Lechu. Serwisujemy bowiem stronę WWW klubu, a więc lechpoznan.pl. Mamy przyjemność robić to od marca 2021 roku, kiedy przejęliśmy ten projekt od innego wykonawcy - tak, to przykład oprogramowania, którego nie tworzyliśmy od podstaw, natomiast wprowadzamy zmiany, które klub potrzebuje na bieżąco oraz sprawiamy, iż witryna cały czas działa. Obejmuje to:

  • frontend, czyli aplikację, którą widzą odwiedzający,
  • CMS (panel administracyjny), czyli miejsce, w którym obsługa Lecha wprowadza treść,
  • API dla zewnętrznych aplikacji,
  • integrację z zewnętrznymi systemami (takimi jak np. Lechici),
  • kontakt z administracją zajmującą się serwerem.

Z racji tego, iż strona działa od dawna, przejmując ją zrobiliśmy to z całym "dobrodziejstwem inwentarza", a więc technologią i architekturą, w której była napisana. Jednak ślady naszej obecności jak najbardziej są widoczne - widać je choćby w ankietach, które Lech czasem ogłasza i udostępnia, poprawkach w formularzach, na ekranie meczowym, w kwestiach dotyczących SEO, ciasteczkach, stronach związanych ze sponsorami czy technicznej realizacji specjalnej odsłony serwisu na 100-lecie klubu. Wiele rzeczy działo się też za kuluarami, czego bezpośrednio użytkownicy nie mogą zobaczyć, ale za to mogą poczuć.

Wyzwania przy pracy z taką stroną WWW

Strona Lecha Poznań jest specyficzna. To przede wszystkim witryna informacyjna, przeznaczona dla szerokiego grona odbiorców, w przeważającej części dostępna bez logowania i która musi radzić sobie z dużym ruchem. Szczególnie jest to widoczne podczas meczów, kiedy serwis ze zwykłego wyglądu przechodzi do tzw. ekranu meczowego, aktualizowanego na bieżąco pod wpływem wydarzeń na boisku. Jest to też strona, w której pozycjonowanie i wszystkie działania związane z SEO są bardzo istotne, gdyż, jak każdy klub sportowy, Lech musi być ciągle obecny w sieci i znajdować się wysoko w wynikach wyszukiwania. Oczywiście, same decyzje dotyczące optymalizacji SEO należą do specjalistów od marketingu, jednak muszą za tym podążać prace techniczne, już należące do nas.

To sprawia, że ten serwis w projektowaniu jest diametralnie inny niż choćby ComMan. Funkcje serwisu zazwyczaj nie są bardzo skomplikowane z architektonicznego punktu widzenia (choć były wyjątki), natomiast tutaj jeszcze "bardziej" niedopuszczalne jest, aby ich wprowadzanie lub modyfikacja psuły wydajność czy pozycjonowanie. Dodatkowo, w przypadku strony Lecha wyraźnie widać większe nastawienie na wersję mobilną - idąc ramię w ramię z generalnymi trendami w Internecie, witryna często przeglądana jest w biegu, na komórce, kiedy fani czy dziennikarze chcą sprawdzić wynik lub spodziewają się ważnego newsa. A właśnie.

Kolejną kwestią, którą trzeba uwzględnić przy planowaniu takiej strony, jest przepustowość i to jedna z rzeczy, przy której zachodzi konieczność współpracy z administratorami. Strona musi być przygotowana na mocne, chwilowe "piki" powstałe w momencie nadejścia meczu czy pojawienia się znaczącej wiadomości. Także ankiety czy jakieś zdarzenie poza stroną związane z Lechem może wygenerować bardzo duży ruch, zarówno prawdziwych użytkowników, jak i botów. Na całe szczęście, wykonawcy, od których przejmowaliśmy oprogramowanie, zadbali także o to i system zawiera bardzo silny mechanizm cache'ujący oraz zabiegi optymalizacyjne, niekiedy kosztem zmian niewidocznych od razu po wprowadzeniu. Tutaj wyzwaniem było poznanie tych wszystkich "sztuczek" przy wprowadzaniu się do obsługi serwisów, co jest chyba najtrudniejszą rzeczą przy przejmowaniu tego typu zleceń.

W kwestiach pozatechnicznych należy przypomnieć, że to strona kierowana do szerokiego grona odbiorców, a także posiada miejsca dla sponsorów klubu. To oznacza, że wszelkie niedokładności graficzne są punktowane przez użytkowników dużo bardziej niż w innych serwisach, a kwestie ważne z biznesowego punktu widzenia organizacji są monitorowane przez więcej niż jedną stronę. Taki jest wymóg tej współpracy, która - co trzeba podkreślić - zachodzi w bardzo dobrej, wręcz przyjacielskiej atmosferze. Warto zwrócić uwagę, że firmy, które są wybierane do utrzymywania stron popularnych klubów sportowych czy innych tego typu organizacji, muszą być przygotowane na niekiedy szybsze reagowanie niż tylko w godzinach 8-16 od poniedziałku do piątku - wyjątki nie są częste i tutaj też z Lechem jesteśmy odpowiednio "dogadani", natomiast bywają sytuacje, w których dzieje się coś złego i potrzebne jest działanie lub przynajmniej konsultacja wieczorami lub w weekend, kiedy trwa mecz. Jednak większość prac zachodzi w standardowym, "dłuższym" trybie.

Co zyskuje Lech Poznań na współpracy?

Zastanówmy się przez chwilę, co tak naprawdę taki klub jak Lech Poznań zyskuje przy współpracy z takimi partnerami, jak my. Przede wszystkim, jest to spokój i to warto podkreślić, nawet kilka razy. Czy strona WWW mogłaby funkcjonować bez firmy IT? Oczywiście, mogłaby - pewne drobne zmiany klient byłby w stanie sam przeprowadzić i nawet czasem to robi. Natomiast naturalnie takie serwisy są rozbudowywane o różne funkcje, niekiedy widoczne dla masowego odbiorcy, a czasem przeznaczone wyłącznie dla pracowników organizacji. Zwykle nie są to zmiany, których wprowadzenie trwa parę minut lub godzinę, tylko modyfikacje, które ingerują zarówno we frontend, jak i logikę działania aplikacji, a czasem też w samą bazę danych. Software house bierze na siebie odpowiedzialność za tego typu działania, gdyż zwyczajnie z tego żyje i na tym się zna. W zamian daje pewność klientowi, że strona jest zaopiekowana.

Drugi ważny czynnik to gotowość do konsultacji. Tak, jak można przeczytać w naszej ofercie, nie tylko tworzymy i rozwijamy oprogramowanie, ale też analizujemy różne możliwości oraz konsultujemy je, korzystając z teoretycznej i praktycznej wiedzy, którą posiadamy i rozszerzamy przez lata. Brzmi to jak fragment ulotki promocyjnej, ale fakt jest taki, że często (prawdopodobnie częściej, niż myślicie wy i młodzi programiści wchodzący do zawodu) naszą rolą jest wskazanie drogi lub przedstawienie rozwiązań. I nie mówimy tutaj tylko o Lechu, ale właściwie każdym projekcie, którym się zajmujemy. Wracając jednak do poznańskiego klubu, to ponownie w pewien sposób chodzi tutaj o spokój - klub może wyznaczać cele rozwoju strony WWW (mając dane analityczne), ale nie musi się zastanawiać, jakie są opcje dojścia do tych celów, gdyż od tego jesteśmy my. Czasem oznacza to odradzenie czegoś lub rzucenie bardziej negatywnego światła na sprawę, ale cóż - tak jest też nasza rola.

Czego można nauczyć się podczas takiej współpracy?

Innego podejścia do kwestii technicznych

Tak, jak już kilka razy wspomnieliśmy, oprogramowanie zostało przejęte od innej firmy, co naturalnie oznacza, iż musieliśmy je poznać, gdyż zastosowane techniki znacząco różnią się od tych, które sami stosujemy konstruując serwisy od nowa. Tym niemniej, nie tylko było to spodziewane, ale też konstruktywne. Oczywiście, są fragmenty, które pewnie najlepiej byłoby przepisać od nowa, ale istnieją też całe moduły, których analiza sprawiła nam dziką przyjemność i pozwoliła się czegoś nauczyć. Generalnie, każde oprogramowanie i kod ujrzany w innych aplikacjach kształci programistów i pokazuje nowe rzeczy, natomiast obcowanie ze stroną Lecha Poznań jest pod tym względem wyjątkowe z uwagi na fakt, w jakich warunkach ten serwis "pracuje" (liczba odwiedzających).

Przejęcie takiego kodu uczy jeszcze jednej rzeczy - pokory. Nie wszystko, co na pierwszy rzut oka wydaje się napisane źle, faktycznie takie jest. Czasami ma swoje uzasadnienie i zalety, które ujawniają się dopiero w odpowiednim miejscu i w odpowiednim czasie. A wszystko stanowi cenną lekcję architektoniczną.

Konsultacji i integracji z wieloma podmiotami

Pisaliśmy też o tym, że wokół Lecha Poznań orbituje dużo firm IT, zajmujących się różnymi elementami infrastruktury oraz ekosystemu. Siłą rzeczy te elementy muszą ze sobą współpracować, co oznacza szerokie korzystanie z nawzajem napisanych API, ale także niekiedy długie wątki mailowe mające na celu wyjaśnić poszczególne kwestie. Są to w dodatku firmy o różnej strukturze, wielkości i przyzwyczajeniach, co objawia się w sposobie komunikacji i czasami wykorzystywania specjalnych systemów do osiągnięcia porozumienia. Tutaj wielkie brawa dla osób ze strony Lecha, którzy koordynują taką komunikację i panują nad tym, aby odpowiednie strony mogły ustalić wspólne stanowisko.

Musimy też pamiętać, iż wszelkie zmiany np. w API, nawet te drobne, mogą być zauważalne dla systemów korzystających z nich - to wymaga uwagi i myślenia szerzej niż tylko o modyfikacji, którą się przeprowadza. Zwłaszcza, jeśli chodzi o fragment oprogramowania niepisany oryginalnie przez nas, który musimy najpierw przeanalizować, a dopiero później zaplanować działania.

Wreszcie, wspominałem już wcześniej o sponsorach, którzy wymagają trochę więcej uwagi i tworzenia dedykowanych stron pod siebie lub umieszczenia odpowiedniej treści dostarczonej przez nich. Problem w tym, że przybierają one różną formę i nie zawsze są tak proste do zaimplementowania, jak na początku się to wydaje, co oznacza komunikację pomiędzy działami IT. Tym niemniej, każde takie doświadczenie czegoś uczy i pozwala nie tylko rozwijać stronę zgodnie z potrzebami klienta, ale także poznać różne style działania.

Dbałości o szczegóły

Często odwiedzane strony muszą się ładnie prezentować. A często odwiedzane strony dla miłośników danej marki i to takich, którzy gotowi byliby pójść za tym w ogień, oznacza przyłożenie jeszcze większej uwagi. Wiedzą pracownicy Działu Marketingu Produktowego, a siłą rzeczy również my, jak istotne jest to, aby np. w tle strony były dokładnie takie, a nie inne paski, a na urządzeniu mobilnym kolejne odpowiedzi w pytaniu ankietowym pokazywały się w konkretnej formie. Pamiętajmy, że w takim przypadku użytkownicy wytkną każdy feler i to już nie jest kwestia kilku osób, które wewnętrznie używają systemu, tylko czegoś, co jest widoczne publicznie dla wielu tysięcy fanów. Z tego płynie inna, bardziej ogólna nauczka, widoczna jeszcze bardziej w aplikacjach mobilnych - odbiorcy chętniej komentują złe rzeczy niż te dobre, gdyż te drugie są uznawane za standard. Niekoniecznie przekłada się to na ogólną średnią ocen - to osoby najbardziej rozżalone mają najwięcej do powiedzenia i są najbardziej widoczne, mimo że obok znajduje się kolejnych paru odbiorców, którzy z miejsca dali 5 gwiazdek.

Jeszcze trudniej jest w sytuacjach ze sponsorami, kiedy wszystko musi być dopięte na ostatni guzik i w grę wchodzą, oczywiście, pieniądze. Wcześniej już wspominaliśmy o tym, iż w takich przypadkach margines błędu jest jeszcze mniejszy i konieczna jest większa kontrola takiej pracy.

Organizacji pracy z klientem

Mamy to szczęście, że osoby, z którymi mamy kontakt ze strony Lecha (pozdrowienia dla Was), są przykładami klientów, z którymi nie tylko dobrze się pracuje, ale też którzy potrafią co nieco sami poprawić i z tego faktu korzystają. Jest to dobre i na pewno satysfakcjonujące, natomiast wymaga uzgodnień dotyczących zarządzania kodem. Należy bowiem panować nad sytuacjami, w których pewne zmiany dzieją się bezpośrednio na serwerze (z racji konieczności szybkiej reakcji), a później muszą zostać wytransferowane do repozytorium.

W górę serca!

Nie ukrywamy - pracowanie przy tak dużej i znanej stronie jak lechpoznan.pl jest bardzo satysfakcjonujące i pozwala poczuć się częścią czegoś dużego. Smaku dodaje fakt, że co najmniej kilku pracowników Wilda Software to wielcy fani tego klubu, więc możliwość zajrzenia "za kulisy" to również dla nich nie lada gratka. Jesteśmy też wdzięczni za zaufanie, którym obdarza nas Lech Poznań i mamy nadzieję, że ta współpraca będzie trwała jak najdłużej. Powodzenia we wszystkich rozgrywkach!

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Design System - co to jest i jak pomaga? https://wildasoftware.pl/post/design-system-co-to-jest-jak-pomaga?ref=rss https://wildasoftware.pl/post/design-system-co-to-jest-jak-pomaga?ref=rss Thu, 21 Mar 2024 17:30:00 +0000 Witaj drogi czytelniku,

Jeśli jesteś, jak większość z nas, obecny w świecie oprogramowania, prawdopodobnie napotykasz wiele wyzwań związanych z utrzymaniem spójności, skalowaniem projektów i zapewnieniem, że Twoje produkty są zarówno atrakcyjne wizualnie, jak i funkcjonalne. Design Systemy mogą być odpowiedzią na Twoje zagwozdki.

Dla zobrazowania przytoczmy oto taki przykład: Adam, programista w firmie zajmującej się tworzeniem aplikacji mobilnych, był bardzo zajęty, próbując dodać nowy moduł do istniejącej aplikacji fitnessowej. Jego biurko było zatłoczone kubkami po kawie, kartkami z notatkami i pustymi opakowaniami po zupkach chińskich. "To musi być gotowe do końca tygodnia" - powiedział mu product owner. Problem zaczął się, kiedy Adam zauważył, że projekt interfejsu użytkownika, nad którym pracował, był dość chaotyczny. "Kurcze, ten przycisk wygląda zupełnie inaczej niż ten na poprzedniej stronie". Zaczęły się pojawiać pytania: "Czy to jest w porządku? Czy to naprawdę powinno tak wyglądać?".

Wtedy Adam przypomniał sobie o systemie, który zawierał spójne wzorce komponentów interfejsu użytkownika. Z pomocą takie zestawu nie musiałby już przejmować się tworzeniem nowych elementów od podstaw. Mógłby skorzystać z gotowych komponentów, co pozwoliłoby mu skupić się na implementacji nowych funkcji, zamiast na projektowaniu interfejsu. Adam zaczął przeglądać dostępne komponenty w Design Systemie i znalazł to, czego potrzebował - od przycisków i pól tekstowych po menu nawigacyjne i karty produktów. "To jest to!" - pomyślał z ulgą. Zamiast tracić czas na tworzenie kolejnych elementów od zera, mógł skorzystać z przygotowanych wcześniej rozwiązań. Adam nie musiał już przejmować się niepotrzebnymi detalami projektowania interfejsu, nie musiał zadawać pytań product ownerowi lub w dalszej kolejności dopytywać o szczegóły klienta, jak dokładnie to miałoby wyglądać - wszystko było już zaplanowane i udokumentowane.

Czym są Design Systemy i kiedy je tworzymy?

Na początek, co to jest ten tajemniczy "Design System"? To tak jakbyś miał magiczną księgę z instrukcjami dotyczącymi tego, jak budować swoje aplikacje - od kolorów i typografii po interakcje i komponenty. To zestaw zasad, wytycznych i komponentów, które pomagają w utrzymaniu spójności przy tworzeniu produktu. Design Systemy mogą być przygotowywane na różnych etapach procesu projektowego, ale zazwyczaj są tworzone na początku lub w trakcie kreślenia pierwszych prototypów aplikacji lub produktu. W mniejszych zespołach projektowych osobą odpowiedzialną będzie UX/UI designer. W takim przypadku Design System jest często tworzony równolegle z projektowaniem ekranów czy mechanizmów. Niektóre firmy decydują się również na współpracę z zewnętrznymi agencjami projektowymi lub konsultantami, którzy posiadają specjalistyczną wiedzę i doświadczenie w tworzeniu Design Systemów. To podejście może przyspieszyć proces przygotowania takiego zestawu i zapewnić dostęp do najlepszych praktyk i innowacyjnych rozwiązań w dziedzinie projektowania interfejsu użytkownika.

W czym pomagają Design Systemy?

Design Systemy zapewniają jednolity wygląd i zachowanie interfejsu użytkownika, co jest kluczowe dla budowania zaufania użytkowników. Kiedy przyzwyczajamy się, że po kliknięciu zielonego zaokrąglonego przycisku z cieniem akceptujemy pewną czynność, to oczekujemy tego samego zachowania, gdy ten przycisk pojawi się w innym miejscu. Powiedzmy, że dwa różne przyciski wykonują tą samą akcję - potrafi być to mylące dla użytkowników. I tutaj pomaga Design System.

Kiedy użytkownicy są zaznajomieni z interfejsem i wiedzą, czego się spodziewać, są mniej podatni na frustrację i dezorientację. Spójny interfejs eliminuje niepotrzebne zaskoczenia i niejednoznaczności, które mogą prowadzić do stresu i niepewności. Użytkownicy mogą skupić się na celu i wykonywaniu zadań, bez obaw o to, czy zrozumieją i jak poradzą sobie z interfejsem bez konieczności nauki nowych wzorców i zachowań co, przekłada się na zwiększoną produktywność i efektywność w korzystaniu z aplikacji. Kiedy można łatwiej przewidzieć, jak będą zachowywać się różne elementy interfejsu w różnych sytuacjach, sprawia to, że interakcja z aplikacją jest bardziej intuicyjna i przyjemna. To wszystko przekłada się na korzyści biznesowe, ponieważ spójność w interfejsie użytkownika buduje zaufanie użytkowników do marki i aplikacji, co prowadzi do większej lojalności i powtarzalności korzystania z niej. A gdy użytkownik jest zadowolony to jest bardziej skłonny do dokonywania zakupów lub korzystania z płatnych usług. Dodatkowo, zmniejszenie ryzyka pomyłek i nieporozumień prowadzi do zmniejszenia liczby pytań i problemów zgłaszanych przez użytkowników, a to w rezultacie do zredukowania kosztów obsługi klienta :)

W miarę rozwoju projektu, jego złożoność również rośnie. Design Systemy pozwalają na efektywne skalowanie projektu poprzez ponowne wykorzystanie gotowych komponentów, co przyspiesza proces tworzenia nowych funkcji i ułatwia zarządzanie zmianami. Ponadto, zespoły projektowe mogą skupić się na istotnych aspektach projektu, zamiast tracić czas na powtarzające się decyzje. Kiedyś usłyszałam jak ktoś powiedział coś bardzo trafnego - Design Systemy to inaczej reużywalny kod. Oznacza to mniej czasu poświęconego na projektowanie od zera i możliwość przeznaczenia większej ilości czasu na innowacje oraz eksperymenty.

Design Systemy służą również jako narzędzie do współpracy i komunikacji między różnymi zespołami projektowymi, w tym projektantami, programistami, testerami i interesariuszami. Dzięki jednemu źródłu prawdy o projekcie, wszyscy są na bieżąco z aktualnym stanem przedsięwzięcia. To jak katalog, który przyciąga wszystkie fragmenty projektu i układa je w spójną całość. Wyobraźmy sobie: masz jedną wielką tablicę informacyjną, na której każdy z zespołu ma swój kawałek. Można po prostu spojrzeć na tę tablicę i zobaczyć pełny obraz projektu. Design systemy nie są tylko zbiorem kodu określającym wygląd elementów na stronie - są one również oparte na jasnych wytycznych i fragmentach dokumentacji, które precyzyjnie określają, jak mają być używane poszczególne komponenty, jakie są ich założenia i jak się zachowują w różnych sytuacjach. Dzięki temu, gdy jeden członek zespołu tworzy lub modyfikuje komponent, inni automatycznie wiedzą, co to za zmiany oraz jakie są ich konsekwencje. To jak w mechanizmie z dobrze naoliwionymi trybikami - każdy element wpasowuje się idealnie w całość, bez szwanku. Taka synergia sprawia, że ​​praca zespołowa może stać się łatwiejsza i bardziej efektywna.

Jak tworzymy Design Systemy?

Pierwszy krok w tworzeniu Design Systemu to znalezienie swojego Superbohatera - nie, nie Batmana ani Supermana, chociaż mogą być inspiracją :) Chodzi o wybór technologii i narzędzi, które najlepiej odpowiadają Twoim potrzebom. Czy to będzie Sketch, Figma, czy może coś innego, to zależy od Ciebie i Twojego zespołu.

Każdy dobry Design System ma swoją opowieść - nie musi być to epicka saga, ale powinna być klarowna i zrozumiała dla wszystkich zainteresowanych. Opowiedz historię o tym, dlaczego tworzysz ten system, jak ma pomóc w pracy zespołu i jakie cele ma osiągnąć.

Od przycisków po karty, od ikon po formularze - wszystko ma swoje miejsce w Design Systemie. Upewnij się, że tworzysz komponenty elastyczne jak plastelina - mogą się rozciągać, kurczyć i dostosowywać do różnych potrzeb. Wybierz swoją paletę kolorów mądrze - chcesz, aby twoje aplikacje były zarówno atrakcyjne wizualnie, jak i dostępne dla wszystkich. I nie zapominaj o typografii - czytasz to właśnie teraz chętniej dzięki odpowiednio dobranej czcionce. No, przynajmniej miejmy nadzieję, że w tym roku zostanie lepiej dobrana.

Testuj swoje komponenty, eksperymentuj z różnymi rozwiązaniami i zbieraj opinie od swojego zespołu. Pamiętaj, że nawet najmądrzejsi uczniowie Jedi potrzebują czasem wsparcia :)

Tworzenie nowego Design Systemu vs. korzystanie z istniejącego

Decyzja, czy stworzyć nowy Design System od podstaw czy skorzystać z istniejącego, zależy od indywidualnych potrzeb projektu oraz dostępności odpowiednich rozwiązań na rynku. Tworzenie własnego Design Systemu to jak przygotowanie własnego dania – masz pełną kontrolę nad wszystkimi składnikami, ale czasami lepiej jest po prostu zamówić coś z menu i zaoszczędzić sobie wysiłku przy gotowaniu. Własny Design System daje większą kontrolę nad funkcjonalnością i dostosowanie do konkretnych potrzeb projektowych, jednak może być czasochłonne i wymagać znacznych zasobów. Z drugiej strony, korzystanie z istniejącego Design Systemu może zaoszczędzić czas i wysiłek, ale może nie spełnić wszystkich wymagań projektowych.

Moment użycia Design Systemu

Jeśli chodzi o moment, kiedy należy używać Design Systemu w procesie projektowania, istnieją dwa podejścia: przed prototypowaniem lub dopiero po nim.

Użycie przed prototypowaniem

Argument za tworzeniem Design Systemu przed prototypowaniem opiera się na konieczności zapewnienia spójności wizualnej i funkcjonalnej od samego początku projektu. Dzięki temu projektantom i deweloperom jest umożliwione korzystanie z ustalonych wzorców i komponentów od pierwszych kroków tworzenia interfejsu użytkownika. To jak planowanie wyprawy – lepiej wiedzieć, dokąd zmierzasz, zanim wsiądziesz do samochodu i ruszysz w drogę.

Użycie po prototypowaniu

Z drugiej strony projektowanie interfejsów użytkownika wymaga eksperymentowania z różnymi rozwiązaniami, a tworzenie Design Systemu przed prototypowaniem może ograniczać kreatywność i innowacyjność. Dopiero po przetestowaniu różnych pomysłów i znalezieniu tych, które najlepiej spełniają potrzeby użytkowników, można przejść do definiowania spójnych wzorców i komponentów w ramach Design Systemu.

Ostatecznie decyzja, czy tworzyć system przed czy po prototypowaniu, powinna być podejmowana indywidualnie dla każdego projektu, uwzględniając jego specyfikę i wymagania. W końcu, życie bez trochę spontaniczności i decyzji na żywioł byłoby nudne, prawda?

Najbardziej popularne Design Systemy

Kiedy myślimy o systemach projektowych, niektóre nazwy od razu przychodzą nam na myśl. Są to te, które przyczyniły się do kształtowania naszych doświadczeń użytkownika w internecie i poza nim. Oto lista najbardziej popularnych design systemów, które wyznaczają standardy w świecie projektowania interfejsu użytkownika:

  • Material Design (Google) - oferuje spójny zestaw zasad projektowania dla aplikacji na różnych platformach, w tym na system Android.
  • Bootstrap - Bootstrap to jeden z najbardziej popularnych frameworków CSS do budowania responsywnych i mobilnych stron internetowych. Zawiera wiele gotowych komponentów, które można łatwo dostosować do własnych potrzeb, co sprawia, że jest to idealne narzędzie dla projektantów i programistów.
  • Ant Design (Alibaba) - kompleksowy system projektowy, który oferuje gotowe komponenty i wzorce projektowe dla aplikacji internetowych. Znany ze swojej prostoty i elastyczności, Ant Design jest popularnym wyborem wśród deweloperów na całym świecie.
  • IBM Design Language - znany z minimalistycznego podejścia i eleganckiego designu, IBM Design Language jest często używany w aplikacjach biznesowych i korporacyjnych.
  • Apple Human Interface Guidelines (HIG) - zbiór wytycznych i zasad projektowych opracowany przez Apple, który ma na celu zapewnienie spójnego i intuicyjnego użytkowania aplikacji na urządzeniach firmy, takich jak iPhone, iPad i Mac. Znany z prostoty i elegancji, HIG jest inspiracją dla wielu innych systemów projektowych.
  • Fluent Design System (Microsoft) - oferuje spójne i atrakcyjne wzorce projektowe dla aplikacji na platformach firmy, takich jak Windows, Xbox i Surface. Znany z głębi, cienia i ruchu, Fluent Design System jest często wybierany przez projektantów aplikacji na platformy Microsoft.
  • Polaris (Shopify) - Polaris to system projektowy stworzony przez Shopify, który oferuje kompleksowy zestaw zasad i komponentów dla aplikacji internetowych i mobilnych. Znany ze swojej elastyczności i prostoty, Polaris jest popularnym wyborem wśród sprzedawców internetowych i deweloperów na całym świecie.
  • Foundations - to zestaw zasad i wytycznych projektowych opracowany przez ZURB, który oferuje gotowe komponenty i wzorce projektowe dla aplikacji internetowych i mobilnych.

Oprócz wymienionych powyżej istnieje jeszcze mnóstwo innych, które mają wpływ na nasze codzienne doświadczenia online. Jednakże nie będę wymieniać ich wszystkich, gdyż czytalibyście ten artykuł przez kolejne dni.

Przydatne artykuły

Podsumowanie

Jeśli chcesz, żeby współpraca pomiędzy zespołem frontendowym oraz UX/UI designerami działała jak dobrze naoliwiona maszyna, a nie jak grupka uczniów próbujących zrozumieć zadanie domowe, to Design Systemy są kluczem do sukcesu. Stanowią przenośny zestaw narzędzi dla każdego, kto dąży do spójności i efektywności w projektowaniu interfejsów użytkownika. Porównując proces wytwarzania oprogramowania do gry w puzzle, każda osoba ma swoje unikalne zadanie do wykonania i one wszystkie składają się na jeden obraz. Projektanci odpowiadają za projektowanie interfejsu użytkownika, programiści za implementację kodu, a testerzy za weryfikację poprawności działania aplikacji. Design System działa jak tablica ogłoszeń w klasie, gdzie wszyscy członkowie zespołu mogą zobaczyć pełny obraz projektu, zamiast szukać zagubionych kartek z notatkami. Efektywność pracy jest zwiększona, gdy programiści mogą szybko odnaleźć i wykorzystać gotowe komponenty interfejsu, a testerzy mają dostęp do szczegółowych wytycznych, ułatwiając im tworzenie przypadków testowych i weryfikację poprawności działania interfejsu. Dzięki jednemu źródłu prawdy wszyscy członkowie zespołu mogą pracować na tej samej wersji projektu, co minimalizuje ryzyko powstawania niezgodności i nieporozumień.

]]> Podstawowe pojęcia architektury oprogramowania https://wildasoftware.pl/post/podstawowe-pojecia-architektury-oprogramowania?ref=rss https://wildasoftware.pl/post/podstawowe-pojecia-architektury-oprogramowania?ref=rss Wed, 06 Mar 2024 17:30:00 +0000 Programistą można zostać na wiele sposobów - większość zaczyna w domowym zaciszu, ucząc się danego języka lub technologii, ciesząc się tym i po prostu starając się doprowadzić swoje pomysły do realizacji. Podczas tego procesu człowiek poznaje kolejne konstrukcje językowe, coraz bardziej złożone zagadnienia i możliwości oferowane przez daną technologię, które przekładają się na lepsze i szybsze "osiągnięcia" w danej dziedzinie. To ważne. Natomiast bez odpowiedniego mentora lub możliwości pracy zawodowej czasami zapomina się o innej rzeczy, a mianowicie architekturze oprogramowania i efektywnej konstrukcji systemów IT.

Nie zrozumcie mnie źle - te zagadnienia również są często omawiane w tutorialach. Natomiast dzieje się to często przy okazji, gdyż są po prostu potrzebne do wykonania poszczególnych ćwiczeń (w przeciwieństwie np. do standardu kodowania, który niezbędny na tym poziomie nie jest). W zależności od jakości tego tłumaczenia, mróżne wzorce ogą być bardziej przyswajane przez studenta lub pomijane, gdy nie zostanie zasygnalizowane, że właśnie została przedstawiona koncepcja ważna nie tylko z punktu widzenia danej technologii, ale ogólnie sposobu projektowania jakiegokolwiek oprogramowania i dalszego rozwoju programisty. Tego typu zagadnienia są potem omawiane na studiach lub podczas kursów i zdarza się, że w umyśle studenta pojawia się myśl "hej, znam to".

I mimo że architektura oprogramowania to znacznie szersze pojęcie, a sposoby organizacji poszczególnych komponentów systemów IT są dzisiaj bardziej złożone, to aby je zrozumieć, warto cofnąć się do podstaw. I właśnie o takich fundamentalnych pojęciach architektonicznych dzisiaj porozmawiamy z myślą o osobach, które dopiero wchodzą w ten świat na poważnie, a wcześniej nie miały okazji np. samodzielnie zaprojektować żadnego oprogramowania. Co, oczywiście, nie jest żadnym wstydem, gdyż czasem robi to ktoś za nas lub framework sam narzuca pewien sposób myślenia. Tylko czy w tym przypadku wiemy dokładnie, dlaczego robimy to tak, jak robimy?

Architektura klient-serwer

Cóż, starsi stażem programiści po tym rozdziale zorientują się, że naprawdę będziemy wyjaśniać same podstawy. Zachęcam ich nie do porzucenia lektury, ale wręcz czegoś przeciwnego - przygotowania sobie herbaty, przeczytania dalszej części tekstu i zaproponowania w komentarzach innych fundamentalnych pojęć z zakresu architektury oprogramowania, które ich zdaniem powinien znać adept programowania.

Wyobraźmy sobie sytuację, w której korzystamy z aplikacji webowej służącej do komunikowania się z innymi użytkownikami - może być to serwis społecznościowy, komunikator internetowy czy nawet system komentarzy pod artykułami. Jedna osoba pisze wiadomość, którą może odczytać inny konkretny użytkownik lub wszyscy, a także na nią odpisać. Oczywiście, to nie jest tak, że informacja jest przesyłana bezpośrednio do przeglądarki innych użytkowników. Podobnie jak nawet w całkiem realnej poczcie lub firmie kurierskiej, istnieje pośrednik, który koordynuje dane przesyłane pomiędzy odbiorcami. Tym pośrednikiem jest serwer, natomiast odbiorcami - klienty (tak - w tym przypadku "klienty", a nie "klienci", podobnie jak w IT mamy "agenty", a nie "agentów"). Mówimy zatem o architekturze klient-serwer, w której wielu klientów może korzystać z jednego (choć nie zawsze) serwera, pełniącego rolę składowiska danych i synchronizatora komunikacji.

Diagram pokazujący architekturę klient-serwer. Trzy aplikacji klienckie nie łączą się ze sobą bezpośrednio, tylko odnoszą się do jednego centralnego serwera na środku.

Ubierając temat z innej strony, klient to aplikacja, którą użytkownik otwiera u siebie. W przypadku aplikacji webowej służy do tego przeglądarka internetowa, która pobiera pliki strony z serwera (jako maszyny, a nie komponentu) i otwiera użytkownikowi "u siebie", korzystając z zasobów jego komputera. Jeszcze bardziej wyraźne staje się to w aplikacjach desktopowych oraz mobilnych, gdzie następuje instalacja (lub przynajmniej pobranie pliku wykonywalnego) i uruchomienie bezpośrednio w systemie operacyjnym urządzenia. Z kolei serwer jest oprogramowaniem działającym na serwerze i klienci komunikują się z nim poprzez interfejs, taki jak choćby API.

To oznacza, że istnieje jeden wspólny punkt kontaktu różnych użytkowników, ale także to, że najbardziej krytyczne informacje z perspektywy bezpieczeństwa powinny być przechowywane właśnie w aplikacji serwerowej - do plików aplikacji klienckich użytkownicy mają bezpośredni dostęp, a więc teoretycznie mogą modyfikować ich kod, narażającym tym samym system na nieuprawnione działanie. Z drugiej strony, to aplikacje klienckie zazwyczaj są szybsze - jako że są uruchamiane bezpośrednio na maszynach użytkowników, te obliczenia nie obciążają serwera i jeśli tylko jest to możliwe, warto to wykorzystać, nie nadwyrężając komunikacji z aplikacją serwerową. Jest to wykorzystywane np. w grach sieciowych, gdzie synchronizowane przez serwer są tylko krytyczne informacje, a np. szczegóły animacji kart czy broni są kalkulowane już bezpośrednio na komputerze gracza. Jest to rozsądne biorąc pod uwagę, że serwer obsługuje w danym momencie nie tylko nasz mecz, ale tysiące innych, a do tego - szczególnie w dynamicznych rozgrywkach - musi być wydajny i szybko odpowiadać.

Architektura klient-serwer jest tak powszechnie stosowana, że już nikt o niej specjalnie nie mówi, biorąc to rozwiązanie za pewnik. Tym niemniej, warto powiedzieć o przeciwieństwie, które mogą kojarzyć np. użytkownicy tzw. torrentów, a więc peer-to-peer (zapisywane niekiedy jako P2P). Taka architektura oznacza, że każdy komputer w danej sieci (tzw. węzeł) jest jednocześnie klientem i serwerem. Może zatem korzystać z zasobów innych serwerów, ale też sam świadczy zasoby dla reszty. Omija to koncepcję centralnego serwera, podnosząc odporność na awarię sieci, ale z drugiej strony nakładając więcej "obowiązków" na każdego użytkownika. Oba podejścia mają swoje zalety i wady, ale trzeba przyznać, że P2P jest na tyle specyficzny, że w dobie aplikacji webowych i chmur nie jest tak często używany. Zdecydowanie nie powinien być to pierwszy wybór przy projektowaniu "uniwersalnego" oprogramowania wykorzystującego sieć.

Ważna uwaga - podejście klient-serwer to zupełnie coś innego niż master-slave. To drugie odnosi się do sytuacji, gdy pewien węzeł, mający dokonać pewnych obliczeń (rozumianych bardzo ogólnie), dzieli dane i wykorzystuje inne jednostki, z których każda wykonuje część kalkulacji. Krótko mówiąc, jeden serwer synchronizuje pracę innych serwerów, a nie klientów. Trochę jak product owner w zespole programistów.

Frontend i backend

Z pojęciem klient-serwer wiąże się też często przywoływane w artykułach, a nawet na tym blogu pojęcie frontendu oraz backendu. W pewnym uproszczeniu można powiedzieć, że frontend to to, co widzi użytkownik, a backend to to, czego nie widzi.

Frontend generalnie kojarzy się z interfejsem graficznym i kontrolkami. W aplikacjach webowych to właśnie ta część, która jest pobierana przez przeglądarkę użytkownika i która ma za zadanie zaprezentować dane oraz dać możliwość operowania na systemie. Tenże frontend komunikuje się z backendem, który jest częścią systemu odpowiadającą za logikę obliczeniową oraz komunikację z bazą danych. Często więc za frontend uważa się aplikację kliencką, a za backend - aplikację serwerową.

Diagram pokazujący użytkownika, który korzysta z aplikacji frontendowej, która z kolei łączy się z aplikacją backendową przez API.

Natomiast warto wiedzieć, że może istnieć aplikacja w architekturze klient-serwer, w której frontend i backend są zgromadzone w jednym kawałku oprogramowania. Wiele starszych stron (szczególnie powstałych w języku PHP przy udziale osób, które nie poświęciły temu zbyt dużo czasu lub nie miały innej możliwości) jest tzw. monolitami i trudno w nich jednoznacznie wydzielić obie warstwy. Podział na "przód" i "tył" ma na celu nie tylko utworzenie dwóch osobnych aplikacji, ale też oddzielenie od siebie odpowiedzialności oraz lepszy rozwój oprogramowania poprzez przydzielenie do obu fragmentów innych zespołów programistycznych, szczególnie w większych firmach. Nierzadko słyszymy, że ktoś jest frontend developerem, backend developerem lub full stack developerem, łączącym oba światy - wynika to z faktu, że do frontendu i backendu odpowiednie są inne technologie i ktoś, kto lubi tworzyć interfejs, niekoniecznie sprawdzi się po stronie serwerowej oraz vice versa. Obie części wymagają rozwiązywania innych problemów architektonicznych oraz wiążą się z nimi inne wymagania pozafunkcjonalne.

Model View Controller (MVC)

Omawiając tę sekcję zacznijmy od jednej ważnej rzeczy - MVC nie jest architekturą. Jest to wzorzec projektowy (jeden z naprawdę wielu), który może być składnikiem projektu architektonicznego.Powiedzmy sobie, co kryje się pod tym znanym skrótem.

Kod aplikacji można pisać w jednym dużym pliku i często tak zaczynali adepci programowania wiele lat temu. Szybko jednak okazuje się, że nie jest to najefektywniejszy sposób tworzenia oprogramowania. Nie tylko dlatego, że jeden duży zbiór linijek jest trudny w obsłudze i modyfikacjach, ale także dlatego, że na pierwszy rzut oka nie widać, gdzie znajduje się część odpowiedzialna za prezentację interfejsu, gdzie jest logika, gdzie połączenie z bazą danych itd. Gdy oprogramowanie zacznie się rozwijać, coraz trudniej jest zmieniać taki kod i się w nim odnaleźć, zarówno nowej osobie, jak i nawet autorowi. Naprawa jest prosta - rozbić plik na kilka plików, a jeszcze lepiej na kilka "sekcji". Tylko jakie powinny one być?

Diagram pokazujący wzorzec MVC. Użytkownik wysyła żądanie do kontrolera, który następnie odpytuje model o dane. Gdy model prześle dane, są one przesyłane przez kontroler do widoku, który następnie pokazywany jest użytkownikowi.

W 1979 roku Norweg Trygve Reenskaug zaproponował koncepcję, która po małym "rebrandingu" opisuje trzy części oprogramowania:

  • Model (M) - klasy przechowujące logikę aplikacji, manipulujące danymi lub stanowiące encje reprezentujące różne zbiory informacji.
  • View (V) - klasy reprezentujące to, co widzi użytkownik i obsługujące komunikację z nim.
  • Controller (C) - klasy przyjmujące żądanie użytkownika, walidujące je i wywołujące klasy modelu po to, aby zaktualizowały klasy widoku.

Koncepcja prosta, ale pozwaląca w logiczny sposób podzielić kod. W dodatku posiada kilka innych zalet, wśród których można wyróżnić "luźniejsze" klasy, będące bardziej podatne na rozbudowę, a także ulatwiające ponowne użycie kodu, unikając tym samym jego duplikacji. Dodatkowo, zachodzi inna nieoczywista zaleta, która związana jest z tym, w jaki sposób w praktyce powstaje oprogramowanie. Nie ukrywajmy tego, że w danej aplikacji formularze lub kontrolery często są bardzo podobne do siebie i programiści zazwyczaj nie piszą kolejnych tego typu klas od zera, tylko posiłkują się już istniejącymi fragmentami kodu. A łatwiej to robić, kiedy wszystko jest ładnie podzielone na różne pliki.

Jak to bywa z takimi koncepcjami, trochę się nią nacieszono, ale szybko przestano używać klasyki - powstały wersje z dodatkowym prezenterem (który restrukturyzuje dane pomiędzy modelem i widokiem) czy podejście MVVM, gdzie kontroler staje się View-Modelem, który obsługuje bardziej aktualizację danych na widoku zgodnie ze stanem logiki. To podejście jest widoczne np. w Angularze czy WPF (w technologii .NET). Sama warstwa M może zostać podzielona na kilka podrodzajów, gdyż mieszczą się tam formularze (ich logika), logika obliczeniowa, repozytoria (bezpośrednio manipulujące danymi w bazie danych) czy klasy DAO (ang. Data Access Object, przenoszące dane). Dodatkowo, MVC nie jest podejściem, który jest przeznaczone dla całej aplikacji - to oczywiste, że nie mamy jednej klasy modelu, jednego kontrolera i widoku, tylko jest to wiele plików. I to nawet nie w jednym folderze - takich struktur MVC-podobnych może być w oprogramowaniu wiele. O czym jeszcze będziemy dzisiaj rozmawiać.

Architektura trójwarstwa

Koncepcja MVC i architektura trójwarstwowa (ang. three-layer architecture) są czymś innym, ale nie da się ukryć, że można w nich znaleźć podobne pierwiastki. Warstwy, o których mowa, to prezentacja, logika oraz dane, a więc coś, co do złudzenia przypomina części powyżej omówionego wzorca. Jednak istnieją trzy kolosalne różnice.

Diagram pokazujący architekturę trójwarstwową, gdzie na górze jest widok, pobierający dane z warstwy logiki, która następnie pobiera dane z warstwy danych. Obok są pionowo ustawione (obejmujące całą szerokość architektury, a więc łączące się ze wszystkim) rdzeń (core) oraz interfejsy.

Po pierwsze, komunikować się ze sobą mogą tylko dwie sąsiednie warstwy - prezentacja odnosi się do logiki, logika do danych, dane przekazują wartości logice i wreszcie logika prezentacji. Mamy w ten sposób pewien porządek i ograniczony obszar poszukiwań, co pomaga przy debugowaniu.

Po drugie, do tych warstw dokładane "z zewnątrz" mogą być inne, jak warstwa interfejsów czy core, a więc główne wspólne narzędzia wykorzystywane przez cały system. Nie bez powodu mówi się w ogólności o architekturze n-warstwowej, o czym, zresztą, jeszcze zaraz wspomnimy.

Po trzecie, z założenia każda warstwa to osobna aplikacja. A więc widać tutaj miejsce nie tylko na architekturę klient-serwer, ale też oddzielenie od siebie frontendu (warstwa prezentacji) od backendu (reszta). Oczywiście, nic nie stoi na przeszkodzie, aby przygotować przykład, który zawiera w sobie te trzy warstwy, jednak ta koncepcja architektoniczna sięga dużo dalej.

Oczywiście, w takiej czystej formie architektura trójwarstwowa to też już pewna klasyka - liczba warstw zależy od potrzeb i obecnie wyróżnilibyśmy jeszcze warstwę kontrolera, która przyjmuje żądania po stronie backendowej, a wszystko tak naprawdę zależy od aplikacji. Tym niemniej, ten tradycyjny opis pozwala zrozumieć ogólną koncepcję projektowania architektur, nawet w dzisiejszych czasach - starannie odseparowane od siebie części (często programowane przez różne osoby), utrzymanie porządku, możliwość rozbudowy w zależności od potrzeb, a nawet przygotowanie do osobnego skalowania poszczególnych warstw. Wiele frameworków wspiera ten sposób budowania i staje się on naturalny, hołdując zasadzie luźno związanych ze sobą komponentów, ale będących spójnych wewnętrznie. Oczywiście, to zależy od wielu innych czynników - równie dobrze można utworzyć aplikację zgodną z tą koncepcją, która od razu nadaje się do ponownego napisania. Tak samo należy dobierać narzędzia odpowiednie do zadania - nikt nie przygotuje trójwarstwówki (nie mylić z trójpolówką) do prostego skryptu np. usuwającego niedowiązane pliki na dysku. Tym niemniej, opisywane zagadnienie należy do tych fundamentalnych, które ułatwiają zrozumienie innych, bardziej specyficznych konstrukcji.

Architektura modułowa

Powyżej wspomnieliśmy o tym, iż aplikacja wykorzystująca koncepcję MVC nie ma zazwyczaj trzech folderów na poszczególne warstwy, w których znajdują się wszystkie pliki modelu, wszystkie pliki kontrolera itd. Może tak być, jednak nie jest to sposób pisania, który jest zalecany w dzisiejszych czasach. Zamiast tego poleca się podzielić oprogramowanie jeszcze bardziej - na moduły.

Diagram pokazujący architekturę modułową, gdzie widać, iż całe oprogramowanie dzieli się na moduły, z których każdy ma swój układ model-widok-kontroler.

Modułem może być spójny obszar oprogramowania, który zawiera w sobie kontroler, widoki, modele i inne klasy przypisane tej części. Przykładowo, dla sklepu internetowego modułem może być produkt, koszyk, zamówienie czy dostawca. Wówczas, gdy programista chce zmodyfikować część odpowiedzialną za obliczanie wartości zamówienia, prawdopodobnie najszybciej zrobi to szukając modułu zamówienia i dopiero w nim klasy logiki. To zresztą pierwsza i najważniejsza zaleta takiego podejścia - jeszcze bardziej separuje od siebie mniejsze fragmenty oprogramowania, ułatwiając poruszanie się w ich obrębie i ogranicza wpływ zmian w jednym module na inny moduł (choć, oczywiście, to też można spektakularnie zepsuć, jak wszystko zresztą). W wielkim uproszczeniu można powiedzieć, że każdy moduł może zawierać swoje MVC, choć niekoniecznie tak to wygląda w praktyce.

Druga zaleta to jeszcze bardziej widoczny wpływ tego, o czym wspomniałem w poprzedniej sekcji - duża spójność wewnętrzna, mała zewnętrzna, sprawiająca, że odpowiednie moduły stają się trochę osobnymi wysepkami, niewpływającymi na siebie nawzajem, a jednocześnie nadal stanowiące część jednej aplikacji. Koncepcja wysp prowadzi nas zresztą do kolejnej konsekwencji - w momencie, gdy jeden moduł okazuje się ważniejszy lub bardziej obciążony niż inne, można go albo jeszcze bardziej podzielić, albo wynieść do osobnej podaplikacji, co sprawia, że moduły stają się dobrym wstępem do koncepcji mikroserwisów.

Ponownie - w bardzo prostych aplikacjach nie ma sensu dzielenie jej na moduły, gdyż zwykle nie będzie ich wiele lub staną się za bardzo ze sobą związane. Natomiast w dużym oprogramowaniu jest to rzecz niemal obowiązkowa, będąca wstępem do jeszcze większej separacji.

Podsumowanie

Oczywiście, przedstawione koncepcje nie wyczerpują wachlarza podstawowych pojęć związanych z architekturą oprogramowania. Są jednak terminami, które i tak trzeba znać, pracując jako programista, gdyż albo są wykorzystywane bezpośrednio, albo stanowią wstęp do innych, bardziej złożonych struktur. Na pewno znajomość powyżej zaprezentowanych informacji nikomu nie zaszkodzi, a może pomóc i uporządkować umysł młodego programisty, który do tej pory spotykał w artykułach fragmenty niepozwalające ubrać w całość całych pojęć. Jak najbardziej można je jeszcze rozwinąć i każdemu poświęcić osobny artykuł - dajcie znać, czy któreś z zagadnień powinno zostać rozszerzone lub czy czy w artykule nie zabrakło innej "klasyki".

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Co zrobić, gdy nie widać zmian na stronie WWW? https://wildasoftware.pl/post/co-zrobic-nie-widac-zmian-stronie-www?ref=rss https://wildasoftware.pl/post/co-zrobic-nie-widac-zmian-stronie-www?ref=rss Thu, 22 Feb 2024 17:30:00 +0000 Niektórzy znają to uczucie aż za dobrze - istnieje aplikacja webowa, która działa produkcyjnie i jest cały czas rozwijana. Kończy się pewien kolejny etap prac (np. sprint), wszystko zostało przetestowane, wypolerowane i pozostaje tylko wdrożenie na serwer. Ten wiekopomny moment następuje, ktoś jeszcze kontrolnie "przeklikuje" nową wersję, klient jest informowany o przyroście, po czym następnego dnia... software house dostaje informację, że użytkownicy nie widzą zmian lub aplikacja dziwnie się zachowuje.

Wówczas programiści wypowiadają pod nosem klasyczny zwrot "dziwne, u mnie działa" i jeszcze raz sprawdzają sytuację. Wchodzą na serwer, do którego dostęp mają użytkownicy, logują się, wykonują te same akcje i... okazuje się, że widać wszystkie nowe elementy i działają one poprawnie. Zatem ta sama wersja aplikacji na tym samym serwerze działa u jednego użytkownika, a u drugiego nie. Kto w takiej sytuacji ma rację - klient zgłaszający błąd czy programista, który mimo wszelkich prób nie może tego błędu odtworzyć i klnie się na swojego laptopa, że wszystko jest poprawne?

Odpowiedź brzmi: nikt i oboje jednocześnie. Tego typu zachowanie systemu jest frustrujące, gdyż pojawia się tutaj kilka zmiennych - przeglądarka, środowisko (czyli np. znaczenie może mieć to, jakie ciasteczka są zgromadzone w aplikacji), użytkownik, jego uprawnienia itd. Nie da się ukryć, że dużą rolę odgrywa też cache, a więc pamięć podręczna, która w trosce o wydajność aplikacji potrafi zachować stary obraz strony lub jego części. Wówczas rzeczywiście mogą się dziać nieprzewidziane rzeczy w postaci niewidocznych nowych zmian lub wręcz dziwacznych wyników zwracanych przez system IT.

Mimo że nikt jednoznacznie nie ponosi tutaj winy i nie ma racji, to jakoś tę kwestię trzeba rozwiązać lub przynajmniej zbadać. Problem w tym, że jeśli programista nie może odtworzyć kłopotu u siebie, to musi zobaczyć to u klienta, a to bywa czasem utrudnione. W związku z tym, należy mieć procedurę działania, która nie tylko pozwoli rozjaśnić sytuację, ale również zapewnić, iż software house podchodzi do sprawy profesjonalnie.

Ten tekst jest poradnikiem na takie okazje i postaramy się opisać najczęstsze kroki, jakie wówczas powinno się wykonywać. Natomiast najpierw dokładniej wyjaśnijmy, na czym może (choć nie musi) polegać problem. Przypomnijmy, że będziemy obracać się w kręgu aplikacji webowych, choć w przypadku aplikacji desktopowych występują podobne problemy, aczkolwiek tam łatwiej zadbać o logi.

"Halucynacje" aplikacji

Specjalnie wykorzystałem słowo "halucynacje", mimo iż temat nie jest związany ze sztuczną inteligencją, gdzie ten termin opisuje oderwane od rzeczywistości wyniki działania modelu LLM (ang. Large Language Model). Powszechnie ten wyraz oznacza omamy, fałszywe doznania wzrokowe i poniekąd pasuje to do sytuacji, jaką mogą mieć użytkownicy, którym aplikacja nie wczyta się w odpowiedni sposób.

Powód zwykle mieści się w jednym z dwóch obszarów. Pierwszy to wspomniania już pamięć podręczna (cache), która działa jak magazyn przechowujący gotowe, już wcześniej obliczone, wyniki, aby w przyszłości szybciej serwować je użytkownikowi. Wynika to z tego, że nowoczesne systemy IT są dynamiczne i po otwarciu odpowiedniej strony przez użytkownika, oprogramowanie musi "przekalkulować" treść, którą pokaże, w tym np. pobrać informacje z bazy danych, przetworzyć je, a następnie wygenerować odpowiedni kod HTML. To wszystko zajmuje czas, a jeśli do tego uwzględnimy fakt, iż dana strona może być wyświetlana wiele razy i za każdym razem proces wygląda tak samo, to nietrudno dojść do wniosku, że drugie, trzecie i kolejne wywołanie może być szybsze, o ile zachowamy wyniki pośrednie. Tak działa właśnie cache, który może zachodzić na wielu poziomach, jednak w kontekście dzisiejszego tekstu najbardziej interesuje nas przeglądarka użytkownika. Otwarcie strony internetowej to tak naprawdę zlecenie przeglądarce pobrania nie tylko samego kodu HTML, ale też skryptów JavaScript, plików CSS, obrazków itd. W związku z tym przez pewien czas są one cache'owane, aby przy kolejnym wywołaniu użytkownik szybciej zobaczył stronę. Szczególnie dotyczy to plików statycznych, za jakie uważane są pliki JS czy CSS.

Te pierwsze są szczególnie istotne w kontekście naszego problemu, ponieważ nowoczesne frontendy są zazwyczaj (aczkolwiek nie zawsze) pisane przy pomocy frameworków JS, u których plik index.html jest tylko czymś w rodzaju punktu startowego, a całe działanie aplikacji mieści się w zbiorach javascriptowych. W związku z tym podmiana tych zasobów nie zawsze jest od razu rejestrowane przez przeglądarkę i odświeżane, to użytkownik tuż po wdrożeniu nadal może widzieć stare pliki, odnosząc wrażenie, że nic się nie zmieniło.

Drugi najczęstszy powód sytuacji typu "u ciebie działa, a u mnie nie" to uprawnienia użytkownika. Może być tak, iż aplikacja nie została dostatecznie dobrze przetestowana z perspektywy usera o określonej roli lub kombinacja jest na tyle unikalna, że oprogramowanie - mówiąc kolokwialnie - "zgłupiało". Czasem jest to z kolei poprawne zachowanie aplikacji, która odpowiednio dba o uprawnienia, natomiast w przedstawionym przypadku nie jest to klarowne dla klienta. W przeciwieństwie do problemów z cachem, które czasami występują tylko i wyłącznie u konkretnej osoby na jego komputerze, kwestię przywilejów danego użytkownika programiści mogą zbadać zdalnie lub "u siebie".

Pozostaje pytanie, jak zabrać się do rozwiązywania takiej kwestii, jeśli już wystąpi. Jest na to parę sposobów i rad, które kolejno można przekazać klientowi.

Wyczyszczenie cache'a przeglądarki

W momencie, kiedy programista słyszy o tym, iż po wdrożeniu u użytkownika coś niepoprawnie się załadowało, następuje zwykle rada "proszę w twardy sposób odświeżyć stronę". No dobrze, ale co to właściwie oznacza?

Jeśli jako użytkownicy chcemy jeszcze raz załadować stronę na której się znajdujemy, zazwyczaj zaznaczamy adres URL i klikamy ENTER lub - jeszcze szybciej - naciskamy klawisz F5, który w większości przeglądarek jest przypisany do funkcji odświeżenia. To jest coś, co można nazwać "miękką" lub normalną wersją tej operacji - przeładowuje ona tylko stronę, powodując np. pobranie danych na nowo, natomiast statyczne pliki są zazwyczaj nadal przywracane z cache'a. Aby zmusić przeglądarkę do tego, aby te zasoby również zostały pobrane na nowo, należy zamienić pojedynczy klawisz F5 na CTRL + F5 lub CTRL + SHIFT + R, w zależności od preferencji, przeglądarki i systemu operacyjnego (w przypadku macOS zazwyczaj CTRL należy czytać jako CMD, znany też z symbolu ⌘). Listę dostosowaną do każdego środowiska można znaleźć np. w tym artykule.

Tutaj warto wspomnieć jeszcze o jednym fakcie, który zauważyliśmy u naszego klienta, gdzie usilne wciskanie kombinacji CTRL + F5 na Windowsie nie pomagało. Szybko okazało się, że niektóre modele laptopów mają domyślnie zmienione zachowanie klawiszy funkcyjnych (a więc od F1 do F12) i traktują je tak, jakby włączony był klawisz Fn znajdujący się zwykle pomiędzy lewym CTRL i ALT. Jest to przycisk aktywujący alternatywne znaczenie klawiszy, jak np. zwiększenie głośności czy przełączanie ekranu. Jak widać, niektórzy producenci notebooków uznali, iż "drugie" funkcje są ważniejsze niż pierwotne, w wyniku czego zamiast CTRL + F5 należy naciskać CTRL + Fn + F5, aby osiągnąć to, co normalnie byłoby możliwe za pomocą dwóch przycisków. Oczywiście, można to przełączyć systemowo, jednak autor tego artykułu przyznaje, że domyślne ustawianie klawiatury w taki sposób jest jedną z bardziej idiotycznych praktyk, jakie widział w ostatnim czasie.

Wracając do twardego odświeżania, w większości wypadków usuwa to problem. Czasem potrzebne jest kilkukrotne działanie w ten sposób, jednak w końcu powinno to sprawić, iż pliki strony internetowej załadują się na nowo i wówczas okazuje się, iż problemem faktycznie był cache. Na całe szczęście.

Zmiana przeglądarki

Czasem jednak tak się nie dzieje i nadal pojawiają się kłopoty. Wówczas, przed podjęciem innych kroków, warto jeszcze sprawdzić inną przeglądarkę lub przynajmniej tryb incognito, jeśli żadna inna aplikacja tego typu nie jest zainstalowana na komputerze. Pamiętajmy, że cache i lokalne pliki są zapisywane nie dla całego systemu, tylko dla konkretnego programu do wyświetlania stron WWW. Łatwo to zresztą zauważyć - gdy zalogujemy się na nasze konto w serwisie internetowym za pomocą Chrome, to po przejściu do Firefoxa nadal będziemy niezalogowani.

Oczywiście, twarde odświeżenie strony również powinno rozwiązać problem na tej samej przeglądarce, jednak sprawdzić kolejną nie zaszkodzi także z innych powodów. Pierwszy z nich to problemy samej strony internetowej na konkretnym programie. To się zdarza i o ile, oczywiście, nie jest to powód do chwały dla programistów, to jest to wątek, który warto zweryfikować. Druga sprawa to z kolei rozszerzenia, jakie użytkownicy mają zainstalowane w przeglądarce, a które w skrajnych przypadkach mogą utrudniać działanie strony. Do tej grupy zaliczają się też różne unikalne decyzje konfiguracyjne, jak np. ograniczenie ładowania JavaScript.

Wyczyszczenie aplikacji i ciasteczek (ang. cookies)

Zanim przejdziemy dalej, warto sprawdzić jeszcze jedną rzecz. Być może stara i nowa wersja aplikacji w różny sposób przechowują dane w ciasteczkach lub local storage - są to miejsca, do których trafiają różne informacje użytkownika, jak choćby token, z którego korzysta po zalogowaniu się do serwisu czy akceptacja profilowania na stronie. Widywaliśmy w przeszłości przypadki, w których zmiana sposobu gromadzenia takich danych potrafiła doprowadzić do dziwnych sytuacji, kiedy aplikacja nie umiała prawidłowo zinterpretować wartości, które użytkownik już miał w przeglądarce.

Dla pewności można je wyczyścić, przy czym tutaj należy już zapoznać się z czymś, co nazywa się narzędziami deweloperskimi (ang. Developer Tools) i w większości przeglądarek jest dostępne po naciśnięciu klawisza F12 lub kliknięciu prawym przyciskiem myszy w dowolnym miejscu na stronie oraz wybrania opcji w rodzaju "Zbadaj" czy "Inspect". Wówczas pojawi się panel składający się z kilku zakładek, który zapewnia ogromne możliwości i jeszcze dzisiaj na chwilę do niego wrócimy. Teraz jednak interesuje nas sekcja "Application" i to, co jest widoczne pod "Local storage" lub "Cookies" dla interesującej nas strony. Warto wyczyścić tamte dane poprzez kliknięcie prawym przyciskiem na danym elemencie i wybraniu "Clear", natomiast trzeba uważać - najczęściej oznacza to również, że zostaniemy wylogowani z danej witryny.

Uprawnienia

Jeśli nie pomogło czyszczenie przeglądarki oraz sprawdzenie innej na tym samym komputerze, to warto sprawdzić z innym użytkownikiem, czy on(a) również ma podobne problemy. Jest to sytuacja częsta w aplikacjach przeznaczonych dla konkretnego zespołu lub firmy i niejednokrotnie dostawaliśmy zgłoszenia "u kolegi działa, a u mnie nie". Zakładając, że nie jest to wina cache'a, warto poprosić "ofiarę" o test krzyżowy, czyli:

  • inny użytkownik sprawdza daną funkcję u siebie,
  • jeśli nie było problemów, to niech ten użytkownik w miarę możliwości zaloguje się na swoje konto na komputerze "ofiary".

W tym przypadku chodzi, oczywiście, o sprawdzenie uprawnień lub innych charakterystycznych danych konta - najczęściej na tym etapie okazuje się, że kłopot wynika z braku nierównych przywilejów i wówczas jest to bardzo ważna informacja dla programistów, którzy pod tym kątem będą sprawdzać zachowanie aplikacji. Nie zawsze musi być to tylko rola, a więc pakiet uprawnień - czasami jest to powiązanie użytkownika z konkretnymi obiektami w systemie, co oznacza, że zespół IT musi sprawdzić sytuację dokładniej korzystając z konta równoważnego osoby poszkodowanej. W jaki sposób to robią - zależy od wewnętrznych ustaleń pomiędzy software housem a klientem.

Natomiast taki test może też wykazać ewentualny przypadek, w którym to sam komputer osoby poszkodowanej jest w jakiś sposób winny. Rzadko się to zdarza, ale tutaj ponownie wysuwa się wpływ różnych rozszerzeń w przeglądarce, a także choćby połączenie z inną siecią internetową. Bywały już przypadki, w których problem wynikał nie tyle z samej aplikacji, co konfiguracji firewalla, choć trzeba przyznać, że to bardzo rzadkie okoliczności.

Dane przeglądarki

Wreszcie, gdy mimo tylu prób u poszkodowanego użytkownika nadal występuje problem i alternatywą pozostaje tylko pojawienie się u niego lub zdalne użyczenie ekranu, pozostaje zebranie odpowiednich danych, które być może rozjaśnią temat. I tutaj wracamy do Developer Tools, o których już wyżej wspomnieliśmy, a które tutaj ponownie nam się przydadzą.

Pierwsza sprawa to sprawdzenie, jak wygląda konsola JavaScript (zakładka "Console") - jest duża szansa, iż w tym miejscu będzie się znajdować dużo komunikatów w kolorze czerwonym, co - oczywiście - oznacza błędy. Często znajdują się tam ważne informacje, które należy skopiować i później przeanalizować.

Istotne rzeczy można też znaleźć w zakładce "Network" (lub "Sieć"), gdzie mogą na czerwono widnieć żądania zakończone błędem. Warto w takie pozycje kliknąć i skopiować dane z podzakładek "headers", "payload" oraz "response". Te informacje również są ważne dla programisty, choć trzeba wspomnieć o tym, że jeśli coś wyskoczyło w tym miejscu, to najczęściej można to też znaleźć w logach na serwerze. Z konsolą JS tak łatwo, niestety, nie jest.

W przypadku drugiej porady warto też wspomnieć o dodatkowych kwestiach. Po pierwsze, wpisy w tym miejscu pojawią się dopiero po odświeżeniu strony (w jakikolwiek sposób) i jeśli w "Network" niczego nie ma, to prawdopodobnie wystarczy nacisnąć F5. Po drugie, ta zakładka pozwala też zaznaczyć opcję "Disable cache", którą warto wypróbować przy szukaniu źródła błędu - działa ona podobnie, jak twarde odświeżenie omawiane wcześniej.

Cierpliwość jest cnotą

Tytuł tego rozdziału brzmi jak nieśmieszny żart, ale ma sens w przypadku, kiedy sytuacja dotyczy ogromnej aplikacji, która jest skalowana poziomo. Mowa o serwisach, które mieszczą się nie na jednym serwerze, tylko wielu, powielając swój kod w celu równoważenia obciążenia i wykorzystując do tego load balancera. Tego typu konstrukcja nie tylko pomaga w zachowaniu odpowiedniej przepustowości witryny, ale także w radzeniu sobie z awariami. W jaki sposób? Choćby taki, że wdrożenie nowej wersji może nastąpić tylko na część serwerów, inkrementacyjnie, w celu zweryfikowania, czy wszystko działa jak należy. Wówczas przez pewien czas użytkownicy, trafiający na "nowe" serwery, widzą już zmiany, podczas gdy nieszczęśnicy (albo i szczęśliwcy), którzy zostali przekierowani do "starych" jednostek jeszcze nie doświadczą modyfikacji. Muszą wtedy poczekać, aż wdrożenie dopełni się na wszystkich maszynach i również one zaczną serwować nową wersję usługi.

Ten mechanizm powinien być nam doskonale znany z sytuacji, kiedy pojawia się nowa zmiana w dużym serwisie (np. na Facebooku) i wszyscy o niej mówią, a my jej jeszcze nie widzimy, mimo usilnego odświeżania strony. Taka sytuacja oznacza, że prawdopodobnie odwołujemy się do serwera (tzn. tak zostaliśmy pokierowani przez wewnętrznego "dystrybutora" serwisu), który jeszcze nie ma wprowadzonej zmiany lub wręcz nie znajdujemy się w grupie kontrolnej użytkowników mogących doświadczyć modyfikacji. Jakkolwiek to źle nie brzmi, jest to zaplanowane działanie producenta oprogramowania i należy po prostu poczekać.

Jak do tego nie dopuścić?

Oczywiście, te wszystkie porady mają zastosowanie już po fakcie, a więc po wystąpieniu sytuacji, w której użytkownik nie jest zadowolony, a programiści zastanawiają się, co począć. Warto więc wiedzieć, w jaki sposób ograniczyć częstotliwość takich zdarzeń. Przede wszystkim należy mieć świadomość, że przeglądarka cache'uje pliki o takich samych nazwach, a mówiąc bardziej konkretnie - żądania odwołujące się do plików o tym samym URL. Aby to ominąć, częstą techniką jest dodawanie przyrostków po znakach zapytania, najczęściej losowych liczb. Wówczas przeglądarka "myśli", że to inny plik i go nie cache'uje. Jest to technika prosta, ale siłą rzeczy sprawi ona, że pamięć podręczna nie zadziała także w odpowiednich ku temu sytuacjach, a więc kiedy trzeba przyspieszyć stronę. Coś za coś.

Można też zwyczajnie poinformować przeglądarkę o tym, że dane witryny nie powinny być cache'owane poprzez odpowiednie opcje tagów meta, a więc Pragma oraz Expires. Generalnie warto zainteresować się hasłem "cache control" dotyczącym żądań HTTP, a w szczególności nagłówkiem o nazwie Cache-Control. Polecamy również przeczytać ten tekst, w którym znajduje się więcej informacji o cachingu w przeglądarce i przykłady, jak sobie z tym "radzą" duże witryny.

Frameworki JS-owe umożliwiają również inne nazywanie plików będących wynikiem budowania aplikacji - zarówno React, jak i Angular pozwalają uzupełnić nazwę poprzez losowy hash, jednak w sposób, który nie powinien zaburzyć prawidłowego cache'owania. Ten "dodatek" będzie stały na jedno wdrożenie - po zbudowaniu nowej wersji ulegnie zmianie, a więc zmusi przeglądarkę do ponownego pobrania pliku. A przynajmniej powinien, bo powiedzmy, że różnie z tym bywa, jako że sam index.html też ulega zapamiętywaniu w pamięci podręcznej.

W przypadku problemów wynikających z uprawnień nie ma tak naprawdę innego sposobu, jak dokładniejsze zarządzanie tym aspektem systemu, lepsza weryfikacja oraz przygotowanie przypadków testowych lub użytkowników testowych, za pomocą których będzie można w manualny lub automatyczny sposób weryfikować różne scenariusze.

Podsumowanie

Ten artykuł był przeznaczony zarówno dla programistów, jak i użytkowników, którzy narzekają na tego typu przypadłości. A że każdy z nas jest użytkownikiem takiej czy innej aplikacji, teoretycznie jest to tekst dla każdego odbiorcy stron internetowych. Warto przede wszystkim zapamiętać, czym jest twarde odświeżenie strony oraz fakt, że nie zawsze programiści są winowajcami sytuacji, która spotyka odbiorcę. Z naciskiem na "nie zawsze".

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Co się dzieje, gdy napiszesz do software house'u? https://wildasoftware.pl/post/co-sie-dzieje-gdy-napiszesz-do-software-house?ref=rss https://wildasoftware.pl/post/co-sie-dzieje-gdy-napiszesz-do-software-house?ref=rss Thu, 08 Feb 2024 17:30:00 +0000 Na tym blogu zwykle poruszamy tematy związane mniej lub bardziej z technikaliami i praktykami wytwarzania software'u. Dotyczą one programowania, czasem serwerów, może trochę cyberbezpieczeństwa. Bywają też takie teksty, w których uciekamy w tematy z teorii informatyki lub zarządzania. Od czasu do czasu napiszemy też co nieco o naszych flagowych systemach - Feedybacky oraz ComManie. Natomiast stosunkowo rzadko dotykamy tematów związanych z obsługą klientów i działaniami IT w kontekście biznesowym. Zmienimy to i to nie tylko dlatego, że taki pomysł zaproponował Artur Jabłoński w swoim materiale - przede wszystkim musimy pamiętać, jak funkcjonuje software house.

A funkcjonuje tak, że, oprócz oferowania własnych produktów, przyjmuje zlecenia klientów, głównie firm (a więc jest to sektor B2B). To oczywiste, ale już mniej pewne jest to, czy wszyscy wiedzą, czego dokładnie mogą spodziewać się po takim software housie. O tym akurat już pisaliśmy, natomiast skonkretyzujmy trochę ten najwcześniejszy etap, czyli fakt wpłynięcia zapytania do firmy. Wszyscy spodziewamy się, że w większości piękna przygoda w postaci wykonania systemu IT rozpoczyna się od pierwszego kontaktu, a my uznaliśmy, że sam w sobie jest on całkiem ciekawym tematem na artykuł. Nie tylko dlatego, że kogoś może interesować, co dzieje sie w takiej sytuacji po drugiej stronie, ale także dlatego, że w ten sposób można rozwiać pewne wątpliwości i mity, które niektórzy mogą mieć zakodowane w głowach.

Oczywiście, będziemy tutaj pisać o tym, jak dzieje się to u nas, czyli w Wilda Software. O ile poszczególne informacje będą pokrywały się z tymi, których udzieliliby inni wykonawcy, o tyle na pewno każde środowisko ma swoje "detale", które będą źródłem większych lub mniejszych różnic. Może to wynikać z wielu rzeczy - główną i najbardziej rozpoznawalną z nich jest struktura organizacyjna i rozmiar firmy. Jak większość firm, software house'y obok działów technicznych mogą posiadać osobne zespoły związane ze sprzedażą i w zależności od wielkości spółki, będzie to mniej lub bardziej widoczne na zewnątrz. Akurat w naszym przypadku, gdzie zespół jest stosunkowo mały i działa blisko siebie, więc ten łańcuszek decyzyjny również jest dość krótki.

Skąd przychodzą do nas zgłoszenia?

Na początku powiedzmy, o jakiej kategorii zapytań będziemy pisać w dzisiejszym artykule. Skupimy się na tych, które pojawiają się u nas spontanicznie lub innymi słowy - pochodzą od firm lub osób, z którymi wcześniej nie mieliśmy relacji biznesowych, a chcą zrobić rozeznanie przed zleceniem nam prac (a zatem nie wlicza się w to tzw. cold mailing uprawiany przez firmy szczególnie w sektorze B2B). Takie "niespodzianki" to dla nas szczególnie ciekawe wiadomości, gdyż obok szansy na współpracę pozwalają również poznać nowych ludzi i tym samym niekiedy świeże środowisko, szczególnie jeśli dojdzie do kolejnych rozmów. Zresztą, mała uwaga na boku - jeśli widzicie u różnych firm wzmiankę napisz do nas nawet, jeśli chcesz tylko powiedzieć "cześć!", to nie jest to tylko zabieg marketingowy mający rozluźnić konwersację, ale często szczery przekaz. To są bardzo przyjemne wiadomości, które w środowisku biznesowym pozwalają czasem odetchnąć i potwierdzić, że treść blogera czy firmy została w sieci zauważona i przeczytana. A jednocześnie takie kontakty mogą w przyszłości przyczynić się do jakiejś formy współpracy. Także już tutaj pojawia się myśl, którą chcielibyśmy przekazać całym artykułem - nie bójcie się pisać do firm. W żadnym wypadku to nie jest tak, że po pierwszym kontakcie już wpadniecie w jakiś wir, z którego nie będziecie mogli się wydostać.

Warto też wspomnieć, w jaki sposób można skontaktować się z software housem, przynajmniej na naszym przykładzie. Jeśli macie pomysł na aplikację, potrzebę biznesową lub po prostu chcecie porozmawiać o obszarze IT, do dyspozycji jest zazwyczaj skrzynka mailowa lub formularz kontaktowy. Akurat w naszym przypadku obok adresu e-mail dysponujemy też możliwością wysłania zgłoszenia przez (a jakże!) Feedybacky. Z doświadczenia wiemy, że potencjalni zleceniodawcy korzystają z obu dróg, co nas bardzo cieszy. Oczywiście, można również do nas zadzwonić, natomiast nie da się ukryć, że pierwszy kontakt poczyniony drogą tekstową i w dodatku asynchroniczną jest bardziej komfortowy dla obu stron. Co nie oznacza, że nie ucieszymy się również po odebraniu połączenia telefonicznego.

Kto odczytuje zgłoszenie?

Przychodzi do nas wiadomość, która zawiera pytanie lub konkretną prośbę o wycenę rozwiązania IT. Co dzieje się dalej?

Tutaj warto zaznaczyć, że większość takich maili trafia najpierw do naszych szefów - Joanny (pani prezes i kierowniczka projektów), ew. Piotra (dyrektor działu IT). Oboje z nieco różnych stron zajmują się organizacyjną stroną firmy i mają jasność projektów oraz przedsięwzięć, które są realizowane w Wilda Software. Także, jeśli napiszecie do nas, to z dużym prawdopodobieństwem Wasze zapytanie zostanie wyświetlone najpierw przez Asię. Następnie wszystko zależy od charakteru takiego maila. W momencie, kiedy jest to luźne zapytanie (na przykład o ofertę i usługi, które świadczymy - tak, jak najbardziej też można o to poprosić, choć te informacje znajdziecie również na naszej stronie internetowej), najczęściej właśnie ta dwójka z miłą chęcią przygotuje dla Was odpowiedź. Powtarzam - jest to całkowicie niezobowiązujące, a my jednocześnie będziemy mogli doradzić, w jakim kierunku powinna przebiegać dalsza korespondencja w zależności od tego, na co nacisk kładła pierwsza wiadomość. A lubimy doradzać.

Nieco inaczej wygląda sprawa w momencie, kiedy mail zawiera zapytanie o konkretne rozwiązanie IT. Z praktyki możemy stwierdzić, że duża część takich wiadomości to pytanie "za ile zrobicie taki portal?". I w porządku, nie ma w tym niczego złego. Natomiast musimy napisać, że o ile z równą chęcią odpowiadamy na takie wiadomości, o tyle nierzadko nie jesteśmy w stanie udzielić prostej odpowiedzi. Dlaczego? Pewnie się domyślacie - pytanie o wycenę np. serwisu informacyjnego jest na tyle ogólne, że potencjalny zleceniodawca może mieć na myśli WSZYSTKO. W tym konkretnym przykładzie może to być zarówno lokalny serwis z wiadomościami za kilkanaście lub kilkadziesiąt tysięcy złotych, jak i ogólnopolski portal tematyczny czy nawet system obejmujący platformy z artykułami i materiałami wideo za setki tysięcy. To oznacza, że nasza odpowiedź będzie bardziej naprowadzaniem i pokazaniem możliwości aniżeli dokładną wyceną.

Właśnie - tutaj warto powiedzieć, że działalność takich software house'ów jak nasz nie polega tylko i wyłącznie na projektowaniu, realizacji i serwisowaniu oprogramowania. Czasem również po prostu konsultujemy, wskazujemy drogę i tłumaczymy zawiłości tej branży oraz dostępnych opcji. Niekiedy robimy to publicznie na blogu, wyjaśniając pewne zagadnienia, ale dużą przyjemność sprawia nam również zrobienie tego w personalizowany sposób, w odpowiedzi na zapytanie. A przynajmniej ja tak mam, zwłaszcza, że wiadomości dotyczące konkretnych rozwiązań technicznych zazwyczaj są przesyłane do Szymona lub do mnie (Jakuba), którzy w Wilda Software stanowią dynamic duo CTO (Chief Technology Officer). Krótko mówiąc, jesteśmy jednocześnie głównymi programistami, kierownikami prac technicznych oraz projektantami rozwiązań technologicznych. Jeśli firma zajmuje się jakimś oprogramowaniem dla Ciebie, to poza nielicznymi przypadkami to właśnie ktoś z naszej dwójki jest zaangażowany w to przedsięwzięcie i dyryguje kwestiami technicznymi.

Nic zatem dziwnego, że to my z Szymonem często dostajemy wiadomości z prośbą o chociaż szacunkową wycenę lub inne techniczne sprawy. Tę odpowiedź przygotowujemy wraz z Piotrem, starając się zaspokoić zaciekawienie potencjalnego zleceniodawcy. I chyba całkiem nieźle nam to idzie, gdyż kontynuacja korespondencji nie jest wcale taki rzadka.

Co dalej?

Dalszy kontakt może oznaczać wiele różnych rzeczy. Jeśli pytającemu spodoba się nasza odpowiedź lub poczuje się nią zaintrygowany, często kolejna wymiana wiadomości jest już bardziej szczegółowa lub wręcz eksploruje kolejne wątki. Nierzadko również już na tym etapie do głosu dochodzi kontakt głosowy, a nawet spotkanie. To zależy stricte nie tylko od rodzaju sprawy, ale też charakteru osób uczestniczących w korespodencji - nie każdy lubi od razu się widzieć i przechodzić do konkretów i my to rozumiemy.

Gdy już jednak do konkretów dojdzie, to komunikacja wygląda nieco inaczej. Przede wszystkim, możesz być spokojny o naszą dyskrecję - podpisujemy umowę o zachowaniu poufności (NDA, Non-disclosure agreement), aby obie strony czuły sie bezpieczne (niekiedy dzieje się to już przed pierwszym zapytaniem, jeśli klient sobie tego życzy), a następnie rozpoczyna się bardziej precyzyjny proces analizy potrzeb klienta, definiowanie wymagań oraz podstawowa propozycja architektury. Jeśli na tym etapie odkryjemy, że Twoja potrzeba już została pokryta przez istniejące i znane nam rozwiązanie na rynku, to poinformujemy Cię o tym i zaproponujemy albo integrację, albo wdrożenie tego narzędzia. Najczęściej jednak mamy do czynienia z pomysłami lub oczekiwaniami wymagającymi autorskiego oprogramowania i na tym polega znakomita większość naszych realizacji.

Tak opisywana analiza, która zawiera dużo więcej detali i praktycznie projekt tego, co będzie wykonywane, już jest płatna, choć na pewno co do rzędu kosztu nie można tego porównać z wartości całości prac programistycznych. W tego typu rozmowach uczestniczy najczęściej Piotr oraz Szymon lub Kuba jako osoby bardziej techniczne, jednocześnie mające doświadczenie z dziesiątek podobnych rozmów. I nadal - jeśli na tym etapie pojawią się u Ciebie dodatkowe pytania, to nie zawahamy się odpowiedzieć.

Podsumowanie

Przede wszystkim pamiętajmy, że napisanie do firmy IT czy jakiegokolwiek usługodawcy jest bezbolesne - nie wiąże się z żadnymi konsekwencjami, zaangażowaniem finansowym czy narażeniem się na cokolwiek. To naturalna droga do dalszej współpracy lub przynajmniej pozyskania odpowiednich informacji, pozwalających lepiej ocenić ryzyko przedsięwzięcia. Tak - jeśli już po pierwszym mailu będziemy widzieć, że sprawa jest znacznie bardziej skomplikowana lub wiążąca się z problemami dla Ciebie, to nie omieszkamy się o tym napisać i to bez względu na nasze interesy. Tym niemniej, jeśli tylko potrzebujesz rozwiązania IT dla swojej firmy lub masz pomysł na biznes czy startup, to cóż - wiesz, gdzie nas szukać. A my zapraszamy do kontaktu - będzie miło :)

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Cron dla początkujących https://wildasoftware.pl/post/cron-dla-poczatkujacych?ref=rss https://wildasoftware.pl/post/cron-dla-poczatkujacych?ref=rss Thu, 25 Jan 2024 17:30:00 +0000 Tworząc oprogramowanie i definiując wymagania serwerowe dla administratora, bardzo często dołączany jest tam punkt "potrzebny cron". I od razu mała dygresja - niektórzy powiedzą, że wskazywanie tej pozycji osobno jest bezsensowne, gdyż jest to klasyczny element każdego systemu na serwerze. Może i tak, ale:

  • pamiętamy w firmie sytuacje, w których administrator nie przygotował crona, gdyż "uznał, że nie jest potrzebny",
  • nawet, jeśli był, nie zawsze był do niego dostęp.

Rzeczywiście, jeśli to jeden z podstawowych składników serwerów, ale przede wszystkim niezwykle potrzebne narzędzie w większości aplikacji sieciowych. Z tego powodu jego używanie jest tak naturalne, jak tworzenie kolejnych endpointów API czy zapewnienie kolejnych funkcji w aplikacji klienckiej. A przynajmniej tak się wydaje - programistom (szczególnie bardziej doświadczonym) nazwa "cron" jest tak znana, że aż stała się synoninem wszystkich podobnych mechanik, niezależnie od tego, jak one się nazywają w danym środowisku czy technologii. Ale trzeba pamiętać, że bardzo młodzi adepci informatyki lub klienci nie zawsze mogą rozumieć ten slang. A nawet, jeśli rozumieją, to nie zawsze wykorzystanie crona jest takie oczywiste - jakieś gwiazdki, liczby, nic nie działa jak trzeba...

Dlatego w tym artykule wytłumaczymy, czym jest cron, kiedy się go wykorzystuje i jak to zrobić. Tekst jest przeznaczony raczej dla początkujących, ale nie wykluczamy, że parę zamieszczonych informacji, które dotyczą bardziej kwestii aplikacyjnych, przyda się również lub zainspiruje osoby bardziej zaawansowane.

Co to jest cron?

Najprościej mówiąc, cron to program do cyklicznego uruchamiania zaplanowanych zadań. Jest to narzędzie typowo linuksowe, a właściwie powinniśmy powiedzieć "uniksowe" - powstało w maju 1975 roku w firmie AT&T Bell Laboratories (notabene, jak cały UNIX), która obecnie nazywa się Nokia Bell Labs. I tak, cząstka "Bell" nie jest przypadkowa, gdyż fundamenty tej zasłużonej instytucji powstały za sprawą znanego wszystkim Alexandra Grahama Bella pod koniec XIX wieku. Sama nazwa programu pochodzi od greckiego słowa chronos oznaczającego czas. Ale do rzeczy.

Wyobraźmy sobie sytuację, w której pewne zadania system musi wykonać bez naszej ingerencji. Przykładem może być generowanie pewnego raportu co noc i wysyłanie go do użytkowników. Wykorzystywanie do tego człowieka, aby zawsze o określonej godzinie znalazł się przy komputerze i kliknął określony przycisk, jest bezcelowe i męczące. Lepiej zdać się na system komputerowy, który działa cały czas i o odpowiedniej porze zrobi to za nas. Do tego właśnie służy cron - możemy za jego pomocą definiować, o której (lub co ile) ma wykonać określone akcje. Technicznie rzecz biorąc, jest to serwis (w Linuksie nazywany demonem, ang. daemon), który działa w tle i cały czas sprawdza listę zadanych operacji pod kątem tego, czy powinien je teraz uruchomić.

Cron jest tak naprawdę pierwszym programem tego typu i doczekał się kilku implementacji, wśród których popularny jest np. fcron. Jednak w praktyce, gdy zostanie wskazana chęć posiadania lub użycia crona, to wszyscy wiedzą, o co chodzi i rzadko wymagana jest decyzja, która konkretna implementacja powinna zostać zainstalowana. Warto natomiast odróżnić termin "cron" od "crontaba" - to drugie to program lub tabele programu cron, z których pobierane są definicje zadań. Możemy sobie wyobrazić crontaby jako listy działań do wykonania zapisane przez różne osoby mające dostęp do serwera. Z tego powodu ich definiowanie odbywa się właśnie poprzez polecenie crontab, gdzie każdy operator systemu ma swoją listę, którą potem serwis crona zbiera i uruchamia na uprawnieniach tej osoby.

Jak wygląda definiowanie zadań?

Z poprzedniego akapitu dowiedzieliśmy się, że aby zdefiniować zadania crona, powinniśmy skorzystać z polecenia crontab, a dokładnie crontab -e, które pozwala edytować wpisy. Dzieje się to za pomocą edytora tekstowego, w związku z czym przy pierwszej próbie skorzystania z tej komendy użytkownik może zostać zapytany przez system, jaki program chce wykorzystać. Jest to kwestia wyłącznie wygody i przyzwyczajeń - niżej podpisany zawsze wybiera Vima, aczkolwiek większość pozostaje przy prostym nano.

Tablica składa się z wpisów, które muszą zachować następującą strukturę:

m h dom mon dow command

Jak widać, każde zadanie będzie składało się z sześciu kolumn, z których pierwsze pięć określają moment lub częstotliwość wykonania, a ostatnia informacja to konkretne polecenie. I tutaj właśnie dzieje się magia w postaci tych dziwnie wyglądających linijek z gwiazdkami. Jest to jednak stosunkowo proste do zrozumienia.

Te pięć pierwszych kolumn należy interpretować w następujący sposób:

  • m - minuta, zakres od 0 do 59
  • h - godzina, zakres od 0 do 23
  • dom - dzień miesiąca, zakres od 1 do 31
  • mon - miesiąc, zakres od 1 do 12
  • dow - dzień tygodnia, zakres od 0 do 7, gdzie niedziela jest zarówno pod 0, jak i 7, poniedziałek to 1 itd.

Zwykle nie wszystkie kolumny chcemy uzupełnić konkretnymi wartościami i bardzo często będziemy wykorzystywać znaki specjalne. Cron pozwala na wstawienie:

  • gwiazdki (*) - oznacza każdą wartość, a więc np. "o każdej minucie".
  • łącznika (-) - oznacza zakres wartości, a więc np. 1-3 to "gdy wartość jest od 1 do 3".
  • slasha (/) - służy do określenia częstotliwości, np. */2 to "co dwie wartości". Przed ukośnikiem nie musi być gwiazdki i można dodatkowo zawęzić zakres, np. pisząc 6-16/2 mamy na myśli "od wartości 6 do 16, ale co dwie jednostki (czyli 6, 8, 10, 12, 14, 16)".
  • przecinka (,) - pozwala podać konkretne wartości, jeśli nie chcemy lub nie możemy używać zakresu. Przykładowo, 2,5 oznacza "o wartości 2 lub 5".

Jest to całkiem potężne narzędzie, ale dobrze pamiętamy, że na początku korzystania z niego można mieć pewne wątpliwości, jak w praktyce definiować czasy. Możemy sobie to wyobrazić tak, że system co minutę sprawdza, czy obecny czas pasuje do jakiejś definicji - jeśli tak, wykonuje to zadanie. Aby lepiej to zrozumieć, przyjrzyjmy się kilku przykładom (dość sztucznym, ale ciekawym):

0 10 * * * php ~/script.php - dokładnie o 10:00 (m = 0, h = 10) każdego dnia (dom, mon, dow = *) wykonaj skrypt script.php znajdujący się w katalogu domowym użytkownika. Przy tej okazji warto nadmienić, że znak ~ (tylda) odniesie się właśnie do użytkownika, który zdefiniował zadanie, tj. w którego tabeli crontab znajduje się ten wpis. Gdy nie chcemy popełnić błędu, warto używać ścieżek bezwzględnych.

*/30 6 * * 1,5 cp ~/file1.txt ~/copy.txt - w poniedziałki i piątki (1 oraz 5), gdy wybije godzina szósta (6), to co pół godziny (*/30) wykonaj kopię pliku file1.txt do copy.txt. W praktyce w ciągu tygodnia ta operacja zostanie uruchomiona cztery razy - w poniedziałek o 6:00 oraz 6:30 i w piątek o tych samych porach. Tylko te momenty pasują do podanej definicji czasu.

22 * * * * mysqldump -u user -d db > ~/"backup_$(date +\%Y-\%m-\%d_\%H-\%M-\%S).sql" - co godzinę o minucie 22 (a więc 14:22, 15:22, 16:22 itd.) każdego dnia wykonaj kopię zapasową bazy MySQL do danego pliku. Przy tej okazji można zobaczyć, że w komendzie można używać zmiennych i wewnętrznych poleceń, tak jak np. daty, aby odpowiednio nazwać wynikowy plik. Trzeba tylko pamiętać o odpowiednim formatowaniu danych. Warto zajrzeć do tego wątku oraz przy okazji poznać polecenie date.

0 20 1 3 * php ~/report.php - dokładnie 1 marca o 20:00 każdego roku (bez względu na dzień tygodnia) wykonaj skrypt z raportem.

Jak widać, instrukcje potrafią być czasem zawiłe, ale opanowanie ich to kwestia praktyki. I spokojnie - jeśli nadal trochę się gubicie, to nie jesteście jedyni. Z myślą o początkujących w świecie crona, powstały różne interfejsy pomagające wyklikać pożądane czasy, a także generator z przykładami w postaci crontab.guru/.

Na koniec warto wspomnieć o tym, że jeśli nie chcemy już wykonywać jakiegoś zadania, ale nie jest nam na rękę jego usunięcie, to pamiętajmy, że edytowanie crontaba to działanie na pliku tekstowym - taką linijkę możemy zakomentować, wstawiając hasz (#) na początku linii.

Rodzaje dostępu do crona

Warto też nadmienić, iż w zależności od hostingodawcy i rodzaju serwera dostęp do definiowania zadań crona może być inny. Nie zawsze administrator udostępni polecenie crontab - czasem jest to interfejs webowy, w którym wybieramy opcje z listy, a niekiedy są to wytyczne dotyczące umieszczania plików tekstowych o ściśle zdefiniowanych nazwach w konkretnych lokalizacjach. W przypadku wątpliwości, warto zajrzeć do systemu pomocy serwerodawcy lub skontaktować się z nim.

W przypadku, kiedy mamy dostęp poprzez konsolę i większe niż zwykle uprawnienia, warto wiedzieć, iż logi dotyczące uruchamiania crona są dostępne w /var/log/cron lub /var/log/syslog, w zależności od dystrybucji Linuxa oraz konfiguracji. Możemy tam podejrzeć, czy dane zadanie rzeczywiście zostało uruchomione o wyznaczonym czasie.

W tym artykule nie będziemy w szczegółach omawiać kwestii konfiguracyjnych - zazwyczaj nie są one istotne dla programistów i zajmują sie nimi administratorzy. Oczywiście, nie jest to żadna wymówka i warto wiedzieć jak najwięcej, natomiast trzeba mieć świadomość, że konfiguracja crona (jako programu, a nie poszczególnych zadań) to działanie znacznie wykraczające poza tworzenie aplikacji - to obszar pod panowaniem osób zarządzających serwerem i systemem operacyjnym na nim. Tym niemniej, warto zajrzeć do artykułu Mateusza Mazurka oraz Zairy Hiry, gdzie jest opisane trochę więcej.

Na koniec tej sekcji wróćmy jeszcze na chwilę do definiowania zadań - zazwyczaj polega to na umieszczeniu kilkunastu osobnych poleceń w crontabie. Nie jest to jednak jedyny sposób, a mimo prostoty, może być nawet nieco zgubny. Jeśli w rozwijanej aplikacji pojawia się wiele akcji, które będą uruchamiane periodycznie, to za każdym razem trzeba pamiętać o uzupełnianiu crontaba przy wdrożeniu lub zautomatyzować to. Problem jest też w przekazaniu tej informacji między programistami i wdrażającym. Jednak niektóre frameworki podchodzą do tego trochę inaczej - przykładowo, Laravel wymaga dodania tylko jednej komendy do tabeli systemowej (uruchamianej co minutę), a to sama aplikacja zarządza czasami uruchomienia poszczególnych zadań, które ma w sobie zaprogramowane. Atut tego rozwiązania polega na tym, że programista nie musi przejmować się uzupełnianiem crona, a w dodatku już w kodzie ma informację o tym, co ile wykonywana jest dana operacja (w dodatku mogąc śledzić zmiany w repozytorium).

Przy okazji, warto uzmysłowić sobie, że nie jest wymagane ręczne edytowanie pliku crontaba, aby dodać nową operację czy zmienić istniejącą. Reguły można przechowywać w innym pliku tekstowym i zaimportować go poprzez polecenie crontab file.txt. To może pomóc w automatyzacji tego procesu podczas wdrożeń. Tak samo prosto można zrobić kopię zapasową obecnych reguł komendą crontab -l > backup.txt.

Do czego można wykorzystać crona?

Z pewnością podczas czytania dotychczasowej części artykułu, w głowie każdego czytelnika pojawiło się wiele pomysłów na to, w jakich sytuacjach można wykorzystać crona. Dotyczą one zarówno aplikacji, jak i różnych operacji systemowych. Dla formalności wypiszmy najczęstsze przykłady użycia menedżera zadań wykonywanych cyklicznie. I to z życia, a nie teoretycznych rozważań.

  • tworzenie zadań na bazie dat (np. "dzisiaj kończy się twoja umowa"),
  • tworzenie periodycznych raportów,
  • wysyłanie zaplanowanych powiadomień,
  • ustalanie statusów obiektów w systemie,
  • usuwanie nieużywanych plików,
  • przeliczenie zagregowanych danych,
  • przygotowywanie kopii zapasowych bazy danych bądź plików,
  • pobieranie danych z zewnętrznego API (np. kursy walut),
  • odnowienie certyfikatu SSL,
  • aktualizowanie plików (np. mapa strony lub kanał RSS),
  • czyszczenie cache'a.

Możliwości jest bardzo dużo - to tylko ich garstka. Prawie w każdej aplikacji znajdzie się kilka funkcji, które są uruchamiane nie na żądanie użytkownika, tylko automatycznie, ułatwiając choćby monitorowanie terminów czy obiektów wymagających interwencji. Trudno wyobrazić sobie choćby mechanikę newslettera bez zastosowania crona - to, że odbiorcy dostają nowe wiadomości np. co poniedziałek o 9 rano nie jest wynikiem tylko regularności nadawcy, ale właśnie takich "schedulerów", jak niepozorne uniksowe narzędzie.

Jak uruchamiać zadania co sekundę?

Bardziej spostrzegawczy zauważyli, że najmniejszą jednostką czasową crona jest minuta - linijka * * * * * oznacza wywołanie danej komendy co 60 sekund. Jak zatem robić to częściej, nawet co 1 sekundę? Na wstępie należy powiedzieć, że jeśli takie jest wymaganie aplikacji, to... warto je przemyśleć. Pamiętajmy, że zadania wykonywane w systemie w tle nadal go obciążają, a dodatkowo określenie momentu uruchomienia operacji nie oznacza, że znamy moment jej końca. W przypadku większych działań może się okazać, że zadanie uruchomione planowo np. o 6:12 zakończy się dopiero o 6:20. Oczywiście, większość zadań na serwerze zostanie sfinalizowana się przed upłynięciem sekundy, ale w przypadku bardziej złożonych systemów może to być np. kilka sekund. Uruchamiając takie zadanie co sekundę system będzie coraz bardziej obciążony, co może skończyć się fatalnie. W większości wypadków uruchamianie co minutę jest jak najbardziej wystarczające, a i tak nierozważnie wykorzystane może spowodować przekroczenie zużycia zasobów.

To jednak nie oznacza, że nie istnieje sposób na "oszukanie" crona i uruchomienie zadania w konkretnej sekundzie. Nie jest to też bardzo trudne, o ile znamy obecną tak w Linuksie, jak i praktycznie każdym języku programowania operację sleep, pozwalając "zasnąć" aplikacji na określoną liczbę sekund. Kluczem jest to, aby uruchomić zadanie w sekundzie 0 i poczekać chwilę na interesujący nas moment. W niektórych przypadkach można to zrobić w samym crontabie za pomocą komendy systemowej, natomiast, jeśli technologia aplikacji nam na to pozwoli, można to zrobić także w niej.

Nie mam crona - co robić?

Obecnie brak możliwości skorzystania z crona jest dość rzadkim zjawiskiem, jednak z naszych doświadczeń wynika, że może się to zdarzyć, szczególnie w przypadku bardzo tanich lub małych hostingów. Czasem wynika to też z kwestii uprawnień, choć nie powinno być to wytłumaczeniem z uwagi na to, że każdy użytkownik ma swojego crontaba i odpowiednio zawężone możliwości.

Załóżmy jednak, że faktycznie taka sytuacja nas spotkała - co możemy zrobić poza ręcznym uruchamianiem komend? Możliwości są co najmniej dwie. Pierwsza z nich to wykonywanie pewnych działań podczas pierwszego logowania się użytkownika w danym dniu, oczywiście, w miarę możliwości w tle. Dotyczy to szczególnie operacji przeliczenia zagregowanych danych, np. do kokpitu firmy wchodzącej do systemu. Tym niemniej, potężną wadą jest czasochłonność operacji oraz wymóg, aby ktoś się zalogował, co nie wiadomo, czy nastąpi. Drugie rozwiązanie, znacznie lepsze, to wystawienie usługi API i codzienne odwoływanie się do niej z zewnętrznego źródła, które z kolei jest sterowane cronem. Jest to właśnie imitacja okresowego wywoływania operacji, jednak wymaga publicznego dostępu do serwisu oraz pisania kolejnej usługi. Tym niemniej, jest to jakaś opcja w przypadku braku możliwości skorzystania ze standardowej ścieżki.

Warto też wspomnieć o tym, że czasem cron może nie działać, gdyż zwyczajnie... nikt go nie uruchomił lub nie zainstalował. W takim wypadku, o ile posiadamy odpowiednie uprawnienia, warto sprawdzić stan demona za pomocą komendy sudo service cron status lub innej, odpowiedniej dla danej dystrybucji systemu Linux. Różne możliwości i sposób uruchamiana zostały opisane w tym poradniku.

Cron w różnych środowiskach

Mówiąc o cronie, cały czas poruszamy się w tematyce Linuxa. Nie jest to dziwne, gdyż na większości serwerów króluje właśnie ten system operacyjny. Ponieważ omawiane narzędzie zostało stworzone za czasów UNIXa, to można się spodziewać, że znajdzie się również w macOS i tak jest w istocie - w tym środowisku możemy z niego skorzystać.

A jak to wygląda w przypadku Windowsa? W tym przypadku prostego dostępu do crona nie mamy, ale za to mamy dwie drogi, jak sobie z tym poradzić. Istnieje Windows Subsystem for Linux (WSL), który pozwala odtworzyć Linuxa w Okienkach. W zależności od dystrybucji, program może już tam być, ale wyłączony (jak to ma miejsce w przypadku Debiana), jednak łatwo to zmienić, korzystając z porad znajdujących się w poprzedniej sekcji. Uruchomienie usługi do zadań cyklicznych automatycznie nie jest aż tak proste, jakby się mogło wydawać, ale również jest możliwe.

Natomiast warto pamiętać, że sam Windows oferuje zamiennik w postaci Harmonogramu Zadań dostępnego z poziomu menu start lub jako Taskschd (wielkość liter jest ważna) z wiersza poleceń. Ten program umożliwia tworzenie zadań za pomocą interfejsu graficznego, choć istnieje też opcja zarządzania nimi z poziomu konsoli, której warto się przyjrzeć (nie od dzisiaj wiadomo, że programiści lepiej się dogadują z interfejsem konsolowym niż GUI).

Podsumowanie

Zadania cykliczne pojawiają się praktycznie w każdej aplikacji tworzonej przez software house i z cronem po prostu trzeba nauczyć się żyć oraz z niego korzystać. Zwłaszcza, że nie jest to skomplikowane narzędzie, za to dające duże możliwości, także w sytuacjach, w których pozornie nie należy się tego spodziewać (np. przy przeliczaniu pomocniczych wartości w tle). Zachęcamy do samodzielnych prób, gdyż tylko praktyka pozwoli opanować tego typu techniki we właściwy sposób.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Marka w Fediverse - czy i jak zacząć? https://wildasoftware.pl/post/marka-fediverse-czy-jak-zaczac?ref=rss https://wildasoftware.pl/post/marka-fediverse-czy-jak-zaczac?ref=rss Wed, 17 Jan 2024 18:20:00 +0000 ("uROJenia" to cykl tekstów (często o charakterze publicystycznym), które są zwykle zamieszczane poza obowiązującym harmonogramem artykułów i dotyczą spraw ważnych dla jego autora, a więc Jakuba Rojka. Czasem ich związek z tematyką IT jest bardzo swobodny, podobnie zresztą jak styl.)

O Fediverse (lub - bardziej po polsku - Fediwersum czy też Fediwers) można pisać bardzo dużo. To tylko z pozoru kolejny system społecznościowy, jednak to również niewyczerpane źródło przemyśleń dotyczących architektury rozproszonej, prywatności w sieci, zachowań międzyludzkich, grup społecznych oraz pomysłów na rozszerzanie środowiska wokół nas. Posiada wiele aspektów, których nie mają scentralizowane portale, a także nie zawiera tych cech, które w oczach społeczności są złe w komercyjnych serwisach. Oczywiście, to wszystko kwestia względna i nic nie jest idealne, jednak trzeba przyznać, że Fediverse ma swoją filozofię, której się trzyma i choć czasem jest naginana w zależności od potrzeb oraz kreatywności użytkowników, to jednak w dużej mierze trzyma się swoich ideałów, co należy pochwalać.

Jednocześnie, utarło się, że nie jest to platforma dla wszystkich typów użytkowników - wśród nich na pierwszym miejscu wymienia się marki lub firmy, które często traktują społecznościówki jako tubę marketingową zamiast rzeczywiście skupiać wokół siebie społeczność i zyskać w ich oczach. Trudno się temu dziwić - pamiętajmy, że istnienie w przestrzeni internetowej i dbałość o swoje profile nie są za darmo i koszty oznaczają, że działalność musi przynosić pewien zysk organizacji, liczony w różnych jednostkach, niekoniecznie mierzalnych. Można to osiągnąć różnymi sposobami, ale nie ukrywajmy tego, że zazwyczaj jest to korzystanie ze sprawdzonych "patentów", obliczonych na zasięg i niekiedy - ujmijmy to delikatnie - niekoniecznie przyczyniających się do rozwoju obserwujących profil użytkowników, za to próbujących za wszelką cenę wepchnąć się do nich ze swoim produktem lub usługą. Czy to coś złego? Raczej normalnego, o ile nie staje się to nachalne lub wręcz szkodliwe społecznie. W tym miejscu powstaje pytanie, czy Fediverse (Mastodon, /kbin czy Pixelfed), jako medium zdecydowanie bardziej społecznościowe niż scentralizowane platformy, jest na to odpowiednim miejscem oraz czy użytkownicy, którzy przecież przenieśli się do tego miejsca m.in. ze względu na chęć uniknięcia "marketingowych ścian" w ogóle przyjęliby takie profile pozytywnie. Większość osób, szczególnych stałych bywalców Fedi odpowie, że nie, a nawet, jeśli nie mają zdania, stwierdzą, że to po prostu nie może się udać.

Ale czy na pewno?

W przestrzeni Fediverse są profile różnych organizacji, blogów, podcastów, inicjatyw, ale istnieją też nieliczne miejsca, w których swoje informacje przedstawiają firmy. Z dumą mogę oznajmić, że od pewnego czasu taką przestrzeń posiada również Wilda Software i chyba jesteśmy tolerowani. W dzisiejszym tekście chciałem poruszyć temat tego, czy osoby zajmujące się swoją działalnością mogą próbować swoich sił w Fediverse i jeśli tak, to jak mogą to zrobić. Z góry uprzedzam, że będą to bardziej przemyślenia, aniżeli potwierdzona wiedza - nie jestem specjalistą od marketingu, PR-u i sprzedaży, niezależnie od medium. Natomiast na tyle długi czas jestem w świecie Fedi, że pojawiły się u mnie refleksje, którymi chciałem się z Wami podzielić. Czy te refleksje będą raczej zachęcać, czy odradzać i czy w ogóle będą z tego wnioski - zobaczymy.

Warto też zwrócić uwagę, że o ile często będę używał zwrotu "firma", to mam na myśli wszystkie podmioty, które wykorzystują swoje konta nie tyle w celach społecznościowych, co komercyjnych lub zwyczajnie są na tyle znane, że siłą rzeczy skupiają na sobie zainteresowanie szerokiej grupy osób. Także obok faktycznych firm poniższy tekst odnosi się też do osób prowadzących działalność w sieci (np. twórców treści), przedsiębiorców (jako pojedyncze osoby) czy serwisów tematycznych.

Podejście do komercji w Fediverse

Przede wszystkim, warto znać klimat panujący na Fediverse i powody, dla których w ogóle powstał. Obok czynników związanych np. ze światopoglądem, powodem stworzenia otwartego serwisu społecznościowego jest choćby chęć uniknięcia reklam, toksycznych treści, ofert sprzedaży czy niedostarczanie firmom danych pozwalających na profilowanie indywidualnych użytkowników. Jest to coś, co śmiało można nazwać inicjatywą społeczną i rzeczywiście, obok kont prywatnych, to miejsce na różne fundacje, organizacje pozarządowe i inne przedsięwzięcia nienastawione na zysk, tylko pomoc określonej grupie osób.

Bardzo dobrym przykładem pożytecznej inicjatywy społecznej jest Fedigov, który promuje wykorzystanie Fediverse przez instytucje publiczne, działające dla ludzi i informujących ich o swoich poczynianiach lub umieszczających ważne ogłoszenia. Jest to oferta skierowana przede wszystkim do urzędów, starostw, ale też mniejszych jednostek organizacyjnych - myślę, że również szkoły i uczelnie pasują do tego grona. Jest to zupełnie inny obszar niż ten, o którym tutaj piszemy, więc nie będę się nad nim dzisiaj rozwodzić, natomiast polecam przejrzeć podlinkowaną witrynę i zainteresować się tematem, szczególnie, jeśli jesteś przedstawicielem(-ką) takiej instytucji lub masz w niej kogoś bliskiego.

Wracając do klimatu - jak można podejrzewać, firmy słabo wpisują się w taki krajobraz. W Fediverse (czyli m.in. Mastodonie) nie brakuje osób, które cieszą się, że nie widzą już w końcu postów promocyjnych różnych marek, nie wyskakują im pięknie przygotowane, ale nieszczere reklamy, a kolejny influencer nie próbuje im wcisnąć niesamowitej pasty do zębów, która wstawia brakujące zęby już tylko za 399,99 zł za tubkę. Nie bez powodu wspomniałem o braku szczerości - dobrze wiemy, że posty firm i marek bywają "obliczone" na pewien określony efekt i są pisane w specyficzny, ogólny sposób (pomijając te, które z założenia są kontrowersyjne i tak mają brzmieć). Szczególnie dotyczy to marek, w tym tych influencerów, którzy starają się zbratać ze społecznością, ale tak naprawdę są to mechaniczne reakcje. Owszem, pozostaje problem osób, którzy za wszelką cenę chcą wywołać zamieszanie i szum w myśl zasady "nieważne jak, byle mówili". Choć po pierwsze, platforma, którą rządzi społeczność, a nie wielka firma, radzi sobie z takimi przypadkami, a po drugie - brak algorytmu opartego na liczbie reakcji naturalnie blokuje pewną eskalację.

Oczywiście, nie dotyczy to wszystkich użytkowników, gdyż ich przekrój jest bardzo szeroki. Są osoby, które absolutnie nie chcą widzieć treści marek i będą chciały z tym walczyć (do czego mają prawo). Są tacy, którzy nie mają nic przeciwko takim postom lub ich nie obchodzą. Jest też grupa pośrednia, która z chęcią zobaczyłaby na swojej osi czasu działania ulubionych firm i marek, o ile będą trzymały się pewnych ram oraz zachowań. No właśnie.

Oczekiwane zachowanie firmy lub marki

Te podmioty zachowują się w sieci różnie. Istnieją takie, którzy rzeczywiście są przyjacielskie i chcą pokazać, że potrafią coś więcej niż oferowanie swoich produktów oraz usług. Są takie, które dobrze to udają i markują chęć interakcji. A bywają też takie (szczególnie wśród wielkich firm), które nawet tego nie imitują, tylko pięknie wyglądającymi reklamami i treścią pieczołowicie napisaną przez PR-owców starają się dotrzeć do mas ludzi oraz ich zachwycić.

W przypadku tych ostatnich trudno liczyć na sukces w zaistnieniu w Fediverse - same cudowne treści nikogo nie przekonają, a szeroką rzeszę odbiorców trudno sobie wypracować, gdy nie ma się dostępu do systemu reklamowego i algorytmu. Zapewne promocja byłaby możliwa, ale istnieje duża szansa, że nastawiając się z każdym postem wyłącznie na zysk lub poklask, bardzo szybko zrazi się do siebie społeczność. Dlatego kluczowe są szczerość, realna chęć przyniesienia czegoś dobrego i edukowanie. Jeszcze dosadniej można określić to brakiem pazerności. Nie oznacza to, że posty o charakterze stricte marketingowym są absolutnie wykluczone, ale na pewno powinny być sporadyczne i nienachalne.

Niektórzy, szczególnie bardziej świadomi w kwestii marketingu, powiedzą o tym, że tak naprawdę piszę o czymś, co nazywa się CSR (ang. Corporate Social Responsibility, Społeczna Odpowiedzialność Biznesu). I rzeczywiście, wpisuje się to w oczekiwany obraz firmy i to nie tylko w Fediverse, ale generalnie na świecie. Jednak jest pewien szkopuł - to musi być prawdziwe CSR. Przykładowo, to świetnie, jeśli firma chwali się, że jej pracownicy zasadzili 100 nowych drzewek, które w przyszłości będą stanowić zalążek lasu. Natomiast, jeśli zaraz obok pojawią się doniesienia o złym traktowaniu klientów czy pracowników, to te działania wizerunkowe niespecjalnie uratują reputację. Tak samo krzywo patrzy się na CSR-owe starania firm, jeśli posty zawierają dobrą treść, ale widać, iż były pisane bez emocji, z użyciem utartych sformułowań, czasami nawet przez sztuczną inteligencję. To taka typowa PR-owa papka, która na Fedi też nie jest specjalnie oczekiwana, gdyż ludzie mają jej dosyć w innych miejscach.

Jak zatem powinna zachowywać się firma lub marka w takiej przestrzeni, jeśli nie chce zrazić do siebie społeczności? Przede wszystkim, warto się... przywitać. Tak po prostu, po ludzku wytłumaczyć, po co się tutaj jest, co się robi oraz będzie robiło i czego można oczekiwać po profilu. Generalnie posty wprowadzające (i ich przyklejenie do profilu) są dobrą praktyką w Fedi, ale uważam, że w przypadku podmiotów komercyjnych są szczególnie istotne, gdyż od nich zależy choćby pierwszy odbiór. I tak - brzmię teraz jak typowy PR-owiec (którym nie jestem), ale podejrzewam, że nie tylko ja tak mam, że gdy pierwszy post nowego profilu jest od razu "merytoryczny", to dziwnie mi to wygląda.

Na pewno docelowo lepiej przyjmowane będą konta, które będą oferowały coś ludziom bez ukrytej intencji. Oczywiście, ta intencja i tak istnieje (jest nią promowanie firmy), ale można ją motywować w dobry sposób i zwyczajnie pokazać się z przyzwoitej strony. Można to osiągnąć choćby poprzez dostarczanie wiedzy, edukowanie i wzajemną pomoc. Tak - wyobrażam sobie, że profile firmowe reagują nie tylko tam, gdzie mogą w pierwszej kolejności przypomnieć o sobie i swoich usługach, ale także zwyczajnie odpowiadając na pytania lub problemy. Pamiętajmy, że za profilami firmowymi stoją też zwykli ludzie, którzy chcą dobrze (no, chyba że nie chcą) i tym samym przynieść ze sobą ludzką twarz. Dotyczy to też np. dostarczania rozrywki, dzięki czemu można się czasem pośmiać. Oczywiście, z tym należy uważać - pomijając kwestie żartów "na krawędzi", warto wiedzieć, że tzw. RTM-y (ang. Real-Time Marketing) również męczą i nie powinny być nadużywane. Zwłaszcza, że czasami ich wykonanie na zasadzie "byle szybko wykorzystać mem, póki jest gorący" jest żenujące.

To oznacza, że nie można przenosić jeden do jednego zachowań z korporacyjnych serwisów społecznościowych, gdyż one po prostu nie zadziałają i tylko zniechęcą ludzi. Trzeba poczuć duch Fediverse - wzajemnej pomocy, szacunku, szczerości i zaangażowania w dyskusję (które tutaj są niekiedy bardzo rozbudowane). Trzeba zasłużyć sobie na zaufanie, pokazać czyste intencje i wspierać ludzi, a nie ich wykorzystywać. Oczywiście, są firmy oraz marki, które potrafią tak się zachowywać i chwała im za to. Są też takie, które mogą się tego nauczyć. Wówczas interakcja z ludźmi przestaje być nazywana "zarządzaniem społecznością" - staje się raczej "współpracą ze społecznością".

Pamiętajmy też, że niekoniecznie trzeba od razu zakładać konto firmowe - może być to też osoba wyznaczona do bycia twarzą przedsięwzięcia i która działa zawodowo, choć pod własnym nazwiskiem. Dobrym przykładem są rzecznicy prasowi, trener klubu, showrunner widowiska telewizyjnego czy prezes firmy. W tym przypadku zasada obowiązuje ta sama - niech to nie będzie papka PR-owa, tylko szczere dobre intencje i wsłuchiwanie sie w głos ludu. Warto też wprost napisać o tym, że tak - "to mój profil, ale tutaj będe pisał(a) o sprawach zawodowych".

Także to nie jest tak, że Fediverse nie jest w ogóle przychylne podmiotom komercyjnym - jest wobec nich nieufne i to z całkiem zrozumiałych powodów, które często się potwierdzają. Są nawet osoby, które powiedzą, że żadne firmy nie powinny istnieć w tej przestrzeni. Ja z kolei twierdzę, że jest na to miejsce, tylko trzeba dostosować swoje podejście. A jeśli już ktoś wnosi ze sobą pozytywny wkład w przestrzeń internetową lub jest gotowy to robić, to czemu nie spróbować?

Wykorzystanie zasobów sieci

Należy też przy tym mieć świadomość, jak działa Fediverse pod kątem technicznym. Niegdyś już o tym pisałem, ale w telegraficznym skrócie - jest to zbiór serwerów (instancji), z których każda udostępnia jakąś platformę (Mastodon, Misskey, Pixelfed, /kbin itd.) i te serwery łączą się ze sobą tworząc federację. Kto może mieć własny serwer? Każdy chętny. Znakomita większość instancji jest zarządzana przez osoby prywatne, które po prostu chcą zrobić miejsce dla społeczności lub samych siebie. Trochę tak, jak kiedyś z forami internetowymi, tylko o szerszym zakresie, gdyż każda instancja może komunikować się z innymi, wymieniając dane. Olbrzymią ilość danych.

To oznacza, że o ile każdy może mieć swój serwer, o tyle nie każdy serwer się do tego nadaje i poza wiedzą oraz umiejętnościami trzeba mieć środki na utrzymanie takiej maszyny wykupionej u wybranego hostingodawcy. Stąd osoby posiadające swoje instancje i utrzymujące na nim społeczność, zazwyczaj opierają się na zbiórkach pieniędzy, które nie tylko pozwalają pokryć koszty, ale także zbliżają do siebie użytkowników. Oczywiście, uczestnictwo w zrzutkach nie jest obowiązkowe. Jednak tutaj powstaje ważna kwestia, która ma związek z firmami, a więc podmiotami, które potencjalnie mogą zyskać (nawet niematerialnie i nie wprost).

Takie przedsiębiorstwo może dołączyć do gotowej instancji, na której jest już pewna grupa osób. Ma to przede wszystkim jedną zaletę - brak potrzeby przejmowania się kwestiami technicznymi. Dla niektórych to gigantyczny atut, a dla innych nieco mniejszy, natomiast na pewno jest to aspekt, który warto uwzględnić. Ale wziąć pod uwagę należy również wady, a tych jest całkiem sporo i są związane właśnie z kosztami. Otóż, firma dołączająca do gotowej instancji jest trochę odbierana jako "darmozjad" i intruz, który nie zamierza sprzymierzyć się ze społecznością, tylko ją wykorzystać i to ich kosztem. Jak można pokazać swoje dobre intencje, opisałem wyżej, natomiast pozostaje kwestia tego, że na pewno taki profil firmowy powinien w jakiś sposób wspomóc administrację serwera, zwłaszcza, że potencjalnie niesie ze sobą zainteresowanie, które zwiększy ruch, a więc też koszty. Tyle tylko, że trzeba jasno powiedzieć, że nawet chęć partycypacji w kosztach utrzymania maszyny i dobre zamiary mogą nie wystarczyć - niektórzy administratorzy zwyczajnie nie chcą pozwolić na komercyjne przedsięwzięcia, a na dodatek pod uwagę trzeba wziąć również regulamin danej instancji. Inną wadą tego rozwiązania jest domena instancji, która niekiedy może wyglądać niepoważne. Tym niemniej, jest to opcja warta zastanowienia przez np. mniejsze firmy, duże serwisy fanowskie, blogi i przedsięwzięcia "półprofesjonalne".

Inną drogą jest zainwestowanie we własną instancję. Jest to zobowiązanie i jeśli ktoś nie "czuje" klimatu Fediverse, to rzeczywiście na początku może mieć choćby problem dotyczący tego, jaką platformę chce hostować na swojej maszynie (o czym jeszcze będe pisał). Do tego dochodzą koszty - nawet instancja stricte dla paru wybranych profili (np. różnych oddziałów bądź przedstawicieli firmy) wymaga odpowiedniego serwera, który będzie kosztował od 100 do nawet 500 zł, dodając do tego inne wydatki związane z utrzymaniem, samodzielne aktualizacje oraz zarządzanie. Brzmi strasznie, ale można sobie uprościć sprawę, korzystając z takich usług jak np. Masto.host, który za odpowiednią opłatą będzie utrzymywał instancję Mastodona. I wydaje się, że jest to naprawdę dobre rozwiązanie.

Droga z własną instancją ma szereg zalet. Po pierwsze, nie obciąża zanadto zasobów istniejących, "prywatnych" serwerów (co nie jest do końca prawdą, ale to już urok federacji). Po drugie, pozwala utworzyć profil pod własną domeną, która dodatkowo identyfikuje konto (np. u nas jest to wilda@social.wildasoftware.pl). Po trzecie, pozwala na większą kontrolę i przechowywanie danych swojego konta faktycznie u siebie. Po czwarte, wygląda profesjonalnie i budzi nadzieję na poważne traktowanie Fediwersum lub - w niektórych przypadkach - zbudowanie wokół siebie własnej społeczności, gdyż przecież tylko koszty i czas stoją na przeszkodzie temu, aby przyjmować u siebie użytkowników. Wreszcie, można znaleźć piąty, dość zaskakujący powód - mianowicie, taką nową instancję łatwiej... zablokować. Brzmi bardzo źle i wiele osób powie "ale przecież ja właśnie chcę dotrzeć do ludzi!". Tak, to ważne - w kontekście tego, o czym pisałem wcześniej, powinno być już zrozumiałe, że ludzie chcą mieć wybór i jeśli nie zamierzają widzieć żadnych treści pochodzących od firmy lub marki, to mają prawo tak skonfigurować swoje środowisko. Należy to uszanować i burzenie się o to świadczy o tym, że jednak może trzeba przemyśleć swoją strategię związaną z Fediverse.

Warto jeszcze wrócić do tematu wielu profili i przyjrzeć się, jakie właściwie serwisy zdecydowały się na swoje instancje. Jest ich wiele, ale jako piękny przykład można podać brytyjską platformę medialną BBC, która, co prawda, jest instytucją publiczną, ale do Fedi weszła w dość pozytywnej atmosferze - eksperymentalnie, ale pozytywnie, tworząc konta dla paru swoich oddziałów. Z marek znanych w świecie internetowym jest też choćby Vivaldi, Mozilla czy Flipboard. Ten ostatni to zresztą ciekawy przykład, gdyż jako serwis agregujący treści, powoli uruchamia również możliwość śledzenia naprawdę uznanych serwisów prosto z poziomu swojego konta w Fediverse.

Własna instancja nie musi zawierać tylko jednego lub kilka profili "oficjalnych" - to może być również dobre miejsce dla pracowników danej firmy lub instytucji, aby czuli się zachęceni do prowadzenia swoich kont. Zresztą, do tego nawiązuje też wcześniej wspomniana inicjatywa Fedigov, która zakłada, że np. na instancji urzędu miasta swoje konto może mieć burmistrz, przewodniczący rady czy urzędnik. Zresztą, odwołując się do działań firmy Meta z końcówki 2023 roku - gdyby potraktować Threads jako instancję fediwersową (którą zresztą zamierza być, ale jest to dość drażliwy temat w tym światku), to przecież Mark Zuckerberg czy Adam Mosseri, podobnie jak oddziały korporacji są właśnie takimi profilami zarządzanymi na swojej instancji. Inna sprawa, że to akurat dość kontrowersyjne przykłady w kontekście wychodzenia do społeczności.

Ale w sumie... po co?

Wierzcie lub nie, ale pisząc ten tekst i robiąc potem korektę, zorientowałem się, że nie napisałem wprost o tym, po co w ogóle firma lub marka miałaby się interesować Fediwersum. Być może przemknęło mi przez myśl, że to oczywiste, ale tak naprawdę nie musi być. Zwłaszcza, że obecnie, nie ma co ukrywać, społeczność otwartej sieci jest mniejsza niż tych od dużych graczy. Tym niemniej, istnieją liczne zalety i warto je wziąć pod uwagę.

Po pierwsze, Fediverse jest oddane i angażujące się. To dobra społeczność, która się wspiera i marka, która działa razem z nią, może być uznana za "swoją". W mniejszym stopniu dotyczy to większych firm, ale w przypadku małych biznesów czy "ludzkich" influencerów może tak być. W dodatku, dzięki historii i specyfice Fedi, można znaleźć tutaj wartościowych ludzi, którzy nie istnieją w innym medium. W dodatku, nie ograniczając się do wybranej platformy - na tym polega siła federacji, że posty firmy mogą być przeglądane oraz komentowane na różnych serwerach, w różnych aplikacjach i to jest piękne.

Po drugie, może być to przyszłościowe rozwiązanie, a w przypadku własnej instancji jest to przejaw wspomnianych już własnych mediów. To oznacza, że w przypadku problemów dużych usługodawców społecznościowych, firma nie jest od nich zależna. A wcale nie jest oczywiste, czy w obliczu zmian prawnych i starań Unii Europejskiej w 2023 roku w celu ustandaryzowania przestrzeni internetowej oraz zapewnieniu większej swobody użytkownikom, duże portale takie jak Twit... X czy Facebook nie będą ograniczały swoich działań w tym regionie. Oczywiście, to zapewne dość surrealistyczny scenariusz, gdyż te serwisy nie pozbędą się tak dużych społeczności same z siebie, ale nadal pozostają dość... ciekawe zachowanie takich osób, jak np. Elon Musk.

Po trzecie, to ten czas, kiedy poważne wejście w Fediverse jest traktowane jako innowacyjne i trochę eksperymentalne. I to raczej w pozytywnym aspekcie, przynajmniej w zakresie organizacji pozarządowych. Czy tak byłoby w przypadku firm? Wszystko zależy od zachowania, któremu wcześniej poświęciłem tak dużo miejsca, ale nie jest wykluczone, że wokół takiego wejścia pojawiłoby się sporo szumu. Jeśli wszystko odbędzie się w pozytywnej atmosferze, to taka organizacja może nie tylko pomóc sobie i zyskać opinię pioniera, ale także przyczynić się do rozrostu Fediverse, nowych instancji itd.

Po czwarte, pojawienie się firm i marek w otwartych sieciach, mogłoby zmusić komercyjne serwisy do zastanowienia się nad sobą i swoimi praktykami. Choć przyznaję, że to akurat argument dość utopijny, bo prędzej spodziewałbym się buńczusznych zapowiedzi przedstawicieli Big Techu.

Po piąte, takie konto w Fediverse można zintegrować ze swoją stroną, umieszczając treści z jednego miejsca i odbierając komentarze z wielu miejsc. Przykładem może być blog, do którego zresztą też istnieją rozwiązania w otwartej sieci, naturalnie integrujące się ze społecznością. Można też zintegrować to samemu, czego strona, którą czytacie, jest przykładem, gdyż na dole czekają na Was komentarze właśnie z Fediverse.

Także argumenty za wejściem do Fediverse istnieją i mimo wielu niewiadomych po drodze, warto się nad tym zastanowić. Tym bardziej trzeba wiedzieć, jak się do tego przygotować.

Jaką platformę wybrać?

Czujesz się zachęcony do tego, aby spróbować swoich sił w prowadzeniu profilu firmowego lub innej komercyjnej działalności w Fediverse? Czas pomyśleć o platformie, z której chcesz korzystać. Tutaj ponownie, nie wdając się w szczegóły, które są opisane w innych przywoływanych tekstach na tym blogu - z poziomu każdej aplikacji opartej o ActivityPub Twoje konto będzie widoczne w innych aplikacjach tego typu. Natomiast możliwości publikowania, które będziesz miał, będą inne.

Najpopularniejszą opcją jest Mastodon, czyli platforma mikroblogowa. Jest ona bardzo dobra do prowadzenia społeczności i stworzenia miejsca dla osób, które chcą mieć swoje konto w Fediverse. Jednak czy jest najlepsza do działalności społecznościowej dla firmy? Jest to dyskusyjne, choćby ze względu na to, że to bardzo duże oprogramowanie, a niekoniecznie jego charakterystyka odpowiada procesowi, w jakim przedsiębiorstwo umieszcza teksty. Zauważmy, że mimo zachęt do bycia interaktywnym, nie da się ukryć, iż marki raczej częściej publikują, aniżeli odpowiadają na publikacje. Co za tym idzie - Mastodon może być "armatą na mrówkę". Jednak jego korzyści również są istotne - to najbardziej rozpowszechniona aplikacja w świecie Fedi, posiadające API wykorzystywane w niektórych narzędziach (np. Buffer), skupiające wokół siebie największe zainteresowanie techniczne i np. taki Masto.host {https://masto.host/} świadczy usługi właśnie w tym obszarze. Krótko mówiąc - mając Mastodona, wiele integracji stanie się prostsze, choć będą też aspekty, które będą trochę irytowały.

Inną możliwością jest także omawiany u nas /kbin, który jest z kolei odpowiednikiem Reddita czy Wykopu, a więc stanowi agregator treści. Tutaj warto wspomnieć, że w chwili, gdy piszę te słowa, jest to cały czas oprogramowanie dojrzewające - już zaawansowane i gotowe do użycia, ale jeszcze będzie lepsze i kompletne. Tym niemniej, wydaje się trochę prostsze w zarządzaniu na serwerze oraz bardziej dostosowane do publikowania. Użytkownicy mogą obserwować zarówno profil firmy, jak i jej magazyn ("zbiornik" na posty o danej tematyce, odpowiednik subreddita). W gratisie platforma oferuje ładne przedstawienie komentarzy.

Kolejną opcją jest GoToSocial, który wyróżnia się przede wszystkim prostotą - to chyba najlżejsze z przedstawionych rozwiązań i wymagające najmniej, jeśli chodzi o sprzęt serwerowy. Oczywiście, nie będzie tak funkcjonalne, jak inne rozwiązania fediwersowe, ale do publikowania całkowicie wystarczy.

Oczywiście, systemów jest znacznie więcej - Misskey, Firefish, Lemmy, Pixelfed to również platformy, które warto zgłębić. Tym niemniej, nie wydaje mi się, aby wśród swoich atutów dysponowały akurat takimi, które będą istotne szczególnie dla profilów firmowych. Tym niemniej, istnieje szansa, że się mylę - pamiętajcie, aby zajrzeć w komentarze pod tekstem. No i ciągle przypominam, że ze mnie taki specjalista od działań marketingowych, jak pająki od aportowania.

Przygotowanie do obsługi kont w Fediverse

Osoby prowadzące profile społecznościowe marek w korporacyjnych mediach społecznościowych mniej więcej wiedzą, z czym to się wiąże - ustalanie strategii, narzędzia do publikacji, śledzenia statystyk itd. Czy coś się zmienia w przypadku Fediverse? Owszem.

Przede wszystkim, Fediverse nie jest nastawione na wykręcanie cyferek. Z jednej strony wynika to z charakteru i powodów powstania tego "światka", a z drugiej - rozproszona struktura federacji utrudnia zbieranie twardych danych. Oczywiście, nadal mamy możliwość podglądu, ile razy nasz post został powielony czy polubiony (co tutaj nie ma takiego znaczenia ze względu na brak algorytmu), a także zobaczymy komentarze, ale nie ma choćby licznika wyświetleń, gdyż z założenia nie jest potrzebny. Przecież widzimy, ile osób obserwuje nasz profil, a także ile osób obserwuje użytkowników, którzy podali naszą wiadomość dalej - na tej podstawie możemy oszacować liczbę prezentacji na osi czasu. Jeśli takie podejście do sprawy jest dużą przeszkodą, to niestety - być może Fediverse nie jest dla Was. Tak, jak pisałem, tutaj liczą się nie statystyki, tylko interakcja i "czucie" społeczności. Nie policzymy tutaj konwersji sprzedaży, gdyż twórcy świadomie nie dają takich narzędzi. Dlatego powtarzam - wejście w Fediverse to kwestia raczej pozytywnego i szczerego PR-u, a nie kolejny kanał handlowy.

To oznacza, że być może trzeba przemyśleć treść oraz formę swoich postów i tutaj wygrywają marki, które naturalnie są pozytywne - wówczas w Fediverse mogą komunikować się podobnie, jak w "dużych" serwisach społecznościowych, wykorzystując do tego takie narzędzia, jak choćby Buffer, który umożliwia integrację z Mastodonem. Oczywiście, świetnie byłoby też delegować osobną osobę do zajmowania się Fediverse, ale wiadomo - jest to dodatkowy koszt, który nie zawsze może być poczyniony, szczególnie przez małe lokalne przedsiębiorstwa. Z drugiej strony - właśnie takie biznesy lepiej pasują do ekosystemu Fediverse, w związku z czym będą czuły się tutaj lepiej. Liczy się bowiem pomysł na siebie, a nie zasobność portfela przy kupowaniu reklam.

W przypadku instancji Mastodona warto zweryfikować swój profil. I spokojnie - nie oznacza to płacenia za żadne "ptaszki", przesyłania dokumentów do administratora czy dodatkowe formalności. Ta platforma podchodzi do sprawy inaczej i zdaniem wielu - uczciwie. Jeśli bowiem zależy nam na pokazaniu, że jesteśmy własnie tą firmą, za którą się podajemy, to dowodem powinno być potwierdzenie, iż odpowiedni adres internetowy należy do nas. I tak właśnie sie to robi - wystarczy np. na swojej stronie firmowej wkleić odpowiedni tag HTML, aby Mastodon skojarzył profil z tą witryną, udowadniając, że prowadzi je ta sama osoba lub organizacja. Trochę więcej pisałem o tym w tutorialu.

Na koniec warto nadmienić, że wejście do Fediverse przez firmę to koszty, o rozmiarze zależnym od tego, czy wspieramy lokalną instancję, czy zarządzamy swoją. Tym niemniej, osoby, które powiedzą, że przecież konto na Facebooku czy Twitterze jest za darmo, muszą sobie uświadomić, że raczej nie do końca tak jest - jeśli ktoś prowadzi biznes wymagający szerokiej społeczności, to musi tam zapłacić za "profesjonalne" lub zweryfikowane konto, a także może (a nawet powinien) korzystać z opcji reklamy. W konsekwencji, opłaty mogą być podobne. Oczywiście, jeśli chodzi o zyski, to każdy musi odpowiedzieć sobie na to pytanie sam, ale jeszcze raz powtórzę - działalność w Fediverse nie należy traktować jako kanał dystrybucyjny.

Podsumowanie

Zdaję sobie sprawę, że niektórzy znienawidzą mnie za ten artykuł. Inni wyśmieją. Jeszcze inni nic nie zrobią, bo wolą kolejny raz obejrzeć 1670 lub po prostu temat ich nie interesuje. Ale liczę na to, że udało mi się nie tylko przekazać swoje refleksje (niektórzy pewnie zażartują, że faktycznie są to uROJenia), a więc "wygadać się", ale też odpowiedzieć na zadane lub niezadane pytania różnych osób, które zastanawiają się, czy warto. Otóż - warto przynajmniej się zainteresować. Ale też mieć świadomość, że to specyficzne medium, do którego trzeba się dostosować, a nie zmuszać je do ukształtowania na nasze potrzeby.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Standard kodowania - czy jest potrzebny? https://wildasoftware.pl/post/standard-kodowania-czy-potrzebny?ref=rss https://wildasoftware.pl/post/standard-kodowania-czy-potrzebny?ref=rss Thu, 11 Jan 2024 17:30:00 +0000 Osoby czytające tytuł tego artykułu i troszeczkę znające się na rzeczy mogę popukać się w głowę - jak to "czy potrzebny"? Przecież wiadomo, że potrzebny! Tak - faktycznie pytanie można by było sformułować inaczej, na przykład "jak bardzo jest potrzebny". Ale po kolei.

Kod oprogramowania można pisać na różne sposoby i jest to rzecz, która ewoluuje przez całą karierę programisty. Od najprostszych kontrukcji, na których koder uczy się w ogóle fachu, poprzez pisanie większych aplikacji w nieefektywny i nieustrukturyzowany sposób, aż do wręcz przesadzonych konstrukcji i znalezienia złotego środka. Jeśli mówimy nie tylko o tym, czy kod działa, ale także jak prezentuje się jego jakość, bierze się pod uwagę kilka czynników, które szczególnie zyskują na znaczeniu w obliczu pracy zespołowej. I być może nie uwierzycie, ale jednym z tych czynników jest... estetyka. Tak, jak interfejs użytkownika może być ładny lub brzydki, użyteczny lub nie, tak kod może być napisany ładnie lub brzydko.

I na tym się dzisiaj skupimy, gdyż w przeciwieństwie do wielu dziedzin życia, estetyka kodu źródłowego może być opisana standardem. Oczywiście, nie tylko ona gra rolę w tym, czy uznamy kod za dobry jakościowo - bardzo ważne, a w konsekwencji dużo ważniejsze jest architektura, w tym projekt klas i podatność na rozszerzenie. Jest to temat bardzo, bardzo szeroki, jednak od czegoś trzeba zacząć, najlepiej prostego. Stąd zapraszam na rozważania o urodzie linijek składających się na źródła oprogramowania.

Czym jest standard kodowania?

Jest to dokument lub zbiór wskazówek z omówieniem zasad pisania poszczególnych instrukcji kodu w danym języku programowania lub technologii. Przy czym rozumiem, że nadal można to rozumieć dwojako i na różnym poziomie szczegółowości. Dlatego, bazując na przykładach, można powiedzieć, że standard kodu może określać choćby:

  • w jakim miejscu stawia się klamrę otwierającą ciało metody czy klasy,
  • jakie odstępy stosować zarówno przy zagnieżdżaniu kodu, jak i podczas pisania instrukcji,
  • jakimi zasadami kierować się przy nazywaniu klas lub metod,
  • jaka jest kolejność metod i pól w klasach.

Te zasady określają zatem zarówno estetykę kodu, jak i zasady nazewnictwa. Jednak głównym celem nie jest to, aby "bebechy" oprogramowania prezentowały się pięknie i historycy sztucy w przyszłości zachwycali się bogactwem smaczków. Przede wszystkim przyczyną ustalenia wspólnego standardu kodu jest potrzeba unifikacji kodu pisanego przez różnych programistów. Wspominałem o tym, że coraz szerzej zakrojona praca zespołowa wymaga dodatkowych ustaleń i porządku. Wyobraźcie sobie bowiem jeden program implementowany przez trzy osoby, z których każda pisze w zupełnie inny sposób - jeden stawia klamry tak, drugi metody rozpoczyna wielką literą, a trzeci nie używa tabulatorów do odstępów, tylko spacji. Powstaje chaos, który nie tylko brzydko wygląda, ale przede wszystkim nie pozwala szybko zorientować się w programie i poznać szczegółów implementacji. Sami zresztą możemy tego doświadczyć, próbując czytać obcy amatorski kod lub nawet samego siebie sprzed kilku lat, kiedy to doświadczenie było mniejsze. W przypadku nazewnictwa mówimy o dodatkowym aspekcie, którym jest idea samodokumentującego się kodu. Jest to osobny temat, ale kluczowe jest to, że bez żadnych reguł, każdy programista pod kątem "słowotwórstwa" będzie znacząco odbiegał od innych (na zasadzie "przecież ja rozumiem, co tutaj jest napisane, inni też się domyślą"). Oczywiście, nie da się tego ustandaryzować całkowicie, ale cenne jest wskazanie, kiedy stosujemy notację PascalCase, a kiedy camelCase, kebab-case czy snake_case, jakich przedrostków (i czy w ogóle) używamy itd.

Czym grozi brak standardu kodowania?

Poniekąd wskazaliśmy to sobie w poprzednim akapicie - brak standardu oznacza, że każdy pisze kod "po swojemu", pełny wiary w dobrą wolę i to, że wszyscy rozumieją pisany tekst tak, jak on(a). Aby było jasne, to oczywiście - pełna zgodność w zespole i podobny styl można wypracować bez żadnych standardów. Może się też okazać, że wszyscy członkowie zespołu tworzą kod w jednakowy sposób, naturalnie się dostosowując. Jednak jest to szczególnie szczęśliwy zbieg okoliczności, zakładający też równy poziom doświadczenia całego składu. Natomiast tak, jak o umowach mówi się, że są "na trudne czasy", tak to samo można powiedzieć o standardzie kodu.

Nie jest niczym złym, że w zespole są różne style pisania, o ile te odmienności nie są znaczące i zrozumiałe tylko dla wybranego programisty. Natomiast dość prosto można znaleźć słuszne powody, dla których styl powinien być jednak zunifikowany. Jeśli tak nie jest, to możemy doprowadzić do:

  • dłuższego czasu potrzebnego na zrozumienie takiego kodu i skorzystania z niego,
  • dłuższych przeglądów kodu, co zaburza pracę nad nową funkcjonalnością,
  • nieporozumień i złego użycia wzajemnej pracy lub wręcz duplikowania jej (np. poprzez napisanie kodu, który już jest w programie, ale w innym module i pod inną nazwą),
  • problemów ze scaleniem kodu i zgłaszaniem konfliktów, które tak naprawdę nie istnieją (np. problemy z białymi znakami),
  • dłuższym czasem wprowadzenia i zadomowienia się nowych programistów, którzy dopiero zaczęli pracować w danym projekcie.

W dalszej perspektywie problemy z unifikowaniem pracy mogą doprowadzić do złego oprogramowania, którego w dodatku stworzenie zabierze więcej czasu niż zakładano. Ale to nie wszystko - w skrajnych przypadkach dochodzą konflikty w zespole, konieczność spotkań wyrównujących lub pisanie dodatkowej dokumentacji, komentarzy w kodzie i przede wszystkim frustracja.

Kiedy warto i jak stworzyć standard kodowania?

Oczywiście, standardy kodowania spotyka się w środowiskach, gdzie odbywa się praca zespołowa. Dotyczy to przede wszystkim firm zajmujących się oprogramowaniem, ale też np. społeczności, które wspólnie opracowują kod konkretnego software'u. Mam tutaj na myśli zwłaszcza grupy utrzymujące projekty opensource'owe, gdzie przypadkowość dostarczanego kodu może być jeszcze większa, chyba że jest to trzymane w ryzach przez coś w rodzaju "komitetu". Wątpliwe jest z kolei, czy osobny standard kodowania jest potrzebny indywidualnym programistom (np. freelancerom pracującym samodzielnie) oraz grupom, które współpracują ze sobą przez krótki okres nad projektami uczelnianymi czy szkolnymi. Natomiast to nie oznacza, że w tych przypadkach można robić, co się chce - warto trzymać się standardów, ale zewnętrznych, o których jeszcze sobie wspomnimy.

Pozostaje zatem pytanie, jak tworzyć taki standard. Wcześniej użyłem słowa "dokument" i rzeczywiście na myśl przychodzi konkretny plik tekstowy, w którym zostaną opisane i zawarte wszystkie reguły. W Wilda Software też kiedyś tak do tego podchodziliśmy, ale po latach zaczęliśmy mieć coraz więcej wątpliwości, czy to dobre postępowanie. Stworzenie odpowiedniego dokumentu jest pracochłonne i niekoniecznie spowoduje, że wszyscy łatwo odnajdą w nim to, co powinni. A trzeba przyznać, że standard kodu to nie książka z dobrą fabułą, którą się chłonie - ludzi niekoniecznie interesuje historia powstania poszczególnych reguł (chyba że w formie ciekawostek, które jeszcze mocniej pozwalają zapamiętać szczegóły), ale konkretne wytyczne, do których zaglądają w razie potrzeb i szybko je znajdują. Dlatego od pewnego czasu nasz standard jest tworzony w formie przykładów, kilku większych fragmentów kodu, który jest bezsensowny funkcjonalnie, ale pokazuje idealny kod pod względem stylistycznym. Mamy wrażenie, że napisanie wytycznych w takiej formie jest nie tylko szybsze, ale i łatwiej przyswajalne, gdyż można wzrokowo porównać poszczególne elementy z własnym kodem. Natomiast to każdy zespół musi wypracować sobie sam.

Niezależnie od tego, czy piszemy pełny tekst, czy przykład, bez dodatkowych opisów się nie obejdzie, szczególnie przy regułach nazewniczych. Tam, gdzie to możliwe, warto też krótko skomentować powody, dla których poszczególne wytyczne zostały wprowadzone. Z jednej strony dlatego, że szczególnie młodzi programiści lubią dopytywać "a dlaczego, a po co", gdy weryfikują swoją teoretyczną wiedzę z praktyką. Z drugiej - tak, jak pisałem, czasem pozwala to łatwiej zapamiętać pewne fragmenty. Przypomnijcie sobie, kiedy nauka historii była łatwiejsza - gdy opieraliśmy się na samych datach i suchych opisach czy gdy dowiadywaliśmy się różnych anegdot o bitwie pod Grunwaldem. Tutaj taką może być fakt, dlaczego polecamy ciało każdej pętli czy instrukcji warunkowej otaczać nawiasami klamrowymi, nawet, gdy to tylko jedna linijka - przypomnijmy sobie historię z błędem w SSL w kodzie Apple'a. To przy okazji dobry przykład, który pokazuje, że odpowiedni standard potrafi zaoszędzić różnych perypetii (nawet, jeśli opisywana sytuacja to po prostu zwykły, choć poważny błąd).

Warto również pamiętać o tym, że w różnych edytorach kodu istnieją mechanizmy, pozwalające do pewnego stopnia kontrolować pisanie zgodnie ze standardem. Są to zwykle pliki konfiguracyjne do wgrania lub konkretnie ustawienia. W pewnych przypadkach to również może być odpowiednia "dokumentacja" specyfiki pisania kodu w danym zespole.

Ostatnia rzecz warta uwagi w tej sekcji - jak już wcześniej zasugerowałem, standard kodu nie jest uniwersalny dla każdego języka programowania. Może być, ale zwykle nie jest, gdyż każda technologia wiąże się z pewnymi wewnętrznymi standardami, na których powinno się opierać ten swój, dostosowany do danego zespołu.

Jak ściśle trzymać się standardu?

To dobre pytanie. Oczywiście, narzuca się odpowiedź "w pełni" i przez pewien czas tak do tego podchodziliśmy w zespole podczas przeglądów kodu. Jednak, jak ze wszystkim w życiu, warto zachować umiar.

To nie jest tak, że osoba nietrzymająca się standardu jest od razu godna potępienia i ma spadać sobie do wulkanu (pozdrowienia dla Maćka i Tymona). Tak, jak pisałem, czasem różnice stylistycznie nie są na tyle duże, aby zostały negatywnie rozpatrzone. Z punktu widzenia harmonogramu projektu też nie ma sensu robić drobiazgowego przeglądu kodu tylko pod tym kątem - można przyjąć założenie, że uwagi dotyczące estetyki powinny raczej być od razu zauważalne lub stanowić wyraźne zagrożenie w dalszym rozwoju oprogramowania. Warto natomiast przykładać większą wagę do przeglądów programistów młodych, jeszcze nieukształtowanych, aby wyrobili sobie poprawne nawyki, niebędące kulą u nogi w dalszej współpracy.

Dodatkowo, nie należy zapominać, że standard nie musi być zacementowany - to naturalne, że wraz z rozwojem technologii, umiejętności programistów czy po prostu nowych doświadczeń, pewne wytyczne mogą ulegać zmianie. Dlatego nie zawsze odstępstwa od narzuconych reguł należy traktować jako błędy i wskazywać je niczym na sprawdzianie - dobrze jest od czasu do czasu spojrzeć na nie pod kątem tego, czy pewne zmiany w standardzie mogą w czymś pomóc zespołowi lub projektowi.

Standardowe standardy dla języka programowania

Wspomniałem wcześniej o tym, że swój standard należy opierać na zewnętrznych wytycznych, charakterystycznych dla danej technologii. Niektórzy pewnie powiedzą, że w ogóle powinno się opierać wyłącznie na światowych standardach, gdyż... są światowymi standardami. Bez względu na to, którą szkołę reprezentujemy, warto zapoznać się z tym, jakie są "oficjalne" wskazówki.

W przypadku języka PHP jest to PSR, czyli PHP Standards Recommendations, który jest nie jednym dokumentem, ale ich zbiorem z różnymi wytycznymi. W niektórych momentach widać, że jest mocno osadzony w swoich korzeniach związanych z językiem C/C++ i to są elementy, które dostosowaliśmy do swoich potrzeb w Wilda Software. Tym niemniej, tak, jak pisałem, warto zerknąć na takie propozycje uznawane za ogólnie obowiązujące.

Nie zawsze dla jednego języka istnieje jeden zestaw oficjalnych wytycznych. Java jest tak popularnym i "korporacyjnym" językiem programowania, że stała się obiektem zainteresowania różnych firm, takich jak Google czy Oracle, z których każdy utworzył swój standard (choć ten ostatni ma już swoje lata, a nawet wieki). W sieci można znaleźć też standardy opracowane np. przez Uniwersytet Hawajski i wiele innych instytucji.

Nie inaczej jest z każdym innym językiem - Pythonem, JavaScriptem i kolejnymi. Niekoniecznie należy trzymać się ich w pełni, natomiast warto wiedzieć, że będąc jak najbliżej "bazy", jednocześnie będziemy bliżej globalnych standardów.

W Internecie możemy szukać informacji o tym zagadnieniu pod terminami coding standards czy też coding guidelines.

Czy tylko kodowanie potrzebuje standardu?

Najczęściej mówi się o standardzie kodu, ale to nie jest jedyna kwestia, która powinna być uregulowana, co zresztą widać po powyższych odnośnikach do światowych standardów. W Wilda Software funkcjonuje też np. standard tworzenia schematów bazodanowych, który być może jest nawet ważniejszy z uwagi na to, iż modyfikacja schematu powoduje często więcej zamieszania niż refaktoryzacja kodu. Poza tym umiejętność szybkiego odnalezienia się w dużych relacyjnych bazach i zapytaniach do nich jest równie cenna jak umiejętność poruszania się po kodzie.

Innym przykładem są wytyczne tworzenia dokumentacji, choć w tym przypadku warto pamiętać, iż każdy dokument może wymagać specyficznego podejścia ze względu na opisywany projekt bądź odbiorców. Tym niemniej, nie zaszkodzi wypracować sobie choćby wspólnego szablonu dokumentu, np. dotyczącego tworzenia wymagań czy architektury oprogramowania.

Wreszcie, bywają również nie tyle standardy, co procedury postępowania w różnych przypadkach, zarówno technicznych (wdrażanie nowej wersji na serwer), organizacyjnych (procedura przyjęcia nowej osoby w zespole) czy biznesowych (wytyczne dot. korespondencji z klientem).

Podsumowanie

Standardy kodowania to ciekawy temat, choć w gruncie rzeczy prosty - ma zapobiec "rozjeżdżaniu się" kodu pisanego przez różne osoby i tym samym ułatwiać tworzenie oprogramowania. Natomiast ten obszar łączy się też z tworzeniem dokumentacji kodu, co jest znacznie szerszym zagadnieniem. Należy jednak od czego zacząć i małymi kroczkami polepszać swój wasztat, gdyż standardy również temu służą.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Blog - podsumowanie roku 2023 https://wildasoftware.pl/post/blog-podsumowanie-roku-2023?ref=rss https://wildasoftware.pl/post/blog-podsumowanie-roku-2023?ref=rss Wed, 27 Dec 2023 18:00:00 +0000 W chwili, gdy piszę te słowa, a Wy zobaczyliście powiadomienie o tym, że jest nowy artykuł (np. dzięki czytnikowi RSS), kończy się rok 2023. Pod pewnymi względami dobry, pod pewnymi zły, a pod jeszcze innymi taki sam, jak każdy inny. To czas różnych podsumowań, na których wszelkie serwisy i firmy robią obecnie "markieting" i starają się dotrzeć do żądnych informacji odbiorców. My od razu uprzedzamy, że w poniższym tekście nie będzie niczego rewolucyjnego i takiego, że nie możesz tego przegapić. Ot, przywołamy ranking najchętniej czytanych artykułów, napiszemy parę słów o tym, co było i o dalszych planach. Czyli generalnie to, co zrobiliśmy na koniec poprzedniego roku, tylko na innej platformie.

Zanim przejdziemy do tego, co wiele osób bardzo lubi (a więc cyferek i rankingów), opowiedzmy sobie o tym, co najważniejszego stało się w minionych 12 miesiącach. Przede wszystkim:

  • pojawiły się 42 nowe teksty (nie licząc tego, który właśnie czytacie),
  • w międzyczasie pojawił się artykuł nr 100,
  • utrzymaliśmy regularność publikowania w czwartki o 17:30, choć w pewnym momencie zmieniliśmy częstotliwość (o czym zaraz),
  • pojawiła się możliwość komentowania postów, wykorzystująca mechanizm serwisu społecznościowego i Fediverse,
  • założyliśmy własną instancję i profil w Fediverse,
  • nasze artykuły trafiały do kilku newsletterów i agregatorów linków (za co dziękujemy, szczególnie SOLID.Jobs),
  • pierwszy raz (i mamy nadzieję, że nie ostatni) połączyliśmy siły z Just Join IT przy jednym z tekstów,
  • Kuba odkrył, jak generować grafiki nagłówkowe w DALL-E 3 i teraz wszyscy muszą oglądać jego "dzieła".

(Oczywiście, sporo pozytywnych rzeczy działo się też w samej firmie, ale dzisiaj skupmy się na działalności blogowej).

Zacznijmy może od rzeczy najważniejszej - na przełomie sierpnia i września zmieniliśmy harmonogram publikowania z "co czwartek" na "co drugi czwartek". Było to spowodowane prozaiczną rzeczą - blog daje nam i (mamy nadzieję) Wam dużo przyjemności oraz wiedzy, ale zabiera trochę czasu, który jest potrzebny na standardową pracę firmy. Pamiętajmy, że Wilda Software tworzy oprogramowanie - działalność publicystyczno-poradnikowa jest kwestią poboczną, wytchnieniem od deadline'ów, choć ten czwartek niejako takim deadlinem też jest. Zdajemy sobie sprawę, że prawdopodobnie nie powinniśmy tak pisać - zapewne wskazane byłoby udawanie, że to przemyślana i skrupulatnie zaplanowana strategia oraz wypełnianie celów biznesowych, okraszona efektownym zdjęciem zaplanowanym przez dział PR. Ale zamiast tego wybieramy szczerość, bo uważamy, że tak trzeba - tak, tekstów jest mniej niż rok temu, gdyż zwyczajnie inaczej musieliśmy podzielić naszą uwagę. Przepraszamy i mamy nadzieję, że to rozumiecie. Na pewno klienci (obecni i przyszli) powinni być z tego zadowoleni :)

W pierwszej połowie roku wprowadziliśmy też system komentarzy. Do tej pory trochę się przed nim wzbranialiśmy, gdyż celem bloga jest przede wszystkim szerzenie wiedzy, natomiast dodatkowe "atrakcje" w komentarzach, które wymagałyby moderacji, niekoniecznie z tym współgrają, pomijając już kwestie techniczne. Natomiast biorąc pod uwagę fakt, że nasze zainteresowanie Fediverse (a więc m.in. Mastodonem) się utrzymało, postanowiliśmy połączyć jedno z drugim i nie tylko wprowadzić system oparty o posty z "mamuciego" medium, ale też opisać cały proces i to nawet w dwóch częściach. Dodatkowo, pojawił się u nas szybki poradnik rozpoczęcia swojej przygody z Mastodonem oraz rzecz o innym stowarzyszonym systemie - /kbinie. Rzecz warta uwagi tym bardziej, że w chwili, gdy piszemy to słowa, w Unii Europejskiej pojawił się portal Threads, który testuje połączenie się z Fediverse, choć akurat ta integracja jest dość... kontrowersyjna.

Jeśli chodzi o rozkład opublikowanych treści, to w ogólności przedstawia się on tak:

  • 8 z obszaru zarządzania
  • 7 z obszaru oprogramowania i architektury
  • 6 z obszaru mediów i społeczności internetowych
  • 5 z obszaru cyberbezpieczeństwa
  • 5 tekstów bardziej publicystycznych
  • 5 z obszaru Linuxa, sieci i/lub serwerów
  • 3 z obszaru ogólnej informatyki
  • 2 z trudno pomijalnej w tym roku dziedziny sztucznej inteligencji
  • 1 dotyczący nowych technologii (o komputerach kwantowych)

Jak widać, staraliśmy się krążyć pomiędzy niektórymi obszarami, aby tematy poruszane na blogu były bardziej zróżnicowane. Nawiasem mówiąc, powyższa lista pokazuje też jedną z rzeczy, które chcemy zmienić w nowym roku - lepszy podział na kategorie na stronie. Ten obecny nie jest zły, ale z biegiem czasu pewne teksty wymagają aktualizacji przypisania, aby łatwiej byłoby je odnaleźć.

Warto może też uchylić rąbka tajemnicy, w jaki sposób pojawiają się pomysły na kolejne materiały. A źródła tych idei są dosyć różne. Są takie teksty, które mają charakter edukacyjny i wynikają również z naszego wykształcenia oraz chęci dzielenia się ze światem "sekretami" informatyki - to przyczyna, dla której napisaliśmy m.in. o systemie dwójkowym. Bywają tematy, które po prostu trzeba poruszyć na blogu IT i wystarczy znaleźć odpowiedni pretekst - w taki sposób pojawiła się u nas tematyka testowania. Niektóre pomysły rodzą się naturalnie i wynikają z biegu wypadków, jak choćby próba oceny "przydatności" MacBooka - tekst powstał przy okazji zmiany komputera przez niżej podpisanego, który stwierdził, że nie może przepuścić takiej okazji na materiał, w którym trochę się powyżywa na produkcie Apple'a, aczkolwiek pewne rzeczy pochwali. Niektóre artykuły mają źródło w dyskusjach internetowych i potrzebach wyrażonych przez społeczność lub nawet członków zespołu - w ten sposób pojawił się filozoficzny tekst o tym, kim jest programista. Zaskakująco często inspirację dają też rozmowy biznesowe i techniczne, które ujawniają potrzebę edukacji klientów oraz użytkowników w pewnych obszarach - przykładem jest tekst porównujący rooting oraz routing, który de facto zrodził się pomyłki językowej rozmówców, ale to przerodziło się w pomysł na cały artykuł. Nie ukrywamy, że bywają też tematy, które powstają nie tylko z zabawy, ale także pewnego wpasowania się w trendy i mrugnięcia okiem do pewnych osób i tak - dobrze myślicie, że do tej kategorii wpada tekst o żabach. Wreszcie, są takie artykuły, które po prostu niżej podpisany chce napisać, nie patrząc na zapotrzebowanie - tak było z m.in. szachami.

Chcieliśmy w ten sposób Wam przekazać, że o ile faktycznie czasem zdarzy nam się tekst mający w dużej mierze "zadanie marketingowe", o tyle, w większości wypadków są to artykuły z ideą "ciekawego tematu" lub "o, to się komuś przyda" (nawet nam podczas rozmów wewnątrz lub na zewnątrz zespołu). Bywa też tak, że coś, co teoretycznie nie powinno się dobrze wypozycjonować, zyskuje popularność. W mijającym roku pojawiły się również tematy, które planowaliśmy poruszyć, ale w końcu z nich zrezygnowaliśmy - czasem z rozwagi i niechęci do pisania o czymś, co mogłoby okazać się niestosowne lub "pod publiczkę", a czasem z braku pomysłu na interesujące podejście do artykułu. A bywały też obszary, do których wrócimy w momencie, kiedy będzie więcej czasu na solidny research i przygotowanie się, gdy w 2023 roku po prostu tego zabrakło.

Wreszcie, zanim przejdziemy w końcu do rankingów - co planujemy zmienić w 2024 roku? W zeszłym roku plan mieliśmy jeden i dotyczył regularności pisania. Udało się to, nie licząc zmniejszenia tempa od początku jesieni, co już tłumaczyliśmy. W tym roku jednym z planów jest pochylenie się nad estetyką bloga i strony - wiemy od Was, że czytelność nie jest najlepsza i zwyczajnie mimo ciekawej treści, forma graficzna pozostawia wiele do życzenia. Ten temat wiąże się jednak z większymi zmianami layoutu na samej stronie, które mamy na horyzoncie, ale które też muszą często ustępować zwyczajnej pracy. Tak czy inaczej, wiedzcie, że Wasze uwagi przyjmujemy z pokorą i sami rozumiemy, iż pewne modyfikacje estetyczne są potrzebne. Kiedy się pojawią? Czas pokaże, ale naprawdę mamy nadzieję, że stanie się to w 2024 roku.

Uwagi dotyczące rankingów

Rozpocznijmy zabawę związaną z podsumowaniem artykułów, które w 2023 roku pojawiły się na blogu. Dane pochodzą z 27 grudnia 2023 r. z okolicy godziny 17:00.

Podzieliliśmy nasze zestawienia na kilka kategorii i większość z nich opiera się na wyświetleniach, a konkretnie z liczby unikalnych odwiedzin. Podobnie, jak w zeszłym roku, liczby będziemy pokazywać w formie procentowego udziału danego artykułu spośród wszystkich wyświetleń danego typu. Będziemy też podawać daty publikacji poszczególnych materiałów, aby móc ocenić, czy duża liczba odtworzeń nie wynika czasem z faktu, iż tekst powstał na początku roku i zwyczajnie było więcej czasu, aby liczby poszły do góry.

Najdłuższe i najkrótsze teksty

Zaczniemy jednak od czegoś, co bywa obiektem żartów wewnątrz firmy, a mianowicie długości tekstów. Sprawa wygląda tak, że poniżej podpisany (czyli ja) mam dość specyficzne podejście do krótkich form, a konkretnie rzadko korzysta z tej możliwości. Bywa to widoczne w mailach (gdzie zdarzało mi się pisać spisy treści do dalszej części wiadomości), w wypowiedziach i o ile uważam, że nie przekraczam granicy rozumu i godności człowieka, o tyle faktycznie, zdarzają mi się teksty o solidnej liczbie znaków. Przy czym w przypadku artykułów na blogu uważam, że zbyt lakoniczny materiał jest gorszy niż brak treści - zwyczajnie trzeba wyczerpać temat lub przynajmniej dotrzeć do momentu, w którym napisało się wszystko, co ważne i zostawia czytelnika z otwartymi drogami do zdobywania dalszej wiedzy. Mówiąc szczerze - wpis na dwa akapity nie wyglądałby poważnie na takim blogu, jak nasz, nawet, jeśli zamykałby temat.

Tym niemniej, tak - nie ukrywam, że lubię statystyki i liczba użytych znaków jest jedną z nich. Więc teraz 5 najdłuższych artykułów, które pojawiły się na blogu (licząc bez formatowania HTML):

  1. Komentarze na blogu z użyciem Mastodona - część 1. (50349 znaków)
  2. Komentarze na blogu z użyciem Mastodona - część 2. (50184)
  3. Podstawy zarządzania aplikacjami webowymi na serwerze Linuxa (39054)
  4. MacBook w pracy - porady i czy warto? (34175)
  5. Co robić, kiedy projekt IT nie idzie? (32153)
  6. Jak się nie narażać w sieci? (30503)
  7. System binarny - podstawy (28771)

"Patrzcie na niego - nie dość, że pisze długie artykuły, to jeszcze nawet Top 5 zwiększa do Top 7" - pewnie sobie pomyślicie. W tym przypadku zrobiłem to z rozmysłem - dostawałem bowiem sygnały i wiem też o tym, że teksty zawierające dużo fragmentów kodu siłą rzeczy będą dłuższe i uwzględnianie ich w rankingu jest wątpliwe. A tak jest z dwiema pierwszymi pozycjami, przez co nie dla wszystkich mogą być one miarodajne. Stąd dodatkowe miejsca na liście, choć np. taki tekst o systemach binarnych też zawiera kawałki obliczeń matematycznych.

Wróćmy jednak do treści. Artykuły o systemie komentarzy zawierają liczne i bardzo pokaźne "snippety" kodu źródłowego, a do tego sama treść jest bardzo obszerna. Nie są to najdłuższe teksty na blogu (palma pierwszeństwa nadal przypada materiałowi o refaktoryzacji), ale zdecydowanie dłuższe niż pierwszy "normalny" wpis w tym roku, jakim był opis fundamentów działania na serwerze Linuxa, mający pomóc osobom, które zwyczajnie boją się postawić pierwsze kroki w takim środowisku. Rozpisaliśmy się też przy okazji "recenzowania" MacBooka i systemu macOS, gdzie połączyliśmy opis samego sprzętu, firmy, a także zamienników aplikacji proponowanych nowym użytkownikom, do tej pory przyzwyczajonych do Windowsa. Następnie mamy ważny dla nas tekst o tym, jak "ratować" projekty IT, które mają problemy, a który to artykuł pozwolił też uporządkować parę spraw oraz uświadomić niektórym, iż porażki się zdarzają i nie zawsze należy bać się do nich przyznawać. Ten rok obfitował też w kilka ważnych tekstów dotyczących cyberbezpieczeństwa, z których jednym z reprezentantów jest artykuł o nienarażaniu się w sieci, a którego bezpośrednią inspiracją byli lokalni influencerzy relacjonujący praktycznie każdy swój krok w relacjach na Instagramie. Nie będę ukrywał - mimo że sam nie jestem bardzo skryty w Internecie, to przeraziło mnie to, jak daleko są w stanie posunąć się osoby chcące zdobyć dodatkowe "lajki" i być może niezdające sobie sprawy, jaki może być koszt dotyczący prywatności. Wreszcie, Top 5 (lub Top 7) zamyka wspomniany już materiał o liczeniu dwójkowym, który by planowany jako pomoc dydaktyczna dla uczniów szkół średnich (i nie tylko).

Dla równowagi zobaczmy, jakie teksty były najkrótsze w tym roku:

  1. Kim jest programista? (7368 znaków)
  2. Co składa się na wycenę oprogramowania? (8688)
  3. Czym się różnią rooting i routing? (8965)
  4. Klienci nie są chętni do zmian (9513)
  5. Na co zwrócić uwagę w portfolio przy rekrutacji? (10279)

Ogólnie mało było w tym roku krótkich artykułów - poprzedni rok zawierał takowe w większej liczbie. Tym niemniej, w 2023 roku też kilka się znalazło, z których liderem okazały się publicystyczne rozważania o tym, kim jest programista (a których by nie było, gdyby nie dyskusja na Twitterze/X - jeszcze raz pozdrawiam Kamila). Tekst o wycenie oprogramowania był wynikiem częstych tłumaczeń, dlaczego liczymy tyle, a nie mniej za dane pozycje w szacowanym oprogramowaniu. O rootingu oraz routingu już wspominałem, że są wynikiem literówki klientów, którzy z kolei bywają też niechętni w zmienianiu czegokolwiek w swoim procesie, mimo że równie często deklarują pewną elastyczność. Z kolei najkrótszym tekstem, który jednak przekroczył 10 000 znaków, jest ten ze wskazówkami dla młodych programistów, którzy szukają pierwszej (lub jednej z pierwszych) pracy w sferze IT.

Najlepszy debiut w ciągu 24 godzin

Ta kategoria pokazuje, jak dobrze link "rozniósł się" w Internecie w ciągu pierwszej doby, co może sugerować ciekawy tytuł, nośny temat lub wyrażenie poparcia przez kogoś bardziej znanego. To taki wyścig sprinterski postów.

  1. Jak "wejść" w Mastodona - szybki tutorial (25.07.2023, 14,44% wyświetleń debiutowych)
  2. Miejsca do wymiany linków na przykładzie /kbin (21.09.2023, 7,65%)
  3. Tłumaczymy memy informatyczne (20.07.2023, 5,08%)
  4. Pomysły na prezent świąteczny dla programisty (30.11.2023, 4,87%)
  5. Jak się nie narażać w sieci? (30.03.2023, 3,96%)

To zabawne, że artykuł, który powstał spontanicznie, poza harmonogramem, zajął pierwsze miejsce w kilku dzisiejszych zestawieniach, w tym właśnie w najlepszym debiucie. Ale wiemy, że tekst będący swoistym quick start guide w Mastodonie i pokazujący, że to nic strasznego (specjalnie też nierozszerzający tematu Fediverse), był potrzebny i trafił nawet do pewnych poradników. Z tego powodu osiągnął bardzo dużą przewagę nad innym tekstem ze świata Fedi, tym razem dotyczącym /kbina, który w tamtej społeczności również został spopularyzowany. Z kolei materiał o memach (który, mam nadzieję, będziemy kontynuować) to efekt współpracy z Just Join IT, którzy też o nim wspomnieli na swoich profilach i stąd wysoki wynik. Gorączka przedświąteczna sprawiła, że dużo osób sięga do poradników prezentowych, który również opublikowaliśmy. Natomiast wspomniany już tekst o nienarażaniu się w sieci to jeden z tych, które potem doczekały się atencji w newsletterach, natomiast już same z siebie dobrze sobie radziły od początku swojego istnienia.

Najlepszy "długi" debiut w ciągu 7 dni

Ta kategoria jest trochę inna - obejmuje ona tydzień, a więc okres, w którym oryginalnie pojawiał się post, informacja o nim była publikowana w serwisach społecznościowych i w RSS, ale link był też dwa razy przypominany w mediach. Od momentu zmiany harmonogramu publikacji na codwutygodniowy ten ranking będzie niespójny i od przyszłego roku pewnie pod "długim debiutem" będzie rozumiane 14 dni.

  1. Jak "wejść" w Mastodona - szybki tutorial (25.07.2023, 12,19% wyświetleń długodebiutowych)
  2. Jak się nie narażać w sieci? (30.03.2023, 10,68%)
  3. Miejsca do wymiany linków na przykładzie /kbin (21.09.2023, 8,76%)
  4. Dlaczego nie należy podawać hasła obsłudze serwisu? (10.08.2023, 8,36%)
  5. Jak chronić oprogramowanie i dane? (05.01.2023, 7,84%)

Tym razem różnice są nieco mniejsze, ale nadal prym wiodą "starzy znajomi" i przede wszystkim artykuły związane z cyberbezpieczeństwem. Wynika to z faktu, że linki do tych właśnie tekstów umieszczała często w swoim newsletterze Zaufana Trzecia Strona, za co bardzo dziękujemy i czujemy się zaszczyceni. Cieszymy się z tego tym bardziej, że są to artykuły ważne i jeśli możemy jakoś przyczynić się do edukowania w kwestiach informatycznych, to chyba ta droga jest najlepsza. Z Internetu korzysta każdy, a więc też każdy jest narażony na różne ataki. Oczywiście, nie opowiemy o tym tak szczegółowo jak robi to wspomniana Zaufana Trzecia Strona, Niebezpiecznik czy Sekurak, ale cieszymy się, że możemy dołożyć choć drobną cegiełkę.

Najczęściej komentowane teksty

Odkąd wprowadziliśmy system komentarzy pod artykułami (choć nie zdołaliśmy zrobić tego pod wszystkimi historycznymi), mamy kolejną miarę dla tekstów, związaną być może bardziej z atrakcyjnością postu promującego oraz ciekawie rozwijającą rozmową pod nimi. Ale też o to chodzi - nie chcemy, aby teksty były zostawione same sobie, tylko faktycznie wiązały się z pewną dyskusją. Nawet, jeśli to wytykanie nam błędów - bardzo dobrze, jeśli czytelnik będzie mógł zweryfikować informacje, a my poczujemy się zmobilizowani do poprawek, gdyż wszyscy w ten sposób czegoś się uczymy. Zazwyczaj źródłem komentarzy są dwa posty w Fediverse - jeden w naszej oficjalnej wizytówce, a drugi na moim prywatnym profilu - poniższa liczba to suma odpowiedzi pod tymi wpisami.

Na pewno liczba komentarzy jest lepsza niż sucha liczba podbić i polubień w mediach społecznościowych - świadczy bowiem nie tylko o popularności, ale też zaangażowaniu Was, czytelników. Za które jesteśmy bardzo wdzięczni.

  1. Programista i administrator to nie to samo (02.11.2023, 25 komentarzy)
  2. Wirtualne hosty - czym są i ich konfiguracja (14.12.2023, 16)
  3. Czy programista powinien grać w szachy (lub warcaby)? (20.04.2023, 13)
  4. RSS to nadal dobre rozwiązanie (07.09.2023, 11)
  5. Miejsca do wymiany linków na przykładzie /kbin (21.09.2023, 9)

Tak coś czuliśmy, że porównanie roli programisty i administratora spowoduje, że przedstawiciele obu zawodów coś napiszą i stąd pierwsze miejsce tego tekstu. Jednak wirtualne hosty również przyciągnęły komentarze, związane głównie z konfiguracją NGINXa pod Windowsem. Artykuł dotyczący szachów był pierwszym tekstem, w którym system komentarzy został zaimplementowany, więc była to swego rodzaju ciekawostka dla stałych bywalców. Z kolei RSS i /kbin to tematy, które skłoniły użytkowników do podzielenia się swoimi przemyśleniami na temat "starego dobrego Internetu". Czyli "kiedyś to były czasy, teraz nie ma czasów".

"Złote... poziomki"

Zanim przejdziemy do najważniejszej kategorii, pokażmy też, które teksty - delikatnie mówiąc - nie cieszą się powodzeniem.

Najgorszy debiut w ciągu pierwszej doby zaliczyły:

  1. Czym jest ukryta wiedza dziedzinowa? (06.07.2023, 0,91%)
  2. Kiedy warto napisać projekt od nowa? (27.07.2023, 0,91%)
  3. System binarny - podstawy (06.04.2023, 0,96%)
  4. Struktura i cechy systemów rozproszonych (16.03.2023, 1,07%)
  5. Jak działa i w czym może pomóc komputer kwantowy? (12.01.2023, 1,07%)

Cóż, są to teksty ważne i uważamy, że potrzebne, natomiast to takie artykuły, które są przydatne osobom szukającym informacji akurat o tych zagadnieniach. Stąd nie dziwimy się, że ich start nie był najlepszy.

A jak to wyglądało w ciągu pierwszego tygodnia?

  1. Czym jest ukryta wiedza dziedzinowa? (06.07.2023, 0,51%)
  2. Kiedy warto napisać projekt od nowa? (27.07.2023, 0,51%)
  3. System binarny - podstawy (06.04.2023, 0,64%)
  4. Klienci nie są chętni do zmian (13.04.2023, 0,66%)
  5. Czym się różnią rooting i routing? (22.06.2023, 0,68%)

Zaskoczenia nie ma - kiepski debiut pociągnął za sobą kiepski długi debiut, tylko nieco zmieniła się kolejność. Rotacja nastąpiła na miejscach 4. i 5., ale te teksty i tak są na dole tabeli w obu kategoriach. Czy zatem będzie tak samo w ostatnim zestawieniu, a więc najmniej poczytnych tekstów w 2023 roku (tzw. największych hipsterów)?

  1. Wirtualne hosty - czym są i ich konfiguracja (14.12.2023, 0,54%)
  2. Czy wszystkie zadania można zrównoleglić? (16.11.2023, 0,70%)
  3. Czym jest ukryta wiedza dziedzinowa? (06.07.2023, 0,74%)
  4. Kim jest programista? (16.02.2023, 0,84%)
  5. Kiedy warto napisać projekt od nowa? (27.07.2023, 0,84%)

Otóż, nie do końca. W przypadku tego rankingu mamy do czynienia z artykułami nowymi (dwa pierwsze miejsca), zaliczającym słaby debiut i dodatkowo nielinkowane w innych tekstach. Cóż, nie każdy artykuł może być popularny i muszą być też takie, które zapewniają "tło". Zdajemy sobie też sprawę, że są interesujące dla konkretnych czytelników, w konkretnych sytuacjach. I dlatego też takie materiały nadal będą się u nas pojawiać, gdyż chcemy dla każdego coś miłego.

Najpopularniejszy tekst

Teraz najważniejszy ranking, a więc z kolei najbardziej poczytnych artykułów mijającego roku.

  1. Jak "wejść" w Mastodona - szybki tutorial (25.07.2023, 10,44% wszystkich wyświetleń artykułów z 2023 roku)
  2. Jak się nie narażać w sieci? (30.03.2023, 8,07%)
  3. Adresy IPv4 i IPv6 (04.05.2023, 7,87%)
  4. Czym są klucze SSH? (02.03.2023, 7,41%)
  5. Dlaczego nie należy podawać hasła obsłudze serwisu? (10.08.2023, 6,21%)
  6. Miejsca do wymiany linków na przykładzie /kbin (21.09.2023, 5,91%)
  7. Jak chronić oprogramowanie i dane? (05.01.2023, 5,87%)
  8. Usunięcie nie zawsze jest usunięciem (24.08.2023, 5,18%)
  9. Tłumaczymy memy informatyczne (20.07.2023, 3,46%)
  10. Pomysły na prezent świąteczny dla programisty (30.11.2023, 2,76%)

Jak widać, dobry debiut i ogólna przydatność wywindowały mastodonowy tutorial na sam szczyt - to taki tekst, do którego następują częste odwołania w wielu miejscach i to sprawiło, że sumaryczna liczba wyświetleń była największa ze wszystkich publikacji z tego roku. Inne artykuły już się pojawiały w poprzednich kategoriach lub również są efektem umieszczenia ich w newsletterze, ale w trochę późniejszym czasie - przykładem jest tekst o adresach IP czy kluczach SSH. Także chronienie danych czy rzecz o usuwaniu informacji doczekały się wspomnienia w różnych zestawieniach linków. Jak widać, potwierdza się przewidywanie, że obszar cyberbezpieczeństwa i ochrony danych jest najbardziej przyciągający, gdyż zwyczajnie dotyczy każdego, a jednocześnie każdy ma na ten temat coś do powiedzenia. I bardzo dobrze - jeśli wiedza o tym, jak się zabezpieczyć, będzie powszechna, dużo łatwiej będzie nam wszystkim uczciwie funkcjonować w przestrzeni internetowej. Ważne jest tylko to, aby przekazywana wiedza była pożyteczna i sprawdzona.

Ranking "all-time"

Pozostał nam jeszcze jeden ranking, tym razem wychodzący poza miniony rok - nasze Top 10 tekstów z całej działalności blogu, oczywiście, uwzględniając także wyświetlenia za rok 2023. Z racji zeszłorocznego podsumowania, możemy tutaj dodatkowo podać, jak zmieniła się pozycja danego materiału względem rankingu z poprzednich 365 dni.

  1. Slash czy backslash - oto jest pytanie (04.11.2021, 16,19% wszystkich wyświetleń, brak zmiany pozycji)
  2. Specyfikacja wymagań oprogramowania - jak ją stworzyć prosto i skutecznie? (29.09.2021, 7,07%, brak zmiany pozycji)
  3. Podstawy i diagram klas UML (10.03.2022, 5,37%, brak zmiany pozycji)
  4. Jak opisywać architekturę oprogramowania? (23.06.2022, 3,97%, wzrost o 4 pozycje)
  5. Jak "wejść" w Mastodona - szybki tutorial (25.07.2023, 2,91%, nowa pozycja)
  6. Co to jest stos technologiczny? (18.08.2022, 2,77%, nowa pozycja)
  7. Jak się nie narażać w sieci? (30.03.2023, 2,25%, nowa pozycja)
  8. Czym jest Mastodon i Fediverse? (17.11.2022, 2,23%, spadek o 4 pozycje)
  9. Adresy IPv4 i IPv6 (04.05.2023, 2,20%, nowa pozycja)
  10. Czym są klucze SSH? (02.03.2023, 2,07%, nowa pozycja)

W sumie jest dość... nudno. Artykuł o slashach i backslashach tak mocno ugościł się w Google, że codziennie notujemy dużo wejść pod ten właśnie tekst i jest to absolutny dominator naszych "łam". Inni "starzy druhowie" to materiały, o których wiemy, że są używane na zajęciach na uczelniach, podczas szkoleń lub sami do nich się odwołujemy tłumacząc klientom, jak będziemy postępować. Zabawne, że opis architektury oprogramowania oraz pierwsza wzmianka o Mastodonie zamieniły się miejscami (mimo że dzielą je 4 pozycje), natomiast na liście pojawił się tekst o stosie technologicznym, do którego nie tylko często linkujemy w swoich tekstach, ale także widzieliśmy, że jest dość dobrze wyszukiwany przez Google. Aż cztery nowe artykuły z 2023 roku na liście "wszech czasów" uważamy za całkiem dobry wynik.

Podsumowanie

Przede wszystkim, dziękujemy Wam za to, że jesteście i nas czytacie. Nam to naprawdę nie jest obojętne i nie chodzi tutaj wcale o wyświetlenia - wielokrotnie pisaliśmy, że radujemy się, gdy choć jedna osoba skorzysta z naszych rad lub wyrazi swoje zadowolenie z przeczytanego artykułu. To nieistotne, że blog jest tak naprawdę firmowy i umówmy się - w pewien sposób ma promować markę Wilda Software. Ale jesteśmy też ludźmi, którzy - oprócz tworzenia oprogramowania i pomocy udzielanej klientom - chcą się podzielić ze światem czymś więcej. Tak do tego podchodzimy i mamy nadzieję, że będziemy podchodzili jak najdłużej.

Pozdrawiam, dziękuję i wszystkiego, co najlepszego, na rok 2024 - Jakub Rojek.

]]> Wirtualne hosty - czym są i ich konfiguracja https://wildasoftware.pl/post/wirtualne-hosty-czym-sa-ich-konfiguracja?ref=rss https://wildasoftware.pl/post/wirtualne-hosty-czym-sa-ich-konfiguracja?ref=rss Thu, 14 Dec 2023 17:30:00 +0000 Przy okazji omawiania tematu Linuxa oraz serwerów, na tym blogu zostało poruszonych wiele tematów. Większość z nich dotyczy stricte aplikacji webowych, używania Pingwina w podstawowy sposób i tego, jak zorganizowane są pliki z oprogramowaniem na serwerze. Trochę mniej wspominaliśmy o tym, że jeśli już strona znajdzie się na komputerze umieszczonym w sieci, to dobrze by było, gdyby użytkownicy mogli ją znaleźć. I nie mamy na myśli pozycjonowania w Google (SEO, co jest zupełnie innym tematem, bardzo szerokim) - bardziej chodzi o to, aby mając adres strony można było po prostu ją otworzyć. Wbrew pozorom nie jest to takie oczywiste, szczególnie na maszynach, które pozwalają hostować wiele stron.

Niektórzy naturalnie tutaj pomyślą o domenach i protokole DNS i o ile siłą rzeczy zahaczymy o ten temat, to nie jest on istotą tego tekstu. Bardziej chcielibyśmy się skupić na tym, czym zakończyliśmy poprzedni akapit - na serwerze może znaleźć się wiele stron, także niezwiązanych ze sobą, a użytkownik chciałby dostać się do konkretnej z nich. Jak to zrobić?

Do tego służy mechanizm, który zwyczajowo nazywa się wirtualnymi hostami lub vhostami i ten właśnie sobie dzisiaj omówimy. Pośrednio zrobiliśmy to przy okazji artykułu o posługiwaniu się serwerem dla początkujących, ale dzisiaj rozszerzymy temat i pokażemy przykłady. Zademonstrujemy również, jak dostać się do strony, nie mając domeny lub chcąc, aby wskazywała na coś innego niż faktycznie wskazuje.

Czym jest host?

Na początku odpowiedzmy sobie na pytanie, czym w ogóle jest host, jeszcze bez przymiotnika "wirtualny". Osoby bardziej biegłe w angielskim od razu stwierdzą, że to "gospodarz" i dobrze oddaje to też znaczenie tego terminu w informatyce. Jest to maszyna lub serwer, który gromadzi u siebie ("hostuje") pewne zasoby, które następnie może udostępniać przez sieć, zarówno globalną, jak i lokalną. Może to być cokolwiek i niekoniecznie chodzi tutaj o stronę internetową - dotyczy to także zwykłej wymiany plików czy jakiejś usługi, jak np. SSH.

Jednak w naszym kontekście najczęściej jako hosta będziemy przyjmować komputer, który udostępnia pliki aplikacji webowej i to niekoniecznie jednej. Ważne jest to, że mówimy o urządzeniu, które faktycznie istnieje. Uwaga - niekoniecznie "fizycznie". Jest bowiem możliwość (i to bardzo często wykorzystywana), że jeden komputer tworzy maszyny wirtualne, które same w sobie są hostami. Jednak "gospodarza", będącego maszyną wirtualną, nie należy mylić z "wirtualnym hostem". To bowiem zupełnie inny byt.

Czym jest wirtualny host i jak obsługuje go serwer HTTP?

Wyobraźmy sobie sytuację, że mamy serwer pod adresem IP 10.20.30.40, który zawiera aplikację z systemem klasy ERP (zarządzanie zasobami przedsiębiorstwa, jak np. ComMan). Jest to jedyny system na tej maszynie i prowadzi do niego adres MyERP.com. Gdy użytkownik wpisze w przeglądarkę ten adres, serwer nazw domenowych poinformuje komputer, że host, którego szuka, znajduje się pod adresem 10.20.30.40. Wówczas przeglądarka uda się pod wskazany adres, wchodząc na nasz serwer, a tam serwer HTTP zwróci zawartość plików strony.

Ten scenariusz jest prosty, ale bardzo... nierealistyczny. Po pierwsze, obecnie rzadko która aplikacja składa się z jednego komponentu posiadającego jeden adres. To akurat może, ale nie musi mieć znaczenia, gdyż dzieląc system na frontend i backend ten drugi zwykle jest ukryty przed dostępem z zewnątrz. Natomiast nie zawsze i to oznacza, że na jednym serwerze znajdują się dwie aplikacje pod różnymi adresami. To jednocześnie drugi powód - większość serwerów jest przeznaczona do hostowania wielu aplikacji webowych znajdujących się pod różnymi adresami za pomocą jednej maszyny i jednego serwera HTTP (czyli aplikacji, która serwuje strony, którymi zarządza). Z jednej strony dlatego, że tak jest taniej, a z drugiej niekiedy serwer jest "za duży", aby obsłużyć jedną aplikację i zwyczajnie można go zająć czymś jeszcze, aby nie marnować zasobów.

Zobaczmy taką perspektywę:

Diagram pokazują, że żądanie HTTP do myerp.com jest kierowane do serwera DNS, uzyskuje adres IP, z którym udaje się do serwera. Ten z kolei jest podzielony na kilka adresów, z których każdy związany jest z określonym folderem na dysku. Jednym z tych adresów oraz folderów jest myerp.com i diagram pokazuje, jak serwer HTTP odnajduje tę stronę i ją zwraca użytkownikowi.

Użytkownik, chcąc wejść na stronę MyERP.com, musi najpierw poznać adres IP serwera, który tę stronę przechowuje. Może to zrobić poprzez jeden z dostępnych serwerów DNS (ang. Domain Name Server), który ma coś w rodzaju tabelek mapujących adresy domenowe na adresy IP. W ten sposób przeglądarka użytkownika dowiaduje się, że interesujący go serwer ma "numer" 10.20.30.40. Z tą wiedzą przeglądarka udaje się do tej maszyny i na tym rola DNS się kończy. Jego zadaniem było wskazanie odpowiedniego komputera i to tylko za pierwszym razem (lub raz na jakiś czas) - później przeglądarka cache'uje sobie ten adres, przyspieszając późniejszą drogę.

Przychodzi zatem żądanie do 10.20.30.40, które przedstawia się jako żądanie do MyERP.com - to szalenie istotna informacja. Służy bowiem serwerowi do tego, żeby rozpoznać, do którego ze zdefiniowanych dla siebie wirtualnych hostów (ang. virtual hosts, w skrócie vhosts) przekierować żądanie niczym router. Każdy z nich ma bowiem swoje dane konfiguracyjne i wskazany folder, w którym przechowuje pliki, składające się na aplikację. Jest to zatem taki lokator w wielkim bloku mieszkalnym zwanym serwerem HTTP. Tutaj warto też zauważyć, że sprawy nie rozwiązuje wpisanie w pasku adresu bezpośrednio 10.20.30.40 - serwer znajdziemy, ale ten nie będzie mógł zdecydować, o którą witrynę nam chodzi i w efekcie użytkownik uzyska błąd.

Ponieważ czasem lepiej pokazać coś za pomocą metafory, to spróbujmy. Wyobraźmy sobie młodzieńca Krzysia (użytkownik i jego przeglądarka), który chce zaprosić na bal Zosię (strona internetowa). Od kolegów (serwer DNS) dowiaduje się, że dom Zosi (adres domenowy) znajduje się na Lipowej 46 (adres IP). Zatem nasz Krzyś idzie na tę Lipową, puka do drzwi i po chwili widzi postawnego pana o groźnej minie (serwer HTTP), przedstawiającego się jako gospodarz. Niezrażony tym młodzieniec mówi, że przyszedł do córki rzeczonego gospodarza. Na to ten dopytuje "do której?" - ma bowiem aż trzy: Kasię, Zosię oraz Martę (wirtualne hosty). Krzyś wskazuje, że chodzi o Zosię, więc ojciec woła ją i ta wychodzi do chłopaka, wysłuchując zaproszenia na bal.

Jak widać, pojęcie wirtualnego hosta jest dość proste - to coś w rodzaju jednego z nazwanych zasobów dostępnych przez adres URL, które są na serwerze. Natomiast trochę trudniejsze zadanie czeka tych, którzy muszą takie wirtualne hosty zdefiniować, gdyż nie zawsze jest to proste, zwłaszcza, że wykonuje się to inaczej na każdym rodzaju serwera HTTP.

Konfiguracja Apache

Jest to drugi najpopularniejszy aplikacyjny serwer HTTP używany na serwerach, ale najbardziej rozchwytywany przez początkujących (choć nie tylko i od razu to napiszę wyraźnie - to żadna ujma). Wynika to z jego prostoty konfiguracji (przynajmniej na tle konkurentów), natomiast trzeba zdawać sobie sprawę, że jest uznawany za wolniejszy względem np. NGINX. Tym niemniej, wszystko zależy od wymagań pozafunkcjonalnych systemu, który ma być hostowany za pomocą takiego serwera. Sam serwer często jest nazywany Apache 2, gdyż druga wersja jest od wielu lat wiodąca. Raz zdarzyło mi się po poprosić administratora o serwer Apache'a i dostałem Apache'a w wersji pierwszej, mimo że od wielu lat była dostępna "dwójka".

W tym przypadku wirtualne hosty definiuje się w folderze /etc/apache2/sites-available (używamy domyślnych ścieżek linuxowych), zazwyczaj tworząc osobne pliki tekstowe dla każdego vhosta. Ułatwia to ich późniejsze włączanie i wyłączanie.

Poniżej znajduje się przykład pliku myerp.com.conf, który definiuje vhost myerp.com:

<VirtualHost *:80>
	DocumentRoot /var/www/myerp.com 
	ServerName myerp.com
	ServerAlias www.myerp.com
	
	ServerAdmin admin@myerp.com
	ErrorLog ${APACHE_LOG_DIR}/myerp.com-error.log
	CustomLog ${APACHE_LOG_DIR}/myerp.com-access.log common
	
	<Directory /var/www/myerp.com> 
		Allow from all
		Options Indexes FollowSymLinks
		AllowOverride All
		Require all granted
	</Directory>
</VirtualHost>

Każdą definicję zawieramy w węźle VirtualHost podając konkretny adres i port lub używając właśnie gwiazdki jako dowolnego adresu IP, który i tak zaprowadził użytkownika na nasz serwer. Najważniejsze są pierwsze dwie instrukcje - DocumentRoot określa lokalizację plików aplikacji, natomiast ServerName - adres, który wywołuje te pliki. Jak można się domyśleć z kodu, istnieje także możliwość określenia aliasu, administratora oraz lokalizacji plików z logami.

Ważną definicję stanowi też węzeł Directory, który nie jest obowiązkowy, ale służy m.in. do ustawienia AllowOverride All, pozwalający na nadpisywanie reguł poprzez pliki .htaccess w samej aplikacji, tak charakterystyczne dla serwera Apache'a. Oprócz tego, jak widać, można m.in. odblokować dostęp z każdego miejsca.

Jednak umieszczenie konfiguracji w folderze sites-available to tylko połowa sukcesu - konfigurację trzeba też włączyć (lub wyłączyć, jeśli jej już nie potrzebujemy). Do tego służą odpowiednie komendy:

sudo a2ensite myerp.com.conf
sudo a2dissite myerp.com.conf

Zmiany konfiguracyjne należy zaaplikować poprzez restart samego serwera w sposób zależny od konkretnej dystrybucji Linuxa. Przykładowo:

sudo systemctl reload apache2

Więcej informacji znajdziecie w tym łatwo zrozumiałym poradniku od DigitalOcean.

Konfiguracja XAMPP

XAMPP to znane narzędzie szczególnie na Windowsie, które łączy w sobie serwer HTTP Apache'a, serwer MySQL-a (choć ten akurat osobiście polecam zainstalować osobno) i moduł interpretera PHP. Bardzo ułatwia tworzenie aplikacji i zdejmuje z programistów potrzebę samodzielnej konfiguracji wielu parametrów.

Jako że tak, jak napisałem, ten pakiet wykorzystuje pod spodem serwer Apache'a, tworzenie tutaj wirtualnych hostów wygląda bardzo podobnie jak to, co przedstawiliśmy wyżej. Różnica jest taka, że w tym przypadku domyślna lokalizacja pliku z wirtualnymi hostami (na Windowsie) to C:\xampp\apache\conf\extra\httpd-vhosts.conf i jest to jeden plik obejmujący wszystkie takie wpisy. Bo tak - także w natywnym Apache'u (zresztą także w NGINX, który zaraz omówimy) można wszystkie vhosty zawrzeć w jednym pliku, tylko po prostu jest to mniej wygodne w późniejszym zarządzaniu na serwerze produkcyjnym.

Przy tej okazji warto wspomnieć o tym, że w tego typu lokalnych środowiskach nie należy zapominać o pozostawieniu dostępu do adresów localhost/nazwafolderu, co jest bardzo pomocne podczas rozwijania wielu aplikacji na komputerze. Wówczas pomocna będzie następująca definicja vhosta:

<VirtualHost *:80>
	ServerAdmin localhost@example.com
	DocumentRoot "C:/xampp/htdocs" 
	ServerName localhost.com
	ServerAlias www.localhost.com
	ErrorLog "logs/localhost-error.log" 
	CustomLog "logs/localhost-access.log" common
	<Directory "C:/xampp/htdocs">  
		Allow from all
		Options Indexes FollowSymLinks
		AllowOverride All
		Require all granted
	</Directory>
</VirtualHost>

Konfiguracja MAMP

MAMP jest odpowiednikiem XAMPPa na systemach operacyjnych macOS. Swoją drogą, sam XAMPP też jest dostępny na Jabłkach, ale MAMP jest jeszcze prostszy i... czasem irytujący w darmowej wersji z uwagi na trochę utrudniony dostęp do pewnych plików konfiguracyjnych. Ale spokojnie - tutaj też można włączyć wirtualne hosty i to na podobnej zasadzie, jak w XAMPPie. Natomiast trzeba dodatkowo pamiętać o włączeniu samego mechanizmu w /Applications/MAMP/conf/apache/httpd.conf, gdzie należy odkomentować linijkę:

Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

Jak się możecie domyślać, wskazuje ona lokalizację pliku z definicjami wirtualnych hostów, gdzie kwestia wygląda tak samo, jak opisano powyżej. Warto też wspomnieć, że MAMP umożliwia przełączenie się z Apache'a na NGINX. A właśnie.

Konfiguracja NGINX

Według badań z czerwca 2022 roku jest to najpopularniejszy serwer HTTP na świecie (33,6%, podczas gdy drugi Apache ma 31,4% udziału), jeśli mówimy o środowiskach produkcyjnych. To właśnie w nich NGINX pokazuje swoją szybkość i możliwości, w wyniku których jest szeroko wykorzystywany do serwerowania stron WWW, jako load balancer, serwer reverse proxy i w innych przypadkach. Dlaczego zatem sugerowałem, że Apache jest najpopularniejszym serwerem wśród początkujących? Ponieważ ma ciut prostszą strukturę i sposób definiowania konfiguracji. To nie jest też tak, że jeśli ktoś używa NGINX-a to jest automatycznie profesjonalistą, a "apaczowcy" są słabsi - oba serwery HTTP są dobre, tylko każdy z nich ma pewne zalety i wady, które nie zawsze muszą być kluczowe. Jeśli kluczowa jest wydajność, to nie da się ukryć, że NGINX jest preferowany.

Jeżeli chodzi o wirtualne hosty, to w przypadku NGINX-a mówimy o czymś, co się nazwa server blockami. Dobrą informacją jest to, że co do zasady definiuje się je bardzo podobnie jak w Apache - interesuje nas folder /etc/nginx/sites-available, w którym tworzymy pliki dla każdej strony, a które wyglądają mniej więcej tak:

server {
	listen 80;
	listen [::]:80;

	root /var/www/myerp.com;
	index index.html index.htm index.nginx-debian.html;

	server_name myerp.com www.myerp.com;

	location / {
		try_files $uri $uri/ =404;
	}
}

Jak widać, struktura wydaje się nieco bardziej kompaktowa, natomiast różnice pod spodem są większe i sposób definiowania np. ścieżek przekierowań w NGINX jest zupełnie inny. Natomiast, żeby włączyć vhosta, także tutaj należy podlinkować odpowiedni plik w katalogu sites-enabled (tym razem standardową komendą linkowania):

sudo ln -s /etc/nginx/sites-available/myerp.com /etc/nginx/sites-enabled/

a następnie sprawdzić i zrestartować NGINX-a:

sudo nginx -t
sudo systemctl restart nginx

Również w tym przypadku polecamy tutorial autorstwa DigitalOcean, który tłumaczy cały proces krok po kroku.

Konfiguracja Caddy

Wraz z upowszechnieniem się języka programowania Go, środowisko programistyczne zostało zasilone narzędziami, z których niektóre weszły do szerszego użytku. Jednym z nich jest Caddy, prosty serwer webowy, który jest podatny na rozszerzanie i - co ciekawe - automatycznie zapewnia protokół szyfrowany. Jest przedstawiany jako bezpieczniejszy i przede wszystkim prostszy w konfiguracji serwer, nawet od Apache.

Choć z tym prostszym bym może nie przesadzał - jak każde narzędzie wymaga zapoznania się i samodzielnych prób, w trakcie których niektóre osoby zrażą się do Caddy'ego, a inne nim zachwycą. Ten serwer jest używany między innymi przez /kbin i tworzenie wirtualnych hostów wygląda tutaj dość prosto:

myerp.com {
	root * /var/www/myerp
	file_server
}

Więcej informacji możecie przeczytać w tym artykule oraz, oczywiście, oficjalnej dokumentacji. A samego Caddy'ego możecie poznać poprzez przykład podany na stronach - a jakże - DigitalOcean.

Czym jest /etc/hosts?

Wróćmy jeszcze na chwilę do wcześniej przytoczonego tłumaczenia tego, jak użytkownik dostaje się w ogóle do strony i skupmy się na tej pierwszej części - kontakcie z serwerem DNS. Zakładamy bowiem, że przykładowa domena MyERP.com jest zarejestrowana i dostępna publicznie. Wówczas rzeczywiście powinniśmy podążać tą ścieżką. Jednak, jak zawsze, można znaleźć co najmniej trzy sytuacje wyjątkowe, kiedy trzeba podejść do tego inaczej.

Pierwsza z nich to taka, w której strona, do której chcemy się dostać, znajduje się już pod nowym adresem IP (np. została przeniesiona na inny serwer), ale serwer DNS jeszcze o tym nie wie. Nie ma w tym niczego dziwnego - tzw. propagacja zmian na serwerach DNS może trwać od kilkunastu minut do nawet 48 godzin, w związku z czym zmiana adresu domenowego tak, aby wskazywał na inny serwer może nie być u wszystkich widoczna od razu. Dodatkowo, może zaistnieć sytuacja, w której serwery DNS zwracają już poprawne rekordy, ale u nas nadal aktywny jest cache, a chwilowo nie możemy lub nie umiemy go wyczyścić.

Druga sytuacja jest podobna, ale dotyczy awarii serwerów DNS lub braku możliwości odwołania się do nich - bywają takie błędy. Do tej puli wpada też np. ominięcie jakichś blokad bądź zrobienie żartu koledze z pracy, ale tego ostatniego, oczywiście, nie polecamy.

Trzecia sytuacja jest również ciekawa, gdyż domena może nie istnieć publicznie. Można się umówić w firmie, że jakaś witryna będzie dostępna pod adresem myerp.local i jest to URL używany tylko w obrębie tego środowiska. Nie chcemy lub nie możemy tej domeny zarejestrować publicznie, a więc umieścić ją na serwerach DNS. A jednak jakoś przeglądarka będzie musiała się dowiedzieć, gdzie kierować się po wpisaniu tego adresu.

Gdy adresujemy jeden z powyżej opisanych problemów do kogoś, kto może nam pomóc, często usłyszymy "dodaj wpisy do /etc/hosts". Jest to bowiem plik systemowy, który służy do lokalnego podania stałego adresu IP, który jest przypisany danemu adresowi domenowemu. Jest to zatem taka lokalna uproszczona wersja serwera DNS dostępna tylko dla nas i nadrzędna względem DNS-ów. Przykładowo, jeśli pod adres youtube.com przypiszemy w tym pliku 91.185.189.246, to po wpisaniu "youtube.com" w przeglądarce wylądujemy tak naprawdę w Feedybacky.

Budowa tego pliku jest prosta, aczkolwiek warto wspomnieć, że możemy go edytować tylko z uprawnieniami administratora. Oto przykładowy fragment /etc/hosts:

120.50.66.171 system.test.com
127.0.0.1 local.site1
127.0.0.1 local.site2

Te reguły mówią nam o tym, że jeśli użytkownik na tym komputerze odwoła się do adresu system.test.com, to trafi pod adres IP 120.50.66.171. Ma też dwa wirtualne hosty skonfigurowane na swojej maszynie, czyli localhoście (zwyczajowa nazwa 127.0.0.1) - są to local.site1 oraz local.site2. Jak widać, potwierdza się, że można jednemu adresowi IP przypisać przypisać wiele domen lub pseudodomen.

Sam plik /etc/hosts znajduje się właśnie w tej lokalizacji w Linuxach i systemach macOS. Ale także Windows posiada taki zbiór dyskowy, tylko w trochę trudniejszym do zapamiętania folderze - C:/Windows/System32/drivers/etc/hosts.

Podsumowanie

Mamy nadzieję, że tym tekstem rozświetliliśmy choć trochę temat wirtualnych hostów - to nie jest nic strasznego, za to wręcz stanowi wymagany mechanizm przy projektowaniu nowoczesnego oprogramowania, a także przy zarządzaniu serwerem HTTP, na którym znajduje się wiele stron. W tym momencie niektórzy mogą zadać sobie pytanie, kto konfiguruje vhosty i odpowiedź brzmi: administratorzy przy wsparciu instrukcji od programistów. Tutaj nie ma też co się łudzić, że koderzy ustawią wszystko od A do Z - często wymagają pomocy administratorów, którzy jednak potrzebują dokładnych wytycznych dotyczących tego, co ma być osiągnięte.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Pomysły na prezent świąteczny dla programisty https://wildasoftware.pl/post/pomysly-prezent-swiateczny-programisty?ref=rss https://wildasoftware.pl/post/pomysly-prezent-swiateczny-programisty?ref=rss Thu, 30 Nov 2023 17:30:00 +0000 Właściwie tytuł tego artykułu nie jest do końca dobry - potrzeba podarowania znajomemu programiście prezentu nie musi być związana koniecznie ze świętami (a już szczególnie z Bożym Narodzeniem). Równie dobrze może być to Dzień Programisty, który jest obchodzony w 256. dzień roku, co zwykle wypada 12 września (za wyjątkiem lat przestępnych, kiedy okazja do radowania się jest 13 września). To hasło pasuje również do urodzin osoby lubiącej programować i nie tylko zawodowców, ale też wszystkich pasjonatów. Tak czy inaczej, są takie momenty, kiedy chcemy komuś kupić prezent, ale nie do końca wiemy co. W głowie pojawia się myśl, że powinno być to związane z programowaniem i... właściwie do czego nam się przyda ta informacja?

O tym jest dzisiejszy artykuł - zastanowimy się, co można sprezentować programiście ze względu na jego zawód. Cóż, wbrew pozorom wiele rzeczy, zwłaszcza, że programiści - wbrew stereotypom - to też ludzie. To nas prowadzi do jednego zastrzeżenia, które jest ważne w kontekście tego tekstu. W sumie dość oczywistego zastrzeżenia.

Wiadomo, że każda osoba ma jakieś zainteresowania lub zwyczajnie swoje aktualne potrzeby i zazwyczaj nie są one związane z zawodem. Dotyczy to też programistów - to, że ktoś zawodowo tworzy oprogramowanie nie oznacza, że musi dostać związany z tym prezent. Ba - może nawet tego nie chcieć. Być może woli standardowe skarpety, szalik, pidżamę czy boostery Magic: the Gathering. Dlatego bez względu na to, co napiszemy my lub inne osoby w świecie internetowym, zawsze kierujcie się indywidualnymi pragnieniami przyszłego obdarowanego. Zwłaszcza, jeśli to członek Waszej rodziny lub bardzo bliska Wam osoba.

Z drugiej strony, są takie rzeczy, które ucieszą nawet nie tylko każdego programistę, ale też szerokie spektrum informatyków lub po prostu osoby lubiące sferę techniczną. I to nie byle jakie produkty, bo przecież nikt by nie pogardził nowym telefonem, laptopem, słuchawkami skutecznie odcinającymi od otoczenia, monitorem czy aparatem cyfrowym. Natomiast te prezenty, o ile bardzo cieszą, to mają jeden minus - jest nim cena. Nie ukrywajmy, że w przypadku takich podarunków trzeba już albo bardzo dobrze znać odbiorcę prezentu, albo zaprosić go do wspólnego kupna prezentu, gdyż przy takich wydatkach konieczne (albo przynajmniej polecane) jest zweryfikowanie oferty rynkowej, przeczytanie recenzji i generalnie coś, co nazywamy researchem. Dlatego pominiemy tutaj też prezenty droższe niż 300 zł. Poza jednym wyjątkiem, choć i tak odniesiemy się do jego tańszej wersji.

No właśnie - skupimy się na potencjalnych prezentach, które kojarzą się z programowaniem lub mogą być przez kodera odebrane ze szczególnym uśmiechem, którego nie spodziewałby się nawet kupujący. Skąd to wiemy? Sami w większości jesteśmy programistami i wiemy, co nas cieszy. Oczywiście, poza brakiem błędów w kodzie.

Pendrive lub dysk zewnętrzny

Zaczynamy od prezentu w miarę bezpiecznego i niezwiązanego stricte z programistami. Każdy bowiem ma pliki, które trzeba czasem przenieść lub przechować je na zewnątrz komputera. I pendrive czy dysk zewnętrzny jest tutaj oczywistym rozwiązaniem, które zresztą wiele osób stosuje i to w dużej liczbie. Natomiast niepisana zasada jest taka, że niezależnie od tego, ile mamy pendrive'ów, to nigdy nie ma ich pod ręką, gdy są potrzebne, mają za mało miejsca lub nie chcemy mieszać ich zawartości z tym, co właśnie chcemy nagrać. Zdarza się też, że chcemy nagrać system na wolne urządzenie, tylko że dziwnym trafem żadne nie jest wolne.

Do tego dochodzi jeszcze inny aspekt, a mianowicie wielkość dysków montowanych w laptopach. Wbrew pozorom, nie zawsze jest ona wystarczająca. Oczywiście, większość ma co najmniej 512 GB, co wydaje się dużą przestrzenią i rzeczywiście taka zwykle jest. Natomiast zdarzają się sytuacje, w których dość szybko zacznie nam brakować gigabajtów. W przypadku programistów może to wynikać z przechowywania materiałów od klientów, paczek instalacyjnych, backupów, bibliotek do aplikacji, baz danych, cache'a i innych zasobożernych folderów. Ale nie tylko u tej profesji występuje problem nagromadzenia się zbyt dużej liczby zbiorów dyskowych - znają to także graficy z licznymi i "ciężkimi" projektami interfejsu, gracze z coraz większymi grami czy montażyści filmowi z plikami wideo.

Wróćmy jednak do programistów - warto rozważyć opcję kupienia dysku SSD o rozmiarze 1 TB, który będzie stanowił dobre uzupełnienie normalnego dysku i zapewniał miejsce na wyjątkowo duże pliki, których właściciel nie potrzebuje na co dzień. Oczywiście, dyski mechaniczne (HDD) będą tańsze lub oferowały znacznie większą przestrzeń, co może być jeszcze bardziej przydatne dla kopii zapasowych, natomiast mimo wszystko świat informatyczny stał się tak przesiąknięty szybkością oferowaną przez SSD, że mimo wszystko polecam w pierwszej kolejności wziąć pod uwagę tę ścieżkę.

Dysk zewnętrzny jest pojemny, ale jednak ciut droższy niż pendrive, który też jest godny rozważenia. Szczególnie, jeśli programista jest bardzo mobilny, uczestniczy w licznych prezentacjach (i to mimo że wszędzie chodzi z laptopem) lub czujemy, że 512 GB/1 TB nie jest konieczne i wystarczy 128 GB dodatkowego miejsca. Szczególnie mobilność warto wziąć pod uwagę - jeśli odbiorca prezentu często się przenosi z laptopem i pracuje w różnych warunkach, to dysk zewnętrzny z dodatkowym kablem będzie czasem stanowił utrapienie.

Minutnik

Podejrzewam, że mało kto spodziewał się takiej propozycji. I faktycznie, pewnie nie jest to coś, co wzbudzi radość na pierwszy rzut oka. Dlatego, jeśli zdecydowalibyśmy się na taki podarunek, to powinien być to fantazyjny minutnik w kształcie jakiejś postaci, zwierzęcia czy po prostu z jakiegoś powodu jedyny w swoim rodzaju. Wówczas będzie cieszył oko już od pierwszej chwili, a potem jego atuty przeniosą się z estetycznych na grunt bardziej funkcjonalny. Właśnie - skąd taki pomysł?

Programiści cenią sobie możliwość skupienia się i odcięcia od wszelkich czynników rozpraszających. Stąd bardzo często słuchawki na uszach czy preferowana praca zdalna (choć to akurat może być miecz obosieczny). Nierzadko mówi się o tzw. "wchodzeniu w strefę", kiedy najlepiej się programuje i ogólnie analizuje problem. Niestety, pracownik IT pracujący w zespole (a z tym wiąże się omawiana profesja) musi również czasem się komunikować i równie często jest zagadywany przez kogoś, kto chce się czegoś dowiedzieć. To bardzo wytrąca z równowagi i utrudnia wejście w "strefę". Co więcej, ludzie miewają słabą wolę i często sami sobie stwarzają sposoby na rozpraszanie, szczególnie, jeśli co chwilę są odrywani od pracy i muszą przypominać sobie kontekst, a jest to trudne. Dlatego w ogóle pojawia się temat metod na polepszenie pracochłonności, wśród których jedną z bardziej znanych jest Pomodoro. Jest to nic innego jak wyznaczanie np. 20-minutowych okresów, w czasie których NIC nie może nam przeszkodzić (oczywiście, pomijając wypadki krytyczne). Wyłączamy wszelkie powiadomienia, bodźce zewnętrzne, ale co ważniejsze, coś musi kontrolować nam ten czas i (w biurze) dawać znać innym, że właśnie jesteśmy w "strefie Pomodoro". Do tego właśnie może służyć minutnik, pełniący jednocześnie rolę gadżetu.

To przykład tego, jak pozornie dziwny prezent przez dobrą historię może stać się bardzo dobrze przyjętym podarunkiem. A jednocześnie pomoże w kuchni przy gotowaniu jajek.

Gumowa kaczuszka

Pozostajemy w temacie pracochłonności oraz gadżetów. Pewnie nikt nie spodziewałby się w tym zestawieniu nie tylko hiszpańskiej inkwizycji, ale także gumowej kaczuszki. Czy na pewno? Osoby nieznające kultury IT pewnie szeroko otworzyły oczy ze zdumienia, ale programiści czytający te słowa pewnie troszeczkę się uśmiechnęli.

Nie bez powodu mówi się, że pisanie odręczne jest lepsze niż pisanie na klawiaturze. Wynika to z faktu, że "uruchamia" inne obszary mózgu, pozwalając lepiej zbierać i łączyć zdobyte informacje. Zapewne podobny mechanizm stoi za tym, że rozmyślanie o problemie jedynie w głowie jest mniej efektywne niż dodatkowe rozpisywanie go lub wypowiadanie na głos. Albert Einstein nie bez powodu mówił, że jeśli nie umiemy wytłumaczyć danego zagadnienia początkującemu, to być może tego zagadnienia sami dobrze nie rozumiemy. Biorąc te wszystkie pozornie niezwiązane ze sobą rzeczy, przechodzimy do sedna - już dawno programiści (i nie tylko) odkryli, że mówienie podczas wyjaśniania problemu i próby dochodzenia do jego rozwiązania, jest lepsze niż po prostu myślenie o tym w ciszy. Tylko że każdy, kto choćby nagrywał filmy w samotności rozmawiając z laptopem wie, że znacznie łatwiej mówi się do kogoś, choćby do skromnej publiczności w postaci jednej istoty. A jeśli nie chcemy angażować prawdziwej osoby, to pozostaje nam rekwizyt. Wreszcie, wiedząc o tym, że programiści lubią dodać coś "szalonego" i "memicznego" do swojego środowiska, nie powinniśmy się dziwić, że jako rekwizyt zaczęto wykorzystywać gumową kaczuszkę.

Oczywiście, nie trzeba kupować takiej zwykłej - ponownie może to być fantazyjny gadżet, być może o dodatkowych funkcjach, ale akurat ten prezent może wzbudzić co najmniej uśmiech na twarzy programisty zamiast rozgoryczenia. A przy okazji stanowić ciekawą ozdobę na biurku.

Książka i cheatsheet

Książki zawsze są dobrym prezentem. Niektórzy je uwielbiają, inni po prostu stawiają na półce, gdzie ładnie wyglądają. W przypadku programistów jest to dość specyficzny prezent, gdyż technologia zmienia się tak szybko, że literatura fachowa dość szybko się dezaktualizuje. Chyba że jest przedstawicielem tzw. evergreenów, czyli pozycji, które są ponadczasowe.

Mam tutaj na myśli tomy o pewnych fundamentach informatycznych lub pokazujących podejście niezwiązane z konkretnym językiem programowania, aplikacją bądź biblioteką. Przykładem może być książka o algorytmach, sieciach komputerowych czy choćby Linuksie. Są to pozycje, które, co prawda, kiedyś się zdezaktualizują, ale stanie się to bardzo wolno, a często nieźle się prezentują wizualnie. Co do ich przydatności dla programisty, to zależy od indywidualnego przypadku - np. koder zaczynający mieć do czynienia z projektem wiążącym się z systemem wbudowanym, może z odpowiedniej pozycji dowiedzieć się czegoś o podstawach nieznanego dla siebie obszaru, aby lepiej rozumieć kolegę, który się tym zajmuje. Dobrym pomysłem może być też obserwowanie, jakie są długotrwałe trendy w informatyce i kupno książki pod "modę". Tutaj na myśl przychodzi np. konteneryzacja, która pewnie jeszcze trochę z nami pobędzie, ale też (a może i zwłaszcza) tematy związane z uczeniem maszynowym, sztuczną inteligencją czy nawet głębokimi sieciami neuronowymi.

Można też kupić pozycję z dziedziny nie tyle programistycznej, co pozwalającej rozwinąć się programiście w innym kierunku. Tutaj z kolei przykładem mogą być zagadnienia devopsowe, z tworzenia startupu, ale także choćby zarządzania projektami. Ten rejon poszukiwania prezentu warto wybrać zwłaszcza, jeśli koder ma zamiar stać się seniorem lub wręcz kierownikiem zespołu IT.

A jeśli chcemy kupić coś "lżejszego", to niezłym pomysłem są poręczne kompendia wiedzy lub tzw. cheatsheety (kompendia, wykazy, zestawienia, wskazówki...) - zbiory wskazówek, skrótów klawiszowych i szybkich zestawień do codziennego korzystania. Na myśl przychodzą książeczki z najczęstszymi komendami Linuxa lub Vima - takie pozycje spokojnie mogą leżeć przy monitorze i przydawać się w różnych momentach.

Podstawka pod laptopa

Dość kontrowersyjny punkt z tego powodu, iż spotkałem się ze stwierdzeniami, iż ten przedmiot może też być szkodliwy. I o ile w przypadku dodatkowych wiatraków chłodzących może mieć to podstawy, o tyle same podstawki stały się w ostatnich latach wręcz obowiązkowym elementem biurowego wyposażenia.

Dlaczego? Zapewniają kilka rzeczy:

  • lepszą wentylację - laptop ma przestrzeń pod sobą, przez co aż tak się nie nagrzewa,
  • bardziej ergonomiczny układ klawiatury, która nie jest płaska, tylko pochylona (to też kontrowersyjny punkt, ale np. mnie się tak lepiej pisze),
  • ekran jest wyżej, przez co użytkownik nie musi aż tak się schylać, a więc przy okazji niszczyć sobie kręgosłup.

Oczywiście, są podstawki tańsze, dość proste oraz te bardziej zaawansowane, z dodatkowymi funkcjami. Nie bez znaczenia jest też wygląd oraz wielkość. To dość ciekawy prezent, gdyż nie jest tak "oklepany", jak inne peryferia komputerowe (które też, oczywiście, warto rozważyć). Generalnie, w przypadku programistów i osób długo siedzących przy komputerze warto zainteresować się tematem ergonomii. W przypadku większego budżetu dotyczy to też krzesła i biurka elektrycznego.

Podpórka pod plecy

...a w przypadku mniejszego można kupić taki przydatny element wyposażenia, jak ergonomiczna podpórka pod plecy do krzesła. Oczywiście, ktoś może powiedzieć, że wystarczy zwykła, odpowiednio duża poduszka, ale od tego są różne okazje, aby zainteresować się rozwiązaniami bardziej dostosowanymi do potrzeb.

Przede wszystkim chodzi o zabezpieczenie odcinka lędźwiowego, który jest szczególnie narażony przy długotrwałym siedzeniu przed monitorem. Nie będę tutaj silił się na wyjaśnienia, gdyż nie jestem specjalistą w temacie - tutaj znajdziecie więcej informacji. Natomiast i tak warto pamiętać, że nic nie zastąpi zmian pozycji, ruchu i ogólnie zwiększonej aktywności fizycznej. Dlatego, abstrahując od kwestii wyposażania miejsca pracy, być może warto przemyśleć, czy znajomy programista ucieszyłby się z czegoś związanego ze sportem, co zachęciłoby go do ćwiczeń. Może kettlebelle?

Krople do oczu

W temacie ergonomii i zdrowia, nie należy zapominać o tym, że oczy to równie ważne narzędzie pracy programisty i jest to związane z długotrwałą obecnością przed ekranem. Przede wszystkim nic nie zastąpi higieny i dbania o wzrok, wykonania podstawowych ćwiczeń czy spojrzenia w dal raz na jakiś czas, najlepiej na zielony krajobraz. Warto również regularnie kontrolować ten organ u specjalisty. Ale o tym wiemy wszyscy.

Ekrany mają to do siebie, że potrafią wysuszać gałkę oczną ze względu na rzadsze mruganie, w związku z czym przydatne są krople do oczu. I tutaj uwaga - niektórym wydaje się, że są one dosyć tanie, ale mimo wszystko ich cena w ostatnich latach trochę urosła, szczególnie jeśli mówimy o kroplach bez konserwantów (a tylko z takich powinniśmy korzystać). Jest to zatem miły prezent dla każdej osoby, która bez ustanku wpatruje się w elektroniczny prostokąt wyświetlający różne rzeczy z pewną częstotliwością odświeżania.

Raspberry Pi (w różnych wersjach)

Teraz będzie coś droższego, choć... to też zależy. Prawie każdy słyszał o Raspberry Pi, a więc płytce elektronicznej, która za stosunkowo niewielką cenę może stanowić mały i przenośny komputer, a raczej mikrokomputer. To "otwarta" elektronika, która zapewnia podstawowe komponenty do tego, aby zainstalować na niej system operacyjny, podpiąć różne elementy i zastosować w różny sposób. No właśnie.

Prawdą jest, że to nie jest maszyna tak potężna jak normalny komputer - nie można się łudzić. Całość brzmi też jak obiekt zafascynowania osób parających się elektroniką, a niekoniecznie programiści w tym obszarze czują się pewnie (to zależy od konkretnej osoby). Tym niemniej, dość wielu koderów lubi mieć możliwość w miarę sprawnego testowania różnych rzeczy na taniej maszynie. Czasem chodzi o czystą zabawę, a czasem o realne zastosowanie w postaci domowego serwera, namiastkę smart home czy zewnętrznego dysku z różnymi usługami. A że Raspberry Pi jest zwykle tańszy niż nawet najprostsze komputery, to stanowią bardzo popularne rozwiązanie. Na tyle, że... przestały być bardzo tanie. I przy okazji z dostępnością też pojawił się pewien problem.

Tym niemniej, istnieją dwie alternatywy spod znaku RPi, które warto rozważyć. Pierwszą z nich jest Raspberry Pi Zero, który jest jeszcze bardziej uszczuplonym mikrokomputerem, bez pewnych komponentów domyślnie dostępnych w standardowej wersji. Tym niemniej, nadal pozwala zainstalować Linuxa oraz rozbudować płytkę, w efekcie czego może stanowić ciekawą alternatywę do zabaw z np. domowym serwerem. A że ta wersja RPi jest naprawdę niedroga, to można ją rozważyć zarówno w przypadku programisty, jak i fascynata elektroniki.

Choć w przypadku tego drugiego można jeszcze pokusić się o Raspberry Pi Pico, który jest nie tyle mikrokomputerem, co mikrokontrolerem i dużo lepiej sprawdzi się w przypadku projektów robotów, przedsięwzięć typowo elektronicznych i generalnie niskopoziomowych. Jest to ten sam poziom abstrakcji co choćby osławione Arduino, które zresztą też jest niezłym pomysłem na prezent. Tym niemniej, w tym przypadku mówimy już o zastosowaniach stricte związanych z hardwarem, a nie softwarem. A przypominam, że nie każdy programista to lubi i potrafi.

Koszulka lub kubek

Na koniec wspomnimy o najbardziej wyświechtanym pomyśle na prezent. Czasem się mówi, że jeśli ktoś komuś kupuje koszulkę lub kubek, to nie miał koncepcji na coś lepszego. Nie jest to prawda i choćby dlatego ta sekcja znalazła się w tym artykule.

Koszulka z ciekawym napisem, rysunkiem czy cechą nawiązującą do jakiejś pasji osoby potrafi naprawdę mocno ucieszyć. Podobnie jest z kubkiem, który ku zadowoleniu programisty pomieści potem herbatę czy kawę wypijaną podczas kolejnych minut intensywnej pracy. A ludzie (nie tylko specjaliści IT) lubią takie gadżety, którymi mogą się pochwalić czy to w biurze, czy nawet na telekonferencjach, np. zaskakując rozmówców niezwykłym t-shirtem. Oczywiście, nie dotyczy to każdego człowieka, ale przestrzegałbym przed lekceważeniem takich prezentów, ponieważ nie jest to wcale "pójście na łatwiznę". Szczególnie, jeśli trzeba zlecić wydruk takiego przedmiotu z odpowiednią grafiką.

W tym aspekcie można też pomyśleć o czymś bardziej niezwykłym. Pamiętajmy, że programiści często obracają się w kulturze internetowej, a to oznacza "podatność" na memy. Swego czasu, jednemu koledze w biurze (pozdrawiam, Szymonie) kupiliśmy puzzle, które układały się w jeden mem specjalnie lubiany w biurze. Linka nie dam, gdyż niespecjalnie się tutaj nadaje, ale tak czy inaczej samą ideę polecam rozważyć.

Podsumowanie

Tak, jak pisałem, przedstawione porady nie dotyczą tylko świąt, ale też innych okazji. Nie jest to też na pewno kompletna lista - celem tego tekstu nie było doradztwo konsumenckie i przedstawienie stanu rynku, ale bardziej dostarczenie pomysłów i inspiracji na to, co można kupić programiście, gdy nie do końca potrafimy wymyślić coś związanego z jego osobowością i nie znamy potrzeb. To się zdarza i nie ma w tym nic strasznego. Tym bardziej mam nadzieję, że ten artykuł trochę Wam pomoże. A jeśli macie dodatkowe pomysły, zapraszam do podzielenia się nimi w komentarzach - wszyscy na tym zyskamy.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Czy wszystkie zadania można zrównoleglić? https://wildasoftware.pl/post/czy-wszystkie-zadania-mozna-zrownoleglic?ref=rss https://wildasoftware.pl/post/czy-wszystkie-zadania-mozna-zrownoleglic?ref=rss Thu, 16 Nov 2023 17:30:00 +0000 "Możesz wydzielić część zadania innej osobie, aby było szybciej?". Wielu programistów słyszało w swoim życiu podobne pytanie co najmniej raz, a najpewniej takich razów było kilka. Natomiast nie tylko osoby techniczne spotykają się z koniecznością odpowiedzi na ten dylemat - równie często, a może i nawet częściej w podobnej sytuacji znajdują się osoby z kadry kierowniczej, którzy rozmawiają z klientem i tłumaczą mu, że realizacji pewnych rzeczy nie da się przyspieszyć. A zleceniodawca pyta "dlaczego?".

No właśnie - jak to jest, że są zadania, które można wykonać szybciej poprzez przydzielenie większej liczby osób, ale są też takie, w których nijak nie da się tego zrealizować? Od czego zależy to, że są tematy, które muszą zostać poprowadzone przez jedną osobę, ale bywają takie, w których mimo ogromnego nakładu pracy, może ona rozłożyć się na kilku programistów? Czy w ogóle są jakieś "wzory" na obliczanie takich rzeczy?

Czy dziewięć kobiet urodzi jedno dziecko w miesiąc?

Na początku trochę teorii, jednak spokojnie - związanej z dzisiejszym tematem, dodatkowo wyjaśniającej słynne zdanie znajdujące się w tytule tego podrozdziału. A jest ono często przywoływane właśnie w kontekście równoczesnej pracy wielu osób i na jego podstawie tłumaczy się absurd w przydzielaniu kilku programistów do zadania, które nijak nie może być podzielone. Aby podejść do tego bardziej naukowo, przywołamy sobie dwa prawa, które pojawiają się w obszarze informatyki zajmującej się problemami zrównoleglania obliczeń. I od razu zastrzegam - będę to tłumaczył tak, że nie zdacie na tej podstawie żadnego egzaminu, więc lepiej uczcie się z poważnych źródeł, a poniższy opis co najwyżej jako metaforę.

Pierwsze z tych praw to prawo Amdahla. Pokazuje ono, że przyspieszenie wykonywania obliczeń (czyli działania programu) ma granicę wynikającą z części, która musi być wykonywana sekwencyjnie. Intuicyjnie pewnie każdy to rozumie, ale na przykładzie - jeśli normalnie obliczenia wykonują się przez 10 godzin, ale fragment 2-godzinny musi być realizowany sekwencyjnie (czyli instrukcja po instrukcji, bez czegoś dziejącego się "w tle"), to niezależnie od tego, ile procesorów zostanie przydzielone, minimalny czas wykonania programu nigdy nie spadnie poniżej tych 2 godzin. Sama teoria związana z tym prawem jest bardziej skomplikowana, ale przywoływanie wzorów nie jest tutaj moim celem.

Bardziej chodzi o przełożenie tego na wykonanie zadań - w tym przypadku procesorami są programiści, a obliczeniami zadanie do realizacji. Załóżmy, że jego czas został oszacowany na 60 godzin i możemy je podzielić na 3 podpunkty. Pierwszy z nich zajmie 30 godzin i musi być wykonany na początku, jednym ciągiem (sekwencyjnie). Druga część wymaga poświęcenia 20 godzin, a trzecia 10 i te fragmenty akurat mogą być realizowane równolegle, gdyż są od siebie niezależne. Pomijając czas poświęcony na scalenie zmian i ich weryfikację, widzimy, że przy działaniu dwóch programistów, całość najmniej wyniesie 30 + 20 = 50 godzin (tutaj jeszcze można zainteresować się tematem metody ścieżki krytycznej, CPM). Dość małe przyspieszenie. Pytanie, co by się działo, gdybyśmy te dwa podpunkty mogli podzielić na jeszcze mniejsze cząstki wykonywane równolegle - być może przy zastosowaniu większej liczby programistów przyspieszenie byłoby większe, jednak nigdy nie spadłoby poniżej 30 godzin. Idąc tym tropem i odpowiadając na pytanie z tytułu sekcji - poproszenie 8 dodatkowych kobiet nie spowoduje, że jedno dziecko urodzi się szybciej, gdyż ta jedna kobieta musi "wykonać to zadanie" sekwencyjnie. To nie jest tak, że jedna kobieta urodzi głowę, druga ręce, trzecia nogi i po połączeniu wysiłków pań powstanie jedno dziecko. Makabryczny przykład, ale mam nadzieję, że rozumiecie, o co mi chodzi.

Drugie z interesujących nas praw, to prawo Gustafsona, które bywa nazywane także prawem Gustafsona-Barsisa. Niesie ono ze sobą bardziej pozytywne hasło - każdy problem może być efektywnie zrównoleglony, o ile jest wystarczająco duży. Brzmi abstrakcyjnie (i w teorii informatyki takie jest), ale ma również odniesienie do praktyki.

Załóżmy, że jako s oznaczymy część wykonywaną sekwencyjnie, a p to część dająca się zrównoleglić przy użyciu n procesorów. W tym przypadku na jednym komputerze czas wykonania będzie wynosić s + n * p, gdyż to, co normalnie robiłoby n procesorów, tutaj musi być realizowane przez jedno CU. Natomiast cała idea polega na tym, że jeśli cały problem będzie wystarczająco duży (co oznacza, że część sekwencyjna będzie w niej coraz mniejsza, gdyż nieprawdopodobne jest, aby zwiększenie rozmiaru projektu powodowało wydłużenie jednego ciągłego procesu), to przyspieszenie w wyniku równoległości będzie dążyło do nieskończoności.

Idąc tropem poprzedniego przykładu - jeśli zadanie dane programistom, które wcześniej wynosiło 60 godzin i było podzielone na jedną część sekwencyjną oraz (następujące po nim) dwie równoległe, zostałoby znacznie rozszerzone i wynosiłoby teraz 1000 godzin, ale mogłoby zostać podzielone na wiele równoległych części, to mimo iż sekwencyjny fragment nadal by istniał (lub doszłyby jego nowe elementy), to stanowiłby mniejszość prac. Tym samym można rzucić więcej programistów do jeszcze większego zadania i uzyskać większe przyspieszenie niż przy mniejszym zadaniu. Ktoś w tym momencie powie, że przecież to oznacza dłuższy czas oczekiwania niż 50 godzin, ale tutaj chodzi o coś innego - im więcej wymagań dorzucimy do projektu, to ten czas 50 godzin nie będzie rósł zgodnie z "dodatkami", tylko przyrost będzie mniejszy. Wracając do przypadku 9 kobiet - prawo Gustafsona oznacza, że po 9 miesiącach 9 kobiet urodzi 9 dzieci. Więcej dzieci oznacza zwiększenie zakresu zadania i, faktycznie, w ten sposób przyspieszenie zostało osiągnięte - nie trzeb czekać 81 miesięcy, tylko 9.

Dlaczego w ogóle o tym piszę? Dlatego, aby pokazać, że problem zrównoleglania prac nie polega tylko na rzuceniu w bój N dodatkowych programistów - dużo zależy także od rodzaju problemu, zidentyfikowaniu części, której nie da się podzielić i musi ją realizować jedna osoba. Prawa Amdahla oraz Gustafsona pokazują, że ma to naukowe podstawy i chociaż oryginalnie te terminy wiążą się z obliczeniami równoległymi oraz procesorami, to w łatwy sposób mogą zostać przeniesione na grunt tworzenia oprogramowania i zarządzania zespołem. Tylko że jest jeszcze coś...

Charakterystyczne cechy zadań programistycznych

Realizacja wymagań funkcjonalnych to nie tylko czas spędzony nad samym projektowaniem i kodowaniem. Wspomniałem wyżej o tym, że nawet w przypadku zrównoleglania prac (a może właśnie z tego powodu) istnieje jeszcze potrzeba ich scalenia oraz sprawdzenia, czy po integracji działają. Kolejna rzecz to przeprowadzenie testów, co też zajmuje czas i wymaga obecności "wszystkiego na miejscu" od programistów (albo przynajmniej znaczącej części). Ale to jeszcze nie jest pełen obraz.

Klienci często zapominają, że developerzy są różni i nie każdy z nich dysponuje odpowiednim doświadczeniem pozwalającym na wykonanie danego zadania efektywnie. Co więcej, poszczególne jednostki znają lepiej jedną część systemu, a gorzej inną. Czasem trzeba też najpierw zaprojektować fragment architektury wykorzystywany przy kilku zadaniach lub mimo równoległości, te zadania w jakiś sposób z siebie "korzystają" (choć to może być objaw błędu w zarządzaniu przydziałem wymagań). Istnieją też wymagania, których nijak nie da się sensownie podzielić, aby nie powodowało to większego zamieszania. Dlatego np. przy ustalaniu zakresu sprintów unikamy proponowania zadań z jednego modułu, nawet jeśli jest on priorytetowy. Istnieje bowiem ryzyko, że poszczególne zadania będą ze sobą tak związane, iż nie będzie możliwe ich rozdzielenie na 2-3 programistów, przez co i tak nie zmieści się w sprincie (i to mimo że oszacowanie czasowe jest mniejsze niż liczba programistów * liczba godzin pracy programisty), a dodatkowo niektórzy będą musieli dostać zadania spoza projektu, aby się nie nudzić. Dlatego często bywa tak, że umawiamy się, iż jeden moduł robimy w połowie w danym sprincie, ale dokładamy do tego połowę drugiego priorytetowego modułu. A w następnym sprincie robimy drugie połowy obu, dzięki czemu mamy zastosowane prawo Gustafsona w praktyce - w ciągu 2 sprintów "urodziliśmy" 2 moduły, ale - tym razem zgodnie z prawem Amdahla - nie bylibyśmy w stanie stworzyć 2 modułów w 1 sprincie wykorzystując 2 razy więcej programistów.

A żeby tego wszystkiego było mało, to przecież realizacją tych zadań i monitorowaniem ich progresu musi ktoś zarządzać. Od tego jest kierownik projektu czy product owner, których pracą jest nadzorowanie, reagowanie na problemy i planowanie przydziału tak, aby dowieźć wartość biznesową w efektywny sposób. Tylko czy zwiększając zespół np. dziesiękrotnie nie powodujemy nawału pracy także u osoby zarządzającej, która ma nagle wiele osób do nadzorowania i odpowiadania na pytania? Być może wówczas pion kierowniczy również powinien zostać zwiększony, ale przecież te osoby też musiałyby się wtedy podzielić oraz wzajemnie informować się o postępach (i to w bardziej złożony sposób niż poprzez stand-up meetingi). Jakby było mało problemów...

Oczywiście, to wszystko zależy od samego projektu i zadań. To bardzo indywidualna kwestia i bywają sytuacje (nawet częste), kiedy jedną dużą funkcjonalność udaje się "upchnąć" w sprincie. Natomiast trzeba pamiętać, że nie zawsze jest to takie proste i możliwe.

Czy podział zadania zawsze jest pozytywny?

Czytając poprzednią sekcję prawdopodobnie wiecie już, że tak nie jest - nie zawsze szukanie na siłę równoległych prac w zadaniu przyniesie oczekiwany skutek. Przykładowo, jeśli tworzymy moduł powiadomień i mamy pięć wymagań związanych z pięcioma różnymi rodzajami powiadomień, to mimo iż w jakiś sposób różnią się one od siebie, to bardzo prawdopodobne jest, że korzystają z podobnych koncepcji, a co za tym idzie - rozwiązań w kodzie. I teraz, rozdzielając te zadania wśród pięciu różnych programistów, oni mogą to zrobić nawet w jeden dzień zamiast w tydzień. Ale jest zagrożenie, że zostanie to okupione powtarzającym się kodem czy różnym sposobem rozwiązania tego samego dylematu, występującego w kilku z tych zadań. Oczywiście, można z tym sobie poradzić bardziej dzieląc punkty funkcjonalne i wyróżniając wspólną część w postaci interfejsu, którego implementacją zajmie się jedna osoba, natomiast nie zawsze warunki pozwalają na to, aby można było się w ten sposób bawić.

Podsumowanie

Oczywiście, nie zrozumcie mnie źle - odpowiedni podział zadań jest kwestią kluczową i jak najbardziej pozwala szybciej tworzyć oprogramowanie bez utraty jakości. Duże projekty są tworzone przez zespoły, a nie jedną osobę i siłą rzeczy wymagania muszą dać się zrównoleglić. Tym niemniej, warto pamiętać o tym, że istnieją naukowe przesłanki mówiące o tym, że to nie jest tak, iż rzucenie kilku dodatkowych programistów magicznie przyspieszy tworzenie oprogramowania w każdej sytuacji. Trzeba umiejętnie zidentyfikować wąskie gardła i rozsądnie gospodarować zasobami. Nie mówiąc już przy tym o kwestiach czysto biznesowych, wiedzy o projekcie, doświadczeniu czy tak prozaicznej rzeczy jak zdolność do wspólnego działania w grupie. Zwyczajnie - nie wszystko da się robić jednocześnie. Ale warto próbować.

Przy pisaniu artykułu wykorzystałem materiały dr. inż. Rafała Walkowiaka z Politechniki Poznańskiej (z przedmiotu "Przetwarzanie równoległe"). Przyznaję, że czasem zaskakuje mnie, jak często wracam do niektórych tematów omawianych na uczelni, które teraz zaczynają układać mi się w całość. Poza tym, standardowo wspomogła mnie Wikipedia oraz takie artykuły, jak choćby ten.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Programista i administrator to nie to samo https://wildasoftware.pl/post/programista-administrator-nie-to-samo?ref=rss https://wildasoftware.pl/post/programista-administrator-nie-to-samo?ref=rss Thu, 02 Nov 2023 17:30:00 +0000 Wielokrotnie na blogu dawałem do zrozumienia, że programista i administrator to osoby o dwóch różnych specjalizacjach i zestawie umiejętności. Obie są informatykami i pracują w firmach IT zajmujących się np. oprogramowaniem. Natomiast nie wszystkie software house'y dysponują administratorami, podobnie jak istnieją firmy, które oferują wyłącznie usługi serwerowe. Co ważniejsze, nie każdy programista będzie umiał pomóc w kwestiach wdrożeniowych, podobnie jak administratorzy nie mają w zwyczaju debuggować i poprawiać kodu aplikacji. Ta uwaga dotyczy także freelancerów, tak popularnych u niektórych klientów - są wśród nich świetne osoby, jednak nie należy ich traktować jako "specjalistów od wszystkiego".

Dlaczego o tym piszę? Ponieważ klientom zdarza się myśleć, że specjalista IT będzie jego "jednoosobową armią", a przy większych systemach tak się po prostu nie da. Dzisiaj porozmawiamy (a właściwie popiszemy i poczytamy) sobie, z czego to wynika, jakie są różnice pomiędzy programistami oraz administratorami, a także dlaczego trudno znaleźć specjalistów od jednego i drugiego.

Czym zajmują się te osoby?

Na początku odpowiemy sobie na pytanie, kim jest programista. W skrócie - jest to osoba, która pisze programy, ale nie tylko. To również specjalista od konstruowania i analizy software'u, aby zapewnić nie tylko wymaganą funkcjonalność, ale też elastyczność, bezpieczeństwo i dobrą architekturę (choć tutaj moglibyśmy się już spierać, czy nie zahaczamy o rolę architekta oprogramowania, obecnej w większych firmach). Programista to zatem człowiek, który przygotuje kod składający się na paczkę, która będzie udostępniona na serwerze (zakładamy, że mówimy o aplikacjach webowych).

Jednak tę paczkę na serwerze trzeba również umieścić w konkretny sposób i w odpowiednim środowisku. I o ile programiści często faktycznie wrzucają swoją aplikację w wyznaczone miejsce, o tyle zwykle nie są odpowiedzialni za przygotowanie samego środowiska. Tym zajmuje się zazwyczaj administrator, a więc osoba, która doskonale zna się na systemach operacyjnych (w tym przypadku serwerowych) oraz konfiguracji pozwalającej na optymalne wykorzystanie zasobów i działanie kodu. To także specjalista wiedzący, jakie paczki instalacyjne powinny być zainstalowane, aby spełnić potrzeby nie tylko oprogramowania, ale też np. bezpieczeństwa. To on lub ona tworzy odpowiednie uprawnienia, zarządza nimi i zabezpiecza serwer przed niepowołanym dostępem. Może też coś podpowiedzieć w kwestii optymalizacji wykorzystania zasobów lub zwyczajnie zapewnić dodatkowe możliwości środowiska. Administrator jest też często człowiekiem znającym strukturę sieci, wszystkie przekierowania i odpowiada za ustawienie serwera HTTP oraz systemu do zarządzania bazami danych.

Krótko mówiąc i upraszczając wiele aspektów, programista tworzy to, co administrator później utrzymuje na serwerze. Różnice leżą nie tylko w umiejętnościach czy zakresie odpowiedzialności (o czym jeszcze będzie dalej), ale także w czasie pracy. Koderzy zwykle pracują w normalnym trybie, czyli 8 godzin dziennie (no... standardowo) w dni robocze. W przypadku adminów sprawa jest bardziej skomplikowana, gdyż opieka nad serwerem w większości przedsięwzięć IT teoretycznie powinna przebiegać w trybie 24 godziny przez 7 dni roboczych. Oczywiście, nie jest to fizyczne możliwe bez całego zespołu administratorów, którzy nawzajem się zmieniają. Dlatego bywa, że wyznacza się godziny "urzędowania" (co jest łatwiejsze w przypadku aplikacji typowo użytecznych dla jednej firmy) lub organizuje to wszystko w ramach umowy serwisowej, gdzie specjalista zapewnia pewną pulę godzin do wykorzystania w ciągu pewnego okresu. Dodatkowo, działania administracyjne nie są "pracą stałą" - poza zleceniami od klienta na skonfigurowanie serwera czy wzmocnienie maszyny, jest to często obsługa incydentów. Rozmawiając z administratorami można usłyszeć opowieści o tym, jak to bywały miesiące, w których musieli być tylko dyspozycyjni oraz czuwać, ale gdy przychodziły zadania, to wszystkie naraz i z adnotacją "na wczoraj".

Do tego dochodzi konieczność współpracy pomiędzy programistami oraz administratorami. Trzeba uczciwie przyznać, że różnie z tym bywa - jako że admini są odpowiedzialni za przygotowanie środowiska, a każda dodatkowa aplikacja wymaga konfiguracji oraz może wpłynąć na już inne, zainstalowane, to zazwyczaj nie jest chętny, aby dołączać do systemu wszystkie zachcianki programistów. Z kolei programiści chcieliby mieć wszystkie potrzebne narzędzia do dyspozycji, a jednocześnie w przypadku problemów liczyć na admina. Tym niemniej, nie jest tak źle - w profesjonalnym świecie jak najbardziej te dwie strony dogadują się bez problemów i zachowują zdrowy podział. Natomiast wiele osób interesuje się tym, co się dzieje, kiedy na serwerze wystąpi błąd. Bywa, że wówczas jedni wskazują na drugich, a drudzy na pierwszych. Prawda jest taka, że wszystko zależy od natury błędu i tego, co odpowiada strona WWW, która przestała działać. Jeśli w ogóle się nie wyświetla lub np. widoczny jest błąd certyfikatu SSL, zwykle odpowiada za to administrator. Jeśli jednak dostęp do aplikacji istnieje, ale następuje błąd podczas jej uruchomienia lub dostępu do danej strony, to zazwyczaj działanie spada na barki programistów. Obie strony mają do dyspozycji logi i na tej podstawie mogą ocenić, co się tak naprawdę stało. Ważne, aby współdziałać i znać swoje możliwości oraz zakres odpowiedzialności, a nie bezsensownie walczyć. Pamiętajcie - szacunek przede wszystkim.

Co łączy te role, a co różni?

Specjaliści w obu obszarach mają dużą wiedzę w zakresie działania oprogramowania i orientują się w nowych narzędziach służących uruchamianiu aplikacji. Oczywiście, taka znajomość i umiejętności są bardziej kojarzone z programistami, natomiast trzeba pamiętać, że administratorzy również muszą być na bieżąco, aby móc odpowiednio świadczyć usługi i umieć doradzić. Nierzadko osoby opiekujące się serwerami dla wielu firm muszą więcej doczytywać, aby móc obsługiwać technologie stosowane i "klarowne" dla każdego zespołu, który jest ich klientem. Przedstawiciele obu ról radzą sobie też z Linuxem, który jest standardem branżowym (choć programiści jak najbardziej też pracują na Windowsie oraz macOS).

Różnica polega na podejściu obu ról do narzędzi programistycznych. W przypadku programistów jest to wiedza związana z tworzeniem i projektowaniem oprogramowania. To oni koniec końców wiedzą, jak to wszystko działa w środku, jakie są możliwości rozbudowy i de facto co potrzebują pod kątem paczek na serwerze. Natomiast często nie są w stanie w szczegółach ustalić, jakie parametry konfiguracyjne serwera są potrzebne, jaka ilość pamięci RAM będzie wystarczająca oraz co dokładnie trzeba zrobić, aby serwer HTTP prawidłowo serwował stronę internetową.

Z kolei administratorzy właśnie w tym są mistrzami, a dodatkowo umieją zaproponować odpowiedni sprzęt do danego zastosowania. Doskonale orientują się w możliwościach Linuxa i to w obszarach, do których programiści zwykle nie zaglądają. Dbają też o aktualizację systemu operacyjnego na serwerze, mają większą wiedzę hardware'ową, a także o środowisku sieciowym. Potrafią również obsługiwać narzędzia zabezpieczające środowisko na wypadek ataków, analizują logi, reagują w przypadku braku zasobów (np. dysku)... Natomiast kwestię tego, jak działa aplikacja i czy konstrukcje programistyczne użyte przez software house są poprawne, zupełnie nie muszą ich interesować. Co najwyżej podpowiedzą, że widzą np. znaczne użycie pamięci w sytuacji, która nie powinna tego powodować, natomiast nie są w stanie powiedzieć "przestaw te dwie pętle oraz napisz ten warunek inaczej".

To, co piszę, to dość szablonowe przedstawienie różnic pomiędzy obiema rolami i domyślam się, że niektórzy poczują się urażeni oraz ogłoszą, że przecież znają programistów, którzy sami potrafią zadbać o serwer, a także administratorów, którzy jak najbardziej są w stanie napisać aplikację. I to racja. Dlatego zaraz o tym porozmawiamy.

Czy jedna osoba może pełnić obie role?

Jak zawsze, są specjaliści, którzy potrafią odnaleźć się w obu obszarach - zarówno programują lub przygotowują oprogramowanie, jak i potem je wdrażają oraz utrzymują. Często wspomniani już freelancerzy są całkowicie samodzielni i oferują klientom swoje usługi dotyczące skonfigurowania serwisu na podstawie CMS, a później zadbania o nie na serwerze. A nawet nie tylko na podstawie CMS, ale też samodzielnie napisanej aplikacji. Czy zatem osoby, które nie potrafią pełnić obu funkcji są... wybrakowane? Absolutnie nie, gdyż wszystko zależy od skali.

Każdy programista ma (a przynajmniej powinien mieć) minimalną wiedzę o administracji serwerem, aby zrozumieć drugą stronę. Podobnie dobrze by było, gdyby admini potrafili zrozumieć, dlaczego takie, a nie inne decyzje podjęli programiści. Dzięki temu strony mają dla siebie więcej zrozumienia i szybciej potrafią wypracować rozwiązanie napotkanych problemów. Jeszcze lepiej, gdyby przedyskutowali te kwestie przed rozpoczęciem prac, aby znaleźć ewentualne problemy z usługą, na której planuje się postawić system. Natomiast nie ma co ukrywać, że w przypadku większych aplikacji, skrojonych pod potrzeby klienta, znalezienie kogoś będącego ekspertem w obu dziedzinach to swego rodzaju trafienie na garniec złota na końcu tęczy. O wiele bardziej pasuje tutaj powiedzenie "jeśli coś jest do wszystkiego, to jest do niczego", mimo że może być to obraźliwe dla paru osób.

Specjaliści mający wiedzę i umiejętności pozwalające na programowanie lub administrowanie dużymi systemami muszą te elementy pozyskać. I to nie poprzez przeczytanie miliona książek czy tutoriali, ale praktykę z produkcyjnymi systemami, prawdziwymi potrzebami klientów oraz problemami w działaniu. Niestety - na to potrzeba czasu i zaangażowania. Siłą rzeczy człowiek poznaje ten drugi obszar niejako przy okazji rozwijania się w tym pierwszym, ale nie jest w stanie być ekspertem w obu naraz. Zwłaszcza, że praca administratorów często wymaga zastosowania przygotowanej wcześniej wiedzy w krótkim momencie, nierzadko w ciągu kilku godzin czy nawet minut od zaistnienia potrzeby. I teraz wyobraźcie sobie programistę, który ma szybko postawić firewalla na serwerze i wpisuje w wyszukiwarkę "how to enable firewall on ubuntu", poniewać "coś kiedyś czytał, ale nie jest teraz pewien, a nie chce zepsuć".

Natomiast istnieje rola, która łączy te dwa obszary w bardzo dużych firmach, często zajmujących się swoimi autorskimi projektami, choć nie tylko. Jest to termin pewnie Wam znany - mianowicie chodzi mi o specjalistę DevOps, gdzie "DevOps" (będący metodyką) pochodzi od "development and operations". Nieprzypadkowo też dodałem słowo "specjalista", gdyż chodzi o osobę, która tę metodykę uskutecznia, aczkolwiek często mówi się też po prostu "DevOps". Jest to człowiek będący pomostem pomiędzy zespołem programistów a administratorów w sytuacjach, kiedy wydania (ang. realeses) oprogramowania są bardzo częste, obejmują dużą skalę i siłą rzeczy to wszystko musi być zautomatyzowane. De facto DevOps bardziej kojarzy się z administracją niż z programowaniem, natomiast to nie do końca tak jest - są to osoby, które sterują i wręcz ustalają proces zautomatyzowanej budowy paczek z oprogramowaniem, wersjonowania ich, konfigurują odpowiednie środowisko programistyczne oraz same serwery, korzystając przy tym najczęściej ze skryptów uruchamianych w takich narzędziach jak Ansible, Puppet czy Terraform. Popularyzacja tego obszaru IT wyrosła z uwagi na coraz bardziej skomplikowane oprogramowanie, większe potrzeby skalowania aplikacji, konteneryzację (DevOps może np. tworzyć pliki Dockerfile i rozwiązywać problemy związane z kontenerami, gdyż szybciej się w tym odnajdzie niż programista) oraz zintensyfikowanie stosowania chmur. Dlatego ta rola w mniejszych firmach nie jest aż tak potrzebna jak w większych zespołach, co nie oznacza, że nie może występować.

Czy zawsze firma IT potrzebuje administratora?

Są firmy, które posiadają swój zespół administracyjny, wdrożeniowy czy specjalistów DevOps, ale istnieją też takie, które polegają na zewnętrznych dostawcach i usługodawcach. Najczęściej zależy to od rozmiaru zespołu IT, a także zwyczajnie potrzeb. Nie da się ukryć, że rola administratora na miejscu wzrasta w momencie, kiedy firma tworzy własne oprogramowanie na rynek, często aktualizowane lub projektów IT jest tyle, że - mówiąc obrazowo - nie ma nudy. W przypadku, kiedy okresy wdrożeniowe są od siebie bardzo oddalone lub charakterystyka techniczna aplikacji jest dość prosta, najczęściej korzysta się z outsourcingu.

Natomiast istnieje jeszcze jeden aspekt, o którym należy pamiętać - administratorem nie musi być tylko osoba, która utrzymuje oprogramowanie dla zewnętrznych użytkowników. Ten termin może oznaczać też człowieka, który zarządza wdrożeniami wewnątrz firmy i reaguje w przypadku wystąpienia różnych problemów, np. z siecią. Każdy z nas zna pewnie pojęcie "informatyka w urzędzie" czy "informatyka zakładowego" (pozdrowienia dla Tomka Zielińskiego), który w równym stopniu jak usługami na potrzeby organizacji, odpowiada również za systemy uprawnień, sprzęt, sieć komputerową i jest konsultantem przy wszystkich zakupach informatycznych czynionych przez urząd lub firmę. To też osoba, którą można nazwać administratorem, tylko o innym zakresie odpowiedzialności.

Podsumowanie

Najważniejsze kwestie to potrzeba rozróżnienia ról programisty oraz administratora - to nie są te same typy informatyków i o ile pewne aspekty są wspólne, o tyle usługi zapewniane przez ludzi z obu obszarów są diametralnie różne i nierzadko wykonywane w innym trybie czasowym. Klient musi też rozumieć, że nie wszystko jest w stanie ustalić z programistą bez uczestnictwa ze strony administratora. A w tym wszystkim przewija się jeszcze metodyka DevOps, tak modna (i nie ma co ukrywać - potrzebna) w dzisiejszych czasach.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Model V w testowaniu oprogramowania https://wildasoftware.pl/post/model-v-testowaniu-oprogramowania?ref=rss https://wildasoftware.pl/post/model-v-testowaniu-oprogramowania?ref=rss Thu, 19 Oct 2023 17:30:00 +0000 Każdy wie o tym, że jeśli realizuje się cokolwiek, to po wykonaniu wypada swoje dzieło sprawdzić. Nie inaczej jest w przypadku oprogramowania - wszyscy doskonale znamy pojęcie "buga" i ogólnie błędów w programach. Niektórzy doświadczyli ich w samym Windowsie (lub macOS), inni w różnych programach biurowych, a jeszcze inni z tym słowem zetknęli się grając w różne gry, gdzie napotkanie niedoskonałości kodu mogło skończyć się śmiechem lub gniewem. Nikt nie lubi błędów i najchętniej wszyscy byśmy się ich pozbyli z przeróżnych aplikacji, nawet jeśli są pocieszne (błędy, nie aplikacje). Czy można to zrobić? Nie całkiem, ale są techniki, które w tym pomagają.

Oczywiście, program komputerowy jest zapisany w postaci kodu, a więc sekwencji instrukcji. Jest to coś, co można przedstawić w sposób matematyczny, a to z kolei sprawia, że istnieje teoretyczna możliwość formalnego sprawdzenia poprawności takiego programu. Jednak, poza zapewne nielicznymi przypadkami, tego się nie robi z prostego powodu - jest to trudne i niemożliwe z praktycznego punktu widzenia, gdy aplikacje są obecnie gigantyczne, asynchroniczne, podzielone na wiele składowych (w tym mikroserwisy) i zależą od mnogości parametrów.

Pozostają zatem inne metody, w tym statyczne (do których zaliczają się między innymi przeglądy kodu) oraz dynamiczne. Wśród tych ostatnich mamy do czynienia z testowaniem, o którym dzisiaj skrótowo sobie porozmawiamy, pokazując, że nie dotyczy ono tylko jednego poziomu oprogramowania. A przy okazji rozjaśnimy sobie parę pojęć.

Czym jest model V?

Przejdźmy od razu do bohatera dzisiejszego tekstu, a mianowicie koncepcji, która nazywa się modelem V. Żeby jednak lepiej go zrozumieć, najpierw musimy podzielić sobie testy na manualne oraz automatyczne. Te pierwsze są dość proste koncepcyjnie - jest człowiek, który "przeklikuje" aplikację, sprawdzając różne przypadki ręcznie i wypisując błędy, które zauważy. Oczywiście, wiele osób krzyknie teraz, że to w ogóle bez sensu, gdyż wszystko powinno się weryfikować automatycznie. Poniekąd mają rację - testy ręczne mają swoje duże wady, wśród których najczęściej wymienia się czas ich przeprowadzania, brak powtarzalności oraz czynnik ludzki w postaci testera, który może się zmęczyć lub czegoś nie zauważyć. Ale, wbrew pozorom, manualne testy nadal mają sens, gdyż o ile w długiej perspektywie ich czas realizacji jest dłuższy niż automatów, o tyle do szybkiej pojedynczej weryfikacji jak najbardziej się nadają i można do niej przystąpić z marszu. Nie wymagają też żadnego przygotowania od strony kodu, a na dodatek pozwalają testować aplikację z perspektywy normalnego użytkownika, co często jest bardzo istotne i jeszcze do tego wrócimy.

Z drugiej strony nie można zaprzeczyć zaletom testów automatycznych - znacząco ułatwiają ponowną weryfikację, a także (a może i przede wszystkim) pozwalają robić tzw. testy regresyjne, a więc sprawdzenie, czy nowe zmiany nie naruszyły istniejących funkcji. Istnieją też jednak wady - wymagają odpowiednich bibliotek, zakodowania i w przypadku, kiedy coś weryfikowane jest raz, mogą zająć więcej czasu niż ręczne testowanie (inna sprawa, że nigdy nie jesteśmy w stanie przewidzieć, czy do weryfikacji czegoś jeszcze nie wrócimy). Do tego nie są takie proste przy testowaniu interfejsu użytkownika, a przynajmniej nie wszystko pozwolą zweryfikować. Tym niemniej, to tak użyteczne narzędzie, że nie sposób go pominąć i dodatkowo stanowi podstawę tego, do czego dążymy, a więc modelu V.

Bloczki układające się w literę V. Od góry - po lewej jest \

Zerkając w różne opracowania, znajdziecie różniące się od siebie przedstawienia tego modelu. Czasem brakuje jednego stopnia, innym razem układ jest nieco inny, natomiast wszystkie sprowadzają się do tego, że testowanie zachodzi na różnych poziomach, z których każdy odpowiada konkretnego etapowi tworzenia oprogramowania. Przyjrzyjmy się im od dołu, po kolei.

To, z czym większość kojarzy samo programowanie, to tworzenie plików z kodem i klasami w paradygmacie obiektowym, które zawierają pewną wydzieloną część całego programu. Przykładowo, możemy mieć plik reprezentujący jakiś obiekt, element logiki biznesowej, kontroler czy klasę pomocniczą. W każdym znajdują się jakieś funkcje czy metody, przyjmujące określone parametry i zwracające dla nich konkretny wynik (pomijając kwestię losowości). Możemy się spodziewać, że jakość oprogramowania zależy między innymi od tego, czy wszystkie metody działają prawidłowo, a więc każdą z nich trzeba przetestować. To robi się testami jednostkowymi (ang. unit tests), które każdą metodę pozwalają zweryfikować pod kątem różnych przypadków, zwłaszcza brzegowych oraz wyjątkowych (a więc takich, w których programista mógł nie dopatrzyć czegoś lub źle zinterpretować). To są testy przeprowadzane najczęściej i są trudne do zrobienia w inny efektywny sposób sposób niż automatyczny.

Wróćmy do tego, że jakość oprogramowania zależy od tego, czy wszystkie składniki zachowują się poprawnie. Teraz zaprzeczę sam sobie, ponieważ nie do końca tak jest - może się okazać, że wszystkie metody klas w ramach danego modułu działa dobrze, ale nie są właściwie wywoływane lub nie wpływają na siebie odpowiednio (czy też wpływają na siebie aż za bardzo). W sieci można znaleźć dużo żartobliwych przykładów takiej sytuacji, często w postaci gifów:

Dlatego większe fragmenty architektury oprogramowania, czyli zestawy modułów lub wręcz całe architektury sprawdza się za pomocą testów integracyjnych. Działają one tak samo, jak testy jednostkowe i też zwykle są zautomatyzowane, natomiast skupiają się nie na metodach (gdzie jeden test testuje konkretny przypadek metody), ale raczej całych sekwencjach zdarzeń, spójności poszczególnych obiektów ze sobą i kolejności wywoływania poszczególnych elementów.

Idąc dalej musimy pamiętać o tym, że architektura systemu jest tworzona po to, aby zaspokoić wymagania funkcjonalne i pozafunkcjonalne. Te podlegają testom systemowym (funkcjonalnym) oraz testom pozafunkcjonalnym - jak można spodziewać się po nazwach, odpowiadają one poszczególnym typom elementów zaimplementowanych w oprogramowaniu. Dużo ciekawsze są testy pozafunkcjonalne, gdyż pozwalają zweryfikować np. wydajność, obciążenie czy bezpieczeństwo systemu, a więc kwestie, których nie da się zbadać prostymi metodami i w każdych warunkach. Część weryfikacji można przeprowadzić ręcznie (jak np. niektóre punkty związane z bezpieczeństwem), ale trudno wyobrazić sobie, aby takę ścieżkę przyjąć w przypadku obciążenia - nie będziemy prosić np. wszystkich studentów, aby w jednym momencie weszli na stronę. Na szczęście, są takie narzędzia jak JMeter czy k6, które mogą w tym pomóc.

Ostatni, najwyższy poziom to nadal wymagania, ale rozumiane trochę szerzej - jak najbardziej mamy tutaj do czynienia z testowaniem wymagań funkcjonalnych, ale bardziej chodzi o przepływ użytkownika i przy okazji walidację tego, czy wszystko jest w porządku z "ludzkiego" punktu widzenia. Tutaj może warto na chwilę się zatrzymać i wyjaśnić, że weryfikacja i walidacja to dwa różne pojęcia. Pierwsze polega na sprawdzeniu, czy oprogramowania działa zgodnie z wymaganiami, a więc można powiedzieć, czy wszystkie punkty są odhaczone i wszystko zgadza się "matematycznie". Natomiast walidacja to "test" tego, czy oprócz poprawnej implementacji wszystko działa tak, jak oczekuje klient i spełnia jego, czasem niewypowiedziane wcześniej, wymogi. Co z tego bowiem, że w systemie jest możliwość dodania produktu do koszyka, wyświetlenia tego koszyka i zamówienia produktu, jeśli żadna z tych funkcji nie jest łatwo dostępna i nie tworzą razem scenariusza, który wręcz narzuca się użytkownikowi będącemu na stronie. Można więc powiedzieć, że mamy powtórkę z kodu - każde wymaganie może być zaimplementowane idealne, ale razem nie tworzą dobrego systemu. Za sprawdzenie tego odpowiadają testy akceptacyjne, które często są tworzone bardzo wcześnie (wręcz przy okazji tworzenia wymagań) i to przy udziale klienta. Wtedy najczęściej mówimy o manualnych testach akceptacyjnych (tzw. MATach) lub ich prostszej, mniej formalnej formie - punktach Definition of Done, które stanowią drogowskaz dla programisty. I nie da się ukryć, że tutaj akurat ręczne testy często okazują się jeśli nie lepsze, to przynajmniej potrzebne, z uwagi na walidację i ludzką ocenę sytuacji. Natomiast należy pamiętać, że jak najbardziej istnieje możliwość testowania na tym poziomie w sposób automatyczny, do czego najpopularniejszym (aczkolwiek niejedynym) narzędziem jest Selenium, dostarczające zarówno interfejs graficzny, jak i API.

Testy testom nierówne

Warto jeszcze wspomnieć o paru pojęciach, które nieodłącznie kojarzą się z testowaniem. O tym, czym się różni weryfikacja od walidacji wspomniałem już wyżej. Teraz czas jeszcze wprowadzić termin czarnej i białej skrzynki. Pierwszy z nich (czyli popularne "black boxy") to takie testy, jakie może przeprowadzić każdy z nas - nie znając tego, co jest w środku, korzystamy z oprogramowania i patrzymy, jakie dostarcza wyniki. Nie musimy wiedzieć, jak wygląda implementacja pod spodem - liczy się dla nas tylko to, jakie są parametry wejściowe oraz wyjściowe. Z kolei "white boxy" biorą pod uwagę również implementację - tester wie, jak zbudowana jest dana metoda i gdzie można spodziewać się większych problemów, przez co może skupić się na ich weryfikacji. Obie ścieżki mają swoje zalety i wady - z jednej strony czasem lepiej się weryfikuje nie wiedząc, co dzieje się w aplikacji, a z drugiej mając tę świadomość można lepiej wycelować testy lub wręcz zauważyć gołym okiem jakieś braki.

Trzeba też wiedzieć, że testowanie nie dostarcza dowodu na to, że oprogramowanie działa poprawnie. Ono wzmacnia naszą pewność, że tak jest, natomiast siłą rzeczy weryfikacja oparta o różne przypadki testowe nie jest w stanie pokryć wszystkich możliwości, jakie mogą wystąpić na przestrzeni lat i - matematycznie ujmując - zweryfikować całej dziedziny argumentów. Nie mówiąc już o tym, że pod wpływem różnego obciążenia czy nowej wersji narzędzi, na których użytkownik uruchamia oprogramowanie, też mogą ujawnić się różne "file" i błędne działanie niewynikające z samych pomyłek programistycznych. Dlatego testować jak najbardziej warto (w jakikolwiek sposób), ale to nie jest tak, że 100% testów ukończonych poprawnie świadczy o bezbłędnym oprogramowaniu.

Warto też pamiętać, że testować należy jak najwcześniej - to dlatego w ogóle tworzymy wymagania oraz prototypy, aby pewne kwestie przetestować niskim kosztem. Im poźniej wystąpi dany błąd, tym zwykle więcej kosztuje jego naprawienie i to nie tylko budżetowo, ale też nerwowo. Stresów podczas tworzenia oprogramowania jest co niemiara - warto zabezpieczyć się przed ich dokładaniem sobie. A na wypadek, gdyby jakieś błędy przemknęły do dalszych prac lub pojawiły się nowe propozycje, warto skonfigurować sobie odpowiedni system.

Kto powinien testować?

Pytanie wydaje się głupie, gdyż wszyscy zaraz krzykną, że od tego jest dział Quality Assurance, czyli popularny QA. Jednak to tylko część prawdy. Rzeczywiście, zespoły IT często dysponują testerami, którzy zdejmują z programistów obowiązek weryfikowania każdego przypadku i są bezstronni. Jednak należy pamiętać o kilku rzeczach.

Po pierwsze, nie każda firma ma dział QA, choćby ze względów budżetowych. Po drugie, testerzy nie będą w stanie dobrze weryfikować programów, jeśli nie będą znali ich wymagań oraz oczekiwań klienta. Po trzecie, bycie testerem to wbrew pozorom dość trudna, a przede wszystkim żmudna praca, która wymaga uwagi oraz zwracania uwagi na szczegóły. Z tego powodu czasem mówi żartobliwie mówi się, że dział QA nie powinien lubić się z działem programistów, aby z większą zaciekłością szukać bugów i tym samym czynić oprogramowanie lepszym.

To wszystko sprawia, że nie można wszystkiego zrzucać na testerów i siłą rzeczy programista powinien w pewnym zakresie upewnić się, że jego kod działa poprawnie i spełnia różne, choćby podstawowe lub prawdopodobne przypadki. Pierwsza sprawa to zwykła ludzka przyzwoitość - w przeszłości słyszałem o przypadkach, w której koder wypuszczał oprogramowanie, które "wydaje mu się, że działa", licząc na to, że ktoś wyłapie błędy, bo jemu samemu nie chce się testować lub twierdzi, że nie ma na to czasu. To już nie tylko zła praktyka, ale też po prostu wstyd i brak poszanowania cudzej pracy. Druga kwestia to fakt, że o ile programista nie wszystko jest w stanie znaleźć będąc "zafiksowanym" na danym kodzie, to właśnie bycie tak blisko swojego kodu sprawia, że jest w stanie szybko i na gorąco poprawić oczywiste błędy, które widać po kilku przebiegach kodu. Później dotarcie do źródeł problemu będzie trudniejsze.

Omawiany model V pokazuje też inne stopnie testowania i tak np. testy akceptacyjne nie są tak naprawdę techniczne - to bardziej sprawdzenie oczekiwań klienta względem systemu. A więc mogą być przeprowadzane także zarówno przez osoby reprezentujące zespół IT, jak i samego klienta, który tylko w ten sposób może przekonać się, czy rozumie to, jak działa system oraz czy software house prawidłowo zrozumiał jego kontekst biznesowy.

Podsumowanie

To zaledwie wierzchołek góry lodowej tematu związanego z testowaniem oprogramowania, a przecież tak, jak pisałem - to tylko jedna z metod zapewniania jakości aplikacji. Model V może kształtować się trochę inaczej w zależności od potrzeb i nie ma potrzeby też ścisłego trzymania się tego podziału oraz pokrywania każdego stopnia we wszystkich projektach. Tym niemniej, stanowi poradnik, pozwalający dobrze podejść do weryfikacji oraz walidacji wykonywanej pracy.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> MacBook w pracy - porady i czy warto? https://wildasoftware.pl/post/macbook-pracy-porady-czy-warto?ref=rss https://wildasoftware.pl/post/macbook-pracy-porady-czy-warto?ref=rss Thu, 05 Oct 2023 17:30:00 +0000 Czasami w pracy bywa tak, że trzeba zmienić sprzęt. Może wynikać to z parametrów dotychczasowego laptopa, problemów z jego działaniem, specyficznymi potrzebami lub po prostu pragnieniem zmiany. Niedawno tak się stało w moim przypadku - biurowy sprzęt zaczął niedomagać, jakiś czas temu fizycznie uszkodziłem klawiaturę, przez co mimo interwencji serwisu irytowała podczas spotkań (kiedy nie miałem zewnętrznej), co jakiś czas Windows 11 prezentował "atrakcje" w postaci rozmytego ekranu (mimo nowych sterowników karty graficznej), a bateria przestała wystarczać nawet na krótkie wizyty u klienta. Co prawda, to wszystko po czterech latach, więc nie jest to zły wynik, ale w porozumieniu z szefami uznałem, że czas na zmianę.

I to zmianę totalną. Ogólnie nie przepadam za wybieraniem sprzętu - męczy mnie przeglądanie parametrów, porównywanie dostępnych opcji i poczucie, że zawsze mogę coś przeoczyć lub dołożyć trochę pieniędzy, aby mieć coś lepszego. I jeszcze dołożyć. I jeszcze. Z drugiej strony, stwierdziłem, że może być to okazja do większej rewolucji i zmiany nie tylko laptopa, ale też systemu operacyjnego. Przez chwilę rozważany był Linux, jednak okazjonalna praca na nim na serwerach to jedno, ale używanie go w pełnym wymiarze zawodowym to dość ryzykowna sprawa, biorąc pod uwagę doświadczenie oraz zadania, z którymi mam do czynienia. Dlatego przełamałem się i poprosiłem "górę" o pierwszy w moim życiu sprzęt z macOS na pokładzie.

(fani Apple'a są proszeni o pominięcie następnego akapitu)

Musicie wiedzieć jedno - delikatnie mówiąc, nigdy nie byłem fanem Apple'a jako firmy oraz jego urządzeń. Głównym powodem była przesadzona w mojej opinii cena oraz dość nieprzyjemne wrażenie po dyskusjach w sieci, w których fani "Jabłek" zachowywali się niekiedy jak wyznawcy religii, mówiąc "raz spróbujesz Apple'a, nigdy nie wrócisz do Windowsa/Androida". Nie bez powodu spotkałem się parę razy z określeniem "Kościoła" tej marki. Szczególnie zapadła mi w pamięć sytuacja, kiedy na Twitterze (znanym teraz jako X) zapytałem niegdyś, jaki smartwatch byłby polecany do pewnego konkretnego zadania i wyraźnie zaznaczyłem, że z pewnych powodów (urządzenia miały być kupowane w bardzo dużej liczbie przez osoby niekoniecznie majętne) nie może być to Apple Watch. Wśród odpowiedzi, które dostałem, mimo wszystko bardzo często powtarzało się "Apple Watch", a jedna osoba napisała mi nawet, że jeśli proszę o wybór innego zegarka, to on nie widzi sensu dyskutowania ze mną. Inny przypadek dotyczył próby zademonstrowania łatwości interfejsu iPhone'a i dziwnych minach prezentującego, gdy prosiłem go, aby pokazał, jak łatwo zmienia się sygnał dźwiękowy na swój własny (np. ulubiony utwór muzyczny) przy przychodzącym połączeniu. Dla tych, co nie wiedzą - jest to "trochę" trudniejsze niż w Androidzie.

Przepraszam za te złośliwości - musiałem to z siebie wyrzucić.

Mem z mężczyzną mówiącym do wyraźnie zmieszanej dziewczyny: Jak to nie lubisz Maców, przecież wszyscy lubią MacBooki, tak, jak w ogóle urządzenia Apple'a, wszystko w nich działa, jest piękne, nie wiem jak można nie lubić urzadzeń Apple'a, przecież to jest złoto, nigdy nie przesiądziesz się z powrotem na Windowsa czy Androida, mówię Ci, bierz tego MacBooka, weź nawet kredyt na niego, warto.

Tym niemniej, o MacBookach krąży też sporo pochlebnych opinii, szczególnie wśród programistów i grafików. Zainstalowany system operacyjny ma swoje korzenie w platformie Unix, co oznacza, że wykorzystanie pewnych aplikacji (także konsolowych) będzie prostsze, a całość działa szybko (zakładając procesor ARM-owy, taki jak M1, M2 lub nowszy), sprawnie i w dodatku ma potężną baterię. Sam design ma dla mnie znaczenie drugorzędne, jednak powszechnie chwalona intuicyjność systemu również stanowi interesującą cechę, którą chciałem sprawdzić. Dodatkowo, jakby nie patrzeć - wiele technicznych osób korzysta z laptopów od Apple'a i jest zadowolonych, więc ważąc wszystkie argumenty, dołączyłem do tego grona.

Po spędzeniu paru tygodni z 14-calowym MacBookiem Pro z procesorem M2 z 2023 roku, podczas których przechodziłem fazy od "na co mi to było" do "w sumie jest w porządku" mogę powiedzieć, że w miarę polubiłem się z komputerem Apple'a, choć - ku rozpaczy kolegów "ajfoniarzy" - nie pokochałem go i nadal widzę wady, niekiedy zastanawiając się, o jakiej intuicyjności wcześniej mówili. I między innymi o moich wrażeniach jest ten artykuł, aczkolwiek jego celem jest również pokazanie, jak firma IT może skorzystać na posiadaniu choćby jednego takiego sprzętu, a także jak odnaleźć się po przesiadce z Windowsa na macOS.

Zaczniemy od wątku z firmą.

Dlaczego software house powinien mieć różne systemy?

Zauważcie, że tytuł tego rozdziału nie brzmi "dlaczego powinien mieć macOS-a", tylko rozszerzamy to na różne systemy operacyjne. Wbrew temu, co myśli wiele nieinformatycznych osób, software house'y nie są w stanie posiadać i weryfikować oprogramowania na każdej możliwej konfiguracji, którą można spotkać na rynku. Zwłaszcza, że "konfiguracja" to pojęcie bardzo szerokie w tym aspekcie i może dotyczyć zarówno smartfonów z różnymi ekranami i systemami, jak i właśnie komputerów. Często firmy są w stanie sprawdzać aplikacje różnych przeglądarkach, które dość łatwo zainstalować, jednak w grę wchodzą też przeróżne ustawienia użytkowników i choćby wtyczki pozbywające się reklam, które też potrafią wpłynąć na "normalne" oprogramowanie. Zwyczajnie nie da się zweryfikować każdego przypadku. Najbliżej tego są profesjonalne firmy testerskie, ale podejrzewam, że nawet one mają z tym problem.

Warto jednak zadbać o to, aby w firmie IT była pewna różnorodność dotycząca systemów operacyjnych zainstalowanych na komputerach, zwłaszcza, jeśli zakres usług software house'u jest dość szeroki. W przypadku Linuxa ma to większe znaczenie ze względu na narzędzia, które stosuje się do wytwarzania oprogramowania - poza np. Redisem, dobrze też sprawdzić działanie aplikacji na Pingwinie, choćby ze względu na tak prozaiczne cechy jak rozróżnianie małych i dużych liter w nazwach plików. Zdarzało się, że przez nieuwagę takie rzeczy wychodziły dopiero na docelowym, linuksowym środowisku.

Ale warto też mieć co najmniej jeden sprzęt z systemem macOS. Najważniejsza korzyść w przypadku tworzenia aplikacji webowych to Safari - tutaj już możemy liczyć na to, że użytkownicy i klienci mogą posiadać komputery z Jabłkiem (co w przypadku Linuxa jest raczej ewenementem), a zatem w dużej mierze uruchomią naszą aplikację za pośrednictwem charakterystycznej dla Apple'a przeglądarki. A ta lubi sprawiać psikusy pod kątem interpretacji dyrektyw CSS, co sprawia, że warto zerkać, jak prezentuje się na niej nasza strona. Inna korzyść może dotyczyć aplikacji mobilnych tworzonych przy użyciu frameworków hybrydowych, takich jak Ionic. Aby zbudować paczkę dla systemu iOS, trzeba posiadać macOS. Można to ominąć poprzez wynajęcie dostępu do środowiska w chmurze na dany czas, ale na dłuższą metę nie ma to sensu podczas testowania aplikacji.

Jeszcze inna, już mniej oczywista, zaleta to zwyczajnie zapoznanie się z systemem, także "biernie" poprzez zwykłą obserwację w zespole. Programiści dobrze wiedzą, że ludzie nie patrzą na nich wyłącznie jak na osoby piszące kod - przecież programista to informatyk, a każdy informatyk zna się na komputerach, prawda? No, nie całkiem, ale nie wiedzą o tym klienci (i rodzina), którzy czasami mogą poprosić o jakieś drobne techniczne przysługi, choćby podczas spotkania i napotkania problemów w rodzaju podłączenia do rzutnika. Brzmi prosto, ale w momencie, kiedy zleceniodawca posiada macOS, a programista w ogóle nigdy go nie widział na oczy, może zrobić złe wrażenie, nie potrafiąc pomóc w pozornie prostej sytuacji.

Czy to oznacza, że w takim razie cały zespół powinien przejść na "maki"? Nie do końca, a już na pewno nie, jeśli software house pracuje z klientem, który korzysta z oprogramowania windowsowego, jak np. system kadrowo-księgowy instalowany na komputerze i tworzonya aplikacja będzie się z tym programem integrowała. Oczywiście, sama integracja nie zawsze wymaga posiadania Windowsa u siebie, ale zapoznanie się ze środowiskiem - już często tak. Także bywa, że Windows jest potrzebny bardziej niż się wydaje. Dodatkowym problemem jest cena sprzętu, ale o tym jeszcze zdążę wspomnieć. Zresztą, nawet Google nie zawsze może pozwolić sobie na ten sprzęt dla każdego pracownika.

Podsumowując tę sekcję, z jednej strony warto dywersyfikować środowisko, w jakim działa zespół, a z drugiej - należy zwrócić uwagę na kontekst biznesowy, w jakim operuje software house. Nie zawsze jest sens dzielić na siłę programistów według systemów i zwykle po prostu trzeba spojrzeć na to, z czym przyjdzie im pracować. Lub po prostu posłuchać ich preferencji.

Zalety MacBooka okiem nowicjusza

Tak, jak wspomniałem, w chwili pisania tego artykułu mam za sobą krótki czas korzystania z macOS i na dodatek na co dzień w domu cały czas korzystam z Windowsa. Mam zatem świeże porównanie obu systemów i cały czas przyzwyczajam się do produktu Apple'a. Tym niemniej, jestem w stanie zrozumieć, dlaczego ludzie mogą go uwielbiać oraz gdzie sam zauważyłem poprawę.

Po pierwsze, trzeba potwierdzić to, że bateria i przenośność MacBooków to faktycznie bajka. Nie sprawdzałem tego w praktyce, ale na bazie swoich doświadczeń jestem w stanie uwierzyć, że ten laptop przy rozsądnej pracy jest w stanie wytrzymać 8-10 godzin, a nawet dłużej. W dodatku piekielnie łatwo człowiek się z nim przemieszcza i nie czeka kilku minut na wyjście z trybu uśpienia, a jedynie sekundę. To sprawia, że nawet bardziej niż dla programistów, widzę zastosowanie MacBooków w pracy osób z kadry kierowniczej, często uczestniczących w spotkaniach w różnych lokalizacjach i nie zawsze z możliwością doładowania baterii. Ten wynik akumulatora psuje trochę konieczność podłączenia huba na interfejsy USB typu A (czyli 2.0 i 3.X) oraz dysk zewnętrzny - te elementy wpływają na szybkość utraty energii, jednak nadal jest bardzo wątpliwe, abyście w pełni podłączeni do urządzeń peryferyjnych stracili baterię podczas dwu-, a nawet trzygodzinnego spotkania. Podczas 2 godzin intensywnej rozmowy z klientem, gdzie miałem podłączone dwa urządzenia przez huba, dysk zewnętrzny oraz monitor (również przez huba), co chwilę udostępniany był ekran, aktywny głośnik, kamera itd., straciłem ok. 40% baterii. Wynik nie do osiągnięcia na Windowsie.

Po drugie, touchpad, a raczej gładzik działa lepiej niż się spodziewałem. Słyszałem o nim legendy, ale jako osoba, która całe życie korzystała z myszki i nigdy nie mogła przyzwyczaić się do poruszania kursorem we wbudowanych panelach w laptopach, tutaj jestem miło zaskoczony. I nie chodzi nawet o gesty, które pomagają w obsłudze, ale o tak prozaiczną rzecz jak konieczność fizycznego kliknięcia gładzika, aby rzeczywiście coś wybrać na ekranie. To sprawia, że nie boję się już dotykać tego obszaru z obawy przed tym, że coś przypadkowo uruchomię, dzięki czemu po prostu czuję się pewniej. Mimo że nadal przez 80% czasu korzystam z zewnętrznej myszki (normalnej, nie Magic Mouse'a), to gładzik działa naprawdę dobrze podczas normalnej pracy.

Po trzecie, czuć, że system działa dość szybko i sprawnie. To, oczywiście, zasługa nie tylko samego macOS, ale też (a może i przede wszystkim) procesora w architekturze ARM, którym jest u mnie M2 Pro z 10 rdzeniami. Ma się poczucie, że można efektywnie wykonywać swoją pracę, co w przypadku Windowsa też jest możliwe, ale po jakimś czasie pojawia się w nim ociężałość systemu i wymagane są gruntowne porządki. Dodatkowo, MacBook jest naprawdę cichy i ciągle chłodny mimo długiej pracy. Aczkolwiek to będzie trzeba zweryfikować po kilku latach korzystania ze sprzętu. Na razie pod tym kątem jest rewelacyjny.

Po czwarte, ekran i kolory są całkiem wyraźne. To dla mnie o tyle istotne, że jestem osobą z dość słabym wzrokiem, a w przypadku sprzętu Apple bardzo obawiałem się zejścia do laptopa o ekranie 14-calowym (na jaki się zdecydowałem), nie mówiąc już o 13-calowym. Jednak okazało się, że jest naprawdę dobrze pod tym względem i praca na wyświetlaczu Retina to przyjemność. Co prawda, w międzyczasie wymieniłem też okulary i to na pewno też pomogło, ale ekran po prostu muszę docenić. Podobnie jest z dźwiękiem - głośniki w MacBooku są dobre i nie mam poczucia, że tracę przez nie bardzo dużo ze słuchanej muzyki. Problem pojawił się dopiero w momencie, kiedy próbowałem korzystać z nich podczas telekonferencji, gdyż rozmówca wyraźnie słyszał echo swoich słów. Ale nie mam pewności, czy to kwestia samego położenia głośników, czy czegoś innego.

Po piąte, niektóre elementy systemu są naprawdę dobrze przemyślane. Ikony na górnym pasku, sposób poruszania się po systemie i dbałość o spójność interfejsu aplikacji to bardzo pomocne cechy w odnalezieniu się nowego użytkownika. Może to szczegół, ale na tyle miły, że od razu lepiej się pracuje. Przykładem jest choćby skrót do tworzenia zrzutu ekranu i jego późniejsza obsługa (CMD + SHIFT + 4) czy przełączanie między oknami tej samej aplikacji (CMD + ~). O skrótach będę jeszcze potem pisał.

Ale ja z kolei nie jestem taki miły jak projektanci UX Apple'a i muszę wymienić parę wad.

Wady MacBooka okiem nowicjusza

Włożę kij w szprychy i na pierwszy ogień skrytykuję cenę, mimo że wiele osób popuka się w czoło. "Przecież jakość kosztuje", "to dobry sprzęt" - pewnie powiecie. I macie rację. Ale nie uważam, aby na tyle dobry, żeby za moją wersję laptopa należało zapłacić 11 000 zł. Zdaję sobie sprawę, że koszt będzie większy niż w przypadku "normalnego" laptopa, gdyż - jak twierdził Steve Jobs - "Apple nie sprzedaje śmieci", ale mam też świadomość, że pewien procent tej wartości to opłata za markę i poczucie, że należy się do "elitarnego klubu". I nie dotyczy to tylko MacBooków, ale też innych sprzętów od tej firmy, peryferiów (dodatkowe 512 GB miejsca na dysku za 3000 zł…) i nawet nie tylko technikaliów - wiedzieliście, że ściereczka do wycierania ekranu kosztuje 119 zł?

A przecież ta cena laptopa nie uwzględnia kosztu potrzebnych aplikacji do pracy, dodatkowych usług (np. miejsca w iCloud). Nie będę ukrywał - za tyle pieniędzy i po tylu zachwytach ze strony środowiska miałem tak wysokie oczekiwania dotyczące jakości pracy, że mimo wszystko czuję się trochę zawiedziony, a może raczej niewystarczająco usatysfakcjonowany. I zdaję sobie sprawę, że wychodzę teraz w Waszych oczach za sknerę, skąpca. A może zwyczajnie nie jestem tak zauroczony Applem, aby z radością wyciągać portfel za każdym razem, gdy ta firma o to poprosi. No i pamiętajcie, że jestem z Poznania - to zobowiązuje.

Przejdźmy jednak do wad w samym użytkowaniu. Muszę przyznać, że przy uruchamianiu laptopa i początkowej konfiguracji napotkałem na sporą przeszkodę - nie mogłem bowiem wybrać właściwej strefy czasowej. Długo szukałem rozwiązania i okazał się nim restart systemu. Podobno było z rejestracją konta w App Store. Co w tym dziwnego, powiecie? Otóż to, że w życiu nie spodziewałbym się, że w świeżo zainstalowanym systemie, który w dodatku już się ponownie uruchamiał, będę wymagał jeszcze dodatkowych restartów do modyfikacji tak prostych ustawień.

Wiąże się z tym jeszcze inna rzecz - brak jasnych komunikatów o błędach. Przy problemach z deinstalacją aplikacji (swoją drogą, sama czynność rzeczywiście jest prosta i oznacza przeniesienie do kosza) nie jestem informowany, dlaczego nie mogę tego zrobić. Przy wspomnianych problemach z ustawieniem strefy czasowej czy założenia konta iTunes system również nie raczył podawać konkretnego komunikatu. Zdaję sobie sprawę, że jest to dostępne w systemie, ale nie chodzi o to, abym - znowu - w tak drogim sprzęcie musiał jeszcze zastanawiać się, co się dzieje, zamiast czekać, aż system poda mi rozwiązanie w klarowny sposób. Mam wrażenie, że intuicyjność i łatwość użytkowania tak przyświecała projektantom macOS, że zapomnieli o pewnych udogodnieniach dla osób, które potrzebują nieco więcej technicznych informacji.

Wspomniałem też o konieczności używania huba, ponieważ moja wersja MacBooka posiada trzy porty USB-C (ta liczba jest różna w zależności od wersji i wielkości), ale ani jednego na "normalne" USB. Wiem, że ten pierwszy to przyszłość i wygoda, natomiast dużo urządzeń peryferyjnych typu zewnętrzna klawiatura czy myszka, a także pendrive nadal w większości korzystają z USB-A, w związku z czym potrzebuję takich portów. I wiem, o czym teraz pomyśleliście, więc może uprzedzę Was przerobionym memem:

Mem komiksowy z dwiema osobami, rysunki są dość niedbałe. Pierwsza scena to chłopiec A mówi do chłopca B 'Masz myszkę przewodową', a B odpowiada 'Yhy'. W drugiej A mówi 'Ale wiesz, że są też bezprzewodowe?', a B odpowiada 'Wiem'. W trzeciej scenie A patrzy zmieszany na B. W czwartym wypala 'To niewygodne!', a B odpowiada 'A ja lubię'. Po czym w ostatniej scenie A zaczyna mówić 'Ale wiesz...', a zezłoszczony B bardzo szeroko otwiera buzię i mówi 'A ja lubię'.

Inne wady, które bym wymieniał, nie są tak naprawdę wadami, gdyż albo wynikają z moich konkretnych oczekiwań oraz potrzeb (choćby uruchomienie Windowsa na wirtualnej maszynie, czego nie zrobię na ARM-ie na Virtual Boxie), albo ze zbytniego przyzwyczajenia się do Windowsa, albo ze zbyt krótkiego korzystania z systemu i niepoznania wszystkich jego zakamarków. Nie jestem przekonany do tego, czy to faktycznie tak intuicyjny system, jeśli w poszukiwaniu różnych opcji zdarza mi się częściej korzystać z przeglądarki Google niż od razu trafiać w dobre (bo "wynikające z logiki") miejsca w ustawieniach. Natomiast zdaję sobie sprawę, że to może być kwestia czasu i przyzwyczajenia.

Chcę tylko przekazać, że nie - nie są to sprzęt i system bez wad. To nie jest tak, że tutaj działa wszystko bezbłędnie i zgodnie z oczekiwaniami (choć z wieloma rzeczami rzeczywiście tak jest). I na pewno nie jest to środowisko, w którym się zakochałem i wyrzuciłem sprzęt z innymi systemami do kosza. Po prostu macOS i w ogóle MacBook jest dobry, nawet bardzo dobry, można go śmiało polecić i rzeczywiście są osoby, którym ten ekosystem tak przypadnie do gustu, że większość swojej elektroniki skonstruują wokół tej marki i tak zostanie na długie lata. Ale jest dużo przesady w stwierdzeniu, że jeśli ktoś spróbował Apple'a, to zawsze będzie z niego korzystał. Powiedziałbym nawet, że takie twierdzenie to fanatyzm i najgorsza odsłona "fanbojstwa". Lub po prostu zwykłe przekomarzanie się.

Jak odnaleźć się po zmianie Windowsa na macOS?

Od razu może napiszę, że poniższe informacje nie stanowią żadnego formalnego poradnika czy tutorialu dla nowych użytkowników sprzętu Apple'a. Te znajdziecie bez problemu na Youtubie, nawet w formie kompletnych, 5-godzinnych wprowadzeń. Chcę jednak podzielić się paroma wskazówkami, którymi sam zostałem obdarzony przez moich kolegów posiadających już sprzęt Apple'a (za co im dziękuję) lub dowiedziałem się o nich po samodzielnych próbach oraz poszukiwaniach.

Przede wszystkim, jeśli przychodzicie z Windowsa i jesteście przyzwyczajeni do częstego używania CTRL z lewej strony oraz dodatkowo zewnętrznej klawiatury innej niż Magic Keyboard, to polecam spróbować przestawić klawisze specjalne. U mnie na ten moment skończyło się na zamianie miejscami CTRL oraz CMD, co sprawiło, że palec szybciej przyzwyczaił się do Commanda oddalonego tylko o 1-2 (a nie trzy) klawisze od windowsowego układu. Drobna rzecz, a cieszy. Oczywiście, w Waszym przypadku taka zamiana może nie być potrzebna lub wyglądać zupełnie inaczej.

Po drugie, zdziwić Was może brak klawisza Delete. Jak zatem wygląda usuwanie plików? Otóż, jest to CMD + Backspace. A przy pisaniu tekstu działanie tego klawisza jest imitowane przez Fn + Backspace. Podobne problemy mogą mieć użytkownicy dużo piszący na komputerze, którzy do tej pory często korzystali ze skrótów CTRL + strzałka w lewo lub prawo, a także Home i End do przesuwania się od początku do końca linii - w MacBooku jest inaczej. Trzeba przyzwyczaić się do Option + strzałka (odpowiednik CTRL + strzałka) oraz CMD + strzałka (odpowiednik Home oraz End). Można przywyknąć, choć zabierze to trochę czasu.

W macOS dostępne są dwa tryby poruszania się po pulpicie (zwanego tutaj "biurkiem") - bez Stage Managera czy ze Stage Managerem. Powiem szczerze, że za namową kolegi z rozpędu przy wstępnej konfiguracji włączyłem ten drugi tryb. Jest on rzeczywiście elegancki i utrzymuje otwarte okna z boku, jeszcze bardziej poprawiając wrażenia wizualne. Jednak po jakimś czasie zorientowałem się, że wyświetlanie wielu otwartych okien obok siebie jest tutaj dość toporne, żeby nie powiedzieć "niemożliwe" - męczyłem się tak, że w końcu wyłączyłem Stage Manager i dopiero wtedy zaczęło mi się dobrze pracować. Znam jednak zwolenników obu trybów, więc każdy musi wybrać wersję odpowiednią dla siebie. Natomiast niezależnie od tego warto zainteresować się Mission Control, który odblokowuje wiele biurek, pomiędzy którymi można się przełączać poprzez CTRL i strzałki (lub przesunięcie trzema palcami w bok po gładziku), a na każdym mieć otwarte inne aplikacje.

W ogóle warto przyzwyczaić się do innego sposobu zarządzania aplikacjami - one tutaj nie są zamykane "tak łatwo". Zwykle są cały czas uruchomione w tle i widoczne na Docku (czyli pasku zadań), dzięki czemu ich ponowne włączenie jest szybsze. Wiąże się to z lepszym automatycznym zarządzaniem pamięcią przez system i o ile może dziwić na początku, to można się do tego przyzwyczaić, nawet jeśli ktoś tak dba o minimalną liczbę otwartych okien, jak ja. Plusem rozwiązania stosowanego przez macOS jest zwykle krótszy czas uruchomienia aplikacji.

Prawy przycisk myszy w samym gładziku? Naciśnięcie dwoma palcami lub CTRL + przyciśnięcie gładzika. Szybkie uruchomienie aplikacji poprzez wyszukanie? CMD + spacja aby włączyć Spotlight, wykonanie gestu zbliżania na gładziku lub wybranie ikonki Launchpada z Docka. Pokazanie pulpitu (a więc odpowiednik WIN + D)? Gest oddalenia wykonany pięcioma palcami na gładziku. Wybranie jednego z otwartych okien? Trzy palce do góry na gładziku. Przełączanie się pomiędzy wieloma oknami jednej aplikacji (np. różne okna przeglądarki)? CMD + ~. Zrzut ekranu z zaznaczeniem dowolnego obszaru na ekranie? CMD + Shift + 4 (warto też spróbować z innymi cyframi). Odświeżenie przeglądarki? CMD + R lub CMD + Shift + R. Zablokowanie komputera, a więc odpowiednik WIN + L? Po prostu naciśnięcie włącznika lub zamknięcie klapy laptopa. Dzięki temu można zacząć w miarę szybko poruszać się po systemie, natomiast trzeba pozwolić sobie na wyrobienie pamięci mięśniowej przy korzystaniu z różnych opcji.

MacBook dysponuje świetną baterią, ale to nie oznacza, że należy ją zostawić bez nadzoru. Warto zaopatrzyć się w aplikację, która pozwala nam wybrać procent zapełnienia akumulatora i tym samym nie ładować go za każdym razem do 100%. W tym celu kolega z zespołu polecił aplikację AlDente i faktycznie warto ją wypróbować. Po jej zainstalowaniu w każdym momencie możemy ustalić maksymalny poziom naładowania i nie przejmować się ręczną kontrolą. Choć pewne wytyczne i tak warto przyswoić, nie tylko ze względu na MacBooka.

Kolejną rzeczą, niezmiernie ważną z punktu widzenia programisty, jest znalezienie odpowiedników pewnych aplikacji. Wiadomo bowiem, że wielu producentów tworzy paczki instalacyjne zarówno na Windowsa, jak i macOS, jednak istnieją też aplikacje dostosowane stricte do jednego środowiska. Do pierwszej grupy należą tak potrzebne mi w codziennej pracy programy jak choćby Slack, pakiet Office, Thunderbird, przeglądarki internetowe czy Visual Studio Code.

Niestety, istnieje też ta druga grupa i alternatywy dla aplikacji, bez których nie wyobrażałem sobie pracy na Windowsie. W niektórych przypadkach znalazłem zamienniki prawie od razu, a w innych nadal szukam ideału. Także poniższej listy nie traktujcie jako wytycznych, a raczej pozycje, które warto sprawdzić.

Windows Terminal, MobaXTerm -> iTerm2

Wiecie dobrze, że programiści dużo pracują z terminalem, a ponieważ macOS opiera się na systemie UNIX, to pewne przyzwyczajenia pozostają tutaj żywe. I co prawda, Apple udostępnia domyślny program, jednak nie bez powodu wiele osób poleca i stosuje iTerm2, który zawiera wiele udogodnień. I to przykład, kiedy oczekiwania nie pokrywają się z rzeczywistością.

Owszem, iTerm2 rzeczywiście jest dobry. Ale mam wrażenie, że w MobaXTerm, z którego też korzystam np. w domu, mogę więcej i łatwiej, nawet w darmowej wersji. Zapisywanie sesji było tam proste, dostępny dla użytkownika był też panel do graficznego przesyłania oraz pobierania plików, przez co nie było potrzeby korzystania z poleceń SCP. A tutaj? O ile nie odkryłem jeszcze jakichś pluginów lub opcji, to o graficznym udogodnieniu do zarządzania plikami mogę tutaj zapomnieć, a zapisywanie danych do sesji jak najbardziej jest, ale mam wrażenie, że mało intuicyjne i opiera się na profilach oraz menedżerze haseł (swoją drogą, macOS ma nieźle skonstruowany system pomocy - w górnym pasku wybieramy "Pomoc" i możemy szukać opcji z klawiatury). Zawiodłem się, aczkolwiek nie znalazłem jeszcze niczego lepszego.

Notepad++ -> TextMate (na razie)

Notatnik z dwoma plusami to dla mnie istny szwajcarski zegarek. To w nim piszę większość tekstów (w tym te na blog), otwieram duże oraz małe pliki, czasami edytuję kod (mimo że w większości robię to w VS Code), przeglądam duże pliki np. ze zrzutami bazy danych, robię notatki na spotkaniach, formatuję pliki XML oraz JSON do postaci "pretty" i przechowuję zapiski, których nie chcę zachowywać na dysku, tylko trzymam w pamięci, w poszczególnych zakładkach, które rzadko zamykam. Tym bardziej posmutniałem, gdy okazało się, że nie ma wersji tego wspaniałego narzędzi na macOS.

Poszukując alternatywy (oczywiście, darmowej - nie po to wydałem (a raczej moja firma wydała) tyle na sprzęt, aby teraz płacić za tak codzienne aplikacje), zetknąłem się choćby z Brackets, który jednak ma tę wadę, że nie przyjmuje plików większych niż 16 MB. A to już jest dużym ograniczeniem w przypadku otwierania np. zrzutów bazy danych, co zdarza mi się dość często (choć ostatnio akurat częściej poprzez Vima). Następnie sprawdziłem polecony mi na Mastodonie Zettlr, który zapowiadał się całkiem dobrze - umożliwia edytowanie plików zgodnie z językiem znaczników Markdown i jest świetny na spotkaniach oraz do pisania instrukcji. Jakiż więc był mój gniew, gdy okazało się, że nie pozwala otworzyć plików SQL i generalnie dowolnego formatu pliku, niezależnie od tego, jakby sensowne lub bezsensowne to było.

Wówczas polecono mi TextMate'a, który jest prosty, elastyczny i na ten moment robi to, co ma robić - służy na spotkaniach, ułatwia pisanie dłuższych maili. Tym niemniej, czuję, że nie jest to koniec moich poszukiwań i albo muszę poznać lepiej tę aplikację, albo pogodzić się z pewnymi ograniczeniami, albo przeglądać dalej Internet. Podejrzewam też, że czytelnicy zarekomendują pewne programy w komentarzach (lub skrytykują moje powyższe słowa, gdyż nie odkryłem jakiejś istotnej funkcji).

XAMPP -> MAMP

Jako programista nie lubię utrudniać sobie życia i mimo w miarę sprawnej obsługi konsoli lubię aplikacje przygotowujące mi środowisko za pomocą jednego kliknięcia. Przykładem jest XAMPP, który zawiera w sobie Apache2, MySQL-a (którego jednak akurat zawsze polecam instalować osobno) oraz wszystko, co jest potrzebne do konfiguracji PHP-a. Istnieje też możliwość korzystania z XAMPP-a w wersji portable i przełączania się (ręcznego, ale jednak) pomiędzy wieloma instancjami w celu uzyskania różnych wersji PHP.

I tutaj akurat macOS posiada ciekawą alternatywę w postaci MAMP, który jest w wersji darmowej oraz płatnej i faktycznie ułatwia życie. Umożliwia nawet przełączanie się w locie pomiędzy dwiema najnowszymi wersjami PHP 7 i 8 w parę sekund, bez restartu całej usługi. Jego jedyną wadą jest większe ukrycie plików konfiguracyjnych (co ma związek z zachęceniem do kupna wersji płatnej, która tutaj ma sens) oraz domyślne porty inne niż standardowe, które czasem trzeba zmieniać.

OpenVPN GUI -> Tunnelbrick

Tutaj przyznaję, że byłem wygłupiony - istnieje wersja OpenVPN-a na macOS, jednak jest to Connect, który nie do końca jest tym, czego się spodziewałem. A OpenVPN to ważne narzędzie, gdyż większość sieci VPN działa za jego pośrednictwem i opiera się na plikach z rozszerzeniem .ovpn, które się magazynuje i wykorzystuje do połączeń. Niestety, próby korzystania z oficjalnych narzędzi OpenVPN na macOS okazały się u mnie bezskuteczne, choć tutaj jestem świadomy, że to może być spowodowane moim brakiem wiedzy.

Na szczęście jest taki mały program jak Tunnelbrick, który wygląda niepozornie, ale robi dokładnie to, co OpenVPN GUI na Windowsie - przechowuje konfiguracje w postaci plików OVPN i umożliwia łączenie.

HeidiSQL -> DBeaver

Tutaj niektórzy pewnie krzykną, że przecież DBeaver jest też dostępny na Windowsie. Owszem, potwierdzam. Jednak nawet u nas w zespole jest podgrupa korzystająca z prostszego i łatwiejszego w użyciu, ale mniej stabilnego HeidiSQL-a oraz drugi zbiór osób obsługujących aplikację o szerszych możliwościach, ale trudniejszą, jaką jest DBeaver. Ja akurat należałem zawsze do pierwszej grupy, ale siłą rzeczy teraz musiałem przenieść się do drugiej i zwyczajnie polubić program z bobrem w logo. Jest to możliwe, choć wymaga zmiany przyzwyczajeń. Nie znalazłem do tej pory lepszego darmowego zamiennika.

WinSCP -> FileZilla

Ponownie program, który jest dostępny na każdej platformie, ale zacząłem z niego korzystać dopiero na macOS z konieczności. WinSCP był dla mnie niezwykle ważnym narzędziem do graficznej komunikacji poprzez SCP z uwagi na prostotę użycia oraz - co tutaj dużo mówić - przyzwyczajenie i tym samym szybkość obsługi. Wiedziałem, że muszę z tego zrezygnować po przeniesieniu się na komputer Apple'a i na szczęście, to akurat odbyło się w miarę bezboleśnie.

Przed FileZillą testowałem jeszcze Cyberducka, który był szeroko polecany, jednak okazał się dla mnie kompletnym niewypałem. W moich oczach charakteryzował się jako bardzo nieintuicyjny i ograniczony. W związku z tym pochyliłem się ku FZ i to był niezły wybór, bo o ile nie jest on tak kompaktowy jak WinSCP pod kątem np. przechowywania sesji, to wydaje się równie funkcjonalny i po prostu działa tak, jak chcę.

Podsumowanie

Zdaję sobie sprawę, że zbiorę gromy za ten artykuł. Osoby pracujące dłużej na MacBookach na pewno wytkną mi pewne nieścisłości i wskażą lepsze rozwiązania lub powody, dla których Apple skonstruował określone rzeczy. I rozumiem to oraz zachęcam do takich komentarzy - zawsze warto się edukować oraz poznawać nowe spojrzenia. Zwłaszcza, że w paru miejscach zapewne byłem bardziej złośliwy niż powinienem. Natomiast muszę jeszcze raz podkreślić jedną rzecz.

MacBook to naprawdę dobry sprzęt i może się podobać, a także umożliwić lepszą pracę. Wiadomo, że jest szczególnie ceniony przez programistów (choć to zależy, co dokładnie potrzebują), grafików czy montażystów filmowych. Moim zdaniem jest dobrym wyborem także dla osób będących często w biegu i uczestniczących w spotkaniach. Zdaję sobie sprawę, że może się też po prostu podobać, oczarować swoim ekosystemem (szczególnie jeśli ktoś ma dodatkowo iPhone'a, iPada itd.) i stanowić sprzęt na długie lata w kolejnych wersjach.

Natomiast to nie jest sprzęt idealny - taki zresztą nie istnieje. To nie jest tak, że jeśli Wam MacBooki się podobają, to nie istnieją osoby, które nie są zadowolone z ich użytkowania. Zdaję sobie sprawę, że w wielu przypadkach jest to spowodowane długotrwałym korzystaniem z Windowsa i nawykami, które trudno zmienić, jednak po prostu trzeba to uszanować i nie starać się na siłę wszystkich "nawracać" na sprzęt Apple'a oraz dziwnie patrzeć na osoby, które go krytykują, często nie tyle za produkt, co niektóre ruchy samej firmy (jak widzicie, pominąłem w tekście ten wątek). Tak samo istnieją też osoby (i znam je osobiście), które po przejściu z Androida na telefon z iOS prędko wracali do "Robocika", gdyż zwyczajnie nie odnaleźli się w "Jabłku". Tak już bywa, na tym polega wolność na rynku elektroniki i oprogramowania - każdy używa tego, co chce i czego potrzebuje, także uwzględniając to, ile pieniędzy jest w stanie na to wydać. Bo, w nawiązaniu do przykładu z początku tekstu, krytykowanie kogoś za to, że np. szukając "po prostu" smartwatcha chce sprzęt tańszy niż Apple Watch i obrażanie się na taką osobę, jest po prostu oznaką braku dojrzałości.

Mam nadzieję, że udało mi się przedstawić swój punkt widzenia na ten sprzęt i przede wszystkim potwierdzić lub obalić pewne mity, które mogą zastanawiać osoby niemające kontaktu z Applem. Zachęcam do dyskusji w komentarzach, na której mogą skorzystać osoby chcące pogłębić swoją wiedzę oraz te wahające się jeszcze, czy warto zainteresować się tym sprzętem.

Za pomoc w przygotowaniu artykułu dziękuję kolegom z zespołu i ze studiów, którzy pozwolili mi poznać MacBooka i zachęcić do samodzielnego spróbowania - Rafałowi, Szymonowi (który szantażuje mnie teraz zdjęciem, na którym siedzę przed MacBookiem Airem w różowym etui), Aleksowi, Krzysztofowi i Erykowi.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Miejsca do wymiany linków na przykładzie /kbin https://wildasoftware.pl/post/miejsca-wymiany-linkow-przykladzie-kbin?ref=rss https://wildasoftware.pl/post/miejsca-wymiany-linkow-przykladzie-kbin?ref=rss Thu, 21 Sep 2023 17:30:00 +0000 Większość z nas przegląda Internet wzdłuż i wszerz, szukając czegoś, sprawdzając informacje (najnowsze bądź nie) lub po prostu ciesząc sie rozrywką. Zaglądamy przy tym na strony internetowe, które znamy, a także takie, które dopiero odkrywamy. Czasem przy tym znajdziemy coś, co uważamy za tak ciekawe, że aż palimy się do tego, aby podzielić się tym z innymi osobami, niekiedy ozdabiając to swoim komentarzem. Oczywiście, wyślemy to do rodziny, znajomych, może współpracowników (jeśli to coś, co przyda się w pracy... albo po prostu fajne memy), ale bywa też tak, że chcielibyśmy podzielić się tym z większą grupą osób.

Wówczas wielu takich "szperaczy" pomyśli o serwisach społecznościowych, gdzie ma nie tylko znajomych, ale też kontakt z osobami o podobnych zainteresowaniach, którym może się dany link spodobać, a oni podadzą to dalej. Pomińmy tutaj kwestię zyskiwania w ten sposób zasięgu - skupmy się na tym, że użytkownik wrzucający takie hiperłącze odczuwa satysfakcję, że podzielił się ze światem czymś, co uważa za wartościowe, zabawne lub po prostu przydatne. A czasami wręcz przeciwnie - wdaje się w polemikę z autorem, co może owocować konstruktywną dyskusją (choć czasami przeradza się w tzw. dramy).

Natomiast trzeba przyznać, że "klasyczne" media społecznościowe nie są stworzone stricte do dzielenia się linkami. Owszem, można w nich to robić, ale:

  • taki link może zgubić się wśród wielu innych postów pisanych przez wiele osób (w tym tak prozaicznych, jak "z nieba przyleciał mój wielki przyjaciel, kiedy lądował, ja jadłem kanapkę"),
  • algorytmy serwisu ograniczają widoczność postu, gdy ten zawiera link do zewnętrznego źródła, a także niekiedy nie pozwalają go podlinkować prawidłowo (przykład Instagrama, gdzie URL jest zwykłym tekstem - link trzeba podać w profilu),
  • trudniej skategoryzować treść, aby dotrzeć do osób interesujących się daną kategorią (hashtagi pomagają, ale nie zawsze są wystarczające),
  • w zależności od serwisu: trudniej śledzić wątek ewentualnych komentarzy, istnieje ograniczenie do liczby znaków itd.

Jednak istnieją serwisy, które skupiają się właśnie na tym, aby dzielić się na nich ciekawymi adresami i nie tylko - grafikami, informacjami czy zwyczajnie rozpoczynając wątek do dyskusji wśród zainteresowanych osób. Poznajcie typ portali, które klasyfikuje się jako social news lub bardziej w języku polskim - agregatorami treści.

Jak to działa?

Na początku może powiedzmy sobie, jakie są przykłady takich portali, gdyż czasem bardziej wyjaśnia to sytuację niż nawet najlepszy opis. Polski internauta z pewnością kojarzy dwie nazwy - Reddit oraz przede wszystkim Wykop. Nieco starsi użytkownicy globalnej wioski wspomną jeszcze choćby Digga. Oczywiście, to nie są jedyne przykłady, ale będą stanowić dla nas materiał demonstracyjny, gdyż właśnie o takich portalach dzisiaj będziemy rozmawiać, pokazując jednocześnie alternatywę.

Agregatory treści to serwisy, które pozwalają użytkownikom zamieszczać określoną treść. Zwykle są to linki do ciekawych artykułów, materiałów czy stron, ale nie tylko - mogą być to posty z ciekawą historią, wyrażenie opinii, pytanie do społeczności czy pojedynczy materiał audiowizualny. Na tym etapie można powiedzieć, że jest to coś w rodzaju znanego wszystkim z dawnych czasów forum dyskusyjnego, przy czym solą serwisu nie jest dyskusja, ale przeróżne znaleziska. Idąc tym skojarzeniem, wszystkie takie treści są grupowane w poszczególnych podforach, które różnie nazywają się się w zależności od serwisu (np. na Reddicie jest to "subreddit"), a dodatkowo mogą być szczegółowo poetykietowane w postaci np. hashtagów. To wszystko dodają użytkownicy, którzy w ten sposób odznaczają się w społeczności, a jednocześnie socjalizują się, co jest przecież ideą serwisów społecznościowych. Na tym etapie faktycznie niewiele może różnić się to od forów.

Jednak zmienia się to, gdy popatrzymy na to, co dzieje się z danymi treściami (wyjątkowo użyję liczby mnogiej, choć nie do końca jest to poprawne). Każdy materiał może być bowiem nie tylko komentowany przez społeczność, ale też oceniany za pomocą mechanizmu "podoba mi się/nie podoba mi się" (na Reddicie: update/downvote, na Wykopie: wykopanie/zakopanie). W ten sposób treść może zyskiwać na popularności i - w przypadku wyjątkowo dobrych ocen - być wyniesiona na stronę główną lub po prostu górę tematów w danym dziale. Oczywiście, ten stan nie utrzymuje się wiecznie - materiały mają swój "termin ważności" i zajmują z trudem zdobyte miejsce przez określony czas, później ustępując innym wiadomościom, nowszym i równie wysoko ocenianym. Biorąc pod uwagę fakt, że w wielu przypadkach takie serwisy pełnią funkcję informacyjną lub po prostu newsową, przestaje dziwić nazwa "social news" - to nic innego, jak społecznościowy serwis informacyjny, który pozwala w jednym miejscu udostępniać linki nie tylko do ciekawych miejsc, ale także bieżących wydarzeń, gorących wiadomości czy ważnych ogłoszeń. A ponieważ za przypływ nowych informacji nie odpowiada jedna osoba czy redakcja tylko duża grupa różnych użytkowników, którzy interesują się rozmaitymi rzeczami, to w ten sposób przekrój wiadomości jest (a przynajmniej powinien być) naprawdę szeroki i mniej doniesień zostanie pominięta.

Aby tego było mało, niektóre z tych serwisów udostępniają także funkcję mikroblogowania, a więc prowadzenia swoistego publicznego pamiętnika każdego użytkownika, w którym osoby mogą dzielić się swoimi wiadomościami niekoniecznie powiązanymi z danym "podforum". Niektórzy zatem powiedzą, że z technicznego punktu widzenia jest to serwis kompletny - nie dość, że są tutaj informacje, rozrywka, to jeszcze można traktować taki serwis jak Twittera/X czy Mastodona. Oczywiście, w praktyce to nie jest tak, że taki agregator zastępuje wszystkie inne serwisy, gdyż służy po prostu do czegoś innego, a pewne funkcje ma "przy okazji". Przez swoją dwoistą naturę nie dla wszystkich nawigacja po takich serwisach jest zrozumiała. A w ogóle niektórym lepiej dyskutuje się na portalach społeczniościowych o innym charakterze, przez co ci bardziej wytrwali stale się przełączają pomiędzy poszczególnymi social mediami.

Ale co jeśli powiedziałbym Wam, że istnieje projekt, który pozwala stworzyć "swój" agregator treści i jest naturalnie połączonymi z innymi serwisami w systemie społecznościowym?

Czy można mieć samemu taki portal?

Jak wiele pomysłów na takie serwisy, które powstają w sieci, także tutaj pojawiły się alternatywy. Niektóre skoncentrowane na konkretnych obszarach, mające nadzieję na powtórzenie sukcesu Reddita (swoją drogą, ani Reddit, ani Digg nie były pierwsze). Inne z kolei skupione na tym, aby otworzyć to rozwiązanie dla większej grupy użytkowników. Nie da się bowiem ukryć, że o ile Wykop czy Reddit są darmowe i wygodne, o tyle nadal są to przykłady systemów scentralizowanych, znajdujących się na serwerach konkretnych organizacji czy firm. Ma to swoje zalety, ale też wady. A dodatkowo niektórzy zwyczajnie chcieliby rozwiązanie, które mogą postawić na swoim serwerze (tzw. self-hosted) oraz upublicznić innym lub decydować, komu upublicznić.

Istnieją co najmniej dwa takie fragmenty oprogramowania do samodzielnej obsługi. Pierwszym z nich jest Lemmy, który powstał w 2019 roku i konstrukcyjnie bardzo przypomina Reddita. Jest darmowy, otwarty oraz możliwy do samodzielnego hostowania na wybranym serwerze. Jednak dzisiaj zajmiemy się tym drugim systemem, z którego możemy być szczególnie dumni, gdyż powstał w Polsce i zatacza coraz szersze kręgi. Mowa tutaj o /kbin, który zaczął swój żywot za sprawą Ernesta Wiśniewskiego na początku 2021 roku. Przez długi czas był on jedynym programistą i orędownikiem tego projektu, który jednak po niedługim czasie zyskał popularność i obecnie do współtworzenia dołączyła społeczność, podczas gdy Ernest mógł dodatkowo zająć się popularyzacją oraz koordynacją prac. O ile oba rozwiązania - Lemmy i /kbin - przedstawiają się jako podobne do Reddita, to nie brak głosów, że inspiracją dla /kbina w pewnym stopniu był też nasz polski Wykop. Funkcjonalnie te wszystkie serwisy są dość zbliżone do siebie.

Lemmy'ego i /kbina łączy jeszcze jedna rzecz - powiązanie z Fediverse. Wspominałem o tym, że aby korzystać z Reddita czy Wykopu trzeba na nim posiadać konto i nie można choćby skomentować linku będąc na innym portalu. Z kolei np. w /kbinie jest możliwe, żeby polubić lub skomentować wpis korzystając ze swojego konta na Mastodonie, Pixelfedzie czy Misskeyu. Choć fakt, że aby dodać link czy go podbić, już potrzebny jest profil w /kbinie... jakimkolwiek. Tutaj bowiem wychodzi kolejna cecha Fediverse, a więc rozproszony charakter systemu. Chcąc korzystać z funkcji charakterystycznych dla /kbina możemy robić to z dowolnej instancji, co umożliwia posiadanie małych "przyczółków", z których użytkownicy dyskutują ze sobą. Co prawda, podfora (nazywane tutaj "magazynami") są osobne dla każdego serwera, jednak są widoczne pomiędzy nimi, a w przyszłości pewnie pojawi się możliwość ich logicznego łączenia. Trzeba bowiem uczciwie rzec, że ten projekt nadal jest w fazie wczesnego rozwoju i chociaż już działa produkcyjnie, to zapewne zostanie dodanych do niego i wyszlifowanych wiele funkcji.

Do czego można to wykorzystać?

Takie samohostowalne rozwiązanie ma jeszcze jedną zaletę, przy której ponownie wrócimy do tematu forów internetowych. Wielu z nas pamięta bowiem, że nierzadko specjalistyczne serwisy z jednej strony miały właśnie portal, a z drugiej - życie na nich tętniło właśnie na forach dyskusyjnych, które były połączone z materiałami na głównej witrynie. W ten sposób stosunkowo niewielkim kosztem tworzyły się dość popularne fanowskie serwisy lub nawet te poważniejsze.

Rozwiązania typu social news nadają temu dodatkowy wymiar - może być to miejsce, w którym dana instytucja publikuje ogłoszenia i zachęca do komentowania lub zadawania pytań. Można wyobrazić sobie choćby urząd miasta, który zamiast na fanpage'u na Facebooku umieszcza ogłoszenia właśnie na swojej instancji /kbin. Funkcjonalność ta sama, ale jeśli dodatkowo użytkownicy mają konta w Fediverse, mogą od razu roznieść daną informację szerszemu gronu osób oraz wyrazić swoje zdanie. Tutaj słusznie może ktoś zauważyć, że przecież takie organizacje powinny korzystać ze swojej macierzystej strony do publikacji informacji. I tutaj zgoda - trudno wyobrazić sobie, aby choćby starostwo nie zaktualizowało swojej strony o news ważny dla mieszkańców. Natomiast trzeba pamiętać, że serwisy społecznościowe same w sobie stały się agregatem różnych treści i to tam ludzie najczęściej szukają informacji, czy tego chcemy, czy nie. A /kbin, z publicznie dostępnym API (choć ponownie - wymaga ono rozwoju), pozwala połączyć publikację na stronie z postem na instancji. Można też pokusić się o połączenie samych wątków komentarzy w ten sposób, tworząc iluzję jednego zintegrowanego systemu.

Zresztą, na marginesie - swoje instancje (choć akurat Mastodona, a nie /kbin) otworzyły już komórki rządowe kilku europejskich krajów - dokładniej Niemcy, Holandia oraz Szwajcaria. Dodatkowo, niektóre niemieckie landy również zainicjowały swoje serwery z już konkretnymi profilami ważnymi dla danego regionu. Z komórek pozarządowych podobnie uczyniła też brytyjska stacja BBC. Wynika to z chęci zapewnienia alternatywnych profili instytucji publicznych lub prywatnych w stosunku do Facebooka czy niekiedy Twittera/X ze względu na liczne wątpliwości związane z prywatnością danych oraz bezpieczeństwem korzystania z tych gigantów.

Wracając do tematu agregatorów treści i nadal przyrównując je do forów - ciekawym pomysłem jest wykorzystanie takiej instancji /kbina dla szkoły czy uczelni, aby zdynamizować rozpowszechnianie informacji o wydarzeniach w danej instytucji i choćby poznać zdanie studentów. Jeszcze bardziej interesującą ideą mogą być instancje naukowe, wiążące naukowców z określonych dziedzin w celu wymiany linków do najnowszych artykułów oraz dyskutowania nad badaniami. Gdyby każda uczelnia lub wydział miały swoje instancje, mogłyby skupiać swoich naukowców, a ci łączyć się w ten sposób z uczonymi z innych jednostek badawczych, korzystając z dobrodziejstwa Fediverse, jednocześnie posiadając dostęp do szerszej sieci, w celach pozanaukowych. Oczywiście, tak samo można by było postępować na Reddicie czy Wykopie, jednak umówmy się - nigdy nie były to portale dostosowane do takich obszarów, także z uwagi na to, że zwyczajnie muszą na siebie zarabiać i wyświetlać reklamy czy udostępniać pewne kwestie za dodatkowe opłaty. A /kbin, jako otwarte oprogramowanie, może w razie czego być nawet dostosowane do określonych zadań, łącznie z interfejsem, o ile komuś bardzo na tym zależy. Dodatkowo, upublicznienie takiego serwera może przyciągnąć osoby chętne do dyskusji o danych zagadnieniach spoza środowiska naukowego (lub zainteresować potencjalnych doktorantów).

Jednak nie musimy ograniczać się do poważnych zastosowań, choć dla niektórych to, o czym teraz będę pisał, jest śmiertelnie poważnym tematem. Mowa o sporcie, który - trzeba przyznać - na Fediverse jest traktowany trochę po macoszemu, a mimo to jest popularny i dzieje się w nim tak dużo, że człowiek może się w tym pogubić, obserwując różnych dziennikarzy w kilku miejscach. Aczkolwiek tutaj chciałem poruszyć inną kwestię i przyznaję, że będzie to trochę prywata. Mam nadzieję, że mi wybaczycie, a jeśli nie - omińcie następne trzy akapity.

Internetowe dzienniki sportowe w Polsce (i nie tylko) są trapione przez dwa bardzo duże problemy, które uwidoczniły się szczególnie w ostatnich latach (mimo że wcześniej te niedogodności też istniały). Pierwszy to skupienie się na sportach bardzo popularnych kosztem dyscyplin niszowych lub po prostu mniej "nośnych", nawet jeśli reprezentanci danego kraju osiągają w nich sukcesy. Oczywiście, mam tutaj na myśli specjalne traktowanie piłki nożnej, która w większości przypadków zajmuje większość nagłówków na stronie głównej, nawet poza sezonem, kiedy piłkarze choćby wypoczywają na wakacjach czy polubili wpis. Nie mówię, że inne dyscypliny również tam nie widnieją, ale są to raczej okazjonalne sytuacje, jak mistrzostwa świata w danej dyscyplinie typu siatkówka, koszykówka czy lekkoatletyka. O tym, że np. w chwili, gdy to piszę, trwa Puchar Świata w rugby czy rozpoczął się sezon NFL raczej przeciętny czytelnik w popularnym serwisie sportowym nie przeczyta. O zdobyciu złotego medalu na Mistrzowstach Europy przez naszych siatkarzy (gratulacje!) media trąbiły, jednak szybko ustąpiły miejsca informacji o tym, kto zostanie nowym selekcjonerem polskich piłkarzy. Oczywiście, zdaję sobie sprawę z czego to wynika. Po pierwsze, popularne dyscypliny są - niespodzianka - popularne i generują największy ruch, a ten jest potrzebny, aby takie serwisy na siebie zarabiały. Trudno się zatem dziwić, że jeśli 70% czytelników szuka informacji o piłce nożnej, 50% z nich o siatkowce, a 40% o żużlu, to więcej newsów i artykułów będzie dotyczyło tej pierwszej dyscypliny, gdyż to się "klika", co powoduje też częstsze wyświetlenie reklam. Co za tym idzie - redakcja jest tak skonstruowana, aby więcej osób było ekspertami z danej dyscypliny, siłą rzeczy ignorując inne obszary sportu lub traktując je po macoszemu.

Drugi problem jest jeszcze bardziej związany z klikalnością i jest to większa clickbaitowość newsów. Niedopowiedzenia, fragmenty w rodzaju "jest kandydat na selekcjonera", "to na niego stawia trener", "kuriozalny powód dyskwalifikacji", informacje z pogranicza sportu i świata plotek (vide przytoczone powyżej polubienie wpisu przedstawione jako "wymowna reakcja na wywiad") - to wszystko, niestety, generuje ruch, bo ludzie lubią interesować się życiem innych ludzi. A to jest coraz śmielej oraz perfidniej wykorzystywane, aby zmuszać ludzi do klikania, aby po trzech akapitach tekstu dowiedzieli się, że w sumie news jest o niczym. Straszna praktyka i uważam, że to próba robienia z ludzi idiotów, sztuczne pompowanie zainteresowania oraz utrzymywanie tylko pozorów poważnego dziennikarstwa sportowego. Zresztą, to zjawisko nie dotyczy tylko sportu i o ile pojawiają się próby przeciwdziałania temu łącznie z profilami, które ułatwiają nieklikanie w takie wiadomości, to przez jakiś czas ta walka będzie pewnie skazana na niepowodzenie.

O e-sporcie już nie piszę, gdyż jego sytuacja jest specyficzna - z jednej strony są to rozgrywki sportowe, a z drugiej jakakolwiek informacja w serwisie sportowym o meczach rozgrywanych na ekranie spotyka się ze sporą grupą osób uważających, że do sportu pasuje to jak wół do karety. Dodatkowo, ten obszar został zagospodarowany przez specjalistyczne serwisy... które jednak też skupiają się na pewnych grach, pomijając inne. Nie jest u nich to tak widoczne i perfidne, jednak także tutaj istnieje obszar do zagospodarowania dla miłośników turniejów w nieco mniej popularnych tytułach e-sportowych. I tak, clickbaity tutaj też się zdarzają, szczególnie w portalach będących pod egidą innej, większej kompanii medialnej.

Czy zatem ciekawą alternatywą nie byłaby instancja sportowa tworzona przez społeczność, złożoną z miłośników różnych (nawet małopopularnych, ale ciekawych) dyscyplin, którzy zasilaliby taki serwis wiadomościami ze swoich "dziedzin" i tym samym dający lepszy obraz sytuacji w świecie sportu? Właśnie w takim celu mógłby zostać wykorzystany /kbin, tym samym pozwalając też zainteresować ludzi bardziej niszowymi obszarami sportu, a nawet udostępniający miejsce na publicystykę prywatnych osób, dołączając do tego społecznościowe komentowanie meczów. Oczywiście, do rozwiązania jest kwestia wydajności takiego serwera - nie od dzisiaj wiadomo, że sport jest popularny i wywołuje ogromne emocje, przez co liczba postów mogłaby przekroczyć zakładane normy. Tym niemniej uważam, że jest to temat do zastanowienia się nawet przez redakcje sportowe, łącznie z dostosowaniem instancji do swoich potrzeb. Co za tym idzie, to rozszerzyłoby pulę użytkowników Fediwersum, którzy zaczęliby szukać kontaktu z osobami na innych instancjach i w serwisach w tym systemie społecznościowym.

W pewnym momencie wspomniałem o publicystyce - instancje /kbina to też niezłe miejsce na prowadzenie blogu. Co prawda, istnieją bardziej wyspecjalizowane w tym systemy jak np. WriteFreely, jednak także agregator ma solidny system i spory limit znaków, oscylujący wokół kilkunastu tysięcy na post. Jak najbardziej jest to miejsce na swoją twórczość internetową z pominięciem mechanizmu magazynów.

Istniejące serwisy /kbina

Posiadanie własnej instancji jest dostępne dla każdego, jednak nie da się ukryć, że jest to raczej przedsięwzięcie dla bardziej zorientowanych technicznie osób lub instytucji, który na takich specjalistów mogą sobie pozwolić. Z własnego doświadczenia mogę powiedzieć, że uruchomienie kontenera lokalnie zajęło mi ok. godzinę, z czego większość czasu minęła na pobieranie paczek. W przypadku poważnych planów poleca się standardową instalację, która pewnie potrwa trochę dłużej, ale też czas inicjalizacji zamknie się w jednym dniu. Oczywiście, inną sprawą jest utrzymanie i moderowanie takim serwerem, a także jego aktualizowanie.

Dlatego warto wspomnieć o instancjach, które już istnieją i w których można zapoznać się z mechanizmem. Tak, jak wspominałem wcześniej - większość serwerów jest ze sobą połączona w federacji, zatem wybór konkretnego serwera nie jest sprawą krytyczną. Także osoby posiadające już konto np. na Mastodonie mogą swobodnie obserwować magazyny z różnych instancji /kbinowych. Ich pełna lista znajduje się na FediDB, natomiast najbardziej popularne są:

  • kbin.social - "oficjalny", największy agregator treści oparty o omawiane oprogramowanie.
  • fedia.io - również duża instancja, na przykładzie której można zauważyć, jak działa federacja, gdyż materiały na kbin.social oraz fedia.io w dużej mierze się pokrywają. To efekt wymiany informacji.
  • karab.in - oryginalna polska instancja, która jest trochę mniej dopieszczona niż kbin.social, ale to stan przejściowy.
  • bin.pol.social - instancja zarządzana przez organizację Fundacja Technologie dla Ludzi, która ma pod swoją pieczą także m.in. obecnie wiodącą polską mastodonową instancję pol.social (obecnie największa w Polsce zaraz za 101010.pl), a także m.in. serwer PeerTube oraz Matrixa.

Przeglądając pewne zakamarki można faktycznie zauważyć, że oprogramowanie jest cały czas rozwijane - tu i ówdzie pojawiają się różne artefakty graficzne, są pewne szczegóły do dopracowania itd. Jednak tak, jak pisałem - software jest gotowy, działa i można konfigurować swoje instancje, dołączając tym samym do grona administratorów systemu /kbin. A lista następnych poprawek czeka w kolejce.

Trzeba przyznać, że tak, jak Reddit czy Wykop, tak /kbin nie dla wszystkich może być zrozumiały od początku - pojęcie "magazynu" może być trochę niejasne, nie wiadomo do końca gdzie dodawać posty, a także w jaki sposób użytkownicy poszukają i zobaczą nasze treści. To normalne i to zamieszanie w głowie mija dość szybko po korzystaniu z serwisu. Tym niemniej, w razie wątpliwości warto zainteresować się nieoficjalnymi poradnikami, takimi choćby jak ten.

Podsumowanie

Czy /kbin jest idealny? Absolutnie nie, ale twórcy zdają sobie z tego sprawę. Jest na tyle dobry, że administratorzy różnych instytucji, organizacji, redakcji, szkół, uczelni czy społeczności mogą myśleć o tym, czy nie jest to narzędzie, które mogą wykorzystać do lepszej komunikacji ze swoimi odbiorcami, bardziej rozpowszechnionych systemów newsowych lub łatwiejszej dyskusji specjalistów lub fanów na dany temat. Tym bardziej, że fanpage na Facebooku zawsze może zostać zamknięty przez Metę (co w przeszłości przytrafiało się różnym, nawet niebudzącym kontrowersji, podmiotom), a nad instancją /kbinową właściciel ma większą kontrolę.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> RSS to nadal dobre rozwiązanie https://wildasoftware.pl/post/rss-nadal-dobre-rozwiazanie?ref=rss https://wildasoftware.pl/post/rss-nadal-dobre-rozwiazanie?ref=rss Thu, 07 Sep 2023 17:30:00 +0000 Żyjemy w dynamicznym świecie, w którym jesteśmy wręcz uzależnieni od nowych informacji. Dzieje się dużo, materiałów w sieci powstaje jeszcze więcej, a ludzi coraz częściej zaczyna dotykać niechciane FOMO (ang. Fear of Missing Out). Społeczność internetowa w jakiś sposób musiała poradzić sobie z tym natłokiem komunikatów, więc zaprojektowano różne aplikacje, rozwiązania i wypracowano metody. Niektórzy zwyczajnie zaglądają co jakiś czas na ulubione serwisy, inni szukają serwisów agregujących wiadomości, a jeszcze inni tylko czytają nagłówki i odkładają linki do przeczytania na później za pomocą skrótów w przeglądarce czy specjalnych aplikacji. A niektórzy na to wszystko machnęli ręką i wyjechali w Bieszczady.

Jak w wielu sytuacjach, Internet (a raczej ludzie tworzący wspólnie globalną wioskę) stworzył pewne narzędzia, wśród których są kanały RSS, którym poświęcony jest ten artykuł. Szczerze mówiąc, w latach 2004-2008... nie byłoby potrzeby pisania takiego tekstu, jaki teraz widzicie na ekranach. RSS był bowiem bardzo powszechny, przez niektóre przeglądarki wręcz proponowany domyślnie (zresztą tak właśnie się o nim dowiedziałem) i korzystało z niego bardzo dużo osób. Teraz powoli odradza się zainteresowanie wokół niego, ale przez wiele lat technologia niemalże leżała schowana w szufladzie. Dlaczego? Odpowiedzią są media społecznościowe oraz mechanizmy subskrypcji. Użytkownicy, porażeni magią tego typu serwisów, zaczęli w nich obserwować wszystkich, nie tylko zdobywając informacje o nowych materiałach, ale też czytając komentarze oraz utrzymując kontakt ze znajomymi. Jednak także ten urok miał swój koniec oraz ujawnił pewne problemy (w tym między innymi wspomniany już przesyt informacji), stąd kanały RSS wcale nie zniknęły, a obecnie powoli wracają do łask lub raczej "normalności".

Opowiedzmy sobie zatem o nich z technicznego punktu widzenia i tego, jak mogą zostać wykorzystane.

Czym jest RSS?

Ten skrót ma dwa rozwinięcia:

  • RDF Site Summary (RDF = Resource Description Framework)
  • Really Simple Syndication

Jest to zbiór języków opartych o znaczniki, które służą do tworzenia kanałów z wiadomościami możliwych do obserwowania. Można powiedzieć, że każdy kanał (ang. channel lub częściej feed) to taki "profil" z najnowszymi materiałami z danej strony, który może być dodany do aplikacji będącymi czytnikami RSS (nie chodzi o fizyczne czytniki, jak np. te do e-booków). Dzięki takim aplikacjom użytkownik może w jednym miejscu śledzić nowości z różnych miejsc, a więc portali, które go interesują. Inaczej mówiąc - RSS służy do tworzenia swojego osobistego serwisu informacyjnego, który agreguje materiały z różnych stron internetowych. Można go też traktować jako telewizor, który po włączeniu pokazuje wiele stacji i najnowsze wiadomości z każdej z nich.

Specjalnie pisałem o tym, że to zbiór języków. Nie ma bowiem jednego standardu "zakodowania" takiego kanału, choć takim rozwiązaniem miał być Atom. Tym niemniej, technologia jest tak rozwinięta, że współczesne czytniki RSS nie powinny mieć problemu z różnymi odmianami sposobu zapisu feeda. Ważne jest tylko to, aby taki portal udostępniał kanał (lub kanały) RSS, do czego za chwilę dojdziemy.

Jak technicznie przebiega odczyt kanału?

Wbrew pozorom, cały proces nie jest specjalnie skomplikowany. Kanał RSS na stronie internetowej (lub jakimkolwiek innym zasobie) to nic innego, jak plik XML, który jest dostępny pod danym adresem URL i cyklicznie odczytywany przez czytniki u użytkowników. Mówiąc bardziej konkretnie:

  1. Strona internetowa tworzy odpowiednio zbudowany plik XML i co pewien czas go aktualizuje (o nowe artykuły, wiadomości itd.).
  2. Ten plik XML musi być publicznie dostępny w sieci.
  3. W sekcji HEAD strony internetowej za pomocą specjalnego znacznika umieszczany jest link i opis kanału.
  4. Użytkownik w swoim czytniku RSS (np. w przeglądarce) dodaje dany adres do subskrybowanych treści. Zwykle, jeśli to wtyczka do przeglądarki, to po wejściu na stronę z kanałem czytnik pozwala na łatwe dołączenie subskrypcji.
  5. Czytnik RSS w odpowiednich odstępach czasu odczytuje w tle ten adres z plikiem XML i sprawdza, czy pojawiła się aktualizacja.
  6. Jeśli pojawiła się nowa wiadomość, to czytnik informuje o tym użytkownika.

Czyli tak naprawdę mamy dwa zadania działające cyklicznie, co pewien okres. Z jednej strony witryna internetowa aktualizuje swój plik z feedem o np. nowe newsy, które pojawiły się na stronie. Z drugiej strony - czytnik RSS spogląda na ten plik i patrzy, czy coś się zmieniło. Z punktu widzenia twórcy strony internetowej nie wymaga to np. udostępnienia specjalnego portu na serwerze czy instalacji dodatkowego oprogramowania - musi "jedynie" tworzyć i uzupełniać plik tekstowy oraz zapewnić możliwość dojścia do niego po danym adresie. Bardzo często są to odnośniki w rodzaju adresstrony.com/rss.xml.

Tworzenie własnego kanału

Wiemy, że dostarczanie kanału z wiadomościami polega na tworzeniu pliku XML, a więc czegoś, co jest obsługiwane przez wiele języków i frameworków. Przykładowo, język PHP w swojej bibliotece standardowej udostępnia moduł SimpleXML ułatwiający zarządzanie tym formatem. Ale to nie zmienia faktu, że trzeba wiedzieć, jak taki plik XML dla RSS-a jest zbudowany.

Tak, jak pisałem - RSS nie do końca jest standardem, a raczej rodziną różnych metod zapewniających wytyczne. Ponieważ jednak te strumienie są dojrzałe i dostępne od wielu lat, czytniki radzą sobie z różnymi notacjami. Tym niemniej, pewne elementy są wspólne.

Jako przykład możemy podać nasz blog. Plik XML, który budujemy co godzinę, dostępny jest u nas pod adresem https://wildasoftware.pl/rss.xml. Śmiało możecie kliknąć w link i otworzyć go w przeglądarce.

Plik zbudowany jest w następujący sposób:

<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
	<channel>
		<title>Blog Wilda Software</title>
		<link>https://wildasoftware.pl</link>
		<description>Blog prowadzony przez Wilda Software o tworzeniu oprogramowania i przybliżający branżę IT spoza niej.</description>
		<lastBuildDate>Thu, 3 Sep 2023 01:02:00 +0000</lastBuildDate>
		<language>pl-PL</language>
		<atom:link href="https://wildasoftware.pl/rss.xml" rel="self" type="application/rss+xml"/>
		<item>
			<title>Kiedy 99,9% nie ma znaczenia</title>
			<link>https://wildasoftware.pl/post/kiedy-999-nie-ma-znaczenia?ref=rss</link>
			<guid>https://wildasoftware.pl/post/kiedy-999-nie-ma-znaczenia?ref=rss</guid>
			<pubDate>Sat, 01 Feb 2020 00:00:07 +0000</pubDate>
			<content:encoded>
				<![CDATA[ <p>Osoby pracujące w IT...</p> ]]>
			</content:encoded>
		</item>
		<item>
			...
		</item>
		...
	</channel>
</rss>

Widzimy tutaj budowę typowego pliku XML - zaczynamy od głównego węzła rss informującego przeglądarkę, że w ogóle mamy do czynienia z plikiem RSS, a następnie widzimy tag channel, który w standardzie Atom może też nazywać się feed. W tym miejscu znajdują się podstawowe informacje o samej stronie, czyli swoiste "przedstawienie się", aby użytkownicy mogli lepiej nas zlokalizować, gdy już dodadzą kanał do swoich subskrypcji. Można podać tytuł, link, opis oraz to, co może być istotne dla technicznej warstwy czytników - język oraz datę ostatniego zbudowania pliku. Dzięki temu wtyczka po stronie odbiorcy będzie mogła zoptymalizować odczyt kanału i sprawdzać zmiany tylko w tych, które deklarują, że zmienił się u nich moment ostatniej generacji. Na naszym blogu artykuły pojawiają się w odstępach tygodniowych lub dwutygodniowych, więc nie ma potrzeby aktualizowania pliku wiele razy dziennie, jak to ma miejsce np. w portalach newsowych. Moglibyśmy robić to co tydzień czy raz w nocy, ale musimy wziąć też pod uwagę, że subskrybent chciałby dowiedzieć się o nowym artykule jak najszybciej. Dlatego nowy plik generujemy co godzinę.

Następnie mamy szereg węzłów item i to są właśnie pozycje, które są pobierane i pokazywane w czytniku RSS. W naszym przypadku będą to artykuły, które mają swój tytuł, link oraz identyfikator wpisu (warto tutaj znać różnicę), datę opublikowania, a także treść, przynajmniej skróconą. W tym ostatnim węźle może pojawić się kod HTML, przez co w normalnym przypadku plik XML mógłby być źle interpretowany - w końcu te dwa formaty są do siebie dość podobne pod kątem budowy. Dlatego tego typu opisy warto opatrzyć specjalnym znacznikiem , który zapobiega interpretowaniu ewentualnych tagów w środku.

Jak widać, węzłów item może być wiele i cały czas dochodzą nowe - na tym polega dodawanie wiadomości. Oczywiście, nie zawsze warto zachowywać stare węzły, np. sprzed roku - w czytniku RSS nikt ich nie przeczyta, a jedynie zajmują miejsce, przez co coraz większy plik RSS wolniej się ładuje, gorzej wygląda jego odczytywanie i tym samym ludzie będą mniej chętni, aby go subskrybować.

Mamy zatem plik XML - jak poinformować świat, że go udostępniamy? Służy do tego odpowiedni tag w sekcji HEAD strony internetowej. W naszym przypadku jest to:

I już - czytniki będą mogły zobaczyć (oczywiście, o ile plik ma poprawną strukturę), że można dodać ten kanał RSS do subkrypcji.

Wróćmy na chwilę do zmianki o języku i jednej związanej z tym rzeczy - jeśli na stronie udostępniamy materiały dostosowane do danego odbiorcy, mamy sztywny podział na kategorie lub osobno chcemy powiadamiać o komentarzach, to istnieje możliwość generowania wielu kanałów. Nie jesteśmy ograniczeni do jednego pliku XML i jednego tagu - można mieć ich wiele i upubliczniać osobno. Widać to zresztą w niektórych czytnikach, które pozwalają wybrać konkretny feed dla danej strony.

Warto też wspomnieć o tym, że nie trzeba tworzyć takiego pliku ręcznie - dla wielu znanych technologii istnieją odpowiednie biblioteki, a w przypadku stron zbudowanych za pomocą np. Wordpressa można posiłkować się wtyczkami, które wykonają proces za programistę, opierając się na początkowej konfiguracji.

Czy warto mieć swój kanał RSS?

W przypadku, kiedy strona internetowa ma charakter wizytówkowy, jest wyłącznie sklepem lub to system do pracy, o konkretnych funkcjach, to faktycznie kanał RSS może nie mieć sensu. Jednak większość miejsc w sieci udostępnia nowe zasoby, o których chce powiadamiać odbiorców i wówczas kanał RSS jest dobrym wyborem. Są to:

  • portale newsowe,
  • blogi,
  • miejsca dyskusyjne (fora),
  • serwisy z ogłoszeniami

i tak naprawdę wiele innych witryn. Dodatkowo, nawet np. wcześniej wymienione sklepy również mogą prowadzić blog, który wspiera ich główną działalność. Sami jesteśmy przykładem strony, która przedstawia profil naszej firmy oraz usługi, które oferujemy, ale kanał RSS prowadzi do blogu, bo to on dostarcza nowe materiały.

Ta droga powiadomień jest niezależna i trafia bezpośrednio do odbiorców. Nie stoi też w sprzeczności z innymi sposobami dotarcia do potencjalnych czytelników, w tym nie broni reklamowania się w inny sposób. To przykład mediów własnych, które są jak najbardziej w cenie, a co ważniejsze, po ich początkowym przygotowaniu i odpowiednim ustawieniu automatycznych mechanizmów, nie ma potrzeby ich edytowania, a tym bardziej samodzielnego, ręcznego aktualizowania pliku. Krótko mówiąc - nie do końca istnieją argumenty, które odradzałyby stosowanie RSS w portalu z treściami. Natomiast, oczywiście, nie powinna być to jedyna droga, którą informujemy o nowych postach czy newsach.

Kanał RSS a serwisy społecznościowe

Wspominałem o tym, że od pewnego momentu rolę powiadomień przejęły media społecznościowe, które w jednym miejscu pozwalają wyświetlać informacje o nowościach, komentarze innych użytkowników, a także wszelkiego rodzaju inne materiały - opinie, dyskusje, ciekawostki czy memy. To oznacza, że wielu internautów stwierdziło, że po co mają konfigurować sobie RSS, skoro wszystko mają w portalu, który i tak regularnie przeglądają. Albo w kilku portalach. No właśnie - tutaj rodzi się problem.

Media społecznościowe to bardzo dobre narzędzie i trudno wyobrazić sobie bez nich życie, także firmom, nawet tym mniejszym. Natomiast ich rozrost sprawił, że ludzie zaczęli "pływać" w nowych treściach i powoli zaczęło to przeszkadzać. Portale takie jak Instagram, Twitter/X czy LinkedIn mogą nie tylko dostarczać radość, ale wręcz przytłaczać nowymi wiadomościami i zaburzać tzw. higienę korzystania z Internetu. Co za tym idzie, odnalezienie się w gąszczu informacji i wyłuskanie wiadomości o nowym artykule ulubionego blogera czasami graniczy z cudem, zwłaszcza, jeśli ten bloger dodatkowo umieszcza posty na zupełnie inne tematy (a umówmy się - większość to robi, bo inaczej "nie istnieją" lub nie zarabiają). Z drugiej strony, przeglądanie kilku miejsc ręcznie w celu znalezienia nowego artykułu również mija się z celem i niepotrzebnie zabiera czas.

Dlatego kanały RSS są nadal ciekawym rozwiązaniem, które trafi do osób chcących odciąć się od tego internetowego zgiełku, ale nadal pragnących śledzić nowe artykuły ulubionych twórców. Co więcej, te kanały są ze sobą "kompatybilne" - powiadamiać o nowych wiadomościach można zarówno przez feed, jak i przez media społecznościowe, przy tym tak, jak pisałem - w tym pierwszym przypadku robimy to automatycznie, bez naszego czynnego udziału. A żeby tego było mało, same systemy socialmediowe czasem udostępniają kanały RSS. Przykładem jest Mastodon - jeśli adres samego profilu to np. https://social.wildasoftware.pl/@wilda, to po dodaniu ".rss" na końcu uzyskujemy rzeczony kanał.

Jedyna większa wada kanałów RSS w stosunku do mediów społecznościowych to fakt, że nie ma jasnej informacji o tym, ile osób subskrybuje dany kanał. Aczkolwiek, dzięki różnym czytnikom i serwisom pobierającym dane, można to oszacować.

Podsumowanie

Kanały RSS to trochę zapomniana technologia w obliczu "ekscytujących" portali społecznościowych, ale nadal ważna i cenna. W dodatku po prostu działa i to w bardzo zrozumiały sposób, przez co nie wymagają dużo czasu poświęconego na obsługę. Wielu użytkowników posiada czytniki wbudowane w przeglądarkę lub można je bez problemu doinstalować. Wystarczy zatem to wszystko połączyć i używać RSS-a, aby mieć wszystkie nowości w jednym miejscu.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Usunięcie nie zawsze jest usunięciem https://wildasoftware.pl/post/usuniecie-nie-zawsze-usunieciem?ref=rss https://wildasoftware.pl/post/usuniecie-nie-zawsze-usunieciem?ref=rss Thu, 24 Aug 2023 17:30:00 +0000 Systemy informatyczne są bardzo różne, zarówno pod kątem dziedziny, której dotyczą, platform, na których działają, jak i odbiorców, do których są kierowane. Jeśli już mielibyśmy znaleźć jakąś część wspólną, to byłoby wykonywanie podstawowych operacji dodawania, odczytywania itd. na obiektach biznesowych, co lepiej znamy pod skrótem CRUD. Dzisiaj jednak nie będzie nas interesować tworzenie, wyświetlanie czy aktualizacja. Zamiast tego skupimy się na tym, co kryje się pod "D" w tym terminie, a więc delete - usuwaniu.

Każdy oczekuje, że jeśli cokolwiek możemy dodać w aplikacji, to powinniśmy to też móc usunąć. Powody mogą być różne - zwolnienie miejsca, pozbycie się błędnych danych, ukrycie czegoś itd. Jednak ta operacja jest bardzo specyficzna i z tego powodu nie zawsze możliwa. Co jest powodem i czy faktycznie usuwanie zasługuje na specjalne traktowanie? Przecież mechanicznie jest dużo prostsze od wygenerowania obiektu, prawda? Cóż, niekoniecznie.

Formy usuwania

Większość z nas, myśląc o usuwaniu, kojarzy to z fizycznym pozbyciem się informacji z bazy danych (lub pliku z systemu). I całkiem słusznie - w końcu taki jest cel skasowania czegokolwiek. Tymczasem, o ile podczas pisania dokumentacji i specyfikowaniu wymagań faktycznie używa się tego terminu pod kątem opisania funkcji systemu, o tyle nie zawsze "fizyczne" kasowanie jest zalecane.

Powody są co najmniej dwa. Pierwszy z nich to fakt ostateczności takiej operacji. Oczywiście, wiele osób powie, że tak ma być - w końcu użytkownik wybiera tę opcję nie bez powodu i chce oczyścić system. Jednak nie spodziewacie się, jak bardzo użytkownicy są czasem nieświadomi i niepewni tego, o co proszą oraz co robią w aplikacji. Niby człowiek wie, że chce usunąć, ale tak naprawdę później nachodzą go wątpliwości: "a co, jeśli to nie o ten obiekt chodziło", "a można to jakoś odzyskać", "a dlaczego to mi zniknęło" i tym podobne. Jeśli mówimy o "fizycznym" usuwaniu, to faktycznie czasem mogą zdarzyć się takie dramaty - dlatego ten rodzaj powinien być stosowany tylko i wyłącznie w przypadku prostych i "nieskomplikowanych" danych. Jednak istnieje jeszcze druga kwestia, którą należy rozważyć.

A jest nią powiązanie obiektów ze sobą i to główna przyczyna, dla której "fizyczność" nie jest rekomendowana. Wyobraźmy sobie dokument przetwarzany w systemie (jako rekord w bazie danych) i zastanówmy się, jakie atrybuty go opisują. Z pewnością wiele osób wymieni nazwę czy treść, ale jest to także m.in. autor (a więc jakiś użytkownik), osoby przypisane do edycji (ponownie użytkownicy) czy kontekst, w jakim dokument został utworzony (np. projekt czy klient, także znajdujący się w bazie danych). Ale nie tylko są to atrybuty - sam dokument może mieć swoją historię, osoby go podpisujące czy załączniki. W takim wypadku, w momencie usunięcia rekordu pliku, dzięki nierozważnie ustawionym mechanizmom systemów do zarządzania bazami danych automatycznie musiałyby zostać skasowane powiązane z nim informacje, a użytkownik straciłby np. w ogóle dojście do wpisu z historii, że wykonał jakąś operację. Może to spowodować duże szkody w systemie, jest narażone na błędy, a dodatkowo sama z siebie nie pozwoli na to baza danych (o ile odpowiednio skonfigurujemy schemat), co oznacza, że wiele operacji usunięcia stowarzyszonych obiektów trzeba wykonać ręcznie.

Dlatego dużo częściej stosuje się usuwanie "logiczne" zwane też dezaktywacją. W tym przypadku dane nie są trwale usuwane w systemie - zamiast tego oznacza się jako usunięte lub nieaktywne. Niewątpliwymi zaletami są:

  • brak potrzeby kaskadowego usuwania powiązanych rekordów (prostsza obsługa),
  • "wentyl bezpieczeństwa" w postaci możliwości cofnięcia się do danego rekordu,
  • większe możliwości analizy, kto usunął rekord,
  • od strony użytkownika jest to funkcjonalnie równoważne fizycznemu usunięciu (jeśli jest dobrze zrobione),
  • jeśli usunięte dane mają nadal być widoczne przy obiektach, w których zostały wcześniej wybrane, jest to nadal możliwe.

W praktyce większość ważnych obiektów przetwarzanych w systemie jest usuwana w ten sposób, gdyż tak jest po prostu bezpieczniej, a te twory bywają w relacji z naprawdę wieloma elementami. Z drugiej strony, wymaga to sprawdzania flagi aktywności praktycznie w każdym zapytaniu bazodanowym, co trochę je wydłuża, ale przede wszystkim wymaga od programistów pamiętania o tym. Są to jednak małe wady, nieznaczące w obliczu zalet. Zwłaszcza, że można wykorzystać odpowiednie mechanizmy w architekturze lub systemie bazy danych, aby takie filtrowanie robić automatycznie.

Dezaktywowanie może być rozumiane także bardziej dosłownie - bywają obiekty, które klient chce jedynie oznaczać jako nieaktywne i móc do nich zajrzeć w każdym momencie z poziomu aplikacji. Najczęściej jest to nazywane "archiwizowaniem" i działa na podobnej zasadzie, natomiast występują dwie podstawowe różnice. Po pierwsze, interfejs umożliwia ich jawne przywracanie, a po drugie - rodzi to trochę więcej problemów z zapytaniami, gdyż trzeba zdecydować, kiedy sprawdzać daną flagę, a kiedy nie. To zależy już od konkretnych ustaleń.

Inną z form jest zamazywanie danych usuwanego obiektu, co działa jak dezaktywacja, ale nie polega na zmianie jednej kolumny w systemie - zamiast tego haszuje się odpowiednie informacje, nie pozwalając na ich klarowny odczyt. Dwa terminy, o których tutaj trzeba pamiętać, to pseudonimizacja oraz anonimizacja, a do samego tematu wrócimy w dalszej części tekstu.

Wreszcie, niekiedy występuje też coś takiego jak scalanie, które samo w sobie usunięciem nie jest, ale zwykle się z nim wiąże. Bywają systemy, do których importowane są archiwalne dane klienta z plików lub innego systemu i - jak można się spodziewać - nie zawsze są to czyste informacje. Zdarza się również, że zaimportowane obiekty zostały już wcześniej ręcznie dodane do systemu, przez co powstają duplikaty. Dlatego funkcja scalania (lub, jak częściej powiedzą informatycy, "merdżowania") bywa potrzebna, a jedną z konsekwencji jest pozbycie się duplikatu, a więc jego (tym razem) fizyczne usunięcie. To sytuacja jeszcze bardziej związana ze specyfiką systemu i implementowana dość rzadko, gdyż - co tu dużo mówić - jest bardzo złożonym zagadnieniem.

Istnieją też przypadki, w których system w ogóle nie pozwala na usuwanie obiektów, w żadnej formie. Najczęściej wynika to z kwestii prawnych, związanych z płatnościami lub po prostu świadomej decyzji właściciela oprogramowania. Przykładem może być posiadanie danych użytkownika, który podpisał umowę lub dostał fakturę. Akurat kwestię użytkowników i tak rozpatrzymy osobno, ale związane z nim przypadki to najlepiej "udokumentowane" sytuacje, w której w skrócie CRUD nie ma prawa wystąpić "D". A przynajmniej nie zawsze.

Kiedy usuwać, a kiedy dezaktywować?

Pośrednio odpowiedziałem już na to pytanie - dezaktywacja na pewno jest bezpieczniejsza, pozwala uniknąć zastanawiania się, co trzeba uwzględnić przy pozbywaniu się krotki z bazy danych i daje zabezpieczenie w postaci możliwości powrotu do danych. Dlatego zaleca się tę technikę przy wszystkich obiektach, które są:

  • biznesowo istotne,
  • "duże", tj. nie tylko mają wiele pól, ale też ich uzupełnianie zajmuje użytkownikowi więcej czasu,
  • wiążą się z wieloma innymi obiektami,
  • stanowią istotny składnik danych, które są cały czas przetwarzane w systemie (np. grupa produktów, z której korzystają towary).

Natomiast ktoś słusznie może zauważyć, że pomijając wcześniej wspomnianą konieczność uwzględnienia odpowiedniej flagi w zapytaniach, dezaktywacja ma tę wadę, iż nie pozbywa się informacji, a co za tym idzie - duże tabele, w których dane są często usuwane, mogą stać się śmietnikiem i zajmować sporo przestrzeni dyskowej. W takich sytuacjach, jeśli dotyczy to np. danych słownikowych i można przenieść referencje do nich na inne obiekty, warto pokusić się o drogę "fizyczną". Dość naturalny przykład to sytuacja, w której mamy obiekt, dla którego od razu (na jednym ekranie) zarządzamy grupą informacji. Weźmy choćby klienta i jego osoby kontaktowe - dane są przesyłane w jednej paczce i istnieją dwa podejścia do zapisu:

  1. Każdą przesłaną osobę kontaktową przeglądamy pod kątem tego, czy jest nowa (insert), czy edytowana (znajdujemy odpowiednią krotkę i wykonywany jest update). Jeśli jakaś osoba kontakowa wcześniej istniała w bazie, a w nowych danych jej nie ma, to ją usuwamy (fizycznie lub logicznie).
  2. Usuwamy (fizycznie) wszystkie dotychczas zapisane osoby kontaktowe i dodajemy na nowo krotki korzystając z przesłanego formularza. W szczególności może się zdarzyć, że usunęliśmy dwie osoby i dodaliśmy na nowo te same dwie osoby.

Ponownie - wszystko zależy od przypadku. Są takie, w których te powiązane informacje dalej są wskazywane przez inne obiekty i wówczas w grę wchodzi tylko opcja nr 1. Natomiast, jeśli nie zależy nam na zachowaniu identyfikatorów rekordów, a obiekty spokojnie mogą zostać "zresetowane", to opcja nr 2 jest zdecydowanie prostsza.

Inne trudności związane z usuwaniem

Wspomniałem o tym, że usuwanie może być bardziej złożoną sprawą, niż początkowo wydaje się klientowi. W przypadku dezaktywacji "kruczek" polega na obsłudze określonej flagi przy obiektach. W przypadku klasycznego podejścia jest to zwyczajnie obarczone pewnym ryzykiem, a co za tym idzie - potrzebą uważniejszego przetestowania różnych przypadków.

Ale należy też pamiętać o szczegółach, które zwykle umykają uwadze podczas analizy. Chociażby to, że operacje usunięcia powinny być potwierdzane przez użytkowników, co oznacza wprowadzenie okien modalnych lub innych form alertów z przyciskami "Tak" oraz "Nie". Jako że z punktu widzenia użytkownika operacja jest nieodwracalna (lub przynajmniej przywrócenie jest problematyczne), taka prośba o potwierdzenie jest potrzebna. Druga kwestia to uprawnienia - jeśli nawet użytkownik może dodawać obiekty, to nie zawsze oznacza, że może je usuwać. To oznacza zabezpieczenie metod zarówno po stronie frontendu, jak i backendu, zadbanie o wyświetlenie odpowiednich przycisków na frontendzie, a czasem nawet przeniesienie wszystkiego do specjalnie wydzielonego panelu administracyjnego.

Trzecia kwestia to logowanie, ale w znaczeniu przechowywania historii operacji na danym obiekcie. Ma to sens szczególnie dla większych, biznesowo ważniejszych tabel, w których może być potrzebne późniejsze dochodzenie do tego, które dane zniknęły, dlaczego i kto był za to odpowiedzialny. Sam temat logów wykracza poza temat tego tekstu, ale jest to kolejne zabezpieczenie na wypadek nieprzewidzianych sytuacji i pytań klienta "jak to się stało, że to mi zniknęło".

Jak to wygląda z użytkownikami?

Wspomnieliśmy już o tym, że usuwanie użytkowników należy traktować specjalnie. Z jednej strony mamy do czynienia z RODO, czyli ochroną danych osobowych oraz między innymi zapewnieniem obsługi żądania usunięcia tych informacji z systemu informatycznego. Z drugiej - fakt, że użytkownicy są zazwyczaj powiązani z ogromną ilością danych i ich fizyczne usunięcie to tragedia dla systemu. Tutaj z pomocą przychodzą trzy rzeczy.

Po pierwsze, usunięcie danych osobowych może być różnie rozumiane i istnieją prawne uzasadnienia, aby takie informacje jednak były zachowywane w określonych warunkach.

Druga i trzecia rzecz to techniki nazywane anonimizacją oraz pseudonimizacją. Obie polegają na wspomnianym wcześniej maskowaniu danych w taki sposób, aby nie można było ich odczytać bez odpowiednich uprawnień lub dodatkowych działań. Jednak różnią się sposobem maskowania. W przypadku anonimizacji mamy do czynienia z całkowitą, pseudolosową (w przypadku klasycznych systemów informatycznych trudno mówić o pełnej losowości) transformacją wartości danego pola, przez co nie da się go potem odzyskać. Z jednej strony jest to bezpieczne dla personaliów użytkownika. Z drugiej - bywają sytuacje, w których dane muszą zostać odzyskane na potrzeby działań śledczych czy procesowych. Wówczas bardziej polecana jest pseudonimizacja, która również maskuje dane, jednak z użyciem pseudolosowo wygenerowanego klucza, który znają tylko zaufane osoby i może służyć do odkodowania informacji. W praktyce więc anonimizacja od pseudonimizacji różni się tym, że klucz użyty do szyfrowania w pierwszym przypadku nie jest nigdzie zachowywany, a w drugim - jest.

W takiej sytuacji należy szczególnie pamiętać o bezpieczeństwie danych oraz ewentualnym dostępie do zakodowanych informacji tylko dla ściśle uprawnionych osób - musi mieć to uzasadnienie prawne i być zawarte w regulaminie czy polityce prywatności. Często tworzy się osobne konto administratora, który ma uprawnienia do usuwania oraz przywracania, a jego hasło jest wręcz zamykane w sejfie. Dodatkowo, z uwagi na to, że użytkownicy nadal mogą być wyświetlani w systemie przy okazji powiązania z pewnymi obiektami, należy zadbać o to, aby odbiorcom w takich sytuacjach wyświetlała się informacja o tym, iż taka osoba została usunięta. Na pewno nigdzie nie powinien pojawić się hasz, którym teraz jest imię czy nazwisko.

Remove a delete

Na koniec warto wyjaśnić jeszcze subtelną różnicę w języku angielskim pomiędzy słowami remove oraz delete. To pierwsze sformułowanie dotyczy właśnie "miękkiego" potraktowania usuwania - oznacza odseparowanie informacji, ukrycie jej przed wzrokiem osób, ale nadal zachowanie w bazie danych. Może też być użyte w momencie, kiedy dany obiekt jest "odpinany" od innego. Z kolei delete to faktyczne usunięcie, wręcz wymazanie informacji z systemu. Pierwotnie pochodzi z języka łacińskiego, w którym praprapraprzodek tego słowa, dēlētus oznaczało "zniszczony".

Podsumowanie

Jak widać, temat usuwania wydaje się prosty, ale taki nie jest. A nawet, jeśli ktoś już wcześniej spodziewał się, że dane raczej się dezaktywuje niż kasuje, to mam nadzieję, że mogłem coś dodać do tej wiedzy i sprawić, że każdy zacznie traktować tę operację jeszcze bardziej poważnie niż do tej pory.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Na co zwrócić uwagę w portfolio przy rekrutacji? https://wildasoftware.pl/post/na-co-zwrocic-uwage-portfolio-rekrutacji?ref=rss https://wildasoftware.pl/post/na-co-zwrocic-uwage-portfolio-rekrutacji?ref=rss Thu, 17 Aug 2023 17:30:00 +0000 Prowadzimy software house, a więc jasne jest, że od czasu do czasu zdarza nam się przepytywać osoby, które są potencjalnymi kandydatami do pracy. Każdy, kto kiedykolwiek aplikował do jakiegoś zakładu, starał się o praktyki lub generalnie chciał się "pokazać", wie, co w takich sytuacjach się wysyła - jest to CV, czyli (jeśli ktoś chce pokazać, że jest erudytą) curriculum vitae, po polsku nazywany życiorysem zawodowym. Zawiera on personalia, wykształcenie, ale przede wszystkim doświadczenie danej osoby, łącznie z certyfikatami i przebytymi szkoleniami. Nie do zignorowania są też sekcje z umiejętnościami, kompetencjami, a także zainteresowaniami. Oczywiście, CV jest bardzo ważne i nawet, jeśli jesteście dopiero na wstępie swojej drogi zawodowej w IT, to powinno być wypełnione, schludne, na bieżąco aktualizowane, a jednocześnie odpowiadać stanowi rzeczywistemu. Jednak mimo to, ten dokument zwykle nie jest wystarczający, aby zainteresować sobą firmę produkującą oprogramowanie. O co jeszcze warto zadbać? O portfolio.

Zanim przejdziemy dalej, że absolutnie nie jest to tekst odkrywający tajniki rekrutacji. Jeśli szukacie materiałów na ten temat, to znajdziecie je na stronach i blogach specjalistów, takich jak Just Join IT czy SOLID.Jobs, a my nie aspirujemy, aby się z nimi równać. Zamiast tego chcieliśmy przedstawić to, w jaki sposób software house może patrzeć na przesłane portfolio kandydata i tym samym, jak kandydat może pomóc sobie (lub zaszkodzić) prezentując swoje prace. Nadmienię również, że to nasze subiektywne spojrzenie na tę kwestię.

Zacznijmy od najważniejszej rzeczy - warto utrzymywać portfolio. Nawet, jeśli jest ono skromne, to sama jego obecność jest sygnałem dla firmy, że pretendent nie próżnuje i oprócz wypisania kompetencji oraz uczestniczenia na studiach rzeczywiście może pokazać owoce swojej pracy. Przy czym tutaj należy uważać na kilka rzeczy. Oczywiście, portfolio składające się z prostego kalkulatora liczącego podstawowe operacje arytmetyczne w konsoli nie wzbudzi specjalnej ekscytacji u osób rekrutujących, nawet jeśli aplikacja będzie opisana w niesamowity sposób. Dlatego pozycje, które są pokazywane w tej sekcji, powinny być ciekawe, większe lub - najlepiej - mające sens, a nawet potencjał biznesowy. I nie oznacza to, że nie opłaca się wpisywać do prezentowanych projektów niczego poniżej poziomu Nozbe czy innych komercyjnych aplikacji - bardziej chodzi o to, aby były one "sensowne". Przykładowo, jeśli dana osoba chwali się oprogramowaniem do powtarzania słówek z angielskiego za pomocą elektronicznych fiszek, to nie jest istotne, że istnieje już masa takich programów na rynku ani że ta konkretna nie wprowadza niczego innowacyjnego. Jeśli natomiast rekrutujący widzi lub może przeczytać, że aplikacja powstała na potrzeby danej osoby (jedna z lepszych rad: "twórz coś, co Tobie samemu się przyda"), jest zmierzeniem się z nieznaną wcześniej technologią i - co zaraz podkreślę - jest skończona, to jak najbardziej jest to sygnał, że takie oprogramowanie było tworzone na poważnie i z "sercem".

I właśnie - oprogramowanie powinno być skończone lub przynajmniej w fazie, w której można je opublikować. Wielu programistów po godzinach pracuje nad swoimi prywatnymi projektami, ucząc się nowej technologii lub tworząc narzędzia, które sami będą wykorzystywali. To są idealne pozycje do portfolio, gdyż pokazują, że dana osoba ma nie tylko zapał, ale też determinację do tego, aby finalizować swoje projekty lub przynajmniej skonstruować MVP. Łatwo jest zacząć pisać oprogramowanie, wpaść na genialny pomysł i projektować go w nieskończoność - jak to ktoś kiedyś powiedział, pomysły są tanie (choć to raczej kwestia dotycząca startupów i ich spieniężenia). Natomiast przejście tej drogi przez trudności, które piętrzą się po drodze, poradzenie sobie z nimi i wreszcie stworzenie czegoś, co ktoś może nawet przeklikać już takie proste nie jest. Ale właśnie dlatego to tak cenne doświadczenie. Dużo lepsze są 2 ukończone lub "produkcyjnie" dostępne aplikacje niż 40 w fazie ciągłego rozwoju.

Przy okazji - to oznaka, że tak, nie warto ograniczyć się do programowania tylko na studiach informatycznych. Bardzo cenne jest pokazanie, że człowiek nie ogranicza się tylko do tego, ale rzeczywiście pracuje nad sobą w domu, poznając technologie inne niż omawiane w akademickich ławach. Nie chcę tutaj mówić, że lepiej być pasjonatem niż tylko rzemieślnikiem, gdyż byłoby to obraźliwe i nieprawdziwe (choć "za moich czasów..."), natomiast umówmy się - aby czegoś się nauczyć, trzeba wyjść poza strefę komfortu. Nie zawsze całkowicie, ale chociażby o jeden mały krok. Na studiach był React? Może warto poznać podejście z Reduxem. Pojawił się projekt aplikacji do zapisywania wyników meczu w Pythonie? Może warto rozbudować go o mechanizm uwierzytelniania. Nie trzeba od razu zmieniać całego stosu technologicznego, choć i czasem warto to zrobić, szczególnie na początku "kariery".

Należy też wziąć pod uwagę technologie - potencjalny pracodawca, rekrutujący np. w segmencie aplikacji mobilnych, niekoniecznie będzie zainteresowany botem giełdowym na Slacku czy aplikacją desktopową, w której kandydat spróbował swoich sił w C# i .NET Core. Jasne, że z takich pozycji, jeśli są dobrze opisane, też można czegoś dowiedzieć się o kandydacie, ocenić konstrukcje w kodzie, zobaczyć tok myślenia dotyczący technikaliów, ale także analizę wymagań - dlatego to nie jest tak, że należy takie rarytasy wyrzucać je z portfolio. Natomiast co rekrutującemu po dziesięciu aplikacjach w C#, jeśli nie widzi czegoś, co potwierdzałoby doświadczenie (lub próbę jego zdobycia) w Kotlinie/Swifcie/Ionicu/Flutterze, który jest podstawą stanowiska, o jakie toczy się gra? Oczywiście, to tylko przykład, ale warto przejrzeć, na które projekty położyć nacisk i zdecydować nie tylko o tym, z czego jesteśmy dumni jako "prywatni" programiści, ale też co rzeczywiście może przekonać firmę do nas.

Warto też zwrócić uwagę na to, co pojawia się w portfolio wielu młodych osób - wspomniane wcześniej projekty stworzone na potrzeby zajęć na uczelni. Bardzo często widzimy takie aplikacje i wcale się temu nie dziwimy - niektóre są tak duże i włożono w nie tyle serca, że spokojnie można się nimi pochwalić, zwłaszcza, że zwykle "leżą" już gotowe na Githubie (do tego jeszcze dojdziemy). Natomiast do tego też trzeba podchodzić rozsądnie. Po pierwsze, nie wszystko, co zostało stworzone w ramach zajęć na uniwersytetach jest warte pokazania, bo dobrze wiemy, jak wygląda tworzenie niektórych projektów zaliczeniowych - sami byliśmy studentami. Można ich wypisać dziesiątki, ale zwykle najwyżej kilka ma sens. Po drugie, warto uczciwie zaznaczyć, że dana aplikacja została stworzona na potrzeby zaliczenia przedmiotu, chyba że jest to projekt programisty, który przy okazji przysłużył się do zdobycia oceny, a tak naprawdę był tworzony lub rozwijany w zakresie znacznie wykraczającym poza ramy przedmiotu. Po trzecie, należy wziąć pod uwagę to, że czasami projekty powstają w grupach, niekiedy istnieją jakieś dodatkowe obostrzenia z ramienia uczelni i nie zawsze można się czymś pochwalić pod kątem prawnym lub moralnym. Co nie zmienia faktu, że studenci tej drogi nie muszą odrzucać, a jedynie ją przemyśleć.

Wspomniałem już o tym mimochodem, ale tak - osoby weryfikujące kandydata przeglądają kod. Może być to dość istotne na wielu płaszczyznach. Całkiem rozbudowane oprogramowanie, ale wyglądające w źródłach jak koszmar głównego programisty daje pole do przemyślenia. Podobnie różnice pomiędzy projektami, szczególnie czasowe, które pozwalają przekonać się, czy dany kandydat potrafi się uczyć na błędach lub włączać do swoich technik kolejne elementy. Nie zapominajmy, że profesjonalne oprogramowanie ma nie tylko działać, ale być też stosunkowo łatwe we wdrożeniu się do niego oraz modyfikacji, a zatem umiejętność pisania czytelnego kodu jest bardzo istotna. Choć, oczywiście, można ją sobie wyrobić w trakcie i do tego najlepiej nadają się praktyki lub praca.

Wreszcie, ważny jest sposób prezentacji. Zdecydowana większość programów w portfolio posiada link do Githuba i to jak najbardziej prawidłowe podejście, szczególnie, jeśli istnieje tam odpowiedni plik typu README rozszerzający opis. Natomiast jeszcze milej widziane są aplikacje znajdujące się na serwerze i osiągalne z poziomu przeglądarki. Nie zawsze jest to możliwe, ale pokazanie oprogramowania w tej formie świadczy nie tylko o zaawansowaniu projektu, ale jeszcze o czymś - że kandydat potrafi coś wdrożyć i tym samym zetknął się z wieloma tematami, które programiści mają na co dzień w pracy, mimo że nie są administratorami systemów czy specjalistami w tej dziedzinie. Niestety (albo stety?), takie umiejętności się przydają i klienci ich oczekują.

Oczywiście, nie są to wszystkie wytyczne dotyczące umieszczania portfolio w aplikacji wysyłanej do software house'u - to bardziej nasz punkt widzenia na tę sekcję wynikający z praktyki i tego, jak sami oceniamy takie osoby (pomijając inne pytania oraz poproszenie o zrobienie zadania rekrutacyjnego). Nie oznacza to, że nie możecie zachwycić potencjalnych pracodawców innymi wpisami w CV, jednak nie oszukujmy się - napisanie, że swoją znajomość JavaScriptu oceniacie na 10/10 nie jest wymierne, za to bardzo, ale to bardzo subiektywne i może się okazać, że Wasza "dziesiątka" jest "dwójką" u danej firmy. Dlatego to portfolio pokazuje, co rzeczywiście umiecie i z czego jesteście dumni. A samo przygotowywanie projektów, aby móc je pokazać, pozwala się rozwinąć i zmusza do poznawania nowych rzeczy.

Pozdrawiam i dziękuję - Jakub Rojek.

PS. Tak zupełnie na boku - pozdrawiam wszystkich, którzy aplikując na stanowisko programisty piszą w umiejętnościach "zaawansowana obsługa komputera".

]]> Dlaczego nie należy podawać hasła obsłudze serwisu? https://wildasoftware.pl/post/dlaczego-nie-nalezy-podawac-hasla-obsludze-serwisu?ref=rss https://wildasoftware.pl/post/dlaczego-nie-nalezy-podawac-hasla-obsludze-serwisu?ref=rss Thu, 10 Aug 2023 17:30:00 +0000 Nie ukrywam, że tytuł tego artykułu jest trochę prowokacyjny, być może nawet clickbaitowy. Ale pełny tytuł, który brzmiałby "O haszowaniu haseł słów kilka, czyli dlaczego nie powinieneś(-naś) podawać swojego hasła, gdy prosi o nie Twój administrator lub dział wsparcia", byłby nie tylko mało atrakcyjny, ale też zwyczajnie nie zmieściłby się na "łamach" blogu. Z drugiej strony, dokładnie opisywałby cel dzisiejszego tekstu, a także zapowiadałby pewien przekaz społeczny. Rzeczywiście, większość z nas wie, że nie wolno podawać swojego hasła konsultantowi czy nawet członkowi działu technicznego i większość domyśla się, dlaczego (a w razie, gdyby jednak nie - chodzi o groźbę utraty konta). Ale nie każdy z nas wie, dlaczego w ogóle ci konsultanci mogą nas o to pytać i to w dobrej wierze. A także dlaczego administratorzy w sumie sami nie odzyskają tej informacji z bazy serwisu.

Jak przechowywane są hasła w systemach informatycznych?

Aby odpowiedzieć sobie na to pytanie, musimy wiedzieć, w jaki sposób hasła są zapisywane w bazie danych, oczywiście, zakładając, że dany serwis uwierzytelnia użytkowników właśnie poprzez podanie takiego "sekretu". Jak się pewnie spodziewacie, nie są one zapisywane w formie jawnej, czyli za pomocą tzw. plain text. Oczywiście, taka forma przechowania danych byłaby najprostsza oraz najszybsza przy sprawdzaniu hasła po wpisaniu go przez użytkownika, jednak nie usprawiedliwia to zagrożenia, które powstaje, gdy do bazy dostanie się nieuprawniona osoba. Wówczas dane do logowania byłyby widoczne jak na dłoni.

Dlatego hasła użytkowników zapisywane w bazie danych muszą być kodowane i tutaj mamy do czynienia z podejściem odwracalnym oraz nieodwracalnym. Pierwsze zakłada, że każde hasło jest transformowane przez pewien algorytm, który zamienia jeden ciąg znaków na inny tak, aby później można było to odwrócić. Przykładem jest słynny szyfr Cezara, który polega na przesunięciu każdego znaku o określoną liczbę. Idąc typ tropem i znając wartość tego przemieszczenia, można odwrócić działanie i poznać oryginalną wiadomość. Z jednej strony jest to lepsze niż plain text, gdyż faktycznie hasła zapisane w systemie są nieczytelne na pierwszy rzut oka. Z drugiej - to zabezpieczenie jest bardzo słabe, gdyż atakujący zacznie szukać w kodzie sposobu obsługi haseł i jeśli znajdzie takie coś, to może zrobić wszystko. Dlatego odwracalną metodę kodowania stosuje się tylko i wyłącznie w przypadku, kiedy jest to naprawdę konieczne, ale może byłoby to 0,01% wszystkich sytuacji.

Dlatego zdecydowanie lepsze jest używanie szyfrowania nieodwracalnego i stosowanie tzw. funkcji skrótu, znanych lepiej pod nazwą funkcji haszujących. Działają one w taki sposób, że pewnej grupie tekstów przydzielają pewien skrót tekstowy. Tego typu algorytmy przydają się przy indeksowaniu danych i przyspieszeniu ich wyszukiwania, jednak nas najbardziej interesuje ich zastosowanie w bezpieczeństwie. Jedną z najprostszych funkcji skrótu jest MD5, który tworzy hasz składający się z liczb szesnastkowych. Przykładowo, ta metoda dla hasła TajneHaslo123 wygeneruje skrót d51472b37f8b58be359ac086c639a7da. Co jednak ważne, mimo że za tym stoi pewien algorytm, to ten kod wygląda na przypadkowy. Na tyle, że dla podobnego hasła TajneHaslo124 hasz to c4eaabcaea5623eceda71955d42943a6, a więc zupełnie inny niż dla poprzedniej danej wejściowej. Co więcej, może istnieć inne hasło, które "przypadkiem" zyskałoby identyczny skrót, co oznacza, że próba rozszyfrowania niezrozumiałego ciągu znaków nic nie da atakującemu. Aczkolwiek uspokajam - szanse, że traficie w dwóch różnych danych na identyczny hasz są dość małe.

Tym niemniej, MD5 jest dość słabym algorytmem do haszowania haseł i zdecydowanie bardziej użyteczny jest w porównywaniu informacji, gdzie zależy nam np. na unikalnym identyfikowaniu obiektów i właśnie ich wyszukiwaniu. Natomiast łamanie haszy zapisanych przez MD5 jest na tyle proste dla obecnych komputerów, że przechowywanie w tej formie danych uwierzytelniających jest bardzo niebezpieczne i niepolecane. Istnieją o wiele lepsze metody typu SHA3 czy bardzo popularny bcrypt. Po użyciu pierwszej (dokładniej w wersji SHA3-256) nasze hasło TajneHaslo123 uzyska skrót:

1da9221b1fbe5a91e90ccd84ff994823c7c4a9d235044a504b5eb1936b0283aa

natomiast po użyciu drugiej:

$2a$13$qxKekEVlvm4ugIbxLK/Jf.JHdUmdHmyZbakTPvER0XokIOmhEG7Rm

A i nie jest to jedyna możliwość ze względu na wiele odmian tej metody oraz użytą "sól" (ang. salt), a więc dodatkowy środek maskujący.

Cechą wspólną takich zabiegów jest fakt, że nie tylko pozwalają one zapisać hasło użytkownika w nieczytelnej formie, ale też nie istnieje algorytm odwracający je do postaci oryginalnej, zwłaszcza, że jako skrót są "urywane" w pewnym momencie. Dotyczy to nie tylko człowieka z "kalkulatorem" i wiedzą o działaniu danej metody, ale też komputera. Proces logowania wygląda zatem tak, że to, co wpisze użytkownik przy wchodzeniu do systemu, jest haszowane, a następnie ten hasz porównywany jest z zapisanym w bazie danych. Jeśli są one zgodne - następuje zalogowanie. Przy czym należy pamiętać, że porównanie nie oznacza całkowitej równości i w zależności od metody może to wyglądać trochę inaczej.

Jak zatem atakujący może uzyskać hasło, skoro nie może go odtworzyć z hasza? Nawet nie próbuje tego robić - zamiast tego może:

  • próbować różnych haseł z możliwego zestawu sekretów i liczyć na to, że w końcu trafi (tzw. brute force),
  • stosować tzw. tęczowe tablice, który oszczędzają moc obliczeniową i czas oraz wykorzystują powtarzalność haszy,
  • próbować uzyskać dostęp do poczty elektronicznej ofiary i zmienić hasło w serwisie,
  • zastosować atak socjotechniczny, skłaniając ofiarę do dobrowolnego podania hasła.

Temat jest bardzo szeroki (szczególnie jeśli chodzi o socjotechnikę), jednak nie jest on tematem tego artykułu.

Dlaczego ktoś może chcieć nasze hasło?

Oczywiście, podstawowy powód, który każdemu (słusznie) przyjdzie do głowy, to próba włamania. Świat widział wiele "ataków" polegających na tym, że osoba udająca konsultanta przekonała ofiarę, żeby ta łatwo udostępniła mu dostęp do serwisu. Dlatego praktycznie nigdy nie podawajcie swojego hasła obcej (a nawet i nieobcej) osobie do swojego konta w serwisie. I teraz pora wyjaśnić, dlaczego prawdziwy konsultant lub pracownik działu wsparcia często takich danych nie potrzebuje (prędzej zostaniemy poproszeni telefonicznie o "kod bezpieczeństwa" w celu dalszej rozmowy z help deskiem) lub odwrotnie - kiedy może potrzebować.

Jeśli komunikujemy komuś problem z systemem lub potrzebujemy czegoś od działu wsparcia, to gwarantuję Wam, że specjalista po drugiej stronie - w zależności od poziomu uprawnień i narzędzi - ma możliwość znalezienia Waszych danych nawet bez posiadania hasła. Wynika to oczywiście z dostępu do bazy danych lub specjalnych paneli administracyjnych, które ułatwiają wyszukanie i wyświetlenie pewnych informacji jedynie uprawnionym osobom. Tak naprawdę administratorzy i programiści zazwyczaj, mówiąc m.in. o użytkownikach, posługują się identyfikatorami bazodanowymi, adresami e-mail lub innymi unikalnymi danymi. Oczywiście, z zapewnieniem pełnej dyskrecji i ochrony danych, ale nadal bez dostępu do informacji uwierzytelniających.

Bowiem nawet, gdyby programista czy administrator stanęli na głowie, to nie zobaczą haseł użytkowników w czystej formie. Powodem jest wcześniej omawiane haszowanie i to, że takiego hasza nie można przełożyć na oryginalny kod. Jedyne miejsce, gdzie teoretycznie można zobaczyć przesyłane dane, to podgląd żądań przesyłanych w przeglądarce (tuż po naciśnięciu "Zaloguj się" i podaniu danych) lub w logach serwera. Jednak z pierwszym przypadku ta droga jest (a przynajmniej powinna) być zabezpieczona poprzez protokół HTTPS, a w drugim - takie informacje powinny być wyłączone z zapisywania w logach serwera. To wszystko też wyjaśnia, dlaczego opcja "przypomnij hasło" nie działa tak, że faktycznie przypomina hasło - zamiast tego przesyła nowo wygenerowany tymczasowy kod lub przenosi do formularza zmiany hasła z odpowiednim tokenem (również zabezpieczającym przed złośliwymi agresorami). Jeśli kiedykolwiek serwis w reakcji na użycie opcji "przypomnij hasło" prześle Wam hasło przypominające Wasze, to bardzo polecam przestać korzystać z takiego portalu, gdyż z dużą dozą prawdopodobieństwa Wasze dane uwierzytelniające są w niebezpieczeństwie.

To nie znaczy, że nie ma sytuacji, w której obsługa serwisu nie potrzebuje Waszych haseł. Istnieją bowiem zgłoszenia, których nie sposób odtworzyć inaczej niż logując się na dane konto i mając przed oczami to, co ma użytkownik. Kiedyś na potrzeby takich sytuacji implementowało się dostępny dla administratora przycisk "Zaloguj jako...", który automatycznie pozwalał wejść na konto danej osoby. Jednak to rozwiązanie budzi wątpliwości pod kątem RODO, a ponadto wymaga określonego sposobu obsługi procesu uwierzytelniania, który z kolei jest możliwy przy określonej strukturze aplikacji. Dlatego najczęściej procedura w takich sytuacja wygląda tak, że po uzyskaniu zgody od użytkownika (koniecznie!), obsługa serwisu zamienia hasło na znane tylko sobie po czym prosi o jego ustawienie na nowo lub ewentualnie przywraca poprzedni hasz. Nadal bez znajomości oryginalnego hasła. Oczywiście, zawsze jest też opcja skorzystania z TeamViewera lub RustDeska i podejrzenia na żywo, co użytkownik może zobaczyć na ekranie, ale wówczas odbiorca musi być absolutnie pewien, że oddaje kontrolę właściwej osobie.

Czy istnieje alternatywa dla haseł?

Owszem, istnieją serwisy, w których hasła nie są potrzebne lub nie stanowią jedynej formy logowania. Przykładem są tzw. hasła jednorazowe lub tokeny, które są generowane na pewien krótki czas i przesyłane poprzez pocztę elektroniczną bądź SMS-em. Podobnie zresztą działa uwierzytelnianie dwuskładnikowe (2FA), które zawsze warto ustawiać w ważnych dla nas serwisach. Inną drogą jest biometria, czyli wykorzystanie odcisku palca, skanowania twarzy lub tęczówki. Jednak te rozwiązania, mimo że są już stosowane, budzą pewne wątpliwości pod kątem prywatności i dostępu do naszych danych osobowych lub wykorzystania wizerunku. Wreszcie, istnieje jeszcze opcja logowania się poprzez klucze SSH, jednak jest ona wykorzystywana raczej w specyficznych usługach i przez bardziej techniczne osoby.

Podsumowanie

Jak widać, wyciek hasła z bazy danych wcale nie musi oznaczać, że nasze dane uwierzytelniające są dostępne dla przestępców, co jednak też nie oznacza, że nie należy się mieć na baczności. Jeśli ktoś chce nam pomóc w problemie w serwisie, to praktycznie nigdy nie będzie potrzebował do tego hasła, a co najwyżej dobrej woli i współpracy z obu stron. Dlatego przyjmijmy zasadę, że nigdy nie ujawniamy naszych haseł, o ile nie jest to absolutnie koniecznie i nie dotyczy bliskiej nam osoby.

Jednocześnie nie należy się bać opcji przypomnienia hasła i tutaj mogę podać przykład z naszego podwórka - zmiana biblioteki do haszowania w Feedybacky, która wynikała z aktualizacji oprogramowania na serwerze, spowodowała, że użytkownicy musieli jeszcze raz ustawić swoje hasła. Nie mogliśmy tego zrobić automatycznie z uwagi na to, że... tych haseł nie znamy i nigdy nie poznamy. Także możecie się czuć spokojni.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Przydatne komendy na serwerze z Linuxem https://wildasoftware.pl/post/przydatne-komendy-serwerze-linuxem?ref=rss https://wildasoftware.pl/post/przydatne-komendy-serwerze-linuxem?ref=rss Thu, 03 Aug 2023 17:30:00 +0000 Wiemy o tym, że na serwerach dla aplikacji w dużej mierze instalowany jest system operacyjny Linux, który pod wieloma względami różni się od znanego prawie wszystkim Windowsa. Odnalezienie się w mechanizmach spod znaku pingwina nie dla wszystkich jest łatwe i osoby niedoświadczone różnie reagują na fakt, że muszą z nim mieć styczność. Niektórzy przyjmują postawę, że będą mieli okazję się czegoś nauczyć, a innych paraliżuje ze strachu, gdyż boją się, że każdy ich błąd będzie miał poważne konsekwencje. Jeszcze inni nie boją niczego i nie czytają dokumentacji, przez co faktycznie potem te poważne konsekwencje się ujawniają.

Tym niemniej, co jakiś czas staramy się Was przekonać, że Linux i środowisko serwerowe w podstawowym zakresie naprawdę nie są takie trudne, a ich znajomość choćby w fundamentalnych sprawach naprawdę się przydaje. Jest to wiedza, którą można wykorzystać nie tylko w pracy, ale też w projektach domowych czy przy próbie zrozumienia bardziej złożonych problemów, co przynosi okazję do rozwoju. Czasem naprawdę wystarczy umiejętność poruszania się po folderach, uruchomienie skryptu, zrestartowanie usługi, skopiowanie pliku i inne operacje, których poznanie nie wymaga dużo pracy, a już można w ten sposób dużo osiągnąć.

Aczkolwiek czasem trzeba ciut więcej i dzisiaj właśnie tym się zajmiemy. Pokażemy sobie parę komend, które mogą nie być na początku intuicyjne lub są na tyle złożone, że nie zawsze człowiek pamięta ich składnię i musi szukać w dokumentacji lub na forach. Jednocześnie, nie są to operacje, które są zarezerwowane dla administratorów - bo trudno nazwać takimi np. spakowanie plików czy przesłanie go z serwera do lokalnego komputera. Jednak nie wykonuje się ich codziennie, więc nie utrwaliły się w pamięci, a czasem się po prostu przydają. Spróbujemy dzisiaj krótko omówić parę takich komend, zdecydowanie skupiając się na praktyce i przez to upraszczając wiele aspektów. Warto zauważyć, że wiele z poniższych kwestii można w Windowsie przetrenować za pomocą choćby WSL-a.

Pakowanie i rozpakowywanie plików

Zaskakująco często pojawia się problem przy obsłudze plików archiwum w linii komend. Rzeczywiście - wymaga to zapamiętania określonej kolejności parametrów czy przełączników lub ciągłego zaglądania do manuala. Tym niemniej, warto się tego nauczyć lub gdzieś zapisać obok monitora, ponieważ przy kopiowaniu dużej ilości plików na lub z serwera naprawdę warto robić to w postaci zarchiwizowanych paczek. Kto często kopiuje w ten sposób tysiące plików, ten wie, o czym mowa.

Najczęściej spotykamy się z dwoma formatami - .zip oraz .tar.gz (lub .tgz zwany też tarballem). Ten pierwszy jest wygodniejszy, jednak wymaga zainstalowania na serwerze programów zip oraz unzip, a nie zawsze są one dostępne. Polecenia do obsługi drugiego formatu są dostępne wszędzie, aczkolwiek kształt zapytania jest mniej intuicyjny na pierwszy rzut oka.

Składnia komendy zip to w ogólności zip [opcje] nazwa_pliku.zip pliki_do_spakowania. W najprostszym przypadku, chcąc spakować wszystkie pliki w aktualnym folderze, zrobimy to tak:

zip test.zip *

Oczywiście, zamiast gwiazdki możemy podawać konkretne pliki lub foldery po spacji, choć uwaga - w tym drugim przypadku należy użyć opcji -r oznaczającą rekursywne przeszukiwanie podfolderów.

zip -r test.zip a.txt dir

Przydatne mogą być też komendy umożliwiające spakowanie wszystkiego z wyłączeniem konkretnych pozycji oraz spakowanie z hasłem (po wykonaniu komendy zostaniemy poproszeni o jego podanie).

zip -r test.zip * -x fileToIgnore.txt -x dirWithContentToIgnore/*
zip -e test.zip *

Aby rozpakować takie archiwum, najprościej jest wykonać komendę unzip test.zip, jednak to utworzy zawartość w tym samym folderze, w którym się znajdujemy (niekoniecznie tam, gdzie jest sam plik). Aby jawnie wskazać katalog docelowy, należy wykorzystać przełącznik -d:

unzip test.zip -d folderDoRozpakowania

Tak to wygląda dla rozszerzenia .zip. A jak jest w przypadku .tar.gz (.tgz)? Poniżej wszystkie powyższe komendy, jednak właśnie w wersji tarballowej:

tar cvfz test.tar.gz *
tar cvfz test.tar.gz a.txt dir # zwróćcie uwagę, że nie trzeba używać "-r" przy folderach
tar --exclude fileToIgnore.txt --exclude dirWithContentToIgnore cvfz test.tar.gz *
tar xvfz test.tar.gz
tar xvfz test.tar.gz -C folderDoRozpakowania # uwaga: folder musi wcześniej istnieć

Pewien problem pojawia się przy próbie nadania hasła archiwum, gdyż tarball nie ma wbudowanej takiej możliwości. Można wówczas zaszyfrować plik za pomocą narzędzia GPG i komendy gpg -c test.tar.gz.gpg test.tar.gz.

Wypada jeszcze wyjaśnić, co oznaczają te dziwne symbole przy komendzie tar. Poniżej wyjaśnienie poszczególnych opcji:

  • c - utworzenie archiwum.
  • x - rozpakowanie archiwum.
  • z - wykorzystanie Gunzipa, a więc uczynienie z .tar archiwum .tar.gz, stosującego kompresję.
  • v - od verbose, a więc wyświetlenia logu z operacji, w tym też przetwarzanych plików.
  • f - wskazanie nazwy pliku z utworzonym archiwum.

Przesyłanie plików przez SCP

W większości przypadków, chcąc przesłać pliki do serwera dostępnego przez SSH lub przeciwnie - pobrać z niego - korzystamy z programów graficznych pokroju WinSCP czy terminali z obsługą GUI, jak MobaXterm. Jednak czasem nie jest to możliwe lub staje się znacznie utrudnione poprzez konkretną metodę wejścia na taki serwer. W takim przypadku niektórzy nie bardzo wiedzą, w jaki sposób wówczas wczytać pliki. Czasem próbują pobrać z zewnętrznego źródła poprzez wget, inni zwyczajnie przepisują zawartość lub wklejają ją w edytor (przy okazji - czasem wystarczy po prostu zaznaczyć tekst, aby go skopiować i nacisnąć prawy przycisk myszy, aby wkleić). A przecież istnieje prostszy sposób - poznajcie polecenie scp.

Podobnie jak ssh, także scp pozwala połączyć się poprzez port 22, jednak nie służy do zalogowania się lub wykonania zdalnie określonej komendy - scp daje możliwość transferowania plików pomiędzy takim serwerem a naszą maszyną lub innym serwerem. Budowa jest prosta:

scp ścieżka/do/pliku user@serwer:folder/na/serwerze
scp user@serwer:folder/na/serwerze/plik ścieżka/do/folderu

W pierwszym przypadku wysyłamy plik na serwer, a w drugim - pobieramy z niego. Spójrzmy na praktyczny przykład, gdzie naszym użytkownikiem na serwerze jest "ubuntu", adres IP to 192.168.100.31, a plik "plik.txt" chcemy umieścić w folderze domowym w podkatalogu "backup". Zakładamy, że ten folder już istnieje.

scp plik.txt ubuntu@192.168.100.31:~/backup

I już. W ten sposób możemy też przesyłać całe foldery, o ile nie zapomnimy o przełączniku -r.

scp -r folder/* ubuntu@192.168.100.31:~/backup

Podobnie sprawa wygląda, gdy chcemy pobrać plik na dysk - w tym przypadku będzie to "plik.txt", który zapiszemy u nas jako "plik_z_serwera.txt".

scp ubuntu@192.168.100.31:~/backup/plik.txt plik_z_serwera.txt

Z pewnością zauważyliście, że kluczowa jest kolejność argumentów - na pierwszym miejscu jest miejsce, z którego plik lub folder jest wysyłany, a jako drugi zostaje podany odbiorca. Jeśli jednym z tych punktów jest zewnętrzny serwer, należy podać użytkownika, znak "@", adres serwera (domenowy lub IP), a następnie po dwukropku ścieżkę, która nas interesuje. Warto zauważyć, że na serwerze musi istnieć dana ścieżka i co więcej - terminal nie podpowie nam jej po naciśnięciu klawisza TAB. Dodatkowo, jeśli połączenie z serwerem wymaga podania jawnie klucza prywatnego (-i klucz.key), to również musimy dodać to do komendy scp, tak jakbyśmy korzystali z ssh.

Sprawdzanie miejsca na dysku

Maszyny serwerowe oferują pewną przestrzeń dyskową, która może się zapełnić - to oczywiste. Problem pojawia się wtedy, kiedy nagle zabrakło miejsca, a trzeba szybko zobaczyć, co tyle zajmuje, aby odzyskać trochę megabajtów. Najczęściej są to kryzysowe sytuacje (np. klient zgłasza, że nie może się zalogować do aplikacji lub przesłać żadnego pliku) i jeśli nie umiemy wówczas tego poprawnie zrobić, to trochę się pomęczymy. Pomijam standardowe wylistowanie plików z danego folderu wraz z m.in. rozmiarem poprzez komendę ls -l - to pozwala uzyskać nam pewien obraz sytuacji, ale tylko w kontekście danego katalogu.

Nas będzie bardziej interesować polecenie df -H, które pokaże rozmiar poszczególnych dysków, wolne i zajęte miejsce oraz procent zajętości. W ten sposób łatwo się zorientować w tym, czy zabrakło miejsca - jeśli w głównym dysku "Use%" stanowi 100%, to oznacza, że trzeba się czegoś pozbyć lub dołożyć pojemności. To polecenie pochodzi od "disk free" i "human readable" - można też zamienić ostatni parametr na "-h", aby pokazać wartości podzielone przez 1024, a nie 1000.

Warto zaznaczyć, że df skupia się na partycjach, co nie jest szczególnie użyteczne, gdy chcemy dowiedzieć się, który folder zajmuje tyle miejsca. Wówczas bardziej skłonimy się ku poleceniu du, które wykonane w odpowiednim folderze wypisze nam wszystkie podfoldery i pliki wraz z informacją o rozmiarze. Niestety, zrobi to w bardzo nieczytelnej formie, a w przypadku dużej liczby plików dostaniemy po prostu niekończący się wypis, który uniemożliwi nam szybką reakcję poza kombinacją CTRL + C.

Dlatego jeszcze bardziej warto zapamiętać taką komendę:

du -h --max-depth 1

Wypisze nam ona zajętość na dysku nie tylko w skróconym formacie (choć przy porównywaniu liczb czasem warto jednak zrezygnować z przełącznika "-h"), ale także tylko następnych podfolderów na konkretnej głębokości. Oznacza to, że jeśli folder, w którym się znajdujemy, zawiera katalogi X, Y i Z, a katalog X zawiera X1 oraz X2, katalog Y ma w sobie Y1 i Y2, to zobaczymy tylko zajętość X, Y i Z. Słowem - na tej podstawie możemy ocenić, który folder opłaca się dalej analizować, gdyż jest największy.

Jak się pewnie domyślacie, zmiana parametru --max-depth z 1 na 2, 3 itd. pogłębi informacje dotyczące poszczególnych podfolderów. Z drugiej strony ustawienie tego atrybutu na 0 lub zmienienie go na -s (du -hs) pokaże jedynie łączną zajętość całego folderu, co również może być czasem przydatne. Przypomina to wywołanie "Właściwości" na katalogu w systemie Windows - zobaczymy totalny rozmiar, razem z jego podfolderami i plikami.

Na uwagę zasługuje także to, że po dodaniu opcji --time uzyskamy czas ostatniej modyfikacji danego pliku lub folderu, a w ogóle możemy też wskazać ręcznie folder, dla którego chcemy obliczyć rozmiar - nie jesteśmy ograniczeni do katalogu, w którym aktualnie się znajdujemy.

du -h --max-depth 1 --time innyFolder

Szukanie plików i ich zawartości (find i grep)

Wyszukiwanie czegokolwiek na dysku często jest potrzebne, szczególnie, jeśli trafiamy na maszynę, o której nie mamy pojęcia, gdzie co się znajduje, jak np. serwer z aplikacją tworzoną przez inny zespół. Równie często interesuje nas nie tyle plik, co jego zawartość, gdyż wiemy, że tam znajduje się coś, czego szukamy (np. konfiguracja dostępu do bazy danych). Jak sobie wówczas poradzić? Większość dobrze wie, że istnieją polecenia find oraz grep, ale zdarza się, że jest problem z ich wykorzystaniem.

Powiedzmy, że jesteśmy w katalogu, w którym chcemy wyszukać wszystkie pliki z rozszerzeniem .xlsx. Jak to zrobimy?

find . -name '*.xlsx'

Po nazwie polecenia podajemy lokalizację, w której chcemy zacząć wyszukać. W naszym przypadku będzie to kropka, a więc aktualny katalog, w którym się znajdujemy. Jeśli zupełnie nie wiemy, gdzie coś się znajduje, w tym miejscu wstawimy zapewne slash (/), jednak musimy zdawać sobie sprawę z tego, że wyszukiwanie może potrwać bardzo długo.

Później czeka nas podanie wytycznych - u nas będzie to -name (zwracam uwage na pojedynczy myślnik), po którym następuje szablon nazwy wykorzystujący wzorzec regularny. Oczywiście, jeśli znamy dokładną nazwę pliku, to możemy spróbować wpisać ją bezpośrednio, bez żadnych gwiazdek imitujących dowolny ciąg znaków. Sam parametr -name nie jest jedyną opcją - jak się pewnie spodziewacie, można wyszukiwać po tym, czy jest to plik, czy folder (-type), nie zwracać uwagę na wielkość liter (-iname), wziąć pod uwagę czas ostatniej modyfikacji (-mtime -liczbadni), a także m.in. rozmiar (-size). Możliwości jest bardzo dużo, a same warunki można łączyć, także poprzez alternatywę. Wiele informacji i praktyczne przykłady znajdziecie pod tym linkiem.

Jeszcze jedna mała uwaga - przy przeszukiwaniu całego systemu plików często będziemy napotykali na komunikaty typu "permission denied", co jest zrozumiałe - zazwyczaj nie mamy uprawnień do odczytu wszystkich folderów, więc przy przeszukiwaniu ich Linux posłusznie poinformuje, że ich nie przejrzymy, bo nie. Jeśli takich uwag jest dość dużo, może być to męczące, jednak istnieje sposób, aby się ich pozbyć. W tym celu można wykorzystać "plik-pustkę" /dev/null (zresztą niekiedy występujący w informatycznych memach) i przekierować do niego tzw. wyjście błędu. Zdaję sobie sprawę, że dla niektórych brzmi to jak czarna magia, jednak wytłumaczenie tego w pełni wymagałoby podjęcia tematu standardowych wyjść, a to nie jest celem tego tekstu. Po więcej informacji odsyłam do tej strony.

find / -name '*.xlsx' -print 2>/dev/null

Jednak chyba częściej będziemy chcieli przeszukać zawartość plików za pomocą polecenia grep. Zacznijmy od prostego przypadku - załóżmy, że chcemy znaleźć słowo "zadanie" w konkretnym pliku i nie interesuje nas wielkość znaków. Użyjemy wówczas polecenia:

grep -i 'zadanie' plik.txt

Warto zauważyć, że nawet, jeśli słowo "zadanie" występuje jako element innego ciągu, to również zostanie znaleziony. Jeśli tego nie chcemy, warto użyć przełącznika -w. Trzeba też pamiętać, że narzędzie szuka po tekstowej zawartości plików - nie odnajdziemy w ten sposób ciągów w plikach binarnych.

To teraz przeszukajmy folder "arkusze" pod kątem ciągu "Ania" wraz z wypisaniem pliku oraz numerem wiersza:

grep -rn 'Ania' arkusze

Jeśli jakieś polecenie zwraca zawartość pliku (np. cat), to możemy je również wykorzystać jako bazę do przeszukania go pod kątem zawartości, wykorzystując tzw. pipe'y:

cat /proc/cpuinfo | grep -i 'Model'

W przypadku obu omawianych tutaj komend, wyników może być tak wiele, że trudno będzie je zmieścić na ekranie. W takim przypadku warto skorzystać z przekierowania rezultatu do określonego pliku:

grep -rn 'Ania' arkusze > output.txt

Bardzo wiele przykładów użycia komendy grep znajdziecie pod tym linkiem.

Usuwanie plików starszych niż X dni

Skoro już jesteśmy w temacie wyszukiwania plików według różnych kryteriów, to warto wspomnieć o możliwości usuwania takich, które zostaną znalezione. W tym momencie niektórzy przypomną, że przecież do kasowania plików służy polecenie rm, ale nie do końca umożliwia ono podanie wszystkich potrzebnych nam parametrów. Na szczęście, z pomocą przychodzi nam przed chwilą omówiony find - zobaczmy, jak możemy usunąć wszystkie pliki z kopią zapasową bazy SQL starsze niż 100 dni.

find backups/ -name "backup_*.sql" -type f -mtime +100 -delete

Kluczowy jest tutaj parametr -mtime, który pozwala odfiltrować pliki po wieku (zakładamy, że zrobienie kopii zapasowej to jednocześnie jej ostatnia modyfikacja), a także parametr -delete. Nie muszę chyba mówić, że przez to, iż ta komenda jest tak potężna, należy bardzo uważać z jej wywoływaniem?

Wyświetlenie części pliku

Czasem chcemy wszystko wyświetlić określony plik. Służy do tego polecenie cat, które zwyczajnie pokazuje zawartość na ekranie. Przykład:

cat plik.txt

Jednak problem polega na tym, że w przypadku bardzo długiego tekstu nasz terminal zostanie nim po prostu "zalany". Można to rozwiązać na różne sposoby, jak np. zamianę polecenia cat na more lub less, które pozwalają przesuwać się po pliku, w ten sposób stopniowo go przeglądając. Jest to również użyteczne przy plikach tak długich, że stanowią wyzwanie dla stabilności systemu (choć tutaj przydaje się również Vim). Jednak równie użyteczną komendą w przypadku długiej zawartości może być tail, który pozwala wyświetlić N ostatnich wierszy. Przykład dla 50 linii:

tail -n 50 /var/log/apache2/error.log

Użycie w przykładzie pliku z logiem nie jest przypadkowe - to właśnie w nich najczęściej interesują nas ostatnie linijki, gdy szukamy błędu, który przed chwilą wystąpił.

Lista aktywnych procesów

Bywa, że chcemy sprawdzić, jakie procesy są uruchomione na serwerze, aby np. upewnić się, że dane zadanie wystartowało i działa. W podstawowej wersji możemy użyć do tego polecenia ps, jednak w wielu przypadkach jest ono niewystarczające i warto dopisać dodatkowe trzy przełączniki, tworząc ps alx. Na takiej liście możemy zobaczyć nie tylko polecenia, które są wykonywane, ale też m.in. PID (ID procesu) czy status (np. czy uruchomiony, zatrzymany).

Istnieje jeszcze możliwość, która pokazuje również procent użycia procesora oraz pamięci - tutaj może się przydać ps aux, ale ciekawsze jest top. To drugie ma tę świetną cechę, że pokazuje listę procesów w sposób dynamiczny, pozwalając obserwować, jak się zmienia w czasie. Może być to bardzo ciekawe przy badaniu problemów wydajnościowych serwera lub operacji, które go blokują. Wyjść z tego okna można poprzez naciśnięcie klawisza "q". A jeśli ktoś potrzebuje czegoś ciut ładniejszego, to może dodatkowo doinstalować htop.

Załóżmy, że istnieje proces, który zakłóca działanie systemu i chcemy go zakończyć w najbardziej brutalnej formie - poprzez wysłanie sygnału KILL, dostępnego również pod kodem 9. Aby to zrobić, musimy znać PID danego zadania, co możemy odczytać poprzez jedną z poprzednich komend. Wówczas wiedząc, że interesujący nas proces znajduje się pod PID-em 6789 możemy wywołać:

kill -9 6789

Zdarzają się jednak sytuacje, w których problem dotyczy wielu podobnych procesów o takiej samej nazwie. Przykładem może być interpreter PHP-a, który uruchomił się 40 razy i we wszystkich przypadkach się zawiesił lub zakleszczył. Wówczas nie tyle interesuje nas PID, co nazwa procesu i polecenie killall. Przykładowo, dla zatrzymania php-fpm byłoby to:

killall -9 php-fpm

Oczywiście, także w tym przypadku należy zachować daleko idącą ostrożność.

Sprawdzenie aktywnych portów

Czasem chcemy zobaczyć, na których portach nasłuchuje nasz serwer, aby potwierdzić, że jakaś usługa sieciowa została uruchomiona. Wbrew pozorom, to pozornie proste zadanie potrafi czasem sprawić trochę kłopotów ze względu na to, że w różnych systemach zachowuje się to nieco inaczej. Najczęściej weryfikacji można dokonać poprzez:

netstat -anp tcp

co ukaże wszystkie procesy działające pod portami TCP wraz z numerem portów i informacją, czy nasłuchują. W przypadku długiej listy można posłużyć się wspomnianym wcześniej poleceniem grep:

netstat -anp tcp | grep LISTEN

A żeby ułatwić sobie zadanie, zawsze można spróbować wykryć otwarte porty na zewnątrz poprzez odpowiednie programy czy telnet.

Podsumowanie

W żaden sposób nie wyczerpaliśmy tematu. Zdaję sobie też sprawę, że administratorzy systemów linuksowych patrzą na ten artykuł z niesmakiem, gdyż takie rzeczy, a nawet trudniejsze, robią codziennie i to z zamkniętymi oczami. Tym niemniej, wiemy, że nie dla wszystkich są one oczywiste i takie ściągi bywają potrzebne. Nie zawsze mamy do dyspozycji graficzne narzędzia i interfejsy, które część pracy wykonają za nas - bywa, że jedyną drogą staje się linia komend. Dlatego warto ją poznawać i przestać sie jej bać. A przy okazji rozwijać swoją znajomość systemów unixowych, gdyż informatykowi na pewno to nie zaszkodzi, a może się przydać.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Kiedy warto napisać projekt od nowa? https://wildasoftware.pl/post/kiedy-warto-napisac-projekt-nowa?ref=rss https://wildasoftware.pl/post/kiedy-warto-napisac-projekt-nowa?ref=rss Thu, 27 Jul 2023 17:30:00 +0000 Projekty informatyczne rodzą się i rozwijają w różny sposób. Niektóre są zaplanowane od początku do końca i rzeczywiście ten plan jest cały czas realizowany. W zdecydowanie większej liczbie przypadków zespół spotyka różne zakręty po drodze, do których można zaliczyć np. nadmiernie zbliżającą się datę wykonania, wymagania zmienione "w locie" czy brak uwzględnienia określonego przypadku przy planowaniu architektury. Jednak w takich sytuacjach zazwyczaj pomaga regularna refaktoryzacja, która wyprostuje kod w spokojniejszym czasie. Niestety, dobrze wszyscy wiemy, że bywają też projekty, w których różne zdarzenia doprowadzają do tego, że po pewnym czasie programiści coraz śmielej mówią o napisaniu projektu od nowa. Równie śmiało kierownik projektu mówi wówczas "ale skąd".

W jaki sposób można poznać, że oprogramowanie rzeczywiście wymaga napisania go od nowa, a kiedy jest to tylko fanaberia i frustracja programistów? Czy są w ogóle takie sytuacje, kiedy po wielu latach kod rzeczywiście nadaje się do zaprojektowania i realizacji od początku? Na pierwsze pytanie będziemy starać się odpowiedzieć niżej, natomiast na drugie możemy odpowiedzieć od razu - tak, jak najbardziej istnieją takie przypadki. Tym niemniej, tylko mały procent z nich rzeczywiście doczeka się ponownej realizacji i - jak się pewnie domyślacie - przyczyny leżą w biznesie.

Co sprawia, że projekt wymaga restartu?

Wiele osób na to pytanie zapewnie odpowie, że wystarczającym argumentem jest brzydki kod, pełen przykrych zapachów. Jednak nie jest to prawdą - nie każdy paskudny kod nadaje się do przepisania całego oprogramowania od nowa. A przynajmniej nie w warunkach biznesowych, które koniecznie trzeba uwzględnić w swoich planach i jakie najtrudniej wytłumaczyć tzw. technologicznych pistoletom, wołający jako pierwsi o restart projektu, bo to po prostu frajda. I tak, przyznaję - tworzenie architektury i rozpoczynanie czegoś od nowa, z nadzieją na lepszą przyszłość, to rzeczywiście frajda, ale niekoniecznie właściwe rozwiązanie.

Po pierwsze, należy zidentyfikować, gdzie są tak naprawdę problemy z kodem. Na tym etapie często okazuje się, że dotyczą one tylko konkretnych fragmentów oprogramowania lub ujawniają się w określonych momentach. W takim przypadku nie ma sensu przepisywać wszystkiego - znacznie łatwiej jest wydzielić konkretną część do osobnego modułu lub nawet podaplikacji i ją refaktoryzować. To jednak też trzeba robić z wyczuciem, ale o tym później. Sytuacja zmienia się, gdy po analizie okazuje się, że problem z kodem leży u samych fundamentów, np. w obsłudze kluczowych obiektów zarządzanych przez system. W takim układzie o drobne zmiany tu i ówdzie jest znacznie trudniej.

Po drugie, należy przejrzeć stos technologiczny używany w oprogramowaniu. Najczęstszą realną przyczyną przepisywania systemów na nowo jest historyczny kod, bazujący na wersjach bibliotek, które są archaiczne lub po prostu już niewspierane. Przykładem może być aplikacja, która powstała w Angularze 2 i od tego czasu nie była aktualizowana (w chwili, gdy piszę te słowa, dostępna jest wersja 16) - w takim wypadku nie ma się co dziwić, że programiści narzekają na rozwój oprogramowania w tak starej technologii. Warto też wówczas rozważyć, czy aktualizacja wersji rzeczywiście jest problematyczna - może nie będzie tak źle i wystarczy tylko dostosować parę rzeczy. Choć trzeba przyznać, że czasem to droga przez mękę, szczególnie w frameworkach, w których twórcy wprost odrzucają tzw. kompatybilność wsteczną (ang. backward compatibility).

Po trzecie, należy wziąć pod uwagę ostatnie zmiany i kierunek nowych wymagań klienta. Czy faktycznie sprawiały one, że to, co w "normalnej" architekturze zrobilibyśmy w kilka dni, tutaj potrwało kilka tygodni i wygenerowało dużo nieznanych wcześniej problemów? Przy czym pytanie dotyczy nie tego, czy dało się to zrobić szybciej, tylko czy powodem opóźnienia były problemy z dotychczasowym kodem. Jeśli tak i sytuacja się powtarza, to rzeczywiście staje się to solidnym argumentem do przepisania dużej części systemu. Natomiast warto przeanalizować również, czy zmiany zgłaszane przez klienta faktycznie są sensowne i konieczne do realizacji - być może te same cele biznesowe można osiągnąć w inny sposób lub wręcz obecny kierunek przeczy wstępnym założeniom. Są to jednak problemy do rozstrzygnięcia na szczeblu biznesowym i zarządczym, a czasem oznaczają wręcz drugą aplikację.

I wreszcie, po czwarte, trzeba to wszystko skonfrontować ze środowiskiem biznesowym. Jeśli mimo swoich problemów rozwój projektu jest konieczny i klient osiąga dzięki niemu korzyści, z których software house też korzysta, to nagłe powiedzenie "stop" i rozpoczęcie prac od nowa nie jest najlepszym wyjściem. To walka kompromisów - z jednej strony nie można zaprzestać modyfikacji, a z drugiej brnięcie w zły kod tylko pogłębia problem i dług technologiczny. Żeby jeszcze tego było mało, to nie ma za bardzo możliwości, aby łączyć rozwój i restart projektu ze sobą - pierwsze musi się zatrzymać, aby drugie mogło efektywnie trwać. Na szczęście, istnieje sposób, aby to przyspieszyć.

Jak przeprowadzać restart i większą refaktoryzację?

Specjalnie użyłem terminu "większa refaktoryzacja", gdyż mimo sprzyjających okoliczności nadal realizacja projektu od nowa nie zawsze jest dobrym pomysłem. Powiem więcej - zwykle jest niewykonalna w takiej czystej formie, chyba że zespół ma dużo środków i czasu, a także nie musi nigdzie się spieszyć (np. jest liderem rynku w danym obszarze). Dużo popularniejsze podejście mówi o tym, aby transformować obecne oprogramowanie stopniowo, krok po kroku. Jednak do tego trzeba się przygotować.

Przede wszystkim przydatna jest analiza rzeczywistych problemów, którą programiści tworzą przed podjęciem decyzji. Nie ma projektów, w których wszystko jest złe - są takie, w których pewne obszary są tak źle zrobione, że wpływają na inne, potencjalnie "normalne". Być może w aplikacji do zarządzania stajnią problemem nie jest obsługa koni czy budynku, ale system uprawnień użytkowników, przez który każdy nowy ekran oznacza dwukrotną pracę? A może przyjęto złe założenia dotyczące wprowadzenia API, dobierając przy tym nieodpowiednią technologię? Warto jeszcze raz przejrzeć raporty czasów spędzonych nad danymi wymaganiami i znaleźć takie, które notorycznie przynoszą opóźnienia. Taka analiza jest potrzebna do tego, aby zdecydować, co rzeczywiście będzie zmieniane.

Drugim etapem jest podjęcie decyzji i zaplanowanie kierunku zmian, a więc przemyślenie zmian architektonicznych oraz wydzielenie części, która zostanie objęta zmianą. W tym miejscu niektórzy mogą powiedzieć, że to dobry moment na zaktualizowanie frameworka i bibliotek, ale osobiście radziłbym się przez chwilę z tym wstrzymać i zauważyć, że przecież podejście może być zupełnie inne. Może technologia, która została użyta w projekcie, nie jest w ogóle wspierana lub wręcz nie pozwoli na realne zmiany? Niektórzy z nas sami zetknęli się z podobnymi sytuacjami, np. wiele lat temu, gdy standardowa kombinacja Java + GWT stosowana przy panelach administratora okazywała się coraz większym ciężarem i to z kilku powodów - zamiast tego uprościliśmy podejście i zaczęliśmy wykorzystywać mechanizmy dostarczane najpierw przez Yii 1.0, a później Yii 2.0, co znacząco przyspieszyło pracę, ale też pozwoliło większej grupie osób w przyszłości pracować przy takich projektach. Jeśli jednak uznamy, że obecne technologie są dobre, tylko należy je zaktualizować, to faktycznie jest to dobry moment - na tym etapie nie są jeszcze realizowane żadne zmiany architektoniczne, a jedynie dostosowanie kodu do nowej wersji bibliotek. Chyba że to samo w sobie oznacza solidną modyfikacją użytych struktur.

Trzecim etapem jest ustalenie kolejności przeprowadzania zmian - fatalnym pomysłem jest robienie wszystkiego naraz (chyba że faktycznie mówimy o zupełnie nowym projekcie). Trzeba do tego podejść z rozsądkiem - jeśli pewne kwestie mogą być zmieniane równolegle i nie wpływają na siebie, to można się o to pokusić, jednak warto przemyśleć, czy nie jest możliwe wydzielenie pewnego modułu, który zostanie przepisany od nowa. A potem kolejnego i tak dalej. Tak jest - tutaj błyszczą podejścia modułowe i mikroserwisowe, gdyż wydzielają one poszczególne obszary oprogramowania i ułatwiają zmiany. Czasem staje się to naturalne, a czasem trzeba się trochę postarać. Niewątpliwą zaletą jest to, że naturalnie taki podział zostaje i w przyszłości zaowocuje łatwiejszym planowaniem prac w danych częściach.

W szczególności warto rozważyć wydzielenie modułów, które będą dostępne dla reszty oprogramowania przez API (a nie bezpośrednio w kodzie jak do tej pory), a następnie napisanie obok nowego modułu, który w przyszłości zastąpi ten stary. Zaletą jest to, że wówczas wystarczy po prostu przepiąć starą część na nową. W ten sposób w ostateczności przez jakiś czas obie wersje mogą działać koło siebie i być porównywane pod kątem różnych kryteriów. Oczywiście, trudno to rozważać w momencie, kiedy problemy z aplikacją są fundamentalne i dotyczą elementów, których nie da się wydzielić. Ale przyznam szczerze, że to dość rzadka sytuacja.

Inną zaletą podejścia krok po kroku jest też fakt, że po drodze może się okazać, iż pełna zmiana (czy też refaktoryzacja)... nie jest potrzebna. Być może po przepisaniu 30% oprogramowania okaże się, że system działa już jak należy i najważniejsze problemy zostały rozwiązane? Oczywiście, do tego potrzebna jest solidna analiza, o której pisałem wyżej - to warunek, bez którego nowy kod nie będzie znacząco lepszy od starego, a przynajmniej taki efekt będzie bardziej kwestią szczęścia niż rozumu. Jednak gdy zrobi się wszystko "uczciwie" - jest szansa, że nie wszystko zostanie "zresetowane", a zespół i klient będą mieli możliwość stopniowego rozwoju oprogramowania przy ewentualnie równoległych dalszych zmianach w architekturze.

Warto wspomnieć o jednej rzeczy - należy zadbać o to, aby pisanie nowej części oprogramowania nie wprowadzało nowych błędów. W takim układzie warto przemyśleć kwestię testów automatycznych lub przynajmniej innego podejścia weryfikującego poprawność transformacji.

Podsumowanie

Oczywiście, czasem nie ma siły i konieczne jest przepisanie oprogramowania na nowo. Tym niemniej, w wielu sytuacjach solidna i dobrze przeanalizowana refaktoryzacja staje się lepszym wyjściem. Być może jest też tak, że problem jest tylko np. z frontendem, a nie backendem i można przepisać tylko połowę aplikacji? Są to decyzje zależne od konkretnego projektu, jednak należy pamiętać, że każde podejście do oprogramowania od nowa jest dużym przedsięwzięciem, które wymaga środków i zapasów czasowych. Dlatego - jak mówi klasyk - lepiej zapobiegać niż leczyć i starać się tworzyć dobre jakościowo oprogramowanie od początku. Niekoniecznie idealne, ale wystarczająco dobre (ang. good enough), aby zadowolić i harmonogram, i budżet, i rozwój.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Jak "wejść" w Mastodona - szybki tutorial https://wildasoftware.pl/post/jak-wejsc-mastodona-szybki-tutorial?ref=rss https://wildasoftware.pl/post/jak-wejsc-mastodona-szybki-tutorial?ref=rss Tue, 25 Jul 2023 09:00:00 +0000 Dzisiaj krótka piłka - tak, to kolejny tekst o Mastodonie. Jednak tym razem nie będę robił długiego wprowadzenia i mieszał Wam w głowach hasłem "Fediverse" (pojawi się dopiero na końcu, podobnie jak parę innych wyjaśnień). Będę wręcz za bardzo upraszczał różne kwestie. Chcę raczej skupić się i odpowiedzieć na zarzuty, które czasem się powtarzają:
  • "Ale ten Mastodon trudny, po co tyle poradników do niego?"
  • "Nie wiem w ogóle, co tutaj się robi"
  • "Jak tam w ogóle wejść?"
  • "Jest tutaj ktoś w ogóle?"
  • "Głupi interfejs, nie umiem nic zrobić"

I wiele innych, podobnych. Chciałbym raz na zawsze rozwiać pewne wątpliwości i pokazać, że jest to medium jak każde inne, w którym można pojawić się niezwykle szybko oraz równie prosto odnaleźć się i zacząć poznawać nowych, bardzo interesujących ludzi.

Pierwsze, co trzeba zrobić, to znaleźć instancję. Jeśli jesteście w Polsce i chcecie obcować głównie z rodakami, to prawdopodobnie traficie na "oficjalną" polską instancję, pol.social. Instancja to taki serwer, gdzie jest zainstalowany Mastodon i uspokajam - nie ma większego znaczenia to, gdzie są Wasi znajomi. Nawet, jeśli zarejestrowali się gdzieś indziej, to będziecie mogli się z nimi komunikować.

Aktualizacja 30.10.2025 r.

W chwili pisania tego artykułu, pol.social rzeczywiście było wiodącą instancją Mastodona w Polsce. Niestety, od tego czasu sytuacja uległa zmianie i obecnie, z uwagi na długotrwałe problemy techniczno-operacyjne, nie jest zalecana rejestracja na tej instancji. Dlatego w poniższym artykule, mimo że zostały odniesienia i zrzuty ekranu do pol.social, to częściowo zostały zmienione na inne, obecnie stabilniejsze instancje. Zostały one wymienione poniżej, w sekcji "Skąd wiedziałem, że wybiorę dany serwer?".

Jednocześnie chcieliśmy wyrazić szacunek i podziękować administratorowi pol.social za inicjatywę (obejmującą nie tylko Mastodona) - aktualizacja nie wynika z niedocenienia włożonego wysiłku czy niechęci na innych polach, tylko z troski o przyszłość tego projektu i użytkowników Fediverse, szczególnie tych dopiero wchodzących do tego świata.

Po wejściu na stronę zobaczycie coś podobnego do tego:

Strona główna instancji Mastodona (w tym przypadku pol.social).

Jak widać, są jakieś wpisy (a więc są tutaj ludzie), można spojrzeć, że w danej chwili zarejestrowanych jest 1,4 tysiąca kont (tylko na tym serwerze - to tylko ułamek użytkowników "całego Mastodona"), a także dostępny jest kontakt do administratora opiekującego się instancją, który z chęcią odpowie na wszystkie pytania. Nie pozostaje nam nic innego, jak się zarejestrować - po prawej znajduje się przycisk do założenia swojego konta.

Sam proces jest prosty - akceptujemy (zwykle krótki) regulamin, podajemy swój nick, adres e-mail oraz hasło. Jak widać, nie ma tutaj pytania o wszystkie nasze dane i podzielenie się choćby danymi o kontaktach czy zdrowotnymi, jak choćby ma to miejsce w przypadku niektórych innych aplikacji. Następny krok to standardowe odebranie wiadomości e-mail i kliknięcie linku aktywacyjnego. Pierwsze wejście po zalogowaniu powita nas równie znajomym widokiem:

Strona rekomendowanych profili do zaobserwowania (podstrona /start).

Od czegoś trzeba zacząć, więc serwis zaproponuje nam osoby do początkowego śledzenia. Rekomendacje są na podstawie aktywności. Zawsze warto obserwować administratora swojej instancji (zwykle jest na górze listy), gdyż często informuje o ewentualnych nowościach lub kwestiach technicznych. Niezależnie od tego, czy skorzystamy z rekomendacji, czy nie, możemy przejść do swojej strony głównej (z menu po prawej stronie). I tutaj faktycznie niektórych czeka niespodzianka:

Pusta strona główna, brak wpisów na osi czasu.

Większość w tym momencie sie zdziwi i rozczaruje. "Ale jak to - na takim Twitterze X czy Instagramie widzę jakieś wpisy, a tutaj pusto? Gdzie się wszyscy podziali?". I tutaj dochodzimy do jednej ważnej różnicy względem mediów scentralizowanych - na Mastodonie nie ma algorytmu. Nie ma tutaj domyślnego pokazywania przez system postów rekomendowanych na podstawie jakiejś "maszynki", lajków oraz komentarzy. W ten sposób nie ma też sztucznego podbijania wpisów, które w jakiś sposób prowokują lub wywołują największe reakcje. Jak to ktoś ładnie określił, tutaj algorytmem są użytkownicy - poprzez swoje wpisy oraz podbicia (odpowiednik retweetów) zapełniają nam oś czasu. Proste, ale przez to skuteczne i niebudzące konsternacji, jak w zakładkach "dla Ciebie" w innych serwisach.

Jakoś jednak tych użytkowników trzeba poznawać, to naturalne. Na szczęście, główna oś czasu (gdzie widzimy obserwowane przez nas profile oraz hashtagi, z dowolnego serwera) nie jest jedyną - do dyspozycji mamy też inne, którym warto się przyjrzeć. Wszystkie są w menu po prawej stronie.

  • Odkrywaj (explore) - no, powiedzmy, że to taka karta "dla Ciebie", ale w mocno uproszczonej formie. Z tego, co wiem, mało osób zagląda do niej w dalszej perspektywie, ale przydaje się, gdy faktycznie na początku chcemy odkryć nowe profile lub dyskusje do śledzenia.
  • Lokalne (local) - oś wpisów z danej instancji. Przykładowo, jeśli zarejestrowaliśmy się na instancji mastodon.com.pl, to zobaczymy tutaj posty osób tylko z tej instancji. Dobre miejsce, aby znaleźć osoby z naszego "podwórka".
  • Globalne (public) - jak pewnie wielokrotnie słyszeliście, Mastodon jest przykładem systemu opartego na federacji i komunikacji z innymi instancjami. Tutaj właśnie znajdziemy wpisy z "zewnątrz". Na bardzo dużych serwerach można tutaj znaleźć niezliczoną liczbę wpisów i przez to ta oś jest często trudna w przeglądaniu. Na szczęście, można spróbować ją ograniczyć poprzez odfiltrowanie języka - wystarczy wejść do swoich ustawień, następnie preferencji i pozostałych, gdzie są do wyboru języki.

W ten sposób możemy znajdować ludzi, których możemy zaobserwować w standardowy sposób, jak w każdym innym serwisie. Mało tego - samo dodawanie wpisów, podbijanie, dodawanie do ulubionych i inne tego typu czynności również działają tak, jak pozostałych serwisach społecznościowych. Czy powinno nas to dziwić? Absolutnie nie - w końcu Mastodon to właśnie serwis społecznościowy, stworzony od ludzi, dla ludzi. Nie ma tutaj też reklam, a przynajmniej wpisów promowanych, gdyż za systemem nie stoi żadna firma. To sprawia, że nie będziemy co chwilę napotykali treści komercyjnych, których zwykle nie chcemy widzieć.

Uzupełniona strona główna, widać posty obserwowanych profili.

I... to tyle na początek. Jak widzicie, nie ma w tym nic trudnego, a ludzi jest naprawdę sporo, gdy weźmiemy pod uwagę wszystkie instancje. Reszta należy już do Was - piszcie, komentujcie i dzielcie się wrażeniami.

Na tym kończy się zasadnicza część poradnika. Pozostało do wyjaśnienia parę kwestii, które mogą nurtować niektórych niezdecydowanych.

Skąd wiedziałem, że wybiorę dany serwer?

Instancji (serwerów) jest dość dużo i faktycznie pytanie jest zasadne. W momencie przygotowania artykułu, pol.social było "oficjalną" instancją dla naszego kraju, co oznacza, że była widoczna w publicznym katalogu Mastodona, który skupia serwery spełniające określone warunki, dotyczące między innymi moderacji. Jednak ani wówczas, ani teraz nie oznacza to, że to jedyna warta uwagi polska instancja - sam mam konto na 101010.pl, istnieją również m.in. mastodon.com.pl, mastodon.pl, wspanialy.eu i wiele innych. Nie należy zapominać również o serwerach zagranicznych, w tym też oficjalnych, jak mastodon.social czy mastodon.online, ale w tym przypadku warto też zwrócić uwagę na wydajność danej jednostki. A ta dla oficjalnych instancji nie jest najlepsza, choćby dlatego, że jest domyślnym wyborem przy zakładaniu konta bezpośrednio z joinmastodon.org.

A czym w ogóle różnią sie instancje? Zazwyczaj regulaminem (na niektórych wolno więcej, na innych moderacja jest bardziej restrykcyjna) oraz społecznością - istnieją serwery skupione wokół danej tematyki lub bardziej otwarte. Nie należy jednak przywiązywać do tego nadmiernej wagi - po pierwsze, ogromna część fediwersum (zaraz to wyjaśnię) jest ze sobą połączona, co oznacza, że możecie obserwować osoby z innych instancji. Po drugie - instancję można w każdym momencie zmienić bez szkody dla swojej listy obserwujących.

Ponadto umówmy się - często idziemy na tę instancję, na której są nasi znajomi. I to też jest dobry sposób.

O czym muszę wiedzieć pisząc wpisy?

Tak naprawdę odkrywanie możliwości Mastodona zostawiam Wam. Na początku warto jednak wiedzieć, że można tutaj swobodnie edytować wpisy, zwykle mamy do dyspozycji więcej znaków niż choćby na Ćwierkaczu (domyślnie 500, ale wiele instancji to zwiększa), a także że wiadomości prywatne niekoniecznie muszą być wymieniane między dwiema osobami. To ważne - gdy ktoś inny zostanie wspomniany w prywatnej konwersacji, to też włączy się do rozmowy.

Musicie też pamiętać, że użytkownicy utrzymuja porządek i faktycznie stosują się do netykiety, a także opisują grafiki dla osób z problemami ze wzrokiem. W ogóle uszanujmy to, że dla wielu grup społecznych Mastodon i Fediverse to bezpieczna przystań.

Jak obserwować kogoś spoza swojej instancji?

Zwykle bardzo prosto - jeśli widzimy jakiś wpis przy osobie, którą chcemy zaobserwować, to będzie przy niej przycisk "obserwuj". Trochę więcej komplikacji pojawia się, gdy przejdziemy na stronę profilową takiego użytkownika na innej instancji - wówczas najprościej wkleić do niej link w wyszukiwarkę w Mastodonie, w ten sposób "pobierając" ją i dając możliwość zaobserwowania.

Warto też wspomnieć, iż można śledzić hashtagi tak, jak osoby - wystarczy kliknąć na dany znacznik i dodać go do obserwowanych. Wówczas wpisy zawierające ten hashtag będą pojawiać się na naszej stronie głównej, podstawowej osi czasu.

Czym jest to całe Fediverse?

Mastodon jest najpopularniejszą, ale nie jedyną aplikacją, która umożliwia kontakt z osobami z otwartego systemu społecznościowego zwanego Fediverse. Niektórzy powiedzą wręcz (nie bez słuszności), że nie jest najlepszą - istnieje masa innych nie tylko instancji, ale też interfejsów odpowiadających różnym potrzebom. Mamy choćby Peertube (odpowiednik YouTube'a), /kbin (odpowiednik Wykopu, zresztą polskiej produkcji), Pixelfed (odpowiednik Instagrama) czy wiele innych - mając konto na jednej z instancji tych aplikacji możemy śledzić dowolne konto w Fediverse, także z innej aplikacji. Jest to możliwe dzięki temu, że wszystkie instancje mogą się ze sobą łączyć oraz wymieniać informacje dzięki wspólnemu protokołowi - na tym polega system federacyjny.

Krótko mówiąc - to tak, jakbyście w Instagramie mogli bezpośrednio śledzić kogoś z Twittera X czy Reddita, a ten ktoś również Was widział.

Szerzej o koncepcji instancji i federacji pisałem w sekcji "Czym jest Mastodon i Fediverse?" w artykule o komentarzach.

Czy mogę tutaj uzupełnić swój profil?

Jasna sprawa! Wszystko jest dostępne w ustawieniach i naprawdę nie różni się to wiele od np. uzupełnienia konta na Twitterze X. Zaryzykowałbym stwierdzenie, że tych opcji jest nawet nieco więcej. Przede wszystkim, można się samemu zweryfikować, przy czym działa to trochę inaczej niż w scentralizowanych portalach.

Nie ma tutaj bowiem jednego organu, który sprawdzi dane osobowe konkretnego użytkownika i potwierdzi, że to np. jakaś znana osoba. Nie zajmuje się tym też administrator, który ma sporo innych rzeczy na głowie. Weryfikacja odbywa się tutaj samodzielnie poprzez podanie linków do swoich miejsc w sieci i umieszczenie w nich specjalnego, prostego kodu HTML, który sprawia, że link zostaje oznaczony jako sprawdzony. Tutaj macie przykład mojego profilu, w którym potwierdziłem autorstwo blogu:

Profil użytkownika SceNtriC@101010.pl, gdzie widać, iż link wildasoftware.pl/blog został uznany za zweryfikowany i jest podświetlony na zielono.

Dlatego też nie należy ufać niebieskim "tickom" ("ptaszkom") przy nickach użytkowników - jest to raczej forma żartu, parodii podobnych oznaczeń po wprowadzeniu przez Elona Muska Twitter Blue.

Warto też wspomnieć o tym, że bardzo łatwo przejść z trybu prostego do trybu kolumnowego (znanego choćby z TweetDecka) - jest to możliwe w Ustawieniach -> Preferencje -> Wygląd -> Włącz zaawansowany interfejs użytkownika.

Jak korzystać z Mastodona na urządzeniu mobilnym?

Oczywiście, nie trzeba być przy komputerze, aby rozmawiać z ludźmi - serwisy społecznościowe tak nie działają. Jak najbardziej Mastodon ma również swoją aplikację mobilną dostępną za darmo w sklepach, ale istnieje sporo ciekawych alternatyw - Tusky, Ivory, Toot!, Megalodon, Fedilab, Ice Cubes... Do wyboru, do koloru. Także na komputerze istnieją różne alternatywne interfejsy (jak chociażby Elk czy Mangan), które można wypróbować.

Podsumowanie

Cóż, samo wprowadzenie było krótkie, ale wraz z odpowiedziami na pewne kwestie zrobił nam się z tego normalny tekst. Na koniec zachęcę zatem tylko do śledzenia nas właśnie w Fediverse, a także obserwowania samego autora tego tekstu. A jeśli chcecie poczytać więcej o Mastodonie i odkryć inne jego arkana - polecamy Wam poradnik napisany przez Łukasza Wójcika.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Tłumaczymy memy informatyczne https://wildasoftware.pl/post/tlumaczymy-memy-informatyczne?ref=rss https://wildasoftware.pl/post/tlumaczymy-memy-informatyczne?ref=rss Thu, 20 Jul 2023 17:30:00 +0000 Każdy, kto spędza choć trochę czasu w Internecie, doskonale wie, że dostarcza humor w wielu formach. Dawniej były to żarty (takie, jak opowiada się podczas imienin u cioci), zdarzały się też dłuższe formy kopiowane bez żadnej kontroli zwane "pastami", aż w końcu śmieszne zdjęcia czy filmy. Jednak globalna wioska z czasem przyniosła nam jeszcze jeden nośnik treści, który łączy ze sobą dowcip, ale też nierzadko edukację czy komentarz do otaczającego nas świata. W dodatku jest podany w taki sposób, aby łatwo można było go przekazywać dalej i zapamiętywać. Z pewnością wielu z Was domyśla się już, że mam na myśli memy.

Można powiedzieć, że memy zawładnęły światem i coraz częściej wychodzą poza Internet. Co ciekawe, nie są zjawiskiem nowym - samo słowo "mem" oznacza w nauce ideę, która rozprzestrzenia się w danej społeczności, nierzadko wspomagając integrację i wywołując u odbiorców podobną reakcję. Zajmuje się tym nauka zwana memetyką (nie "memologią"!) i, co ważne, nie dotyczy tylko materiałów graficznych. Memem może stać się powiedzenie, wpis jakiejś osoby, sygnał dźwiękowy, piosenka, wideo, zdjęcie, wydarzenie, a nawet cała osoba. Wystarczy, że dana treść jest nieszablonowa, zabawna, kojarzy się z niezwykłymi okolicznościami lub jest zwyczajnie głupia. Osobom, które się tym nie zajmują naukowo lub zawodowo, trudno stwierdzić, co się stanie memem - to się "po prostu dzieje" i jest trochę jak z viralem (który jednak podobno można zaprojektować), którego się nie kontroluje. Źródłem mogą być sytuacje polityczne, sportowe, muzyczne lub po prostu głupie wypowiedzi znanych osób. W ten sposób powstają szablony, masowo wykorzystywane w różnych sytuacjach.

Jednak mem potrafi być czymś więcej niż tylko żartem - może być to satyra, zwrócenie uwagi na problem, wyrażenie "śmiechu przez łzy" lub... edukacja. Mamy bowiem memy ogólne, które trafią do każdego (co nie oznacza, że każdego rozbawią), ale też specjalistyczne, które są zrozumiałe głównie dla osób z danej dziedziny. Nie inaczej jest w informatyce, której przedstawiciele z lubością i naturalnie korzystają z tego środka przekazu, czasem sprawiając wrażenie jeszcze bardziej wyobcowanej społeczności niż głoszą stereotypy. Ale tak nie musi być - jak pisałem wyżej, twórczość internautów może edukować, nawet jeżeli nie było ich to pierwszoplanowe zadanie. Wykorzystamy to dzisiaj do poznania paru zagadnień z IT, czyli, krótko mówiąc - będziemy tłumaczyć memy.

Jakiś czas temu w serwisach społecznościowych zapytałem o przykłady, które Waszym zdaniem mógłbym omówić, choć sam mam też parę propozycji. Dodamy do tego materiały umieszczane na swoich profilach przez znaną Wam pewnie platformę Just Join IT, z którą w ramach przyjacielskiej współpracy przygotowaliśmy ten artykuł.

Zanim przejdziemy do grafik…

...to chciałbym wspomnieć o dwóch żartach tekstowych, które może są nie tyle memami, ale były przerabiane tak wiele razy w Internecie, że pewnie większość z Was je zna. Ale wiem, że niekoniecznie są one zrozumiałe dla każdego, dlatego warto je tutaj przytoczyć i wyjaśnić. Spokojnie - zaraz do memów wrócimy.

Ludzie dzielą się na 10 typów: tych, którzy rozumieją system dwójkowy i tych, którzy go nie rozumieją.

Na początku coś prostego, ale dla niektórych nie do przełknięcia - jak może być 10 typów, podczas gdy zostały wymienione tylko dwie grupy osób? Cała "magia" tkwi w systemie dwójkowym, który został wspomniany w żarcie. Otóż, w tym przypadku liczba 10 powinna zostać zapisana tak naprawdę jako 10(2), a więc jest to liczba binarna. Co za tym idzie, nie należy jej czytać jako pospolitej "dziesiątki", tylko jako 1 * 21 + 0 * 20 = 2. Wówczas cały dowcip nabiera sensu - rzeczywiście istnieją dwie grupy ludzi, z których jedna, rozumiejąc (i rozpoznając) system dwójkowy może się zaśmieje, a druga grupa nie wie nawet, czego się “chwycić".

Numeracja złożona z dwóch cyfr nie jest aż tak trudna, ale fakt, że wymaga pewnego wprowadzenia, aby go zrozumieć. Takowe kiedyś popełniliśmy.

Żona wysyła męża (informatyka) do sklepu, mówiąc:
- Kup parówki, a jak będą jajka, to kup 10.
Mąż przychodzi do sklepu i pyta:
- Czy są jajka?
- Tak.
- To poproszę 10 parówek.

To drugi z bardzo znanych i dość wiekowych już żartów. Co ciekawe, jest bardziej zrozumiały dla mas, gdyż opiera się o logiczną analizę poszczególnych części tekstu. A to właśnie robią programy komputerowe za pomocą instrukcji pisanych przez programistów. Jeśli takie polecenie od żony usłyszałaby osoba, która nie myśli jak informatyk, to zapewne zrozumiałaby to w ten sposób:

"Mam kupić parówki oraz jajka. Tych pierwszych nie wiem ile (wymyślę na miejscu), a tych drugich 10, jeśli akurat będą."

Jest to zastosowanie i prawidłowe zinterpretowanie skrótów myślowych. Jednak taki typowy, stereotypowy programista (bo pewnie o nim jest ten żart) myśli dość ścisłymi instrukcjami. Nie dostał informacji, ile powinno być parówek, więc wydedukował, że ta liczba zależy to od tego, czy są jajka. A zatem, jeśli w sklepie będą jajka, to kupi 10 parówek. Niestety, dowcip nie rozwija, co by się stało, gdyby jajek nie było - albo zostałoby zakupione 0 parówek, albo zwyczajnie mąż wyszedłby ze sklepu.

Memy znalezione w sieci

Mem zawierający parę zdjęć. Najpierw wtyczki włożone w siebie jak w drzewo i przypięte do komputera, podpisane if else if else... Potem listwa (a właściwie hub) z podłączonymi kablami i przełącznikiem na każdym wyjściu opisana jako switch. Następnie listwa połączona sama z sobą z podpisem while (true). Następnie wiele listew podpiętych w łańcuch podpisane jako foreach. Wreszcie plątanina kabli podpisana jako try i bezpiecznik podpisany jako catch.

Źródło: fanpage Wonderful Engineering (a także kolega OsaX Nymloth z Twittera, którego serdecznie pozdrawiam).

Już same zdjęcia umieszczone w tym kolażu mogą bawić, natomiast jeśli ktoś zna zasady programowania, to znajdzie tutaj dodatkowe smaczki. Przejdźmy przez to po kolei.

if else if else... - instrukcje warunkowe nie muszą być prostymi "jeśli X, to wykonaj A, w przeciwnym wypadku B". Często przybiera to formę bardziej odpowiadającą "jeśli X, to wykonaj A, w przeciwnym wypadku jeśli Y, to wykonaj B, w przeciwnym wypadku C". Ale żeby tego było mało, to takie instrukcje można jeszcze bardziej zagnieżdżać: "Jeśli X, to sprawdź, czy Y - jeśli tak, to B, jeśli nie, to C. Jeśli nie X, to sprawdź Z...". W efekcie w kodzie robią nam się tzw. "drabinki ifów", które rozgałęziają się coraz bardziej, co graficznie wygląda jak kolejne linijki z coraz większym wcięciem z lewej strony. A to widok łudząco podobny do tego ze zdjęcia.

switch - poza instrukcją warunkową if, programiści mają też często do dyspozycji instrukcję switch, która działa jak "wybierz 1 z X możliwości" (co prawda, nie do końca jest to prawda, ale pomińmy szczegóły). Czyli w zależności od warunku kod prowadzi do konkretnej opcji, a że jednocześnie słowo "switch" to "przełącznik", to mem staje się bardziej zrozumiały.

while(True) - to tzw. wieczna pętla, czyli konstrukcja, która użyta w niekontrolowany sposób potrafi zawiesić program. Sama pętla while wykonuje się, dopóki spełniony jest warunek podany w nawiasach, a ponieważ ten to po prostu True (a więc prawda), to jest zawsze prawdziwy. A zatem, o ile nie wyjdziemy z pętli w inny sposób, to kod będzie działał "wieczność", wracając ciągle na początek (jak kabel w listwie na zdjęciu).

foreach - to też pętla, ale wykonująca się dla wszystkich elementów w danej tablicy czy na liście, stopniowo rotując do następnego obiektu w kolejności. W tym przypadku widzimy to na przykładzie listew zasilających, które są połączone w porządku i program by po nich przechodził. Choć przyznaję, że akurat to zdjęcie wydaje mi się najmniej trafione - bardziej pasuje do struktury listy, adapterów czy nawet od biedy blockchaina.

try/catch - dwa ostatnie zdjęcia należy rozpatrywać jako całość. W programowaniu funkcjonują bloki instrukcji try...catch...finally, które pozwalają wykonać pewien kod w sekcji try w taki sposób, aby móc wyłapać tzw. wyjątek, czyli błąd o określonym charakterze. W momencie, kiedy to się stanie, program, zamiast kończyć swoje działanie awarią, przechodzi do sekcji catch, gdzie programista powinien w bezpieczny sposób obsłużyć daną sytuację wyjątkową. Czyli dokładnie to, co robi bezpiecznik w układzie elektrycznym. Przy czym tutaj dodatkowo mamy smaczek w postaci bardzo skomplikowanego połączenia kabli, co wyśmiewa koderów robiących bałagan w sekcji try i wierzących w to, że przecież i tak wszystko zostanie złapane przez catch.

Kadr z filmu 'Pasażerowie', gdzie Jennifer Lawrence pyta 'so you are a programmer?', a Chris Pratt odpowiada 'Yes babe... but for you I will even fix the printer...'. Jennifer w odpowiedzi namiętnie całuje mężczyznę.

Źródło: Programmer Humor.

Tutaj mamy przykład szablonu mema, który powtarza się dość często, gdyż pasuje do wielu sytuacji. W tym przypadku są to Jennifer Lawrence oraz Chris Pratt z filmu "Pasażerowie", z których ten drugi wyraża swoją miłość poprzez gotowość do czegoś, na co normalnie w życiu by się nie zgodził. I to właśnie przekazał autor mema poprzez wspomnienie drukarki.

Dobrze wiemy, że informatyk informatykowi nierówny i to, że ktoś umie programować, nie oznacza, że zna się np. na sieciach komputerowych. Tak samo sprzętowiec niekoniecznie od razu zaproponuje schemat skomplikowanej bazy danych, a osoba od uczenia maszynowego nie poratuje architekturą całego systemu. Niestety, wiele osób o tym nie wie i słysząc "informatyk" lub "programista" nadal oczekuje, że to człowiek, która zna się na komputerach i umie pomóc ze wszystkim, co można napotkać w tym obszarze. Stąd właśnie memy o programistach, którzy są już znudzeni powtarzaniem, że nie pomogą z awarią drukarki, gdyż nie zawsze są w stanie cokolwiek na to poradzić, a ponadto nie chcą być wykorzystywani jako darmowy serwis komputerowy.

(Tutaj pozdrowienia dla kolegi, który gdy tylko jedzie na wieś do rodzinnego domu, musi przejść po całej okolicy i pomóc wszystkim dawno niewidzianym sąsiadom z komputerami i drukarkami.)

Chyba że programiście na kimś zależy - według memu wyrazem miłości może być właśnie chęć do pomocy przy rzeczach, z którymi taki specjalista na co dzień nie ma do czynienia.

Mem podzielony na dwie części. Górna podpisana jest 'what people think programmers do' i pokazuje dłonie bardzo szybko piszące na klawiaturze. Dolna część to 'what programmers actually do' i zrzut ekranu z podpowiadania składni przez kod w Visual Studio Code oraz spokojne naciśnięcie klawisza tabulacji.

Źródło: Programmer Humor.

Programiści kojarzą się ze specami od szybkiego pisania i swobodnego tworzenia linijek, które układają się w kod źródłowy, na który laik patrzy i zupełnie nie rozumie. I o ile rzeczywiście osoby pracujące dużo przy komputerze piszą zauważalnie szybciej, o tyle nie zawsze bycie programistą oznacza pisanie ogromnej ilości tekstu. Powiem więcej - czasem im mniej, tym lepiej. A w dodatku przez lata zmieniło się ogromnie dużo dzięki systemom podpowiadającym.

Od dawna programiści przy pisaniu kodu korzystają z tzw. IDE, czyli Integrated Development Environments, zwanych po polsku zintegrowanymi środowiskami developerskimi. Jest to coś więcej niż edytory kodu, gdyż zawierają w sobie dużo narzędzi do różnorakich działań na nim i programie, który z tego powstaje. Jedną z ich podstawowych zalet jest funkcja podpowiadania kodu, która powoduje, że po wpisaniu początkowego fragmentu tekstu, narzędzie samo podpowiada możliwe opcje, np. nazwę szukanej zmiennej. Zresztą, nie jest to tylko domena programistów - choćby Google podpowiada frazy do wyszukania po wpisaniu pewnego tekstu, a w telefonach komórkowych dostępne są słowniki T9.

Informatycy korzystają z podpowiadania tak często, że wręcz nie zawsze pamiętają, jak dokładnie nazywa się element, którego szukają. Jednak IDE stanowią pomoc również we wstawianiu standardowych elementów składni czy po prostu pokazania wszystkich możliwych opcji w danym kontekście. A wywołanie menu podpowiedzi lub skorzystanie z niej najczęściej dzieje się po naciśnięciu klawisza tabulacji (TAB). I o tym właśnie mem mówi.

Gif pokazujący bohatera bajki zmagającego się z żaluzjami sterowanymi linkami. Coraz bardziej zezłoszczony mężczyzna za nic w świecie nie może zasłonić okna, co chwilę wykrzywiając żaluje. Całość podpisana jest jako CSS.

Źródło: Serial "Family Guy".

Wiele razy pewnie słyszeliście, że programistów można podzielić według różnych kryteriów, a jednym z nich jest to, czy pracują bardziej z frontendem, czy backendem. W przypadku tego pierwszego obszaru, który jest związany z aplikacjami klienckimi i interfejsem użytkownika, wachlarz technologii obejmuje nie tylko modny JavaScript czy HTML, ale też np. CSS, czyli kaskadowe arkusze stylów (ang. Cascading Style Sheets). Jest to zbiór dyrektyw, oznaczeń, które pozwalają stylować strony WWW. To, że kolor tego tekstu jest taki, a nie inny, a z boku macie specyficzne marginesy, jest możliwe właśnie dzięki tej technologii, która według niektórych jest prosta, ale inni szczerze jej nienawidzą. Nie dlatego, że jest niepotrzebna, tylko dlatego, że potrafi być kapryśna.

Legendą obrosły już sposoby na wycentrowanie obrazka w CSS, co można zrobić wieloma drogami, jednak nie każda może być zastosowana w każdej sytuacji. Ustawianie elementów koło siebie bez frameworków w postaci Bootstrapa czy Tailwind CSS jest dla niektórych barierą nie do przebycia, podobnie jak dojście do ładu z marginesami zewnętrznymi (margin) i wewnętrznymi (padding). Oczywiście, z jednej strony to żarty - w software house'ach pracują specjaliści potrafiący swobodnie korzystać z dobrodziejstw CSS, jednak nie da się ukryć, że dla osób mających kontakt bardziej z backendem lub tylko okazjonalnie z frontendem, jest to często droga przez mękę. Stąd została uwieczniona na wielu memach.

Memy od Just Join IT

Jeśli jakimś cudem nie znacie tej nazwy, to spieszę z wyjaśnieniem - to portal z ofertami pracy dla programistów. Tylko tyle i aż tyle, gdyż, oczywiście, daje do tego odpowiednie narzędzia wspomagające, zarówno dla potencjalnych specjalistów, jak i rekruterów. Jednak to, co sprawiło, że mówi się o nich częściej niż o konkurencji w Polsce to bardzo swobodne poruszanie się w przestrzeni internetowej oraz inwestycja w niecodzienny PR i marketing. Zresztą, wystarczy wejść na ich stronę, aby odrzucić wizję nudnej korporacji, w której są tylko deadline'y i ASAPy. Oczywiście, te też pewnie się trafiają, ale przynajmniej robią całkiem sympatyczne wrażenie na swoich profilach w sieciach społecznościowych. I organizują nawet teleturniej.

No dobra, ale to przyjacielska współpraca, a nie biznesowa, więc dosyć tych peanów - weźmy się za memy od nich. Choć warto wspomnieć też o tym, że na swoich profilach wrzucają również ciekawostki ze świata IT.

Zdjęcie małpy Janusza (nosacza sundajskiego) z napisem 'kiedy nad prostym projektem pracujecie już 8 miesiąc', gdzie małpa mówi 'a żech godoł... oszczegoł...'.

Źródło: https://twitter.com/Just_Join_IT/status/1677558131856117760.

Każdy wykonawca IT choć raz (a raczej wiele razy) zetknął się z sytuacją, w której ustalony wcześniej harmonogram już dawno stał się historią, gdyż przez niespodziewane problemy, niedopowiedzenia lub po prostu złe oszacowanie potrzebnego czasu projekt zaczyna się przeciągać, a opóźnienia stają się coraz większe. Oczywiście, wraz z nabywaniem doświadczenia oraz wzrostem umiejętności estymacje są coraz lepsze, jednak to nie zmienia faktu, że niektórzy nadal zbyt optymistycznie podchodzą do tworzonego oprogramowania i to zarówno wykonawcy, jak i zleceniodawcy.

Ten mem idealnie to obrazuje, jednocześnie jako element humorystyczny wykorzystując charakterystycznego nosacza sundajskiego, który stał się kwintesencją Polaka, m.in. ciągle narzekającego na… wszystko. Młodzi programiści i kierownicy projektu (a także handlowcy) zdecydowanie powinni czasem posłuchać starszych stażem specjalistów IT, którzy niejedno w życiu widzieli i szybciej zauważą pewne zagrożenia na horyzoncie.

Zdjęcie podpisane 'ewolucja kodu w projekcie' i podzielone na dwie części. Górna to 'start projektu' i ładnie złożony makaron wyjęty od razu z paczki. Dolna to 'miesiąc później' i gotowe spaghetti z makaronem pomieszanym ze sosem.

Źródło: https://twitter.com/Just_Join_IT/status/1677195746209333253.

Nie ukrywam - sam parsknąłem, gdy to zobaczyłem. To odwołanie do zjawiska, które nazywa się spaghetti code i oznacza kod źródłowy, w którym zmiana jednej rzeczy pociąga za sobą konieczność dostosowania innej, najczęściej w odległym miejscu w programie. A to z kolei ma wpływ na jeszcze inne miejsce. Krótko mówiąc - kod jest napisany w taki sposób, że programista zaczyna się po nim poruszać jak po polu minowym i w którym już dawno nikt nie słyszał o zasadach dobrej architektury czy SOLID. To jeden wielki przykry zapach, który często prowadzi do problemów z utrzymaniem oprogramowania. Remedium jest bardzo duża refaktoryzacja lub wręcz napisanie systemu od nowa.

Analogia do spaghetti, w dodatku ubrudzonego sosem, jest zasadna - gdy pociągniemy za jedną nitkę makaronu, odkrywa ona luki w innej części dania, przez co inne nitki również się poruszają i zapadają. To wszystko tworzy plątaninę trudną do analizy i "naprawienia". Czego, oczywiście, nie robimy podczas jedzenia takiej potrawy, ale w przypadku oprogramowania problem staje się realny.

Zdjęcie podpisane 'gdy cały tydzień pracujesz już nad jednym projektem'. W środku jest mężczyzna, który trzyma za rękę kobietę po prawej, ale ogląda się za kobietą z lewej, którą właśnie minął. Uśmiechnięta kobieta z lewej podpisana jest jako 'obiecujące nowe projekty', a zniesmaczona kobieta po prawej to 'obecny projekt'.

Źródło: https://twitter.com/Just_Join_IT/status/1674659032080982017.

Istnieją projekty długie oraz krótkie, jak i takie, które są dobre (i przez to przyjemne w rozwijaniu) lub doczekują się miana "zła koniecznego". Dla programisty największą traumą jest praca przy oprogramowaniu, które jest nudne, trudne w rozbudowie, a na dodatek trwa już tak dużo czasu (nierzadko wiele miesięcy, a nawet lat), że taki koder zrobi wszystko, aby się z niego wyrwać. Nawet, jeśli sam pośrednio odpowiada za obecny stan, a - niestety - tak też bywa.

Nie bez powodu nowe projekty zaczyna się z dużą dozą entuzjazmu, który spada w trakcie trwania. Można go odbudowywać poprzez dbanie o jakość, częste rozmowy z klientem podczas omawiania wyników sprintu, a także dobre planowanie, dające miejsce na świeże, fascynujące wymagania. Oczywiście, łatwo powiedzieć, ale nie zawsze można tak zrobić. Dlatego ogólna zasada jest taka, że zacząć projekt jest stosunkowo prosto, ale prawdziwego programistę poznaje się po tym, kiedy go skończy lub przynajmniej doprowadzi do wersji produkcyjnej.

To ma jeszcze większe znaczenie przy projektach prywatnych, podczas których nikt nie kontroluje danej osoby poza nią samą, a które też często nie mają znaczenia biznesowego, tylko po prostu pozwalają się rozerwać lub poznać nową technologię. Jednak o tym ewentualny spadek motywacji w takim projekcie robionym po godzinach jest akceptowalny, o tyle w pracy może oznaczać potężne problemy. Dlatego dobry kierownik zespołu w środowisku biznesowym powinien umieć ją utrzymać na tyle, aby programiści z chęcią trwali w danym projekcie.

Oczywiście, to zdjęcie do parodia znanego mema z mężczyzną oglądającym się za inną kobietą na ulicy. Ten szablon ma nawet nazwę - jest to "Distracted Boyfriend" i jak w przypadku wielu zdjęć znanych z bycia memem, jest dość dokładnie opisany i przeanalizowany.

Zdjęcie podpisane 'niezbędnik pomocy technicznej' i pokazujący treść kartki przyklejonej pod biurkiem. Treść: 'Przywitaj, zaproponuj wyłączenie i włączenie komputera, podziękuj, pożegnaj'.

Źródło: https://www.facebook.com/JustJoinIT/posts/pfbid02wxGFJp1ykzVoZYVEFnFdozMtMwMtgKw31tGALMp5JSYb4XRtYiaQeMbmVhcYGfTtl

Żarty o tym, że na wiele problemów z elektroniką pomaga restart, to nie do końca dowcipy - ponowne uruchomienie maszyny czy aplikacji wiąże się z wyczyszczeniem pamięci, której "zabrudzenie" często jest powodem zawieszenia się czy złego działania (oczywiście, bardzo upraszczając). Ewentualnie program wszedł w jakiś fragment kodu, który nie został dostatecznie dobrze przetestowany, ale jak to się stało - nikt nie wie. Jeszcze trudniej jest w przypadku sprzętu, gdzie zazwyczaj nie sposób znaleźć dokładną przyczynę, szczególnie na odległość. Stąd tak częste prośby działu IT (tym razem sprzętowego) o wyłączenie i włączenie zasilania.

Swoją drogą, ta rada często leży u podłoża innych, bardziej skomplikowanych sposobów proponowanych przez działy wsparcia. Istnieją legendy, według których różne rekomendacje dotyczące modemów (np. odłączenie kabli, obrócenie na drugą stronę, podłączenie w inny sposób, przedmuchanie) miały tylko zamaskować fakt, że tak naprawdę wystarczyłby restart, ale jeśli pracownik powiedziałby to wprost, to zostałby zwyzywany przez klienta, że "przecież to próbował i nie zadziałało". Nie, zwykle nie próbował. Choć trzeba przyznać, że teraz tego typu rady mogą mieć większe znaczenie, gdyż większość urządzeń jest nie tyle wyłączana, co usypiana i choćby Windowsa można wyłączyć na dwa sposoby. A wówczas ma to znaczenie dla pewnych usług.

Gdzie szukać memów o IT?

Oczywiście, to tylko ledwie ułamek twórczości internautów w świecie memów związanych z branżą informatyczną. O wiele więcej możecie znaleźć w Internecie, ale trzeba wiedzieć, gdzie szukać (oczywiście, poza profilami takich platform jak Just Join IT). Jest choćby Programmer Humor, który jest dostępny na Twitterze oraz Reddicie. Po gify warto zajrzeć do serwisu The Coding Love. Jeśli z kolei szukacie nieco dłuższych materiałów z lekko cringe'owym humorem i scenkami rodzajowymi, to bardzo znany jest kanał HRejterzy, który parodiuje branżę na wszystkie możliwe sposoby. Swego czasu popularne były serwisy wywodzące się bezpośrednio z IRC-a, jak choćby Bash, ale niestety, ten fragment Internetu będzie już wspominany tylko w książkach historycznych.

Ale również użytkownicy Fediverse znajdą coś dla siebie - niezastąpiony Kierunkowy74 (pozdrawiam) podrzucił w komentarzu trzy agregaty memów i innych postów dotyczących humoru programistycznego. Możecie je również obserwować posiadając konto np. na Mastodonie (ale nie tylko):

Oczywiście, to konkretne profile, jednak samych memów o IT w Internecie znajdziecie dużo więcej. Wystarczy poszukać.

Podsumowanie

Mam nadzieję, że o ile może nie wszystkie przedstawione dzisiaj materiały wywołały salwy śmiechu, o tyle przy każdym dowiedzieliście się czegoś ciekawego o charakterystyce pracy w IT. Taki był cel tego artykułu i kto wie, może jeszcze kiedyś wrócimy do tej formy, jeśli będzie zainteresowanie. Tymczasem życzę Wam dużo uśmiechu w codziennej walce z oprogramowaniem, zarówno przy korzystaniu z niego, jak i pisaniu.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Co składa się na wycenę oprogramowania? https://wildasoftware.pl/post/co-sklada-wycene-oprogramowania?ref=rss https://wildasoftware.pl/post/co-sklada-wycene-oprogramowania?ref=rss Thu, 13 Jul 2023 17:30:00 +0000 "Co tak drogo?!" - to pytanie słyszała w swoim życiu (i to wielokrotnie) praktycznie każda osoba, która prowadzi firmę usługową, produkcyjną lub sklep. Nie da się ukryć, że o ile wszyscy zawsze podkreślają, że jakość jest najważniejsza, to cena zazwyczaj jest pewną barierą. Oczywiście, nie musi tak być - istnieją usługi, w których większość jest w stanie dopłacić do jakości lub zwyczajnie cena jest wystarczająco niska. Tym niemniej na pewno większość z nas musiała choćby raz tłumaczyć, dlaczego cena, za którą oferuje dany produkt lub działanie, jest ustawiona na tak wysokim pułapie.

Dzisiaj pokażemy sobie, z czego składa się cena za oprogramowanie lub usługę IT. Od razu zastrzegam, że nie będziemy wchodzili w szczegóły, a tym bardziej podawać konkretnych kwot, gdyż zależą one od stawek firmy (naszą możecie znaleźć pod tym linkiem), pracy do zrealizowania, a także typie wykonawcy. Zaznaczam też, że będziemy pisać o koszcie systemu informatycznego tworzonego na zlecenie - w przypadku produktów do kupienia "z półki" jest to zwykle kwestia strategii cenowej danej firmy i planów sprzedażowych związanych z oprogramowaniem. Dlatego wszystko, co przeczytacie poniżej, dotyczy wycen tworzonych indywidualnie na zamówienie.

Każdy, kto kiedykolwiek widział wycenę oprogramowania, wie, że zazwyczaj wynika z pracochłonności konkretnych zadań. Często jest to szacowana liczba godzin potrzebna do realizacji czegoś, czasem stosowane są punkty funkcjonalne lub inne jednostki, według, których łatwiej ustalać choćby rząd wielkości. Estymacje wynikają z burzy mózgów, metod typu Planning Poker, historii lub po prostu doświadczenia, że coś tyle czasu zwykle zajmuje. Nie jest też żadną tajemnicą, że bywają niedokładne - to w końcu oszacowania, które są bazą dla podejścia fixed price. Ale pytanie, czy faktycznie jest to tylko samo wprowadzenie zmiany do kodu? Czy wprowadzenie jakiegoś pola do formularza to nie jest tak naprawdę kwestia 30 minut, a ten zły software house liczy za to kilka godzin? Otóż, nie, słusznie tak liczy i to z kilku powodów.

Po pierwsze, zazwyczaj jako użytkownicy oceniamy dane funkcje pod kątem ich pojawienia się w interfejsie użytkownika. Mówiąc bardziej obrazowo, dla laików sam fakt, że może uzupełnić dane pole oznacza wykonanie zadania, jednak takie podejście jest dużą pomyłką. To troche tak, jakby wstawić do samochodu ładny fotel, ale go nie przytwierdzić do reszty. Za zmianami na frontendzie muszą podążyć zmiany w backendzie i obsługa tego pola w systemie. A to nie zawsze jest proste, szczególnie przy danych kluczowych dla działania systemu. Po drugie, czasem dodanie pola (nie mówiąc już o bardziej złożonych modyfikacjach) uruchamia efekt domina i wymaga przemyślenia innych części systemu. Po trzecie, w ten czas wliczona jest także weryfikacja, czyli przetestowanie tej zmiany. Uwierzcie mi - nie chcielibyście, aby programista dodał pole i uznał, że sprawa jest zakończona. Trzeba rozpisać, co ta zmiana ze sobą niesie, jakie są warunki wykonania zadania oraz je przetestować, łącznie ze skrajnymi przypadkami. Oczywiście, nie zawsze wszystko zostanie wykryte na etapie wewnętrznych testów, jednak bez tej fazy błędów byłoby znacznie więcej. Po czwarte, czasem liczy się moment wprowadzenia zmiany - łatwiej wprowadzić do jednego formularza trzy pola naraz niż każde z nich osobno, w tygodniowych odstępach.

Bardzo duże, wręcz ogromne znaczenie mają też wymagania pozafunkcjonalne, które mogą funkcję pozornie prostą wywindować do zadania wymagającego wiele godzin pracy. Inaczej kształtują się estymacje dla systemów kierowanych do małego grona osób, a inaczej dla oprogramowania, które musi obsłużyć miliony użytkowników i będzie działać na serwerach o określonym charakterze. Im większe bezpieczeństwo czy wymagania związane z interfejsem użytkownika, tym bardziej trzeba na to zwrócić uwagę przy liczeniu potrzebnych środków. Tak samo narzucenie określonych technologii (co wynika np. z wewnętrznego działu IT klienta, który potem przejmie rozwój aplikacji) może podnieść koszty ze względu na potrzebę zapoznania się z nowymi narzędziami przez dany software house. Wreszcie, znaczenie ma liczba komponentów - inaczej wycenia się oprogramowanie składające sie z samej aplikacji webowej, a inaczej takie, które zawierają również "mobilkę" czy interfejs desktopowy. Dając do wyceny tę sama aplikację jako webową i mobilną uzyskacie dwa różne oszacowania i to normalne. Wreszcie, wszelkie dodatkowe panele (np. administracyjny) również mogą wpłynąć na budżet potrzebny do stworzenia oprogramowania.

Jednak prace programistyczne, nawet włącznie z testowaniem, to nie jedyne, co trzeba uwzględnić. Niektóre obszary wymagają bowiem zaprojektowania nowych modułów i architektury pod nie. A to oznacza kolejną pracę, którą software house musi wykonać. Niekiedy zdarza się też, że jakaś funkcja wymaga zapoznania się z dostępnymi rozwiązaniami i wybór konkretnego - jest to tzw. research, który też ktoś musi zrobić. Kolejna kwestia to przygotowanie makiet oraz prototypów, nawet jeśli tylko do części zadań. Podeście "zaproponujcie coś, a potem się zmieni" jest fatalne i generuje frustrację oraz kolejne koszty, z którymi zarówno klient, jak i wykonawca nie mogą się pogodzić - stąd przy bardziej skomplikowanych lub kluczowych z punktu widzenia systemu ekranach należy wcześniej przygotować ich projekt.

Ale nie tylko praca techniczna musi być opłacona - to także praca osób kierujących projektem, osób przeprowadzających szkolenia, prezentacje dla klienta, a także analizujące nowe potrzeby. To również nie jest robione "z marszu" i wymaga przemyślenia oraz przygotowania choćby szczątkowej specyfikacji. Spotkania i konsultacje również wchodzą w zakres tego segmentu prac. Sporo osób zapomina również o tym, że oprogramowanie należy wdrożyć. A to oznacza czas spędzony na przygotowywaniu paczek z oprogramowaniem, opracowaniu procedury wdrożeniowej i "ostatniej linii" testów, które sprawdzają nie tylko same funkcje, ale także ich powiązania ze sobą.

Tak, jak pisałem - w zależności od projektu, kosztorys prac może mieć najróżniejsze pozycje zawarte w sobie. Zdarzają się choćby systemy, w których konieczne jest zakupienie odpowiedniej licencji na biblioteki czy oprogramowanie, a nawet sprzęt. Co więcej, istnieją projekty, w których potrzebny staje się dojazd do klienta w celu wykonania określonych prac na miejscu (choć, na szczęście, jest to duża rzadkość). Może być to też koszt wynajęcia odpowiedniego eksperta, konsultanta, który nie tylko będzie stanowił pomoc w zrozumieniu kontekstu biznesowego (szczególnie ważne przy systemach tworzonych przez dłuższy czas w specyficznej branży), ale też ograniczy występowania nieporozumień.

Natomiast klient musi też pamiętać o innych kosztach tworzenia oprogramowania, niebezpośrednio związanych z pracami technicznymi. Pamiętajmy o tym, że otwarte systemy wymagają regulaminów i przeprowadzenia różnych formalności, które stają się możliwe z udziałem prawników lub np. audytorów. W przypadku aplikacji wielojęzycznych konieczne okazuje się zapewnienie tłumaczeń, które będą mogły zostać wprowadzone do aplikacji. Wcześniej wspomniane zostały też makiety, które mogą wymagać konsultacji z grafikiem, np. pod kątem loga serwisu czy użytych kolorów. Wreszcie, większość systemów działa na serwerach i innej infrastrukturze, którą trzeba zakupić, skonfigurować oraz utrzymać. A żeby tego było mało, to w niektórych przypadkach należy zapewnić moderatorów i wsparcie klienta...

Z tego wszystkiego powinny płynąć dwa wnioski. Po pierwsze, zaimplementowanie czy dodanie nowej funkcji do systemu to nie jest tylko czas poświęcony na samo dodanie paru linijek kodu - to także cała "otoczka" wokół tego, weryfikacja, czasem projekt, przemyślenie sposobu działania itd. Z tego powodu już dawno przestało się oceniać programistów poprzez napisane linie kodu (choć bywa, że ten temat wraca). Po drugie, jeśli ktoś chce stworzyć oprogramowanie, musi liczyć się także z kosztami pozatechnicznymi i utrzymaniem systemu przez dłuższy czas. Stąd warto zaznajomić się z technikami, które umożliwiają większy zwrot z przeprowadzonej inwestycji w kod lub po prostu przemyśleć kwestię MVP.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Czym jest ukryta wiedza dziedzinowa? https://wildasoftware.pl/post/czym-ukryta-wiedza-dziedzinowa?ref=rss https://wildasoftware.pl/post/czym-ukryta-wiedza-dziedzinowa?ref=rss Thu, 06 Jul 2023 17:30:00 +0000 Tworzenie oprogramowania nie rozpoczyna się od napisania pierwszej linijki kodu. Za punkt startowy nie należy nawet uznawać zaprojektowania architektury czy interfejsu. Tak naprawdę projekt zaczyna się w momencie, kiedy dowiadujemy się o nim czegoś więcej i rozpoczyna się etap zbierania wymagań. Celem tego procesu jest zgromadzenie i przeanalizowanie bardziej szczegółowych wytycznych dotyczących nie tylko tego, jak system ma się zachowywać, ale przede wszystkim jaki jest kontekst biznesowy, w jakim będzie działać oprogramowanie oraz co tak naprawdę jest w nim najważniejsze, czyli cel biznesowy do spełnienia. Taka analiza (przez niektórych nazywana audytem, ale przyznaję, że nie pasuje mi to określenie akurat w tym przypadku) skutkuje lepszym poznaniem oczekiwań klienta oraz trafniejszym wyspecyfikowaniem wymagań, co pozwala potem stworzyć odpowiedni dokument. Jednak niezależnie od tego, jak starają się obie strony (zarówno software house, jak i zleceniodawca), zawsze pozostaną niedopowiedzenia, które zostaną odkryte dopiero na dalszym etapie.

Roboczo nazywam to ukrytą wiedzą dziedzinową, która może przybierać różne formy, ale zawsze jest zaskoczeniem dla wszystkich zaangażowanych osób, choć z różnych powodów. Dzisiaj porozmawiamy o tym zjawisku.

Czym jest ukryta wiedza dziedzinowa?

Aby to dobrze wyjaśnić, muszę odnieść się do przykładu. Być może trochę uproszczonego, ale jak najbardziej występującego w rzeczywistości.

Wyobraźmy sobie projekt systemu dla motoryzacyjnego zakładu produkcyjnego. Są tam wytwarzane i montowane samochody, motocykle, a także inne pojazdy oraz części do nich. Oprogramowanie ma wspomagać wiele rzeczy, a jedną z nich jest harmonogram produkcji. Hale zawierają wiele maszyn, dostępna jest pewna pula pracowników, ale jest też dużo zleceń o różnych wymaganiach - trudno jest to wszystko zaplanować ręcznie, zwłaszcza w taki sposób, aby zasoby zakładu zostały optymalnie wykorzystane, żaden pracownik się nie nudził (i nie było nadmiaru ludzi), a jednocześnie zadbać o balans eksploatacji poszczególnych maszyn. Nowa aplikacja ma to ułatwić, proponując automatyczne propozycje grafiku prac - w skrócie sprowadzi się to do tego, która część zlecenia jest wytwarzana na danej maszynie w którym momencie. Oczywiście, w grę wchodzi równoległość zadań, uwzględnienie dat wykonania (tzw. deadline'ów) oraz warunki przy danych czynnościach (np. konieczność skorzystania z określonej maszyny lub kompetencje pracownika). Klient to wszystko cierpliwie tłumaczy software house'owi, ci drudzy zadają pytania doprecyzowujące oczekiwania i w końcu powstaje projekt rozwiązania, który po konsultacji jest realizowany.

Po pewnym czasie klientowi wraz z którymś sprintem oddawana jest początkowa wersja funkcji harmonogramu. Jest ona przedstawiana na spotkaniu, zespół programistów pokazuje przygotowane wcześniej scenariusze testowe, a klient weryfikuje funkcjonalność we własnym zakresie. I nagle pada pytanie od użytkowników zleceniodawcy: "a jak mogę przypisać dwie maszyny do jednej czynności lub jedną maszynę do dwóch czynności? Często tak robię.". Okazuje się, że ten wątek nie pojawił się podczas rozmów o wymaganiach dotyczących harmonogramu, a pracownicy rzeczywiście regularnie z tej sposobności korzystają, w ten sposób przyspieszając produkcję. Powstaje problem, gdyż taka zmiana wiąże się ze sporymi modyfikacjami algorytmu układającego harmonogram, a w dodatku klient nie do końca zgadza się z tym, że to coś, za co powinien dopłacić.

Każda komunikacja pomiędzy klientem a wykonawcą IT zachodzi w obie strony i polega między innymi na wymianie wiedzy i doświadczenia. Zleceniodawca ma tzw. wiedzę biznesową i wie bardzo dużo o dziedzinie, którą ma modelować system. Takie informacje potrzebuje software house, gdyż musi je "przetłumaczyć" na kwestie techniczne. Z kolei specjaliści od oprogramowania mają wiedzę techniczną i podczas rozmów mogą zaproponować inne, lepsze rozwiązania, z których klient nawet nie zdawał sobie sprawy. Co więcej, mogą czasem uświadomić drugą stronę, że dana kwestia jest niemożliwa do zrealizowania w sposób przewidywany przez użytkowników lub ta forma znacznie wykracza poza budżet. Wiele razy podczas rozmów z klientami w Wilda Software mieliśmy poczucie, że nie tylko dowiadujemy się czegoś nowego, ale i klient rozszerza swoją wiedzę na temat rozwiązań IT, gdyż przez lata żył w niewiedzy lub był przyzwyczajony do pewnego sposobu działania.

Natomiast musimy pamiętać o drugiej stronie medalu - dla każdej z tych stron są aspekty w ich dziedzinach, które wydają się oczywiste. To trochę tak, jakby specjalista od remontów powiedział "młodemu", że ma pierwszy raz zawiesić szafkę i wskazałby mu wiertarkę oraz pokazał, jak się wierci, który haczyk potem wkręcić, natomiast zapomniał powiedzieć o tym, że w ścianę wbija się kołek, w efekcie czego mebel spada na ziemię lub ściana jest w ruinie. W przedstawionym wyżej przykładzie dla przedstawicieli zakładu produkcyjnego było oczywiste, że zadania mogą być związane z więcej niż jedną maszyną i odwrotnie, natomiast nie przekazali tej wiedzy software house'owi, bo uznali, że to naturalne i szkoda czasu na wspominanie o tym. A jak widać, nie było to takie oczywiste, podobnie jak dla klienta nie byłoby oczywiste, że np. aplikacji webowej nie trzeba instalować na komputerze użytkowników (historia prawdziwa). Jest to coś, co nazywamy ukrytą wiedzą dziedzinową lub biznesową. Są to kwestie tak oczywiste dla jednej ze stron, że nie wspomina o nich (lub wspomina niedostatecznie dokładnie) drugiej stronie w nieuzasadnionej wierze, że jest to dla niej równie zrozumiałe.

Jak groźna jest ukryta wiedza?

Tak, jak pisałem, powyższy przykład jest nieco uproszczony, gdyż akurat taka kwestia jak podwójne wykorzystanie maszyn to rzecz na tyle ważna w harmonogramie, że ujawniłaby się podczas analizy. Nawet, jeśli nie podczas rozmowy, to podczas przeglądania przykładowych harmonogramów, walidacji testowego scenariusza czy wycieczki po fabryce i obserwacji pracowników (czasem praktykuje się takie rzeczy, tylko potrzebny jest przewodnik ze strony firmy, aby było to efektywne). Natomiast podobne przypadki się zdarzają i ich efekt może być różny.

Rzadko zdarza się, aby ujawnienie jakiegoś aspektu wymagało bardzo dużej refaktoryzacji, a jeśli już, to dzieje się to w początkowej fazie projektu, więc o taką modyfikację jest jeszcze stosunkowo łatwo. Dużo częściej fragment ukrytej wiedzy dziedzinowej powoduje:

  • znaczne skomplikowanie algorytmu wykonującego obliczenia,
  • modyfikacje schematu bazy danych,
  • sparametryzowanie danego modułu,
  • szukanie rozwiązania zastępczego.

Bywają też odwrotne sytuacje - w wyniku nadmiernej ostrożności software house założy zbyt dużą elastyczność i rozdzielenie od siebie obiektów, po czym okazuje się, że np. maszyna i urządzenie, stosowane w opowieści klienta i potencjalnie mające różne znaczenie w procesie biznesowym, są tak naprawdę tym samym, a prezentujący zwyczajnie stosował synonimy. Jest to lepsza sytuacja z punktu widzenia realizacji projektu IT, gdyż wymaga uproszczenia, a nie rozszerzenia, ale tutaj z kolei powstaje często kłopot zostawienia nieużywanej funkcjonalności lub niewykorzystanej tabeli w bazie danych, gdyż nigdy nie ma pewności, czy rozdzielenie w przyszłości nie będzie potrzebne. A skoro już nastąpiło w aplikacji, to następuje "zostawmy, może się przyda". Nie jest to chlubna praktyka, ale biorąc pod uwagę napięte terminy, niepewność dotyczącą wymagań i konstrukcję kodu, czasem ma to miejsce.

W ostatnim zdaniu wspomniałem o niepewności i to też aspekt ukrytej wiedzy, o którym warto pamiętać - to naturalne, że podczas omawiania planu projektu klient nie zawsze pamięta o wszystkim lub pewne potrzeby pojawiają się później. Stąd taka popularność metodyk zwinnych, które pozwalają radzić sobie z podobnymi sytuacjami poprzez rozwijanie i oddawanie oprogramowania w etapach. Tym niemniej, należy przygotować się na to, że nie wszystkie wymagania określone na początku zachowają swój poziom priorytetu aż do końca oraz że ta lista nie jest kompletna. Nawet przy odpowiednio elastycznej architekturze będą sytuacje, w których trzeba będzie przeprojektować lub rozszerzyć już napisane fragmenty oprogramowania.

Jak poradzić sobie z tym zjawiskiem?

Na początku trzeba powiedzieć jasno jedną, smutną rzecz. Niezależnie od tego, jak bardzo obie strony będą się starać, to nie ma idealnego sposobu na uniknięcie zjawiska ukrytej wiedzy dziedzinowej. Taka sytuacja może być rzadsza, a nawet szczęśliwie może też w ogóle nie wystąpić (np. w bardzo małych projektach), natomiast nie ma metody, aby przewidzieć wszystko na samym początku. Oznaczałoby to, że software house zaczynałby z wiedza o środowisku biznesowym równą lub większą od tej, którą posiada klient, a jest to niemożliwie do osiągnięcia poprzez szereg spotkań, wymianę maili i nawet najbardziej dokładne prototypy. Nawet jeśli przedstawiciele software house'u kupiliby książki z dziedziny, w której ma się poruszać aplikacja lub przeszliby odpowiednie kursy, to nigdy nie będą mieli takiego doświadczenia jak klient oraz informacji o wszystkich wewnętrznych procedurach obowiązujących w danej firmie. Bo wiadomo, że na to wszystko nakłada sie fakt, że w poszczególnych środowiskach pracy ludzie są przyzwyczajeni do określonego sposobu działania.

Dlatego tego zjawiska nie można się całkowicie pozbyć - można za to zminimalizować ryzyko jego wystąpienia i znaczenia. Jest na to kilka sposobów, które zostały wspomniane w tekście, ale warto je usystematyzować.

Pierwszą i najważniejszą sprawą jest podzielenie projektu na etapy i przejście na metodykę zwinną lub przynajmniej częściowo zwinną. W ten sposób w sytuacji, w której wystąpi przypadek ukrytej wiedzy dziedzinowej (a już pisaliśmy, że najczęściej pojawia się w początkowych fazach projektu i podczas walidacji przez klienta, co w agile jest częstsze), oprogramowanie nie będzie aż tak rozbudowane, przez co wprowadzenie ewentualnych zmian będzie prostsze. Nie zawsze jest to możliwe, ale na pewno daje to zwiększenie szans na prawidłową reakcję.

Drugą kwestią jest przygotowanie dobrych scenariuszy pokazujących przykładowe korzystanie z systemu. Nie mam tutaj na myśli ani prototypów (choć te również mogą być elementem scenariusza), ani typowych manualnych testów akceptacyjnych. Wiele razy zdarzało nam się, że dyskusja o jakimś module dochodziła do momentu, w którym obie strony nie do końca rozumiały nawzajem, co nie jest jasne. Wówczas warto zwyczajnie przygotować przykład i wizję, w jaki sposób będzie on obsługiwany w systemie, tj. gdzie należy nacisnąć i co się stanie po wprowadzeniu danych. W znakomitej większości przypadków już samo ułożenie przykładu pokazuje klientowi, czy software house dobrze pojął temat, a dodatkowo może ocenić proces użytkowania względem swoich (czasem niewyrażonych) oczekiwań. Ta technika jest pracochłonna, ale użyta w odpowiednich momentach przydaje się obu stronom, gdyż nawet przygotowywanie takiego dokumentu wymaga bardziej szczegółowej analizy i w ten sposób składania do zadania właściwych pytań. To również dobry sposób, gdy klient jest przyzwyczajony do jednego typu oprogramowania i ma trudności w pojęciu innej filozofii działania.

Przy tej okazji warto wspomnieć, że podobne dokumenty przygotowuje się w przypadku projektowania algorytmów, choć nie mają one wówczas formy scenariusza, a raczej pokazania krok po kroku, jak liczony jest dany przypadek, W ten sposób można uzgodnić zachowanie systemu dla ciekawych kombinacji danych, choć należy wspomnieć, że np. przy wspomnianym wcześniej szeregowaniu zadań produkcyjnych przygotowywanie takiego przykładu może być jeszcze bardziej czasochłonne. Tym niemniej, zazwyczaj opłaca się to w dłuższej perspektywie.

Trzecia technika to dobry, wręcz "przesadzony" pod kątem detali słownik terminów. Można to przyrównać do opisania obiektów biznesowych, jednak w bardziej szczegółowej formie, której przygotowanie sprawia, że niezbędne jest rozważenie wręcz każdego słowa i tym samym znalezienie przypadków szczególnych lub stwierdzenie, że tutaj nie występują. Ta metoda może zostać wykorzystana w specyficznych przypadkach, aby zorientować się, jak bardzo elastyczne obiekty musi założyć wykonawca IT, natomiast nie da się ukryć, że jest dość pracochłonna, wymaga dużej uwagi i dyskusji z obu stron (przypomina trochę "łapanie za słówka"), a na dodatek powinna być wykonana na początkowym etapie, kiedy tak naprawdę nie wiadomo jeszcze, gdzie pojawią się nieporozumienia. Tym niemniej, warto o tym wspomnieć, w szczególności przy osobach preferujących ścisłe podejście do tematu.

Czwarta metoda polega na wprowadzeniu trzeciej strony, a mianowicie konsultanta, który łączy w sobie wiedzę dziedzinową oraz techniczną. Jego pochodzenie może być różne - bywa, że jest to osoba zupełnie z zewnątrz, która na co dzień zarządza zespołami w danej branży lub jest naukowcem zajmującym się danym obszarem, ale może być to też osoba wyznaczona przez klienta, która ma stosunkowo dużą wiedzę techniczną. Jest to swego rodzaju przekaźnik pomiędzy obiema stronami (stanowiącymi nadal jeden zespół), który w niektórych przypadkach szybciej zidentyfikuje sedno problemów i potencjalne nieporozumienia. Jest to też osoba bardzo pomocna przy przekonywaniu firmy o tym, jak aplikacja może zmienić ich sposób funkcjonowania na lepsze, ale także poinformować wykonawcę IT o tym, co w praktyce będzie stanowiło trudność dla zleceniodawcy. Niestety, wadą jest to, że zatrudnienie takiej osoby zazwyczaj kosztuje niemało, a ponadto nawet człowiek znający obie branże nie zawsze prawidłowo odgadnie wszystkie ukryte problemy trapiące obie strony.

Wreszcie piąta kwestia nie tyle minimalizuje ryzyko wystąpienia nieporozumień, co ich skutki. Mowa o ostrożniejszym szacowaniu pracochłonności lub przyjęcia elastycznego sposobu rozliczania. Wówczas zarówno software house jest zabezpieczony i ma bufor na poprawki wynikające m.in. z ukrytej wiedzy dziedzinowej, jak i klient płaci rzeczywiście za to, co zostało wykonane i ma nad tym większą kontrolę. W niektórych przypadkach dobrym rozwiązaniem jest "przedwczesne" wprowadzenie umowy serwisowej.

Podsumowanie

Problem istnieje i to nie tylko w branży IT, ale w każdej, gdzie nakładają się na siebie obszary z różnych dziedzin lub nawet różnej filozofii działania firm. Należy się z tym pogodzić i nie reagować na nieporozumienia w sposób alergiczny. Oczywiście, ich pojawienie się nie jest witane aplauzem i nierzadko powoduje negatywne emocje, natomiast są techniki, które pozwalają je ograniczać i się na nie przygotować.

Warto wyciągnąć z tego wniosek, że etap analizy jest często ważniejszy niż się wydaje i trzeba poświęcić na niego więcej czasu. Z drugiej strony, bardzo dokładna analiza działania dużej firmy zajmuje tak dużo czasu, że w większości przypadków trzeba ją zarzucić na rzecz ogólnego planowania na początku, a następnie szczegółowych rozmów dotyczących konkretnych kwestii w przyszłości. Żadne podejście, nawet najbardziej drobiazgowe poznawanie zasad funkcjonowania danej branży, nie ustrzeże przed wystąpieniem nieporozumień. Jedyne, co możemy robić, to minimalizować ich wpływ na projekt IT.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Wersje językowe, czyli internacjonalizacja https://wildasoftware.pl/post/wersje-jezykowe-czyli-internacjonalizacja?ref=rss https://wildasoftware.pl/post/wersje-jezykowe-czyli-internacjonalizacja?ref=rss Thu, 29 Jun 2023 17:30:00 +0000 Internet często jest nazywany "globalną wioską" i jest w tym dużo słuszności - pomijając kwestie polityczne i cenzorskie, każdy człowiek na świecie może mieć w ten sposób dostęp do materiałów z innych zakątków planety i komunikować się z obcokrajowcami tak "blisko", jak czyni to z rodakami. Jednak należy pamiętać, że nie oznacza to, że wszyscy internauci rozmawiają w jednym języku (chyba że jest to język memów). Co prawda, ostrożnie można założyć, że dominującą mową jest angielska (mimo że pewnie w Chinach czy Rosji mieszkańcy pokazaliby inne wskaźniki), ale większość z nas milej patrzy na treść dostępną w rodzimym języku. Prowadzi nas to do tego samego wniosku, który już dawno, dawno temu miały osoby zajmujące się tworami kultury - treść można i warto tłumaczyć.

Jednak to, o czym dzisiaj będziemy pisać, a więc internacjonalizacja, jest szerszym pojęciem. Oczywiście, większość z nas utożsamia go z translacją językową, jednak to trochę tak, jak w kinematografii - czym innym jest tłumaczenie, a czym innym adaptacja, czego dobrym przykładem jest chociażby Shrek. Internacjonalizacja to bardzo ciekawe zagadnienie, które jednak nie zawsze jest dobrze rozumiane, także przez klientów, w efekcie czego przy tworzeniu aplikacji pojawiają się czasem nieporozumienia. Postaram się dzisiaj rozwiać większość wątpliwości.

Czym jest internacjonalizacja?

Zacznijmy od tego, że "internacjonalizacja" jest długim słowem i z tego powodu często skraca się ją do "i18n", co jest innym zapisem angielskiego terminu internationalization. Liczba 18 wyjaśni się po policzeniu środkowych liter. Ale wracając do meritum - czym to właściwie jest?

Internacjonalizacja to proces projektowania lub przystosowania oprogramowania do obsługi różnych wersji językowych. Do tego obszaru zalicza się nie tylko samo wprowadzenie sformułowań w innym języku, ale też między innymi:

  • obsługa wyboru (ręcznego i automatycznego) języka dla danego użytkownika,
  • dostosowanie interfejsu do różnej długości słów w odpowiednich wersjach,
  • zastosowanie odpowiedniego kodowania znaków,
  • dopasowanie sposobu wyświetlania tekstu, np. dla języka arabskiego, gdzie obowiązuje zapis od prawej do lewej (RTL),
  • (w grach) umożliwienie dopasowania ruchu ust i animacji do wersji językowej.

Gracze komputerowi mogą kojarzyć podobne kwestie z wywiadów z polskimi studiami lokalizującymi popularne tytuły, gdzie w ramach ciekawostek poruszane są takie tematy jak rozszerzanie ramek, aby tekst się zmieścił czy dostosowanie form związanych z płcią. Natomiast nieprzypadkowo użyłem tutaj terminu "lokalizacja" - jest to bowiem słowo określające dostosowanie do konkretnego języka. Mówiąc inaczej - za internacjonalizację powinni odpowiadać twórcy oprogramowania, którzy projektują "narzędzia" umożliwiające lub ułatwiające późniejszą pracę osobom przeprowadzającym lokalizacje (w liczbie mnogiej, gdyz języków może być wiele).

Ponieważ localization również jest dość długim słowem, także tutaj w powszechnym użyciu funkcjonuje odpowiedni skrót, tym razem "l10n". Takich terminów jest dużo więcej, a wśród nich można znaleźć choćby accessibility, czyli dostępność (dla osób z niepełnosprawnościami) oznaczaną jako "a11y". Więcej takich krótszych określeń można znaleźć choćby w tej prezentacji.

Jeszcze warto wspomnieć o dość oczywistej rzeczy - internacjonalizacja jest powszechną praktyką w przypadku otwierania się na inne rynki i wyciągnięcia ze swojego oprogramowania maksimum wartości. Nie oznacza to, że przetłumaczenie aplikacji na np. angielski od razu przyniesie sukces, ale lepiej się na to przygotować i najwyżej nie skorzystać. Do tego jeszcze dzisiaj dojdziemy.

Jak wygląda internacjonalizacja od strony programisty?

Tak, jak wyżej wspomnieliśmy, to zespół realizujący oprogramowanie najczęściej odpowiada za przygotowanie go do obsługi wielu języków. Przy czym nie ma tutaj znaczenia, ile ich będzie - jeśli potrzebna jest internacjonalizacja dla dwóch wersji językowych, to przebiega ona tak samo, jakby była przygotowywana dla kilkunastu. Pewną różnicą jest natomiast projektowanie pod wersje stosujące inny alfabet (np. cyrylicę) lub kultury (np. arabska), gdzie pracy jest nieco więcej z uwagi na dostosowanie kodowania i interfejsu. Należy jednak wspomnieć, że różne frameworki, które są używane do tworzenia oprogramowania, dostarczają narzędzia pomagające w tego typu pracach i wiele z nich rozwiązuje problemy za programistów.

Trochę inaczej wygląda sprawa z wykrywaniem języka lub jego wybieraniem. Oczywiście, różne silniki zapewniają obsługę wielojęzyczności także na tym poziomie, jednak sam sposób wskazywania wersji pozostaje w gestii zespołu, nie tylko programistów, ale też UX-owców. W aplikacjach widać wiele sposobów wizualizacji wielojęzyczności w interfejsie - kliknięcie jednego z przycisków, flagi, rozwinięcie opcji, umieszczenie kontrolki w nagłówku, w stopce itd. Także wykrycie języka na podstawie przeglądarki może mieć większe lub mniejsze znaczenie, podobnie jak adresacja - widzimy strony zapisujące wybrany język w przeglądarce użytkownika, jak i takie, które wprowadzają symbol do adresu, co wiąże się z dostosowaniem routingu. Frameworki bardzo pomagają, jednak nie zrobią wszystkiego za programistę. Warto tutaj przy okazji wspomnieć, że odradzane jest wykorzystywanie flag do wyboru języka, choćby ze względu na to, że użytkownik wybiera właśnie język, a nie kraj. W wielu przypadkach jest to tożsame, ale np. taki Brytyjczyk może mieć opory przy wybraniem flagi amerykańskiej, a Austriak - przy zobaczeniu jedynie fladze niemieckiej.

Inną kwestią jest takie zaprojektowanie interfejsu (ponownie we współpracy z grafikami i UX-owcami), aby w przypadku dłuższych tekstów opcji nadal mieściły się one w wyznaczonych ramach. Klasycznym przykładem jest menu, które najczęściej składa się z kilku przycisków lub linków ustawionych równo obok siebie i "obliczonych" na pewną odległość od siebie. Często zdarza się, że po zlokalizowaniu na inny język (np. hiszpański) wszystko zaczyna wyglądać nienaturalnie ciasno lub wręcz nakłada się na siebie. Niestety, niezależnie od tego, jak wiele czasu się nad tym spędzi, nigdy nie można przewidzieć wszystkich przypadków, dopóki nie będzie się miało konkretnych tekstów w danym języku. Dlatego etap dostosowywania interfejsu najczęściej ma miejsce po uzyskaniu konkretnych tłumaczeń i polega na przygotowaniu poprawek typowo pod daną wersję.

A jak wygląda samo wprowadzanie tłumaczeń do oprogramowania? Tak, jak wspomniałem, dzięki frameworkom jest to zwykle stosunkowo proste. Troszkę nawiązywałem do tego przy okazji rozpisywania się o systemie komentarzy, a poniżej pokażę, jak to wygląda w przypadku silnika, z którego najczęściej korzystamy w Wilda Software w chwili pisania tego tekstu, a więc Yii 2.0.

Weźmy pod uwagę następujący przykład:

<h1>Twoje dane</h1>
<div>Trofea: <?= $trophyCount ?></div>
<div>Twój język: PL</div>

Taki kod HTML (a właściwie PHP, gdyż widać wstawkę z tego języka) jest poprawny, ale nieprzygotowany do internacjonalizacji - wszystkie teksty są wpisane wprost (jak to się mówi kolokwialne, "na sztywno") i tak samo zostaną wyświetlone osobie oczekującej wersji polskiej, jak i takiej wybierającej opcję angielską. Dlatego przygotujmy ten kod do i18n:

<h1><?= Yii::t('app', 'yourData') ?>:</h1>
<div><?= Yii::t('app', 'yourTrophies {n}', ['n => $trophyCount]) ?></div>
<div><?= Yii::t('app', 'yourLanguage {lang}', ['lang' => strtoupper(Yii::$app->language)]) ?></div>

Cóż, gołym okiem widać, że kod stał się bardziej skomplikowany i pojawiło się więcej wstawek PHP-owych. Metoda Yii::t odpowiada za wstawienie w dane miejsce tekstu, który znajduje się w pliku z tłumaczeniami (zaraz go sobie pokażemy). Widać zatem, że tam, gdzie wcześniej znajdowały się "normalne" teksty, teraz to framework będzie odpowiadał za znalezienie odpowiedniej wersji i wczytanie jej. Jednak sam mechanizm jest znacznie bardziej rozbudowany - umożliwia np. podział tłumaczeń na kategorie, co jest ważne w przypadku bardzo dużych aplikacji z wieloma tekstami. W powyższym przykładzie akurat używamy tylko jednej, domyślnej kategorii, którą jest "app", co oznacza, że komunikaty są zgromadzone w pliku app.php. Są one identyfikowane poprzez klucze, dopiero pod którymi znajdują się właściwe tłumaczenia. Natomiast powyższy przykład pokazuje też parametryzowanie tłumaczeń poprzez możliwość podstawienia odpowiednich zmiennych. Sam Yii 2.0 oferuje również mechanizmy do odmian mnogości czy formatowania podstawowych typów danych.

Zobaczmy zatem, jak wyglądają pliki z konkretnymi tekstami, które znajdują się w konkretnym folderze w aplikacji:

// zawartość pliku messages/pl/app.php

return [
	'yourData' => 'Twoje dane',
	'yourTrophies {n}' => 'Trofea: {n}',
	'yourLanguage {lang}' => 'Twój język: {lang}',
];

// zawartość pliku messages/en/app.php

return [
	'yourData' => 'Your data',
	'yourTrophies {n}' => 'Trophies: {n}',
	'yourLanguage {lang}' => 'Your language: {lang}',
];

Jak widać, teksty są zgromadzone w jednym miejscu (przynajmniej w teorii), dzięki czemu można łatwo je modyfikować i później tłumaczyć. Warto wspomnieć, że teoretycznie zamiast kluczy można używać konkretnych tekstów w domyślnym języku, jednak nie jest to polecane, gdyż w przypadku zmian modyfikacja musi nastąpić nie tylko w powyższym pliku, ale także we wszystkich miejscach, gdzie został użyty dany wpis.

Widać też, że Yii 2.0 oferuje możliwość pozyskania aktualnie aktywnego języka (Yii::$app->language) oraz ma odpowiednie mechanizmy do ich ręcznego i automatycznego ustawiania. Oczywiście, nie tylko ten framework to potrafi - np. Angular, wykorzystywany najczęściej we frontendach, ma swój moduł, dzięki któremu tłumaczone wpisy korzystają z plików JSON i są wstawiane w następujący sposób: {{ 'app.yourData' | translate }}. Z kolei Laravel ma jeszcze krótszy zapis: __('yourData').

Jak przebiega tłumaczenie?

Wspomniałem wyżej o tym, że teksty są zgromadzone w jednym miejscu, który zawiera minimum kodu, a właśnie skupia się głównie na treści wiadomości. Ten zbiór jest zwykle wysyłane do tłumaczy, którzy przekładają go na konkretny język, po czym odsyłają zmieniony plik, gotowy do wprowadzenia do aplikacji. Brzmi prosto, ale także tutaj trzeba powiedzieć o kilku rzeczach.

Pierwsza i podstawowa sprawa - jeśli nie zostało ustalone inaczej, software house nie odpowiada za samo tłumaczenie. Wspominałem wyżej, że zespół IT przygotowuje internacjonalizację, czyli m.in. możliwość wprowadzenia tekstów w innym języku. Natomiast to nie oznacza, że programiści siądą i sami przeprowadzą translację na pożądany przez klienta język, nawet jeśli go znają. Dotyczy to także angielskiego, choć wiadomo, że ten jest powszechny w świecie IT i siłą rzeczy programista przy okazji wprowadzania domyślnych tekstów w ojczystej mowie mógłby też wstawiać je po angielsku. Jednak nie ukrywajmy - ta osoba odpowiada za inne rzeczy, bez których oprogramowanie nie będzie poprawnie działać, a zmuszony do samodzielnej translacji po prostu skorzysta z Google Translate. Dlatego to zazwyczaj klient wprowadza swoją firmę tłumaczącą, podczas gdy zadaniem firmy IT jest ułatwić ten proces ekspertom.

Kolejna rzecz to weryfikacja sformułowania "jedno miejsce" - nie zawsze jest możliwe, aby wszystkie teksty stosowane w systemie znajdowały się w wyznaczonym pliku lub folderze. Teksty mogą być podzielone na frontend, backend czy panel administratora, a także być przechowywane w bazie danych przy odpowiednich tzw. tabelach słownikowych. Dlatego tłumacze zazwyczaj dostają nie jeden plik, tylko kilka o różnym formacie. Co rodzi podstawowy problem.

Mianowicie każde techniczne formatowanie (JSON, tablica PHP itd.), nawet dość proste, nie zawsze jest łatwe do "odczytania" dla lokalizatorów. Oczywiście, programiści dostarczają odpowiednie instrukcje, jednak należy pamiętać o tym, że w tekstach mogą pojawić się znaczniki HTML, parametry, znaki specjalne, a także sama konstrukcja plików niekiedy sprawia trochę problemów. Z doświadczenia wiemy, że zawsze są potrzebne poprawki "potłumaczeniowe", które wydłużają czas pracy. Najbezpieczniejszą formą jest arkusz kalkulacyjny, jednak wówczas to software house musi zadbać o konwertery, które wprowadzą dane teksty do aplikacji.

Każdy tłumacz wie, że niezmiernie ważny jest kontekst. Istnieją słowa lub sformułowania, które oznaczają różne rzeczy w danym języku (np. "zamek" w języku polskim), ale w innym każde z nich posiada już inną translację. Z tego powodu tłumacze powinni znać oprogramowanie, które tłumaczą lub przynajmniej omówić to z software housem czy klientem. Wiadomo jednak, że po pierwsze, nie zawsze jest na to czas, a po drugie - niekiedy nie wiadomo, czy dana kwestia faktycznie jest problematyczna (to tzw. wiedza ukryta). Ten kłopot zwykle objawia się w dziełach fabularnych, ale również zdarza się w aplikacjach.

Ostatnia kwestia dotyczy... końca. Z uwagi na to, że oprogramowanie może dynamicznie się rozwijać, dotyczy to także zbioru tekstów. Z tego powodu może się okazać, że sesji tłumaczenia będzie kilka i w czasie, kiedy poprzednia partia zostaje oddana, zostały już stworzone nowe komunikaty i to nie zawsze na końcu pliku (wówczas łatwo byłoby je wyłuskać), ale też w środku, w miejscu oryginalnych tekstów. Dodatkowo, tłumaczenie na końcu ma sens także z powodu interfejsu i całościowego ocenienia, czy wszystkie komunikaty mieszczą się na ekranie i wyglądają estetycznie.

Czy w tłumaczeniu może pomóc AI?

W wielu dziedzinach życia i tworzenia oprogramowania sztuczna inteligencja już bardzo pomaga, a wielu z Was doskonale wie, że tłumaczenia to jeden z oczywistych obszarów, gdzie Google Translate czy DeepL wspiera prace nawet profesjonalnego tłumacza. Czy można jednak całkowicie oprzeć się na tych narzędziach i rezygnować z usługi żywego eksperta?

Jak się pewnie domyślacie, odpowiedź to "raczej nie". Z jednej strony zawsze pojawią się sytuacje, w których ludzkie zrozumienie kontekstu i wiedza człowieka będą nieodzowne. Z drugiej - rozwój AI i automatycznych translatorów sprawia, że już teraz są całkiem przyzwoite w tego typu działaniach. Na pewno są kołem ratunkowym w przypadku, kiedy do przetłumaczenia są teksty w obcym języku, a brakuje czasu oraz budżetu na profesjonalistów. Natomiast w celu przetłumaczenia całego portalu np. fintechowego miałbym duże wątpliwości przy poleganiu na takich narzędziach.

Co nie zmienia faktu, że są to znakomite systemy służące jako API i wykorzystywane do proponowania tłumaczeń tekstów wprowadzanych przez użytkowników, np. kiedy uzupełniają opisy produktów w aplikacji. Nie dość, że zapewniają dużą oszczędność czasu, to dodatkowo stanowią mocny punkt pod kątem marketingowym. Ważne jest jednak to, aby wykorzystywać je jako wsparcie, a nie całkowite zastępstwo żywego specjalisty.

Czy zawsze warto internacjonalizować?

To bardzo dobre pytanie. Z doświadczenia wiemy, że wiele aplikacji powstaje z myślą o lokalnym odbiorcy lub mają bardziej wewnętrzny charakter. Można zatem domniemywać, że są przypadki, kiedy internacjonalizacja będzie nieprzydatna i okazałoby się stratą czasu. Jednak także to samo doświadczenie podpowiada, że nawet wówczas w 90% przypadków warto założyć wprowadzenie i18n i są ku temu mocne podstawy.

Najważniejszym argumentem jest fakt, że o ile na początku oprogramowanie rzeczywiście może być wykorzystywane tylko w lokalnym języku, to w równie wielu przypadkach klient w przyszłości zapragnie wprowadzić je na inny rynek, co wymaga tłumaczenia. Ale nie tylko o inny rynek chodzi - także aplikacje tworzone z myślą o konkretnych firmach muszą założyć, że nie wszyscy pracownicy tej firmy (a więc potencjalni użytkownicy) pochodzą z danego regionu. Doskonałym przykładem jest Polska, w której w wielu zakładach pracy w latach 2010-2022 znacznie zwiększyło się zatrudnienie osób zza wschodniej granicy, co sprawiło, że przydatne okazało się wprowadzenie lokalizacji ukraińskiej czy białoruskiej w celu ułatwienia pracy obcokrajowcom. Gdyby nie myślano o internacjonalizacji od początku, taka potrzeba wiązałaby się z ogromną pracą w aplikacji.

A to jest bez sensu, ponieważ w większości przypadków internacjonalizacja jest po prostu łatwa. Oczywiście, nadal wiąże się z pewną pracą do wykonania i wymaga pewnych kompromisów, ale raz wprowadzona przez większość czasu nie wymaga "opieki" podczas realizacji innych funkcji w aplikacji. Dlatego powinno się ją włączać od samego początku, kiedy oprogramowanie dopiero nabiera kształtów, aby wszyscy przyzwyczaili się do korzystania z i18n. Dużo łatwiej zrobić to wtedy niż internacjonalizować już gotowy program. Oczywiście, podchodząc do tego rozsądnie - jeśli wiemy, że nie będziemy obsługiwać np. języków azjatyckich, nie warto poświęcać długich godzin na przygotowywanie wersji RTL (czytanej od prawej do lewej).

Wprowadzanie internacjonalizacji w trakcie zaawansowanych prac ma jeszcze jedną dużą wadę - znajdowanie w kodzie miejsc, w których teksty zostały wpisane "na sztywno" i zamienianie ich na wersje tłumaczone to niezwykle żmudna i czasochłonna praca, która potrafi zniechęcić. Nie zawsze widać takie wiadomości od razu i oznacza to wnikliwe przeglądanie każdego pliku oraz przenoszenia tekstów w odpowiednie miejsce.

Oczywiście, istnieją przypadki, kiedy wiadomo, że aplikacja zostanie tylko w jednym języku. Przykładem są wewnętrzne aplikacje dla konkretnego, bardzo wąskiego grona odbiorców lub wręcz tymczasowe programy, np. wspomagające krótkotrwałe eksperymenty naukowe. Wówczas można pokusić się o pominięcie internacjonalizacji, jednak są to sytuacje szczególne i należy traktować je jako wyjątki.

Podsumowanie

Internacjonalizacja to z jednej strony temat bardzo prosty, a z drugiej dość głęboki, szczególnie w dużych aplikacjach nastawionych na globalny rynek. Najważniejszy wniosek z artykułu powinien być taki, że przy użyciu odpowiedniego frameworku, lokalizacje oprogramowania są stosunkowo proste (co nie oznacza, że nieczasochłonne), a także że warto zakładać różne wersje językowe od początku.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Czym się różnią rooting i routing? https://wildasoftware.pl/post/czym-roznia-rooting-routing?ref=rss https://wildasoftware.pl/post/czym-roznia-rooting-routing?ref=rss Thu, 22 Jun 2023 17:30:00 +0000 Jakiś czas temu przeglądałem opis projektu przygotowany przez klienta, który chciał w ten sposób wyjaśnić metodę działania swojej firmy i to, w jaki sposób system informatyczny ma pomóc w usprawnieniu określonych procesów biznesowych. Całość była związana z dużymi urządzeniami połączonymi ze sobą i przedstawione materiały dotykały różnych obszarów działalności spółki w kontekście właśnie tych urządzeń. W jednym miejscu pojawiło się pojęcie, które oryginalnie było zapisane jako "rooting maszyn". Co prawda, moja wiedza na temat tej dziedziny jest dość skromna, ale od razu coś przestało mi tutaj się zgadzać. Z kontekstu wynikało bowiem, że chodzi o tzw. marszrutę, czyli wykonywanie czegoś w określony sposób, konkretną ścieżką działań. Tylko że uważny obserwator w tym przypadku wspomni, że chodzi o "routing maszyn".

Pozornie niewielka różnica i z kontekstu wiadomo, o co chodzi, ale jest to okazja do wyjaśnienia, czym sie różni "rooting" od "routingu" i dlaczego warto uważać z tą jedną literką w środku. Wbrew pozorom zmienia ona bardzo dużo i to mimo że te słowa wymawia się podobnie lub wręcz identycznie.

Co to jest rooting?

Aby odpowiedzieć sobie na to pytanie, musimy wiedzieć, czym jest root, oczywiście, w informatyce. Jest to pojęcie wywodzące się z systemów uniksowych i oznacza głównego użytkownika systemu, superadministratora. Najczęściej mówiąc "mam roota" mamy na myśli posiadanie całkowitej kontroli nad systemem. Z jednej strony pozwala to nie martwić się o to, że czegoś nie będziemy mogli wykonać - skoro mamy wszystkie uprawnienia, to posiadamy także pełną gamę możliwości i wszystko, co oferuje nam sam system. Z drugiej strony, "z wielką mocą wiąże się wielka odpowiedzialność" i osoba będąca rootem może spowodować niesamowite szkody, jeśli nie wie, co robi lub zwyczajnie się pomyli. Jest to użytkownik traktowany na specjalnych zasadach, który może nawet omijać polecenia wskazujące, że to, co właśnie robi, wymaga praw superużytkownika, a zatem nie istnieje żadne ostrzeżenie przed wykonaniem operacji pozornie destrukcyjnych.

Dlatego dużo częściej pracuje się na użytkownikach o prawach roota, czyli takich, którzy mają odpowiedni poziom dostępu, jednak wymagają podania komendy sudo, będącej niejako potwierdzeniem, że wykonywana jest operacja chroniona lub na zasobach chronionych. Jednak, poza tym faktem, taka osoba jest nadal zwykłym userem, który ma swój katalog domowy w /home. Istnieje też możliwość przełączenia się na konto typowego roota poprzez sudo su ("su" od superuser), jednak przestrzegamy przed tym - może jest to wygodne w momencie, kiedy wykonujemy wiele operacji wymagających większych przywilejów, jednak w ten sposób popełnienie błędu jest bardziej prawdopodobne. Zachęcamy do doczytania o tym obszarze, nawet w wątkach w społecznościach związanych z Stack Overflow.

Wiemy już zatem, czym (a właściwie kim) jest root. A czym jest rooting lub po polsku "rootowanie"? To odblokowanie urządzenia w taki sposób, że nabywamy prawa superużytkownika i, co więcej, dostajemy się do ukrytych wcześniej funkcji, gdyż nie ogranicza nas nakładka systemowa producenta. Dodatkowo, rootowanie wiąże się z odblokowaniem tzw. bootloadera, co stanowi drogę do zainstalowania innej wersji systemu operacyjnego na urządzeniu mobilnym. To właśnie z nimi najczęściej wiąże się to pojęcie, a dokładniej z telefonami z Androidem, których nie da sie już w inny sposób zaktualizować lub chcemy zmodyfikować standardowe oprogramowanie. Należy pamiętać o tym, że rootowanie nie jest "naturalne", tzn. może wiązać się z zagrożeniem dla naszego urządzenia (w tym tzw. brickowaniem, czyli "unieruchomieniem" go), a na pewno w ten sposób tracimy gwarancję.

Jest to temat szeroki i wiąże się z dużą wiedzą o systemach operacyjnych. O samym rootowaniu, jego zaletach i wadach traktuje ten artykuł w "Komputer Świat", natomiast jeśli chcecie spróbować innego systemu mobilnego na swoim smartfonie lub tablecie z Androidem, Tomasz Dunia pokazał proces dla Ubuntu Touch oraz Droidiana.

Co to jest routing?

Po polsku to pojęcie spolszczane jest często do "rutingu", jednak puryści językowi zapewne prędzej użyją terminu "trasowanie". Jest to wyznaczanie trasy i poprowadzenie nią danego obiektu. To słowo spotyka się w co najmniej dwóch obszarach w informatyce, z których jeden jest dominujący.

Jest to routing pakietu, który ma przedostać się w sieci od jednego komputera do drugiego. Nie jest to proces prosty, biorąc pod uwagę fakt, że maszyny najczęściej znajdują się w różnych sieciach lokalnych, są ukryte za NAT-em oraz urządzeniami zwanymi właśnie routerami. To one służą ustalaniu trasy paczki danych i skutecznemu określeniu adresu odbiorcy. Oczywiście, w procesie najczęściej bierze udział wiele routerów - oprócz tych urządzeń po stronie nadającego i odbierającego, po drodze znajdują się maszyny pośredniczące, związane choćby z dostawcami internetowymi (ISP) lub serwerowniami. Aby przekonać się, jak skomplikowana jest droga od naszego komputera do np. google.pl, wystarczy w konsoli wpisać tracert google.pl (w Windowsie) lub traceroute google.pl (w Linuxie).

Oprócz tego routery najczęściej pełnią też rolę switcha, tj. są rozdzielaczem sygnału sieci na kilka komputerów. Jednak sam routing to właśnie ustalanie i realizacja trasy pakiety. Mamy więc w sieci punkt dostępowy, z którym się komunikujemy bezpośrednio, a on odpowiada za dalsze przesyłanie wiadomości na zewnątrz i ich odbiór. Dlatego sprawny router to podstawa efektywnego dostępu do Internetu w naszym domu lub firmie.

Drugi obszar, w którym mamy do czynienia z routingiem, związany jest z aplikacjami i sposobem, w jaki następuje "obliczenie" adresu URL wpisanego przez użytkownika. Przykładowo, jeśli otworzycie następujący link:

https://wildasoftware.pl/post/gucio-jego-zaby-wytrwalosc-programistow

to najpierw nastąpi trasowanie do samej aplikacji ukrytej za adresem wildasoftware.pl, a następnie już w aplikacji (napisanej w Laravelu) znajdują się reguły, według których adres /post/:symbol kieruje do odpowiedniego kontrolera oraz metody, przekazując parametr :symbol. W Yii 2.0, z którego korzystamy przy tworzeniu aplikacji dla naszych klientów, reguła routingu /product/api/count oznaczałaby, że po wejściu na stronę aplikacja skieruje się do modułu product, następnie kontrolera ApiController oraz znajdującej się w niej metody actionCount. Określenie dobrych zasad routingu nie jest proste, ale dobrze zrobione pozwalają zachować porządek, a jednocześnie od razu wskazać programiście miejsce, w którym powinien szukać interesującego go/ją kodu.

Nawiasem mówiąc, samo trafienie żądania do wildasoftware.pl to też przykład routingu, tylko najpierw na poziomie samej sieci w celu ustalenia adresu właściwej maszyny (kłania się tutaj protokół DNS), a potem serwera, w celu skierowania do właściwego folderu z aplikacją (dzięki mechanizmowi wirtualnych hostów lub bloków serwerowych).

Routing jest na tyle ogólnym pojęciem, że wychodzi daleko poza informatykę. Przykładem jest choćby przywołana marszruta w zakładzie produkcyjnym, czyli zbiór wszystkich operacji (rozumianych bardzo szeroko), które w odpowiedniej kolejności doprowadzają do utworzenia produktu. Także w tym przypadku mamy informacje, w jakim porządku i w jakich punktach musi się zatrzymywać dany obiekt, aby proces produkcji mógł przebiegać prawidłowo. Oczywiście, wiąże się też z tym zjawisko optymalizacji takiej procedury, jednak jest to osobny temat. Trasowanie jest też terminem spotykanym w logistyce i transporcie, gdzie wiąże się z określeniem efektywnej drogi dystrybucji danego towaru wśród różnych punktów. Tutaj jednak mamy punkt styczny z informatyką, gdyż w tym obszarze są stosowane właśnie różne algorytmy i metody komputerowe, optymalizujące przebytą drogę. Studenci studiów informatycznych doskonale znają zapewne problem komiwojażera, ale z tym tematem związany jest też cała dziedzina badań operacyjnych i algorytmiki.

Podsumowanie

Jak widać, "rooting" i "routing" to pojęcia brzmiące bardzo podobnie, ale o zupełnie różnym znaczeniu. Ten pierwszy związany jest z systemami operacyjnymi oraz uprawnieniami, a drugi - z sieciami komputerowymi lub procesami, w których zachodzi potrzeba zaplanowania jakiejś trasy lub sekwencji operacji. Warto pamiętać o tej różnicy, gdyż, co prawda, specjaliści zwykle doskonale zrozumieją, o co chodzi i że użycie złego słowa to zwyczajna literówka, jednak w niektórych przypadkach może mieć to duże znaczenie.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Komentarze na blogu z użyciem Mastodona - część 2. https://wildasoftware.pl/post/komentarze-blogu-uzyciem-mastodona-cz2?ref=rss https://wildasoftware.pl/post/komentarze-blogu-uzyciem-mastodona-cz2?ref=rss Thu, 15 Jun 2023 17:30:00 +0000 Poprzednio omówiliśmy koncepcję stworzenia systemu komentarzy na blogu lub stronie internetowej przy użyciu Mastodona. Konkretnie zrobiliśmy wprowadzenie w temat i wyświetlaniem takich postów wraz z wyjaśnieniem, dlaczego ta koncepcja może być kusząca. Jeśli przeoczyliście ten tekst lub chcecie go sobie odświeżyć, to link do niego znajdziecie tutaj. Tymczasem, bez zbędnej zwłoki, zapraszamy Was do drugiej części, w której zajmiemy się dodawaniem komentarzy z poziomu blogu, oczywiście, nadal za pośrednictwem Mastodona. Przy okazji opowiemy sobie trochę więcej o federacyjności, jaka cechuje to medium społecznościowe.

Na początku omówimy parę kwestii teoretycznych, także jeżeli nie czujecie się nowicjuszami w kwestii obsługi Fediverse lub OAuth 2.0, to śmiało możecie pominąć te sekcje i przejść od razu do przykładu implementacji.

Dlaczego dodanie komentarzy nie jest łatwe?

W większości funkcji realizowanych w przeróżnych aplikacjach, wyświetlanie jest łatwiejsze od wprowadzania danych. Jest to związane z tym, że pokazanie informacji na ekranie zazwyczaj wymaga jedynie wywołania żądania GET i odpowiedniego ustrukturyzowania oraz ostylowania wyników. Z kolei przy dodawaniu lub aktualizowaniu danych potrzebne są m.in. obsługa formularza, walidacja, wyświetlenie błędów oraz w końcu zapisanie wartości w konkretnej formie. A teraz wyobraźmy sobie, że to ostatnie musimy robić korzystając z zewnętrznego API.

Tak jest właśnie z Mastodonem, ale oczywiście, nie jest on wyjątkiem - każdy system stojący na jego miejscu byłby odbierany tak samo. Kolejną rzeczą, którą musimy się zająć, jest autoryzacja użytkownika, który chce dodać wpis. W tak dużych systemach, które pozwalają na SSO (ang. Single Sign-On - jeszcze dzisiaj do tego wrócimy) nie ma mowy, aby podczas korzystania z API w żądaniu wysyłać po prostu hasło. Raz, że mogą ogarnąć nas wówczas wątpliwości związane z bezpieczeństwem (choć protokół HTTPS jest tutaj naszym przyjacielem), a dwa, że nie ma potrzeby, aby użytkownik podawał swoje hasło do zewnętrznego serwisu na np. naszej stronie i się tym stresował. Dlatego czeka nas nauka korzystania z OAuth 2.0.

Najpierw jednak musimy zmierzyć się z jeszcze jedną kwestią, która już wprost odnosi się do Mastodona, a raczej całego Fediverse - federacyjną, rozproszoną konstrukcją całego systemu. W przypadku np. Twittera odniesienie się do serwisu byłoby względnie proste - istnieje jeden serwer (ponownie - wiadomo, że to farma serwerów, ale nie jest to interesujące z naszego punktu widzenia) i jeśli ktoś chce skorzystać ze swojego konta na Ćwierkaczu, to mamy jeden punkt dostępowy, do którego musimy się udać (twitter.com). W przypadku Mastodona nie jest już to takie oczywiste - każdy użytkownik odwiedzający nasz blog, który chce skomentować artykuł, może mieć konto na innej instancji. Na szczęście, posiadają one to samo API, jednak musimy być świadomi tego, że token autoryzacyjny pobrany dla jednego serwera nie zadziała na innym. Tym problemem też się dzisiaj zajmiemy.

Federacyjna natura pokazuje też inny problem - dystrybucję postów pomiędzy instancjami. Tutaj musimy na chwilę się zatrzymać.

Jak rozgłaszany jest wpis w Mastodonie?

W scentralizowanym systemie wszystko jest w miarę proste - użytkownik loguje się do serwisu, uzupełnia treść wpisu, klika "wyślij" i post jest wysyłany na serwer. Każdy użytkownik, który go zobaczy, widzi dokładnie tę paczką danych, która została oryginalnie opublikowana oraz pod tym samym identyfikatorem, co wszyscy inni odbiorcy. Dzięki temu łatwo można komuś wysłać do link do wiadomości, gdyż taki odnośnik jest jeden. A jak jest w systemie sfederowanym? Sprawa się trochę komplikuje i ma to dla nas znaczenie.

Idea federacji opiera się na tym, że poszczególne instancje są niezależnymi bytami, ale pozwalają komunikować się użytkownikom ze sobą tak, jakby był to jeden organizm. Czyli jeśli użytkownik z instancji A napisze post, to mogą zobaczyć go nie tylko użytkownicy instancji A, ale także te osoby z instancji B, które obserwują tego użytkownika (w uproszczeniu). Działa tutaj normalna zasada serwisów społecznościowych - jeśli kogoś obserwujemy lub ktoś, kogo obserwujemy, poda dalej toota lub wejdziemy wprost do danej rozmowy, to możemy zobaczyć wpisy z innej instancji. Co prawda, czasem odczuwalne jest pewne opóźnienie, ale w konsekwencji będzie to działać. Tylko że technicznie te wpisy nie są tymi samymi, co oryginalne.

Wyobraźmy sobie sytuację, w której jesteśmy na instancji A i przeglądamy jakiś post z naszego macierzystego serwera kub zwyczajnie wyświetlamy naszą oś czasu (ang. timeline). Możemy robić to wiele razy dziennie i najczęściej widzimy tam wpisy nie tylko opublikowane na instancji A, ale też takie, które trafiły do nas z instancji B, C, D itd. W podstawowym przypadku nasza kopia Mastodona powinna za każdym razem sprawdzać inne instancje, aby zorientować się, które posty pobrać. Jednak bez żadnych eksperymentów możemy powiedzieć, że jest to bez sensu - przy systemie, który obsługuje tysiące użytkowników (największe instancje mają po kilkaset tysięcy), pobieranie dla każdej osoby w każdej sytuacji danych z zewnątrz to prosta droga do kłopotów z wydajnością (a wręcz uniemożliwienia normalnego działania i to nie tylko "naszej" maszyny). Z tego powodu tooty oraz informacje o profilach z innych instancji są kopiowanie na każdej instancji, na której zostały wyświetlone. Oczywiście, nie działa to idealnie, jednak takie cache'owanie jest dużo lepszym rozwiązaniem niż odwoływanie się za każdym razem do źródła. Wraz z kopią zapisywane są odnośniki do oryginału, dzięki czemu w określonych momentach następuje aktualizacja danych, jeśli np. oryginalny wpis uległ edycji.

Najważniejsza nauka, która z tego płynie i przyda nam się w dalszych działaniach, to wiedza o tym, że toot na oryginalnej instancji i na innych może mieć zupełnie inne identyfikatory. Przykładem niech będzie ten, zapoznawczy wpis Wilda Software na naszej instancji. W oryginalne link do niego wygląda następująco:

https://social.wildasoftware.pl/@wilda/110010384660147893

Natomiast gdy ten wpis ogląda ktoś np. z instancji 101010.pl, to widzi już inny adres:

https://101010.pl/@wilda@social.wildasoftware.pl/110010384696884554

Łatwo można poznać, że nie jest to toot z obecnego serwera - do nazwy użytkownika została doklejona domena, natomiast widzimy również inny identyfikator na końcu. Nie jest to dziwne, ponieważ różne instancje mają swoje osobne bazy danych, a więc także inną sekwencję numeracji - jeśli na instancji A post dostał ID = 10, to nie możemy oczekiwać, że po pobraniu na instancję B, C czy D tam również ten ID będzie dostępny lub następny w kolejności. Na każdym serwerze numerek będzie inny, ale treść pozostanie taka sama.

A kiedy w ogóle nasze wpisy są kopiowane na instancję A? W uproszczeniu są to momenty, kiedy są odpowiedziami na toot z instancji A (nawet na kopię tego toota), kiedy ktoś na instancji A nas obserwuje lub jest to prywatna wiadomość. Nie zawsze to działa od razu - swego czasu, gdy mastodon.social (największa instancja Mastodona z opieką samego twórcy) miał potężne problemy wydajnościowe, wpisy stamtąd pojawiały się na innych instancjach z dużym opóźnieniem. Oczywiście, samo kopiowanie nie jest ideą związaną wyłącznie z Mastodonem - to koncepcja wywodząca się z ActivityPub, a więc interfejsu wiążącego wszystkie aplikacje fediwersowe, jak choćby Pixelfed, /kbin czy Friendica.

Jak widać, federacyjność nie jest prostą koncepcją i będzie stanowić pewną trudność w naszym zadaniu, jednak jak najbardziej działa i pozwala na skalowanie poziome całego systemu, zwiększając jego dostępność, a także wydajność (problemy z tym ostatnim dotyczą głównie bardzo dużych instancji, a więc w pewien sposób punktów starających sie wszystko centralizować). Czas teraz przejść do drugiego "kłopotu" - skorzystania z API z poziomu danego użytkownika, co oznacza zapoznanie się ze sposobem działania pewnego protokołu.

OAuth 2.0

W razie czego od razu zaznaczam - OAuth 2.0 nie ma nic wspólnego z ideą federacyjności. Jest to standardowy protokół autoryzacji użytkowników, który jest stosowany w wielu API oferowanych przez różne systemy informatyczne. Nie wszystkie - istnieją inne podejścia, w tym prostsze oparte o tokeny JWT (ang. JSON Web Token), które jest również szeroko stosowane i ma swoje zalety i wady, zresztą podobnie jak bohater tej sekcji. OAuth 2.0 zazwyczaj stosowany jest w sytuacji, gdy pragnie się osiągnąć tzw. logowanie jednokrotne, w skrócie SSO (ang. Single Sign-On), a więc logowanie się za pomocą jednego konta do wielu usług. W tym momencie niektórym może zapalić się lampka w głowie - przecież wiele stron oferuje uwierzytelnianie za pomocą konta Google'a, Facebooka czy Apple'a. Tak, tam też mamy do czynienia z OAuth 2.0 i chociaż zawsze będą istnieć różnice w integracji z takimi systemami (gdyż różni się implementacja samego protokołu), to ogólna zasada będzie podobna.

Formalnie ten protokół może być traktowany jako mechanizm autoryzacji przekazania dostępu do zasobów danego użytkownika. Mówiąc prościej - w ten sposób możemy zewnętrznej stronie (np. blogowi) udostępnić możliwość zapisu danych na Mastodonie za pośrednictwem naszego konta. Oczywiście, zastosowanie jest dużo szersze, jednak w naszym przypadku będzie to głównie możliwość dodawania tootów oraz odczytu wyników wyszukiwania i danych profilu.

Jak przebiega cały proces?

  1. Użytkownik na blogu wybiera opcję wykonania akcji za pomocą konta w zewnętrznym serwisie (Mastodonie). Najczęściej jest to zalogowanie się, ale w naszym przypadku będzie to udzielenie odpowiedzi na komentarz.
  2. Strona przenosi użytkownika do zewnętrznego dostawcy (konkretnej instancji Mastodona) z prośbą o autoryzację konkretnych typów operacji (tzw. scope'a). Jeśli osoba nie jest zalogowana, musi wpisać swoje dane uwierzytelniające (najczęściej adres e-mail oraz hasło).
  3. Zewnętrzny dostawca wyświetla informację o typach operacji, jakie blog potrzebuje do swoich celów (np. możliwość dodawania wpisów). Użytkownik potwierdza.
  4. Zewnętrzny dostawca generuje kod i wraca z nim do blogu na wyznaczony wcześniej adres (przesłany razem z prośbą o autoryzację).
  5. Blog na podstawie kodu (tokenu) może wykonywać kolejne operacje w imieniu konta użytkownika.

Tak, jak pisałem, to procedura ogólna i może się zmienić w zależności od potrzeb oraz zewnętrznego serwisu. Nieco inaczej będzie to wyglądało dla Google'a, a inaczej dla Mastodona. Tym niemniej, zasada działania jest podobna i prowadzi do potwierdzenia, że użytkownik zgadza się na użycie swojego konta w obrębie danego blogu czy strony internetowej w konkretnych celach. W naszym przypadku - potwierdza, że wpis, który dokona z poziomu naszego blogu, pojawi się w Fediverse pod jego kontem. Warto również zauważyć, że w większości przypadków udzielenie autoryzacji na dany zestaw operacji jest zapamiętywane na pewien czas i nie ma potrzeby np. potwierdzać swojej woli za każdym razem, gdy logujemy się kontem Google'a - w większości wypadków, jeśli robimy to regularnie, dzieje się to automatycznie.

Jeśli pragniecie poznać ten protokół bardziej szczegółowo lub skupić się na kwestiach związanych z żądaniami HTTP i bezpieczeństwem, a także dowiedzieć się, dlaczego nie powinien on służyć do samego uwierzytelnienia, to polecamy ten artykuł od Sekuraka.

Przykładowa implementacja

Uzbrojeni w wiedzę o tym, jak "roznoszą się" posty na Mastodonie i jak autoryzować w nim operacje, możemy przejść do przykładowej implementacji. Tak, jak poprzednio, skorzystamy z przykładu, który sobie wcześniej przygotowaliśmy w PHP, Laravelu oraz Bootstrapie i który dostępny jest w tym miejscu:

https://github.com/WildaSoftware/MastodonCommentSystem

Jeszcze raz podkreślę, że jest to przykładowa implementacja. Nie jest to biblioteka przygotowana do natychmiastowego zaczerpnięcia jej do swojego projektu ani ideał do którego należy dążyć. Jak najbardziej istnieje tutaj miejsce na swoją inwencję, poprawki, a przede wszystkim dostosowanie do systemu, w których system komentarzy ma zostać osadzony. Z miłą chęcią zobaczymy, w jaki sposób zaimplementowaliście swoje komentarze oparte o Mastodona na swoich blogach czy stronie - zawsze jest to okazja do wymiany doświadczeń.

Kroków przy dodawaniu komentarza jest trochę więcej niż przy ich wyświetlaniu. Dlatego nie będziemy na początku umieszczać planu ramowego całego procesu, tylko przejdziemy etap po etapie, aż do osiągnięcia celu.

Wywołanie procedury i wybór instancji

Na początku musimy pamiętać o tym, że w przeciwieństwie np. do Twittera, integracja z Mastodonem nie ma jasno przypisanego serwera - mogą trafić do nas użytkownicy korzystający z mastodon.social, pol.social, 101010.pl, wspanialy.eu czy z zupełnie innej instancji. Jest to ważne, ponieważ determinuje to serwer, na którym znajduje się konto danej osoby, a co za tym idzie - miejsce wywołania API. Dlatego na początku użytkownik musi wybrać instancję. Zrealizujemy to poprzez wywołanie okna modalnego w reakcji na kliknięty przycisk odpowiedzi.

// fragment pliku blog-post-comment-box.blade.php

<div class="col-12 comment" ...>
    ...
    <div class="comment-reply-to row">
        <div class="col-12 text-right">
            <i class="comment-reply-link fa-solid fa-reply fa-lg" data-src="{{ $comment['url'] }}" title="{{ __('replyToThisCommentWithMastodon') }}"></i>
        </div>
    </div>
</div>

// fragment pliku blog-post.blade.php

<body>
	...
	<div class="modal fade" id="mastodon-reply-modal" tabindex="-1" role="dialog">
		<div class="modal-dialog modal-dialog-centered" role="document">
			<div class="modal-content">
				<div class="modal-header">
					<h5 class="modal-title">{{ __('enterMastodonDomain') }}</h5>
					<button type="button" class="close" data-dismiss="modal" aria-label="{{ __('closeModal') }}">
						<span aria-hidden="true">×</span>
					</button>
				</div>
				<div class="modal-body">
					<p>{!! __('provideMastodonInstanceToReply') !!}</p>
					<input type="hidden" id="mastodon-src-reply"/>
					<input type="text" class="form-control" id="mastodon-domain-reply" placeholder="{{ __('provideMastodonInstanceShort') }}">
				</div>
				<div class="modal-footer">
					<button type="button" id="mastodon-reply-modal-confirm" class="btn btn-primary">{{ __('confirmModal') }}</button>
					<button type="button" id="mastodon-reply-modal-cancel" class="btn btn-secondary" data-dismiss="modal">{{ __('cancelModal') }}</button>
				</div>
			</div>
		</div>
	</div>

	<div class="modal fade" id="mastodon-reply-modal-failure" tabindex="-1" role="dialog">
		<div class="modal-dialog modal-dialog-centered" role="document">
			<div class="modal-content">
				<div class="modal-header">
					<h5 class="modal-title">{{ __('mastodonFailure') }}</h5>
					<button type="button" class="close" data-dismiss="modal" aria-label="{{ __('closeModal') }}">
						<span aria-hidden="true">×</span>
					</button>
				</div>
				<div class="modal-body">
					<p>{{ __('noMastodonConnectionDescription') }}</p>
				</div>
				<div class="modal-footer">
					<button type="button" id="mastodon-reply-modal-ok" class="btn btn-primary">{{ __('ok') }}</button>
				</div>
			</div>
		</div>
	</div>
	
	...
	
	<script src="<?= URL::to('/') ?>/js/post.js"></script>
	<script>
		(new PostScript(
			"<?= URL::to('/') ?>",
			<?= $post->id ?>,
			<?= json_encode($commentSourceIds) ?>,
			<?= json_encode([
				'enterMastodonDomain' => __('enterMastodonDomain'),
			]) ?>,
			<?= !empty($mastodonCode) ? '"'.$mastodonCode.'"' : '' ?>
		)).init();
	</script>
</body>

// fragment pliku post.js

class PostScript {

    constructor(baseUrl, postId, commentSourceIds, translations, mastodonCode) {
        this.baseUrl = baseUrl + '/';
        this.postId = postId;
        this.commentSourceIds = commentSourceIds;
        this.translations = translations;
        this.mastodonCode = mastodonCode;

        this.isCommentContainerLoaded = false;
    }

    init() {
        $('#comment-container').on('click', '.comment-reply-link', (event) => {
            const savedDomain = localStorage.getItem('lastMastodonDomain');
            if(savedDomain) {
                $('#mastodon-domain-reply').val(savedDomain);
            }
            
            const src = $(event.target).data('src');
            $('#mastodon-src-reply').val(src);

            $('#mastodon-domain-reply').removeClass('error');
            $('#mastodon-reply-modal').modal('show');
        });

        $('#mastodon-reply-modal-confirm').on('click', (event) => {
            $('#mastodon-domain-reply').removeClass('error');
            
            const domain = $('#mastodon-domain-reply').val();
            const src = $('#mastodon-src-reply').val();
            if(domain && src) {
                $('#mastodon-reply-modal').modal('hide');
                localStorage.setItem('lastMastodonDomain', domain);
                localStorage.setItem('lastMastodonSrc', src);

                $.ajax({
						...
                    },
                    error: (err) => {
                        $('#mastodon-reply-modal-failure').modal('show');
                    }
                });
            }
            else {
                $('#mastodon-domain-reply').addClass('error');
            }
        });

        $('#mastodon-reply-modal-ok').click((event) => {
            $('#mastodon-reply-modal-failure').modal('hide');
        });
    }
	
	...
}

To tylko fragmenty plików, które interesują nas w danym momencie. Pierwsze, co widzimy, to fakt, że pod każdym komentarzem znajduje się ikonka, od której zaczyna się cała operacja - ma ona klasę HTML-ową comment-reply-link i w reakcji na nią pokazuje się okno modalne.

Zrzut ekranu komentarza na blogu wildasoftware.pl, gdzie w prawym dolnym rogu znajduje się zaznaczona ikonka rozpoczynająca udzielenie odpowiedzi
Okno modalne, w którym użytkownik jest proszony o podanie instancji Mastodona, na której posiada konto

Od razu chciałem zaznaczyć, że można to rozwiązać w inny sposób - zamiast okna modalnego można zdecydować się na listę rozwijaną, normalne pole tekstowe lub jeszcze inną implementację. Nie ma to żadnego znaczenia - my wykonaliśmy to taką metodą, ale równie dobra jest każda inna, która doprowadzi do wskazania poprawnej instancji. Poprawnej, ponieważ musimy się przygotować na to, że użytkownik może podać nieistniejący adres lub niebędący Mastodonem. Stąd u nas taka skomplikowana logika i obecność aż dwóch okien modalnych, z których jedno pozwala wpisać instancję, a drugie - poinformować o błędzie na etapie połączenia (do czego przejdziemy w kolejnym kroku). Dodatkowo, jeśli nie jest to pierwsza styczność użytkownika z systemem komentarzy na naszym blogu, zostanie przywołana wartość wpisana wcześniej i zachowana w local storage, czyli lokalnym magazynie danych przeglądarki. W reakcji na przycisk sprawdzamy, czy taka instancja została poprzednio podana i jeśli tak, odtwarzamy ją. Następnie, po potwierdzeniu przez użytkownika podania domeny, sprawdzamy ewentualne błędy (głównie pusty ciąg znaków) i jeśli wszystko jest w porządku - zapisujemy zaktualizowaną wartość oraz przechodzimy już do integracji z Mastodonem.

Uzyskanie aplikacji

W tym miejscu musimy powiedzieć sobie o trzech kwestiach. Po pierwsze, od tej pory będziemy intensywnie korzystać z API Mastodona, które zostało opisane tutaj, a konkretnie połączenie się z kontem Fediverse - tutaj. Po drugie, wszystkie żądania są wywoływane z poziomu JavaScriptu, ale przechodzą przez PHP-owy kontroler MastodonController, który będzie towarzyszył nam aż do końca. Wynika to z faktu, że po drodze będziemy korzystać z paru sztuczek optymalizacyjnych, które wymagają skorzystania z naszej bazy danych, a z tą pozwala się komunikować Laravel. W teorii jednak nic nie stoi na przeszkodzie, aby te żądania wywoływać bezpośrednio z poziomu JS-a.

Po trzecie, aby korzystać z API Mastodona, musimy mieć tzw. aplikację. Pod tym pojęciem kryje się zbiór danych uwierzytelniających (tzw. sekretów), które służą nam do wywołania kolejnych żądań. W przypadku jednej instancji można te dane utworzyć również ręcznie, w panelu swojego konta w Mastodonie. Jednak w naszej sytuacji nie wiemy, z którą instancją przyjdzie nam się komunikować, a przede wszystkim nie w każdej będziemy posiadać konto. Na szczęście, istnieje możliwość utworzenia takiej aplikacji "zdalnie", właśnie przez API.

// fragment pliku post.js

$('#mastodon-reply-modal-confirm').on('click', (event) => {
	$('#mastodon-domain-reply').removeClass('error');
	
	const domain = $('#mastodon-domain-reply').val();
	const src = $('#mastodon-src-reply').val();
	if(domain && src) {
		$('#mastodon-reply-modal').modal('hide');
		localStorage.setItem('lastMastodonDomain', domain);
		localStorage.setItem('lastMastodonSrc', src);

		$.ajax({
			type: 'GET',
			url: this.baseUrl + 'mastodon/app/' + domain,
			data: { redirectUri: window.location.href },
			cache: true,
			success: (res) => {
				const json = JSON.parse(res);

				const authorizeUrl = 'https://' + domain + '/oauth/authorize?' 
					+ 'client_id=' + json.clientId 
					+ '&scope=' + json.scope
					+ '&redirect_uri=' + json.redirectUri
					+ '&response_type=code';
				window.location.href = authorizeUrl;
			},
			error: (err) => {
				$('#mastodon-reply-modal-failure').modal('show');
			}
		});
	}
	else {
		$('#mastodon-domain-reply').addClass('error');
	}
});

// fragment pliku web.php z routingiem

Route::get('/mastodon/app/{instance}', [MastodonController::class, 'getAppCredentials']);
Route::get('/mastodon/token/{instance}/{code}', [MastodonController::class, 'getToken']);
Route::get('/mastodon/post/{instance}', [MastodonController::class, 'getPostInfoOnInstance']);
Route::post('/mastodon/toot/{instance}', [MastodonController::class, 'sendToot']);

// fragment pliku MastodonController.php

class MastodonController extends Controller {

    private $presenter;
    private $mastodonInstanceCredentialsRepository;
    private $postCommentSourceRepository;

    public function __construct() {
        parent::__construct();

        $this->presenter = new MastodonPresenter();
        $this->mastodonInstanceCredentialsRepository = new MastodonInstanceCredentialsRepository();
        $this->postCommentSourceRepository = new PostCommentSourceRepository();
    }

    public function getAppCredentials(Request $request, $instance) {
        $redirectUri = $request->get('redirectUri', env('MASTODON_APP_REDIRECT_URI'));
        if(App::environment('local')) {
            $redirectUri = env('MASTODON_APP_REDIRECT_URI');
        }

        $credentials = $this->mastodonInstanceCredentialsRepository->getByInstance($instance);
        if(empty($credentials)) {
            $url = 'https://'.$instance.'/api/v1/apps';
            $body = [
                'client_name' => env('MASTODON_APP_NAME'),
                'redirect_uris' => $redirectUri,
                'scopes' => str_replace('+', ' ', env('MASTODON_APP_SCOPES')),
                'website' => URL::to('/'),
            ];
            $response = Http::asForm()->post($url, $body);

            if($response->successful()) {
                $rawOutput = $response->body();
                $output = json_decode($response->body(), true);
                $now = (new DateTime())->format('Y-m-d H:i:s');

                $credentials = new MastodonInstanceCredentials();
                $credentials->instance = $instance;
                $credentials->client_id = $output['client_id'];
                $credentials->client_secret = $output['client_secret'];
                $credentials->vapid_key = $output['vapid_key'];
                $credentials->response = $rawOutput;
                $credentials->save();
            }
            else {
                $message = 'Error during calling '.$url.' with body '.print_r($body, true);
                Log::error($message);
                Log::error($response->status().': '.print_r($response->body(), true));
                return response(json_encode(['message' => $message], 500));
            }
        }

        $response = [
            'clientId' => $credentials->client_id,
            'redirectUri' => $redirectUri,
            'scope' => env('MASTODON_APP_SCOPES'),
        ];

        return response(json_encode($response), 200);
    }
	
	...
}

// fragment pliku .env

MASTODON_APP_NAME=MastodonCommentSystem_test
MASTODON_APP_REDIRECT_URI=urn:ietf:wg:oauth:2.0:oob
MASTODON_APP_SCOPES="write:statuses+read:search+read:accounts"

Dosyć dużo tego kodu i na początku warto wyjaśnić, jak to przebiega z "lotu ptaka". Pierwsza rzecz to kontynuacja procesu podawania instancji, co powoduje wywołanie wewnętrznej usługi GET /mastodon/app/{instance}. Skąd wiemy, gdzie jest ona w kodzie? Za to odpowiada już plik web.php, który jest laravelowym punktem "tłumaczącym" adresy URL na konkretne kontrolery i ich metody. W tym przypadku widzimy, że wywołanie np. GET /mastodon/app/mastodon.social spowoduje dopasowanie adresu do pierwszego wpisu i przekierowanie do MastodonController->getAppCredentials('mastodon.social').

W samej metodzie w kontrolerze najpierw musimy pobrać przesłany również w tle adres przekierowania (redirectUri). Jest to nic innego, jak adres naszego artykułu, do którego Mastodon będzie musiał zawrócić użytkownika, gdy zostanie udzielona autoryzacja. I tutaj uwaga - w przypadku testów na lokalnej maszynie (localhost) nie możemy podać adresu powrotu wprost. Dlatego w tym przypadku korzystamy ze specjalnego ciągu znaków ukrytego pod zmienną środowiskową MASTODON_APP_REDIRECT_URI, a więc urn:ietf:wg:oauth:2.0:oob.

Moglibyśmy w tym miejscu już wprost wywołać odpowiednie żądanie do wybranej przez użytkownika instancji Mastodona, ale zatrzymajmy się na chwilę. Tworzenie aplikacji na danym serwerze może nastąpić raz na jakiś czas i uzyskane w ten sposób sekrety możemy zapisać. Oczywiście, moglibyśmy je generować za każdym razem, jednak podobnie, jak miało to miejsce w poprzednim odcinku, powinniśmy czuć pewną solidarność z administratorami instancji, którzy utrzymują je za własne pieniądze lub z datków swoich użytkowników. Pamiętajmy, że każdorazowe żądanie utworzenia aplikacji to nie tylko samo żądanie HTTP, ale też nowy wpis w bazie danych instancji. Jeśli wielu użytkowników z danego serwera rozpoczyna pisanie u nas komentarzy, na dłuższą metę może to oznaczać niepotrzebne obciążanie konkretnego serwera. Dlatego tak samo, jak to miało miejsce w przypadku odczytanych komentarzy, także tutaj będziemy te dane cache'ować.

Skorzystamy z tabeli mastodon_instance_credentials:

CREATE TABLE mastodon_instance_credentials (
	id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
	instance VARCHAR(512) NOT NULL,
	client_id VARCHAR(1024) NULL DEFAULT NULL,
	client_secret VARCHAR(1024) NULL DEFAULT NULL,
	vapid_key VARCHAR(1024) NULL DEFAULT NULL,
	response TEXT NULL,
	created_at TIMESTAMP NULL DEFAULT NULL,
	updated_at TIMESTAMP NULL DEFAULT NULL,
	PRIMARY KEY (id),
	UNIQUE INDEX mastodon_instance_credentials_instance_unique (instance)
);

Jak widać z kodu, odpytujemy ją (za pomocą klasy repozytorium, czyli MastodonInstanceCredentialsRepository.php), czy dla danej instancji posiadamy odpowiednie dane. Chodzi tutaj o CLIENT_ID, CLIENT_SECRET oraz VAPID_KEY. Jeśli tak, to z nich korzystamy i po prostu zwracamy do dalszej obróbki. Jeśli nie - faktycznie wywołujemy żądanie do konkretnej instancji, wykorzystując nasze dane (w tym scope, o czym za chwilę) i zapisujemy je do bazy danych na późniejszy użytek. W ten sposób aplikację w danej instancji utworzymy tylko i wyłącznie raz na jakiś czas, co oszczędzi nie tylko transferu pomiędzy serwerami, ale też czas.

Uwaga: danych nie możemy przechowywać bezterminowo - istnieje pewien okres, przez które są one ważne. Dlatego zaleca się co jakiś czas czyszczenie zawartości tabelki mastodon_instance_credentials, np. poprzez zadania crona. Zostawiamy to jako ćwiczenie dla czytelników.

W kodzie widać kilkukrotne użycie zmiennej środowiskowej MASTODON_APP_SCOPES. Są to uprawnienia, których wymagany przy okazji komunikacji za pomocą protokołu OAuth 2.0. Z pewnością kojarzymy sytuację, kiedy przy instalacji danej aplikacji na urządzeniu mobilnym jesteśmy pytani przez sklep o to, czy zezwalamy na dostęp np. do swojej listy kontaktów. Tutaj mamy do czynienia z czymś podobnym - każda aplikacja i późniejsze żądanie autoryzacyjne do API Mastodona przebiega dla konkretnego zakresu operacji. W tym przypadku są to:

  • write:statuses - będziemy chcieli dodawać tooty za pośrednictwem konta użytkownika.
  • read:search - będziemy chcieli wyszukiwać tooty lub konta na danej instancji.
  • read:accounts - będziemy chcieli odczytać dane profilu przechowywane na danej instancji.

Trzy ważne uwagi, zanim przejdziemy dalej. Po pierwsze, słusznie możecie zauważyć, że w poprzednim odcinku odczyt treści tootów oraz komentarzy był publiczny i to prawda - nie wszystkie usługi w API są dostępne dopiero po autoryzacji dokonanej przez użytkownika. Tutaj jednak mamy do czynienia właśnie z potrzebą takiego potwierdzenia, stąd te wszystkie działania związane z OAuth 2.0 i wprowadzenie tego tematu. Po drugie, jeśli chcemy się dowiedzieć, jakie uprawnienia (składające się na scope) będą nam potrzebne, to należy spojrzeć do dokumentacji konkretnych usług API Mastodona - tam znajdują się odpowiednie informacje. Po trzecie, jeśli w trakcie rozwoju aplikacji okaże się, że musimy poszerzyć zakres przyznanych uprawnień, to niestety, ale wszystkie utworzone do tej pory aplikacje musimy utworzyć na nowo, a wygenerowane tokeny - zresetować.

Na końcu widzimy, że zwrotnie dostajemy wymagany CLIENT_ID, a także scope oraz adres do przekierowania. Te dane będą nam potrzebne już w samym Mastodonie.

Przekierowanie do Mastodona i uzyskanie kodu

Na pewno zauważyliście ten fragment w post.js:

$.ajax({
	type: 'GET',
	url: this.baseUrl + 'mastodon/app/' + domain,
	data: { redirectUri: window.location.href },
	cache: true,
	success: (res) => {
		const json = JSON.parse(res);

		const authorizeUrl = 'https://' + domain + '/oauth/authorize?' 
			+ 'client_id=' + json.clientId 
			+ '&scope=' + json.scope
			+ '&redirect_uri=' + json.redirectUri
			+ '&response_type=code';
		window.location.href = authorizeUrl;
	},
	error: (err) => {
		$('#mastodon-reply-modal-failure').modal('show');
	}
});

Mając odpowiednie dane, musimy przekierować użytkownika do zewnętrznego dostawcy (w tym przypadku - Mastodona, a raczej konkretnej instancji Mastodona) i poprosić użytkownika o udzielenie autoryzacji, a w konsekwencji - o kod (stąd parametr response_type=code). To ten moment, w którym komentujący opuści na chwilę nasz blog i ukaże mu się widok podobny do tego:

Fragment okna z Mastodona o treści:

Na tym ekranie użytkownik jest pytany o potwierdzenie operacji. Gdy się zgodzi, Mastodon automatycznie przekieruje użytkownika z powrotem do naszego blogu, jednak tym razem doda kod do parametrów GET-owych adresu URL.

Wykorzystanie kodu do dalszych operacji

Teraz będzie się działo dużo rzeczy. Po pierwsze, widzimy, że jeśli podaliśmy adres https://naszblog/artykul, to nowy URL będzie wyglądał mniej więcej tak:

https://naszblog.pl/artykul?code=dlugiKod

Wykorzystamy to do tego, aby:

  1. od razu wczytać komentarze (nie czekając na ruch użytkownika),
  2. pobrać dodatkowy token uwierzytelniający (potwierdzający, że identyfikujemy się jako dany użytkownik),
  3. pobrać dane toota i naszego konta,
  4. przygotować formularz do wpisania komentarza,
  5. wyświetlić formularz i skierować do niego użytkownika.

Jak widać, jest to dość sporo pracy. Na początku zobaczmy, że w BlogController i w widoku dokonaliśmy małej zmiany, która dodatkowo odczyta nasz kod, jeśli ten został przekazany.

// fragment BlogController.php

public function post(Request $request, $id, $lang = null) {
	$post = $this->postRepository->getById($id, App::currentLocale());

	if(!empty($post)) {			
		$commentSourceIds = $this->postCommentSourceRepository->getIdsByPostId($post->id, App::currentLocale());

		// code after Mastodon authorization
		$mastodonCode = $request->input('code');

		return view('blog-post', [
			'post' => $post, 'commentSourceIds' => $commentSourceIds, 'mastodonCode' => $mastodonCode,
		]);
	}
	else {
		abort(404);
	}
}

...

// fragment blog-post.blade.php

<script>
	(new PostScript(
		"<?= URL::to('/') ?>",
		<?= $post->id ?>,
		<?= json_encode($commentSourceIds) ?>,
		<?= json_encode([
			'enterMastodonDomain' => __('enterMastodonDomain'),
		]) ?>,
		<?= !empty($mastodonCode) ? '"'.$mastodonCode.'"' : '' ?>
	)).init();
</script>

Jednak dużo więcej dzieje się w pliku post.js. Teraz będziemy mogli zobaczyć, do czego potrzebna jest zmienna withFormInitiating, którą ostatnio pominęliśmy przy omawianiu odczytu komentarzy.

init() {
	...

	if(this.mastodonCode) {
		if(this.commentSourceIds.length > 0) {
			this.loadComments(true);
		}
	}
	
	...
}

...

loadComments(withFormInitiating = false) {
	if(this.isCommentContainerLoaded) {
		return;
	}

	$.get(this.baseUrl + 'post/comment', { sourceIds: this.commentSourceIds }, (page) => {
		$('#comment-container-internal').html(page);
		this.isCommentContainerLoaded = true;

		if(withFormInitiating) {
			const instance = localStorage.getItem('lastMastodonDomain');
			const postSrc = localStorage.getItem('lastMastodonSrc');

			let accessToken = localStorage.getItem('mastodonAccessToken');
			let accessTokenCreatedBy = localStorage.getItem('mastodonCreatedBy');
			const accessTokenLifespan = 4 * 3600 * 1000;

			if(!accessToken || !accessTokenCreatedBy || instance != localStorage.getItem('mastodonAccessTokenInstance')
				|| (Date.now - accessTokenLifespan > accessTokenCreatedBy)        
			) {
				$.ajax({
					type: 'GET',
					url: this.baseUrl + 'mastodon/token/' + instance + '/' + this.mastodonCode,
					data: { redirectUri: window.location.href },
					cache: false,
					success: (res) => {
						const json = JSON.parse(res);
						accessToken = json.accessToken;
						accessTokenCreatedBy = json.createdBy;
						localStorage.setItem('mastodonAccessToken', accessToken);
						localStorage.setItem('mastodonCreatedBy', Date.now());
						localStorage.setItem('mastodonAccessTokenInstance', instance);

						this.prepareCommentBox(instance, postSrc, accessToken);
					},
					error: (err) => {
						$('#mastodon-reply-modal-failure').modal('show');
					}
				});                
			}
			else {
				this.prepareCommentBox(instance, postSrc, accessToken);
			}
		}
	});
}

Jeśli kod jest dostępny, to nie czekamy i od razu ładujemy komentarze w taki sam sposób, jak do tej pory, ale poprzez flagę withFormInitiating informujemy, że po wczytaniu wpisów musimy pobrać dane instancji (zapisanej w local storage) i wykorzystać je do pobrania tokenu uwierzytelniającego. Jednak zanim to się stanie, sprawdzamy, czy czasem już takiego tokenu nie posiadamy - może bowiem się zdarzyć, że dany użytkownik odpowiada na wiele komentarzy na naszym blogu w krótkim czasie. Nie trzeba zatem co chwilę go uwierzytelniać - można zrobić to np. raz na 4 godziny (co zostało zapisane w stałej accessTokenLifespan). Jeśli tokenu nie mamy lub jest on starszy niż wyznaczony czas, to musimy ponownie udać się do API Mastodona po wymaganą informację. Wróćmy do MastodonControllera:

public function getToken(Request $request, $instance, $code) {
	$redirectUri = $request->get('redirectUri', env('MASTODON_APP_REDIRECT_URI'));
	if(App::environment('local')) {
		$redirectUri = env('MASTODON_APP_REDIRECT_URI');
	}

	$credentials = $this->mastodonInstanceCredentialsRepository->getByInstance($instance);
	$accessToken = null;
	$createdAt = null;
	if(!empty($credentials)) {
		$url = 'https://'.$instance.'/oauth/token';
		$body = [
			'client_id' => $credentials->client_id,
			'client_secret' => $credentials->client_secret,
			'redirect_uri' => $redirectUri,
			'grant_type' => 'authorization_code',
			'code' => $code,
			'scope' => str_replace('+', ' ', env('MASTODON_APP_SCOPES')),
		];
		$response = Http::asForm()->post($url, $body);

		if($response->successful()) {
			$body = json_decode($response->body(), true);
			$accessToken = $body['access_token'];
			$createdAt = $body['created_at'];
		}
		else {
			$message = 'Error during calling '.$url.' with body '.print_r($body, true);
			Log::error($message);
			Log::error($response->status().': '.print_r($response->body(), true));
			return response(json_encode(['message' => $message], 500));
		}
	}
	else {
		$message = 'mastodon/getToken fail - there is no instance like '.$instance;
		Log::error($message);
		return response(json_encode(['message' => $message], 500));
	}

	$response = [
		'accessToken' => $accessToken,
		'createdAt' => $createdAt,
	];

	return response(json_encode($response), 200);
}

Kod wydaje się bardzo "długi" z tego powodu, iż na tym etapie musimy sprawdzić każdą ewentualność nieuprawnionego wywołania żądania takiego tokenu i zapobiec wystąpieniu dalszych błędów. To, co nas najbardziej interesuje, to ponowne uzyskanie danych aplikacji związanych z odpowiednią instancją oraz wywołanie POST /oauth/token. Co ciekawe, widać tutaj niekonsekwencję twórców Mastodona, gdyż tym razem scope podawany jest w innej formie - nie z użyciem plusów, ale spacji.

Wynikiem tego żądania będzie kilka informacji, z których najważniejszy dla nas jest token dostępowy (accessToken) oraz data utworzenia (createdAt). Te dane zwracamy i zapisujemy w JS-ie w local storage. Następnie wykorzystujemy je do rozpoczęcia generacji pola, w którym użytkownik będzie mógł wpisać komentarz.

prepareCommentBox(instance, postSrc, accessToken) {
	$.ajax({
		type: 'GET',
		url: this.baseUrl + 'mastodon/post/' + instance,
		data: { postUrl: postSrc, accessToken},
		cache: false,
		success: (resPost) => {
			const postJson = JSON.parse(resPost);
			
			$.get(this.baseUrl + 'post/comment/form', postJson, (form) => {
				$('#comment-form').remove();
				const commentBox = $('.comment-reply-link[data-src="' + postSrc + '"]').closest('.comment');
				commentBox.after(form);

				document.querySelector('#comment-form').scrollIntoView({
					behavior: 'smooth'
				});
			});
		},
		error: (errPost) => {
			$('#mastodon-reply-modal-failure').modal('show');
		}
	});
}

Także tutaj czeka nas wywołanie nawet nie jednego, ale dwóch żądań do Mastodona. Dobrze byłoby użytkownikowi wyświetlić jego avatar i nick, aby poczuł, że korzysta ze swojego konta. Jednak ważniejsze jest pobranie identyfikatora toota, na który następuje odpowiedź. Jednak "zaraz" - powiedzą uważni czytelnicy i wskażą na zmienną postSrc, która ten identyfikator powinna przechowywać już od momentu, kiedy użytkownik kliknął na ikonkę odpowiedzi przy danym toocie. Czy to nie jest właśnie ta wartość? Otóż - nie i w tym momencie potrzebna jest wcześniej dostarczona wiedza dotycząca federacji.

Zmienna postSrc to rzeczywiście numer wpisu, ale w obrębie oryginalnej instancji danego toota. Łatwo to zrozumieć na przykładzie - wyobraźmy sobie, że naszym tootem źródłowym jest wpis z instancji social.wildasoftware.pl, natomiast jeden użytkownik odpowiedział na niego z instancji wspanialy.eu. Na naszym blogu wyświetlamy oba wpisy, jednak identyfikator pierwszego wpisu jest z bazy social.wildasoftware.pl, a drugiego ze wspanialy.eu. Natomiast nasz nowy użytkownik chce odpowiedzieć na ten wpis z instancji pol.social i już autoryzował dostęp ze swojego konta. Aby móc potem dodać wysłać toot będący odpowiedzią na wybranego toota, musimy znać identyfikator tego toota na instancji nowego użytkownika, a więc pol.social. Czyli w szczególnym przypadku - wpis, na który odpowiada ta osoba, musi zostać skopiowany na instancję pol.social.

A zatem za pomocą mastodon/post i tym samym kontrolera MastodonController pobierzemy zarówno informacje o profilu, jak i wyszukamy toot w celu pobrania z niego właściwego identyfikatora. Wyszukanie wpisu automatycznie pobierze jego kopię na instancję pol.social, jeśli jeszcze jej tam nie było.

public function getPostInfoOnInstance(Request $request, $instance) {
	$postUrl = $request->input('postUrl');
	$accessToken = $request->input('accessToken');

	$output = [
		'postId' => null,
		'instance' => $instance,
		'acct' => null,
		'avatarStatic' => null,
		'displayName' => null,
		'emojis' => null,
		'accountUrl' => null,
	];

	$url = 'https://'.$instance.'/api/v2/search';
	$params = [
		'q' => $postUrl,
		'type' => 'statuses',
		'resolve' => true,
		'limit' => 1,
	];

	$response = Http::withHeaders([
		'Authorization' => 'Bearer '.$accessToken,
	])->get($url, $params);

	if($response->successful()) {
		$body = json_decode($response->body(), true);
		if(!empty($body['statuses'])) {
			$output['postId'] = $body['statuses'][0]['id'];
		}
		else {
			$message = 'mastodon/getPostIdOnInstance fail - there is no post '.$url.' on instance '.$instance;
			Log::error($message);
			return response(json_encode(['message' => $message], 500));
		}
	}
	else {
		$message = 'Error during calling '.$url.' with body '.print_r($params, true);
		Log::error($message);
		Log::error($response->status().': '.print_r($response->body(), true));
		return response(json_encode(['message' => $message], 500));
	}

	//--

	$urlAccount = 'https://'.$instance.'/api/v1/accounts/verify_credentials';

	$responseAccount = Http::withHeaders([
		'Authorization' => 'Bearer '.$accessToken,
	])->get($urlAccount);

	if($responseAccount->successful()) {
		$body = json_decode($responseAccount->body(), true);

		$output['acct'] = $body['acct'];
		$output['displayName'] = $body['display_name'];
		$output['avatarStatic'] = $body['avatar_static'];
		$output['emojis'] = $body['emojis'];
		$output['accountUrl'] = $body['url'];
	}
	else {
		$message = 'Error during calling '.$url;
		Log::error($message);
		Log::error($responseAccount->status().': '.print_r($responseAccount->body(), true));
		return response(json_encode(['message' => $message], 500));
	}

	return response(json_encode($this->presenter->formatGetPostInfoOnInstance($output)), 200);
}

Warto zwrócić uwagę na dwie rzeczy. Po pierwsze, ponieważ te dwa żądania są niezależne od siebie, można je wywołać równolegle, a nie tak, jak to zrobiliśmy, synchronicznie. Biblioteka Guzzle umożliwia taką operację, jednak zostawiamy to jako zadanie dla chętnych czytelników. Po drugie, po pobraniu danych użytkownika musimy je przeformatować podobnie, jak to robiliśmy przy okazji wyświetlania samych komentarzy. Także tutaj robimy to za pomocą klasy prezentera, jednak pozwolicie, że pominę tutaj dokładny opis - po szczegóły zapraszam do kodu i poprzedniej części naszego artykułu.

Na końcu musimy wyświetlić samo miejsce na wpisanie treści komentarza. Uzbrojeni w informację o profilu użytkownika, udajemy się do kontrolera BlogController i odpowiedniego widoku, aby AJAXowo pobrać odpowiedni bloczek, wyświetlić go i przewinąć użytkownikowi stronę do tego miejsca. W tym momencie pominę opis, gdyż sam formularz korzysta z kodu omawianego w poprzednim artykule i jest po prostu nudny - warto przejrzeć źródła na GitHubie. Efektem końcowym jest taki widok:

Fragment okna na naszym blogu, gdzie użytkownik widzi swój avatar i nick z Mastodona oraz miejsce do wpisania komentarza

Wysłanie toota, odświeżenie komentarzy

W momencie, kiedy użytkownik wpisze treść swojego komentarza i naciśnie "Wyślij", oczywiście, musimy wysłać tę treść do wybranej wcześniej instancji Mastodona za pomocą API. Zaczynamy od post.js:

$('#comment-container').on('click', '.comment-form-send-button', (event) => {
	const answer = $(event.target).closest('.answer');
	const answeredTootId = answer.find('.comment-form-postid').val();
	const message = answer.find('.comment-form-message').val();

	const instance = localStorage.getItem('lastMastodonDomain');
	const accessToken = localStorage.getItem('mastodonAccessToken');

	if(message) {
		$.ajax({
			type: 'POST',
			url: this.baseUrl + 'mastodon/toot/' + instance,
			data: { message: message, answeredTootId: answeredTootId, accessToken: accessToken, postId: this.postId },
			cache: false,
			success: (res) => {
				answer.remove();
				this.isCommentContainerLoaded = false;
				this.loadComments();
			},
			error: (err) => {
				$('#mastodon-reply-modal-failure').modal('show');
			}
		});
	}
});

Jak widać, w samym formularzu zachowana była też informacja o identyfikatorze toota, na który odpowiadamy (na wybranej przez siebie instancji), a dane samego serwera i token pobieramy z local storage. Wówczas wywołujemy naszą metodę w MastodonController:

// fragment MastodonController.php

public function sendToot(Request $request, $instance) {
	$message = $request->post('message');
	$answeredTootId = $request->post('answeredTootId');
	$accessToken = $request->post('accessToken');
	$postId = $request->post('postId');

	$url = 'https://'.$instance.'/api/v1/statuses';
	$params = [
		'status' => $message,
		'in_reply_to_id' => $answeredTootId,
	];

	$response = Http::withHeaders([
		'Authorization' => 'Bearer '.$accessToken,
	])->post($url, $params);

	if($response->successful()) {
		$this->postCommentSourceRepository->resetCache($postId);
	}
	else {
		$message = 'Error during calling '.$url.' with body '.print_r($params, true);
		Log::error($message);
		Log::error($response->status().': '.print_r($response->body(), true));
		return response(json_encode(['message' => $message], 500));
	}

	return response('', 200);
}

// fragment PostCommentSourceRepository.php

public function resetCache(int $postId) {
	PostCommentSource::where('post_id', $postId)->update(['data_received' => null]);
}

To, co jest tutaj ciekawe, to zresetowanie cache'a w post_comment_source. Po co to robimy? Pamiętamy z poprzedniego odcinka, że pobrane raz komentarze, w celu optymalizacji transferu i czasu, zachowujemy u siebie na pewien czas. Jednak po dodaniu komentarza chcemy je wyświetlić zaktualizowane i nie korzystać z pamięci podręcznej. Najprościej jest to zrobić właśnie poprzez usunięcie zachowanych wcześniej danych dla danego posta. W tym miejscu wkradła się mała nieoptymalność - nie wiemy, w ramach jakiego toota źródłowego odpowiadaliśmy na komentarz (w końcu mogliśmy komentować wpis innego użytkownika, a nie oryginalny), więc musimy usunąć cache dla wszystkich tootów źródłowych danego artykułu. Nie jest to jednak duży problem.

Po pomyślnym dodaniu komentarza na Mastodonie, możemy zaktualizować nasz wątek wpisów. Stąd we wcześniej podanym kodzie JS ponowne wywołanie loadComments().

Miejsce na rozwój

Podczas lektury na pewno zauważyliście miejsca, w których można usprawnić cały mechanizm. O niektórych z nich wspomniałem przy poszczególnych punktach, w innych każdemu przyszły do głowy jego własne pomysły. Na pewno w oczy rzuca się potrzeba jeszcze lepszej obsługi błędów, np. w sytuacji, kiedy użytkownik po uwierzytelnieniu zbyt długo zwleka z napisaniem i wysłaniem komentarza. Jednak można też pomyśleć o rozwoju samego systemu, np. poprzez wyświetlanie boostów czy polubień, a także możliwość zaobserwowania innego użytkownika z poziomu samego blogu. Jak najbardziej jest to możliwe z poziomu API i byłoby jeszcze mocniejszym związaniem blogu ze światem serwisów społecznościowych. Pytanie, czy jest to dobre, zostawiamy do Waszej oceny.

Podsumowanie

Uff, dotarliśmy do końca. Dziękuję wszystkim, którzy przeczytali obie części artykułu i mam nadzieję, że nie była to podróż nudna. Zdaję sobie sprawę, że nie każdego może interesować sam kod. Dlatego liczę na to, że wielu osobom podobał się wstęp i wytłumaczenie mechaniki działania poszczególnych protokołów czy sposób obsługi konkretnych operacji. A przede wszystkim będę usatysfakcjonowany jeśli okaże się, że za sprawą tego dwuczęściowego tekst ktoś rzeczywiście zaimplementuje system komentarzy oparty o Mastodona na swoim blogu czy stronie. Będzie to dla mnie oznaka, że trud się opłacił.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Komentarze na blogu z użyciem Mastodona - część 1. https://wildasoftware.pl/post/komentarze-blogu-uzyciem-mastodona-cz1?ref=rss https://wildasoftware.pl/post/komentarze-blogu-uzyciem-mastodona-cz1?ref=rss Thu, 01 Jun 2023 17:30:00 +0000 Dopiero piszę te słowa, zaczynając artykuł, a już wiem, że szykuje się długi tekst. Na tyle długi, że zostanie podzielony na dwie części, aby dać Wam (oraz sobie) wytchnienie, a jednocześnie pozwolić omówić każdy aspekt dokładniej. Będzie to też artykuł dosyć techniczny, skierowany przede wszystkim do twórców stron WWW, ale nie tylko. Pełni on bowiem rolę "proof of concept" - prezentacji tego, jak można podejść do systemu komentarzy na blogu lub w innym serwisie internetowym w taki sposób, aby oszczędzić sobie trochę pracy, zrealizować ciekawą ideę, a jednocześnie ściślej powiązać wiadomości ze światem społecznościowym. A to może podobać się redakcjom czy twórcom portalu, zwłaszcza kiedy liczą koszt rozwoju oprogramowania.

Oczywiście, ktoś mógłby powiedzieć, że zewnętrzny system komentarzy nie jest niczym nowym w świecie blogowym, gdyż istnieje choćby Disqus, a na niektórych stronach można znaleźć wstrzyknięte komentarze z Facebooka. Tym niemniej, nie wszystkim uśmiecha się płacenie lub ograniczenia dotyczące darmowych wersji (w tym szczególnie wyświetlanie reklam) lub powiązanie z "dużym graczem". Co więcej, to nadal umieszczanie kont i wiadomości na zewnętrznym serwerze jakiejś firmy, do czego jesteśmy przyzwyczajeni, ale nie zawsze może nam się to podobać. A co jeśli wykorzystalibyśmy istniejące mechanizmy mniejszych, otwartych społecznościówek i po prostu wyświetlali już i tak publiczne posty w formie komentarzy? Dodatkowo, te wiadomości mogłyby być dodawane zarówno z poziomu blogu, jak i samego serwisu social media, ale traktowane byłoby to jako jeden, wspólny wątek? I to wszystko za darmo oraz na serwerach należących zwykle do społeczności, ludzi ją tworzących? Właśnie na tym polega pomysł z wykorzystaniem Mastodona.

Tak, jak wspomniałem, artykuł został podzielony na dwie części. W pierwszej (którą właśnie czytacie) zajmiemy się wyjaśnieniem lub przypomnieniem:

  • jaki w ogóle mamy cel,
  • czym jest właściwie Mastodon i dlaczego jest dobrym kandydatem do systemu komentarzy,
  • jak pobierać komentarze i wyświetlać je w formie wątku,
  • gdzie można znaleźć przykład.

Z kolei w drugiej części zajmiemy się omówieniem bezpośredniego odpowiadania na posty z poziomu blogu, co jest bardziej złożonym tematem. Jednocześnie nie ograniczymy się do surowego omówienia metody działania - będziemy też zwracać uwagę na miejsca, gdzie może nastąpić optymalizacja, przy czym nie mówimy tylko o czasowej, ale też np. transferowej. Dodatkowo omówimy parę ogólnych mechanizmów stosowanych szczególnie przy korzystaniu z API. Przemycimy także parę uwag dotyczących standardu kodowania.

Artykuł jest z jednej strony techniczny, ale z drugiej - pokazuje ogólne możliwości, jakie drzemią w tym środowisku, a które mogą spodobać się np. specjalistom od social media. Na pewno skorzystają na nim programiści lub osoby, które opiekują się swoim blogiem i nie boją się czasem wejść do kodu. Jednak, musimy mieć świadomość, że to nie jest opis gotowej biblioteki do wykorzystania czy jedyne słuszne rozwiązanie - to raczej pokazanie mechanizmu działania wraz z przykładem kodu, który pozwala osiągnąć zamierzony cel. Demonstracja odbędzie się w języku PHP, ale to, oczywiście, nie oznacza, że tylko w tej technologii można stworzyć taki system komentarzy - to, co będę opisywał, pasuje także do innych języków czy frameworków. Choć nie da się ukryć, że większość blogów jednak korzysta właśnie z Personal Home Page.

Gotowy przykład

W tekście będę omawiał także podstawy "teoretyczne", wyjaśniając pewne podstawowe pojęcia i pokazując ich plusy oraz minusy. Jednak zdaję sobie sprawę, że nie wszystkich to interesuje - niektórzy chcą dostać od razu odpowiedź na swoje pytanie "jak zaimplementować system komentarzy". Z tego powodu przygotowaliśmy przykład, który zresztą będzie bazą do omówienia w dalszej części tekstu. Oto on:

https://github.com/WildaSoftware/MastodonCommentSystem

Jest to aplikacja w Laravelu stworzona na podstawie tego blogu, w którym znajduje się jeden przykładowy artykuł oraz źródło komentarzy do niego. Jeśli wolicie uczyć się poprzez samodzielną analizę kodu i próbowanie rozwiązań w praktyce, to zapraszam do klonowania repozytorium. Instrukcja konfiguracji aplikacji jest zawarta w pliku README.md. Powodzenia! Mimo wszystko mam nadzieję, że choćby z ciekawości wrócicie potem do tego tekstu lub będziecie przerabiać te materiały równocześnie :)

Jedna uwaga - doskonale wiem, że kod nie jest idealnym przykładem aplikacji webowej napisanej w Laravelu. To jest jedynie przykład, który pokazuje, w jaki sposób praktycznie można poradzić sobie z pewnymi kwestiami i do którego można zerknąć podczas implementowania systemu komentarzy u siebie. Natomiast nie znaczy to, że nie zajmujemy się aplikacjami w tym frameworku - również mamy w nim doświadczenie, mimo że naszą podstawową technologią jest Yii 2.0. W razie czego - wiecie, jak się z nami skontaktować.

Co chcemy osiągnąć?

Na początku należy określić, co w ogóle chcemy zrobić. Naszym celem jest to, aby pod artykułami na blogu wyświetlał się wątek z komentarzami. Technicznie będą to posty na portalu społecznościowym (tutaj: dowolna instancja Mastodona, do czego zaraz przejdziemy), które są odpowiedziami na pewien źródłowy post. Wykorzystamy do tego fakt, że zwykle ogłaszamy publikację nowego artykułu właśnie za pomocą wpisu w social media, na który ludzie mogą odpowiadać. I dokładnie to będziemy tutaj wyświetlać w nieco bardziej dostosowanej formie.

Jako przykład możemy przywołać nasz artykuł o znaczeniu szachów w rozwoju programisty - po przewinięciu strony na dół trafimy do sekcji komentarzy, gdzie wyświetli nam się wątek, mający źródło m.in. w moim toocie zapraszającym do przeczytania tekstu ("toot" to wpis w serwisie Mastodon). Wszystkie odpowiedzi (będące czasem odpowiedziami do innych odpowiedzi) są wyświetlane w wątku i są faktycznymi tootami napisanymi przez innych użytkowników Fediverse (do tego też dojdziemy) lub przeze mnie. Gdy klikniemy na datę lub login danego rozmówcy, to przejdziemy do konkretnych wiadomości lub profilu już w portalu społecznościowym. Jednocześnie, bierzemy pod uwagę tylko publiczne wpisy - jeśli któryś z użytkowników napisze toota niepublicznego lub wręcz bezpośredniego, to ta wiadomość nie pojawi się w wątku na blogu ze względu na prywatność.

Dodatkowo, dobrze by było móc nie tylko odczytywać i wyświetlać tooty jako komentarze, ale także odpowiadać na nie. Z uwagi na fakt, że blog jest zewnętrzną stroną, nie jest to takie trywialne - użytkownik musi użyć swojego konta na Mastodonie, ale dobrze by było, aby miał poczucie, że pisze komentarz z poziomu strony. Dlatego po kliknięciu na ikonkę odpowiedzi zostanie przekierowany do Mastodona w celu potwierdzenia swojej osoby (bardzo podobnie, jak to ma miejsce przy logowaniu się kontem Google'a lub Facebooka), a następnie zawrócony do blogu w celu napisania treści wiadomości, która i tak przechodzi przez Mastodona.

To wszystko daje nam system komentarzy, który pokazuje dyskusję pod artykułem, ale jednocześnie nie angażuje zasobów bloga i co więcej - nie wymaga przechowywania danych kont w naszej bazie danych, co odciąża nas pod kątem wielu mechanizmów uwierzytelniających i autoryzacyjnych.

Czym jest wewnętrzny i zewnętrzny system komentarzy?

W wielu przypadkach komentarze pod artykułami są w całości obsługiwane w ramach danego serwisu. W dawnych czasach było to bardzo "frywolne" - nierzadko możliwość dodania wpisu nie wymagała zalogowania się ani jakiegokolwiek potwierdzenia swojej tożsamości. Objawiało się to wygodą, natomiast skutkowało spamem, postami nienadającymi się do cytowania i ogólnym śmietnikiem, który należało czyścić lub wyłączyć. Z tego powodu coraz częściej zaczęto stosować mechanizm CAPTCHA lub wymagać rejestracji konta, co przybiera różne formy. Jeśli portalowi zależy na dużym ruchu (np. serwisy informacyjne), to proces uwierzytelnienia jest bardzo prosty, natomiast w innych przypadkach przypomina normalną rejestrację, z aktywacją konta itd. Coraz częściej serwisy bazują głównie na kontach dużych serwisów (tzw. SSO, Single Sign-On), np. Google, Facebook czy Apple, które z jednej strony są wygodne dla użytkowników, a z drugiej - ściągają część obowiązków z głowy twórców portalu.

Opisany wyżej mechanizm nazywamy "wewnętrznym", gdyż całość jest realizowana po stronie serwisu. Zarówno sama mechanika wyświetlania oraz odpowiadania na komentarze, jak i obsługa kont (nawet w przypadku użycia SSO) jest do zaimplementowania przez twórców portalu. Z jednej strony to kuszące, gdyż mamy nad wszystkim całkowitą kontrolę, także pod kątem estetyki - łatwiej taki system komentarzy zintegrować graficznie z portalem. Z drugiej strony - jest to pracochłonne, być może nawet bardziej niż wszystkim się wydaje. Wymaga implementacji każdego elementu i zadbania o proces uwierzytelniania (staje się to łatwiejsze, gdy system i tak wymaga zalogowania się w celu korzystania z innych funkcji). Dodatkowo, dochodzą dwie kwestie, które należy rozważyć. Jedną z nich jest moderowanie treści dodanej przez użytkowników, co w przypadku dużych serwisów może być trudne, ale też konieczne ze względu na spam i nieodpowiednią zawartość, jaką złośliwi użytkownicy są w stanie zamieścić. Drugim kłopotem jest fakt, że internauci coraz bardziej wzbraniają się przed zakładaniem masy kont w różnych serwisach, gdyż potem i tak nie pamiętają haseł lub w ogóle o fakcie, że dane konto posiadają. Ten problem w pewien sposób rozwiązuje właśnie SSO.

Na przeciwnym biegunie mamy zewnętrzne systemy komentarzy w postaci Disqusa, OpenWeba czy wielu innych. Działają one na podobnej zasadzie jak wtyczka Feedybacky - system znajduje się na zewnętrznym serwerze i jest wstrzykiwany na blog lub portal za pomocą tagu iframe albo poprzez użycie odpowiedniego skryptu JavaScript. Wymaga to założenia konta u zewnętrznego dostawcy, skonfigurowania parametrów (np. maksymalna długość komentarza), a następnie użycia odpowiednich danych na właściwej stronie. W takim układzie programista nie musi implementować tego mechanizmu u siebie ani tym bardziej zamartwiać się obsługą kont - to wszystko jest po stronie dostawcy. Wygląda to na bardzo wygodne rozwiązanie i takie rzeczywiście jest, a dodatkowo jest ustandaryzowane - użytkownik przeglądający blogi i napotykający np. Disqusa rozpoznaje go, wie, czego może się po nim spodziewać i być może nawet ma jedno konto, który wykorzystuje do komentowania wpisów na wszystkich ulubionych blogach.

Natomiast, oczywiście, istnieje parę wad takiego podejścia. Po pierwsze, są to często rozwiązania płatne lub ograniczone w pewien sposób, co też trzeba zrozumieć - zewnętrzny dostawca musi chronić swoje zasoby przed "testowaniem" systemu komentarzy ponad jego możliwości. Dodatkowo, musi w jakiś sposób na tym zarabiać i opłacić swoich programistów oraz serwery, co wymaga wprowadzenia abonamentu lub reklam. Po drugie, za cenę braku konieczności własnoręcznej implementacji, twórcy stron mają mniejsze możliwości dopasowania systemu komentarzy do własnego layoutu. Istnieją na to sposoby lub twórcy zapewniają wprowadzanie własnych ustawień (choćby poprzez pliki CSS czy po prostu "wyklikanie" poszczególnych opcji), ale na pewno nie jest to tak "customizowalne" jak natywny system. Po trzecie, jesteśmy uzależnieni od zewnętrznej firmy - jeśli ta zmieni warunki usługi, cenę, limity, sposób działania komentarzy lub zwyczajnie zamkną usługę, to pozostaje nam się z tym pogodzić i/lub zmienić dostawcę.

Gdzie plasuje się nasz system komentarzy, który zaimplementujemy? Pomiędzy - można powiedzieć, że to rozwiązanie hybrydowe. Zewnętrzna natura polega na tym, że źródłem komentarzy jest zewnętrzny serwis, który w dodatku nie jest jednym portalem (o czym za chwilę), co w pewien sposób pomaga w radzeniu sobie z utratą dostępu do usługi. Także konta użytkowników są po stronie Mastodona i nas nie interesują hasła ani inne wrażliwe dane konkretnych profilów. Natomiast "wewnętrzność" objawia się w potrzebie przygotowania mechanizmu wyświetlania oraz wprowadzania treści komentarzy, co z jednej strony jest wadą, a z drugiej zaletą, gdyż możemy wiele dostosować do naszych potrzeb. Takie podejście będziemy omawiać dzisiaj oraz w następnej części. Co więcej, prezentowane rozwiązanie można również zawrzeć w bibliotece, tworząc z tego de factu zewnętrzny system komentarzy, łatwiejszy do "zaimplementowania" przez inne osoby. To już stanie się "zadaniem dla chętnych".

Czym jest Mastodon i Fediverse?

Warto również przypomnieć i jeszcze raz omówić, czym właściwie jest Mastodon oraz wiążący się z tym Fediverse - jeszcze raz, gdyż już kiedyś to zrobiliśmy. Tylko wtedy skupiliśmy się na jego społecznościowym aspekcie, natomiast tutaj omówimy to zagadnienie od bardziej technicznej strony, ale także filozofii działania. Jeśli jesteście ciekawi, przeczytajcie kolejne akapity, a jeśli chcecie przejść do "mięsa" - możecie śmiało ominąć tę sekcję, choć polecam zajrzeć przynajmniej do końcówki tego rozdziału.

Wyobraźmy sobie dowolny serwis społecznościowy, zapewniający tworzenie treści - zapewne w tym momencie do głowy przyszły Wam takie tuzy, jak Facebook, Twitter, Instagram czy YouTube. To są tak zwane systemy scentralizowane - gdy rejestrujemy konto np. na Twitterze, trafiamy do tej samej bazy, co miliony innych użytkowników i mamy łatwy wgląd do każdej publicznej wiadomości. Najważniejsze jest to, że dostęp do całego serwisu jest pod jednym, konkretnym adresem, który odnosi się do jednego serwera (a raczej farmy serwerów, ale nie bądźmy drobiazgowi). Jest to wygodne, natomiast istnieją też różne wady oraz niekiedy wątpliwości moralne. Taka "społecznościówka" jest zarządzana przez konkretną firmę, gdyż nie jest to już prosta strona dla miłośników jakiegoś tematu - to globalny moloch, którego rozwój i utrzymanie wymagają ogromnych nakładów, co z kolei sprawia, że firmy chcą dużo zarobić. I pół biedy, gdyby odbywało się to w sposób niebudzący wątpliwości etycznych, ale tutaj często dane darmowych (i nie tylko) kont są wykorzystywane do lepszego personalizowania reklam, które stanowią główne źródło utrzymania serwisów. Reklamy mogą nie przeszkadzać (a personalizacja w pewnych przypadkach może nawet pomagać), ale czasem to robią, dopełniając obraz serwisu jako de facto systemu "billboardowego", w którym każdy się promuje i żyje ponad stan (tak często kojarzy się Instagram lub LinkedIn). Dodatkowo, w serwisie obowiązuje pewien regulamin i zasady zachowania, co jest dobre. Jednak z uwagi na tak ogromną bazę twórców oraz treści, właściciele portalu nie mogą moderować postów ręcznie - robią to boty, które czasem się mylą i blokują dostęp użytkownikom, którzy niczego złego nie zrobili. Radzenie sobie z takimi sytuacjami wiąże się ze stresem, pisaniem do pomocy technicznej i utratą zaufania do takiego portalu, a czasem przejściem na tzw. media własne. Warto też wspomnieć o tym, że jako że jest to system scentralizowany, to staje się bardziej podatny na awarie. Oczywiście, przy kilkuset (lub nawet więcej) serwerach obsługujących dany portal, problemy z jedną maszyną nie są kłopotliwe, ale jeśli jakaś zmiana ujawni się na wielu jednostkach, to cały system może przestać działać, czego przykłady mieliśmy w przyszłości.

Wielu osobom nie pasowały te warunki - niektórym te związane z problemami technicznymi, części łatwość dostania blokady, a innym kwestie prywatności i te bardziej ideologiczne. Po początkowym zachwycie gigantami, cząsta społeczności internetowej zapragnęła stworzyć własne, otwarte rozwiązanie. W ten sposób opracowano np. Mastodona (za chwilę wrócimy do innych aplikacji, bo nie jest to jedyna) - platformę mikroblogową bez reklam, która przypomina Twittera, choć nim nie jest i istnieją pewne funkcjonalne różnice. One jednak nie są interesujące w kontekście tego artykułu. Teraz wyobraźmy sobie, że możemy postawić takiego Mastodona u siebie, na swoim serwerze i to bez pytania autora. Możemy nawet na ten serwer samodzielnie przyjąć użytkowników, choć wiadomo, że pewnie stosunkowo niewielu, gdyż nie dysponujemy takimi zasobami jak duże firmy. To przypomina trochę czasy forów internetowych i mniejszych społeczności skupionych wokół konkretnego tematu. Natomiast, wracając do posiadania serwera, zwróćmy uwagę, że nie jesteśmy jedyni - nasz sąsiad również może skonfigurować swoją maszynę z Mastodonem. Inne osoby również. Każdy z nich staje się administratorem swojej instancji i może przyjąć do siebie pewną liczbę użytkowników lub mieć serwer tylko dla siebie. I teraz następuje moment kulminacyjny - te instancje mogą się komunikować ze sobą. Są na różnych serwerach, mają osobne bazy danych, ale użytkownik z instancji A może obserwować użytkownika z instancji B i odpowiadać mu. To nie jest system forów, które nie są ze sobą połączone - tutaj mówimy o "federacji serwerów" i tworzeniu jednego wielkiego systemu złożonego z autonomicznych jednostek zarządzanych przez lokalne (lub mniej lokalne) społeczności. Przypomina to trochę świat i komunikację obywateli różnych krajów, którzy stanowią jedną globalną wioskę. Oczywiście, tak jak w dyplomacji, tak tutaj może się zdarzyć, że dwie instancje ze sobą "nie rozmawiają", ale są to marginalne przypadki.

Kwestia instancji i komunikacji pomiędzy nimi będzie niezmiernie kluczowa w drugiej części naszej przygody, a więc podczas komentowania artykułu z poziomu blogu. Przy okazji - federacja to wspaniały przykład jednego z rodzajów systemów rozproszonych.

No dobrze, a czym jest zatem Fediverse? Pośrednio odpowiedzieliśmy na to wyżej - jest to możliwość grupowania się instancji w federacje i tworzenia wrażenia jednego wielkiego systemu, ale istnieje jeszcze jeden aspekt. Wróćmy na chwilę do Twittera. Mając w nim konto, widzimy posty innych użytkowników tego portalu, możemy im odpowiadać, dodawać do ulubionych itd. Jednak nie możemy z poziomu tego samego konta obserwować kogoś na Instagramie lub Facebooku. Nie możemy też skomentować filmu znajomego na YouTubie korzystając z LinkedIna. Aby to zrobić, musimy mieć profil na każdym z tych portali i korzystać z nich osobno. Tymczasem, w świecie federacyjnym Mastodon nie jest jedyną możliwą aplikacją. Ba - nie jest nawet jedynym portalem mikroblogowym, gdyż istnieje choćby Pleroma, Soapbox, Misskey czy obiecujący Calckey (o którym wiadomo, że zmieni nazwę, ale w chwili pisania tego tekstu nie jest ona znana). Również inne "centralki" mają swoje odpowiedniki. Fani Instagrama odnajdą się w Pixelfedzie, widzowie na YouTubie zainteresują się PeerTubem, a redditowcy lub wykopowcy powitają Lemmy'ego lub polski /kbin. Nawet miłośnicy książek zamiast Goodreads posiadają alternatywę w postaci BookWyrma. Dlaczego o tym wszystkim piszę? Dlatego, że te wszystkie portale korzystają z jednego bazowego systemu (nie wchodząc w szczegóły - implementują jego interfejs) zwanego ActivityPub, dzięki czemu mając konto na Mastodonie (a raczej jednej instancji Mastodona) możemy skomentować zdjęcie kolegi z Pixelfeda (i znowu - raczej jednej instancji Pixelfeda), a zaraz zostać zaobserwowanym przez użytkownika z instancji Soapboxa, który wspomni o koleżance z instancji Calckeya. Oczywiście, są wyjątki lub pewne specyficzne funkcje dostępne tylko w określonych aplikacjach, ale wszystkie portale mogą być ze sobą połączone. A są ich tysiące.

Inną, ciekawą metaforę zaproponował Tomasz Dunia na swoim blogu, porównując Fediverse do całego Wszechświata, w którym są galaktyki (Mastodon, Pixelfed, Friendica itd.), składające się z planet (konkretne instancje). Z kolei ActivityPub to prądy, którymi poruszamy się swoim pojazdem garażującym na konkretnej planecie (naszym kontem na jednej z instancji) z jednej planety do drugiej lub nawet między galaktykami. Oczywiście, nic nie stoi na przeszkodzie, aby mieć wiele kont na różnych portalach i jest to nawet powszechne. Tym niemniej, z powodzeniem można używać jednego profilu.

Tak przedstawia się ta idea i jest ona dostępna za darmo (opiera się na datkach społeczności, ew. dodatkowych usługach), co idealnie wpisuje się w bazę dla systemu komentarzy. Czy scentralizowane systemy społecznościowe to faktyczne niebezpieczeństwo to kwestia sporna i zależy od punktu widzenia oraz często filozofii życiowej, w tym podejścia do korporacji. Wszystko ma swoje zalety i wady, także Fediverse, dlatego warto znać tę koncepcję, aby poszerzać swoje horyzonty. Warto również wspomnieć o tym, że duże firmy też zainteresowały się federacjami i zapewniły (lub zapewniają) integrację z nimi - mam tutaj na myśli np. Wordpressa, Tumblra oraz Flipboarda. Nie jest to jedyna próba "odcięcia" się od tzw. "big techu" - na horyzoncie pojawiły się rozwiązania alternatywne w postaci Nostr czy tworu byłego twórcy Twittera Jacka Dorseya, Bluesky. Należy też pamiętać o protokole do komunikacji bezpośredniej, a mianowicie Matrix.

System komentarzy opisywany w tym artykule polega w całości na Mastodonie, gdyż wykorzystujemy nie tyle Fediverse, co API samej aplikacji. To akurat różni się w zależności od portalu, natomiast jeśli np. Calckey miałby API kompatybilne z Mastodonem (a są na to pewne szanse), to przedstawione rozwiązanie działałoby również z nim. Natomiast dlaczego blog nie może po prostu implementować ActivityPub? Otóż, mógłby to zrobić, ale z rozmysłem nie podążyliśmy tą drogą ze względu na to, żeby uniknąć obsługi kont użytkowników. Jednak, jeśli ktoś zainteresowany tym tematem, to tą drogą podąża Wordpress.

Wyświetlenie wątku komentarzy

Czas na konkrety, gdzie przyda się wcześniej przywoływany gotowy przykład, do którego często będziemy się odnosić. Tak, jak pisałem, w tej części skupimy się na samym odczycie komentarzy. Wymaga to wykonania następujących kroków:

  1. Określenie pewnych tootów (postów) jako "źródłowe".
  2. Pobranie z API treści zarówno tootów źródłowych, jak i odpowiedzi na nie.
  3. Sformatowanie treści, aby można było je bezpiecznie wyświetlić na blogu.
  4. Wyświetlenie komentarzy w postaci wątku.

Samo podejście do odczytu nie jest bardzo oryginalne, gdyż opierałem się na implementacjach zaproponowanych przez Carla Schwana, Daniela Pecosa Martineza oraz Patricka Curry'ego, dostosowując je do PHP-a i poprawiając w paru miejscach, choćby przy wcięciach czy obsłudze przypadków wyjątkowych.

Określenie pewnych tootów (postów) jako "źródłowe"

Wróćmy do przywoływanego wcześniej artykułu o szachach. Gdy przewiniemy do systemu komentarzy, zobaczymy dwa tooty w kolorze żółtym, które są wyraźnie wyróżnione - są to tzw. tooty źródłowe. Stanowią one bazę dla odpowiedzi, które z kolei będą traktowane przez nasz system jako komentarze. Są więc takim "punktem zaczepienia". Tutaj uwaga - moglibyśmy zrezygnować z ich wyświetlania i skupić się na samych odpowiedziach, natomiast warto wziąć pod uwagę to, że tooty źródłowe również mają jakiś tekst i to do nich zwykle odnoszą się komentujący użytkownicy. Może być też ich wiele, co oznacza, że trzeba przygotować się na więcej niż jeden wątek odpowiedzi. W niczym nam to jednak nie przeszkadza, a zapewnia wręcz większą elastyczność, jeżeli inna osoba tootowałaby o naszym artykule i chcielibyśmy umieścić również odpowiedzi pod jego wpisem (oczywiście, warto zapytać najpierw o zgodę).

W bazie danych, gdzie znajdują się same artykuły (w tabelkach post oraz post_translation, gdyż dbamy o wielojęzyczność), istnieje tabela post_comment_source, która zawiera informację o tootach źródłowych:

CREATE TABLE post_comment_source (
	id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
	post_id BIGINT UNSIGNED NOT NULL,
	language_id BIGINT UNSIGNED NOT NULL,
	mastodon_instance VARCHAR(128) NOT NULL,
	mastodon_user VARCHAR(128) NOT NULL,
	mastodon_toot_id VARCHAR(128) NOT NULL,
	data_received MEDIUMTEXT NULL COLLATE,
	date_data_received TIMESTAMP NULL DEFAULT NULL,
	PRIMARY KEY (id),
	CONSTRAINT post_comment_source_language_id_foreign FOREIGN KEY (language_id) REFERENCES language (id),
	CONSTRAINT post_comment_source_post_id_foreign FOREIGN KEY (post_id) REFERENCES post (id)
);

Przykład danych:

{
	id: 1,
	post_id: 1,
	language_id: 1,
	mastodon_instance: "social.wildasoftware.pl",
	mastodon_user: "wilda",
	mastodon_toot_id: "110435606334801439"
}

Jak widać, nie dość, że do każdego artykułu możemy dołączyć wiele tootów źródłowych (tutaj akurat jest przykład jednego), to dodatkowo rozróżnić je w zależności od języka. W naszym przykładzie pod "jedynką" w language figuruje język angielski. Dane toota prowadzą do tego wpisu, gdzie w linku możecie zobaczyć, że zgadzają się wszystkie informacje. Pola data_received oraz date_data_received omówimy później - są związane z cache'owaniem wartości.

Warto wspomnieć o tym, że pewną wadą tego rozwiązania jest konieczność ręcznego dodania linków do tootów, co ma miejsce już po opublikowania tych wpisów, a więc będzie istniało tę parę minut, przez które na stronie nie będą wyświetlane komentarze. Nie jest to duży problem, natomiast jego ominięcie może się wiązać z większą pracą i przygotowaniem infrastruktury do jednoczesnego umieszczenia toota i dodawania go do bazy danych, czego tutaj nie będziemy omawiać.

Pobranie z API treści zarówno tootów źródłowych, jak i odpowiedzi na nie

Jeśli uruchomicie przykładowy projekt lub przyjrzycie się uważnie komentarzom na naszym blogu, to zauważycie, że nie są one ładowane od razu - pojawiają się dopiero po chwili od momentu przewinięcia strony do sekcji z wpisami. O takim sposobie mówimy, że są ładowane na żądanie lub że jest to lazy loading - dane są wczytywane dopiero wówczas, kiedy rzeczywiście są potrzebne. W tym przypadku ma to dużą zaletę - nie obciążamy ani naszego bloga, ani instancji z tootami źródłowymi, gdy użytkownik nie jest zainteresowany komentarzami, czyli kiedy w ogóle nie chce ich wyświetlić. Zapewnienie tego nie jest takie trudne - zerknijmy na pliki w przykładzie. Gdy wchodzimy na np. pierwszy artykuł poprzez URL /post/1, przechodzimy przez BlogController, w którym pobieramy informacje o samym artykule i tootach źródłowych, przekazując dane na widok blog-post.blade.php (jak widać, korzystamy z silnika szablonów Blade), w którym wywołujemy skrypt post.js:

// blog-post.blade.php
...
<div>
	...
	@if (count($commentSourceIds) > 0)
		<div class="row pb-3">
			<div id="comment-container" class="col-12">
				<h2 class="comments-header pb-3">{{ __('comments') }}</h2>
				<div id="comment-container-internal">{{ __('loadingComments') }} </div>
			</div>
		</div>
	@endif
	...
</div>

<script src="<?= URL::to('/') ?>/js/post.js"></script>
<script>
	(new PostScript(
		"<?= URL::to('/') ?>",
		<?= $post->id ?>,
		<?= json_encode($commentSourceIds) ?>,
		<?= json_encode([
			'enterMastodonDomain' => __('enterMastodonDomain'),
		]) ?>,
		<?= !empty($mastodonCode) ? '"'.$mastodonCode.'"' : '' ?>
	)).init();
</script>

// post.js
class PostScript {

    constructor(baseUrl, postId, commentSourceIds, translations, mastodonCode) {
        ...
        this.isCommentContainerLoaded = false;
    }

    init() {
		...
		if(this.commentSourceIds.length > 0 && !this.mastodonCode) {
			const observer = new IntersectionObserver((entries, observer) => {
				entries.forEach(entry => {
					if(entry.intersectionRatio > 0) {
						this.loadComments();
					}
				});
			}, { root: null });

			observer.observe(document.getElementById('comment-container'));
		}		
		...
	}
		
	loadComments(withFormInitiating = false) {
		if(this.isCommentContainerLoaded) {
			return;
		}

		$.get(this.baseUrl + 'post/comment', { sourceIds: this.commentSourceIds }, (page) => {
			$('#comment-container-internal').html(page);
			this.isCommentContainerLoaded = true;

			if(withFormInitiating) {
				// later in the second part: initializing the answer form
			}
		});
	}
}

Tworzymy kontener, do którego będziemy wczytywać komentarze. Zauważmy, że jeśli przy artykule nie ma podanych żadnych tootów źródłowych, to nie będzie żadnych komentarzy, więc ten div nie będzie potrzebny - stąd instrukcja warunkowa. Jedna uwaga ogólna - nie będziemy tutaj szczegółowo omawiać stylowania (w czym pomaga Bootstrap) oraz internacjonalizacji (tłumaczenia poszczególnych tekstów znajdują w tym pliku). Nie poruszymy również tematu samego Laravela czy MVC, natomiast liczę na to, że przykłady będą w stanie pokazać odpowiedni kierunek prac.

W funkcji init widzimy fragment, który odpowiada za reakcję w przypadku, kiedy użytkownik przewinie stronę do miejsca z komentarzami i istnieją jakieś tooty źródłowe. Technicznie opiera się to na klasie IntersectionObserver, która reaguje w sytuacji, kiedy użytkownik wyświetli fragment strony zawierający dany element HTML, czyli nasz kontener. Wtedy uruchamia się pobieranie komentarzy z naszego kontrolera na podstawie ID-ków wpisów z tootami źródłowymi w bazie danych. Na razie nie przejmujmy się zmiennymi mastodonCode oraz withFormInitiating - one będą wykorzystywane dopiero przy samym komentowaniu.

Pozostała nam do omówienia najważniejsza część - wykorzystanie API Mastodona do pobrania treści tootów. To już jednak ma miejsce w kontrolerze BlogController, gdzie znajduje się metoda comments, na którą wskazuje routing.

Kod metody w kontrolerze omówimy partiami.

public function comments(Request $request) {
	$sourceIds = $request->get('sourceIds', []);
	if(empty($sourceIds)) {
		return response('Missing comment source IDs', 400);
	}

	$commentSources = $this->postCommentSourceRepository->getByIds($sourceIds);
	$mastodonToots = [];

	$now = new \DateTime();

	foreach($commentSources as $source) {
		//...
	}

	return view('inc/blog-post-comments', $this->presenter->formatComments(['mastodonToots' => $mastodonToots]));
}

Przede wszystkim warto zadbać o to, żeby wywołując tę metodę, sprawdzić, czy na pewno nikt nie zrobił tego "złośliwie", wysyłając pustą listę tootów źródłowych. W takim przypadku nie ma sensu wykonywać dalszych operacji - zwracamy kod HTTP 400 (Bad Request). Upewniamy się przy tym, że w normalnym trybie nigdzie w aplikacji taka sytuacja nie wystąpi - jeśli prześledzimy od początku kod podany wyżej i ten, to zauważymy, że comments zostanie wywołane tylko w momencie, kiedy istnieją jakiekolwiek tooty źródłowe. Te zabezpieczenia zostały wprowadzone na wypadek prób ataków i są swego rodzaju standardem, związanym także z optymalizacją wykonywania się kodu.

Następnie pobieramy resztę informacji o tootach źródłowych, czyli wcześniej przywoływaną instancję Mastodona, login użytkownika i ID toota. I tutaj ktoś może rzec, że zrobiliśmy to nieoptymalnie - mogliśmy pobrać te informacje za pierwszym razem, przy wyświetlaniu posta, w ten sposób oszczędzając na jednym zapytaniu do bazy (można to prześledzić czytając cały kod klasy BlogController). Tylko że wówczas musielibyśmy te wszystkie informacje przekazywać z kontrolera na widok, z widoku do skryptu JavaScript, a później ze skryptu do metody w kontrolerze, sztucznie wydłużając żądanie HTTP. Stąd taka optymalizacja nie tyle czasowa, co estetyczna (choć w przypadku zbyt wielu wpisów źródłowych i zbyt długich informacji, mogłoby się zdarzyć, że w którymś momencie serwer odmówiłby przyjęcia zbyt długiego URL-a, w którym byłyby zawarte te wszystkie parametry). Warto też zwrócić uwagę na zmienną mastodonToots, która będzie przechowywała pobrane tooty - dlaczego w ogóle piszemy wszędzie (także w bazie danych) przedrostek "mastodon"? Przecież nie dość, że wydłuża to nazwy pól i zmiennych, to jeszcze "ogranicza nas", gdybyśmy chcieli zmienić źródło komentarzy. Tak, to prawda - ale zauważmy, że kod jest przygotowany także na sytuację, w której komentarze będziemy pobierać z innych aplikacji i każda z nich będzie wymagała nieco innego sposobu. Gdy zerkniemy na wcześniej opisywaną tabelę post_comment_source, to zobaczymy, że równie dobrze można tam dodać kolejne pola dotyczące np. Facebooka czy Pixelfeda i nadal nie trzeba będzie zmieniać nazwy tabeli. Tak samo w metodzie comments mogą istnieć kolejne części funkcji, które będą zbierać wpisy z innych portali i tworzyć większy konglomerat niż tylko mastodonToots. Stąd taki drobny niuans dot. nazewnictwa zmiennych, który został zastosowany świadomie.

Widzimy też, że pobieramy aktualny czas (przydatny zaraz przy cache'owaniu) oraz na końcu będziemy zwracać widok HTML z przetworzonymi komentarzami. Do tego zaraz dojdziemy. Przejdźmy teraz do wnętrza pętli foreach.

foreach($commentSources as $source) {
	if(!empty($source->data_received)) {
		$cacheDate = new \DateTime($source->date_data_received);
		$diff = $now->getTimestamp() - $cacheDate->getTimestamp();

		if($diff <= 600) {
			$mastodonToots[] = json_decode($source->data_received, true);
			continue;
		}
	}

	try {
		$url = 'http://'.$source->mastodon_instance.'/api/v1/statuses/'.$source->mastodon_toot_id;
		$response = Http::get($url);
		if($response->successful()) {
			$toot = json_decode($response->body(), true);

			$url .= '/context';
			$commentsResponse = Http::get($url);
			if($commentsResponse->successful()) {
				$comments = json_decode($commentsResponse->body(), true)['descendants'];
				$toot['comments'] = $comments;

				$mastodonToots[] = $toot;
			}
			else {
				Log::error('Error during calling '.$url);
				Log::error($commentsResponse->status().': '.print_r($commentsResponse->body(), true));
			}

			PostCommentSource::where('id', $source->id)->update([
				'data_received' => json_encode($toot),
				'date_data_received' => $now->format('Y-m-d H:i:s'),
			]);
		}
		else {
			Log::error('Error during calling '.$url);
			Log::error($response->status().': '.print_r($response->body(), true));
		}
	}
	catch(\Exception $e) {
		Log::error($e->getMessage());
		Log::error($e->getTraceAsString());
	}
}

Pomińmy na razie pierwszego ifa i skupmy się na zawartości bloku try - dla każdego toota źródłowego musimy wywołać dwa żądania:

Warto wspomnieć, że termin "toot" związany z Mastodonem jest raczej stosowany wśród normalnych użytkowników - od strony technicznej są to statusy. Stąd to słowo pojawia się w wywołaniach API (czynionych u nas za pomocą biblioteki Guzzle) do konkretnej instancji. Nie wdając się w szczegóły - najpierw pobieramy samego toota, konwertujemy JSON-a na tablicę PHP-ową, a następnie pobieramy wszystkie komentarze, doisując je do oryginalnego toota. Potem dodajemy wpis na tablicę i przechodzimy do kolejnego źródła. Jeśli jakaś operacja się nie powiedzie, zapisujemy ten fakt w logach oraz - co istotne - sprawdzamy kolejne źródła lub prawidłowo zwracamy wynik, choćby był pusty. Nie może wystąpić sytuacja, w której użytkownik czeka w nieskończoność na pobranie komentarzy, nie mając świadomości, że po drodze np. jedna instancja nie odpowiada i blokuje całą operację.

Wróćmy teraz do miejsc, w których wykorzystywane są pola data_received oraz date_data_received. Po co w ogóle są nam potrzebne? Rozważmy sytuację, w której umieszczamy artykuł na stronie, publikujemy toota i w ciągu minuty wchodzi na niego 100 osób, którzy czytają w miarę równym tempie i docierają do sekcji komentarzy. To oznacza, że dla każdej z tych osób musimy wykonać po 2 żądania do API Mastodona na każdy toot źródłowy. Co więcej, w tak krótkim czasie te żądania zwrócą te same dwa wyniki, gdyż nie zdążą się pojawić nowe wpisy w międzyczasie. Widzimy zatem, że jest tutaj pole na optymalizację i cache'owanie wyników, co można osiągnąć zapisywaniem pobranych danych wraz ze znacznikiem czasowym. Do tego służą właśnie omawiane pola. Następnie, przy innych żądaniach (np. druga osoba "dojechała" do sekcji komentarzy), sprawdzamy czy zapisane dane są "dostatecznie nowe" (w naszym przypadku czasem granicznym będzie 600 sekund, czyli 10 minut; nawiasem mówiąc, ta wartość powinna być w parametrach i możliwie łatwa w modyfikacji). I rzeczywiście - jeśli wejdziemy na artykuł z komentarzami za pierwszym razem, wywołując pobranie komentarzy, a następnie odświeżymy stronę, to prawdopodobnie wpisy załadują się nam dużo szybciej, gdyż są pobierane z lokalnej bazy danych, a nie z innego serwera (instancji Mastodona). Aż do kolejnych 10 minut.

Jest to optymalizacja nie tylko czasowa i to dobry moment, aby wrócić do federacyjnej natury Mastodona. Pamiętajmy, że nasz kod odpytuje API realnej instancji, która jest zarządzana przez pewnego człowieka, dysponującego serwerem, na jaki go stać. W niektórych usługach istnieją limity na przesyłaną liczbę bajtów, a same serwery mają swoje restrykcje dotyczące liczby przetwarzanych żądań. To oznacza, że nasz bardzo popularny artykuł, który ma dużo komentarzy, może czasowo obciążyć serwer instancji, na czym ucierpią zwykli użytkownicy oraz administrator, jeśli płaci np. za wykorzystany transfer w chmurze. Dlatego już po stronie samego Mastodona istnieją domyślne ustawienia blokujące zbyt częste zapytania z jednego źródła. Jednak, aby nie nadwyrężać instancji oraz nie narażać administratora i naszego bloga na straty, warto zastosować cache'owanie.

Nie są to duże liczby - jednorazowe pobranie komentarzy do artykułu o szachach to ok. 14 KB transferu i 350 ms czasu oczekiwania na odpowiedź. Przy 50 takich podwójnych żądaniach jest to 700 KB - to nadal niewiele. Ale przy większej liczbie lub popularności utrzymującej się przez dłuższy czas oraz przy chęci zachowania zwykłej przyzwoitości warto skusić się na przechowywanie części danych u siebie.

Sformatowanie treści, aby można było je bezpiecznie wyświetlić na blogu

W porządku, mamy dane. Teraz można je wyświetlić. Ale zanim to zrobimy, musimy je jeszcze przetworzyć.

public function comments(Request $request) {
	...
	return view('inc/blog-post-comments', $this->presenter->formatComments(['mastodonToots' => $mastodonToots]));
}

Widzimy, że przed wysłaniem danych na widok, przekształcamy je w tzw. prezenterze, a więc klasie, która "czyści" dane przed obróbką HTML-ową. Zgodnie bowiem z podejściem MVC i dobrymi obyczajami, widok powinien zadbać tylko o wyświetlenie danych, a nie ich dodatkowe formatowanie. Jednocześnie wiadomo, że nie powinien się tym zajmować też kontroler czy model. Stąd czasem pomiędzy tymi dwiema warstwami umieszcza się prezentery, które wykonują "brudną robotę". W przypadku aplikacji angularowych często stosuje się do tego tzw. pipe'y.

A mówimy tutaj nie tylko o ewentualnej zmianie struktury, ale też usunięciu pewnych informacji w trosce o bezpieczeństwo. Zwróćcie uwagę, że użytkownicy Mastodona mają dość dużą dowolność w uzupełnianiu informacji o sobie, mogąc np. dokładać do nicka różne emoji. Dodatkowo, w samych tootach wypada sprawdzić, czy nie zostały tam umieszczone złośliwe skrypty JS, narażające nas na tzw. atak XSS (Cross-Site Scripting).

Dodatkowo zachodzą też operacje stricte estetyczne, jak choćby odpowiednie sformatowanie daty wpisu. Nie ma sensu omawiać całego kodu - poniżej przedstawiam treść klasy BlogPresenter. Warto natomiast zwrócić uwagę na obliczanie głębokości (ang. depth) wpisu, gdyż zaraz będzie nam to potrzebne przy wyświetlaniu.

class BlogPresenter {

    public function formatComments(array $input): array {
        $output = $input;

        $replyCount = [];

        foreach($output['mastodonToots'] as &$toot) {
            $toot = $this->presentComment($toot);
            if(!empty($toot['in_reply_to_id'])) {
                if(!array_key_exists($toot['in_reply_to_id'], $replyCount)) {
                    $replyCount[$toot['in_reply_to_id']] = 0;
                }
                $replyCount[$toot['in_reply_to_id']]++;
            }

            foreach($toot['comments'] as &$reply) {
                $reply = $this->presentComment($reply);
                if(!empty($reply['in_reply_to_id'])) {
                    if(!array_key_exists($reply['in_reply_to_id'], $replyCount)) {
                        $replyCount[$reply['in_reply_to_id']] = 0;
                    }
                    $replyCount[$reply['in_reply_to_id']]++;
                }
            }
        }

        $depths = [];
        $isIncreasingChildrenDepth = [];
        
        // setting an appropriate toot's depth in terms of responded post
        foreach($output['mastodonToots'] as &$toot) {
            $isIncreasingChildrenDepth[$toot['id']] = false;
            
            $depth = 0;
            $toot['depth'] = $depth;
            $depths[$toot['id']] = $depth;

            foreach($toot['comments'] as &$reply) {
                $isIncreasingChildrenDepth[$reply['id']] = false;

                $depth = ($depths[$reply['in_reply_to_id']] ?: 1)
                    + (!empty($isIncreasingChildrenDepth[$reply['in_reply_to_id']]) ? 1 : 0);
                $reply['depth'] = $depth;
                $depths[$reply['id']] = $depth;

                if($replyCount[$reply['in_reply_to_id']] > 1) {
                    $isIncreasingChildrenDepth[$reply['id']] = true;
                }
            }
        }

        return $output;
    }

    private function presentComment(array $comment) {
        $output = $comment;
        $output['account']['display_name'] = htmlspecialchars($output['account']['display_name']);
        $output['account']['avatar_static'] = htmlspecialchars($output['account']['avatar_static']);

        foreach($output['account']['emojis'] as $emoji) {
            $code = ':'.$emoji['shortcode'];
            $staticUrl = htmlspecialchars($emoji['static_url']);
            $output['account']['display_name'] = str_replace($code, 'Emoji '.$code.'', $comment['account']['display_name']);
        }

        if(!strpos($output['account']['acct'], '@')) {
            $parsedUrl = parse_url($output['account']['url']);
            if(!empty($parsedUrl)) {
                $output['account']['acct'] .= '@'.$parsedUrl['host'];
            }
        }

        $output['created_at'] = (new DateTime($output['created_at']))->format('d.m.Y H:i:s');

        return $output;
    }
}

Wyświetlenie komentarzy w postaci wątku

W tym, ostatnim już, etapie, czekają na nas dwa wyzwania. Pierwsze z nich to samo wyświetlenie bloczka z komentarzem. Drugie to obliczenie odpowiedniego wcięcia. I na tych ostatnich na chwilę się zatrzymamy.

Gdy wejdziemy do komentarzy artykułu o szachach, to zobaczymy, że niektóre komentarze są wcięte, poczynając, oczywiście, od odpowiedzi bezpośrednio odnoszących się do toota źródłowego. Jednak, jeśli ktoś odpowiada na odpowiedź, to teoretycznie również powinien zostać dodany odstęp, ale nie zawsze tak się dzieje. Sytuacja zmienia się, gdy powstaną dwa niezależne wątki odpowiedzi na jednego toota - wówczas dodatkowy margines jest konieczny lub przynajmniej przydatny. Cóż, nie jest to łatwy problem.

Dlatego już w powyżej przedstawionym prezenterze, pod koniec metody formatComments, następuje obliczenie głębokości za pomocą następującego algorytmu, który najpierw przedstawimy stricte technicznie.

  1. Przygotowujemy tablicę replyCount zawierającą liczbę odpowiedzi na danego toota.
  2. Przygotowujemy tablicę isIncreasingChildrenDepth (w skrócie iicd) oraz depths dla każdego toota.
  3. Dla toota źródłowego głębokość wynosi 0 a iicd wynosi false.
  4. Dla każdego komentarza głębokość wynosi głębokość toota, na którego jest to odpowiedź lub 1.
  5. Jeśli odpowiedziany toot ma ustawione true w iicd, głębokość komentarza jest zwiększana o 1.
  6. Jeśli liczba odpowiedzi odpowiedzanego toota jest większa niż 1, wartość iicd dla tego toota zmienia się na true.

Przyznaję, że prześledzenie tego wymaga rozpisania sobie przykładu. Dlatego może przełóżmy ten opis na bardziej ludzki.

  1. Tooty źródłowe zawsze mają głębokość 0.
  2. Jeśli toot odpowiada bezpośrednio na toot źródłowy, zawsze ma głębokość 1.
  3. Jeśli toot X jest odpowiedzą na toota Y, który nie ma więcej odpowiedzi, to głębokość toota X jest równa głębokości toota Y (następują tuż po sobie).
  4. Jeśli toot X jest odpowiedzią na toota Y, który ma więcej odpowiedzi niż 1, to głębokość toota Y jest równa głębokości toota Y plus 1.

Ta głębokość jest dopisywana do każdego toota w prezenterze, a następnie w taki sposób przekazywana do widoku:

// blog-post-comments.blade.php

@if (count($mastodonToots) > 0)
    @foreach($mastodonToots as $toot)
        @include('inc/blog-post-comment-box', ['comment' => $toot, 'isReply' => false])

        @foreach($toot['comments'] as $reply)
            @include('inc/blog-post-comment-box', ['comment' => $reply, 'isReply' => true])
        @endforeach
    @endforeach
@else
    {{ __('noComments') }}
@endif

// blog-post-comment-box.php

<div class="col-12 comment {{ $isReply ? 'reply' : '' }}" style="
        margin-left: calc(var(--comment-base-indent) * {{ $comment['depth'] }});
        max-width: calc(100% - (var(--comment-base-indent) * {{ $comment['depth'] }}))
    ">
    <div class="comment-author row">
        <div class="comment-author-avatar col-3 col-md-2 col-lg-1">
            <img src="{{ $comment['account']['avatar_static'] }}" alt="">
        </div>
        <div class="comment-author-details col-9 col-md-7 col-lg-8">
            <div class="row">
                <a class="comment-author-details-name col-12" href="{{ $comment['account']['url'] }}" target="_blank" rel="nofollow">{!! $comment['account']['display_name'] !!}</a>
                <div class="comment-author-details-user col-12">{{ $comment['account']['acct'] }}</div>
            </div>
        </div>
        <div class="comment-date col-12 col-md-3 text-right">
            <a href="{{ $comment['url'] }}" target="_blank" rel="nofollow">{{ $comment['created_at'] }}</a>
        </div>
    </div>
    <div class="comment-content row">
        <div class="col-12">
            {!! $comment['content'] !!}
        </div>
    </div>
    <div class="comment-reply-to row">
        <div class="col-12 text-right">
            <i class="comment-reply-link fa-solid fa-reply fa-lg" data-src="{{ $comment['url'] }}" title="{{ __('replyToThisCommentWithMastodon') }}"></i>
        </div>
    </div>
</div>

Tak, jak pisałem, nie będziemy wgłębiać się w stylowanie (odpowiednie dyrektywy znajdziemy w pliku SCSS), natomiast warto zwrócić uwagę na odstępy. Istnieje bazowy margines wynoszący 1.5rem, jednak jest to tylko zmienna CSS-owa, na podstawie której ustalamy jest faktyczne odstawienie bloczka. Ten to wynik mnożenia bazowego marginesu i obliczonej głębokości dla komentarza. Co istotne, nie jest to koniec prac w tym względzie - jeśli poprzestaniemy na odsunięcia bloczka, to zachowa on tę samą długość i przy bardzo złożonych wątkach prawe krawędzie będą wychodziły poza ekran. Dlatego musimy zadbać o analogicznie liczenie stylu max-width, który pozwala obliczyć prawidłową szerokość komentarza.

Inne fragmenty HTML-a są standardowe i można zobaczyć ich działanie w praktyce u nas na blogu lub w projekcie przykładowym.

Podsumowanie

To była część związana z wytłumaczeniem fundamentów, na których opieramy się budując nasz system komentarzy oraz objaśnieniem mechaniki wyświetlania istniejących komentarzy. W tym miejscu robimy pauzę i zapraszamy do zadawania pytań oraz przeczytania drugiej części artykułu, która wyjaśni sposób odpowiadania na tooty bezpośrednio z bloga, co pozwoli nam bardziej zapoznać się z API Mastodona, procesem autoryzacji OAuth oraz mechanizmem SSO.

Jeśli uważacie, że można ten mechanizm poprawić lub znaleźliście w nim jakieś nieścisłości - nie wahajcie się pisać. Im więcej opinii różnych osób i dyskusji, tym więcej wiedzy i przemyśleń mogą wynieść z tego programiści oraz inne osoby zainteresowane tematem.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Gucio i jego żaby a wytrwałość programistów https://wildasoftware.pl/post/gucio-jego-zaby-wytrwalosc-programistow?ref=rss https://wildasoftware.pl/post/gucio-jego-zaby-wytrwalosc-programistow?ref=rss Thu, 25 May 2023 17:30:00 +0000 Internet naprawdę jest dziwnym miejscem. Wiadomo, że to skarbnica wiedzy, informacji oraz narzędzie do komunikacji. Jednocześnie - miejsce rozrywki i to czasem... niebanalnej lub takiej, której w życiu byśmy się nie spodziewali, że może kogoś interesować. A co zabawniejsze, czasem takie "wygłupianie się" może posłużyć jako inspiracja do przemyślenia pewnych "poważniejszych" spraw i podzielenia się swoimi refleksjami np. na temat tworzenia oprogramowania.

Świat gier wideo niesamowicie się rozrósł i to na wszystkich płaszczyznach - istnieje dużo narzędzi dla potencjalnych twórców (dzięki czemu nie tylko wielkie studia mogą tworzyć produkcje dla masowego odbiorcy), technologia pozwala tworzyć coraz bardziej zaawansowane tytuły, toczą się poważne rozgrywki w grach sieciowych, nierzadko interaktywna fabuła stoi na poziomie porównywalnym z filmową, w tle przerzucane są duże pieniądze, a to wszystko sprawia, że elektroniczna rozrywka weszła do tzw. mainstreamu i stała się elementem popkultury. Gry przeniknęły do naszego życia na tyle mocno, że niektórych fascynuje nie tylko granie, ale nawet oglądanie. A to objawia się w postaci streamowania swojej rozgrywki przez różne osoby i specyficznej kultury oraz wydarzeń z tym związanych. Czasami są one zrozumiałe tylko dla osób w danej "bańce", czasem dla szerszego, ale nadal wtajemniczonego grona, ale od czasu do czasu zdarzy się coś, o czym słychać nawet w "niegrowych" mediach. I tak było na początku maja 2023 r. ze streamerem o nicku Gucio.

Mniej więcej w tym okresie na rynku pojawiła się gra Star Wars Jedi: Survivor, która jest kontynuacją wcześniejszej produkcji Star Wars Jedi: Fallen Order. Oba tytuły należą do tzw. podgatunku Soulslike, a więc gier cRPG widzianych z perspektywy trzeciej osoby i nastawionych na akcję, wyróżniające się naturalnie wysokim poziomem trudności. Gracze doświadczają w nich wielu śmierci i powtarzania poszczególnych walk, ale za to są wynagradzani dużą satysfakcją po pokonaniu bossów, których często trzeba się po prostu "uczyć" i poznać ich zachowania na drodze wielu porażek. Nazwa nurtu wzięła się od najpopularniejszej serii tego typu, a więc Dark Souls, aczkolwiek warto wspomnieć również o Bloodborne, Elden Ringu czy Sekiro: Shadows Die Twice, gdyż to najpopularniejsi przedstawiciele tego gatunku. Czytając opis, łatwo domyślić się, że dla niektórych bardziej radosne niż sama gra będzie oglądanie zmagań innej osoby i jej czasami nieudolnych prób poradzenia sobie z wyzwaniem, ale także obserwowanie sukcesów. Nie mówiąc o tym, że niektórzy wyćwiczyli się w tego typu grach na tyle, że narzucają sobie dodatkowe wyzwania w stylu przejścia gry bez jednego draśnięcia lub nawet z użyciem elektroencefalografu. Jednak są to jednostki - czasem nawet zwykły sposób pokonania gry stanowi wyzwanie. I tutaj wracamy do Gucia.

Ten na swojej transmisji spróbował swoich sił właśnie z nową grą z uniwersum Gwiezdnych Wojen, wiedząc, że czeka go trudna batalia, zwłaszcza, że wybrał najwyższy poziom trudności. Tym niemniej, nie spodziewał się, że pokonanie jednego z opcjonalnych bossów, a więc dwóch ogromnych żab będzie aż tak skomplikowane. Ale co to za gracz Soulslike, który odpadnie po paru porażkach, prawda? Więc spróbował znowu. I znowu. I jeszcze raz. I kolejny... W ten sposób w pierwszej sesji zajęło mu to 22 godziny, po czym następnego dnia (albo raczej nocy) przystąpił do kolejnego szturmu i po dalszych 7 godzinach w końcu poradził sobie z Oggdo Bogdo oraz jego (jej?) pomiotem. Streamerowi zajęło to łącznie 29 godzin i ponad 1200 śmierci tylko w tym fragmencie rozgrywki. No cóż, wytrwały gracz, pomyślicie. Dlaczego zatem walka Gucia z przerośniętymi płazami stała się wręcz viralem i jakie to miało skutki?

Wpływ na to miała absurdalność wyzwania - umówmy się, większość z nas już po 100-200 śmierciach zaczęłaby szukać innej drogi pokonania tego bossa lub jego ominięcia. Zwłaszcza, że żaby były przeciwnikiem opcjonalnym, a więc niewymaganym do ukończenia gry. Co więcej, większość graczy zaopatrzyłaby się w inny ekwipunek, zestaw umiejętności lub zwyczajnie ukończyłaby parę innych zadań, aby wzmocnić postać i dopiero wtedy wróciła do gigantycznych potworów. Tutaj nie będę ukrywał - nie wiem, czy podejście Gucia było optymalne, aczkolwiek sądząc po różnych komentarzach w Internecie, to na tym etapie rozgrywki i z tym "buildem" było to szaleństwo oraz bardziej sprawa honoru, mająca zmazać na nim plamę po tak wielu zgonach. Żeby było jasne - świetnie że się udało, należą się gratulacje, natomiast warto pamiętać o tym uporze, gdyż to właśnie nić łącząca ten viral z programistami. Ale o tym za chwilę.

Należy jeszcze wspomnieć, jakie liczby wygenerowała nierówna walka Gucia z żabami. Nie była to bowiem wielogodzinna bitwa oglądana przez dziesiątki kibiców - w szczytowym momencie obserwatorów było ok. 60 tysięcy. A mówimy o polskim streamerze i "zwykłym graniu w grę". Popularność tego wydarzenia wyszła daleko poza Twitcha i trafiła do firm niezwiązanych z gamingiem, które zaczęły umieszczać nawiązania do żab w swoich postach promocyjnych (tzw. RTM-y, Real-Time Marketing), a nawet przyjmować zakłady bukmacherskie. A to wszystko już podczas pierwszej, tej 22-godzinnej sesji. To wszystko sprawiło, że Gucio stał się bardzo popularny, a podejrzewam, że sam wydawca gry w Polsce również zacierał ręce widząc szał wokół tej sytuacji i nazwą produktu w tle.

Wróćmy jednak do innego aspektu - uporu, z jakim następowały kolejne podejścia do dwóch żabek (wielkości bardzo dużego człowieka). Trwało to wiele godzin, na pewno powodowało frustrację u gracza (aczkolwiek nieprzesłaniającą motywację) i - powiedzmy wprost - nie było to efektywne wykorzystanie czasu. Czy z tym samym nie mierzą się programiści, gdy próbują wykonać szczególnie uciążliwe zadanie? I nie chodzi mi o wymagania funkcjonalne obliczone na wiele godzin, gdyż te z natury rzeczy albo są dzielone na mniejsze partie lub realizowane etapowo. Bardziej mam na myśli pozornie nieskomplikowane funkcje, w których nie umiemy poradzić sobie z drobnym elementem i blokuje to dalsze prace. Lub nie blokuje, ale czujemy, że musimy to skończyć teraz. Może być to umiejscowienie fragmentów na stronie za pomocą CSS-a lub długotrwałe szukanie drobnego błędu w kodzie, który nie wiadomo kiedy się ujawnia. Jako programiści brniemy w to, gdyż wiemy, że nie powinno to zająć dużo czasu, ale zanim się obejrzymy, mija wiele godzin, a efektów brak. Narasta gniew, zniechęcenie i rzadko jest to motywujące, zwłaszcza, że nie ogląda nas 60 tysięcy kibiców, tylko zdenerwowany kierownik projektu oraz klient. Idąc tropem Gucia, mogłoby to przedłużyć się nawet na kolejne dni w biurze, aż w końcu szef by nie wytrzymał i przekazałby to innej osobie lub kazał odpuścić, a programista skończyłby z poczuciem porażki.

Tylko że najczęściej okazuje się, że jeśli dane zadanie odpuścimy, zajmiemy się czymś innym lub - co najlepsze - wyczyścimy głowę odpoczynkiem po pracy, to rozwiązanie znajduje się samo. Czasem jest to nagłe uświadomienie sobie pewnego aspektu języka, o którym zapomnieliśmy. Niekiedy jest to dojrzała zmiana podejścia, np. struktury elementów w HTML-u, przez co łatwiej je ostylować. Kiedy indziej po prostu nowy pomysł na kawałek kodu i generalnie spojrzenie na problem z dystansu. Nie bez powodu, gdy nie możemy sobie przypomnieć, co chcieliśmy powiedzieć, to najlepszą receptą jest zaprzestanie prób i pomyślenie o czymś innym - mózg pracuje "w tle" i jest szansa, że po jakimś czasie uda nam się wpaść na właściwy trop z innej strony.

Oczywiście, trudno porównywać pracę analityczną, jaką stają się szczególnie trudne okresy w programowaniu do działań fizycznych, wymagających zręczności gracza. Tym niemniej, mechanizm pozostaje taki sam - czasem ślepy upór w niczym nie pomaga, a tylko przeszkadza. Warto "oddalić się", spojrzeć na problem z pewnej perspektywy i zastanowić się, czy są inne drogi do osiągnięcia danego celu. Warto zwrócić uwagę, że w przypadku Gucia dochodziła do tego jeszcze kwestia honoru i przede wszystkim "hajpu", jaki wytworzył się w społeczności, a który prawdopodobnie zniknąłby, gdyby gracz zająłby się innymi zadaniami i do żab wrócił po czasie silniejszy. Obserwatorzy byliby zawiedzeni i opuścili transmisję. Programiści taki dylemat mają rzadko i należy to wykorzystać.

Istnieje jeszcze druga, powiązana sprawa - czasem wszystko idzie jak należy, ale programista ciągle nie jest zadowolony ze swojej pracy. W związku z czym szlifuje część systemu, nad którą właśnie pracuje. Jest to tak zwane polerowanie, które w skrajnym przypadku zmienia się w perfekcjonizm. Nie ma w tym niczego złego, gdyż dbanie o jakość należy pochwalać... o ile nie dzieje się to kosztem harmonogramu i innych zadań. Wielokrotnie widziałem bowiem sytuację, w której zadanie przewidziane na np. 10 godzin trwało 30, ale nie dlatego, że był problem z zaimplementowaniem pewnej funkcji, tylko programista "zapomniał się" i testował różne możliwości, aby uzyskać idealny efekt i zapewnić lepszy rozwój w przyszłości. Normalnie byłyby to cechy godne podziwu, ale zawsze trzeba brać pod uwagę kontekst, a więc np.:

  • obłożenie zadań w projekcie,
  • harmonogram oraz terminy,
  • priorytet oraz znaczenie zadania - jeśli to drobna funkcja, która nie ma wielkiego wpływu na środowisko biznesowe lub nie stanowi bazy dla innych funkcji, to warto odpuścić polerowanie.

Dążę do tego, że trzeba znać dwa powiedzenia - "lepsze jest wrogiem dobrego" oraz "trzeba wiedzieć kiedy ze sceny zejść niepokonanym". Może być tak, że w trosce o zadbanie o najmniejszy szczegół zapędzimy się tak, że zmarnujemy 8 godzin na dobranie odpowiedniej ikony lub obsłużenie przypadku, który nigdy nie wystąpi. Oczywiście, jest to bardzo względne - jeśli zadanie jest ważne i rozwojowe, a sam system skomplikowany, to wiadomo, że lepiej wszystko przetestować oraz poprawić różne przypadki lub przeprowadzić autorefaktoryzację. To już kwestia indywidualna i wymagająca zdrowego rozsądku zarówno programisty, jak i kierownika projektu, a być może także po prostu sygnał, że wycena powinna byc wyższa. Tak samo nie mówimy tutaj o sytuacji, kiedy rdzeń zadania jest dużo bardziej pracochłonny niż początkowo zakładano - w takim przypadku albo oszacowanie było błędne, albo część prac można zostawić na później (i np. zapisać sobie w Feedybackym, aby się nie zgubiło). Natomiast warto przyswoić sobie, że przed przystąpieniem do "polerowania" należy zastanowić się, w jakim stopniu jest ono rzeczywiście potrzebne i wykonalne.

Jak widać, można połączyć kulturę streamerską z programowaniem i nawet czegoś się nauczyć. A może nie i ten cały artykuł (setny na tym blogu) jest jedynie bajdurzeniem? Dajcie znać w komentarzach.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> "Deep Learning" - recenzja ksiązki https://wildasoftware.pl/post/deep-learning-recenzja-ksiazki?ref=rss https://wildasoftware.pl/post/deep-learning-recenzja-ksiazki?ref=rss Thu, 18 May 2023 17:30:00 +0000 Wiadomo, że dobrze czytać książki, a jeszcze lepiej czytać dobre książki. W przypadku literatury fachowej dochodzi do tego jeszcze potrzeba, aby książka była jak najdłużej aktualna i faktycznie niosła ze sobą wiedzę - w końcu nie są to tanie towary. Z tego powodu, czy tego chcemy, czy nie warto nabywać pozycje omawiające podstawy teoretyczne. Z drugiej strony, wiadomo, że często najłatwiej zaznajomić się z tematem poprzez przykłady, co zazwyczaj wymaga wprowadzenia narzędzi, które mają tendencję do starzenia się. A gdyby tak połączyć te dwa obszary i mieć książkę, która zawiera zarówno teorię (wręcz matematyczną), jak i praktykę? Taki miał być "Deep Learning. Praktyczne wprowadzenie z zastosowaniem środowiska Pythona". Przynajmniej teoretycznie - zobaczmy, czy w praktyce też tak jest. Tak, jestem dumny z tego słownego żartu.

Obecnie warto zasięgnąć trochę informacji o sieciach neuronowych lub je rozszerzyć. Powodem jest, oczywiście, stale rosnący udział metod uczenia maszynowego lub - szerzej mówiąc - sztucznej inteligencji w zastosowaniach komercyjnych, co sprawia, że specjaliści w tych dziedzinach, umiejący dobrać, przygotować i pomyślnie wytrenować model będą na wagę złota. A nawet, jeśli programista jest specjalistą w innej dziedzinie lub niecodziennie ma kontakt z podobną funkcjonalnością, to warto przyswoić sobie tę wiedzę lub odświeżyć, jeśli posiada się już podstawy ze studiów. Z takim podejściem rozglądałem się za odpowiednią książką i trafiłem na bohatera dzisiejszego tekstu. Poniżej jego recenzja.

Nie ukrywam, że szczególnie zachęciła mnie obietnica połączenia teorii i praktyki w postaci przykładów kodu, a konktretnie w Pythonie. Jeśli ktoś programuje nie od wczoraj, to doskonale wie, że to właśnie w tym języku powstała bardzo duża pula bibliotek do uczenia maszynowego, statystyki i innych "naukowych" tematów. Stąd ta technologia jest tak lubiana w ośrodkach naukowych i nie tylko, gdyż trzeba przyznać, że Python jest bardzo uniwersalny. Jeśli ktoś potrzebuje konkretów, to w książce zabawa koncentruje się wokół takich paczek jak NumPy, scikit-learn i Keras. Warto wspomnieć, że to wszystko nie oznacza, iż w innych językach nie można wykonywać podobnych obliczeń - też znajdą się tam potrzebne biblioteki. A to ważne dla osób niesympatyzujących z Pythonem stosowanym w książce, która w dodatku nie przedstawia tego kodu bardzo przejrzyście - można zauważyć tutaj trochę skrótów, sklejanie fragmentów w sposób wymagający uwagi (choć tego akurat trudno było uniknąć), wykorzystanie niuansów składni, a jeśli chodzi o estetykę kodu, to pewnie miałbym trochę uwag podczas przeglądu. Natomiast warto wspomnieć, że jeśli ktoś nie zna tej technologii lub nie jest w niej biegły, to nie musi się martwić - cały jeden rozdział jest poświęcony konstrukcjom Pythona, a inny bibliotece NumPy. Jeśli ktoś jest zapoznany z tymi zagadnieniami, to może spokojnie te fragmenty ominąć, szybciej dochodząc do "mięsa".

Nie jest to bowiem książka stricte o kodowaniu, tylko o uczeniu maszynowym, więc omówmy ją pod tym kątem. Trzeba przyznać, że autor (Ronald T. Kneusel, naukowiec specjalizujący się w omawianym temacie) starał się napisać pozycję dla zielonych, choć ambitnych. I niemalże mu się to udało, ale najpierw prześledźmy, co tutaj mamy:

  • przypomnienie zagadnień ze statystyki i algebry liniowej (wektory, macierze), które są stosowane w tym obszarze,
  • informacje dotyczące budowania zestawu danych do uczenia i testowania,
  • klasyczne metody uczenia maszynowego: centroidy, metoda k najbliższych sąsiadów, naiwny Bayes, drzewa decyzyjne, lasy losowe, maszyny wektorów nośnych (SVM),
  • sieci neuronowe nadzorowane - matematyczne omówienie podstaw i zasad uczenia się,
  • miary oceny przydatności modeli, czyli statystyki operujące na macierzy pomyłek (true positive i inne, bardziej złożone wskaźniki, które z tego wynikają),
  • splotowe sieci neuronowe, stosowane głównie do rozpoznawania grafik,
  • klasyfikowanie próbek dźwiękowych.

Na początku powiedzmy sobie jedną rzecz - autor bardzo dużo miejsca poświęca właściwemu przygotowaniu zestawów danych, a także eksperymentom. W mojej ocenie to bardzo ważne, ponieważ uczenie maszynowe nie polega na tym, że bierzemy wybraną metodę (jeszcze najlepiej taką, której nazwa nam się najbardziej podoba), wrzucamy do niej dane i zyskujemy idealny klasyfikator. Bardzo dużo zależy od "wejścia", które zostanie przygotowane i podzielone na zestawy uczące, walidujące oraz testowe. Oczywiście, rekordów powinno być dużo, ale znaczenie mają też atrybuty, czystość i charakter, gdyż to przekłada się później na wybór konkretnej metody. Co więcej, autor opisuje, w jaki sposób rozszerzać zbiór danych, co pomaga modelowi w uczeniu. Trochę zaskoczyło mnie, że z setek danych w ten sposób można zrobić tysiące i model rzeczywiście działa lepiej. W książce przedstawione są metody, jak to się robi.

Eksperymenty też są ciekawą sprawą, gdyż autor poświęca kilka rozdziałów na pokazanie, w jaki sposób zmiany metod dla poszczególnych problemów (zbiorów danych) oraz dobranie odpowiednich parametrów pozwalają podnieść lub zmniejszyć skuteczność modelu. Tak, zmniejszyć - książka pod tym kątem "nie jest nudna" i pokazuje, że nie zawsze zmiana wszystkich ustawień wydłużająca czas nauki powoduje polepszenie rezultatu. Warto korzystać z wniosków oraz wykresów zaprezentowanych przez dr. Kneusela, aby oszczędzić sobie pracy w rzeczywistych przypadkach.

Jeśli chodzi o samo wyjaśnianie metod, to mam wrażenie, że jest dosyć nierówne. W przypadku klasycznych (tzw. płytkich) podejść autor omawia je nieźle, w łatwy do zrozumienia sposób, choć może czasem aż w nieco zbyt skrócony. Nie ukrywam, że gdybym nie miał wcześniej odpowiedniego przedmiotu na studiach, to np. trudniej byłoby mi zrozumieć ideę drzewa decyzyjnego - tam aż prosi się jakiś przykład krok po kroku przy każdej metodzie, aby pokazać zasadę działania danej ścieżki klasyfikacji. Natomiast przy sieciach neuronowych autor wyraźnie za punkt honoru postawił sobie wyjaśnienie tego zagadnienia faktycznie od podstaw. Także tych matematycznych, które nie dla wszystkich są równie zrozumiałe. I mam wrażenie, że trochę przesadził - brakuje mi tutaj (lub je przypadkiem pominąłem) takiego wytłumaczenia na prostym przykładzie, jak działa sieć przy uczeniu się kolejnych informacji, nawet na bardzo małym zbiorze danych, co oznacza zmiana wag itd. Zamiast tego autor skupia się na gradiencie, pochodnych, funkcjach i operowaniu symbolami. Owszem - to powinno być i na pewno jest to coś, co przyda się studentom informatyki czy osobom, chcącym tym zagadnieniem zająć się na poważnie. Ale obawiam się, że programiści chcący zrozumieć faktycznie podstawy sieci od strony praktycznej, aby móc potem używać biblioteki, odbiją się od tej pozycji, chyba że zagryzą zęby lub od razu przejdą do rozdziałów opisujących eksperymenty. Sam w którymś momencie zacząłem bardziej kartkować niż wnikliwie czytać, z czego nie jestem dumny, ale właśnie sądziłem, że wszystko wyjaśni się w doświadczeniach.

Warto też wspomnieć, że w tej książce mamy do czynienia głównie z problemami klasyfikacji i to binarnej (dwie przeciwstawne klasy), ale jak najbardziej uwzględnione są też podejścia z wieloma klasami. To atut tej pozycji - pokazuje, w jaki sposób podchodzić do tego problemu (i to od praktycznej strony), a także jak ocenić, czy dobrze wytrenowaliśmy taki model. W ten sposób przedstawione jest np. klasyfikowanie grafik z cyframi oraz próbkami dźwiękowymi, czemu towarzyszy omówienie drugiego "konika" autora, a więc sieci splotowych (gdzieniegdzie nazywanych też "konwolucyjnymi"). Także w tym przypadku mamy trochę matematyki, ale tym razem jest ona dość zrozumiała. Tym niemniej, zabrakło chyba bardziej czytelnego przykładu, ale to może już moje wygórowane wymagania.

Należy wspomnieć o tym, że w tej książce nie ma omówionych sieci rekurencyjnych, nienadzorowanych, a także ze wzmocnieniem. O każdym z tych zagadnień jest wspomnienie zawarte w 1-2 akapitach, ale to tyle. Trochę szkoda, gdyż to właśnie sieci ze wzmocnieniem są najbardziej interesujące w kontekście nowych narzędzi AI robiących furorę, natomiast należy zwrócić uwagę na to, że do ich zrozumienia i tak potrzebna jest wiedza o podstawach uczenia się sieci neuronowych, którą autor dostarcza. Dodatkowo, jeśli miałby dołączyć rozdziały dotyczące każdego typu sieci, to książka miałaby nie ok. 470 stron, tylko bliżej 600. Oczywiście, co najmniej połowa tomu dotyczy ogólnych informacji, takich jak posługiwanie się Pythonem, danymi wejściowymi oraz klasycznymi metodami uczenia się, ale taki jest urok pozycji dla początkujących.

Jeśli chodzi o styl pisania, to mimo fragmentów bardzo technicznych i ścisłej terminologii, autor zdecydowanie unika naukowego patosu. Wtedy, kiedy jest potrzeba, wprowadza "wykładowy klimat", ale pozwala sobie również na kolokwialne sformułowania (szczególnie, kiedy model nie działa tak dobrze, jak zakładano), a w niektórych miejscach nawet na drobne żarty. Również tłumacz stanął na wysokości zadania i widać, że nie była to tylko osoba dobrze znająca język angielski, ale także znawca obszaru sztucznej inteligencji. Książka ma dość dużo wykresów, grafik i listingów kodu, więc mimo wspomnianych już 470 stron nie jest to długa pozycja.

Podsumowując, uważam, że recenzowana książka to niezły podręcznik do nauki podstaw uczenia maszynowego i sieci neuronowych, ale głównie dla studentów informatyki, którzy jakieś podstawy mieli na uczelni lub poznali je inną drogą. Niektóre części są opisane zbyt skrótowo, inne zbyt matematycznie. Natomiast dużą zaletą jest faktyczne podpieranie się przykładowymi kodami w Pythonie, prezentowanie gotowych programów oraz wyników eksperymentów wraz z omówieniem przydatności poszczególnych metod. Powiedziałbym, że to taka książka na 6/10, może 7/10 - jak najbardziej godna uwagi, choć nie sprawi, że wszyscy nagle będą biegli w fundamentach czegoś, co być może zaleje świat.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Uwierzytelnianie dwuskładnikowe (2FA) https://wildasoftware.pl/post/uwierzytelnianie-dwuskladnikowe-2fa?ref=rss https://wildasoftware.pl/post/uwierzytelnianie-dwuskladnikowe-2fa?ref=rss Thu, 11 May 2023 17:30:00 +0000 O tym, że bezpieczeństwo danych i kont jest niezmiernie ważne, nie trzeba nikogo przekonywać, choć nie zaszkodzi co jakiś czas przypomnieć. Kwestią sporną jest natomiast sposób chronienia swojej własności. Niektórzy twierdzą, że nie mają nic ważnego do ukrycia i wystarczy im pojedyncze hasło. Inni zbroją się na wszelkie możliwe sposoby, szyfrując pliki na dysku, maile, a nawet posiadając osobny komputer do korzystania z banku. Wiadomo, że wszystko zależy od sytuacji i naszego poczucia bezpieczeństwa lub świadomości na temat możliwych zagrożeń - zupełnie inaczej podejdziemy do bezpieczeństwa przy okazji logowania się do serwisu z naszymi umowami, a inaczej do portalu z memami. Tym niemniej, pewne podstawowe zasady warto sobie wpoić, a jedną z nich jest włączenie dwuskładnikowego uwierzytelniania w większości miejsc.

W tym tekście opiszemy, czym jest ta technika, dlaczego powinniśmy z niej korzystać oraz jakie odmiany są do dyspozycji. Odmiany, ponieważ nie występuje ona tylko w jednej wersji, ale aż w trzech podstawowych, a niektórzy próbują wprowadzać rozwiązania towarzyszące i hybrydowe.

Czym jest 2FA?

Uwierzytelnianie dwuskładnikowe (ang. two-factor authentication, 2FA) jest sposobem logowania się do serwisu, który polega na potwierdzeniu swojej tożsamości są na dwa różne sposoby. Zwracam uwagę na "dwa różne sposoby" - nie polega to na podaniu hasła dwukrotnie lub użyciu dwóch różnych haseł wpisywanych w podobnym oknie. Żeby wyjaśnić, dlaczego to takie ważne, weźmy pod lupę trzy przykłady.

Na pewno wszyscy znamy osoby, które do wszystkiego posiadają jedno hasło lub ewentualnie kilka, ale będących wariacją tego pierwszego. Tacy ludzie tłumaczą to chęcią łatwiejszego zapamiętania swojego dostępu do serwisów, natomiast widocznie nie zakładają, że to hasło gdziekolwiek wycieknie. A przecież to się może zdarzyć każdemu - wpiszemy dane w nieodpowiednim miejscu, ktoś podejrzy nam przez ramię wciskane klawisze lub pomylimy pole i kod trafi do autouzupełniania w przeglądarce. A konsekwencje w tym przypadku mogą być tragiczne - znając nasz adres e-mail (co jest dość proste), atakujący może tym samym hasłem zalogować się wszędzie, łącznie z kontem pocztowym (umożliwiającym zmianę hasła w innych serwisach) czy bankowym. Chyba nie muszę opowiadać, jakie to będzie miało skutki.

Weźmy teraz przypadek osoby, która zdaje sobie sprawę z zagrożenia i ma różne hasła do każdego lub większości serwisów. Osobną kwestią jest siła tych haseł, ale przyjmijmy, że mają one rozsądną długość i zawierają duże litery, małe, cyfry oraz znaki specjalne. Jest bezpiecznie? Na pewno bardziej niż w poprzednim przykładzie, ale nadal hasło może nam wyciec przez naszą nieuwagę lub ktoś może zwyczajnie je zgadnąć, przeprowadzając tzw. atak brute force (próbując wszystkich kombinacji, ew. posiłkując się jakimś słownikiem). Oczywiście, jeśli włamie się w ten sposób do jednego serwisu, to można się jeszcze uratować, zmieniając tam nasz sekret po zauważeniu akcji. Ale jeśli ktoś odkryje nasze hasło do konta pocztowego, sprawa zaczyna robić się mniej zabawna, gdyż może zresetować hasła wszędzie indziej. A tworzenie osobnego konta pocztowego do wszystkich profili w Internecie jest - powiedzmy to sobie wprost - nierealne i "nieżyciowe".

Jednak załóżmy, że regularnie dbamy o nasze hasła i nie tylko je różnicujemy względem serwisów oraz usług, ale także co jakiś zmieniamy. Dbamy o to, aby nikt ich nie podpatrzył, wpisujemy je tylko na wyznaczonym komputerze oraz mamy nawyk czyszczenia cache'u w przeglądarce. Ale pamiętajmy, że jesteśmy tylko jedną stroną komunikacji - po drugiej jest serwis, do którego się logujemy i który nie zawsze może być równie dobrze zabezpieczony. To właśnie po włamaniach do baz danych często pojawiają się alerty dotyczące wycieku informacji. Na szczęście, większość usług haszuje hasła, co znakomicie utrudnia włamującemu ich odgadnięcie, ale nadal nie jest to niemożliwe.

Wszystkie te przypadki łączy jedno - jeśli ktoś zna nasz login (zwykle adres e-mail) oraz hasło, to może się za nas podać. Co więcej, trudno temu aktywnie przeciwdziałać i dowiedzieć się, że w tym momencie stajemy się ofiarą ataku. "Haker" (choć to słowo jest mocno na wyrost w tym przypadku) niczego innego nie potrzebuje. Oczywiście, więcej haseł do wpisania może podnieść poziom bezpieczeństwa, ale to wszystko jest na nic w momencie, kiedy ktoś ma dostęp do naszego komputera lub smartfona lub ma się dostatecznie dużo czasu, aby odgadnąć także drugi i kolejny sekret. Dlatego tak ważne jest, aby drugi stopień weryfikacji, który chcemy włączyć, wymagał skorzystania z innej drogi. To ta sama zasada, która wymaga wysłania zaszyfrowanego archiwum i hasła do niego dwiema różnymi metodami (np. mail i telefon).

Włączenie 2FA pozwala wybrać (naturalnie, w serwisach, które daną metodę implementują) jedną z trzech dróg dodatkowej weryfikacji - SMS, kody jednorazowe oraz tzw. U2F.

Krótkie wiadomości tekstowe (SMS)

Jest to najpowszechniejsza forma, do której wiele osób się przyzwyczaiło. Po wpisaniu hasła przez użytkownika serwis wysyła mu SMS-a z jednorazowym kodem do wpisania. Dopiero po wpisaniu tego ciągu znaków w aplikacji użytkownik staje się uwierzytelniony.

Ta forma dla wielu jest najprostsza do zrozumienia i najbardziej intuicyjna. Zwłaszcza, że wszyscy (lub prawie wszyscy) mają telefony komórkowe oraz zasięg, więc dostęp do SMS-ów jest bardzo powszechny. Z punktu widzenia użytkownika wydaje się to zatem najbardziej obiecującą formą potwierdzenia uwierzytelnienia, zwłaszcza że złodziej musiałby mieć dostęp do naszej komórki. Jednak - jak wszystko - metoda SMS-owa ma swoje wady.

Po pierwsze, wymaga podania swojego numeru telefonu w serwisie. Dla niektórych nie jest to żadna przeszkoda, gdyż i tak udostępniają dużo więcej, ale dla innych - potrzeba przełamania pewnej bariery, ponieważ numerem telefonu zwykle dzielimy się dużo mniej chętnie niż adresem e-mail. Niegdyś baliśmy się o jakieś głupie żarty w słuchawce, ale dzisiaj w ten sposób można trafić do bazy telemarketerów, oszustów, a czasem po prostu obawiać się zadzwonienia przez obsługę serwisów, bo nie każdy lubi rozmawiać przez telefon. Rozwiązaniem jest, oczywiście, drugi numer telefonu, przeznaczony tylko i wyłącznie do 2FA.

Po drugie, jest to stosunkowo droga forma dla twórców aplikacji. Wysłanie SMS-a przez bramki udostępniane przez wiele zewnęrznych firm nie jest darmowe i w przypadku ogromnej rzeszy użytkowników, którzy takie wiadomości mogą generować po kilka dziennie, koszt robi się stosunkowo duży. Swoją drogą, to właśnie prawdopodobnie jest powód, dlaczego w marcu 2023 r. Twitter decyzją Elona Muska zablokował tę formę dla użytkowników korzystających z serwisu za darmo - jedni powiedzą, że chodzi o bezpieczeństwo (o czym za chwilę), a drudzy, że o oszczędności. Skłaniałbym się ku drugiej wersji (zwłaszcza, że Musk swego czasu wyłączał usługi, aby zaoszczędzić na serwerach i zobaczyć, które są rzeczywiście potrzebne), aczkolwiek przyznaję, że PR-owo wygląda to na szukanie okazji na podreperowanie budżetu kosztem bezpieczeństwa użytkowników. Co nie do końca odpowiada prawdzie, gdy się bliżej temu przyjrzymy, ale wrażenie pozostaje.

Po trzecie, właśnie bezpieczeństwo. SMS-y nie są w pełni bezpieczne - mogą okazać się nieskuteczne w przypadku narażenia się na atak na kartę SIM, który jest jak najbardziej możliwy. Tym niemniej, nadal lepiej mieć włączone kody przez SMS niż nie posiadać żadnej formy 2FA.

Kody jednorazowe (OTP)

Drugi sposób dotyczy także "haseł", które są krótkotrwałe i możliwe do wykorzystania tylko raz (ang. one-time passwords, OTP), ale pomijają drogę SMS-ową. Jest to sposób znany klientom niektórych banków, gdzie udostępniane są karty kodów lub właśnie aplikacje generujące tokeny. Jak to działa?

Użytkownik najpierw musi zainstalować na telefonie aplikację uwierzytelniającą. Wybór jest dość szeroki - od najpopularniejszego Google Authenticatora poprzez Microsoft Authenticatora, aż do mniej "nośnych", ale nadal dobrych opcji w rodzaju LastPassa, Auth0, Twilio czy wielu innych. Większość z nich jest darmowa, niektóre posiadają też wersję desktopową i różnią się szczegółami, ale ich zasada działania pozostaje podobna.

Po instalacji użytkownik może sparować swoją aplikację z serwisami, do których chce się logować. Przykładowo, jeśli chcemy użyć tego do logowania do Mastodona, należy dodać nowe "konto" w Authenticatorze, a następnie w Mastodonie w ustawieniach wywołać kod QR. Wówczas telefonem skanujemy ten kod QR i od tego momentu aplikacja będzie generować nam kody jednorazowe ważne przez określony czas (po czym samoistnie je odświeżać, tworząc nowe zestawy numerów). Działa to identycznie, jak w przypadku SMS-ów, tylko właśnie nie dostajemy SMS-ów. Oprócz kodu QR można też skorzystać z kluczy konfiguracyjnych.

Jak widać, ta metoda jest bardzo podobna i - co więcej - nie wymaga nawet dostępu do Internetu. Wystarczy mieć zainstalowaną aplikację w telefonie, w której co pewien czas generowane są nowe kody dla sparowanych serwisów. Jeśli akurat potrzebujemy się zalogować lub potwierdzić jakąś operację - otwieramy aplikację i przepisujemy kod. Jest to darmowe (choć niektóre usługi oferują płatne funkcje), łatwe do zastosowania, a do tego tańsze od strony twórców serwisów.

Niestety, także tutaj pozostaje do rozwiązania problem przechwytywania kodów lub ich wyłuskiwania metodami socjotechnicznymi (tzw. phishing).

Klucz sprzętowy (U2F)

Dochodzimy do trzeciego, najbardziej bezpiecznej metody dwustopniowego uwierzytelniania, opartej o standard FIDO. Klucze sprzętowe U2F to zazwyczaj małe urządzenia przypominające pendrive'y, które umieszcza się w slocie USB komputera i w odpowiednim momencie aktywuje, wywołując wpisanie kodu. Nie ma tutaj zatem przechwytywania kodów czy ich generowania ich z zewnątrz, gdyż wymagane jest fizyczne posiadanie takich urządzeń. A są one zwykle przy właścicielu, dopięte do breloczka lub ukryte w bezpiecznym miejscu. Każdy egzemplarz posiada swój unikalny i zaszyfrowany kod dostępu i można w przybliżeniu uznać, że nie jest podrabialny.

Oczywiście, nie ma róży bez kolców - taki klucz kosztuje użytkownika trochę pieniędzy. W zależności od wersji i poziomu ochrony, cena zaczyna się od ok. 150 zł. Podobnie jak wcześniej omawiane aplikacje do OTP, także jeden egzemplarz może służyć do logowania w wielu różnych serwisach i nie trzeba posiadać osobnego urządzenia do każdej usługi. Pewnym problemem może być też pamiętanie o tym, aby nosić taki klucz ze sobą wszędzie tam, gdzie chcemy się zalogować do zabezpieczonej aplikacji, ale jeśli dopniemy go do kluczy, to nie powinniśmy specjalnie ucierpieć.

Ten sposób jest zatem najbardziej bezpieczny i przez to polecany przez takie serwisy branżowe, jak choćby Niebezpiecznika czy Zaufaną Trzecią Stronę. Kwota rzędu 150 zł za jeden klucz (choć warto mieć dwa, o czym za chwilę) jest naprawdę niewygórowana jak na chęć ochrony swojego konta przed niepowołanym dostępem w wielu serwisach. Możecie też sprawdzić, jaki klucz najbardziej pasuje do Waszych potrzeb na stronie producenta, a więc Yubico. Szerzej o tym sposobie możecie również poczytać na Sekuraku.

Inne sposoby

Warto zauważyć, że twórcy aplikacji od dawna znają ten problem i starają się przyciągnąć do siebie użytkowników także stawiając na bezpieczeństwo i pokazując swoje zaawansowanie w tym zakresie. Ogromna rzesza popularnych usług wspiera wcześniej wymienione sposoby, ale też dodaje swoje. Przykładem jest możliwość podania pomocniczego adresu e-mail czy wyświetlanie historii logowań, dzięki czemu użytkownik może się zorientować, czy ktoś nie próbował lub wręcz zdołał przywłaszczyć sobie konto.

A co, jeżeli w ogóle nie musielibyśmy wpisywać hasła? W tym momencie niektórzy wspomną o stosowaniu odcisku palca, rozpoznawania twarzy oraz skanowaniu tęczówki, a więc wszystko, co można umieścić pod hasłem biometrii. Wiele osób korzysta już z tych technologii, jednak inni mają obawy, choćby przed awarią sprzętu i brakiem możliwości zalogowania się na swoje konto mimo pełnych praw do tego (np. odcisk palca nie zostanie poprawnie porównany ze wzorcem). Niektórzy twórcy stosują też hasła jednorazowe wysyłane na adres e-mail, w związku z czym nie trzeba ustawiać swojego na stałe - to taka forma "wymuszonego" OTP.

A co jeśli zgubię narzędzie uwierzytelniające?

To wątpliwość, która niektórym spędza sen z powiek. Faktycznie, utrata telefonu lub klucza, a także zwykłe awarie sprzętowe są problemem, na który trzeba opracować rozwiązanie. Wiele serwisów oferuje tzw. kody zapasowe (ang. backup codes), z których można skorzystać w momencie, kiedy jest problem z SMS-ami lub aplikacją do OTP - należy je jednak wcześniej wygenerować i gdzieś zapisać. W przypadku kluczy sprzętowych warto zainwestować w podwójne urządzenie, z których drugi będzie stanowił właśnie taki backup. Wówczas jeden nosimy ze sobą, natomiast rezerwę pozostawiamy w bezpiecznym miejscu w domu.

Podsumowanie

Uwierzytelnianie dwuskładnikowe to dobry sposób na dodatkowe chronienie swoich kont w serwisach (i to nie tylko tych najbardziej drogocennych), a w przypadku ważniejszych osób lub usług biznesowych - wręcz warunek konieczny, aby nie zostać negatywnych bohaterem jakiegoś ataku. Jeśli tylko 2FA jest dostępne, polecamy je ustawić i korzystać, gdyż licho nie śpi i nigdy nie wiadomo, kiedy zabezpiecznie faktycznie okaże się potrzebne.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Adresy IPv4 i IPv6 https://wildasoftware.pl/post/adresy-ipv4-ipv6?ref=rss https://wildasoftware.pl/post/adresy-ipv4-ipv6?ref=rss Thu, 04 May 2023 17:30:00 +0000 Myśląc obecnie o komputerze praktycznie nierozerwalnie wiążemy go z dostępem do Internetu. Coś, co kiedyś było luksusem lub ekstremalnie wolne, dzisiaj jest codziennością, na wyciągnięcie ręki, a światłowód nie jest już czymś futurystycznym, tylko fizycznie obecnym w wielu domach. Technologie sieciowe są tak popularne i powszechne, że korzystają z nich praktycznie wszyscy, a w takich sytuacjach okazuje się, że większość nie wie, jak to tak naprawdę działa. Oczywiście, nie wymagajmy od nikogo szczegółowej znajomości budowy kabla sieciowego czy standardu Wi-Fi, bo to nawet mało który informatyk zna i potrzebuje na co dzień. Ale jest takie pojęcie, które często pojawia się czy to w poradnikach, czy przy ustawianiu czegoś w domu, czy podczas korzystania z pomocy technicznej.

Dzisiaj przypomnimy sobie lub dowiemy się, czym jest adres IP oraz jak jest zbudowany. I dlaczego właściwie innym adresem posługujemy się w sieci domowej lub biurowej, a inny jest widoczny na zewnątrz. A także dlaczego IPv4 już powoli przestaje być wystarczające i warto cokolwiek wiedzieć o IPv6.

Czym jest adres IP?

Krótko mówiąc - jest to adres każdego urządzenia podpiętego do sieci, przy czym trzeba zdać sobie sprawę z kilku rzeczy:

  • urządzenie może mieć więcej niż jeden adres IP naraz,
  • adres IP może się zmieniać,
  • urządzenie zwykle nie ma unikalnego adresu IP w kontekście świata,
  • nie zawsze urządzenie jest widoczne w Internecie pod posiadanym adresem IP,
  • "sieć" niekoniecznie musi oznaczać Internet.

To teraz wytłumaczmy to na spokojnie.

Gdy podpinacie urządzenie do sieci przez kabel ethernetowy lub Wi-Fi, to zazwyczaj przyłączacie je do routera lub innej maszynki rozdzielającej sygnał. Dopiero ta jest podpinana do Internetu, a więc sieci globalnej. To oznacza, że nasz komputer czy smartfon (podpięty przez Wi-Fi) zazwyczaj nie funkcjonuje bezpośrednio w eterze - ma do niego dostęp, ale skrywa się właśnie za routerem, który stanowi jedyny kontakt ze światem. Łączy on zwykle wiele urządzeń, które w ten sposób znajdują się w jednej sieci lokalnej. Zobaczmy następujący diagram:

Diagram pokazujący dwie sieci lokalne (obie mają po trzy komputery z adresami 192.168.1.2, 192.168.1.3, 192.168.1.4), z których każda podpięta jest do routera o adresie lokalnym 192.168.1.1 oraz unikalnym adresie globalnym. Dopiero routery są podpięte do Internetu.

Widzimy tutaj dwie sieci lokalne, z których każda składa się z trzech komputerów. Maszyny w tym obszarze nie mają bezpośredniego dostępu do Internetu - muszą polegać na routerze, który zazwyczaj jest podpięty jeszcze dodatkowo do tzw. ISP (ang. Interner Service Provider, dostawcy usług internetowych), a dopiero ten pozwala komunikować się z globalną wioską. Każde widoczne urządzenie posiada swój adres IP, przy czym obserwujemy, że w sieciach lokalnych te adresy się powtarzają, a niektóre urządzenia mają wręcz dwa. O co tutaj chodzi?

Adresy IP mogą być publiczne lub prywatne. Te pierwsze, jaka sama nazwa wskazuje, są lokalizacjami, które są publicznie dostępne i pod tym adresem dany komputer czy urządzenie jest widoczny w Internecie (o ile, oczywiście, nie ma innych zabezpieczeń). Jednocześnie, ten adres może się zmieniać - wiedzą o tym doskonale użytkownicy domowi, którzy mogli zauważyć, że po każdym restarcie routera zyskują nowy globalny adres sieciowy (można to sprawdzić np. na tej stronie). O tym, dlaczego tak się dzieje, jeszcze dzisiaj napiszemy. Natomiast adresy prywatne są używane tylko i wyłącznie w obrębie sieci lokalnej. Dlatego te same liczby mogą powtarzać się w różnych sieciach lokalnych, ale w obrębie jednej muszą już być unikalne. Z kolei adresy publiczne muszą być niepowtarzalne globalnie. I tutaj zaczyna się zabawa.

Ponieważ adresy IP mogą być z zakresu 0.0.0.0 do 255.255.255.255 (przynajmniej czysto teoretycznie, bo w praktyce ten przedział jest mniejszy), to możliwych kombinacji jest 4 228 250 625, a to już od dawna o wiele za mało, aby każde urządzenie na świecie podpięte do Internetu miało swój specyficzny identyfikator (tę rolę przejął poniekąd adres MAC, a więc numer karty sieciowej, choć poleganie na nim też nie jest pozbawione wad). W związku z tym należało coś zrobić i w ten sposób wymyślono, aby w jednej serii numeracji mogły powstawać podserie, czyli właśnie sieci lokalne. Tym niemniej, oznaczało to wyznaczenie zakresów, w obrębie których mogą powstawać adresy prywatne. Są to:

  • 10.0.0.0 - 10.255.255.255
  • 172.16.0.0 - 172.31.255.255
  • 192.168.0.0 - 192.168.255.255

Najczęściej mamy do czynienia z trzecim rodzajem adresów, który pozwala na tworzenie sieci do 65 025 urządzeń, choć w praktyce w większości zastosowań już sieć dla 256 urządzeń jest zdecydowanie za duża. O tym, dlaczego stworzone zostały aż trzy pule adresów prywatnych, można poczytać w kontekście tzw. klas adresów IP.

Warto wiedzieć, że to też nie jest tak, że jeśli np. w zakresie od 192.168.1.0 do 192.168.1.255 (najczęściej spotykanym w domach) mamy 256 możliwości, to faktycznie tyle urządzeń można podłączyć. Niektóre adresy są bowiem zarezerwowane. I tak:

  • 192.168.1.0, a więc pierwszy adres podsieci to właśnie adres podsieci, a więc tak jakby grupowy adres, który nie jest przydzielany żadnemu urządzeniu.
  • 192.168.1.1 zwyczajowo jest adresem routera.
  • 192.168.1.255, czyli ostatni z puli, to tzw. adres rozgłoszeniowy do wiadomości broadcastowych, czyli obejmujących całą sieć.

A zatem w takiej typowej sieci lokalnej, poza routerem może zostać podpiętych do 253 konkretnych urządzeń. W mniejszych firmach jest to całkowicie wystarczające, ale w większych może być już problematyczne.

Router jest specyficznym przypadkiem - z jednej strony posiada adres lokalny, gdyż należy do sieci lokalnej. Z drugiej - musi być dostępny z poziomu sieci globalnej (a przynajmniej w teorii), stąd ma także adres publiczny. Nawiasem mówiąc, komputery w sieci lokalnej też mają adres publiczny - identyczny, jak ten, który ma router. Zresztą, można ten identyfikator wykorzystać także do tego, aby uzyskiwać dostęp do usług uruchomionych w sieci lokalnej - czyni się to poprzez funkcję przekierowania portów, czego jednak tutaj nie będziemy omawiać.

Budowa adresu IPv4 i podział na podsieci

Na pewno już zauważyliście, że adres IP (a właściwie IPv4, do czego jeszcze wrócimy) jest zbudowany w specyficzny sposób. To cztery bajty lub - jak często się mówi - cztery oktety, które są tak nazywane, ponieważ każdy z nich składa się z ośmiu bitów. Dzięki temu, że każda część jest jednym bajtem, nie ma mowy o tym, aby pojedynczy fragment adresu IP miał liczbę większą niż 255 (zakres to 0-255).

Z binarną budową adresu IP związane jest też zagadnienie podziału sieci na podsieci. W ten sposób w ramach jednej sieci można tworzyć inne, osobne "dzieci". To z kolei łączy się z pojęciem maski podsieci lub tzw. notacją CIDR, która określa, jak wiele bitów zostanie przeznaczonych na samą sieć, a ile będzie do rozdysponowania dla urządzeń w środku.

Pokażmy przykład z adresem 192.168.1.96, który w notacji binarnej zapiszemy następująco:

11000000.10101000.00000001.01100000

Co ważne, widzimy, że na końcu mamy pewną liczbę zer. Dzięki temu możliwy będzie łatwy podział sieci. Następnie potrzebujemy maskę, a więc adres lub liczbę bitów, które będą stanowiły podstawę sieci. Zazwyczaj maskami są wielokrotności ósemki, a więc 8, 16 lub 24 (w zapisie standardowym: 255.0.0.0, 255.255.0.0 lub 255.255.255.0). Weźmy dla przykładu jednak coś niestandardowego, a więc maskę 255.255.255.240 lub w zapisie CIDR /28. Zapis binarny jest następujący:

11111111.11111111.11111111.11110000

Widzimy sporo jedynek na początku oraz zera na końcu. To właśnie te zera pokazują nam bity w dzielonym adresie, które będą przeznaczone na podsieć. A zatem działanie wygląda następująco:

Bazowy adres IP: 11000000.10101000.00000001.01100000
Wydzielenie zer: 11000000.10101000.00000001.0110 0000
Maska podsieci: 11111111.11111111.11111111.1111 0000

Zakres dla podsieci: od 11000000.10101000.00000001.0110 0000
do 11000000.10101000.00000001.0110 1111
Sieć ma zakres od 192.168.1.96 do 192.168.111, a więc pomieści 16 - 2 urządzeń wraz z routerem.

Na końcu mała prywata - jeśli jesteście studentami Politechniki Poznańskiej i tamtejszego kierunku informatycznego, to uwierzcie mi - wiedza o dzieleniu na podsieci będzie Wam niezmiernie przydatna na odpowiednim przedmiocie w czasie studiów inżynierskich. Zawsze możecie też podeprzeć się takimi kalkulatorami.

DHCP oraz stały adres

Wspomniałem wcześniej o tym, że jeśli ponownie uruchamiamy nasz router, to bardzo często za każdym razem dostaniemy inny publiczny adres IP. Jeszcze łatwiej zaobserwować to w sieci lokalnej - te same podłączone urządzenia mogą mieć inne adresy w różnych dniach lub godzinach (dokładniej po restarcie sieci). Odpowiada za to tzw. protokół DHCP (ang. Dynamic Host Configuration Protocol), który zdejmuje konieczność ręcznego przyznawania adresów IP i czyni to automatycznie, korzystając z puli wolnych miejsc w danym momencie. Nawiasem mówiąc, ta sama zasada działa na poziomie routera - przypomnijmy bowiem, że jeśli podłączamy router do Internetu, to tak naprawdę łączy się on najpierw z ISP (a więc naszym dostawcą Internetu), czyli można powiedzieć, że ma przyznawany adres IP w lokalnej sieci danego dostawcy. To tak w dużym skrócie, gdyż mechanizm jest bardziej skomplikowany i wychodzi poza zakres nie tylko tego tekstu, ale też obszaru, z którym zwykle mają do czynienia programiści.

Tym niemniej, dynamicznie przydzielany adres IP jest wygodny, ale bywają sytuacje, w których jest niewystarczający i potrzebne (lub nawet wymagane) jest przydzielenie stałego adresu. W przypadku sieci lokalnej nie jest to problemem - na routerze można wymusić przypisanie konkretnego miejsca urządzeniu o danym adresie MAC (identyfikującym kartę sieciową, a więc w skrócie - komputer lub smartfona). Schody zaczynają się w przypadku, kiedy to nasz router ma przedstawiać się w Internecie niezmiennym adresem - jest to usługa, którą oferują dostawcy internetowi za dodatkową opłatą. W przypadku, kiedy chcemy mieć dostęp do sieci lokalnej z zewnątrz, stały adres jest wręcz niezbędny, gdyż za pomocą przekierowania portów umożliwia korzystanie z pewnych usług lub np. udostępnienie ich klientowi. Do pewnego stopnia jest to możliwe również bez stałego adresu (np. poprzez DDNS), ale zdecydowanie bardziej utrudnione.

IPv6

Adresy, o których do tej pory rozmawialiśmy, należą do tzw. protokołu IPv4. Tak, jak pisałem, jest to pula ponad 4 miliardów adresów, która... już dawno się wyczerpała. Ba - już na początku lat dziewięćdziesiątych było wiadomo, że nie zaspokoi globalnego zapotrzebowania na urządzenia podpięte do sieci. Dlatego dawno rwmu zaczęto opracowywanie nowego standardu i on powstał. Problem w tym, że nie jest używany.

IPv6, bo o nim mowa, posiada adresy zapisane nie w postaci 4 bajtów (a więc 32 bitów), tylko 16 bajtów (128 bitów). Ponieważ zapisywanie takich konstruktów byłoby dość problematyczne w dziesiętnej formie, wyglądają one bardzo podobnie jak adresy MAC. Mianowicie, jest tutaj wykorzystywany system heksadecymalny i dwukropki, oddzielające dwubajtowe fragmenty. Przykładowo może to wyglądać tak:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Co więcej, w przypadku fragmentów posiadających same zera można je omijać, znacząco skracając zapis. No dobrze, ale w takim razie dlaczego ciągle rządzi IPv4? Okazuje się, że to wina infrastruktury i dostawców Internetu - ponieważ przez lata wszystko było dostosowywane do IPv4, to w momencie nadejścia IPv6 świat był na to gotowy niczym polscy drogowcy na zimę. Czyli nie był. W związku z tym zbyt mały procent ISP obsługuje "szóstki", przez co trudno z nich realnie korzystać. Co prawda, istnieje możliwość tłumaczenia wpisów z jednego protokołu na drugi, ale zwyczajnie w większości prawdopodobnie macie wyłączoną obsługę tych dłuższych adresów. Możecie to sprawdzić np. tutaj. Z kolei dłuższy wywód dotyczący tej adresacji znajdziecie w Wikipedii lub w dokumentacji usług serwerowych Mikrus, które z tej formy korzystają i wyjaśniają dlaczego.

Jak sprawdzić swój lokalny adres IP?

Jest to dość proste, jeśli korzystacie z terminala i spokojnie - nie trzeba do tego być programistą. Interesować będą Was trzy polecenia. Najpierw podam wersje dla Windowsa, natomiast przede wszystkim trzeba wspomnieć o tym, jak w tym systemie można otworzyć konsolę - robi się to poprzez "Uruchom" (WIN + R -> cmd -> ENTER).

Trzy popularne polecenia, które mogą nas interesować, to:

  • ipconfig - sprawdzenie ustawień naszych kart sieciowych (osobno interfejsów przewodowych i bezprzewodowych), w tym adresu IP. Jeśli do tego dodamy /all, to uzyskamy więcej informacji, w tym adresy MAC (physical address).
  • ping [adres domenowy lub adres IP] - polecenie odpytujące inne urządzenie w sieci, pozwalające sprawdzić połączenie. Często przydatne, jeśli podejrzewamy utratę dostępu do sieci. Istnieją urządzenia, które blokują pingi (odpowiada za nie protokół ICMP), mimo że sam bez problemu są widoczne w sieci.
  • tracert [adres internetowy] - ciekawsza wersja poprzedniego polecenia, które pozwala prześledzić drogę od naszego komputera do np. serwera Google'a. Niektórym otwiera oczy na to, ile przystanków komunikat zalicza po drodze.

W przypadku Linuxa te polecenia to odpowiednio ifconfig (lub ip a), ping oraz traceroute.

Czy IP zawsze jest związany z siecią?

Na końcu warto wspomnieć, że "IP", o którym tutaj rozprawialiśmy, rozwija się jako Internet Protocol. Jest dla wielu oczywiste wyjaśnienie tego skrótu i nawet nie zdają sobie sprawy, że w siostrzanej branży pod tymi dwoma literkami kryje się zupełnie coś innego. A mowa o branży gier wideo lub filmów oraz terminie Intellectual Property, oznaczającym własność intelektualną. Często mówi się bowiem, że "dane IP należy do firmy X", co należy odczytywać jako bycie właścicielem danej marki. Warto o tym wiedzieć, przeglądając materiały w Internecie.

Podsumowanie

Ten tekst miał na celu spokojne wprowadzenie początkujących w świat adresów IP i uświadomienie im, że takie coś w ogóle istnieje i może być przydatne np. przy kontakcie z obsługą techniczną lub podczas rozbudowy własnej sieci domowej lub firmowej. Często taka wiedza jest bezcenna i umożliwia np. lepsze zrozumienie tego, co można ustawić w routerze.

Pozdrawiam i dziękuję - Jakub Rojek.

]]> Czy to sztuczna inteligencja, czy uczenie maszynowe? https://wildasoftware.pl/post/czy-sztuczna-inteligencja-czy-uczenie-maszynowe?ref=rss https://wildasoftware.pl/post/czy-sztuczna-inteligencja-czy-uczenie-maszynowe?ref=rss Thu, 27 Apr 2023 17:30:00 +0000 Nie będę odkrywczy, gdy ogłoszę, że najgorętszym tematem technologicznym w Internecie w 2022 i na początku (a prawdopodobnie w całym) 2023 roku jest ChatGPT oraz inne narzędzia korzystające ze sztucznej inteligencji (ang. artificial intelligence). Sam termin AI (lub po polsku SI) jest znany od dawna, zarówno w środowisku naukowym, jak i tworach z nurtów science-fiction lub cyberpunk, także to pojęcie nie jest obce ludzkości. Natomiast do niedawna sądzono, że może coś tam już jest możliwe do zrobienia, ale cały czas jest to przyszłość. A tutaj okazało się, że przyszłość nadeszła, wyrwała drzwi z framugi, wyrzuciła kota z fotela i rozgościła się w salonie.

Szybko ujawniło się, że narzędzia w rodzaju generowania grafik na podstawie tekstowego opisu (np. DALL-E 2, Midjourney) to ledwie rozgrzewka. Pojawiło się ChatGPT będące jednocześnie rozmówcą, poradnikiem, doradcą, jak i moralizatorem. Co więcej, szał stał się tak wielki, że nagle inne firmy zaczęły naśladować firmę OpenAI i tworzyć własne narzędzia, z których bardzo obiecująco wygląda np. asystent Binga wykreowany przez Microsoft. Pojawiają się doniesienia o wykorzystaniu sztucznej inteligencji w różnych gałęziach przemysłu, w podpowiadaniu użytkownikom, w rozwiązywaniu codziennych problemów technicznych... Nagle wszystko, co modne, musi posiadać etykietę "AI". Istnieją nawet gotowe systemy do AI, które można uruchomić na swoim serwerze. Oczywiście, w tym samym czasie pojawiły się problemy moralne i dyskusja o bezpieczeństwie tej technologii, gdy już weszła do powszechnego użycia. Skupmy się jednak na tym, że sama sztuczna inteligencja wyszła już poza laboratoria badawcze i jest dostępna na wyciągnięcie ręki.

Pytanie, czy to faktycznie sztuczna inteligencja. W końcu do tej pory takim "oczkiem w głowie" systemów, zwłaszcza tych starających się o dofinansowanie, było uczenie maszynowe (ang. machine learning, ML), które było osiągalne i odpowiednio dobrze wykorzystane faktycznie robiło wrażenie, oszczędzając też pracę ludzi odpowiedzialnych za algorytmy (ale dodającej jej innym osobom). I nie ukrywam, że w którymś momencie w moim zwichrowanym umyśle pojawiła się chęć wyjaśnienia tego, jak to jest z tym porównaniem AI do ML i czy faktycznie mamy do czynienia z rewolucją. Spoiler: mamy.

Jak działa uczenie maszynowe?

Zacznijmy od najważniejszej rzeczy - jest to poddziedzina sztucznej inteligencji. A więc AI i ML nie są rozłącznymi obszarami, tylko jeden zawiera się w drugim. Natomiast samo ML, jak w skrócie będziemy nazywać machine learning, polega na odkrywaniu w danych pewnych wzorców, które pozwalają je agregować, grupować, klasyfikować itd. Przykładowo, na pewno kojarzycie rekomendacje wyświetlane w sklepach internetowych lub w serwisach z newsami - w tym momencie prawdopodobnie macie do czynienia z metodą uczenia maszynowego (na podstawie historii przeglądanych artykułów lub produktów), a konkretnie znajdowaniem reguł asocjacyjnych. To zagadnienie w praktyce możecie też spotkać np. przy zaawansowanym filtrowaniu spamu, ale także w bardzo poważnych zagadnieniach jak diagnostyka medyczna, dająca wskazówkę, czy na podanym zdjęciu rentgenowskim widać niepokojące zmiany nowotworowe, czy nie.

Ktoś w tym momencie może powiedzieć, że przecież istnieje algorytmika i to wszystko można zapisać w postaci odpowiednich warunków, pętli itd. W końcu tak naprawdę pod spodem uczenie maszynowe właśnie tak działa - można powiedzieć, że tworzy sobie wewnętrzne instrukcje, jak reagować w danym przypadku. Wszystko dobrze, tylko tutaj chodzi o poziom złożoności. Jawne instrukcje człowiek może przygotowywać w przypadku, kiedy np. decyzja o zaklasyfikowaniu osoby do danej grupy wynika z jasnych kryteriów (np. dana liczba punktów oznacza odpowiednią ocenę ze sprawdzianu). Z kolei uczenie maszynowe przydaje się w momencie, kiedy chcemy przetwarzać dane i odkrywać pewne reguły, ale nie wiemy, jak to zrobić oraz nie dowiemy się tego łatwo przy ogromnej puli informacji, które mamy do dyspozycji. Jednak ta pula daje nam przypadki, który wynikają z życia lub opisał je ekspert - jest to zbiór uczący, który posłuży danej metodzie ML do utworzenia wewnętrznego modelu wykorzystywanego w faktycznej pracy. Nie jest to aż takie proste - badacz nadal musi określić np. parametry, które opisują dany przypadek i mogą przydać się klasyfikatorowi, a nie zawsze są to wprost podane informacje w rodzaju prawdy, fałszu czy liczby. Nie są to też zwykle 3 atrybuty, ale prędzej 30, 300 lub nawet 3000 czy więcej. W dodatku zbiór wejściowy musi być na tyle zróżnicowany i "rozsądny", aby powstałe reguły faktycznie pozwalały na ocenienie jak największej liczby przypadków. Jednak to wszystko można jeszcze skomplikować - zbiór uczący nie może być za duży, aby nie "przeuczyć" modelu, który nagle w bardzo prostych sprawach zacznie się gubić i oceniać jako specyficzne przypadki.

Podsumowując ten fragment, uczenie maszynowe pozwala w łatwiejszy sposób interpretować złożone dane w celu automatycznego wysnuca wniosków. Oczywiście, nie zawsze działa to idealnie, ale na pewno może bardzo usprawnić pracę w wielu dziedzinach i o ile jest trudne, to nie jest nieosiągalne, zwłaszcza, że istnieją gotowe biblioteki implementujące poszczególne metody (zwłaszcza w języku Python, ale też JavaScripcie, PHP i innych technologiach). Rolą inżyniera jest tutaj bardziej dobranie odpowiedniej metody, zbioru uczącego oraz przygotowanie atrybutów, które go opisują i pomogą prawidłowo wykształcić wynikowy model.

Co to sztuczna inteligencja?

Każdy z nas intuicyjnie czuje, że termin AI odnosi się do zachowania maszyn i programów w taki sposób, jakby posiadały swoją inteligencję. W praktyce oznacza to symulowanie sposobu myślenia prawdziwego człowieka, a raczej próba odwzorowania takiego procesu. Pojęcie jest bardzo rozległe i tak, jak pisałem wcześniej, jest tematem wykraczającym poza naukę - pojawia się w wielu dziedzinach i rozważaniach, także tych fabularyzowanych (jak choćby HAL 9000 z "2001: Odysei kosmicznej").

Gracze komputerowi bez wątpienia znają pojęcie AI w kontekście zachowania przeciwników. W praktyce nie jest to do końca sztuczna inteligencja, ponieważ postępowanie wrogów czy nawet NPC-ów jest oskryptowane, tj. programiści sami konstruują modele (np. w postaci automatów skończonych), które w zależności od sytuacji (opisanej zmiennymi, np. liczba punktów zdrowia czy odległość od gracza) wydają komunikaty w rodzaju "atakuj", "uciekaj", "zażyj miksturę" itp. Zresztą, dotyczy to nie tylko gier wideo - także w tradycyjnych grach typu szachy istnieją silniki, które wykorzystują reguły, drzewa i inne techniki w celu wskazywania najlepszych ruchów czy przewidywania szans danego gracza.

Jednak sztuczna inteligencja wykracza znacznie dalej - są to także właśnie wcześniej opisane metody uczenia maszynowego czy metody analizujące i syntetyzujące język naturalny (tzw. NLP, czyli Natural Language Processing). I właśnie te ostatnie robią ostatnio największe wrażenie w postaci ChatGPT, a wcześniej pod postacią różnych mniej zaawansowanych czatbotów (które jednak mogły też korzystać z tzw. systemów eksperckich czy po prostu predefiniowanych reguł). Oczywiście, NLP samo w sobie jest dziedziną z wieloma rozgałęzieniami, badająca konstrukcję danego języka w celu dalszego przetworzenia. Jak możecie się domyślać, metody najlepiej działają zwykle z językiem angielskim, a np. w przypadku języka polskiego sprawa bardzo się komplikuje ze względu na odmiany, szyk zdania itd. Tym niemniej, jak najbardziej można też automatycznie analizować i tworzyć zdania w mowie potomków Piastów.

Wiele osób kojarzy też ten obszar z użyciem sieci neuronowych, czyli struktur, które mają w założeniu imitować ludzki proces myślowy. Wątpliwe jest, czy faktycznie to czynią, ale są jednymi z najbardziej znanych typów modeli wykorzystywanych w AI, skłądającymi się z neuronów połączonych ze sobą w celu stopniowego przekazywania wniosków i dociekania do danej informacji oraz zwrócenia jej. Podobnie, jak cebula lub ogry, składają się z warstw, ale w tym przypadku należy mówić raczej o poziomach - od liczby neuronów oraz "pięter" zależy złożoność i skuteczność danej sieci. Co więcej, może ona w sobie zawierać elementy rekurencji, a więc powrotu do już wcześniej odwiedzonych węzłów w celu ponownego przetworzenia informacji w innym kontekście. Dużą zaletą sieci neuronowych jest ich odporność na błędy czy braki oraz równoległość. Duże sieci są też podstawą poddziedziny uczenia maszynowego nazywaną uczeniem głębokim (ang. deep learning). Możecie znać jeden z serwisów, którego działanie na tym się opiera - to DeepL, automatyczny tłumacz uznawany przez wielu za lepszy w konkretnych zastosowaniach niż Google Translate.

Jednak to, co stanowi "prawdziwą" sztuczną inteligencję, to fakt, że model potrafi również sam się uczyć. Przykładowo, w tradycyjnym uczeniu maszynowym klasyfikatory potrafią przydzielać tylko klasy, o których wiedzą. Jeśli mogą wystawić ocenę od 1 do 6, to nie znajdzie się przypadek, w którym pojawi się wynik 7 - co najwyżej metoda zgłosi brak możliwości przydzielenia odpowiedniej oceny. Natomiast jeśli pozwolimy programowi na samodzielne uczenie się na podstawie dalszych przypadków, to zaczyna być to możliwe - widać to właśnie na przykładzie ChatGPT, który potrafi zdobywać wiedzę od użytkowników. Oczywiście, jest to niebezpieczne - zarówno ze względu na żartownisiów, jak i zwyczajnie błędne informacje lub takie nacechowane odpowiednimi poglądami. Tym niemniej, przy odpowiednio ogromnym zbiorze uczącym może mieć to mniejszy wpływ negatywny, a większy pozytywny, uzupełniający.

A jaki był zbiór uczący ChatGPT w wersji 3 (w chwili, gdy piszę te słowa, jest już dostępna "czwórka")? Gigantyczny, bo było to 570 GB danych (a wiemy, że pliki tekstowe same w sobie są dość niewielkich rozmiarów) oraz 176 miliardów parametrów opisujących informacje. Te dane, jak i wyjaśnienie modelu znajdziecie w tym artykule, który opisuje wszystko właśnie od strony metod sztucznej inteligencji. Na tym przykładzie można zobaczyć, że to naprawdę ogromne przedsięwzięcie, wymagające naukowców, ale również dużych mocy obliczeniowych, które nareszcie stały się dostępne.

Podsumowanie

A zatem ChatGPT oraz inne narzędzia stosujące AI od OpenAI faktycznie można określić mianem sztucznej inteligencji. Oczywiście, nadal nie jest to kres możliwości, a malkontenci powiedzą, że to nie jest AI i oni chcą coś lepszego. Ale czy w sumie na tym nie polega prawdziwe uczenie się, że osobie przedstawiane są materiały tekstowe i przykłady, a ta na ich podstawie uczy się i wyciąga wnioski? Kwestią jest to, kiedy technologia w tym obszarze stanie się nie tylko zachwycająca, ale też realnie niebezpieczna. A właściwie, czy czasem już tego punktu nie osiągnęliśmy, patrząc na deepfake, podkładanie głosów, twarzy czy generowanie materiałów nie do odróżnienia na pierwszy rzut oka od ludzkich tworów. To jednak temat na inne rozważania, których nie chciałem się tutaj podejmować (przepraszam tych, którzy chcieli poczytać o regulacjach prawnych, liście otwartym do m.in. OpenAI czy ChaosGPT).

Tym niemniej, warto pamiętać o tym, że popularność rozwiązań bazujących na sztucznej inteligencji sprawia, że także dość proste rozwiązania, które "same z siebie coś wnioskują" nazywa się teraz AI, bo to przyciąga tłumy lub wywołuje kontrowersje. A tak naprawdę "stare dobre" metody uczenia maszynowego, które i tak należą do dziedziny AI, nadal sprawują się całkiem nieźle w wielu obszarach i używanie frazy "sztuczna inteligencja" jest często nieco na wyrost. Pytanie, jak długo "zwykłe" ML faktycznie wystarczy.

Pozdrawiam i dziękuję - Jakub Rojek.

]]>