<?xml version='1.0' encoding='UTF-8'?>
<rss version='2.0' xmlns:atom='http://www.w3.org/2005/Atom'>
<channel>
<atom:link href='https://pzmi.github.io/' rel='self' type='application/rss+xml'/>
<title>
pzmi
</title>
<link>
https://pzmi.github.io/
</link>
<description>
Babbling
</description>
<lastBuildDate>
Wed, 20 Jul 2016 21:27:48 +0200
</lastBuildDate>
<generator>
clj-rss
</generator>
<item>
<guid>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-3-pl/
</guid>
<link>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-3-pl/
</link>
<title>
Która to godzina? Czas na Devoxxa! [Dzień 3 / Podsumowanie]
</title>
<description>
&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/AEnmTpYsoqXvou_00lVpX716khXJr7hMQGsTFMmIpiStE_-4rAKzl-KYTouzzNMQlFcIhyn36jpBPeP-p54i9w9Tz5fQ8cPSk1Ofu4DTdCUHBLaDQyru0XxFdd6_SNoqrlMmYqpu3CiiqP9NLeQ055BIWlX6a8y0WqVOCeBbIvlOCoxAL2NI2hknyVlgkRm5puH2BzCMbWe8F2-iT4L2HRlvbAAGqVAdV6mXtMTPJcb2yFuya5zV1m99L0zWk7QJbgWuCajrSgTDTBaLTuZqXt-PViudhCKgSazzzaDT43Glarhrddyg7s2HuCBXnrySU4yaowkBK0urRMYN_b5mQ0U1mIdd0AVWfIX9evk7cCBcUtatTdF_nKGq_TLHKftubdU1uGxYClyg8O4A8gZug-bPsB5zVBu9QUFhsutuXNDlCEKfzFhEm55-8c8355gjifDS_T1jfZQ1l6Uex_XqUFKb5WrrXn0QQkVoP2cZCs7Gp0YMPdMq2Y919JCYXJAoHA8wn_Fsgu6GNbloWnPSWdfwTApO_noLWt2_NAIuQ1xCsyLCZ2Ai54R4MjdHMbLeNzggX6uGEQusGujfOoiTsrhgmyMItyc=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Wielki finał Devoxx Poland 2016.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;continuous&amp;#95;delivery&amp;#95;with&amp;#95;kubernetes&quot;&gt;&lt;/a&gt;Continuous Delivery with Kubernetes&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Adriana Vasiu - Sky&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Sky i standaryzacja Continuous Delivery. W skrócie wszystkie projekty w Sky używają Gradle (nawet te nie jvmowe) i ich in-house plugina, który za pomocą odpowiednio przygotowanych jobów w Jenkinsie tworzy pipeline Continuous Integration i środowisko testowe. Tytułowy Kubernetes jest wykorzystywany, aby uprościć ten proces - każdy korzysta z kontenerów, to nie trzeba się martwić infrastrukturą. Chociaż taka standaryzacja brzmi nie najgorzej, to coś czuję są w Sky niezadowoleni pracownicy, którzy psioczą na ten proces. Mogłem o to zapytać, ale nie zapytałem. Cóż, pierwsza prezentacja trzeciego dnia, za wcześnie na pytania.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;microservices&amp;#95;and&amp;#95;conway's&amp;#95;law&quot;&gt;&lt;/a&gt;Microservices and Conway's Law&lt;/h2&gt;&lt;p&gt;&lt;em&gt;James Lewis - ThoughtWorks&lt;/em&gt;&lt;/p&gt;&lt;p&gt;ThoughtWorks masowo produkuje tych prelegentów czy co? Wystąpieniami Neala Forda byłem zachwycony, a i James Lewis mnie nie zawiódł. Ponownie wracamy do Melvina Conwaya i jego słynnego prawa. &lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh5.googleusercontent.com/i4dWytYMAnt5FG4PIXfuxQ1mbbPR6W0ZxnDy_MTJWJJRKBp2UQ8fcicq4ZZGY1cQcTWnuQ9wSSRwjMK9Ifbb45TfVz8n6a-NYRDhx836USQ0ighAmXHfKz947RZKbzaKp6e2aVslB_XFKHWNYVD8Yyi7ua1oqH4Gj-hMqOrCtuLH6P3erWVE5-hyfpfQ7-A89vAS1KRQL6aBfGBoQT8jFMQqPNVmsG2OtdGLOLORqpz2i439GyyxTEkJeSqeU-HIua_dZYO3Q9APx2D3hRKSf7gYNHGKyxj0Lap2l9uXMuFQ9addmysQEcwi5Rwo96u8Lr-cvJPPSVSGofS2MnZNbpWGnedgfy0jxSLPv6npeWkU7nd439XUMpr18GWfRqR0Q_3TZHieifnzrOCIGimwDNPK1F4EV7ghZcSnkILL3o8jrsfEN4QAsVNVe5_qsMinQjz00_WDvM0LwgWVmLQEGcenJlJwNEjCGphjs69BgFxbpHnmX2kLNI-HZskn8nvbIS4keGmfJLa1EHuYIlUUFYs8yyDiF1SwPpMR-TsQrEJjdhiKNLPIBQ=s1280-w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;You fools!. I've told you in 1968!&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;James zauważył, że firmy działają jak gra &lt;em&gt;Snake and Ladders&lt;/em&gt;, każde zadanie wędruje między działami, często wielokrotnie. Każde takie przejście to wysłanie wiadomości do &lt;em&gt;kolejki&lt;/em&gt; innego zespołu, a każda kolejka wprowadza opóźnienia i musi być obsłużona.&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;There is nothing quite so useless as doing with great efficiency something that should not be done at all. - Peter Drucker&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Prelegent proponuje zmniejszenie opóźnienia, wyeliminowanie kolejek poprzez stworzenie kros-funkcyjnych zespołów, które zamiast tylko &lt;em&gt;build it&lt;/em&gt; powinny również &lt;em&gt;run it&lt;/em&gt;. Jednak takie podejście jest od dawna znane i Lewis przedstawił jak możemy pójść dalej. Aby jeszcze bardziej zmniejszyć liczbę kolejek między zespołami należy wszystkie osoby zaangażowane w tworzenie produktu (nie projektu!) umieścić w jednym zespole, najlepiej zlokalizowanym w jednym pokoju czy biurze. Co oznacza zespół złożony nie tylko z developerów i testerów, ale również biznes, sprzedaż, itd.&lt;/p&gt;&lt;p&gt;Na prawdę nie mam się do czego przyczepić, wystąpienie było świetne.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;odds&amp;#95;&amp;&amp;#95;ends&quot;&gt;&lt;/a&gt;oDDs &amp; enDs&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Vaughn Vernon - for{comprehension}&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Znowu to zrobiłem. Poszedłem na prezentację Vaughna Vernona, chociaż tak narzekałem na poprzednią. Vaughn mówił o rzeczach, które były już na wielu innych panelach (prawo Conwaya, big ball of mud, bezpośrednia współpraca), więc nie będę się powtarzał. &lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/weYFAPEgOVFlGdgYNrgBvG1XWOB_1nuwaFmX-8_DidE7aiGiLACFJKgOhcPHSjyyvOgHdXYS9jgpB36vUStWNGLhptSaUxxUZ5hqVa4oKZvkRulnnMq9_blqu-ovtQWRWY7rAXCIhHytcKFweuegYYJ3WkCH6dssPc2SgCDHGI9lvr6p38j_G58fK_HH6UFgcwRsZDowfQZch8TIZ7rElraiRwzTL_UyQHZTEeHBHzjN2a1YZyEaGIXszEAWdOAAHjivNmGxlJT-XWadcK3_6V6DRFZxJRJ8ZOdHT_0ORRyU669wt8_gascAGcuSvAiEu9yz-5Yke5cZ-sUlBQHNVGg7C6J4mpHJu7IiP-1fT2x8kiCikJ3J5G6rN3qa-zOOJNzWw5M-XZbE5l4Az0jC9w0iJjc-pjKWojBlUX9QzZtrEV-O3eizIzaDC8gc5-Ia8EAs3AXerPcFo-i4RoZ83eHpsvf2frkvGGSz6gWRVtHa7eWhvq-_CUXLdQefzansldwL97FN2h5Va1EDPC0q6dxSCxed0V77yzoaKy5fJk3p14HLE-oJO71IGgym9uUKIx3mP603Zpc_hQae7BswaVQADs0tV3k=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Przedstawił również Event Storming jako dobrą alternatywę dla procesów tworzenia  wymagań architektonicznych i planowania.  Jeśli chciałbyś, drogi czytelniku, poznać moją opinię na temat wystąpienia, to zapraszam do opisu dnia drugiego Devoxxa i &lt;strong&gt;Reactive Microservices with DDD and Actors&lt;/strong&gt;, odczucia dokładnie te same.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;jvm&amp;#95;and&amp;#95;docker,&amp;#95;a&amp;#95;good&amp;#95;idea?&quot;&gt;&lt;/a&gt;The JVM and Docker, a good idea?&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Christopher Batey&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Może pomysł i dobry, ale trzeba znać swoje narzędzia. Przynajmniej tyle wyniosłem z tego wystąpienia. Christopher zaprezentował kilka użytecznych, a może i niezbędnych, narzędzi do pracy z Dockerem (i nie tylko), takich jak  systemd-cgls (odpowienik *nixowego ls), systemd-cgtop (top), jcmd czy cAdvisor. Przestrzegał przed domyślnymi ustawieniami wielowątkowości. Dla przykładu Jetty czy javowy ForkJoinPool domyślnie tworzy pule wątków bazując na liczbie dostępnych rdzeni procesora, co w przypadku systemu będącego hostem dla skonteneryzowanych aplikacji może nie być najlepszym pomysłem ze względów wydajnościowych. &lt;/p&gt;&lt;p&gt;Prowadzący pokazał również kilka techniki kontroli zasobów kontenerów przy pomocy parametrów Dockera, między innymi cpu-shares, cpu-quota. Może nie jestem zbytnio obeznany w Dockerze, ale dowiedziałem się wielu ciekawych rzeczy o wydajności JVM i Dockera oraz ich połączanie. &lt;/p&gt;&lt;p&gt;Solidnie, nic dodać, nic ująć. Christopher Batey sprawiał wrażenie człowieka posiadającego sporą wiedzę i potrafiącego ją przekazać.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;climb&quot;&gt;&lt;/a&gt;The Climb&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Bruce Tate - icanmakeitbetter.com&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Kolejna pogadanka Bruce Tate. Tym razem porównał tworzenie oprogramowania do wspinaczki na Mount Everest. Stwierdził, że każdy projekt, w szczególności oparty na społeczności, potrzebuje swojego szerpy i każdy z nas powinien być jednym w jakimś projekcie. Ponownie sporo mówił o Elixirze, co mnie niezmiernie cieszy, może więcej ludzi odkryje ten interesujący język.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;pragmatic&amp;#95;architecture&quot;&gt;&lt;/a&gt;Pragmatic architecture&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Ted Neward - iTrellis&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Na koniec na scenie zagościł Ted Neward ze swoją przezabawną opowieścią o architektach. Jednak na żartach się nie skończyło. &lt;/p&gt;&lt;p&gt;Zauważył on, że architekci nie mają łatwego zadania, muszą wprowadzić zasady, wedle których developerzy będą popełniać jak najmniej błędów, &lt;em&gt;wpadać w szczeliny sukcesu&lt;/em&gt;. Przypomniał również o &lt;em&gt;best practice&lt;/em&gt; oraz o tym, że takich zasad nie można stosować wszędzie. Trzeba myśleć o tym co jest potrzebne w danej sytuacji i czy sprawdzi się w tym przypadku. &lt;/p&gt;&lt;p&gt;Według Teda, architekt powinien zdefiniować proste zasady, które odwiodą zespół developerski od podejmowania złych decyzji, a jednocześnie nie zabiją kreatywności. Architekt nie może po prostu zakończyć swojego zadania i przejść do następnego, musi musi reagować na zmiany. &lt;/p&gt;&lt;p&gt;Prelegent wspomniał również, że architekt nie powinien w pułapkę fajności, wykorzystywać każdą najnowszą technologię, ale odkrywać to co może wnieść wartość do projektu. Osobiście myślę, że ta ostatnia rada tyczy się do każdego z nas. &lt;/p&gt;&lt;pre&gt;&lt;code&gt;would&amp;#95;recommend? =&amp;gt; true
&lt;/code&gt;&lt;/pre&gt;&lt;h2&gt;&lt;a name=&quot;podsumowanie&quot;&gt;&lt;/a&gt;Podsumowanie&lt;/h2&gt;&lt;p&gt;O łał. Nie spodziewałem się, że tyle tego wyjdzie. Jeśli ktoś przebrnął przez wszystko, najszczersze kondolencje. Niemniej jednak wydaje mi się, że wyszło całkiem nieźle, biorąc pod uwagę rozmiar moich notatek (około 3x więcej niż tekst wszystkich trzech postów razem wziętych).&lt;/p&gt;&lt;p&gt;Co do konferencji, jedna z lepszych na jakiej byłem. Centrum kongresowe nadaje się świetnie do tego typu imprez, a samo audytorium jest genialne. Czasami, jak nie miałem upatrzonego żadnego panelu lub nic mnie nie zaciekawiło, szedłem tam po prostu posiedzieć. &lt;/p&gt;&lt;p&gt;Jedzenie było ok, a i kolejki były znośne. &lt;/p&gt;&lt;p&gt;Sporo stoisk wystawców, kilka konkursów, ale nic szczególnie nie przykuło moje uwagi. Swój cel osiągnąłem, a było nim zebrać jak największą ilość naklejek. Skarpetki i powerbanki jeszcze nie wyszły z konferencyjnej mody, a już wyłania się nowy FOTM - barmani. Kilka firm zatrudniło barmanów robiących kawę (całkiem dobrą) oraz smoothie (też nienajgorsze). &lt;/p&gt;&lt;p&gt;Co do wyboru prelegentów, super, przynajmniej dla mnie. Świetnie było spotkać ludzi, których czyta się książki czy śledzi blogi. &lt;/p&gt;&lt;p&gt;Podsumowując, polecam Devoxx Poland. Jeśli nadarzy się okazja wybrać się na przyszłoroczną edycję, na pewno skorzystam.&lt;/p&gt;&lt;p&gt;&lt;a href='https://goo.gl/photos/GmecMWFePBJNRm7F6'&gt;Na koniec mała galeria zdjęć z konferencji.&lt;/a&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Zobacz także &lt;a href='../2016-07-09-devoxxpl-2016-day-1-pl'&gt;Dzień 1&lt;/a&gt; oraz &lt;a href='../2016-07-09-devoxxpl-2016-day-2-pl'&gt;Dzień 2&lt;/a&gt; z tej serii postów.&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;&lt;a href='../2016-07-09-devoxxpl-2016-day-3'&gt;You can find english version of this post here&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
<author>
Patryk Żmigrodzki
</author>
<enclosure>

