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

Sprawdź TAB w interpreterze scala

Czas biegnie nieubłaganie i coraz częściej doświadczam olśnienia właściwego przeznaczania czasu na rzeczy, które mają dla mnie znaczenie (zamiast na takie, które jedynie przez krótki moment wydają się być wartościowe). Widzę to chociażby na przykładzie moich dzieciaków, szczególnie tego najmłodszego, ale również i najstarszej. Pierwszy może pochwalić się pierwszym ząbkiem (poza innymi nowinkami, którymi obdarza nas właściwie każdego dnia), a druga ukończoną 18tką (!) Jak ten czas leci! Kiedy dodać do tego "zabawę" w egzamin gimnazjalny u drugiego syna, czasu zdecydowanie nie starcza na wszystkie uciechy.

Mimo to, nie poddaję się ze Scalą i wykorzystując czas w drodze do pracy komunikacją miejską udało mi się przejść przez darmowy rozdział Functional Programming in Scala. Nie zamierzam się rozpisywać na jej temat, bo można krótko: "Polecam!" Jeśli tylko autorzy utrzymają narrację, zapowiada się naprawdę wyśmienita książka. Każdemu początkującemu w programowaniu funkcyjnym polecam, a jako, że przykłady będą w Scali, to zainteresowanym tym językiem przede wszystkim. W zasadzie trudno wyobrazić mi sobie programistę dowolnego poziomu, który nie skorzystałby z lektury tej książki. Chociaż, jeśli się zastanowić, to jest to wrażenie po jednym rozdziale, który koniec końców nie jest zapewne jeszcze nawet w finalnej wersji. Nadzieja jest i poprosiłem Manning o dostęp do MEAP. Właśnie dostałem odpowiedź, że zgoda jest. Będzie okazja dostąpić zaszczytu przeczytania kolejnego rozdziału "Strictness and laziness".

Jako, że próbuję ukończyć lekturę innej książki o programowaniu funkcyjnym, tyle że w F# - Real-World Functional Programming (With examples in F# and C#), to Scali nie poświęcam tyle czasu, ile chciałbym. Nie zapominam również o Clojure, któremu poświęciłem wszystkie moje publiczne wystąpienia w 2012 do tej pory. A jest jeszcze planowanych kilka (niektóre jeszcze niepotwierdzone) - GeeCON, spotkanie na Warszawa JUG, podobnież Softdevcon, jar.camp(), podobnież Eclipse DemoCamp w Poznaniu i Warszawie, oraz planowane wspólne wystąpienie z Grzegorzem B. na Confiturze. Jeszcze będzie spoooro tego Clojure w moim życiu. Konrad Garus utwierdza mnie w przekonaniu, że nawet uda mi/nam się coś w Clojure napisać - zachęcam do udziału w zabawie w projekcie librarian-clojure.

Kiedy jednak zasiadam przy kompie, zaczynam od odrobiny Clojure, a później szczypty Scali. Jest to o tyle łatwe, że wystarczy uruchomić lein2 repl, aby doświadczyć przyjemności pracy z Clojure, a scala, aby skorzystać z interpretera Scali.

I tak bodajże wczoraj zasiadłem przy Scali i kiedy zacząłem wpisywać kawałki kodu javowego, jakoś niechcący skorzystałem z klawisza tabulacji. Jakież było moje zdumienie, kiedy dla typów z dopiero co zaimportowanego pakietu java.net (import java.net._) zacząłem dostawać w odpowiedzi dostępne klasy, a później nawet i ich składowe - metody i pola. Trzeba było widzieć moją minę, kiedy uzmysłowiłem sobie siłę środowiska Scala, w którym mogłem śmiało wpisywać wyrażenia javowe, które wcześniej wymagały ode mnie pracy w IDE - nie zawsze zgodnie z moimi potrzebami.

Spróbuj samemu/-ej. Wystarczy pobrać dystrybucję Scali, uruchomić interpreter scala i zacząć od importu wybranego pakietu. Wtedy TAB i voila. Próg wejścia bardzo obniżony mając do dyspozycji bardzo dynamiczne środowisko, w którym odpowiedź jest natychmiastowa. To lubię!

