Java Developers' Day 2009 moimi oczami

Siedzę sobie w pociągu relacji Kraków-Warszawa, za oknem już ciemno, pogoda z tych raczej dołujących, ale na szczęście PKP tym razem spisało się na medal i w przedziale jest ciepło i (o dziwo!) nie jesteśmy spóźnieni :)

No ale... przecież ten wpis nie może być tylko o pogodzie i naszym narodowym przewoźniku, więc już przechodzę do sedna.

Dzisiejszy dzień zaczął się bardzo wcześnie, bo już o 5:10. Wtedy zadzwonił budzik i operacja "JDD 2009" mogła się rozpocząć. Szybkie śniadanie, a potem na dworzec. Na szczęście bilet mogłem kupić online, więc zaoszczędzone na staniu w kolejce 20 minut mogłem przeznaczyć na dłuższy sen :)
Potem trzygodzinna podróż do Grodu Kraka i 15 minutowy spacer z dworca na Uniwersytet Ekonomiczny, gdzie miała odbyć się konferencja.

Po wejściu wszystkich przywitały urocze hostessy, każdy otrzymał zestaw materiałów od sponsorów, koszulkę i trochę gadżetów. Potem krótkie przemówienie i rozpoczęły się wykłady.


Jak usprawnić model domeny wykorzystując jBPM? by Tom Baeyens i Joram Barrez

Pierwszy z nich, niejako na rozgrzewkę, dotyczył jBPM, narzędzia z którym nigdy wcześniej nie miałem styczności. Ponieważ była to sesja dla wszystkich, miałem okazję posłuchać i dowiedzieć się czym w ogóle jest jBPM, co czego może się przydać i jak za pomocą narzędzi JBossa można szybko tworzyć (nawet wyklikać!) reguły biznesowe i potem używać ich w Eclipsie. Wykład był dobrze przeprowadzony, ciekawostką było użycie filmików prezentujących tworzenie przykładów zamiast częściej spotykanego kodowania na żywo czy przyrostowej prezentacji tworzenia kodu na slajdach. Moim zdaniem sprawdziło się to bardzo dobrze, prelegent mógł swobodniej uzupełniać przekaz niż gdyby musiał koncentrować się na kodowaniu.


Kolejny wykład to

Sztuka messagingu by Mark Richards
I znów temat dla mnie zupełnie dziewiczy, ale po to między innymi są konferencje by odkrywać nieodkryte i poznawać nieznane :) Prowadzący najpierw krótko opowiedział o podstawach JMS, by potem przejść do bardziej zaawansowanych kwestii. Pod względem treści wykład ciekawy, ale największe wrażenie zrobił na mnie sam prowadzący: nawiązał świetny kontakt z publicznością, potrafił rzucić kilkoma żartami i wytworzyć bardzo fajną atmosferę, a wszystko to bez uszczerbku na wartości merytorycznej prezentacji. Moim zdaniem był to najlepszy prowadzący konferencji, a jego drugi wykład o antywzorcach (o którym poniżej) był najlepiej poprowadzonym tego dnia.
Prezentacja z tego wykładu do pobrania tutaj.


Ostatnim wykładem przed przerwą obiadową był

Obsługa sytuacji wyjątkowych w systemach budowanych w technologii JEE by Tomasz Skutnik, e-point

Bardzo wartościowe merytorycznie wystąpienie, dużo przykładów jak nie należy i jak powinno się obsługiwać sytuacje wyjątkowe w systemach JEE. Można było zobaczyć i posłuchać jak to się robi w jednej z większych firm programistycznych, które znam. Prezentacja ciekawa, może czasami prowadzący za bardzo wchodził w ton "wyroczni" mówiąc w stylu "to jedyna dobra droga", "tak nie róbcie, to zło", ale myślę, że można mu to wybaczyć, bo cała prezentacja była ciekawa :)


Po tym wykładzie nastąpiła przerwa obiadowa. Ze znajomymi zastanawialiśmy się już gdzie idziemy coś zjeść, ale okazało się, że organizatorzy zapewnili wszystkim uczestnikom ciepły obiad na miejscu. Było dobrze: smacznie i do syta :)
Potem każdy miał sporo czasu, żeby odwiedzić stoiska na holu. Można było sprawdzić jak wyglądają certyfikaty Suna, a nawet pograć w parach na konsoli. Przede wszystkim jednak można było spotkać mniej lub bardziej znanych ludzi z polskiego javowego środowiska. Ja na przykład poznałem Tomka Nurkiewicza, z którym, jak się okazało, mamy wspólnych znajomych :)


