poniedziałek, 1 września 2014

Implementacja Singleton’a w Javie

Ostatnio, podczas z jednej z rozmów rekrutacyjnych, dostałem pytanie, "A jak by Pan zaimplementował singleton w Javie?". Pytanie dość standardowe, mógł by je zadać każdy. Odpowiadam więc: „Klasa, z prywatnym konstruktorem, z polem statycznym o typie zadeklarowanej klasy, metoda getInstnce(), itd.”. Rekruter na to: "No dobra, a jakiś inny pomysł?".

Na szybko nie przychodziło mi jednak nic do głowy... Wtedy padło pytanie, które zmotywowało mnie do przygotowania tego wpisu: "A czytał Pan Effective Java, Joshua Bloch?". A no nie czytałem i nie sądzę, abym ją przeczytał.

Dlaczego?

Przede wszystkim uważam że ta książka jest trochę przestarzałą. Drugie wydanie pochodzi z 2008 roku i informacje w niej zawarte są trochę nieaktualne. To nie książka o wzorcach projektowych Bandy Czworga, która nie traci na swojej aktualności, a jedynie pozycja o tym jak coś tam dobrze zrobić w Javie. I tak przykładowo rozdział: "Item 51 Beware the performance of string concatenation", traktujące o tym, aby lepiej używać StringBuilder’a niż + do sklejania tekstów, jest już dawno nieaktualne! Chciałem kiedyś pisać posta o tym, ale na stackoverflow i jeszcze gdzieś tam już dawno o tym było. Nie wiem tylko od kiedy dokładnie istnieje ten mechanizm zamiany + na StringBuilder’a w Javie.

O innych dobrych praktykach, można się dowiedzieć zawsze z innych źródeł, niekoniecznie czytając wspomnianą książkę.

Dobra wróćmy do tematu wpisu. W innym rozdziale Effective Java (Item 3: Enforce the singleton property with a private constructor or an enum type), jest zalecenie, aby Singletona implementować za pomocą Enuma. Z tym rozwiązaniem spotkałem się po raz pierwszy podczas review kodu kogoś, kto czytał tę książkę. Użycie wówczas enuma w roli singletonu było dla mnie zupełnie niezrozumiałe! Musiałem dopytać autora o co chodzi.

Dlaczego nie lubię tego rozwiązania? Spójrzmy na przykładowy kawałek kodu (inspirowany Joshuą Blochem, co bym za dużo nie musiał wymyślać, jak tu mądrze użyć singletona). Kod jest i tak kiepski (obliczanie czasu), ale chodzi mi o zaprezentowanie działania omawianego wzorca.
public enum Elvis {
    INSTANCE;

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

public class ElvisProfitService {

    public double ELVIS_SALARY_YEAR = 70_000;

    public double calculateElvisProfit() {
        return Elvis.INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }
}

No i weź tu panie przetestuj taki kod! Możemy jeszcze Elvisa statycznie zaimportować, to linijka 6 skróci się do jeszcze mniej czytelnej formy.

return INSTANCE.howOldIsElvisNow() * ELVIS_SALARY_YEAR;

Ktoś ma jakieś pomysły jak taki kod przetestować? Da się oczywiście, z wykorzystaniem PowerMock’a [link do rozwiązania na końcu ^1], ale chyba nie o to chodzi aby pisać nietestowany kod?

Dlaczego wolę starszą wersję tegoż rozwiązania:

public class Elvis {

    private static final Elvis INSTANCE = new Elvis();

    private final int ELVIS_BIRTHDAY_YEAR = 1935;

    private Elvis() {
    }

    public static Elvis getInstance() {
        return INSTANCE;
    }

    public int howOldIsElvisNow() {
        return new GregorianCalendar().get(Calendar.YEAR) - ELVIS_BIRTHDAY_YEAR;
    }
}

Dochodzi prywatny konstruktor, statyczna metoda getInstance() i inicjalizacja pola klasy wraz z deklaracją.

W tym przypadku kod korzystający z tego singletonu, mógłby być następujący:

public class ElvisProfitService {

    private final double ELVIS_SALARY_YEAR = 70_000;
    private Elvis elvis = Elvis.getInstance();

    public double calculateElvisProfit() {
        return elvis.howOldIsElvisNow() * ELVIS_SALARY_YEAR;
    }

    // For tests
    void setElvis(Elvis elvis) {
        this.elvis = elvis;
    }
}

W linii 4 wywołałem getInstance(), aby w przykładowym kodzie produkcyjnym było wszystko cacy. Dzięki temu, zależność ta jest definiowana jako pole w kasie i mamy setter do tego, więc możemy sobie bardzo ładnie przetestować tą funkcjonalność, bez hackowania z PowerMockiem:

public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();
        Elvis elvis = mock(Elvis.class);
        when(elvis.howOldIsElvisNow()).thenReturn(1);
        service.setElvis(elvis);

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

W sekcji given mamy bardzo ładnie zdefiniowane zachowanie, za pomocą Mockito, jakie ma przyjmować masz singleton na potrzeby tego testu.

A Ty jak definiujesz (o ile to robisz) swoje singletony? Które rozwiązanie uważasz za lepsze?



[1] Co do rozwiązania zagadki, jak przetestować Singletona jako Enum’a, to tutaj jest odpowiednia rewizja na github’ie: SingletonInJava e714fb a kod poniżej:

@RunWith(PowerMockRunner.class)
@MockPolicy(ElvisMockPolicy.class)
public class ElvisProfitServiceTest {

    @Test
    public void shouldCalculateElvisProfit() {
        // given
        ElvisProfitService service = new ElvisProfitService();

        // when
        double elvisProfit = service.calculateElvisProfit();

        // then
        assertEquals(70_000, elvisProfit, 0.1);
    }
}

public class ElvisMockPolicy implements PowerMockPolicy {

    @Override
    public void applyClassLoadingPolicy(MockPolicyClassLoadingSettings settings) {
        settings.addFullyQualifiedNamesOfClassesToLoadByMockClassloader("com.blogspot.mstachniuk.singletoninjava.Elvis");
    }

    @Override
    public void applyInterceptionPolicy(MockPolicyInterceptionSettings settings) {
        Method method = Whitebox.getMethod(Elvis.class, "howOldIsElvisNow");
        settings.proxyMethod(method, new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                return 1.0;
            }
        });
    }
}

czwartek, 17 lipca 2014

Wyższy poziom produktywności w IntelliJ Idea

Ostatnio natrafiłem na nagrania z konferencji Geekout z Estonii. Zainteresowała mnie 3cia prezentacja: Mouseless Driven Development by Hadi Hariri.


Prelegent (pracownik JetBains’a) opowiadał o tym jak efektywnie kodować bez użycia myszki. Myślałem, że już dostatecznie poznałem to moje ulubione środowisko developerskie, ale jak zobaczyłem pierwszą ciekawostkę, którą pokazał Hadi, to zacząłem robić notatki. A skoro notatki to już nie wiele trzeba, aby był wpis na bloga…

Uważam, że najlepszą metodą poznawania środowiska pracy, jest patrzenie jak korzystają z niego inni. I to może być przy okazji warsztatów typu Code Retreat, Coding Dojo czy innych hackathon'ów, lub właśnie oglądając screencasty i wystąpienia z konferencji. Zachęcam do obejrzenia powyższego video (choć ten efekt z przekrzywionym obrazem z rzutnika uważam za głupi), gdyż opisałem poniżej rzeczy dla mnie nowe, tudzież te wymagające mojego odświeżenia. Warto, przed dalszą lekturą tego wpisu, znać choć połowę skrótów z IntelliJIDEA_ReferenceCard.pdf, gdyż niżej będzie o bardziej zaawansowanych zagadnieniach. A więc do dzieła!

Jak wszyscy zapewne wiedzą (albo powinni wiedzieć), Ctrl + N otwiera klasy lub pliki (gdy dwa razy naciśniemy tą kombinację, lub Ctrl + Shift + N). I tutaj nazwę możemy podawać w szelaki sposób: CamelCase, snake_case (ale dla ułatwienia ze spacją), wspomagając się gwiazdką itd. Idea będzie szukać wszystkiego co pasuje i wyświetli w logicznym porządku. W Eclipse „jakoś tam” też to działa, ale o wiele gorzej.

