Pokazywanie postów oznaczonych etykietą bazy danych. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą bazy danych. Pokaż wszystkie posty

poniedziałek, 21 grudnia 2015

33rd Degree 4 Charity we Wrocławiu

Keep things in memory with Cache, Mateusz Herbut

Mateusz na początku przedstawił ciekawą historię, odnośnie tego, dlaczego się zainteresował cache’m i kiedy został zdefiniowany standard JSR-107 - JCache. Fajnie się całość zbiegła z datami z filmu "Powrót do przyszłości", co prelegent dobrze wykorzystał na slajdach.

Mateusz bardzo fajnie przedstawił na diagramach sekwencji różne techniki działa cache'a:
  • Cache Aside
  • Read Through
  • Write Through
  • Write Back
  • Write Behind
  • Refresh Adead

Pierwsze trzy techniki z pośród wymienionych są zdefiniowane przez standard JSR-107, a pozostałe są wspierane dodatkowo przez niektóre implementacje.

Cache Aside jest najprostszy. Klient (aplikacja) sprawdza najpierw, czy wartość jest dostępna w cache’u. Gdy nie, to aplikacja sama odczytuje wartość ze źródła prawdy (dysku, bazy danych, etc.) i jeśli chce, to ją wrzuca do cache’a.

W metodzie Read Through to cache, a nie aplikacja kliencka, jest odpowiedzialna za odczyt wartości ze źródła prawdy i jej zapamiętaniu u siebie na później.

W podejściu Write Through to cache zapisuje wartość do źródła prawdy (synchronicznie) i zapamiętuje u siebie.

Write back zapisuje dane do źródła prawdy, dopiero wtedy gdy dana wartość jest usuwana z cache’a. Podejście to jest często stosowane w procesorach (L1, L2 cache) i wartości te mogą być niespójne ze źródłem prawdy (pamięć RAM). O unieważnieniu cache’a decyduje cache provider.

Przy Write behind klient zapisuje do cache’a i cache asynchronicznie rozpoczyna zapisywanie do źródła prawdy. Gdy w międzyczasie, ktoś będzie chciał odczytać wartości, to dostanie je bezpośrednio z cache’a.

W ostatniej metodzie Refresh Ahead cache decyduje podczas odczytu, czy wartość trzeba odświeżyć, czy nie.

Dalej było jeszcze o 3ch rodzajach operacji jakie mogą być wywoływane na cache’u:
  • Pessimistic locking
  • Lock free
  • Optimistic locking
ale tu już nie będę przedstawiał, które są które.

Bardzo fajna, mięsista prezentacja. Uwagi odnośnie sposobu prezentowania  przekazałem wieczorem bezpośrednio Mateuszowi.

-XX:+UseG1GC, Jakub Kubrynski

Następnie Jakub Kurbyński ładnie omówił Garbage collector G1, który na być domyślny w Javie 9. Prelegent fajnie przeszedł przez to w jaki sposób jest zorganizowana pamięć w Javie i jakie to ma konsekwencje dla algorytmów odśmiecania. Stopniowo powoli odkrywaliśmy nowe pomysły w sposobach organizacji pamięci i algorytmów odśmiecających.

W G1 mamy wiele faz, ale dokładniej były omawiane 4:
  • Young GC
  • Concurrent cycle
  • Mixed GC
  • Full GC
Young GC to odśmiecanie młodej generacji, odpalane po zapełnieniu wszystkich regionów typu Eden. Jest ono wykonywane równolegle i zatrzymuje naszą aplikację. Concurrent Cycle bazuje na wynikach poprzedniej fazy i stara się znaleźć regiony łatwe do odśmiecenia i je oznacza. Mixed GC uwalnia te obszary z poprzedniej fazy. Czyści on pamięć zarówno z młodej generacji, jaki i starej. Najgorzej, gdy dojdziemy do Full GC (jak go zobaczymy w logach), gdyż on odśmieca całą pamięć i zajmuje sporo czasu, bo wykonuje się jednowątkowo. Powinniśmy tego unikać.

Fajne było podsumowanie, jak tuningować G1. Najlepiej ustawić:
-XX:MaxGCPauseMillis=250
lub na inną empiryczną wartość. Wtedy G1 będzie starał się nie przekroczyć zadanego czasu na odśmiecanie. Oczywiście gdy wartość będzie zbyt mała to się to nie uda. Złą stroną tuningu jest natomiast ten slajd:

czyli flagi których należy się wystrzegać ;)

Jeszcze inne dobre praktyki to:

A do przeglądania logów warto skorzystać z GCViewer, JVisualVM i Mission Control.

Nagranie z Confitury, polecam sobie obejrzeć:


Później była przerwa obiadowa, po której na prezentację Tomka Dziurko "Brzydka Pani od HR radzi…” po raz N-ty nie chciało mi się iść (widziałem na YT), a konkurencyjny temat mnie nie zachęcił. Filmik z prezentacji Tomka poniżej:



Liquibase - zarządzanie zmianami w relacyjnych bazach danych, Marcin Stachniuk

W kolejnym slocie przyszedł czas na moją prezentację. Grono zainteresowanych było niewielkie, bo w drugiej sali w tym czasie mówili o mikroserwisach po raz 144. Slajdy (trochę zaktualizowane od ostatniego razu) poniżej.



Ze zmian (po za kolorkami dopasowanymi do konferencji) to istnieje łatwiejszy sposób na wprowadzenie Liquibase'a do istniejącego projektu, niż ten który przedstawiałem na WrocJUG'u. Można skorzystać z komendy changeLogSync, która to tworzy i wypełnia danymi z changelog'a tabele potrzebne do działania biblioteki (DATABASECHANGELOG i DATABASECHANGELOGLOCK), a same zmiany nie są wykonywane. Po więcej szczegółów zapraszam na stonę Liquibase'a: Adding Liquibase on an Existing project.

Drugą wartością dodaną do prezentacji jest moje subiektywne porównanie Flyway'a i Liquibase'a, ale kot nie był niech żałuje.

Java 9, Arkadiusz Sokołowski

Prelegent pokazał parę nowości które nas czeka w kolejnej wersji Javy. Było oczywiście o REPLu i modułach, czyli projekcie Jigsaw i jak to na nas wpłynie. Prezentacja była ok, ale gdzieś już coś o nowościach słyszałem...

