Monday, April 2, 2018

Geecon 2017 - recenzja


Witam.
Jako zwycięzca loterii JUG Łódź, wybrałem się na konferencję https://2017.geecon.org/, która odbyła się w dniach 17-19 maja 2017 w Krakowie.
W sumie była to moja druga konferencja Geecon'a na jakiej byłem i mogę Wam powiedzieć że jedyne czego żałuję to, iż była to dopiero druga, na łącznie dziewięć jakie się już odbyły.
Ujmując rzecz krótko Geecon zdecydowanie mnie nie zawiódł, zarówno poziomem organizacyjnym jak i merytorycznym. Kilka powodów dla których uważam, iż krakowski Geecon warto sobie zapisać do kalendarza na kolejne, przyszłe edycje :
1) Miejsce : bardziej mam tu na myśli sale niż sam Kraków, który oczywiście też jest fajnym miastem. Geecon, już trochę tradycyjnie, odbywa się w Multikinie. Moi skromnym zdaniem multiplex-owe kino jest chyba najlepszym miejscem na organizacje konferencji programistycznych :
- duże sale ( do 500 miejsc siedzących)
- duży ekran do prezentacji
- bardzo dobra widoczność z każdego miejsca
- dobre nagłośnienie i akustyka sal
- duża ilość miejsca poza salami wykładowymi.

Jedynym minusem jest może przepustowość samych wejść do sali, co przy pełnej 500 osobowej sali jest pewnym „wąskim gardłem” no ale cóż wszystkiego mieć nie można. Gdyby przyszło mi organizowanie konferencji programistycznej z pewnością rozważyłbym jako jej miejsce właśnie takie kino.

2) Termin konferencji - rzecz również nie bez znaczenia, gdyż zdecydowanie przyjamniej jest jechać na konferencję w ciepły majowy dzień niż jakiś mroźny zimowy - a i na takich konferencjach się bywało.

3) Organizacja samej konferecji - absolutnie bez zarzutu, sprawna obsługa rejestracji, kateringu. W imprezach pomiędzy dniami konferencji nie uczestniczyłem ale sądząc po stopniu „zmęczenia” niektórych uczestników też musiały być udane.

4) No dobra może teraz do jakiś konkretów bo wyjdzie, iż na Geecona warto jechać by się poopalać w majowym słońcu najeść i napić :)).
Poziom wykładów - bardzo dobry ! Wykłady odbywają się jednocześnie na 4 salach więc siłą rzeczy na wszystkich być nie można i z czegoś trzeba zrezygnować na rzecz czegoś innego. Nie ma tam zasady ścieżek tematycznych, więc należy trochę krążyć pomiędzy salami w poszukiwaniu tego, co Nas interesuje. Mnie udało się tak dobrać sobie prezentacje, iż trafiłem na wyłącznie takie z których jestem na prawdę zadowolony. Dało się co prawda usłyszeć, w ramach rozmów korytarzowych, narzekania osób iż „źle wybrały sobie jakąś prezentację” no ale cóż - tak też bywa.
Generalnie tegoroczny Geecon był zdecydowanie z nastawieniem na „server side” więc jeżeli ktoś spodziewałby się wielu prezentacji o technologiach/aplikacjach mobilnych bądź też front-endzie to raczej by się zawiódł.
Ponieważ tak jak wspomniałem wcześniej był to mój 2nd Geecon to mogę powiedzieć, iż ServerSide jest raczej dominującą tematyką. Większość prezentacji Geecon'a jest o „Java and JVM based technologies” - zgodnie z tym co zapowiadają na stronie konferencji. W ramach każdej edycji zapraszany jest przynajmniej jeden prelegent z bardzo wysokiej półki. W tym roku prezentację kończońcą konferencję prowadził Rod Johnson - twórca frameworka Spring.

Powiem tak, trochę się najeździłem po różnych konferencjach i mogę z czystym sumieniem polecić Geecon'a jeżeli interesują cię szczególnie technologie bazujące na JVM i jesteś bardziej programistą aplikacji „server side” niż aplikacji mobilnych lub front-endowcem.

