27 września 2009

Java EE 6 i OSGi z FishCAT i "Pro Spring Dynamic Modules for OSGi Service Platforms"

2 komentarzy
Rozpoczął się FishCAT, czyli program testowania najnowszego wydania GlassFish v3 (b65), który ma ocenić gotowość produktu do produkcyjnych wdrożeń. Tym samym moja aktywność wokół Grails zostaje wzbogacona o doświadczenia z GlassFishem.

Z listu powitalnego do FishCAT - [FishCAT] Please start FishCAT testing on b65, Thanks ! - można przeczytać, że:

Here is FishCAT testing schedule. Bugs filed after the ending date may be differed to next release based on
the priority. Hope you will find some time in next to weeks to help us testing.

FishCAT Testing Schedule: 9/25/09 - 10/9/09 (2 weeks)
FishCAT doc review schedule: 9/25/09 - 10/9/09 (2 weeks)
FishCAT i18n/l10n testing: 9/25/09 - 10/21/09 (4 weeks)


czyli jedynie 2 tygodnie na testowanie produktu przed finalnym wydaniem. Zdaje się, że w tym czasie należy oczekiwać również wielu finalnych wydań specyfikacji wchodzących w skład Java EE 6. Proszę, proszę, to było w końcu rok temu, kiedy na rynku pojawiło się Java EE 5, a tu mamy nową wersję. Ta również ma być jeszcze ciekawsza niż poprzednie. I znowu wyścig serwerów aplikacyjnych o prym w realizacji Java EE 6 się zacznie.

Już od jakiegoś czasu przyglądałem się rozwojowi GF i co mnie najbardziej zachwyciło, to wsparcie dla OSGi. Oczywiście dodając do tego wsparcie Java EE 6 mamy pełen obraz, dlaczego zdecydowałem się na 2-tygodniowe turnee z GlassFishem w roli głównej. Sam udział w programie ma być pretekstem do powrotu do korzeni ze wspomnianymi technologiami, które zostały przesłonięte Grails.

Jako uzupełnienie mojego powrotu do Java EE/OSGi zabrałem się za lekturę "Pro Spring Dynamic Modules for OSGi Service Platform" z Apress. Jakkolwiek książce bliżej do rozwiązań opartych na Spring Framework, a więc bliżej jej do Grails niż GlassFish czy Java EE 6, to wszystkie technologie są tak ze sobą związane, że dotykając jednego trudno nie dotknąć innych.

Na pierwszy rzut oka, najbardziej egzotyczną technologią może wydawać się OSGi, ale właśnie z rozwiązaniami typu Spring-DM, czy GlassFish jego rola sprowadza się do ukrytego gracza, który wspiera infrastrukturę, na której nasze aplikacje są budowane (Spring-DM) i/lub uruchamiane (GlassFish). Właśnie podział na budowane-uruchamiane daje odpowiedź, dlaczego Spring-DM (strona OSGi) ma tak silny związek z GlassFish (strona Java EE 6). I coś co wydaje się być różne i odległe od siebie jest faktycznie nierozerwalne (albo przynajmniej takim powinno być).

Stworzenie aplikacji springowej może być rozbudowane o cechy OSGi z pomocą Spring-DM, a środowiskiem uruchomieniowym może być właśnie GlassFish (który niestety poza wykorzystaniem OSGi wewnętrznie nie daje możliwości skorzystania z niego w ramach wdrażanych aplikacji korporacyjnych). Spring Framework to wyłącznie szkielet aplikacyjny, którego główną cechą jest realizacja podejścia (wzorca?) Inversion of Control przez mechanizm Depenency Injection, który potrzebuje środowiska uruchomieniowego z jego usługami. Serwer aplikacyjny Java EE świetnie uzupełnia ofertę Spring Framework przez dostarczenie wszystkich obowiązkowych usług typu monitor transakcyjny, zarządca utrwalania danych JPA czy infrastruktura bezpieczeństwa.

Jeszcze podczas lektury "Grails in Action" doświadczyłem niesamowitego olśnienia odnośnie różnicy między Inversion of Control (IoC) a Dependency Injection (DI), co zwykłem traktować jako synonimy. Jakież było moje zdumienie, kiedy przeczytałem, że IoC to podejście (wzorzec?) tworzenia aplikacji, gdzie zarządzanie zależnościami oddelegowuje się do kontenera IoC, a DI to jedna z jego realizacji, która polega na przekazywaniu/wstrzykiwaniu owych zależności do komponentu zarządzanego (strona 396). Niestety, nie jestem w stanie wskazać innej realizacji IoC, ale na takie przedstawienie tematu mogę się zgodzić. Niewielka różnica, która często "fall through the cracks" (piękny idiom w j. angielskim, którego nie mogłem nie użyć w ramach pogłębiania mojej znajomości angielskiego).

