niedziela, 15 maja 2016

GeeCON 2016

Prezentacje

Human Design Engineering

by Matt Ferrar

O tym jak to ludzie są różni, ale że trzeba ich zrozumieć i znaleźć między nimi wspólny mianownik, żeby zaprojektować dla nich dobry interfejs użytkownika. Do tego ogólniki w rodzaju, że należy rozmawiać z klientami, żeby dowiedzieć się co im przeszkadza oraz żeby łączyć i mieszać różne podejścia i technologie. Na koniec garść frazesów w rodzaju “właściwy produkt musi pojawić się we właściwym czasie”.


A Decade of DDD, CQRS, Event Sourcing

by Greg Young

Z tej prezentacji najlepiej zapamiętałem część o kulcie cargo wśród programistów, którzy ucząc się jakiejś metodologii lub technologii zaczynają na ślepo podążać za autorytetami. Tymczasem od wszystkich reguł i wzorców są wyjątki i CQRS nie jest tu wyjątkiem.

Była także krytyka programistów, którzy mają ambicje by tworzyć kolejne frameworki, ale porzucają je po kilku miesiącach. Zapoznanie się z frameworkiem zaczyna zajmować więcej więcej czasu niż napisanie podobnego kodu i wtedy jego twórcy ogłaszają, że to już nie framework tylko “reference application”. Naprawdę użyteczne są tylko te elementy, które można zaimportować do swojego projektu jako biblioteki.

Caught in the Act: Kotlin Bytecode Generation and Runtime Performance

by Dmitry Jemerov

O tym jak bytecode wygenerowany ze źródeł w Kotlinie przekłada się na kod w Javie. Nie znałem wcześniej Kotlina, ta prezentacja to nie był mój pierwszy wybór (ta którą wybrałem została odwołana) i nie przekonała mnie do pisania w Kotlinie. Wydaje mi się, że przynajmniej po części, język rozwiązuje problemy, które istniały tylko do czasu wprowadzenia Javy 8.

Cloud Native Java

The Bootiful Application

by Josh Long

Dwie bardzo podobne do siebie prezentacje z tworzeniem REST-owej aplikacji na żywo, rozpoczynając od szablonu wygenerowanego na start.spring.io. W pierwszej wykorzystane zostały SpringBoot, Eureka, Hystrix i Zipkin. Druga prezentacja była bardziej o konfiguracji samego SpringBoot-a.

Fajnie i zabawnie poprowadzone, make jar not war i zabawy z ascii logiem springowej aplikacji. Tyle tylko, że druga prezentacja wydawała się klonem pierwszej. Identyczny wstęp, te same dowcipy, w dokładnie tych samych miejscach. Zastanawiałem się czy nie wyjść, ale kiedy przebrnęliśmy przez pierwsze dziesięć minut zrobiło się inaczej i znów ciekawie.

Servless Architecture in the Cloud - AWS Lambda

by Tomasz Stachlewski

Napisany w Javie mikroserwis jako AWS lambda. Przykład konfiguracji na Amazon API Gateway  i mapowania parametrów wejściowych HTTP na JSON. Prezentacja zrealizowana trochę z punktu widzenia sprzedawcy Amazona, więc dużo o tym dlaczego warto w ogóle zapłacić za ich usługi.

Machine Learning for (JVM) developers

by Mateusz Dymczyk

Wyszliśmy od definicji podstawowych pojęć używanych w systemach uczących się, a potem prowadzący przeszedł do istniejących rozwiązań dla JVM. Jako warte uwagi wymienił cztery: Spark, Flink, Storm i H2O - są one nowe i moją dość wygodne API.

W Sparku było przygotowane demo. W pierwszej części, na podstawie archiwalnych danych z Google’a, wykorzystując model Linear Regression, Spark usiłował przewidzieć ceny akcji. Wyszło tak sobie, tzn. różnice w cenie były w okolicach 10 dolarów dla skrajnych wartości.

W drugiej części, posiłkując się przykładami spamu oraz normalnych mejli, Spark miał się nauczyć rozpoznawać spam. Tym razem została wykorzystana metoda Logistic Regression With SGD i Spark odniósł sukces, prawidłowo rozpoznając kolejny spam.

Is HBase still a thing?

by Lars George

Trudno powiedzieć. To znaczy może i jest, ale wykład nie zainteresował mnie. Rozpoczął się od przydługiego wstępu o historii komputerów, zmian sprzętowych, wejścia oprogramowania open source, itd. Potem było o architekturze HBase, używanym przez nie formacie plików i zaletach w porównaniu z komercyjnymi produktami (dobrze się skaluje).

Beyond Lambdas - the aftermath

