Dawno, dawno temu, na produkcji, pojawił nam się problem z wydajnością aplikacji. Analiza i rozwiązanie problemu pochłonęła nam dobre kilka dni. Debugowaliśmy, czytaliśmy dokumentację, analizowaliśmy logi. Nic nie mogliśmy znaleźć, do momentu, gdy nas oświeciło. Analizowaliśmy requesty i zauważyliśmy, że większość czasu żądania była na odczycie wartości z… cache. Problem był banalny. Zapychaliśmy cache’a generując za każdym razem uniwersalny klucz wartości. Chwilę wcześniej mergowaliśmy ogromnego PR, który pozmieniał w kodzie dużo – za dużo. Zmiany były w różnych częściach aplikacji – technicznych i biznesowych. To był nasz ogromny błąd.

Uznałem, że artykuł, który w sposób początkujący przedstawi temat cache pomoże innym. Mi też będzie punktem referencyjnym w przyszłości. W dzisiejszym artykule:

• Czym jest cache
• Cache lokalny vs rozproszony
• Algorytmy przechowujące dane
• Inwalidacja cache
• Monitorowanie cache

Czym jest cache

Cache w Javie to mechanizm przechowywania często używanych danych, w celu szybszego dostępu i poprawy wydajności aplikacji. Możemy zastosować go do operacji, które są czasochłonne lub kosztowne w wykonaniu. Dobrymi przykładami takich operacji są zapytania do bazy danych, requesty do API czy powtarzalne obliczenia matematyczne.

Załóżmy, że tworzymy aplikację pobierającą informacje o pogodzie. Informacje pobieramy z różnych lokalizacji, z zewnętrznego serwisu pogodowego za pomocą REST API. Pobierane dane zmieniają się co 3 godziny. Z naszej aplikacji dziennie korzysta około 50 000 osób, co przekłada się na średnio 2000 requestów na godzinę (upraszczamy, że ruch został rozłożony na całą dobę równomiernie). Użytkownicy pochodzą głównie z Polski i często pytają o te same lokalizacje. Aby uniknąć wywoływania zewnętrznego serwisu pogodowego wiele razy, możemy użyć mechanizmu cache. Przyspieszymy dostęp do informacji i unikniemy ciągłego zapytywania zewnętrznego API.

Cache lokalny vs rozproszony

Pamięć cache, możemy podzielić na dwa typy: lokalny i rozproszony. W tej sekcji postaram się opisać ich cechy, wady oraz zalety. Na końcu sekcji wrzuciłem też dwie tabele. Jedna porównująca cechy obydwu typów i druga z przykładami i rekomendacjami, który rodzaj wybrać w danej sytuacji.

Cache lokalny (In-memory cache)

In-memory cache to lokalny cache w procesie aplikacji, który przechowuje dane w pamięci RAM na jednym serwerze. Pozwala to na błyskawiczny dostęp do danych tam przechowywanych. Jest on najszybszy, ale ograniczony rozmiarem pamięci dostępnej w jednej instancji aplikacji. Jego główne cechy to:

• Lokalność: dane przechowywane są w pamięci RAM konkretnego procesu lub instancji aplikacji.
• Szybkość: dostęp do danych jest ekstremalnie szybki, ponieważ omijana jest komunikacja sieciowa i operacje na dysku.
• Prostota: może być implementowany za pomocą prostych struktur danych, np. ConcurrentHashMap, lub dedykowanych bibliotek, np. Caffeine.
• Brak współdzielenia: dane w cache są dostępne tylko dla jednego procesu lub instancji aplikacji (chyba że używana jest rozproszona implementacja in-memory, np. Hazelcast).

Zalety:

• Wysoka wydajność: zapewnia bardzo niski czas dostępu do danych, ponieważ przechowuje je w pamięci RAM. Odczyt danych z pamięci jest znacznie szybszy niż z dysku twardego czy bazy danych, co przyspiesza działanie aplikacji.
• Prosta implementacja: jest stosunkowo łatwa i nie wymaga skomplikowanej konfiguracji. Istnieje wiele gotowych rozwiązań, oferujących gotowe mechanizmy.

Wady:

• Ulotność danych: dane zostaną utracone w przypadku restartu serwera lub awarii aplikacji.
• Ograniczona pojemność: pojemność jest ograniczona przez dostępność pamięci RAM na serwerze. W przypadku dużych aplikacji lub intensywnego wykorzystania pamięci może to prowadzić do problemów z wydajnością lub brakiem miejsca na nowe dane (OutOfMemoryError).
• Trudności w skalowaniu: w architekturze rozproszonej każda instancja aplikacji ma swoją własną pamięć podręczną, co może prowadzić do problemów z synchronizacją danych między instancjami oraz zwiększonego ryzyka nieaktualnych informacji.

Cache rozproszony (Distributed cache)

Działa na wielu serwerach w klastrze, umożliwiając szybki dostęp do często używanych danych. Pamięć współdzielona jest między wieloma instancjami aplikacji i umożliwia obsługę dużych wolumenów danych oraz zapewnia wysoką dostępność danych. Jego główne cechy:

• Rozproszenie danych (eureka!): te same dane dostępne z różnych instancji aplikacji.
• Skalowalność: może być łatwo skalowany poprzez dodawanie nowych węzłów do klastra. To pozwala na zwiększenie pojemności cache i obsługę większej liczby żądań.
• Odporność na awarie: dzięki replikacji danych na różnych węzłach, nawet w przypadku awarii jednego z nich, dane pozostają dostępne.
• Partycjonowanie (sharding): każdy węzeł przechowuje tylko część danych, a aplikacja odwołuje się bezpośrednio do odpowiedniego serwera.

Zalety:

• Wysoka dostępność i odporność na awarie: dane mogą być replikowane na wielu węzłach, dzięki czemu awaria jednego serwera nie powoduje utraty danych.
• Szybkość i niskie opóźnienia: dane przechowywane są w pamięci RAM (z tym, że na wielu węzłach w porównaniu z lokalnym cache).
• Usprawnienie pracy mikroserwisów: w systemach mikroserwisowych cache rozproszony pozwala na szybką wymianę danych między usługami bez konieczności ciągłego odpytywania bazy danych.
• Obsługa dużych wolumenów danych: dzięki partycjonowaniu dane mogą być równomiernie rozłożone na węzłach, co pozwala na obsługę dużych zbiorów danych w rozproszonym środowisku.

Wady:

• Opóźnienia Sieciowe: cache działa na wielu serwerach, co oznacza, że każde zapytanie musi przejść przez sieć. Jeśli węzły są oddalone geograficznie, latencja wzrasta.
• Koszt Pamięci RAM: RAM jest znacznie droższy niż dysk, a cache rozproszony przechowuje dane w pamięci operacyjnej. Skalowanie dużych systemów wymaga serwerów z dużą ilością RAM-u.
• Nieścisłości w Danych (Data Inconsistency): dane na różnych węzłach mogą być przez chwilę niespójne. Możesz odczytać stare dane, zanim propagacja zmian się zakończy.
• Złożoność architektury: wprowadza dodatkową złożoność do architektury systemu. Wymaga planowania i zarządzania, aby zapewnić prawidłowe działanie i integrację z innymi komponentami systemu.
• Split-Brain: Jeśli węzły stracą komunikację między sobą, może dojść do stanu „split-brain”, gdzie różne węzły mają różne wersje danych. Część aplikacji może korzystać z nieaktualnych danych.

Rozproszony vs Lokalny

Cecha	Rozproszony Cache	Lokalny Cache
Lokalizacja danych	Dane są przechowywane na wielu instancjach.	Dane są przechowywane w pamięci RAM lokalnej instancji aplikacji.
Dostępność danych	Dane są współdzielone między wszystkimi instancjami aplikacji w klastrze.	Dane są dostępne tylko dla jednej instancji aplikacji.
Przykłady technologii	Redis, Memcached, Hazelcast, Infinispan, Apache Ignite, Ehcache (tryb rozproszony)	Caffeine, Guava, Ehcache (tryb lokalny), ConcurrentHashMap
Szybkość dostępu	Dostęp jest szybszy niż do bazy danych, ale wymaga komunikacji sieciowej.	Dostęp jest ekstremalnie szybki, ponieważ dane są przechowywane w pamięci lokalnej.
Skalowalność	Łatwo skalowalny dzięki rozproszonej architekturze – nowe węzły można dodawać w celu zwiększenia pojemności.	Skalowalność ograniczona do zasobów (RAM) jednej instancji aplikacji.
Niezawodność danych	Może obsługiwać replikację i trwałość danych.	Dane są ulotne – tracone w przypadku restartu aplikacji lub awarii instancji.
Złożoność zarządzania	Zazwyczaj wymaga dodatkowej konfiguracji.	Łatwe w zarządzaniu – wystarczy biblioteka lub struktura danych w aplikacji.
Przeznaczenie	Do współdzielenia danych między wieloma instancjami lub usługami w architekturze rozproszonej	Do lokalnego buforowania danych specyficznych dla jednej instancji aplikacji.
Czas życia danych (TTL)	Obsługuje globalne TTL dla danych, które są ważne niezależnie od instancji.	Dane wygasają tylko w kontekście jednej instancji aplikacji.
Koszty	Wymaga dodatkowych zasobów infrastruktury (np. serwery Redis, Memcached).	Niskie koszty – wykorzystuje lokalną pamięć aplikacji.
Odporność na awarie	Może być replikowany, co zwiększa odporność na awarie	Dane są tracone w przypadku awarii procesu aplikacji.

Kiedy wybrać który?

Algorytmy przechowujące dane

Wiemy już czym jest cache i jakie są jego typy. Teraz pora poznać jakie algorytmy są implementowane najczęściej. Warto poznać co się dzieje pod bebechami, w jaki sposób nasze dane są organizowane w cache. W gotowych rozwiązaniach mamy możliwość customizowania, znając skróty (np. LRU, LFU) oraz teoretyczne działanie algorytmu, jesteśmy w stanie lepiej go ustawić.