Java developer meets AngularJS/JavaScript: real-world projects’ experiences, Marek Matczak

Prelegent pokazywał z początku popularność różnych języków programowania, gdzie górował JavaScript i Java. Marek proponował te dwa języki do obecnych projektów, a dokładniej Spring-Boot’a i AngularJS’a.

Prelegent przedstawił, jakie są możliwości połączenia tych dwóch światów, od strony budowania aplikacji. Jedno podejście, to łączenie części frontend'owej z buildem Maven’owym. Można do tego wykorzystać maven-assembly-plugin, który buduje zzipowaną aplikację kliencką, a później za pomocą exec-maven-plugin można uruchomić node.js’a. A całość do WAR’a można wrzucić za pomocą: maven-war-plugin’a.

Drugie podejście proponowane przez Marka to wykorzystanie exec-maven-plugin’a do budowania frontendu w trakcie fazy generate-sources. Zasoby te wrzucamy do src/main/resources/static, czyli tam gdzie standardowo Spring Boot się ich spodziewa.

Całość jest dostępna na GitHubie jako Open Application Standard Platform (OASP).

Z ciekawostek, które mi utkwiły, to warto się przyjrzeć Google JavaScript Style Guide i Idiomatic JavaScript, aby wiedzieć jak dobrze pisać kod w JavaScript’cie.

Warto też na przyszłość przyjrzeć się Isomorphic JavaScript. Dzięki temu, będziemy mogli wyrenderować stronę HTML po tronie backend'u, co pozwoli nam np. na szybsze ładowanie się strony głównej naszej aplikacji.

Muszę się również przyjrzeć Gulp’owi, gdyż on ma wbudowane reverse proxy.

Dzień 2
On-heap cache vs. Off-heap cache, Radek Grębski

Drugi dzień zaczął się bardzo mięsistą prezentacją na temat pamięci off-heap, czyli pamięci po za standardowym heap’em Javowym. Jest to pamięć, która nie jest zarządzana przez Garbage Collector, można w niej zapisywać tylko tablice bajtów (korzystająć ze standardowego API) i sami musimy zajmować się jej zwalnianiem.

Generalnie bardzo polecam tą prezentację, jest dostępne nagranie z Confitury 2015 jak i kod na GitHubie: https://github.com/rgrebski/confitura2015


Trochę podsumowując prezentację:
Aby zaalokować pamięć w Javie, można skorzystać z następujących klas: HeapByteBuffer (na stercie [heap], do 2 GB), DirectByteBuffer (po za stertą, do 2 GB), MappedByteBuffer (po za stertą, do 2 GB, pamięć perzystowana), Unsafe.allocateMemory() (więcej niż 2 GB).

Pierwsze 3 klasy mogą allokować do 2 GB ponieważ jako argument przyjmują int’a, który ich ogranicza. Bardzo ciekawą klasą jest MappedByteBuffer, która tworzy buffer w pamięci, który może być zapisywany do pliku na dysku. Ma on tą przewagę nad wszystkim innym, że w przypadku całkowitego crash’u maszyny wirtualnej zapis i tak się powiedzie. Operacja ta jest zapewniana przez system operacyjny.

Chcąc allokować pamięć większą niż 2 GB to już trzeba korzystać z Unsafe’a. Korzystanie z tej klasy nie jest łatwe i wygląda jakby sam Chuck Noris ją pisał. Właściwie ta klasa z definicji miała być dostępna tylko dla „zaufanego kodu”, czyli do wewnętrznego użytku przez Javę. Ale coś poszło nie tak i obecnie masa frameworków i bibliotek z niej korzysta. Co gorsza to klasa ma być niedostępna w Javie 9, więc będzie ciekawie. Sporo kodu trzeba będzie przepisać, albo znaleść haka, aby się dostać do odpowiedniego modułu.

Dalej było o Chronicle Map. Jest to mapa, która jest zapisywana po za stertą. Jest też perzystowalna, dzielona pomiędzy osobnymi procesami JVM (również po sieci). Jedynym minusem jest fixed size, tzn. musimy wiedzieć jak duże będą nasze obiekty. I tak dla String’ów i kolekcji musimy za pomocą @MaxSize zdefiniować jak maksymalnie długie będą nasze teksty i jak wielkie kolekcje w obiektach. Gdy przekroczymy granicę to dostaniemy błąd. Obiekty zapisujemy do bloków o stałej wielkości - trochę pamięci się marnuje, ale dostęp do niej jest łatwiejszy.

Dalej było sporo porównań szybkości działania Mapy i Chronicle Mapy. Następnie prelegent opowiedział jeszcze z grubsza o Hazelcas’cie i Redisie, które również porównał z Chronicle Map.

Purely functional data structures, Tomasz Kaczmarzyk

Na początku zaczęło się o tym jak w językach funkcyjnych są zaimplementowane Listy, że składają się z głowy i ogona, że ogon wykorzystuje dokładnie tą samą strukturę co pierwotna lista itd. Kto się uczył Skali, lub innego języka funkcyjnego, to na pewno kojarzy koncept.

Póżniej było już ciekawiej, o tym jak jest zbudowana kolejka w językach funkcyjnych, w której można dodawać elementy na końcu. W standardowej liście jest to bardzo kosztowna operacja. Kolejka wprowadza pewne ciekawe pomysły, jak może ona być wewnętrznie zorganizowana, aby efektywnie przeprowadzać operacje na niej, mi.in. dodawania elementu na końcu. Ten fragment prezentacji był bardzo fajny.

Następnie było o tym jak wewnętrznie jest zorganizowany Git i jaka to jest ładna struktura danych. Temat był mi już wcześniej znany, więc mnie aż tak nie zachwycił jak poprzednia część.

Prelegent miał bardzo fajne slajdy (pisane kredą po tablicy), z ładnymi animacjami przejścia.

Sane Sharding with Akka Cluster, Michał Płachta

Tutaj było mnóstwo programowania na żywo, które działało! Prelegent się dobrze do tego przygotował.

Na początek napisał pojedynczego aktora obsługującego jakieś zapytania i zrobił test wydajności. Następnie, razem z publicznością, udoskonalał rozwiazanie… Implementowaliśmy system rozdzielający paczki na taśmociągu w jakimś magazynie.