p.s. Wciąż nie mogę oduczyć się rozpoczynania od nawiasu, kiedy widzę środowisko scala. Czarne tło interpretera Scali nie sprzyja koncentracji?

Fsharp, dotNet i okolice...dojrzałem - zarzucam JEE na rzecz ciekawiej zapowiadającej się platformy .Net

Ostatnie wpisy całkowicie odbiegały od moich ciągot programistycznych i bardziej skłonne były kierować czytelnika w stronę rozważań architektonicznych, projektowych. Jak ujął to mój kolega i stały czytelnik Notatnika:

Jak tak dalej pójdzie to będę Twój każdy post komentował. Przynajmniej dopóki nie przyprawisz mnie o przysłowiowy zawał :)

Przyznam się, że ostatnio obserwuje u Ciebie dużą zmianę. Pamiętam jeszcze jak przed podjęciem pracy w IBM spotkałem się z Tobą na Gigaconie. Wówczas opowiadałeś o Geronimo 2, który właśnie pojawiał się na rynku. To był pierwszy certyfikowany (oczywiście poza Glasfishem) serwer JEE 5. No i ta niezapomniana prezentacja z małpą.

Kiedy przyszedłem do IBM i pojawiłem się na pierwszej Javarsovii pamiętam jak powtarzałeś, że nie musisz identyfikować się z firmą, w której pracujesz. Że ograniczasz się do tego, co trzeba zrobić z klientami. A poza tym rozpoznajesz i bawisz się technologiami. Twój blog zaś był pełen rozwiązań niezależnych.

Teraz nastąpił niebywały przełom. Zaczynasz promować rozwiązania IBM. "Chełpisz" się nieco swoimi certyfikatami. A blog? Jest raczej pełen rozważań architekta rozwiązań niż programisty.

A że widzę, że taka droga też Ci odpowiada i daje możliwości rozwoju to serdecznie gratuluje :)

Dużo w tym uwag skłaniających do głębszej refleksji, której przez ostatnie dni było u mnie co nie miara. Trudno było mi się z tym pogodzić, ale coraz bardziej dostrzegam przytłaczające skomplikowanie technologii z obszaru "Java i okolice". Ostatni komentarz Michała Piotrowskiego, bardziej znanego jako chlebik, do wpisu "IBM WebSphere Application Server V8.0 Alpha ze wsparciem dla Java Enterprise Edition 6.0" jakby potwierdza ten trend:

Twój wpis Jacku prezentuje dokładnie to, co najbardziej mnie w Javie wkurza, a juz zwlaszcza w wersji EE. Sam spojrz ile podales nazw/linkow/technologii - w glowie sie kreci.

I nie wiem czy wlasnie ten entuzjazm dla nowych technologii nie napedza tego ciaglego gonienia za nowoscia u producentow tychze. Co i rusz powstaje cos nowego, dalej, szybciej i niby lepiej, a tak naprawde to czlowiek sie tylko denerwuje, gdyz ma poczucie, ze cos mu ucieka. Ale w sumie ja mlody jestem, moze sie nie znam.

Jakby tego było mało, Łukasz Rybka dorzucił coś od siebie w temacie, w relacji 4Developers 2010, czyli mogło być lepiej...:

Na samym końcu zawitał Jacek Laskowski ze swoją prelekcją na temat "Modele komponentowe SCA, OSGi, Distributed OSGi i OSGi Enterpise a Java EE". Na temat tej prelekcji nie będę nic pisać, gdyż temat jest dla mnie całkowicie obcy i większości z tego co Jacek mówił nie rozumiałem. Może kiedyś :)

czy później w odpowiedzi do mojego komentarza:

Odniosłem wrażenie, że znacząca większość osób obecnych na Twoim wykładzie wiedziała lub już miała styczność z OSGi - mnie w tym gronie nie było. Ale zdawałem sobie z tego sprawę jak szedłem na prelekcje, a mimo to poszedłem, bo lubię słuchać o rzeczach, których poziom mnie przewyższa znacznie mając nadzieję, że wrócę do tego tematu kiedyś mając jakiś obraz sprawy uzyskany dzięki takiej prelekcji :)

