Pokazywanie postów oznaczonych etykietą java. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą java. Pokaż wszystkie posty

poniedziałek, 21 marca 2016

Chamberconf 2016

W weekend 5-6 marca 2016 miałem zaszczyt po raz drugi uczestniczyć w konferencji Chamberconf, którą również organizowałem. Rozpoczęliśmy już w piątek od pre-party. Kto chciał, mógł przyjechać wcześniej i już zacząć integrację z innymi uczestnikami. Bo głównie o to w tej konferencji chodzi, aby integrować się, poszerzać swoje horyzonty myślowe oraz wymieniać się doświadczeniami. W tym celu nie przekraczamy liczby 90 uczestników i spotykamy się daleko od miejskiego zgiełku, aby nic nie rozpraszało naszej uwagi. Dodatkowo zwiedzamy zamki - w końcu całkiem sporo ich na Dolnym Śląsku. Tym razem byliśmy w Pałacu Łagów pod Zgorzelcem. Miejsce trochę awaryjnie wyszło, ale nie było na co narzekać.

Po pre-party i krótkiej przerwie na sen, przyszedł czas na pierwszy dzień. Po krótkim przywitaniu uczestników pierwszy na scenę wszedł Jarek Ratajski z tematem "ScalaJS i architektura #noserver". Prelegent opowiadał, jak to dojrzewał jego pomysł, aby robić aplikacje internetowe bez serwera. Na początku był trochę hejt na REST’a, bo przykładowo czym jest nawiązywanie znajomości na facebooku? PUT czy POST?

Jarek pracując jakiś czas temu mocno z frontendem, mockował backend i te wydmuszki szły do klienta. Można w ten sposób już sporo przetestować (w sensie UX'a) i mieć szybki feedback od klienta. Skoro to już jakoś działa, to co jeszcze trzeba było dorobić aby można było używać?

Następnie było trochę o ScalaJS. Jest to kompilator, a dokładniej transpiler (czyli kompilator jednego języka programowania w drugi) Scali do JavaScriptu. Zyskujemy silne typowanie, wykrywanie literówek w nazwach i inne. Działa z bibliotekami JavaScript'owymi jak React czy AngilarJS. Jarek przekonywał nas, że warto wybrać to narzędzie, jeśli zespół zna Scalę, a musi robić frontend w JavaScripcie. Ale teraz mamy już ECMAScript 6 i TypeScript, więc wybór nie jest już taki oczywisty dla pozostałych niescalowych developerów.

Ale mniejsza o technologie wykonania, liczy się pomysł. Jarek pokazał na przykładzie czata (standardowy przykład tego typu problemów), jak można go zrealizować w trochę inny sposób. Może być wiele niewielkich serwerów (node’ów, aktorów) z których korzystają końcowi użytkownicy, którzy generują eventy. Zdarzenia, zależnie od logiki aplikacji, są zapisywane na node’ach. I teraz potrzeba, aby te node’y się wymieniały informacjami bezpośrednio, lub za pomocą dedykowanych do tego węzłów.

Demo wyszło bardzo fajnie. Prelegent pokazał, co się stanie, gdy wszystkie węzły padną i jak większości użytkownikom wyczyści się local storage w przeglądarce. Wystarczy, że jeden będzie miał te dane u siebie i gdy serwer wstanie to sobie odtworzy poprzedni stan. Gdy kolejne węzły się dołączą, to u nich też się to odtworzy i zapisze się w lokalnej pamięci w przeglądarce. I gdy teraz te poszczególne węzły będą działały na maszynach użytkowników, to można w całości, albo prawie w całości zrezygnować z serwerów.

Jarek fajnie opisał, jak mogło by to działać na przykładzie Wikipedii. Każdy wchodzący na stronę / podstronę miały zapisane u siebie te artykuły, które przeglądał. I jak ktoś będzie chciał przeglądać jakiś artykuł, to go ściągnie od innego użytkownika i też będzie miał kopie u siebie. W takiej konfiguracji mogły by zaginąć stare, mało popularne artykuły. Ale skoro nikt tego dawno nie czytał, to widocznie nie jest jakoś specjalnie potrzebne ;)

Jarek opowiadając o swoich przemyśleniach, doszedł do wniosku, że implementując to podejście to chyba (albo prawie na pewno) na nowo napisał model aktorowy. W takim systemie jeszcze sporym wyzwaniem jest zapewnienie bezpieczeństwa, ale da się to zrobić. Fajny był przykład o myśleniu o koncie w banku w skali galaktycznej. Jarek jeszcze bardzo polecał filmiki pana: Haoyi Li odnośnie ScalaJS. Ja chwilę ten: SBTB 2014, Haoyi Li: Cross-platform development with Scala.js oglądałem.

Jako następny na scenie pojawił się Artur Suchwałko z tematem "Budowa modeli predykcyjnych w R". Artur jest organizatorem grupy Data Science Wroclaw. Artur pokazał co można robić w języku R. Za pomocą niewielu linijek, można sobie przeanalizować pewien zbiór danych, aby odpowiedzieć (albo chociaż próbować) na jakieś pytanie biznesowe. Dane trzeba sobie wcześniej jakoś przygotować, zrozumieć, wyczyścić (np. zapchać czymś, gdy brakuje wartości), zanalizować, utworzyć cechy pochodne (kombinacja podstawowych), wybrać cechy, model i ocenić jakość. Do tego wszystkiego można zapiąć język programowania R, który jest obecnie standardem w bioinformatyce. Tak mówi Wikipedia, więc to prawda ;-) A wszystko ponoć za sprawą projektu bioconductor.org. Konkurencją dla R jest Python jak i komercyjne narzędzia jak: SPSS, SAS, RapidMiner, Statistica.

Wykład był fajny, poszerzający horyzonty myślowe. Warto uczestniczyć w trakcie konferencji na takich prelekcjach, bo w domu / w pracy niekoniecznie będzie czas na poznanie takich narzędzi. Jak dla mnie łatwość (a może szybkość) z jaką R radzi sobie z wizualizacją jakiś analiz była zaskakująca. Trzeba jednak mieć wg. mnie sporą wiedzę z zakresu statystyki, aby się zajmować tego typu problemami.

Po wykładzie Artura nastał czas na część, za którą byłem w dużej mierze odpowiedzialny, czyli Pecha Kucha. Formuła polega na pokazaniu 20 slajdów gdzie każdy przeskakuje co 20 sekund. Jest więc niecałe 7 minut na przedstawienie swojego tematu. Było to po raz pierwszy w Polce na konferencji IT na taką skalę, bo wystąpiło 11 osób. Podobno wcześniej ktoś coś pojedynczo próbował robić - ale tylko podobno. Tematyka była dowolna, choć w większości przedstawiane tematy były techniczne, lub półtechniczne. Po rozmowie z uczestnikami okazało się, że forma ta bardzo im przypadła do gustu. A jak kogoś temat nie interesował, to mu nie było żal tak krótkiego czasu. Mam nadzieję, że ta formuła na stałe zagości do polskiego światka IT.

Nie będę tu opisywał wszystkich prezentacji, wszystkie dały radę mniej lub bardziej. Jako że trzeba się chwalić, to napiszę o swojej prelekcji. Jako jedyny miałem temat totalnie nietechniczny, ani nawet nie miękki. Po prostu zachęcałem uczestników do morsowania, czyli kąpieli w lodowatej wodzie w otwartych zbiornikach wodnych. Poszło mi chyba całkiem nieźle, bo publika się śmiała parę razy jak i później uczestnicy do mnie podchodzili na unconference pogadać. Zarzucić sobie mogę trochę „tańczenie” na scenie, co jest wytykane jako błąd w podręcznikach do wystąpień publicznych. Chyba też za mało miałem kontakt z publicznością, bo często patrzyłem na ekran komputera jak i na małe ściągi - aby wiedzieć co będzie na następnym slajdzie. Będzie to widać na nagraniu za rok ;)

Później była przerwa obiadowa, a po niej kolej na rzeźnika, czyli Marcina Rzeźnickiego z tematem "Fun with Arrows". Niestety więcej nie pisałem w Scali niż pisałem, temat mnie wymęczył i nie dałem rady być do końca. Był to zaawansowany wykład, możliwy do strawienia przez osoby mające już wcześniej kontakt z tematem. Zamiast tego IT Arystorkacja mogła się pobawić:

Film zamieszczony przez użytkownika Ola K. (@akunysz)