Na zakończenie garść porad praktycznych :
- gdybyś miał się wybierać na jakąś konferencję wyjazdową to Geecon'a zdecydowanie polecam - jak dla mnie jest to numer 1, a byłem już na wielu różnych konferencjach.
- jeżeli się już na Geecon wybierasz to wyjedź dzień wcześniej i wróć dzień po konferencji. W prawdzie zapłacisz trochę więcej za noclegi, ale się nie umęczysz w podróży ani nie będziesz się zastanawiał co zrobić ze sobą i swoimi rzeczami w ostatnim dniu konferencji. Poza tym możesz wykorzystać ten dodatkowy czas na pozwiedzanie Krakowa, a chwila odpoczynku każdemu dobrze zrobi.
- lepiej jest pojechać większą grupą niż samemu,
- jeżeli nie możesz się zdecydować na jaką prezentację pójść o danej godzinie, wybierz tą która jest w największej sali - ta taktyka mi się sprawdziła już nie raz.

Geecon 2018 będzie jubileuszową, 10 edycją. Organizatorzy zapewniali, iż z tej okazji przygotują coś „EXTRA”. Mając na względzie doświadczenia z tej i poprzedniej mojej wizyty na Geecon uważam iż będzie warto wybrać się w maju 2018 roku do Krakowa.

dziękuje i pozdrawiam

Tomek

p/s

Nie wiem czemu tak się stało, że w/w powstała na koniec maja 2017 roku i nie została przeze mnie nigdy przesłana ani opublikowana. Mogę się jedynie tłumaczyć nadmiernym obciążeniem wszelkimi obowiązkami zawodowymi oraz domowymi, a także zwykłym roztargnieniem.
Nie ma jednak tego złego co by na dobre nie wyszło i mogę recenzje wzbogacić o refleksję na temat przydatności technologii prezentowanych na prelekcjach.
Mam pewną niepisaną zasadę, iż uznaję konferencję za udaną jeżeli choć jeden z prezentowanych materiałów uda mi się faktycznie wdrożyć i używać produkcyjnie.
Geecon 2017 z pewnością był udany gdyż wzbogacił mój zbiór narzędzi o ciekawy projekt analizatora logów https://www.graylog.org/ , który udało Nam się zastosować produkcyjnie w dość dużej realizacji i mogę z czystym sumieniem zarekomendować GrayLoga jako coś wartego uwagi.



Tuesday, July 11, 2017

Devoxx 2017

Devoxx 2017   


Tegoroczny Devoxx w Krakowie trwał  od 21 do 23 czerwca  i odbył się w centrum kongresowym ICE, które według organizatorów może pomieścić ponad 2 tysiące osób, jest to zatem jedna z największych o ile nie największa konferencja dla programistów w naszym kraju. Dzięki uprzejmości JUG Łódź miałem okazję wziąć w niej udział za co jestem niezmiernie wdzięczny.


Przejdźmy zatem do opisu samych prelekcji. Zaraz po otwarciu na scenę wyszedł Venkat Subramanian, który mówił  o potrzebie coraz szybszego wytwarzania rozwiązań programistycznych, o znienawidzonym przez wszystkich programistów pytaniu “Are you done yet ? “ i o tym, jak bez odpowiedniego podejścia doprowadzić projekt do fiaska. Prezentacja pokazała również dlaczego programiści powinni pisać testy i dbać o quality swojego kodu, tak by nie utknąć w JDD, czyli Jesus Driven Development. Kolejną interesująca prezentacja z dnia pierwszego była autorstwa Douglasa Howkinsa zaś jej tytuł to Concurrency concepts in Java” , zatem coś  czym słyszeliśmy już wielokrotnie, prezentacja ta była jednak nieco inna, autor nie skupiał się na konkretnych przykładach programistycznych, ale zamiast tego próbował pokazać jak to wygląda “od środka”, czyli w jaki sposób kompilator może reorganizować kod i jaki to może mieć wpływ chociażby na widoczność zmiennych między wątkami. Następnie trafiłem prosto na wykład o Clean Code prowadzony przez Victora Rentea, poza konceptami szeroko poruszanymi we wszystkich ksiażkach na temat clean code’u, a więc odpowiednim nazywaniu metod, rozważaniami ile linijek może mieę nasza klasa a ile powinna miec metoda, autor mówił również o Javie 8 i o tym jak używac Lambd i Streamow, by nie doprowadzić do sytuacji w której nasz kod staje się zupełnie nieczytelny - każdy kto pracował z Java 8 wie, że o to nietrudno. Następnie rozpoczęła się sesja  Meet & Greet w trakcie której kilku prelegentów prowadziło dyskusje, jedną z nich była dyskusja na temat popularnego ostatnio Kotlina i jego zastosowań w firmie Allegro, z dyskusji można się było z niej dowiedzieć między innymi, dlaczego używają oni Kotlina “na produkcji” w czym jest lepszy od Javy i dlaczego w ich przypadku zdeklasował Scale.