Sama książka "Pro Spring Dynamic Modules for OSGi Service Platforms" rozpoczyna się, tak jak prawdopodobnie zaczyna się każda książka na ten temat - najpierw wprowadzenie do OSGi, później Spring Framework, dalej Spring Dynamic Modules, aż lądujemy z SpringSource dm Server w jednej dłoni, a jego rozwiązaniami wokół wersjonowania składowych aplikacji, dostępem do danych, aplikacjami webowymi i testowaniem w drugiej. Na razie mam za sobą pierwszy rozdział książki "Introducing OSGi" i mimo jedynie 42 stron na ten temat, warto było. Tak jak można było się tego spodziewać, było tworzenie pakunku OSGi, ale czego nie, to próba zarejestrowania jego funkcjonalności jako usługi (tak, było też wymienione SOA, ale tylko przez chwilę) i udostępnienie jej jako servlet za pomocą HTTP Service. Nie ma wiele rozpisywania się nt. OSGi, ale jest wystarczająco, aby wprowadzić w temat, a sam przykład jest zdecydowanie bardziej zaawansowany niż jego nazwa mogłaby wskazywać - HelloWorld. Jestem niezwykle zadowolony z tego, że zdecydowałem się na tę książkę. Leżała u mnie od lutego (!) Jest to książka drukowana, więc zainteresowani będą musieli odczekać jeszcze kilka tygodni, kiedy wróci do Biblioteki Warszawskiego JUGa.

Przede mną wprowadzenie do Spring Framework przez 60 stron. Już przez głowę przeszło mi, aby przerzucić te strony i zabrać się za kolejny rozdział 3. "Integrating Spring and OSGi". Nie będzie mi łatwo przebrnąć przez niego. Już tyle zostało powiedziane o Springu, a tu jeszcze 60 stron przede mną. Dobrze, że po nim znowu OSGi, a w odwodzie jest testowanie GlassFisha z NetBeans IDE 6.7.1/6.8 i nauka Java EE 6.

24 września 2009

Recenzja "Grails in Action" z Manning - numer 1 w książkach o Grails

5 komentarzy
Wspominałem już o tym, że zabrałem się za lekturę kolejnej książki o Grails 1.1 - "Grails in Action" autorstwa Glena Smitha i Petera Ledbrooka z wydawnictwa Manning kilka dni temu (patrz "Grails in Action" w akcji i moje pierwsze wrażenia). Właśnie ją skończyłem i jedynie powtórzę, że sposób w jaki panowie Glen i Peter przedstawili Grails budzi mój najwyższy szacunek. Konkretnie i z humorem. Dokładnie tak, jak mógłby oczekiwać tego, każdy adept sztuki grailsowej, aczkolwiek byłbym niezwykle ostrożny z postawieniem tezy, że jest to książka dla nowicjuszy. W moim przypadku, kiedy to skończyłem 3 książki o Grails - Beginning Groovy and Grails: From Novice to Professional, Grails 1.1 Web Application Development oraz The Definitive Guide to Grails, 2nd Ed. sądziłem, że jedyne co w niej znajdę, to po prostu ugruntowanie już zdobytej wiedzy. Nie długo trwało, abym przekonał się, jak bardzo się myliłem. Mam wrażenie, że poprzednie książki były po prostu preludium do "Grails in Action". Jeśli "The Definitive Guide to Grails, 2nd Ed." jest kompedium wiedzy o Grails (w końcu pisana przez samego twórcę Grails - Graeme Rocher), to "Grails in Action" jest zwartym, ale wciąż kompletnym jego streszczeniem z nutką dobrego humoru. Mnóstwo testów jednostkowych, integracyjnych i kilka funkcjonalnych dopełniły obraz książki o Grails, w której stawia się nie tylko na przedstawienie jego cech, ale również, aby przeprowadzić przez nie w odpowiedni i interesujący sposób. Zdecydowanie udało się to autorom. Polecam! Kolejność czytania wspomnianych książek ma znaczenie, a nawet dwie pierwsze można spokojnie ominąć bez utraty wiedzy.

Recenzja książki po angielsku (ze względu na wymóg wydawcy w ramach programu wsparcia Warszawa JUG) na moim Wiki - Book review: Grails in Action. Opublikowałem ją również na Amazonie - The concise definitive guide to Grails (kolejny wymóg wydawnictwa). Książka jest do wypożyczenia w ramach Warszawa JUG w wersji PDF, więc nic nie stoi na przeszkodzie, aby poznać i Waszą opinię na jej temat. Chętni proszeni o kontakt na priv.

