28 lutego 2010

Recenzja "Pro JPA 2: Mastering the Java Persistence API" - obowiązkowa lektura dla zainteresowanych JPA 2.0

0 komentarzy
Pro JPA 2: Mastering the Java Persistence APIO mojej lekturze książki Pro JPA 2: Mastering the Java Persistence API panów Mike Keith i Merrick Schincariol (wydawnictwo Apress, grudzień 2009) pisałem już kilkakrotnie (patrz Z Pro JPA 2: zapytania natywne w SQL vs JP QL i peany nt. WAS V7, Boimy się nieznanego, regularny wypoczynek z pływaniem i silnie typizowane zapytania w JPA2 czy Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2).

Możnaby powiedzieć, że wiele już o tej książce napisano (na Amazonie jest już 5 recenzji tej książki), ale co mnie niezwykle zaskoczyło to fakt, że to, co ja uważam za plus, inni uważają za minus i odwrotnie. Niby nic dziwnego, ale jak tu wybrać kolejną książkę technologiczną do czytania, kiedy Ci, którzy zdecydowali się na jej kupno są równie zachwyceni, co rozczarowani, a Ci, którzy nie kupili, stracili możliwość kreowania własnego poglądu na sprawę samodzielnie, bo akurat negatywna recenzja książki przypadła im bardziej do gustu. Co zrobić? Całkowicie zaniechać czytania recenzji nie polecam i zachęcam do większego samozaparcia, bo akurat w tym przypadku warto skusić się na tę 500-stronicową cegłę. Dla mnie miała wszystko, czego oczekiwałbym od książki tego pokroju - dokładnego opisu JPA 1.0 i wejścia w temat JPA 2.0. Skoro jest częścią Java EE spodziewałem się również, że będzie wiele o powiązaniach między nimi i tak też było. Znalazłem to, czego chciałem, a nawet więcej.

Nie będę ukrywał, że jednocześnie książka mnie niezwykle zmęczyła i pozwolę sobie na lekturę kolejnej książki...nietechnicznej celem odświeżenia umysłu. Trochę gimnastyki w dziedzinie bardziej efektywnego (i efektownego) zarządzania zadaniami dobrze mi zrobi. Zdecydowanie warto czytać książki, a Pro JPA 2: Mastering the Java Persistence API przybliża zmiany w obszarze JPA 2.0 znakomicie. Pewnie możnaby lepiej, ale 500 stron daje wyobrażenie o wysiłku autorów w wytłumaczeniu niuansów tej specyfikacji (a i tak zawarto w niej jedynie wycinki kodów).

Zainteresowanych moją, angielską recenzją książki zapraszam do lektury Book review: Pro JPA 2: Mastering the Java Persistence API (język podyktowany programem wydawnictw anglojęzycznych "Książka za recenzję").

Książka dostępna jest w Bibliotece Warszawskiego JUGa i czeka na kolejnego zainteresowanego jej lekturą i poznaniem tajników specyfikacji JPA 2.0.

25 lutego 2010

"Prezentacyjna" dyktatura Tomka z Mule ESB na 62. spotkaniu WJUGa - normalnie Git!

8 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG)Niezwykłem komentować wydarzeń ze spotkań Warszawa JUG, ale ostatnie, 62. spotkanie było prawdziwym kilerem wśród WJUGowych prezentacji i wyróżniało się pośród dotychczasowych spotkań! Po prostu nie mógłbym tego nie skomentować. Technologiczne cudo!

Na WJUGowej scenie wystąpił Tomasz Nurkiewicz z Mule ESB i nie byłoby może w tym wielkiego wydarzenia, bo temat ciekawy, jak wiele innych, ale sposób, w jaki przyszło nam oglądać występy sceniczne Tomka przyprawił niejednego o lekką palpitację serca...z wrażenia, że można tak składnie poprowadzić temat (przede mną siedzieli Mateusz Z. i Jacek K., i co rusz potakiwali głową na moje ochy i echy :)). Jestem pełen podziwu dla warsztatu prezenterskiego Tomka, w którym miejsce znalazły - doskonałe przygotowanie merytoryczne (słuchało się z zapartym tchem) i dobrze dobrane narzędzia - IntelliJ IDEA, mnóstwo uruchomionych wcześniej serwerów - James (SMTP/POP3), JBoss AS (kolejki JMS z ActiveMQ i jego wyśmienitą konsolą webową) i serwer FTP - pewnie FileZilla - oraz Git. I było faktycznie Git! Kiedy zobaczyłem, jak można połączyć prezentację kodu źródłowego w trakcie tworzenia oprogramowania na żywo z odtwarzaniem zmian z lokalnego repo Gita (git co -f [tag]) bez straty czasu na przeklejanie ze schowka czy przeklepywanie z kartki, o mało nie spadłem z krzesła. Najbardziej nie mogłem zrozumieć, jak można się tak dobrze przygotować do prezentacji, aby idealnie wpasować się w kolejne numery tagów w repo. Zrozumiałbym, gdyby poszło v1, v2, v4, v6, ale v1, v2, v3, v4, aż do bodajżę v12 przeszło moje najśmielsze oczekiwania. Możnaby powiedzieć, że prezentacja w dużej mierze składała się z kodowania, albo nawet możnaby to nazwać gitokodowaniem, w którym część programowania zrzucono na barki odtwarzania odpowiedniego taga z repo Gita. Bajecznie!

Nie byłbym sobą, gdyby nie udało mi się wyłapać kilku niedoskonałości w wystąpieniu Tomka, a odważyłem się na ich publikację na blogu, bo są one tak niewinne, że wręcz śmiesznie nazywać je "niedokonałościami". Na pewno zabrakło przejścia przez slajdy. Było ich zbyt mało, abym uwierzył, że wszyscy zrozumieli sens tych inboundów, outboundów, trasformersów, ruterów, komponentów i co tam jeszcze w Mule można znaleźć. I nie ma co marzyć, aby tak było, nawet ze slajdami, ale przynajmniej mi brakowało ich, aby ułożyć sobie wiedzę, zobrazować ją. Na pierwszym slajdzie, gdzie pojawiła się architektura Mule ESB było za mało kolorowo i trochę niewidocznie (nie narzekam na wzrok, a siedząc w trzecim rzędzie miałem już problemy z odczytaniem, co na nim było - obstawiam, że za mną już nic nie było widać). Kiedy przeszliśmy pobieżnie przez pozostałe slajdy widać było, że były i kolorowe, i wyraźniejsze. Szkoda, że nie było nam dane ich zobaczyć.

