Jacek Laskowski - Notatnik Projektanta Java EE

Funkcyjne wyjście z REPL z (exit) i ankieta językowa

2009-11-13T15:25:00.002+01:00

Już dawno nie czułem takiej radości z tak niewielkiej ilości kodu. Chyba wciąż jestem przerażony liczbą nawiasów w Clojure, więc kiedy napisałem funkcję (exit) bezbłędnie za pierwszym razem, można sobie wyobrazić, jaki byłem szczęśliwy.

 user=> (def exit (fn [] (. System exit 0)))
 #'user/exit
 user=> (exit)

Brakowało mi tej funkcji w Clojure REPL, bo ^C, czy ^Z + ENTER pachniały mi jakąś niedoróbką. W tak niewielkiej funkcji udało mi się wykorzystać 3 istotne możliwości Clojure - definiowanie zmiennej przez def, której przypisano funkcję anonimową przez fn, która z kolei wykorzystuje integrację Clojure z Javą za pomocą specjalnej formy . (kropka). Ale ze mnie programista, co? :)

Można to jednak lekko podrasować i wykorzystać specjalną formę #(), która również definiuje funkcję anonimową. Owa funkcja anonimowa w niektórych kręgach nazywana jest...domknięciem (ang. closure). Domknięcie w Clojure nie różni się bardzo w porównaniu do tradycyjnego wywołania funkcji, ale tym razem owe wywołanie fn kończy się stworzeniem nowej. Funkcja, która operuje na innych, w tym zwraca je, nazywamy funkcją wyższego poziomu (ang. higher-order function).

Wracając do naszego #() to możnaby powyższe zapisać tak:

 user=> (def exit #(. System exit 0))
 #'user/exit
 user=> (exit)

Przeglądając kod źródłowy "Game of Life" Scotta Frasera trafiłem na metodę java.lang.Runtime.availableProcessors(), o której istnieniu nie wiedziałem. W zasadzie o wielu metodach jeszcze nie wiem i wiele z nich wywrze na mnie podobne, pozytywne wrażenie, aczkolwiek ta ma tą zaletę, że utwierdziła mnie w przekonaniu, że mój laptop faktycznie posiada procesor 2-rdzeniowy i 2 wątki powinny działać równolegle (biorąc pod uwagę działanie wszystkich innych programów w tle, pewnie tak nie będzie i jeden z wątków i tak będzie szybszy).

 user=> (def available-procs (.. java.lang.Runtime getRuntime availableProcessors))
 #'user/available-procs
 user=> (println available-procs)
 2
 nil

Zadanie dla wytrwałych: Jak zmienić def powyżej, aby możliwe było wykonanie (available-procs), który zwróci 2, tj.

 user=> (available-procs)
 2

p.s. Rozpocząłem kolejną ankietę odnośnie języków programowania "Jaki język programowania używasz poza Javą?" (jest na blogu po prawej u góry). Nie ma znaczenia, czy do zabawy, w projekcie, własnej ciekawości, czytasz o nim książkę, czy podobnie. Poświęcasz swój czas, więc wystarczy, aby określić go jako "używasz". Interesuje mnie, czy chociażby rozważasz alternatywę dla Javy i jaki to jest język. Wszystkie języki poza JVM wpadły do kategorii "Inne (poza JVM)". Głosujcie!

56. spotkanie Warszawa JUG - Jesienny Eclipse DemoCamp 2009

2009-11-12T21:02:00.000+01:00

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

Temat: Jesienny Eclipse DemoCamp 2009
Prelegenci: Michał Margiel, Łukasz Lenart, Jacek Laskowski, Sebastian Pietrowski, Tomasz Bujok

Tym razem forma spotkania będzie minikonferencją wokół produktów Eclipse Foundation, w której 5 prelegentów zaprezentuje rozwiązania w ciągu...20 minut każdy. Jeśli to nie przekonuje Cię o spędzeniu wtorkowego wieczoru w niezwykle porywającej atmosferze w gronie entuzjastów javowych, to może agenda?

18:00-18:20 Bądź leniwy - wykorzystaj ukrytą moc Eclipse, czyli jak robić by się nie narobić i wycisnąć max ze środowiska Michał Margiel
18:25-18:45 GoogleAppEngine - chmura na Ja(v)wie Łukasz Lenart
18:50-19:10 OpenEJB Eclipse Plugin - EJB 3.1 z Apache OpenEJB w Eclipse IDE Jacek Laskowski
19:15-19:35 Wprowadzenie do Cloud Foundry Sebastian Pietrowski
19:40-20:00 Po prostu monitoring, czyli jak zbudować skalowalną architekturę monitoringu w 20 minut za pomocą Spring, AOP i ActiveMQ Tomasz Bujok

Harmonogram niezwykle napięty, więc o nudzie nie może być mowy. W miłej atmosferze wiedza sama wchodzi do głowy, mimo późnej godziny.

Wstęp wolny, ale rejestracja wskazana.

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

(-> Clojure zrozumieć-makro-thread przeczytać-artykuł opisać-na-blogu)

2009-11-11T22:10:00.003+01:00

Zgodnie z sugestią Michaela zabrałem się za poznawanie Clojure od strony jego kodu źródłowego i podążając słowami mojego mistrza zabrałem się za makro ->, zwane również w kręgach Clojure jako makro "thread".

Kod źródłowy jest niezwykle mały i znajduje się w repozytorium Git - core.clj.

 (defmacro ->
   "Threads the expr through the forms. Inserts x as the
   second item in the first form, making a list of it if it is not a
   list already. If there are more forms, inserts the first form as the
   second item in second form, etc."
   ([x form] (if (seq? form)
               `(~(first form) ~x ~@(next form))
               (list form x)))
   ([x form & more] `(-> (-> ~x ~form) ~@more)))

Forma doc zwraca Clojure doc, czyli dokumentację funkcji będącej jej argumentem wejściowym, więc i bez kodu źródłowego możnaby się doczytać, co autor miał na myśli tworząc makro -> (mi to nie wystarczyło, ale pomyślałem, że wspomnę i o tej możliwości).

 user=> (doc ->)
 -------------------------
 clojure.core/->
 ([x form] [x form & more])
 Macro
   Threads the expr through the forms. Inserts x as the
   second item in the first form, making a list of it if it is not a
   list already. If there are more forms, inserts the first form as the
   second item in second form, etc.
 nil

Czytając dokumentację dosłownie, makro -> ma za zadanie wpleść wyrażenie do listy form. Wciąż mi to jednak niewiele mówi. Definicja -> składa się z dwóch przypadków - kiedy makro dostaje na wejściu dwa parametry i więcej. Forma (ang. form) to po prostu dwa nawiasy, w których są wywołania funkcji czy makr, lub ponownie form. I tak rekurencyjnie mamy całą masę par nawiasów. W Clojure *wszystko* jest w nawiasach, albo zastąpione pewnymi specjalnymi konstrukcjami - uproszczeniami rozpoznawanymi przez kompilator, które wychodzą poza ten schemat, np. przywoływana już konstrukcja tworzenia kluczy :nazwa jest równoznaczna z wywołaniem funkcji (keyword "nazwa") (często nazywanymi po angielsku "syntactic sugar").

Wykonanie -> z jednym parametrem, to po prostu jego zwrócenie.

 user=> (-> 2)
 2

To było proste! :) Teraz będzie znacznie trudniej. Jeśli na wejściu -> mamy dwa parametry, to rozpatrujemy przypadki - 1) forma jest sekwencją (seq? zwraca prawdę) i 2) kiedy nie jest. Przy okazji, nazwy funkcji, których wynikiem jest wartość logiczna true/false są zakończone ? (znak zapytania).

Weźmy ponownie coś równie prostego jak poprzednio.

 user=> ; w nawiasie mamy funkcję minus i jej jedyny argument 3
 user=> (-> 2 (- 3))
 -1

Dlaczego? Analizując kod źródłowy -> dochodzimy do wniosku, że jest to równoznaczne z poniższym.

 user=> (- 2 3)
 -1

Pierwszy argument dla -> jest na drugiej pozycji w pierwszej formie, którą było (- 3). Można jeszcze sprawdzić, jaki był wynik if'a w makro ->.

 user=> (seq? (- 3))
 false

