29 października 2009

Wrażenia z sobotniej, zwinnej Warsjawy 2009

15 komentarzy
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!

5 komentarzy
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.









27 października 2009

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

3 komentarzy
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.

26 października 2009

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

1 komentarzy
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!

24 października 2009

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

3 komentarzy
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!

23 października 2009

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

7 komentarzy
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.

19 października 2009

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

7 komentarzy
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).

16 października 2009

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

2 komentarzy
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?

14 października 2009

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

7 komentarzy
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?!

11 października 2009

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

0 komentarzy
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 ;)

10 października 2009

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

2 komentarzy
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! ;-)

09 października 2009

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

2 komentarzy
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.

05 października 2009

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

8 komentarzy
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?

03 października 2009

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

7 komentarzy
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.