12 lutego 2010

Boimy się nieznanego, regularny wypoczynek z pływaniem i silnie typizowane zapytania w JPA2

Najbardziej uwielbiam te momenty, w których na usta ciśnie się "Eureka!". To jest ten moment, w którym wszystko układa się w jedną całość i brak w nim niewyjaśnionych miejsc. Można wtedy wygodnie rozłożyć się w fotelu i powiedzieć sobie "Udało się!" Wtedy wiem, że wysiłek nie poszedł na marne.

Uważam, że jest wiele rzeczy, które ostatecznie składają się na ten moment wzniosłości. Sam smak zwycięstwa to za mało, aby ucieszyć ślęczącego nad tematem programistę, który tak trwa w tym stanie ciągle, przez kilka ostatnich dni i zrekompensować mu poniesione straty. Ważne, aby w tym całym szaleństwie znaleźć jeszcze umiar w dążeniu do celu i znaleźć czas na relaks i wypoczynek. Właśnie wtedy, kiedy rozwiązujemy problem najbardziej potrzeba nam wypoczynku.

Spotkałem się z dwoma podejściami do rozwiązania problemu - siłować się z nim do momentu, aż albo on, albo ja, lub też, drugie podejście, gryźć problem kawałek po kawałku, rozkładając go na części pierwsze.

Zakładając, że oba kończą się tym samym - zwycięstwem - nie mam wątpliwości, w której ja chciałbym się znaleźć. Oczywiście w tej drugiej. Ostateczne zwycięstwo będzie dodatkowo udekorowane wieńcem końca zadania i wystarczających sił na kolejne.

Takie coś przytrafiło mi się dzisiaj z rana, kiedy po śniadaniu z Agatką, zasiadłem do pewnego tematu (na razie o nim sza) i wszystko wydało się takie oczywiste. A wystarczyły regularność i spanie > 7h. Rozwiązanie samo do mnie przyszło, zamiast mnie biegającego za nim.

Najbardziej w tym wszystkim zdumiewające było to, że problem był niezwykle błahy i wyłącznie moja nieznajomość tematu robiła z niego większego potwora niż było potrzebne. "Boimy się nieznanego", jak powiadają.

I tu jest właśnie sedno sprawy - ciągłe rozwijanie swojej wiedzy, ciągłe próbowanie się z nowym. Kiedy czegoś nieznamy, kolejne nieznane może nas łatwo sfrustrować, prowadząc do błędnego wniosku, że jedyne, co potrafimy, to odkrywać nieznane. To samo w sobie może być wartościowe, ale niewielu pomyśli o tym pozytywnie. Kiedy jednak owe poznawanie wpiszemy w kontrakt naszego działania i wejdzie nam w krew, przedzieranie się przez nieznane, będzie jedynie odkrywaniem kolejnego nieznanego, co z dobrym wypoczynkiem (!) może dawać satysfakcję jego odkrycia. Idąc dalej, to nieznane może być niezwykle dochodowe (przez "dochodowe" rozumiem nową wiedzę, nowe możliwości, itp.) W końcu może się nawet okazać, że nowe dla nas jest nowym dla większości wokoło, a to stawia nas w szeregu nowicjuszy...eee, raczej...nowatorów!

Zostawiając na boku ten cały bełkot psychologiczny, pamiętajmy o wypoczynku, regularnym wypoczynku. 7h minimum i 3 x 1/2h ciągłego pływania/tydzień, to obowiązek każdego programisty. Tak sobie to dzisiaj wymyśliłem. Siedzenie nas wykańcza, a problemy technologiczne nie pomagają.

Żeby nie było, że wpis taki umoralniający, bez pierwiastka javnego, to napiszę, że właśnie z ukończeniem rozdziału 9-tego "Criteria API" książka Pro JPA 2: Mastering the Java™ Persistence API stała się dla mnie lekturą obowiązkową każdego parającego się JPA czy ORMem w Javie. Jestem na 10 rozdziale (273. strona) i z trudem idzie mi jej czytanie. Nie dlatego, że taka beznadziejna, ale dlatego, że każda strona wypełniona jest wiedzą JPA po brzegi! Rozdział 9. "Criteria API", który właśnie skończyłem zajął mi prawie 4 dni i cały jest zakreślony notatkami. W zasadzie wszystko było nowe (nie dotykałem wcześniej tematu w Hibernate) i niezwykle zapadające w pamięć swoją złożonością (w sensie pozytywnym, bo w końcu wciąż może być jeszcze trudniej, bo wciąż możemy zejść na poziom SQLa i bawić się z przenośnością aplikacji przechodząc ze środowiska lokalnego, najczęściej z jakąś wbudowaną bazą danych typu HSQL, do testowego z DB2, Oracle, MySQL, czy innym SQLowym stworzeniem).

Co mnie najbardziej zainteresowało, to budowanie zapytań SQL z mechanizmem silnie typizowanych (jak ja nie lubię tego słowa) zapytań w JPA2 (ang. strongly typed query definition) z kanonicznym metamodelem. Brzmi wyniośle, a sprowadza się do zmiany nazw pól w mapowaniu ORM (w postaci napisów) na ich silnie typizowane odpowiedniki (w postaci pól w klasie reprezentującej kanoniczny metamodel encji). Zamiast pisać ...get("ksiazka").get("tytul") można ...get(Ksiazka_.tytul). Kiedy dodam, że dostawcy JPA2 generują takie klasy kanoniczne (zwykle zakończone podkreślnikiem po nazwie encji/klasy) i przy pisaniu zapytania pomaga nam każde IDE, bez specjalnego wsparcia dla JPA2, to zysk jest niebagatelny. Można wręcz całkowicie zapomnieć o trzewiach ORMa w postaci relacyjnej bazy danych - same obiekty i silna typizacja. I znowu zaczynam biegać za nowym :) Bawił się tym już ktoś?