Zatem wyliczenie (-> 2 (- 3)) sprowadza się do konstrukcji (list form x), tj. (list - 3 2), a to daje:

 user=> (list - 3 2)
 (#<core$___4506 clojure.core$___4506@16de49c> 3 2)

Sprawdźmy, co da wywołanie tego funkcją eval.

 user=> (eval (list - 3 2))
 1

Źle! Chyba popełniłem jakiś błąd w rozumowaniu, jaki argument jest przekazywany do seq?, bo w końcu zgodnie z definicją formy, zapis (- 3) nią jest! Biorąc więc pod uwagę moje niedoświadczenie i możliwe pomyłki w rozumowaniu, wchodzimy w sekcję if'a, bo wtedy wszystko jest cacy - 2 staje się drugim argumentem dla odejmowania, a 3 trzecim. Owe szlaczki w makro to sposób na tworzenie kodu w fazie wczytywania programu w Clojure (zaraz przez kompilacją i uruchomieniem), w której następuje rozwiązywanie makr, których celem jest uproszczenie życia programistom przez generowanie bardziej złożonego kodu (po co klepać kilkakrotnie to samo w wielu liniach, jeśli możemy zdefiniować makro raz i wywoływać wielokrotnie w jednej?! "Cudo" znane programistom C/C++).

Wciąż jednak nie rozumiałem, co jest takiego specjalnego w tym makro, aż trafiłem na LexParse, gdzie padła wzmianka o potoku (ang. pipeline). Teraz było znacznie łatwiej zrozumieć, co autor miał na myśli. Aczkolwiek do pełnego zrozumienia daleko (pewnie za mało wciąż napisanych programów w Clojure).

 user=> (-> 2 {2 "dwa"} {"dwa" "DWA"})
 "DWA"

Spróbuj samodzielnie znaleźć odpowiedź dlaczego w wyniku otrzymaliśmy "DWA", albo poniżej true:

 user=> (-> '(0 0 0) (count) (odd?))
 true

Doświadczenia z Clojure skończyłem artykułem Clojure - Functional Programming for the JVM, którego autorem jest R. Mark Volkmann. Tam znalazłem wzmiankę o Simon Peyton-Jones, który włożył wiele wysiłku w Haskella (czysty język funkcyjny) i miał powiedzieć w OSCON 2007 - Simon Peyton-Jones - A Taste of Haskell Part I:

"In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."

i dalej już od autora artykułu: The key is to limit side effects, clearly identify them, and avoid scattering them throughout the code.

Warto również wspomnieć o leniwym rozwiązywaniu/wyliczaniu sekwencji - leniwych sekwencjach (ang. lazy sequences) (a może trafniej będzie nazywać je opóźnionymi czy nawet ospałymi czy w końcu uśpionymi sekwencjami?). Elementy w sekwencji nie są wyliczane, aż do momentu ich użycia, co pozwala na tworzenie nieskończonych ciągów danych bez narażania się na wysycenie sterty pamięci JVM. Ta cecha Clojure uzmysłowiła mi o możliwym podejściu w Javie, w której zwykle (zawsze?) wyliczamy wszystkie elementy, nawet jeśli ich nie potrzebujemy. Weźmy za przykład tablicę 150-elementową, albo jeszcze dłuższą. W Javie, w zależności od typu elementów, wielkość potrzebna na ich przechowanie musi być dostępna w trakcie deklaracji. Alternatywą mogłoby być stworzenie takiej kolekcji, w której podajemy liczbę elementów i tyle, a kiedy potrzebny będzie piąty, dziesiąty, czy którykolwiek inny element, wyliczamy go dokładnie w momencie zapytania o niego. Nie sądzę, abym kiedykolwiek myślał o programowaniu w Javie w ten sposób (może dlatego, że po prostu nie miałem okazji?!). Na szczęście nie musimy już tego implementować w Javie, bo mamy Clojure, więc chociażby dla tego warto zwrócić się ku niemu.

Bardzo przypadł mi do gustu następujący akapit:

Is Clojure code hard to understand? Imagine if every time you read Java source code and encountered syntax elements like if statements, for loops, and anonymous classes, you had to pause and puzzle over what they mean. There are certain things that must be obvious to a person who wants to be a productive Java developer. Likewise there are parts of Clojure syntax that must be obvious for one to efficiently read and understand code.

Podobnie będzie z dowolnym językiem mówionym - angielski prosty, niemiecki również, pewnie podobnie z francuskim, czy hiszpańskim, nie wspominając o rosyjskim czy w ogóle słowiańskich. Nasłuchaliśmy się ich wokoło i teraz po prostu przywykliśmy do ich konstrukcji. Brakuje nam zrozumienia ich semantyki, więc chodzimy na drogie kursy licząc, że cudem bez specjalnego wysiłku mentalnego wejdą nam w przysłowiowe 5 minut. Wtedy również zadamy sobie pytanie o sensowność nauki kolejnego języka skoro mówimy, piszemy i czytamy po angielsku. Przypomina mi to pytanie o sensowność uczenia się Clojure. Po co się go uczyć skoro znamy Javę? Po co uczyć się kolejnego języka mówionego, znając angielski? Dla mnie, odpowiedź nasuwa się sama - z ciekawości, co tracimy nie potrafiąc posługiwać się językiem, którym władają inni. Czy Clojure jest tym językiem, który należałoby poznać? Nie wiem. Wiem jednak, że należy chociażby spróbować zrozumieć programowanie funkcyjne, aby zastosować go tam, gdzie programowanie obiektowe czy imperatywne nie przystaje. Jeśli znamy tylko OO, to jak tu mówić o zdrowym rozsądku? Dobrze ujął to Abraham Maslow:

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

bądź, jak to jest częściej przywoływane:

If the only tool you have is a hammer, you tend to see every problem as a nail.

Niestety nie wiem, jak miałoby to brzmieć po polsku :(

Właśnie kiedy miałem opublikować wpis, zajrzałem jeszcze do źródeł Clojure i trafiłem na funkcję clojure-version. Trywialna, aczkolwiek wciąż pouczająca implementacja (której pewnie jeszcze samodzielnie nie dałbym rady napisać):

 user=> (clojure-version)
 "1.1.0-alpha-SNAPSHOT"

Jeśli doczytałeś/-aś do tego miejsca, to może i wytrwałeś/-aś z czytaniem podanego wyżej artykułu o Clojure. Jeśli tak, to w sekcji o mapach (Maps) jest wzmianka o...makrze -> (!)

The -> macro, referred to as the "thread" macro, calls a series of functions, passing the result of each as an argument to the next. For example the following lines have the same result:

(f1 (f2 (f3 x)))
(-> x f3 f2 f1)

Teraz już jest jasne, co makro -> robi. W ramach nauki Clojure pozostaje więc nauczyć się jego implementacji na pamięć, aby kolejnym razem napisać podobne.

Środowisko programistyczne dla Clojure i poprzedni przykład funkcjonalniej

2009-11-10T23:09:00.000+01:00

Nasze praktyczne przygody z Clojure możemy zacząć od instalacji wymaganego oprogramowania i/lub uruchomienia Clojure REPL lokalnie, albo skorzystać z Lord of the REPLs. Interesująca alternatywa, nie tylko pomocna w nauce Clojure, ale i Groovy, Ruby czy Scala.

Kiedy jednak nasze doświadczenie w programowaniu funkcyjnym w Clojure zacznie wykraczać poza proste aplikacje będące złożeniem kilku funkcji i spróbujemy wyjść poza ramy REPL możemy skorzystać ze wsparcia udostępnianego przez zintegrowane środowiska programistyczne, np. NetBeans IDE, Eclipse IDE czy IntelliJ IDEA. Wystarczy doszukać się właściwej wtyczki (rozszerzenia) i możemy czerpać garściami z pomocy IDE - możemy chociażby znieść z siebie trud dbania o nawiasy. Dla NetBeans IDE mamy Enclojure. Ostatnia wersja z 3.11, więc dostatecznie świeża, aby uwierzyć w aktywny jej rozwój. Dla środowiska Eclipse IDE mamy Clojure plug-in for Eclipse (clojure-dev), o której dowiedziałem się w artykule The Clojure programming language - Take advantage of the Clojure plug-in for Eclipse. Stawiam na NetBeans IDE i Enclojure.

Dla bloggerów istnieje podświetlanie składni dla Clojure w ramach Syntax Highlighter 2.0 - All Syntax Highlighter 2.0 brushes collected, described and downloadable. Można zobaczyć go w działaniu w moich wpisach dotyczących Clojure, chociażby ten. Jeśli więc przyjdzie zaprezentować swoje cudo w Clojure szerokiej publiczności na własnym blogu warto podeprzeć się stylem clojure. Znacznie uatrakcyjnia prezentację kodu.

A skoro mamy środowisko możemy powrócić do naszego przykładu z surowcami, której wersja bardziej przypominająca wersję funkcjonalną (dosłownie i w przenośni) wygląda teraz następująco:

 (ns pl.jaceklaskowski.clojure)

 (defn czas-zwiekszenia-produkcji
  "Wylicza potrzebny czas (w minutach) do osiagniecia stanu magazynowego na uruchomienie rozbudowy do poziomu przy danej produkcji"
  [docelowo, magazyn, produkcja]
  (let [teraz (java.util.Calendar/getInstance)]
   (. teraz (add (java.util.Calendar/MINUTE)
    (* 60 (reduce max (map / (map - (map #(.getValue %) docelowo) (map #(.getValue %) magazyn)) (map #(.getValue %) produkcja))))))
   (. teraz getTime)))

Widać wyraźne zwiększenie konstrukcji PF z reduce i map. Poza samym wyliczeniem, za ile nastąpi zwiększenie (w linii 8.) mamy również wyliczoną dokładną godzinę, kiedy to nastąpi (linie 6., 7. i 9.)

Zamiast dłubania w REPL zapisujemy cały program w pliku czas-zwiekszenia-produkcji.clj. Zwyczajowo skrypty w Clojure zapisywane są z rozszerzeniem .clj.

Tworzymy kolejny skrypt testowy skrypt-testowy.clj, który zweryfikuje poprawność działania.

 (load-file "czas-zwiekszenia-produkcji.clj")

 (ns pl.jaceklaskowski.clojure)

 (def magazyn {:drewno 10 :glina 10 :zelazo 10 :zboze 10})
 (def docelowo {:drewno 20 :glina 20 :zelazo 20 :zboze 20})
 (def produkcja {:drewno 5 :glina 5 :zelazo 5 :zboze 5})

 (println (czas-zwiekszenia-produkcji docelowo magazyn produkcja))

Uruchomienie to po prostu wykonanie:

 $ java -jar clojure-1.1.0-alpha-SNAPSHOT.jar skrypt-testowy.clj
 #<Date Tue Nov 10 23:36:07 CET 2009>

I tak kończy się moje poszukiwanie ładniejszej (=bardziej funkcyjnej) wersji czas-zwiekszenia-produkcji. Oczywiście nie kończy to mojej przygody z Clojure i jeśli kiedykolwiek pomyślałem, aby sobie odpuścić, bo i po co mi PF, to wizyta na blogu BEST IN CLASS jest faktycznie najlepszym w swojej klasie i nie pozwala zapomnieć o możliwościach Clojure. Warto tam zajrzeć w wolnej chwili, szczególnie w chwilach zwątpienia. Mnie zachwycił i upewnił w postanowieniu poznania go dokładniej.

W kolejnym podejściu postaram się zrozumieć o co chodzi w makro -> oraz funkcji line-seq z core.clj jak zasugerował Michael w komentarzu do ostatniego mojego wpisu o Clojure - Programowanie w Clojure - część 2 - pierwszy przykład z wyliczaniem surowców.

Programowanie w Clojure - część 2 - pierwszy przykład z wyliczaniem surowców

2009-11-08T13:28:00.004+01:00

Nasze ćwiczenia z programowania w Clojure zaczniemy od uruchomienia Clojure REPL (Read-Eval-Print-Loop). Clojure REPL jest niczym innym jak interaktywnym interpreterem dla Clojure.

 jlaskowski@work /cygdrive/c/oss/clojure
 $ java -jar clojure-1.1.0-alpha-SNAPSHOT.jar
 Clojure 1.1.0-alpha-SNAPSHOT
 user=>

Od tej pory zakładam, że wiemy, w jaki sposób dostać znak zachęty jak wyżej.

Powiedzmy, że chcemy wyliczyć liczbę surowców do wybudowania pewnej jednostki (w szczególności podniesienia poziomu samego surowca, aby dawał znacznie większą produkcję niż obecnie). Mamy 4 rodzaje surowców, które nazwiemy: drewno, glina, żelazo i zboże. Całkiem typowe w wielu grach strategicznych. Na celownik weźmiemy Traviana. Trochę czasu mi z nim zeszło i zawsze zastanawiałem się, czy jestem w stanie stworzyć system-bota, który podpowiadałby mi najlepszą strategię. Ktoś kiedyś wspominał coś o programowaniu nieliniowym odnośnie tego rodzaju kalkulacji, ale pojawiała się również wzmianka o programowaniu funkcyjnym. Ile w tym prawdy nigdy nie doszedłem, jednakże tym razem mam możliwość choć po części sprawdzić się w Clojure jako języku funkcyjnym do rozwiązania, albo chociaż próby rozwiązania, tego problemu. To byłby taki system ekspertowy, który podpowiadałby mi różne strategie (pewnie za nim stoi cała masa teorii matematycznej z różnymi modelami, ale ja wybieram podejście naiwne bez zebrania wcześniej wystarczającej wiedzy, tj. "na żywioł" :)). Do zbudowania gliny na 1. poziomie (tak, z każdą jednostką mamy związaną cechę - poziom) potrzeba 80 drewna, 40 gliny, 80 żelaza i 50 zboża (patrz 1.1.11 Kopalnia gliny). Każda wioska ma swoją produkcję i zakładam, że początkowo produkcja jest na 0. Najpierw spróbuję odpowiedzieć na pytanie, ile czasu potrzeba, abym podniósł produkcję gliny przy aktualnym stanie magazynu i produkcji surowców.

Mamy więc założenia do funkcji, którą w Javie moglibyśmy nazwać obliczCzasDoZwiekszeniaProdukcji(surowca, naPoziom, przyObecnymStanieMagazynowym, przyObecnejProdukcji). Nazwy funkcji w Clojure są zazwyczaj ciągiem słów oddzielonych myślnikami, co daje w naszym przypadku czas-zwiekszenia-produkcji (zakładając, że celem funkcji jest obliczenie czegoś nie widzę potrzeby powtarzania tego w nazwie funkcji).

Zaczynam od definicji magazynu. Będzie to mapa, która w Clojure deklarowana jest przez {} (nawiasy klamrowe), między którymi ciąg elementów tworzy pary klucz-wartość. Przecinki są opcjonalne i traktowane dokładnie jak spacja, czyli taki zapis

 user=> (def magazyn {:drewno 0 :glina 0 :zelazo 0 :zboze 0})
 #'user/magazyn

jest równoznaczny takiemu:

 user=> (def magazyn {:drewno 0, :glina 0, :zelazo 0, :zboze 0})
 #'user/magazyn

W definiowaniu mapy skorzystałem z możliwości definiowania słów kluczowych w Clojure z użyciem : (dwukropek). Wartością słów kluczowych są one same, więc idealnie nadają się na klucze w mapie.

 user=> :cokolwiek
 :cokolwiek

Jak większość (wszystko?) w Clojure, tak i mapa jest funkcją, której pojedynczym argumentem jest klucz.

 user=> (magazyn :drewno)
 0

Również odwrotne spojrzenie jest poprawne, tj. słowa kluczowe są również funkcją, której argumentem jest mapa, w której się odszukują (!)

 user=> (:drewno magazyn)
 0

Takie spojrzenie na mapę i jej kluczy było dla mnie niezwykłym doświadczeniem mentalnym :) W sumie to logiczne, aby potraktować w ten sposób struktury danych, a zmienia całkowicie moje dotychczasowe spojrzenie obiektowe. Skoro wszystko jest funkcją, jedynym problemem pozostaje poznanie ich zasady działania (semantyki). Niby proste i pamiętam, że kiedy uczyłem się żonglować, co wydawało mi się początkowo niezwykle trudne i w zasadzie poza zasięgiem, kiedy oduczyłem się złego sposobu podawania piłeczki z ręki do ręki, nauczenie się poprawnie przez przerzucanie piłeczek było dziecinnie proste. Mówi się, że jedynym problemem w nauce nowego są nasze własne przyzwyczajenia i obawy. Chyba dlatego tak trudno jest się uczyć z wiekiem - zbyt wiele doświadczenia, które nas ogranicza?!

Do definicji funkcji w Clojure używamy defn, w której w cudzysłowach dodajemy opis funkcji, a w nawiasach kwadratowych parametry wejściowe.

 (defn czas-zwiekszenia-produkcji
  "Wylicza potrzebny czas do zwiekszenia produkcji surowca na danym poziom przy danym stanie magazynowym i produkcji"
  [surowiec, poziom, stanMagazynowy, produkcja]
  ...
 )

Chwilowo zamiast parametru wejściowego poziom będącym liczbą całkowitą przekażemy mapę z potrzebnymi surowcami do przejścia na dany poziom.

 user=> (def poziom1 {:drewno 80 :glina 40 :zelazo 80 :zboze 50})
 #'user/poziom1

W takim przypadku sam surowiec nie ma znaczenia, bo w końcu na wejściu mamy stan początkowy (stan magazynowy), stan docelowy i produkcję (przyrost jednostek w czasie 1h). Definicja funkcji mogłaby wyglądać tak:

  (defn czas-zwiekszenia-produkcji
  "Wylicza potrzebny czas do osiagniecia stanu magazynowego na uruchomienie rozbudowy do poziomu przy danej produkcji"
  [stanDocelowy, stanMagazynowy, produkcja]
  ...
 )

Wszystkie parametry wejściowe są mapami.

Wywołanie funkcji w Clojure jest listą, której pierwszym elementem jest nazwa funkcji, a po nim następują parametry wejściowe.

 user=> (czas-zwiekszenia-produkcji docelowo magazyn produkcja)

Dodając do tego możliwość importowania typów javowych przez import oraz ich wywoływania przez . (kropka) czy / (ukośnik) otrzymujemy ostatecznie następujący program w Clojure do obliczania czas potrzebnego do zwiększenia produkcji surowca przy danym magazynie i bieżącej produkcji.

 (def magazyn {:drewno 10 :glina 4 :zelazo 15 :zboze 0})

 (def produkcja {:drewno 5 :glina 2 :zelazo 5 :zboze 4})

 (def glina1 {:drewno 80 :glina 40 :zelazo 80 :zboze 5})

 (import '(java.util Calendar))

 (def teraz (Calendar/getInstance))

 (defn czas-zwiekszenia-produkcji
  "Wylicza potrzebny czas (w minutach) do osiagniecia stanu magazynowego na uruchomienie rozbudowy do poziomu przy danej produkcji"
  [docelowo, magazyn, produkcja]
  (max
   (/ (- (docelowo :drewno)(magazyn :drewno)) (produkcja :drewno))
   (/ (- (docelowo :glina)(magazyn :glina)) (produkcja :glina))
   (/ (- (docelowo :zelazo)(magazyn :zelazo)) (produkcja :zelazo))
   (/ (- (docelowo :zboze)(magazyn :zboze)) (produkcja :zboze)))
 )

 (. teraz add (Calendar/MINUTE) (* 60 (czas-zwiekszenia-produkcji glina1 magazyn produkcja)))

 (. teraz getTime)

Kopiując każdą z linii do REPL mamy:

 $ java -jar clojure-1.1.0-alpha-SNAPSHOT.jar
 Clojure 1.1.0-alpha-SNAPSHOT
 user=> (def magazyn {:drewno 10 :glina 4 :zelazo 15 :zboze 0})
 #'user/magazyn
 user=> (def produkcja {:drewno 5 :glina 2 :zelazo 5 :zboze 4})
 #'user/produkcja
 user=> (def glina1 {:drewno 80 :glina 40 :zelazo 80 :zboze 5})
 #'user/glina1
 user=> (import '(java.util Calendar))
 java.util.Calendar
 user=> (def teraz (Calendar/getInstance))
 #'user/teraz
 user=> (defn czas-zwiekszenia-produkcji
  "Wylicza potrzebny czas (w minutach) do osiagniecia stanu magazynowego na uruchomienie rozbudowy do poziomu przy danej produkcji"
  [docelowo, magazyn, produkcja]
  (max
   (/ (- (docelowo :drewno)(magazyn :drewno)) (produkcja :drewno))
   (/ (- (docelowo :glina)(magazyn :glina)) (produkcja :glina))
   (/ (- (docelowo :zelazo)(magazyn :zelazo)) (produkcja :zelazo))
   (/ (- (docelowo :zboze)(magazyn :zboze)) (produkcja :zboze)))
 )
 #'user/czas-zwiekszenia-produkcji
 user=> (. teraz add (Calendar/MINUTE) (* 60 (czas-zwiekszenia-produkcji glina1 magazyn produkcja)))
 nil
 user=> (. teraz getTime)
 #<Date Mon Nov 09 07:16:59 CET 2009>

Wersja bardziej funkcyjna z map i reduce w kolejnym wpisie. Zdecydowanie zbyt wiele w tej wersji argumentów do max. Można się zapisać na śmierć z tymi kluczami w mapach i samym wprowadzaniem programu do wykonania. Wasze propozycje mile widziane, bo moja przygoda z programowaniem funkcyjnym z Clojure dopiero się zaczęła i wpadki są wręcz oczekiwane.

55. spotkanie Warszawa JUG - "Zastosowanie BPELa w praktyce" Rafała Rusina i Macieja Próchniaka

2009-11-05T21:11:00.002+01:00

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

Temat prezentacji: Zastosowanie BPEL'a w praktyce przy użyciu Apache ODE, Apache ServiceMix i SoapUI
Prelegenci: Rafał Rusin (TouK), Maciej Próchniak (TouK)

W trakcie prezentacji Rafał i Maciej opowiedzą o połączeniu Apache ODE i Apache ServiceMix. Rozpoczniemy od wstępu do BPELa i jego ideologii oraz prostego przykładu połączenia kilku serwisów ODE z ServiceMixem. Będzie to podstawą do omówienia różnych kwesti, które sprawiły im najwięcej trudności podczas projektu i sposoby ich rozwiązywania. SoapUI znajdzie swoje miejsce w arsenale programisty jako wygodne narzędzie do testowania serwisów.

Rafał Rusin jest absolwentem Uniwersystetu Warszawskiego. W TouK pracuje od 2004 roku. Zajmowałem się developmentem i architekturą wielu komercyjnych projektów w tym czasie. Tematyka procesów biznesowych towarzyszyła mu już w tamym okresie. Ostatnio postanowił zastować projekt Apache ODE do większego projektu komercyjnego, który sprawił, że pojawiło się kilka poprawek i rozszerzeń ODE, co z kolei skończyło się nieoczekiwanym zaproszeniem Rafała jako członka zespołu sterującego Apache ODE PMC.

Maciej Próchniak jest absolwentem matematyki Uniwersystetu Warszawskiego. W poprzednich latach tworzył w Javatechu aplikacje webowe. Obecnie zajmuje się utrzymaniem oraz testowaniem procesów biznesowych napisanych w BPELu, a także architekturą i implementacją komponentów ServiceMix'owych.

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

Wstęp wolny!

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

(wady) Agile - Dyskusja

2009-11-03T23:35:00.002+01:00

Najwyraźniej ostatnia Warsjawa 2009 (patrz moja relacja Wrażenia z sobotniej, zwinnej Warsjawy 2009) pokazała niedosyt "lekkich" tematów o Scrumie/Agile podczas spotkań i konferencji organizowanych przez Warszawa JUG, bądź też w samej Warszawie. Na forum grupy rozgorzała dyskusja [warszawa-jug] (wady) Agile - Dyskusja, w której moim faworytem stał się nieznany mi wcześniej Adam Lider (nota bene, nazwisko mówi samo za siebie), który napisał (cytuję za pozwoleniem Adama w całości):

Po kilku latach doswiadczenia z lekkimi metodykami jestem sceptycznie nastawiony do Scruma. Uwazam ze jest to metoda, ktora moze nawet wyrzadzic krzywde filozofii Agile. Wytwarzanie oprogramowania jest rzemioslem trudnym, wymagajacym wiedzy, doswiadczenia, a przede wszystkim dyscypliny. Aby dojsc do "mistrzostwa" trzeba po prostu duzo pracy. Natomiast Scrum jest czesto widziany jako rozwiazanie dla zespolow, ktore sobie nie radza. Niestety zdecydowana wiekszosc tych zespolow zbudowana jest z malo lub srednio doswiadczonych ludzi i Scrum moze im niewiele pomoc a nawet zaszkodzic, poprzez koncepcje samoorganizujacego sie zespolu. Jak ja moge wiedziec co jest dla mnie dobre skoro malo jeszcze doswiadczylem? Najczesciej nie wiem. Co wiecej wprowadzenie Scruma do takich zespolow wprowadza rodzaj sztucznego uporzadkowania, w ktorym czesto wieksza wage przewiazuje sie do pielegnacji Scruma niz projektu. Tam gdzie Scrum dziala to najczesniej zespoly zbudowane z bardzo dobrych ludzi, a Scrum jest tylko (bardzo waznym) smarem dla dobrego mechanizmu.Dla zespolow mniej doswiadczonych zdecydowanie bardziej polecam XP. Dla mnie glowna roznica w stosunku do Scruma to zdecyowanie wiekszy nacisk na czysto techniczne praktyki tj. TDD, No bugs, Done Done z podkresleniem, ze musisz stosowac wszystko i nie jutro, ale dzisiaj. Praktykowanie TDD nie jest latwe i wiekszosc mniej doswiadczoncyh zespolow pracujacych pod etykieta Scrum (lub bez) po prostu odklada w czasie zastosowanie tej (lub innych rownie wymagajacych) praktyki (w koncu sami sie organizujemy i skoro to dla nas trudne, mozemy to zaczac pozniej). Jak sie ma kiepskich rzemieslnikow to Scrum niewiele pomoze. To troche tak jak z nasza reprezentacja pilki noznej - czy wierzycie ze z super taktyka super trenera nasi kopacze zdobyliby puchar w 2012? Moze i zagraliby lepiej, a moze wrecz przeciwnie bo np. kluczem dla taktyki bylaby gra z pierwszej pilki, a to trzeba umiec.

Moj glowny zarzut dla tej metody to proba wmowienia, ze wytwarzanie oprogramowania moze byc efektywne i dosc latwe (ze Scrumem), z niedostateczny podkresleniem wagi rzemiosla zespolu i jego czlonkow.

Ta wypowiedź dokładnie wyraża mój pogląd na temat lekkich metodyk, które mimo swojej nazwy nie są wcale lekkimi we wdrożeniu, bo ich lekkość jest zauważalna dopiero, kiedy zespół jest doświadczony, aby pozwolić sobie na samoorganizowanie i dyscyplinę pracy. Skąd niby członkowie młodych zespołów (doświadczeniem nie wiekiem) mieliby wiedzieć, czego chcą, jeśli ich jedyną potrzebą jest skończyć projekt (nic nadzwyczajnego, normalka) w technologi, którą dopiero poznają, bo wszyscy wkoło mówili, że fajna?! Przejaskrawiam z tą nową technologią, ale traktuję go jedynie jako przykład i możnaby tutaj podstawić wszystko inne, które kojarzy nam się z fantazją młodych zespołów. Tutaj podkreślam, że zwykle w takich zespołach panuje przekonanie, że fajna technologia będzie panaceum na brak doświadczenia zespołu oraz skróci czas, tak że projekt nie tylko, że zakończy się w założonym czasie, ale i budżecie (!) Marzenia ściętej głowy, co? Powiedziałbym, że zwinny zespół można budować z osób, które samodzielnie również potrafiliby poprowadzić ten projekt tyle, że zajęłoby im to więcej czasu. Siła doświadczonych inżynierów wynika z ich pragmatycznego podejścia do tematu i świadomości, że po ciekawym poranku z kawką i eclipsową wtyczką do pudelka (ukłon w stronę Mateusza) przyjdzie im ciężko popracować przy zadaniu. Jeśli do tej ciężkiej pracy dodamy niezwykle wyrafinowany funkcjonalnie superszkielet aplikacyjny, to mamy dwa podejścia, idziemy z nim w szranki i konkury, aby go poznać, a wtedy wdrażamy, albo po prostu zarzucamy, bo z naszych obliczeń wynika, że albo on albo my. To nazywam pragmatycznym podejściem. Mamy świadomość, że nie wszystko teraz i zaraz, że niektóre superrozwiązania jeszcze na nas poczekają. Takiej świadomości nie możemy oczekiwać od niedoświadczonych członków zespołu.

A Ty jak uważasz? Pewnie nie tylko ja jestem zainteresowany Twoim zdaniem, więc podejmij temat i wyraź swoją opinię na forum w wątku [warszawa-jug] (wady) Agile - Dyskusja.

Programowanie w Clojure - część 1 - tytułem wstępu

2009-11-01T23:05:00.004+01:00

Jedną książkę o Clojure mam już za sobą (patrz recenzja Book review: Programming Clojure), a kolejna jest w trakcie pisania - Practical Clojure (The Definitive Guide), więc jeśli miałbym poczuć klimaty programowania w języku funkcyjnym z użyciem Clojure, nie pozostaje mi nic innego jak po prostu zacząć w nim programować. Nie planuję wielkich programów, ale przynajmniej przećwiczę te elementy języka, które oznaczyłem sobie jako ciekawe podczas lektury Programming Clojure Stuarta Halloway'a.

Jest wiele cech różniących programowanie funkcyjne od programowania obiektowego, ale podstawowym mogłyby być "czyste" funkcje (ang. pure functions), których wynik działania zależy wyłącznie od parametrów wejściowych, a nie od aktualnego stanu aplikacji czy innych ukrytych źródeł danych możliwych do wykorzystania w implementacji funkcji. Wiemy, że te same dane dają ten sam wynik bez względu na moment, w jakim funkcja została wykonana. Programowanie z czystymi funkcjami nie jest obce programistom javowym. W Javie to my jednak decydujemy, czy tworzona funkcja jest czysta (bez efektów ubocznych), czy nie. Wszystko zależy od implementacji. W programowaniu funkcyjnym może to być w ogóle niemożliwe do realizacji, albo wymaga specjalnych słów kluczowych w języku, które explicite oznaczą funkcję, jako posiadającą efekty uboczne. Możnaby powiedzieć, że w Javie też tak jest, bo pewne konstrukcje mówią nam, czy skutkują efektem ubocznym, czy nie, ale to wymaga analizy implementacji, podczas gdy w Clojure jedynie wyszukania odpowiednich słów kluczowych obejmujących sekcje modyfikujące.

Kolejną składową programowania funkcyjnego są niezmienne struktury danych (ang. immutable data structure). Każda operacja na strukturze danych powoduje jej skopiowanie i wykonanie operacji. Każdorazowo dostajemy kopię struktury wejściowej.

Łącząc obie cechy programowania funkcyjnego, efekty uboczne (ang. side effects) nie wystąpują w ogóle, albo są wyjątkiem a nie regułą. Tym samym testowanie aplikacji jest prostsze. Sprawdzamy, czy dla tego samego wejścia mamy to samo wyjście i tyle. Podobnie z programowaniem współbieżnym (równoległym). Skoro wszystkie struktury są niezmienne, a działanie funkcji zwraca ich kopię, to nie ma czego synchronizować (!) Idąc dalej, programowanie funkcyjne daje możliwość zrównoleglania obliczeń, skoro wynik działania funkcji zależy wyłącznie od danych wejściowych, a kolejność obliczeń składowych funkcji złożonej nie ma znaczenia. I dalej, jeśli wykonamy funkcję czystą z parametrami wejściowymi, które będą wykorzystane w kolejnym wywołaniu, możemy zoptymalizować takie wywołanie podstawiając wynik poprzedniego wywołania funkcji - umieścić wynik w pamięci podręcznej i kosztem funkcji będzie jedynie odczyt z pamięci.

Nie ma nic za darmo. W końcu, gdyby taka słodycz płynęła z programowania funkcyjnego, zamiast programowania imperatywno-obiektowego w Javie pisalibyśmy aplikacje w Haskellu, OCamlu, MLu, czy microsoftowym F#. Coś jest na rzeczy, że bliżej nam do imperatywnego myślenia niż funkcyjnego, podobnie jak z bazami danych, które przyzwyczailiśmy się postrzegać relacyjnie, a oprogramowywać dostęp do ich danych obiektowo (stąd powód dla rozwiązań ORM). Dobrze jednak mieć wybór. Clojure jest językiem uruchamianym na JVM z całym dobrodziejstwem inwentarza, a wprowadza nas w świat programowania funkcyjnego, w którym niektóre problemy rozwiązuje się prościej. Miejmy po prostu świadomość istnienia Clojure, podobnie jak Groovy, Scala, JRuby, Jython, Erlang, itp. i dobierajmy narzędzie do problemu, a nie komplikujmy problem, aby dopasować i rozwiązać go znanymi technikami.

Nie mam jeszcze wyrobionego zdania nt. Clojure i jego użycia w projektach. Próbuję wierząc, że komentarze i dyskusje dadzą mi odpowiedź, czy jest warto. Jedna książka to zdecydowanie za mało, aby wyrobić sobie pogląd na temat zastosowania Clojure w projektach. Skoro znalazła się osoba Rich Hickey, która stworzyła kolejny język funkcyjny Clojure, tym razem działający na JVM, to musi w tym być jakaś ukryta wiedza, której zrozumienie nie jest mi jeszcze dane. Kładę to raczej na barki mojego intelektualnego niedorozwoju niż braku sensu w powstaniu Clojure. Kiedy będę mógł porównać Javę do Clojure i wskazać zalety jednego względem drugiego, nawet jeśli skończy się na wyrzuceniu Clojure jako niepotrzebnego, mam nadzieję, że mimo wszystko nie będzie to czas stracony. Podkreślam słowo nadzieja. Aktywność na grupie dyskusyjnej użytkowników Clojure wskazuje, że język ma swoje poletko, w którym sprawdza się. Chcę wiedzieć, czy dla mnie również.

Ciekawym podsumowaniem cech programowania funkcyjnego może być prezentacja Programowanie funkcyjne - wprowdzenie p. dr inż. Marcina Szlenka z PW. W katalogu spop, gdzie znajduje się prezentacja, znajdziemy 2 zadania, które możemy spróbować zrealizować w Clojure (autor zażyczył sobie implementacji w Haskellu). Zawsze to łatwiej uczyć się nowego mając określone zadanie, poza takim ogólnym jak po prostu nauczyć się nowego :)

Clojure to Lisp na JVM. Składniowo oznacza to mnóstwo nawiasów, aczkolwiek twórca Clojure zrozumiał, że była to jedna z bolączek Lispa i w wielu miejscach, gdzie Lisp wymagałby nawiasów, w Clojure ich nie ma. I dobrze.

W książce "Programming Clojure" autor napisał:

"My personal quest for a better JVM language included significant time spent with Ruby, Python, and JavaScript, plus less intensive exploration of Scala, Groovy, and Fan. These are all good languages, and they all simplify writing code on the Java platform. But for me, Clojure stands out."

Interesujące, co? Nie potrafiłbym porównać wszystkich wymienionych języków, więc nie pozostaje mi nic innego, jak uwierzyć autorowi na słowo i samemu spróbować swoich sił z Clojure. Ciekawe jest, że obok Clojure pojawiły się również Scala, Groovy i nieznany mi w ogóle Fan. Wystarczy chwila na stronie Fan i trudno nie oprzeć się wrażeniu, że wszystko w nim jest, a jednak brakuje mu zainteresowania społeczności. Dlaczego? Działa na JVM, .Net CLR i w przeglądarce. Ma jakby wszystko, co daje Java, a środowisko szersze, a jednak czegoś brakuje. Ktoś parał się nim?

Wracając do Clojure, zacznijmy od początku. Rozpoczynamy programowanie w Clojure pobierając kompilator i środowisko uruchomieniowe ze strony domowej Clojure. Pobieramy Clojure 1.0.0 i rozpakowujemy w wybranym katalogu. Ja wybrałem trochę bardziej pokrętną drogę i zbudowałem Clojure lokalnie, więc numery wersji będą różne. Dla zainteresowanych, wystarczy

 svn co http://clojure.googlecode.com/svn/trunk/ clojure
 cd clojure
 ant

Uruchamiamy interpreter Clojure - REPL - poleceniem

 jlaskowski@work /cygdrive/c/oss/clojure
 $ java -jar clojure-1.1.0-alpha-SNAPSHOT.jar
 Clojure 1.1.0-alpha-SNAPSHOT
 user=>

Jest to podobne do groovysh czy groovyConsole w Groovy i pewnie podobne rozwiązania znajdziemy również w Scali czy Erlangu. Składnia Clojure wymaga, aby każde polecenie było podawane w nawiasach, w których najpierw podajemy funkcję, a później jej parametry, np.

 user=> (+ 1 3)
 4
 user=> (- 3 1)
 2
 user=> (* 2 4)
 8

Jeśli wymagane jest dalsze zagnieżdzenie struktur, mamy kolejny poziom nawiasów, itp.

 user=> (+ 2 (- 5 2))
 5

Z pewnymi wyjątkami nawiasy wyznaczają zakres działania funkcji. Skoro wszystko jest funkcją, będzie tyle par nawiasów, co wykonywanych funkcji.

Koniec pracy w REPL to znane i lubiane Ctrl-C. To byłoby tyle na dobry początek. Zainteresowany? A czym?! :) W kolejnych wpisach dalsze podboje programowania funkcyjnego z Clojure przy tworzeniu czegoś bardziej użytecznego niż przysłowiowe "Witaj Świecie".

Wrażenia z sobotniej, zwinnej Warsjawy 2009

2009-10-29T22:10:00.004+01:00

Tematem przewodnim sobotniej konferencji Warsjawa 2009 były metodyki lekkie i tylko takie prezentacje zostały zakwalifikowane. Do grupy szczęśliwców, którzy mogli przedstawić swój punkt widzenia na sprawy Agile/Scrum byli (w kolejności występowania): Łukasz Lenart, Paweł Lipiński, Krzysztof Jelski, Tomasz "szimano" Szymański i Tomasz Łasica.

Pojawiłem się w budynku Elki PW w trakcie trwania przerwy na pizzę - około 13tej. Pierwsze wrażenia bardzo pozytywne - tłok na piętrze, co mogło być spowodowane liczbą uczestników lub niewielkich rozmiarów korytarzem. Niestety nie policzyłem uczestników, ale zaryzykowałbym 100kę. Było wystarczająco dużo jak na sobotę i niecałkiem techniczną konferencję. Widać było zainteresowanie Scrumem. Tematy były praktyczne i panowie Tomki nie pozostawili złudzeń, że znają się na rzeczy.

Najpierw, co mi się podobało. Podobało mi się móc wysłuchać o Scrumie w przysłowiowych "żołnierskich słowach". Krótko i treściwie. Każdy z prelegentów miał 30 minut na przedstawienie tematu i 15 minut dyskusji. Akurat. Tomek Ł. skorzystał nawet z pomocy kawek, które zapalały się po przekroczeniu kwadransu. Ciekawy pomysł. Nie dłużyło się wcale, a nawet, mimo, że byłem jedynie na 2 wystąpieniach (szimano i Tomka Łasicy), miałem wrażenie, że prezentacje pojawiają się i znikają, i nie wiedząc kiedy, było po wszystkim. Było ciekawie, czasowo dopasowane, więc dla mnie idealnie. Organizacyjnie super! Łukasz Lenart, który wraz z grupą wolontariuszy (wybaczcie nie wspomnę z imienia i nazwiska, bo pamiętam tylko Agnieszkę i to tylko dlatego, że później jeszcze wystąpiła na wtorkowym 54. spotkaniu Warszawa JUG i tak się jakoś utrwaliło) zorganizował konferencję zrobił to dokładnie, jak było trzeba. Napoje były, pizza też i mini-aula również. Oświetlenie, nagłośnienie i ekran dopasowane. Logistyka na medal. Sponsorzy również dopisali i na scenie pojawili się Pragmatists oraz SoftwareMill.

Wracając do naszych prelegentów - Tomków, o tym co dobre już było. Byli merytoryczni, ale nie obyło się bez jednego drobnego minusu. U obu nie podobało mi się "mówienie do monitora". Kontakt wzrokowy z uczestnikami był, ale niewielki w porównaniu z tym z komputerem. Dało się odczuć, że bardziej zależało im na przedstawieniu tematu bez wpadek, tak jak przygotowali sobie na komputerach niż na kontakcie z publicznością. Niewielka to strata, gdy merytorycznie wypadają doskonale, ale znacznie łatwiej zadaje się pytania prelegentowi, który wręcz prowokuje do nich patrząc na uczestników. I to byłoby tyle z wpadek. Jedna, niewielka wielkiej różnicy nie robi, więc odbiór obu oceniam na wysoki (do perfekcji brakuje właśnie tego wzrokowego kontaktu).

Co mnie jednak nieprzyjemnie wzbudziło w kontekście przedstawiania Scruma, to fakt, że podkreśla się go jako metodykę niesformalizowaną, a aż roi się w nim od formalizmów - podział ról, etapów w projekcie i ta przedziwna mania utrzymywania nazewnictwa angielskojęzycznego. Nie nalegam na zaprzestanie korzystania z niego, gdzie brakuje polskiego odpowiednika, ale wprowadzanie nowego nowym (językiem) może zakończyć się znacznie mniejszym powodzeniem niż mówienie w języku zrozumiałym dla słuchaczy-nowicjuszy. Weźmy na przykład taki sprint - raczej kojarzy się z uciążliwym biegiem po wygraną i nie oddaje lekkości tego terminu (zakładając, że w Scrumie jako metodyce lekkiej wszystko jest lekkie). Dlaczego nie korzystać jednocześnie ze sprintu i okresu produkcji, aby w ten sposób przybliżyć znaczenie tego pierwszego? Jeszcze z samym sprintem można przywyknąć, bo kilkakrotnie padło na konferencji, że nazwa sprint odpowiada trudowi, jaki wkłada się w każdy ze sprintów, aby zrealizować zakładany plan, ustalony wspólnie z właścicielem produktu czy też Scrum Masterem (nie pamiętam dokładnie z kim to się ustala, chyba z oboma). Padło nawet, że po 4tym czy jeszcze kolejnym można odczuć trudy sprintów. Nie rozumiem tego do końca, bo w końcu pracujemy znacznie więcej niż 6-7h zakładane jako dzień w Scrumie, więc dobrze spędzone godziny powinny być kojące niż wykańczające? Bardziej nieprzemawiającymi do mnie terminami były (świadomie używam ich formy mówionej) toking stik, tajmboksowanie, assajnowanie, łajtbord i beklog. Nie twierdzę, że nie nasuwają skojarzeń, ale tylko nieznacznie. Czy nie lepiej byłoby używać słownictwa bardziej bliskiego słuchaczom, aby nowy temat przedstawiać "starymi" terminami/słowami, które niosą tą samą informację, ale przemawiają do nas dosadniej, np. pałeczka/różdżka rozmówcy, harmonogramowanie, przypisywanie, tablica, lista zadań, itp. Akurat idealnie odpowiadają terminom angielskim, ale chodzi mi raczej o przybliżenie słuchacza korzystając z bardziej zrozumiałego dla niego słownictwa. Mam wrażenie, że przez to całe słownictwo wokół Scruma tworzy się pewna aura tajemniczości, która niepotrzebnie wpływa niekorzystnie na zrozumienie, o co w tym wszystkim chodzi. Ma być lekko, a przez to słownictwo nie jest. Nasunęła mi się nawet myśl, że Scrumowcy to "językowi inwalidzi". Jakby się wszyscy uparli na to angielskie słownictwo?!

Co mnie "ujęło za serce" w Scrumie to położenie nacisku na odpowiedzialność jednostki w zespole. W razie niesubordynacji nie wskazuje się winnych, ale odbiera im się możliwość popełnienia ich kolejnym razem. Zamiast winienia, że Iksiński zatwierdza zmiany, które skutkują złamaniem budowania aplikacji (nie wykonaniem kompilacji czy brakiem spełnienia testów jednostkowych), do systemu kontroli wersji wprowadza się "zaporę" w postaci automatycznie wykonywanych testów, kompilacji, itp. i tylko ich spełnienie potwierdza zmianę. Zamiast stać i krytykować wzbogaca się środowisko o narzędzia, które wiele robią za nas. Tak jak powinno być. Wcześniej czy później, Iksiński zrozumie swój błąd i się nauczy, że zmiany należy zatwierdzać do repozytorium jedynie po poprawnym zbudowaniu/przetestowaniu aplikacji lokalnie. Jakość wzrasta samoistnie.

W Scrumie występują karty, którymi przypisujemy wagę każdego z omawianych funkcjonalności, które wejdą do sprintu. Gra w karty świadczy, że Scrum kładzie nacisk na luźną atmosferę pracy, ale jednocześnie wprowadza tyle nowej nomenklatury i nakłada ramy odpowiedzialności, że trudno w to uwierzyć, że wciąż nazywa się go lekkim. Może gdyby nie naciskano tak często na ową lekkość Scruma, miałbym do tego mniej uszczypliwy stosunek.

Miałem jeszcze okazję przejrzeć nagranie z Łukaszem Lenartem w roli organizatora podczas wystąpienia otwierającego konferencję i jako prelegenta w kolejnym wystąpieniu. Bardzo ciekawie przeprowadzona prezentacja z dużą dawką sportu. Zrozumiałem różnicę między uczestniczeniem w spotkaniu na żywo. Tego się nie da odtworzyć podczas odsłuchiwania. Brawo Łukasz za pomysł!

24. listopada, w ramach wtorkowych spotkań Warszawa JUG, będzie miał miejsce Eclipse DemoCamp 2009. Spróbujemy odtworzyć atmosferę Warsjawy, bo jak dla mnie wyznaczyła ciekawą formułę spotkań - 30/15. Zresztą taki postulat pojawił się po Warsjawa Eclipse DemoCamp 2009, więc dlaczego nie spróbować ponownie?! Chętni do pomocy przy organizacji DemoCampa proszeni o kontakt na grupie Warszawa JUG. Każda pomoc mile widziana. Finansowanie mamy zapewnione przez Eclipse Foundation, ale wartoby również skorzystać z możliwości promocji polskich firm informatycznych. Znacie takowe, które byłyby zainteresowane wystawieniem swojego logo na stronie Eclipse.org, konferencji i w trakcie, piszcie. W końcu tyle, ile sami zrobimy, tyle będziemy mieli. Tym razem zadbam, aby w relacjach pojawiły się nazwiska zaangażowanych :)

A to Ci niespodzianka - 1002 czytelników przy 501 wpisach!

2009-10-29T00:25:00.012+01:00

Czasami było więcej, a czasami mniej. Czasami ciekawiej, a czasem niekoniecznie. Przez ostatnie 3 lata, odkąd postanowiłem spróbować swoich sił na polu blogerskim i założyłem Notatnik, upewniłem się co do tego, że w życiu dobrze jest wyznaczyć sobie cel, obrać właściwy kurs i dążyć do niego każdego dnia, aby ostatecznie chociażby otrzeć się o jego zrealizowanie.

Niestety mogę tak napisać wyłącznie o bardzo wąskiej części mojego życia, a mowa o moich doświadczeniach przy prowadzeniu Warszawa JUG oraz prezentowania swojej wiedzy szerokiej publiczności, czego celem było utrzymanie jej w ryzach i ciągłe samodoskonalenie ku uciesze własnej i czytelników. Ja Wam moje spojrzenie technologiczne, a Wy mi komentarze, spostrzeżenia i własne doświadczenia. Układ wystarczająco partnerski, aby po wspomnianych 3 latach móc ucieszyć oko 1002 czytelnikami przy 501 wpisach.

I nie chodzi o liczby, ale o efekt, jaki udało mi się osiągnąć przy tym wystawianiu się na publiczną krytykę. Dzięki złudnemu magicznemu blaskowi rosnącej popularności mojego bloga, przyzwyczaiłem się do próbowania swoich sił z coraz to ciekawszymi rozwiązaniami, które pozwoliły mi ostatecznie uwierzyć, że jak się chce, to można. Można znacznie więcej, ale nie chodzi, aby robić więcej i więcej, ale żeby robić to z głową. Mam wrażenie, że to właśnie pisanie na blogu pozwoliło mi być konkretniejszym literacko i przedstawiać temat zwięźlej. Chciałbym, aby było to prawdą, bo w życiu osobistym różnie to bywa.

Zebrałem kilka statystyk z Google Analytics, które pokazują, co cieszyło się największym zainteresowaniem. Może również komuś nasuną jakieś spostrzeżenia, o których mi nie byłoby dane pomyśleć? W końcu co dwie głowy to nie jedna. Co by nie napisać, to sądzę, że możliwość zamienienia słowa i wymiana doświadczeń pozwoliła mi stać się efektywniejszym technologicznie. Dzięki Notatnikowi udało mi się poznać wielu ludzi, których z pewnością nie miałbym okazji poznać i miałem możliwość uczestniczenia w wielu konferencjach, a nawet kilka zorganizować w ramach Warszawa JUG. Nie mam złudzeń, że jest warto kontynuować temat upubliczniania swojego spojrzenia na technologie javowe na blogu (i wciąż zachodzę w głowę do czego mógłby przydać mi się mikroblog w stylu tweetera, blipa czy podobnych).

Dziękuję wszystkim, którzy zajrzeli do mojego bloga. Ufam, że choć raz znaleźli coś interesującego, a jeśli nie było im to dane do tej pory, zapraszam do kolejnych wpisów. Wczoraj udało mi się uruchomić Apache OpenEJB 3.1 w ramach środowiska OSGi (Apache Felix), gdzie pakunkami są składowe serwera oraz same moduły EJB, a ziarna są usługami OSGi, więc jeśli nawet nie było ciekawie, to z pewnością będzie. Jeśli wciąż nie wierzysz, napisz na priv dlaczego. W końcu jak inaczej poprawić swój warsztat, jeśli nie przez zbieranie krytycznych uwag i wyciąganie wniosków?

Wciąż zastanawiam się, jakby tu wykorzystać popularność Notatnika i sprawić, aby zmienił się w "stanowisko pracy większej liczby osób" i poza komentarzami udostępnił możliwość innym wyrażenia swojego zdania technologicznego. Myślałem o pewnej społecznościówce, gdzie nagrodą za aktywność byłoby publiczne wyróżnienie w statystykach. Brzmi trochę wyniośle, ale ideą jest, aby kanał dystrybucji wiedzy nie był jednoosobowy i był platformą dla innych, którzy dla jednego wpisu nie widzą sensu zakładania własnego bloga. Domena już jest - javosfera.pl i nazwa mówi za siebie. Teraz należałoby stworzyć interesującą szatę graficzną i uzbroić technologiami javowymi. Jeśli macie dostęp do grafików, którzy zechcieliby stworzyć taką szatę Web 2.0 z pastelowymi kolorami, krągłościami przy przyciskach i skromnym aczkolwiek użytecznym układem strony koniecznie dajcie mi znać. Z jednym już rozmawiam, ale poza grafikiem potrzebne są osoby do zabawy z technologiami klienckimi, przede wszystkim CSS, HTML i JavaScript. Serwerem zajmę się z przyjemnością, ale na kliencie będzie to trwało. Dotychczasowe serwisy javowe (jdn.pl, dworld.pl, java.pl, j2ee.pl) po prostu nie dają tych możliwości, które promują aktywność, a dla potencjalnych sponsorów są za mało widoczne, nie zapominając, że są niejavowe (poza dworld.pl?). Pora to zmienić. Możnaby w ten sposób popróbować się ze Scrumem wirtualnie, gdzie jest lista zadań do wykonania, pary pracujące nad daną funkcjonalnością i cotygodniowe podsumowanie co zrobiono, a co planujemy na przyszłość. Może być zabawnie. Zainteresowanych uprasza się o kontakt na priv.

W świat programowania funkcyjnego na JVM z "Programming Clojure" od The Pragmatic Programmers

2009-10-27T09:14:00.004+01:00

Jesienna aura idealnie sprzyja zgłębianiu wiedzy przez lekturę książek. Tym razem padło na Programming Clojure Stuarta Halloway'a (The Pragmatic Programmers, Maj 2009).

Po 2 tygodniach naginania mojego obiektowo-imperatywnego umysłu do myślenia funkcyjnego przebrnąłem w pocie czoła przez 300 stron o Clojure. Początkowo nie mogłem się w ogóle odnaleźć. Wszechobecne nawiasy były do strawienia, ba nawet wydały mi się przyjazne jak średniki, czy jawne określanie typów w Javie. Po prostu składnia i tyle. Kwestia gustu, czy się ją lubi, czy nie. Co mnie jednak najbardziej zmęczyło (i to w pełnym tego słowa znaczeniu), to myślenie w kategoriach struktur danych, które są...niezmienne. Dodając do tego funkcje jako obywateli pierwszej kategorii (domknięcia), makra i multimetody, a programowanie obiektowe wydaje się być zbyt rozdmuchane składniowo. Wiele z problemów programistycznych przedstawiono ciekawie w sposób funkcyjny.

Przez cały czas nie mogłem zrozumieć, dlaczego miałbym poznać kolejny język programowania, który w dodatku jest funkcyjny. Po co mi się z nim męczyć?! Mało mi było Haskella czy OCamla, które omijałem szerokim łukiem?! Teraz nie mam złudzeń, że chociażby, dla świadomości, że osoba programująca funkcyjnie w Clojure nie musi być dodatkiem do zespołu, a powinna być jego przewodnikiem. Clojure to po prostu język funkcyjny napisany w znanej nam Javie, więc w chwilach zwątpienia zawsze możemy zejść na poziom programowania obiektowego w niej lub mikstury programowania obiektowo-imperatywno-funkcyjnego z Groovy. Wszystko zależy od zdrowego rozsądku, gdzie i jak wkleić poszczególne elementy. Zamknięcie funkcjonalności w biblioteki wielokrotnego użycia ukrywa nam detale jaki język programowania został użyty, więc nic nie stoi na przeszkodzie, aby jednym z nich w projekcie był właśnie...Clojure.

Recenzja książki "Programming Clojure" znajduje się na moim Wiki - Book review: Programming Clojure (po angielsku ze względu na wymogi wydawnictwa w programie "Książka dla JUGa za recenzję").

Zapewne kolejne wpisy powinny choć w niewielkim stopniu przedstawić możliwości programowania funkcyjnego z Clojure, więc nie jest to ostatni raz, kiedy się z nim spotykam(y). Czy ma ktoś tyle szczęścia, aby wykorzystać jakikolwiek język funkcyjny w projekcie komercyjnym? Wszędzie wszechobecna Java, Scala, Groovy, czy może znalazłoby się, albo już znaleziono, miejsce dla Clojure? Jest strona po polsku o Clojure i trochę o programowaniu funkcyjnym można poczytać w materiale "Programowanie funkcyjne" na ważniaku. Jeśli dodać do tego, że właśnie kilka dni temu pojawiła się wtyczka Clojure Plugin do Grails można odnieść wrażenie, że obok Clojure nie można przejść obojętnie. W końcu, czego możnaby oczekiwać od Clojure w Grails, gdzie jest Groovy?! Taki temat mógłby pojawić się na spotkaniu Warszawa JUG. Kto chętny? Krzysiek? Przyjezdni mają gwarantowany wikt i opierunek :)

Dziękuję Pawłowi Stawickiemu ze szczecińskiego JUGa za kontakt z wydawnictwem "The Pragmatic Programmers", a Michałowi Januszewskiemu za wskazanie "Programming Clojure". Prawdopodobnie nie schyliłbym się po nią, gdyby nie obaj panowie. Chylę czoła za dobór repertuaru informatycznego.

54. spotkanie Warszawa JUG - "Wyślij siebie na urlop, czyli o skutecznym zarządzaniu zespołem programistów" Agnieszki Orlewicz

2009-10-26T15:55:00.000+01:00

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

Temat prezentacji: Wyślij siebie na urlop, czyli o skutecznym zarządzaniu zespołem programistów
Prelegent: Agnieszka Orlewicz

W trakcie prezentacji Agnieszka opowie, jak być skutecznym liderem zespołu programistów i radzić sobie z problemami, takimi jak brak zaangażowania, delegowanie pracy, przekazywanie informacji zwrotnej. Tematy te są istotne niezależnie od tego czy pracujemy w SCRUMIe, XP czy innej cięższej/lżejszej metodyce. Znajdziemy tu przedstawienie technik, dzięki którym nasze 8 godzin w pracy będzie bardziej wartościowe i będzie można bezproblemowo iść na urlop ... lub nawet w pracy czuć się jak na urlopie (ech, dla wielu to tylko marzenia).

Agnieszka Orlewicz jest absolwentką Wydziału Elektroniki i Technik Informacyjnych PW i pracuje jako konsultant w firmie Premium Technology. Javę pokochaną od 'pierwszego wejrzenia' sprawdziła w wielu ciekawych projektach m.in w CERNie i cały czas pozostaje z nią w kontakcie. Oprócz tego interesuje się kulturą japońską, podróżowaniem, psychologią i ostatnio również tworzeniem muzyki elektronicznej. Posiada certyfikat SCJP.

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

Wstęp wolny!

Zapraszam w imieniu prelegenta i grupy Warszawa JUG!

Użycie javax.transaction.TransactionManager w OSGi z Apache Felix

2009-10-24T17:03:00.003+02:00

Jeszcze przed Warsjawą byłem gotów do opublikowania moich doświadczeń z "OSGifikacji" OpenEJB, więc wrażenia z dzisiejszej, zwinnej Warsjawy pojawią się w kolejnym wpisie. Muszę się jeszcze nad nimi zastanowić, aby były odczytane właściwie.

Wracając do tematu przewodniego tego wpisu - OSGi, podczas wspomnianej osgifikacji natrafiłem na początkowo nietrywialny problem związany z dostępnością pakietu javax.transaction i jego interfejsu TransactionManager. Sama platforma Javy - JRE - dostarcza pakiet javax.transaction, więc OSGi również. Idąc jednak ku rozwiązaniom Java EE, gdzie korzysta się z javax.transaction.TransactionManager prowadzi to do nieoczekiwanych komplikacji i praca początkowo zaplanowana przeze mnie na kilka kwadransów skończyła się po kilku...godzinach o 3 nad ranem. Miało już nie być takich numerów z nocnymi nasiadówami, ale po prostu nie mogłem się oprzeć. Jeszcze tylko to, tylko to i będzie koniec. Był - problemu i mój! :)

Spisałem swoje doświadczenia w kolejnym artykule Użycie javax.transaction.TransactionManager w OSGi z Apache Felix, abyście nie musieli tracić czasu na rozwiązywanie problemów, które już nimi nie są. To właśnie nazywamy doświadczeniem, a skoro ja je mam (w kontekście OSGi i javax.transaction), to i Wy. Proste!

"Zwinna" Warsjawa 2009 w najbliższą sobotę

2009-10-23T12:00:00.002+02:00

W najbliższą sobotę, 24. października, w godzinach 10:00-16:00 odbędzie się "Zwinna" Warsjawa 2009 organizowana przez grupę Warszawa JUG. Tym razem nie na MIMUWie, czy w auli Wydziału Biologii, ale na Elce - Wydziale Elektroniki i Technik Informacyjnych.

Informacje o konferencji znajdziecie na jej stronie domowej i wierzę, że już wszyscy wiedzą co i jak, i stawią się tłumnie. Wstęp wolny, a jeszcze w międzyczasie będzie poczęstunek - pizza! Dzięki naszym sponsorom softwaremill, pragmatists i ej-technologies całość imprezy nie wiąże się dla Was z żadnymi kosztami, a zwinnych wystąpień nie powinno zabraknąć (dosłownie i w przenośni).

Niech harmonogram mówi sam za siebie:

10:00 - 10:15 - słowo wstępne
10:15 - 11:00 - I ty możesz być zwinny (30 minut wykład, 15 minut na dyskusję) - Łukasz Lenart
11:00 - 11:45 - I Twój zespół może być zwinny (czas j. w.) - Paweł Lipiński
11:45 - 12:30 - TDD w Twoim zespole (czas j. w.) - Krzysztof Jelski
12:30 - 13:30 - przerwa na Pizzę!
13:30 - 14:15 - Scrum czyli Młyn, ale w rozproszeniu (czas j. w.) - Tomek Szymański
14:15 - 15:00 - Niepopularne retrospekcje (czas j. w.) - Tomek Łasica
15:00 - 15:30 - dyskusje, dojadanie pizzy i koniec....

Niektórych prelegentów już znam i największą niewiadomą jest dla mnie Tomek Łasica. Wiem ile zależy od prowadzącego i jestem ciekaw, co gość zaprezentuje. Reszta prelegentów już wygłaszała swoje peany nt. Agile podczas konferencji - Paweł i Krzysiek, więc połowicznymi niewiadomymi będą dla mnie - Łukasz i Tomek Sz. (znany szerokiej publiczności jako "szimano"). Cięty język to jego drugie ja i liczę, że ten Młyn i to jeszcze w rozproszeniu będzie właśnie zbiorem takich ciętych ripost pod adresem Scruma (nie muszą być krytyczne, ale zwięzłe i konkretne aż do bólu jak najbardziej). Brakuje mi w tym gronie Michała M., albo Pawła W. z naszego lokalnego podwórka (nazwiska znane redakcji :)). Z tego, co się zorientowałem ich Agile też porwało! A czy są wśród nas sceptycy? Słuchać samych ewangelistów może być nużące.

Jakkolwiek sama Warsjawa nie jest organizowana pierwszy raz, to pojawienie się jej na Elce może zaskoczyć. Sam nie wiem, czego można się tam spodziewać, więc nawet jeśli nie sama konferencja, to chociaż miejsce powinno być dla mnie źródłem ciekawych doświadczeń. Będzie czas na dyskusje, więc należałoby jedynie zadbać, aby nie zaprzepaścili nam go przeciągający czas występu prelegenci. To będzie nasz obywatelski projekt, aby dopilnować końca wystąpienia i mieć czas na dyskusje. Zgoda?

p.s. Kto zamierza twittować czy blipować? Wiedza na bieżąco, jak idą prezentacje może być interesująca dla tych, którym nie dane było pojawić się na nich. W zasadzie w takim wykorzystaniu twittera/blipa widzę ich największą wartość. Może poza informowaniem o pracy zespołu przy projekcie, ale to już temat na inne p.s.

Java Type Proposals wyłączone w Eclipse IDE 3.6?!

2009-10-19T17:47:00.004+02:00

To już nie pierwszy raz, kiedy się z tym spotykam i nie wiem, czemu miało by to służyć?! Korzystam z Eclipse IDE 3.6m2 i wciskając Ctrl+Spacja w edytorze javowym nie są podpowiadane typy javowe?!

Rozwiązaniem jest włączenie opcji Java Type Proposals w Preferences > Java > Editor > Content Assist > Advanced.

Czy mógłby mi ktoś wyjaśnić, dlaczego to jest domyślnie wyłączone? To tak, jakby zaoferować samochód ze wskazaniem, że służy wyłącznie do spania (zamiast jeżdżenia).

Tworzenie pakunków OSGi w Eclipse IDE 3.6m2 - Eclipse się sprawdził

2009-10-16T22:48:00.000+02:00

Potrzebowałem stworzyć wtyczkę OSGi, ale nie miałem zamiaru zejść na poziom linii poleceń. To już przerabiałem w Tworzenie pakietów OSGi z Apache Maven 2 czy Pakunki OSGi w projekcie wielomodułowym Apache Maven 2 z maven-bundle-plugin. Tym razem miałem potrzebę skorzystania z IDE.

NetBeans IDE odpada, bo nie oferuje żadnego wsparcia w tym temacie. IntelliJ IDEA - hmmm, nie mam wciąż pojęcia, czy się nadaje, ale przecież Eclipse IDE to w końcu środowisko oparte na OSGi - jako platformie i składowych. W Eclipse można stworzyć jego wtyczki (rozszerzenia), które są niczym innym jak pakunkami OSGi.

Po chwili byłem po lekturze artykułu OSGi with Eclipse Equinox - Tutorial i byłem gotów do eksperymentów.

Zaczynam typowo. Otwieram Eclipse 3.6M2, Ctrl+N i wybieram Plug-in Project.

Uzupełniam dane projektu przyszłej wtyczki - Project name ustawiam na ejb-client i wybieram Target Platform jako an OSGi framework: standard (ktoś wie, co to oznacza i czego nie mam w porównaniu z Equinox?).

Kolejny ekran bez zmian

i w następnym Templates wybieram Hello OSGi Bundle.

Super te szablony, bo z nimi stworzenie bardziej wyrafinowanej wtyczki (wszystkie poza wspomnianym Hello OSGi Bundle) sprowadza się do odpowiedniego wyboru. Nie trzeba nawet wiedzieć, co to są pakunki, aby je stworzyć!

Ostatni ekran to konfiguracja szablonu, więc może się różnic, w zależności od wcześniejszego wyboru.

Kiedy pojawi się pytanie o przełączenie perspektywy na Plug-in Development

wciskam Yes i w końcu mam swój wymarzony pakunek OSGi.

Teraz można dalej się bawić w tworzenie bardziej wyrafinowanych elementów pakunku, a na uznanie zasługują dwie rzeczy - edytor MANIFEST.MF (patrz zrzut ekranu wyżej) oraz widok Outline (na zrzucie wyżej po prawej).

Kiedy przełączyłem się na zakładkę MANIFEST.MF w edytorze manifestu, w widoku Outline pojawiła się charakterystyka pakunku. Bajera!

Mając gotową wtyczkę/pakunek wystarczy File > Export i wybrać Deployable plug-ins and fragments.

Mamy możliwość wyboru pakunku i jego danych do eksportu.

Po prostu bajka. Wszystko idzie bez najmniejszych potknięć. W katalogu plugins, poniżej wskazanego katalogu, czeka na nas gotowy do uruchomienia pakunek OSGi.

W łatwy sposób mamy możliwość importu istniejących pakunków oraz definiowania zależności między nimi - określenie importów i eksportów w manifeście.

Tym samym Eclipse IDE 3.6m2 stało się narzędziem numer 1, jeśli chodzi o tworzenie pakunków OSGi.

Ciekawe, czy IntelliJ IDEA daje jakiekolwiek wsparcie dla tworzenia pakunków OSGi?

IT-SOA - interesujący projekt z OSGi/SCA w roli głównej na AGH i innych polskich uczelniach

2009-10-14T22:49:00.006+02:00

Kilka dni temu natchnęło mnie na wyszukiwanie informacji o prowadzonych projektach badawczych wokół OSGi na polskich uczelniach. Nie pamiętam dokładnie jaką frazę wpisałem w Google, ale było to bodajże "osgi uniwersytet" i w zakładce zaawansowane wybrałem język polski. Ku mojemu zdumieniu natrafiłem na bardzo zaawansowany technologicznie projekt IT-SOA, którego uczestnikami są AGH z Krakowa, Uniwersytet Ekonomiczny w Poznaniu, Politechnika Poznańska, Instytut Podstaw Informatyki PAN i Politechnika Wrocławska.

Za stroną główną projektu: "Projekt dotyczy współczesnych technologii informacyjnych działających w systemach rozproszonych." Nie powiem, żeby mnie nie zaintrygowało. Zacząłem przeglądać informacje o projekcie i trafiłem na Obszar Badawczy 5, którego tematem przewodnim był OSGi (było tam kilka innych akronimów, ale ja widziałem, albo chciałem widzieć, jedynie OSGi :)).

Postanowiłem napisać do koordynatora projektu (namiary na stronie Kontakt) i niedługo musiałem czekać, aby dostać odpowiedź z...Sekretariatu Projektu SOA. Po krótkiej korespondencji z panem prof. Krzysztofem Zielińskim z AGH, który zawiaduje projektem okazało się, że dzisiejszy dzień (środa) jest najlepszy dla obu stron i spotykamy się w Krakowie, aby przedyskutować temat współpracy (okazało się, że IBM jest również zaangażowany w temat, więc nie mogłem życzyć sobie więcej).

Po kilkugodzinnej rozmowie w gronie pracowników AGH zaangażowanych w temat okazało się, że mimo początkowego sceptycyzmu, że OSGi jest, i SOA też, ale pewnie jedynie dla wzmocnienia przekazu projektu, bez jakiegokolwiek mocniejszego wykorzystania, projekt nie tylko, że wymienia je z nazwy, ale rozpoznanie technologiczne nie skupia się na podstawowym użyciu, ale również w postaci rozwiązań typu Spring-DM, Swordfish, Distributed OSGi (D-OSGi) i in. Bardzo mocno korzysta się z ServiceMix 4 z jego wsparciem dla OSGi i możliwością klastrowania komponentów JBI (jako członek ServiceMix PMC nie miałem nawet świadomości, że JBI jest wspierane przez niego). Padły również akronimy typu SCA, CEI (rozwiązanie WebSphere AS do rozgłaszania komunikatów) oraz CBE (format komunikatów), więc można sobie tylko wyobrazić, jak chłonąłem te wszystkie informacje podczas spotkania. Widać, że jest z kim porozmawiać na te tematy w Krakowie, bo na AGH naliczyłem 6 osób, które wiedzą, co w trawie piszczy.

Byłoby to niesamowite doświadczenie móc uczestniczyć w tego typu przedsięwzięciu, więc rozpoczynam moją krucjatę, aby choć przez chwilę móc czerpać z doświadczeń projektu IT-SOA.

Podczas podróży miałem okazję przeczytać pierwsze rozdziały książki Programming Clojure. Jedyne co mogę powiedzieć po 3 rozdziałach, to że programowanie funkcyjne jest...trudne dla mojego imperatywno-obiektowego postrzegania świata. Wciąż zachodzę w głowę dlaczego miałbym się nauczyć Clojure, ale skoro mam o nim książkę i wielu wychwalało programowanie funkcyjne jako odświeżające, postaram się wytrwać do końca. Tak wiele trudności w zrozumieniu tematu z branży IT już dawno nie miałem, a już odnośnie samego programowania, wcale. Czy tylko ja doświadczam takich trudności intelektualnych?!

53. spotkanie Warszawa JUG - "Java w długopisie, zaskakująco użyteczne połączenie" Michała Margiela

2009-10-11T14:52:00.001+02:00

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

Temat prezentacji: Java w długopisie, zaskakująco użyteczne połączenie
Prelegent: Michał Margiel

W takcie prezentacji Michał przedstawi genialny[1] wynalazek firmy livescribe - inteligentny długopis o jakże zaskakującej nazwie "Smart pen", który może zrewolucjonizować sposób prowadzenia notatek na wykładach[1].

Długopis zawdzięcza swą "mądrość" Javie ME, którą ma na pokładzie oraz rozszerzeniom, o których więcej podczas prezentacji.

Wykład składa się z dwóch części. W pierwszej zostaną zaprezentowane wbudowane możliwości pisaka - synchronizacja tego, co piszemy z tym, co słyszymy, rozpoznawanie pisma, oraz aplikacja desktopowa do zarządzania naszymi notatkami. W drugiej części przedstawiony będzie interfejs programistyczny na przykładzie aplikacja tworzonej na żywo.

Zdaniem Michała każdy student (ale nie tylko) po wysłuchaniu prelekcji będzie marzył o własnym "Smart penie"

Michał Margiel jest absolwentem wydziału Elektrycznego Politechniki Warszawskiej, z wykształcenia informatyk. W WJUGu jest od samego początku jego istnienia, oraz współorganizował dwie edycje konferencji Javarsovia. Na codzień pracuje w firmie Pragmatists na stanowisko artysta-programista[2] , zaś samą javą zajmuje się już od ponad 4 lat. Posiada certyfikaty SCJP, SCWCD, pomocy przedmedycznej oraz wychowawcy kolonijnego.

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!

[1] Tak przynajmniej twierdzi Prelegent.
[2] Oczywiście artysta sztuki programowania ;)

Recenzja "Pro Spring Dynamic Modules for OSGi Service Platforms" z Apress - dobry wstęp do OSGi/Spring-DM, ale ogólnie klapa

2009-10-10T18:23:00.004+02:00

Udało mi się wygospodarować trochę czasu na lekturę Pro Spring Dynamic Modules for OSGi™ Service Platforms autorstwa Daniela Rubio z wydawnictwa Apress i niestety, ale noty są bardzo niskie. Dobre wprowadzenie do OSGi i Spring-DM, ale jak na książkę z "Pro" w tytule, to zdecydowanie za mało. Zresztą, gdyby tylko to, ale listingi build.xml Anta, cały 2 rozdział o Spring Framework czy kolejny o SpringSource dm Server przeszły moje najśmielsze oczekiwania, co można zrobić z książką, gdzie tematem przewodnim miał być Spring-DM. Tyle sobie obiecywałem po tej książce, a skończyło się na tym, że jestem mocniejszy w Apache Ant, Apache Ivy i wiem, co w trawie piszczy odnośnie SpringSource dm Server. Później miało być lepiej. Szumny tytuł o wersjonowaniu w OSGi, tworzeniu aplikacji webowych z Spring-DM oraz testowanie aplikacji opartych na OSGi ze Spring-DM, a skończyło się jedynie na wielkich oczekiwaniach i niemiłym zaskoczeniu, że mogło być więcej, lepiej, itp. Nie powiem, że nie nauczyłem się więcej o OSGi, ale zdecydowanie za mało jak na książkę "Pro" (każdorazowo, kiedy piszę to słowo przypomina mi się wypowiedź Lt. Aldo Raine w "Inglourious Basterds" "I think you show great talent. And I pride myself on having an eye for that kind of talent. Your status as a Nazi killer is... still amateur. We all come here to see if you wanna go pro..."). W tej książce mieć talent, to znaleźć te brylanty, które po 300 stronach zrobią z nas Pro. Ostrzegam jednak, nie będzie łatwo. W zasadzie, każdy komu ta książka nie zacznie się dłużyć stanie się Pro. Może o to chodziło autorowi?!

Podsumowując, książka nie warta swych pieniędzy, ale dla członków Warszawa JUG, którzy mają ją kosztem recenzji, i są zainteresowani wprowadzeniem do OSGi i Spring-DM z dodatkami w stylu Ant, Ivy czy SSdS, dlaczego nie?! Uważam, że bez wygórowanych oczekiwań można znaleźć kilka ciekawostek.

Pełną recencję książki po angielsku (ze względu na wymagania wydawcy w programie "Książka za recenzję") znajdziecie w Book review: Pro Spring Dynamic Modules for OSGi Service Platforms. Miłej lektury - recenzji i...książki! ;-)

Uruchomienie zdalnego klienta EJB wyłącznie w oparciu o interfejs biznesowy (bez implementacji)

2009-10-09T10:33:00.003+02:00

Właśnie takiego obrotu sprawy sobie życzyłem. Publikuję wyniki moich doświadczeń szerszemu gronu z nadzieją, że komukolwiek zechce się poświęcić trochę czasu na prześledzenie mojego toku myślenia i samych wyników. Tak też było w przypadku mojego, ostatniego artykułu Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3). Jego celem było sprawdzenie zachowania się zdalnej referencji EJB3 podczas niedostępności serwera. Przeoczyłem jednak fakt, że aplikacja kliencka dystrybuowana była nie tylko ze zdalnym interfejsem biznesowym, ale również z jego implementacją jako bezstanowe ziarno sesyjne EJB. Nie długo trzeba było czekać, aby takiemu podejściu zaprotestował Łukasz Lenart:

Jedna uwaga, która ogólnie jest globalna do tego typu przykładów. Mianowicie klientowi dostarczasz nie tylko interfejs ale również implementację jako zależność, przez co używanie serwera aplikacyjnego do zdalnej komunikacji jest zbędnym narzutem. Nigdzie jeszcze nie znalazłem przykładu jak to zrobić bez dostarczania implementacji a tylko sam interfejs. Moje próby potwierdziły tylko, że tego nie da się zrobić w przypadku Glassfisha :-(

Problem, jaki wskazał Łukasz, polegał na dystrybuowaniu zdalnego klienta EJB3 w paczce, która zawierała nie tylko interfejs biznesowy, ale i jego implementację (!) Przyznaję, że nie pomyślałem o takim skonstruowaniu paczki dystrybucyjnej klienta, która nie zawierałaby implementacji komponentu EJB, z którego korzysta. Kiedy przeczytałem komentarz, a szczególnie jego ostatnie zdanie, nie miałem złudzeń czym się zająć.

Ten rodzaj reakcji jest zapewne największym podziękowaniem czytelników - dzielimy się własnymi reakcjami na proponowaną rzeczywistość. W końcu autor mógł nie wiedzieć, że da się lepiej, lub po prostu uważać to za nieistotne. Stwarza się w ten sposób okazję do wymiany doświadczeń w jedną (od autora) i drugą, zwrotną stronę (od czytelników), w której nie ma strony wiodącej (poza stroną inicjującą dyskusję, ale tutaj trudno wskazać, czy sam autor artykułu, czy komentarza nią jest - świetny temat na pracę doktorską z filozofii :-)). Tak czy owak, jest nad czym się pochylić i artykuł spełnia swoją rolę - nie jest jednostronny. Najważniejsze, że przy takim podejściu nikt nie traci, bo ja miałem kolejny temat, a Łukasz et al rozwiązanie. Idziemy tym samym naprzód i kolejne projekty stają jeszcze prostsze technologicznie.

