19 lipca 2009

2-tygodniowa przerwa urlopowa

1 komentarzy
Przez kolejne 2 tygodnie jestem na urlopie. W tym czasie kramik blogerski będzie czasowo zamknięty! Aż boję się pomyśleć, ile się będzie działo i to beze mnie :( Ja jednak nie zamierzam próżnować i odwiedzę kilka ciekawych miejsc oraz przeczytam kilka książek nietechnicznych (nawet 1-2 o inwestowaniu). Zero zajmowania się jakimkolwiek tematem javowym - całkowite wyciszenie od zgiełku technicznego, aby wypoczęty zabrać się za nie z nową energią. Bawcie się dobrze!

17 lipca 2009

Trochę o Grails WebFlow i więcej o wydarzeniach okołospołecznościowych

2 komentarzy
Wielokrotnie obsługujemy w aplikacji pewnien rodzaj interakcji z klientem, która polega na serii kroków (ekranów), których wykonanie nie jest możliwe bez wykonania wcześniejszych. Takim przykładem jest sprawdzian - wydarzenie, które przechodziliśmy niejednokrotnie. Wchodzimy na sprawdzian (rejestracja), otrzymujemy zestaw pytań, aby odpowiedzieć na nie kolejno, aby na zakończenie oddać nasze wypociny i z niecierpliwością oczekiwać wyniku. Jest to nic innego jak przykład przepływu - akcja jest wejściem dla kolejnej i wykonanie "wewnętrznych" akcji nie jest dozwolone.

Diagram stanowy w UML jest idealny w takiej sytuacji. Jedynym problemem jest wskazanie tego właściwego bytu, którego stan monitorujemy i w tym przypadku może nim być po prostu sprawdzian, którego "egzemplarz" konstruujemy dla każdego z uczestników (analogicznie do zależności między klasą a jej egzemplarzem - instancją). Zazwyczaj postrzegamy świat obiektowo, ale interakcje między nimi już imperatywnie (chyba w dobrym kontekście użyłem tego słowa nawiązując do sposobu programowania - krok po kroku proceduralnie). Stąd tyle trudności w znalezieniu się w sposobie programowania z językami funkcyjnymi czy modelowaniu z użyciem diagramu stanów zamiast powszechnego diagramu przepływów. Z użyciem diagramu stanów mogłoby to wyglądać tak:

Teraz wygląda to znacznie lepiej niż przy pierwszym podejściu. Chciałem, aby diagram był jasny, zaraz po pierwszym spojrzeniu na niego. Czuję, że jestem bliżej ideału.

Jak niektórzy zauważyli korzystam z Visual Paradigm for UML CE. Pisałem o moich próbach z UMLowym diagramem stanów w Pierwsze (krótkie) doświadczenie z Eclipse UML2 Tools - idzie do kosza i za namową Krzyśka Kowalczyka oraz Radka Szulgo vel dayt3k (w komentarzach do wspomnianego wpisu) postanowiłem sprawić jego możliwości. Po pierwszych kilku godzinach mogę śmiało polecić to narzędzie, aby popróbowąć się z UMLem. Interfejs jest intuicyjny, a liczba diagramów jest wystarczająca, aby sobie pomodelować. Nie jest to narzędzie-marzenie, ale dla początkujących (jak ja) może być.

Wciąż zastanawiam się, jak to zrobić bardziej profesjonalnie, gdzie mam przemyślane, co, gdzie, kiedy i dlaczego. Najpierw odsiedziałem swoje przy diagramie i sądzę, że w tej postaciu wyraża co autor miał na myśli. Zabieram się za implementację w Grails (chyba nikt nie przypuszczał, że mu odpuściłem?! :)). Znalazłem w ten sposób sytuację, w której mogę wykorzystać mechanizm Grails Web Flow, który jest zbudowany w oparciu o Spring Web Flow (tak na prawdę jest jego DSLem). Dobrym źródłem informacji jak to jest zrealizowane w Grails jest bez wątpienia rozdział 6.5 Web Flow. Po tym powinno być jasne, co możemy, a czego nie w Grails w obsłudze tego typu scenariuszy.

Wydawałoby się, że mogę wracać do Grails, ale pojawił się ping od Piotra Przybylaka. Fajna sprawa, że można za pomocą bloga dotrzeć do ciekawych ludków. Po tym, kiedy opublikowałem mój wyjazd do Łodzi - OT: Białowieża nie tak daleko, jadę do Łodzi i o przyzwyczajeniach słów kilka - napisał do mnie:

Piotr: hej, jesteś w Łodzi teraz ? Ja się chętnie spotkam i pogadam o tych wszystkich trudnych słowach które wspomniałeś na blogu ;>