Ostatni wykład pierwszego dnia (jak i całej konferencji) był Jarka Pałki pt. "Tęcza, kucyki i Equestria i co to wszystko ma wspólnego z programowaniem”. Czyli było o języku Pony.

Pony to język kompilujący się do natywnego kodu z niewielką pomocą Low Level Virtual Machine (LLVM). Jest tworzony w C/C++. Język dużo naobiecał, a najbardziej Jarek skupił się na Capabilities, czyli prawach dostępowych do obiektów. Jest zdefiniowanych 6 poziomów: iso (Isolated), val (Value), ref (Reference), box (Box), trn (Transition ), tag (Tag). Dzięki temu, na poziomie języka / kompilacji mamy kontrolę, czy dany kawałek kodu może odczytywać lub zmieniać wartość. Są pewne regóły kiedy referencja się przekształca z jednego typu na inny. Koncept bardzo mi się podoba, mimo że go jeszcze nie zrozumiałem, ale generalnie pozwala nam to na łatwiejsze pisanie aplikacji bezpiecznych wielowątkowo. Ponadto model aktorowy jest wbudowany w język. Aby coś więcej się dowiedzieć o języku warto przejrzeć prezentację My Little Pony - Codemesh 2015.

I to tyle jeśli chodzi o wykłady. Później była kolacja i unconference, czyli zapisaliśmy na karteczkach tematy o których chcielibyśmy porozmawiać i przylepiliśmy na drzwi. Po pogrupowaniu tematów zostały one przydzielone do stołów i już ludzie zaczeli dyskutować i przesiadać się między stolikami. Trochę osób podchodziło do mnie pogadać o morsowaniu i tak m.in. dowiedziałem się o panu Porfirii Ivanov. Gościu był rosyjskim mistykiem, który nawoływał do nawiązywania bliższego kontaktu z naturą poprzez zrzucenie ubrań w czasie gdy jest zimno. Uskuteczniał polewanie się zimną wodą w zimie na powietrzu jak i kąpiele w takiej wodzie. Próbował też leczyc ludzi, Kościół Prawosławny uznał go za heretyka, a na koniec skończył w szpitalu psychiatrycznym. Poczytałbym coś więcej, ale na Wikipedii sensowny artykuł jest po rosyjsku ale ja не понимаю.

Nocne rozmowy uczestników (zainicjowane unconference) trwały bardzo długo. W niedzielę zaczął się dzień warsztatowy. Do wyboru był LeanPoker, Hackergarten i RoboCode. Pierwszy z nich polegał na implementacji algorytmu grającego w pokera. Celem nie było pisanie testów, ani praca w parach, tylko dostarczenie jak najszybciej działającej wersji algorytmu i ulepszanie jej wraz z biegiem czasu. Warsztat ten potrwał najdłużej ze wszystkich.

Ja wziąłem udział w Hackergarten. Zabawa polega na zaangażowaniu się w jakiś projekt Open Source i stworzenia Pull Request’a. Ja pomagałem Patrykowi i Rafałowi porozwijać IceBoar’a. Pomagałem im z setupem projektu i dostałem dzięki temu feedback, jak go można ulepszyć. Udało się stworzyć PR, ale jeszcze go nie akceptowałem, bo wymaga kilku poprawek.

Później jeszcze chciałem zaangażować się w walki czołgów (RoboCode), ale zostało mało czasu, więc trochę pomogłem Piotrkowi patrząc przez ramię. Podczas finałowej rozgrywki jego czołg wygrał. Dla 3ch pierwszych miejsc znalazły się nawet nagrody, ale nie powiem przez kogo ufundowane, bo konferencja była bez sponsorów ;-)

Podsumowując, konferencja bardzo się udała. Miejsce konferencji okazało się bardzo fajne i uczestnicy bardziej sobie chwalili niż zamek w Mosznej (przynajmniej jeśli chodzi o noclegi). Miały być 3 warsztaty i tyle ich było. Co prawda zamiast Scalatrona był RoboCode, ale i tak było fajnie. No i Pecha Kucha wyszła wspaniale.

