Konferencja odbyła się w Centrum Konferencyjnym Muranów w Muzeum Historii Żydów Polskich. Miejsce bardzo ładne, wszystko nowe, a samo muzeum ponoć zdobyło w 2016 roku jakąś nagrodę najlepszego muzeum w Europie. Ekran na którym pokazywano prezentację był wielki jak na sali kinowej, a głos prelegentów tak czysty, jakby stali tuż obok.

Swoją obecnością i krótką przemową na początek zaszczycił nas wiceprezydent Warszawy, Michał Olszewski. Całość prowadził zawodowy konferansjer, który sprawował się całkiem nieźle, oprócz dwóch wpadek, kiedy skofundował niemieckiego prelegenta tekstem, który mógł zostąć odebrany jako delikatnie ksenofobiczny, i kiedy sypnął innym tekstem, który mógł być odebrany jako seksistowski względem jedynej na konferencji prelegentki. Słowem – nie było źle, ale mógłby mieć trochę więcej klasy.

Merytorycznie wystartowaliśmy kilka minut po dziewiątej, i to od razu z wysokiego C.

Sesja 1

Pierwsza prezentacja to klasa sama w sobie. Paweł Szulc zrobił równie wspaniały show, jak w tamtym roku. Wtedy było o monadach i bardzo ubolewałem, że ostatecznie prezentacja nie znalazła się na Youtube, może w tym roku będzie inaczej.

A w tym roku prezentacja Pawła Szulca była o typeclasses: Having a cake and eating it too. Introduction to typeclasses. Skonstruowała została po mistrzowsku. Mieliśmy nie tylko pasjonującą fikcyjnego historię senior developera w trudnym czasie, kiedy nastąpiła awaria Stack Overflow i Google, i musiał kodować inspirując się starą książką z programowania obiektowego. Mieliśmy przede wszystkim też świetnie skonstruowany z pedagogicznego punktu widzenia flow prezentacji. Najpierw zostaliśmy postawieni przed problemem, potem śledziliśmy poczynania bohatera, śmialiśmy się od czasu do czasu, a w międzyczasie dowiedzieliśmy się, czym są type classes i zobaczyliśmy modelowy przykład ich wykorzystania. Wielkie brawa, dla mnie to bez dwóch zdań najlepsza prezentacja na tym Scalarze.

A czym są takie type classes? W uproszczeniu można powiedzieć, że to takie implcit class, które służą do tego, żeby opakować istniejącą klasę nową funkcjonalnością. Czyli to takie dekoratory na istniejące klasy, ale ponieważ wszystko dzieje się w tle, wygląda to tak, jakby sama klasa miała daną metodę.

Druga prezentacja też miała bardzo wysoki poziom i była wciągająca, choć nie tak porywająca z fabularnego punktu widzenia. Swave – a fresh reactive streams implementation Mathiasa Doenitza była o nowej bibliotece na streamach – prezenter i jednocześnie autor, wypuścił ją jako Open Source w dniu prezentacji. Choć dużo rzeczy jest do zrobienia, biblioteka już teraz zapowiada się ciekawie. Oprócz standardowych operacji na streamach, pozwala też na rozdzielanie i łączenie streamów, a wszystko w pięknej notacji, do której przyzwyczaiły nas scalowe kolekcje.

Sesja 2

Druga sesja to trzy prezentacje, na których trzeba było włożyć sporo wysiłku, żeby nadążyć (zwłaszcza na pierwszej i drugiej).

Eric Torreborre w The Eff monad, one monad to rule them all pokazywał monadę, która może uogólniać wszystkie inne monady (tak przynajmniej to zrozumiałem). Krzysztof Romanowski w Incremental compiler: taming scalac pokazywał, jak działa kompilacja inkrementalna w sbt. Wreszcie Maciej Biłas w prezentacji Akka-cluster-etcd pokazał swój (i kolegi) pet project na deployowanie klastra Akki.

Sesja 3

Po przerwie obiadowej Łukasz Lenart stworzył aplikację w Lifcie (Lift Framework in 30 minutes). Potem była prezentacja o Shapeless – z gatunku tych, kiedy dopiero pod koniec wszystko zaczyna wskakiwać na swoje miejsce i zdajesz sobie sprawę z tego, że to, co mówił prelegent jest genialne, choć jeszcze do końca nie rozumiesz, o co w tym chodzi. To wszystko w Shapeless? Easy! Valentina Kasasa.

Na koniec sesji trzeciej prezentacja jedynej kobiety w gronie prelegentów: IoT, timeseries and prediction with Android, Cassandra and Spark. Amira Lakhal wyznała, że jest nałogową biegaczką i dwa tygodnie wcześniej przebiegła swój pierwszy maraton. Ma to znaczenie, bo treść prezentacji była niejako z tym związana.

Pokazany został proof on concept systemu składający się z aplikacji na Androida, restowej usługi w Spring Boocie, bazki Cassandry i do tego aplikacji w Sparku, wykorzystującej uczenie maszynowe. Aplikacja na podstawie wskazań żyroskopu w telefonie rozpoznawała, czy właściciel siedzi, chodzi, czy biega.