Jako drugi krok, prelegent dorzucił drugiego aktora, który tylko podejmował decyzję o przeznaczeniu paczki. Następnie pojawili się kolejni aktorzy i to już bardzo przyspieszyło obsługę zapytań. Na koniec był jeszcze przedstawiony Akka cluster, aby można było to łatwo skalować na więcej maszyn.

Kod z prezentacji jest dostępny tutaj: https://github.com/miciek/akka-sharding-example. Warto przejść sobie po commit'ach i zobaczyć jak się aplikacja rozwijała.

Recepta na retrospekcję z finezją, Wòjcech Makùrôt

Retrospekcje są wpisane w Agile Manifesto jako dwunasty punkt:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
czyli:
W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.
Prelegent podał i opowiedział na przykładach swoje 10 punktów, które trzeba spełnić, aby mieć dobrą retrospektywę. Postaram się streścić, jak ja to zrozumiałem.
  • Trzeba się dobrze przygotować. Spisać sobie plan spotkania, załatwić wszystkie niezbędne pomoce materialne, poszukać inspiracji, aby nie było nudno.
  • Wprowadzamy jakiegoś IceBreak’era, aby rozmawiało się na luzie. Można odwrócić krzesła w sali, aby ludzie musieli zrobić coś innego. Prowadzący spotkanie (facylitator) może być niemerytoryczny - do niego należy moderacja i czasem pacyfikacja spotkania. Najważniejsze jest zdanie innych.
  • Sprawdzamy, czy z poprzedniej retrospekcji udało nam się zrealizować jakieś postanowienia. Jeśli nic się nie udało, to powinniśmy przerwać i zastanowić się dlaczego się nie udało.
  • Możemy opowiedzieć historyjkę, odnośnie tego co działo się w ostatnim sprincie. Budujemy przez to naszą wspólną świadomość.
  • Grupowanie i priorytetyzowanie problemów - powinniśmy zajmować się tylko tymi najważniejszymi problemami.
  • Dziel i rządź, czyli z którymi problemami jesteśmy zdolni sobie poradzić, i które będą miały największy wpływ na poprawę naszej sytuacji.
  • Analiza przyczyn, dlaczego coś nie działa. Tutaj możemy skorzystać z metody 5x dlaczego, ość Ishikawy
  • Planowanie naprawy, czyli: co trzeba zrobić, jak, kto będzie za to odpowiedzialny i na kiedy. Nie warto brać więcej niż 4 tematy do naprawy, bo to może być niemożliwe do zrealizowania.
  • Celebracja tego do czego udało się dojść, czyli warto podziękować za współpracę, nagrodzić jakoś uczestników, wyjść na piwo...
  • Śledzenie postępów w kolejnej iteracji, czyli sprawdzanie wykonania zadań.
Jako źródło inspiracji, warto spojrzeć na retrospectivewiki.org i blog.accentient.com/upgrade-your-sprint-retrospective-meetings oraz do książki Agile Retrospectives.

Slajdy z wystąpienia:


Refactoring meets big money, Michal Gruca

Prelegent przedstawił 3 możliwe podejścia do refactoringu:
  • Codzienny refactoring
  • Pisanie całości od nowa
  • Przepisywanie modułów i podmienianie
Tylko jak to wszystko wytłumaczyć i sprzedać biznesowi? Warto zdecydować się na mierzenie jakiś metryk kodu. Można wziąć jakieś Sonarowe metryki dobrych projektów open source, porównać z metrykami naszych projektów, przełożyć na kasę i strać się wytłumaczyć, że to jest ważne. Warto zrobić sobie sceeena tych metryk z naszego projektu, aby później, po serii refaktoringów, zobaczyć czy i ile się poprawiło.

Warto też, przed pójściem do biznesu, trochę się przygotować. Można stworzyć jakieś prototypowe rozwiazanie i pokazać, że ono przynosi nam jakąś wartość. Przykładowo przyspieszymy build’a albo release’a.

Prelegent polecał do przeczytania fane case study, jak to Soundcloud przechodził na mikroserwisy.

Common fallacies of micro services, Marcin Matuszak

Prelegent w ciekawy sposób podszedł do tego, w jaki sposób obecnie są wynoszone pod niebiosa mikroserwisy, kontrargumentując potencjalne zalety jakie nam daje to podejście. I tak możliwość pisania każdego mikroserwisu w innym języku jest kiepski, bo jak ktoś napisze coś w bardzo egzotycznym języku (którego mało kto zna) i później się zwolni z pracy, to trzeba będzie nauczyć się tego języka, aby utrzymywać kod.

Monolityczne aplikacje wcale nie są takie złe. Są łatwe do pisania testów, w deploymencie i utrzymaniu. Jak rozmawiamy o mikroserwisach, to się skupiamy na tym, że mają być serwisy i że mają być małe. A zapominamy że mają sie komunikować po sieci, co przysparza masę dodatkowych problemów. Jeśli zepsuliśmy aplikację monolitową, to również i zepsujemy mikroserwisy.

Podsumowując całość, była to bardzo fajna konferencja, w końcu coś ciekawego i większego zawitało do Wrocławia. Nie miałem wysokich oczekiwań co do prelekcji, a okazały się one na dobrym poziomie. Byłem więc pozytywnie zaskoczony tą konferencją. Jednocześnie sam miałem okazję wystąpić i wyświetlać swoje slajdy po raz pierwszy na kinowym ekranie.

sobota, 3 października 2015

Po 67 spotkaniu Wrocławskiego JUG'a


Ostatnio miałem przyjemność poprowadzić 67 spotkanie Wrocławskiego JUG'a na temat: Liquibase - zarządzanie zmianami w relacyjnych bazach danych.

Co prawda podobny temat przedstawiałem niemal rok temu na dbconf.pl, ale chciałem w ramach JUG'a zrobić bardziej praktycznie i z przykładami. Tworzyłem więc (przez rok z wieloma przerwami) przykładową aplikację, aby zaprezentować to, co chciałem. Zabrało mi to tyle czasu, bo walczyłem ze Spring Boot'em, Java Movie Database, Postregssem, MySQLem, mapowaniem Hibernate'a, a do tego wszystkiego chciałem pokazać choć proste GUI, a więc jeszcze AngularJS i HTML. Ostatecznie na prezentacji i tak puszczałem nagranie, jak można dodać Liqibase'a do istniejącego projektu, bo znając życie to podczas wystąpienia i tak by coś nie zadziałało, albo nie wiedziałbym jak zwiększyć czcionkę w Idei ;) Dodatkowo miałem mikrofon, który musiałem trzymać w ręce, więc było by ciężko.