Dzień drugi to między innymi kolejny temat “na topie” a więc nowa Java, Simon Ritter i jego prezentacja 55 new features in JDK 9” jak sama nazwa wskazuje skupiała się na tym co nowego zobaczymy w nowej wersji języka. Poza omawianymi szeroko Jigsawem, czyli modularnością i długo oczekiwanym jshellem, Simon opowiedział również o usprawnieniach związanych ze strumieniami i wielowątkowością, prywatnymi metodami w interfejsach, czy zmianach związanych z zachowaniem struktury kodu w czasie kompilacji. Warto również wspomnieć o prezentacji Sama Newmana, który opowiedział o bezpieczeństwie w mikroserwisach, o tym w czym mikroserwisy są lepsze od monolitu jeśli chodzi o kwestie bezpieczeństwa i dlaczego, ale żeby nie było tak kolorowo, była również mowa o ich wadach w szczególności problemach z maintenance’ m  i wykrywaniem ataków. Jeżeli mielibyśmy zapamiętać z prezentacji tylko jedną rzecz, niech to będzie fakt, że najlepszą metodą reakcji na atak jest usunięcie wszystkiego i przywrócenie backupów z momentu co do którego jesteśmy pewni, że system był “czysty”. Kolejna interesująca prezentacja to znowu Doug Hawkins i  Java Performance Puzzlers”. Jeszcze raz była mowa o JVM i jego wewnętrznym działaniu, o tym jak architektura CPU wpływa na optymalizację JVM, i dlaczego ta architektura nie zawsze działa na naszą korzyść. Była mowa o tym, jaka jest maksymalna długość bytecode’ u która JVM będzie próbował optymalizować. Dzień drugi, podobnie jak pierwszy zakończył się sesją Meet & Greet przy piwku.


Dzień trzeci to talki głównie o architekturze i mikroserwisach, pierwszy z nich “Resilient Architecture” prowadzona przez Matta Stine, skupiła się na pokazaniu różnic między architekturą, którą tworzymy dziś a tą która powstawała dziesięć lat temu. Największą różnicą jest zasada “Embrace Failure”, której trzymamy się dziś. Nie tworzymy więc aplikacji, która jest niezawodna, ale zakładamy, że prędzej czy później dojdzie do jakichś błędów, które spowodują niedostępność części systemu i staramy się na to przygotować,  tak by zminimalizować straty. Pewnym rozwiązaniem tego problemu wydają się mikroserwisy. Które nie rozwiązują jednak wszystkich problemów związanych z resiliency. Na prezentacji była mowa o kilku technologiach, które mogą pomóc w budowaniu tego typu aplikacji. Są to między innymi  Hystrix czy Chaos Monkey. Dalej o architekturze mówił Jakub Kubryński w prezentacji “Microservices - the naked truth of maintainability”. Ta prezentacja była inna niż większość prezentacji o mikroserwisach, zazwyczaj słyszymy jakie to wielkie zyski przynosi przeniesienie się z monolitu na mikroserwisy, mało zaś mówi się, że utrzymanie architektury mikroserwisowej jest zdecydowanie trudniejsze i dużo bardziej wymagające. Testy integracyjne mikroserwisów są zazwyczaj zarówno trudne, drogie i czasochłonne. Jakub starał się pokazać, że z odpowiednim podejściem, możemy ograniczyć koszty i ilość testów integracyjnych, skupiając się na unitowych i pozwalając użytkownikom zweryfikować pełną funkcjonalność.Ostatnia prezentacja miała nieco dziwny i intrygujący tytuł “PsyPhilProg”  i była prowadzona przez Teda Newarda, który mówił o podobieństwach między programistami, psychologami i filozofami, o tym, że przedstawiciele tych trzech grup muszą się zmagać z wielopoziomowymi abstrakcjami, które są niespotykane nigdzie indziej. Jedną najcenniejszych rad wynikających z tej prezentacji była ta, że programiści w pracy powinni zadawać filozoficzne pytania jak “po co?”, “dlaczego?”, gdyż mogą one zmienić nasze postrzeganie problemu z którym się zmagamy.

Tegoroczny Devoxx miał bardzo mocny “skład” i w ciągu wszystkich trzech dni można się było dowiedzieć masy ciekawych i przydatnych rzeczy, trudno by mi było wybrać najlepszą prezentację czy też najlepszego prelegenta. W tym krótkim poście starałem się zawrzeć opisy najciekawszych moim zdaniem prezentacji ze wszystkich trzech dni.