23 września 2009

52. spotkanie Warszawa JUG - "Kickstart w tworzeniu aplikacji webowej z AppFuse i pomocnikami" Wojtka Erbetowskiego

0 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 52. spotkanie, które odbędzie się w najbliższy wtorek, 29.09.2009 o godzinie 18:00 w sali 5440 Wydziału MIMUW przy ul. Banacha 2 w Warszawie.

Temat prezentacji: Kickstart w tworzeniu aplikacji webowej z AppFuse i pomocnikami
Prelegent: Wojtek Erbetowski

W trakcie prezentacji zostanie przedstawiony szkielet aplikacji webowej opartej na Spring Framework - AppFuse. Prelegent pokaże jak szybko stworzyć (nie taką znowu) prostą aplikację, jakie narzędzia mamy w niej "za darmo", a jakie możemy wdrożyć niedużym kosztem. W zależności od chęci publiki wdrożone do gotowej aplikacji (i omówione dla niezaznajomionych z nimi) zostaną m.in. takie rozwiązania jak: Gradle, Mercurial i JRebel. A może nawet spróbujemy porównać aplikację do wciąż młodego projektu Spring Roo?!

Wojtek Erbetowski jest z wykształcenia matematykiem i pracuje jako naczelny programista Java (J2EE/Spring) w niedużej firmie technologicznej.

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

Wstęp wolny!

Zapraszam w imieniu prelegenta i grupy Warszawa JUG!

20 września 2009

"Grails in Action" w akcji i moje pierwsze wrażenia

3 komentarzy
Jeśli poprzednie książki o Grails (patrz recenzje Book review: Grails 1.1 Web Application Development, Book review: The Definitive Guide to Grails, Second Edition, Book review: Beginning Groovy and Grails: From Novice to Professional) zrobiły na mnie jakiekolwiek wrażenie, to Grails in Action z Manning pozostawi takie jedno, nieodparte, że jedynym słusznym sposobem na poznanie dowolnej technologii jest właśnie...czytanie książek. Nic to, że ich czytanie wymaga dużej cierpliwości i mnie każdorazowo rusza po rozdziale, bądź dwóch, więc czytanie robię na wyrywki, ale to, co uda mi się z nich wyciągnąć jest po prostu warte swojej ceny. Paradoksalnie, frustrujące w tym wszystkim jest to, że ów "strumień książkowy" z książkami do przeczytania nie ma końca. Aktualnie jestem zaangażowany w projekt SOA (wybaczcie użycie tego akronimu, ale to faktycznie jest przykład typowego projektu integracji usług, która idealnie pasuje do niego) z zabawkami typu IBM WebSphere Process Server i IBM WebSphere Business Services Fabric, gdzie króluje SCA, SDO, WS-BPEL z SOAP/JMS i dynamicznym wyszukiwaniem usług, więc kiedy przychodzę z pracy wkraczam w całkowicie odmienny świat Grails. Całkowicie niekomercyjny, pełen rozwiązań z bodaj wszystkich dziedziń świata projektów otwartych związanych z Java EE. Czytania jest co nie miara, ale pozostaje uczucie niedosytu braku wykorzystania tej wiedzy w praktyce - oczywiście tworząc nowy serwis Web 2.0. Szczęśliwie Grzesiek Duda & Co nie zasypiają gruszek w popiele i udało im się wkroczyć na ścieżkę ciągłych udoskonaleń, nowych wydań i wyzwań wokół serwisu Developers World. Wygląd zupełnie powalony, ale przecież nie o to w tym chodzi (im na pewno nie :)). Chodzi o dobrą zabawę tworząc ciekawy serwis, a jeśli dzieje się to przy akompaniamencie Grails i w dobrej wierze zaoferowania czegoś ciekawego (oby i nowatorskiego), to tym lepiej.