Intrygujące, co?! Nie było na co czekać, o 20:00 spotkaliśmy się idąc na Piotrkowską. Okazało się, że Piotr jest takim znawcą Łodzi, że w zasadzie ja - gaduła nad gadułami - powiedziałem mniej niż najbardziej cicha osoba, jaką możecie sobie wyobrazić :) W ten sposób, dowiedziałem się tylu ciekawych rzeczy o historii Piotrkowskiej, Łodzi i całego klimatu informatycznego, że postanowiłem przy najbliższej okazji pojawić się w Łodzi ponownie. Byliśmy przez chwilę w fajnej knajpce Łódź Kaliska, a dzień wcześniej z żoną byłem w Manufakturze. Miejsca, których nie można nie odwiedzić będąc w Łodzi. Jest w niej tyle ciekawych miejsc, że mam wrażenie, że brakuje tam jedynie prężniejszej grupy JUGowej. I właśnie to jest celem Piotra - rozruszać lokalną społeczność i ponownie zainicjować serię spotkań jugowych. Zainteresowani? Kiedyś spotkałem się z Adrianem Nowakiem z krakowskiego JUGa, który pokazał mi, jak poprowadzić temat i zorganizować konferencję, nie jedną, ale kilka. W ten sposób mamy Javarsovię, Warsjavę, Warszawski Eclipse DemoCamp i wizyty osób z zagranicy, które nie byłyby możliwe bez aktywnego wsparcia wielu osób z Warszawa JUG. Tego samego możnaby również oczekiwać od innych JUGów, w tym i łódzkiego. Koniecznie piszcie do niego, bo jeśli nie on, to pewnie niewielu będzie miało tyle zapału, aby tego dokonać. Widać, że się zawziął i ma szansę coś większego zrobić. Niektórzy twierdzą, że to bliskość Warszawy powoduje, że ludzie zwracają głowy w tym kierunku, zamiast zająć się tym, co można zrobić lokalnie. W Łodzi jest wspaniały klimat i nie widzę powodów, dla którego nie możnaby zorganizować następnego Eclipse DemoCamp lub mniejszego kalibru konferencję, aby ostatecznie rozruszać towarzystwo łódzkie. Jeśli w Warszawie się dało, w Krakowie, Wrocławiu, Lublinie, Gdańsku, Szczecinie, Tarnowie, Silesii, Gdańsku czy Poznaniu, to dlaczego nie wskazać na Piotra jako tego, który tchnie życie w łódzki JUG?! Zdecydowanie potrzeba tego temu miastu i ludziom, którzy oparli się pokusie migracji do Warszawy (czego nie mogę powiedzieć o sobie).
Tak się skończyła moja wizyta w Łodzi. Podziękowania dla Piotra za spotkanie, że mu się w ogóle chciało. Niewiele trzeba było, a efekt może być zaskakujący. Dla mnie kolejna wizyta na Piotrkowskiej będzie z głową wyżej niż sklepowe witryny - to właśnie tam jest wiele ciekawych rzeźb, herbów i innych atrakcji. Warto!

W jednym z wpisów - Javarsovia 2009 scaliła (spoiła?) polską społeczność javową - wspomniałem o Sławku Sobótce z Lublin JUG. Sławek Sobótka napisał do mnie o swojej inicjatywie, a tam maluczki peesik:

ps: czekam na slowa krytyki (to najlepszy feedback) odnosnie stronki - krytyka absolutnie nie musi byc konstruktywna:)

Chętni wyrazić swoją opinię proszeni są o kontakt ze Sławkiem. Kto jak kto, ale lubelski Sławek nie jeden raz udowodnił, że zależy mu na wzmocnieniu polskiej społeczności javowej, więc należy mu się sukces w branży. Niewielka reklama na moim blogu jest moim skromnym podziękowaniem za jego przemyślenia architektoniczne na blogu Holistyczna inżynieria oprogramowania. Nie mam wątpliwości, że wszyscy już tam zaglądacie regularnie, a gdyby nie, teraz już powinniście. Już nie przyjmuję wymówek w stylu "Nie wiedziałem", "Nie mam adresu" i takie tam. Polecam!

A dla zainteresowanych spotkaniem ze znanymi osobistościami świata Javy zapraszam na JDD Road Show. Pisała o tym Ania na jdn.pl - Zapraszamy na JDD Road Show do Krakowa i Warszawy, więc nie będę powtarzał. Na MIMUWie jest wszystko dograne - jest sala i rzutnik. Jak to zostanie wykorzystane nie mam pojęcia. Mnie nie będzie, bo wybieram się na 2-tygodniowy urlop, ale Ci, którzy nie mają tyle szczęścia i wciąż spędzają lato przed kompem powinni skorzystać z nadarzającej się okazji spotkania.

p.s. Właśnie odkryłem, że można uruchomić takie stare gierki dosowe na DOSBoxie. Pamiętam czasy Prehistorika czy Boulder Dash (a nawet Caveman Ugh, Lemmings czy Titus the Fox) i widać, że mimo upływu czasu wciąż są w ruchu. Wystarczy pobrać Prehistorika z Best Old Games i DOSBox. Próbowałem i działa. Agata się ucieszy, jak jest pokażę Prehistorika - ile to ona czasu przesiedziała przy nim! :)
Poza tym, kiedy tak wspominałem różne gry, padła nazwa nowej, takiej z górnej półki wymagań sprzętowych - Assassin's Creed 2 od Ubisoft. Chociażby dla rozejrzenia się w możliwościach dzisiejszych gier warto przejrzeć jego zwiastun. I jak tu się rozwijać informatycznie, kiedy tyle pokus wokół?! ;-)

13 lipca 2009

