"Prezentacyjna" dyktatura Tomka z Mule ESB na 62. spotkaniu WJUGa - normalnie Git!

Niezwykłem komentować wydarzeń ze spotkań Warszawa JUG, ale ostatnie, 62. spotkanie było prawdziwym kilerem wśród WJUGowych prezentacji i wyróżniało się pośród dotychczasowych spotkań! Po prostu nie mógłbym tego nie skomentować. Technologiczne cudo!

Na WJUGowej scenie wystąpił Tomasz Nurkiewicz z Mule ESB i nie byłoby może w tym wielkiego wydarzenia, bo temat ciekawy, jak wiele innych, ale sposób, w jaki przyszło nam oglądać występy sceniczne Tomka przyprawił niejednego o lekką palpitację serca...z wrażenia, że można tak składnie poprowadzić temat (przede mną siedzieli Mateusz Z. i Jacek K., i co rusz potakiwali głową na moje ochy i echy :)). Jestem pełen podziwu dla warsztatu prezenterskiego Tomka, w którym miejsce znalazły - doskonałe przygotowanie merytoryczne (słuchało się z zapartym tchem) i dobrze dobrane narzędzia - IntelliJ IDEA, mnóstwo uruchomionych wcześniej serwerów - James (SMTP/POP3), JBoss AS (kolejki JMS z ActiveMQ i jego wyśmienitą konsolą webową) i serwer FTP - pewnie FileZilla - oraz Git. I było faktycznie Git! Kiedy zobaczyłem, jak można połączyć prezentację kodu źródłowego w trakcie tworzenia oprogramowania na żywo z odtwarzaniem zmian z lokalnego repo Gita (git co -f [tag]) bez straty czasu na przeklejanie ze schowka czy przeklepywanie z kartki, o mało nie spadłem z krzesła. Najbardziej nie mogłem zrozumieć, jak można się tak dobrze przygotować do prezentacji, aby idealnie wpasować się w kolejne numery tagów w repo. Zrozumiałbym, gdyby poszło v1, v2, v4, v6, ale v1, v2, v3, v4, aż do bodajżę v12 przeszło moje najśmielsze oczekiwania. Możnaby powiedzieć, że prezentacja w dużej mierze składała się z kodowania, albo nawet możnaby to nazwać gitokodowaniem, w którym część programowania zrzucono na barki odtwarzania odpowiedniego taga z repo Gita. Bajecznie!

Nie byłbym sobą, gdyby nie udało mi się wyłapać kilku niedoskonałości w wystąpieniu Tomka, a odważyłem się na ich publikację na blogu, bo są one tak niewinne, że wręcz śmiesznie nazywać je "niedokonałościami". Na pewno zabrakło przejścia przez slajdy. Było ich zbyt mało, abym uwierzył, że wszyscy zrozumieli sens tych inboundów, outboundów, trasformersów, ruterów, komponentów i co tam jeszcze w Mule można znaleźć. I nie ma co marzyć, aby tak było, nawet ze slajdami, ale przynajmniej mi brakowało ich, aby ułożyć sobie wiedzę, zobrazować ją. Na pierwszym slajdzie, gdzie pojawiła się architektura Mule ESB było za mało kolorowo i trochę niewidocznie (nie narzekam na wzrok, a siedząc w trzecim rzędzie miałem już problemy z odczytaniem, co na nim było - obstawiam, że za mną już nic nie było widać). Kiedy przeszliśmy pobieżnie przez pozostałe slajdy widać było, że były i kolorowe, i wyraźniejsze. Szkoda, że nie było nam dane ich zobaczyć.

Drugim elementem było zbyt intensywne skakanie po kodzie, otwartych konsolach serwerów, przeglądarce i tak w kółko. Dawałem radę, ale wymagało to ode mnie dużego skupienia i nie było nawet mowy o...układaniu pytań (!) Albo temat był doskonale przedstawiony przez Tomka, albo sala oniemiała z wrażenia i pytań było niewiele. Zabrakło mi tego, bo mogłoby mi uporządkować wiedzę.

Kolejnym zaskoczeniem dla mnie była zbieżność nomenklatury między Mule ESB a SCA. W sumie chodzi o to samo - mediację i na wejściu (usługi) czy wyjściu (referencje) musi być możliwość dogadania się z nadającym lub odbierającym. W Mule ESB na wejściu mówimy o Inbound'zie, a w SCA mamy usługę z odpowiednim binding, który wyznacza protokół. Na wyjściu, w Mule ESB, mówimy o Outbound'zie, a w SCA o referencji z binding, ponownie. Naturalnie, że chciałoby się, aby określenie protokołu wejściowego i wyjściowego było deklaratywne. I tak mamy w SCA (jeśli istnieje odpowiedni binding), ale i w Mule ESB, przy odpowiednim transformer'ze. Trochę za wiele było dla mnie XMLa i zdecydowanie brakowało narzędzia typu IDE, które konfigurację transformacji dla Mule przygotował wizualnie (zamiast zmuszać mnie do zejścia na poziom XMLa).

Odświeżające było również zobaczyć, kiedy strona HTML nie była udostępniana przez serwer, ale po prostu uruchomiona w przeglądarce i dopiero zatwierdzenie formularza słało dane do serwera - do Mule ESB. Niby nic odkrywczego, jak tak piszę o tym, ale wiedzieć a stosować, to dwie różne sprawy.

I te uruchomione serwery - James, JBoss z ApacheMQ, serwer FTP i Mule ESB. Transportowy mix. Ostatnio potrzebowałem obsługi protokołu SMTP/POP3 i jakoś nie wpadłem, aby uruchomić James. Zachodzę w głowę, aby znaleźć odpowiedź dlaczego. Widać za mało chciałem i trzeba mi było pojawić się na występie Tomka. Nauka od lepszych mobilizuje do pracy!

Podsumowując, przed moimi występami w Krakowie i Poznaniu muszę:

* przygotować wszelkie przykłady aplikacyjne w lokalnym repo - git lub hg
* zaprezentować działający przykład po pierwszym slajdzie wprowadzającym
* omówić aplikację slajdami
* (kiedy starczy czasu) rozpocząć tworzenie aplikacji od zera, ale bez zbędnej pisaniny - git co -f [tag] zrobi swoje!
* pamiętać o pytaniach do publiki (jak to miało miejsce podczas spotkania z Kirkiem)
* wrócić do slajdu początkowego z architekturą aplikacji

Do poznania (ale w sensie nauki, a nie wyjazdu na konferencję - zbieżność z Poznaniem przypadkowa :)):

* Mule ESB - pojawiły się książki nt. temat, więc będzie co i dlaczego czytać
* Apache CXF - książka o nim już u mnie leży, więc tym bardziej nie mogę się jej doczekać

A jak Wam podobała się prezentacja? Nagranie z niej już wkrótce w Sieci.

p.s. Poza Tomkiem, wystąpił również Łukasz Dywicki, ale nie dane mi było wysłuchać go, poza 1. slajd z mnóstwem wersji i softu, więc korzystam z...prawa do milczenia.