Marcin Stachniuk Blog

Nagrania moich prezentacji o ElasticSearchu

2016-03-22T11:03:00.000+01:00

Pamiętacie wpis odnośnie dbconf 2015 i 69 spotkania Wrocławskiego JUG'a? Pisałem wtedy o moich wystąpieniach w ramach konferencji dla bazodanowców, jak i w ramach WrocJUG. Temat ten sam, tylko zakres trochę inny.

Dzisiaj znów o tym piszę, bo pojawiło się nagranie z dbconf, które prezentuję poniżej:

Pojawienie się tego nagrania zmotywowało mnie do umieszczenia w końcu swojego wystąpienia na ten sam temat w rozszerzonym wydaniu z WrocJUG. Jeżeli po obejrzeniu pierwszego filmu Wam mało, to możecie obejrzeć wydanie poniżej. Jakościowo jest co prawda trochę gorsze, ale tak niestety GoPro nagrywa w niedoświetlonym pomieszczeniu. Kamera jest raczej przystosowana do alpejskiego słońca, niż do ciemnego pomieszczenia. No i dźwięk gorszy z powodu obudowy. Musiałem również wyciąć kilka sekund w początkowych minutach, jak miałem problemy z mikrofonem. Mam nadzieję, że to nie wpłynie na odbiór merytoryczny.

Poniżej jeszcze raz slajdy z edycji wrocławskiej.

Wszelkie komentarze mile widziane.

Chamberconf 2016

2016-03-21T22:50:00.000+01:00

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ć:

IT arystokracja podczas konferencji @chamberconf16

Film zamieszczony przez użytkownika Ola K. (@akunysz) 5 Mar, 2016 o 7:28 PST

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.

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

2016-01-25T21:54:00.000+01:00

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.

Technologia Java Web Start - co i jak?

2015-12-26T09:47:00.000+01:00

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ę:

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.agent, http.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.

33rd Degree 4 Charity we Wrocławiu

2015-12-21T23:40:00.000+01:00

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.

Po dbconf 2015 i 69 spotkaniu Wrocławskiego JUG'a

2015-11-05T12:12:00.000+01:00

Ostatnio, miesiąc po poprzednim wystąpieniu na WrocJUGu, miałem okazję dzielić się swoją wiedzą na temat ElasticSearch’a. Najpierw było to w ramach dbconf - konferencji dla bazodanowców, a później na swoim podwórku, czyli Wrocławskim JUG’u. Początkowo kolejność miała być inna (najpierw WrocJUG, potem dbconf), ale nie wyrobiłem się z przygotowaniem. Nie wpłynęło to jednak na jakość obydwu wystąpień.

W ramach dbconf byłem właściwie tylko na swoim wykładzie i imprezach integracyjnych, gdyż nie czuję się typowym bazodanowcem. Zresztą konferencja odbywała się w Jurze Krakowsko-Częstochowskiej, więc była okazja aby zwiedzić okolicę.

Co do samego wykładu, to poszło mi chyba całkiem dobrze. Płynnie uruchamiałem wcześniej przygotowane przykłady i było trochę pytań z sali. Końcówkę musiałem jednak już gnać i pominąć parę szczegółów, bo niestety sztywne ramy czasowe nie pozwoliły mi na przekazanie wszystkiego. Po prezentacji było trochę pytań, na które już odpowiadałem po za salą.

Z całego pośpiechu zapomniałem zabrać zasilacza, ale na szczęście organizatorzy mi go odesłali, więc mogłem kilka dni później poprowadzić ten sam temat we Wrocławiu.

W ramach JUG’a pierwszy raz spotkaliśmy się w nowym miejscu tj. w Sanatorium Kultury na rynku. Bardzo fajne miejsce, ze sceną jak w teatrze i klimatycznym oświetleniem. Było trochę problemów z mikrofonem, ale jak już wymienili baterię, to działało.

Na spotkanie była chętna ponad setka ludzi, ale na sali była już tylko połowa z tego.

Na szczęście nie ograniczał mnie czas i cała prezentacja zajęła mi 2 godziny! Było sporo pytań z publiczności, zwłaszcza od Kamila i jeszcze jednej osoby, która wcześniej pracowała sporo z Apache Solr. Nie na wszystkie umiałem odpowiedzieć, bo nie jestem specjalistą w temacie i nie spotkałem się z niektórymi omawianymi przypadkami.

Udało mi się na szczęście zebrać trochę feedbacku, tego dobrego i złego, więc uważam, że warto go tutaj zapisać, aby za jakiś czas zrobić sobie retrospekcję i sprawdzić czy się coś poprawiło. Dziękuję wszystkim dzielącym się ze mną swoją opinią!

Uwagi:

“Podczas przełączania slajdów machałeś ręką, jakbyś chciał rapować” - fakt, widać to na nagraniu, do poprawki.
“Warto by mieć ciągle agendę gdzieś z boku, bo często pytania wybiegały mocno w przód (dotyczyły tematu który nie był jeszcze omawiany)” - choć nie spotkałem się z takim podejściem na konferencjach, ale to może mogę być pierwszy ;) Rzeczywiście można wywiesić agendę gdzieś z boku i wtedy osoby zadające pytanie mogą 2 razy się zastanowić, czy to aby na pewno jest dobry moment na dane zapytanie. Można jeszcze wydrukować kartki z agendą i umieścić na siedzeniach jak w teatrze lub operze, ale to jeszcze wyższy poziom ;)
“Dużo pytań o specyficzne tematy, których ktoś kto pierwszy raz spotyka się z narzędziem i tak nie zapamięta” - to fakt. Było sporo szczegółowych pytań, których osoby początkujące i tak nie zapamiętają. Z drugiej strony osoby zaawansowane też chcą coś wynieść z prezentacji, więc wypada odpowiedzieć. Ja się cieszę, że czasem była zażarta dyskusja, bo sam się przez to czegoś dowiedziałem. Fajne jest również to, że uczestnicy odpowiadają sobie nawzajem. Z drugiej strony liczne pytania trochę zaburzają tok prezentacji. Ciężko tutaj znaleźć złoty środek:/ Może powinienem rzadziej pytać, czy są jakieś pytania?
“Zabrakło przykładów z poziomu Javy” - no fakt skupiłem się na zapytaniach ~~REST~~JSON’owych, a zapomniałem, że jesteśmy na Java User Group. Dobra uwaga, powinno być więcej kodu z Javie. Chyba coś muszę dodać w kolejnej wersji (jeśli będzie kolejna wersja).
“Lepiej niż miesiąc wcześniej, gdzie puszczałeś wcześniej nagrany film” - tak, tym razem były przygotowane przykłady, które odpalałem na żywo. W prezentacji o Liquibasie bardzo dużo mogło pójść nie tak, więc lepiej było nagrać krótki filmik. Jest więc jakiś postęp.
“Widownia mogłaby bardziej uczestniczyć w tworzeniu przykładów” - mogłem pytać się np. jaki film utworzyć w indeksie, co poszukać itp. Do poprawki.
“Przydałyby się jeszcze jakieś fajerwerki. Nawet najlepsza prezentacja jeśli trwa długo, potrzebuje przerywnika” - był żart o masturbacji… Ale fakt zapomniałem o zasadzie, która kiedyś była dla mnie bardzo ważna, aby był jakiś śmieszny przerywnik w trakcie. Zwłaszcza, że prezentacja zajęła mi 2 godziny. Nie wiedziałem wcześniej, że może mi to tyle zająć.
“Sekcja "teoretyczna" powinna zostać lepiej omówiona” - nie wiem co miałbym jeszcze omawiać w kwestii teoretycznej… postawiłem bardziej na praktykę.
“Wymowa: "bede", "must", "fuzzy", "schema” i język potoczny: "klepał w klawiaturę", “mianowicie” - chyba trochę za dużo oglądania Pana Wiesława Wszywki. Nad wymową niektórych słów muszę trochę popracować, ale języka potocznego nie zmienię - innym osobom luźny styl prowadzenia prezentacji się podobał (wliczając w to mnie), więc tak już zostanie. Nie chcę gadać jak nudny wykładowca.
“Próby kodowania na żywo kiepsko wychodzą” - fakt chciałem coś tam małego zakodować w trakcie - pod wpływem pytania z publiczności - i były z tym pewne problemy. Podpowiadania składni brak, nie robiłem tego wcześniej, po za tym inne obszary mózgu są odpowiedzialne za mówienie i za pisanie - nie jestem w stanie robić tego równocześnie.

Była jeszcze masa pozytywnych komentarzy. Większości bardziej się podobało niż nie podobało. Nie będę jednak przytaczał tych pozytywnych komentarzy.

A już za niecały miesiąc, 33 degree 4 charity zawita do Wrocławia. Będę tam mówił o Liquibase, czyli mój temat z 67 spotkania WrocJUG. Trzeba będzie go trochę zmodyfikować, aby zmieścić się w wyznaczonym czasie. I będę mógł zobaczyć swoją prezentację na dużym ekranie :) Już dzisiaj wszystkich serdecznie zapraszam!

Poniżej slajdy dla zainteresowanych odnośnie ElasticSearch’a:

Po 67 spotkaniu Wrocławskiego JUG'a

2015-10-03T23:59:00.000+02:00

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:

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

Poniżej slajdy ze spotkania...

Liquibase - Zarządzanie zmianami w relacyjnych bazach danych

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

Confitura 2015

2015-07-15T22:38:00.000+02:00

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

Devoxx w Polsce - dzień 3 ostatni

2015-07-01T23:15:00.000+02:00

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’a, Metrics do zbierania statyskych z różnych części aplikacji, Guava, Logback, Hibernate Validator, JDBI dla połączenia z bazą danych, Liquibase dla wersjonowania bazy, Freemarker, Mustache 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:

Szukanie wielu pomysłów - najpierw powinniśmy zbierać jak najwięcej pomysłów
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
Tworzenie połączeń - musimy naszym pomysłem podzielić się z innymi i wzajemnie się inspirować
Poszukiwanie kierunku - mindfulness i unfocus są najlepsze dla kreatywności
Wykonanie pomysłu - trzeba wizję zrealizować
Zrozumieć błędy - i wynieść naukę na przyszłość
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

2015-07-01T23:08:00.000+02:00

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 YAGNI, DRY, 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))
        );
    }
}

Kod z repozytorium Tomka.

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:

Źródło: https://github.com/Netflix/Turbine/wiki

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.

Źródło https://www.domo.com/learn/data-never-sleeps-2

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.

Devoxx w Polsce - wrażenia z pierwszej edycji

2015-07-01T22:44:00.000+02:00

Pierwszy Devoxx w Polsce (dawniej 33 Degree) odbył się w dniach 22-24 czerwca 2015, w nowo wybudowanym centrum kongresowym w Krakowie, mogącym pomieścić ponad 2000 ludzi. I to było idealne miejsce na konferencję - nowy, ładny i przestronny budynek z ogromną salą z balkonami na trzech poziomach, gdzie mogli zmieścić się wszyscy uczestnicy.

Konferencję otworzył standardowo Grzesiek Duda. W trakcie rozpoczęcia miała być krótka prezentacja Vaadin Designer’a, ale niestety był problem z połączeniem laptopa do rzutnika. Z racji ograniczonego czasu, trzeba było uwierzyć na słowo, że narzędzie jest fajne.

Pierwszy keynote poprowadził Hadi Hariri: "The Silver Bullet Syndrome". Opowiadał o tym, w jaki sposób szukamy rozwiązania starych problemów, czyli o wynajdowaniu koła na nowo, aby było bardziej okrągłe. I tak z make’a przerzuciliśmy się na ant’a, później maven’a i gradle’a… Poszukujemy idealnego rozwiązania, najlepiej naszych wszystkich problemów, czyli tytułowego silver bullet. Powoduje to następujący "cykl przetrwania w IT": nowa technologia -> wciśnięcie jej użytkownikom -> organizowanie szkoleń -> użycie na produkcji -> jak coś nie działa, to telefon do konsultanta i tak w kółko od nowa.

Hadi wyśmiewał jeszcze inne potworki jakie tworzymy, np.: AbstractSingletonProxyFactoryBean, FizzBuzzEnterpriseEdition i JavaScript:

Tak naprawdę, to powinniśmy zadać sobie pytanie, jaką to nam przyniosło wartość biznesową? Jak usprawniliśmy czyjąś pracę lub życie, a nie wymyślamy kolejne frameworki. Nasze CV powinno więc wyglądać raczej tak:

(Sorry za kiepską jakość...)

Ostatecznie stanęło na tym, że jednak musimy ciągle uczyć się nowych rzeczy. Nagranie z prezentacji (ale nie z Devoxxa) jest dostępne na Vimeo: https://vimeo.com/130202574, a starszą wersję slajdów znalazłem tutaj: http://schd.ws/hosted_files/buildstuff14/a5/wcf.pdf

Pierwszą prezentacją po keynote na którą poszedłem było: "Principles Of Microservices", Sama Newmana. Było o The Twelve Factors, czyli o zebranych zasadach z doświadczeń, jak pisać aplikacje, które są deploy'owane w dużych ilościach, aby było łatwiej nimi zarządzać i utrzymywać.