OT: Białowieża nie tak daleko, jadę do Łodzi i o przyzwyczajeniach słów kilka

6 komentarzy
Sądziłem, że do Białowieży to się z żoną w najbliższym czasie nie wybierzemy. Trwało to już dobrych kilka tygodni, kiedy pierwszy raz Agata wspomniała o wyjeździe. I tak sobie trwało. Trwaliśmy w błogim stanie zawieszenia wierząc, że skoro Ziemia się kręci, to może kiedyś, przypadkiem, się tam znajdziemy. Niby mieliśmy to zaplanowane na jakąś bliżej nieokreśloną przyszłość, a tak właściwie jedynie naszkicowane. Dzieciaki pojechały do dziadków, a my sami. Sami, więc wydawałoby się, że skoro zawsze tyle było pomysłów, to teraz będzie znacznie łatwiej je zrealizować, chociażby kilka z nich. Nic bardziej mylnego! "Przyzwyczajenie drugą naturą człowieka" - ten, kto to wymyślił chciał jeszcze bardziej dobić człowieka. Kończymy pracę, idziemy do domu i gdyby tak się temu naszemu profesjonalnemu życiu przyjrzeć możnaby z niezwykłą precyzją powiedzieć, co będziemy robić jutro, pojutrze i jeszcze w kilku nadchodzących dniach. Niby słoneczna pogoda powinna zachęcić nas do wyjścia i spędzenia czasu aktywnie(j), zamiast ślęczenia przed kompem, ale się po prostu nie chce. Czy, aby na pewno się nie chce, czy po prostu łatwiej nam jest siedzieć przy kompie?! To znacznie łatwiejsza czynność i tak nie męczy. To znaczy, męczy, ale chyba mniej, skoro robimy tego więcej, a to że psychicznie bardziej, to już nieważne. W końcu kiedyś pójdziemy spać i może się wyśpimy (słowo-klucz: może). I prześpimy kolejny czas, w którym moglibyśmy zrobić coś bardziej pożytecznego dla nas samych. Tak też było ze mną w sobotę, kiedy to się przebudziłem i z Agatą rozważaliśmy opcje wyjazdowe. Tutaj za daleko, więc nieopłaca się na 2 dni, tutaj to może później i tak nic by z tego nie wyszło, gdyby nie fakt, że trochę przekorne z nas istotki i każdy chce pokazać, jaki to z niego luzak i że sumienność oraz planowanie to nasze drugie ja, więc, kiedy Agata zapytała "Jedziemy?", ja bez wahania odpowiedziałem "Jedziemy! A co mamy nie jechać?!". Wtedy padło pytanie "A gdzie?", a ja na to pewnie "Nooo, może wcześniej planowane Żubry?". Kiedy sobie teraz o tym przypomnę wiem, że wtedy nie przypuszczałem, że się faktycznie ruszymy. Wiedziałem, że będzie 150 powodów, aby zostać w domu i że będzie doskonała wymówka, że tak było lepiej pod każdym względem. Nie zanudzam dalszymi akcjami przedwyjazdowymi, ale koniec końców znaleźliśmy się w Białowieży. Było super! Super pogoda, super spanie w Soplicowie (jedną noc we dwoje można sobie pozwolić na trochę rozrzutności) i zdaje się, że również wiele atrakcji, aczkolwiek my skorzystaliśmy z potrawy z jelenia i pierogów z jagodami, odwiedzenia Rezerwatu Żubrów (jakby to moja żona powiedziała Dżubrów) i wizycie w skansenie Sioło Budy oraz przyległej knajpce, w której zjedliśmy wspaniałe coś ala pierogi i coś ala tortellini. Jedzenie palce lizać. Wróciliśmy cało i zdrowo w niedzielę przed wieczorem z bodajże 8-10 słoikami miodu (należymy do grona miodożerców, więc nie wróżę im długiego bytu u nas w domu). W tym tygodniu, od poniedziałku do czwartku, będę w Łodzi prowadząc szkolenie z administracji IBM WebSphere Application Server 6.1, więc "stracony" czas na jakieś dżubozwiedzanie zrekompensuję sobie ślęczeniem przed kompem :) W końcu, ile czasu można chodzić po Piotrkowskiej?! A może znajdzie się ekipa, gotowa się spotkać i przegadać swoje doświadczenia z ciekawymi rozwiązaniami, typu Grails, Groovy, a może i Clojure czy Scala? Chętnie przyłączyłbym się. W końcu nie często człowiek ma taką możliwość. Mógłbym nawet pokazać Grails w akcji. To mnie zawsze dopinguje do większej aktywności.