Ale co mnie właściwie onieśmieliło, to gdy pisząc po nazwie klasy :<numer lini> (słownie: dwukropek i numer linii), plik zostanie otworzony na żądanej pozycji! Ciekawie działa również Alt + F1, które pozwala otworzyć nam plik np. w Project View, Structure, Exporatorze Windowsa, i w innych oknach. A chcąc otworzyć plik w osobnym oknie można zamiast Entera wcisnąć Shift + Enter. A jak chcemy wyszukiwać wszędzie, to możemy to zrobić za pomocą podwójnego naciśnięcia Shift. Część tych wskazówek zaczerpnąłem ze strony JetBrains’a: Navigating to Class, File or Symbol by Name, a część z opisanego na początku video.

Do wyszukiwania użycia jakiejś zmiennej lub metody, zawsze korzystałem z Alt + F7. Jest to skrót, który swoimi korzeniami sięga TotalCommandera, a nawet Norton Commandera. Podobnie jest zresztą z Shift + F6 - rename. Natomiast jak chcemy widzieć dolnego okienka z wynikami poszukiwań, możemy skorzystać z Ctrl + F7, które to skoczy nam do pierwszego wykorzystania i zaznaczy pozostałe. A jak byśmy chcieli podświetlić wykorzystanie wielu różnych zmiennych, to na każdej możemy skorzystać z Ctrl + Shift + F7. Jeszcze podobnie zachowuje się Ctrl + Alt + F7, które to pokazuje wyniki wyszukiwania w popupie. Poniżej przykłady z mojego projektu HamcrestVsFest.

Alt + F7

Ctrl + F7. Obiekt mercury jest tworzony w lini 10, ale po raz pierwszy jest użyty w linii 20.

Ctrl + Shift + F7. Tutaj wykonane na mercury, PlanetBuilder, RotationDirection i Gases.

Ctrl + Alt + F7

Dalej było o tym, jak zmaksymalizować przestrzeń na pisanie kodu. I tak prelegent, przekonywał nas, że można się obejść bez nawigation bara na górze ekranu.


To ten pasek, gdzie jest rozpisane, w jakim pakiecie i pliku aktualnie jesteśmy. Nie jest on nam potrzebny, bo możemy się dostać do niego za pomocą Alt + Home. Mi osobiście on nie przeszkadza, bo jest na tym samym poziomie, co ostatnio uruchamiana konfiguracja projektu, a to lubię widzieć.

Nie potrzebujemy również Tab’ek, gdy mamy wiele otwartych plików, bo przeglądanie ich i szukanie odpowiedniej po nazwie zajmuje wiele czasu.


Tak naprawdę potrzebujemy tylko Ctrl + E, które w bardziej czytelny sposób nam pokazuje, jakie pliki ostatnio przeglądaliśmy i szybciej je w ten sposób odnajdziemy. Jeśli zależy nam tylko na tych które ostatnio edytowaliśmy, to możemy skorzystać z Ctrl + Shift + E. Jest to ulubiony skrót prowadzącego prezentację do tego stopnia, że musi używać zewnętrznej klawiatury w laptopie, bo przycisk E mu się zepsuł. Przykłady użycia poniżej, a Tab'ki możemy całkowicie wyłączyć w ustawieniach.


Ctrl + E
Ctrl + Shift + E

Jak usunąć Tab'ki z otwartymi plikami.

Przeskakiwać pomiędzy poszczególnymi oknami w IntelliJ Idea można za pomocą Alt + <numer okienka>, widoczny przy jego nazwie. Niestety nie na wszystkie okienka wystarczyło numerków, więc jak chcemy np. dostać się do Mavena lub Bazy danych, to Ctrl + Tab jest twoim przyjacielem.

Ctrl + Tab

A jak już w ogóle byśmy chcieli tylko i wyłącznie kod widzieć, to warto się zapoznać z Prezentation Mode. Warto na Windowsie sobie zdefiniować skrót Ctrl + Shift + P jako wejście do tego trybu. Na pewno może się to przydać podczas prezentacji, jak i osobom lubiącym widzieć tylko kod na ekranie.

Następnie poznałem nowe znaczenie F4 w oknie projektu. Dotychczas używałem tego klawisza tylko do otwierania właściwości projektu, a w ten sposób można również otworzyć plik i automatycznie skoczyć do jego edycji. Jest to lepsze od oczywistego Entera, który tylko otwiera wybrany plik, ale fokus pozostaje na oknie projektu.

A co z operacjami typowymi dla myszki, jak dostrajanie wielkości okna projektu? Sam dotychczas myślałem, że jest to jedynie możliwe za pomocą myszki, ale da się też z klawiatury! To kolejne moje wielkie odkrycie z tej prezentacji, po którym mi i osobom na sali opadła szczęka. Chcąc przykładowo zmienić rozmiar widoku projektu, musimy mieć na nim focus (Alt + 1) i teraz już wciskamy tylko Ctrl + Shift + Prawo / Lewo. Okno z wynikami testu? Po porostu Alt + 4 aby uzyskać fokus i Ctrl + Shift + Góra / Dół. Na oknie z kodem to nie działa, gdyż te skróty odpowiadają za zaznaczanie tekstu i przenoszenie linii w pionie.

Było jeszcze o mulitikursorze, który swoim zasięgiem może objąć wiele wierszy. Tu już trzeba zrobić z użyciem prawego Alt’a i myszki. Ale Idea proponuje jeszcze  coś innego, a mianowicie Alt + J, które zaznacza dany tekst w pliku i tworzy multikursor. Jest jeszcze: Ctrl + Alt + Shift + J, ale jak to działa, sprawdźcie sami. Aby opuścić ten tryb edycji, trzeba wcisnąć 2 x Esc.

Warto przypomnieć o Live Templates (Ctrl + J) i Postfix templates, o których to się nie pamięta, a za pomocą których można tworzyć kod w ciekawszy sposób. Możemy również otaczać kawałek kodu różnymi konstrukcjami (np. if, try/catch, itp.) za pomocą Ctrl + Alt + T.

Warto także utworzyć własną szybka listę (Quick Lists w Settings), gdzie można wrzucić operacje, które często używamy i przypisać wywołaniu tej listy jakiś skrót klawiaturowy. Muszę sobie przygotować taką listę, z rzeczami które często potrzebuję, a nie mają domyślnego skrótu klawiaturowego.

Na koniec jeszcze pozostaje nam Ctrl + ~, które to umożliwia nam szybką zmianę, m.in. kolorów, Look and Feel jak i skrótów klawiaturowych (przykładowo na te z Eclipse’a). Może się to przydać, gdy akurat musimy zrobić Pair Programing z użytkownikiem Eclipse’a. I aby śledzić nasze postępy w niewykorzystywaniu myszki, warto się przyjrzeć statystykom z menu Help -> Productivity Guide.

A Ty jakie znasz bardziej zaawansowane i skomplikowane skróty w IntelliJ Idea? Pisz w komentarzu!

piątek, 11 lipca 2014

Konfitura, marmolada, dżem, powidło i spiżarnia, czyli wrażenia po confiturze 2014

Rapid dev environments, Marcin Brański i Przemek Hejman
Prelegenci opowiadali o tym w jaki sposób tworzyć środowiska developerskie, a właściwie ich konfiguracje i obrazy, aby później można było je szybko odtworzyć np. na nowej maszynie. Chłopaki bardzo sprawnie i płynnie mówili, widać, że przećwiczyli to wystąpienie wcześniej. Ale niestety używali w swoich wypowiedziach sporo skrótów, które nie koniecznie musieli wszyscy znać. Pokazywali również sporo detalów, a zabrakło mi jakiegoś big picture, co do czego jest, oraz czym różnią się opisywane rozwiązania.

I tak oto było o następujących narzędziach: Packer.io, PuppetVagrantAnsibleChefSaltFabricDocker i Fig (nakładka na dockera). Niestety z powodu znikomej znajomości tematu nie jestem w stanie nic więcej tutaj napisać.

