"Otwórz swój projekt albo daj mu umrzeć", Krzysztof Debski.
Był to keynote, w którym prelegent z Allegro opowiadał o tym, że warto otwierać swój kod, tj. wypuszczać go w open source. Krzysztof najpierw opisał jak to było, gdy nie dzielili się swoimi dokonaniami ze światem zewnętrznym. Tworzyli więc pewne rozwiązania, a po jakimś czasie okazywało się, że ktoś robił coś podobnego i lepszego. A jeszcze później trzeba było się zmigrować do innego rozwiązania.
Natomiast, gdy jakiś projekt wychodził do open source’a, to nie dość, że inni zaczynają go używać, to i też rozwijać. A to strasznie przyspieszyło development danego rozwiązania. Nie trzeba oczywiście udostępniać wszystkiego (główny core biznesu można sobie zostawić), ale pewne rzeczy czasem warto upublicznić.
"Jak prezentować swoje pomysły przed ludźmi technicznymi i biznesem - rady od zwykłego programisty dla programisty", Sławomir Sobótka.
Nie widziałem w tym slocie nic lepszego dla siebie, więc poszedłem na „pewniaka”, czyli wystąpienie Sławka. Prezentację przejrzałem sobie wcześniej, wiedziałem czego się spodziewać, ale i tak było warto posłuchać i poznać parę wskazówek dla prelegentów.
Ludzie nie chcą słuchać o innych ludziach, tylko o sobie. Powinniśmy podkreślać, że prezentacja jest dla nich i przykładowo nie mówić „ja zrobiłem to i to…”, tylko raczej powinniśmy pytać się publiki, jak ona by się zachowała, gdyby miała taki problem u siebie. Taka sztuczka sprawia, że słuchacze zaczynają myśleć o tym problemie i się z nim utożsamiać. Zyskujemy sobie wtedy zainteresowanie słuchaczy.
Innym błędem, często popełnianym przez początkujących prezenterów, jest mówienie na początku wystąpienia, że są raczkujący w danym zagadnieniu, albo, że się nie przygotowali itd. Jest to spory błąd, bo od samego początku nastawia słuchaczy negatywnie do prelegenta. Można jedynie powiedzieć, że się przykładowo sepleni, ale nie powinno to wpłynąć na jakość prezentacji. Trzeba trochę z tego zażartować, aby rozluźnić atmosferę.
Jest sporo poradników, jak robić prezentację, jak się przygotowywać, ale tak naprawdę to każdy musi wypracować sobie swój sposób. No i wiadomo, że prezentacje robione na kolanie dzień wcześniej nie mogą się udać.
Przygotowania przygotowaniami, ale co z stresem przed widownią? Warto na pewno przyjść wcześniej, poczuć klimat sali, na spokojnie się rozłożyć i przyzwyczaić do otoczenia. A gdy pojawia się stres? Emocje są przez nas rozpoznawane w ciągu 0.3 s i mamy tylko 0.2 s na to, aby nazwać nasze uczucie i zlokalizować, z jaką częścią ciała jest to powiązane. Dzięki temu cukier będzie dopływał do kory przedczołowej, a nie do układu limbicznego.
Sławka osobiście denerwuje, gdy prelegent zadaje pytanie publiczności i sam podnosi rękę do góry sugerując odpowiedź. Ja na to dotychczas nie zwróciłem uwagi i osobiście nie przeszkadza mi to. Dla mnie jest to sygnał, że pytanie nie jest retoryczne, że prelegent oczekuje odpowiedzi, a także sam korzysta z rzeczy, o które pyta. Dodatkowo może to trochę obudzić publiczność i zachęcić do interakcji.
Na koniec Sławek zachęcał do nakręcenia video ze swojej prezentacji. Można to uczynić na większości polskich JUG’ów. Następnie należy je obejrzeć kilkakrotnie. Raz ogólnie, raz zwrócić uwagę na głos, kolejnym na reakcję ludzi, następnym na mowę ciała itd. Na koniec trzeba wyciągnąć wnioski i się poprawić.
Slajdy z prezentacji można przejrzeć tutaj:
https://prezi.com/lwiqdtc1oe9u/jak-prezentowac-swoje-pomysy-przed-ludzmi-technicznymi-i-biznesem/
"Are you aware of /bin of your JDK?" Andrzej Grzesik
Na prezentację się chwilę spóźniłem, ale Andrzej ogólnie pokazywał narzędzia, jakie każdy ma w swoim JDK. Było o javac, javap, jps, jar, jmap, jhat, jstack (wypisuje stacktrace’y), jstat, jstatd (monitoring zdalnej maszyny).
Większość tych narzędzi już widziałem w akcji. Nowy był dla mnie
jhat. Potrafi on wystawić serwer http i można za jego pomocą analizować to, co znajduje się na starcie naszego procesu javovego. Ponadto udostępnia on OQL - Object Query Language do wyszukiwania naszych obiektów na owej stercie.
W nowym JDK 9 ma wejść nowe narzędzie jcmd, które ma zastąpić wszystkie te pozostałe narzędzia. Sensowne posunięcie, zwłaszcza, że część tych funkcjonalności powiela się między narzędziami. Na koniec było jeszcze o
Jvisualvm i plugine
visualgc.
"Need for async: In pursuit of scalable internet-scale applications", Konrad `ktoso` Malawski
Konrad opowiadał o wielu kwestiach związanych z przetwarzaniem wielowątkowym. Było o Unfair scheduling’u, czyli gdy jakiś proces jest głodzony przez scheduler’a i jakie są sposoby radzenia sobie z tym, czyli o algorytmach nieblokujących. I tak
Lock-free (inaczej Lock-freedom), jak mu się nie uda uzyskać lock’a to się cofa i próbuje jeszcze raz.
Wait-free (albo Wait-freedom) dodatkowo wprowadza maksymalną liczbę prób, jakie może podjąć algorytm, aby uzyskać locka na potrzebnym zasobie.
Było jeszcze
java nio, czyli o nowym sposobie dostępu do plików. Na poziomie systemu operacyjnego operacje wejścia / wyjścia są bardzo czasochłonne, ponieważ system musi się przełączyć pomiędzy user mode a kernel mode. I to się dzieje wielokrotnie podczas typowej pracy z plikami, a jak wiadomo to kosztuje czas i zasoby. Rozwiązaniem tej kwestii jest korzystanie z
Zero-copy.
Było jeszcze parę pobocznych tematów, ale podsumowując prelekcję, to powinniśmy wybierać narzędzia pod nasze problemy, a nie ze względu, że są na hype.
"Vert.x - wydajna i skalowalna platforma", Bartek Zdanowski
Bartek bardzo pobieżnie i marketingowo przedstawił narzędzie
Vert.x Posiada ono swoją szynę zdarzeń, za pomocą której przesyłamy zdarzenia, które następnie są wykonywane przez inną cześć aplikacji. Czyli możemy tworzyć aplikacje wielowątkowe. Dla mnie najciekawszy jest fakt, że z Vert.x’a można korzystać z Javy, Grooviego, Ruby jak i JavaScript’a. Jeszcze do końca tego nie pojmuję, jak to jest zbudowane, ale z prezentacji wynikało, że część serverowa, pisana np. w Groovym, może rzucić event’a, który zostanie obsłużony po stronie przeglądarki w JavaScripcie.
Generalnie zabrakło mi trochę konkretnych przykładów, zamiast przymiotników, jaka to nie jest wspaniała technologia. Cała prezentacja chyba zrodziła więcej pytań i wątpliwości niż wyjaśnień, co było widać po ogromnej ilości pytań na koniec.
"Elasticsearch at Scale of Billions of Documents," Igor Kupczyński
Na tej prezentacji spodziewałem się doświadczeń i wniosków z napotkanych problemów z użyciem Elastic’a. Sam z niego ostatnio sporo korzystałem w projekcie, więc byłem w temacie.
Igor sugerował, aby definiować
minimum_master_nodes=(n+1)/2, gdzie
n to [chyba] liczba wszystkich nodów w klastrze.
discovery:
zen:
minimum_master_nodes: 2
Nie powinniśmy również wykorzystywać Elastic’a jako nasze główne źródło prawdy, tylko powinniśmy przechowywać dane w innej bazie / bazach i je replikować do Elastica.
Nie powinniśmy również pozwalać, na ponowne tworzenie utraconych shardów. Pozwoli to nam uniknąć niekonzystencji. Przykładowa konfiguracja dla 4ch nodów w klastrze:
gateway:
expected_data_nodes: 4
recover_after_time: 48h
Było też o tym jak przeprowadzać update’y oprogramowania lub sprzętu, aby klaster dalej działał. Cała procedura jest opisana na stronie Elastic’a pod hasłem:
Rolling Restarts.
Dalej było o ustawieniach pamięci, której 50% powinniśmy ustawić dla JVM heap’a, a drugie tyle dla Lucynki. Powinniśmy jednak mieć mniej niż 32 GB pamięci operacyjnej ze względu na
compressed object pointers. Powinniśmy również tą pamięć zaalokować od razu na starcie:
bootstrap:
mlockall: true
i sprawdzić, czy JVM nam na to rzeczywiście pozwala:
curl -s $URL/_nodes/process?pretty | grep mlockall
Było jeszcze o
Fielddata, garbage collector’ze i paru innych tematach. Powinniśmy raczej obserwować nasz klaster, a nie go stroić, co radzą również twórcy tego rozwiązania. Do monitoringu Igor polecał m.in.
Kopf,
Elastic HQ,
Bigdesk i pluginy do
Nagios’a. Spis tego typu narzędzi możemy znaleźć na oficjalnej stronie:
Health and Performance Monitoring.
Wykład fajny, ale wolałbym go usłyszeć po polsku. Slajdy są dostępne tutaj:
ELASTICSEARCH IN PRODUCTION.
"Czego Javowiec nauczy się od Haskella?", Tomasz Nurkiewicz
Najlepszy, wg mnie, wykład został na koniec. Nie dotyczył on co prawda jakiejś konkretnej przełomowej technologii, ale zmieniał trochę światopogląd na nasz sposób programowania i wywracał myślenie do góry nogami. O dziwo na prezentacji nie było kodu
Haskell’a, a chodziło o pewne koncepty z tego języka, a właściwie to, czego tam nie ma: null, zmienne, wyjątki, void, Object, pętle, przeciążanie metod, efekty uboczne. Tylko jak bez tego wszystkiego żyć? A no da się.
W Haskelu już na podstawie definicji funkcji, można wywnioskować, jaka jest jej implementacja. Bardzo często mamy jedną możliwość implementacji takiej funkcji. Dlatego powstało
Hoogle, czyli takie Google dla Haskella do wyszukiwania funkcji na podstawie sygnatury. W IntelliJ’u jest to zdefiniowane jako Structural Search
Ctrl + Shift + S.
I tak, jak Java w tym roku obchodziła 20-lecie, tak
null obchodził 50-lecie. Ile to katastrof z tego faktu wynikło… W Javie i Scali mamy niby teraz
Optional, ale i tak może ono być null’em:
Optional<String> name = null;
albo jeszcze lepiej:
Optional<String> name = Optional.of(null);
więc to tak naprawdę niczego nie rozwiązuje. A w Haskellu tak się (podobno) nie da. Tomek pokazywał przykład w
Kotlin’ie, jak on nam uniemożliwia wykonanie kodu, który jest niebezpieczny pod względem null pointerów.
A propo de facto, czy my w ogóle mamy w Javie wskaźniki?
Dalej Tomek podawał przykłady aplikacji, które nie zmieniają stanu, a jedynie tworzą nowe, z ewentualnymi referencjami do poprzednich stanów. I tak przykładowo działa Git, gdzie każdy commit to nowe pliki + wskazanie ma poprzedni commit. Baza danych
Datomic została napisana w
Clojure i posiada ona tylko jedną zmienną. Nie można w niej edytować danych - baza trzyma całą historię zmian.
I ostatnia rzecz, która wywarła na mnie ogromne wrażenie, to eksperyment
John'a Carmack'a, twórcy Wolfenstein'a 3D, Doom'a i Quake'a, który przepisał pierwszy tytuł do Haskella, czyniąc go czysto funkcyjnym. Pomysł ten mnie zniszczył w pierwszej chwili i dał sporo do myślenia. Myślę, że to świetna metoda nauki. Pozatym kod tych produkcji jest w całości dostępny na githubie:
github.com/id-Software.
Podsumowując, Confitura w tym roku była na pewno lepiej zorganizowana (mniejsze kolejki do rejestracji), była walka o wejściówki (ale się udało), a napoi chłodzących było pod dostatkiem w ten upalny dzień. Co do agendy, to mam wrażenie, jakby poza ścisłą, oczywistą, polską czołówką prelegentów, dostało się sporo prezentacji z przypadku. Albo takich, co już były. No ale cóż, taka była wola ludu.