</enclosure>
<pubDate>
Sat, 09 Jul 2016 00:00:00 +0200
</pubDate>
</item>
<item>
<guid>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-2-pl/
</guid>
<link>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-2-pl/
</link>
<title>
Która to godzina? Czas na Devoxxa! [Dzień 2]
</title>
<description>
&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/LuSlj83fvIbvdvnTvOwSeEbEKiIwVsgJnrIRK1LvPgPqwjbX2t6jCqwXBrIlIIEPpVIwlNKnqcDfcPJO5EvY_clGBEi13n2gYmYxEgLfRT9VPqZmk3Nq5QCkI2I5ldlydJ1LhtYD9hcC9anHyMwtURJAQg6aktvwc8jJVUg21bKlIUVsBeoJnQ9EjjnFSKudZNG-U4pKL6k0MvjHE3cdUnnPs4ItXaptQ1rf1QtRJyDfTP_x4dvXIjOVVIVW-RBlJQOGC4nIE8MWSqFDOlryLCIMK39CuEXx7XLnuqz010L3lcqfJj4KzGsU1wkrxFuqTtjCZ6SDQZmF3mdsQBlzvTmgRjjajAUXSoj0Y95-18y9RXEoOslk8LHpGuBEy5DrHZnCDdPezl3IoDwbXgpbAmLyve8jcBG9KL5daP7k2yqaGkELuaXNr9q2OjHyzRUtGhU_A4kktdQWW03BSLkkDUbIYZ_U5ErSmV9leaE01Mzhq9-PuHExNVSh-ohWjfD3VchMK2_mpjQMIOf6_xzCsczdvbsbi-xbimxeUWRfM7z5VJ7ju_kKhB9TJOW7d6FGiv6-yFOhfhfjUXoLNamt4lFsZFO78P4=w980-h979-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Dzień drugi konferencji Devoxx Poland 2016.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;understanding&amp;#95;microservice&amp;#95;performance&quot;&gt;&lt;/a&gt;Understanding Microservice performance&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Rob Harrop - Skipjaq&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Gdzieś zapodziałem notatki, a kompletnie nie pamiętam o czym była ta prelekcja. Cóż, ciężki poranek.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;evolutionary&amp;#95;architecture&quot;&gt;&lt;/a&gt;Evolutionary architecture&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Neal Ford - Thoughtwork&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Kolejne wystąpienie Neala i po obejrzeniu pierwszego, tego nie mogłem opuścić. Na keynocie padło kilka słów o architekturze ewolucyjnej, lecz teraz rozwinął przedstawione wcześniej koncepty. &lt;/p&gt;&lt;p&gt;Przy projektowaniu architektury trzeba rozumieć potrzebę zmian. Prelegent nawiązał do o Dockera i jego niebywałego wpływu na projektowanie systemów komputerowych. To nie jest jednak odosobniony przypadek. środowisko programistyczne zmienia się stale, dynamicznie i nieprzewidywalne. Według Neala jest to jeden z głównych czynników uniemożliwiających długoterminowe planowanie. Zaproponował on podejście ewolucyjne, przyjmujące wsparcie dla ciągłych zmian za podstawową wartość. &lt;/p&gt;&lt;p&gt;Oczywiście nie mogło zabraknąć mikroserwisów. Nigdy nie zastanawiałem nad wymianą w swoim systemie całej warstwy persystencji, a jednak architektura warstwowa jest wciąż bardzo popularna. Neal zauważył, że pomimo wielowymiarowości takiego podejścia, gdy skupimy się na wartości biznesowej, rozproszonej po wszystkich warstwach, to jesteśmy bardzo zamknięci na zmiany. Na ten problem nie cierpią systemy oparte o mikroserwisy, gdyż każdy z nich można stosunkowo łatwo zastąpić. Ta cecha czyni z nich solidną podwalinę pod architekturę ewolucyjną.  Innym proponowanym wzorcem, który może ułatwić iteracyjne zmiany aplikacji, są feature toggle. &lt;/p&gt;&lt;p&gt;Później prelegent wspomniał że powinniśmy stosować do BASE (Basic Availability, Soft-state, Eventual Consistency) zamiast ACID (bo świat nie jest spójny, na wszystko trzeba czekać). Powtórzyło się kilka kwestii z keynote, jak zdecentralizowane zarządzanie i prawo Conwaya.  Niestety organizatorzy konferencji przeznaczyli po 50 minut na każde wystąpienie, więc prezentacja Neala została obcięta w porównaniu z &lt;a href='http://nealford.com/downloads/Evolutionary_Architecture_Keynote_by_Neal_Ford.pdf'&gt;tą wersją&lt;/a&gt;.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;reactive&amp;#95;microservices&amp;#95;with&amp;#95;ddd&amp;#95;and&amp;#95;actors&quot;&gt;&lt;/a&gt;Reactive Microservices with DDD and Actors&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Vaughn Vernon - for{comprehension}&lt;/em&gt;&lt;/p&gt;&lt;p&gt;I przyszedł czas na Vaughna Vernona, pierwszego człowieka który zrozumiał Domain Driven Design Erica Evansa i napisał od tym książkę. Na tej konferencji wszyscy lubią wspominać o &lt;em&gt;big ball of mud&lt;/em&gt;, najwyraźniej ładnie wygląda w porównaniu z mikroserwisami (a jak wiadomo te dają dodatkowe punkty w ocenie mówców). &lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/HPlJIMbkNI_mMqYtTNefAjdFXdb4d_gTImr263ccApSguJA83gwXGa-1s_vTmQ6is41o7fZQy8TtClA8gXI8tPec8FqiRjJ6NOoXcHvNk_Lok0fX0dv0QamLNwFbAiyMup4pHxBzd1bvMiKptDp_mnNLDfr2x7vVzQ2I6oqwgrjZSS_ibfpyHljzL2fzmt3SetwE__lYsjUYY_jT1ov5bCoPBwMptJpL-KSb47NyfE7SIs-FmiSwIMbmvUOVigmUKt7-9vl0ZoxJF10k3xNvtSNYaRGl8UN17gnr-fF2oBrlALvLwPh0nPWwjsFnSsIqoirPHzzHdeKju0WQKa8wEyqOz7jCpyiVJY_Xx04OHk_BlJo84Qsyr_ZXEyTt0_iAK8V4tze6xqaEy9UfTf_QnG2uP5Mdm8xEfTQzGqGPcrPMhNHojXAOs3KAnnee1LEpRBeeAQ5ecF_F-kbsd2XxT_bzWnB5OUi64ib7kTfsTDcA5zDGA79QIlKW_3g2kHH7VA3S06un4CRnnPwLIfBbUOCa6mqD5Hat2le7hWP-N_rXgj4HJTcN3xg_5s1A-Mh3z9HV2oR03wVVo5bjLY_xn3CVP3eU-kU=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Vaughn również wspominał o ACID i o tym jak kiedyś, przed erą komputerów, wszystko był &lt;em&gt;eventually consistent&lt;/em&gt;. Kilka słów o DDD w kontekście mikroserwisów i o tym, że powinny być one wielkości &lt;em&gt;bounded context&lt;/em&gt;. Vernon próbował wyjaśnić typy usług (rapids, rivers, ponds), ale wyłączyłem się w momencie jak zaczął pokazywać kod i mówić o Scali, Akka i Play Frameworku. Na tej prelekcji czułem się trochę jak na wykładzie jakieś profesora, który jest całkowicie przekonany do swoich racji i głosi swoją mądrość. Chociaż lubię aktorów i mikroserwisy, to nie kupiłem tego kazania.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;data&amp;#95;consistency:&amp;#95;analyse,&amp;#95;understand&amp;#95;and&amp;#95;decide&quot;&gt;&lt;/a&gt;Data consistency: Analyse, understand and decide&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Louis Jacomet - Terracotta/Software AG&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Byłem przekonany, że będzie to kolejna prezentacja o mikroserwisach i &lt;em&gt;eventually consistent&lt;/em&gt;, ale myliłem się! Chociaż bardziej prawdopodobne jest, że nie przeczytałem opisu.&lt;/p&gt;&lt;p&gt;Louis trochę poopowiadał o ACID i przytoczył parę definicji z Wikipedii. Zauważył, że w aplikacjach rzadko wykorzystywanych jest kilka connection pooli o różnych stopniach izolacji. Dowiedziałem się, że cache, np. w Hibernacie, też ma poziomy izolacji i dostępu (tyle człowiek używa tego szajsu, a dalej nie wie nic). Prezenter przedstawił bardzo trafne spostrzeżenie, że transakcje nie dają nam całkowitego bezpieczeństwa jeśli stosujemy się do poziomów izolacji ANSI, gdyż nieustannie są opisywane nowe anomalie w systemach transakcyjnych. &lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;functional&amp;#95;data&amp;#95;structures&amp;#95;with&amp;#95;java&amp;#95;8&quot;&gt;&lt;/a&gt;Functional data structures with Java 8&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Oleg Šelajev - ZeroTurnaround&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Chciałem zobaczyć ten panel, gdyż Olega kojarzyłem z sesji &lt;a href='http://virtualjug.com/'&gt;vJUG&lt;/a&gt;, a i sam temat przykuł moją uwagę. Na prawdę chciałbym lubić to wystąpienie, ale nie mogę. Pomimo ładnych i merytorycznych slajdów oraz wiedzy i chęci prowadzącego coś było nie tak. Wydawał on się zdenerwowany i nie trafił do publiczności. Sprawiło to, że całość sprawiała wrażenie monotonnej i nieinteresującej. &lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/Tb2HZdicv8mqs8Gs5Is99U_hqqj6YC8QhbjQuCzquCQbNFc9C0RVM_-ijLUQa3kdTh288zb9mjhb5gQBxnoRPSFWZhZ-DogaXlDlPUPd33gY4FdUckWJStLR6j411gHYSZ7z1ImFKVVazDnyNK7ua9G4U81cBWM-NySiO1AJAsDwKNanIShn1NDztWXelt_2agCOhPqiLWHHWOThWtuuP8qnOdxpRkMJt9zO7w03DrpS9o-yyulVmTcx7GCdgA22HnK5zRvecB3cD8bGTRWPpeT5-ktu78BKcHCktJlQH7JkuRSfQc_qINhHKwle6pwAlQbCwbqebXceoWyQ7chLY44wizzUeD_ZWW9xHzPAtsX6IkBb-4ot0eL9a0kQK1x2HHK3U-G3FSrSxicuMg_azohJ4XWT2I2fieOzfJqV_wT0pKL3yhYbQge2a4yKS4v953jPTk79qmAHZz-H54DIRlkw94-xro0e2-RUWcR_TfrEeGX84U64YwfqXzePWDNtiwmmGU9BJjHj2KQptpvHNgynjRQdLJUn8f7wZhbWu3pbg5JTSEejrQaw5Zqu11FdJhImTDnLmAnrEAUqAZXViSjUN786bPI=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Wracając do treści wystąpienia, Oleg przedstawił czym charakteryzują się funkcyjne struktury danych i czym różnią się od tych powszechnie znanych z zajęć na uczelni (chyba że ktoś miał funkcyjne struktury danych na zajęciach na studiach, zazdroszczę). Prelegent omówił kilka optymalizacji umożliwiających efektywne operowanie na niezmiennych strukturach oraz przedstawił w skrócie ich implementację. Moją uwagę szczególnie przykuł HAMT (Hash Array Mapped Trie).&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;how&amp;#95;to&amp;#95;create&amp;#95;a&amp;#95;new&amp;#95;jvm&amp;#95;language&amp;#95;in&amp;#95;under&amp;#95;an&amp;#95;hour&quot;&gt;&lt;/a&gt;How to Create a New JVM Language in Under an Hour&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Oleg Šelajev - ZeroTurnaround&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Ponownie Oleg i ponownie się zawiodłem, nawet opowiadał te same żarty co na poprzednim wystąpieniu. Tak na prawdę poszedłem na tę prezentację, aby zobaczyć salę numer 5, która znajduje się w podziemiach centrum kongresowego, na poziomie -2 (wygląda jak bunkier).&lt;/p&gt;&lt;p&gt;Co do samej prezentacji, był to (mniej więcej) skrót &lt;a href='http://jakubdziworski.github.io/enkel/2016/03/10/enkel_first.html'&gt;postów Jakub Dziworskiego na temat tworzenia języka Enkel&lt;/a&gt;.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;pendulum&quot;&gt;&lt;/a&gt;The Pendulum&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Bruce Tate - icanmakeitbetter.com&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Od formatek klienta przetwarzanych przez systemy w COBOL do aplikacji webowych. Bruce Tate opowiada o tym, że historia lubi się powtarzać, nawet w software developmencie. Przyjemna pogadanka, taka felietonistyczna, sam nie wiem co tu opisywać. Z pewnością Bruce bardzo lubi język Elixir (yay!).&lt;/p&gt;&lt;p&gt;I w ten sposób zakończyłem drugi, ciężki dzień. Później jeszcze odbyły krótkie prezentacje i przedstawienia produktów, ale byłem już zbyt zmęczony, aby spędzić kolejną godzinę w centrum kongresowym.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Zobacz także &lt;a href='../2016-07-09-devoxxpl-2016-day-1-pl'&gt;Dzień 1&lt;/a&gt; oraz &lt;a href='../2016-07-09-devoxxpl-2016-day-3-pl'&gt;Dzień 3&lt;/a&gt; z tej serii postów.&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;&lt;a href='../2016-07-09-devoxxpl-2016-day-2'&gt;You can find english version of this post here&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
<author>
Patryk Żmigrodzki
</author>
<enclosure>