Wracając do mojej czytelniczej działalności, to mam wrażenie, że przy takim podejściu specjalizacja jest nieuchronna. Ostatnio przytrafiło mi się czytać wyłącznie książki o Grails. Za sobą mam 3, a w trakcie jest kolejna. Zabrało mi to circa dobre 1-2 miesiące. Gdybym chciał przetestować wszystkie te cudeńka grailsowe zabrałoby mi to kolejne miesiące. Innymi słowy, mam wrażenie, że taka seria czytelnicza może sprawić, że wiedza wzrośnie w tempie wykładniczym, ale tylko poparta praktyką będzie faktycznie użyteczna. Machać rękoma każdy potrafi, ale niewiele trzeba, aby rozpoznać semi-praktyka w tłumie. Zdaje się, że znowu wpadłem w pułapkę perfekcjonizmu (o której wciąż wspomina moja żona używając bardziej dobitnego terminu "odpał". A może to był "odchył"?!). Tak czy owak dobrze jest nie przesadzać i lektura dobra rzecz, aczkolwiek bez przesady. Warto poczytać i warto potrenować nabytą wiedzę w praktyce, ale również warto zaznać całkowicie odmiennych wrażeń zarzucając komputer i znaleźć czas, aby sobie wszystko poukładać. Po wakacjach, gdzie czasu miałem co nie miara, zauważyłem, że warto.

A co nowego w "Grails in Action" (GiA)? Miałem wrażenie, że poprzednie książki nie dadzą mi już cieszyć się nową wiedzą o Grails, bo wszystko już było powiedziane. Nie mogłem bardziej się mylić. Każdorazowo, kiedy czytam książkę, zaznaczam interesujące fragmenty do zbadania, zapamiętania, czy po proste warte ponownej uwagi. Jeśli w poprzednich książkach tych fragmentów było, powiedzmy, 30%, to w przypadku GiA będzie tego coś koło 50%! Panowie, Glen Smith i Peter Ledbrook dali nieźle popalić. Nie tylko, że przedstawiają temat dogłębnie, ale przede wszystkim praktycznie. Znajdziemy wiele przykładów w postaci testów jednostkowych i integracyjnych (są również funkcjonalne, ale one jedynie podczas przedstawiania odpowiednich wtyczek Grails). Do tej pory udało mi się dotrwać do części 4-tej "Advanced Grails" i zachodzę w głowę, co jeszcze mogę się dowiedzieć. Tyle już zostało opisane, a tu jeszcze ta ostatnia część. Formuła książki przedstawia się w ten sposób, że panowie przedstawiają daną problematykę, aby ją później rozwiązać dostępnymi wtyczkami Grails i po dywagacjach, które lepsze/gorsze, podsumować ją pewnym planem działania przy rozwiązywaniu tematu z pomocą Grails. Nie raz, nie dwa, znajdziemy tam informacje wykraczające poza obszar samego Grails, więc wszyscy zainteresowani tworzeniem oprogramowania webowego, bez względu na język/technologię, mogliby znaleźć coś dla siebie. Pewnie trochę wyolbrzymiam to oderwanie od technologii, ale Ci z obszaru Javy i okolic już na pewno. Są rozdziały, które czyta się bardzo przyjemnie, ale są i takie, które ciągną się godzinami. Takim rozdziałem był rozdział poświęcony tym wszystkim cechom dobrego serwisu Web 2.0 (rozdział 8 "Using plugins: adding Web 2.0 in 60 minutes"). Jak sobie o tym pomyślę teraz, to nie był taki zły, ale jakoś nie szedł mi płynnie, jak inne. Jedno, co pozostało mi w głowie po nim, to nauczyć się jQuery. Podobno to taki javascriptowy killer, jeśli chodzi o dodawanie bajerów ajaxowych do aplikacji. Tak przy okazji, to dobrze się składa, bo w kolejce do przeczytania leżą książki o JavaScripcie i jQuery, więc tylko czekać, aż się za nie zabiorę. Zdecydowanie za mało u mnie wiedzy z obszarów Script.acolo.us, Prototype, czy YUI. Szczęśliwie, z Grails nie można się tego nie nauczyć. Po prostu, tworzenie aplikacji Grails to skorzystanie z domyślnej biblioteki ajaksowej w Grails - Prototype, a wskazanie na inne to kwestia niewielkiej zmiany w konfiguracji. Grails, jak nikt inny, pozwala na delikatne wejście w temat ze swoimi wtyczkami. To jest jedna z tych cech Grails, które mnie wciąż zdumiewają - uczę się Grails, a przy okazji wszystkiego wokół. Przecież Grails to zlepek wszystkich tych technologii/projektów, które do tej pory musiałem samodzielnie, tak misternie składać, więc skąd to zdumienie?! Może to Groovy, który znosi ten cały bagaż Javy ze mnie?! Na razie nie było żadnych poważniejszych projektów z Grails, więc niewiele praktyki, ale z tego, co słychać wszyscy mówią o nim w samych superlatywach. Chyba dałem się zwieść :)