I ja właśnie o tym - o aktywnościach, możliwościach i naszych przyzwyczajeniach. Doświadczam tego niejednokrotnie, że łatwość pewnych możliwości nie idzie w parze z przyzwyczajeniami. Jam, jako człowiek, bardzo leniwa bestia. Ile to razy, kiedy pada deszcz mówię sobie "Ech, byłbym teraz na koszu, albo poszedłbym z żoną na rower, a tak nie będę i znowu muszę przesiedzieć przed kompem". Może warto sobie zaplanować jeden dzień na coś niezwykłego, powiedzmy wtorek będzie dniem, kiedy rzucimy wszystko, co do tej pory robiliśmy i przez jeden dzień, zajmiemy się czymś nowym. Jak mamy wiele zapału zabieramy się za coś spoza zasięgu komputera, a jeśli trochę mniej, wystarczy poznanie nowego rozwiązania, języka, albo założenie bloga. Cokolwiek, byle było nowe. Po kilku dniach, owe nowe stanie się mniej nowe, więc przy kolejnym wtorku będzie to coś jeszcze innego, ale po jakimś czasie, na pewno będziemy wiedzieć, że skoro planowaliśmy wyjazd do Białowieży, to 250km nie może być powodem, dla którego nie zrealizujemy swoich planów. Dla niektórych będzie to plan, a dla innych marzenie. Do której grupy należysz?

p.s. A może pora zabrać się za nowy język programowania?! Sam wybierz, ale niech to będzie coś innego niż Java, a wciąż na JVM. Będzie to niezwykle odświeżające doświadczenie, które właściwie przeżyte na pewno da kopa na kolejne przeciągające się dni w projekcie. Sprawdź to sam!

08 lipca 2009

Javarsovia 2009 scaliła (spoiła?) polską społeczność javową

10 komentarzy
Może zabrzmi to trochę patetycznie, ale jestem niezwykle szczęśliwy mogąc współpracować z tyloma ciekawymi osobami, które pozwoliły mi spełnić moje odwieczne marzenie ożywienia i zintegrowania polskiej społeczności javowej przez organizację konferencji Javarsovia. Tegoroczna edycja konferencji była wydarzeniem organizowanym przez nas dla nas. A jeśli ktoś zapyta: "A kto to my?" bez wahania odpowiem "Polska społeczność javowa". Udowodniliśmy tym samym, że nie potrzeba komercyjnych imprez organizowanych przez tuzów IT dla wybrańców celem zwiększenia sprzedaży produktów pod sztandarami konferencji javowej skoro, jeśli się chce można dla wszystkich i to bez bełkotu marketingowego. Głównymi sprawcami tego dzieła byli (w kolejności alfabetycznej):
  • Łukasz Lenart
  • Michał Margiel
  • Marcin Molak
  • Paweł Wrzeszcz
  • Mateusz Zięba
  • Łukasz Żuchowski
  • Jacek Laskowski
Konferencja była tak płodna, dosłownie i w przenośni, że 3-em osobom...urodziły się dzieci (!) Możnaby powiedzieć, że zwiększenie aktywności konferencyjnej jest wprost proporcjonalne do wielkości populacji w Polsce :) Tak trzymać!

Podziękowania należą się sponsorom i patronom, począwszy od Wydziału Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego (MIMUW), przez sponsora głównego Javart, złotych - Google i e-point oraz sponsorów Artegence, iSolution, Sages, Touk, Code-House, a także firmą NASK jako partnerem merytorycznym i Dobre Programy za medialny rozgłos. Bez ich wsparcia finansowego możliwości konferencyjne byłyby znacznie skromniejsze. I nie byłoby tak pysznego obiadu. Oficjalne podziękowania w drodze.
  1. Zaczęliśmy pracę przy konferencji - 8. stycznia 2009 r.
  2. Liczba organizatorów zmieniała się w czasie i ostatecznie ustabilizowała się na 7 wyżej wymienionych (chociaż było więcej zapisanych do grupy Kapituły, ale widać nie mogło znaleźć dla siebie adekwatnego zadania)
  3. Liczba uczestników: aż do 372 osób, w tym 12 kobiet - podział terytorialny z liczbą osób poniżej, ale w sumie było 61 miejscowości
  4. 3032 wiadomości w grupie dyskusyjnej Kapituły
Poznałem wiele nowych osób, ale najważniejsze było móc podczas przerw przechodzić od grupy do grupy, w którym spotykałem osoby znane mi z polskiej blogosfery czy po prostu z życia JUGowego. Wielu początkowo sceptycznie podchodziło do udziału w Javarsovii, spodziewali się raczej mniej atrakcyjnego wydarzenia, a okazało się, że konferencja przeszła ich najśmielsze oczekiwania. Takie głosy dochodziły ze strony uczestników, ale także sponsorów. Dzięki Koziołkowi byliśmy również na tweeter'ze i to był ten moment, w którym uzmysłowiłem sobie, gdzie jest jego wartość - bieżąca relacja z konferencji. Blogi są zbyt statyczne i wymagają bogatszych treścią wpisów, podczas gdy tweeter to po prostu SMS w Internecie. Przypomina mi to relację między SMSem a emailem, albo prowadzeniem rozmowy (gdyby założyć, że są jedynie z kategorii "komunikacja"). Trzeba było Javarsovii i Koziołka, abym sobie to uzmysłowił. Dzięki Koziołek.