Asynchroniczność, współbieżność i rozproszone przetwarzanie w Java EE – przykłady z użyciem technologii middleware Oracle: WebLogic Server, EclipseLink/TopLink JPA i Coherenc by Waldemar Kot, Oracle
Pierwszy wykład po przerwie prowadził Waldemar Kot. Ktoś gdzieś napisał o nim, że nawet dla laików w danej tematyce jego prelekcje są ciekawe i warte wysłuchania. I tak faktycznie było także w tym przypadku. Prowadzący opowiadał jak można rozbijać dłużej trwające zadania w aplikacjach JEE na kilka mniejszych przetwarzanych równolegle, aby czas oczekiwania użytkownika na wynik był jak najkrótszy. Wszystko podane w przystępnej formie, chociaż szkoda, że na pokazanie wszystkiego zabrakło czasu.


Java dla dużych chłopców, czyli Lego Mindstorms i leJOS by Jacek Kunicki
Po bardzo technicznych i poważnych tematach przyszedł czas na coś lżejszego: powrót do lat dziecięcych, czyli zabawa klockami Lego. Prowadzący pokazał jak za pomocą Javy i biblioteki leJOS oprogramować robota, aby można było nim kierować z telefonu komórkowego. Wykład ciekawy i fajnie poprowadzony. A roboty z Lego MindStorms mogą służyć do najróżniejszych celów: od "drukowania" za pomocą flamastra zamocowanego do ruchomego ramienia po robota-barmana nalewającego piwo po otrzymaniu smsa :)


Anty-wzorce programowania, czyli czego NIE robić by Mark Richards
Drugi wykład prowadzony przez tego prelegenta i, jak już wspomniałem, moim zdaniem najlepszy na całej konferencji. Prowadzący ciekawie i z humorem omówił kilka najczęstszych złych praktyk tworzenia oprogramowania. Porównanie programistów bezrefleksyjnie wybierających używane technologie do czcicieli kultu cargo było bardzo ciekawe i chyba wielu zapadło w pamięć. Stąd termin cargo cult programming.
Prezentację z wykładu można pobrać stąd.


O czym wiedzą najlepsi programiści? by Michał Bartyzel i Mariusz Sieraczkiewicz
Wykład z tzw. "umiejętności miękkich" programistów, czyli co można zrobić poza doskonaleniem warsztatu, żeby wzrosła nasza efektywność. Była mowa o stanie umysłu zwanym "transem", "flow" lub "programmers zone", czyli stanie podwyższonej koncentracji, gdy usiłujemy rozwiązać jakiś skomplikowany problem. O tym jak wykorzystywać taki stan do efektywnej pracy, ale i jak nie popaść w skrajność ciągłej pracy i siedzenia przed komputerem. Prowadzący podkreślali jak ważne jest dbanie o "higienę umysłu" w naszym zawodzie. Ogólnie temat ciekawy i myślę, że na każdej konferencji powinno się znaleźć coś o podobnej tematyce, nie do końca związane z programowaniem, ale jednak przydatne w naszej pracy. W tej chwili nasuwa mi się pomysł z wykładem pt. "Choroby zawodowe programistów i jak im zapobiegać". Ciekawe czy ktoś podchwyci? :)


Architektura Resource-Oriented (ROA) i REST by Scott Davis
Ostatni wykład, ogólnie o tym, że SOA jest kiepskie, a REST i ROA fajne. Prezentacja ciekawa, ale nie dlatego ją zapamiętam. Scott Davis rozpoczął ją około 17:30, na zewnątrz robiło się już szaro, a na auli większość oświetlenia była wyłączona. Spacerując po mrocznej auli i rzucając taki długi i niemal upiorny cień na ścianę, momentami mówił tak, że przypominał jakiegoś kaznodzieję kreślącego wizje nadchodzącej apokalipsy. Tak mi się jakoś dziwnie skojarzyło :) Ale sam wykład fajny.


Po tym wykładzie nastąpiło oficjalne zakończenie, na którym pojawił się pomysł, że być może przyszłoroczna edycja będzie dwudniowa. Moim zdaniem kierunek dobry, ale co z tego wyniknie zobaczymy za rok.

Podsumowanie i wrażenia ogólne