Wracam do lektury GiA. Niedługo recenzja i upragniony powrót do Nauczyciela. W końcu rozpoczął się nowy rok szkolny i dzieciaki potrzebują trochę frajdy z nauki, nieprawdaż?

p.s. Mamy już jdn.pl, java.pl i wspomniany dworld.pl. Sądzę, że jest jeszcze miejsce dla kolejnego tworu ala wspomniane serwisy, ale oferującego coś faktycznie odświeżającego dla naszej społeczności javowej i zbudowanego na bazie Grails. Poszukuję grafika, który wie, co to Web 2.0 i zna się na tych wszystkich pastelowych kolorach, zaokrągleniach, śmiesznych rysunkach i dużych czcionkach. Jeśli ktoś mógłby się podzielić ze mną namiarami na takowego, będę dozgonnie zobowiązany. Czas zabrać się za urzeczywistnienie pomysłu i sprawdzenie swoich grailsowych umiejętności w boju. Każdy może, więc i ja spróbuję. Kiedy przyjdzie do programowania na pewno zaproszę wszystkich zainteresowanych do udziału w przedsięwzięciu.

13 września 2009

Ciekawostki Grails z książki "Grails 1.1 Web Application Development"

9 komentarzy
Podczas lektury ostatniej książki o Grails - Grails 1.1 Web Application Development (której moją recenzję można przeczytać w Book review: Grails 1.1 Web Application Development) - zaintrygowała mnie wzmianka nt. Stripes. Jestem w trakcie czytania kolejnej książki o Grails i tam również trafiłem na Stripes. Mam wrażenie, jakby w tym szkielecie aplikacyjnym było coś, co podobnie jak w Wicket sprawia, że jest to całkiem ciekawe rozwiązanie, ale brakuje mu po prostu rozgłosu. Chyba kolejny raz potwierdza się reguła, że dobre samo się nie obroni i potrzeba trochę PRu, aby zademonstrować jego siłę. Pamiętam wystąpienie Jacka Lisa o Stripes, ale było to tak dawno, że nie ukrywałbym swojego zainteresowania, gdyby ktoś zechciał przedstawić go jeszcze raz w ramach spotkań grupy Warszawa JUG.

Jednej z rzeczy, na którą wcześniej nie zwróciłem uwagi było wyświetlanie wyłącznie 6 kolumn klasy dziedzinowej przy użyciu rusztowania (ang. scaffolding) w Grails. Krótki przykład jak najbardziej na miejscu. Zaczynamy od grails create-app barfaw, później cd barfaw, a dalej już pozostaje grails create-domain-class pl.jaceklaskowski.Uzytkownik, edycja klasy i dodanie więcej niż 6-ciu pól do niej, stworzenie kontrolera UzytkownikController (grails create-controller pl.jaceklaskowski.Uzytkownik) i włączenie rusztowania (niezapominając o skasowaniu akcji index), aby ostatecznie uruchomić aplikację poleceniem grails run-app.

(dla zainteresowanych: barfaw to taki na prędce sklecony skrót od BARdzo Fajna Aplikacja Webowa).

Co mnie niezwykle mile zaskoczyło, to fakt, że Grails 1.2-M2 przychodzi z całkiem nową, domyślną szatą graficzną. Niezwykle odświeżający widok.

Dodatkowo Grails chodzi domyślnie na Apache Tomcat! Wiedziałem, że w planach jest uruchomienie Grails na Tomcacie, ale sądziłem, że to jeszcze trochę potrwa. Co za niespodzianka! Mam wrażenie, że gdybym przeczytał Release Notes do tej wersji mógłbym poznać kilka innych ciekawostek, a tak pozostawiam ich spotkanie przypadkowi.

Dowiedziałem się również, że na szczycie hierarchii obiektów w Groovy stoi interfejs groovy.lang.GroovyObject z klasą abstrakcyjną groovy.lang.GroovyObjectSupport. Chcesz być obiektem Groovy a żyjesz na Javie? Wystarczy odpowiednia implementacja.

W końcu również udało mi się przez przypadek znaleźć rozwiązanie dla kwestii aktualizacji Grails bez konieczności aktualizacji wtyczek. Wystarczy zdefiniować zmienną grails.project.plugins.dir w grails-app/conf/BuildConfig.groovy i od tej pory wszystkie wtyczki trafią do wskazanego katalogu. Domyślnie wtyczki są umieszczane w katalogu zależnym od wersji Grails (w ścieżce katalogów jest numer wersji), więc wystarczyła zmiana Grails, aby całą instalację wtyczek zaczynać od nowa. Znając rozwiązanie, już nie.
 jlaskowski@work /cygdrive/c/projs/sandbox/barfaw