Z rozwiązań, które warto zapisać (i może kiedyś im się w razie konieczności lub nadmiaru wolnego czasu przyjrzeć) to:

Pact - biblioteka do testowania i definiowania kontraktów pomiędzy mikroserwisami (czyli: Consumer driven contracts)
ZooKeeper - do ogarnięcia utrzymania, konfiguracji itp. wielu rozproszonych systemów
etcd - rozproszona konfiguracja dla wielu serwisów
Consul - to samo (albo prawie to samo co dwa powyższe)

Sam na prezentacji przedstawił 8 zasad mikroserwisów i je wyjaśnił:

Modelled Around Business Domain
Culture Of Automation
Hide Implementation Details
Decentralise All The Things
Deploy Independently
Consumer First
Isolate Failure
Highly Observable

Najbardziej mi utkwiło w pamięci, że trzeba mieć jedną osobę, która patrzy na aplikację i co się w niej dzieje, korzysta z kibany i stosując correlation id, śledzi, co dokładnie się dzieje z danym request’em i gdzie najwięcej czasu spędza. A tutaj jakaś starsza wersja slajdów z XP Days Ukraine

Następnie pospieszyłem na "OnConnectionLost: The life of an offline web application", prowadzoną przez młodych pracowników z ThoughtWorks: Stefanie Grewenig i Johannesa Thönesa. Prelegenci tworzyli aplikacje, które musiały działać w przeglądarce i również off-line. Przykładowo aplikacja na tableta dla pracownika supermarketu, który sprawdza dostępność produktów na półkach i zamawia co trzeba. Dawniej korzystano z kartek do tego celu, ale można pójść z duchem czasu i zrobić to lepiej. Połączenie z internetem bardzo łatwo zgubić na sklepie, a zamówienie trzeba złożyć, więc warto w takim przypadku, aby aplikacja działała offline.

I tak za pomocą html5 application cache możemy zdefiniować, które zasoby powinny zostać zapamiętane po stronie przeglądarki, do działania w trybie offline. Mamy również możliwość, wymuszenia aktualizacji tych zasobów, gdy pojawią się ich nowsze wersje na serwerze. Najważniejsze, aby manifest, w którym definiujemy co ma być cachowane, sam nie został zcache'owany. W tym celu warto ustawić w nagłówkach no chache. Alternatywą dla application cache jest Service Workers, ale póki co jest to googlowy wynalazek, zaimplementowany tylko w Chromie i FF.

Jeśli chodzi o przechowywanie wprowadzonych danych offline, to mamy Web Storage i IndexedDB. W pierwszym rozwiązaniu jest sporo problemów (między innymi jak użytkownik chce otworzyć wiele zakładek naszej aplikacji) i prelegenci zalecali drugie rozwiązanie. Oferuje ono transakcyjność pomiędzy wieloma zakładkami. Niestety obecnie jest ono wspierane tylko w Chrome.

Ostatnim problemem, jaki jest do rozwiązania przy aplikacjach działających w przeglądarkach off-line, to synchronizacja danych. Warto korzystać od samego początku ze wzorca Command, czyli wszelkie zmiany, jakie wykonuje użytkownik wrzucamy do lokalnej kolejki i jak stanie się online, to je dopiero przetwarzamy na serwerze. Ewentualnie, aby nie mieć jakiś problemów z łączeniem wyników, to możemy zapisać snapshot’a aktualnego wyniku. Nie warto się spalać nad rozwiązywaniem konfliktów (o ile nie piszemy gita przez przeglądarkę), a w najgorszym wypadku możemy wyświetlić dwie wersje dokumentu i użytkownik skopiuje sobie to, co mu brakuje do nowszej wersji.

Z dalszych rad - danych wrażliwych nie powinniśmy zapisywać w przeglądarce, bo są one dostępne jawnym tekstem, a sama enkrypcja po stronie JavaScriptu może nie być najlepsza. I jeżeli decydujemy się na budowanie aplikacji działającej bez połączenia z internetami, to w pierwszej kolejności powinniśmy zadbać o działanie bez serwera i wprowadzenie wzorca Command zamiast requestów. W innym wypadku bardzo zemści się to na nas w późniejszym czasie. Slajdy można obejrzeć tutaj: http://www.slideshare.net/jthoenes/onconnectionlost-the-life-of-an-offline-web-application-craft-conf-2015

Kolejne wystąpienie pt.: "Co było pierwsze: kod czy architektura?" Sławka Sobótki rozpoczęło się od poziomów cywilizacji wg. Skali Kardaszewa, aby zachęcić słuchaczy do aktywnego słuchania. I to się z pewnością Sławkowi udało. Prelegent „zajrzał” na chwilę do umysłu programisty i architekta. Ten pierwszy w przypadku problemu wyboru rozwiązania A i B próbuje wybrać lepsze. Architekt w takim przypadku robi krok wstecz, patrzy z dalszej perspektywy i zastanawia się, czemu w ogóle mamy wybór i czy rzeczywiście musimy wybierać.

Następnie przyglądaliśmy się różnym rodzajom obrazków, jakie malują architekci, aby przejść do tego, jak je malować. Dobry podział tych obrazków jest zebrany w książce Software Architecture for Developers, a mianowicie C4:

Context - czyli architektura korporacyjna. Pokazujemy na niej osoby korzystające z systemu, inne zależne systemy i instytucje. Odbiorcami taki obrazów są klienci i zarząd.
Containers - architektura wdrożenia. Tutaj mamy wszelkie techniczne zależne elementy, jak bazy danych, kolejki komunikatów, repozytoria, bazy danych, kontenery, klienci (w sensie przeglądarka, aplikacja na telefon). Jest to przydatny diagram dla administratorów, utrzymaniowców i DevOpsów.
Components - czyli architektura systemu. Obrazek ten pokazuje komponenty / moduły (jakkolwiek sobie zdefiniujemy czym to dokładnie jest). Jest to przydatne dla programistów, dając obraz z lotu ptaka na aplikację
Classes - architektura aplikacji, pokazująca wewnętrzną strukturę dokumentu, bardziej wzorce niż konkretne klasy

Jak prezentacja Sławka będzie dostępna on-line to umieszczę tutaj odpowiednie zdjęcia.

Z praktycznych rzeczy to zapamiętałem (albo raczej sobie zapisałem) jeszcze parę rad. Jeśli korzystamy z RESTa, to powinniśmy mieć teoretycznie tylko nazwy zasobów w adresach URL. Jednak praktycznie, to warto rozważyć, co częściej się nam zmienia: zasoby czy procesy? Gdy zasoby są w systemie stabilne, to robimy RESTfull, a jak procesy to do RESTa wrzucamy czasowniki.

Connascence oznacza, że jak coś zmieniamy w jednym miejscu w systemie, to musimy to również zmienić w drugim miejscu. Przykładowo mikroserwisy nie powinny korzystać z bibliotek współdzielonych. I dodatkowo powinniśmy rozdzielać pojęcia w systemie, aby lepiej nam się rozdzielało komponenty systemu.

W ten sposób zostało przedstawione, jak tworzenie dużej architektury od początku prowadzi do kodu. Następnie Sławek spróbował pokazać podejście odwrotne, tzn. jak z naszych mikrodecyzji na poziomie kodu wyłania się nasza architektura.

Podsumowując, nie wiadomo który framework jest lepszy, ani który język programowania. Programowanie to dyscyplina polegająca na zmyślaniu - faktura to funkcja, albo faktura to obiekt… A tak to wszyscy powinniśmy się nauczyć assemblera, aby wiedzieć jak działa krzem, aby przestać toczyć wojny religijne, o to który język programowania jest lepszy...

Następnie byłem chwilę na wykładzie "Using JavaScript/HTML5 Rich Clients with Java EE 7", Reza Rahmana, ale musiałem wyjść. W sumie dobrze, bo z późniejszych opinii było nieciekawie, głównie historia, jak to przez lata próbowano ożenić frontend z backendem.

Poszedłem więc na: "Technical leadership – from an expert to a leader", Mariusza Sieraczkiewicza. Nie widziałem początku, ale prelegent mówił o tym, że dobry leader powinien przygotować takie środowisko, że każdy będzie chciał w nim pracować. Następnie było o rzeczach, których każdy powinien spróbować: więcej myśleć niż tylko reagować, robić sobie codzienną retrospektywę, zrozumieć, a nie oceniać - coaching. Aby móc lepiej motywować ludzi, to powinniśmy ich lepiej poznać, jakie są ich potrzeby i zbierać feedback, a w Agile jest pełno narzędzi związanych z feedbackiem.

Na koniec Mariusz ogłosił, że pisze książkę na ten temat i szuka chętnych chcących podzielić się z nim swoimi doświadczeniami. Kontakt można znaleźć na jego blogu: http://msieraczkiewicz.blogspot.com/

Przedostatnią prezentacją pierwszego dnia konferencji była: "Caching reboot: javax.cache & Ehcache 3" prowadzona przez Louis Jacomet. Początkowo prowadzący omówił, co ile czasu zabiera, jak przeskalujemy czas pewnych operacji komputera na bardziej ludzkie, odczuwalne i zrozumiałe jednostki. Miało to na celu uświadomienie sobie, że naprawdę potrzebujemy cache w aplikacji. Następnie było o zmianach w EhCache w wersji 3 w stosunku do wersji 2. Mianowicie Java doczekała się ustandaryzowanego Caching API ujawniającego się pod numerem JSR-107. I nowa wersja EhCache’a implementuje tą specyfikację, przez co wsteczna kompatybilność została złamana.

W standardzie JSR-107 nie ma zdefiniowanych ustawień dla Capacity control, ani Locking Options. Dalej było demo, jak łatwo można korzystać z EhCache. Jest możliwość modyfikowania ustawień w trakcie działania aplikacji. Problemem jest jedynie odpowiednia konfiguracja, a mianowicie dobranie odpowiednich wartości. Jedyne co prowadzący mógł polecić, to pójście na produkcję i obserwowanie zachowania. Największym wyzwaniem przy implementacji EhCache’a jest założenie, że błąd w cache’u nie powinien skutkować wyjątkiem do użytkownika (aplikacji). Prezentacja całkiem fajna.

Na końcu dnia poszedłem na prezentację Adama Warskiego pt. "Supler: complex web forms, not so complex". Adam jak zwykle w wielkim stylu przedstawił rozwiązanie, które stworzył wraz z zespołem w SoftwareMill’u. Supler jest narzędziem, które spaja frontend w JavaScripcie z backendem Scalowym. Pomaga generować formularze (nawet zagnieżdżone i skomplikowane), a jednocześnie nie jest związany z żadnym frameworkiem. Było przez cały czas live demo i niewiele slajdów. Trochę mi umknęło jak ożenić to rozwiązanie z jakimś frejmworkiem JS. Gdybym musiał tworzyć formularze w Scali, to z pewnością bym pozytywnie rozważył użycie Suplera w projekcie.

Podsumowując pierwszy dzień konferencji, to trzymał poziom, ale czegoś mi zabrakło. Początkowy wykład był mocno motywujący i dający do myślenia, Sławek Sobótka bardzo fajnie opowiedział o malowaniu architektury, ale to było bardzo miękkie. O EhCache i Suplerze była całkiem niezła, ale tego drugiego raczej nie będę mógł zastosować praktycznie w najbliższym czasie. Zabrakło mi trochę jakiejś mocno technicznej prezentacji na temat czegoś nowego, świeżego, lub wywracającego myślenie do góry nogami.

Voxxed Days Vienna 15

2015-02-09T21:28:00.000+01:00

Ledwo zakończył się ChamberConf, a tu już czas na Voxxed Days Vienna 15. Była to moja pierwsza zagraniczna konferencja, nie licząc Code Retreatów. Wejściówkę wygrałem w losowaniu, więc czemu by nie pojechać? W końcu z Wrocławia do Wiednia jedzie się tak długo, jak jeszcze całkiem niedawno jechało się do Warszawy.

Konferencję otworzył Greg Young z tematem Polyglot Data. Była to powtórka z Wrocławia, między innymi opowieść o programiście, co zbamałucił system obstawiania wyścigów konnych i jak można było się przed tym zabezpieczyć.

Następnie byłem na prezentacji Norberto Leite - ewangelisty z MongoDB - pt. Operational Database with Elephant Memory. Początkowo było dużo marketingowego gadania, jak to CTO, CIO, CSO i inni C* widzą bazy danych. Było bardzo dużo odniesień do wcześniejszego wystąpienia Greg'a, który trochę jechał po Mongo DB. Według Norberto, ssie ta baza danych, którą akurat używamy.

Dalej były podstawy Hadoopa (HDFS, YARN, MapReduce) oraz o Pig, Hive, Sparku, jakie są drivery do Mongo, z czym można się integrować... Miało być demo, ale nic konkretnego w końcu nie było. Merytorycznie bardzo słabo.

Później byłem chwilę na wystąpieniu Michaela Nitschingera, ale przeniosłem się na Monadic Java prowadzone przez Mario Fusco. I na początek zobaczyłem te wzory