Dziękuję mojej żonie Agacie za uczestniczenie w konferencji i późniejszej SPOINIE. Zabawa przednia. Dzielnie sprawowała się również żona Łukasza Marta Lenart, która sprawnie zawiadowała rejestracją (podobno podczas rozpoczęcia były aż 3 kolejki!). Dziękuję Krakowowi (ags, Adrian i Radek), Lublinowi (z jedną osobą zamieniłem słowo, ale widziałem również Sławka Sobótkę w tłumie, którego niestety nie udało mi się zaczepić na pogaduchy), Poznaniowi (szczególnie Adamowi za przyjazd na kilka godzin oraz Kubie za prelekcję), Szczecinowi (pozdrowienia dla 15-dniowych nowożeńców - niestety nie pamiętam imion i właścicielom glanów), Bydgoszczy (reprezentowanej przez mojego kumpla ze studiów Przemka - nie wiedzieliśmy się przez ponad 10 lat!), Wrocławowi (którego wiążę z Pawłem Szulcem, ale i Markiem Goldmannem - sorry Marek, ale dla mnie zawsze będziesz z Wrocka :)). Dziękuję za pomoc osobom, którzy pojawiali się z rana przygotowując wszystkie gadżety, które uatrakcyjniły konferencję - koszulki, kubki, materiały reklamowe sponsorów. A jakie było jedzenie - palce lizać. Kiedyś pisałem o konferencji celem większej jej reklamy, ale teraz piszę dokładnie tak, jak czułem się po JBoss World w Bracelonie, czy JAOO w Aarchus - byłem zachwycony mogąc zobaczyć tyle interesujących osób, które związane są z Javą, tyle tylko, że tym razem była to sama śmietanka polskiej społeczności. To był mój cel całej mojej działalności publicznej, który się w ten jeden dzień zmaterializował - możliwość poznania osób z Polski, które parają się Javą na codzień i wraz z nimi stworzyć klimat konferencji zagranicznych, gdzie możliwość zamienienia słowa z blogerami, prelegentami, autorami artykułów z czasopism branżowych jest realna, na wyciągnięcie ręki. I wszystko całkowicie bezpłatnie! Jedynym kosztem dla uczestnika był jego/jej czas spędzony w Warszawie na konferencji Javarsovia. Nie mało, ale do opanowania. Wierzę, że był to owocnie spędzony czas.

Dodatkowe informacje o miejscowościach, które były reprezentowane przez uczestników Javarsovii 2009 (obok nazwy miasta liczba uczestników):

Warszawa 183, Kraków 22, Wrocław 20, Łódź 12, Białystok 10, Gdańsk 9, Poznań 9, Lublin 8, Piaseczno 6, Szczecin 6, Kielce 5, Toruń 5, Bydgoszcz 4, Katowice 4, Płock 4, Skierniewice 4, Tarnów 4, Dąbrowa Górnicza 3, Pruszków 3, Zielona Góra 3, Chorzów 2, Elbląg 2, Gliwice 2, Ostrołęka 2, Pabianice 2, Rybnik 2, Wołomin 2

oraz po jednej osobie z: mojego rodzinnego Grudziądza (bardzo chciałem zamienić choć słowo z nią), Przasnysz, Zalesie Górne, Kobiór, Pszczyna, Krynka, Duszniki Zdrój, Gniezno, Bełchatów, Knurów, Sochaczew, Otwock, Żory, Błonie, Węgierska Górka, Zawoja, Nowa Iwiczna, Łuków, Legionowo, Aleksandrów Kujawski (moja żona pochodzi ze Służewa i bardzo była ciekawa, kto zawitał stamtąd), Walendów, Węgrów, Radom, Gdynia, Łomża, Sulechów, Grójec, Inowrocław, Częstochowa, Bielsko-Biała, Sokołów Podlaski, Lubliniec oraz Rzeszów.

Pojawiły się już relacje z Javarsovii w polskiej blogosferze (proszę o kontakt osoby, których wpisów nie wymieniłem):
Do zobaczenia za rok!

p.s. Zrozumiałem jeszcze, że koniec z relacjami, które rozwadniają tego bloga. Pora na mocne wpisy o treści technicznej z przykładami wdrożenia wiedzy, którą wyczytałem z książek, poznałem przeglądając pRaSSówkę, czy w ogóle uważam za wartościową, a poznałem z innych źródeł. Wciąż będą relacje, ale bardziej wyrafinowane. Zobaczymy.

05 lipca 2009

Pierwsze (krótkie) doświadczenie z Eclipse UML2 Tools - idzie do kosza

9 komentarzy
Już pojawiają się opinie po wczorajszej Javarsovii 2009, ale moje wrażenia chciałbym jeszcze uzupełnić o kilka danych statystycznych i zdjęcia, więc temat odłożony na kolejny wpis.

Dzisiejszy dzień dosyć deszczowy w Warszawie i po uwagach, jakie coraz częściej do mnie dochodzą w kontekście treści publikowanych w moim blogu zdecydowałem się na niewielką acz zapewne zauważalną zmianę - koniec z relacjami z lektury książek, które ciągną się tygodniami. Nie ukrywam, że mój plan zaczął mnie samemu przygniatać swoim zasięgiem i próba relacjonowania każdego z rozdziałów powodowała, że miałem "zarezerwowane" kilkanaście dni/tygodni wprzód. Czytanie książek idzie mi znacznie szybciej, a relacje poszczególnych rozdziałów zajmowały często zdecydowanie za dużo treści w pojedynczym wpisie niż samemu chciałbym przeczytać. Na własne życzenie wiązałem sobie ręce. Głosy, jakie do mnie dochodziły zdawały się sugerować zmianę podejścia na bardziej produktywny, a nie jedynie odtwórczy. Koniec więc z pomysłami relacji książek w stylu "wpis za rozdział". Powinno być znacznie odświeżające dla obu stron.