Byłem pod wielkim wrażeniem – choć to tylko proof of concept, trzeba było zrobić mnóstwo rzeczy i zintegrować ze sobą. A w dodatku prezentacja zakończyła się demonstracją.

Autorka stała przez chwilę z telefonem i aplikacja pokazywała, że właściciel telefonu stoi w miejscu. Potem Amira Lakhal przeszła się kawałek, Spark ciągle wypluwał mnóstwo logów, a stronka z aplikacją WWW przeładowała się i pokazała informację, że właścicielka telefonu w tej chwili chodzi. Wreszcie prelegentka przebiegła się po scenie (podeście?) i kiedy pokazała się informacja o tym, że w tej chwili biegnie, została nagrodzona gromkimi brawami.

Sesja 4

Kolejną prezentację robił Człowiek, Który Wie, Bo Sam To Robił. Dmytro Petrashko, doktorant u Martina Oderskiego w prezentacji Making sense of initialization order in Scala opowiadał o tym, jak przypisywane są wartości do zmiennych w traits i klasach. Oczywiście było kilka niemiłych niespodzianek, związanych z tym, jak działa kompilator Scali:

• val w rzeczywistości po kompilacji nie jest wcale final. Kompilator tworzy w klasie pole i settera, który wywoływany jest w trakcie inicjalizacji.
• final val i = 3, czyli inicjalizacja finalnej zmiennej bez side effects zostanie skompilowane jako metoda zwracająca stałą wartość (przypisywana jest wartość primitive, a nie rezultat jakiegoś wywołania, więc kompilator wie, że nie będzie side effects). Innymi słowy, w tym wypadku (i z tego, co rozumiem) jest to to samo, co def i = 3.
• Nie używaj lazy vals, jeśli nie musisz (w tym po kompilacji zaszyte są synchronized, które znacząco zmniejszają wydajność).
• Nie przeciążaj val, jeśli nie musisz.

O tym ostatnim w sumie już coś kiedyś czytałem i jeśli wiem, że coś ma być przeciążone, robię to jako def, ale Dmytro Petrashko wytłumaczył mi dlaczego. Przykład:

trait A {
  val a = 5
}

class B extends A {
  println("Value a is: " + a)
  override val a = 7
}

val b = new B

Czy będzie błąd kompilacji? Nie. Czy wyświetlone zostanie Value a is: 5? Nie. 7? Też nie. Wyświetlone zostanie 0.

Dlaczego tak się dzieje?

W momencie tworzenia instancji B, najpierw zostanie zadeklowany artybut klasy a typu Int. Ponieważ wartość w a jest przeciążąna, nie zostanie ustawiona wartość z trait A na 5. W a zostanie wartość domyślna – dla int z jvm jest to 0. W momencie wykonania println, w a ciągle jest ta domyśna wartość. Dopiero potem wywołany jest setter, który do a wrzuci siódemkę.

Kiedy ma się sporo traits ze zdefiniowanymi val, które są przeciążane, nietrudno nawet o NullPointerException, bo przecież null jest domyślną wartością dla typów, które nie są primitive. Kiedyś właśnie miałem takie problemy z NPE, w efekcie czego przestałem przeciążać vals.

Uff, wracam do Scalara. Druga prezentacja w tej sesji to Cool toolz in the Scalaz and Cats toolboxes Jana Pustelnika. Czego się nauczyłem? Że często wydaje się, że Scala jest taka zwięzła i piękna, ale są biblioteki, które mogą zrobić z niej jeszcze piękniejszą. Scalaz jest już trochę przestarzałe, ale w Cats – bliźniaczej bibliotece – są te same funkcje, operatory, czy klasy, które mogą sprawić, że kod Scali będzie jeszcze bardziej czytelny.

Sesja 5, ostatnia

Przyznaję, że byłem już trochę zmęczony. Być może dlatego prezentacja Contracts first, session types later Marko Borsta i Slava Schmidta kompletnie do mnie nie przemówiła. Niby był pokazywany kod, niby coś było omawiane, ale o czym była ta prezentacja? Nie wiem.

A potem Scala SWAT: tackling 1 billion member social network Artura Bańkowskiego. Bardzo konkretna i mięsista prezentacja o tym, jak poradzono sobie z tak wielką ilością danych w miesiąc, korzystając z Neo4j i ElasticSearch.

Czego się nauczyłem

Czyli innymi słowy, jakie mam ogólne wnioski po całej konferencji:

• Stosuję za mało typeclasses i pewnie niepotrzebnie ograniczam korzystanie z implicits. Zawsze mi się wydawało, że one dość mocno zaciemniają kod i utrudniają debugowania, ale teraz widziałem mnóstwo zalet, że muszę zmienić swoje nastawienie.
• Teraz już na pewno wiem, że nie mogę przeciążać vals, a powinienem też ostrożnie obchodzić się z lazy vals.
• Powinienem przynajmniej spróbować Shapeless.
• Powinienem zacząć stosować Cats.

I takie są mojej postanowienia po tej konferencji. Pełny entuzjazmu piszę ten post na gorąco w pociągu i jestem pełen zapału, żeby od poniedziałku kodować lepiej.

(Tak powinno być po każdej konferencji).