Drugim elementem było zbyt intensywne skakanie po kodzie, otwartych konsolach serwerów, przeglądarce i tak w kółko. Dawałem radę, ale wymagało to ode mnie dużego skupienia i nie było nawet mowy o...układaniu pytań (!) Albo temat był doskonale przedstawiony przez Tomka, albo sala oniemiała z wrażenia i pytań było niewiele. Zabrakło mi tego, bo mogłoby mi uporządkować wiedzę.

Kolejnym zaskoczeniem dla mnie była zbieżność nomenklatury między Mule ESB a SCA. W sumie chodzi o to samo - mediację i na wejściu (usługi) czy wyjściu (referencje) musi być możliwość dogadania się z nadającym lub odbierającym. W Mule ESB na wejściu mówimy o Inbound'zie, a w SCA mamy usługę z odpowiednim binding, który wyznacza protokół. Na wyjściu, w Mule ESB, mówimy o Outbound'zie, a w SCA o referencji z binding, ponownie. Naturalnie, że chciałoby się, aby określenie protokołu wejściowego i wyjściowego było deklaratywne. I tak mamy w SCA (jeśli istnieje odpowiedni binding), ale i w Mule ESB, przy odpowiednim transformer'ze. Trochę za wiele było dla mnie XMLa i zdecydowanie brakowało narzędzia typu IDE, które konfigurację transformacji dla Mule przygotował wizualnie (zamiast zmuszać mnie do zejścia na poziom XMLa).

Odświeżające było również zobaczyć, kiedy strona HTML nie była udostępniana przez serwer, ale po prostu uruchomiona w przeglądarce i dopiero zatwierdzenie formularza słało dane do serwera - do Mule ESB. Niby nic odkrywczego, jak tak piszę o tym, ale wiedzieć a stosować, to dwie różne sprawy.

I te uruchomione serwery - James, JBoss z ApacheMQ, serwer FTP i Mule ESB. Transportowy mix. Ostatnio potrzebowałem obsługi protokołu SMTP/POP3 i jakoś nie wpadłem, aby uruchomić James. Zachodzę w głowę, aby znaleźć odpowiedź dlaczego. Widać za mało chciałem i trzeba mi było pojawić się na występie Tomka. Nauka od lepszych mobilizuje do pracy!

Podsumowując, przed moimi występami w Krakowie i Poznaniu muszę:

* przygotować wszelkie przykłady aplikacyjne w lokalnym repo - git lub hg
* zaprezentować działający przykład po pierwszym slajdzie wprowadzającym
* omówić aplikację slajdami
* (kiedy starczy czasu) rozpocząć tworzenie aplikacji od zera, ale bez zbędnej pisaniny - git co -f [tag] zrobi swoje!
* pamiętać o pytaniach do publiki (jak to miało miejsce podczas spotkania z Kirkiem)
* wrócić do slajdu początkowego z architekturą aplikacji

Do poznania (ale w sensie nauki, a nie wyjazdu na konferencję - zbieżność z Poznaniem przypadkowa :)):

* Mule ESB - pojawiły się książki nt. temat, więc będzie co i dlaczego czytać
* Apache CXF - książka o nim już u mnie leży, więc tym bardziej nie mogę się jej doczekać

A jak Wam podobała się prezentacja? Nagranie z niej już wkrótce w Sieci.

p.s. Poza Tomkiem, wystąpił również Łukasz Dywicki, ale nie dane mi było wysłuchać go, poza 1. slajd z mnóstwem wersji i softu, więc korzystam z...prawa do milczenia.

23 lutego 2010

Nowy serial "SCA praktycznie" - Zestawienie środowiska z Apache Tuscany i Eclipse IAM

3 komentarzy
Apache TuscanyPisałem o SCA wielokrotnie - cała masa wpisów w kategorii sca, więc przed zbliżającymi się konferencjami - Studenckim Festiwalu Informatycznym (SFI) 11-13. marca w Krakowie oraz 4Developers 26. marca w Poznaniu, ze mną w roli prelegenta o SCA, wystarczyło jedynie (?) odświeżyć sobie wiedzę nt. Apache Tuscany i zmian w nim.

Pomysł narodził się, kiedy w trakcie pisania redbooka (książki o technologiach IBM) dotyczącym IBM WebSphere Application Server V7 Feature Pack for Service Component Architecture (w skrócie SCA FeP) dostałem jednocześnie zaproszenie na obie konferencje. Mając głowę w SCA nie miałem wątpliwości, o czym chciałbym powiedzieć. Jest wiele tematów, które nazwałbym bardziej chwytliwymi i właśnie to był główny powód, dla którego postawiłem na SCA - niewielkie jego użycie w naszych rozwiazaniach. A może okazać się, że niepotrzebnie. Nadchodzą cieplejsze dni - wiosna, a po niej lato (nic odkrywczego), więc niejednemu marzy się większa aktywność poza komputerem. Gdyby tak móc zrzucić część naszych obowiązków na barki kogoś innego?! Albo jeszcze lepiej, gdyby tak coś, a nie ktoś, zrobił za nas większość roboty, na pewno byłoby więcej czasu (który i tak wielu zmarnowałoby na pierdoły w Sieci - biedaczyska :)).