Z minusów, to ludzie trochę narzekali na kolację w ramach pre-party. Niektórzy później przybywający do pałacu nie mieli już co jeść :-( Następnym razem trzeba zrobić konferencję od razu z pre-party bo i tak większość ludzi przyjechała już w piątek. Co do Pechy Kuchy, to jednak zabrakło dyskusji od razu po każdym wystąpieniu. Po 11 szybkich prezentacjach ludzie już zapominali co było wcześniej i o co chcieli zapytać.

Mam nadzieję, że za rok znów się spotkamy, a konferencja będzie jeszcze lepsza.

poniedziałek, 25 stycznia 2016

IceBoar, czyli jak radzić sobie lepiej z technologią Web Start

W poprzednim wpisie opowiedziałem o kłopotach na jakie możemy natrafić korzystając z technologi Java Web Start. Przede wszystkim nie mamy pewności na jakiej wersji Wirtualnej Maszyny Javy użytkownik uruchomi naszą aplikację. Musimy również podpisywać nasze aplikacje i działają one w piaskownicy web starta (proces javaws lub jp2launcher). Ale oto przedstawiam rozwiązanie części z tych problemów:



IceBoar to mój pierwszy projekt Open Source, który wylądował w repozytorium maven central. Dodatkowo był on finansowany i pisany na zlecenie Roche, więc mamy połączenie przyjemnego z pożytecznym.

Co robi IceBoar? Najłatwiej wyjaśnia to poniższy diagram ze strony projektu.



Gdy użytkownik kliknie linka na stronie www, ściągany jest plik JNLP. Zamiast uruchamiać od razu docelową aplikację, uruchamia on Ice Boar’a. Ten najpierw ściąga spakowaną Wirtualną Maszynę Javy (musimy ją wcześniej sami przygotować i udostępnić do ściągnięcia). Następnie rozpakowuje ją (ale nie instaluje w systemie), ściąga docelową aplikację wraz z zależnościami i uruchamia ją. Aplikacja jest już uruchamiana po za procesem web start’a (javaws / jp2launcher), więc IceBoar może zakończyć swoje działanie.

Podoba się? Mam nadzieję, że tak!

Dodatkowo zaimplementowałem mechanizm cache’owania ściąganej JVM’ki i rozpakowanej JVM’ki. Dzięki temu kolejne uruchomienie nie będzie musiało ponownie pobierać tego pliku. Będzie to tak długo działać, dopóki ktoś nie wyczyści katalogu temp.

Pobierane JAR’y są chache’owne z automatu przez mechanizm czystego web start’a, więc nie trzeba było tego implementować. Co prawda w logu wypisuje się, że je pobiera, ale tak na prawdę są one brane z cache’a web starta. Wystarczy porównać czasy pierwszego i drugiego uruchomienia.

Jak zacząć przygodę z IceBoar’em? Sugeruję przyjrzeć się przykładowemu projektowi: ice-boar-demo. Nie korzysta on co prawda z Webstart Maven Plugin’a i setup jest trochę czasochłonny (patrz Readme), ale prezentuje dokładnie to co potrzeba. Może kiedyś zrobię przykładowy projekt ze wspomnianym Maven’owym plugin’em. Kwestia tylko gdzie i czy można udostępniać spakowane JRE?

Tak więc zachęcam do przeglądania kodu, testowania, zgłaszania błędów, Pull Request’ów i dzielenia się feedbackiem. Wszystko jest mile widziane.

sobota, 26 grudnia 2015

Technologia Java Web Start - co i jak?

TL;DR Jeśli nie korzystałeś nigdy z technologi Java Web Start (pliki JNLP) i jeśli nie musisz tego robić, to spokojnie możesz nie czytać dalej - nie obrażę się. Jest to zamierająca technologia i niedługo nie będzie wspierana w nowszych przeglądarkach (zobacz: The Final Countdown for NPAPI). Jeśli jednak korzystałeś / musisz skorzystać z tej technologi, to pewnie [mam nadzieję] dowiesz się czegoś ciekawego z tego i kolejnych artykułów.

Czym jest Java Web Start? Popatrzmy na dokumentację Javy SE.


Powinniście kojarzyć powyższy widok. Zazwyczaj korzystamy z Java SE API, natomiast Web Start jest zdefiniowany trochę wyżej po lewej, zaraz koło Applet'ów - a to nie wróży nic dobrego.


Java Web Start pozwala nam na uruchamianie javowych aplikacji standalone, bezpośrednio po kliknięciu na link’a na stronie www. Nie jest potrzebna żadna instalacja. Jest to wygodny sposób na dystrybuowanie wśród użytkowników najnowszej wersji naszego oprogramowania standalone - wejdźcie na stronę X, kliknijcie link Y i uruchomi się najnowsza wersja oprogramowania z którego [niestety] musicie korzystać. Jest to coś innego niż aplety, bo aplikacja uruchamia się po za przeglądarką.

Jak to działa? Po kliknięciu na link ściągany jest plik JNLP, który jest on w formacie XML’owym. Generalnie plik ten zawiera informację,  co ma uruchomić, skąd pobrać JAR’y, parametry uruchomieniowe itd. Aby całość zadziałała, musimy mieć jakąś Javę zainstalowaną na docelowej maszynie klienckiej.

Tyle teorii. Moim zdaniem, ta technologia świetnie sprawdza się z tutorialem do Swinga, gdzie za pomocą jednokliku możemy odpalić przykład ze strony i zobaczyć efekt. Wystarczy kliknąć na poniższą ikonkę:

https://docs.oracle.com/javase/tutorialJWS/samples/uiswing/CelsiusConverterProject/CelsiusConverter.jnlp



I to by było na tyle. Jeśli chodzi o jakieś bardziej skomplikowane aplikacje, to już może nie być tak różowo. Oracle nigdy jakoś szczególnie nie dbał o jakość tej technologii, czasem wprowadzał niekompatybilne zmiany, zaostrzał security itd.

Największą jednak bolączką programistów zmuszonych do korzystania z tej technologi jest niepewność, na której wersji wirtualnej maszyny Javy będzie odpalona aplikacja. Póki jest to proste demo (tutorial do Swinga), to żadnych problemów nie powinno być. Gdy jednak stworzyliśmy kolosa, który z jakiś powodów działa tylko na konkretnej wersji JVM’a, to zaczynają się schody.

Gdy zdefiniujemy w naszym pliku JNLP, że aplikacja ma się odpalić na Javie 1.7, a user będzie miał zainstalowaną Javę 1.8, to może zobaczyć poniższy komunikat:


Ten i inne screeny otrzymałem grzebiąc w plikach JNLP edytora UML’a: ArgoUML, udostępniającego link do uruchomienia za pomocą Web Start'a.

Czyli aplikacja w tym wypadku uruchomi się na Javie 1.8. W przypadku, gdy mamy w systemie zainstalowane kilka wersji Javy, to użytkownik będzie miał możliwość wyboru, na której się uruchomi.

Jeszcze innym problemem, może być posiadanie przez użytkownika starszej wersji Javy. Jeśli zdefiniujemy, że aplikacja ma się tylko odpalać na wersji 1.8.0_50, a będziemy mieć zainstalowaną starszą (1.8.0_28), to dalej nie mamy pewności, na której się uruchomi - patrz komunikat poniżej.


Jak dobrze pamiętam, to jeszcze jest możliwość, że Web Start będzie próbował ściągnąć nowszą wersję JRE i zainstalować. Jest to spory problem w dużych firmach, gdzie korpo ludki mogą nie mieć (albo raczej nie powinni mieć) uprawnień do instalowania nowych rzeczy na swojej maszynie.

Inną niedogodnością jest jeszcze konieczność podpisywania swoich aplikacji. Od którejś wersji Javy, własne certyfikaty (self signed) są z domysłu blokowane. Trzeba więc albo zdobyć porządny certyfikat od zaufanego wystawcy (czytaj zapłacić), albo skonfigurować userom maszyny tak, aby mogli otwierać aplikacje z zaufanych źródeł.

Jak widać jest sporo tej babraniny, aby całość doprowadzić do ładu i składu. Spójrzmy zatem na kolejne fragmenty przykładowego pliku JNLP. Pozwoliłem sobie bazować na pliku z ArgoUML, ale dorzuciłem też parę ciekawych rzeczy, których tam nie ma zdefiniowanych.
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for launching ArgoUML with WebStart -->
<jnlp
  spec="1.0+"
  codebase="http://argouml-downloads.tigris.org/maven2"
  href="http://argouml-downloads.tigris.org/jws/argouml-latest-stable.jnlp">

Całość będzie zawierać się w tagu jnlp. Możemy w nim zdefiniować atrybut codebase, który będzie naszym bazowym URL’em przy pobieraniu JAR’ów.

Bardzo ciekawy jest atrybut href. Jeśli jest on zdefiniowany, to po uruchomieniu pobranego pliku JNLP (czy to w przeglądarce, czy bezpośrednio z dysku), to Web Start pobierze ten plik jeszcze raz ze zdefiniowanego tutaj adresu i jego będzie interpretował! Jeśli wprowadzimy jakieś zmiany lokalnie w pliku JNLP, ale będzie istniał atrybut href, to nic nam to nie da! Dla celów produkcyjnych warto ustawić ten parametr, na pewno utrudni on życie początkujących hackerom.
<information>
    <title>ArgoUML Latest Stable Release 0.34</title>
    <vendor>Tigris.org (Open Source)</vendor>
    <homepage href="http://argouml.tigris.org/"/>
    <description>ArgoUML application.
                 This is the latest stable release.
    </description>
    <description kind="short">ArgoUML 0.34</description>
    <icon href="http://argouml.tigris.org/images/argologo16x16.gif" width="16" height="16" />
    <icon href="http://argouml.tigris.org/images/argologo32x32.gif" width="32" height="32" />
    <icon href="http://argouml.tigris.org/images/argologo64x64.gif" width="64" height="64" />
    <offline-allowed/>
  </information>

Dalej mamy definicje, które są gdzieś tam wyświetlane podczas uruchamiania aplikacji, czyli tytuł, wydawca, strona domowa, opis, ikonka itp. Ostanie ustawienie (offline-allowed) definiuje nam, że docelowa aplikacja może działać, gdy nie mamy połączenia z netem. Jest jeszcze możliwość tworzenia skrótu na pulpicie, menu start i inne pierdoły.
  <security>
    <all-permissions/>
  </security>
Tutaj definiujemy, co nasza aplikacja może, a co nie. Jeśli jest to okienko swingowe z tutoriala, to nic nie potrzebujemy. Gdy chcemy zapisywać pliki na dysku itp, to potrzebujemy dostęp, najlepiej do wszystkiego. Dokładnie takie same seciurity (ale w trochę innej formie zapisu), musi być zdefiniowane w Manifeście w JAR’ze zawierającym klasę, którą będziemy uruchamiać (z metodą main()).
  <resources>
    <j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se” 
             initial-heap-size=„64m" 
             max-heap-size=„512m" 
             java-vm-args="-ea -Xincgc"/>

Następnie mamy definicję na jakiej wersji Javy ma być odpalona docelowa aplikacja. W specyfikacji 6.0 JNLP zamiast „j2se" może pojawić się „java".

Wersja może być zdefiniowana na wiele sposobów. Możemy podać dokładnie (np.: 1.7, 1.4.2, 1.4.2_04, 1.5.0-beta2), albo większe równie niż (np.: 1.5+, 1.4.2+). Można również podać kilka wersji kolejno wg. preferencji.

Gdy chcemy jakiejś egzotycznej wersji, musimy podać atrybut href.

Na koniec możemy jeszcze zdefiniować ustawienia pamięci i przekazać jakieś flagi do JVM’a.
    <jar href="http://argouml-downloads.tigris.org/maven2/antlr/antlr/2.7.7-3/antlr-2.7.7-3.jar"/>
    <jar href="http://argouml-downloads.tigris.org/maven2/org/argouml/argouml-euml/0.34/argouml-euml-0.34.jar"/>

Dalej definiujemy nasze zależności, które Web Start ma ściągnąć. Zależności są cache’owane, więc jak podbijamy wersję biblioteki, to warto zmienić nazwę pliku. Gdy nie podamy pełnej ścieżki do pliku, to będzie ona budowana na podstawie codebase (w tag’u jnlp).
    <property name=„argouml.modules" value=";org.argouml….."    />
</resources>

W ten sposób definiujemy sobie właściwości wspólne dla wszystkich platform. Muszą one jednak się zaczynać od "javaws." lub "jnlp.”. Ta powyższa definicja z ArgoUML wg. mnie nie zadziała. Jeszcze niektóre predefiniowane propertisy (np.: http.agenthttp.keepAlive) można zdefiniować w ten sposób.

To były właściwości wspólne dla wszystkich systemów operacyjnych. Mamy jeszcze możliwość zdefiniowania właściwości specyficznych dla konkretnej platformy, np.:
  <resources os="Windows" arch="amd64">
     <property name="jnlp.abc" value=„xyz"/>
  </resources>

  <resources os="Mac OS X" arch="x86_64">
     <property name="jnlp.abc" value=„123"/>
  </resources>

Jeszcze na koniec pozostaje nam punkt wejścia do aplikacji:
<application-desc main-class=„com.mycompany.myapp.MainApp">
   <argument>arg1</argument>
   <argument>arg2</argument>
</application-desc>

Tutaj możemy dodatkowo przekazać argumenty do aplikacji. Pełen opis tego co możemy zrobić w pliku JNLP można znaleść tutaj: JNLP File Syntax.

I to już wszystko jeśli chodzi o sam plik JNLP. Przygotowujemy taki plik, wrzucamy na serwer, umieszczamy do niego link, podpisujemy nasze JAR’y, robimy je możliwe do ściągnięcia i już możemy cieszyć się Web Startem. Brzmi prosto, ale na pewno takie nie jest. W kolejnym artykule opiszę, jak można sobie trochę ułatwić życie.

poniedziałek, 21 grudnia 2015

33rd Degree 4 Charity we Wrocławiu

Keep things in memory with Cache, Mateusz Herbut

Mateusz na początku przedstawił ciekawą historię, odnośnie tego, dlaczego się zainteresował cache’m i kiedy został zdefiniowany standard JSR-107 - JCache. Fajnie się całość zbiegła z datami z filmu "Powrót do przyszłości", co prelegent dobrze wykorzystał na slajdach.

Mateusz bardzo fajnie przedstawił na diagramach sekwencji różne techniki działa cache'a:
  • Cache Aside
  • Read Through
  • Write Through
  • Write Back
  • Write Behind
  • Refresh Adead

Pierwsze trzy techniki z pośród wymienionych są zdefiniowane przez standard JSR-107, a pozostałe są wspierane dodatkowo przez niektóre implementacje.

Cache Aside jest najprostszy. Klient (aplikacja) sprawdza najpierw, czy wartość jest dostępna w cache’u. Gdy nie, to aplikacja sama odczytuje wartość ze źródła prawdy (dysku, bazy danych, etc.) i jeśli chce, to ją wrzuca do cache’a.

W metodzie Read Through to cache, a nie aplikacja kliencka, jest odpowiedzialna za odczyt wartości ze źródła prawdy i jej zapamiętaniu u siebie na później.

W podejściu Write Through to cache zapisuje wartość do źródła prawdy (synchronicznie) i zapamiętuje u siebie.

Write back zapisuje dane do źródła prawdy, dopiero wtedy gdy dana wartość jest usuwana z cache’a. Podejście to jest często stosowane w procesorach (L1, L2 cache) i wartości te mogą być niespójne ze źródłem prawdy (pamięć RAM). O unieważnieniu cache’a decyduje cache provider.

Przy Write behind klient zapisuje do cache’a i cache asynchronicznie rozpoczyna zapisywanie do źródła prawdy. Gdy w międzyczasie, ktoś będzie chciał odczytać wartości, to dostanie je bezpośrednio z cache’a.

W ostatniej metodzie Refresh Ahead cache decyduje podczas odczytu, czy wartość trzeba odświeżyć, czy nie.

Dalej było jeszcze o 3ch rodzajach operacji jakie mogą być wywoływane na cache’u:
  • Pessimistic locking
  • Lock free
  • Optimistic locking
ale tu już nie będę przedstawiał, które są które.

Bardzo fajna, mięsista prezentacja. Uwagi odnośnie sposobu prezentowania  przekazałem wieczorem bezpośrednio Mateuszowi.

-XX:+UseG1GC, Jakub Kubrynski

Następnie Jakub Kurbyński ładnie omówił Garbage collector G1, który na być domyślny w Javie 9. Prelegent fajnie przeszedł przez to w jaki sposób jest zorganizowana pamięć w Javie i jakie to ma konsekwencje dla algorytmów odśmiecania. Stopniowo powoli odkrywaliśmy nowe pomysły w sposobach organizacji pamięci i algorytmów odśmiecających.

W G1 mamy wiele faz, ale dokładniej były omawiane 4:
  • Young GC
  • Concurrent cycle
  • Mixed GC
  • Full GC
Young GC to odśmiecanie młodej generacji, odpalane po zapełnieniu wszystkich regionów typu Eden. Jest ono wykonywane równolegle i zatrzymuje naszą aplikację. Concurrent Cycle bazuje na wynikach poprzedniej fazy i stara się znaleźć regiony łatwe do odśmiecenia i je oznacza. Mixed GC uwalnia te obszary z poprzedniej fazy. Czyści on pamięć zarówno z młodej generacji, jaki i starej. Najgorzej, gdy dojdziemy do Full GC (jak go zobaczymy w logach), gdyż on odśmieca całą pamięć i zajmuje sporo czasu, bo wykonuje się jednowątkowo. Powinniśmy tego unikać.

Fajne było podsumowanie, jak tuningować G1. Najlepiej ustawić:
-XX:MaxGCPauseMillis=250
lub na inną empiryczną wartość. Wtedy G1 będzie starał się nie przekroczyć zadanego czasu na odśmiecanie. Oczywiście gdy wartość będzie zbyt mała to się to nie uda. Złą stroną tuningu jest natomiast ten slajd:

czyli flagi których należy się wystrzegać ;)