</enclosure>
<pubDate>
Sat, 09 Jul 2016 00:00:00 +0200
</pubDate>
</item>
<item>
<guid>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-1-pl/
</guid>
<link>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-1-pl/
</link>
<title>
Która to godzina? Czas na Devoxxa! [Dzień 1]
</title>
<description>
 &lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/WWC8Jr6RIgFbDCKY0zeRi2dAVWwBwOYJAYSldUjQY75IWGbhaoVXzPOs5HHdoo4PmCIoUPAbVkoqG7pqSbLZC5JZdjCB82rbRBR6zLpUbrlQBene-msIBIR3kBlY1nDFU-E9zpQe0WvnycQ-Zp1trWLqeyCGPHOmOaCyUeoxxn3zrl10__G8KbiXf18cZFop4JJIEAglZC5rKXCyqrOn8e3j6YFDq3catcY-iLfuElhJmMkcbgcPd3_fsHOX-Ed2PCIg3X4wY69mQlCUgGgL8brhmappFcJB3bObHgu75HNN11N1dqa0_An54tOziIM24gi_-DFf9xeD717iMq8-pqBj_EmQOT-siglK0FMsFv8GP6cM0TJYnOndx4qvYtVSgu0sRYCaZaaZMLYdx82J3esL03R_ugOcNnu6cQa7vAz6pkv5IS2viRrnMkVGL7QjpBAAE-zEDCs1tDnqaAp38FuL0KBKaZ4v5qGDillFgxSTqQ-NEukh_GZQJ8gcOmnDrtsdBQzREXNShi9zXdT-YJeyqHzlR8cKyMeuR6QYkGVbJ0fSNrLhD3FZb1aJFO5BOKAvfQrd3kMXtaEt3HqbtJWTdRJ8WZ8=w1158-h1008-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Konferencja konferencja i po konferencji. W tym cyklu postów postaram się przybliżyć co działo się na &lt;a href='http://devoxx.pl'&gt;Devoxx Poland 2016&lt;/a&gt;, czego ciekawego mogliśmy się dowiedzieć i przedstawię kilka subiektywnych opinii na temat wystąpień.&lt;br /&gt; Tegoroczny Devoxx Poland odbył się w dniach 22-24.06.2016, podobnie rok temu, na terenie Centrum Kongresowego ICE w Krakowie.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;why&amp;#95;does&amp;#95;yesterday's&amp;#95;best&amp;#95;practice&amp;#95;become&amp;#95;tomorrow's&amp;#95;antipattern?&quot;&gt;&lt;/a&gt;Why does Yesterday's Best Practice Become Tomorrow's Antipattern?&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Neal Ford - ThoughtWorks&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Keynote Neala Forda w nieludzko szybkim tempie. Jak sam prezenter pisze na swoim blogu, jego keynote'y są ogólne i poruszają wiele tematów, aby trafić do jak najszerszej publiczności. Ta prezentacja nie była wyjątkiem. Prowadzący przemknął przez kilka historycznych anty-wzorców i ich wpływ na późniejsze rozwiązania, np. Continuous Integration uznawano za zły pomysł, gdyż faza integracji kojarzyła się ze żmudnym i bolesnym procesem. Neal na tej historii nie poprzestał i wspomniał o niedawnej dramie z Leftpadem, co podsumował cytatem swojego kolegi z ThoughtWorks:&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Dependency management will be our &quot;Goto Considered Harmfil&quot; moment&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Jeśli mówimy o cytatach, to jako jedną z przyczyn powstawania anty-wzorców prelegent zobrazował słowami George Santayana:&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Those who cannot remember the past are condemned to repeat it.&lt;/em&gt;&lt;br /&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&lt;strong&gt;Transpiling&lt;/strong&gt;, powszechnie używany przy tworzeniu javascriptowych frontendu, nie jest niczym innym jak, od dawna uznawaną za anty-wzorzec, generacją kodu.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;EDIT:&lt;/strong&gt; Otrzymałem komentarz, że generacja kodu nie jest anty-wzorcem, a chodziło tu o wymyślanie wszystkiego na nowo. Cóż mogłem źle zrozumieć przekaz (albo po prostu nie lubię generowanego kodu).&lt;/p&gt;&lt;p&gt;Na prezentacji nie zabrakło prawa Conwaya, wypominania, ze developerzy szukają wrażeń w pracy oraz przypomnienia, że powinniśmy wybierać biblioteki zamiast frameworków. Neal przytoczył także kolejne prawo (które sam sformułował?), &lt;a href='http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html'&gt;&lt;em&gt;prawo Dietzler'a&lt;/em&gt;&lt;/a&gt;. 2016 i wystąpienie na konferencji bez wspomnienia o mikroserwisach?! No oczywiście że nie mogło i ich zabraknąć. Przy tej okazji Neal nawiązał do  architektury ewolucyjnej, czyli tematu jego kolejnej prezentacji. &lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/EVXcbWooKr7-_Qswgw204hQWwMcdEd7Rbicvt3z2yeKkB7VVPhvcaRbRTUWzEnH0UDmKtQZJE6Dj-58nnEt0vKReaZ6cIDqCaxSLOaeer8KiKW58LZG8REsbdgceLYRt5DRdaETAqYWlFTlL8XlnF7MQ7-y6G9MSbyXK0XvTK6rEEzh_v3qY4T8Ihw6mIdlSNo5iahG-7IXsPfViqIO_sMXS1XhmCe0B2S4eXubjSMRwnci_kyV-QTwFnL68QnWAmYPwQtayCSHKWxMf4qYEuwxDFbJcYfmo7pjQcgv4fSRMTJ6NvSfkoAidGZWBdnrtj7j7OernR6cXTUtnIcfQetplQIcIDL6Rxw3CE_pwc59piUkKdiBk23SIxl1rBMMyRqe5noqR0RZe-rorR-I07zOuWqPZ2Hi1t9d5P_HjeN7qBQwojP8cpCtyO_ej6LvexqiB7taVfDnfedCPrxJacx01h02SoMXFAEjfaPVgceFkyibJXlD0XrlOKwFAl3ZFyr9q5adnQiaBNVZmp6CGnOGi1hHblK93z5qmNwmCXDFALhWYk4GU-ZbDiFGY0kY6ix6LLlm7LAfV-MEes1YJfmXSOMiOzAY=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Ogólnie to keynote był przedsmakiem wszystkiego co mogliśmy doświadczyć przez kolejne trzech dni Devoxxa, świetnie przedstawione dzięki niebywałym umiejętnościom prezenterskim Neala Forda. Jeśli ktoś ma okazję jakiegokolwiek posłuchać wystąpienia tego pana, szczerze polecam.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;good&amp;#95;monolith&quot;&gt;&lt;/a&gt;The Good Monolith&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Łukasz Szydło - Bottega IT Solutions&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Dobry monolit czyli jak skutecznie tworzyć aplikacje, które nie są mikroserwisami (coś strasznego). Prosty przepis? Projektować tak jak mikroserwisy, ale deployować jako pojedynczą usługę. Przynajmniej tak próbował przekonać nas Łukasz Szydło porównując systemy monolityczne do wielkich budowli, a mikroserwisowe do miasteczek skupiających mniejsze budynki. Dobry monolit ma być miastem pod wielką kopułą. Prowadzący, nawiązując do Domain Driven Design, wspomniał o Encjach i Bounded Context. Duży nacisk położył na problem z tworzeniem przeładowanych modeli, gdzie jeden obiekt jest wykorzystywany w różnych kontekstach. Przytaczając prosty przykład: człowiek jest bardzo skomplikowanym obiektem, ale kiedy znajduje się na basenie - jest pływakiem, na strzelnicy - strzelcem, itd.&lt;/p&gt;&lt;p&gt;Według mówcy, przewaga dobrego monolitu nad mikroserwisami to mniejsze skomplikowanie, głównie komunikacyjne. Jednak jeśli w przyszłości takie podejście okaże się niewystarczające, to z dobrze zamodelowaną dziedziną i luźno związanymi komponentami, przepisanie istniejącego systemu na architekturę mikroserwisową będzie mniejszym wyzwaniem niż stworzenie wszystkiego od podstaw. &lt;/p&gt;&lt;p&gt;Wystąpienie niezbyt przeładowane informacjami, duża zmiana po poprzednim wystąpieniu. Można było spokojnie przeglądać skrzynkę mailową i nadążać za prelegentem. &lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;hotspot&amp;#95;&amp;&amp;#95;aot&quot;&gt;&lt;/a&gt;Hotspot &amp; AOT&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Dmitry Chuyko - Oracle&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Co to jest AOT i dlaczego powinno nas obchodzić. Dmitry przedstawiał nowe eksperymenty Oracle nad kompilatorem Javy. Wyjaśnił pokrótce jak działa Hotspot VM i czym od niego różni się GraalVM - nowy kompilator Javy napisany w Javie.  Plus AOT jest taki, że JIT nie zajmuje zasobów w trakcie działania systemu oraz dostajemy przewidywalne wyniki wydajnościowe.  Slajdy były słabe i w większości przypadków mogłoby ich w ogóle nie być, a sam Dmitry raczej nie może się poszczycić mocnymi umiejętnościami oratorskimi, a szkoda.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;successful&amp;#95;startup&amp;#95;is&amp;#95;not&amp;#95;enough.&amp;#95;you&amp;#95;must&amp;#95;scale&amp;#95;technology&amp;#95;to&amp;#95;enterprise&amp;#95;while&amp;#95;maintaining&amp;#95;your&amp;#95;startup&amp;#95;creativity.&quot;&gt;&lt;/a&gt;Successful startup is NOT enough. You must scale technology to ENTERPRISE while maintaining your startup creativity.&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Marek Grochowski, Cezary Zminkowski - Sabre&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Panel sponsorski Sabre. Chyba najgorszy na jakim byłem na tej konferencji. Panowie opowiadali o ich produkcje, TripCase, i o drodze jaką przebył. Projekt powstał i był rozwijany przez mniej więcej 5 lat, przy czym wymierny sukces odniósł w ostatnim roku. Zaraz, zaraz! To nie miało być o osiąganiu startupowego sukcesu? Dowiedziałem się, że 90% startupów upada, bo robią to źle. A jak dobrze robić? No trzeba stworzyć idealną architekturę, oszacować teoretyczną złożoność naszych algorytmów, monitorowaćlogowaćanalizowaćtrendyblablablab........&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;antifragile&amp;#95;architectures&quot;&gt;&lt;/a&gt;Antifragile Architectures&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Matt Stine - Pivotal&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Jeśli rzeczy wrażliwe (fragile) niszczą się pod wpływem stresu, to antifragile w tej samej sytuacji powinny wzmacniać się. Co więcej, antifragile jeśli nie są poddawane ciągłemu stresowi, słabną.&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/k4MfoJ1CudGzSfia0xzz8_4dm7xuU4Hh8CuwRPPaRvsyQzl10Cx5Bk5LLClvOPWv2egTzt25qVOz5N_Zcl2mdfrjHrOdqtDSbWeO56uzREk_kXH415YPm2fwPAeHO6RvGAG0WGpli-yPkTyIlN4MordlPWFhQhMr8_ofjWwAYNQJH1Mz68gco9nDLE7pM_l-L3tVrv1CXLOd3b73HaQhRvVouI8RwdsYdHOJwt2FAAT4kq2lBiipNmKuN94YqJTE4-pmoRHfUtrmQkYbMHuogtfzUqC4V7b9BXpzaWAVWaLS7Sl4-Mh-37N0-4XSt3rqXjhm-QzzNBNBJese3D4gs4wUcjQU9_X0n8orQ4lWmbhvTyhM0IPpU8JKC_4XSjRaYtIsL2JUJCQ4rreySKdLCD78yhqO9h2Xh2UnWdReX5xHA1F65KhYzsufoHHc4D4d2E6AeG0T6m-RYperdbrbgWov6ov4FOSUKg8AjKweKOpV_VYmp64TPzpN-xXrt7H-c9rsHi_FkItsw-2ZyGYTDlc8qu1dzxBOtmI7czSbvgFHLqn3LwfmPnXFWjU5FVwUG81_FmBOtZtsjPhGrfnEvalzpNUUNy8=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Tak antifragile opisał Matt Stine w swoim wystąpieniu. Twierdzi on, że systemy informatyczne muszą być antifragile, aby móc sprostać ciągłym zmianą. Konieczność zmian zmotywował istnieniem &lt;a href='https://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution'&gt;prawa Lehmana o ewolucji oprogramowania&lt;/a&gt;. &lt;/p&gt;&lt;p&gt;Według prelegenta systemy failsafe powinny być bezusterkowe oraz samodiagnozujące. Jako przykład podał produkty Netflixa oraz stworzone przez nich narzędzia, &lt;a href='https://github.com/Netflix/Hystrix'&gt;Hystrix&lt;/a&gt; i &lt;a href='https://github.com/Netflix/SimianArmy'&gt;Simian Army&lt;/a&gt;, zapewniające takie cechy. Szczególnie podkreślił rolę Chaos Monkey, gdyż wstrzykiwanie defektów zmusza do ciągłego myślenia o błędach i zapobieganiu nim.&lt;/p&gt;&lt;p&gt;Prelekcja całkiem ciekawa, ale jak dla mnie za dużo filozofii o ultrawielkich systemach (wg mnie trochę zbyt odległy temat).&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;jvm&amp;#95;dive&amp;#95;for&amp;#95;mere&amp;#95;mortals&quot;&gt;&lt;/a&gt;JVM Dive for mere mortals&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Jakub Kubrynski - Devskiller&lt;/em&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;JVM is just an application&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Jakub przedstawił JVM jako zwykły program, który można poznać i zrozumieć (co więcej, można zajrzeć w kod :)) Omówił również cykl życia kodu w Javie, od kodu źródłowego, przez bytecode, JIT, aż do kodu natywnego. Podał kilka technik wykorzystywanych przez JIT do optymalizacji, zaznaczając wartość tej wiedzy. W skrócie, znając je wiemy czego się spodziewać po optymalizacji i nie wprowadzać tych zmian samemu, aby niepotrzebnie nie zmniejszać czytelności kodu. Solidnie i przyjemnie.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;how&amp;#95;to&amp;#95;survive&amp;#95;and&amp;#95;thrive&amp;#95;in&amp;#95;a&amp;#95;bigco&quot;&gt;&lt;/a&gt;How to survive and thrive in a BigCo&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Michael Coté - Pivotal&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Jesteśmy śmieciarzami, nie kowbojami, ale bez kowbojów świat nie byłby taki zły jak bez śmieciarzy. &lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/DZA-l4VKHdQTU6nbOUCHyTbYdxo9jBcSB1fXZ7MYcyv2xJKKGbA_xn6DjGWt5cEv7yI4IQRhF30kf8q9Z-nP_kCCyiLR5Kv6xAFPzXIXsmfKzPU9b4vUEjg4kjuqnkt8rYv70ukjwh82r5NDk5XCLeeGeC4s0yNTOXYS0M9DW2bELMc9eL2aCtIvcHmiOZ2gyM_VqZnq5-5D8gMB265kcz2YSVG_PHfN1uisBLcR-kk9rMuFfTEXxUOsjfShXdklTqeQBydsvZhDBFuPuAo8VVWSZpLCaqEkG6WGl7pwOFDR47vC2TCbxbsCrMSmhIGamODehIPVaLx9PTRTB397088ACCYBujOIHv6yjnnjlL6SbDyt8RIvGvaCYQXeFGb9PDT6-9sayCHgAhAm1T7RVHYbSUCzm63ayxaVq92osBWBo32SwVJuN9OYvJt32Kim2sfr3KHx4hj1pYS4nNiEeTjlvC_PdpzorMSTM9zvOJwrRwo1bQ0IroUwzFpNxJnVVP8whSQKr_l8tw_vwIQC_KGVXIUCjQzPDQLXkyfnMO-kHieK6z_Zkpzsx5KwkdJLAMLnKQaH11UAEhS-QR-kkDtFmIu0AvE=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Taka myśl z ostatniej prezentację dnia pierwszego, jak przetrwać w korpo.  Pierwszą radą Michaela jest znalezienie w korporacji mentora, który pomoże nam odnaleźć się w firmie. A jeśli nie chcemy zostać przeciętnymi klepaczami kodu, powinniśmy znaleźć czempiona mogącego angażować nas w rozwijające projekty. &lt;/p&gt;&lt;p&gt;Prelegent radzi również, aby wkopywać się w dodatkową pracę, poza naszym zakresem obowiązków, nie dać się zadaniowym wampirom. Podobno dobrze sprawdza się poproszenie o wprowadzenie do zadania, wybranie konkretnych slajdów z otrzymanej prezentacji. Jeśli poświęcą swój czas, może im jednak zależeć na współpracy, nie na wykorzystywaniu innych.&lt;/p&gt;&lt;p&gt;Michael poruszył również kwestię wprowadzania zmian korporacji, zaznaczając że nie jest do prosta sprawa. Potrzeba wielkiego nakład pracy, aby naprawić ogromną organizację. Najlepiej pracować nad wprowadzaniem zmian czy nowych projektów w ukryciu i ujawnić się dopiero po osiągnięciu sukcesu.&lt;/p&gt;&lt;p&gt;Poza kilkoma poradami co do tworzenia prezentacji, które jak wiadomo są podwaliną każdej korporacji, Michael podsumował swoje wystąpienie dwoma stwierdzeniami (mniej więcej coś takiego):&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Największą konkurencją jest status quo&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Pracuj najmniej jak możesz&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Jako korposzczurowi, trudno mi się nie zgodzić z jego spostrzeżeniami :)&lt;/p&gt;&lt;p&gt;Wyszła niezła ściana tekstu. Jednak to był najbardziej owocny dzień konferencji i obiecuję, że relacje z kolejnych będą krótsze.&lt;br /&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Zobacz także &lt;a href='../2016-07-09-devoxxpl-2016-day-2-pl'&gt;Dzień 2&lt;/a&gt; oraz &lt;a href='../2016-07-09-devoxxpl-2016-day-3-pl'&gt;Dzień 3&lt;/a&gt; z tej serii postów.&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;&lt;a href='../2016-07-09-devoxxpl-2016-day-1'&gt;You can find english version of this post here&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