Wnioski jakie z tego płyną, to:
- przygotowanie super przykładów, zajmuje wiele czasu - zbyt wiele
- przykłady nie muszą być super dopieszczone i powinny koncentrować się na głównym problemie, a nie dodatkowych aspektach wizualnych
- lepiej skupić się na samej prezentacji - na careercon.pl miałem 5 dni na przygotowanie prezentacji o Javie 8 i się udało (może nie na takim poziomie jakbym sobie tego życzył, ale feedback nie był najgorszy)

Dziękuję sponsorowi spotkania, firmie:

IT Kontrakt

za zapewnienie żłocistego napoju chłodzącego dla uczestników.

Poniżej slajdy ze spotkania...

... i kod z przykładów: https://github.com/mstachniuk/movies-database

Wykład był też nagrywany, ale jego jakość może być wątpliwa, więc jeszcze nie wiem czy udostępnię.

Dziękuję wszystkim uczestnikom za udział i za pozytywny feedback. Widziałem, że pod koniec trochę już niedawaliście rady, ale jakoś dotrwaliście szcześliwie do końca. Wszelki dodatkowy feedback (zwłaszcza ten konstruktywno-krytyczny - co można na przyszłość ulepszyć), mile widziany!

A w najbliższym czasie ponownie się szykuję na dbconf.pl i pewnie będzie pra premiera na WrocJUGu. Jakoś polubiłem tą konferencję, bo może nie jestem do końca typowym bazodanowcem, ale jako że konferencja odbywa się tym razem w Jurze Krakowsko-Częstochowskiej, to jest okazja zwiedzenia okolicy i pooddychania czyst[sz]ym powietrzem. Chcę również pokazać bazodanowcom, że po za bazami SQL (od firmy na O. lub I.) są też jeszcze ciekawe rozwiązania.

Na koniec mały bonus zachęcający do robienia prezentacji




wtorek, 9 grudnia 2014

Moje wystąpienie na dbConf

Jakiś czas temu wspominałem o konferencji dla bazodanowców dbConf.pl

Dziś czas w końcu na relacje z niej, gdyż właśnie się pojawiło moje wystąpienie.


Już nie pierwszy raz mam okazję obejrzenia samego siebie w roli prelegenta, ale to pierwsze, publicznie dostępne nagranie. Poprzednie mało kiepski głos. Na początku jestem mocno spięty, gdyż trochę za późno wyjechałem z Wrocławia i musiałem nieźle palić gumę aby zdążyć na czas. Przyjechałem co prawda na miejsce pół godziny przed konferencją, ale byłem trochę zmęczony i lekko zestresowany – do poprawy następnym razem. Można się jeszcze pewnie przyczepić do wielu mankamentów, ale trzeba się nie poddawać i działać dalej. Chyba że myślicie inaczej to czekam na głosy krytyczne.

Moje wystąpienie było jako pierwsze, więc później mogłem już tylko sobie na spokojnie słuchać innych prelekcji i odpoczywać.

Co do samej konferencji, to bardzo mi się podoba jej formuła. Jest ona weekendowa, w górach, więc w razie zmęczenia można sobie trochę powędrować, co uczyniłem drugiego dnia konferencji. Opuściłem wprawdzie przez to wykłady, ale nie ukrywam, że to miałem w planach:-) Nadrobię sobie niedługo, oglądając pominięte, ciekawsze wystąpienia. Spis opublikowanych już prelekcji można już znaleźć na stronie konferencji, lub na kanale na Vimeo.

DbConf jest wyjazdem beż żon, dzieci, kochanek i wszyscy uczestnicy śpią w jednym ogromnym hotelu. Bardzo dobrze to wpływa na integrację, gdyż osoby nie rozchodzą się wieczorami, a wspólnie spędzają czas wolny. Pierwszego dnia zaplanowano spontanicznie konkurs gry w open hexagon. Jest to chyba gra dla psychopatów, wystarczy obejrzeć poniższą zajawkę:


My graliśmy na jakimś wyższym poziomie, gdzie średni czas rozgrywki wynosił 3 sekundy. Ponadto muzyczka była jeszcze bardziej męcząca niż na filmiku powyżej, więc szybko odpadłem. Nie polecam nikomu tej gry.

W drugi dzień, jak już wspomniałem, odpuściłem sobie wykłady na rzecz chodzenia po górach. Wróciłem jednak na wieczorny grill, który odbył się na zewnątrz. Dzień wcześniej jakaś inna równoległa konferencja też miała mieć podobną imprezę, ale przenieśli się gdzieś do środka. My byliśmy twardzi i siedzieliśmy na zewnątrz przy ognisku. Dobrze że zdążyłem zakupić sobie czapkę tuż przez przyjazdem.

W niedzielę był jeszcze warsztat, ale z tego co widziałem nie było już na nim wielu uczestników. Pewnie albo niektórzy za bardzo zabalowali przy ognisku lub już się rozjeżdżali do domów.

Podsumowując, była to pierwsza edycja tejże konferencji. Liczebnie było skromnie (bo tylko 50 osób), ale jest szansa że się to rozrośnie. Podobnie ponoć zaczynał PhpCon - inna konferencja również organizowana przez Polską Grupę Użytkowników Linuxa. Szkoda tylko, że termin się pokrył z czeskim GeeConem, więc ciężko by było być w dwóch miejscach na raz.

czwartek, 10 lipca 2014

dBConf 2014 nowa konferencja dla bazodanowców w Polsce

Ruszyła właśnie nowa konferencyjna inicjatywa w Polsce, mianowicie: dBConf 2014, czyli "Bazodanowcy wszystkich środowisk łączcie się!" - tak brzmi motto konferencji. Organizatorem jest PLUG, czyli Polska Grupa Użytkowników Linuxa. Konferencja odbędzie się w dniach 24 - 26 października w Szczyrku. Rejestracja dla uczestników jest już otwarta i do końca lipca obowiązuje promocyjna cena.

A dlaczego o tym wspominam? Widzę trzy powody. Po pierwsze jest to nowa inicjatywa na naszej konferencyjnej scenie i myślę, że sporo z Was może również być zainteresowana udziałem. Wiem, że na co dzień pewnie programujecie, ale z pewnością również nie jest Wam obca tematyka baz danych. No bo przecież gdzieś trzeba składować te wszystkie dane wpisywane przez użytkowników waszych aplikacji.