Jeszcze inne dobre praktyki to:

A do przeglądania logów warto skorzystać z GCViewer, JVisualVM i Mission Control.

Nagranie z Confitury, polecam sobie obejrzeć:


Później była przerwa obiadowa, po której na prezentację Tomka Dziurko "Brzydka Pani od HR radzi…” po raz N-ty nie chciało mi się iść (widziałem na YT), a konkurencyjny temat mnie nie zachęcił. Filmik z prezentacji Tomka poniżej:



Liquibase - zarządzanie zmianami w relacyjnych bazach danych, Marcin Stachniuk

W kolejnym slocie przyszedł czas na moją prezentację. Grono zainteresowanych było niewielkie, bo w drugiej sali w tym czasie mówili o mikroserwisach po raz 144. Slajdy (trochę zaktualizowane od ostatniego razu) poniżej.



Ze zmian (po za kolorkami dopasowanymi do konferencji) to istnieje łatwiejszy sposób na wprowadzenie Liquibase'a do istniejącego projektu, niż ten który przedstawiałem na WrocJUG'u. Można skorzystać z komendy changeLogSync, która to tworzy i wypełnia danymi z changelog'a tabele potrzebne do działania biblioteki (DATABASECHANGELOG i DATABASECHANGELOGLOCK), a same zmiany nie są wykonywane. Po więcej szczegółów zapraszam na stonę Liquibase'a: Adding Liquibase on an Existing project.

Drugą wartością dodaną do prezentacji jest moje subiektywne porównanie Flyway'a i Liquibase'a, ale kot nie był niech żałuje.

Java 9, Arkadiusz Sokołowski

Prelegent pokazał parę nowości które nas czeka w kolejnej wersji Javy. Było oczywiście o REPLu i modułach, czyli projekcie Jigsaw i jak to na nas wpłynie. Prezentacja była ok, ale gdzieś już coś o nowościach słyszałem...

Java developer meets AngularJS/JavaScript: real-world projects’ experiences, Marek Matczak

Prelegent pokazywał z początku popularność różnych języków programowania, gdzie górował JavaScript i Java. Marek proponował te dwa języki do obecnych projektów, a dokładniej Spring-Boot’a i AngularJS’a.

Prelegent przedstawił, jakie są możliwości połączenia tych dwóch światów, od strony budowania aplikacji. Jedno podejście, to łączenie części frontend'owej z buildem Maven’owym. Można do tego wykorzystać maven-assembly-plugin, który buduje zzipowaną aplikację kliencką, a później za pomocą exec-maven-plugin można uruchomić node.js’a. A całość do WAR’a można wrzucić za pomocą: maven-war-plugin’a.

Drugie podejście proponowane przez Marka to wykorzystanie exec-maven-plugin’a do budowania frontendu w trakcie fazy generate-sources. Zasoby te wrzucamy do src/main/resources/static, czyli tam gdzie standardowo Spring Boot się ich spodziewa.

Całość jest dostępna na GitHubie jako Open Application Standard Platform (OASP).

Z ciekawostek, które mi utkwiły, to warto się przyjrzeć Google JavaScript Style Guide i Idiomatic JavaScript, aby wiedzieć jak dobrze pisać kod w JavaScript’cie.