Wszystko to sprawiło, że uczucie zmęczenia i wypalenia technologicznego wzmagało się we mnie, aby ostatecznie sprowokować mnie do podjęcia decyzji, która będzie niemałym zaskoczeniem, a może nawet przyprawić o zawał serca, więc...jeśli ostrzeżony/-a, wciąż czytasz...kończę praktykowania Java EE, OSGi i wszystkiego co javowe na rzecz...technologii .Net (!) Tak, nie przesyłyszeliście się D.O.T.N.E.T. Kilkakrotnie spoglądałem w stronę tych rozwiązań i programowanie w C# wspominam jako bardzo ciekawe i pouczające doświadczenie, a niedawne próby z F# przekonały mnie do słuszności tej decyzji (pomijając, że jest ona moja, więc z gruntu słuszna w moim rozumowaniu :)).

Tym samym kończę wpisy na tym blogu, nie bez przyczyny zatytułowanego Notatnik Projektanta Java EE i zapraszam na nowy blog Notatnik Projektanta .Net. Do zobaczenia w innym świecie!

Inicjacja w F# już za mną - pierwsza aplikacja kliencka, która działa

Właśnie zakończyłem moją inicjację w F# (również znanego jako fsharp).

#light

open System
open System.Net
open System.IO
open System.Diagnostics

let HttpPost (url:string) =
  let request = WebRequest.Create(url) in
    request.Method <- WebRequestMethods.Http.Post;        
    request.ContentType <- "application/x-www-form-urlencoded";

  let response = request.GetResponse() in        
    let reader = new StreamReader(response.GetResponseStream()) in
      reader.ReadToEnd()

do let response = HttpPost "http://java.sun.com" in Console.WriteLine("odpowiedź: {0}", (response))

Nie jest to arcydzieło programowania funkcyjnego czy obiektowego, a przypomina stare dobre czasy programowania proceduralnego w C, więc możnaby powiedzieć, że nie ma się czym chwalić, ale chodziło mi raczej o zwrócenie uwagi w stronę tego języka i zdobycie kilku komentarzy, czy warto, czy idę w dobrą stronę, itp. Owe (arcy)dzieło stworzyłem na bazie przykładu Simple Web Service Consumer i zmierzam do czegoś bardziej wyrafinowanego, co w odpowiedzi otrzyma obiekt ze świata Javy. Taka skromna integracja światów .Net/F# ze SCA.

Skąd pomysł na fsharp? Wszystko zaczęło się od Clojure i mojego pierwszego na poważnie spotkania z językami funkcyjnymi. Coś we mnie pękło, coś się przestawiło i z programowania obiektowego zwróciłem się w stronę programowania funkcyjnego (PF). Podobno nie jest tak ciężko, a na pewno bardziej wieloprocesorowo i mniej pamięciożernie. Zalety są, a jedyną wadą, na jaką wciąż trafiam, to w zasadzie słabe rozpoznanie tego obszaru. Może dlatego mnie tak na to wzięło (objaw duszy odkrywcy?).

Komentarz Mateusza Mrozewskiego do Nowy serial "SCA praktycznie" - Zestawienie środowiska z Apache Tuscany i Eclipse IAM uzmysłowił mi, że brakuje mi języka spoza JVM, który mógłby być klientem usługi ATOMowej z artykułu. Przecież nie będę wracał do C czy C++, a do C# nie mam narzędzi, a nawet i systemu operacyjnego (od stycznia siedzę wyłącznie na MacOS), więc przypomniało mi się z F#. A może jest coś jeszcze alternatywnego i równie ciekawego?

Zainteresowanym programowaniem w F# proponuję książkę F# Programming na WikiBooks, bo sam poza istnieniem języka i kilku jego cech oraz tym pierwszym programem/skryptem, nic więcej nie wiem.

W planach mam opisanie konfiguracji środowiska do F# na MacOS, ale na razie walczę z zadaniem od Mateusza i lekturą kolejnej książki "Growing Object-Oriented Software, Guided by Tests", więc albo należy cierpliwie poczekać, albo przekonać mnie do zmiany planów :)