02 czerwca 2012

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

14 komentarzy:

  1. > A jednak "zawalenie robotą" bierze górę

    Jacku, nie każdy ma taką fajną ciepłą posadę jak Ty i nie może w czasie pracy poświęcić tyle czasu na research. Czeba przecież coś na stand-up'ie powiedzieć, że się coś zrobiło.

    Co do programowania współbierznego w Javie, właśnie całość obsługi wielu wątków została przerzucona na kontenery Servletów / frameworki i się pisze na codzień jakby "jednowątkowo". Wszystko to po to, aby niedoświadczonym progamistom było łatwiej w pracy i nie popełniali podstawowych błędów przy wielu wątkach. Wyjątkiem są niektore specyficzne branże (np. bankowa) gdzie tam trzeba pisać wielowątkowo.

    Ponadto po prezentacjach Venkata Subramaniama na 33degree uważam że wielowątkowość w Javie jest słaba.

    OdpowiedzUsuń
  2. Co to za wyświechtane stwierdzenie to "taką fajną ciepłą posadę jak Ty i nie może w czasie pracy poświęcić tyle czasu na research"?! Jeśli nie masz czasu na research, to jak zrealizujesz "Czeba przecież coś na stand-up'ie powiedzieć, że się coś zrobiło."?! Uważam, że jedno wyklucza drugie i bez czasu na rozpoznanie daleko nie zajedziesz, ani projekt, ani zespół, w którym jesteś. W zasadzie to nasz obowiązek, aby nie klepać ciągle tego samego bezwiednie i bez świadomości co dzieje się pod spodem.

    A dodatkowo zakładam, że wielu czytelników mojego bloga to mają daleko do określenia siebie jako "niedoświadczonym progamistom było łatwiej w pracy i nie popełniali podstawowych błędów przy wielu wątkach.". Wymaga się od nich więcej niż...biadolenia :P

    Proszę o rozwinięcie "wielowątkowość w Javie jest słaba."

    OdpowiedzUsuń
  3. Że tak się wtrącę, cała książka Venkata jest o minusach wielowątkowości w Javie. Wszędobylscy mutanci, brak STM-u, brak aktorów, lansowanie potencjalnie bardzo niebezpiecznych rozwiązań (synchronized i hopla). "It's just waiting for you to fail!"

    Jak masz trochę wiedzy i dyscypliny, to być może uda ci się w Javie solidnie napisać nietrywialny kod wielowątkowy. Z drugiej strony bardzo łatwo zrobić coś źle.

    Dodajmy do zestawu powszechne napierdalanie oparte na dziurawej wiedzy ze szkoły i poganiane przez szefa...

    OdpowiedzUsuń
  4. @Jacek
    Jeśli jest to research dla rzeczy które są w projekcie i na które odpowiedź trzeba znaleść to ok - trzeba to zrobić i nikt złego słowa na to powiedzieć nie może. Co do research'u innych tematów (bibliotek, języków, F#, patternów, czytania blogów itp.) to nie zawsze można sobie na to pozwolić, a na pewno nie w dużym zakresie czasowym.

    Co do "słabej wielowątkowości" to już Konrad w międzyczasie napisał: "bardzo łatwo zrobić coś źle". Jeśli ktoś nie siedzi w temacie na codzien to wiedza o wątkach szybko umyka. Pamięta się, że jest synchronized, ale najczęściej nie rozwiazuje to wszystkich problemów.

    OdpowiedzUsuń
  5. Jestem zdumiony tym, co piszesz, bo "Co do research'u innych tematów...to nie zawsze można sobie na to pozwolić, a na pewno nie w dużym zakresie czasowym." "wkładasz w moje usta rzeczy, których nie powiedziałem" i używasz ogólników, które nie poprawiają dyskusji.

    Weźmy pierwszą tezę "Co do research'u innych tematów...to nie zawsze można sobie na to pozwolić". Czy mógłbym założyć, że w takim zespole rozwój w zasadzie zamiera?! Termin "nie zawsze" nie pozwala na precyzyjną odpowiedź, bo wszystko w naszym życiu zależy od wielu czynników, że często trudno w ogóle cokolwiek zaplanować. Mimo wszystko twierdzę, że 4-8h tygodniowo musimy przeznaczać na własny rozwój = dotykanie spraw, które nie są i nie będą wkrótce wykorzystywane w projekcie/-ach. To musi być coś w rodzaju powiewu świeżości, co uważam za podstawowy aspekt "zdrowych" zespołów.

    Druga teza "a na pewno nie w dużym zakresie czasowym." jest zbyt ogólnikowa, więc zawężam ją do 4-8 godzin tygodniowo. Czy mógłbyś zgodzić się z tą tezą? Jeśli nie, ile uważasz za bezwzględne minimum tygodniowo.

    OdpowiedzUsuń
  6. Jacku, nie wkładam w twoje usta czegoś czego nie mówiłeś. Należy poświęcać czas na rozwój osobisty, Wujek Bob twierdzi że powinno to być 20h tygodniowo, przy czym jest to czas PO ZA czasem pracy.

    A ile projekt powinien przeznaczać na rozwój / powiew świeżości?

    W zespołach, nie każdy zajmuje się research'em. Zazwyczaj jak już, to robią to najczęściej osoby najbardziej doświadczone. I jak projekt jest przykładowo w Javie (i jest to wymaganie klienta), to nikt nie będzie patrzył na C#, F#, czy Scalę. Ja uważam, że kazdy powinien coś tam probować ulepszyć, ale nie kazdy projekt na to pozwala.
    Być może dlatego Jakub nie zapoznał się z F#?

    Mój zespół na szczęscie nie zamiera. Wykorzystujemy framework frontend'owy, którego nazwę pierwszy raz usłyszałem w tym projekcie. Udaje nam się również wprowadzać sporo technicznych usprawnień.

    OdpowiedzUsuń
    Odpowiedzi
    1. Eee tam, coś mi mówi, że przyłożyłeś do "research" jakąś magię, a to po prostu usystematyzowana nauka - bez skoków w bok, lewo, prawo, jak jakieś ruchy robaczkowe. Tego u nas brakuje. Brakuje usystematyzowania nauki, a zalew informacji dodatkowo utrudnia opanowanie przysłowiowego braku czasu. Piszę to tak pewnie, bo doświadczam tego na co dzień u siebie.

      Z tym nie mogę się zgodzić - "I jak projekt jest przykładowo w Javie (i jest to wymaganie klienta), to nikt nie będzie patrzył na C#, F#, czy Scalę." Właśnie uczestniczę w projekcie w Javie, w którym należy uzupełnić system o pewną funkcjonalność przetwarzania nieustrukturyzowanego XMLa (brak XSD) i jak ulał pasuje mi to pod dynamiczne programowanie (Java również dałaby radę, ale skoro XML jest dynamiczny, to i tak język zdaje się pasować jak ulał). Co planuję, to właśnie zaproponować prototyp i korzystać z niego jak z biblioteki zewnętrznej.

      I teraz zaczynamy poruszać odwieczny problem/kwestię, co można, a czego nie w projekcie, w którym króluje Java. Czy to wyklucza stosowanie biblioteki X? Nie, jeśli jest użyteczna. A co, jeśli zewnętrzna biblioteka napisana jest w Scali? Czy wyklucza ją to? Po ewaluacji stwierdzamy, że nie, bo potrzeba nam właśnie tego, a nikt się na tej tematyce nie zna. Co robimy? Akceptujemy bibliotekę, a nie wprost i nowy język.

      Dlaczego sytuacja zmienia się (często na gorsze, tj. staje się nieakceptowalna), kiedy mielibyśmy zamienić słowo "zewnętrzna" na "wewnętrzną" w powyższym? Czynniki negatywne, jak pewność zachowania ciągłości rozwoju biblioteki są, a "zewnętrzność" nawet może komplikować sprawę. Tak czy owak, wydaje się, że często akceptujemy "mniejsze zło" wierząc, że inni potrafią, a my to jedynie w Javie.

      Dlaczego projekty muszą być jednojęzykowe, kiedy pojęcie "polyglot programmer" wiąże się z czymś pozytywnym?! Tego jeszcze nie mogę pojąć, ale absorbuję wiedzę zewsząd, aby zmierzyć się z tą kwestią.

      Usuń
    2. Sporo zależy ile w kwestii technologii ma do powiedzenia klient. Jeśli mamy klienta, którego nie interesują szczegóły techniczne, to mamy pełną wolnosć i możemy urzywać wielu języków i dowolną bazę danych. W przypadku gdy klient jest bardzo blisko (wręcz w środku) projektu / zespołu (ma tam swoich kretów) to bardzo uważnie patrzy na ręce i jakakolwiek próba "odskoku w bok" (mam namyśli użycia np. biblioteki w Scali) albo będzie całkowicie niemożliwa, albo bardzo trudna. Nie zawsze też chce sie na to zgodzić kierownik projektu.

      Jeśli chodzi o wykorzystanie czegos Javowego, to już raczej przechodzi bez większego problemu, bo to standard korporacyjny, pewnie jest stabilne itd.

      Inna kwestia to sporo zależ od ludzi jakich masz w projekcie. Jeśli każdy jest naszego pokroju (chce się rozwijać, czyta blogi, eksperymentuje po pracy) to można robić cuda w projekcie i mieć wszystkie seksi technologie. Jak masz betony (ludzi których nie da się przekonać do niczego nowego, piszą proceduralnie w Javie, debugera urzywają częsciej niż kompilatora, a z technologią mają kontakt tylko w godzinach pracy) w projkcie to zapomnij o powiewie świerzości. A zazwyczaj w projekcie nie masz tylko pasjonatów ale i tych mniej zaangarzowanych: http://mbartyzel.blogspot.de/2012/03/craftsmanship-nie-dla-wszystkich.html

      Usuń
    3. A możesz napisać, cóż takiego w owym Groovim moglibyśmy znaleźć, co pomogłoby ruszyć ów "beton technologiczny" w projekcie? Pytam trochę prowokacyjnie, bo mam świadomość istnienia Groovy oraz jego roli w projektach. Chętnie jednak usłyszałbym coś więcej ponad "polecam Grooviego".

      Usuń
  7. No ale skoro masz czas na researche to przeciez mozesz sam rozpoznac ;)

    OdpowiedzUsuń
    Odpowiedzi
    1. Co rozpoznać? Odpowiedź nie jest podlinkowana pod odpowiedź i nie wiem, do czego się odwołuje.

      Usuń
    2. Juz ratuje - chodzilo o watek dot. Groovego.

      Usuń
    3. Moja ewaluacja nie pomoże mi w poznaniu myślenia Corvina o Groovy. Jego doświadczenie z tym językiem może prowadzić do innych wniosków, mimo że wychodzimy od tego samego źródła.

      Usuń