Warto też na przyszłość przyjrzeć się Isomorphic JavaScript. Dzięki temu, będziemy mogli wyrenderować stronę HTML po tronie backend'u, co pozwoli nam np. na szybsze ładowanie się strony głównej naszej aplikacji.

Muszę się również przyjrzeć Gulp’owi, gdyż on ma wbudowane reverse proxy.

Dzień 2
On-heap cache vs. Off-heap cache, Radek Grębski

Drugi dzień zaczął się bardzo mięsistą prezentacją na temat pamięci off-heap, czyli pamięci po za standardowym heap’em Javowym. Jest to pamięć, która nie jest zarządzana przez Garbage Collector, można w niej zapisywać tylko tablice bajtów (korzystająć ze standardowego API) i sami musimy zajmować się jej zwalnianiem.

Generalnie bardzo polecam tą prezentację, jest dostępne nagranie z Confitury 2015 jak i kod na GitHubie: https://github.com/rgrebski/confitura2015


Trochę podsumowując prezentację:
Aby zaalokować pamięć w Javie, można skorzystać z następujących klas: HeapByteBuffer (na stercie [heap], do 2 GB), DirectByteBuffer (po za stertą, do 2 GB), MappedByteBuffer (po za stertą, do 2 GB, pamięć perzystowana), Unsafe.allocateMemory() (więcej niż 2 GB).

Pierwsze 3 klasy mogą allokować do 2 GB ponieważ jako argument przyjmują int’a, który ich ogranicza. Bardzo ciekawą klasą jest MappedByteBuffer, która tworzy buffer w pamięci, który może być zapisywany do pliku na dysku. Ma on tą przewagę nad wszystkim innym, że w przypadku całkowitego crash’u maszyny wirtualnej zapis i tak się powiedzie. Operacja ta jest zapewniana przez system operacyjny.

Chcąc allokować pamięć większą niż 2 GB to już trzeba korzystać z Unsafe’a. Korzystanie z tej klasy nie jest łatwe i wygląda jakby sam Chuck Noris ją pisał. Właściwie ta klasa z definicji miała być dostępna tylko dla „zaufanego kodu”, czyli do wewnętrznego użytku przez Javę. Ale coś poszło nie tak i obecnie masa frameworków i bibliotek z niej korzysta. Co gorsza to klasa ma być niedostępna w Javie 9, więc będzie ciekawie. Sporo kodu trzeba będzie przepisać, albo znaleść haka, aby się dostać do odpowiedniego modułu.

Dalej było o Chronicle Map. Jest to mapa, która jest zapisywana po za stertą. Jest też perzystowalna, dzielona pomiędzy osobnymi procesami JVM (również po sieci). Jedynym minusem jest fixed size, tzn. musimy wiedzieć jak duże będą nasze obiekty. I tak dla String’ów i kolekcji musimy za pomocą @MaxSize zdefiniować jak maksymalnie długie będą nasze teksty i jak wielkie kolekcje w obiektach. Gdy przekroczymy granicę to dostaniemy błąd. Obiekty zapisujemy do bloków o stałej wielkości - trochę pamięci się marnuje, ale dostęp do niej jest łatwiejszy.

Dalej było sporo porównań szybkości działania Mapy i Chronicle Mapy. Następnie prelegent opowiedział jeszcze z grubsza o Hazelcas’cie i Redisie, które również porównał z Chronicle Map.

Purely functional data structures, Tomasz Kaczmarzyk

Na początku zaczęło się o tym jak w językach funkcyjnych są zaimplementowane Listy, że składają się z głowy i ogona, że ogon wykorzystuje dokładnie tą samą strukturę co pierwotna lista itd. Kto się uczył Skali, lub innego języka funkcyjnego, to na pewno kojarzy koncept.

Póżniej było już ciekawiej, o tym jak jest zbudowana kolejka w językach funkcyjnych, w której można dodawać elementy na końcu. W standardowej liście jest to bardzo kosztowna operacja. Kolejka wprowadza pewne ciekawe pomysły, jak może ona być wewnętrznie zorganizowana, aby efektywnie przeprowadzać operacje na niej, mi.in. dodawania elementu na końcu. Ten fragment prezentacji był bardzo fajny.

Następnie było o tym jak wewnętrznie jest zorganizowany Git i jaka to jest ładna struktura danych. Temat był mi już wcześniej znany, więc mnie aż tak nie zachwycił jak poprzednia część.

Prelegent miał bardzo fajne slajdy (pisane kredą po tablicy), z ładnymi animacjami przejścia.

Sane Sharding with Akka Cluster, Michał Płachta

Tutaj było mnóstwo programowania na żywo, które działało! Prelegent się dobrze do tego przygotował.

Na początek napisał pojedynczego aktora obsługującego jakieś zapytania i zrobił test wydajności. Następnie, razem z publicznością, udoskonalał rozwiazanie… Implementowaliśmy system rozdzielający paczki na taśmociągu w jakimś magazynie.

Jako drugi krok, prelegent dorzucił drugiego aktora, który tylko podejmował decyzję o przeznaczeniu paczki. Następnie pojawili się kolejni aktorzy i to już bardzo przyspieszyło obsługę zapytań. Na koniec był jeszcze przedstawiony Akka cluster, aby można było to łatwo skalować na więcej maszyn.

Kod z prezentacji jest dostępny tutaj: https://github.com/miciek/akka-sharding-example. Warto przejść sobie po commit'ach i zobaczyć jak się aplikacja rozwijała.

Recepta na retrospekcję z finezją, Wòjcech Makùrôt

Retrospekcje są wpisane w Agile Manifesto jako dwunasty punkt:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
czyli:
W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.
Prelegent podał i opowiedział na przykładach swoje 10 punktów, które trzeba spełnić, aby mieć dobrą retrospektywę. Postaram się streścić, jak ja to zrozumiałem.
  • Trzeba się dobrze przygotować. Spisać sobie plan spotkania, załatwić wszystkie niezbędne pomoce materialne, poszukać inspiracji, aby nie było nudno.
  • Wprowadzamy jakiegoś IceBreak’era, aby rozmawiało się na luzie. Można odwrócić krzesła w sali, aby ludzie musieli zrobić coś innego. Prowadzący spotkanie (facylitator) może być niemerytoryczny - do niego należy moderacja i czasem pacyfikacja spotkania. Najważniejsze jest zdanie innych.
  • Sprawdzamy, czy z poprzedniej retrospekcji udało nam się zrealizować jakieś postanowienia. Jeśli nic się nie udało, to powinniśmy przerwać i zastanowić się dlaczego się nie udało.
  • Możemy opowiedzieć historyjkę, odnośnie tego co działo się w ostatnim sprincie. Budujemy przez to naszą wspólną świadomość.
  • Grupowanie i priorytetyzowanie problemów - powinniśmy zajmować się tylko tymi najważniejszymi problemami.
  • Dziel i rządź, czyli z którymi problemami jesteśmy zdolni sobie poradzić, i które będą miały największy wpływ na poprawę naszej sytuacji.
  • Analiza przyczyn, dlaczego coś nie działa. Tutaj możemy skorzystać z metody 5x dlaczego, ość Ishikawy
  • Planowanie naprawy, czyli: co trzeba zrobić, jak, kto będzie za to odpowiedzialny i na kiedy. Nie warto brać więcej niż 4 tematy do naprawy, bo to może być niemożliwe do zrealizowania.
  • Celebracja tego do czego udało się dojść, czyli warto podziękować za współpracę, nagrodzić jakoś uczestników, wyjść na piwo...
  • Śledzenie postępów w kolejnej iteracji, czyli sprawdzanie wykonania zadań.
Jako źródło inspiracji, warto spojrzeć na retrospectivewiki.org i blog.accentient.com/upgrade-your-sprint-retrospective-meetings oraz do książki Agile Retrospectives.

Slajdy z wystąpienia:


Refactoring meets big money, Michal Gruca

Prelegent przedstawił 3 możliwe podejścia do refactoringu:
  • Codzienny refactoring
  • Pisanie całości od nowa
  • Przepisywanie modułów i podmienianie
Tylko jak to wszystko wytłumaczyć i sprzedać biznesowi? Warto zdecydować się na mierzenie jakiś metryk kodu. Można wziąć jakieś Sonarowe metryki dobrych projektów open source, porównać z metrykami naszych projektów, przełożyć na kasę i strać się wytłumaczyć, że to jest ważne. Warto zrobić sobie sceeena tych metryk z naszego projektu, aby później, po serii refaktoringów, zobaczyć czy i ile się poprawiło.