W tym klimacie, pomyślałem sobie, że ja (ów ktoś z poprzedniego akapitu) i SCA (owe coś) damy Wam szansę z artykułem Service Component Architecture (SCA) praktycznie - zestawienie środowiska z Apache Tuscany i Eclipse IAM, z serii "SCA Praktycznie". Nigdy nie zgłębiałem protokołu Atom i nie sądziłem, że kiedykolwiek będę, a tu proszę, wystarczyło kilka pytań przy Redbooku, abym zechciał sprawdzić to w Apache Tuscany - darmowego kontenera SCA. Jeśli dodam, że z nim i binding.atom, możemy praktycznie poznać podejście REST, to nie mam złudzeń, że tyle akronimów wystarczy, aby skłonić Was do lektury. Zajmie niespełna kwadrans, a może zaoszczędzić całe godziny. Chętnie posłucham, czy faktycznie. Komentarze mile widziane - priv, albo do tego wpisu.

p.s. A czy Ty już oddałeś/-aś swój głos na Notatnik w konkursie Bloger 2009 Roku? Ja też lubię prezenty. ;-)

21 lutego 2010

Eclipse pomocny przy NPE w AtomBindingListenerServlet.doPost() z Apache Tuscany

0 komentarzy
Siedzę przy Service Component Architecture (SCA) z Apache Tuscany i nie pamiętam już, dlaczego wybrałem na rozpoznanie binding.atom. Nie ma to znaczenia, ani nie ma znaczenia, czym jest SCA i owe (magiczne) binding.atom. Przeczytacie w nadchodzącym artykule, a niektórzy usłyszą na nadchodzących konferencjach - Studenckim Festiwalu Informatycznym (SFI) 11-13. marca w Krakowie oraz 4Developers 26. marca w Poznaniu, na których będę prezentował tę technologię (i liczę na Wasz aktywny udział).

Tym razem przyszło mi rozwiązać problem z NPE w Tuscany. Zaczęło się stworzeniem odpowiednich (tak przynajmniej sądziłem początkowo) klas i podczas uruchomienia wciąż tylko:
java.lang.NullPointerException
at org.apache.tuscany.sca.binding.atom.provider.AtomBindingListenerServlet.doPost(AtomBindingListenerServlet.java:590)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at org.apache.tuscany.sca.core.work.Work.run(Work.java:63)
at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java:215)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)
Pracuję z Tuscany 1.6, którego źródeł nie ma w repozytorium mavenowym, a wtyczka Eclipse IAM uparcie przy swoim "Nie ma mowy o podłączeniu źródeł do zależności mavenowych!".

Eclipse IAM - Java Source AttachmentKoniecznie potrzebowałem podpiąć źródła modułu tuscany-binding-atom-abdera-1.6.jar, aby namierzyć przyczynę NPE. Mogłem ręcznie, i tak faktycznie początkowo zrobiłem, ale po kwadransie zarzuciłem to, bo nie tylko, że zaczęło zajmować zbyt wiele czasu, ale i zażyczyłem sobie przejrzenie struktur i ich danych na żywo.

Pamiętam, że miałem podobne "chciejstwo" w IDEA i chyba NetBeans, i nie poszło mi z jego realizacją tak prosto, jak w Eclipse. Wystarczyło podpiąć źródła do projektu przez Build Path > Link Source...

Eclipse - Build Path | Link Source..., aby związać zewnętrzny katalog ze źródłami z projektem...

i w końcu uruchomić projekt w trybie śledzenia (ang. debug).

Eclipse - DebugNie długo trwało, abym się przekonał, że obsługa protokołu Atom przez binding.atom w Tuscany (oparta na Apache Abdera) wymaga właściwego komunikatu przy POST, ale to już historia na inną okazję.

Najważniejsze, że użyte narzędzie - Eclipse IDE - pozwoliło mi na namierzenie i rozwiązanie problemu w kilka chwil, bez znajomości niuansów Atoma. Nie obyło się bez ich poznania, ale to było przy okazji i wchodziło samo do głowy, z nieukrywaną przyjemnością.

Jeszcze tylko zgłosić kilka problemów w JIRA dla Apache Tuscany, aby inni nie musieli przechodzić przez to samo ponownie.

19 lutego 2010

62. spotkanie Warszawa JUG - Tomasz Nurkiewicz i Łukasz Dywicki z "Mule ESB vs. Apache ServiceMix"

2 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG)Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 62. spotkanie, które odbędzie się we wtorek, 23. lutego o godzinie 18:00 w sali 5440 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Temat: Mule ESB vs. Apache ServiceMix
Prelegenci: Tomasz Nurkiewicz, Łukasz Dywicki

W trakcie prezentacji Tomasz i Łukasz stworzą działający system, integrujący różne aplikacje przy użyciu technologii takich jak JMS, WS, HTTP, JDBC, ale też poczciwej poczty elektronicznej, FTP czy... współdzielonych plików Excel. Ich celem jest oprogramowanie od zera pełnego procesu biznesowego, wykorzystującego komunikację synchroniczną i asynchroniczną z systemami zewnętrznymi. Ponadto, poruszą fundamentalne cechy ESB, takie jak transformacje, filtrowanie i routowanie komunikatów.

Atrakcją wieczoru będzie integracja przykładowego systemu jednocześnie przy użyciu Mule ESB (Tomek) i Apache ServiceMix (Łukasz). Nie spodziewajcie się wskazania tego najlepszego, ale demonstracji różnic praktycznie, aby umożliwić każdemu słuchaczowi podjęcie decyzji o wyborze samodzielnie.

Gościem specjalnym będzie Gregory Brackett, dyrektor sprzedaży MuleSoft na terenie Europy. Zainteresowani komercyjnym wsparciem i dodatkowymi funkcjami Mule ESB Enterprise będą mieli niepowtarzalną okazję porozmawiać z nim bezpośrednio.

Łukasz Dywicki jest założycielem firmy Code-House. Zawodowy programista od 2005 roku. Programowaniem w Javie zajmuje się od 3 lat. W 2008 roku pracował jako główny programista przy budowaniu magistrali usług w oparciu o Apache ServiceMix w jednym z polskich banków.