• Zastosowania i ograniczenia: Omówienie, kiedy i dlaczego warto stosować dany algorytm oraz ich potencjalne ograniczenia.

Najpopularniejsze algorytmy to:

• LRU (Least Recently Used)
• LFU (Least Frequently Used)
• FIFO (First In, First Out)
• ARC (Adaptive Replacement Cache)
• SLRU (Segmented LRU)
• 2Q (Two-Queue)

LRU (Least Recently Used)

Algorytm LRU usuwa najdawniej używane elementy z cache, aby zrobić miejsce dla nowych. Jest to jeden z najczęściej stosowanych algorytmów, ponieważ dobrze odzwierciedla rzeczywiste wzorce użycia danych. Warto go stosować gdy ważne są najświeższe dane.

Wyobraźmy sobie aplikację udostępniającą zdjęcia. Zdjęcia są przechowywane na dysku, a ich pobieranie zajmuje pewien czas. Aby przyspieszyć dostęp do często żądanych zdjęć, aplikacja może użyć cache LRU. Kiedy użytkownik żąda zdjęcia, aplikacja najpierw sprawdza, czy znajduje się ono w pamięci podręcznej. Jeśli tak, zdjęcie jest natychmiast zwracane. Jeśli zdjęcia nie ma w pamięci podręcznej, aplikacja pobiera go z dysku, zapisuje w pamięci podręcznej i zwraca użytkownikowi. Pamięć podręczna LRU ma ograniczoną pojemność, więc gdy jest pełna, algorytm usuwa najdawniej używane zdjęcie, aby zrobić miejsce dla nowego. Dzięki temu często żądane zdjęcia są szybko dostępne, co poprawia wydajność serwera i skraca czas ładowania strony dla użytkowników

LFU (Least Frequently Used)

Algorytm LFU usuwa elementy, które były najrzadziej używane w danym okresie czasu. Wymaga on śledzenia liczby odwołań do każdego elementu w cache, co może zwiększać złożoność implementacji i obciążenie pamięci. Warto go stosować gdy ważna jest częstotliwość użycia.

Wyobraź sobie, że tworzysz aplikację finansową, która pokazuje kursy walut w czasie rzeczywistym. Każdego dnia tysiące użytkowników sprawdza notowania, ale większość z nich interesuje się tylko kilkoma najpopularniejszymi walutami – np. USD, EUR i PLN. Zamiast za każdym razem pobierać dane z API, przechowujemy w pamięci najczęściej pobierane kursy walut, a rzadko używane usuwamy.

1⃣ Użytkownik pyta o kurs USD/PLN. Sprawdzamy, czy mamy go w LFU Cache.
2⃣ Im częściej dana waluta jest wyszukiwana, tym dłużej pozostaje w cache.
3⃣ Jeśli cache jest pełny, usuwamy najrzadziej pobierane waluty.

FIFO (First In, First Out)

Algorytm FIFO usuwa najstarsze elementy z cache’a w momencie, gdy osiągnięty zostaje jego maksymalny rozmiar. Jest to prosty algorytm, ale może nie być optymalny w przypadku, gdy starsze dane są nadal często używane.

Załóżmy, że budujemy serwer proxy, który buforuje strony internetowe, aby zmniejszyć liczbę żądań wysyłanych do serwera źródłowego. Kiedy użytkownik odwiedza stronę, jej zawartość jest zapisywana w pamięci podręcznej. Jeśli inny użytkownik zażąda tej samej strony, proxy zwróci ją z cache, zamiast pobierać ponownie z internetu.

Jednak cache ma ograniczoną pojemność, więc najstarsze strony muszą być usuwane, aby zrobić miejsce na nowe. FIFO dobrze sprawdza się w tym przypadku, ponieważ starsze strony są mniej prawdopodobne do ponownego użycia.

ARC (Adaptive Replacement Cache)

ARC to bardziej zaawansowany algorytm, który łączy cechy LRU i LFU. Dostosowuje się do zmieniających się wzorców użycia danych, starając się utrzymać równowagę między częstością a świeżością danych w cache’u. Algorytm opiera się na czterech listach, które służą do zarządzania pamięcią podręczną. Dwie główne listy, T1 i T2, odpowiadają za przechowywanie odpowiednio niedawno używanych oraz często używanych elementów. Dodatkowo istnieją dwie listy pomocnicze, B1 i B2, które przechowują referencje do elementów wcześniej usuniętych z T1 i T2, co pozwala na inteligentne dostosowanie algorytmu do zmieniających się wzorców dostępu do danych.

Załóżmy, że mamy system rekomendacji filmów w serwisie streamingowym. Filmy mogą być często oglądane przez różnych użytkowników (np. hity kinowe), ale niektóre treści mogą być oglądane tylko raz przez jednego użytkownika (np. premierowe odcinki seriali). ARC może być tu użyty do cache’owania najczęściej oglądanych filmów, jednocześnie dostosowując się do zmieniającego się trendu popularności. Jeśli dany film jest nagle często oglądany przez wielu użytkowników, ARC zwiększy swoją pamięć dla takich elementów (T2). Jeśli użytkownicy konsumują głównie nowe treści (np. nowy sezon serialu), ARC dostosuje się do tego, zwiększając T1 i usuwając mniej popularne starsze filmy.

SLRU (Segmented LRU)

SLRU to wariant klasycznego algorytmu LRU, który wprowadza podział pamięci podręcznej na dwa segmenty: ochronny i próbny. Ochronny przechowuje często używane elementy, które zostały uznane za „ważne”, próbny natomiast nowe elementy, które jeszcze nie zostały uznane za istotne. Nowo wczytane elementy trafiają najpierw do segmentu próbnego. Jeśli element zostanie ponownie użyty, jest przenoszony do segmentu ochronnego. Elementy z segmentu ochronnego mają pierwszeństwo przed usunięciem – jeśli pamięć cache jest pełna, elementy usuwane są w pierwszej kolejności z segmentu próbnego, co zwiększa szanse na zachowanie często używanych danych.

Weźmy realny przykład z e-commerce. Każdy użytkownik, odwiedzając sklep internetowy, otrzymuje sesję, która może być wykorzystywana wielokrotnie, np. podczas dodawania produktów do koszyka, ale w wielu przypadkach jest jednorazowa – użytkownik przegląda stronę i nigdy nie wraca. W takim scenariuszu nowo utworzone sesje trafiają najpierw do segmentu próbnego pamięci podręcznej. Jeśli użytkownik podejmuje kolejne działania, jego sesja zostaje przeniesiona do segmentu ochronnego, co oznacza, że uznano ją za wartościową. W momencie, gdy pamięć cache się zapełni, system usuwa w pierwszej kolejności elementy z segmentu próbnego, pozostawiając w cache sesje użytkowników aktywnie korzystających z platformy. Dzięki takiemu podejściu unika się przechowywania w cache sesji użytkowników, którzy odwiedzili stronę tylko raz i nie wykazali żadnej aktywności.

2Q (Two-Queue)

Algorytm 2Q to ulepszona wersja LRU, która lepiej radzi sobie z jednorazowymi dostępami do danych. Dzieli pamięć cache na dwie główne kolejki: A1 i Am. Nowe elementy trafiają najpierw do A1, która pełni funkcję filtra. Jeśli dany element zostanie użyty ponownie po usunięciu, przechodzi do Am, gdzie przechowywane są często wykorzystywane wpisy. Dzięki temu system unika sytuacji, w której jednorazowe żądania wypierają wartości bardziej istotne.

Wyobraź sobie aplikację internetową dla sklepu online, który obsługuje zapytania użytkowników o szczegóły produktów. Każde zapytanie pobiera dane z bazy, co może powodować duże obciążenie serwera. Standardowy mechanizm cache oparty na LRU miałby problem, gdyby użytkownicy jednorazowo przeglądali wiele różnych produktów – te mniej popularne mogłyby wypierać z cache’a często wyszukiwane artykuły.

Algorytm 2Q rozwiązuje ten problem poprzez wstępną kolejkę A1, do której trafiają nowo pobrane produkty. Jeśli dany produkt zostanie zapytany tylko raz, po krótkim czasie zostanie usunięty, nie wpływając na cache długoterminowy. Natomiast produkty często wyszukiwane zostaną przeniesione do kolejki Am, gdzie będą utrzymywane dłużej, co przyspieszy ich późniejsze ładowanie. Dzięki temu aplikacja efektywnie zarządza pamięcią cache, zmniejsza liczbę zapytań do bazy danych i poprawia czas odpowiedzi dla użytkowników.

Porównanie algorytmów

Inwalidacja cache

Inwalidacja cache to proces usuwania lub aktualizowania nieaktualnych danych w pamięci podręcznej. Jest kluczowa dla zapewnienia spójności danych i zapobiegania zwracaniu przestarzałych wartości. Istnieją różne strategie inwalidacji, zależnie od wymagań aplikacji.

Inwalidacja oparta na czasie (TTL – Time-To-Live) / TTI (Time-To-Idle)

TTL jest najprostsza metodą, w której każdy wpis w cache ma określony czas życia. Po upływie tego czasu zostaje automatycznie usunięty. TTI powoduje usunięcie wpisu z cache, jeśli nie był on używany przez określony czas. TTI i TTL można łączyć, np. ustawić TTL na 30 min i TTI na 10 min, aby zapewnić zarówno maksymalny czas życia, jak i usuwanie nieaktywnych danych.

Inwalidacja natychmiastowa (Explicit Invalidation)

Aplikacja ręcznie usuwa wpisy z cache, gdy dane ulegną zmianie. Gwarantuje to aktualność danych, ale wymaga dokładnego zarządzania cachem.