Plusy:
- bardzo równy poziom wykładów i prelegentów, nie było żadnego wykładu, który bardzo wyróżniał się in minus. Wszystkie moim zdaniem były albo dobre albo bardzo dobre.
- dobra organizacja, żadnych wpadek, minimalne poślizgi w wykładach.
- strefa ładowania laptopów, super sprawa zwłaszcza dla tych, którzy jechali i wracali tego samego dnia pociągiem.
- katering, pod dostatkiem napojów i jedzenia. Dobry obiad na miejscu.

Minusy:
- na głównej auli miejsca w górnej części były dość ciasne i brakowało trochę miejsca, żeby wygodnie usiąść. Po pierwszym wykładzie przenieśliśmy się niżej na zwykłe krzesełka i było dużo lepiej.
- trochę brakowało mi większej ilości ławek czy krzeseł na holach, gdzie można by było usiąść w grupie i porozmawiać.
- miałem wrażenie, że czas przeznaczony na każdą prezentację był trochę za krótki, bo praktycznie każdy prelegent musiał się mocno streszczać, żeby powiedzieć wszystko co zaplanował, a potem brakowało czasu na dyskusję i pytania.

A już za tydzień kolejna impreza javowa, tym razem w Warszawie: Warsjawa, czyli zwinnie o Javie.

Jak odmienić sposób programowania używając refaktoryzacji - moje wrażenia

Ku mojej radości rodzą się w Polsce inicjatywy, by pisać książki informatyczne niosące sporą dawkę wiedzy w naszym ojczystym języku. Cieszy to tym bardziej, że często czas czekania na polskie tłumaczenie jest skandalicznie długi. Faktem jest, że i tak każdy z nas chcąc być na bieżąco z nowinkami musi czytać książki, odwiedzać portale i blogi w dużej części pisane po angielsku, ale z drugiej strony miło jest od czasu do czasu zanurzyć się w świat Javy i programowania opisany "przez naszych i po naszemu".

Jedną z takich pozycji jest e-book pod tytułem "Jak całkowicie odmienić sposób programowania używając refaktoryzacji" autorstwa Mariusza Sieraczkiewicza. Książka nie jest przesadnie potężna objętościowo, ale po jej przeczytaniu mogę stwierdzić, że jako wprowadzenie w świat refaktoryzacji i pokazanie najważniejszych i najbardziej użytecznych technik spełnia swoją rolę bardzo dobrze.

Autor na wstępnie przedstawia myśl, która na początku nauki programowania nie była obca chyba nikomu: "Obym nie musiał w tym kodzie nic zmieniać". Niestety okazuje się, że kod aplikacji jest częściej czytany i modyfikowany po wdrożeniu niż zdajemy sobie sprawę, dlatego tak duży nacisk powinniśmy kłaść na jakość i przejrzystość tego co tworzymy. Nasze sprytne rozwiązanie problemu, które wymyśliliśmy dzisiaj za pół roku może być dla nas równie trudne do zrozumienia co kod napisany przez kogoś innego.

//

//When I wrote this, only God and I understood what I was doing
//Now, God only knows
//

Źródło: StackOverflow

Dlatego właśnie tak ważne jest, aby pisać kod, który nie tylko dobrze działa, ale i który będzie łatwo się czytało, analizowało i modyfikowało w przyszłości. I właśnie o tym jest ta książka, na przykładzie programu do tłumaczenia słów z wykorzystaniem internetowego słownika polsko-angielskiego autor krok po kroku wyjaśnia co można zrobić, żeby kod aplikacji był czytelniejszy i przygotowany do zmian w przyszłości.

Najważniejsze, ale i najbardziej podstawowe porady zawarte w książce to:
- twórz zmienne i metody, których nazwy opisują ich cel i sposób działania
- unikaj rozwlekłych klas i metod. Dobrym miernikiem długości metody jest możliwość przeczytania jej w całości bez konieczności przewijania ekranu.
- nie twórz bytów ponad miarę, anty-przykład: "wypychanie" metod i zmiennych na siłę do klas abstrakcyjnych, z których potem i tak dziedziczy tylko jedna klasa.
- unikaj niejawnego modyfikowania zmiennych klasowych wewnątrz metod. Jeśli inicjalizujesz taką zmienną klasy za pomocą metody, łatwiej będzie to odnotować, gdy metoda będzie zwracała właśnie tą zmienną.