<author>
Patryk Żmigrodzki
</author>
<enclosure>

</enclosure>
<pubDate>
Sat, 09 Jul 2016 00:00:00 +0200
</pubDate>
</item>
<item>
<guid>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-2/
</guid>
<link>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-2/
</link>
<title>
What time is it? It's Devoxx time! [Day 2]
</title>
<description>
&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/LuSlj83fvIbvdvnTvOwSeEbEKiIwVsgJnrIRK1LvPgPqwjbX2t6jCqwXBrIlIIEPpVIwlNKnqcDfcPJO5EvY_clGBEi13n2gYmYxEgLfRT9VPqZmk3Nq5QCkI2I5ldlydJ1LhtYD9hcC9anHyMwtURJAQg6aktvwc8jJVUg21bKlIUVsBeoJnQ9EjjnFSKudZNG-U4pKL6k0MvjHE3cdUnnPs4ItXaptQ1rf1QtRJyDfTP_x4dvXIjOVVIVW-RBlJQOGC4nIE8MWSqFDOlryLCIMK39CuEXx7XLnuqz010L3lcqfJj4KzGsU1wkrxFuqTtjCZ6SDQZmF3mdsQBlzvTmgRjjajAUXSoj0Y95-18y9RXEoOslk8LHpGuBEy5DrHZnCDdPezl3IoDwbXgpbAmLyve8jcBG9KL5daP7k2yqaGkELuaXNr9q2OjHyzRUtGhU_A4kktdQWW03BSLkkDUbIYZ_U5ErSmV9leaE01Mzhq9-PuHExNVSh-ohWjfD3VchMK2_mpjQMIOf6_xzCsczdvbsbi-xbimxeUWRfM7z5VJ7ju_kKhB9TJOW7d6FGiv6-yFOhfhfjUXoLNamt4lFsZFO78P4=w980-h979-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Second day of Devoxx Poland 2016 conference.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;understanding&amp;#95;microservice&amp;#95;performance&quot;&gt;&lt;/a&gt;Understanding Microservice performance&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Rob Harrop - Skipjaq&lt;/em&gt;&lt;/p&gt;&lt;p&gt;I've lost my notes and can't remember anything from this lecture. Well, tough morning.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;evolutionary&amp;#95;architecture&quot;&gt;&lt;/a&gt;Evolutionary architecture&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Neal Ford - Thoughtwork&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Second appearance of Neal and after the first one I couldn't miss this one. He expanded ideas he mentioned during his keynote.&lt;/p&gt;&lt;p&gt;When you design your architecture you have to understand the need of change. Lecturer referred to Docker's unbelievable influence on systems architecture. This isn't just an individual case. World of software development is changing constantly, dynamically and incalculably. According to Neal this is one of the main reasons why long term planning is impossible. He proposed an evolutionary approach which primary value is a support for incremental changes.&lt;/p&gt;&lt;p&gt;Of course microservices are still on the top and we also had something about them here. I've never thought about exchanging the whole persistent layer of any software nonetheless layered architecture is still crazy popular. Neal noticed that even though this approach can have multiple dimensions of possible change when we focus on business value smeared all across the system the reality is we are closed for any change. This problem does not affect microservice based systems as they are quite easily replaceable. This trait makes solid base for the evolutionary architecture. Another proposed pattern that could facilitate iterative changes are feature toggles.&lt;/p&gt;&lt;p&gt;Later lecturer mentioned that we should prefer BASE (Basic Availability, Soft-state, Eventual Consistency) over ACID (because world isn't consistent and we are constantly waiting for everything to set). There were also some repeated stuff from keynote like central governance and Conway's Law. Unfortunately organizers assumed that every talk should lat 50 minutes so Neal's one got shortened in comparison to &lt;a href='http://nealford.com/downloads/Evolutionary_Architecture_Keynote_by_Neal_Ford.pdf'&gt;this version&lt;/a&gt;.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;reactive&amp;#95;microservices&amp;#95;with&amp;#95;ddd&amp;#95;and&amp;#95;actors&quot;&gt;&lt;/a&gt;Reactive Microservices with DDD and Actors&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Vaughn Vernon - for{comprehension}&lt;/em&gt;&lt;/p&gt;&lt;p&gt;And now's the time for Vaughn Vernor, first man who understood Eric Evan's Domain Driven Design and wrote a book about it. During the conference everyone likes to mention &lt;em&gt;big ball of mud&lt;/em&gt;, apparently it looks nice beside microservices (and you get additional points if you mention them).&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/HPlJIMbkNI_mMqYtTNefAjdFXdb4d_gTImr263ccApSguJA83gwXGa-1s_vTmQ6is41o7fZQy8TtClA8gXI8tPec8FqiRjJ6NOoXcHvNk_Lok0fX0dv0QamLNwFbAiyMup4pHxBzd1bvMiKptDp_mnNLDfr2x7vVzQ2I6oqwgrjZSS_ibfpyHljzL2fzmt3SetwE__lYsjUYY_jT1ov5bCoPBwMptJpL-KSb47NyfE7SIs-FmiSwIMbmvUOVigmUKt7-9vl0ZoxJF10k3xNvtSNYaRGl8UN17gnr-fF2oBrlALvLwPh0nPWwjsFnSsIqoirPHzzHdeKju0WQKa8wEyqOz7jCpyiVJY_Xx04OHk_BlJo84Qsyr_ZXEyTt0_iAK8V4tze6xqaEy9UfTf_QnG2uP5Mdm8xEfTQzGqGPcrPMhNHojXAOs3KAnnee1LEpRBeeAQ5ecF_F-kbsd2XxT_bzWnB5OUi64ib7kTfsTDcA5zDGA79QIlKW_3g2kHH7VA3S06un4CRnnPwLIfBbUOCa6mqD5Hat2le7hWP-N_rXgj4HJTcN3xg_5s1A-Mh3z9HV2oR03wVVo5bjLY_xn3CVP3eU-kU=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Vaughn also mentioned ACID and that before the computers everything was &lt;em&gt;eventually consistent&lt;/em&gt;. A few words about DDD in a context (wink wink) of microservices and that they should be the size of  &lt;em&gt;bounded context&lt;/em&gt;. Vernon tried to explain types of microservices (rapids, rivers, ponds), but I drifted away in the moment when he started showing code, taking about Scala, Akka and Play Framework. During this lecture I felt like at the university with professor that is completely devoted to his believes and preaches his wisdom. I like actors and microservices but this preach hasn't reached me.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;data&amp;#95;consistency:&amp;#95;analyse,&amp;#95;understand&amp;#95;and&amp;#95;decide&quot;&gt;&lt;/a&gt;Data consistency: Analyse, understand and decide&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Louis Jacomet - Terracotta/Software AG&lt;/em&gt;&lt;/p&gt;&lt;p&gt;I was sure I'm going to another talk about microservices and eventual consistency but I couldn't have been more wrong! Well, there's a possibility that I've never read the description.&lt;/p&gt;&lt;p&gt;Louis talked a bit about ACID and cited some Wikipedia definitions. He notet that applications rarely take advantage of multiple connection pools with distinct isolation levels. I had no idea that cache, for example in Hibernate, could utilize isolation level itself (you use this crap every day and still know nothing). Lecturer brought up essential remark that transactions won't give us certainty if we employ ANSI defined isolation levels as anomalies in relational systems are discovered every day.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;functional&amp;#95;data&amp;#95;structures&amp;#95;with&amp;#95;java&amp;#95;8&quot;&gt;&lt;/a&gt;Functional data structures with Java 8&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Oleg Šelajev - ZeroTurnaround&lt;/em&gt;&lt;/p&gt;&lt;p&gt;I wanted to check this panel as I recognized Oleg from &lt;a href='http://virtualjug.com/'&gt;vJUG&lt;/a&gt; sessions and even the topic grabbed my attention. I really really want to like this talk but I simply can't. Despite nice and substantive slides, lecturers wisdom and best will, something was wrong. He seem a little bit nervous and not really well-received. Those issues gave the feeling of tediousness and dullness.&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/Tb2HZdicv8mqs8Gs5Is99U_hqqj6YC8QhbjQuCzquCQbNFc9C0RVM_-ijLUQa3kdTh288zb9mjhb5gQBxnoRPSFWZhZ-DogaXlDlPUPd33gY4FdUckWJStLR6j411gHYSZ7z1ImFKVVazDnyNK7ua9G4U81cBWM-NySiO1AJAsDwKNanIShn1NDztWXelt_2agCOhPqiLWHHWOThWtuuP8qnOdxpRkMJt9zO7w03DrpS9o-yyulVmTcx7GCdgA22HnK5zRvecB3cD8bGTRWPpeT5-ktu78BKcHCktJlQH7JkuRSfQc_qINhHKwle6pwAlQbCwbqebXceoWyQ7chLY44wizzUeD_ZWW9xHzPAtsX6IkBb-4ot0eL9a0kQK1x2HHK3U-G3FSrSxicuMg_azohJ4XWT2I2fieOzfJqV_wT0pKL3yhYbQge2a4yKS4v953jPTk79qmAHZz-H54DIRlkw94-xro0e2-RUWcR_TfrEeGX84U64YwfqXzePWDNtiwmmGU9BJjHj2KQptpvHNgynjRQdLJUn8f7wZhbWu3pbg5JTSEejrQaw5Zqu11FdJhImTDnLmAnrEAUqAZXViSjUN786bPI=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Oleg showed differences between functional data structures and those commonly known for example from university (envy those who were taught functional data structures in school). Speaker described few optimizations which enable effective operations on immutable structures and also some of their implementations. I got really interested in HAMT (Hash Array Mapped Trie).&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;how&amp;#95;to&amp;#95;create&amp;#95;a&amp;#95;new&amp;#95;jvm&amp;#95;language&amp;#95;in&amp;#95;under&amp;#95;an&amp;#95;hour&quot;&gt;&lt;/a&gt;How to Create a New JVM Language in Under an Hour&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Oleg Šelajev - ZeroTurnaround&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Again Oleg's talk and again a letdown, even jokes were the same. To be honest I just wanted to see room number 5 which is located underground, on a level -2 (it looks like some kind of a bunker).&lt;/p&gt;&lt;p&gt;The presentation was more or less summary of &lt;a href='http://jakubdziworski.github.io/enkel/2016/03/10/enkel_first.html'&gt;Jakub Dziworski's blog about creation of Enkel programming language&lt;/a&gt;.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;pendulum&quot;&gt;&lt;/a&gt;The Pendulum&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Bruce Tate - icanmakeitbetter.com&lt;/em&gt;&lt;/p&gt;&lt;p&gt;From client forms processed by systems written in COBOL to web applications. Bruce Tate tells a tale of history that repeats, in software development. Pleasant talk, felt like a casual column in your favorite magazine. Bruce for sure likes Elixir language (yay!).&lt;/p&gt;&lt;p&gt;And thats how I finished day two. There were some other short talks and product showcases but I was so tired that I couldn't stand another hour there.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Check out &lt;a href='../2016-07-09-devoxxpl-2016-day-1'&gt;Day 1&lt;/a&gt; and &lt;a href='../2016-07-09-devoxxpl-2016-day-3'&gt;Day 3&lt;/a&gt; of this series.&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;&lt;a href='../2016-07-09-devoxxpl-2016-day&amp;ndash;pl'&gt;Tutaj możesz znaleźć wersję polską tego posta&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
<author>
Patryk Żmigrodzki
</author>
<enclosure>