Tomasz Nurkiewicz jest absolwentem Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Programista Java EE od 3 lat, obecnie w JAVART. Posiada certyfikaty SCJP, SCJD, SCWCD i SCBCD. W wolnych chwilach pisuje artykuły na swojego bloga: http://nurkiewicz.blogspot.com.

Planowany czas prezentacji to 1,5h, po której planuje się 15-30-minutową dyskusję.

Wstęp wolny

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

16 lutego 2010

Z Pro JPA 2: zapytania natywne w SQL vs JP QL i peany nt. WAS V7

7 komentarzy
Lektura książki Pro JPA 2: Mastering the Java Persistence API z Apress trwa i nie przestaje mnie zdumiewać. Może nawet nie chodzi o nią samą, ale o to, co ma JPA2, co sprawia, że to właśnie sama specyfikacja mnie tak zdumiewa. Niektóre rzeczy były już w JPA1, więc tym bardziej lektura Pro JPA2 sprawia mi tyle przyjemności, bo co strona, to coś nowego. Pisałem, że mam w zwyczaju oznaczać sekcje książki do dogłębniejszego zbadania i kiedy zwykle w książkach jest kilka akapitów per rozdział, tak w Pro JPA2 są to prawie całe strony (!) "Prawie robi różnicę", ale jak by tego nie wartościować, materiału do przetrawienia jest cała masa.

Kiedy to piszę, zaczynam zastanawiać się, czy mógłbym tę książkę polecić adeptom JPA. Książka zakwalifikowana jest dla średniozaawansowanych - User level: Intermediate. Z jednej strony jest w niej wszystko, co poleciłbym początkującym, ale z drugiej jest tego tyle, że czytanie specyfikacji byłoby łatwiejsze - nie ma tam tylu dywagacji. Owe dywagacje sprawiają, że książka należy do obowiązkowych lektur każdego programisty JEE i nie ma co jej porównywać ze specyfikacją, ale jeśli mi rozdział (około 30-40 stron) zajmuje 3-4 dni, aby całość przetrawić, to jak tu polecić ją początkującym?! Serca nie mam?!

Jestem przy rozdziale 11. "Advanced Topics" (strona 333) i mam wrażenie, że czytam ją całe wieki. Z jednej strony, ciągnie mnie do niej, aby poznać więcej, z drugiej zaczynam powątpiewać w sens tak kurczowego się jej trzymania i dobrnięcia do końca. Nie będę ukrywał, że mnie trochę zmęczyła. Coś mi mówi, że gdyby była podzielona na dwie części, byłoby ją przyjemniej czytać. Przypomina mi "Wprowadzenie do algorytmów" Cormena i in., gdzie można znaleźć wszystko o algorytmach i faktycznie poleca się ją początkującym, ale przebrnięcie przez nią zabiera wieki. Fajnie, że można wszystko znaleźć w jednym miejscu, ale nawet najbardziej wytrwali padają w połowie i tylko zdrowy rozsądek podpowiada, że po zakończeniu satysfakcja gwarantowana. Wiedzy po pachy i aż by się chciało przeskoczyć kilka stron, aby mieć to za sobą.

Możnaby zapytać, czy warto tak się katować czytaniem, skoro czytanie powinno sprawiać przyjemność, a z moich słów można wyczytać ból i cierpienie. Możnaby to porównać do wyjścia na siłownię, bieżnię, wiosła, basen w wydaniu zaawansowanym. Wiemy, że będzie bolało i ma boleć, bo bez tego nie będzie wyników. Podobnie jest z Pro JPA 2 (i było z Cormenem) - bolało, ale ostatecznie wiedza była ponadprzeciętną i nawet, jeśli wszystkiego się nie spamiętało, to wiedza, że tam to jest nie raz uratowała tyłek. Bolało i pewnie nie raz jeszcze zaboli, ale lepsze to, kiedy chcemy, niż później podczas projektów, których jedynym rezultatem i tak jest zatonięcie, tyle że okupione większymi stratami i ślęczeniem po nocach (czego nikomu nie życzę).

Wszedłem w temat zaawansowanego JPA, w świat zapytań natywnych w SQL. W JP QL naszym modelem jest model obiektowy, a w SQL model relacyjny (czy jak to ostatnio ujął Michał M. na spotkaniu Warszawa JUG - tabelkowy). Wybór należy do piszącego zapytanie, do czego mu bliżej - obiekty czy tabelki. Co mnie jednak dzisiaj niezwykle przyjemnie zaskoczyło, to fakt, że bez względu na wybór języka zapytań, programista i tak korzysta z tych samych obiektów - wciąż mamy javax.persistence.Query lub wprowadzone w JPA2 - javax.persistence.TypedQuery (!) Czyż to nie jest wspaniałe w tej specyfikacji, że bez względu na język SQL vs JP QL zmiana w wielu przypadkach odbywa się bez zmiany kodu?! Kiedy dodam do tego, że wprowadzenie zapytań nazwanych (mianowanych?, ang. named queries) umożliwia nadpisywanie ich przez deskryptor persistence.xml, wtedy można do zespołu wdrożyć gościa, którego zadaniem będzie optymalizowanie zapytań. Pasuje mu pisać w SQL, niech będzie, woli podciągnąć się z technologii JEE, wchodzi w JP QL. Najważniejsze, że nie trzeba schodzić na poziom JDBC, aby tworzyć wysokowydajną obsługę danych w bazie. Programiści nie zmieniają swoich konstrukcji programistycznych i prą do przodu, a ów człowiek od zapytań, aka człowiek-pytajnik, optymalizuje zapytania w cieple domowego kominka. Niby oczywiste, ale dla mnie niezwykle odświeżające. Kiedy dodam, że wynik zapytania, to wciąż encje zarządzane przez kontekst utrwalania, wtedy świat staje się ułożony. Pamiętajmy jednak, aby zapytanie SQL pobierało całość danych z bazy danych, bo w przeciwnym wypadku, część danych nie spłynie do encji i podczas zatwierdzenia transakcji, albo przy javax.persistence.EntityManager.flush() dane zostaną wyczyszczone (zamazane pustymi wpisami). Zapewnie nie byłoby to czymś, czym chcielibyśmy się pochwalić klientowi ;-)

