Pamiętacie wpis odnośnie dbconf 2015 i 69 spotkania Wrocławskiego JUG'a? Pisałem wtedy o moich wystąpieniach w ramach konferencji dla bazodanowców, jak i w ramach WrocJUG. Temat ten sam, tylko zakres trochę inny.
Dzisiaj znów o tym piszę, bo pojawiło się nagranie z dbconf, które prezentuję poniżej:
Pojawienie się tego nagrania zmotywowało mnie do umieszczenia w końcu swojego wystąpienia na ten sam temat w rozszerzonym wydaniu z WrocJUG. Jeżeli po obejrzeniu pierwszego filmu Wam mało, to możecie obejrzeć wydanie poniżej. Jakościowo jest co prawda trochę gorsze, ale tak niestety GoPro nagrywa w niedoświetlonym pomieszczeniu. Kamera jest raczej przystosowana do alpejskiego słońca, niż do ciemnego pomieszczenia. No i dźwięk gorszy z powodu obudowy. Musiałem również wyciąć kilka sekund w początkowych minutach, jak miałem problemy z mikrofonem. Mam nadzieję, że to nie wpłynie na odbiór merytoryczny.
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.
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.
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.
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ń.
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.
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.
Ostatnio, miesiąc po poprzednim wystąpieniu na WrocJUGu, miałem okazję dzielić się swoją wiedzą na temat ElasticSearch’a. Najpierw było to w ramach dbconf - konferencji dla bazodanowców, a później na swoim podwórku, czyli Wrocławskim JUG’u. Początkowo kolejność miała być inna (najpierw WrocJUG, potem dbconf), ale nie wyrobiłem się z przygotowaniem. Nie wpłynęło to jednak na jakość obydwu wystąpień.
W ramach dbconf byłem właściwie tylko na swoim wykładzie i imprezach integracyjnych, gdyż nie czuję się typowym bazodanowcem. Zresztą konferencja odbywała się w Jurze Krakowsko-Częstochowskiej, więc była okazja aby zwiedzić okolicę.
Co do samego wykładu, to poszło mi chyba całkiem dobrze. Płynnie uruchamiałem wcześniej przygotowane przykłady i było trochę pytań z sali. Końcówkę musiałem jednak już gnać i pominąć parę szczegółów, bo niestety sztywne ramy czasowe nie pozwoliły mi na przekazanie wszystkiego. Po prezentacji było trochę pytań, na które już odpowiadałem po za salą.
Z całego pośpiechu zapomniałem zabrać zasilacza, ale na szczęście organizatorzy mi go odesłali, więc mogłem kilka dni później poprowadzić ten sam temat we Wrocławiu.
W ramach JUG’a pierwszy raz spotkaliśmy się w nowym miejscu tj. w Sanatorium Kultury na rynku. Bardzo fajne miejsce, ze sceną jak w teatrze i klimatycznym oświetleniem. Było trochę problemów z mikrofonem, ale jak już wymienili baterię, to działało.
Na spotkanie była chętna ponad setka ludzi, ale na sali była już tylko połowa z tego.
Na szczęście nie ograniczał mnie czas i cała prezentacja zajęła mi 2 godziny! Było sporo pytań z publiczności, zwłaszcza od Kamila i jeszcze jednej osoby, która wcześniej pracowała sporo z Apache Solr. Nie na wszystkie umiałem odpowiedzieć, bo nie jestem specjalistą w temacie i nie spotkałem się z niektórymi omawianymi przypadkami.
Udało mi się na szczęście zebrać trochę feedbacku, tego dobrego i złego, więc uważam, że warto go tutaj zapisać, aby za jakiś czas zrobić sobie retrospekcję i sprawdzić czy się coś poprawiło. Dziękuję wszystkim dzielącym się ze mną swoją opinią!
Uwagi:
“Podczas przełączania slajdów machałeś ręką, jakbyś chciał rapować” - fakt, widać to na nagraniu, do poprawki.
“Warto by mieć ciągle agendę gdzieś z boku, bo często pytania wybiegały mocno w przód (dotyczyły tematu który nie był jeszcze omawiany)” - choć nie spotkałem się z takim podejściem na konferencjach, ale to może mogę być pierwszy ;) Rzeczywiście można wywiesić agendę gdzieś z boku i wtedy osoby zadające pytanie mogą 2 razy się zastanowić, czy to aby na pewno jest dobry moment na dane zapytanie. Można jeszcze wydrukować kartki z agendą i umieścić na siedzeniach jak w teatrze lub operze, ale to jeszcze wyższy poziom ;)
“Dużo pytań o specyficzne tematy, których ktoś kto pierwszy raz spotyka się z narzędziem i tak nie zapamięta” - to fakt. Było sporo szczegółowych pytań, których osoby początkujące i tak nie zapamiętają. Z drugiej strony osoby zaawansowane też chcą coś wynieść z prezentacji, więc wypada odpowiedzieć. Ja się cieszę, że czasem była zażarta dyskusja, bo sam się przez to czegoś dowiedziałem. Fajne jest również to, że uczestnicy odpowiadają sobie nawzajem. Z drugiej strony liczne pytania trochę zaburzają tok prezentacji. Ciężko tutaj znaleźć złoty środek:/ Może powinienem rzadziej pytać, czy są jakieś pytania?
“Zabrakło przykładów z poziomu Javy” - no fakt skupiłem się na zapytaniach RESTJSON’owych, a zapomniałem, że jesteśmy na Java User Group. Dobra uwaga, powinno być więcej kodu z Javie. Chyba coś muszę dodać w kolejnej wersji (jeśli będzie kolejna wersja).
“Lepiej niż miesiąc wcześniej, gdzie puszczałeś wcześniej nagrany film” - tak, tym razem były przygotowane przykłady, które odpalałem na żywo. W prezentacji o Liquibasie bardzo dużo mogło pójść nie tak, więc lepiej było nagrać krótki filmik. Jest więc jakiś postęp.
“Widownia mogłaby bardziej uczestniczyć w tworzeniu przykładów” - mogłem pytać się np. jaki film utworzyć w indeksie, co poszukać itp. Do poprawki.
“Przydałyby się jeszcze jakieś fajerwerki. Nawet najlepsza prezentacja jeśli trwa długo, potrzebuje przerywnika” - był żart o masturbacji… Ale fakt zapomniałem o zasadzie, która kiedyś była dla mnie bardzo ważna, aby był jakiś śmieszny przerywnik w trakcie. Zwłaszcza, że prezentacja zajęła mi 2 godziny. Nie wiedziałem wcześniej, że może mi to tyle zająć.
“Sekcja "teoretyczna" powinna zostać lepiej omówiona” - nie wiem co miałbym jeszcze omawiać w kwestii teoretycznej… postawiłem bardziej na praktykę.
“Wymowa: "bede", "must", "fuzzy", "schema” i język potoczny: "klepał w klawiaturę", “mianowicie” - chyba trochę za dużo oglądania Pana Wiesława Wszywki. Nad wymową niektórych słów muszę trochę popracować, ale języka potocznego nie zmienię - innym osobom luźny styl prowadzenia prezentacji się podobał (wliczając w to mnie), więc tak już zostanie. Nie chcę gadać jak nudny wykładowca.
“Próby kodowania na żywo kiepsko wychodzą” - fakt chciałem coś tam małego zakodować w trakcie - pod wpływem pytania z publiczności - i były z tym pewne problemy. Podpowiadania składni brak, nie robiłem tego wcześniej, po za tym inne obszary mózgu są odpowiedzialne za mówienie i za pisanie - nie jestem w stanie robić tego równocześnie.
Była jeszcze masa pozytywnych komentarzy. Większości bardziej się podobało niż nie podobało. Nie będę jednak przytaczał tych pozytywnych komentarzy.
A już za niecały miesiąc, 33 degree 4 charity zawita do Wrocławia. Będę tam mówił o Liquibase, czyli mój temat z 67 spotkania WrocJUG. Trzeba będzie go trochę zmodyfikować, aby zmieścić się w wyznaczonym czasie. I będę mógł zobaczyć swoją prezentację na dużym ekranie :) Już dzisiaj wszystkich serdecznie zapraszam!
Poniżej slajdy dla zainteresowanych odnośnie ElasticSearch’a:
Ostatnio miałem przyjemność poprowadzić 67 spotkanieWrocł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:
za zapewnienie żłocistego napoju chłodzącego dla uczestników.
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
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.
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.
W systemie Android domyślnie mamy dostęp do relacyjnej bazy danych SQLite w której możemy zapisywać informacje z naszej aplikacji. Jest to typowy sposób dostępu do danych w tym systemie. Nie jest dziwne, że do tego systemu została wybrana ta baza. Nie posiada ona wielu magicznych dodatków (jak obecnie popularne kombajny) i założenia jest „Lite” (przynajmniej z nazwy). Z innej strony jest to baza o ciekawym stosunku kodu źródłowego do testów. Odsyłam do artykułu: Extremalne testowanie w SQLitePawła Lipińskiego. Jak skorzystać z tej bazy jest już opisane na blogu Mirosława Stanka (część 1, część 2, część 3) jak i na helloandroid. Ja nie będę po raz kolejny opisywał tego rozwiązania, ale postaram się poniżej pokazać inne (ciekawsze?) podejście do tematu, z wykorzystaniem obiektowej bazy danych.
DataBase For Objects, zwana powszechnie db4o, to interesująca alternatywa dla SQLite w systemie Android, jeśli chodzi o składowanie danych. Od wersji 7.5 biblioteka daje wsparcie dla tej platformy. Poniżej przedstawię jak zbudować projekt w NetBeans’ie 6.9 z wykorzystaniem tej biblioteki.
Tworzymy w NetBeans’ie nowy projekt typu AndroidApplication. Następnie do bibliotek dodajemy JAR’a zawierającego db4o.
Następnie warto skorzystać z klasy Db4oHelper przedstawionej przez Damasia Maneiro (niestety nie mam pojęcia jak to po polsku odmienić) w artykule na dzone.com: Using db4o in an Android application. Jest tam sporo kodu odwołującego się do klas z tamtejszego projektu, więc pozwoliłem sobie trochę ten kod zmienić do naszych potrzeb. Listing poniżej.
Mamy do dyspozycji publiczny konstruktor, który jako argument przyjmuje Context – podobnie jak w SQLite. Potrzebne nam to będzie do umieszczenia pliku z bazą danych w miejscu, gdzie znajdują się dane aplikacji. Następnie mamy metodę db(), która zwraca nam instancję klasy odpowiedzialnej za połączenie z bazą. Mamy jeszcze metodę zwracającą nam konfigurację bazy (domyślna nam początkowo wystarczy) i ścieżkę do pliku z bazą. Na koniec metoda do zamknięcia połączenia z bazą.
Teraz można już napisać klasy, które chcemy składować w bazie danych. Mamy kilka możliwości jak to zrobić. Ja poniżej przedstawię prosty obiekt POJO i odpowiadającą mu klasę DAO. Można oczywiście to wszystko w jedną klasę wrzucić, ale tak będzie ładniej i poprawniej. Poniżej przykładowy kod klasy User.
public class User {
private String login;
private String password;
public User(String login, String password) {
this.login = login;
this.password = password;
}
public String getLogin() {
return login;
}
public void setLogin(String login) {
this.login = login;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}
W klasie są definiowane 2 pola typu String o nazwach login i password oraz odpowiadające im gettery i settery. No i jeszcze konstruktor przyjmujący te parametry. Jeśli ktoś woli programować w stylu funkcyjnym, to można zrobić pola final i wyrzucić settery. Db4o i tak zadziała, gdyż do ustawiania wartości wykorzystuje refleksje do pól składowych, a nie do setterów.
Proszę zwrócić uwagę, że klasa nie posiada żadnego pola w stylu ID. Dodawanie do klas persystentnych identyfikatorów, to niemalże konieczność w świecie relacyjnym, gdyż dzięki identyfikatorom tworzy się relacje i złączenia przy zapytaniach. W bazach obiektowych tego nie potrzebujemy! Mamy przecież referencje i kolekcje.
Poniżej kod klasy DAO dla klasy User:
public class UserDao {
private ObjectContainer db;
public UserDao(Context context) {
Db4oHelper db4oHelper = new Db4oHelper(context);
this.db = db4oHelper.db();
}
public void saveOrUpdate(User user) {
db.store(user);
}
public void delete(User user) {
db.delete(user);
}
public List<User> getAll() {
return db.query(User.class);
}
public List<User> getByLogin(String login) {
User example = new User(login, null);
return db.queryByExample(example);
}
public List<User> getByLoginAndPassword(
String login, String password) {
User example = new User(login, password);
return db.queryByExample(example);
}
}
Klasa posiada konstruktor, za pomocą którego do klasy przekazujemy obiekt typu Context. Jest to klasa android’owa, za pomocą której Db4oHelper może się dostać do odpowiedniego miejsca na zapisanie pliku z bazą. Następnie pobieramy i zapamiętujemy obiekt typu ObjectContainer pochodzący z biblioteki db4o i za jego pomocą odbywa się dostęp do danych. Dalej mamy operacje tworzenia, modyfikacji, usuwania i pobierania wszystkich obiektów - nic specjalnego, ot proste wywołanie pojedynczych metod.
Trochę (ale tylko troszkę) ciekawsza jest metoda getByLogin(), która korzysta z query by example. W skrócie, ta metoda wykonywania zapytań, polega na utworzeniu najpierw obiektu, który będzie przykładem, a następnie wywołaniu odpowiedniej metody zwracającej wszystko, co do danego wzrorca pasuje. Domyślne wartości pól klasy są dopasowywane dowolnie, a te zmodyfikowane dokładnie. W tym przypadku zostaną zwrócone obiekty posiadające ustawione pole login na takie samo jak przekazane w argumencie metody. No prościej się chyba nie da. Istnieją w db4o jeszcze inne bardziej wyrafinowane metody zapytań, ale to nie temat na ten wpis.
Ludzie doświadczeniem z dużymi systemami i relacyjnymi bazami danych, widząc powyższy kod, zaraz zaczną krzyczeć: „a co z dostępem równoległym?”, „a gdzie początek i koniec transakcji?”, itd. Otóż w ogólności db4o wspiera ACID, a poziom izolacji transakcji ma ustawiony na Read Committed. Pytanie z mojej strony: czy rzeczywiście wszędzie tego potrzebujemy? Z tego, co mi wiadomo, to zdarzenia z aktywności w Androidzie są obsługiwane synchronicznie, tzn. w tym samym wątku co GUI. Jeśli nie tworzymy dodatkowych wątków do obsługi zdarzeń (ze względu na ich banalność i szybkość), to nie potrzebujemy transakcji.
Dobra, to teraz by się przydało jakieś GUI dorobić, aby można było zobaczyć jakiekolwiek efekty działania. Po uruchomieniu aplikacji będą się pojawiać dwa przyciski: Create New User i Login. Te będą kierować już do następnych ekranów. Tam będzie można utworzyć nowego użytkownika (i oczywiście go zapisać w bazie), albo się zalogować do aplikacji (na podstawie loginu i hasła zapisanego w bazie). Nie pokazuję tutaj jak utworzyć GUI, gdyż nie jest to tematem tego artykułu. Całkowity kod zamieszczam na końcu wpisu.
Przy pierwszej próbie uruchomienia tak skonstruowanej aplikacji dostaniemy błąd. Jeżeli nie zepsuliśmy niczego po drodze to problem jest jasny. Samo dołączenie biblioteki db4o do projektu nie spowoduje jej dołączenia w trakcie budowy projektu. Należy jeszcze dodać do build.xml następujący target (lub podobny):
Uważam, że środowisko programistyczne powinno być na tyle inteligentne, aby się troszczyło za nas takimi detalami. No ale cóż, nie można mieć wszystkiego. Teraz już powinno pójść gładko i jeśli nic nie popsuliśmy w XML’ach to powinniśmy zobaczyć naszą aplikację. Przykładowe screeny poniżej:
Pod koniec chcę zaznaczyć, ze NetBeans 6.9 nie jest idealnym środowiskiem do pisania aplikacji androidowych (może trzeba jeszcze poczekać?). W trakcie pracy nad projektem natrafiłem na sporo utrudnień. Przykładowo, podczas refaktoringu, po przeniesieniu klasy aktywności, aplikacja przestawała działać. Trzeba było wówczas w AndroidManifest.xml trochę pogrzebać i poprawić nazwy klas. Również zmiana nazwy pakietu wymuszała dodatkowe grzebanie w project.properties.
Z ciekawości sprawdziłem jeszcze jak sobie ze wsparciem Androida radzi IntelliJ IDEA (tak w końcu ją zainstalowałem :) ). Tutaj przeniesienie klasy do innego pakietu nie stanowi problemu. Podobnie z dodaniem biblioteki db4o do projektu. Co do zmiany nazwy pakietu to napiszę o tym w następnym poście (aby wszystko na raz nie było w jednym). Dodatkowo Idea od razu pokazuje Log konsolę z Androida. Chcą ją aktywować w NetBeans'ie trzeba kliknąć: Window -> Output -> ADB Log.
Jeszcze w między czasie tworzenia tego wpisu (nie powstał on w jeden dzień) pojawił się NetBeans 7.0. Tam jednak nawet nie mogłem dodać żadnej zewnętrznej biblioteki do projektu android'owego, więc ewentualna migracja do nowego środowiska musi poczekać.
//Update (25.09.2011)
Jak słusznie zauważył mój przyjaciel Michał, skoro otwieramy połączenie do bazy danych, to musimy je również zamknąć. Można to zrobić w MainActivity.java w przeciążając metodę onDestroy():
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:
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.
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.
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.
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 db4o. Db4o 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ę :)
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.
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.
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.