</enclosure>
<pubDate>
Sat, 09 Jul 2016 00:00:00 +0200
</pubDate>
</item>
<item>
<guid>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-3/
</guid>
<link>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-3/
</link>
<title>
What time is it? It's Devoxx time! [Day 3 / Summary]
</title>
<description>
&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/AEnmTpYsoqXvou_00lVpX716khXJr7hMQGsTFMmIpiStE_-4rAKzl-KYTouzzNMQlFcIhyn36jpBPeP-p54i9w9Tz5fQ8cPSk1Ofu4DTdCUHBLaDQyru0XxFdd6_SNoqrlMmYqpu3CiiqP9NLeQ055BIWlX6a8y0WqVOCeBbIvlOCoxAL2NI2hknyVlgkRm5puH2BzCMbWe8F2-iT4L2HRlvbAAGqVAdV6mXtMTPJcb2yFuya5zV1m99L0zWk7QJbgWuCajrSgTDTBaLTuZqXt-PViudhCKgSazzzaDT43Glarhrddyg7s2HuCBXnrySU4yaowkBK0urRMYN_b5mQ0U1mIdd0AVWfIX9evk7cCBcUtatTdF_nKGq_TLHKftubdU1uGxYClyg8O4A8gZug-bPsB5zVBu9QUFhsutuXNDlCEKfzFhEm55-8c8355gjifDS_T1jfZQ1l6Uex_XqUFKb5WrrXn0QQkVoP2cZCs7Gp0YMPdMq2Y919JCYXJAoHA8wn_Fsgu6GNbloWnPSWdfwTApO_noLWt2_NAIuQ1xCsyLCZ2Ai54R4MjdHMbLeNzggX6uGEQusGujfOoiTsrhgmyMItyc=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Great final of Devoxx Poland 2016 conference.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;continuous&amp;#95;delivery&amp;#95;with&amp;#95;kubernetes&quot;&gt;&lt;/a&gt;Continuous Delivery with Kubernetes&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Adriana Vasiu - Sky&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Sky and their standardization of Continuous Delivery pipeline. In short, all their projects use Gradle (even non jvm ones) and some in house plugin which utilizes generic Jenkins job to create whole CI pipeline with testing and showcase environments. Said Kubernetes is used to simplify this process - when everything uses containers infrastructure isn't your concern. Despite this standardization sounds promising I think there are some engineers mad at all of this. I could have asked about this but I haven't. What can you do, that was the first talk of the day, too early for questions if you ask me.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;microservices&amp;#95;and&amp;#95;conway's&amp;#95;law&quot;&gt;&lt;/a&gt;Microservices and Conway's Law&lt;/h2&gt;&lt;p&gt;&lt;em&gt;James Lewis - ThoughtWorks&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Are ThoughtWorks mass producing those speakers or what? I was mesmerized by Neal Ford's presentations and James Lewis wasn't a letdown. Again we are taking dive into the world of Melvin Conway and his famous law.&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh5.googleusercontent.com/i4dWytYMAnt5FG4PIXfuxQ1mbbPR6W0ZxnDy_MTJWJJRKBp2UQ8fcicq4ZZGY1cQcTWnuQ9wSSRwjMK9Ifbb45TfVz8n6a-NYRDhx836USQ0ighAmXHfKz947RZKbzaKp6e2aVslB_XFKHWNYVD8Yyi7ua1oqH4Gj-hMqOrCtuLH6P3erWVE5-hyfpfQ7-A89vAS1KRQL6aBfGBoQT8jFMQqPNVmsG2OtdGLOLORqpz2i439GyyxTEkJeSqeU-HIua_dZYO3Q9APx2D3hRKSf7gYNHGKyxj0Lap2l9uXMuFQ9addmysQEcwi5Rwo96u8Lr-cvJPPSVSGofS2MnZNbpWGnedgfy0jxSLPv6npeWkU7nd439XUMpr18GWfRqR0Q_3TZHieifnzrOCIGimwDNPK1F4EV7ghZcSnkILL3o8jrsfEN4QAsVNVe5_qsMinQjz00_WDvM0LwgWVmLQEGcenJlJwNEjCGphjs69BgFxbpHnmX2kLNI-HZskn8nvbIS4keGmfJLa1EHuYIlUUFYs8yyDiF1SwPpMR-TsQrEJjdhiKNLPIBQ=s1280-w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;You fools!. I've told you in 1968!&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;James noticed that companies are like game of &lt;em&gt;Snake and Ladders&lt;/em&gt;, every task travels through multiple departments, sometimes in circles. Each one of such transitions is like sending a message to the other team's &lt;em&gt;queue&lt;/em&gt; and every queue introduces latency as it needs to be properly handled.&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;There is nothing quite so useless as doing with great efficiency something that should not be done at all. - Peter Drucker&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Speaker proposed decrease of latency and elimination of queues by composing cross-functional teams with shift from &lt;strong&gt;build it&lt;/strong&gt; to &lt;strong&gt;run it&lt;/strong&gt;. However it's nothing new and Lewis went one step further. In order to knock out even more queues one should colocate anyone involved in product (no project!) life-cycle in one room or office. That means not only developers and testers cooperate in one team but also business, sales, etc.&lt;/p&gt;&lt;p&gt;I can't niggle to anything, great talk.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;odds&amp;#95;&amp;&amp;#95;ends&quot;&gt;&lt;/a&gt;oDDs &amp; enDs&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Vaughn Vernon - for{comprehension}&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Oops I did it again. I attended to Vaughn Vernon's lecture even though I complained so much the last time. He talked about stuff that appeared on other talks so I won't go much into details (Conway's Law, big ball of mud, direct cooperation).&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/weYFAPEgOVFlGdgYNrgBvG1XWOB_1nuwaFmX-8_DidE7aiGiLACFJKgOhcPHSjyyvOgHdXYS9jgpB36vUStWNGLhptSaUxxUZ5hqVa4oKZvkRulnnMq9_blqu-ovtQWRWY7rAXCIhHytcKFweuegYYJ3WkCH6dssPc2SgCDHGI9lvr6p38j_G58fK_HH6UFgcwRsZDowfQZch8TIZ7rElraiRwzTL_UyQHZTEeHBHzjN2a1YZyEaGIXszEAWdOAAHjivNmGxlJT-XWadcK3_6V6DRFZxJRJ8ZOdHT_0ORRyU669wt8_gascAGcuSvAiEu9yz-5Yke5cZ-sUlBQHNVGg7C6J4mpHJu7IiP-1fT2x8kiCikJ3J5G6rN3qa-zOOJNzWw5M-XZbE5l4Az0jC9w0iJjc-pjKWojBlUX9QzZtrEV-O3eizIzaDC8gc5-Ia8EAs3AXerPcFo-i4RoZ83eHpsvf2frkvGGSz6gWRVtHa7eWhvq-_CUXLdQefzansldwL97FN2h5Va1EDPC0q6dxSCxed0V77yzoaKy5fJk3p14HLE-oJO71IGgym9uUKIx3mP603Zpc_hQae7BswaVQADs0tV3k=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Beyond that he introduced a concept of Event Storming as a good alternative for creating architectural requirements and high level planning. If you'd like, my dear reader, know my opinion about this talk you should check out day two from this series and &lt;strong&gt;Reactive Microservices with DDD and Actors&lt;/strong&gt;, got the same vibe as from this one.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;jvm&amp;#95;and&amp;#95;docker,&amp;#95;a&amp;#95;good&amp;#95;idea?&quot;&gt;&lt;/a&gt;The JVM and Docker, a good idea?&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Christopher Batey&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Maybe good, maybe not but you need to know your toolkit. Or thats what I've learned from this lecture. Christopher presented few convenient, or even  essential, tools for managing Docker (and more). Example of those tools are systemd-cgls (something like *nix ls), ystemd-cgtop (top), jcmd and cAdvisor. Lecturer warned of default settings of multithreaded environments. Such case can be Jetty or Java ForkJoinPool which by default sets number of threads basing on available cores. This approach can be troublesome in containerized applications as each container can compete for resources. &lt;/p&gt;&lt;p&gt;Speaker showed few techniques to prevent such events using Docker's configuration parameters like pu-shares and cpu-quota. Maybe I'm not the sharpest knife in the cupboard when it comes to Docker but during this talk I've learner a couple of interesting facts about Docker and JVM performance.&lt;/p&gt;&lt;p&gt;Solid, nothing more, nothing less. Christopher Batey gave impression of a man with knowledge and skills to transfer it.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;climb&quot;&gt;&lt;/a&gt;The Climb&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Bruce Tate - icanmakeitbetter.com&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Another tale from Bruce Tate. This time he compared software development to Mount Everest climb. He stated that every project, in particular community ones, need their Sherpas and everyone should also be one in some project. Again he mentioned Elixir and that gets me jollies, maybe more people will recognize this lovely language.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;pragmatic&amp;#95;architecture&quot;&gt;&lt;/a&gt;Pragmatic architecture&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Ted Neward - iTrellis&lt;/em&gt;&lt;/p&gt;&lt;p&gt;At the end Ted Neward made an appearance with his hilarious talk about architects. But this wasn't just jokes and laughs. &lt;/p&gt;&lt;p&gt;He said that architects have no easy task. They need to form set of rules that developers would follow and &lt;em&gt;fall into a pit of success&lt;/em&gt;. He also reminded that that &lt;em&gt;best practices&lt;/em&gt; don't exist since you can't apply them in any situation. You need to think what's relevant in certain situations and if it's worth the effort. &lt;/p&gt;&lt;p&gt;In Ted's opinion architect should define simple rules making mistakes harder to make but at the same time he can't kill all the creativity. Architect can't finish his job and move on to another task but his responsibility should be being reactive, adapt to changes. &lt;/p&gt;&lt;p&gt;Speaker also stated that architect can't fall into &lt;em&gt;coolness trap&lt;/em&gt; but explore things valuable to the project. Personally I think the last remark should apply to any of us developers. &lt;/p&gt;&lt;pre&gt;&lt;code&gt;would&amp;#95;recommend&amp;#95;talk? =&amp;gt; true
&lt;/code&gt;&lt;/pre&gt;&lt;h2&gt;&lt;a name=&quot;summary&quot;&gt;&lt;/a&gt;Summary&lt;/h2&gt;&lt;p&gt;Phew. I haven't expected so much text. If anyone made it through, best regards. Nonetheless I think it worked out pretty ok despite my notes being 3 times longer than all this series all together.&lt;/p&gt;&lt;p&gt;Enough about me, let's talk about the conference. It was probably one of the best I've attended to. ICE Congress Centre is a great choice for this kind of events and the auditorium is fabulous. Sometimes when I didn't feel like going anywhere I would just go there and relax. &lt;/p&gt;&lt;p&gt;Food was ok, I guess, and queues weren't to troublesome. &lt;/p&gt;&lt;p&gt;Quite a lot of company stands, some raffles but nothing that would get my attention. I've achieved my goal that was to collect every sticker I could find. Socks and powerbanks are still lit in the conference fashion but there is a new FOTM - bartenders. Some businesses hired bartenders to make coffee (quite nice) and smoothies (also good). &lt;/p&gt;&lt;p&gt;As far as speakers are concerned I was pleased. It was great to meet authors of your favorite books and blogs. &lt;/p&gt;&lt;p&gt;All in all I can recommend Devoxx Poland. It there's an occasion to participate in next year's edition I'll go for sure.&lt;/p&gt;&lt;p&gt;&lt;a href='https://goo.gl/photos/GmecMWFePBJNRm7F6'&gt;Here's some small gallery from the conference.&lt;/a&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Check out &lt;a href='../2016-07-09-devoxxpl-2016-day-1'&gt;Day 1&lt;/a&gt; and &lt;a href='../2016-07-09-devoxxpl-2016-day-2'&gt;Day 2&lt;/a&gt; of this series.&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;&lt;a href='../2016-07-09-devoxxpl-2016-day-3-pl'&gt;Tutaj możesz znaleźć wersję polską tego posta&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
<author>
Patryk Żmigrodzki
</author>
<enclosure>