Do zobaczenia za rok w Krakowie!
Dominik

Wednesday, May 31, 2017

MCE 2017 - wygrany bilet “Bo mam szczęście”

Dzięki Łódzkiemu JUG-owi oraz firmie Proidea wygrałem bilet na jedną z największych konferencji w Polsce dotyczącą technologii Mobilnych. Konferencję uważam za naprawdę udaną. Na duży plus zasługuje podział na poszczególne bloki tematyczne (ANDROID, DESIGN, IOS) sprawia to że konferencja skierowana jest do szerszego grona odbiorców nie tylko do developerów ale także designerów jak i grafików. Konferencja trwała 2 dni organizatorzy zapewnili wszystko Prezentacje, Jedzenie, jak i rozrywkę(konsolę, oraz gra networkingowa).  Mnie osobiście podczas całej konferencji spodobały się 3 prezentacje.

1 Psy i Koty w której prelegenci opowiadali jak trzymać w ryzach team - war czyli wojnę pomiędzy Androidem oraz IOS i uwaga jest na to rozwiązanie KOTLIN(nie ten ketchup, tylko język) . Według mnie najbardziej udana prezentacja wiele żartów oraz wzajemne przygryzanie sobie nawzajem prelegentów sprawiły że prezentacja była według mnie najlepszą ze wszystkich.

2 Odchudzanie aplikacji, według mnie najbardziej merytoryczna prezentacja całego MCE. Czyli co zrobić żeby nasze aplikacje zamiast 40mb ważyły tak ze 27mb ,sposoby na oszczędzanie pamięci,(bawienie się formatami grafik, zasady czystego kodu itd...).

3 Aplikacje dla Afryki, Prezentacja przeznaczona bardziej dla freelance’rów. Afryka nie jest kontynentem opóźnionym o 1000 lat, mieszkańcy posiadają smartphon’y i internet. Natomiast na tamten rynek nie ma przeznaczonych tak wiele aplikacji, dlatego należy uznać tamtejszy rynek jako łatwiejszy do ekspansji niż rynek Europejski, Azjatycki czy “Hamerykański”. Także do dzieła :) piszmy i zarabiajmy :)


Pragnę dodać że mnie interesowały tematy dotyczące Androida, nie byłem na żadnej prezentacji dotyczącej designu - teraz trochę żałóuję ponieważ wielu ludzi zachwalało sobie szczególnie ten moduł. Zachwalaną prezentacją była również prezentacja dotycząca linkowania.
Pozdrawiam i jeszcze raz dziękuję naszemu JUG-owi oraz firmie ProIdea.
Paweł Dawiduk  

Wednesday, May 3, 2017

Scalasphere 2017 by Jędrzej Nowowiejski & Sebastian Szyller