Uwielbiam takie publiczne dywagacje, bo nigdy nie wiadomo z kim przyjdzie mi rozmawiać. W przypadku Łukasza to sprawa jest prosta - dostaje baty w bilarda, więc chciał się odegrać :P Ale nie tylko Łukasz zareagował! Dostałem prywatnie komentarz od Pawła Balczyńskiego, który znalazł błąd w jednym z listingów. Standardowe "U mnie działa" miało przez chwilę zastosowanie, ale fakt faktem błąd był (tylko dlaczego u mnie działało?!). Dzięki Paweł!

Zainteresowanych kolejnym doświadczeniem i jego wynikami zapraszam do lektury nowego artykułu Uruchomienie zdalnego klienta EJB wyłącznie w oparciu o interfejs biznesowy (bez implementacji). Teraz oczekuję kolejnej porcji pomysłów na udoskonalenie warsztatu. Komenatrze mile widziane - na priv, albo w komentarzu do tego wpisu.

Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3)

2009-10-05T22:00:00.002+02:00

Niedawno dostałem do skrzynki takie pytanie:

(...)Głównie nurtuje mnie "jak długo" po otrzymaniu referencji do ejb mogę go używać (kontener może go przecież spasywować/usunąć albo *** wie, co jeszcze zrobić) - mogę z niego korzystać dowolnie długo/pobierać od nowa co wywołanie metody biznesowej czy jeszcze inaczej?