Warto też, przed pójściem do biznesu, trochę się przygotować. Można stworzyć jakieś prototypowe rozwiazanie i pokazać, że ono przynosi nam jakąś wartość. Przykładowo przyspieszymy build’a albo release’a.

Prelegent polecał do przeczytania fane case study, jak to Soundcloud przechodził na mikroserwisy.

Common fallacies of micro services, Marcin Matuszak

Prelegent w ciekawy sposób podszedł do tego, w jaki sposób obecnie są wynoszone pod niebiosa mikroserwisy, kontrargumentując potencjalne zalety jakie nam daje to podejście. I tak możliwość pisania każdego mikroserwisu w innym języku jest kiepski, bo jak ktoś napisze coś w bardzo egzotycznym języku (którego mało kto zna) i później się zwolni z pracy, to trzeba będzie nauczyć się tego języka, aby utrzymywać kod.

Monolityczne aplikacje wcale nie są takie złe. Są łatwe do pisania testów, w deploymencie i utrzymaniu. Jak rozmawiamy o mikroserwisach, to się skupiamy na tym, że mają być serwisy i że mają być małe. A zapominamy że mają sie komunikować po sieci, co przysparza masę dodatkowych problemów. Jeśli zepsuliśmy aplikację monolitową, to również i zepsujemy mikroserwisy.

Podsumowując całość, była to bardzo fajna konferencja, w końcu coś ciekawego i większego zawitało do Wrocławia. Nie miałem wysokich oczekiwań co do prelekcji, a okazały się one na dobrym poziomie. Byłem więc pozytywnie zaskoczony tą konferencją. Jednocześnie sam miałem okazję wystąpić i wyświetlać swoje slajdy po raz pierwszy na kinowym ekranie.

sobota, 3 października 2015

Po 67 spotkaniu Wrocławskiego JUG'a


Ostatnio miałem przyjemność poprowadzić 67 spotkanie Wrocławskiego JUG'a na temat: Liquibase - zarządzanie zmianami w relacyjnych bazach danych.

Co prawda podobny temat przedstawiałem niemal rok temu na dbconf.pl, ale chciałem w ramach JUG'a zrobić bardziej praktycznie i z przykładami. Tworzyłem więc (przez rok z wieloma przerwami) przykładową aplikację, aby zaprezentować to, co chciałem. Zabrało mi to tyle czasu, bo walczyłem ze Spring Boot'em, Java Movie Database, Postregssem, MySQLem, mapowaniem Hibernate'a, a do tego wszystkiego chciałem pokazać choć proste GUI, a więc jeszcze AngularJS i HTML. Ostatecznie na prezentacji i tak puszczałem nagranie, jak można dodać Liqibase'a do istniejącego projektu, bo znając życie to podczas wystąpienia i tak by coś nie zadziałało, albo nie wiedziałbym jak zwiększyć czcionkę w Idei ;) Dodatkowo miałem mikrofon, który musiałem trzymać w ręce, więc było by ciężko.

Wnioski jakie z tego płyną, to:
- przygotowanie super przykładów, zajmuje wiele czasu - zbyt wiele
- przykłady nie muszą być super dopieszczone i powinny koncentrować się na głównym problemie, a nie dodatkowych aspektach wizualnych
- lepiej skupić się na samej prezentacji - na careercon.pl miałem 5 dni na przygotowanie prezentacji o Javie 8 i się udało (może nie na takim poziomie jakbym sobie tego życzył, ale feedback nie był najgorszy)

Dziękuję sponsorowi spotkania, firmie:

IT Kontrakt

za zapewnienie żłocistego napoju chłodzącego dla uczestników.

Poniżej slajdy ze spotkania...

... i kod z przykładów: https://github.com/mstachniuk/movies-database

Wykład był też nagrywany, ale jego jakość może być wątpliwa, więc jeszcze nie wiem czy udostępnię.

Dziękuję wszystkim uczestnikom za udział i za pozytywny feedback. Widziałem, że pod koniec trochę już niedawaliście rady, ale jakoś dotrwaliście szcześliwie do końca. Wszelki dodatkowy feedback (zwłaszcza ten konstruktywno-krytyczny - co można na przyszłość ulepszyć), mile widziany!

A w najbliższym czasie ponownie się szykuję na dbconf.pl i pewnie będzie pra premiera na WrocJUGu. Jakoś polubiłem tą konferencję, bo może nie jestem do końca typowym bazodanowcem, ale jako że konferencja odbywa się tym razem w Jurze Krakowsko-Częstochowskiej, to jest okazja zwiedzenia okolicy i pooddychania czyst[sz]ym powietrzem. Chcę również pokazać bazodanowcom, że po za bazami SQL (od firmy na O. lub I.) są też jeszcze ciekawe rozwiązania.

Na koniec mały bonus zachęcający do robienia prezentacji




środa, 15 lipca 2015

Confitura 2015

"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.

środa, 1 lipca 2015

Devoxx w Polsce - dzień 3 ostatni

Trzeci dzień Devoxxa zacząłem do prezentacji Christophera Batey’a: "Building fault tolerant microservices". Dopiero po jakimś czasie się zorientowałem, że już gdzieś to widziałem… I fakt byłem na tej prezentacji na Voxxed Days Vienna 15. A specjalnie przed pójściem sprawdzałem na blogu, czy to nazwisko nie jest mi znane, ale coś mi poszło nie tak :(

Nie będę opisywał wszystkich praktyk i narzędzi z których korzysta prelegent, tylko zmieszczę jego przykładowe projekty:
Z ciekawostek, to w Spring Boot’cie można za pomocą hystrix-javanica skorzystać z adnotacji @HystrixCommand i możemy metody opakowywać w komendy Hystixowe, bez całej ceremonii.

Na koniec było jeszcze jak sprzedawać takie zabawki biznesowi. Trzeba zrobić if’a w kodzie, który będzie odciążał nasz system w ciężkich chwilach i podpiąć guzik do tego. Jak będzie duże obciążenie i ktoś będzie do nas dzwonił, to musimy kazać mu wcisnąć przygotowany guzik i odciążyć serwery. Jak się będzie to powtarzać to w którymś momencie biznes się zapyta, czy nie da się tego zautomatyzować i wtedy wprowadzamy potrzebne zabawki.

Kolejną prezentacją, na którą się udałem była Pawła Szulca na temat: "Event Sourcing & Functional Programming - a pair made in heaven". Był mały problem z kodem, który na części slajdów był niepokolorowany i zapisanym małą czcionką. Prelegent polecał przeczytanie publikacji Why Functional Programming Matters.

Następnie Paweł tłumaczył jak działają monady, na co zeszło dużo czasu. Później było na temat Event Sourcing’u, czyli to o czym zawsze Greg Young opowiada. Na koniec pozostało 20 minut czasu na demo. Było ciekawe, bo „opowiadało” fabułę filmu. Prezentacja była dobra, trzymająca poziom. Więcej kodu następnym razem proszę.

Następnie byłem na 15sto minutówce, gdzie Roy van Rijn opowiadał o REPL’u w Javie 9: "Watch out, the REPL is coming". Była to prezentacja zgłoszona dzień wcześniej i na kolacji ze speakerami była jeszcze łatana przez speców z Oracle’a. Dali radę, bo na demo wszystko zadziałało. Jest to jeszcze wczesny development, więc jest jeszcze sporo błędów, które mogliśmy zobaczyć pod koniec wystąpienia. Jak na prezentację przygotowaną na spontanie to poszła bardzo fajnie.

Następnie byłem na prezentacji Grega Young’a: "8 Lines of Code". Greg pokazał parę wywołań, które w skrajnych przypadkach mogą powodować jakieś problemy, np: FileStream.Flush(), FileStream.Seek(). Nie powinniśmy ponadto tworzyć nieograniczonych kolejek i w momencie zaczynania projektu powinniśmy się zastanowić, jak będziemy chcieli debugować problemy na produkcji. Warto sobie w logach wypisywać wszystkie zmienne środowiskowe, aby można było odtworzyć środowisko, gdzie występuje błąd. Najciekawszych problemów wielowątkowych i tak nie jesteśmy w stanie debugować :(

Kolejną prezentacją na którą się udałem była Teda Newarda: "Busy Java Developer’s Guide to Three REST API Frameworks". Na początek Ted powiedział: „Chrząszcz brzmi w trzcinie” :)

Ted przedstawił 4 różne frameworki. Na pierwszy ogień poszedł SparkJava (nie mylić z Apache Spark). Jest on inspirowany Sinatrą ze świata Rubyiego. Wygląda on na bardzo małe i proste rozwiązanie, gdzie wiele składni Javy 8 jest wykorzystywane. Hello World:
import static spark.Spark.*;

public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");
    }
}