W ten sposób postanowiłem wrócić do bardziej aktywnego rozwoju Nauczyciela - aplikacji w Grails, której celem jest nauka Grails praktycznie oraz pomoc w nauce moim dzieciakom. Dzisiaj przyszła pora na wdrożenie przepływów na bazie Grails Web Flow. Temat bardzo obszernie opisany w książce "The Definitive Guide to Grails, Second Edition", którą swego czasu relacjonowałem (patrz kategoria Grails). Zacząłem już dłubać w kontrolerze, kiedy to postanowiłem podejść do tematu trochę bardziej metodycznie z użyciem diagramu stanowego UML. Potrzebne mi było narzędzie do jego stworzenia i padło na Eclipse UML2 Tools (po prostu wyszukałem w Google frazę "eclipse uml").

Początkowo zabrałem się za instalację UML2TOOLS 0.9.0, ale niedługo trwało, kiedy pobrałem po prostu wersję Eclipse Modeling Tools (includes Incubating components), gdzie wszystko jest gotowe do użycia. Wystarczyło Ctrl+N, wybrać kategorię UML 2.1 Diagrams i pojawiła się cała lista dostępnych diagramów.

Następnie State Machine Diagram i skończyłem z czymś takim.

Jeśli to ma być wszystko, co oferuje Eclipse 3.5 w temacie UML 2.1, to ja dziękuję za takie rozwiązanie. Mam do dyspozycji komercyjne rozwiązania, jak IBM Rational Software Architect czy IBM WebSphere Integration Developer, więc na pewno nie będę narzekał, jak zapomnę o "czystym" Eclipse i jego wsparciu dla UML. Uważam UML2 Tools za niezwykle nieintuicyjne rozwiązanie, gdzie chociażby funkcja "Arrange All" rozkłada elementy odwrotnie - do góry nogami, co można zauważyć na powyższym zrzucie. Całkowicie się zgadzam za określeniem stanu projektu jako Incubating. I niech tam jeszcze posiedzi, bo tylko sprowokuje jeszcze jedną duszyczkę do zmarnowania kilku godzin na jego rozpracowywaniu, poszukiwaniu dokumentacji, aby ostatecznie machnąć na to ręką.

A poza tym, nie wiem, jak należałoby zamodelować przepływ typu sprawdzian w umlowym diagramie stanów. Jak rozumiem ten typ diagramu, jego celem jest przedstawienie zmiany stanu pewnego bytu, np. uczestnik sprawdzianu lub sam sprawdzian. Pierwszy nie pasuje mi - chyba, że miałbym modelować zmianę jego stanu psychicznego podczas sprawdzianu. Stąd pozostaje mi sprawdzian. Tylko to, co do tej pory mam, zdaje się bardziej przypominać diagram iteracyjny niż stanowy. Mam wrażenie, że utknąłem i potrzebuję podpowiedzi. Czy nie jest tak, że stan "w trakcie" nie jest aż nadto ogólny, który mógłbym spróbować rozbić na mniejsze (pod)stany, w których z kolei miałbym zamodelowane stany odpowiedzi na pojedyncze pytania? Trochę podpieram się moją wizją docelowej aplikacji, więc stąd te zapędy na stan: "pytanie odpowiedziane" i pętlę z warunkiem "czy zakończyć sprawdzian?". Chyba utknąłem :( Pooomooocy!

02 lipca 2009

Z rozdziału 11. o uruchamianiu kodu Groovy z Java i na odwrót w "Programming Groovy"

0 komentarzy
W rozdziale 11. "Working with Scripts and Classes" w "Programming Groovy: Dynamic Productivity for the Java Developer" dowiadujemy się o uruchamianiu skryptów/aplikacji Groovy (ogólnie zwanych kodem Groovy) z poziomu aplikacji Java i na odwrót. Skryptem Groovy nazwiemy plik z kodem Groovy, który nie jest zawarty w ramach definicji klasy podczas, gdy kiedy jest, mówimy o aplikacji Groovy. Jeśli korzystamy ze skryptów Groovy, ich wywołanie z poziomu innego kodu Groovy będzie wymagało skorzystania z GroovyShell, podczas gdy dla kodu w Javie z motoru skryptowego JSR-223.

Kiedy uruchamiamy kod Groovy za pomocą polecenia groovy, kod jest kompilowany do bajtkodu w pamięci. Za pomocą polecenia groovyc kompilujemy do pliku .class, a później możemy wykorzystywać gdziekolwiek, gdzie korzystamy z "normalnych" klas (w końcu to jest klasa w postaci bajtkodu). Zero magii, poza dodaniem groovy-all-*.jar do ścieżki klas (CLASSPATH). I nikt się nawet nie zorientuje, że dostarczamy kod pisany w Groovy.

Uruchomienie klas Groovy z poziomu kodu Groovy wymaga jedynie umieszczenie pliku .groovy w ścieżce klas. Podczas uruchomienia Groovy przeszukuje ścieżkę w poszukiwaniu pliku o nazwie używanego typu z rozszerzeniem .groovy, a później .class.

Jeśli mamy kod Groovy w postaci pliku .groovy korzystamy z groovyc i jego funkcjonalności nazywanej współkompilacją (ang. joint compilation). Wywołujemy groovyc z opcją -j i plikami .java/.groovy, a w wyniku otrzymamy bajtkod - pliki .class. Nie jest konieczne uruchamianie kompilatora javac. Zajmie się tym groovyc. Przekazywanie parametrów do kompilatora javac jest możliwe dzięki opcji -J. Najlepiej skorzystać z rozwiązania dla narzędzia, którego używamy do organizowania pracy z projektem, np. Apache Ant, Apache Maven, czy Apache Buildr, czy jeszcze inne cudo. Wtedy konieczność dbania o konfigurację będzie wyłącznie raz i zapominamy o temacie. Kto ma to już za sobą, proszę o podzielenie się konfiguracją z resztą, np. w postaci wpisu u siebie na blogu, albo w komentarzu do tego wpisu (tym samym teraz tego nie pokażę licząc, że ktoś podejmie wyzwanie :)).