Po drugie, jak pokazuje agenda, będę występował i przemawiał na tej konferencji. Opowiem trochę o Liquibase, czyli jak zarządzać zmianami w relacyjnych bazach danych. Jest to temat właściwie na styku dwóch światów, tj. kodu i perzystencji, ale organizatorom się spodobało. Chciałem o tym przemawiać na tegorocznej Confiturze, ale mój opis w C4P był za mało seksi i nie przeszedł głosowania. Po za tym w czerwcu miałem masę innych aktywności, więc i tak nie koniecznie znalazłbym czas na odpowiednie przygotowanie się.

Po trzecie i chyba najważniejsze, piszę o tej konferencji, ponieważ można jeszcze zgłaszać swoje wystąpienia, do czego Ciebie (tak Ciebie drogi czytelniku), gorąco zachęcam! Jest to na pewno dobra okazja do sprawdzenia swoich umiejętności prezenterskich, jak i podzielenia się swoją wiedzą z innymi. C4P jeszcze trwa, więc powinieneś się zgłosić! Mnie e-mail od organizatorów, którzy natrafili na mojego bloga, odpowiednio do udziału zachęcił. Czas więc i na Ciebie, nie zwlekaj, tylko zgłoś swój temat.

czwartek, 23 grudnia 2010

Db4o jak zacząć?


W tym poście opowiem jak zacząć swoją przygodę z db4o. Nie będę pisał kolejnego tutoriala na ten temat, gdyż zostało to już niejednokrotnie zrobione. Skupię się raczej na przygotowaniu środowiska, pokazaniu przydatnych narzędzi i odesłaniu do ciekawych artykułów. Zaczynajmy.

Chcąc się bawić z db4o musimy na początek wybrać wersję z której będziemy korzystać. Ja na co dzień korzystam z wersji 7.4 określanej jako Stable. Mamy jeszcze wersje 7.12 (określaną jako Production) i 8.0 (Development). Podstawowe funkcjonalności powinny być takie same, ale z tego co kojarzę to poszczególne wersje różnią się pewnymi bardziej zaawansowanymi mechanizmami.

Chcąc więc skorzystać z db4o należy podpiąć odpowiedniego JAR’a pod projekt. Możemy takowego bezpośrednio ściągnąć ze strony producenta: db4o for Java, version 7.4.155.14653 ZIP W tym pliku, katalogu lib mamy min. dostępne odpowiednie wersje JAR’ów przygotowane dla różnych wersji Javy:

  • db4o-7.4.155.14653-java1.1.jar
  • db4o-7.4.155.14653-java1.2.jar
  • db4o-7.4.155.14653-java5.jar

Ja oczywiście korzystam z wersji dla Javy 5. Jeżeli korzystamy z mavena, to musimy dodać następujący wpis:


  
    db4o
    http://source.db4o.com/maven/
  



  com.db4o
  db4o-java5
  7.4-SNAPSHOT


Teraz już możemy się bawić. Na początek polecam przejście tutoriala: doc\tutorial\db4o-7.4-tutorial.pdf z archiwum ściągniętego wraz z db4o. Pokazuje on za pomocą przykładów funkcjonalności db4o. Nie ma tu jakiś wielkich teorii jak całość działa, tylko raczej ukazanie funkcjonalności za pomocą przykładu i krótkiego komentarza. Budowana jest w nim aplikacja odnosząca się do wyścigów F1 i w kolejnych rozdziałach przedstawia kolejne dostępne funkcjonalności.

W tutorialu tym brakuje pokazanego kodu klasy Util. Musimy więc sami stworzyć sobie taką klasę w naszym projekcie, lub zastąpić wszelkie wywołania Util.DB4OFILENAME nazwą pliku w którym będzie przechowywana nasza baza danych. Ewentualnie skorzystać z kodu dostępnego w tym samym katalogu co tutorial.

Znalazłem nawet niemalże tłumaczenie tego tutoriala na polski. Fakt faktem nie dotyczy on najnowszej wersji, a jedynie 6.3. Kiedyś przeczytałem to całkiem dokładnie i było nie było to najgorsze tłumaczenie. Można się na nim opierać. Czasami są wywoływane w tym „tutorialu" metody, które są obecnie @deprecated, ale poza tym jest całkiem ok. Opisywane tłumaczenie jest zawarte w pracy magisterskiej Pawła Protasia pt. Pomost pomiędzy SBQL a Db4o.

Jeżeli chcielibyśmy stworzyć prostego CRUD’a z wykorzystaniem db4o i JSP polecam artykuł z 8mego numeru Java exPress  pt.: DB4O - Obiektowa baza danych. Autorem artykułu jest Paweł Cegła, który również na swoim blogu pisze o db4o.

To tyle na początek jeśli chodzi o chęć zrozumienia działania samej bazy db4o. Chcąc tworzyć już bardziej skomplikowane, wielowątkowe aplikacje, powinniśmy zapoznać się z klasą Db4oUtil. Pierwszy raz znalazłem ją na blogu Space Program we wpisie: Db4oUtil (aka. The Easiest Way to Get Started With Db4o). Kopia tej klasy (troszkę zmodyfikowana) znajduje się również na stronie db4o: Db4oUtil (aka. The Easiest Way to Get Started With Db4o). Podaje obydwa linki, gdyż jakiś czas temu strona db4o przechodziła renowacje i wówczas wiele linków nie działało.

Db4oUtil jest thread safe i proste w użyciu. Ja akurat zazwyczaj korzystam ze zmodyfikowanej przez mnie wersji tego pliku w zależności od aktualnych potrzeb projektowych. Schemat użytkowania jest podany w przytoczonych artykułach.

Mamy jeszcze do dyspozycji oczywiście dokumentację javadoc. Miejscami nie jest ona „wylewna”, ale na pewno warto ją podpiąć pod ulubione IDE. Jest jeszcze Reference Documentation (doc\reference\db4o-reference-java.pdf), ale to już jest ponad 1000 stron w pdf’ie i początkowo odradzam. Dopiero jak czegoś nie znajdziemy w tutorialu, ani w javadoc to można tego szukać w dokumentacji referencyjnej.