$ cat grails-app/conf/BuildConfig.groovy
grails.project.plugins.dir="c:/apps/grails-plugins"

jlaskowski@work /cygdrive/c/projs/sandbox/barfaw
$ grails install-plugin jsecurity
Welcome to Grails 1.2-M2 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: c:/apps/grails

Base Directory: C:\projs\sandbox\barfaw
Running script c:\apps\grails\scripts\InstallPlugin.groovy
Environment set to development
Reading remote plugin list ...
Reading remote plugin list ...
Installing plug-in jsecurity-0.4.1
[mkdir] Created dir: c:\apps\grails-plugins\jsecurity-0.4.1
[unzip] Expanding: C:\Documents and Settings\jlaskowski\.grails\1.2-M2\plugins\grails-jsecurity-0.4.1.zip
into c:\apps\grails-plugins\jsecurity-0.4.1
Executing jsecurity-0.4.1 plugin post-install script ...
Plugin jsecurity-0.4.1 installed
Plug-in provides the following new scripts:
------------------------------------------
grails create-auth-controller
grails create-db-realm
grails create-ldap-realm
grails quick-start
Kolejną ciekawostką było przedstawienie różnicy między jawnym definiowaniem typu a użyciem def przy deklaracji pól obiektu, do których zostaną przypisane instancje usług (dzięki mechanizmowi DI). Niby niewinnie wyglądająca deklaracja

def fileService
nie różni się wiele od

FileService fileService
ale w pierwszym przypadku każdorazowa zmiana implementacji FileService będzie automatycznie przeładowana i ponownie przypisana, podczas gdy w drugim przypadku przypisanie nastąpi tylko na początku, a każda kolejna zmiana wymagała będzie ponownego uruchomienia (przeładowania) aplikacji. Zaletą tego drugiego jest wsparcie IDE przy rozwiązywaniu typu zmiennej i tym samym możliwość podpowiadania możliwych metod. Wybór należy do Ciebie.

Kolejna ciekawostka znaleziona w książce to nowe mapowanie usług RESTowych w Grails 1.1 przez resource, np.:

"/api/message/$id?"(resource: "api")
Wystarczy jedynie stworzyć kontroler ApiController, aby metody GET, PUT, POST oraz DELETE były automatycznie kierowane do akcji show, update, save oraz delete. Niewielka zmiana, a ile zaoszczędzi czasu podczas prototypowania (przynajmniej, a kto wie, czy nie w finalnej wersji aplikacji?).

Na koniec ciekawostek z książki padła wzmianka o Google Web Toolkit oraz Wicket. Niestety, ale poza wzmianką niewiele więcej. Ich zaletą jest uproszczone testowanie widoku, co nastręcza dużych trudności przy zastosowaniu GSP. Ostatni komentarz Graeme Rocher do wątku "Wicket plugin and Grails 1.1" na liście dyskusyjnej Grails nie pozostawia jednak złudzeń:

The Wicket plugin needs updating for 1.1, I decided to progress too much further with it until Groovy supports anonymous inner classes and nested classes

i dalej:

> Thx for your response, any idea when Groovy is planned to support anonymous inner classes?

Groovy 1.7


Jeśli miałbym wybierać między GWT a Wicket, to w przypadku integracji z Grails postawiłbym obecnie na GWT. Ale tylko do wersji Groovy 1.7.

12 września 2009

51. spotkanie Warszawa JUG - "Openfire i Smack - tworzenie wtyczek i rozszerzeń Jabbera" Bartka Zdanowskiego

0 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 51. spotkanie, które odbędzie się w najbliższy wtorek, 15.09.2009 o godzinie 18:00 w sali 5440 Wydziału MIMUW przy ul. Banacha 2 w Warszawie.

Temat prezentacji: Ognisty Serwer, smaczny Klient. Openfire i Smack - tworzenie wtyczek i rozszerzeń serwera/klienta Jabbera
Prelegent: Bartek Zdanowski (Zdanek)

Podczas prezentacji zostanie zademonstrowany serwer jabbera Openfire i biblioteka klienta - Smack. Prelegent pokaże jak tworzyć pluginy i komponenty do Openfire oraz zademonstruje prostotę pisania własnego klienta bazując na bibliotece Smack. Oprócz klasycznych wtyczek będzie jak rozszerzać komponenty składowe i właściwości serwera. W trakcie prezentacji - kodowanie na żywo.

Bartek Zdanowski pracuje w firmie AutoGuard SA. Jest głównym programistą i szefem technicznym zespołu tworzącego oprogramowanie do zarządzania flotą samochodową.

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