Początkowo miałem po prostu odpowiedzieć i zapomnieć o temacie. Zdalna referencja jest jedynie pośrednikiem (ang. proxy) między kodem klienta a serwerem i tak na prawdę odpowiada jedynie za komunikację z serwerem bez utrzymywania jakiegokolwiek stanu komponentu EJB. Mimo jasnej dla mnie odpowiedzi, postanowiłem sprawdzić ją w ramach niewielkiego eksperymentu, który miał mi nie tylko zweryfikować samą odpowiedź, ale również dać nową na pytanie, ile czasu potrzeba na zestawienie środowiska do jego przeprowadzenia. Do dyspozycji miałem linię poleceń lub IDE. Z IDE jest o tyle problem, że trudno wybrać to jedyne (w przypadku projektów Java EE wskazywałbym na NetBeans IDE), więc pozostałem przy linii poleceń. Tak się bawiłem, że skończyło się na nowym artykule - Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3).

Wykorzystałem w nim Apache Maven 2.2.1 i GlassFish v3 b66 do zestawienia projektu wielomodułowego, który posłużył mi za materiał testowy. Jest też kilka miejsc oznaczonych TODO, dla osób, które rozmyślają, jakby tu zaangażować się w naukę technologii javowych praktycznie. Ufam, że lektura dostarczy równie wiele zabawy co i mi. Pochwały/nagany mile widziane.