Chciałoby się popróbować z JPA2 i w zasadzie każdy może. JPA2 jest częścią JEE6, ale może żyć i bez niej. Jak to miało miejsce w JPA1, tak i w JPA2, uruchomienie w samodzielnych aplikacjach czy wręcz środowiskach zubożonych, np. w wersji wcześniejszej JEE5, jest jak najbardziej możliwe i wspierane specyfikacyjnie. Bodajże wczoraj czytałem zajawkę o wsparciu JPA2 przez Hibernate 3.5 CR1, więc pasjonaci Hibernate mają możliwość, a Ci spoza jego strefy wpływów mają do wyboru referencyjną implementację JPA2 - EclipseLink, albo nieodstającego od peletonu Apache OpenJPA. Zdaje się, że Hibernate, który miał niebagatelny wpływ na specyfikację JPA, zaczyna oddawać pola konkurencji. Mamy wybór, a to jest najważniejsze i w sumie (początkowo) nie ma znaczenia, co działa pod spodem.

Ostatnie tygodnie spędziłem nad redbookiem (książki o technologiach IBM) dotyczącym IBM WebSphere Application Server V7 Feature Pack for Service Component Architecture (w skrócie SCA FeP). Zajmowałem się częścią administracyjną, która jest niezwykle prosta, zakładając znajomość administacji IBM WebSphere Application Server V7 samą w sobie. Największym wyzwaniem było stworzenie bogatej technologicznie aplikacji SCA, ale kiedy okazało się, że wraz z SCA FeP przychodzi wiele przykładów, temat był do obsłużenia w ciągu tygodnia, dwóch (niestety, jak to zwykle bywa, sam rozruch trwał prawie 2 miesiące - czas Nowego Roku nie sprzyjał rozpoznaniu terenu).

Jeśli ktokolwiek parał się z SCA, to wie, że jedną z darmowych implementacji jest Apache Tuscany. I SCA FeP jest po prostu opakowaniem Tuscany w odpowiednie rozszerzenia WASowe. Podobnie było z EJB3 czy Web Services z JEE5 dla WAS 6.1. Było, ale kto tego używał? Na moje nieszczęście niewielu. Niestety, ale produkty stosowe, np. IBM WebSphere Process Server V6.2 nie wspierały tych rozszerzeń, więc w produkcyjnych środowiskach, gdzie królowało SCA i WS-BPEL z WPSem, o JEE5 można było zapomnieć chyba, że przez wykonywanie zdalnych usług Web Services, ale to zawsze można.

IBM WebSphereNiezwykłem do wychwalania produktów mojego pracodawcy obawiając się oskarżeń, że jest to spowodowane głównie, gdzie pracuję, a nie zaletom technologicznym i jakoś tak trwało, że ja swoje, a IBM swoje - technologicznie, oczywiście. Z pewnością na moją decyzję miała również wpływ cena, która zwykle w naszych (=moich i czytelników mojego bloga) rozwiązaniach oscylowała głównie wokół bezwzględnego zera, ze względu na użycie produktów darmowych, otwartoźródłowych. Kolejnym powodem, może nawet ważniejszym, było opóźnienie technologiczne w porównaniu z darmowymi rozwiązaniami. Kiedy królowało JEE5 najnowsze wydanie IBM WebSphere Application Server V6.1 to wciąż jedynie (?) J2EE 1.4 z rozszerzeniami do EJB3 i Web Services. Dobrze, że WAS 6.1 to OSGi i dał tym samym możliwość zabawy z nowościami JEE5 przez rozszerzenia zwane Feature Packs. Zbierając to wszystko, niewiele można było u mnie znaleźć o produktach z rodziny IBM WebSphere mimo, że duża część mojego czasu była konsumowana właśnie przez nie.

I tak trwałem w tym stanie zawieszenia między rozwiązaniami OSS, a IBM, aż do grudnia 2009, kiedy pojawiły się produkty na bazie WASv7. Najnowsze wydanie WAS V7 zmienia diametralnie oblicze rynku rozwiązań JEE. W końcu mam(y) wsparcie JEE5 z JSE6 i OSGi pod spodem. To się musi podobać, szczęśliwcom, których firmy weszły w tą wersję. Nie ma wciąż wielu produktów realizujących JEE6, więc sprawa nabrała rumieńców i moloch typu IBM w końcu dotrał do punktu, w którym WAS V7 wybroni się technologicznie z każdego przetargu. W końcu! Sprzedawcom na pewno zrobiło się lepiej/łatwiej.

Jeśli ktokolwiek zadaje sobie pytanie, po co to piszę i czy ma to jakikolwiek związek z JPA2, albo innymi specyfikacjami wokół JEE, to śpieszę donieść, że pojawiły się dwa otwarte programy IBM WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0 Open Beta. Z nimi, pod płaszczykiem nauki WAS V7 możemy poznawać nowości JEE6 i OSGi Enterprise z wykorzystaniem Apache OpenJPA 2 i Apache Aries. Czyż nasze administracyjno-programistyczne boje z WASem, nie wydają się być od razu przyjemniejsze? W końcu na coś się zda nasz trud i pot. Jeszcze nie tak dawno, zapisałem się do grupy Apache Aries, aby śledzić poczynania w kontekście korporacyjnego OSGi, gdzie łączy się JEE i OSGi w spójną całość, a tu IBM wyjeżdża z możliwością uruchomienia obu na WAS V7. Niezwykłem wychwalać WASa, bo do wersji 6.1, był po prostu znośny, gdzie moja nauka specyfikacji, to zawsze był krok przez nim. Teraz, z WAS V7, sprawa w końcu przybrała inny obrót - teraz ja muszę nadgonić, bo mam go z przodu. Biorąc pod uwagę inne zalety WAS V7, mogę z czystym sumieniem polecić go jako ten serwer aplikacyjny do rozwiązań komercyjnych. Po 4 latach pracy w IBMie, w końcu mogę odetchnąć, że ja też już mogę bawić się najnowszymi zabawkami i jeszcze mi za to płacą! I to jest w tym wszystkim dobre. Jeszcze tylko niech IBM WebSphere Process Server podskoczy do SCA 1.0 i będzie naprawdę cacy. Na razie ni widu, ni słychu.