Po więcej ciekawych technik refaktoryzacji odsyłam do książki (do kupienia tutaj), cena wersji elektronicznej jest bardzo atrakcyjna (pro-studencka można by rzec), bo za 25zł dostajemy ponad 90 stron przydatnej wiedzy. W dodatku wspieramy rodzimych autorów, co miejmy nadzieję zachęci innych do pójścia w ich ślady :)

Efektywny programista Java, część 3 i 4 - klasy użytkowe i unikanie zbędnego powielania obiektów

Dzisiaj kolejna porcja porad jak efektywnie programować w Javie. Tym razem w jednym poście dwie porady, bo każda z nich jest zbyt krótka, by umieszczać je oddzielnie.

Klasy użytkowe

Prawie w każdym projekcie pojawia się przynajmniej jedna klasa, która gromadzi metody użytkowe wspomagające działanie aplikacji. Taką klasę nazywamy najczęściej klasą pomocniczą (ang. utility class).
Składa się ona z kilku/kilkunastu metod statycznych używanych w różnych miejscach aplikacji. Taka klasa nie powinna umożliwiać tworzenia swojej instancji, gdyż jest to zbędne.

Bardzo łatwo możemy wymusić takie zachowanie na innych programistach tworząc konstruktor prywatny:

public class Utils {

    /*
     * This is utility class, you don't have to create instance to use it
     */
    private Utils() { }
    
    public static String prepareUserStringForEmail(User user) {
        // ...
    }
    
    public static String createRandomString(int length) {
        // ...
    }

    public static String formatDateWithTime(Date date) {
        // ...
    }
}

Dzięki takiemu prostemu zabiegowi, nasz kod zyskał na czytelności, a inni programiście nie będą używać naszej klasy w sposób niepoprawny.

Optymalizowanie tworzenia obiektów, których używamy wielokrotnie

Przyjrzyjmy się poniższemu fragmentowi pewnej klasy:

public class Utils {

    /*
     * This is utility class, you don't have to create instance to use it
     */
    private Utils() { }
    
    public static boolean isOlderThanCodeHardGoProBlogOwner(Date birthDate) {
        if(birthDate == null) {
            throw new IllegalArgumentException("Date can not be null");
        }

        Calendar calendar = Calendar.getInstance();
        calendar.set(1984, Calendar.JULY, 22);
        Date codeHardGoProOwnerDateOfBirth = calendar.getTime();

        return birthDate.compareTo(codeHardGoProOwnerDateOfBirth) < 0;
    }
    
}

Sprawdzamy tutaj, czy czyjaś data urodzin jest wcześniejsza niż moja. Tworzymy obiekt klasy Calendar, ustawiamy mu odpowiednie wartości roku, miesiąca i dnia, a następnie porównujemy ze zmienną birthDate.
Gdy wywołamy metodę kolejny raz, obiekt calendar zostanie utworzony ponownie i zostanie mu ustawiona ta sama data co poprzednio. Nie jest to rozwiązanie najbardziej optymalne. Widać tutaj wyraźnie, że tworzenie obiektu calendar i ustawianie mu odpowiedniej wartości powinno zostać wydzielone poza metodę i wykonywane tylko raz. Efekt taki możemy uzyskać przenosząc fragment kodu do bloku statycznego, a zmienną klasy Date uczynić prywatną i statyczną:

public class Utils {

    private final static Date CODE_HARD_GO_PRO_BLOG_OWNER_BIRTH_DATE;
    
    static {
        Calendar calendar = Calendar.getInstance();
        calendar.set(1984, Calendar.JULY, 22);
        CODE_HARD_GO_PRO_BLOG_OWNER_BIRTH_DATE = calendar.getTime();
    }
    
    private Utils() { }
    
    public static boolean isOlderThanCodeHardGoProBlogOwner(Date birthDate) {
        if(birthDate == null) {
            throw new IllegalArgumentException("Date can not be null");
        }

        return birthDate.compareTo(CODE_HARD_GO_PRO_BLOG_OWNER_BIRTH_DATE) < 0;
    }
    
}

Teraz nasza metoda będzie wykonywała się trochę szybciej. Oczywiście zysk będzie znacznie większy, gdy taki wielokrotnie używany obiekt będzie bardziej skomplikowany, a jego tworzenie kosztowniejsze i bardziej czasochłonne.

Wicket - się dzieje

