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

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

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

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

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!

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

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

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!