Inwalidacja oparta na polityce zastępowania (LRU/LFU)

LRU usuwa najdawniej używane wpisy, a LFU najrzadziej używane wpisy. Sprawdza się, gdy cache ma ograniczony rozmiar. Jego wadą jest, że może przetrzymywać nieistotne dane, które znalazły się w cache a mogłyby już z niego wylecieć.

Jaką strategię wybrać?

• Dane szybko się zmieniają? → TTL + TTI + Explict Invalidation.
• Masz ograniczoną pamięć cache? → LRU/LFU.
• Dane muszą być zawsze aktualne? → Explict Invalidation.

Monitorowanie cache

Monitorowanie cache to kluczowy proces, pomagający utrzymać wydajność, spójność danych i oszczędność zasobów. Aby efektywnie monitorować cache, należy zastanowić się nad metrykami.

Jakie metryki warto zbierać?

• Hit Ratio – określa, jak często dane są znajdowane w cache, zamiast być pobierane z bazy.
• *Miss Rate – pokazuje, ile zapytań nie znajduje danych w cache i musi iść do bazy. Jeśli zbyt wysoki, warto zwiększyć rozmiar cache lub poprawić strategię inwalidacji. Miss Rate i Hit Ratio wzajemnie sumują się do 100%, więc mierząc jeden, automatycznie otrzymujesz drugi.
• Eviction Rate (Wskaźnik usunięć) – Mierzy, ile obiektów zostało usuniętych z cache (z powodu przepełnienia, TTL lub inwalidacji). Zbyt wysoki wskaźnik oznacza, że cache jest za mały.
• Memory Usage (Zużycie pamięci) – ile RAM zajmuje cache.
• Latency (Opóźnienie) – ile trwa odczyt/zapis w cache.

Jak monitorować Cache w Javie?

W Javie istnieje kilka sposobów monitorowania cache. Dużo zależy od tego, jakiego typu aplikację rozwijamy/tworzymy. Jeżeli tworzysz aplikację w Spring Boot, możesz w prosty sposób dodać zależności do actuatora + micrometer’a i prometheusa.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

Następnie w application.properties (lub analogicznie yaml z odpowiednią strukturą) wystarczy włączyć metryki i możemy strzelać do API:

management.endpoints.web.exposure.include=*

curl 'http://localhost:8080/actuator/caches' -i -X GET

Teraz można przenieść te dane do Prometheusa, zrobić dashboardy na Grafanie, dodać alerty i mamy gotowy system monitorujący. Nie jest to temat na ten artykuł.

Natomiast jeżeli nie używamy Spring Boota, możemy użyć MBean’ów JMX’a. Jeżeli korzystasz z popularnego rozwiązania do cache’owania w Javie, to jest duża szansa, że to rozwiązanie daje możliwość udostępnienia danych przez JMX. Osobiście korzystając z tych metryk, używałem bezpośrednio DataDog’a, więc nie jestem w stanie powiedzieć czy integracja ze stackiem Prometheus + Grafana jest tu możliwa, ale zakładam, że tak.

Podsumowanie

Cache jest potężnym narzędziem, które może znacząco przyspieszyć działanie aplikacji. Poprzez inteligentne przechowywanie danych w pamięci podręcznej, możemy zmniejszyć czas dostępu do nich i zwiększyć wydajność. Warto zatem znać i rozważyć wykorzystanie cache’a.

Jeżeli chciałbyś rozwinąć którąś z sekcji, podzielić się swoją opinią czy doświadczeniami, to zachęcam do dyskusji w komentarzach.

Artykuł Cache w Javie. Trochę wiedzy pochodzi z serwisu bdabek.pl.

Dawno mnie tu nie było, ale wracam po długiej przerwie… bardzo długiej. Do bloga wracam po tym, jak zastanawiałem się nad jego zamknięciem przy końcówce roku, gdy trzeba było opłacić domenę i hosting. Zdecydowałem jednak, że przejdę na tańszy hosting a przy migracji przeglądałem skrzynkę odbiorczą, która dodatkowo mocno zachęciła mnie do powrotu.

Dziś chciałbym się podzielić subiektywnymi wskazówkami – tudzież doświadczeniami – jak, jako programista radzę sobie ze stresem w pracy (i nie tylko). Temat wydaje mi się o tyle istotny, że każdy przeżywa jakiś stres. Praca programisty na pierwszy rzut oka wydaje się bezstresowa i lekka – przecież nie narażamy niczyjego zdrowia. Dokładnie takie stwierdzenie usłyszałem ostatnio od znajomego. Nie chciało mi się tłumaczyć, jak szeroki zakres ma dziś IT i na jakie aspekty życia nasza branża wpływa. Mam świadomość, że nie każdy potrafi sobie poradzić ze stresem, dlatego chcę dać Ci pięć przykładów, jak to jest u mnie. Wydaje mi się, że wyszedł całkiem ciekawy artykuł i mam nadzieję, że będziesz zainspirowany / zainspirowana.

W dzisiejszym artykule dowiesz się, jak radzę sobie ze stresem poprzez:

• Aktywność fizyczną
• Wyzwania 30 dniowe
• Codzienny dziennik
• Wspomnienia z przeszłości
• Wiarę

Aktywność fizyczna

W moim przekonaniu dowolna aktywność fizyczna pomaga i rozwija w bardzo wielu aspektach. Co rozumiem przez aktywność? Dla mnie jest to dowolny ruch ciała, zwiększający zużycie kalorii. Dla jednego to będzie kilku kilometrowy spacer, dla innego wyczerpujący trening kilka razy w tygodniu, a kolejnemu jakaś gra zespołowa, np. siatkówka, piłka nożna, squash, etc. Ja na przestrzeni ostatnich 7 lat wykształtowałem sobie nawyki w różnych rodzajach ćwiczeń. Obecnie są to głównie sporty indywidualne, gdzie jedyną osobą, z którą się challenguję jestem sam… i to mi odpowiada.

Nie bój się porażek

W pierwszych latach, gdy nieświadomie kształtowałem nawyk aktywności fizycznej lubiłem gry zespołowe – szczególnie siatkówkę i siatkówkę plażową (nadal je lubię!). Natomiast do tego potrzebny jest zespół. Oprócz tego trzeba reprezentować poziom zależny od tego z kim grasz. Ja byłem przeciętny. Miałem wzrost (190cm) i to było jakimś plusem, coś tam umiałem ściąć, wyblokować i wystawić, ale bez rewelacji + robiłem sporo błędów. I właśnie te przyczyniły się do tego, że uznałem iż się nie nadaję. Nie mam talentu, żeby grać na wystarczająco dobrym poziomie, który by mnie zadowalał + nie chciałem psuć zabawy innym.

Od roku 2016 zacząłem biegać. Do biegów miałem przeważnie kompana, który przez około 3 lata chętnie się dołączał. Później pojawiła mu się dwójka dzieci i ciężko było wychodzić na wspólne bieganie. Taka kolej rzeczy, priorytety się zmieniają. Natomiast te 3 lata wystarczyły do tego, żebym się wkręcił. Pokochałem bieganie, szczególnie po lesie. Teraz rocznie staram się przebiec minimum 365 kilometrów – 1 kilometr dziennie. Chociaż mówiąc trochę nawiasem, a trochę się chwaląc, w 2024 wyszło mi ich 606. Dodatkowo od 2019 roku, kiedy w Polsce robi się wiosennie, zaczynam jeździć rowerem. W ciągu 5 lat nauczyłem się siebie i wiem jaka jazda najbardziej mi odpowiada. Lubię szybko i nie za długo – trasy najlepiej do max. 2 godzin (choć czasem fajnie jest zrobić odskocznię). Historia pokazuje, że średnio moje trasy mają 20-30km i zajmują około godziny.

Jak zacząć?

Co bym polecił osobie, która nie ćwiczy, nie zna się na tym, ale chce coś zmienić? Zacząć być aktywnym dziś, teraz! Moja świadomość i wiedza w zakresie aktywności fizycznej jest o kilka rzędów wielkości większa niż jak zaczynałem, ale zacząć od czegoś musiałem. Bardzo często biegając po lesie porównywałem sobie przebiegnięcie 1 kilometra do czasu straconego na youtubie. I co, że obejrzę jakiś filmik, który nic nie wnosi (albo wnosi mało) do mojego życia? Nic, to tylko stracone minuty życia. Zresztą…aktywność da się łączyć z nauką czy treściami rozrywkowymi. Z tym pierwszym jest to mało efektywne, ale z tym drugim – przyjemne z pożytecznym.

Podsumowując ten akapit, aktywność fizyczna to sprawdzony i potwierdzony przez wiele osób i badań sposób na radzenie sobie ze stresem. Podczas ćwiczeń, w zależności co będziesz robić, możesz wyładować negatywne emocje, wyciszyć się, wypocić, przemyśleć wiele tematów, poszukać inspiracji. Regularnie ćwicząć zwiększasz odporność na stres. Same korzyści. Ja polecam, jeżeli jeszcze tego nie robisz, zacznij. Nie pożałujesz.

Wyzwania 30 dniowe

Czym są wyzwania 30 dniowe wedle moich reguł? Jest to lista czynności do wykonania. Lista zawiera zazwyczaj 8-10 elementów – w zależności od roku. Każdy element z listy powtarzam codziennie, przez 30 dni. Jeżeli zrobię przerwę podczas trwania wyzwania (nawet w 29 dniu), to wyzwanie powtarzam jeszcze raz przez całe 30 dni. Bez względu na chorobę czy ból, mam przejść cały cykl. Czy zdarzyło mi się, że powtarzałem cykl? Tak. Czy zdarzyło mi się, żebym zrobił wyjątej od tej reguły – tak.