</enclosure>
<pubDate>
Sat, 09 Jul 2016 00:00:00 +0200
</pubDate>
</item>
<item>
<guid>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-1/
</guid>
<link>
https://pzmi.github.io/posts/2016-07-09-devoxxpl-2016-day-1/
</link>
<title>
What time is it? It's Devoxx time! [Day 1]
</title>
<description>
&lt;p&gt; &lt;img src=&quot;https://lh3.googleusercontent.com/WWC8Jr6RIgFbDCKY0zeRi2dAVWwBwOYJAYSldUjQY75IWGbhaoVXzPOs5HHdoo4PmCIoUPAbVkoqG7pqSbLZC5JZdjCB82rbRBR6zLpUbrlQBene-msIBIR3kBlY1nDFU-E9zpQe0WvnycQ-Zp1trWLqeyCGPHOmOaCyUeoxxn3zrl10__G8KbiXf18cZFop4JJIEAglZC5rKXCyqrOn8e3j6YFDq3catcY-iLfuElhJmMkcbgcPd3_fsHOX-Ed2PCIg3X4wY69mQlCUgGgL8brhmappFcJB3bObHgu75HNN11N1dqa0_An54tOziIM24gi_-DFf9xeD717iMq8-pqBj_EmQOT-siglK0FMsFv8GP6cM0TJYnOndx4qvYtVSgu0sRYCaZaaZMLYdx82J3esL03R_ugOcNnu6cQa7vAz6pkv5IS2viRrnMkVGL7QjpBAAE-zEDCs1tDnqaAp38FuL0KBKaZ4v5qGDillFgxSTqQ-NEukh_GZQJ8gcOmnDrtsdBQzREXNShi9zXdT-YJeyqHzlR8cKyMeuR6QYkGVbJ0fSNrLhD3FZb1aJFO5BOKAvfQrd3kMXtaEt3HqbtJWTdRJ8WZ8=w1158-h1008-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;And there goes the conference. In this series I'll try to summarize what happened at &lt;a href='http://devoxx.pl'&gt;Devoxx Poland 2016&lt;/a&gt;, what interesting things one could learn and also a few subjective opinions about panels.&lt;br /&gt; This years Devoxx Poland took place on 22th to 24 of July at ICE Congress Centre in Cracow.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;why&amp;#95;does&amp;#95;yesterday's&amp;#95;best&amp;#95;practice&amp;#95;become&amp;#95;tomorrow's&amp;#95;antipattern?&quot;&gt;&lt;/a&gt;Why does Yesterday's Best Practice Become Tomorrow's Antipattern?&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Neal Ford - ThoughtWorks&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Blazingly fast keynote by Neal Ford. His keynotes, as he says, are designed to be entertaining to a more diverse audience. This one was no exception. Speaker rushed through some historical antipatterns and their impact on later solutions, for example Continuous Integration was seen as a bad idea since integration phase was associated with tedious and painful process. Neal hasn't stopped on this case and mentioned recent drama with Leftpad what summarized with his ThoughtWorks colleague's quote:&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt; &lt;em&gt;Dependency management will be our &quot;Goto Considered Harmfil&quot; moment&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;As we are on quotes, one of the reason of antipatterns' birth speaker portrayed with George Santayana's words:&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Those who cannot remember the past are condemned to repeat it.&lt;/em&gt;&lt;br /&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&lt;strong&gt;Transpiling&lt;/strong&gt;, a technique commonly used in javascripty forntends is nothing more than code generation, for decades found as an antipattern.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;EDIT:&lt;/strong&gt; I've got pointed out that code generation isn't necessary an antipattern but this thought is about reinventing the wheel. Well I could have gotten it wrong (or I just don't like generated code very much).&lt;/p&gt;&lt;p&gt;No presentation can miss Conway's Law, rubbing developers' noses in the dirt for looking for excitement in their work and reminding that we should favor libraries over frameworks. Neal quoted another law (his own?), &lt;a href='http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html'&gt;Dietzler's Law&lt;/a&gt;. Year 2016 and nothing about microservices? Of course not! At this occasion Neal mentioned evolutionary architecture which was the topic of this second appearance.&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/EVXcbWooKr7-_Qswgw204hQWwMcdEd7Rbicvt3z2yeKkB7VVPhvcaRbRTUWzEnH0UDmKtQZJE6Dj-58nnEt0vKReaZ6cIDqCaxSLOaeer8KiKW58LZG8REsbdgceLYRt5DRdaETAqYWlFTlL8XlnF7MQ7-y6G9MSbyXK0XvTK6rEEzh_v3qY4T8Ihw6mIdlSNo5iahG-7IXsPfViqIO_sMXS1XhmCe0B2S4eXubjSMRwnci_kyV-QTwFnL68QnWAmYPwQtayCSHKWxMf4qYEuwxDFbJcYfmo7pjQcgv4fSRMTJ6NvSfkoAidGZWBdnrtj7j7OernR6cXTUtnIcfQetplQIcIDL6Rxw3CE_pwc59piUkKdiBk23SIxl1rBMMyRqe5noqR0RZe-rorR-I07zOuWqPZ2Hi1t9d5P_HjeN7qBQwojP8cpCtyO_ej6LvexqiB7taVfDnfedCPrxJacx01h02SoMXFAEjfaPVgceFkyibJXlD0XrlOKwFAl3ZFyr9q5adnQiaBNVZmp6CGnOGi1hHblK93z5qmNwmCXDFALhWYk4GU-ZbDiFGY0kY6ix6LLlm7LAfV-MEes1YJfmXSOMiOzAY=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Generally speaking this keynote was just a taste of things we would experience during following three days of Devoxx. It was great performance due to Neal Ford's great lecturing skills. If you have an opportunity to listen to one of his lectures, you should.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;the&amp;#95;good&amp;#95;monolith&quot;&gt;&lt;/a&gt;The Good Monolith&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Łukasz Szydło - Bottega IT Solutions&lt;/em&gt;&lt;/p&gt;&lt;p&gt;You can create applications that aren't microservices? Cannot be! How?! Well, you just design them as microservices but deploy as monolith. Or that's what we have been told by Łukasz Szydło who compared monolithic systems to sky scrapers and microservice ones to a town consisted of smaller buildings. Good monoliths should be this town but under a dome. Speaker mentioned Domain Driven Design (like almost everyone at this conference) and Entities with Bounded Context. He also stressed out problem with overloaded models where the same objects are used in varying contexts. For example a human is a sophisticated being but in a swimming pool he's a swimmer, at the shooting range he's a gunman, etc.&lt;/p&gt;&lt;p&gt;As Łukasz said, an advantage of good monolith in in comparison to microservices is lower complexity, mainly in communication and transport. Also if, in the future, you decide to move to microservice architecture it would be easier to adapt those loosely coupled components than rewrite everything from scratch.&lt;/p&gt;&lt;p&gt;This presentation wasn't overloaded with information, a huge change after the previous one. You could check your mailbox and easily follow the topic.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;hotspot&amp;#95;&amp;&amp;#95;aot&quot;&gt;&lt;/a&gt;Hotspot &amp; AOT&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Dmitry Chuyko - Oracle&lt;/em&gt;&lt;/p&gt;&lt;p&gt;What is AOT and why should I care. Dimitry showed new Oracle's experiments with Java compiler. Shortly explained what Hotspot VM has hidden underneath the surface of Java and what's the difference between GraalVM - the new Java compiler written in Java. Good side of AOT is that unlike JIT it doesn't require runtime resources and we receive predictable performance. Dmitry had weak slided, in most cases I could do without them as they weren't very informative. It's a shame that presenter's rhetorical skills were rather poor.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;successful&amp;#95;startup&amp;#95;is&amp;#95;not&amp;#95;enough.&amp;#95;you&amp;#95;must&amp;#95;scale&amp;#95;technology&amp;#95;to&amp;#95;enterprise&amp;#95;while&amp;#95;maintaining&amp;#95;your&amp;#95;startup&amp;#95;creativity.&quot;&gt;&lt;/a&gt;Successful startup is NOT enough. You must scale technology to ENTERPRISE while maintaining your startup creativity.&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Marek Grochowski, Cezary Zminkowski - Sabre&lt;/em&gt;&lt;/p&gt;&lt;p&gt;Sabre's sponsor panel. Probably the worst one I've seen on this conference. Gentlemen spoke about their product, TripCase, and it's road to glory. It was developed for about 5 years but business success achieved just last year. Wait a minute! Isn't this supposed to be a lecture about startup success? Well, I &lt;em&gt;learner&lt;/em&gt; that 90% of startups fail because they are just bad at startuping. How to do it well? For starters you should have a perfect architecture, estimate theoretical complexity of algorithms monitorloganalyzetrendsblahblablahblaa.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;antifragile&amp;#95;architectures&quot;&gt;&lt;/a&gt;Antifragile Architectures&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Matt Stine - Pivotal&lt;/em&gt;&lt;/p&gt;&lt;p&gt;If something is fragile and breaks under stress than antifragile, in the same situation, should grow in strength. Moreover, antifragile wither when not subjected to constant stress.&lt;br /&gt;&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/k4MfoJ1CudGzSfia0xzz8_4dm7xuU4Hh8CuwRPPaRvsyQzl10Cx5Bk5LLClvOPWv2egTzt25qVOz5N_Zcl2mdfrjHrOdqtDSbWeO56uzREk_kXH415YPm2fwPAeHO6RvGAG0WGpli-yPkTyIlN4MordlPWFhQhMr8_ofjWwAYNQJH1Mz68gco9nDLE7pM_l-L3tVrv1CXLOd3b73HaQhRvVouI8RwdsYdHOJwt2FAAT4kq2lBiipNmKuN94YqJTE4-pmoRHfUtrmQkYbMHuogtfzUqC4V7b9BXpzaWAVWaLS7Sl4-Mh-37N0-4XSt3rqXjhm-QzzNBNBJese3D4gs4wUcjQU9_X0n8orQ4lWmbhvTyhM0IPpU8JKC_4XSjRaYtIsL2JUJCQ4rreySKdLCD78yhqO9h2Xh2UnWdReX5xHA1F65KhYzsufoHHc4D4d2E6AeG0T6m-RYperdbrbgWov6ov4FOSUKg8AjKweKOpV_VYmp64TPzpN-xXrt7H-c9rsHi_FkItsw-2ZyGYTDlc8qu1dzxBOtmI7czSbvgFHLqn3LwfmPnXFWjU5FVwUG81_FmBOtZtsjPhGrfnEvalzpNUUNy8=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;Thats how Matt Stine described antifragile in his lecture. He thinks that software have to be antifragile in order to withstand constant change and that change is a must according to &lt;a href='https://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution'&gt;Lehman's Law&lt;/a&gt;.  In Matt's opinion systems should be failsafe and autodiagnostic. As an example he mentioned Netflix and their set of tools, &lt;a href='https://github.com/Netflix/Hystrix'&gt;Hystrix&lt;/a&gt; and &lt;a href='https://github.com/Netflix/SimianArmy'&gt;Simian Army&lt;/a&gt;, which allow those traits. He stressed the role of Chaos Monkey as defect injection forces to constantly think about defects and their prevention. I quite liked this lecture but philosophical reflections about ultrabig systems was a little bit too much for me.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;jvm&amp;#95;dive&amp;#95;for&amp;#95;mere&amp;#95;mortals&quot;&gt;&lt;/a&gt;JVM Dive for mere mortals&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Jakub Kubrynski - Devskiller&lt;/em&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;JVM is just an application&lt;/em&gt; &lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;Jakub showes JVM as a regular application which you can learn and understand (especially when you can read the source code :)). He also walked through Java code life cycle, from code, bytecode, JIT, finishing on native code. Speaker also discussed few optimization techniques used in JIT pointing out usefulness of this knowledge. In short when you are aware of such processes you can predict what optimizations can occur and don't optimize prematurely by yourself. Solid and pleasant talk.&lt;/p&gt;&lt;h2&gt;&lt;a name=&quot;how&amp;#95;to&amp;#95;survive&amp;#95;and&amp;#95;thrive&amp;#95;in&amp;#95;a&amp;#95;bigco&quot;&gt;&lt;/a&gt;How to survive and thrive in a BigCo&lt;/h2&gt;&lt;p&gt;&lt;em&gt;Michael Coté - Pivotal&lt;/em&gt;&lt;/p&gt;&lt;p&gt;We are garbage men, not cowboys but without cowboys world wouldn't be as bad as one without garbage men.&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://lh3.googleusercontent.com/DZA-l4VKHdQTU6nbOUCHyTbYdxo9jBcSB1fXZ7MYcyv2xJKKGbA_xn6DjGWt5cEv7yI4IQRhF30kf8q9Z-nP_kCCyiLR5Kv6xAFPzXIXsmfKzPU9b4vUEjg4kjuqnkt8rYv70ukjwh82r5NDk5XCLeeGeC4s0yNTOXYS0M9DW2bELMc9eL2aCtIvcHmiOZ2gyM_VqZnq5-5D8gMB265kcz2YSVG_PHfN1uisBLcR-kk9rMuFfTEXxUOsjfShXdklTqeQBydsvZhDBFuPuAo8VVWSZpLCaqEkG6WGl7pwOFDR47vC2TCbxbsCrMSmhIGamODehIPVaLx9PTRTB397088ACCYBujOIHv6yjnnjlL6SbDyt8RIvGvaCYQXeFGb9PDT6-9sayCHgAhAm1T7RVHYbSUCzm63ayxaVq92osBWBo32SwVJuN9OYvJt32Kim2sfr3KHx4hj1pYS4nNiEeTjlvC_PdpzorMSTM9zvOJwrRwo1bQ0IroUwzFpNxJnVVP8whSQKr_l8tw_vwIQC_KGVXIUCjQzPDQLXkyfnMO-kHieK6z_Zkpzsx5KwkdJLAMLnKQaH11UAEhS-QR-kkDtFmIu0AvE=w1280-h960-no&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;&lt;p&gt;That was just a random thought from the last lecture of day one, how to survive in a corporation. Michaels first advice was to find yourself a mentor who can help you find your place in a company. However if you are not satisfied as a code monkey you have to find a champion who can introduce into educative projects.&lt;/p&gt;&lt;p&gt;Speaker also advise not to take a lot of additional work, out of your responsibilities. There are &lt;strong&gt;homework vampires&lt;/strong&gt; lurking for you. Apparently if you ask them for some involvement, like introduction into their task or picking just the slides directly related to their request you can recognize those vampires. If requester is willing to spend their time for you, they probably mean no harm.&lt;/p&gt;&lt;p&gt;Michael also raised a topic of introducing changes in a corporate cogs noting that it's not an easy task. It requires great effort in order to fix enormous company. Probably the best idea is to go into hiding with your new projects and don't reveal yourself until you achieve some success.&lt;/p&gt;&lt;p&gt;Apart from few tips about creating slides which are foundations of every corporation, Michael summarized his appearance in two statements (more or less):&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;The biggest competition is status quo&lt;/em&gt;  &lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Work as little as you can&lt;/em&gt;  &lt;/p&gt;&lt;/blockquote&gt;As a corporate rat I can't agree more with those remarks :)&lt;/p&gt;&lt;p&gt;Nice wall of text we have here. Yet I think it was the most informative day of the conference and I promise that next ones will be shorter.&lt;/p&gt;&lt;p&gt;&lt;strong&gt;Check out &lt;a href='../2016-07-09-devoxxpl-2016-day-2'&gt;Day 2&lt;/a&gt; and &lt;a href='../2016-07-09-devoxxpl-2016-day-3'&gt;Day 3&lt;/a&gt; of this series.&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;&lt;a href='../2016-07-09-devoxxpl-2016-day-1-pl'&gt;Tutaj możesz znaleźć wersję polską tego posta&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
</description>
<author>
Patryk Żmigrodzki
</author>
<enclosure>

</enclosure>
<pubDate>
Sat, 09 Jul 2016 00:00:00 +0200
</pubDate>
</item>
</channel>
</rss>