A czy Wam też płacą za przyjemności w pracy, czy się wciąż katujecie niszowymi rozwiązaniami?! Wytrwałości. I Wam się też, kiedyś powiedzie! ;-)

p.s. Ci, którzy dobrnęli do końca, mogą odetchnąć i z czystym sumieniem oddać swój głos na Notatnik w konkursie Bloger 2009 Roku. Będzie tego więcej.

12 lutego 2010

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

4 komentarzy
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ś?

10 lutego 2010

Notatnik startuje w "Bloger 2009 roku"

6 komentarzy
Zagłosuj na mnie - Bloger 2009 roku - Wiadomosci24Ci, którzy zaglądają do Notatnika bezpośrednio już zapewne zauważyli, a pozostałych śpieszę poinformować, że mój blog Notatnik Projektanta Java EE został zgłoszony do konkursu Bloger 2009 roku.

Uprasza się wszystkich dbających o moje dobre samopoczucie, co ma niebagatelny wpływ na treść wpisów, o zagłosowanie w konkursie Bloger 2009 roku na mój blog.

Ze swej strony obiecuję poprawę i same wypasione technicznie wpisy :) Wszystkim dziękuję za oddane głosy.

08 lutego 2010

Bajtkod praktycznie z wtyczką Bytecode Outline dla Eclipse

4 komentarzy
Czasy, kiedy pracowałem wyłącznie w Eclipse IDE dawno minęły i teraz częściej można było mnie spotkać przy NetBeans IDE, a ostatnio nawet przy IntelliJ IDEA (darmowe licencje są dostępne za prezentację podczas spotkań JUGa - chociażby Warszawa JUG).

Bodajże Łukasz Lenart zwrócił mi uwagę na aktualność Zestaw wtyczek Eclipse IDE do sprawnego tworzenia oprogramowania i tak mi jakoś zapadło w pamięci, aby go uaktualnić. W ten sposób szukałem tylko okazji, aby ponownie przysiąść przy Eclipse IDE i niedługo trwało, aż trafiłem na wtyczkę Eclipse Groovy (patrz De gustibus non est disputandum - Eclipse Groovy 2.0.0 dostępny). I tak się dalej potoczyło.

W międzyczasie, zaangażowany byłem w tworzenie poprawki do zgłoszenia OPENEJB-1128 Intercepting generic business method calls fails, które kolejny raz zaprowadziło mnie do org.objectweb.asm.signature.SignatureVisitor. Zawsze marzyło mi się dokładniejsze poznanie projektu ASM, więc kiedy zobaczyłem odnośnik Eclipse plugin na jego stronie głównej, w połączeniu z ostatnim rozpoznaniem wtyczek Eclipse, nie miałem złudzeń, że teraz nadeszła ta chwila. Wchodzę w ASMa!

Na głównej stronie ASM możemy przeczytać:

The best way to learn to use ASM is to write a Java source file that is equivalent to what you want to generate and then use the ASMifier mode of the Bytecode Outline plugin for Eclipse (or the ASMifier tool) to see the equivalent ASM code. If you want to implement a class transformer, write two Java source files (before and after transformation) and use the compare view of the plugin in ASMifier mode to compare the equivalent ASM code.

Nie pozostało mi nic innego, jak rozpoznawać ASM z pomocą wtyczki Bytecode Outline i Eclipse.

Pracuję z Eclipse IDE 3.5 SR1 (edycja Eclipse IDE for Java EE Developers), więc wystarczyło zdefiniować repozytorium wtyczki - http://andrei.gmxhome.de/eclipse/, aby się do niej dobrać. Chwila, dwie i wtyczka była już u mnie.

Niez(wyk)łe jest to, że mimo, że wcześniej czytałem, co daje mi wtyczka, kiedy zobaczyłem te funkcjonalności w działaniu, nie wierzyłem własnym oczom. Niesamowite doznania. Wtyczka Bytecode Outline pozwala na przegląd bajtkodu bez jakiegokolwiek wysiłku (nie wliczając wcześniejszego otwarcia widoku Bytecode :)).

Co mamy każdy widzi, ale widzieć nie oznacza rozumieć, więc warto pobrać wtyczkę i spróbować jej własnoręcznie. W widoku Bytecode otrzymujemy wynik działania ASM na skompilowanej klasie (bardzo podobny wynik otrzymalibyśmy korzystając z javap -c). Jakby tego było mało, w kolejnym widoku Bytecode Reference mamy dokumentację do instrukcji bajtkodu - chociażby w duchu poznawania nowego języka czy też wnętrza Javy, można w prosty sposób rozpocząć jego naukę bez wykrętów w stylu "Nie mam czasu", albo "Eee, to dla zaawansowanych".

Jeśli ktokolwiek mi teraz chociażby nadmieni, że poznawanie bajtkodu to wyzwanie dla najbardziej zaawansowanych (i jeszcze pewnie najmniej obłożonych bieżącym poznawaniem javowych szkieletów aplikacyjnych czy języków alternatywnych na JVM), to będę miał odpowiedź od ręki - wtyczka Bytecode Outline dla Eclipse. Z nią poznawanie rozwiązań typu AspectJ czy mechanizmów instrumentacji (modyfikacji bajtkodu w locie) nie powinien nastręczać problemów. Czyż świat nie wydaje się być prostszy, kiedy znamy klocki, z których jest zbudowany i rozumiemy ich wzajemne interakcje?! Nie mogłem wymarzyć sobie lepszego rozpoczęcia tygodnia!