Co mi dają wyzwania 30 dniowe? Motywację do działania. Ćwiczą we mnie zaciętość, dają mi cel i możliwość jego osiągnięcia. Bez względu jak się czuję i jaka jest pogoda za oknem, muszę zrobić to co zaplanowałem. Mam przecież całe 24 godziny na wykonanie wyzwania. No dobra, ale co to ma do radzenia sobie ze stresem? Jeszcze aktywność fizyczna to rozumiem, ale jakieś wyzwania? No i dlatego na samym początku tego wpisu informowałem, że jest to moja subiektywna lista sposobów. Natomiast pozwól, że spróbuję udowodnić, że jednak ma.

Kiedy to robię

Wyzwania ustalam pod koniec każdego roku, przy okazji podsumowując poprzedni. I to jest u mnie istotny etap. To od niego zależy, co będę robił przez około 8-10 miesięcy kolejnego roku codziennie. W jaki sposób wyznaczam wyzwania? Głównie inspiruję się Internetem i (już teraz) historią moich poprzednich wyzwań. Staram się, żeby to było coś, co mnie rozwinie w dowolny sposób – duchowy, fizyczny, intelektualny. Dowolny. Staram się, żeby było to na tyle ciekawe dla mnie samego, żebym chciał zrobić to na nowo kolejnego dnia – przynajmniej z początku roku. Podczas samych wyzwań bywa już różnie. Moje aktualne wyzwania możesz śledzić na githubie.

Na ten rok obrałem sobie dziewięć wyzwań 30 dniowych. Załóżmy, że pierwsze wyzwanie zacznę 15 stycznia i każde kolejne będę zaczynał pięć dni po poprzednim skończonym. Bez większej matematyki, ale powiedzmy, że mniej więcej w listopadzie skończy się moje ostatnie wyzwanie. To oznacza, że do tego czasu, raz w miesiącu mam poczucie osiągnięcia czegoś, co chciałem. Daje mi to satysfakcję i podbija moje endorfiny, czy jakiejś tam inne hormony szczęścia i daje zapał do dalszej pracy. Podczas wyzwań bywa ciężko. Jeżeli pokonałem przeciwności, jestem silniejszy, odporniejszy – wiem, że mogę jeżeli chcę.

Codzienny dziennik

Od 2018 roku prowadzę codzienny dziennik. Wpisuję tam swoje przemyślenia – co robiłem wczoraj, co będę robił dziś, za co jestem wdzięczny, na co jestem zły. Pewnego rodzaju daily, sam ze sobą. Można to robić w formie fizycznego dziennika, pliku tekstowego, nagrań głosowych, nagrań video i co jeszcze do głowy przyjdzie. Ja codzienne notatki prowadzę w formie zwykłego pliku tekstowego. Tak mi najbardziej pasuje. Możesz się nim dzielić z innymi, a możesz zachować wyłącznie dla siebie. Jeżeli nigdy przedtem nie robiłeś/aś czegoś podobnego to muszę Cię przestrzec. Prowadzenie dziennika daje wartość pod dwoma warunkami. Po pierwsze robisz to przez dłuższy czas. Osobiście uważam, że co najmniej rok jest już wystarczający, żeby się za to zabrać. Drugim jest przegląd dziennika od czasu do czasu.

Przejdźmy do korelacji dziennika ze stresem według mnie. Mogę tam wyładować swoje negatywne emocje, jeżeli takie się pojawią. Codziennie mogę tam napisać za co jestem wdzięczny. Oczywiście nie zawsze to robię, a nawet powiedziałbym, że rzadko. Natomiast codziennie coś wpisuję, dosyć często są to bardzo zbliżone wpisy, ale w kontekście roku jest kilka perełek, nad którymi mogę się głębiej zastanowić. Przegląd dziennika robię raz w roku, na jego koniec. To pomaga mi w sprawdzeniu siebie i podsumowaniu rocznym. Widzę co przechodziłem, jak to przeżywałem i z perspektywy czasu jestem w stanie sprawdzić – czy to było warte stresu. Odpowiednio wyciągnięte wnioski są cennymi lekcjami na kolejne lata.

Stres zawodowy

Kolejnym plusem prowadzenia dziennika w kontekście radzenia sobie ze stresem zawodowym jest możliwość ustawienia priorytetów. Ja wpis do takiego dziennika staram się robić codziennie rano. To sprawia, że już z samego rana mogę zaplanować tę najważniejszą rzecz, którą chcę/powinienem zrobić. Obecnie nie praktykuję tego codziennie. Właściwie jak to piszę, to myślę, czy by do tego nie wrócić… Wyplucie na ekran tego, co powinienem zrobić i świadomość, że jutro sam przed sobą to ocenię, może zwiększyć przypływ motywacji, poczucie kontroli i zarazem zredukowanie stresu. Z drugiej strony ciągłe niewykonywanie postawionych celów może tę motywację zabić, a stres zwiększyć.

Jeszcze słowem zakończenia tego akapitu, gdybyś chciał(a) zacząć praktykować dziennik. Nie załamuj się, jeżeli opuścisz dzień czy dwa. Mnie samemu czasem zdarza się pominąć jakiś dzień, gdy np. mam mnóstwo obowiązków z rana, a później w ciągu dnia całkowicie wylatuje to już z głowy. Z początku to nie będzie Twój nawyk i możliwe, że będziesz musiał(a) sobie przypominać o wpisach. Z czasem natomiast wchodzi to już w krew. Ostatnio będąc nawet na wakacjach, robiłem codzienne wpisy. Zaskakujące dla mnie było to, że były one o wiele dłuższe i bardziej szczegółowe niż te standardowe.

Wspomnienia z przeszłości

Kolejny niekonwencjonaly sposób radzenia sobie ze stresem jest moja własna historia. A może bardziej jej wspomnienie. W IT jestem od 2018 roku – 7 lat będzie w lutym. Natomiast moja droga nie była prosta, żeby być tu, gdzie jestem. We wcześniejszym akapicie wspomniałem, że po 8 tygodniach zrezygnowałem ze swoich pierwszych studiów – zarządzania. W momencie, w którym teraz jestem, uważam, że to była jedna z lepszych decyzji, jakie mogłem podjąć. Ten dzień zapewne będę pamiętał do końca życia. Rodzice nie byli z tego powodu zadowoleni – wręcz odwrotnie, byli na mnie wściekli. A ja w moim planie zakładałem, że to właśnie oni będą mnie utrzymywali. Zastanawiając się teraz głębiej, to nie miałem planu. Na tamten czas chciałem grać w gry i z tego zarabiać.

Nie poszło jednak po mojej myśli. Jako, że byłem na utrzymaniu rodziców, to kazali mi iść do pracy. Nie miałem innego wyjścia, bo z gierek nie zarabiałem wystarczająco, aby pozwoliło mi to na utrzymanie się na własną kieszeń. I poszedłem do swojej pierwszej pracy na magazyn w dużym zakładzie meblarskim. Musiałem pracować na 3 zmiany, gdzie były nocki – a tych nienawidziłem. Po 4 miesiącach wyratowali mnie tato z bratem. Załatwili mi pracę w ich fabryce, gdzie nocek już nie było. Tylko dalej to była praca bez perspektywy, w zamknięciu za drutem. Trochę jakby w obozie pracy gdzie musisz przerobić 8 godzin i dopiero możesz wyjść za mur.

Czas zmiany

I nadszedł piękny dzień, kiedy i z tej pracy zrezygnowałem, a zająłem się tym, co pokochałem. Byłem już studentem zaocznym 2 roku i wiedziałem, kim chcę być w najbliższej przyszłości. Kryteria miałem dosyć proste – nie chciałem pracować w zakładzie, zamknięty za ogrodzeniem i zmuszony, żeby tam być przez 8 godzin. Marzyła mi się praca zdalna i elastyczność z tym związana. W skrócie opisałem moją historię. Oczywistym jest, że Ciebie ona nie odstresuje i nie pomoże Ci w rozładowaniu stresu. Mnie natomiast tak i pozwól że wyjaśnię w jaki sposób.

Kilka razy miałem taką sytuację, że w backlogu nazbierały mi się ważne, trudne zadania do zrobienia, które nie były pilne. Wiem natomiast, że przyjdzie dzień, kiedy zaczną być pilne, a ich ważność jeszcze bardziej wzrośnie. Nie wiem jak Ty funkcjonujesz, ale u mnie stres pojawia się podświadomie. Wspominając zdarzenia z przeszłości, analizując jaką drogę przeszedłem i po co, pomaga mi w załagodzeniu stresu. Ba! Nawet zwiększa motywację do działania! Zdaję sobie sprawę, że u Ciebie to wcale nie musi zadziałać, natomiast u mnie działa i dlatego się tym dzielę.

Wiara

Ostatnie, ale dla mnie najważniejsze. Celowo umieściłem to na samym końcu, bo rozumiem, że o polityce i religii nie powinno się dyskutować. Nie ukrywam swoich poglądów, ale też się z nimi nie afiszuję. Jestem praktykującym chrześcijaninem. Sam czytam Biblię i się modlę bezpośrednio do Boga. To daje mi nowe siły na każdy dzień i pomaga pokonywać stres. Nie chcę się mocno rozpisywać na ten temat, bo blog o charakterze programistycznym nie jest do tego. Natomiast jeżeli jesteś ciekawy/a, to w komentarzach lub prywatnych wiadomościach możemy o tym podyskutować.

Podsumowanie

Wyszedł całkiem długi wpis. Jeżeli dotrwałeś do samego końca, to dziękuję. W artykule odsłoniłem dużą część siebie. Mam nadzieję, że nie spojrzysz na to zbyt krytycznie, ale odnajdziesz coś, co da wartość Tobie. Taki jest mój cel.