Na koniec chciałbym polecić narzędzie ObjectManagerEnterprise (OME). Jest to aplikacja służąca do podglądu bazy db4o (nawet jak nie wiemy jakie klasy tam siedzą). Narzędzie jest dystrybuowane razem z biblioteką db4o. Działa ono jako wtyczka do Visual Studio (w przypadku gdy korzystamy z wersji db4o dla C#) lub Eclipse (w przypadku gdy korzystamy z wersji Javowej). Jest jeszcze rozszerzenie dla Netbeans’a: db4o-netbeans, ale jest ono już nie rozwijane od 3ch lat i z nowym NB nie współpracuje (a szkoda).

OME wywodzi się bezpośrednio z projektu db4o Object Manager działającego jako aplikacja standalone. Jednak i ten projekt nie jest już rozwijany i nie wspiera nowszych wersji db4o.

Jeszcze mogę polecić własną prezentację pt.: Inicjatywa NoSQL na przykładzie db4o, którą miałem ostatnio okazję prezentować w ramach WrocJUG. Więcej o samej prezentacji w poprzednim wpisie: Wrażenia po pierwszej mojej prezentacji w ramach Wrocław Java User Group.

To chyba na tyle co mógłbym polecić na początek, jeśli ktoś chciałby się pobawić db4o. Wszelkie komentarze z interesującymi linkami na temat db4o mile widziane.

sobota, 18 grudnia 2010

Wrażenia po pierwszej mojej prezentacji w ramach Wrocław Java User Group


We wrotek (14.12.2010) miałem przyjemność prowadzić prezentację w ramach Wrocław Java User Group (WrocJUG). Było to moje pierwsze wystąpienie na tym poziomie trudności. Wielokrotnie prowadziłem prezentacje w ramach koła naukowego ISA^2 czy PWrJUG, ale na WrocJUG jest trochę inaczej. O ile studenci w miarę wierzą w to co się do nich mówi, to na WrocJUG padają już trudne pytania i byle odpowiedź jest tu niewystarczająca. Tutaj trzeba mieć większą wiedzę i mocne argumenty, aby przekonać do siebie słuchaczy.

Mój temat prezentacji to: Inicjatywa NoSQL na przykładzie db4oDb4o zajmuję się już od jakiegoś czasu, a zaczynałem od studenckiego projektu, później była magisterka i kilka małych projekcików dla własnych celów. O rozwiązaniach NoSQL miałem okazję trochę posłuchać w ramach polskich konferencji. Prezentacją chciałem trochę przybliżyć i rozpropagować te obydwie rzeczy we Wrocławiu.

Do samej prezentacji przygotowywałem się dość długi czas. Już podczas wakacji miałem pierwsze pomysły, jakie triki mogę wykorzystać w prezentacji, aby widownię trochę rozbawić i zmusić do dyskusji. Samą prelekcję musiałem trochę odwlec w czasie, gdyż chciałem się najpierw obronić, a dopiero potem przemówić na WrocJUG. Jak już zgłosiłem gotowość do prezentowania, to trzeba było jeszcze chwilę poczekać na wolną salę (spotkania nie są regularne, więc nie mamy jej na stałe zarezerwowanej).

Jak poszła prezentacja? Po prelekcji zgarnąłem kilka pozytywnych opinii, z czego się cieszę. Zależało mi na tym, aby zmusić widownię do dyskusji, co mi się udało. Padało tyle pytań, że całe wystąpienie przeciągnęło się do 2 godzin i 15 minut! Udało mi się ponadto poprowadzić prezentację na luzie i sala często się śmiała.

Czy udało mi się przekonać uczestników do korzystania z db4o? Chyba nie do końca. Jeżeli przedstawił bym produkt, który ma funkcjonalność zbliżoną do obecnych komercyjnych, relacyjnych baz danych, to wtedy może tak. Db4o jednak ma troszkę inne przeznaczenie (małe i średnie projekty, aplikacje standalone) niż duże relacyjne kombajny, przechowujące ogromne ilości danych.

Podczas prezentacji dało się odczuć, jak bardzo jesteśmy zakorzenieni w relacyjnym modelu danych i jak ciężko jest nam się odnaleźć w nowym środowisku. Znamy bardzo dobrze programowanie obiektowe, ale ciężko nam jest sobie wyobrazić, aby przechowywać dane w postaci obiektów. Bardzo też się przyzwyczailiśmy do innych możliwości jakie oferuje nam relacyjna baza danych i nie chcemy z nich tak łatwo rezygnować.

Uwagi jakie zebrałem na temat samej prezentacji:

  • Nie wszystko było czytelne na slajdach, np. czarny tekst na czerwonym tle na jednym z obrazków. Wynikało to trochę z wypalenia się lampy rzutnika. Z drugiej strony chciałem zachować kolorystyke stosowaną w dokumentacji db4o.
  • Nie zawsze udawało mi się ładnie złamać linię kodu na slajdach. No niestety miałem trochę „tasiemcowate” warunki w if-ach, a nie chciałem czcionki w kodzie pomniejszać, ze względu na pogorszenie widoczności.
  • Ładniej również kod uruchamiany można było dopracować, np. nie tworzyć metod statycznych. Wynikło to trochę z mojego lenistwa, gdyż chciałem aby wszystko co ciekawe w danym przykładzie, działo się w metodzie main(). Niektórzy jednak oceniają programistę po jego kodzie i niezaspecjalnie na tym polu wypadłem. Trzeba się poprawić na przyszłość! Na przykład zamiast pokazywać kolejne możliwości w metodzie main(), można przygotować testy uczące (chyba tak to się nazywa). Chodzi mi o testy, które piszemy dla siebie, gdy chcemy poznać działanie nowej biblioteki. W ten sposób sprawdzamy, czy dobrze zrozumieliśmy dokumentację.
  • Zamiast używać SVN’a można by kopiować odpowiednie pliki projektów z uprzednio przygotowanych katalogów. Nie chciałem tworzyć kodu na żywo, gdyż bardzo dobrze wiem, że to ciężkie zajęcie pisać kod i jednocześnie opowiadać o nim, a najczęściej i tak wychodzi, że o czymś zapominamy i nie działa. Zaczyna się wtedy desperackie poszukiwanie przyczyny, a publika się zaczyna nudzić. Dlatego postanowiłem skorzystać z SVN’a i przełączać się pomiędzy kolejnymi rewizjami kodu. Z widowni słyszałem szmery, że to fajny pomysł, ale rzeczywiście kopiowanie pliku mogło by być trochę szybsze.
  • Mało wiedziałem o komercyjnym zastosowaniu db4o i jakie sprawia problemy. No cóż nie mam komercyjnego doświadczenia z db4o, ani informacji jak to się sprawdza na produkcji.
  • Odpalanie prostych przykładów kodu nie zawsze jest potrzebne.
  • Warto zainstalować program typu ZoomIt, aby jakby coś nie było czytelne, można było powiększyć ekran.
  • Brakowało mi trochę takiej aplikacji, która wyświetlała by slajdy w trybie prezentacji. Tzn. abym na ekranie laptopa widział aktualny slajd i następny, a na rzutniku był tylko aktualny slajd wyświetlany. Z tego co mi wiadomo to pakiet MS Office i OpenOffice mają taką funkcjonalność, ale niestety one nie obsługują pdf'ów. Jakby ktoś znał taką aplikację proszę o info.

Więcej uwag nie pamiętam, jak mi się cos przypomni to dopiszę :)