Wstęp wolny!

Zapraszam w imieniu prelegenta i grupy Warszawa JUG!

09 września 2009

Book review: Grails 1.1 Web Application Development

0 komentarzy
W końcu przyszła kolej na kolejną recenzję książki o Grails wydawnictwa Packt - Book review: Grails 1.1 Web Application Development (ze względu na wymogi wydawnictwa napisana po angielsku). Ilość wiedzy jaką udało mi się zdobyć po przeczytaniu tej książki nazwałbym przygniatającą, mimo wcześniejszych książek o Grails, które udało mi się przeczytać. Do tej pory wszystkie książki o Grails skupiały się raczej na prezentacji funkcjonalności Grails i próbie przedstawienia ich przez pryzmat tworzonej aplikacji. Celem było opisanie możliwie jak największej części Grails, tak aby ostatecznie stworzyć jego encyklopedię, bądź coś na ten wzór. W przypadku tej książki - Grails 1.1 Web Application Development - autor skoncentrował się na tworzeniu aplikacji webowej za pomocą Grails i tam, gdzie konieczne, przedstawienia jego cech, które upraszczają temat. Nie znajdziemy tam całego Grails, ale wystarczająco wiele, aby polecić ją każdemu adeptowi Grails, a nawet tym, którzy sądzą, że wiedzą o nim wiele. Ja byłem mile zaskoczony ogromem wiedzy przystępnie przedstawionej i każdemu życzę podobnego odbioru. W przeciwieństwie do innych książek o Grails, ta będzie wciąż gdzieś pod moją ręką. Pozostałe były ciekawe, ale wystarczy je raz przeczytać i można o nich zapomnieć. Ta ma w sobie coś odmiennego, co powoduje, że mam zamiar do niej wrócić jeszcze kilkakrotnie. Zainteresowanych zapraszam do lektury w ramach Warszawa JUG.

01 września 2009

"Niejawne" wakacyjne przemyślenia

19 komentarzy
To były wakacje! Całkowity odskok od technologii javowych w stronę wypoczynku pełną gębą. Dzięki przedsiębiorczości mojej żony mieliśmy okazję kolejny raz wybrać się samochodem na wakacje do Chorwacji, gdzie pogoda rozpieszczała nas przez cały pobyt, a później już lokalnie, wyjazd do Białowieży (nawet dwukrotny) i Supraśla. I to bez komputera! Dla niektórych to normalne, ale dla mnie przez ostatnie lata owa normalność stanowiła nielada wyzwanie i komputer jechał z nami. Tym razem było inaczej. I nie żałuję, bo chociażby z nudów człowiek szedł o przyzwoitej porze spać, aby wstawać rano wypoczętym. Totalny odlot. Kiedy już wróciliśmy z wojaży wzięło mnie nawet na pogrywanie w grę internetową Traviana (adresu świadomie nie podaję, aby mnie ponownie nie wciągnęło, albo innych :)). Gra bardzo zbliżona do Civilization, ale cały sęk polega na tym, aby nie rozwijać się, a rozwijać wojo i łupić (a że przy okazji się i tak rozwijają wioski, to już inna historia). Wzięło mnie na tyle, że skoro nie angażowałem się w poznawanie Javy zabrałem się za układanie wyliczeń, jakby tu najefektywniej rozbudować osady w możliwie najkrótszym czasie. W pewnym momencie zacząłem nawet czytać o programowaniu liniowym i innych algorytmach, aby tylko połączyć pożyteczne z niepożytecznym (co było czym, nie jestem w stanie teraz powiedzieć). Pojawiły się różne zestawienia w OpenOffice Calc i tak trwało przez całe wakacje z niewielkimi przerwami. Już myślałem, że nie dam rady się z tego wykaraskać, ale wystarczyło uzmysłowić sobie, że przy tej całej zabawie, nic człowiek nie zyskuje. Kompletnie nic! Jedynie miernej jakości zabawa i całkowicie niepotrzebna strata czasu. Przy całkiem niezłym wyniku postanowiłem zaniechać procederu na rzecz porzuconej Dżawki. Zabawne w tym wszystkim było to, że kiedy przyszło do nazywania kolejnych wiosek postanowiłem nazywać je kolejnymi wyrazami w znanej nam wszystkim frazie "public static void main". Co mnie zaskoczyło, że akurat main to faktycznie miała stać się wiochą główną - stolicą (15-cropowcem). Dodatkowo, kiedy zauważyć, że wyrazy z 'a' były od budowania wojska offowego, a reszta deffowego widać niesamowite zależności Javy ze wszystkim co może sprawić przyjemność :) To mam już za sobą i jeśli kiedykolwiek wrócę do gierek internetowych, to chyba tylko, aby samodzielnie napisać taką. Mogłoby być ciekawym doświadczeniem.