by Daniel Sawano, Daniel Deogun

Przykłady użycia lambd i klasy Optional z Javy 8 oraz problemy, które mogą wystąpić przy ich stosowaniu.

O tym na przykład, żeby nie łamać zasady pojedynczej odpowiedzialności, by zapisać cały kod funkcjonalny w jednej linii.

O problemach występujących przy równoległym przetwarzaniu strumieni. O tym, że przy takim przetwarzaniu należy zwrócić uwagę na zmienne lokalne dla wątków oraz upewnić się, że zależności które mamy (zewnętrzne biblioteki) są wątkowo-bezpieczne.

Navigating ALL the Knowledge

by James Weaver

Prezentacja o ConceptMap. Automatyczne budowanie grafów zależności, znajdywanie relacji (również najkrótszych ścieżek) pomiędzy pojęciami. Wszystko to na bazie wiedzy zgromadzonej i udostępnionej na Wikipedii.

Beyond NoSQL - Go Events / DROP DATABASE

by Jarosław Ratajski

Kosmiczna prezentacja o dwóch grupach deweloperów z różnych wszechświatów. W jednym z nich nadal używa się Hibernate’a. W drugim deweloperzy zauważyli, mniej więcej w okolicy 2003 roku, że mają do dyspozycji wiele rdzeni procesora oraz więcej pamięci i przestali stosować bazy danych, jeśli nie są niezbędne. W obydwu wszechświatach galaktyczna firma dostarczająca pizzę zamówiła u deweloperów system, który będzie przetwarzał 10 000 zamówień na sekundę.

Tak więc w tym lepszym ze światów, deweloperzy pisali kod w Javie używając PriorityQueue. Mieli pewne problemy ze współbieżnością i zapisem danych na dysk, ale szybko je rozwiązali. W drugim świecie deweloperzy wstawiali do kodu adnotacje JPA i tworzyli zapytania do bazy danych.

Potem przyszedł czas na test. System bez Hibernate’a był w stanie przetworzyć 40 000 zapytań na sekundę. Ten z Hibernate dał radę 600. I nawet po optymalizacji, nie udało się zbliżyć do wymagań.

A był to dopiero początek, bo prawdziwe problemy pojawiły się z nowymi wymaganiami dla systemu (“będziemy komponować własne pizze - nie ma problemu, potrzebujemy dwudziestu tabel, żeby to zamodelować”).

Puentą prezentacji było to, że bazy danych i JEE to tak naprawdę pomysły z lat 90. Z czasów gdy pamięć była droga, a komputery dysponowały już dużą ilością miejsca na dysku. I że tak naprawdę, dla większości zastosowań, możemy obejść się bez baz danych.

Introduction to Designing Voice-Driven Experiences

by Staszek Paśko

To miało być przede wszystkim demo Alexy, głosowej asystentki Amazonu. Niestety Alexa nie dawała rady, podobno przez to, że po sali rozchodził się dźwięk z mikrofonu, w którym siebie słyszała. Demo zostało więc przerwane po drugiej czy trzeciej pomyłce, a zamiast niego było więcej slajdów o tym jak wykorzystać Alexę we własnej, mobilnej aplikacji.

What’s Oracle Doing With JavaScript?!

by Geertjan Wielenga

Prezentacja o OracleJET, w szczególności o utrzymywaniu zależności do bibliotek JS w projekcie przy użyciu RequireJS. W drugiej części prezentacji o Two-way Data Binding przy zastosowaniu KnockoutJS.

REST no more use an actor (and Lego and Raspberry)

by Johan Janssen

System zbudowany z Raspberry Pi, pociagów Lego, czytnika RFID (żeby pociąg wiedział gdzie jest) i kamery, jako alternatywa do pisania Hello World, przy testowaniu możliwości języka w zastosowaniach IoT. Demo na żywo jeżdżących pociągów, reagujących na zajście pewnych zdefiniowanych zdarzeń.

A przy okazji porównanie możliwości technologii zdalnych aktorów Akki z serwisami REST, w którym ci pierwsi wypadają znacznie bardziej korzystnie (lepszy czas odpowiedzi - 3300 użytkowników obsłużonych w tym samym czasie, co 600 przez REST).


Java 9 Modularity in Action

by Paul Bakker, Sander Mak

O modularyzacji JDK, która zostanie wprowadzona w Javie 9. Definicje modułów, udostępnionych interfejsów oraz zależności w plikach module-info.java. Nowe parametry poleceń java i javac. Linkowanie z jlink.