sobota, 31 lipca 2010

Zdałem egzamin DB2 9 Fundamentals

Wczoraj miałem okazje aby podejść do egzaminu DB2 9 Database and Application Fundamentals. Egzamin był przygotowywany przez firmę IBM we współpracy z Politechnika Wrocławską w ramach jakiś tam praktyk studenckich. W samych praktykach nie brałem udziału, ale mogłem podejść do tego egzaminu.
Ogółem wcześniej nie zajmowałem się DB2 i nic nie wiedziałem na temat ich ścieżek egzaminacyjnych. O możliwości robienia certyfikatu dowiedziałem sie od przyjaciółki (dzięki Agata) 5 dni wcześniej. No ale skoro nic nie płace, nic nie tracę więc czemu nie? Zawieszam chwilowo pracę nad projektem zwanym magisterką i biorę sie za DB2.

Dla studentów biorących udział w DB2 Academic Associate Workshop były zorganizowane 2 wykłady i ćwiczenia laboratoryjne. Na ćwiczeniach dostawało się książkę i płytę. W książce były slajdy z wykładów przeplatane ćwiczeniami do wykonania. Na płytce był obraz VMware systemu SUSE z zainstalowaną bazą danych. Co prawda wszystkich ćwiczeń na tym obrazie nie można było wykonać (wersja czegoś tam się nie zgadzała) ale w laboratorium był dostępny właściwy obraz. Zgrałem go sobie na laptopa i mogłem się później w domu bawić. Książkę i płytkę odebrałem we wtorek i miałem do piątku czas aby się przygotować do egzaminu.

Poświęciłem trochę czasu, aby zaznajomić się z książką i zawartymi w niej ćwiczeniami. W większości przypadków wiązało się to z przepisywaniem komend i obserwowaniem rezultatów. Przez niektóre ćwiczenia się szło jak burza, a przez niektóre o trochę wolniej (z powoku konieczności przepisywania długich zapytań SQLowych).

Ciekawostką i nowością dla mnie był typ kolumny przechowujący XML'e i zapytania operujące na nich. Przydało by się lepsze wytłumaczenie co i jak gdyż jest to świeży wynalazek i puki co na studiach jeszcze o tym dokładniej nie uczą. Po za omawianą książką przyglądałem się również przykładowym pytaniom i odpowiedziom. Dało mi to dużą wiedzę i wyjaśniło pewne sprawy.

W piątek był egzamin który zdawała spora ilość studentów podzielonych na kilka tur. Po załatwieniu spraw formalnych w końcu można było przystąpić do egzaminu. Na egzamin było przeznaczone 1,5h i 60 pytań. Było to w formie testu jednokrotnego wyboru i trochę pytań się powtórzyło z tych przykładowych. Ogółem było łatwo i w porównaniu z SCJP egzamin był o 2 rzędy wielkości trudniejszy (ciekaw jestem jakiej skali do wyrażenia trudności można by tu użyć). Na egzaminie z DB2 nie było pytań gdzie w dopowiedziach trzeba wybrać czy wskazany kod jest błędny czy robi cos innego. Na SCJP nie dość że kod może być błędny to jeszcze należy wskazać czy to błąd czasu wykonania czy kompilacji - dlatego m.in. uznałem że SCJP jest o 2 rzędy trudniejszy.

Jako wynik uzyskałem 61.67% przy 60% wymaganych do zdania (dwie błędne odpowiedzi więcej i bym nie zdał). Czy jestem zadowolony z wyniku? Niespecjalnie. Po pierwsze uzyskałem niski wynik (choć biorąc pod uwagę czas który miałem na naukę to fuks że zdałem).  Dużo jest jeszcze do nauczenia jeśli rzeczywiście chciałbym korzystać z tej bazy danych w przyszłości. Po drugie niespecjalnie podoba mi się idea takich masowych egzaminów. Dla studentów początkowych lat studiów może być to fajnie (WOW patrz zdałem certyfikat…). Może to również być nowe doświadczenie taki egzamin i wielki prezent od IBM’a, że zorganizował taki egzamin za darmo. Z drugiej strony taka masówka obniża wartość takiego certyfikatu (bo go ma dużo osób i nie był specjalnie trudny) i nie czyni go takim fajnym, z którego zdania można być dumnym.

Podsumowując będzie kolejny wpis w CV, ale nie był to dla mnie tak ważny (i wartościowy) egzamin jak SCJP. Trzeba teraz trochę odpocząć i wrócić do magisterki.

środa, 7 lipca 2010

Wyciąganie informacji o schemacie bazy danych

Znalazłem w końcu trochę czasu, aby coś napisać na bloga. Ostatnio przeprowadzka trochę czasu z życia mi zabrała (koniec mieszkania w akademiku), przez co nie było jak pisać. Przygotowuję obecnie jakieś artykuły na bloga, ale będzie to kilkuczęściowa seria wpisów i chcę poczekać do jej ukończenia. Tymczasem opowiem o wydobywaniu metadanych (czy też metainformacji) z baz danych.

Czym są metadane? Są to "dane o danych". Innymi słowy są to informacje o sposobie przechowywania danych, ich strukturze itp. W przypadku baz danych chodzi tu o schemat bazy danych.