Ostatnio społeczność związana z frameworkiem Wicket ma kilka powodów do zadowolenia. Po pierwsze pojawiła się finalna wersja 1.4. Najważniejsza zmiana w porównaniu z wersją 1.3 to całkowite przejście na Javę 1.5 i wprowadzenie generycznego interfejsu IModel wraz z implementacjami. O wszystkich nowościach i zmianach można poczytać tutaj.
Jednocześnie z pojawieniem się wersji 1.4 został opublikowany ostatni upgrade wersji 1.3 o numerze 1.3.7 poprawiający kilkanaście "bugów". Autorzy zapowiadają, że jeśli nie pojawią się krytyczne błędy to ta gałąź nie będzie dalej rozwijana. W związku z tym należy się powoli przygotowywać do migracji na wersję 1.4 w aplikacjach używających Wicketa 1.3.x. Problem dotyczy również i mnie, bo moja magisterka używa wersji 1.3.6.

Kolejnym wydarzeniem istotnym dla fanów Wicketa jest opublikowanie w serwisie RefCardz ściągawki (ang. cheatsheet) o tym frameworku. Na kilku stronach zebrano najważniejsze informacje, najlepsze praktyki i spor porad bardzo przydatnych dla osób używających Wicketa. Całość można pobrać tutaj.

I na koniec informacja bardziej z naszego, polskiego poletka. Paweł Szulc pracuje nad mavenowym archetypem znacznie przyśpieszającym rozpoczęcie pracy z Wicketem. Projekt nazywa się WicketCool i można się z nim zapoznać pod tym adresem. Bardzo podoba mi się pomysł stworzenia czegoś takiego i mam nadzieję, że pomysł zyska na popularności, a Pawłowi należą się podziękowania za poświęcony czas i po prostu za dobrą robotę.
Dodam tylko, że sam projekt miał premierę na prezentacji Pawła podczas tegorocznej Javarsovii.

Efektywny programista Java, część 2 - łatwiejsze tworzenie parametryzowanych kolekcji i obiektów

Tym razem spróbujemy ułatwić sobie tworzenie parametryzowanych typów kolekcji i obiektów. Pierwsza myśl jaka nam przychodzi do głowy to po prostu użycie konstruktora:

    // ...
    List<User> usersList = new ArrayList<User>();

    Map<IpAddress, User> ipUsersMap = new HashMap<IpAddress, User>();

    // ...

To jeszcze nie są zbyt skomplikowane przykłady, ale jeśli okaże się, że musimy stworzyć Mapę złożoną z obiektu i innej kolekcji:

    // ...


    Map<IpAddress, List<User>> ipUserMap = new HashMap<IpAddress, List<User>>();
    // ...

to pojawia się spora ilość zdublowanego kodu z informacją o typach parametrów po lewej i prawej stronie deklaracji.

Okazuje się, że można tego uniknąć wykorzystując tzw. "wnioskowanie typów". Kompilator będzie wiedział jaki tym parametryzowanej instancji ma zwrócić na podstawie tego, do jakiej zmiennej będziemy chcieli zwracany obiekt przypisać. Wygodnym sposobem jest zebranie wszystkich takich metod w jednej klasie użytkowej:

package pl.tdziurko.effectivejava

import java.util.ArrayList;
import java.util.HashMap;
import java.util.HashSet;

/**
 *
 * @author Tomasz Dziurko
 */
public class Helper {

    // Do not instantiate this class, this is utility class
    private Helper() { }

    public static <E> ArrayList<E> newArrayList() {
         return new ArrayList<E>();
    }

    public static <E,K> HashMap <E,K> newHashMap() {
        return new HashMap<E,K>();
    }

    public static <E> HashSet <E> newHashSet() {
        return new HashSet<E>();
    }

}

Teraz możemy zobaczyć o ile krótszy i wygodniejszy jest kod stosujący wnioskowanie typów:

    // ...
    List<User> usersList  = new ArrayList<User>();
    List<User> usersList2 = Helper.newArrayList();

    Map<IpAddress, User> ipUsersMap  = new HashMap<IpAddress, User>();
    Map<IpAddress, User> ipUsersMap2 = Helper.newHashMap();

    Map<IpAddress, List<User>> ipUserMap  = new HashMap<IpAddress, List<User>>();
    Map<IpAddress, List<User>> ipUserMap2 = Helper.newHashMap();

    // ...

Możemy skorzystać z wnioskowania typów również przy tworzeniu parametryzowanych obiektów innych niż kolekcje, ale tutaj zaleta jego użycia jest widoczna najbardziej.