p.s. Zastanawiam się, czy nie warto rozważyć screencastów (brakuje mi dla tego chwytliwego odpowiednika po polsku). Wink, Camtasia, a może jeszcze coś innego? Pewnie z udziałem NetBeans IDE 6.8 dev, bo w końcu tego typu projekty dobrze się w nim robi. Co o tym sądzicie?

default-* execution dla różnych konfiguracji wtyczek w Apache Maven 2.2.1

2009-10-03T19:19:00.004+02:00

Podczas moich ostatnich wojaży z projektami zarządzanymi Apache Maven 2 potrzebowałem możliwości zdefiniowania różnych konfiguracji dla wtyczki maven-surefire-plugin. Początkowo rozważałem taką konfigurację:

 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
     <configuration>
      <excludes>
       <exclude>**/WyswietlanieKomunikatowClientTest.java</exclude>
      </excludes>
     </configuration>
     <executions>
      <execution>
       <id>uruchom-WyswietlanieKomunikatowClientTest</id>
       <phase>integration-test</phase>
       <configuration>
        <includes>
         <include>**/WyswietlanieKomunikatowClientTest.java</include>
        </includes>
       </configuration>
       <goals>
        <goal>test</goal>
       </goals>
      </execution>
     </executions>
   </plugin>
  </plugins>
 </build>