Git nie dla początkujących, Tomasz Borek
Tomek na początku przedstawił różnicę, pomiędzy surowym repozytorium (utworzonym z flagą --bare), a zwykłym repozytorium. Dalej już było ciekawiej. Prelegent pokazywał, co tak naprawdę jest potrzebne w katalogu .git, aby istniało repozytorium. I tak są to katalogi: objects i refs/heads oraz plik HEAD z zawartością (np.: „ref: refs/heads/master”). Ciekawa sztuczka, ale trwała trochę za długo i prelegent miał problemy z koordynacją, tj. czy klepać w klawiaturę, trzymać mikrofon, stać, siedzieć, czy mówić do mikrofonu stojącego na biurku (o którym później prelegent kompletnie zapomniał).

To było trochę jako ciekawostka, ale Tomek omówił również, po co są pozostałe katalogi i pliki. I tak w description jest opis projektu, który nie jest nigdzie pushowany i prawie nigdzie nie używany. W info/exclude można zignorować pewne pliki, których nie chcemy wersjonować. Przydaje się to w momencie, gdy mamy jakiś plik z ustawieniami lub hasłami, który tylko lokalnie powinien być dostępny, a z jakiś powodów nie chcemy go ignorować za pomocą .gitignore.

Jeszcze było o  wewnętrznej budowie commit’a. Ogółem git’a można potraktować jak acykliczny graf skierowany. Pojedyńczy commit może wskazywać na drzewo lub inne commity, drzewo wskazuje na BLOBy lub drzewa, a w BLOBach zapisywana jest zawartość plików. Co ciekawe, to nazwy plików nie są zapisywane w BLOBie, a w drzewie. Dlatego łatwo jest wykrywać zmiany położenia plików, nawet jak częściowo zmieni się zawartość.

Było jeszcze o root-commit’cie, który jest praojcem wszystkich commit’ów. Jak jakiś inny commit nie jest w stanie osiągnąć tegoż praojca, to znaczy, że jest wiszącym commit’em i można go usunąć. Swoją drogą ciekawi mnie, skąd się biorą takie wisielce? Chyba jak nie usuwamy niezmerge'owanych branchy z flagą -D, lub jakiś pojedynczych commit'ów, to nie powinno dochodzić do takich sytuacji.

Dalej było wspomniane, że nie warto wrzucać duże pliki do repozytorium. Nawet jak te pliki tam umieścimy, a następnie usuniemy, to i tak strasznie nam to spowolni pracę z git’em. A ciężko takie coś usunąć z historii tak, aby jej nie popsuć.

Oczywiście ta prezentacja nie mogłaby się odbyć z pominięciem tematu funkcji skrótu SHA1. Organizacja NIST(National Institute of Standards and Technology), która to ogłosiła ten algorytm, obecnie wycofuje się z niego i zaleca zastąpienie go SHA3. Ale w Gitcie ta funkcja skrótu nie jest wykorzystywana w celach kryptograficznych a identyfikacyjnych, więc zagrożenie jest naprawdę niewielkie. Co prawda można wygenerować plik, który będzie nam kolidował z czymś w repozytorium, ale na to pewnie też się znajdzie obejście. Po za tym zmiana funkcji hashującej wymusiłaby zmianę protokołów git’a, a ta jest dodatkowo tak zoptymalizowana, że trafia z chache CPU.

SHA1 jest wykorzystywana w Gitcie do identyfikowania commitu i innych obiektów. Dla commitów wystarczają nam zazwyczaj pierwsze 6, lub 8 znaków tegoż skrótu. Największy otwarty znany projekt hostowany na Gicie, czyli linux kernel, potrzebuje 12 znaków do identyfikacji commit’a. Wartości te są widoczne w .git/objects i są one pogrupowane w podkatalogi, aby nie osiągnąć maksymalnego limitu ilości plików w jednym katalogu i aby można było je szybko odszukać.

Było jeszcze o różnicy w sposobie przechowywania zmian w gitcie, a w SVNie. I tak SVN przechowuje różnice w plikach. Natomiast Git przechowuje całe pliki i gdy się nic w nich nie zmienia, to aktualizuje tylko wskaźnik na aktualną wersję pliku. Nie jest to do końca prawdą, gdyż gdy repozytorium nam rośnie, to git przechowuje stare rewizje również jako różnice w pliku i dodatkowo je kompresuje. Najnowsza wersja jest zawsze przechowywana jako pełen plik, gdyż najczęściej jej potrzebujemy. Dodatkowo Git został zoptymalizowany pod względem ilości zajmowanego miejsca na dysku.