[Sprostowanie]
Stworzona klasa świadomie upstrzona jest adnotacjami, które semantycznie nie mają większego sensu w tej klasie. Jej celem jest jedynie rozpoznanie tematu wymazywania typów generycznych podczas kompilacji oraz dostępności informacji o adnotacjach w klasach, a adnotacje @WebService i @WebMethod dostępne są w Java SE 6 z pudełka.

p.s. Widok Bytecode dostępny jest w kategorii Java obok kolejnego Bytecode Reference.

07 lutego 2010

61. spotkanie Warszawa JUG - Wojciech Erbetowski z "PlayFramework" i Łukasz Lenart z "Google AppEngine"

0 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG)Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 61. spotkanie, które odbędzie się we wtorek, 9. lutego o godzinie 18:00 w sali 5440 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Temat 1: PlayFramework - produktywność szkieletów webowych a'la Django, RoR, Grails
Prelegent: Wojciech Erbetowski

Temat 2: Google AppEngine - chmura na Ja(v)wie
Prelegent: Łukasz Lenart

Tym razem mamy dwie niezależne prezentacje.

Najpierw na scenę wchodzi Wojtek z "PlayFramework - produktywność szkieletów webowych a'la Django, RoR, Grails". Podczas wystąpienia poznamy nowiuteńki szkielet aplikacyjny dla Javy. Zrobiony w pełni w duchu RAD i COC (jeśli ktoś nie wie, o czym mowa, tym bardziej powinien się pojawić).
Ze względu na mechanizm szablonów ma szansę urzec tych, za których wiele może wykonać webmaster (aka pajeńczyniarz). Z drugiej strony, puryści zapewne wyleją na niego wiadro pomyj, bo jeszcze się taki nie narodził, kto by wszystkim dogodził i taka ich rola :)
Uczestnicy zobaczą kilka bardzo przyjemnych mechanizmów przydatnych do tworzenia bardzo typowych serwisów internetowych. Może być niezwykle odświeżająco i zajmie...jedynie 45 minut (!)

Następnie, zobaczymy prezentację "Google AppEngine - chmura na Ja(v)wie" Łukasza Lenarta. Prezentacja wprowadzi uczestników do świata tworzenia aplikacji Java w chmurach (ang. cloud computing), czyli pokaże czym jest Google AppEngine, jak pisać aplikację na tą platformę. W trakcie wystąpienia zostanie zaprezentowana prosta aplikacja korzystająca z dostarczonych usług przez GAE: BigTable - baza danych, Google Accounts czyli usługa zarządzania użytkownikami oraz Mail do wysyłania oraz odbierania poczty elektronicznej.
Na końcu zostanie zaprezentowana konsola dostarczana przez GAE, za pomocą której można zarządzać aplikacjami. Podobnie, wiele w niewiele - jedynie 45 minut (!)

Wojtek Erbetowski jest z wykształcenia matematykiem, a zawodowo programuje w Javie, zwłaszcza takie "typowe" rozwiązania.

Łukasz Lenart - programista z zamiłowania, tworzenie programów od zawsze było jego hobby, aż przerodziło się w zajęcie komercyjne. Uważa, że dobry programista nie powinien być uzależniony od języka, w którym tworzy, a raczej patrzeć w przyszłość i próbować różnych języków i technologii w zależności od wymagań - dzisiaj jest to Java, a co będzie za 10 lat? Równie dobrze może pisać w PHP, C#, Borland Delphi, etc. Ważne, aby przynosiło mu to przyjemność. Prywatnie mąż i ojciec, domator, który lubi czytać i ceni sobie święty spokój! Z przekonań socjalista, z działania kapitalista ;-)

Planowany czas prezentacji to 2x45 minut + 5-10 minut na przełączenie, po których planuje się 15-30-minutową dyskusję.

Wstęp wolny

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

05 lutego 2010

5ty lutego, to imieniny Agaty od Laskowskiego...

2 komentarzy
Dziś Agatki są imieniny,
Jacek pośpiesznie przegląda (javowe) nowiny.
Dziś niewiele przy kompie spędzi,
bo go Agatuś zaraz popędzi.


Dzień pracujący, acz wspaniały zarazem,
Jacek i Agatka spędzą go wieczorem razem.
Zero dżawuni i jej enterprajsa,
Jacek Agatce życzy...wszystkiego najlepszego!

Przy końcu się wypaliłem i coś mi nie szło z tą twórczością liryczną. Nic nie się nie kleiło :( Może Wam udałoby się dokończyć życzenia?

p.s. Może ...wielkiego surprajsa? :)

03 lutego 2010

De gustibus non est disputandum - Eclipse Groovy 2.0.0 dostępny

5 komentarzy
Wszystko zaczęło się od artykułu Groovy 1.7, Grails 1.2 and Groovy Eclipse 2.0 Updates Include Dependency Management,Language Support. Już miałem lekturę zmian w Groovy 1.7 i Grails 1.2 za sobą (nota bene, 1 lutego pojawiło się wydanie 1.2.1), więc pewnie nie dałbym się namówić na jego przeczytanie, ale dodatek w postaci Groovy Eclipse w temacie sprowokował mnie. Szczęśliwie artykuł, a raczej zajawka nowych wydań projektów, nie jest długi, więc wystarczył kwadrans i było po krzyku.

Podobają mi się takie dywagacje nad kodem, co można, a co nie i dlaczego. W tym artykuliku dowiedziałem się o java.util.concurrent.atomic.AtomicInteger (wciąż lektura zmian w Java SE 6 przede mną i tylko tyle wiem, ile się przydaje po drodze - pewnie niejedno przysłowiowe koło odkryłem w międzyczasie) i kolejny raz o Grape. W przypadku Grape, autor ciekawie przedstawia zalety dekorowania importów z adnotacjami, które zwykle trafiają do zewnętrznych plików w Maven czy Ant. Ciekaw jestem, ilu z Was podziela zdanie o "This in turn triggers the download of the dependency and makes your code's build more self-documenting." Mam wrażenie, że autor przekonuje, że użycie wszystkiego, co związane z klasą, bezpośrednio w niej, to dobra rzecz. Moje skromne doświadczenie programistyczne nie pozwala mi dostrzec tych zalet, bo jakkolwiek korzystam z adnotacji Java EE 5+, to tylko i wyłącznie w fazie prototypowania czy wczesnego rozwoju aplikacji. Później, preferuję podejście czysty technologicznie kod źródłowy ze wszelkimi dodatkami technologicznymi w postaci plików XML i to jeszcze w osobnych modułach projektowych. Stawiając sprawę jasno, adnotacje w kodzie dobre, ale docelowo nalegałbym, aby się ich stamtąd pozbyć i wynieść na zewnątrz, np. do plików XML.

