| Autor: | Wojciech Muła |
|---|---|
| Dodane: | 2016-01-16 |
Treść
Na jakimś wrocławskim wykładzie, jeszcze w 2015 roku, o konferencji Boilingfrogs powiedział mi kolega Krzysiek (który opowiadał tam o SOLID). Jako, że postanowiłem nie marnować takich okazji, więc zapisałem się. I właśnie wróciłem. Wyjątkowo autobus linii 409 nie utknął w korkach — niby sobota, ale to Wrocław i różnie mogło być. Słucham sobie tytułowego utworu z płyty "On An Island" Davida Gilmoura i piszę, póki nie zapomniałem (jeszcze tylko herbata i lecimy).
Więc[1] ta jednodniowa konferencja odbyła się w budynku o dumnej nazwie Silver Tower Center[2], który jest nie tylko interesujący architektonicznie, ale przede wszystkim położony w dogodnym miejscu. Blisko dworca PKP i autobusowego, dość blisko Rynku, świetnie skomunikowane. Ja co prawda miałem trzy przesiadki i 15 minut pieszo, ale to tylko dlatego, że mieszkam w dość odległym miejscu (hm, zadupie jest nieodpowiednią nazwą, to jeszcze Wrocław) i z racji weekendu autobusy jeżdżą rzadziej[3].
Była to pierwsza edycja Boilingfrogs. Konferencja była płatna, lecz kwota naprawdę symboliczna, bo jakieś 80 złotych. Organizacyjnie pierwsza klasa. Przede wszystkim porządna strona internetowa, bezproblemowa rejestracja, potrzebne informacje zostały przesłane na maila[4]. Na miejscu była darmowa kawa, herbata, ciasteczka oraz obiad[5]. Do tego wszystkie wykłady zaczynały się punktualnie. Miło, naprawdę.
Słowo-klucz konferencji to "craftsmanship", co wg słowników znaczy skill in a particular craft i na nasz przepiękny język tłumaczy się jako rzemiosło. Ja jednak wolę rękodzieło. W końcu tymi ręcami piszemy te wszystkie mało znaczące ciągi literek.
Organizatorzy zapewnili 5 wykładów w 3 ścieżkach, czyli 15 do wyboru. Mam jednak wątpliwości, czy to po prostu nie za duży wybór. Z 2/3 wykładów trzeba było zrezygnować.
Niekiedy z niemałym trudnem wybrałem następujące wykłady:
Poniżej spisałem moje wrażenia. Nie jestem dziś złośliwy, chyba Gilmour działa tak uspokajająco.
Przeglądam regularnie Hacker News, słowo "monada" pojawia się tam często. Ogólnie jest hype. Jednak ilekroć o tym czytałem, miałem wrażenie, że to za proste, że to nie może być aż tak trywialne. Mój wniosek jest taki, że to dorobienie ideologii do banału[6].
Miałem nadzieję, że wykład Marcina da mi jasną odpowiedź, że to ja czegoś naprawdę nie rozumiem, coś istotnego mi umyka. Niestety, tak się nie stało. Marcin poopowiadał trochę i pokazał praktyczną realizację monad w C# i F#. W sumie potwierdził, co już wiedziałem. Jedynym plusem stosowania monad było uproszczenie kodu, zarówno w imperatywnym C# jak i funkcyjnym F#. A tak naprawdę przeniesienie if w jedno miejsce.
Z mojej perspektywy najciekawsze było jedno z pytań z sali. Kolega przyznał, że uwielbia monady, że używa, ale... kod jest trudny w debugowaniu. Piękna rekomendacja.
Nie podobały mi się dwie rzeczy na tym wykładzie:
Tytuł prelekcji był nieco mylący. Tomek opowiedział tak naprawdę o jednej strukturze danych, ale za to takiej! Otóż nie słyszałem o niej. Prelegent i organizator konferencji w jednym, opisał dość dokładnie kolejki i kolejki zrównoważone Osakiego. Interesujące i inspirujące, jako że struktury danych to jedna z moich ulubionych działek w informatyce (plasują się tuż za zdjęciami kotków w Internecie).
W drugiej części wykładu Tomek pokazał jak w praktyce git używa persystentnych drzew. Akurat o tym kiedyś czytałem, ale całkiem zaskakująca była konstatacja, że tak nieskomplikowana struktura stoi u podstaw jednego z fajniejszych narzędzi[7].
Prelegent na przykładzie prostej gry w węża (działała, był pokaz na żywo!) zademonstrował jak używać strumieni. Strumienie, to jak nazwa sugeruje, ciągi jakiś obiektów. Najciekawsze, że za pomocą kilku prostych operacji na strumieniach można je łączyć w skomplikowane systemy. Bardzo mi się podoba! Za pomocą trywialnych przekształceń, zdaje się 5 czy 6, można budować mocno nietrywialne rzeczy. Siła wyrazu, o! to jest dobre określenie.
Do tego istnieją frameworki, które dramatycznie uproszczają praktyczne zastosowanie. Michał pracuje nad systemem, gdzie strumienie są używane do wizualizacji w przeglądarce aktualnego stanu jakiegoś obiektu przemysłowego (magazynu? nie pamiętam... przepraszam).
Prezentacja była bardzo dobra. Prelegent wiedział o czym mówi, miał doświadczenie w tym temacie i fajnie się go słuchało.
Tomek opowiadał o swoich doświadczeniach z testowaniem, głównie testowaniem integracyjnym systemów sieciowych. Prelegent jest programistą Javy, przykłady były w tym języku, jednak to w niczym nie przeszkadzało.
Bardzo spodobał mi się pomysł enkapsulowania akcji specyficznych dla każdego systemu zewnętrznego i użycia fraz zapożyczonych z BDD. Sami zobaczcie (spróbujcie przeczytać na głos):
whenInMainSystem.createUser(); whenInExternalSystem.receiveNotification(); thenInAnotherExternalSystem.coffeeIsReady();
Każdy podsystem reprezentuje inny obiekt określonej klasy, posiadającej specyficzne fragmenty testów lub sekwencji akcji. Całkiem dobrze się to czyta[8]. Tomek wspomniał, że testują integracyjnie także na poziomie protokołu sieciowego (HTTP). Nie zdążyłem zapytać, czy testują także błędy samej komunikacji (np. zerwanie połączenia, błędy w rodzaju 500) bądź bezsensowne odpowiedzi serwisów zewnętrznych. Ale myślę, że to wykonalne.
Fundamentalnie nie zgadzam się jednak z jednym stwierdzeniem, że pokrycie kodu nie jest istotne i można żyć z niską jego wartością. Nie, przy testowaniu jednostkowym 100% pokrycie kodu to podstawa. Trudne, nie zawsze wykonalne, ale do tego trzeba dążyć. Ile razy nacięliście się na błędy, bo coś tam było niedotestowane w kluczowym module? Mnie się zdarza, bo "po co testować, to tak mało prawdopodobne, weź się".
Ale ogólnie wykład fajny, ciekawe doświadczenia i wnioski.
Generalnie Witek opisał swoje doświadczenia z pracą w zespołach, które słabo dawały sobie radę z powodu nadmiernego obciążenia bądź istnienia wąskich gardeł. Jeden z przykładów takiego wąskiego gardła: 60 programistów + tylko 8 doświadczonych, uprawionych do code review i mergowania — i tylko to robili przez kilka miesięcy[9].
Arcyciekawy był sposób na poradzenie sobie ze słabą wydajnością zespołu. Wystarczyło zmniejszyć liczbę zadań (niewyobrażalne dla menadżera), co spowodowało zmniejszenie obciążenia ludzi, ale podniosło ogólną przepustowość. Efekt sprzeczny z intuicją, nieprawdaż.
Było całkiem interesująco.
Mariusz opowiedział nieco o Machine Learningu, obecnie gorącym temacie. Oczywiście był to wykład wprowadzając, ale Mariusz pokazał co jest istotne z punktu widzenia praktycznego. Jednym z kluczowych problemów jest dobre zrozumienie danych. Przerobiliśmy to na przykładowym, na pierwszy rzut oka, nieskomplikowanym przykładzie. Pouczające doświadczenie.
Prelegent pokazał też, że istnieje obecnie wiele darmowych narzędzi do ML (bibliotek, system, itd.), wiele przykładowych zbiorów danych itd. Ten próg wejścia z technicznego punktu widzenia jest więc niewielki. Schody zaczynają się, gdy trzeba z tych narzędzi umiejętnie skorzystać. I to było zadanie domowe dla chętnych.
Ciekawie, chociaż siłą rzeczy mocno pobieżnie. Chciałoby się więcej.
| [1] | „Nie zaczyna się zdania od więc” — jedyna rzecz, którą wiedzą polonistki płci obojga. |
| [2] | Jest to nazwa tradycyjnie słowiańska. Ale najśmieszniejsza w tym budynku jest Biedronka na parterze i za każdym razem, gdy widzę Srebrną Wieżę, ten fakt mnie autentycznie bawi. Doprawdy, brakuje tam jeszcze lumpeksu. |
| [3] | Wiadomo, że w weekendy mieszkańcy Wrocławia w ogóle nie chcą nigdzie się przemieszczać, siedzą w domach i czekają spokojnie na śmierć. Albo oglądają TV, co na jedno wychodzi. |
| [4] | Myślicie, że to standard? W przypadku pewnej konferencji musiałem pisać do organizatorów, czy na pewno jestem na liście, bo nie dostałem żadnego potwierdzenia. |
| [5] | Z różnych względów przez klawiaturę mi nie przejdzie słowo "lunch", przykro mi. |
| [6] | Co wydaje się dość częstą praktyką w IT. |
| [7] | W obecnej pracy używam Mercuriala. Po przesiadce z gita to jednak krok wstecz. |
| [8] | Modulo konwencja nazewnicza, ja nie lubię camelCase, brzydkie jak Mielno w grudniu. |
| [9] | Przypomniała mi się wtedy sytuacja z mojej poprzedniej pracy, gdzie przez dwa sprinty zajmowałem się wyłącznie poprawianiem błędów, a koledzy wtedy radośnie robili nowe funkcjonalności. Brrr, nigdy więcej. |