Efektywny programista Java, część 1 - singletony

Zgodnie z zapowiedzią w poprzednim poście, dzisiaj początek cyklu postów z najciekawszymi poradami z książki "Java. Efektywne programowanie". W pierwszej kolejności postaram się przedstawić te tematy, z którymi programista Java może zetknąć się najczęściej.

Trzy sposoby na tworzenie singletonów

Najczęściej singleton w Javie wygląda następująco:

package pl.tdziurko.effectivejava;

public class Boniek {

    public static final Boniek INSTANCE = new Boniek();

    private Boniek() {
        // stwórz jedyną instancję Zbigniewa Bońka
    }

    public void doMagicWithBall() {
        // dokonaj czegoś niesamowitego na boisku    
    }

}

W powyższym przykładzie widać od razu, że jest to singleton: prywatny konstruktor i statyczne pole finalne z jedyną instancją klasy dają o tym wystarczająco jasny sygnał.

Drugi sposób przedstawiony w książce jest bardzo podobny:

public class Boniek {

    private static final Boniek INSTANCE = new Boniek();

    private Boniek() {
        // stwórz jedyną instancję Zbigniewa Bońka
    }

    public Boniek getInstance() {
        return INSTANCE;
    }

    public void doMagicWithBall() {
        // dokonaj czegoś niesamowitego na boisku   
    }
}

Stosując powyższe podejście mamy większą elastyczność przy późniejszych modyfikacjach naszej klasy. Możemy bez problemu (czyli bez widocznych zmian w zewnętrznym wyglądzie klasy) zmienić implementację metody getInstance(), tak aby zwracała nie jedyną instancję Zbigniewa Bońka, ale na przykład jedną instancję dla danego wątku czy danego klienta.

Oba podejścia nie są niestety odporne na refleksję, nie są również przystosowane do serializacji. Jeśli chcemy, aby nasz singleton po serializacji i deserializacji był ciągle singletonem poza dodaniem implements Serializable musimy przeładować metodę readResolve() tak, aby zwracała obiekt INSTANCE.
Z kolei przed refleksją można się uchronić dodając blok w konstruktorze, który rzuca wyjątek w momencie, gdy istnieje już instancja obiektu tej klasy.

Ostatnim (i najbardziej polecanym przez autora książki) sposobem na tworzenie singletonu jest zastosowanie typu wyliczeniowego:

public enum Boniek {

    INSTANCE;
    
    void doMagicWithBall() {
        // dokonaj czegoś niesamowitego na boisku   
    }
}

Dzięki zastosowaniu typu wyliczeniowego mamy za jednym zamachem załatwiony problem singletonu, bezpieczeństwa serializacji i zabezpieczenie przed użyciem refleksji. Wszystko zapewnia sam język i nie musimy się o to martwić.

Osobiście najczęściej stosowałem podejście z polem private final static i metodą getInstance(), ale myślę, że zastosowanie typu wyliczeniowego jest bardzo interesującą alternatywą, którą warto dodać do swojego repertuaru :)

Dobiega końca pierwszy (najtańszy) etap rejestracji na Java Developers' Day 2009

Jeszcze tylko kilka dni mają wszyscy, którzy chcą się załapać w pierwszym (najbardziej promocyjnym) etapie rejestracji na konferencję Java Developers' Day 2009 w Krakowie, która odbędzie się 16 października 2009.
Do 31 lipca studenci mogą zaopatrzyć się w wejściówkę już za 167zł, co za całodniową, anglojęzyczną konferencję o Javie jest kwotą bardzo, ale to bardzo małą. Programiści "starsi wiekiem" ;) zapłacą za bilet 219 zł. Im bliżej października tym cena będzie rosła, więc jeśli ktoś wie, że na pewno chcę się wybrać do grodu Kraka posłuchać o Javie, to warto zapłacić już teraz. Oferta last minute dla spóźnialskich to wydatek prawie 600 złotych (swoją drogą last minute kojarzyło mi się zawsze z okazjami, no ale widocznie coś się ostatnio w tej kwestii pozmieniało :))

Niestety agenda nie jest jeszcze gotowa, ale po przejrzeniu relacji z poprzednich edycji mam nadzieję, że tegoroczne JDD nie będzie gorsze.

PS: Sponsorem tego posta jest Dworzec Zachodni w Warszawie, firma PKP i jej spóźniony o ponad 60 minut pociąg.