Znalezione w skrzynce: Do czego mi Clojure?

Właśnie dostałem do skrzynki maila, który odzwierciedla większość pytań i wątpliwości, jakimi zarzucają mnie moi rozmówcy w temacie Clojure. Postanowiłem opublikować moją odpowiedź, która specjalnie nie wnosi nic nowego w temacie, ale być może zainspiruje do ciekawej dyskusji o sensowności...właśnie! Czego ta sensowność miała by dotyczyć?! Pytanie pozostawiam otarte.

> Na pikniku rzuciłeś pytanie "W jaki sposób przekonać programistów Javy do
> użycia Clojure w swoich projektach?". Poczytałem trochę na ten temat i
> jedyne co mi nie pozwala używać tego języka to to, że po prostu nie mam
> czasu na naukę nowych języków. Musisz wziąć pod uwagę to, że ja reprezentuje
> jak to powiedziałeś "żółtodziobów" (chociaż za takiego się nie uznaję). Ja
> swój czas zamierzam poświęcić na naukę technologi takich jak Spring , JPA,
> JSF,EJB, SQL itd. Są to technologie które najczęściej występują w
> ogłoszeniach o pracę i jest ich tak dużo że nie ma czasu na naukę Clojure.

Cześć XXX,

Święta racja! W zasadzie nic dodać nic ująć, ale zastanów się, ile
osób tak myśli. Sądzę, że cała masa. Właściwie nawet więcej, co
sprawia, że przebicie się na lidera w tej grupie jest zadaniem
wymagającym dużego nakładu pracy. A może by tak warto rozważyć
poświęcenie nie mniej czasu na coś odmiennego, co sprawi, że jeśli
wartościowe (podkreślam słowo "jeśli") da Ci gwarantowaną przewagę.
Czy w takim świetle Clojure wypada ciekawiej?

> -powiedział ile czasu zajmie nauka Clojure
> -powiedział jak szybko można zrobić coś co działa w Clojure
> -do czego ten język wykorzystuje się w praktyce, jakiś konkretny przypadek w
> którym Clojure jest bez cenny ( bo jak sam stwierdziłeś że przykład z
> wyświetlaniem daty nie za bardzo wszystkich przekonał)
> -zapewnił że użycie Clojure jest stabilne, można go obdarzyć zaufaniem
> To prawdopodobnie kupił bym Clojure In Action i zaczął przerabiać kolejne
> rozdziały.

Czy potrafiłbyś odpowiedzieć na te pytania, gdyby zamiast Clojure
występowało Java lub inny język programowania? Celem Clojure było
przybliżenie programowania funkcyjnego do platformy Java i wielu
przypadło to do gustu. Jak to bywa, znalazło się też wielu, którym
niekoniecznie. Trudno powiedzieć, kto ma rację, bo gdyby tak było, nie
byłoby tylu języków programowania.

Nie oczekuj od innych, że powiedzą Ci, jak masz żyć. To Twoje życie,
Twoje wybory i co dla jednego wpadką, dla innego sukcesem. Wszystko
zależy od nastawienia. Moje jest otwarte na nowe, a że udaje mi się
zwykle trafiać w ciekawe technologie/języki, nie obawiam się o własną
przyszłość znając Clojure. Na pewno poszerza horyzonty.

> Ogólnie Java jest językiem w którym można zrobić wszystko i należało by
> wskazać taką rzecz która w Javie jest za obszerna. Jakieś porównanie ile to
> trzeba się na główkować w Javie a w Clojure robi się to w prosty sposób i
> można się zająć innymi rzeczami.

Weźmy trywialne przechodzenie po liście. A teraz pomyśl, że to cały
strumień danych. Współbieżność. Zwartość kodu funkcyjnego jest nie do
przecenienia w porównaniu z obiektowym. Oba jednak mają swoje plusy i
minusy.

Zbiegi okoliczności wokół Android 4.1 Jelly Bean

Android 4.1, Jelly Bean "spotykam" na każdym kroku. Poza technicznymi detalami, które udaje mi się wyłapać podczas lektury artykułów, trafiłem ostatnio na informację o przygotowaniach do wydania Android 4.1 na Samsung Galaxy S II. Wcześniejsza zajawka o aktualizacji do 4.0.4 sprawiła, że przez tydzień sprawdzałem co godzinę, czy jest coś dostępnego. W przypadku Jelly Bean, odpuszczam. Na razie nie widzę powodów, abym potrzebował go. Jak będzie to będzie. I od razu mniej problemów na głowie.

