Softdevcon z 20 uczestnikami oraz ja z Clojure o współbieżności i testowaniu

Jakoś tak bez echa przebiegły przygotowania do konferencji softdevcon w Warszawie, na której przedstawiłem temat "O tym jak języki funkcyjne upraszczają testowanie i programowanie współbieżne - na przykładzie Clojure". Wejście miałem o godzinie 9:00, co przy bardzo specjalistycznym temacie wokół Clojure mogło stanowić nielada wyzwanie dla śpiochów.

Konferencja (chociaż przy takiej liczności, chyba raczej nie powinienem tego tak nazywać) odbyła się w czwartek, w budynku Millenium Plaza na Al. Jerozolimskich 123a, na 4 piętrze i już sama sala nie zachęcała do tłumnego przybycia - mogła pomieścić maksymalnie 40 osób i już przy tej liczbie dałoby się odczuć dyskomfort braku miejsca. Kiedy się w niej pojawiłem trochę mnie zmroziło. Wyglądało skromniej niż nasze spotkania WJUGowe. Cóż było robić?! Zacząłem obawiać się braku zainteresowanych. Co nie było dalekie od prawdy.

O 8:45 było już 5 osób, więc dawało mi nadzieję, że to jest właśnie kwiat polskiej branży informatycznej, bo wszystko sprawiało, że myślenie, że uczestnicy są właśnie dla Clojure, mogło być uzasadnione. Na 9:00 sala była "wypełniona" dwunastoosobową grupą zaintrygowanych (przynajmniej tak chciałem i chcę o nich myśleć).

Zaprezentowałem około 10 slajdów wprowadzających, głównie przygotowujących do sesji kodowania na żywo. Jak uzmysłowił mi kolejny prelegent - Jakub Binkowski, który wyśmienicie przedstawił temat "Programowanie równoległe - projektowanie i testowanie" (na platformie .Net) - należało rozpocząć od prezentacji gotowego kodu w IDE, aby potencjalnie zejść na poziom Clojure REPL. Ja jednak nie wyłapałem tej potrzeby i odwróciłem kolejność. Zresztą pamiętam podobne uwagi na poprzednich konferencjach i nie wyciągnąłem z tego właściwych wniosków! Oj, niedobrze, niedobrze.

Wyniki mojej prezentacji można znaleźć w podsumowaniu, które przygotowali organizatorzy. Pozostawię je bez komentarza, pozwalając na własne wnioski.

"Podsumowanie ankiet uczestników - sposób przedstawienia tematu (na podstawie czternastu wypełnionych ankiet)
- 4 osoby oceniło prelekcję jako bardzo dobrą (29%)
- 9 osób oceniło prelekcję jako dobrą (64%)
- 1 osoba oceniła prelekcję jako słabą (7%)

Najczęściej pojawiające się komentarze:
- mało czasu (czyli jest zainteresowanie! może warto zainwestować w warsztaty w tej tematyce - kilka osób wyraziło chęć dalszego zagłębienia się w temat)
- powinno pojawić się więcej informacji na temat 'współpracy z Java'
- 'brak IDE'
- dobry sposób prezentacji
- jasne i klarowne przedstawienie tematu
- wzbudzenie zainteresowania - interakcja z uczestnikami"

Zostałem na kolejnej prezentacji Jakuba o programowaniu równoległym. Doskonale przygotowane slajdy, dykcja, przygotowanie merytoryczne i właściwe przeplatanie slajdów z przykładami sprawiło, że bez wahania mógłbym od razu wystawić najwyższą notę. Kiedy dodać, że przedstawiał programowanie giełdy, natychmiast ujął mnie za serce! Trudno byłoby przebić Jakuba w jakości prezentacji. Przyglądałem mu się chwytając każdy jego gest, zmianę intonacji, przejścia między slajdami a przykładami, aby samemu wdrożyć kilka tricków w swoim repertuarze prezenterskim. Przez 1 godzinę nauczyłem się więcej niż przez ostatnie własne publiczne wystąpienia. Podobało mi się!