Tomek wspomniał również o komendzie add w trybie interaktywnym, gdzie można wybrać, które zmiany w danym pliku wejdą do commita. Było również o takich poleceniach jak squash (pozwala złączyć commity w jeden), rebase (modyfikuje historię) i instaweb. Ta ostatnia komenda git’a pozwala przeglądać historię repozytorium przez przeglądarkę. Niestety funkcjonalność ta, póki co, nie działa w mysysgit na Windowsie(#11).

Z rzeczy poza Gitem z prezentacji dowiedziałem się o fajnej powłoce ZSH i o nakładce na nią ze zbiorem fajnych rozszerzeń: Oh My ZSH.

Prezentacja bardzo fajna. Spodziewałem się trochę więcej o komendach typu plumbing i tego co się pod spodem dzieje, gdy wywołujemy komendy typu porcelain. Ale o tym można sobie doczytać (nawet po polsku) w książce Pro Git 9. Mechanizmy wewnętrzne w Git, a prezentacja Tomka była dobrym wstępem do tego.

Po tej prelekcji niestety zmarnowałem trochę czasu na chodzeniu po stanowiskach sponsorskich, ale mówi się trudno. Ominięte wykłady oglądnę, gdy już zostaną opublikowane.

Clean architecture - jak uporządkować architekturę Twojej aplikacji. Wnioski z projektu. Andrzej Bednarz
Prelegent opowiadał, o swoim greenfield projekcie, w którym wraz z zespołem postanowili poszukać dobrej architektury. W tym celu przejrzeli to, co wielkie autorytety tego świata mówią i piszą w tym temacie i zaczęli podążać ścieżką promowaną przez Wujka Boba, a mianowicie Clean architecture.

Podejście nie jest jakoś szczególnie nowe. Mówi o odseparowaniu GUI i baz danych od naszej logiki. Każda sensowna architektura o tym mówi. Kluczowe w czystej architekturze jest odwrócenie zależności, tj. aby nasz core aplikacji NIE był zależny od bazy danych, frameworka GUI i innych komponentów. Czyli w naszych encjach powinniśmy przechowywać przykładowo datę w formacie typowym dla daty, a nie zdeterminowanym przez bazę danych, czy ORM. Innymi słowy, musimy mieć zależności DO naszej aplikacji. Więcej powinien wyjaśnić ten rysunek ze strony Wujka Boba:


Podejście takie powoduje, że nie jesteśmy uzależnieni od używanych framework'ów i możemy je łatwo wymienić. Zyskujemy również na łatwości testowania naszej logiki biznesowej. Architektura ta wymusza jednak pewien narzut na tworzenie warstw abstrakcji, wielu DTO i konwersji między różnymi obiektami.

Prezentacja była ogółem fajna. Andrzej pokazał na przykładzie kodu, jak to wygląda u niego w projekcie. Osobiście zabrakło mi trochę porównania w kodzie, z typową architekturą 3warstwową, aby móc uświadczyć różnice. Wadą wystąpienia było patrzenie prelegenta przez plecy, na kod wyświetlany na ścianie, aby pokazywać gdzie coś jest. Jak by nie można było włączyć odpowiedniego trybu pracy z rzutnikiem.

JVM and Application Bottlenecks Troubleshooting with Simple Tools Daniel Witkowski
W tym roku było sporo wykładów na Confiturze dotyczących szybkości działania tworzonych przez nas aplikacji. Prelegent pokazał kilka prostych sztuczek, jak wyłapywać problemy w naszych aplikacjach.

Na początku trzeba ustalić nasze wymagania jakościowe, czyli SLA, czas odpowiedzi, ile requestów na sekundę musimy wytrzymać itd. Następnie prelegent odpalił przygotowaną aplikację, „klikający” w nią JMeter i obserwowaliśmy, co nam pokazuje nam JVisualVM. I gdzieś tam chyba z Thread Dump’a wyczytaliśmy, że gdzieś jest ręcznie wywoływany Garbage Collector. Oczywiście wiadomo, że to jest zła praktyka, ale można zawsze ją wyłączyć, za pomocą flagi -XX:+DisableExplicitGC.

Będąc już przy temacie GC, to warto zawsze zapisywać logi z jego działania i przeglądać za pomocą GCViewer.

Inną pożyteczną wiadomością, jaką ze sobą niesie JVisualVM, jest podgląd wątków. Można tam przykładowo sprawdzić, czy liczba wątków http (przyjmujących żądania) jest taka jak się spodziewamy. Gdy będzie tylko jeden, to nie dobrze, bo requesty będą obsługiwane sekwencyjnie.

Wykres aktywności wątków, może również pokazać nam problemy z synchronizacją i blokowaniem się. Może to świadczyć o niewłaściwym użyciu słówka synchronized (np. na metodzie doGet()) lub innych mutex’ów. Jeśli widzimy, że wiele wątków nam się blokuje, to musimy znów w Thread dumpie szukać miejsc, gdzie coś może być nie tak.

Warto też spojrzeć, czy nie mamy problemów z odczytem / zapisem na dysku. W Linuxach można to sprawdzić za pomocą top’a, a na Windowsie poprzez Process Explorer. I tak jeśli dyski nie wyrabiają, może to oznaczać, ze mamy włączony za wysoki poziom logowania. Przy tej okazji w końcu zrozumiałem zasadność takich zapisów:
if(log.isDebugEnabled()) {
     log.debug(createLogMessage());
}

Jeśli ktoś napisze jakieś długotrwające operacje w metodzie createLogMessage(), to powyższy if, spowoduje, że nie będą ona wykonywane, gdy są i tak niepotrzebne. I tu bardzo fajnie widać wyższość Scali, gdzie taki argument mógłby być wyliczany w razie potrzeby.

Ponadto jakie nie wiemy w jaki sposób jest zaimplementowane isDebugEnabled(), to lepiej odczytać tą wartość raz i trzymać gdzieś w systemie.

Na koniec była jeszcze (na szczęście krótka) reklama narzędzia Zing Vision, jako że prelegent jest przedstawicielem Azul Systems. Firma ta jest również producentem maszyny wirtualnej Zing, która wg. producenta jest lepsza od implementacji Oracla.

Working with database - still shooting yourself in the foot? Piotr Turski
Prezentacja Piotrka bardzo mi się podobała, gdyż w moim projekcie doszliśmy do prawie tych samych wniosków co prelegent, a o drobnych różnicach mogliśmy sobie porozmawiać na Spoinie.

Piotrek korzysta w swoim projekcie z dwóch baz: H2 i Oracle. Jednak H2 nie do końca sprawdzała się w testach, gdyż czasem pojawiały się błędu specyficzne dla Oracla. Przykładowo w klauzurze in nie może być więcej niż 1000 elementów. Jest to dość znany problem, ale u Piotrka wyszło to dopiero na produkcji. Innym problemem było wykorzystywanie specyficznych możliwości „wyroczni” w zakresie wyszukiwania po umlautach (üöä). H2 tego nie obsługiwało, więc nie dało się testować. Innym problemem był typ Date, który na Oracle, inaczej jak na H2, po za datą zawiera również dokładną godzinę.

Z tych powodów w projekcie prelegenta testy integracyjne puszczano na Oracle, i każdy developer miał pod ręką dla siebie takową bazę. H2 nie zostało jednak wyrzucone z projektu (mimo 3 rund rozmów na ten temat), gdyż jest lżejsze, szybsze, i tylko kilka funkcjonalności na nim nie działa.

W takim wypadku, warto mieć mechanizm czyszczenia bazy na potrzeby testów. Można to załatwić DbUnit’em, ale utrzymywanie plików z danymi jest kosztowne. Po za tym narzędzie to nie zresetuje sekwencji. Można próbować również próbować przywracać dane z backup’a, ale to również może prowadzić do innego stanu bazy. Problematyczne jest tutaj usuwanie constraint’ów i powiązanych z nim index’ów. Dlatego warto wygooglać, jak można resetować bazę na Oraclu i dopasować rozwiązanie do własnych potrzeb.

Przy takich akrobacjach, warto zadbać o proces wprowadzania zmian na bazie danych. Piotrek używał w tym celu flyway, a ja u siebie korzystałem z liquibase. Nie można wtedy niestety ręcznie robić hotfix’ów. Zaletą jest to, że do testów można wtedy budować bazę tak samo jak na produkcji.

Warto również wprowadzić mechanizm testu „produkcyjnego deploymentu”. Chodzi o to, aby zgrywać stan z produkcyjnej bazy danych (schemat i dane) i wykonać deployment aplikacji (co wymusza wykonanie migracji). Zyskujemy wtedy pewność, że nic nie powinno się posypać przy roll out’cie.

Było jeszcze trochę o testowaniu integracyjnym z bazą danych, np., gdy chcemy sprawdzić HQL’a. Można do tego zaprząc wspomnianego już DbUnit’a, ale analizowanie później czemu test się wywalił, jest czasochłonne. Lepiej przygotować dane do testów w teście. Przecież i tak mamy zapewne możliwość zapisywania naszych encji w bazie, więc możemy to wykorzystywać w setupie naszych testów. Warto również przy tej okazji skorzystać z Builder’ów.

Programowanie JEE'ish bez stresu Jakub Marchwicki
Prelegent opowiadał na początku o tym, że warto czasem zbudować jakąś aplikację, wykorzystując inne technologie, niż standardowy Spring, Hibernate i JSF. Pozwala nam to przypomnieć, co te technologie załatwiają za nas, oraz jak działają pewne rzeczy na niższym poziomie. Do tego są lekkie, a przecież nie zawsze potrzebujemy tych wszystkich kombajnów, aby skosić 2m² trawnika.

I tak Jakub pokazał kilka alternatywnych rozwiązań:


Opisywane przykłady, można sobie tutaj przejrzeć: github.com/kubamarchwicki/micro-java

Zakończenie konferencji.
Na zakończenie konferencji było jeszcze losowanie nagród, wręczanie statuetek, podziękowania dla wolontariuszy itd. Szkoda, że część konkursów była wcześniej rozwiązywana, tj. w przerwach międzywykładowych. Niszczyło to szansę potencjalnych zwycięzców. Oganizatorzy od razu zapowiedzieli, że rejestracja w przyszłym roku będzie poprawiona i nie będzie tak długiej kolejki. Trzymam za słowo.

Na koniec była jeszcze impreza: Spoina, gdzie można było jeszcze trochę pogadać, zjeść pizzę, napić się piwka i pograć w kręgle. Bardzo fajne zwieńczenie tej konferencji, na którą 1400 wejściówek rozeszło się w 2 godziny od rozpoczęcia rejestracji.

Organizatorzy namawiali jeszcze do udziału w siostrzanej konferencji tj: w Warsjawie. A ja ze swojej strony dziękuję za super konferencję i zachęcam do nowej inicjatywy dBConf.

czwartek, 10 lipca 2014

dBConf 2014 nowa konferencja dla bazodanowców w Polsce

Ruszyła właśnie nowa konferencyjna inicjatywa w Polsce, mianowicie: dBConf 2014, czyli "Bazodanowcy wszystkich środowisk łączcie się!" - tak brzmi motto konferencji. Organizatorem jest PLUG, czyli Polska Grupa Użytkowników Linuxa. Konferencja odbędzie się w dniach 24 - 26 października w Szczyrku. Rejestracja dla uczestników jest już otwarta i do końca lipca obowiązuje promocyjna cena.

A dlaczego o tym wspominam? Widzę trzy powody. Po pierwsze jest to nowa inicjatywa na naszej konferencyjnej scenie i myślę, że sporo z Was może również być zainteresowana udziałem. Wiem, że na co dzień pewnie programujecie, ale z pewnością również nie jest Wam obca tematyka baz danych. No bo przecież gdzieś trzeba składować te wszystkie dane wpisywane przez użytkowników waszych aplikacji.

Po drugie, jak pokazuje agenda, będę występował i przemawiał na tej konferencji. Opowiem trochę o Liquibase, czyli jak zarządzać zmianami w relacyjnych bazach danych. Jest to temat właściwie na styku dwóch światów, tj. kodu i perzystencji, ale organizatorom się spodobało. Chciałem o tym przemawiać na tegorocznej Confiturze, ale mój opis w C4P był za mało seksi i nie przeszedł głosowania. Po za tym w czerwcu miałem masę innych aktywności, więc i tak nie koniecznie znalazłbym czas na odpowiednie przygotowanie się.

Po trzecie i chyba najważniejsze, piszę o tej konferencji, ponieważ można jeszcze zgłaszać swoje wystąpienia, do czego Ciebie (tak Ciebie drogi czytelniku), gorąco zachęcam! Jest to na pewno dobra okazja do sprawdzenia swoich umiejętności prezenterskich, jak i podzielenia się swoją wiedzą z innymi. C4P jeszcze trwa, więc powinieneś się zgłosić! Mnie e-mail od organizatorów, którzy natrafili na mojego bloga, odpowiednio do udziału zachęcił. Czas więc i na Ciebie, nie zwlekaj, tylko zgłoś swój temat.

czwartek, 3 lipca 2014

Relacja z 33 Degree 2014

Tegoroczną konferencję 33Degree rozpocząłem od wykładu Tomka Bujoka pt. 33 things you want to do better. Pierwszy poprzedzający go keynote był nudny, a drugi gdzieś już chyba widziałem lub słyszałem.

Tomek przedstawił sporo narzędzi ze swojego toolboxa, z którymi warto się zaznajomić i w razie konieczności używać. I tak było o bibliotekach: Guava, Lombok, SLF4J, Unitils (testy jednostkowe na plikach), JUnitParams, Awaitility (do testowania wielowątkowego), Byteman (ciekawy projekt do zmiany zachowania kodu produkcyjnego w locie), Spock, grape (do skryptów shelowych w Groovy’m), Git, bash i inne. Na koniec Tomek zareklamował swój projekt: babun. Jest to skonfigurowana powłoka z preinstalowanym gitem i paroma narzędziami do przyjemniejszej pracy z shellem pod Windowsem.

Z powyższych warto sobie odświeżyć Lomboka. Kiedyś już przyglądałem się tej bibliotece, ale był wtedy problem ze wsparciem dla IntellJ Idea. Teraz wygląda na to, że jest już lepiej i doszła możliwość tworzenia builderów za pomocą adnotacji.

O kolejnej prezentacji: RESTing away from hell Jakuba Janczaka nic nie napiszę, bo było nudno i nawet nic nie zanotowałem.

Kolejna prezentacja Get Back in Control of Your SQL Lukasa Edera bardzo mi się podobała. Początkowo prelegent przedstawił wady na przykładowym kodzie takich rozwiązań jak: JDBC, EJB 2 / 3 i Hibernate. Rozwiązaniem na wszystko ma być JOOQ. Narzędzie to generuje na podstawie schematu bazy danych stałe zawierające nazwy tabel, kolumn itp. Później możemy z tego korzystać za pomocą fluent API, które jest bardzo zbliżone do SQL. Właściwie jedno i drugie czyta się tak samo, tyle że w Javie dochodzi kilka kropek i nawiasów. Jeszcze przyjemniej wygląda to w Scali. A całość jest Type Safe. Jest nawet jakiś prosty mapping na obiekty POJO. Niestety JOOQ, jest rozwiązaniem komercyjnym, dla komercyjnych baz danych.

Narzędzie spodobało mi się i chętnie bym z niego kiedyś skorzystał w projekcie. Jakby ktoś chciał obejrzeć wystąpienie (ale z GeeCON'a), jest już dostępne:


A w tak zwanym międzyczasie rozwinął się gorący wątek na Wrocław JUG (wielkie brawa za reaktywację) i padło tam jeszcze parę innych narzędzi tego typu: LIQUidFORM (ale to już trochę martwy projekt) Prevayler i Querydsl.

Kolejny wykład był dosłownie sprintem po nowościach w JEE 7. Prelegent (Arun Gupta) przeleciał w 50 min po 50 nowinkach, dotykając każdego aspektu tej technologii. Dla mnie były to jedynie zmiany kosmetyczne, żadnej nowej wielkiej rewolucji.

Następnie słuchałem prezentacji Josh Longa pt. Microservices and REST with Spring Boot. Było kodowanie na żywo, ale bardzo fajnie. Prelegent zaczął od start.spring.io i pokazał jak niewiele należy samemu dopisać, aby mieć już coś działającego. Było sporo o Richardson Maturity Model i trochę o bezpieczeństwie. W międzyczasie prelegent korzystał z ciekawej wtyczki do Chrome’a do generowania zapytań RESTowych: Advanced REST client.

Dzień drugi zaczął się znów od keynotów. Pierwszy był wypełniony tabelkami z Excela i kolorowymi Clipart’ami z Worda bez konkretnego przesłania. Typowy przykład jak nie robić prezentacji... Szybko opuściłem salę.

Drugi keynote był już lepszy. Prelegent wziął na studium przypadku pisanie latarki na iOS. Najważniejsze jest, aby przy różnych przedsięwzięciach nie tylko programistycznych, odpowiedzieć sobie na pytanie „What, Whoam and Why?”

Prelegent opowiadał dalej o aplikacjach i ich interakcji z użytkownikiem. Nasza aplikacja powinna mówić do pojedynczej osoby (używać odpowiednich form gramatycznych), bo interakcja jest między użytkownikiem a sprzętem. W ten sposób uda nam się przemówić do tłumów. Nie zmienimy w ten sposób całego świata (bo nie możemy), ale zmienimy świat dla jednej osoby, a to już jest sukces. A zmieniając rzeczywistość pojedynczych osób zmieniamy świat wielu osób.

Było jeszcze o reklamach Apple które nie mówią o tym jak świetny jest ich produkt, ale uderzają w ludzkie życie, uczucia i inne wartości. Na koniec było jeszcze o córce prelegenta, która mu zmarła, przez co wykład bardzo oddziaływał na emocje prelegenta, jak i słuchaczy.

Następnie byłem na wystąpieniu Tomka Nurkiewicza na temat OLAPowej bazy danych Saiku. Bardzo fajne narzędzie do generowania raportów, trendów, wykresów itd. Wykład był fajny, było wiele przykładów użycia… Jakbym kiedyś potrzebował, to chętnie spróbuję.

Później byłem na wykładzie Jarosława Pałki na temat Patterns for Organic Architecture. Spodziewałem się, że będzie to prezentacja bardziej techniczna, z przedstawieniem konkretnych wzorców, ale było bardzo miękko, więc się zawiodłem.

Następnie byłem na prezentacji Venkat’a Subramaniam’a, który przedstawiał Projekt Nashorn. Jest to narzędzie, które kompiluje kod JavaScript’a do bytecodeu JVM. Czyli możemy sobie po stronie serwera pisać w JavaScript. Prelegent pokazywał na żywo, jak można wywoływać JS z Javy i na odwrót.

Kolejnym slotem byłem mocno zawiedziony. Najpierw byłem na prezentacji Abdelmonaim Remani dotyczącej debuggingu. Wykład był tragiczny, jak dla studentów pierwszego roku. „Aby znaleźć bug’a trzeba najpierw zlokalizować komponent w którym on jest”. Musiałem opuścić prezentację. W innych salach również nie było lepiej, gdyż sporo ludzi wędrowało wte i wewte.

W końcu wylądowałem na prezentacji dotyczącej github’a i gerrit’a Luca Milanesio. Prelegent porównywał oba systemy i przedstawił workflow, aby push’ować do innego brancha, który po przeglądnięciu się merguje z masterem. Było również wspomniane o Git review plugin, który po wypushowaniu zmian podaje linka do review. Było również o jakimś pluginie do Jenkinsa, który wspiera Gerrita. Całość można przetestować na gerrithub.io, które się integruje z naszymi repozytoriami z GitHuba.

Następnie byłem na prezentacji JavaScript Design Patterns Pratika Patela. Było o wzorcach z JS, za pomocą których możemy osiągnąć pewne elementy, które mamy w Javie. I tak przykładowo za pomocą namespace możemy utworzyć globalny obiekt, w ramach którego możemy trzymać sporo rzeczy. Należy jednak uważać, aby nam ten twór nie urósł za bardzo, bo nie będzie on odśmiecany. Było jeszcze o Mixin module (coś na kształt Dependency Injection), publish subscribre w ramach jednego kontekstu, Command (jako Aspect) i Factory (np. w backbone).

Na koniec została jeszcze zaprezentowana ciekawa stronka: TodoMVC.com na której jest napisana jedna i ta sama aplikacja z wykorzystaniem różnych bibliotek JavaScriptowych.

Trzeciego dnia keynote’y były przesunięte na koniec dnia, więc na szczęście można było je bezboleśnie pominąć. A dzień rozpocząłem od wystąpienia Jarka Ratajskiego Doing WEB development clean way, gdyż miało być duże show i ciekawy sposób prowadzenia prezentacji. I rzeczywiście było trochę strzelania do zombie i wywoływania osób z publiczności do odpowiedzi. Było również poprawianie kodu JS na żywo, ale nie do końca ono działało, ze względu na przeskalowanie ekranu.

Co do konkretów, to Jarek pokazał, że należy korzystać ze statycznej analizy kodu, zwłaszcza w dynamicznych, słabo typowanych językach jak JS, gdzie można bardzo łatwo zrobić sobie krzywdę. Takową analizę można przeprowadzić za pomocą np. jshint. Prelegent również namawiał do korzystania z frameworków JS, takich jak angularjs i do używania pluginów w przeglądarkach wspierających development.

Było również o trendach, jak kiedyś, a jak obecnie tworzy się strony internetowe. I tak na dzień dzisiejszy królują single page applications. Z narzędzi było jeszcze o Lesscss które pomaga nam generować CSS. Wartością dodaną jest możliwość tworzenia zmiennych funkcji itp. do lepszego zarządzania tymi stylami.

Prezentacja fajna w formie, ale jak na konferencję pokroju 33 Degree, to było za dużo show, a za mało konkretów. A wiem, że Jarka na pewno stać na więcej.

Później byłem na prezentacji Jakuba Kubryńskiego na temat Spring Boot. Już wcześniej o tym na konferencji słyszałem, ale postanowiłem jeszcze raz zobaczyć. Generalnie framework (a właściwie zbiór frameworków) został pomyślany dla, ostatnio dość popularnych, microserwisów. Jest również świetną baza, dla nowych projektów, gdyż trzeba bardzo mało napisać aby wystartować z aplikacją. Dodatkowo aplikacja zawiera wbudowanego tomcata lub jetty, więc można bardzo szybko ją wystartować.

Jakub pokazał możliwości frameworka i ostatnie 15 minut był live coding. Poprzez lokalne Wi-Fi można było się połączyć ze stworzoną na szybko stroną i dzięki temu prelegent mógł pokazać satystyki jakie daje nam spring boot. Prezentacja bardzo udana.

Następnie byłem na reaktywnej Javie Tomasza Kowalczewskiego. Było o bibliotece RxJava, ale jakoś mnie nie poniosło. Sposób przemawiania do mnie nie dotarł.

Na koniec konferencji byłem chyba na najmniejszym wykładzie podczas całej imprezy. Była to prelekcja Dariusza Lukszy pt. Your own full blown Gerrit plugin. Na sali było jakieś 10 osób, i wszyscy zgromadzili się bliżej prelegenta. Ale trudno się dziwić, skoro w sali obok było show Venkata.

Darek opowiadał, jak łatwo można napisać plugin do Gerrita, który wykonuje ponowny build naszego kodu na Jenkinsie. Kod można znaleźć tutaj: gerrit-retriggerme. Darek bardzo zwinnie przełączał się pomiędzy otagowanymi wersjami swojego kodu, opowiadając przy tym co się w nim zmieniło. Temat ciekawy, jakby ktoś potrzebował.

Podsumowując konferencję było bardzo gorąco, zwłaszcza w namiocie ze stoiskami sponsorskimi. Dmuchawy i otwieranie kolejnych ścian trochę pomagało, ale to i tak lepiej niż gnieździć się w wąskich korytarzach kina. Na szczęście stanowiska sponsorskie szybko reagowały na upał i załatwiały zimne napoje w kolejnych dniach konferencji.

Fajnie też, że przygotowano aplikację na telefon z rozkładem jazdy, ale brakowało mi w niej informacji o tym, kiedy, gdzie, jaki konkurs jest rozstrzygany. Pomogłoby to jeszcze bardziej promować się sponsorom konferencji. W tym roku chyba najbardziej zaszalał Luxoft, dając (prawie) każdemu uczestnikowi tableta. Wiadomo, że nie był to jakiś super sprzęt, ale zasponsorowanie tak sporej ilości urządzeń to na pewno było nie lada wyzwanie i koszt. Choć pewnie spora większość uczestników już takie zabawki dawno posiada w swoich zasobach.

Co do poziomu wykładów, to było bardzo nierówno. Nie było chyba żadnego, który by wywrócił, lub choćby zachwiał mój dotychczasowy światopogląd. Brakowało mi również bardziej praktycznych warsztatów.

Sporo czasu zajęło mi sporządzenie tej notki, ale niełatwo jest streścić 3 dni konferencji w jeden wpis. A już na dniach zbliża się Confitura. Mam nadzieję, że relacja z tej imprezy powstanie szybciej.

środa, 23 kwietnia 2014

DevCrowd 2014

W tym roku udało mi się ponownie (bo po raz drugi) zawitać na konferencję DevCrowd do Szczecina. Nie jest to kolos kalibru GeeCona czy 33rd Degree, ale tworzy ona swój własny specyficzny klimat. Przygotowano nawet aplikację na androida, pomagającą w podjęciu decyzji, na którą prelekcję wybrać się aktualnie. A do wyboru były dwie równoległe ścieżki.

Rozpoczęcie konferencji przeciągnęło się mocno, przez co do obiadu wszystkie wystąpienia zostały przesunięte o kilkanaście minut. Na szczęście po obiedzie wszystko wróciło na swoje miejsce.

Na początek udałem się na prezentację Macieja Opały i Wojtka Erbetowskiego pt. Designing API for Mobile App. Jak więc projektować serwerowe API dla aplikacji mobilnych? Przede wszystkim z powodu powolnych łączy komórkowych, problemów z zasięgiem, przemieszczania się użytkownika, należy ograniczyć liczbę przesyłanych danych do minimum. Jeśli wystawiamy po stronie serwerowej RESTa, to lepiej jest przesyłać dane za pomocą JSONa niż XMLa. W przykładzie prelegentów, pozwoliło to na zmniejszenie wielkości wiadomości o 37%.

Warto również korzystać z Cache’a Http po stronie serwera, jak i Androida. W telefonie można w tym celu skorzystać z tych narzędzi: retrofit, OkHttp i HttpResponseCache. Dobrym sposobem na zmniejszenie rozmiaru paczki danych przesyłanej przez sieć, jest skorzystanie z kompresji GZIPa. Trzeba jednak uważać, gdyż dla małych plików, może ona nie opłacać się.

Przedstawiony był również problem wersjonowania naszych Interface’ów. Wynika on z opóźnionego aktualizowania aplikacji na telefonach użytkowników, czyli mogą wymagać starego API. Najlepiej, aby się ono nie zmieniało, ale najczęściej jest to niemożliwe. I tak można podawać Path parameter (np. http://api.example.com/res/v1) media type (lub custom header) (np. http://api.example.com/res+v1) albo subdomenę (np. http://v1.api.example.com/res). Wszystkie rozwiązania posiadają jednak swoje wady.

Na koniec wspomniano jeszcze o narzędziu Swagger, do tworzenia dokumentacji (coś ala javadoc) dla RESTowych aplikacji.

Zawsze bałem się prezentacji, gdzie jest dwóch prelegentów. Najczęściej oznaczało to, że prowadzący zbytnio nie znają się na temacie, lub mają opory przed wystąpieniami publicznymi. Tutaj jednak wypadło to dobrze i sprawnie.

Na drugą prezentacje wybrałem wystąpienie Mateusza Kaczmarka pt. Good design makes us happy – czyli podejmij tę decyzję za mnie. Na początku Mateusz polecał książki, od których wszystko się u niego zaczęło, czyli pozycje Dona Normana (nie pamiętam którą dokładniej) i Steva Kruga Don’t Make Me Think. Na zajawkę zamieszczam prezentację z TEDa tego pierwszego Pana.



Następnie prezentacja była wypełniona przykładami, gdzie zastosowano fajne, udane pomysły, jak i przedstawiono firmowe porażki. I tak Apple swego czasu było warte więcej niż polskie PKB, Amazon stworzył przyjemny proces zakupowy, Google uznało, że wyszukiwanie musi być proste itd. Natomiast w sektorze gier, firma EA zdobyła 2 razy z rzędu tytuł najgorszej firmy roku w USA. A zasłużyła sobie na to, dzięki wypuszczaniu niedokończonych tytułów. Inaczej było w przypadku Diablo 2 i Starcrafta, na które wydawcy kazali sobie dłuuugo czekać, co zostało sowicie nagrodzone. Również Blizzard (wydawca Diablo) pokazał, jak można naprawić swoje błędy. Przykładowo firma zamknęła sklep, za pomocą którego gracze handlowali przedmiotami w grach, gdyż to psuło rozrywkę. I ogłosili to ludzie wyglądający jak gracze, a nie panowie w garniturkach.

Co więc robić aby uzyskać UX User experience? Dla ludzi biznesu trzeba wkładać więcej wykresów do naszych aplikacji, a dla szarych Kowalskich należy upraszać nasze interfejsy graficzne. Dzięki temu użytkownicy czują się bezpieczniej i będą korzystać z naszej aplikacji. Warto też podejmować typowe decyzje za użytkownika, ograniczając mu liczbę opcji do skonfigurowania, gdyż najgorzej to stracić zaufanie użytkownika, a jeszcze gorzej jego pracę.

Prezentacja fajna, aczkolwiek był to raczej wstęp do tematu, który nie jednemu zapewne uświadomił istnienie problemu. Brakowało mi bardziej konkretnych rad i wytycznych, jak tworzyć proste i przyjemne interfejsy użytkowników. Na koniec wspomniano o innej książce Steva Kruga Rocket Surgery Made Easy, traktującej o tym, w jaki sposób tworzyć testy interfejsów na użytkownikach końcowych.

Następnie udałem się na prezentację Koziołka: Jak pracować i nie zwariować. Rozmawialiśmy o tym, co najbardziej wpływa na naszą pracę (a wiec krzesło, klawiatura, dysk SSD, RAM i 2 monitory). Każdego dnia powinniśmy lepiej poznawać nasze IDE, biblioteki i narzędzia. Warto też automatyzować jak najwięcej, gdyż jesteśmy leniwi, a jak nie będziemy musieli wielokrotnie pisać tego samego, to życie będzie przyjemniejsze.

Dalej było o introwertykach, psychopatach, dzieciach autystycznych, mądrej asertywności, drugim znaczeniu słowa SCRUM, potrzebie twardego resetu, śnie i przerywnikach w pracy. Ciekawy był pomysł Koziołka, jak odliczać sobie czas w technice pomodoro. Warto do tego użyć gier na facebooku, w których coś tam po jakimś czasie można zebrać i na nowo posiać. Wymusi to na nas regularne przerwy dla umysłu. Z praktycznych narzędzi, było wspomniane o bibliotece jFairy. która to generuje losowe dane.

Była to fajna i śmieszna prezentacja.

Następnie byłem na prezentacji Bartłomieja Nićka pt. Programista to za mało. Prelegent bardzo chaotycznie mówił i w ogóle nie zrozumiałem ani grupy docelowej, ani celu prezentacji. Było coś o wadach naszego zawodu, wadach samych programistów, jak się dawniej realizowało projekty, a jak się to robi obecnie. Prezentacja bardzo nieudana. Z prezentacji jedynie utkwiła mi różnica miedzy Computer Programer a Software Developer wg. US Bureau of Labor Statistic. A więc:

Computer programmers write code to create software programs. They turn the program designs created by software developers and engineers into instructions that a computer can follow.

Software developers are the creative minds behind computer programs. Some develop the applications that allow people to do specific tasks on a computer or other device. Others develop the underlying systems that run the devices or control networks.

Następnie był smaczny obiad i wystąpienie Pawła Szulca na temat JavaScriptu. Nie wiem czy to był celowy zamysł organizatorów, aby Pawła umieścić zaraz po obiedzie, ale jak dla mnie był to strzał w dziesiątkę! Nieprzerwany potok słów Pawła nie pozwalał ani na chwilę nudy i raczej nikomu nie chciało się spać.

Prelegent przekonywał nas, że JavaScript nie jest Mordorem, którego należy się obawiać, a wystarczy poznać i zrozumieć różnice w stosunku do Javy, to będzie dobrze. Przede wszystkim JS jest językiem funkcyjnym, a nie obiektowym. To, co początkowo przeraża, to możliwość wywołania funkcji z inną liczbą argumentów niż ją zadeklarowano! I tak niezdefiniowane argumenty będą undefined, a nadmiarowe będą zignorowane. W JS każda funkcja posiada lokalną zmienną argumentsktóra to przechowuje wartości argumentów przekazanych nam do funkcji.

Następnie Paweł bardzo fajnie omówił sposoby wywoływania funkcji w JS i czym się one od siebie różnią. A różnią się zazwyczaj kontekstem, na rzecz którego będzie odbywać się wywołanie, tzn. możemy otrzymać coś innego pod lokalna zmienną this. I tak mamy 4 możliwości:

1.    Wywołanie bezpośrednie powoduje, że funkcja otrzyma domyślny context, w przypadku przeglądarki jest to obiekt window
function func() {
    console.log(this)};

func();
// [object Window]
2.    Wywołanie jako metoda. Polega to na przypisaniu funkcji do pola w obiekcie. Dzięki temu dostajemy metodę, którą mozemy wywołać. W tym przypadku jako this otrzymujemy obiekt na rzecz którego funkcja została wywołana.
function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

variable.method = func;
variable.method();
// Object { property="value", meth=func()}
3.    Wywołanie jako konstruktor, a więc ze słówkiem kluczowym new powoduje utworzenie pustego obiektu (dziedziczącego z prototype). Funkcja ma w takim przypadku za zadania zainicjowanie obiektu, który zostaje zwrócony jako rezultat wywołania.
function func() {
    console.log(typeof(this))
}

var obj = new func('abc');
// object
4.    Wywołanie za pomocą applay() i call(). Przydaje się ta możliwość, gdy nie chcemy kopiować funkcji do innego obiektu, aby nie powtarzać kodu. Podmienimy jednak przez to context, czyli this. Predefiniowana funkcja applay() przyjmuje poza pierwszym argumentem tablicę z argumentami, a call() przyjmuje argumenty osobno (po prostu po przecinku)
function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

func.call(variable)
// Object { property="value"}
Było jeszcze trochę o Scop’ach, Hoistingu, domknięciach i modułach. Warto swój kod Javaskriptowy testować, np. Za pomocą narzędzi jak jasmine, czy mocha. Warto również testować swój kod statycznym analizatorem, np. JSLint. A jak musimy się na szybko nauczyć tego języka, to warto się zabrać za czytanie 2-giego i 3-ciego rozdziału Secrets of the JavaScript Ninja.

Kolejną prezentacją, na którą się udałem, było wystąpienie Tomka Borka, na temat zaawansowanego testowania. Chciałem początkowo iść na SCRUM, but, ale już miałem dość miękkich prezentacji i potrzebowałem czegoś technicznego posłuchać.

Na początku Tomek przestrzegał, aby nie używać PowerMocka, gdyż jest bardzo czasożerny, gryzie się z narzędziami do testowania pokrycia kodu, rzuca kiepskie wyjątki, a przede wszystkim pomaga początkującym pisać brzydki kod.

Dalej było trochę o adnotacji Parameterized z JUnita i ich alternatywach. Ciekawie wygląda projekt zohhak, którego wcześniej nie znałem.

Prelegent opowiedział jeszcze o paru ciekawych pomysłach, dotyczących testowania. Przykładowo, gdy wystawiamy usługi RESTowe na zewnątrz, to warto sprawdzić, czy te opublikowane interfejsy nie zmieniły się. Co do adnotacji @Ignore, to powinna być przy niej data do kiedy może ona być w teście i dlaczego.

Było jeszcze o narzędziach pomagających ogarnąć nam bazę danych, tj Liquibase, DBUnit i Databene Benerator. To ostatnie narzędzie pomaga generować testowe zbiory danych.

Z innych ciekawych (albo też egzotycznych) narzędzi był wspomniany Sureassert. Działa on tylko z Eclipse i pomaga realizować ideę design by contract i ciągłego uruchamiania testów (czyli coś jak infinitest). Niestety nie jestem fanem podejścia programowania kontraktowego i rozwiązanie działa tylko w Eclipsie.

Było jeszcze wspomniane o trzech bibliotekach, pomagających w skanowaniu naszych klas w celu poszukiwania adnotacji: Scannotation, Reflections i Classindex. Na koniec prezentacji było fajne podsumowanie, pokazujące co było omawiane na prezentacji.

Na koniec organizatorzy konferencji przygotowali niespodziankę, a mianowicie zdalne wystąpienie Adama Bienia z tematem How To Tackle Java EE 7. Live streaming był bardzo dobrze przygotowany, całość była transmitowana przez platformę ustream.tv. Prelegent zmieniał tło na którym mówił i wyglądało to bardzo profesjonalnie. Inne jego prezentacje można obejrzeć tutaj: tv.adam-bien.com.

Widać że Adam ma sporo doświadczenia w tym temacie. Było sporo kodowania na żywo, niewiele slajdów (które są dostępne tutaj), a pytania z publiczności można było zadawać za pomocą twittera. Ciekawe rozwiązanie, aczkolwiek z telefonu trochę dłużej pisze się twitnięcie, przez co było spore opóźnienie w dialogu.

Co do samej prezentacji, to Adam pokazał nam, jak można łatwo i szybko zbudować projekt z wykorzystaniem Javy EE 7. Polegało to na skorzystaniu z archetypu mavenowego i wyrzuceniu połowy domyślnego pom’a. Projekt Prelegent twierdził, że nie powinno się dodawać biblioteki do projektu „na zaś”, tylko w momencie gdy naprawdę są potrzebne. Przez to czas build’a i deploymentu powinien (przynajmniej początkowo) trwać krócej.

Generalnie kodzenia było za dużo i po jakimś czasie człowiek się wyłączał i gubił w kodzie. Dla mnie był to trochę odgrzewany kotlet, gdyż podobną prezentację widziałem na JDD 2012 z tą różnicą, że wtedy była Java EE 6 na tapecie. Jeśli ktoś chce obejrzeć tą prezentację, to jest ona dostępna poniżej:


Na zakończenie było jeszcze zbieranie ankiet i losowanie nagrody.  Konferencja wypadła bardzo fajnie. Brakowało mi jedynie typowo technicznych zagadnień, no ale trudno. Może następnym razem.

sobota, 14 grudnia 2013

I znów Global Day Of Code Retreat

Kolejny rok mija i kolejny Global Day of Code Retreat już za nami. W tym roku planowałem początkowo uczestniczyć w tym evencie w Wolfsburgu, ale ostatecznie wybrałem Berlin, aby się trochę zorientować, jak wygląda tamtejsza sytuacja projektowa i mieszkaniowa. A CR to zawsze dobra okazja do tego. To już kolejny raz (6ty, jeśli nie licząc jakiś mniejszych, wewnętrznych inicjatyw), kiedy biorę udział w tego typie wydarzeniu, więc widzę jak się ono zmienia w czasie. Rok temu prawie 200 miast na całym świecie organizowało CR, a w tym było 165 lokalizacji. Tendencja więc spadkowa.

Jako że Berlin uchodzi za bardzo Europejskie miasto(o czym wspominałem już kiedyś w poprzedniej relacji), spotkanie było prowadzone po angielsku. Jednak w międzyczasie można było usłyszeć sporo języka niemieckiego, jaki i polskiego:) Zaczęliśmy więc od sortowania uczestników bąbelkowo, aby zorientować się kto jest mocny w TDD, pair programingu, a kto jest kompletnie świeży. No i w ten sposób najlepsi zasiedli do wspólnego stanowiska pracy z kompletnymi świeżakami. Nie ma to jak nauczanie innych:)

W pierwszej sesji dostałem więc niemieckiego studenta, który w javie pisze od święta, studiuje coś tam powiązane z medycyną, a na co dzień klepie w php. Używa do tego Vim’a. Jest on do niego tak przyzwyczajony, że korzysta z ichniejszych skrótów klawiszowych bezpośrednio w Eclipsie. Byłem pod wrażeniem, choć wątpię, aby była to optymalna droga do wykorzystania w pełni możliwości Eclipse’a.

Drugą sesję pokodowałem z przyjacielem Szymonem, z którym wspólnie przyjechałem do Berlina. Pobawiliśmy się trochę Scalą, ale nie szło nam jakoś najlepiej. Na pewno jeszcze sporo czasu trzeba zainwestować w poznawanie tego języka, aby móc z niego swobodnie korzystać. Niestety kiepska pogoda w ostatnim czasie, brak śniegu i gorączka przedświąteczna, nie jest najlepszym czasem do nauki nowych rzeczy. Dlatego kurs na Courserze sobie troszkę odpuściłem:(

Trzecią sesję miałem sposobność spędzić z pewnym Syryjczykiem, który na co dzień jest adminem, ale chciałby robić jakieś przyjemniejsze rzeczy. Ta sesja była dla mnie bardzo wymagająca pod względem komunikacji, ze względu na mój nienajlepszy angielski, ciężki w zrozumieniu angielski partnera i jego trochę słabą wiedzę w zakresie Javy. Myślę, że ziomek się sporo ode mnie nauczył.

Po trzeciej sesji była mała retrospekcja. W grupach 3 osobowych, mieliśmy napisać na kartkach, co się nauczyliśmy i co chcielibyśmy się nauczyć. Kartki przykleiliśmy na szybę i chwilę o tym dyskutowaliśmy.

Później była przerwa obiadowa. Były kanapki, a nie porządny ciepły, pyszny obiad jak to jest w formule tego wydarzenia zapisane. No ale trudno, nie to jest przecież najważniejsze.

Na 4tej sesji znów próbowałem pisać w Scali z innym nowopoznanym kolegą z Wrocławia. Tutaj trochę ciężko było nam dojść do porozumienia, gdyż zmierzaliśmy w innych kierunkach: ja kładłem nacisk na TDD, a kolega na implementację i lukier składniowy, jak to można by lepiej i ładnie zrobić w Scali.

Po czwartej sesji musieliśmy jednak opuścić warsztaty. Podziękowania dla globalnych i kontynentalnych sponsorów wydarzenia, a także dla sponsora w Berlinie: ImmobilienScout24, gdzie odbywał się event. Podziękowania również dla Martina Klose (@martinklose), który jak zwykle stanął na wysokości zadania i dobrze poprowadził kolejny raz to wydarzenie.

A co się zmienia, jeśli chodzi o Code Retreat? W Berlińskiej edycji zastosowano fajny pomysł przy rejestracji. Należało zapłacić 15 Euro, które było później zwracane, gdy uczestnik się pojawił na spotkaniu. Motywowało to ludzi do przychodzenia, gdy już byli zapisani, a gdyby naprawdę coś komuś nagłego wypadło, to strata 15 E jest do przełknięcia. Uważam to za super pomysł.

Ponadto zauważyłem, że osoby bardziej doświadczone w TDD i w formule Code Retreat już nie tak licznie w nim uczestniczą. Może to wynika z braku chęci nauczania innych, lub są już zmęczenie problemem gry w życie? Albo stwierdzają, że już nic nowego nie mogą się nauczyć i wybierają inne, ciekawsze aktywności w tym czasie. Ciężko mi to oceniać, ale wydaje mi się, jakby młodsi niedoświadczeni uczestnicy byli bardziej widoczni na tego typu wydarzeniach. To oznacza, że nadchodzą nowi, pełni zapału i żądzy wiedzy programiści, a więc tym bardziej nie można zostawać z tyłu…