To są moje główne sposoby na walkę ze stresem. Czy zawsze mi pomagają w 100%? Nie. Ale jak się głębiej nad tym zastanowić, to nie ma takich sposobów. Z pewnością redukują stres, pomagają pokonywać przeciwności – jest łatwiej. Sposobów na walkę ze stresem jest z pewnością więcej. Jeżeli masz swoje sprawdzone sposoby, które u Ciebie działają – daj znać w komentarzu i pozwól mi lub innym czytelnikom się zainspirować.

Do usłyszenia

Artykuł Jak programista może radzić sobie ze stresem🤔. Moich 5 sposobów ✔️ pochodzi z serwisu bdabek.pl.

W dzisiejszym artykule:

• Aspekty i Spring
• Koncept Aspektów
• Rodzaje Advice w AOP
• Mechanizm Proxy
• Przykład użycia

Aspekty i Spring

Programowanie aspektowe (AOP) uzupełnia programowanie obiektowe (OOP), dostarczając innego sposobu myślenia o strukturze programu. Kluczową jednostką modularności programowania obiektowego jest klasa, podczas gdy w AOP jednostką modularności jest aspekt. Aspekty umożliwiają modularyzację zagadnień (takich jak zarządzanie transakcjami), które dotyczą wielu typów i obiektów.

AOP jest paradygmatem programowania, który ma na celu zwiększenie modularności. Czyni to poprzez dodawanie dodatkowych zachowań do istniejącego kodu bez modyfikowania samego kodu. Zamiast tego, możemy zadeklarować nowy kod i nowe zachowanie osobno.

Jednym z kluczowych komponentów Springa jest framework AOP. Podczas gdy kontener Spring IoC nie zależy od AOP (co oznacza, że nie musisz używać AOP, jeśli nie chcesz), AOP uzupełnia Spring IoC, aby zapewnić wydajne rozwiązania. AOP w Springu jest używant m.in. do:

• Dostarczania deklaratywnych usług – najważniejszą taką usługą jest zarządzanie transakcjami.
• Pozwala użytkownikom implementować niestandardowe aspekty, uzupełniając ich użycie OOP o AOP.

Koncept Aspektów

Aby lepiej zrozumieć działanie i odsłonić magię aspektów, trzeba się zapoznać z tym jak ten mechanizm działa. Spójrz na obrazek i przejdź do opisu definicji, aby lepiej poznać konept aspektów.

JoinPoint

Joinpoint jest punktem podczas wykonywania programu, takim jak wykonanie metody lub obsługa wyjątku. W Spring AOP, JoinPoint zawsze reprezentuje wykonanie metody.

Pointcut

Poincut jest predykatem, który pomaga dopasować poradę (Advice), która ma być zastosowana przez Aspekt w konkretnym JoinPoincie. Często kojarzymy Advice z Pointcutem i jest ona uruchamiana w dowolnym JoinPoincie dopasowanym przez ten Poincut.

Advice

Advice jest akcją podejmowaną przez aspekt w konkretnym JoinPoincie. Są różne typy porad, o czym w kolejnym punkcie. W Springu, Advice jest modelowany jako interceptor, utrzymujący łańcuch interceptorów wokół Joinpoint.

Rodzaje Advice w AOP

Spring AOP zawiera następujące rodzaje porad:

• Before advice – porada, która działa przed JoinPointem, ale która nie ma możliwości zatrzymania wykonania programu (chyba, że rzuci wyjątek).
• After returning advice – porada, którą należy uruchomić po normalnym zakończeniu JoinPointu (na przykład, jeśli metoda powróci bez rzucenia wyjątku).
• After throwing advice – porada, którą należy uruchomić, jeśli metoda zakończy działanie rzucając wyjątek.
• After (finally) advice – porada, którą należy uruchomić niezależnie od sposobu, w jaki JoinPoint wychodzi z wykonania (normalny lub zakończony wyjątkiem).
• Around advice – porada, która otacza JoinPoint, taki jak wywołanie metody. Jest to najpotężniejszy rodzaj porady. Wokół porady może wykonywać niestandardowe zachowanie przed i po wywołaniu metody. Jest ona również odpowiedzialna za wybór, czy kontynuować wykonanie do punktu złączenia (JoinPointu), czy też skrócić wykonanie zalecanej metody poprzez zwrócenie własnej wartości lub rzucenie wyjątku.

Mechanizm Proxy

Spring AOP do utworzenia proxy dla danego obiektu docelowego używa albo:

• dynamicznych proxy JDK
• albo CGLIB

Dynamiczne proxy JDK są wbudowane w JDK, podczas gdy CGLIB jest powszechną biblioteką definicji klas o otwartym kodzie źródłowym (przepakowaną do spring-core).

Jeśli obiekt docelowy, który ma być proxowany, implementuje przynajmniej jeden interfejs, używane jest dynamiczne proxy JDK.  Natomiast jeżeli obiekt docelowy nie implementuje żadnych interfejsów, tworzone jest proxy przez CGLIB.

Przykład użycia

Zaczynamy od napisania Join Pointu – czyli w przypadku springa będzie to jakaś metoda.

@Component
public class BusinessClass{
    public void validateTransaction() {
        System.out.println("...validating");
    }
}

Definijuemy Aspect, Pointcuty oraz Advice’y. Pointcuty można definiować oddzielnie a później wykorzystywać jako ’metodę’ w Advice.

@Aspect
@Component
public class LoggingAspect {

    @Pointcut("execution(* BusinessClass.validateTransaction(..))")
    public void logAfter() {
        //pointcut
    }

    @Before("execution(* BusinessClass.validateTransaction())")     //point-cut expression
    public void logBefore(JoinPoint joinPoint) {
        System.out.println("BusinessClass.logBefore() : " + joinPoint.getSignature().getName());
    }

    @AfterReturning(pointcut = "logAfter()")
    public void logujWyjscieZUslugi(JoinPoint joinPoint) {
        System.out.println("BusinessClass.afterRetuning() : " + joinPoint.getSignature().getName());
    }
}

Po wywołaniu metody, na którą Aspekt był założony wynik naszego programu jest następujący:

BusinessClass.logBefore() : validateTransaction
...validating
BusinessClass.afterRetuning() : validateTransaction

Podsumowanie

Mechanizm AOP z pewnością jest jednym z bardziej zaawansowanych technik programowania, która w pewnym momencie kariery staje się niezbędna. Aspekty pozwalają nam na wszechstronność pisania kodu. Za ich pomocą możemy bezinwazyjnie m.in. dodać logi audytu, lub transakcyjność. Jednak z doświadczeniem przychodzi pewna pokora i chciałbym ustrzec wszystkich podjaranych, że czytelność i utrzymanie kodu jest ważniejsze niż kod napisany fajnie. Z tego powodu raczej odradzam dodawanie biznes case’ów w postaci aspektów. Pamiętaj, ten kod ktoś musi później utrzymać.

Źródła:

• https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop
• https://howtodoinjava.com/spring-aop-tutorial/
• https://www.baeldung.com/spring-aop
• https://blog.allegro.tech/2014/12/aspects-in-spring.html

Artykuł Aspekty i Spring 👈 pochodzi z serwisu bdabek.pl.

Cześć 

Na wstępie zaznaczę, że nie jest to pełna lista, czego warto unikać przy pracy z wyjątkami. Są to jednak przypadki, które zdarza mi się widzieć w kodzie produkcyjnym, a czasami bywa, że sam dokładam do tego jakąś cegiełkę (z czego nie jestem specjalnie dumny).

Jeżeli masz jakiś pattern do dodania, napisz w komentarzu. Zaktualizuję listę.

W dzisiejszym artykule:

• Zbyt szczegółowe informacje
• Przerzucanie wyżej
• Dziesiątki podtypów
• Uciszanie wyjątkowych sytuacji
• Finally z ostatecznym zdaniem

Zbyt szczegółowe informacje

Zdarzyło Ci kiedykolwiek się zobaczyć stack trace błędu aplikacji tam, gdzie nie powinno go być? A może sam napisałeś kod, który podobne bagienko wyrzucał na zewnątrz?

Jestem przekonany, że się z tym spotkałeś. Pamiętaj aby nie dawać końcowym użytkownikom zbyt szczegółowych informacji, gdy nie powinni mieć do niej dostępu. Co to znaczy nie powinni mieć dostępu?

Pisząc oprogramowanie, np. dla instytucji finansowej, na 100% nie chcesz zdradzać używanych technologii i frameworków. Nie jest jasne dlaczego wystąpił błąd (w teorii takie sytuacje przecież nie powinny się wydarzyć bo to wyjątki) i kto go spowodował. Być może ktoś właśnie przeprowadza atak i zbiera dodatkowe informacje. Ujawienie zbyt wielu szczegółów otwiera nowe wektory ataku – można wnioskować które wersje bibliotek są używane i szukać pod nie payload’ów.

Przerzucanie wyżej

Kolejnym często spotyknanym mechanizmem jest wyrzucanie wyjątków warstwę wyżej. Celowo użyłem słowa mechanizm, zamiast błąd. Ile razy zdarzyło Ci się widzieć jakiś Checked Exception (nie pasuje mi tu spolszczenie tego słowa), definiowany na poziomie metody w jakimś serwisie a następnie propagowanym w górę? A właściwie to wyżej i wyżej i tak aż do samego kontrolera.. który, też próbuje wyrzucić to warstwę wyżej.

class Controller {
  public Response serwis() throws Exception {
    return Response.of(new Service().metodaSerwisowa());
  }
}

class Service {
  public String metodaSerwisowa() throws Exception {
    return prywatnaMetodaSerwisowa();
  }

  private String prywatnaMetodaSerwisowa() throws Exception {
    // logika wyrzucająca Exception
    return "Nie istotne";
  }
}