która oznacza, że domyślne wykonanie wtyczki, np. podczas wykonania mvn install, wykluczy wykonanie testów z WyswietlanieKomunikatowClientTest, podczas gdy uruchomienie mvn integration-test, albo wszystkich faz kolejnych, tj. verify, install czy deploy, już tak (warto zajrzeć na strony Introduction to the Build Lifecycle i Guide to Configuring Plug-ins#Configuring Build Plugins z dokumentacji Apache Maven, jeśli tematy są niejasne). I tutaj właśnie pojawił się problem - chcąc wykluczyć WyswietlanieKomunikatowClientTest musiałem wykonywać fazy niższe niż integration-test, a one wykluczają install. I na odwrót, wykonanie install wykona integration-test, a to nie było mi na rękę.

Zacząłem przeszukiwać Internet w poszukiwaniu rozwiązania dla konfiguracji bez phase w ramach execution wtyczki. Sądziłem, że gdzieś wokół takiego myślenia powinienem znaleźć rozwiązanie. I jakież było moje zdumienie, kiedy trafiłem na dokument Default Plugin Execution IDs, gdzie przeczytałem o podobnych dywagacjach. To odpowiadało moim potrzebom! Lektura dokumentu upewniła mnie, że mam szansę coś znaleźć w Mavenie. Na końcu dokumentu, w sekcji References, było wskazanie na dwa zgłoszenia JIRA dla Apache Maven. Pierwsze MNG-3401 niezwykle obiecujące, ale kolejne MNG-3203 odpowiadało dokładnie temu, czego poszukiwałem. Oba rozwiązane tyle tylko, że..."This should work both in Maven 2.2.0 and in Maven 3.x". U mnie niestety Maven w wersji 2.1.0:

 $ mvn -v
 Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
 Java version: 1.6.0_14
 Java home: c:\apps\java6\jre
 Default locale: en_PL, platform encoding: Cp1250
 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

Sądziłem, że pracuję z najnowszą wersją Mavena, więc nietrudno sobie wyobrazić, jak wielkie zrobiłem oczy, kiedy zobaczyłem, że wersja 2.2.1 jest już dostępna. To było dokładnie to, czego poszukiwałem. Rozwiązanie na miarę. Instalacja nowej wersji Apache Maven 2.2.1

 $ mvn -v
 Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.6.0_14
 Java home: c:\apps\java6\jre
 Default locale: en_PL, platform encoding: Cp1250
 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

zmiana konfiguracji projektu na następującą:

 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <executions>
     <execution>
      <id>default-cli</id>
      <configuration>
       <excludes>
        <exclude>**/WyswietlanieKomunikatowKlientTest.java</exclude>
       </excludes>
      </configuration>
     </execution>
     <execution>
      <id>default-test</id>
      <configuration>
       <includes>
        <include>**/WyswietlanieKomunikatowKlientTest.java</include>
       </includes>
      </configuration>
      <goals>
       <goal>test</goal>
      </goals>
     </execution>
    </executions>
   </plugin>
  </plugins>
 </build>

i jestem w domu! Problem rozwiązany! Teraz każdorazowe uruchomienie mvn install wykona konfigurację o identyfikatorze default-cli, a każdorazowe wykonanie mvn test, czyli dosłowne uruchomienie wtyczki surefire, która jest związana z fazą test, wykona konfigurację default-test. Dokładnie tak, jak sobie życzyłem. Warto zajrzeć do przykładowego wykonania obu poleceń i prześledzić wykonywanie wtyczek i ich execution, aby dokładnie poznać różnicę między nimi. Nie ma to jak rozwiązanie problemu w przysłowiowe 5 minut - dobrze zadane zapytanie w Google...bezcenne! :)

p.s. Jak tak dalej pójdzie, to niedługo zejdę na serce. Tyle wrażeń jednego dnia na pewno niekorzystanie wpływa na moje zdrowie :) A to tylko przy takim, pojedynczym wydarzeniu, a przecież nie było ono moim jedynym. Informatycy to strasznie podatny na zawał serca lud ;-)

p.s.2. Skoro przy temacie zarządzania projektami, to natrafiłem ostatnio na gradle. Używa ktoś tego? Chętnie wysłucham wrażeń. Komentarze, listy na priv mile widziane.

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

2009-09-27T23:28:00.005+02:00

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.

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

2009-09-24T21:18:00.004+02:00

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.

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

2009-09-23T23:37:00.000+02:00

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!