A tu proszę. Wychodzę na spacer z Maksymem, a tu na telefonie informacja o dostępnej aktualizacji! Ni z gruszki ni z pietruszki pojawia się aktualizacja! Bajka!

Cóż było robić, aktualizacja ruszyła. Po 10 minutach telefon był już gotowy do ponownego użycia.

Jakby na dokładkę, w drodze powrotnej trafiłem na...

I jak to nazwać? Zbieg okoliczności? Próba zwrócenia na siebie uwagi? Ech, Androidzie, już do Ciebie wracam :)

j.piknik z programowaniem funkcyjnym w Clojure

Koniec wakacji zbliża się nieuchronnie i widać ruch w interesie konferencyjnym. Najbliższa konferencja j.piknik już 30 sierpnia w Warszawie, podczas której wystąpię z tematem "Programowanie funkcyjne z Clojure (w przykładach)". Zaczynam o 16:20.

Celem prezentacji jest stworzenie prostego projektu w Clojure zarządzanego przez lein2 oraz informacyjnie konfiguracja dla Apache Maven 3, aby później użyć go w aplikacji javowej. W tej konfiguracji chciałbym pokazać, że elementy naszej aplikacji może być łatwiej oprogramować w Clojure, aby później użyć ich w głównej aplikacji javowej jako biblioteki zależne. Widać wyraźnie, że główny nacisk będę kierował do programistów javowych, których nosi w stronę języków alternatywnych. Sam ostatnio borykałem się z podobnym problemem (jak tu wprowadzić Clojure do projektu, w którym króluje Java) i wydaje mi się, że jest to podstawowy problem wielu z nas (= programistów javowych).
Jako środowiska programistyczne będą zaprezentowane Eclipse IDE + CCW (wtyczka do Clojure, Clojure REPL i informacyjnie Sublime Text 2.

Strona wydarzenia dostępna na facebooku.

Zachęcam do zadawania pytań w komentarzu, abym przygotowany mógł odpowiedzieć na nie podczas prezentacji lub po. Zapraszam i do zobaczenia!

O tym jak DelayQueue realizuje kontrakt Iterable oraz BlockingQueue

W poprzednim wpisie Króciutko o j.u.concurrent.DelayQueue zaprezentowałem dosyć uproszczony przykład zastosowania java.util.concurrent.DelayQueue, w którym kolejka ukrywała elementy nieaktywne, co w tym konkretnym przypadku oznaczało wszystkie elementy. DelayQueue jest najzwyczajniej w świecie kolejką, która posiada dodatkową cechę, która pozwala na "widoczność" elementów, których czas "zamrożenia" minął. Stąd też, nieblokująca metoda poll() zwracała specjalną wartość - null - oznaczającą niemożność wykonania, tj. natychmiastowego zwrócenia elementu z kolejki.

Klasa j.u.c.DelayQueue posiada następujące cechy:

• jest kolejką
• jest nieograniczona (metoda remainingCapacity() zawsze zwraca Integer.MAX_VALUE)
• jest blokująca (niektóre operacje manipulujące elementami kolejki, np. wspomniane poll() czy take())
• operuje wyłącznie elementami typu j.u.concurrent.Delayed.

Zagłębiłem się w javadoc tej klasy i znalazłem inne ciekawostki, które przykuły moją uwagę. Oto przykład z nimi, a Twoim zadaniem jest odpowiedź na pytania w komentarzach. Miłej lektury!

package pl.japila.java7;

import java.util.concurrent.DelayQueue;
import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;

public class DelayQueueMain {

    static class Conference implements Delayed {

        long delay;

        public Conference(long delay) {
            this.delay = delay;
        }

        @Override
        public int compareTo(Delayed o) {
            Conference c = (Conference) o;
            return this.getDelay() < c.getDelay() ? -1 : this.getDelay() == c.getDelay() ? 0 : 1;
        }

        @Override
        public long getDelay(TimeUnit unit) {
            return getDelay();
        }

        public long getDelay() {
            return delay;
        }

        @Override
        public String toString() {
            return String.format("Conference starts in %s days", getDelay());
        }

    }

    public static void main(String[] args) {
        DelayQueue<Conference> conferences = new DelayQueue<Conference>();
        conferences.add(new Conference(5));
        conferences.add(new Conference(10));
        conferences.add(new Conference(15));

        System.out.println("Head (delay expired furthest in the past) element: " + conferences.poll());

        // Q1: Jakie elementy zostaną wypisane na ekran?
        for (Conference conf : conferences) {
            System.out.println(conf);
        }

        // Q2: Jaki efekt po wykonaniu poniższej linii?
        System.out.println(conferences.element());

        // Q3: Co się stanie tutaj?
        conferences.add(null);
    }

}

Króciutko o j.u.concurrent.DelayQueue

Kolejny raz potwierdza się zasada, że kto czyta, nie błądzi. W przypadku pakietu java.util.concurrent możnaby powiedzieć, że jest to najbardziej nieprzestrzegana zasada, której hołduję od jakiegoś czasu i zamiast przysiąść nad dokumentacją javadoc, pozwalam sobie na poznawanie jej wyłącznie przy okazji i to w tak niewielkich dawkach, że byłoby grzechem nazwać je wykraczającymi przyzwoite minimum.

Na szczęście przyszło mi recenzować nadchodzącą książkę o java.util.concurrent - Java 7 Concurrency Cookbook z wydawnictwa Packt, więc chciał, czy nie chciał, jestem zaangażowany i poznaję.

Mojemu Maksymowi stuknęło 10 miesięcy! Postępy jakie robi we własnym rozwoju często są niezwykle zaskakujące i chciałbym móc to samo powiedzieć o swoim w kontekście j.u.concurrent. Przez ostatni miesiąc nauczył się sprawnie raczkować, siadać, wstawać, a nawet zaczyna chodzić asekurowany, czy to meblami czy przez inną osobę. Zaczyna mówić i od kilku dni daje się słyszeć blablabla, mama, czy inne dźwięki, których opisanie uważam za niemożliwe. Rozumie frazy: biedronka, nie, wypluj smoka, gdzie...?, lampa, daj, chodź, piciu piciu, am, otwórz buźkę i jeszcze kilka innych. Zaczęliśmy go przyzwyczajać do mycia zębów, bo przy 4 zębach i kolejnych 4 wychodzących, nie daje nam innego wyboru. Jada chętnie, dużo pije i ogólnie cacy. Oby tak dalej! A mówią, że nic nie trwa wiecznie :(

Gdyby przełożyć jego rozwój na mój w kontekście j.u.concurrent, to ja dopiero zacząłem raczkować. Pora to zmienić, bo za moment, to nie ja jego, ale on mnie będzie wychowywał. A jak Wam idzie poznawanie nowego API? Korzystacie z niego regularnie czy tylko z doskoku i to w ramach własnych, prywatnych projektów?

Na zakończenie krótki przykład z klasą, o istnieniu której dowiedziałem się właśnie z książki. Oto, proszę Państwa, wchodzi java.util.concurrent.DelayQueue. Trzeba było widzieć moją minę, kiedy przeczytałem o tej klasie, a nigdy wcześniej nawet słowa o niej nie czytałem. Niedobrze z moją znajomością Javki.

Pytanie kontrolne: Co będzie wypisane na ekran po uruchomieniu poniższej klaski?

package pl.japila.java7;

import java.util.concurrent.DelayQueue;
import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;

public class DelayQueueMain {

    static class Conference implements Delayed {

        long delay;

        public Conference(long delay) {
            this.delay = delay;
        }

        @Override
        public int compareTo(Delayed o) {
            Conference c = (Conference) o;
            return this.getDelay() < c.getDelay() ? -1 : this.getDelay() == c.getDelay() ? 0 : 1;
        }

        @Override
        public long getDelay(TimeUnit unit) {
            return delay;
        }

        public long getDelay() {
            return delay;
        }

    }

    public static void main(String[] args) {
        DelayQueue<Conference> conferences = new DelayQueue<Conference>();
        conferences.add(new Conference(5));
        conferences.add(new Conference(10));
        conferences.add(new Conference(15));

        System.out.println("Head (delay expired furthest in the past) element: " + conferences.poll());
    }

}

Kilka ciekawostek z Java Concurrency API w Java 7 od Packt

Trudno mi było uwierzyć, że dałem się namówić na kolejną recenzję książki z wydawnictwa Packt. Nie jestem ich fanem, a ich książki są zwykle zbyt lekkie merytorycznie, aby kilka ciekawostek, których doszukanie się i tak zajmuje sporo czasu, było w stanie zrekompensować mój ból.

Tym razem jestem mile zaskoczony zawartością planowanej książki o współbieżności w Java 7 - Java 7 Concurrency Cookbook. Wydaje się być odpowiednio dopasowana merytorycznie do moich potrzeb, a że o współbieżności mowa (z którą mam niezwykle rzadko okazję się spotykać), tym lepiej dla niej (i mnie)!

Jako recenzent techniczny odpowiadam za jej właściwą zawartość merytoryczną i jakkolwiek pierwszy rozdział mógłbym z uciechą wrzucić do kosza, to kolejne zdają się bronić bez większego problemu.

Mam za sobą przeczytane 3 rozdziały (z ośmiu) i zaczynam z niecierpliwością oczekiwać lektury kolejnych. Właśnie w rozdziale 3 pojawiły się java.util.concurrent.CyclicBarrier oraz mój ulubieniec z Java 7 - j.u.c.Phaser.

Sposób przekazywania wiedzy przez autora nie nastraja do zagłębniania się w treść, a raczej służy jako zajawka do dalszego studiowania na własną rękę. Najbardziej "rozbraja" mnie prezentacja kodu źródłowego, który poszatkowany jest na kilkanaście punktów, które okraszone są skromnym opisem, często wręcz trywialnym nawet dla laika. Zatem, czytasz co będzie, demonstracja tego, co miało być i kolejny punkt. Dodając do tego, opisywanie konstrukcji "Stwórz klasę, która implementuje Runnable" i pojawia się kawałek początku klasy z "implements Runnable" i ręce opadają. Trzeba przywyknąć.

Z ciekawostek, które musiałem sprawdzić na własną rękę, zanim wprowadziłem zmiany w obecnej wersji, to klasa j.u.c.TimeUnit (którą swego czasu przedstawił mi Tomek Nurkiewicz), multi-catch oraz kombinacja TimeUnit z Phaser, a także j.u.Collections.nCopies.

Poniżej przykładowy kod, który służył jedynie celom sprawdzenia API. Nic ponadto! I niech tak zostanie.

package pl.japila.java7;

import java.util.Collections;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.Phaser;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class Main {

    public static void main(String[] args) {
        System.out.println("Millis in a day: " + TimeUnit.MILLISECONDS.convert(1, TimeUnit.DAYS));
        System.out.println("Sleeping for 2 secs");
        try {
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(Collections.nCopies(3, true));
        CyclicBarrier barrier = new CyclicBarrier(1);
        try {
            barrier.await();
        } catch (InterruptedException | BrokenBarrierException e) {
            e.printStackTrace();
        }
        Phaser phaser = new Phaser(2);
        try {
            phaser.awaitAdvanceInterruptibly(phaser.arrive(), 2, TimeUnit.SECONDS);
        } catch (InterruptedException | TimeoutException e) {
            e.printStackTrace();
        }
    }

}

Confitura 2012

Świetna sprawa te dzieci. Jestem pełen podziwu dla osób, którym czas upływa na wychowywaniu 3 i więcej dzieci. Jakoś przy dwójce było co robić, ale przy trójce mam wrażenie, że to kosmos.

U mnie dwójka dużych pomaga przy wychowywaniu najmłodszego, więc przy stanie 4:1 (liczba wychowujących do wychowywanych) jest z pewnością łatwiej. Ot, choćby możliwość zostawienia młodego pod opieką córki czy syna - bezcenne!

Jak na zdrowego bobasa przystało, Maksym broi na maksa. Już pełza i podnosi tyłek do raczkowania, a przy przejściu przez granicę 9 miesięcy (3 dni temu!), kiedy to żona wyczytała, że powinien sam siadać, jakby na zawołanie zaczął siadać. Do tego stopnia, że kiedy jest w łóżeczku i oznajmia, że się obudził, albo że chce jeść, siedzi. Dużo radości!

Ach, zapomniałbym - jeśli potrzebujesz uporządkować sobie harmonogram dnia, dziecko okaże się nieocenione. Nie ma czasu na marnowanie dnia, bo za moment stałe momenty, których dzieciak zmarnować nie da. Żadna książka, szkolenie, planowanie nie może równać się z wychowywaniem dziecka. Polecam!

To już prawie tydzień od naszej konferencji społecznościowej - Confitury 2012. Obfitowała w wiele naj, możne nawet w same naj?! Tym bardziej mnie to cieszy, bo nie tylko, że nie uczestniczyłem w jej współtworzeniu, ale również nie przeszedłem sita kwalifikacyjnego z moimi wykładami o Clojure oraz lekkimi kontenerami Java EE - Apache TomEE i IBM WebSphere AS 8.5 Liberty Profile. Czyżby to było powodem, dla którego można nazwać ją naj?! Cóż, samo życie. Mało nie doszło do tego, że w ogóle nie pojawiłbym się na konferencji. Synuś Maksym zagwarantował pobudkę wczesnym rankiem, tak abym przed 9:00 był gotów do dnia, więc na rozpoczęcie Confitury jak znalazł.

I tak się zaczęło.

(Wrażenia na bieżąco można było podziwiać na moim kanale na twitterze - @jaceklaskowski)

Raczej spontanicznie pojawiłem się na konferencji od samego rana. Wpadłem po rozpoczęciu, około 10 i po kilku powitaniach ruszyłem na pierwszą prezentację dnia - "Clojure praktycznie. Clojure jako silnik szablonowania HTML" Łukasza Barana. Byłem mile zaskoczony widząc prezentację o Clojure w harmonogramie konferencji, ale zły (na siebie wyłącznie!), że to nie ja ją prowadzę. W zasadzie z takim lekko agresywnym nastawieniem wszedłem na wykład, chcąc się przekonać, że to ja powinienem to poprowadzić. Pewnie to podejście miało wpływ na odbiór, bo zupełnie mi się niepodobało. Wybacz Łukasz i zrzuć to na barki mojej złości, ale prezentacja była nudna, monotonna i w ogóle nie zachęcała do wejścia w Clojure. Powiem więcej - odrzucała od tego języka. Szkoda, bo ma potencjał, a rozmowy za kulisami utwierdziły mnie w przekonaniu, że prelegent nie przygotował się do tej roli. Pytałem ludzi, którzy siedzieli koło mnie dlaczego przyszli i jakie ich są wrażenia, i dostałem najpierw odpowiedź, że "Ja tutaj, bo kolega jest", aby później dowiedzieć się, że ani kolega, ani pozostali dwaj za mną, nie byli zachwyceni z prezentowanej treści. Noty były niskie, baaardzo niskie. Od wykładu sponsorowanego wymagam więcej. Ja straciłem czas.

Później poszedłem na Waldka Kota i jego "Invokedynamic = bardziej dynamiczna JVM", ale niestety nie dostałem się do sali - cała była wypełniona. Gratulacje Waldek. Po latach ciszy, należało Ci się. Ja niestety zmęczony upałem i staniem na korytarzu, odpuściłem. Później słyszałem głosy, że nic nie było widać, za duszno i trochę za mało programowania. Żałuję, że nie mogłem się przekonać na własnej skórze, ale spokojniejszym po tych komentarzach. Dobrze było jednak móc zamienić słowo z Waldkiem później. Oby było go więcej i niechby jedynie rozprawiał o invokedynamic. Potrzebuję ich więcej!

Przez dłuższą chwilę bawiłem u Kuby Nabrdalika, który roztrząsał temat Grooviego, a wcześniej dodatków funkcyjnych do Javy. Szkoda, że zabrakło Clojure. Może, zgodnie z powtarzanymi tezami, przyjdzie mu poznać ten język w tym roku? Ciekawie prowadzona prezentacja, ale treść nie porywała. Zbyt wielki nacisk na bajeranckie slajdy, a kiedy przyszło do kodu źródłowego, za dużo na pojedynczym slajdzie, a często nawet zbyt skomplikowanie, aby było zachęcające. Pewnie świadomy ruch, aby zachęcić do Groovy i Grails. Mnie nie urzekło i przed wejściem Grails na scenę, uciekłem.

I w tym momencie miałem wracać do domu, do obowiązków, ale wymigałem się i zostałem. Do tej pory czuję razy na plecach. Wybacz Agatko!

Obiad był smaczny. Najadłem się do syta, a przy okazji nagadałem się ze znajomymi. Atmosfera boska!

O 14:10 wszedłem na długooczekiwanego Grzegorza Balcerka i jego prezentację "Jak i po co pozbywać się wzorców projektowych". Poznałem Grześka w Szczecinie i obiecywałem sobie zobaczyć go w akcji. Słyszałem już to i owo, więc tym bardziej nie mogłem doczekać się, co zobaczę. Dodając do tego jego książkę o Scali, którą napisał, bo...uczył się języka (!), liczyłem, że nauczę się wiele. Nauczyłem się. Czy wiele? Niekoniecznie. Najbardziej przypadł mi do gustu jego spokój, kiedy obrzucany obelgami o czelność forowania własnych myśli musiał się zmagać z gorącymi głowami Konrada i spółki. Nie podobała mi się treść prezentacji, więc tutaj duży minus dla Grześka. Jak potwierdziłem u innych uczestników, wielu zauważyło rozbieżność między tematem prezentacji a treścią i wielu oceniło ją jako najgorszą (!) Ja jednak znalazłem w niej kilka ciekawych kąsków prezenterskich, więc nie żałuję poświęconego czasu. Co mnie irytowało, to zachowanie publiki, która nie mogąc zgodzić się z tezami Grześka, próbowała deprecjonować jego zdolności do przekazywania wiedzy. Słychać było zarzuty w stylu "Dlaczego w ogóle śmiesz…", co przekreśla dalszą część pytania. Pytania o monady były niepotrzebne i nie wnosiły nic merytorycznego do spotkania. Niezgoda była wyczuwalna w powietrzu. Grzesiek opanowany próbował ratować sytuację, ale było za późno. Wypadło słabo, a publika również maczała w tym palce. Dla mnie było to o tyle pouczające, że nigdy wcześniej nie byłem na takiej prezentacji - jako prelegent i uczestnik - więc obserwowałem zachowanie obu stron i…będę teraz ostrożniejszy. Czego zabrakło u Grześka, to wzmiankowania, że "wzorce są uzupełnieniem cech języka o elementy, których brakuje mu, a istnieją w innych językach." Weźmy znaną mi Javę i Clojure - większość (wszystkie?) wzorce projektowe w Javie są próbą załatania braku domknięć i funkcji wyższego rzędu.

Później poszedłem na "Uwolnić się od "if"" Tomka Nurkiewicza. Temat zgodny z moim myśleniem, więc nie mogłem doczekać się posłuchać, co ma do powiedzenia. Bardzo interesująca i interaktywna prezentacja. Dużo zabawy i wiedzy. W taki sposób można spędzać całe weekendy, a nie tylko godzinę. Duże brawa dla Tomka za opanowanie i właściwe przedstawienie tematu. Czasami było trochę za bardzo kabaretowo, ale wspominam to jedynie dlatego, że sam nie miałem możliwości zaprezentowania swojego. Chciałbym móc wystąpić na Confiturze i być porównywanym merytorycznie z Tomkiem. Gość ma wiedzę i potrafi ją przekazać. Duże brawa! Jest od kogo się uczyć.

Po Tomku jeszcze kilka chwil na pogaduchach, aby przed kąpielą Maksyma (19:00) pojawić się w domu. Trochę żałuję, że nie mogłem uczestniczyć w Spoinie, ale mówią, że dobrze jest umiejętnie skończyć dobrą zabawę, aby były wyłącznie miłe wrażenia - ja takie mam!

Gratulacje dla prelegentów za chęć podzielenia się wiedzą (mimo moich krytycznych uwag). Gratulacje dla organizatorów za stworzenie bajecznej atmosfery wymiany wiedzy. Gratulacje dla uczestników za liczne przybycie i aktywny udział w prezentacjach (czasami nawet za aktywny). Poza temperaturą na zewnątrz i tłokiem w salach i na korytarzu brak innych uwag. Czekam na kolejną edycję, której nie zamierzam już przepuścić prezentacyjnie. Muszę się jedynie bardziej postarać.