Łap wyjątki jak najszybciej. Wacham się, żeby to napisać, bo wszystko zależy od kontekstu, ALE jeżeli nie wiesz jak obsłużyć ten wyjątek (nie jesteś pewny czy ktokolwiek powinien go łapać), zamień go na Runtime Exception. W przypadku błędu skończysz właściwie z tym samym.

Dziesiątki podtypów

Zdarzyło Ci się widzieć lub definiować specyficzne wyjątki dla poszczególnych case’ów tylko po to aby łatwiej móc zdiagnozować jego wystąpienie?

Jest mi głupio, bo sam w to brnąłem. Tworzyłem nowe wyspecjalizowane wyjątki, których nie miałem zamiaru obsługiwać. Definiujesz customowy wyjątek? Rób to tylko i wyłącznie w przypadku, gdy wiesz, że będziesz go obsługiwał!

Uciszanie wyjątkowych sytuacji

Co powiesz o takim kodzie? Zdarzyło Ci się widzieć lub napisać coś takiego?

public String doSmth() {
  try {
    businessMethodThatThrowsException();
  } catch(Exception e) {
    // TODO:
  }
}

Skoro już obsługujesz wyjątek, to zostaw po nim ślad! Unikaj łapania i wygłuszania wyjątków! Sama nazwa wyjątków mówi, że są to sytuacje wyjątkowe. Jeżeli już wydarzyła się ta wyjątkowa sytuacja, lepiej niech poleci jakakolwiek informacja na stdout. Dlaczego? Będziesz mieć więcej informacji o systemie z jakim pracujesz! Jeżeli będzie to bardzo uciążliwe, to ktoś się tym na pewno zajmie.

Finally z ostatecznym zdaniem

Java działa w taki sposób, że to blok finally ma ostateczne zdanie. Jeżeli kod wyrzuca wyjątek w bloku try, a następnie również w finally, to ostatecznie ten drugi będzie propagowany. Rozważ taki przykład, jak myślisz, co zostanie wyrzucone?

public String doSmth() {
  try {
    throw new IllegalArgumentException("try");
  } catch (RuntimeException e) {
    throw new IllegalStateException("catch", e);
  } catch (Exception e) {
    // nigdy się nie wykona
    System.out.println("oo?");
  }
  finally {
    throw new RuntimeException("finally");
  }
}

Jeżeli powiedziałeś RuntimeException, to masz rację. Spójrz, jaki jest tutaj problem. Straciłeś informację o prawdziwym problemie. Pamiętaj, blok finally ZAWSZE ma ostatnie zdanie!

Podsumowanie

Nie jest to może za obszerny artykuł, natomiast są to sytuacje, które zdarza nam się widzieć i czasami popełniać. Jeżeli masz jakieś inne patterny do dodania, to dziel się śmiało :).

Źródła:

• Victor Rentea – The Definitive Guide to Working with Exceptions in Java
• Presenting Exceptions to Users
• Exception Handling Guide in Java

Artykuł Wyjątki. Czego unikać? pochodzi z serwisu bdabek.pl.

Jeżeli chodzi o poświadczenie wiedzy w zakresie Javy, to dobrą metodą jest uzyskanie certyfikatu. Aby otrzymać certyfikat, trzeba zaliczyć egzamin na odpowiednim poziomie — obecnie jest to 65% poprawnych odpowiedzi. Każde podejście to koszt około 1050 złotych (245$). Czy jest to najlepsza forma? Zapewne nie. Szczególnie dlatego, że sam egzamin nie pokazuje tego jak myślimy, a jedynie sprawdza naszą znajomość języka i jego specyfikacji, ale o tym w dalszej części artykułu.

Osobiście mam przeświadczenie, że niewiele osób decyduje się na pozyskiwanie certyfikatów (szczególnie w świecie Javy). Wydaje mi się, że jednym z głównych powodów jest rozpowszechnione myślenie, że certyfikaty niczego nie dają. Dają czy nie dają? Do tego wrócimy jeszcze we wnioskach…

W artykule będę zamiennie używał słów certyfikat / egzamin. Oba terminy odnoszą się po prostu do podjęcia próby zaliczenia egzaminu, czy też jego konsekwencji — uzyskania certyfikatu.

W dzisiejszym artykule:

• Ścieżki certyfikatów – OCA, OCP. Co to?
• Przygotowania do egzaminu OCA
• Zapis na egzamin
• Przebieg egzaminu

Ścieżki certyfikatów – OCA, OCP. Co to?

Certyfikacja z Javy posiada kilka możliwych ścieżek. Wybór zależy od potrzeby — naszej lub naszych przełożonych. Nie zawsze jednak możemy ot, tak wybrać dowolną ścieżkę certyfikacyjną. Niektóre z egzaminów wymagają spełnienia pewnych warunków wstępnych. Informacje na temat warunków znajdziesz np. na platformie edukacyjnej Oracle’a lub na stronie konkretnego egzaminu (wpisz nazwę egzaminu — requirements).

Jaka jest różnica między OCA a OCP?

• OCA jest skrótem od Oracle Certified Associate. W świecie certyfikacji jest to egzamin identyfikujący się pod nazwą: 1Z0-808 – Java SE 8 Programmer I. Obecnie (lipiec, 2022) egzamin składa się z 70 pytań, trwa 150 minut, kosztuje 245$ i aby go zaliczyć, trzeba poprawnie odpowiedzieć na 65% pytań.
• OCP, to skrót od Oracle Certified Professional. Jego nazwa w systemie certyfikującym to 1Z0-809 – Java SE 8 Programmer II. Na lipiec 2022 egzamin posiada takie same parametry jak OCA, z wyjątkiem liczby pytań, która wynosi 85!

Zarówno OCA, jak i OCP są egzaminami sprawdzającymi naszą wiedzę w zakresie języka Java. Mają one jasno zdefiniowane bloki tematyczne, wokół których możemy się spodziewać pytań. Nie jest więc tak, że zapisując się na egzamin, musimy znać Javę od A do Z. Moim zdaniem egzaminy OCA oraz OCP są najbardziej wiarygodnym poświadczeniem wiedzy w zakresie znajomości języka.

Ścieżka certyfikacji z Javy prezentuje się w sposób pokazany na obrazku poniżej. Jest to zdjęcie z jednego z popularniejszych serwisów dających dostęp do zestawów testowych (oczywiście za odpowiednią opłatą).

Przygotowania do egzaminu OCA

Cały etap przygotowań podzieliłem na trzy sekcje: analiza, teoria oraz praktyka

Analiza

Na tym etapie nie wiedziałem jeszcze nic, o tym, jak wygląda ścieżka certyfikacyjna. Czym są poszczególne egzaminy, czego się spodziewać, od czego zacząć, jak i na który egzamin się zapisać.

Przed podejściem do egzaminu lepiej mieć wiedzę w tym zakresie. Pozwoli to prawidłowo zaplanować, co musimy powtórzyć, czego musimy się nauczyć, jak zapisać się na egzamin, co mieć ze sobą itp. Na całe szczęście nie trzeba wiedzieć aż tak dużo. Wybierając standardową drogę:

1. Musisz wiedzieć, czym jest OCA, a czym OCP
2. Jaki jest zakres zagadnień poszczególnych egzaminów
3. Z jakich materiałów teoretycznych będziesz korzystać (więcej o tym w sekcji Teoria)
4. Z jakich materiałów praktycznych będziesz korzystać (więcej o tym w sekcji Praktyka)
5. Jak zapisać się na egzamin
6. Jak przygotować się do egzaminu online (nie omawiam tego w tym artykule, ale jeżeli jesteś ciekawy/a, daj znać)

Jeżeli masz kogoś znajomego, kto przechodził podobną drogę, porozmawiaj z nim! W moim przypadku, kiedy podchodziłem do egzaminu, nie miałem nikogo, kto by przetarł przede mną drogę. Zatem, każdy z tych kroków musiałem eksplorować sam. Dzięki Bogu w Internecie jest ogrom informacji i znając język angielski (a podchodząc do egzaminu, powinieneś znać ten język) bez problemu znajdiesz odpowiedzi na większość pytań.

Teoria

Na tym etapie trzeba zapoznać się z materiałem obowiązującym na egzaminie. Może to być przeczytanie książki, która przygotowuje do konkretnego egzaminu lub kurs online. Ja zachęcam do wybrania książki! Jeżeli sami przeczytamy i przerobimy zadania, to więcej zostanie w głowie niż po obejrzeniu kursu.

Należy pamiętać, egzamin a programowanie na co dzień, to dwa różne światy. Egzamin zawiera pytania pułapki i sprawdzi Twoją znajomość języka oraz składni. Pokusiłbym się nawet o takie stwierdzenie: egzamin postawi Cię w roli kompilatora.

Natomiast bez obaw! Egzaminy są przeprowadzane od wielu lat i, pomimo że pytania się zmieniają, to struktura egzaminu NIE! I dlatego na przestrzeni lat powstało kilka dobrych materiałów do nauki. Z mojej strony polecę Ci książkę, z której sam korzystałem i jestem zadowolony: OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808. Książka typowo pod egzamin. Autorzy dają wiele wskazówek odnośnie do samego egzaminu. Piszą, na co zwracać uwagę i jakich pytań pułapek można się spodziewać. Co więcej, dla każdego z rozdziałów (jest ich 6), przygotowany jest zestaw pytań, sprawdzający w praktyce przeczytaną wiedzę. Dla osoby z kilkuletnim doświadczeniem książka wchodzi lekką ręką

Inną, również polecaną przez wielu lekturą jest OCA Java SE 8 Programmer I Certification Guide by Mala Gupta. Nie czytałem, więc nie mogę z czystym sercem polecić, ale patrząc na recenzje, uważam, że będzie równie wartościowa.

Praktyka

Sekcja praktyczna, czyli rozwiązywanie zadań i przykładowych egzaminów próbnych.