Tylko po co nam schemat bazy danych? Zazwyczaj jak tworzymy jakąś aplikację to bardzo dobrze znamy schemat bazy danych i na nim operujemy. Czasami jednak chcemy napisać narzędzie wspomagające prace z bazą danych, które będzie uniwersalne i działało niezależnie od schematu bazy. Może to być np. narzędzie do automatycznego generowania kodu klas persystętnych, na podstawie schematu bazy danych. O takim rozwiązaniu słyszałem na konferencji 4Developers podczas prezentacji Marka Berkana pt. Automatyczne generowanie kodu. Podobne rozwiązanie jak przedstawiane na prelekcji wykorzystuję obecnie w swoim pewnym projekcie.

Jako przykład bazy danych wykorzystam Oracle 10g XE. Chcąc się dowiedzieć, jakie tabele mamy zdefiniowane w bazie danych możemy wykorzystać następujące zapytanie:



Dostaniemy wówczas wszystkie tabele zdefiniowane przez zalogowanego użytkownika. Tabela USER_OBJECTS zawiera również wiele innych niekoniecznie dla nas ciekawych informacji o naszych tabelach.

Po pewnym czasie używania tego zapytania zauważyłem, że zaczęły pojawiać się w wynikach zapytania tabele o nazwie typu: BIN$m4Gt7PLlTv6r1dCsd2+ddA==$0. Próba uzyskania dostępu do takiej tabeli kończy się błędem ORA-00903: invalid table name. Skąd się więc bierze ta nazwa? A no z mechanizmu odzyskiwania usuniętych tabel. W Oracle mamy możliwość przywrócenia (przypadkiem) usuniętych tabel. Informacje o tych tabelach są również przechowywane w USER_OBJECTS, tylko że pod taką dziwaczną nazwą.

Chcąc się pozbyć usuniętych tabel z naszego zbioru wyników, możemy wykonać drugie zapytanie:



które zwróci nam nazwy tabel usuniętych. Wyniki wystarczy potem odfiltrować. Możemy to również scalić i wykonać w jednym zapytaniu:



Powyższe zapytania operowały na tabelach danego user'a. Chcąc dostać wszystkie tabele (wraz ze specjalnymi / systemowymi - nie wiem jak się je powinno nazwać) należy USER_OBJECTS zamienić na ALL_OBJECTS (lub DBA_OBJECTS) w powyższych zapytaniach. Tabela USER_OBJECTS jest widokiem tabeli ALL_OBJECTS - różni się tylko jedną kolumną.

Przygotowując ten artykuł znalazłem jeszcze inny, prostszy sposób na wydobycie nazw tabel w naszej bazie. Rozwiązanie poniżej:



To zapytanie zwraca tabele danego user'a. W wyniku zapytania nie ma już usuniętych tabel. Tutaj również mamy możliwość wyboru i zamiast USER_TABLES możemy użyć DBA_TABLES lub ALL_TABLES zależnie od naszych potrzeb.

No dobra, wiemy już jakie mamy tabele w bazie, czas na kolumny. O dostępnych kolumnach ich nazwach typach itp. możemy się dowiedzieć za pomocą:



Innym sposobem jest zapytanie:



jednak w tym przypadku nie dostajemy informacji o typie kolumny. Jeśli zależy nam na typie kolumny możemy użyć zapytania:



jednak znów dostaniemy (w gratisie) kolumny z tabel usuniętych. Wynik należało by więc odfiltrować.

Jeśli korzystamy z JDBC w naszej aplikacji mamy jeszcze inną możliwość. Wykonujemy dowolne zapytanie na interesującej nas tabeli (np. SELECT * FROM "NAZWA_TABELI") i otrzymujemy obiekt implementujący interfejs ResultSet. Udostępnia on metodę getMetaData(), która zwraca ResultSetMetaData. Wówczas nazwę kolumny możemy pobrać za pomocą:



Typ kolumny możemy pobrać za pomocą:



Metoda ta zwraca pełną nazwę klasy Javowej na którą może być zrzutowana dana kolumna. Tutaj co ciekawe, to to, że typy liczbowe, niezależnie czy zdefiniowane jako NUMBER(p, s), NUMBER(p), czy NUMBER w bazie Oracle, zawsze są rzutowane do typu java.math.BigDecimal. Jeśli chcemy rzutować do typów prymitywnych, musimy skorzystać z jednego powyższych zapytań i wydobyć dokładną precyzję liczby oraz odpowiednio zrzutować.

To tyle jeśli chodzi o wydobywanie metadanych z bazy Oracle. Jeśli znacie jeszcze inne, prostsze sposoby na wydobywanie informacji o tabelach i kolumnach z bazy danych to zachęcam do komentowania wpisu.

wtorek, 29 czerwca 2010

Nazwano mnie db4o Most Valued Professional

Dzisiaj miałem przyjemny poranek. Przeglądając pocztę natrafiłem na list, w którym napisano:
You have been selected as a
db4o Most Valued Professional (dVP) awardee for the year 2010
Oznacza to, że zostałem okrzyknięty tytułem db4o Most Valued Professional.
Skąd taka nagroda?
A no od dłuższego czasu piszę magisterkę, w której wykorzystuję obiektową bazę danych db4o. Produkt ten zaczynał jako inicjatywa open source i później został przejęty przez firmę Versant (która również posiada własną obiektową bazę danych, tyle że komercyjną). Db4o jest dalej rozwijane jako open source i jest budowana silna społeczność wokół tego projektu. W ramach podziękowania za zaangażowanie w tej społeczności (poprzez aktywność na forum, projekty powiązane z db4o, artykuły, tłumaczenia, blogi, itp.) około 60 osobom został przyznany tytuł: db4o Most Valued Professional. Jest on przyznawany na rok, i potem trzeba go ponowić. Ja dostałem go na 2010 rok.
Po za informacją na stronie dVP Directory 2010 i ewentualnym wpisem w CV przyznanie nagrody wiąże się z otrzymaniem gadżetów od db4o lub gratyfikacji pieniężnej. Czuję się zaszczycony tym wyróżnieniem i postaram się dopieścić aplikację, która przyniosła mi to wyróżnienie, najlepiej jak potrafię. Będę również dalej propagował ideę obiektowej bazy danych db4o.
Na zakończenie podkreślę, że nie wypełniałem żadnych formularzy, aby dostać to wyróżnienie, tylko poinformowałem koordynatora społeczności db4o, o moim projekcie i trochę na forum się udzieliłem. Cieszę się, że zostało to docenione i tym bardziej jest miło zaskoczony z tego.