Mamy możliwość uruchomienia skryptów Groovy z poziomu Groovy dzięki metodzie GroovyShell.shell(), która zwraca wynik ostatniej instrukcji, np.:
 skrypt = """println 'Witamy w swiecie skryptu Groovy'"""
new GroovyShell().evaluate(skrypt)
albo po prostu
 evaluate(skrypt)
Przekazujemy parametry do tak wykonywanego skryptu przez obiekt binding, który przekazujemy do konstruktora GroovyShell. Przy takiej konfiguracji zmienne znane skryptowi wbudowanemu (przez kontekst przenoszony przez binding) mogą być zmieniane, jakby były przekazywane przez referencję. Jeśli chcielibyśmy odseparować zmienne wywołującego skryptu od wywoływanego, tworzymy nową instancję Binding i ustawiamy te, które chcemy przez setProperty().
 binding0 = new Binding()
binding0.setProperty('nazwa', 'wartosc')
shell = new GroovyShell(binding0)
shell.evaluate(skrypt)
Możemy przekazać parametry z linii poleceń do wywoływanego skryptu, jeśli zamiast evaluate() wykonamy go przez run().

Z poziomu kodu Java wykonujemy skrypty przez JSR-223, której implementacja dostępna jest w Java 6. Pozostawiam do zbadania na własną rękę, skoro z mechanizmem współkompilacji bądź tej kompilacji skryptu Groovy do .class możemy po prostu zająć się tematem wykonania klas Groovy, a to nie jest niczym odkrywczym. Po prostu działa. Nie zapominajmy o dodaniu biblioteki groovy-all-*.jar.

01 lipca 2009

Z rozdziału 10. o obsłudze baz danych w "Programming Groovy"

3 komentarzy
Rozdział 10. "Working with Databases" w "Programming Groovy: Dynamic Productivity for the Java Developer" Venkata Subramaniama przedstawia temat obsługi bazy danych. Krótki acz treściwy rozdział i wierzę, że relacja będzie co najmniej tak treściwa, a jednocześnie nie bardziej obszerna jak relacjonowany materiał.

Groovy SQL (GSQL) przesłania (przykrywa) JDBC udostępniając dodatkowy zestaw metod dostępowych do danych w bazie danych. Z pomocą GSQL możemy tworzyć zapytania SQL i korzystać z wbudowanych iteratorów do obsługi ich wyników.

Podłączamy się do bazy danych z pomocą groovy.sql.Sql.newInstance() podając namiary na bazę danych. Alternatywnie, jeśli mamy już obiekty java.sql.Connection lub java.sql.DataSource, możemy użyć je jako parametry wejściowe dla odpowiednich konstruktorów klasy groovy.sql.Sql zamiast oprzeć się na wspomnianej newInstance(). Informacje o aktywnym połączeniu otrzymujemy przez getConnection() lub po prostu przez atrybut connection na obiekcie Sql. Zamykamy "kramik" metodą close().

Po uwadze Krzyśka postanawiam zrezygnować z groovysh na rzecz groovyConsole, aby zrzuty poszczególnych skryptów Groovy były możliwe do czytania.

Do poprawnego uruchomienia skryptów do pracy z wybraną bazą danych potrzebujemy sterownika bazodanowego - w moim przypadku będzie to mysql-connector-java-5.1.7-bin.jar. Podobno dodanie jara do ścieżki klas groovyConsole jest możliwe przez menu Add Jar to ClassPath, ale u mnie nie dawało to oczekiwanych rezultatów i wciąż tylko miałem NCDFE.

Skończyło się na uruchomieniu groovyConsole z parametrem -cp.
 groovyConsole -cp "C:\apps\mysql-connector-java\mysql-connector-java-5.1.7-bin.jar"
Tym razem wszystko zagrało i mogłem uruchomić swój pierwszy skrypt z wyświetlenie rekordów z bazy
 def sql = groovy.sql.Sql.newInstance('jdbc:mysql://localhost:3306/groovymysqldb', 'root', 'passw0rd', 'com.mysql.jdbc.Driver')