Dzięki temu, że kupiłem wcześniej polecaną książkę (tą), miałem dostęp do strony z testami. Są tam trzy próbne testy (60 pytań każdy), dodatkowo są tam też testy dla każdego z poszczególnych podrozdziałów książki.

Jednak to nie wydawało mi się to wystarczające i bałem się podchodzić do egzaminu wartego 1050 zł bez większej praktyki. W fazie analizy znalazłem kilka polecanych źródeł z przykładowymi testami. Najpopularniejszymi serwisami z pytaniami są:

• Enthuware
• Whizlabs.

Oba są relatywnie tanie — cena około 10$ za 400-500 różnorodnych pytań. Ja zdecydowałem się na Whizlabs. Testy na Whizlabs są ok. Nie mam niestety porównania z Enthuware. Na pewno plusem Whizlabs jest to, że korzystamy z przeglądarki internetowej + do każdego pytania są krótkie wyjaśnienia, dlaczego powinniśmy wybrać daną odpowiedź a inne odrzucić. Choć przyznam, że wyjaśnienia te czasami bywają bezwartościowe. Podam przykład, spolszczając co nieco i dodając szczyptę ironii: odpowiedź A jest błędna, ponieważ nie można tak robić. Mało wyjaśniający tekst, bo bardziej mnie interesowało, dlaczego tak nie można. Całe szczęście takich bezsensownych odpowiedzi nie jest wiele :). Po przeczytaniu wcześniej polecanej książki i przerobieniu pytań na Whizlabs zaliczyłem egzamin na 95%, więc moim zdaniem były to wartościowe źródła.

Inne materiały, nad którymi się zastanawiałem, podaję poniżej. Jednak ze względu na ich cenę, postanowiłem, że wolę odpuścić.

• certification-questions.com
• certleader.com

Zapis na egzamin

TL;DR

Zapis na egzamin w styczniu 2021 w moim przypadku był uciążliwy. Pojawiło się kilka przeszkód, ale ostatecznie udało mi się zapisać… siedząc na słuchawce z konsultantem z UK (a po akcencie wnioskując to z Indii).

Znane mi opcje do zapisu były dwie:

1. kupuję voucher/egzamin na stronie Oracle, a następnie wykorzystuję w systemie certyfikującym (pearson vue)
2. kupuję egzamin bezpośrednio w systemie certyfikującym (pearson vue)

Pomyślałem, że skoro to egzamin Oracle’owy, to kupię egzamin ze strony Oracle’a. Problemy zaczęły się już przy uzupełnianiu profilu… pola walidujące (imię, nazwisko, adres itp.) to porażka. Masz wszystko uzupełnione, wciskasz ok i dostajesz błąd walidacji. Mało tego, pole walidujące numer telefonu posiada wejście na 10 cyfr (pomijając prefiks, który jest wykrywany automatycznie na podstawie wcześniej wprowadzonych pól) i jeżeli podamy mniej (a polskie numery są 9-cyfrowe), to co się dzieje? Oczywiście mamy błąd walidacji! Mocno mnie to zirytowało i aż napisałem do supportu Oracle’a, jak mam uzupełnić to dziadostwo. Rozwiązanie, jakie podali: proszę wprowadzić 0 (zero) jako pierwszą cyfrę.

Przeszliśmy już przez wszystkie pola walidujące, mamy nasz voucher i kierujemy się do płatności. Na ten moment (przypominam, styczeń 2021) są tam 4 metody płatności — najwygodniejsza to oczywiście płatność kartą i tylko taką byłem zainteresowany, więc nie mogę opisać swoich wrażeń z pozostałymi. Wybrałem płatność kartą, uzupełniłem dane karty i aby móc przejść do samego zakupu, trzeba było potwierdzić kartę (lub to, że jest się jej właścicielem, nie wiem). Ogólnie to przenosi mnie na stronę banku, loguję się, widzę płatność dla Oracle’a na 1 zł (!), potwierdzam płatność na telefonie. Strona banku reaguje, że wszystko się udało i za chwilę powrócę do dalszych zakupów i… BAAAM, wywaliło mnie na pustą kartę. W pasku URL widzę tylko dziwny adres jakiegoś API i w zasadzie tyle.

Nic nie mogę zrobić. Na karcie widzę obciążenie na złotówkę (wisiało tak przez około tydzień) i tyle. Spróbowałem powtórzyć proces jeszcze 3x na innych przeglądarkach (nawet na wspaniałym IE!). Na żadnej się nie udało. Ale taki mały tip, że w zależności od przeglądarki, pola walidacyjne działały lepiej (tam, gdzie obsługa flasha była włączona, tam działało to trochę lepiej). O łał… Trochę ponarzekałem, a dopiero przechodzimy do samego systemu certyfikującego — perason vue. Postaram się bardziej streszczać.

W tym przypadku, pola walidacyjne, wprowadzanie numeru telefonu, itp. było o niebo prostsze! Niestety, był ten sam problem z płatnością. Potwierdzasz płatność i dostajesz przekierowanie na pustą stronę. Byłem już zirytowany tym wszystkim i napisałem maila do supportu, jak mam się zapisać na ten egzamin, bo sam nie umiem. Powiedzieli, aby kontaktować się z ich obsługą, podali numer telefonu (numer w UK, bo nie mają wsparcia w Polsce) i godziny pracy. Dzwonię… Standardowa infolinia, automat coś gada i wybieram odpowiednie przyciski. Po kilku wciśnięciach i kolejnych kilku minutach oczekiwania w kolejce w końcu łączy mnie z jednym z konsultantów wspierających sekcje Oracle.

Udało mi się zapisać na ten egzamin za 5 telefonem. Ogólnie całe flow polega na tym, że podajesz swoje dane i mówisz, co chcesz, dlaczego nie możesz sam tego zrobić i oni wprowadzają wszystkie dane za Ciebie. Ale dobra… dlaczego dopiero za 5 razem?? Jeżeli coś im nie działało w systemie, to się rozłączali! Przykład: przeszedłem z gościem przez całe flow, doszliśmy do płatności. Gościu mi mówi, że system akurat im leży, żebym poczekał 4-5 minut i wtedy spróbujemy. Po 5 minutach odezwał się, że dalej nie działa i żebyśmy jeszcze chwilę poczekali. Czekam, czekam… cała rozmowa trwa już 20 minut i nagle słyszę BIP, gościu się rozłączył. A tylko przypomnę, że to rozmowa z numerem z UK, która nie jest specjalnie za tania…

Dobra rada dla każdego, kto musi dzwonić za granicę. Używajcie Skype’a, wychodzi o wiele taniej (lub za darmo, jak się w dobrą promocję trafi).

Przebieg egzaminu

Ten artykuł i tak wyszedł spory, więc w tej sekcji postaram się pisać krótko i zwięźle. Ja podchodziłem do egzaminu online, więc naturalnie ten proces będę opisywać.

Wszystkie przydatne informacje co do samego egzaminu można było znaleźć na tej stronie. Mnie ciekawił bardziej proces weryfikacji przed przystąpieniem do egzaminu i jak to przebiega. Na oficjalnych stronach nie mogłem nic znaleźć, ale jest YouTube :). Poniżej podsyłam video, które przedstawia, jak wygląda proces weryfikacji.

W kwesti samego egzaminu nie było tu nic nadzwyczajnego. Dostajesz pytania i je rozwiązujesz. Egzamin posiada różne typy odpowiedzi — jednokrotnego lub wielokrotnego wyboru. Jeżeli pytania są wielokrotnego wyboru, to w pytaniu jest jasno określona ilość poprawnych odpowiedzi (nie da się zaznaczyć większej ilości). Wszystkie pytania są zamknięte.

Kończąc egzamin, nasz wynik (procent poprawnych odpowiedzi), jest przedstawiony zaraz po zakończeniu. A więc wciskasz Finish i za 10 sekund wiesz, czy egzamin jest zaliczony, czy nie.

Podsumowanie

Egzamin zaliczyłem z wynikiem 95% – myślę, że to jest całkiem ok. Czy warto było wydawać pieniądze na egzamin? W moim przypadku przenosiło się to bezpośrednio na wynagrodzenie, więc dla mnie było warto. Oprócz tego bardzo często firmy oferują pokrycie kosztów, więc czemu by nie spróbować za pieniądze pracodawcy? Dodatkowo mam certyfikat, który dla ewentualnych, przyszłych klientów już coś mówi (co prawda samym OCA może lepiej się nie chwalić, ale lepszy rydz niż nic). Mogę też wpisać coś dodatkowego do CV (o ile potrzebuję). Oprócz kwestii biznesowych, przygotowanie do egzaminu pozwoliło powtórzyć i utrwalić podstawy.

Artykuł Certyfikacja z Javy. Egzamin OCA i Moje Wnioski pochodzi z serwisu bdabek.pl.

Cześć 

W dzisiejszym artykule:

• Czym jest Redis
• Dlaczego warto używać Redisa?
• Do czego stosować?
• Let’s play it

Czym jest Redis

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions, and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.

Jest to opis wzięty z oficjalnej strony autorów oprogramowania. Jak wspomniano, Redis przechowuje dane w pamięci. Nie są one zapisywane na dysku, co zapewnia niezwykle szybki dostęp. Z tego też powodu, Redis jest właśnie często używany jako pamięć podręczna (cache), i/lub pomocnicza baza danych (secondary database).

Z racji, że pamięć jest ulotna, a może się zdarzyć, że nasza aplikacja ulegnie awarii, Redis pozwala podjąć pewne środki zaradcze, poprzez zapisywanie danych na dysku. Możliwość persystencji danych jest jego ogromną zaletą w porównaniu do innych providerów zapewniających cache’owanie.

Podsumowując to prostym językiem – Redis to działająca w pamięci baza klucz-wartość. Sama nazwa, Redis jest akronimem słów Remote (RE) Dictionary (DI) Server (S).