Podczas wyjazdów wakacyjnych udało mi się trochę liznąć literatury niejavowej. Zabrałem się za czytanie książek o negocjacjach, "7 nawyków" Coveya i temu podobne. Pojawiły się również książki o finansach, więc było trochę o giełdzie, inwestowaniu, oszczędzaniu, FOREX i temu podobnych. Tutaj również znalazłem kilka podobieństw z naszym "najulubieńszym" zajęciem, jakim bezsprzecznie jest programowanie w Javie. Jakby nie patrzeć, każdy z nas zarabia i wierzy w to, że któregoś dnia będzie zarabiał jeszcze więcej. Z tym "jeszcze większym zarabianiem" wiąże się jednak fakt, że "więcej zarabiać, znaczy więcej wydawać" (wszystkim tym, którym udało się zapobiec temu gratuluję i proszę o kontakt). Wszyscy zarabiamy, ale niewielu z nas oszczędza, nie wspominając już o inwestowaniu. Pewnie na palcach jednej ręki możnaby policzyć osoby, które poświęcają inwestowaniu więcej uwagi. Co niektóry z nas, coś tak próbuje, ale jest to tak, jakby próbować stworzyć aplikację webową, a nigdy nie uruchomić kontenera servletów. Większość z nas przecież ma zrozumienie matematyki (chociażby powierzchowne, ale większe niż powszechnie), więc podwaliny do zrozumienia jak działa ekonomia są. Jeśli dodać do tego znajomość algorytmiki, to aż trudno uwierzyć, że aplikacje wspomagające podejmowanie decyzji finansowych nie powstają, jak przysłowiowe "grzyby po deszczu" (!) Gdyby próbować to zrozumieć przez pryzmat siebie, to mógłbym postawić tezę, że owa wiedza powoduje, że wiemy wiele, ale jest to jeszcze niewiele, aby w pełni zarządzać naszym budżetem. Wymaga to trochę większej aktywności na innym polu niż śledzenie nowości javowych, a na to nie ma już po prostu czasu. Czyżby? Jeśli tak, to jakich luksusów spodziewamy się po 65. roku życia? Właśnie zacząłem się nad tym zastanawiać (nota bene, w wakacje zawsze wypadają mi urodziny :))

W owych książkach mogłem przeczytać takie zwroty jak "bądź konsekwentny, pragmatyczny, licz się z niepowodzeniem, dywersyfikuj, spekuluj, uważaj na "owczy pęd", trzymaj się trendu", co przypomina mi zachowanie nas samych, jako uczestników społeczności javowej. To w zasadzie o nas, ale książki były o...inwestowaniu. Czyż nie jest to zdumiewające?! Nasze typowe zachowania niezwykle upodabniają nas do inwestorów giełdowych. Kiedy sobie to uzmysłowiłem wprost nie mogłem w to uwierzyć, ile nas łączy, a faktycznie jaka jest przepaść między obiema grupami. Jakbyśmy wypalali się uprawiając programowanie i na finansowanie już nie ma siły. I jedno i drugie wymaga wiedzy i praktyki. Wiemy również, że "jedyną stałą rzeczą w życiu jest zmiana", więc ciągle się dostosowując warto rozważyć dostosowanie się do aktualnej sytuacji finansowej i uszczknąć niewiele, aby zainwestować i potencjalnie zarobić wiele. Wszędzie trąbią o cięciach, zwolnieniach, spowolnieniu gospodarczym, więc może to jest ten moment, kiedy my, osoby uczone logicznego myślenia, rozwiązujące nietrywialne problemy biznesowe w postaci nietrywialnych aplikacji, weźmiemy się w garść i wystartujemy z własnym biznesem? A jeśli jeszcze nie teraz, to może chociaż warto rozważyć rozpoczęci nauki o inwestycjach i przy okazji stworzyć aplikację, która i Tobie, i Tobie, i Tobie również, pomoże zapomnieć o problemach finansowych. Wydaje mi się, że można, ale czy się faktycznie nam chce? Do rozważenia.

Pojawiły się nowe pomysły na rozruszanie społeczności javowej, ale o tym na razie sza, aby nie zapeszyć. Powinno być ciekawiej, ale nie wszystko na raz. Na razie rozpocząłem nowy sezon blogowania. Ag(reg)atka już pewnie zaczyna się martwić odpły(ja)wającym Jackiem :)