println sql.connection.catalog
wyświetla oczekiwane "groovymysqldb".

Można również oprogramować dodanie jara do ścieżki klas.
 import groovy.sql.*

this.class.classLoader.rootLoader.addURL(new URL("file:C:/apps/mysql-connector-java/mysql-connector-java-5.1.7-bin.jar"))
def sql = Sql.newInstance('jdbc:mysql://localhost:3306/groovymysqldb', 'root', 'passw0rd', 'com.mysql.jdbc.Driver')
Baza została świeżo założona na potrzeby doświadczeń z GSQL, więc zaczynamy od utworzenia tabeli i kilku przykładowych rekordów za pomocą klasy DataSet. Wywołanie Sql.dataSet() z parametrem wskazującym na tabelę zwraca proxy (typu DataSet) do danych bez ich pobierania. Tworzenie nowych rekordów w bazie jest możliwe przez DataSet.add(), której parametrami wejściowymi są pary kolumna:wartość. Możemy również skorzystać z bardziej tradycyjnych metod jak Sql.execute() oraz Sql.executeInsert() podając na ich wejściu polecenia INSERT.
 import groovy.sql.*

def sql = Sql.newInstance('jdbc:mysql://localhost:3306/groovymysqldb', 'root', 'passw0rd', 'com.mysql.jdbc.Driver')
println "Korzystam z bazy: ${sql.connection.catalog}"
sql.execute("DROP TABLE pracownicy")
sql.execute("CREATE TABLE pracownicy(imie varchar(25), nazwisko varchar(25))")
def ds = sql.dataSet('pracownicy')
ds.add(imie: 'Jacek', nazwisko: 'Laskowski')
Zapytanie typu SELECT uruchamiamy metodą eachRow(), która na wejściu oczekuje zapytania (jako tekst) oraz domknięcia, które jest uruchamiane, dla każdego rekordu.
 // wraz z tym, co wyżej
println "[Imie]\t[Nazwisko]"
sql.eachRow('SELECT * from pracownicy') {
printf "%s\t%s\n", it.imie, it.nazwisko
}
W wyniku dostajemy:
 Korzystam z bazy: groovymysqldb
[Imie] [Nazwisko]
Jacek Laskowski
GroovyResultSet, który jest przekazywany domknięciu, pozwala na dostęp do kolumn po nazwie lub indeks.

Inna wersja eachRow(), poza samym zapytaniem, przyjmuje dwa domknięcia - pierwszy do obsługi metadanych bazy i jest wykonywana raz, a drugi, jak poprzednio, do obsługi rekordów. Przykładu nie będzie - należy zajrzeć do książki, bądź do dokumentacji Groovy (można zacząć od lektury Database features)

Możemy również skrócić obsługę wierszy do poziomu obsługi listy z rows(). Odczyt danych jest również możliwy przez each() (podobne do Sql.eachRow()). Dodając do tego możliwość zawężania wyników (filtrowania ich) dzięki findAll() otrzymujemy niezwykle efektywne narzędzie do wyciągania danych z bazy.

Mamy również do dyspozycji Sql.call() do uruchamiania procedur składowanych oraz Sql.withStatement(), które akceptuje domknięcie uruchamiane przed wykonaniem zapytania - interesująca opcja, jeśli chcemy wpływać na ostateczną postać zapytań zanim zostaną wysłane do bazy danych.

W połączeniu z mechanizmem budowniczych w Groovy (ang. Groovy builders) tworzenie XMLi z danych z danych w bazie to "kaszka z mleczkiem". Smacznego! :)
 // wraz z tym, co wyżej
bldr = new groovy.xml.MarkupBuilder()
bldr.pracownicy {
sql.eachRow("SELECT * from pracownicy") {
pracownik(imie: it.imie, nazwisko: it.nazwisko)
}
}
W wyniku mamy:
 Korzystam z bazy: groovymysqldb
<pracownicy>
<pracownik imie='Jacek' nazwisko='Laskowski' />
</pracownicy>
W sekcji 10.6 "Accessing Microsoft Excel" autor przedstawia sposób na tworzenie plików XLS na podstawie danych z bazy (przez sterownik JDBC-ODBC). Nic odkrywczego z punktu widzenia samego użycia JDBC-ODBC, ale prostota Groovy bije po oczach. Za Krzyśkiem w jego komentarzu do poprzedniego wpisu o Groovy "nie wszystko to zasługa dynamizmu!". Parafrazując szefo pingwinów: "I to jest coś, z czym mogę się pogodzić", bo wychodzę z założenia, że wiele można zrobić, tylko trzeba mieć na to chęć i czas. Skoro robię to w Groovy i uderza mnie jego prostota, to chcę, czy nie, kładę to na barki jego cech języka dynamicznego. Czasami sobie myślę, że warto by wprowadzić swego rodzaju ożywienie w naszych dyskusjach na blogach i odpowiadać na wpisy za pomocą...(kontr)aplikacji. Gdybym tak mógł poczytać wpisy, które pokazywałyby cechy Scali, F# czy Ocaml jako reakcję na te o Groovy byłoby bajecznie. Wchodzisz Krzysiek w temat? Rękawica leży i czeka na podniesienie :)