Tak naprawdę, to monady ukrywają if'a w metodzie, dzięki czemu możemy ładniej, funkcyjnie zapisywać nasz kod. Był pokazany przykład, jak można zrobić dzięki monadom walidację obiektów, a za zadanie domowe, Mario zadał, aby napisać system transakcyjny, z wykorzystaniem monad rzecz jasna.

Prelegent jest współorganizatorem Voxxed Days Ticino. Zastanawialiśmy się w przerwie gdzie to jest (Google Maps lokalizowało Ticino w Szwajcarii i we Włoszech), ale w końcu okazało się, że chodzi o włoski region w Szwajcarii.

Później był obiad i tu spore zaskoczenie. Część jedzenia przyjechała z Polski.

W końcu Grzesiek Duda był organizatorem tej konferencji i pewnie wychodziło taniej w ten sposób. Część napoi też przebyła sporą drogę.

Kolejny slot był słaby, odwiedziłem wszystkie sale, ale nic ciekawego nie znalazłem.

Później była druga prezentacja Grega Younga, który w zastępstwie kontynuował poranny wykład. Było m.in. o tym aby nie ufać benchmarkom, że często dane z nich przekraczają fizyczne możliwości urządzeń.

Kolejna prezentacja była Sergeya Kuksenko, który to na co dzień pracuje w Oracle i zajmuje się performance'm Javy. Mimo developerskiego charakteru jego pracy, musiał oczywiście pojawić się disclaimer na początku.

Wykład było mało praktyczny, ale bardzo ciekawy. Było o wydajności Javy, ale na poziomie procesora. Sporo rzeczy przypomniało mi się z architektury komputerów ze studiów. Kod z przykładów jest dostępny tutaj: kuksenko/quantum, a slajdy poniżej.

"Quantum" Performance Effects from Sergey Kuksenko

Ostatni wykład był Christophera Bateya o microservisach. Prelegent przedstawiał, jak to on w projekcie zbudował system, będąc świadomym problemów wynikających z rozproszenia aplikacji. Jednak wszelakie przypadki, że część systemu nie działa, albo są lagi na sieci miał przetestowane.

I tak do symulowania problemów z siecią korzystali z saboteur, a do mockowania web serwisów WireMock. Spore streszczenie prezentacji Christophera można znaleźć na jego blogu: Building fault tolerant services: Do you handle timeouts correctly?

Sama prezentacja nie była jakaś fajna, czegoś w niej brakowało...

Na koniec było jeszcze piwo sponsorowane prze TypeSafe. Niestety nie mogłem zostać za długo, ale z tego co wiem, to impreza trwała długo.

Co do samej imprezy, to miała ona na celu rozruszanie lokalnej społeczności. Merytorycznie daleko jej było do tych najlepszych konferencji - była to typowa lokalna inicjatywa, która jak na pierwszy raz wyszła całkiem spoko.

ChamberConf wrażenia jako organizator, prelegent i uczestnik w jednym

2015-02-02T21:59:00.000+01:00

W końcu się zebrałem, aby napisać relację z ChamberConf. Była to pierwsza konferencja organizowana przez Wrocławski JUG. Sam również po raz pierwszy miałem okazję uczestniczyć w organizacji takiego wydarzenia. Ostatnie 2 tygodnie przed wydarzeniem do łatwych nie należały...

Z założenia konferencja miała być bez sponsorów, czyli bez wszelakich konkursów, stoisk, prezentów itp. Początkowo konferencja była planowana na 65 osób, ale ostatecznie wyszło 80. Miejsce było niezwykłe, bo to były psychiatryk (gdzieś niedaleko jest jeszcze działający oddział), a jednocześnie bardzo ładny zamek, z dala od wielkich miast i cywilizacji. Konferencja trwała dwa dni, ale sporo osób przyjechało już w piątek wieczorem, więc nieoficjalnie zaczęło się trochę wcześniej.

Na pierwszej prezentacji w sobotę Tomka Borka i Jacka Jagieły pt. To nie zawsze wina aplikacji, robiłem za pilot do przełączania slajdów, ponieważ żaden wskaźnik nie chciał akurat współpracować z Ubuntu. Slajdy można sobie przejrzeć na prezi.com, jak i na slideshare. Z prezentacji wynikało, że należy pamiętać o monitoringu aplikacji i infrastruktury, bo często problemy z wydajnością nie leżą w naszym kodzie. Fajne było zadawanie pytań na koniec przez prelegentów do publiczności, czyli w odwrotnym kierunku niż zwykle.

Następnie Adam Warski opowiadał o Reactive Manifesto z użyciem Akki. Było trochę wstępu teoretycznego i sporo kodowania na żywo. Występ się trochę przedłużył, ale zależało nam na tym, aby konferencja nie miała sztywnych ram.

Następnie Konrad Malawski opowiadał o algorytmach głosowania w sieci. Było m.in. o Paxosie (którego prawie nikt nie rozumie), jak i jego uproszczonych wersjach. Początkowo bałem się, że to będzie prezentacja czysto akademicka, ale koniec końców okazało się, że bodajże raft consesus jest gdzieś tam w Akkce zaimplementowany.

Następnie był obiad i ostania prezentacja pierwszego dnia, Michała Bartyzela pt. Z czym mierzą się zespoły? Michał opowiadał sporo swoich doświadczeń i trudności jakie spotykamy w naszej pracy, oraz jak zmieniał się jego światopogląd na przestrzeni lat.

Następnie było unconference, czyli coś co nie wiedzieliśmy czy się uda czy nie. Ale wychodzi na to że się udało. Było sporo pytań do Konrada, rozmów o pracy zdalnej, CQRSie i inne, a to wszystko w luźnej atmosferze. Później całość się przeniosła na kolację i dalsze rozmowy z ludźmi zwłaszcza nowopoznanymi.

Drugi dzień rozpocząłem od zapowiadanego morsowania. Niestety nikt chętny się nie zgłosił, chociaż o 2:00 w nocy ktoś się podobno deklarował. Może za mało przypominałem uczestnikom o tym temacie...

Drugiego dnia udałem się na Archi-Katę do Tomka Borko. Warsztat był na kartkach bez użycia komputerów, ale zmuszał do sporego myślenia, a później dyskusji i oceniania prac innych. Bardzo fajny warsztat.

Równolegle do warsztatów była ścieżka z prezentacjami. Tam frekwencja była mniejsza, ale podobno bardzo sprzyjało to żywej dyskusji.

Po przerwie obiadowej sam prowadziłem warsztaty. Jak się okazało, był to jedyny temat związany z Java, gdyż inne były o Scali, architekturze lub miękkie. Chyba trzeba będzie zmienić Java User Group na JVM User Group. Warsztat był rozszerzoną powtórką z Warsjawy. Sam na początku warsztatu się czegoś nowego nauczyłem, a mianowicie poznałem: Presentation Assistant, dzięki któremu można było wyświetlać wciskane skróty na ekranie. Kiedyś jak szukałem takiego narzędzie pod windę, to każde okazywało się jakieś kiepskie. A wspomniany plugin pokazywał skróty w wersji na Winde i Mac'a.

Implementowaliśmy ten sam problem co na Warsjawie, czyli StringCalculator. I jak doszliśmy do wydarzeń regularnych, to znów zaczeły się schody. Okazje się, że jak "ma się jakiś problem, który rozwiązujemy za pomocą regexpa, to de facto rozwiązujemy dwa problemy". Jakoś w końcu udało się wybrnąć z tego, ale nie było łatwo. Sam kilka dni przed konferencją zaimplementowałem problem, rozwiązanie (pewnie nieidealne) dostępne na githubie: mstachniuk/StringCalculatorKata. A slajdy poniżej:

Szkoda tylko, że nie wszyscy uczestnicy dotrwali do końca, ale wiadomo - niedziela i trzeba było wrócić z tego końca świata do domu. Mój warsztat trochę się przedłużył, ale to ze względu na masę pytań. Na koniec było czuć zmęczenie, ale i zadowolenie.

Podsumowując konferencję wypadła bardzo dobrze. Pierwszy dzień był mocny i miał służyć owocnym rozmowom podczas unconference. Ten cel został osiągnięty. Drugi dzień wypadł już trochę słabiej, więc pewnie można coś w nim poprawić. Można to ewentualnie tłumaczyć znakomitym pierwszym dniem. Mam nadzieję do zobaczenia za rok!

Duplikowanie bloku kodu w IntelliJ Idea

2015-01-14T10:23:00.000+01:00

Dzisiaj mam do zaprezentowania mały lifehack w IntelliJ Idea. Wyszło to podczas przygotowywania (a raczej odświeżania) mojego warsztatu na konferencję ChamberConf'15, której też jestem współorganizatorem (wraz z ekipą z Wrocławskiego JUGa).

Otóż gdy się przesiadałem (dawno dawno temu) z Eclipse'a do Idei, to z początku denerwował mnie sposób duplikowania linii w kodzie. Ale nie o sam skrót klawiaturowy mi chodzi (Ctrl + D który to w starym środowisku usuwał linię), a o sposób duplikowania zaznaczonego kodu. A działa to tak:

Wiem, że mógłbym szybciej zaznaczyć dany fragment za pomocą Ctrl + W, ale wówczas efekt końcowy jest mniej zauważalny.

Generalnie powielany fragment kodu jest wstawiany zaraz za zaznaczeniem. Kiedyś bardzo mnie to denerwowało ale z czasem się przyzwyczaiłem i jakoś z tym żyłem. Ale dzisiaj rano znów zaczęło mnie to irytować... Zacząłem przeglądać YouTrack dla Idei i pogrzebałem trochę w ustawieniach.

Jak patrzymy na mapowanie klawiszy to mamy "Duplicate Line or Block" jak i "Duplicate Lines". Pod pierwszą pozycję jest podpięty skrót Ctrl + D. Gdy go stamtąd usuniemy i użyjemy w drugiej opcji, to otrzymamy ostrzeżenie o konflikcie:

Klikamy na "Leave" i uzyskujemy poniższy efekt działania Ctrl + D:

Jak widać, ten sam (tak samo zaznaczony) fragment kodu, po wciśnięciu magicznej kombinacji, wstawia się w nowej linii!

Mam nadzieję, że ten prosty wpis się spodobał. Jak chcesz poznać więcej trików, to zapraszam na wspomnianą już konferencję: ChambeConf'15, lub odezwij się bezpośrednio do mnie.

Moje wystąpienie na dbConf

2014-12-09T00:12:00.000+01:00

Jakiś czas temu wspominałem o konferencji dla bazodanowców dbConf.pl

Dziś czas w końcu na relacje z niej, gdyż właśnie się pojawiło moje wystąpienie.

Już nie pierwszy raz mam okazję obejrzenia samego siebie w roli prelegenta, ale to pierwsze, publicznie dostępne nagranie. Poprzednie mało kiepski głos. Na początku jestem mocno spięty, gdyż trochę za późno wyjechałem z Wrocławia i musiałem nieźle palić gumę aby zdążyć na czas. Przyjechałem co prawda na miejsce pół godziny przed konferencją, ale byłem trochę zmęczony i lekko zestresowany – do poprawy następnym razem. Można się jeszcze pewnie przyczepić do wielu mankamentów, ale trzeba się nie poddawać i działać dalej. Chyba że myślicie inaczej to czekam na głosy krytyczne.

Moje wystąpienie było jako pierwsze, więc później mogłem już tylko sobie na spokojnie słuchać innych prelekcji i odpoczywać.

Co do samej konferencji, to bardzo mi się podoba jej formuła. Jest ona weekendowa, w górach, więc w razie zmęczenia można sobie trochę powędrować, co uczyniłem drugiego dnia konferencji. Opuściłem wprawdzie przez to wykłady, ale nie ukrywam, że to miałem w planach:-) Nadrobię sobie niedługo, oglądając pominięte, ciekawsze wystąpienia. Spis opublikowanych już prelekcji można już znaleźć na stronie konferencji, lub na kanale na Vimeo.

DbConf jest wyjazdem beż żon, dzieci, kochanek i wszyscy uczestnicy śpią w jednym ogromnym hotelu. Bardzo dobrze to wpływa na integrację, gdyż osoby nie rozchodzą się wieczorami, a wspólnie spędzają czas wolny. Pierwszego dnia zaplanowano spontanicznie konkurs gry w open hexagon. Jest to chyba gra dla psychopatów, wystarczy obejrzeć poniższą zajawkę:

My graliśmy na jakimś wyższym poziomie, gdzie średni czas rozgrywki wynosił 3 sekundy. Ponadto muzyczka była jeszcze bardziej męcząca niż na filmiku powyżej, więc szybko odpadłem. Nie polecam nikomu tej gry.

W drugi dzień, jak już wspomniałem, odpuściłem sobie wykłady na rzecz chodzenia po górach. Wróciłem jednak na wieczorny grill, który odbył się na zewnątrz. Dzień wcześniej jakaś inna równoległa konferencja też miała mieć podobną imprezę, ale przenieśli się gdzieś do środka. My byliśmy twardzi i siedzieliśmy na zewnątrz przy ognisku. Dobrze że zdążyłem zakupić sobie czapkę tuż przez przyjazdem.