Demo z wykorzystaniem modułów, a potem przykład adaptacji istniejącego projektu do Javy 9. W przypadku bibliotek nad którymi nie mamy kontroli, będziemy korzystać z modułów automatycznych, generowanych na podstawie nazwy JAR-a i z wszystkimi interfejsami udostępnionymi publicznie. Jeśli mamy kontrolę nad kodem, generujemy nowy module-info komendą jdeps.

Top 10 Performance Mistakes

by Martin Thompson

To według Martina Thompsona:
10. Not upgrading

9. Duplicated work - tu został podany ekstremalny przykład kodu, który 7000 razy odpytywał bazę danych po jednym request’ie, ponieważ wykonywał jedno i to samo zapytanie w pętli.

8. Data Dependent Loads aka Pointer Chasing - sekwencyjny dostęp do pamięci jest szybszy od losowego, ale nawet ten jest wielokrotnie szybszy od dostępu w którym kolejny adres zależy od poprzednich wyliczeń. To w związku z przewidywaniem przez współczesne procesory kolejnych instrukcji. Było o tym, żeby wybierać właściwe kolekcje i potrzebie porządnej implementacji hashCode (bo inaczej HashSet/Map zmieniają się coś w rodzaju LinkedList).

7. Too Much Allocation - alokacja jest prawie darmowa, ale odzyskiwanie pamięci już nie, ze względu na działanie GC. Ponadto zbyt wiele alokacji lub kopiowania danych czyści cache procesora.

6. Going Parallel - z każdym kolejnym wątkiem dodajemy złożoności i powinniśmy zastanowić się czy tego naprawdę potrzebujemy, porównując szybkość przetwarzania wielowątkowego z szybkością działania pojedynczego wątku.

5. Synchronous Communication - marnujemy czas oczekując na odpowiedzi serwera.

4. Not understanding TCP - to rozwinięcie poprzedniego punktu. W szczególności jednak, ze względu na Algorytm Nagle'a, komunikat klienta może w ogóle nie zostać wysłany do serwera, przez co będzie wielokrotnie ponawiany.

3. Text Encoding - przesyłamy dane w tekstowych formatach (JSON, XML, Base64), bo tak jest nam go łatwiej przeczytać w trakcie debuggowania. Marnujemy czas procesora potrzebny na kodowanie/dekodowanie informacji. Lepiej używać Wiresharka.

2. API Design - przykład poniżej
Źle:
public String[] split(String regex)
Lepiej:
public Iterable<String> split(String regex)
ponieważ w tym drugim przypadku nie ma alokacji tablicy o nieznanym rozmiarze.

1. Logging - ponieważ popularne loggery używając locków, zmieniają nawet współbieżne aplikacje w coś co wykonuje się jak w jednym wątku. Czasem wszystko co robią to sprawdzenie, czy debugowanie jest w ogóle włączone. Powodują też, że kompilator ma problemy z wstawianiem metod inline.
Lepiej zapisywać zdarzenia, ale tak żeby wiedzieć kiedy i jak wiele razy jakiś wyjątek wystąpił, nie zapisywać w logach całego stosu, ponieważ jest to informacja która się powtarza. Raporty o błędach mogłyby być zapisywane do plików i odczytywane przez inne procesy.
Do debuggowania lepiej też wykorzystywać narzędzia, które wstawiają instrukcje do kodu w trakcie wykonania aplikacji - jak Byte Buddy.

Stoiska


IG postawiło na odstresowujące kaczki, ale zainteresowanie utrzymywało się tylko przez pierwszy dzień. Były rozdawane pendrive’y, notesy, piwo i inne gadżety. Lepsze nagrody można było wygrać w konkursach z kodem, prostą matematyką czy krzyżówkami. Zawiodłem się na Sii, które zebrało dane osobowe kilkuset osób, a potem losowało nagrody w czasie gdy trwały jeszcze niektóre wykłady. Zamiast kontaktować się telefonicznie z wygranymi, jak robiły to inne firmy, losowano kolejnych. Rósł stos odłożonych na bok “zwycięzców”, a oni dalej losowali. Kto wie może też tam wygrałem, znalazłem się na miejscu pod koniec losowania.

Kolejki ustawiały się do koła fortuny jednej z firm, gdzie można było wygrać power banki, pendrive’y, koszulki i skarpetki. Wszyscy próbowali wielokrotnie, a w pierwszych dniach naprawdę coś tam ciekawszego zdobyłem. Ostatniego dnia wygrałem “prezent”, czyli dowolny przedmiot do wyboru. Na stoisku były w tym czasie już tylko damskie koszulki, skarpetki i długopisy. Nie były to moje pierwsze skarpetki, więc jeszcze kilka dni i nie musiałbym ich już nigdy więcej kupować.