Rozwiązanie to pozwala zarządzać sesją tak jak kontenery servletów. Rozwiązanie na pewno przydatne do małych rozwiązań i testów.

Następnie na tapetę poszedł Vert.x. Bazuje on na JVM, ale można z niego korzystać w Javie, JavaScripcie, Groovym i Rubym. Nie wiem jak to jest technicznie rozwiązane, ale brzmi bardzo ciekawie. Model współbieżności jest oparty na Aktorach i ma rozproszoną szynę zdarzeń. Dalej było parę przykładów jak wygląda kod dla różnych języków. Dla Javy poniżej:
public class Server extends AbstractVerticle {
  public void start() {
    vertx.createHttpServer().requestHandler(req -> {
      req.response()
        .putHeader("content-type", "text/plain")
        .end("Hello from Vert.x!");
    }).listen(8080);
  }
}

Tworzenie współbieżnego kodu z Vert.x jest łatwe ze względu na pewne założenia. Kod który tworzymy jest jednowątkowy i każdy moduł (jakkolwiek go definiujemy) ma osobną pętlę z event’ami, która się nie blokuje.

Kolejny był DropWizard. Jest to już trochę większy kombajn, który ma zintegrowane wiele bibliotek Javowych w sobie, aby można go było szybko wdrożyć na produkcję. Trochę jak Spring Boot. DropWizard ma wbudowanego Jetty’iego, korzysta z Jersey'a do RESTa, Jackson’aMetrics do zbierania statyskych z różnych części aplikacji, Guava, Logback, Hibernate ValidatorJDBI dla połączenia z bazą danych, Liquibase dla wersjonowania bazy, FreemarkerMustache dla frontendu, Joda Time i pewnie jeszcze wiele innych. I całość opędzona mavenem. Przykładowy kod poniżej:
public class HelloWorldApplication extends Application {
    public static void main(String[] args) throws Exception {
        new HelloWorldApplication().run(args);
    }

    @Override
    public String getName() {
        return "hello-world";
    }

}

Jako wynik dostajemy dużego JARa, którego odpalamy i działa. Możemy jako argument przekazać plik konfiguracyjny do aplikacji. Wygląda na całkiem ciekawy stos.

Ostatnim zaprezentowanym narzędziem był RestX, czyli lekki, modułowy, szybki… To co dostajemy to samoaktualizujący się shell, wstrzykiwanie zależności, wsparcie dla MongoDB, interaktywna dokumentacja RESTa, automatyczne testy, konsola admina. Konkretne endpoint’y RESTowe można generować w stylu testów BDD (Resource Spec) albo małych klass:
@Component @RestxResource
public class HelloResource {
    @GET("/message")
    public Message sayHello(String who) {
        return new Message().setMessage(String.format(
                "hello %s, it's %s",
                who, DateTime.now().toString("HH:mm:ss")));
    }
}

Po wystartowaniu otrzymujemy od razu dokumentację naszego API, konsolę admina i coś do monitorowania. Generalnie projekt zawiera w sobie DropWizard’a, wszystkie komponenty są bezstanowymi singletonami, architektura jest mocno zmodularyzowana i dev mode wspiera hot-recompile kodu źródłowego.

Na koniec było podsumowanie, że żaden framework nie jest najlepszy, tylko że każdy jest inny - i w sumie racja.

Na koniec całej konferencji zostało motywujące wystąpienie Jurgen Appelo o "The Creative Networker". Jurgen tłumaczył pewien wykres:


Wynika z niego bardzo wiele, a mianowicie, najwięcej uczymy się podczas eksperymentowania. W przypadku popełniania, błędów uczymy się nie wiele, ale nie powinniśmy się tym przejmować. W przypadku praktyk (czyli produkcji masowej), już nie wiele jest nauki, ale za to duży sukces. Zawsze świętujemy sukcesy (a w Polsce pijemy również przy porażkach), ale często nie świętujemy naszych eksperymentów - a powinniśmy.

Prelegent przedstawił siedem zasad dla kreatywnych:
  1. Szukanie wielu pomysłów - najpierw powinniśmy zbierać jak najwięcej pomysłów 
  2. Generowanie wielu pomysłów - później je jeszcze generować w myśl zasady: "The best way to have a good idea is to have a lot of ideas" - Linus Pauling
  3. Tworzenie połączeń - musimy naszym pomysłem podzielić się z innymi i wzajemnie się inspirować 
  4. Poszukiwanie kierunku - mindfulness i unfocus są najlepsze dla kreatywności 
  5. Wykonanie pomysłu - trzeba wizję zrealizować 
  6. Zrozumieć błędy - i wynieść naukę na przyszłość 
  7. Uczyć się na porażkach - w końcu wiele wynalazków powstało przez przypadek 



Omawiane techniki i praktyki nie są jakimś dużym wymysłem prelegenta, a raczej wnioskami z wielu książek i notatek.



Na koniec była jeszcze reklama książki Jurgena: Management 3.0. Był to bardzo motywujący wykład na koniec konferencji, bardzo motywujący do testowania swoich pomysłów i inspirujący do próbowania ze startup’ami.

Było jeszcze krótkie zakończenie konferencji, gdzie można było zobaczyć wszystkich organizatorów i wolontariuszy. Podsumowując 3 dni, to organizacyjnie konferencja była bardzo dobrze ogarnięta. Super miejsce na tak dużą konferencję, dobre nagłośnienie, rzutniki i jedzenie. Trochę brakowało ciastek w przerwach, aby dostarczyć cukru do kory przedczołowej, ale napojów było pod dostatkiem. Trochę mi zabrakło prezentacji najwyższych lotów, które by wywracały aktualne postrzeganie świata o 180 stopni. Mogło by być również więcej tych dobrych, albo ja trafiałem na wiele przeciętnych. Na pewno będę musiał jeszcze sporo prezentacji obejrzeć, jak będą dostępne.

Devoxx w Polsce - dzień 2

Drugi dzień zaczął się dla mnie kiepsko. Byłem najpierw na "Why software developers should care about deployment and monitoring", Michała Kosmulskiego, który tłumaczył bardzo podstawowe rzeczy. Poszedłem więc na "Case Study: Agile @gov.pl", Matta Harasymczuka, ale tam zamiast o Agile w sektorze rządowym było o podstawach Agile. Skoro prelegent ma tylko 5 minut, aby zachęcić publikę do swojej prezentacji, to tutaj czas ten został ewidentnie źle wykorzystany. 
Ostatecznie poszedłem na "Building systems that are #neverdone", Jamesa Lewisa. Było ogólnie o zasadach YAGNIDRY, TDD, SRP, KISS… Nic konkretnego, już Wujek Bob i inni powiedzieli to 100 razy. Jedyne co to biblioteka Pact się przewinęła po raz drugi na konferencji.

Następnie udałem się na wykład Tomka Nurkiewicza pt.: "Hystrix – managing failures in distributed systems". Jest to biblioteka od Netflix’a, który obecnie generuje sporo ruchu internetowego. A sam Hystrix jest implementacją wzorca Fail Fast. Chodzi o to, że w rozproszonych systemach (np. modne ostatnio wszem i wobec mikroserwisy) czasem część usług może ulec awarii. Jakiś serwis / część systemu może być pod dużym obciążeniem, chwilowo niedostępna, lub odpowiada dopiero po długim czasie. Zamiast próbować taką usługę ciągle odpytywać (i robić jej DoS’a) to może lepiej jest się wstrzymać z zapytaniami i od razu propagować błędną odpowiedź w systemie, albo jakoś inaczej na nią reagować. Podejście takie powoduje, że szybciej mamy informację, że coś nie działa. Dodatkowo jak odciążymy daną usługę, to jest szansa, że się ona naprawi, tzn. skończy przetwarzać zaległe zadania i będzie można z niej ponownie skorzystać. System wtedy jest w stanie samemu się wyleczyć.