Dlaczego warto używać Redisa?

Każde oprogramowanie, jakie by nie było będzie mieć wady i zalety. Jako świadomi programiści, architekci czy inne osoby podejmujące decyzje techniczne, zanim zdecydujemy się na wybór konkretnego dostawcy oprogramowania powinniśmy rozważyć powody za i przeciw jego użyciu. W Internecie znajdziesz kilka artykułów opisujących wady i zalety Redisa [1,2] z którymi warto się zapoznać przed podjęciem decyzji. Dobrze byłoby również porozmawiać z innymi osobami, które takiego rozwiązania już używają i wyciągnąć od nich informacje/wskazówki.

W tym artykule przedstawię Ci kilka, moim zdaniem istotnych zalet Redisa.

Wydajność

Redis pozwala nawet na 120 000 żądań na sekundę! Więcej o benchmarkach można poczytać na ich stronie.

Wysoka dostępność i skalowalność

Redis oferuje architekturę typu primary-replica w pojedynczym węźle lub w topologii klastrowej. Pozwala to na tworzenie wysoce dostępnych rozwiązań zapewniających stałą wydajność i niezawodność. W przypadku konieczności dostosowania rozmiaru klastra, dostępne są również różne opcje skalowania i powiększania lub zmniejszania. Pozwala to na rozwój klastra wraz z potrzebami.

Replikacja i Trwałość (Durability)

Redis obsługuje replikację asynchroniczną, w której dane mogą być replikowane na wielu serwerach replik. Zapewnia to lepszą wydajność odczytu (ponieważ żądania mogą być dzielone między serwery) i szybsze odzyskiwanie w przypadku awarii serwera głównego. W celu zachowania trwałości Redis obsługuje kopie zapasowe w określonym momencie (kopiowanie danych na dysk).

Prostota i łatwość obsługi

Redis upraszcza kod, umożliwiając zapisanie mniejszej ilości linii kodu do przechowywania, dostępu i korzystania z danych w aplikacjach. Posiada natywne struktury danych i wiele opcji do manipulacji i interakcji z danymi. Obsługuje wiele języków oprogramowania, m.in: Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, R, Go i wiele innych. Również popularne frameworki wspierają prostą integrację z Redisem.

Rozszerzalność

Redis jest projektem open source. Jest oparty na standardach, obsługuje różne formaty danych i posiada bogaty zestaw klientów.

Do czego stosować?

Spora część czytelników zapewne odpowie, że Redisa wykorzystujemy jako pamięć cache i kropka. Sam bym tak odpowiedział gdybym nie pisał tego artykułu :). Jednak Redis może być wykorzystany szerzej. Jasne, wykorzystanie go jako cache jest ogromną zaletą, ale poznajmy też inne możliwości, aby w przyszłości móc rozważyć użycie Redisa również w innych aspektach.

Caching

Redis jest doskonałym wyborem do implementacji wysoce dostępnej pamięci podręcznej w celu zmniejszenia opóźnień w dostępie do danych oraz odciążenia bazy danych i aplikacji. Może obsługiwać często wymagane elementy w czasie krótszym niż milisekunda i umożliwia łatwe skalowanie dla większych obciążeń bez zwiększania kosztu backendu.

Chat, messaging, and queues

Redis obsługuje wzorzec Pub/Sub i różne struktury danych, takie jak listy, posortowane zbiory i hashe. Dzięki temu Redis może obsługiwać wysokowydajne czaty, strumienie komentarzy w czasie rzeczywistym, kanały mediów społecznościowych i komunikację między serwerami. Listy ułatwiają również wdrożenie kolejek. Oferują zarówno operacje atomowe, jak i możliwości blokowania, dzięki czemu nadają się do różnych zastosowań, które wymagają niezawodnego brokera wiadomości.

Gaming leaderboards

Redis wykonuje niesamowitą pracę w inkrementacji i dekrementacji, ponieważ jest w pamięci. Zbiory (Sets) i posortowane zbiory (Sorted Sets) ułatwiają nam również życie, gdy próbujemy wykonywać tego typu operacje, a tak się składa, że Redis oferuje obie te struktury danych. Przykładowo aby wyciągnąć 10 najlepszych użytkowników z posortowanego zestawu – nazwiemy go „user_scores” – można po prostu uruchomić następujące polecenie:

ZRANGE user_scores 0 10

Rich media streaming

Redis może być używany do przechowywania metadanych o profilach użytkowników i ich historii przeglądania, informacji uwierzytelniających/tokenów dla milionów użytkowników, plików manifestów aby umożliwić CDN-om strumieniowe przesyłanie wideo do milionów użytkowników mobilnych i webowych w tym samym czasie.

Let’s play it

Ok. Przeszliśmy przez sekcje teoretyczne. Teraz czas na trochę zabawmy z samym Redisem z poziomu klienta. W świecie rzeczywistym raczej rzadko (o ile w ogóle) będziesz używał klienta z poziomu konsoli. Częściej będzie to zwyczajnie klient, w języku programowania w jakim rozwijasz aplikacje.

Chcąć pobawić się Redisem, mamy dwie opcje:

1. 1. Używamy wersji webowej – Try Redis
   2. Stawiamy kontener dockerowy

Opcja 1 jest prosta, wystarczy wejść w link i można wprowadzać komendy. Opcja 2 wymaga nieco większego wysiłku. Po pierwsze, trzeba mieć zainstalowanego dockera a następnie należy wprowadzić dwa polecenia. Pierwsze, uruchamiające Redisa:

docker run --rm -it --name local-redis -p 6379:6379 redis

oraz drugie, odpalające klienta:

docker run -it --link local-redis:redis --rm redis redis-cli -h redis -p 6379

Teraz w kliencie śmiało można uruchamiać komendy, co będzie miało taki sam rezultat jak byśmy używali wersji webowej.

Redis zapewnia kilka struktur danych oraz zbiór komend ułatwiających manipulację na danych. Aby lepiej poznać jego możliwości przejdźmy przez podstawowe. Polecam wklepać komendy do konsoli i obserwować rezultaty. Niby dużo to nie daje, ale coś w głowie zostanie

Strings

Stringi są najbardziej podstawową strukturą danych. Są binarnie bezpieczne, to znaczy, że mogą zawierać dowolny rodzaj danych, na przykład obraz JPEG lub serializowany obiekt Rubiego. Wartość String może mieć długość maksymalnie 512 megabajtów.

SET name "John"                         
GET name

EXISTS name                            // Check existence of key
DEL name                               // Delete key 
EXPIRE name 5                          // Delete key when expired

SET counter 100
INCRBY counter 25                      // Increments by 25
DECR counter                           // Decrements by 1  

MSET a 10 b 20                         // Multiple SET
MGET a b                               // Multiple GET

Lists

Listy to po prostu listy stringów, posortowane według kolejności wstawiania. Możliwe jest dodawanie nowych elementów na początek listy (head) lub na jej końcu (tail). Maksymalna długość listy wynosi (2^32) – 1 elementów (4294967295, ponad 4 miliardy elementów na listę).

LPUSH myList 10                        // Add from left to head
RPUSH myList "str"                     // Add from right to tail

LRANGE myList 0 -1                     // Range from 0 to -1
LTRIM myList 0 1                       // To keep latest elements
RPOP myList                            // Pop last element

Hashes

Hashes to mapy pomiędzy polami i wartościami string. Są one idealnym typem danych do reprezentowania obiektów (np. użytkownik z wieloma polami takimi jak imię, nazwisko, wiek itp.)

HMSET user id 100 name "Smith" age 50 // Setup hash with key "user"
HGET user id // Only 'id' field returned 
HGETALL user

Sets

Zbiory to nieuporządkowana kolekcja stringów. Możliwe jest dodawanie, usuwanie i sprawdzanie istniejących wartości w stałym czasie (O(1)) niezależnie od ilości elementów zawartych w zbiorze. Maksymalna wielkość zbioru jest taka sama jak w przypadku listy.

SADD mySet 10 45 12 // Add elements to set
SMEMBERS mySet // Get all members of the set
SISMEMBER mySet 10 // Returns whether value exists

Sorted Sets

Posortowane zbiory, podobnie jak zwykłe zbiory są niepowtarzającymi się kolekcjami stringów. Różnica polega na tym, że każdy element posortowanego zbioru ma przypisany wynik (score), który jest używany w celu uporządkowania zestawu, od najmniejszego do największego wyniku. Podczas gdy elementy w zbiorze są unikalne, wyniki (score) mogą się powtarzać!

ZADD children 1992 "Sam"             // Birth-year acts as score
ZADD children 1997 "Tom"

ZRANGE children 0 -1                 // Returns all in order
ZREVRANGE children 0 -1 withScores   // Reverse order of ZRANGE

ZRANGEBYSCORE children -inf 1995     // Scores until 1993
ZREMRANGEBYSCORE children 1990 1995  // Remove from sorted set
ZRANK children "Tom"                 // Score rank of 'Tom'

Podsumowanie

Redis jako oprogramowanie z pewnością jest warte użycia. Korzyści płynące z wydajności wydają się jednym z głównych powodów dlaczego miałbyś użyć właśnie tego rozwiązania. Dodatkowy fakt, że jest to projekt open-source, posiadający aktywne community i mający wiele klientów w różnych językach programowania również przemawia.

Na tę chwilę (na całe szczęście) nie mam żadnych nieprzyjemnych doświadczeń z Redisem. Jeżeli masz jakieś, podziel się tym w komentarzu. Na pewno jest to ciekawy temat do eksploracji, aby zastanowić się jak używać, czego próbowali inni i na co uważać na przyszłość.

Źródła:

• Introduction to Redis
• Redis

Artykuł Redis. Wprowadzenie Dla Początkujących pochodzi z serwisu bdabek.pl.