W niedzielę był jeszcze warsztat, ale z tego co widziałem nie było już na nim wielu uczestników. Pewnie albo niektórzy za bardzo zabalowali przy ognisku lub już się rozjeżdżali do domów.

Podsumowując, była to pierwsza edycja tejże konferencji. Liczebnie było skromnie (bo tylko 50 osób), ale jest szansa że się to rozrośnie. Podobnie ponoć zaczynał PhpCon - inna konferencja również organizowana przez Polską Grupę Użytkowników Linuxa. Szkoda tylko, że termin się pokrył z czeskim GeeConem, więc ciężko by było być w dwóch miejscach na raz.

Warsjawa 2014 podsumowanie nr 2 i dawanie feeedback’u

2014-12-01T00:22:00.000+01:00

W moim przedostatnim wpisie: Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty umieściłem materiały z których korzystałem podczas tych warsztatów i opisałem swoje pierwsze wrażenia. Teraz czas na kolejną ostatnią część podsumowania, ponieważ już jakiś czas temu spłynęły do mnie wyniki ankiety przeprowadzonej przez organizatorów. A jest się czym pochwalić :-D Poniżej zamieszczam fragmenty korespondencji, którą otrzymałem od organizatorów.

Odnośnie Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych

Your workshop was among best workshops of Warsjawa 2014!

Here comes the results:

number of feedbacks: 8

average grade (1 to 5, higher is better): 4.63

feedback comments:

- A lot of knowledge presented, but a bit too fast.

- Bardzo fajne i przydatne warsztaty - fajnie zorganizowane

- Z warsztatów jestem bardzo zadowolony. Poznałem nowe, lepsze metody testowania, których mam nadzieje użyć w codziennej pracy. Projekt na githubie znacznie ułatwił cala sprawę. Dziękuje :)

- Workshop was as described. From a begginer point of view approach : from simplest libraries to most helpful was realy good.

Co to dla mnie oznacza? Że dostałem 5 głosów z oceną 5 i 3 z oceną 4, lub jakiś inny wariant dający sumę 37. Przy ośmiu głosach daje to właśnie oceną 4.63 (a dokładniej 4.625). Bardzo się cieszę tak wysoką oceną, która w tym momencie trochę rekompensuje ogrom trudu włożonego w przygotowanie tegoż warsztatu.

Odnośnie Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Here comes the results:

number of feedbacks: 6

average grade (1 to 5, higher is better): 4.5

feedback comments:

- Prawdziwe warsztaty, bardzo ciekawie poprowadzone na konkretnym przykładzie. Nie mam do nich żadnych uwag.

- Miałem iść na C/C++ in Android Apps. Jednak mnogość instalowania narzędzi zniechęciła mnie (była sobota 16:00)... dosłownie na 1 minutę przed startem warsztatu przyszedłem tutaj. I nie żałuje. Skrótów wszystkich nie zapamiętałem, ale wiem dokładnie co można za ich pomocą osiągnąć. Formuła warsztatu wymagała ciągłego zaangażowania oraz umożliwiała świetną zabawę w poprawienie kodu kogoś innego :) Prelegent bardzo pozytywnie nastawiony do życia i moim zdaniem niezły kozak jeżeli chodzi o Intelli :)

- Very good workshop, I learned a lot about the Intellij Idea.

Tutaj ocena nie jest już tak wysoka, ale i tak jest dobrze. Zwłaszcza że warsztat był w sobotę pod koniec dnia i większość już pewnie myślała o wieczornym piwie. Bardzo mnie tutaj ucieszyła druga opisowa opinia jednego z uczestników. Dzięki - kimkolwiek jesteś.

Podczas analizowania feedbacku od uczestników moich warsztatów naszły mnie jednak smutne przemyślenia. Ludzie bardzo niechętnie dają opinię zwrotną drugiej osobie! Trzeba się o nią wręcz dopraszać i ciągnąć za język. Szkoda, że system głosowania na Warsjawie nie zadziałał, bo on mógłby dać trochę szerszy obraz oceny warsztatu. A tak, to ankietę pokonferencyjną – jak widać powyżej – mało komu chce się wypełnić. Nie wiem czy to wynika z naszej introwertycznej natury, nieśmiałości, poprawności politycznej, czy z problemu z wyrażaniem swoich odczuć? Przecież na co dzień przekzujemy dalej swoje opinie na temat kodu naszych współtowarzyszy projektu. Przecież robicie Code Review? A może nie?

W każdym bądź razie prelegenci, czy też prowadzący warsztaty – zwłaszcza Ci poczatkujący – oczekują jakiejś zwrotnej opinii na temat swojej pracy! Wierzę w możliwość ciągłego udoskonalenia się i poprawiania swoich zdolności, aby kolejnym razem wypaść lepiej.

W jaki sposób wiec najlepiej zbierać konstruktywne opinie o sobie i swojej pracy? Jak masz jakieś pomysły to koniecznie pisz w komentarzach!

Chcę jeszcze dokonać publicznej konstruktywnej samooceny (aby dać przykład, jakie potknięcia warto wytykać) i napisać, co poszło mi nie tak na moich warsztatach, aby następnym razem nie popełnić tego samego błędu. Na pierwszym warsztacie zapomniałem puścić powitalny filmiki od organizatorów. Niestety, ale tuż przed samymi warsztatami musiałem trochę pozmieniać bazę w git’cie (mam na myśli rebase, ale nie mam pojęcia jak to można na polski przetłumaczyć), aby historia na publicznym repo nie wyglądała później tak:

After reabse of 12 branches on master in #git pic.twitter.com/cQDWtdEtDJ
— Marcin Stachniuk (@MarcinStachniuk) September 22, 2014

Z tego względu gdzieś mi umknęła wiadomość od organizatorów, prosząca o puszczenie filmików. Sory!

Co do drugiego warsztatu, to trochę mniej się do niego przygotowałem (w sensie slajdów), ale na szczęście nie to było najważniejsze, co widać po ocenie. Ważne, że uczestnicy się świetnie bawili i wynieśli sporą wiedzę z warsztatu.

Błędem był jednak brak porządnej aplikacji na telefon / tablet, pokazującej odliczany czas i dającej sygnał dźwiękowy co określony interwał. W tym warsztacie było bardzo ważne, aby co 5 minut robić zmianę, ale mój budzik nie zawsze dzwonił, przez co niektórzy siedzieli dłużej przy klawiaturze. Jak ktoś ma godną polecenia aplikację, do tego na Androida, to czekam na info!

Również brak przerwy mniej więcej w połowie warsztatu był kiepskim pomysłem, gdyż to chyba szybko wymęczyło ludzi. W okolicach drugiej godziny, widziałem zmęczenie na twarzach uczestników. A przerwa tuż przed końcem warsztatów nie była wystarczająco odświeżająca.

Mogłem również się trochę lepiej przygotować z implementowanego problemu, aby w razie dojścia do ślepego zaułku (do którego doszliśmy), aby szybko z niego wyskoczyć na właściwe tory. Do poprawienia następnym razem.

Przy okazji konfitury, firma Spartez zorganizowała jeszcze konkurs dla uczestników. Zadania można było rozwiązać wcześniej online, aby nie tracić czasu na samej konferencji. Jak zobaczyłem pytania (a było ich 6), od razu wiedziałem kto wygra – i nie pomyliłem się. Mimo wszystko zostałem wyróżniony i dostałem gadżety firmowe. Niestety ucho od kubka się potłukło w transporcie, ale jakoś mi specjalnie na nim nie zależało. Liczy się satysfakcja, z rozwiązanych zadań.

Podsumowując, obydwie wysokie oceny z warsztatów motywują mnie do dalszego działania w sferze dzielenia się moją wiedzą z innymi. Jeśli więc chciałbyś, abym poprowadził któryś w/w warsztatów u Ciebie w mieście / w firmie, daj znać na priv – e-mail do mnie znajdziesz na tej stronie.

A jeśli nie miałeś/-aś okazji uczestniczenia w moich warsztatach podczas Warsjawy, to być może, niedługo będzie taka możliwość w okolicach Wrocławia. Po więcej szczegółów zapraszam na stronę: chamberconf.pl

JDK 7 i 8 64 bit + Windows 7 - problemy z połączeniem internetowym

2014-11-07T17:54:00.002+01:00

Co jakiś czas powraca do mnie problem na mojej maszynie związany chyba z kiepską implementacją IPv6 w 64 bitowym JVM lub Windowsie. Nie wiem dokładnie gdzie leży problem, ale już drugi raz spędziłem sporo czasu, aby znaleźć rozwiązanie, wiec czas na notatkę na blogu. Kłopot się objawia tym że maven / gradle / inny DSL do ściągania połowy Internetu, ma problemy ze dociągnięciem zależności i trzeba go ubić.

Aby rozwiązać ten problem warto dodać / uaktualnić zmienną środowiskową JAVA_OPTS tak, aby znalazła się w niej poniższa flaga:

-Djava.net.preferIPv4Stack=true

W przypadku gradle’a warto to jeszcze wrzucić do pliku gradle.properties w naszym projekcie, np.:

org.gradle.jvmargs=-Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true

Teraz już powinno być lepiej, chyba ze akurat trafimy na jakąś przerwę w działaniu ogólnodostępnych repozytoriów, z których aktualnie korzystamy.

Więcej informacji:
Why do I need java.net.preferIPv4Stack=true only on some windows 7 systems?

Networking IPv6 User Guide for JDK/JRE 5.0

Recenzja książki "Czy jesteś wystarczająco bystry, żeby pracować w Google?"

2014-11-06T08:43:00.000+01:00

Nie mam w zwyczaju recenzowania na blogu przeczytanych książek (wyjątkiem była dotychczas książka Tomka Kacznowskiego: Practical Unit Testing), ale po przeczytaniu „Czy jesteś wystarczająco bystry, żeby pracować w Google?” Pana Poundstone Williama, postanowiłem to zmienić (aby pojawiały się na moim blogu nie tylko posty relacjonujące różne konferencje, ale i recenzje i tematy techniczne [o te najciężej ze względu na konieczny duży nakład na przygotowanie czegoś fajnego]).

Na książkę wpadłem przypadkiem, będąc kiedyś w księgarni i standardowo przeglądając co jest na półce pod szyldem „informatyka”. Książka jest wydana przez Wydawnictwo SQN, (na stronie Heliona niby też jest, ale wiecznie „czasowo niedostępna”), więc pewnie niewielu z Was na nią trafiło. Sam pewnie bym ją szybciej kupił i przeczytał, gdyby wieść o niej przyszła do mnie wraz newsletter’em wspomnianej księgarni.

Książka od samego początku opisuje z jakimi przywilejami wiąże się, wymarzona przez wielu, praca w Google. Szybko jednak przechodzi do tego, jak bardzo ciężko się tam dostać. W końcu jednej osobie na 130 kandydatów się to udaje. A dlaczego? Głównie ze względu na pytania otwarte, w których trzeba się wykazać swoimi umiejętnościami. Nie ma jednego zbioru pytań (i poprawnych odpowiedzi), z których korzystają podczas rekrutacji w Google. Pytania są tak ciężkie, że albo się już wcześniej zna pytanie wraz z poprawną odpowiedzią, albo się na nie raczej nie odpowie. Co gorsza, pytania często nie mają jednej poprawnej odpowiedzi.

W książce jest również uzasadniona bezsensowność i bezcelowość prowadzenia rozmów kwalifikacyjnych.

Podczas rozmowy o pracę można stwierdzić, czy dana osoba potrafi miło prowadzić rozmowę, można zadać szereg pytań technicznych, by wykluczyć kandydatów, którzy nie mają zielonego pojęcia, o czym mówią, lecz po za tym można by równie dobrze rzucać kośćmi.

- twórca BitTorrenta, Bram Cohen

Niby coś tam można sprawdzić podczas rozmowy kwalifikacyjnej, ale to nie gwarantuje sukcesu, że kandydat sprawdzi się w danym projekcie lub firmie. Poza tym jest ciężko zweryfikować, czy odrzuceni kandydaci by się sprawdzili. Można jedynie zwiększać prawdopodobieństwo, że dany człowiek się nada.

Dalej książka opisuje szczegóły odrzucania aplikacji kandydatów przez Google. Proces ten jest bardzo skomplikowany i decyzja zależy od wielu osób. Taki skomplikowany proces musi sporo kosztować firmę, ale dzięki temu jest ona pewniejsza, że ma u siebie tych najlepszych.

Książka jest przepełniona zabawnymi historyjkami i anegdotami, które w dużej mierze uszczypliwie wyśmiewają podejście do problemów firmy Microsoft. Tzn. książka porównuje, jak pewne zadania rozwiązał by ktoś z Google, a jak ktoś z firmy produkującej Windowsy (lub cokolwiek innego). Ma to jednak na celu pokazanie innego sposobu myślenia.

Powyższa książka nie mogłaby się oczywiście obejść bez zagadek. Są w niej opisane pytania logiczne, pytania wymagające przebłysku geniuszu, myślenia niestandardowego (lateralnego), myślenia rozbieżnego, pytania Fermiego i pytania oparte o algorytmy. Na początku każdego rozdziału, jak i często w środku, dostajemy porcję pytań, aby można było wytężyć swoje szare komórki i zatrzymać degradację neuronów. Oczywiście książka oferuje na koniec odpowiedzi do wszystkich zagadek, jak i praktyczne wskazówki, w jaki sposób próbować odpowiadać na te pytania.