O Grails 1.2 jedynie się wspomina, więc nie ma co liczyć na chociażby taki przekrój wiedzy, jak to ma miejsce w przypadku Groovy 1.7. Podobnie z Groovy Eclipse. Zdaje się, że autorowi bliżej do Groovy niż do pozostałych produktów i dodał je, bo...kazano (?). Początek (o Groovy) był świetny z końcówką (o Grails i Eclipse Groovy) do kosza. Można skończyć czytać na akapicie o Grails 1.2.

Gdyby ktoś mogł mi jeszcze wyjaśnić, co autor zamierzał wyrazić przez dwukrotne użycie angielskiego słowa 'sport' w artykule, byłoby cacy. Kompletnie nie mogę docieć, co to słowo znaczy w tym artykule.

Po artykule, zabrałem się za instalację wtyczki Eclipse Groovy. Instalacja zabrała niespełna kilka minut. Wystarczyło pobrać aktualną wersję Eclipse IDE for Java EE Developers 3.5 SR1 (3.6m4 nie działała) i dopisać http://dist.springsource.org/release/GRECLIPSE/e3.5/ jako stronę z aktualizacjami Eclipse Groovy (zainteresowani skrinkastem nt. tej instalacji, proszeni są o komentarz do wpisu). Po instalacji, chwila na restart Eclipse i miałem go uzbrojonego o wtyczkę Eclipse Groovy 2.0.0.

Przejrzałem kilka nowości, które oferuje i wybrałem najważniejsze z mojego punktu widzenia (pisanie dokumentów typu "New and Noteworthy" to wielka odpowiedzialność, bo ma tę wadę/zaletę, że "rozleniwia" potencjalnych użytkowników do badania tylko tych funkcjonalności, które zostały przedstawione w dokumencie - wiele ciekawostek może zostać nieodkrytych do czasu przypadkowego trafienia podczas pracy, a wciąż mogą być interesujące dla szerokiej publiczności):

- z Groovy-Eclipse 2.0.0M1 New and Noteworthy:

Incremental compilation, co zgodnie z nazwą sprowadza się do kompilacji jedynie tych elementów projektu, które zostały zmienione bez względu na język, w jakim zostały napisane - Java czy Groovy. Innymi słowy, ma być szybciej, dzięki integracji kompilatora Eclipse JDT i Groovy.

JUnit Monospace font do wyświetlania wyników uruchomienia testów z Spock Framework. Nigdy nie używałem go wcześniej, a jedynie słyszałem wzmianki o nim, więc teraz chociażby z ciekawości, ile będzie mnie kosztowało uruchomienie go w Eclipse i docenienie zmian we wtyczce Eclipse Groovy znajdę czas dla niego.

Wyłączanie Groovy Script z kompilacji przy budowaniu/uruchamianiu projektu. Wystarczy wybrać opcję Build Path > Exclude z menu kontekstowego na wybranym skrypcie groovy.

Breakpoints and debugging - mamy możliwość ustawiania miejsc zatrzymania (ang. breakpoints) debugera i podejrzenia stanu zmiennych skryptu/aplikacji napisanej w Groovy.

Runtime evaluation of Groovy code - wyliczanie wyniku uruchomienia wycinków kodu Groovy.

- z Groovy-Eclipse 2.0.0M2 New and Noteworthy:

Refactoring Support - zmieniamy zmienną/metodę/klasę w Javie i zmiany propagują się do kodu Groovy, i na odwrót.

Task Tags - znamy i używamy - TODO, FIXME i XXX w kodzie Groovy rozpoznawane są dokładnie jak w Javie.

Wszystkie ze zmian opisane są dokładniej na blogu autora wtyczki Contraptions for programming, więc spragnieni wiedzy (a tylko tacy tutaj zaglądają :)) mogą pozwolić sobie na więcej...wiedzy.

- z Groovy-Eclipse 2.0.0RC1 New and Noteworthy:

Jars from .groovy/lib directory added to classpath - dodajemy wybrane jary do katalogu ~/.groovy/lib i automatycznie trafiają do ścieżki klas (CLASSPATH) naszego projektu. Niekoniecznie potrzebne biorąc pod uwagę możliwość skorzystania z Apache Maven 2, ale...nie wszyscy z niego korzystają (= straceńcy :))

To tylko wybrane usprawnienia we wtyczce Eclipse Groovy i zostały przeze mnie namaszczone mianem tych ważniejszych, co niekoniecznie musi spełniać kryteria Waszej ważności. Szczegółów należy szukać bezpośrednio u źródła - na stronie wtyczki Eclipse Groovy.

Interesujący jest fakt, że mamy publicznie dostępną wersję finalną wtyczki, a w JIRA jest 1 otwarte zgłoszenie na poziomie Major. Widać JIRA swoje, a wtyczka swoje. I tak, głównymi i jedynymi opiniodawcami są sami użytkownicy i bez względu na ilość włożonej pracy nawet największe dzieło może nie doczekać się właściwego poszanowania. W końcu piękno to kwestia gustu, a o nim się nie dyskutuje...De gustibus non est disputandum, albo Beauty is in the eye of the beholder. Wspaniale pasuje jako podsumowanie dyskusji nt. assert w komentarzach do Niemy film(ik) na weekend - Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2. Dzięki Wujek za "uzyles asercji bo chciales i tyle." Właśnie! ;-)