Jak działa Hystrix? Mianowicie każde wywołanie, które może się nie udać, opakowujemy w HystrixCommand. Po wywołaniu metody execute() zostanie zwrócona wartość tego co zostało opakowane. Gdy serwis nie odpowiada dłużej niż 1 sekunda (oczywiście można to zmienić), to zostanie zwrócona wartość błędu (Fallback), którą możemy sobie zdefiniować (domyślnie UnsupportedOperationException). Domyślnie każda komenda (tzn. tego samego typu) posiada pulę wątków ustawioną na 10. Według twórców Hystrixa nie potrzeba więcej.

Oczywiście mamy też większą możliwość konfiguracji zachowania, np. przy jakim procencie błędnych odpowiedzi, albo przy jakiej minimalnej liczbie błędnych request’ów, w danym oknie czasowym nie męczyć więcej zewnętrznej usługi.
static class CircuitBreakingDownloadCommand extends HystrixCommand {

 protected CircuitBreakingDownloadCommand() {
  super(
    Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("Download"))
          .andCommandKey(HystrixCommandKey.Factory.asKey("SomeCommand"))
          .andThreadPoolPropertiesDefaults(
             HystrixThreadPoolProperties.Setter()
                .withMetricsRollingStatisticalWindowInMilliseconds(10_000))
          .andCommandPropertiesDefaults(
             HystrixCommandProperties.Setter()
                .withCircuitBreakerEnabled(true)
                .withCircuitBreakerErrorThresholdPercentage(50)
                .withCircuitBreakerRequestVolumeThreshold(20)
                .withCircuitBreakerSleepWindowInMilliseconds(5_000))
        );
    }
}


Hystrix oferuje jeszcze domyślny servlet, który generuje strumień statystyk odnośnie każdego rodzaju Hystrix’owej komendy. Widać go standardowo pod /hystrix.stream i maksymalnie 5 klientów może się pod niego podłączyć. W ładny sposób są te dane wizualizowane za pomocą Hystrix Dashboard. Gdy chcemy na naszej "desce rozdzielczej" widzieć informacje z wielu miejsc, to za pomocą Turbine możemy połączyć wiele strumieni w jeden i pod niego podłączyć dashboard. Przykładowy wygląd poniżej:


Możemy również zapisywać sobie te statystyki i ładnie wyświetlać w Graphite. Dokładny opis jak tego dokonać znajdziemy na blogu Tomka. Było jeszcze omawiane pobieżnie parę zagadnień, ale czas już gonił. Z ciekawostek to jeszcze było o Executors.newFixedThreadPool(), które to są niebezpieczne w środowisku EE, bo wrzucają wątki do kolejki, która jest nieskończona. Może to się zakończyć błędem OutOfMemory i to nie koniecznie w tym miejscu.

Z ciekawych trików, to Tomek jeszcze korzystał z Ctrl + C do zaznaczania całej linii w IntelliJ-u. Dobre na prezentacje. I jeszcze korzystał z Apache Bench. Jest to odpowiednik JMeter’a, ale działa w linii komand i jest dołączony (i był stworzony) do serwera Apache httpd. Przykładowy kod z prezentacji jest dostępny na githubie: nurkiewicz/hystrix-demo, a prezentację (i to po polsku) można obejrzeć na kanale Warszawskiego JUGa: WJUG #161.

Następnie udałem się na prezentację programisty z Elastic’a, David Pilato na temat: "Make sense of your (BIG) data!". Akcent francuski i żarty z których siał się tylko prowadzący były straszne, ale prelegent nie okazał się kompletnym francuskim ignorantem. Na koniec nawet próbował powiedzieć coś po polsku.

Na początku prezentacji było o tym jak dużo danych generujemy każdego dnia.



Następnie prelegent pokazał, jak można budować przykładowe zapytania w Elastic’u (dawniej ElasticSearch) i skupił się na aggregacjach. Pokazał jak wygląda Marvel, który służy do monitorowania instancji Elastic’a. Dla instancji produkcyjnych narzędzie jest płatne, dla pozostałych serwerów (typu test, QA, stage itp) darmowe. Z ciekawych funkcjonalności, to można sobie odtworzyć, co się działo w shardami, gdy do klastra dołączały się kolejne instancje węzłów.

Dalej prelegent pokazał jak za pomocą Kibany można w łatwy sposób wizualizować wszelakie dane jakie mamy zapisane w indexie Elastica.



I to chyba tyle z prezentacji. Całkiem dobra, ale dla osoby która miała już kontakt z tymi narzędziami nie była bardzo odkrywcza. Miałem jednak za to okazję zadać parę pytań i tak rekomendowaną biblioteką javową do Elastica jest jej oficjalna wersja która to może działać jako węzeł w klastrze, wykorzystywać warstwę transportową między węzłami (udostępnianą standardowo na porcie 9300) i pytać bezpośrednio do miejsca gdzie znajdują się poszukiwane dane.

Kolejna prezentacja, na którą poszedłem, była o "Flavors of Concurrency in Java" prowadzona przez Olega Šelajeva. Na początku było dużo wstępu i dopiero po 20 minutach pojawił się pierwszy kod, na którym omawiał wątki w oldschool’owym wydaniu. Nie dałem rady i wyszedłem. Byłem jeszcze chwilę na Reviewing Architectures, Nathaniela Schutta, ale nie byłem w odpowiednim kontekście i nie dałem rady.

Kolejna prezentacja była najbardziej futurystyczna z całej konferencji a mianowicie: "WebVR - democracy in Virtual Reality", Marcina Lichwały. Był jeszcze jakiś drugi prowadzący, ale nie był wymieniony z nazwiska. Obaj prelegenci pracują w firmie Unit9, która dostarcza rozwiązania wirtualnej rzeczywistości. Organizowali również pierwszy w Polsce festiwal i konkurs wirtualnej rzeczywistości w Łodzi.

Chłopaki opowiadali, jakie zastosowania ma wirtualna rzeczywistość. I jest to nie tylko rozrywka, kampanie reklamowe, ale i edukacji i medycyna (np.: redukcja bólu youtu.be/jNIqyyypojg).

Nie pamiętam jakimi okularami się zajmują chłopaki, ale trend jest taki, aby całość obrazu była generowana przez przeglądarki internetowe. Dzięki temu staje się to przenośne. W tym momencie jedynie MozVR (z Mozilli) i Chromium wspierają generowanie doznań wirtualnej rzeczywistości. Ostatecznie zawsze zostaje nam wersja dla ubogich w postaci Cardboard.

W ramach prezentacji miałem możliwość (podobnie jak inni chętni) przetestować okulary. Obraz całkiem dobry, widać było jedynie małe punkty, na które składał się obraz. Ale to bardzo dobry kierunek i powoli zbliżamy się do już całkiem porządnego sprzętu. Jedynie niektóre osoby z chorobą lokomocyjną nie będą w stanie do końca korzystać z tych wynalazków, bo patrząc w bok i do góry, ciągle niby biegnąc, może zrobić się niedobrze.

W kolejnym bloku nie było możliwości wyboru, bo był zaplanowany tylko jeden wykład: "Get Past the Syntax, The Real Scare is in the Semantics", prowadzony przez Venkata Subramaniama. Oczywiście była pełna sala.


Zaczęło się od tego, że ludzie rożnie postrzegają te same rzeczy. Programiści dlatego nie lubią nowej składni kodu, dlatego wiele języków programowania jest do siebie podobnych C# jest jak Java, a ta jak C++, a C++ jak C...

Venkat chciał nam przez to uświadomić, że nie powinniśmy zwracać uwagi na składnię kodu, a na jego semantykę. No i nasza strefa konfortu powoduje, że się zawsze doszukujemy w nowej składni, tego co już znamy. Jak dla mnie nic więcej konkretnego się nie dowiedziałem na tej prezentacji.

Na koniec drugiego dnia poszedłem jeszcze na "Painfree Object-Document Mapping for MongoDB" prowadzoną przez Philippa Krenna. Prelegent opowiadał o rozwiązaniu Morphia, które pozwala na mapowanie obiektów Javowych na dokumenty MongoDB. Całość bardzo wygląda jak implementacja JPA (adnotacje na klasach i polach).

Dalej było o sposobach wykorzystania tego narzędzia, przykłady i dobre praktyki. Na koniec było jeszcze krótko o spring-data-mongodb. Niby robi to samo co Morphia, ale twórcom się nie spodobała ta implementacja i w zamierzchłych czasach miała sporo błędów, więc twórcy MongoDb wzięli się za własną implementację. Ciekawie też brzmi Fongo, który dostarcza implementację in memory dla MongoDb. I ostatnie narzędzie: Critter, które daje nam coś ala Hibernate’owe Criteria API dla Morphi. To już zostawię bez komentarza.