Podsumowując, polecam tę książkę każdej osobie technicznej, która chce zrobić coś więcej ze sobą niż tylko odbębnić 8 godzin w pracy. Książka nadaje się również dla osób, które nie koniecznie pracują w IT, a ich praca (aktualna lub przyszła) wymaga kreatywności i niestandardowego myślenia. Oczywiście jest to pozycja obowiązkowa dla tych, co wybierają się do Google.

Btw. Za tydzień 15-stego listopada jest Global Day of Code Retreat i obywa się on również we Wrocławiu. Zostało jeszcze kilka wolnych miejsc, więc czas najwyższy się zarejestrować: http://coderetreat-2014-wroclaw.eventbrite.com.

Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty

2014-09-29T18:59:00.000+02:00

W tym roku miałem okazję poprowadzić 2 warsztaty na Warsjawie. Wcześniej prowadziłem jedynie prezentacje (czy to w pracy czy na WrocławJUG), a w formie warsztatów to był mój pierwszy raz! I od razu 2 różne tematy!

Jak mi poszło? Uważam, że co najmniej dobrze. Wydaje mi się, że nie miałem większych potknięć, feedback zbierany od uczestników jest jak dotychczas pozytywny.

Podobne opinie słyszałem, gdy się podpytywałem uczestników, jak i przeczytałem w e-mailach. Pewnie coś więcej będę mógł się dowiedzieć (zwłaszcza liczę na uwagi krytyczne, aby wiedzieć co poprawić następnym razem), gdy uczestnicy wypełnią ankietę pokonferencyjną. Wszelakie e-maile i komentarze również mile widziane.

A tymczasem zamieszczam poniżej materiały z których korzystałem.

Upiększ swoje testy! Testowanie jednostkowe dla średniozaawansowanych.

Kod używany na warsztacie: https://github.com/mstachniuk/SolarSystem

Poznaj lepiej swoje srodowisko programistyczne i zwieksz swoja produktywnosc z IntelliJ Idea.

Kod napisany przez uczestników podczas warsztatów: https://github.com/mstachniuk/WarsjawaCodingDojo

Co do samej konferencji, to minusy (z punktu widzenia prelegenta):
- nie do końca przygotowane sale (rzutnik, nasłonecznienie, jakieś pudła)
- system do komunikacji z uczestnikami nie wysyła załączników i wiadomości nie dochodzą do wszystkich
- nie do końca udany pomysł ze szwendaniem się po knajpach po konferencji

A na plus:
- obecność zagranicznych spikerów
- wcześniejsza rejestracja dla prelegentów
- transparentnosć, co ile kosztowało
- długie przerwy, dobry timeline

I oby tak dalej, albo i jeszcze lepiej!

Rusza rejestracja na tegoroczną Warsjawę oraz moje tematy

2014-09-11T23:39:00.000+02:00

Już niedługo (21.09.2014 21:00) ruszy rejestracja dla uczestników Warsjawy - darmowej konferencji, która składa się z samych warsztatów! Liczba miejsc jest ograniczona, dlatego warto się spieszyć, zwłaszcza, że jest szansa na warsztaty, które będzie prowadził Venkat Subramaniam! Jest to założyciel Agile Developer, autor wielu książek jak i świetny prelegent, którego mieliśmy okazję wielokrotnie oglądać na polskich konferencjach. Styl jego prezentacji jest specyficzny, a o części jego wystąpień można przeczytać na moim blogu.

Dzięki wizycie Venkata w Warszawie, udało się go zaprosić także do Wrocławia i poprowadzi on wykład Programming with Lambda Expressions w ramach WrocJUG. Będzie również warsztat: Programming Concurrency - Workshop, ale na niego nie ma już miejsc, a lista oczekujących jest długa.

Jednocześnie zapraszam na warsztaty, które sam będę prowadził w ramach Warsjawy. Poniżej przedstawiam tematy, które będę prowadził, wraz z krótkim komentarzem.

Czas: Piątek, 26 września 2014 13:00
Temat: Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych

Opis: Warsztat jest przeznaczony dla średniozaawansowanych programistów Java, którzy napisali już trochę testów i chcieliby je upiększyć. Podczas warsztatu będziemy ćwiczyć tworzenie ładnej sekcji given (za pomocą Builder'ów), jak i czytelniejsze zapisywanie assercji (za pomocą Hamcrest'a, FEST'a i AssertJ). Bedzie jeszcze o testowaniu wyjątków i testach parametrycznych. Warsztat będzie prowadzony po polsku, względnie może być po niemiecku;) Wymagane jest zabranie ze sobą własnego komputera ze skonfigurowanym środowiskiem programistycznym i opcjonalnie konto na GitHub'ie (do przesyłania gist'ów).

Być może, jak starczy czasu, będzie można poćwiczyć jeszcze inne rzeczy, ale to już zależy głównie od prędkości grupy, jak i zainteresowania tym, co będą chcieli usłyszeć uczestnicy.

Czas: Sobota, 27 września 2014 16:00
Temat: Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Opis: Każdy programista powinien poświęcić 10 godzin na dogłębne poznanie swojego zintegrowanego środowiska pracy, aby móc z niego efektywnie (i efektownie) korzystać! A Ty ile czasu na to poświęciłeś? Warsztat jest przeznaczony dla programistów Java, korzystających z IntelliJ Idea, lub chcących się go nauczyć. Warsztat będzie miał formę Coding Dojo, podczas którego będziemy wspólnie pisać Katę i wzajemnie uczyć się korzystania z Idei bez użycia myszki. Warsztat będzie prowadzony po polsku, względnie może być po niemiecku;) Własny komputer nie jest wymagany, gdyż będziemy kodować wspólnie na jednym, podpiętym do rzutnika. Przyda się za to notatnik i długopis do zapisywania nowopoznanych kombinacji klawiszowych.

Na pomysł tego warsztatu wpadłem po tym, jak go z wielkim sukcesem przeprowadziłem w ostatnim projekcie. Po prostu, gdy udało się kupić IntelliJ Idea dla całego zespołu (o co bardzo ciężko walczyłem - skutecznie), musiałem wdrożyć kolegów w nowe środowisko. Wcześniej pokazywałem jedynie czym się różni Idea od Eclipse'a, ale to nie to samo co praktyka przy klawiaturze. Nie chciałem również słyszeć narzekań, że teraz trzeba się na nowo uczyć wszystkich kombinacji klawiszowych.

Zebrałem więc cały zespół, wyjaśniłem zasady i poszłooo! Było bardzo intensywnie, śmiesznie i co najważniejsze pouczająco. Ludzie wychodzili wówczas z sali z ugotowaną głową, ale widziałem później, że te warsztaty bardzo im pomogły. Zebrałem również bardzo pozytywne opinie na retrospektywie.

Mam nadzieję, że na Warsjawie będzie równie gorąco.

P.S. W razie jak byście chcieli się wcześniej zapisać na warsztaty, to przeczytajcie ten status.

Implementacja Singleton’a w Javie

2014-09-01T22:29:00.000+02:00

Ostatnio, podczas z jednej z rozmów rekrutacyjnych, dostałem pytanie, "A jak by Pan zaimplementował singleton w Javie?". Pytanie dość standardowe, mógł by je zadać każdy. Odpowiadam więc: „Klasa, z prywatnym konstruktorem, z polem statycznym o typie zadeklarowanej klasy, metoda getInstnce(), itd.”. Rekruter na to: "No dobra, a jakiś inny pomysł?".

Na szybko nie przychodziło mi jednak nic do głowy... Wtedy padło pytanie, które zmotywowało mnie do przygotowania tego wpisu: "A czytał Pan Effective Java, Joshua Bloch?". A no nie czytałem i nie sądzę, abym ją przeczytał.

Dlaczego?

Przede wszystkim uważam że ta książka jest trochę przestarzałą. Drugie wydanie pochodzi z 2008 roku i informacje w niej zawarte są trochę nieaktualne. To nie książka o wzorcach projektowych Bandy Czworga, która nie traci na swojej aktualności, a jedynie pozycja o tym jak coś tam dobrze zrobić w Javie. I tak przykładowo rozdział: "Item 51 Beware the performance of string concatenation", traktujące o tym, aby lepiej używać StringBuilder’a niż + do sklejania tekstów, jest już dawno nieaktualne! Chciałem kiedyś pisać posta o tym, ale na stackoverflow i jeszcze gdzieś tam już dawno o tym było. Nie wiem tylko od kiedy dokładnie istnieje ten mechanizm zamiany + na StringBuilder’a w Javie.

O innych dobrych praktykach, można się dowiedzieć zawsze z innych źródeł, niekoniecznie czytając wspomnianą książkę.

Dobra wróćmy do tematu wpisu. W innym rozdziale Effective Java (Item 3: Enforce the singleton property with a private constructor or an enum type), jest zalecenie, aby Singletona implementować za pomocą Enuma. Z tym rozwiązaniem spotkałem się po raz pierwszy podczas review kodu kogoś, kto czytał tę książkę. Użycie wówczas enuma w roli singletonu było dla mnie zupełnie niezrozumiałe! Musiałem dopytać autora o co chodzi.

Dlaczego nie lubię tego rozwiązania? Spójrzmy na przykładowy kawałek kodu (inspirowany Joshuą Blochem, co bym za dużo nie musiał wymyślać, jak tu mądrze użyć singletona). Kod jest i tak kiepski (obliczanie czasu), ale chodzi mi o zaprezentowanie działania omawianego wzorca.

public enum Elvis {
    INSTANCE;

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

public class ElvisProfitService {

    public double ELVIS_SALARY_YEAR = 70_000;

    public double calculateElvisProfit() {
        return Elvis.INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }
}

No i weź tu panie przetestuj taki kod! Możemy jeszcze Elvisa statycznie zaimportować, to linijka 6 skróci się do jeszcze mniej czytelnej formy.

return INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;

Ktoś ma jakieś pomysły jak taki kod przetestować? Da się oczywiście, z wykorzystaniem PowerMock’a [link do rozwiązania na końcu ^1], ale chyba nie o to chodzi aby pisać nietestowany kod?

Dlaczego wolę starszą wersję tegoż rozwiązania:

public class Elvis {

    private static final Elvis INSTANCE = new Elvis();

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    private Elvis() {
    }

    public static Elvis getInstance() {
        return INSTANCE;
    }

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

Dochodzi prywatny konstruktor, statyczna metoda getInstance() i inicjalizacja pola klasy wraz z deklaracją.

W tym przypadku kod korzystający z tego singletonu, mógłby być następujący:

public class ElvisProfitService {

    private final double ELVIS_SALARY_YEAR = 70_000;
    private Elvis elvis = Elvis.getInstance();

    public double calculateElvisProfit() {
        return elvis.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }

    // For tests
    void setElvis(Elvis elvis) {
        this.elvis = elvis;
    }
}

W linii 4 wywołałem getInstance(), aby w przykładowym kodzie produkcyjnym było wszystko cacy. Dzięki temu, zależność ta jest definiowana jako pole w kasie i mamy setter do tego, więc możemy sobie bardzo ładnie przetestować tą funkcjonalność, bez hackowania z PowerMockiem:

public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();
        Elvis elvis = mock(Elvis.class);
        when(elvis.howOldIsElvisNow()).thenReturn(1);
        service.setElvis(elvis);

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

W sekcji given mamy bardzo ładnie zdefiniowane zachowanie, za pomocą Mockito, jakie ma przyjmować masz singleton na potrzeby tego testu.

A Ty jak definiujesz (o ile to robisz) swoje singletony? Które rozwiązanie uważasz za lepsze?

[1] Co do rozwiązania zagadki, jak przetestować Singletona jako Enum’a, to tutaj jest odpowiednia rewizja na github’ie: SingletonInJava e714fb a kod poniżej:

@RunWith(PowerMockRunner.class)
@MockPolicy(ElvisMockPolicy.class)
public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

public class ElvisMockPolicy implements PowerMockPolicy {

    @Override
    public void applyClassLoadingPolicy(MockPolicyClassLoadingSettings settings) {
        settings.addFullyQualifiedNamesOfClassesToLoadByMockClassloader("com.blogspot.mstachniuk.singletoninjava.Elvis");
    }

    @Override
    public void applyInterceptionPolicy(MockPolicyInterceptionSettings settings) {
        Method method = Whitebox.getMethod(Elvis.class, "howOldIsElvisNow");
        settings.proxyMethod(method, new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                return 1.0;
            }
        });
    }
}

Wyższy poziom produktywności w IntelliJ Idea

2014-07-17T15:25:00.000+02:00

Ostatnio natrafiłem na nagrania z konferencji Geekout z Estonii. Zainteresowała mnie 3cia prezentacja: Mouseless Driven Development by Hadi Hariri.

Prelegent (pracownik JetBains’a) opowiadał o tym jak efektywnie kodować bez użycia myszki. Myślałem, że już dostatecznie poznałem to moje ulubione środowisko developerskie, ale jak zobaczyłem pierwszą ciekawostkę, którą pokazał Hadi, to zacząłem robić notatki. A skoro notatki to już nie wiele trzeba, aby był wpis na bloga…

Uważam, że najlepszą metodą poznawania środowiska pracy, jest patrzenie jak korzystają z niego inni. I to może być przy okazji warsztatów typu Code Retreat, Coding Dojo czy innych hackathon'ów, lub właśnie oglądając screencasty i wystąpienia z konferencji. Zachęcam do obejrzenia powyższego video (choć ten efekt z przekrzywionym obrazem z rzutnika uważam za głupi), gdyż opisałem poniżej rzeczy dla mnie nowe, tudzież te wymagające mojego odświeżenia. Warto, przed dalszą lekturą tego wpisu, znać choć połowę skrótów z IntelliJIDEA_ReferenceCard.pdf, gdyż niżej będzie o bardziej zaawansowanych zagadnieniach. A więc do dzieła!

Jak wszyscy zapewne wiedzą (albo powinni wiedzieć), Ctrl + N otwiera klasy lub pliki (gdy dwa razy naciśniemy tą kombinację, lub Ctrl + Shift + N). I tutaj nazwę możemy podawać w szelaki sposób: CamelCase, snake_case (ale dla ułatwienia ze spacją), wspomagając się gwiazdką itd. Idea będzie szukać wszystkiego co pasuje i wyświetli w logicznym porządku. W Eclipse „jakoś tam” też to działa, ale o wiele gorzej.

Ale co mnie właściwie onieśmieliło, to gdy pisząc po nazwie klasy :<numer lini> (słownie: dwukropek i numer linii), plik zostanie otworzony na żądanej pozycji! Ciekawie działa również Alt + F1, które pozwala otworzyć nam plik np. w Project View, Structure, Exporatorze Windowsa, i w innych oknach. A chcąc otworzyć plik w osobnym oknie można zamiast Entera wcisnąć Shift + Enter. A jak chcemy wyszukiwać wszędzie, to możemy to zrobić za pomocą podwójnego naciśnięcia Shift. Część tych wskazówek zaczerpnąłem ze strony JetBrains’a: Navigating to Class, File or Symbol by Name, a część z opisanego na początku video.

Do wyszukiwania użycia jakiejś zmiennej lub metody, zawsze korzystałem z Alt + F7. Jest to skrót, który swoimi korzeniami sięga TotalCommandera, a nawet Norton Commandera. Podobnie jest zresztą z Shift + F6 - rename. Natomiast jak chcemy widzieć dolnego okienka z wynikami poszukiwań, możemy skorzystać z Ctrl + F7, które to skoczy nam do pierwszego wykorzystania i zaznaczy pozostałe. A jak byśmy chcieli podświetlić wykorzystanie wielu różnych zmiennych, to na każdej możemy skorzystać z Ctrl + Shift + F7. Jeszcze podobnie zachowuje się Ctrl + Alt + F7, które to pokazuje wyniki wyszukiwania w popupie. Poniżej przykłady z mojego projektu HamcrestVsFest.

Alt + F7

Ctrl + F7. Obiekt mercury jest tworzony w lini 10, ale po raz pierwszy jest użyty w linii 20.

Ctrl + Shift + F7. Tutaj wykonane na mercury, PlanetBuilder, RotationDirection i Gases.

Ctrl + Alt + F7

Dalej było o tym, jak zmaksymalizować przestrzeń na pisanie kodu. I tak prelegent, przekonywał nas, że można się obejść bez nawigation bara na górze ekranu.

To ten pasek, gdzie jest rozpisane, w jakim pakiecie i pliku aktualnie jesteśmy. Nie jest on nam potrzebny, bo możemy się dostać do niego za pomocą Alt + Home. Mi osobiście on nie przeszkadza, bo jest na tym samym poziomie, co ostatnio uruchamiana konfiguracja projektu, a to lubię widzieć.

Nie potrzebujemy również Tab’ek, gdy mamy wiele otwartych plików, bo przeglądanie ich i szukanie odpowiedniej po nazwie zajmuje wiele czasu.

Tak naprawdę potrzebujemy tylko Ctrl + E, które w bardziej czytelny sposób nam pokazuje, jakie pliki ostatnio przeglądaliśmy i szybciej je w ten sposób odnajdziemy. Jeśli zależy nam tylko na tych które ostatnio edytowaliśmy, to możemy skorzystać z Ctrl + Shift + E. Jest to ulubiony skrót prowadzącego prezentację do tego stopnia, że musi używać zewnętrznej klawiatury w laptopie, bo przycisk E mu się zepsuł. Przykłady użycia poniżej, a Tab'ki możemy całkowicie wyłączyć w ustawieniach.

Ctrl + E

Ctrl + Shift + E

Jak usunąć Tab'ki z otwartymi plikami.

Przeskakiwać pomiędzy poszczególnymi oknami w IntelliJ Idea można za pomocą Alt + <numer okienka>, widoczny przy jego nazwie. Niestety nie na wszystkie okienka wystarczyło numerków, więc jak chcemy np. dostać się do Mavena lub Bazy danych, to Ctrl + Tab jest twoim przyjacielem.

Ctrl + Tab

A jak już w ogóle byśmy chcieli tylko i wyłącznie kod widzieć, to warto się zapoznać z Prezentation Mode. Warto na Windowsie sobie zdefiniować skrót Ctrl + Shift + P jako wejście do tego trybu. Na pewno może się to przydać podczas prezentacji, jak i osobom lubiącym widzieć tylko kod na ekranie.

Następnie poznałem nowe znaczenie F4 w oknie projektu. Dotychczas używałem tego klawisza tylko do otwierania właściwości projektu, a w ten sposób można również otworzyć plik i automatycznie skoczyć do jego edycji. Jest to lepsze od oczywistego Entera, który tylko otwiera wybrany plik, ale fokus pozostaje na oknie projektu.

A co z operacjami typowymi dla myszki, jak dostrajanie wielkości okna projektu? Sam dotychczas myślałem, że jest to jedynie możliwe za pomocą myszki, ale da się też z klawiatury! To kolejne moje wielkie odkrycie z tej prezentacji, po którym mi i osobom na sali opadła szczęka. Chcąc przykładowo zmienić rozmiar widoku projektu, musimy mieć na nim focus (Alt + 1) i teraz już wciskamy tylko Ctrl + Shift + Prawo / Lewo. Okno z wynikami testu? Po porostu Alt + 4 aby uzyskać fokus i Ctrl + Shift + Góra / Dół. Na oknie z kodem to nie działa, gdyż te skróty odpowiadają za zaznaczanie tekstu i przenoszenie linii w pionie.

Było jeszcze o mulitikursorze, który swoim zasięgiem może objąć wiele wierszy. Tu już trzeba zrobić z użyciem prawego Alt’a i myszki. Ale Idea proponuje jeszcze coś innego, a mianowicie Alt + J, które zaznacza dany tekst w pliku i tworzy multikursor. Jest jeszcze: Ctrl + Alt + Shift + J, ale jak to działa, sprawdźcie sami. Aby opuścić ten tryb edycji, trzeba wcisnąć 2 x Esc.

Warto przypomnieć o Live Templates (Ctrl + J) i Postfix templates, o których to się nie pamięta, a za pomocą których można tworzyć kod w ciekawszy sposób. Możemy również otaczać kawałek kodu różnymi konstrukcjami (np. if, try/catch, itp.) za pomocą Ctrl + Alt + T.

Warto także utworzyć własną szybka listę (Quick Lists w Settings), gdzie można wrzucić operacje, które często używamy i przypisać wywołaniu tej listy jakiś skrót klawiaturowy. Muszę sobie przygotować taką listę, z rzeczami które często potrzebuję, a nie mają domyślnego skrótu klawiaturowego.

Na koniec jeszcze pozostaje nam Ctrl + ~, które to umożliwia nam szybką zmianę, m.in. kolorów, Look and Feel jak i skrótów klawiaturowych (przykładowo na te z Eclipse’a). Może się to przydać, gdy akurat musimy zrobić Pair Programing z użytkownikiem Eclipse’a. I aby śledzić nasze postępy w niewykorzystywaniu myszki, warto się przyjrzeć statystykom z menu Help -> Productivity Guide.

A Ty jakie znasz bardziej zaawansowane i skomplikowane skróty w IntelliJ Idea? Pisz w komentarzu!

Konfitura, marmolada, dżem, powidło i spiżarnia, czyli wrażenia po confiturze 2014

2014-07-11T00:35:00.000+02:00

Rapid dev environments, Marcin Brański i Przemek Hejman
Prelegenci opowiadali o tym w jaki sposób tworzyć środowiska developerskie, a właściwie ich konfiguracje i obrazy, aby później można było je szybko odtworzyć np. na nowej maszynie. Chłopaki bardzo sprawnie i płynnie mówili, widać, że przećwiczyli to wystąpienie wcześniej. Ale niestety używali w swoich wypowiedziach sporo skrótów, które nie koniecznie musieli wszyscy znać. Pokazywali również sporo detalów, a zabrakło mi jakiegoś big picture, co do czego jest, oraz czym różnią się opisywane rozwiązania.

I tak oto było o następujących narzędziach: Packer.io, Puppet, Vagrant, Ansible, Chef, Salt, Fabric, Docker i Fig (nakładka na dockera). Niestety z powodu znikomej znajomości tematu nie jestem w stanie nic więcej tutaj napisać.

Git nie dla początkujących, Tomasz Borek
Tomek na początku przedstawił różnicę, pomiędzy surowym repozytorium (utworzonym z flagą --bare), a zwykłym repozytorium. Dalej już było ciekawiej. Prelegent pokazywał, co tak naprawdę jest potrzebne w katalogu .git, aby istniało repozytorium. I tak są to katalogi: objects i refs/heads oraz plik HEAD z zawartością (np.: „ref: refs/heads/master”). Ciekawa sztuczka, ale trwała trochę za długo i prelegent miał problemy z koordynacją, tj. czy klepać w klawiaturę, trzymać mikrofon, stać, siedzieć, czy mówić do mikrofonu stojącego na biurku (o którym później prelegent kompletnie zapomniał).

To było trochę jako ciekawostka, ale Tomek omówił również, po co są pozostałe katalogi i pliki. I tak w description jest opis projektu, który nie jest nigdzie pushowany i prawie nigdzie nie używany. W info/exclude można zignorować pewne pliki, których nie chcemy wersjonować. Przydaje się to w momencie, gdy mamy jakiś plik z ustawieniami lub hasłami, który tylko lokalnie powinien być dostępny, a z jakiś powodów nie chcemy go ignorować za pomocą .gitignore.

Jeszcze było o wewnętrznej budowie commit’a. Ogółem git’a można potraktować jak acykliczny graf skierowany. Pojedyńczy commit może wskazywać na drzewo lub inne commity, drzewo wskazuje na BLOBy lub drzewa, a w BLOBach zapisywana jest zawartość plików. Co ciekawe, to nazwy plików nie są zapisywane w BLOBie, a w drzewie. Dlatego łatwo jest wykrywać zmiany położenia plików, nawet jak częściowo zmieni się zawartość.

Było jeszcze o root-commit’cie, który jest praojcem wszystkich commit’ów. Jak jakiś inny commit nie jest w stanie osiągnąć tegoż praojca, to znaczy, że jest wiszącym commit’em i można go usunąć. Swoją drogą ciekawi mnie, skąd się biorą takie wisielce? Chyba jak nie usuwamy niezmerge'owanych branchy z flagą -D, lub jakiś pojedynczych commit'ów, to nie powinno dochodzić do takich sytuacji.

Dalej było wspomniane, że nie warto wrzucać duże pliki do repozytorium. Nawet jak te pliki tam umieścimy, a następnie usuniemy, to i tak strasznie nam to spowolni pracę z git’em. A ciężko takie coś usunąć z historii tak, aby jej nie popsuć.

Oczywiście ta prezentacja nie mogłaby się odbyć z pominięciem tematu funkcji skrótu SHA1. Organizacja NIST(National Institute of Standards and Technology), która to ogłosiła ten algorytm, obecnie wycofuje się z niego i zaleca zastąpienie go SHA3. Ale w Gitcie ta funkcja skrótu nie jest wykorzystywana w celach kryptograficznych a identyfikacyjnych, więc zagrożenie jest naprawdę niewielkie. Co prawda można wygenerować plik, który będzie nam kolidował z czymś w repozytorium, ale na to pewnie też się znajdzie obejście. Po za tym zmiana funkcji hashującej wymusiłaby zmianę protokołów git’a, a ta jest dodatkowo tak zoptymalizowana, że trafia z chache CPU.

SHA1 jest wykorzystywana w Gitcie do identyfikowania commitu i innych obiektów. Dla commitów wystarczają nam zazwyczaj pierwsze 6, lub 8 znaków tegoż skrótu. Największy otwarty znany projekt hostowany na Gicie, czyli linux kernel, potrzebuje 12 znaków do identyfikacji commit’a. Wartości te są widoczne w .git/objects i są one pogrupowane w podkatalogi, aby nie osiągnąć maksymalnego limitu ilości plików w jednym katalogu i aby można było je szybko odszukać.

Było jeszcze o różnicy w sposobie przechowywania zmian w gitcie, a w SVNie. I tak SVN przechowuje różnice w plikach. Natomiast Git przechowuje całe pliki i gdy się nic w nich nie zmienia, to aktualizuje tylko wskaźnik na aktualną wersję pliku. Nie jest to do końca prawdą, gdyż gdy repozytorium nam rośnie, to git przechowuje stare rewizje również jako różnice w pliku i dodatkowo je kompresuje. Najnowsza wersja jest zawsze przechowywana jako pełen plik, gdyż najczęściej jej potrzebujemy. Dodatkowo Git został zoptymalizowany pod względem ilości zajmowanego miejsca na dysku.

Tomek wspomniał również o komendzie add w trybie interaktywnym, gdzie można wybrać, które zmiany w danym pliku wejdą do commita. Było również o takich poleceniach jak squash (pozwala złączyć commity w jeden), rebase (modyfikuje historię) i instaweb. Ta ostatnia komenda git’a pozwala przeglądać historię repozytorium przez przeglądarkę. Niestety funkcjonalność ta, póki co, nie działa w mysysgit na Windowsie(#11).

Z rzeczy poza Gitem z prezentacji dowiedziałem się o fajnej powłoce ZSH i o nakładce na nią ze zbiorem fajnych rozszerzeń: Oh My ZSH.

Prezentacja bardzo fajna. Spodziewałem się trochę więcej o komendach typu plumbing i tego co się pod spodem dzieje, gdy wywołujemy komendy typu porcelain. Ale o tym można sobie doczytać (nawet po polsku) w książce Pro Git 9. Mechanizmy wewnętrzne w Git, a prezentacja Tomka była dobrym wstępem do tego.

Po tej prelekcji niestety zmarnowałem trochę czasu na chodzeniu po stanowiskach sponsorskich, ale mówi się trudno. Ominięte wykłady oglądnę, gdy już zostaną opublikowane.

Clean architecture - jak uporządkować architekturę Twojej aplikacji. Wnioski z projektu. Andrzej Bednarz
Prelegent opowiadał, o swoim greenfield projekcie, w którym wraz z zespołem postanowili poszukać dobrej architektury. W tym celu przejrzeli to, co wielkie autorytety tego świata mówią i piszą w tym temacie i zaczęli podążać ścieżką promowaną przez Wujka Boba, a mianowicie Clean architecture.

Podejście nie jest jakoś szczególnie nowe. Mówi o odseparowaniu GUI i baz danych od naszej logiki. Każda sensowna architektura o tym mówi. Kluczowe w czystej architekturze jest odwrócenie zależności, tj. aby nasz core aplikacji NIE był zależny od bazy danych, frameworka GUI i innych komponentów. Czyli w naszych encjach powinniśmy przechowywać przykładowo datę w formacie typowym dla daty, a nie zdeterminowanym przez bazę danych, czy ORM. Innymi słowy, musimy mieć zależności DO naszej aplikacji. Więcej powinien wyjaśnić ten rysunek ze strony Wujka Boba:

Podejście takie powoduje, że nie jesteśmy uzależnieni od używanych framework'ów i możemy je łatwo wymienić. Zyskujemy również na łatwości testowania naszej logiki biznesowej. Architektura ta wymusza jednak pewien narzut na tworzenie warstw abstrakcji, wielu DTO i konwersji między różnymi obiektami.

Prezentacja była ogółem fajna. Andrzej pokazał na przykładzie kodu, jak to wygląda u niego w projekcie. Osobiście zabrakło mi trochę porównania w kodzie, z typową architekturą 3warstwową, aby móc uświadczyć różnice. Wadą wystąpienia było patrzenie prelegenta przez plecy, na kod wyświetlany na ścianie, aby pokazywać gdzie coś jest. Jak by nie można było włączyć odpowiedniego trybu pracy z rzutnikiem.

JVM and Application Bottlenecks Troubleshooting with Simple Tools Daniel Witkowski
W tym roku było sporo wykładów na Confiturze dotyczących szybkości działania tworzonych przez nas aplikacji. Prelegent pokazał kilka prostych sztuczek, jak wyłapywać problemy w naszych aplikacjach.

Na początku trzeba ustalić nasze wymagania jakościowe, czyli SLA, czas odpowiedzi, ile requestów na sekundę musimy wytrzymać itd. Następnie prelegent odpalił przygotowaną aplikację, „klikający” w nią JMeter i obserwowaliśmy, co nam pokazuje nam JVisualVM. I gdzieś tam chyba z Thread Dump’a wyczytaliśmy, że gdzieś jest ręcznie wywoływany Garbage Collector. Oczywiście wiadomo, że to jest zła praktyka, ale można zawsze ją wyłączyć, za pomocą flagi -XX:+DisableExplicitGC.

Będąc już przy temacie GC, to warto zawsze zapisywać logi z jego działania i przeglądać za pomocą GCViewer.

Inną pożyteczną wiadomością, jaką ze sobą niesie JVisualVM, jest podgląd wątków. Można tam przykładowo sprawdzić, czy liczba wątków http (przyjmujących żądania) jest taka jak się spodziewamy. Gdy będzie tylko jeden, to nie dobrze, bo requesty będą obsługiwane sekwencyjnie.

Wykres aktywności wątków, może również pokazać nam problemy z synchronizacją i blokowaniem się. Może to świadczyć o niewłaściwym użyciu słówka synchronized (np. na metodzie doGet()) lub innych mutex’ów. Jeśli widzimy, że wiele wątków nam się blokuje, to musimy znów w Thread dumpie szukać miejsc, gdzie coś może być nie tak.

Warto też spojrzeć, czy nie mamy problemów z odczytem / zapisem na dysku. W Linuxach można to sprawdzić za pomocą top’a, a na Windowsie poprzez Process Explorer. I tak jeśli dyski nie wyrabiają, może to oznaczać, ze mamy włączony za wysoki poziom logowania. Przy tej okazji w końcu zrozumiałem zasadność takich zapisów:

if(log.isDebugEnabled()) {
     log.debug(createLogMessage());
}

Jeśli ktoś napisze jakieś długotrwające operacje w metodzie createLogMessage(), to powyższy if, spowoduje, że nie będą ona wykonywane, gdy są i tak niepotrzebne. I tu bardzo fajnie widać wyższość Scali, gdzie taki argument mógłby być wyliczany w razie potrzeby.

Ponadto jakie nie wiemy w jaki sposób jest zaimplementowane isDebugEnabled(), to lepiej odczytać tą wartość raz i trzymać gdzieś w systemie.

Na koniec była jeszcze (na szczęście krótka) reklama narzędzia Zing Vision, jako że prelegent jest przedstawicielem Azul Systems. Firma ta jest również producentem maszyny wirtualnej Zing, która wg. producenta jest lepsza od implementacji Oracla.

Working with database - still shooting yourself in the foot? Piotr Turski
Prezentacja Piotrka bardzo mi się podobała, gdyż w moim projekcie doszliśmy do prawie tych samych wniosków co prelegent, a o drobnych różnicach mogliśmy sobie porozmawiać na Spoinie.

Piotrek korzysta w swoim projekcie z dwóch baz: H2 i Oracle. Jednak H2 nie do końca sprawdzała się w testach, gdyż czasem pojawiały się błędu specyficzne dla Oracla. Przykładowo w klauzurze in nie może być więcej niż 1000 elementów. Jest to dość znany problem, ale u Piotrka wyszło to dopiero na produkcji. Innym problemem było wykorzystywanie specyficznych możliwości „wyroczni” w zakresie wyszukiwania po umlautach (üöä). H2 tego nie obsługiwało, więc nie dało się testować. Innym problemem był typ Date, który na Oracle, inaczej jak na H2, po za datą zawiera również dokładną godzinę.

Z tych powodów w projekcie prelegenta testy integracyjne puszczano na Oracle, i każdy developer miał pod ręką dla siebie takową bazę. H2 nie zostało jednak wyrzucone z projektu (mimo 3 rund rozmów na ten temat), gdyż jest lżejsze, szybsze, i tylko kilka funkcjonalności na nim nie działa.

W takim wypadku, warto mieć mechanizm czyszczenia bazy na potrzeby testów. Można to załatwić DbUnit’em, ale utrzymywanie plików z danymi jest kosztowne. Po za tym narzędzie to nie zresetuje sekwencji. Można próbować również próbować przywracać dane z backup’a, ale to również może prowadzić do innego stanu bazy. Problematyczne jest tutaj usuwanie constraint’ów i powiązanych z nim index’ów. Dlatego warto wygooglać, jak można resetować bazę na Oraclu i dopasować rozwiązanie do własnych potrzeb.

Przy takich akrobacjach, warto zadbać o proces wprowadzania zmian na bazie danych. Piotrek używał w tym celu flyway, a ja u siebie korzystałem z liquibase. Nie można wtedy niestety ręcznie robić hotfix’ów. Zaletą jest to, że do testów można wtedy budować bazę tak samo jak na produkcji.

Warto również wprowadzić mechanizm testu „produkcyjnego deploymentu”. Chodzi o to, aby zgrywać stan z produkcyjnej bazy danych (schemat i dane) i wykonać deployment aplikacji (co wymusza wykonanie migracji). Zyskujemy wtedy pewność, że nic nie powinno się posypać przy roll out’cie.

Było jeszcze trochę o testowaniu integracyjnym z bazą danych, np., gdy chcemy sprawdzić HQL’a. Można do tego zaprząc wspomnianego już DbUnit’a, ale analizowanie później czemu test się wywalił, jest czasochłonne. Lepiej przygotować dane do testów w teście. Przecież i tak mamy zapewne możliwość zapisywania naszych encji w bazie, więc możemy to wykorzystywać w setupie naszych testów. Warto również przy tej okazji skorzystać z Builder’ów.

Programowanie JEE'ish bez stresu Jakub Marchwicki
Prelegent opowiadał na początku o tym, że warto czasem zbudować jakąś aplikację, wykorzystując inne technologie, niż standardowy Spring, Hibernate i JSF. Pozwala nam to przypomnieć, co te technologie załatwiają za nas, oraz jak działają pewne rzeczy na niższym poziomie. Do tego są lekkie, a przecież nie zawsze potrzebujemy tych wszystkich kombajnów, aby skosić 2m² trawnika.

I tak Jakub pokazał kilka alternatywnych rozwiązań:

Opisywane przykłady, można sobie tutaj przejrzeć: github.com/kubamarchwicki/micro-java

Zakończenie konferencji.
Na zakończenie konferencji było jeszcze losowanie nagród, wręczanie statuetek, podziękowania dla wolontariuszy itd. Szkoda, że część konkursów była wcześniej rozwiązywana, tj. w przerwach międzywykładowych. Niszczyło to szansę potencjalnych zwycięzców. Oganizatorzy od razu zapowiedzieli, że rejestracja w przyszłym roku będzie poprawiona i nie będzie tak długiej kolejki. Trzymam za słowo.

Na koniec była jeszcze impreza: Spoina, gdzie można było jeszcze trochę pogadać, zjeść pizzę, napić się piwka i pograć w kręgle. Bardzo fajne zwieńczenie tej konferencji, na którą 1400 wejściówek rozeszło się w 2 godziny od rozpoczęcia rejestracji.

Organizatorzy namawiali jeszcze do udziału w siostrzanej konferencji tj: w Warsjawie. A ja ze swojej strony dziękuję za super konferencję i zachęcam do nowej inicjatywy dBConf.

dBConf 2014 nowa konferencja dla bazodanowców w Polsce

2014-07-10T23:46:00.000+02:00

Ruszyła właśnie nowa konferencyjna inicjatywa w Polsce, mianowicie: dBConf 2014, czyli "Bazodanowcy wszystkich środowisk łączcie się!" - tak brzmi motto konferencji. Organizatorem jest PLUG, czyli Polska Grupa Użytkowników Linuxa. Konferencja odbędzie się w dniach 24 - 26 października w Szczyrku. Rejestracja dla uczestników jest już otwarta i do końca lipca obowiązuje promocyjna cena.

A dlaczego o tym wspominam? Widzę trzy powody. Po pierwsze jest to nowa inicjatywa na naszej konferencyjnej scenie i myślę, że sporo z Was może również być zainteresowana udziałem. Wiem, że na co dzień pewnie programujecie, ale z pewnością również nie jest Wam obca tematyka baz danych. No bo przecież gdzieś trzeba składować te wszystkie dane wpisywane przez użytkowników waszych aplikacji.

Po drugie, jak pokazuje agenda, będę występował i przemawiał na tej konferencji. Opowiem trochę o Liquibase, czyli jak zarządzać zmianami w relacyjnych bazach danych. Jest to temat właściwie na styku dwóch światów, tj. kodu i perzystencji, ale organizatorom się spodobało. Chciałem o tym przemawiać na tegorocznej Confiturze, ale mój opis w C4P był za mało seksi i nie przeszedł głosowania. Po za tym w czerwcu miałem masę innych aktywności, więc i tak nie koniecznie znalazłbym czas na odpowiednie przygotowanie się.

Po trzecie i chyba najważniejsze, piszę o tej konferencji, ponieważ można jeszcze zgłaszać swoje wystąpienia, do czego Ciebie (tak Ciebie drogi czytelniku), gorąco zachęcam! Jest to na pewno dobra okazja do sprawdzenia swoich umiejętności prezenterskich, jak i podzielenia się swoją wiedzą z innymi. C4P jeszcze trwa, więc powinieneś się zgłosić! Mnie e-mail od organizatorów, którzy natrafili na mojego bloga, odpowiednio do udziału zachęcił. Czas więc i na Ciebie, nie zwlekaj, tylko zgłoś swój temat.

Relacja z 33 Degree 2014

2014-07-03T22:12:00.000+02:00

Tegoroczną konferencję 33Degree rozpocząłem od wykładu Tomka Bujoka pt. 33 things you want to do better. Pierwszy poprzedzający go keynote był nudny, a drugi gdzieś już chyba widziałem lub słyszałem.

Tomek przedstawił sporo narzędzi ze swojego toolboxa, z którymi warto się zaznajomić i w razie konieczności używać. I tak było o bibliotekach: Guava, Lombok, SLF4J, Unitils (testy jednostkowe na plikach), JUnitParams, Awaitility (do testowania wielowątkowego), Byteman (ciekawy projekt do zmiany zachowania kodu produkcyjnego w locie), Spock, grape (do skryptów shelowych w Groovy’m), Git, bash i inne. Na koniec Tomek zareklamował swój projekt: babun. Jest to skonfigurowana powłoka z preinstalowanym gitem i paroma narzędziami do przyjemniejszej pracy z shellem pod Windowsem.

Z powyższych warto sobie odświeżyć Lomboka. Kiedyś już przyglądałem się tej bibliotece, ale był wtedy problem ze wsparciem dla IntellJ Idea. Teraz wygląda na to, że jest już lepiej i doszła możliwość tworzenia builderów za pomocą adnotacji.

O kolejnej prezentacji: RESTing away from hell Jakuba Janczaka nic nie napiszę, bo było nudno i nawet nic nie zanotowałem.

Kolejna prezentacja Get Back in Control of Your SQL Lukasa Edera bardzo mi się podobała. Początkowo prelegent przedstawił wady na przykładowym kodzie takich rozwiązań jak: JDBC, EJB 2 / 3 i Hibernate. Rozwiązaniem na wszystko ma być JOOQ. Narzędzie to generuje na podstawie schematu bazy danych stałe zawierające nazwy tabel, kolumn itp. Później możemy z tego korzystać za pomocą fluent API, które jest bardzo zbliżone do SQL. Właściwie jedno i drugie czyta się tak samo, tyle że w Javie dochodzi kilka kropek i nawiasów. Jeszcze przyjemniej wygląda to w Scali. A całość jest Type Safe. Jest nawet jakiś prosty mapping na obiekty POJO. Niestety JOOQ, jest rozwiązaniem komercyjnym, dla komercyjnych baz danych.

Narzędzie spodobało mi się i chętnie bym z niego kiedyś skorzystał w projekcie. Jakby ktoś chciał obejrzeć wystąpienie (ale z GeeCON'a), jest już dostępne:

A w tak zwanym międzyczasie rozwinął się gorący wątek na Wrocław JUG (wielkie brawa za reaktywację) i padło tam jeszcze parę innych narzędzi tego typu: LIQUidFORM (ale to już trochę martwy projekt) Prevayler i Querydsl.

Kolejny wykład był dosłownie sprintem po nowościach w JEE 7. Prelegent (Arun Gupta) przeleciał w 50 min po 50 nowinkach, dotykając każdego aspektu tej technologii. Dla mnie były to jedynie zmiany kosmetyczne, żadnej nowej wielkiej rewolucji.

Następnie słuchałem prezentacji Josh Longa pt. Microservices and REST with Spring Boot. Było kodowanie na żywo, ale bardzo fajnie. Prelegent zaczął od start.spring.io i pokazał jak niewiele należy samemu dopisać, aby mieć już coś działającego. Było sporo o Richardson Maturity Model i trochę o bezpieczeństwie. W międzyczasie prelegent korzystał z ciekawej wtyczki do Chrome’a do generowania zapytań RESTowych: Advanced REST client.

Dzień drugi zaczął się znów od keynotów. Pierwszy był wypełniony tabelkami z Excela i kolorowymi Clipart’ami z Worda bez konkretnego przesłania. Typowy przykład jak nie robić prezentacji... Szybko opuściłem salę.

Drugi keynote był już lepszy. Prelegent wziął na studium przypadku pisanie latarki na iOS. Najważniejsze jest, aby przy różnych przedsięwzięciach nie tylko programistycznych, odpowiedzieć sobie na pytanie „What, Whoam and Why?”

Prelegent opowiadał dalej o aplikacjach i ich interakcji z użytkownikiem. Nasza aplikacja powinna mówić do pojedynczej osoby (używać odpowiednich form gramatycznych), bo interakcja jest między użytkownikiem a sprzętem. W ten sposób uda nam się przemówić do tłumów. Nie zmienimy w ten sposób całego świata (bo nie możemy), ale zmienimy świat dla jednej osoby, a to już jest sukces. A zmieniając rzeczywistość pojedynczych osób zmieniamy świat wielu osób.

Było jeszcze o reklamach Apple które nie mówią o tym jak świetny jest ich produkt, ale uderzają w ludzkie życie, uczucia i inne wartości. Na koniec było jeszcze o córce prelegenta, która mu zmarła, przez co wykład bardzo oddziaływał na emocje prelegenta, jak i słuchaczy.

Następnie byłem na wystąpieniu Tomka Nurkiewicza na temat OLAPowej bazy danych Saiku. Bardzo fajne narzędzie do generowania raportów, trendów, wykresów itd. Wykład był fajny, było wiele przykładów użycia… Jakbym kiedyś potrzebował, to chętnie spróbuję.

Później byłem na wykładzie Jarosława Pałki na temat Patterns for Organic Architecture. Spodziewałem się, że będzie to prezentacja bardziej techniczna, z przedstawieniem konkretnych wzorców, ale było bardzo miękko, więc się zawiodłem.

Następnie byłem na prezentacji Venkat’a Subramaniam’a, który przedstawiał Projekt Nashorn. Jest to narzędzie, które kompiluje kod JavaScript’a do bytecodeu JVM. Czyli możemy sobie po stronie serwera pisać w JavaScript. Prelegent pokazywał na żywo, jak można wywoływać JS z Javy i na odwrót.

Kolejnym slotem byłem mocno zawiedziony. Najpierw byłem na prezentacji Abdelmonaim Remani dotyczącej debuggingu. Wykład był tragiczny, jak dla studentów pierwszego roku. „Aby znaleźć bug’a trzeba najpierw zlokalizować komponent w którym on jest”. Musiałem opuścić prezentację. W innych salach również nie było lepiej, gdyż sporo ludzi wędrowało wte i wewte.

W końcu wylądowałem na prezentacji dotyczącej github’a i gerrit’a Luca Milanesio. Prelegent porównywał oba systemy i przedstawił workflow, aby push’ować do innego brancha, który po przeglądnięciu się merguje z masterem. Było również wspomniane o Git review plugin, który po wypushowaniu zmian podaje linka do review. Było również o jakimś pluginie do Jenkinsa, który wspiera Gerrita. Całość można przetestować na gerrithub.io, które się integruje z naszymi repozytoriami z GitHuba.

Następnie byłem na prezentacji JavaScript Design Patterns Pratika Patela. Było o wzorcach z JS, za pomocą których możemy osiągnąć pewne elementy, które mamy w Javie. I tak przykładowo za pomocą namespace możemy utworzyć globalny obiekt, w ramach którego możemy trzymać sporo rzeczy. Należy jednak uważać, aby nam ten twór nie urósł za bardzo, bo nie będzie on odśmiecany. Było jeszcze o Mixin module (coś na kształt Dependency Injection), publish subscribre w ramach jednego kontekstu, Command (jako Aspect) i Factory (np. w backbone).

Na koniec została jeszcze zaprezentowana ciekawa stronka: TodoMVC.com na której jest napisana jedna i ta sama aplikacja z wykorzystaniem różnych bibliotek JavaScriptowych.

Trzeciego dnia keynote’y były przesunięte na koniec dnia, więc na szczęście można było je bezboleśnie pominąć. A dzień rozpocząłem od wystąpienia Jarka Ratajskiego Doing WEB development clean way, gdyż miało być duże show i ciekawy sposób prowadzenia prezentacji. I rzeczywiście było trochę strzelania do zombie i wywoływania osób z publiczności do odpowiedzi. Było również poprawianie kodu JS na żywo, ale nie do końca ono działało, ze względu na przeskalowanie ekranu.

Co do konkretów, to Jarek pokazał, że należy korzystać ze statycznej analizy kodu, zwłaszcza w dynamicznych, słabo typowanych językach jak JS, gdzie można bardzo łatwo zrobić sobie krzywdę. Takową analizę można przeprowadzić za pomocą np. jshint. Prelegent również namawiał do korzystania z frameworków JS, takich jak angularjs i do używania pluginów w przeglądarkach wspierających development.

Było również o trendach, jak kiedyś, a jak obecnie tworzy się strony internetowe. I tak na dzień dzisiejszy królują single page applications. Z narzędzi było jeszcze o Lesscss które pomaga nam generować CSS. Wartością dodaną jest możliwość tworzenia zmiennych funkcji itp. do lepszego zarządzania tymi stylami.

Prezentacja fajna w formie, ale jak na konferencję pokroju 33 Degree, to było za dużo show, a za mało konkretów. A wiem, że Jarka na pewno stać na więcej.

Później byłem na prezentacji Jakuba Kubryńskiego na temat Spring Boot. Już wcześniej o tym na konferencji słyszałem, ale postanowiłem jeszcze raz zobaczyć. Generalnie framework (a właściwie zbiór frameworków) został pomyślany dla, ostatnio dość popularnych, microserwisów. Jest również świetną baza, dla nowych projektów, gdyż trzeba bardzo mało napisać aby wystartować z aplikacją. Dodatkowo aplikacja zawiera wbudowanego tomcata lub jetty, więc można bardzo szybko ją wystartować.

Jakub pokazał możliwości frameworka i ostatnie 15 minut był live coding. Poprzez lokalne Wi-Fi można było się połączyć ze stworzoną na szybko stroną i dzięki temu prelegent mógł pokazać satystyki jakie daje nam spring boot. Prezentacja bardzo udana.

Następnie byłem na reaktywnej Javie Tomasza Kowalczewskiego. Było o bibliotece RxJava, ale jakoś mnie nie poniosło. Sposób przemawiania do mnie nie dotarł.

Na koniec konferencji byłem chyba na najmniejszym wykładzie podczas całej imprezy. Była to prelekcja Dariusza Lukszy pt. Your own full blown Gerrit plugin. Na sali było jakieś 10 osób, i wszyscy zgromadzili się bliżej prelegenta. Ale trudno się dziwić, skoro w sali obok było show Venkata.

Darek opowiadał, jak łatwo można napisać plugin do Gerrita, który wykonuje ponowny build naszego kodu na Jenkinsie. Kod można znaleźć tutaj: gerrit-retriggerme. Darek bardzo zwinnie przełączał się pomiędzy otagowanymi wersjami swojego kodu, opowiadając przy tym co się w nim zmieniło. Temat ciekawy, jakby ktoś potrzebował.

Podsumowując konferencję było bardzo gorąco, zwłaszcza w namiocie ze stoiskami sponsorskimi. Dmuchawy i otwieranie kolejnych ścian trochę pomagało, ale to i tak lepiej niż gnieździć się w wąskich korytarzach kina. Na szczęście stanowiska sponsorskie szybko reagowały na upał i załatwiały zimne napoje w kolejnych dniach konferencji.

Fajnie też, że przygotowano aplikację na telefon z rozkładem jazdy, ale brakowało mi w niej informacji o tym, kiedy, gdzie, jaki konkurs jest rozstrzygany. Pomogłoby to jeszcze bardziej promować się sponsorom konferencji. W tym roku chyba najbardziej zaszalał Luxoft, dając (prawie) każdemu uczestnikowi tableta. Wiadomo, że nie był to jakiś super sprzęt, ale zasponsorowanie tak sporej ilości urządzeń to na pewno było nie lada wyzwanie i koszt. Choć pewnie spora większość uczestników już takie zabawki dawno posiada w swoich zasobach.

Co do poziomu wykładów, to było bardzo nierówno. Nie było chyba żadnego, który by wywrócił, lub choćby zachwiał mój dotychczasowy światopogląd. Brakowało mi również bardziej praktycznych warsztatów.

Sporo czasu zajęło mi sporządzenie tej notki, ale niełatwo jest streścić 3 dni konferencji w jeden wpis. A już na dniach zbliża się Confitura. Mam nadzieję, że relacja z tej imprezy powstanie szybciej.