Nie szukałem specjalnie wpadek (może na początku, kiedy zobaczyłem slajdy i gościa, sądząc, że będzie nadrabiał miną, bo były takie przesłodzone), ale na minus mógłbym wskazać metody, którym uzasadniał swoje tezy, które kilkukrotnie nie przypadły mi do gustu. W wielu miejscach były w stylu (baaaardzo upraszczam) "Bo tak jest dobrze i koniec, a skoro ja mówię, to wiem". Z wieloma tezami się nie zgadzałem, ale że nie odpuszczałem sobie z pytaniami do Jakuba, wielokrotnie gryzłem się w język, aby nie spacyfikować prezentacji. W końcu to nie ma być dyskusja wyłącznie między nami. Widząc nikłe zaangażowanie uczestników, odpuszczałem z krytyką, zostawiając sobie jedynie możliwość zadawania pytań uzupełniających. Dodatkowo, na minus położę całkowitą ignorancję języka funkcyjnego F#, bo..."Jestem zawalony robotą." usłyszałem. Porażka! Szczególnie, że F# jest językiem pierwszej kategorii, obok C#, na platformie .Net i wspieranym przez najnowszą wersję Visual Studio. Kiedy zobaczyłem pewne funkcyjne konstrukcje w C# - użycie typu Func (podobnie jak w Scali) oraz wyrażenia lambda (podobnie do tych z Java 8) - aż się prosi o F#. A jednak "zawalenie robotą" bierze górę :(

Możliwość poznania nowych osób uważam za bezcenne i to jest głównym motorem, aby uczestniczyć w konferencjach. Nauczyłem się, aby wyznacznikiem jakości konferencji była liczba osób, które poznam. W zasadzie uważam, aby czas konferencyjny spędzić na ciągłej rozmowie - niechby była o niczym, ale interakcja z żywą istotą informatyczną wynoszę na plan pierwszy.

Dowiedziełm się, że kilku uczestników mojego wystąpienia wyraziło zainteresowanie tematem - w tym jedna firma! - co dobrze wróży na przyszłość. Widać, że wciąż nie prezentuję właściwych argumentów na użycie Clojure, ale mój upór zdaje się zamieniać w realne działania u obserwatorów. I o to właśnie chodzi - zainteresowanie tematem, aby samodzielnie móc ocenić przydatność narzędzia - języka funkcyjnego Clojure, który jest "niewielką biblioteką do programowania współbieżnego" (to wersja dla programistów Java) i pozwala konstrukcjami funkcyjnymi na łatwiejsze testowanie (to wersja dla napaleńców TDD i okolic). Jak można było usłyszeć (trochę nawet doświadczyć, kiedy zszedłem na poziom REPL) na mojej prezentacji "O tym jak języki funkcyjne upraszczają testowanie i programowanie współbieżne - na przykładzie Clojure" łatwość testowania i użycia współbieżności w naszych aplikacjach są niezwykle zbieżne, żeby nie napisać, że są nierozłączne. Czym bardziej testowalny kod, tym łatwiej go użyć wespół z równoległością i na odwrót. Ciekawym Twojej opinii.

I pytanie podsumowująco-zaczepne: Czy kiedykolwiek programowałeś/-aś aplikacje korzystając ze współbieżności? Spodziewam się, że większość niestety odpowie "Tak, ale czasy, kiedy to było zaliczyć można do średniowiecza". Zastanawia mnie, dlaczego programiści Javy mając do dyspozycji wsparcie Javy dla współbieżności - chociażby ostatnie zmiany w pakiecie java.util.concurrent - tak niewiele wiedzą i z takim oporem korzystają z tego. Dlaczego? Tak bardzo ograniczani jesteśmy przez szkielety programistyczne (ang. frameworks)?! Czy to musi nas, aż tak ograniczać?!