Beginning of March in Cracow brought us the 2nd edition of this conference. Scalasphere could be categorized as quite unusual as it's focused not on academic discussions, frameworks or languages themselves but rather on tooling. Tooling, which usually is not perceived as valuable itself (that's a shame). Fortunately, we know the truth, the truth that these 'secret friends' help us be effective and successful on a daily basis. All developers using such complex and rich languages as Scala will probably agree that without proper automated help they would spent significantly more time doing things that seem trivial in other languages. Frankly, it's amazing that this conference gathered around 200 people that are not only interested in this kind of software but also eager to spend their free time on improving these tools. Congratulations to organizers and kudos to everyone that participated! Let's start with a few words about the venue. Beautiful view on Wisła river and real palms growing inside a building were so impressive and made us curious what would come next. Big lecture-rooms, interesting sponsors’ stands and nice coffee service and we were finally prepared to absorb knowledge. To write about all talks that we attended would take too much space and time to read about, especially that all of them are available on the conference website/youtube (scalasphere.org/). Therefore, in this review we decided to focus on "the things", sthe things that we as participants are taking home (of course except sponsor's gifts;)). Bear in mind that it's very opinionated and does not cover everything that was presented at ScalaSphere, so we strongly recommend to check talks online by yourself.

  1. Scala compiler is slow, but this is not a curse. We believe that many new Scala coders are not aware that the way they are writing apps may radically change the compilation time. The great example are implicits. They are a really powerful tool that may be applied in many different contexts. However as one of the comics says: "With Great Power Comes Great Responsibility" and that's really true when it comes to implicits. Compiler is doing many things for you and one of them is resolution of implicits. It has to take time, if you have many of them in scope and you don't want to help compiler hunt them. Advice: always think about their scope, it will save a lot of CPU time. But that's not all that you can do to decrease compile time:)

    Secondly, there was a common theme that was present during different talks and that’s speed of the type parser. We all know that compilation consists of different subtasks like indexing or bytecode generation and the abovementioned type parsing is also one of such steps. Long story short, the role of the type parser is to analyse all types in the code and generate a syntax tree that can be later used to validate the type-safety of the code and then make the bytecode from it. It’s worth pointing out that this task is crucial because at the bytecode level JVM does not handle any types explicitly, but only implicitly through static type inference. This is particularly important in case of Scala as its generics are a lot more powerful than the Java counterparts and more widely used, when it comes to mainstream development. As a result, many people tried to come up with a solution that would speed up the overall compilation time e.g. via caching partial compilation results (Krzysztof Romanowski @RomanowskiKr from Virtus Lab), using distributed version of the Scalac compiler (Hydra compiler from @triple_quote - you can see that they already helped a lot Zalando to make their builds over a 3x faster) or trying to reinvent the type parser itself (Scala.meta). Let’s focus on the last case. It should be noted that at the moment there are three official type parsers in Scala - in Scalac (used in sbt, comes with the Scala distribution), in dotty-compiler (next version of Scalac that will come with Dotty i.e. Scala version 3.0) and in IntelliJ’s (or rather IntelliJ Scala plugin’s) implementation of the Scala compiler and presentation compiler. They do not differ substantially but unfortunately in all cases the type parsing step is quite slow. This is where Scala.meta comes to the rescue. This library is supposed to work on the meta-level of the language and fill the role of the Scala’s reflection API as well as replace or at least aid the procedure of the building the abstract syntax tree. But what is abstract syntax tree? Every language has types, keywords and syntax features that define how the code is written. AST is a tree representation of all those constructs and in the end it corresponds to a semantically consistent structure that represents our code. So far, Scala.meta is in quite early stages but it already shows promising results. Furthermore, rumour has it that JetBrains is planning to invest time in Scala.meta and rewrite its Scala plugin using that library. The only thing that is really needed are contributors so feel free to have a look at the git repository and drop a pull request or two!

  2. Find new usage of already existing simple language mechanisms. That point was inspired by Jon Pretty @propensive talk about contextual. Library that allows you to use String interpolation to validate your inputs. It already supports: some bash command’s syntax, emails, jsons, xml and some more. You can also use it to add your own implementations and that sounds great. To be honest we were sceptical about that as interpolators are applied during compilation phase, so it will work only for strings that you as developer put directly in the codebase. However (thanks to Kamil Owczarek) we found a way to use it in our daily work, we can use it when we want to write some tests with jsons and validate their content (at least on the json specification correctness level). Also bush support sounds promising and may be a true friend, which helps you to avoid unexpected problems in Production runtime as again it works during compilation, so you will know that you made a mistake, before you will try to run it! It took our some time, but we realized that the real greatness, which stands behind it, is to move runtime errors to compilation phase and solve them there. Genius! That conept is amazing. Now we are thinking, if we can’t use some other similar concepts to move further - really interesting homework :)
  3. Building community is really important and Scala have great one. After conference organizers invited everyone to join hackathon. What's more during this event people made some PRs for scalafmt etc. (Ólafur Páll Geirsson about hackathon). We think that's cool, that we are not only using, but also actively trying to help develop tools.

To sum up conference was really nice, great after party and comfortable venue. There was also chance to participate in sister ReactSphere that was taking part at the first day of ScalaSphere (where Jan Pustelnik and Kamil Owczarek from Lodz have their talk), but we were too interested in tooling and missed almost all talks there. Can we recommend this conference to other people - yes and no at the same time. If you didn't work with Scala, we have a mixed feelling if you should go there. You would see that Scala compiler is slow and people work on improving it, developing tools to help you with refactoring, debugging and dependency management, but this is still WIP. That may discourage you from trying to work with it. That's a mistake! You can do many things in this language (for sure more than in Java), but you have to be aware that Scala compiler is doing many things for you, just to let you reduce time of writing code and that comes with price. If you want to spend less time coding, compiler have to do more things for you and that's the tradeoff. You have to choose wisely what you prefer: lower compilation time or flexibility and powerful type system. From the other hand we can recommend this conference to all people who already worked with Scala. It was a real pleasure to be 'an ambassadors' of JUG Łódź at this conference (thanks again for tickets JUG!).

Jędrzej Nowowiejski & Sebastian Szyller