poniedziałek, 12 grudnia 2011

Agile Development Day

W sobotę 10 grudnia odbył się w Warszawie Agile Development Day. Była to impreza zorganizowana przez firmy Sages i Pragmatis. Event polegał na wspólnym tworzeniu aplikacji, ćwiczeniu TDD, programowania w parach i innych zwinnych praktykach. Był do tego Continous Integration (build był uruchamiany co git push) i Continous Delivery (deployment co udany build).

Aby dostać się na warsztaty trzeba było się wcześniej zapisać. Z ponad 60 osób chętnych, wybrano 22 w tym mnie :) Została przygotowana startowa baza kodu i udostępniona na github’ie. Trzeba było więc wcześniej ściągnąć kod i przygotować środowisko. Technologicznie był Spring Core, Spring MVC, JSP, Casandra, Maven. Jako że nie miałem wcześniej możliwości korzystać ze Spring’a w warunkach bojowych (po za jakimiś szkoleniami / prezentacjami), to miałem z czym się bawić. Zaprzyjaźniłem się więc z książkami na ten temat i archetypami kodu, aby porozkminiać te technologie i aby było na czym bazować.

Event zaczął się o 8 rano w Millennium Plaza. Najpierw było przywitanie i omówienie zasad, co będziemy robić w ciągu dnia. Następnie było o aplikacji jaką mamy stworzyć. Mianowicie za pomocą pisanego serwisu internetowego można się chwalić czego się nauczyliśmy, ile czasu na to poświeciliśmy i ile punktów zebraliśmy. Taki jakby twitter, tyle że piszemy co poznaliśmy, jaki był stopień trudności, system nalicza jakieś tam punkty i chwalimy się tym przed znajomymi. Plus jeszcze jakieś pierdoły do tego.

Po omówieniu wymagań aplikacji było wprowadzenie do Casandry, gdyż była to najbardziej „dziwna” i nieznana technologia z używanego technology stack. Później było szybciutko o Spring MVC i zaczęło się. Uczestnicy mieli wybrać sobie couch’a i osobę do pary (najlepiej aby ktoś znał Springa MVC). Jako że znałem Piotra (jednego z prowadzących) to się z nim dogadałem i wraz z Marcinem usiedliśmy do pierwszego user story.

Wybraliśmy sobie na tapetę formatowanie czasu, ile zajęła nam nauka danej technologii. Napisaliśmy kilka testów i zaczęła się zabawa. Postanowiliśmy dodać do projektu bibliotekę JUnitParams do pisania sparametryzowanych testów w JUnit’cie. Swoją drogą jest to biblioteka napisana przez Pawła Lipińskiego, który organizował, prowadził i kodował na warsztatach. Pomogło nam to pisać ładniejsze, parametryzowane testy w JUnicie, podczas pierwszej iteracji.

Wcześniej ustalono, że iteracje będą trwały po półtorej godziny i pomiędzy nimi będą zmiany par, a co kilka iteracji będzie retrospekcja. Czyli jakby jeden dzień ze sprintu został skompresowany do 1,5h a cały Sprint do 5ciu dni (czyli pięciu iteracji). Taka organizacja pracy bardzo motywowała do jak najszybszego kończenia zadań. Nie inaczej było w naszej parze, gdyż chcieliśmy jak najszybciej zobaczyć choćby częściowy efekt naszej pracy na „live”, mimo że nie wszystkie przypadki mieliśmy obsłużone. No i tu zaczęła się prawdziwa walka z technologiami.

Gdy jeszcze wczoraj Piotrek w projekcie dodał Tiles’y zaczęła się cała aplikacja wysypywać. Doszedł on do wniosku, że Casandra z Tiles’ami nie funkcjonuje ;) i wycofał zmiany. W naszej historyjce chcieliśmy (wręcz musieliśmy) skorzystać z JSTL’owego Taga c:forEach, ale też nie chciało działać. Był ten sam błąd co w przypadku Tiles’ów. Nasza koncepcja zamknięcia wyświetlania czasu we własny Tag JSTL’owy również nie zadziałała i trzeba było to jakoś inaczej obmyślić. To wszystko pewnie przez Casandrę ;)

Akurat nadszedł koniec pierwszej iteracji i nastąpiła rotacja par. Jako, ze pracowaliśmy na moim laptopie, to Marcin odszedł, a dołączył się Michał. Porozmawialiśmy chwilę, co zrobić z naszym problemem niemożliwości użycia JSTL’a i zaproponowałem, aby stworzyć Data Transfer Object (DTO) i za jego pomocą wyświetlać już odpowiednio sformatowany tekst. Coś tam niby się udało, ale potem było trochę walki z merge’owaniem zmian. Niestety szybko się okazało, że user story bardzo nachodzą na siebie, wręcz się powtarzają. Powodowało to masę konfliktów i trudności z push’owaniem zmian, gdyż po pull’u, odpaleniu testów, i przy próbie ponownego push’a okazywało się, że ktoś w między czasie zdążył wypushować swoje zmiany i proces trzeba było powtarzać ponownie.

Po drugiej iteracji postanowiono zrobić retrospekcję. Mieliśmy na małych, przylepnych karteczkach wypisać, co nam się podobało, a co nie i przykleić to na ścianę. Później trzeba było w ciszy to pogrupować (silent sorting) i ponazywać grupy. Po „uroczystym” przeczytaniu tego co jest fajne i niefajne, każda para wraz ze swoim mentorem miała się zastanowić, co zrobić, aby było lepiej. Super pomysłem było wprowadzenie stand-up meeting’ów - w trakcie trwania iteracji - [chyba] co 20 minut, aby poprawić komunikację w zespole i wiedzieć, kto co robi i na kiedy będzie. Innym ciekawym pomysłem było wpisywanie podczas commit'a / push’a jako autor numer implementowanego user story i nazwiska autorów. I rzeczywiście, początkowo brakło konwencji wypychania zmian do repozytorium, aby były one jednolite i czytelne.

Następnie był obiad i kolejna iteracja. Tym razem osoby, które przez dwie iteracje robiły jedną opowieść, miały się przesiąść. Może to trochę nieoptymalne posunięcie z punktu widzenia ukończenia zadania, ale podczas eventu chodziło o wspólną naukę. Trafiłem więc do zadania wyświetlania podpowiedzi. Mianowicie gdy wpisujemy technologię, której się właśnie nauczyliśmy, ma nam podpowiadać czy było to łatwe, średnie czy trudne. Wiązało się to z koniecznością napisania kawałka JavaScript’a, ale na szczęście to akurat poszło gładko. Problemem się jednak okazało, gdy coś co było zależne od naszego zadania (mianowicie dodawanie nowych umiejętności) czy jest już skończone i czy dane lądują tam, skąd je odczytujemy. Niestety ciężko w Casandrze cokolwiek podejrzeć, co wylądowało w bazie danych, gdyż zapisują się tam dane binarne. Nad tym zadaniem pracowałem przez dwie iteracje i później na ostatnią iterację, znów trzeba było się przesiąść.

Dosiadłem się więc do Bartka i tam nawet początkowo było fajnie (nie znaczy to wcale, że wcześniej było źle). Dostałem szybkie wprowadzenie co robimy, że właśnie jest test z nową funkcjonalnością i mam ją zaimplementować. Chwila ogarniania / czytania kodu i z pomocą Bartka udało się. Problem niemożliwości skorzystania z JSTL’a rozwiązano użyciem Skryptletów. Coś tam nawet się udało wyświetlić, ale nie można było wypchać zmian, gdyż najpierw trzeba było powalczyć  z kwestią, co wyświetlać, jak ktoś jest niezalogowany. Inny zespół pisał back-end do tej funkcjonalności i niestety czas warsztatów nie pozwolił już na połączenie naszych zmian.

Po piątej iteracji przejrzeliśmy backlog zapisywany na tinypm.com. Okazało się, że niewiele funkcjonalności udało się w pełni zaimplementować. Paweł pokazał jednak na żywym środowisku, że coś tam działa. Patrząc na statystyki na Jenkinsie, było widać, że w ciągu zmian udało się wypchnąć do repozytorium kod 54 razy z czego tylko 9 się wywaliło. Uważam to za niezły wynik, biorąc pod uwagę to, że dla uczestników był to świeży projekt, bez wypracowanych konwencji i nie każdy musiał znać wszystkie wykorzystywane technologie. Poniżej przedstawiam trend tesów.


Podczas warsztatów budowały się build’y od 88 do 142. Wcześniejsze build’y pochodziły z przygotowań do warsztatów. Widać wyraźnie że od 95 build’a liczba testów zaczęła znacząco rosnąć, z każdą nową zmianą.

Na koniec nadszedł czas na podsumowanie. Poprzestawialiśmy trochę stoły i ułożyliśmy krzesła w dwa kółka. W środku było 5 krzeseł, a  na zewnątrz reszta. Kto siedział w środku ten mógł mówić, pod warunkiem, że cztery wewnętrzne krzesła były zajęte. Jedno było wolne, aby kogoś mógł się dosiąść i oczywiście można było spokojnie opuścić wewnętrzny krąg. Osoby siedzące w środku mówiły o swoich odczuciach dotyczących warsztatów, co się nauczyły itd. Czyli taka runda feedback’owa dla innych uczestników i organizatorów.

Jako że ja nie miałem okazji zasiąść w środku, to swoją opinię wyrażę teraz. Ogółem event wyszedł bardzo fajnie. Organizacja w porządku: były kanapki rano, napoje i ciasteczka przez caly dzień, dobry obiad w trakcie (i nie była to pizza). Lokalizacja warsztatów bardzo dobra, mianowicie blisko centralnego – ważna kwestia dla osób przyjezdnych, a tych nie brakowało. Ja sam przyjechałem z Wrocławia, ale spotkałem również ludzi z Gdyni, Gdańska, Wrocławia, a nawet z Berlina. Organizacja pod względem technicznym również dobra – były dwa rzutniki, na jednym Jenkins, a na drugim live aplikacja. Bardzo dobrym pomysłem było przygotowanie zaczynu aplikacji i jej udostępnieniu w necie. Również Continous Integration i Delivery daje bardzo fajny efekt psychologiczny. Można było szybko zobaczyć swoje zmiany na Jenkinsie jak i na na środowisku „produkcyjnym”.

Niestety, jak to sami organizatorzy przyznali, rozpoczęcie przygotowywania tej aplikacji na tydzień przed warsztatami to było trochę za późno. Wynikały później z tego problemy z technologiami (niemożliwość użycia Tiles’ów i JSTL’a). Uważam również, że dobranie stosu technologicznego było nienajszczęśliwsze. Fajnie, że było cos egzotycznego (Casandra), ale mało kto wiedział, jak z tego odpowiednio korzystać. Do tego zastosowanie Springa MVC i JSP powodowało, że czasem trzeba było się męczyć z JavaScriptem (AJAX i jQuery). Te problemy technologiczne powodowały, ze ciężko było się skupić na czystym pisaniu kodu (nie wspominając już o TDD), a trzeba było się męczyć ze zgraniem technologii i merge’owaniem zmian.

Wcześniej wydawało mi się że w miarę ogarnąłem już Git’a, ale dopiero tutaj w warunkach bojowych zweryfikowałem swoje poglądy na ten temat. Problem scalania zmian występuje (pushowaliśmy do jednej gałęzi, aby Continous Server już dalej robił swoje), jak w każdym innym systemie kontroli wersji. Jakub Nabrdalik mówił, że jednym z możliwych sposobów jest zrobienie miecza z dwóch zwiniętych kartek papieru i ten kto aktualnie posiada miecz może push’ować. Jak ktoś innyc chce to robić, to musi uzyskać ten miecz. Wydaje mi się, że skorzystanie z Mercuriala mogło by trochę ułatwić sprawę z łączeniem zmian w kodzie, ale nie jestem ekspertem w tym temacie.

Innym poważnym minusem co do warsztatów, było przygotowanie user story’s. Bardzo często były one do siebie podobne, zachodziły na siebie i od siebie zależały. Jednak podczas wyboru user story nie posiadaliśmy tej wiedzy. Na przyszłość trzeba lepiej przygotować historyjki do zaimplementowania, wraz z grafem, co od czego zależy, co trzeba zrobić najpierw i z lepszym opisem. Większość opowiastek dotyczyła strony głównej, przez co wzajemnie sobie modyfikowaliśmy zawartość tych samych plików, co prowadziło do problematycznych konfliktów. Na przyszłość można kilka opowiastek udostępnić np. tydzień wcześniej, aby można było w domu coś na rozgrzewkę napisać. Zachęciło by to bardziej do zajrzenia w kod i do lepszego przygotowania do warsztatów. I najlepiej aby były one możliwie jak najbardziej rozłączne.

Również wybór Casandry na bazę danych nie było chyba najlepsze, gdyż z rozmów pomiędzy ludźmi słyszałem, że niektóre zespoły sporo się z nią męczyły. Fajnie poznać przy takiej okazji coś nowego, ale wybór chyba nie był najszęśliwszy. Jak bym proponował na następny raz jakąś bazę działającą w pamięci, inną NoSQL’ową (obiektową, key-value) lub jakąś lekką SQLową, którą wszyscy znają. Jako technologię widoku proponowałbym GWT (lub coś o podobnej koncepcji), gdyż tam nie trzeba się bawić z JavaScriptem, ani z JSP, a maksymalnie z niewielkimi kawałkami HTML’a.

Nie oznacza to, ze nic nie wyniosłem z warsztatów. Miałem w końcu motywację do lepszego poznania Springa, Git’a, JUnitParams… Zrozumiałem, że nie tylko testy jednostkowe są najważniejsze, ale obok nich musi się znajdować kilka integracyjnych i akceptacyjnych (już w początkowym stadium projektu). Przykładowo prosty test end-to-end uruchamiający przeglądarkę na stronie głównej i sprawdzający czy jakiś tam przycisk istnieje, pozwolił nam szybko wykryć, że Tagi w JSP nie chcą działać. Inna sprawa ze testy nie były podzielone na jednostokowe i inne (trwające dłużej), przez co ich uruchamianie było trochę przydługie.

Dowiedziałem się też o fajnej technice, podkreślającej współwłasność kod. Mianowicie po za wywaleniem z szablonów plików / klas i metod informacji o autorze, można dać wszystkim pracownikom z danego projektu, jedno konto i hasło do repozytorium. Dopiero wtedy powstaje wspólny kod i nikt się nie boi modyfikować nieswoich części. Poznałem również trochę bardziej w praktyce procesy zachodzące w procesie Agile'owym, jak i mogłem się dowiedzieć jak wygląda IT w innych miastach.

Zawsze z takich wydarzeń można wynieść ciekawe skróty klawiaturowe. I tak dla IDEI: Crtl + Shift + Enter - Statement Comlete, czyli dodanie średnika na końcu linii. Z analogicznych skrotów korzystałem w NetBeans’ie, ale tam to było to Ctrl + ; i Ctrl + Shift + ;. Innymi interesującymi skrótami w Idei są: Ctrl + Shift + T czyli przejście do klasy, która testuję aktualną klasę, w której jesteśmy i Ctrl + Shift + N (odpowiednik Eclipsowego Ctrl + Shift + R), czyli wyszukiwanie po nazwie pliku z projektu.

Ciekawe, nowopoznane skróty dla Eclipse’a to Ctrl + Shift + M - zaimportowanie statyczne danej metody na której znajduje się aktualnie focus. Przydatne zwłaszcza jak mockujemy z Mockito i chcemy samo when() zamiast Mockito.when(). Ponadto Ctrl + Shift + O czyli organizacja importów (w Idei można zrobić, aby automatycznie narzędzie przed commitem zmian, odpowiednio organizowało importy). I na koniec syso + Ctrl + Spacja, czyli skrót od System.out.println();. W Idei jest to sout + Tab co jest według mojego gustu fajniejsze.

Dobra to chyba tyle z podsumowania wydarzenia. W tym roku już się żadna konferencja / warsztaty nie szykują, więc trzeba będzie z tym poczekać do przyszłego roku. Mam nadzieję na kolejną edycję Agile Development Day lub podobny tego typu event.

niedziela, 4 grudnia 2011

I po Global Day of Code Retreat 2011 w Krakowie


W sobotę 3ciego grudnia miało miejsce ciekawe wydarzenie: Global Day of CodeRetreat. Czym jest samo CodeRetreat można poczytać w moim wpisie z przed ponad roku: Wrażenia po CodeRetreat we Wrocławiu. Kilka miast przypadkiem zaczęło organizować u siebie tego typu imprezę akurat 3ciego grudnia. Postanowiono więc, tą datę ochrzcić Globalnym Dniem CodeRetreat’a i zaczęto masowo organizować to wydarzenie na całym świecie. Kraków był jednym z Polskich miast (zaraz obok Łodzi, Poznania i Warszawy), który zorganizował „Rekolekcje Kodu” i postanowiłem się tam wybrać.

Miałem okazję pokodować ze znajomymi jak i z kompletnie obcymi osobami. Zdziwiło mnie, że mimo iż wielokrotnie podchodziłem do problemu Gry w życie Conwaya (na poprzednich CR’ach jak i w domu), to i tak poznałem kolejne, nowe sposoby, jak można ugryźć problem. W wolnej chwili trzeba będzie jeszcze sprawdzić kilka rozwiązań.

Podczas wydarzenia udało mi się m.in. wraz z Tomkiem Kaczanowskim nie używać w ogóle myszki. Po prostu ją wyłączyliśmy. Trochę touchpad w laptopie przeszkadzał (muszę w końcu poszukać, czy da się go jakoś wyłączyć) ale udało się. Trochę innych skrótów klawiaturowych używaliśmy, dzięki czemu można było się „wymienić” znanymi hotkey’ami.

Miałem również okazję popisać w C# z którego na co dzień nie korzystam. W tym języku pozytywnie zaskoczył mnie LINQu po tym, jak spory kawałek brzydkiego kodu z zagłębionymi wcięciami został jednym skrótem klawiaturowym zamieniony na 2 linijki kodu! Był on czytelny, przypominał Fluent Interface i dało się go zrozumieć. Nie wiem czy jest dostępny mechanizm odwrotny – na pewno byłby przydatny dla poczatkujących programistów i chcących poznać ten język.

Ciekawą techniką okazało się również TDD as if you meant it czyli pisanie całego kodu w teście i dopiero na końcu jego ekstrahowanie do metod i osobnych klas na zewnątrz. Ciekawe podejście, podczas którego trzeba nagiąć nasze przyzwyczajenia i pisać kod produkcyjny w metodzie testowej. Niebezpieczeństwem tej metody jest rzecz o której ktoś na sali wspominał, że testy były zielone, ale kod był dalej w testach. Więcej informacji odnośnie tej techniki: na coderetreat.orgcumulative-hypotheses.org i gojko.net.

Miałem również okazję poćwiczyć ping pong’a, gdzie piszemy test dla drugiej osoby, a ta wykonuje implementację, refaktoring i test dla nas. Moje osobiste odczucie jest takie, że staramy się wtedy „odbić” piłeczkę tak, aby drugiemu ciężko było ją „odebrać”. Prowadzi to często do tego, że jedna osoba spędza większość czasu przed klawiaturą, a druga staje się mniej aktywna. No i mogą powstawać wtedy potworki. Przykład poniżej:



Kasowałem kod po każdej z sesji, ale tego screen’a musiałem zrobić :) Co fajniejsze, w tym kodzie jest błąd. Na szczęście udało się go znaleźć, ale na refaktoryzację już zabrakło czasu.

Kolejnym pozytywnym zaskoczeniem dla mnie było to, że coraz więcej osób korzysta / chce korzystać z IntelliJ Idea. Ludzie albo mają dość Eclipse’a, który czasami zachowuje się niedeterministycznie, albo zauważają potęgę IDEI. Żeby tylko jeszcze pracodawcy chętnie w nią inwestowali...

W trakcie jednej z przerw łączyliśmy się przez Skype’a z Nowym Yorkiem i Łodzią, gdzie również odbywało się CodeRetreat. Można było chwilę pożartować i poczuć, że jest to to globalne wydarzenie i że gdzieś indziej ludzie również bawią się wspólnie kodujac. Ogółem do zabawy przyłączyło się 90 miast i około 2200 developerów.

Organizacyjne event w Krakowie był dobrze przygotowany. Mi zabrakło informacji, że tak naprawdę zaczynamy od godziny 9 a nie od 8. Zawsze to by człowiek chwilę dłużej pospał, zwłaszcza gdy się wyjeżdża o 5tej rano z Wrocławia. Niewyspanie dawało chwilami o sobie znać.

Obiad był i nie była to pizza, więc wymaganie podstawowe warsztatów zostało zachowane. Nie był to też obiad w stylu restauracyjnym, ale za to można było wziąć dokładkę. Szybko jednak zabrakło soków i w ogóle nie było herbaty (o dziwo nie wszyscy piją kawę). Początkowo panował mały organizacyjny chaos, ale po 9 godzinie szło już sprawnie. Osobiście trochę nie podobały mi się pytania na retrospektywie (w stylu ile osób robiło coś tam), gdyż to nie zachęca do opisywania swoich odczuć z danej sesji. Ogólne pytanie w stylu: „jak odczucia?” sprawdziło by się lepiej. We Wrocławiu rok temu działało.

Ogólnie całe wydarzenie wypadło bardzo pozytywnie. Widać, ze coraz szerzej techniki programowania w parach jak i TDD są znane wśród programistów. Motywuje to do dalszego działania i zgłębiania tematu.

czwartek, 1 grudnia 2011

Malowanie wykresów za pomocą JFreeChart cz. 2

Ostatnim razem we wpisie Malowanie wykresów za pomocą JFreeChart cz. 1 pokazałem jak przygotować prosty wykres za pomocą biblioteki JFreeChart. Teraz chciałbym rozszerzyć przykład, poprzez pokazanie, jak dodać do wykresu własną skalę kolorów.

Aby to zrobić musimy stworzyć klasę implementującą interfejs PaintScale. Definiuje on dwie metody: getLowerBound() i getUpperBound(). Powinny one zwracać odpowiednio dolną i górną granicę skali. Trzecią i najważniejszą metodą jest getPaint(). Zwraca ona obiekt typu Paint. Początkowo chwilę się zastanawiałem, co to za twór, co sobą reprezentuje i jak go utworzyć…

Na szczęście klasa Color z tej samej biblioteki implementuje ten interfejs. Dzięki temu możemy w naszej implementacji zwrócić odpowiedni kolor. Poniżej przykładowa implementacja.

public class ColorPaintScale implements PaintScale {
    private static final Color[] colors = {
            new Color(36, 35, 105),
            new Color(0, 6, 252),
            new Color(0, 134, 250),
            new Color(9, 251, 242),
            new Color(135, 252, 112),
            new Color(254, 241, 3),
            new Color(255, 117, 0),
            new Color(244, 0, 1),
            new Color(104, 21, 21),
    };

    private int lowerBound = 0;
    private int upperBound = 100;

    public ColorPaintScale(int lowerBound, int upperBound) {
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
    }

    public double getLowerBound() {
        return lowerBound;
    }

    public double getUpperBound() {
        return upperBound;
    }

    public Paint getPaint(double v) {
        double divisor = (upperBound - lowerBound) / colors.length;
        int index = (int) ((v - lowerBound) / divisor);
        if (index < 0) {
            return colors[0];
        }
        if (index >= colors.length) {
            return colors[colors.length - 1];
        }
        return colors[index];
    }
}

W powyższej klasie na początku definiujemy sobie kolory, jakie mają być wyświetlane na naszej skali. W liniach 14 i 15 definiujemy dolną i górną wartość naszej skali. Pola te są inicjowane w konstruktorze. Następnie mamy gettery dla tych pól (zdefiniowane w interfejsie) i metodę getPaint() do zwracania odpowiedniego koloru z dostępnej skali.

Gdy już mamy naszą klasę odpowiedzialną za skalę, przekazujemy ją do obiektu renderer’a:

PaintScale scale = new ColorPaintScale(0, 10);
XYBlockRenderer renderer = new XYBlockRenderer();
renderer.setPaintScale(scale);

Poniższy kod można zastosować w ostatnim przykładzie z poprzedniego postu. Kod i efekt poniżej:

public JPanel chartWithScale() {
    DefaultXYZDataset xyzDataset = new DefaultXYZDataset();
    double[][] series01 = new double[][]{{1}, {1}, {5}};
    double[][] series02 = new double[][]{{2, 5}, {3, 4}, {7, 9}};
    xyzDataset.addSeries("Series01", series01);
    xyzDataset.addSeries("Series02", series02);

    NumberAxis domainAxis = new NumberAxis("X Label");
    domainAxis.setRange(0, 10);

    NumberAxis valueAxis = new NumberAxis("Y Label");
    valueAxis.setRange(0, 7);

    PaintScale scale = new ColorPaintScale(0, 10);
    XYBlockRenderer renderer = new XYBlockRenderer();
    renderer.setPaintScale(scale);

    XYPlot plot = new XYPlot(xyzDataset, domainAxis, 
            valueAxis, renderer);

    JFreeChart chart = new JFreeChart("title", plot);

    return new ChartPanel(chart);
}



Ok, pola zostały pomalowane na kolorowo, ale dalej nie widzimy skali. Aby to zrobić musimy mieć utworzony już obiekt typu Chart, gdyż do niego będzie dodawać "podtytuł". Napiszmy zatem do tego osobną metodę:

private void addPaintScaleToChart(PaintScale scale, JFreeChart chart) {
    NumberAxis numberAxisPaintScale = new NumberAxis("Skala");
    numberAxisPaintScale.setTickLabelFont(new Font("Dialog", 0, 7));

    PaintScaleLegend paintScaleLegend = new PaintScaleLegend(scale, 
            numberAxisPaintScale);
    paintScaleLegend.setAxisOffset(5D);
    paintScaleLegend.setMargin(new RectangleInsets(5D, 5D, 5D, 5D));
    paintScaleLegend.setPadding(new RectangleInsets(10D, 10D, 
            10D, 10D));
    paintScaleLegend.setFrame(new BlockBorder(Color.RED));
    paintScaleLegend.setStripWidth(10D);
    paintScaleLegend.setPosition(RectangleEdge.RIGHT);
    chart.addSubtitle(paintScaleLegend);
}

I ją wywołajmy po utworzeniu obiektu chart. Efekt poniżej:



Na początku przedstawianej metody addPaintScaleToChart() tworzymy skalę i ustawiamy jej czcionkę. Jakbyśmy chcieli się pozbyć czarnych poziomych i pionowych kreseczek pomiędzy liczbami a kolorami, możemy wywołać poniższe dwie metody:

numberAxisPaintScale.setAxisLinePaint(Color.white);
numberAxisPaintScale.setTickMarkPaint(Color.white);

Następnie tworzymy legendę i ustalamy kilka właściwości. Za pomocą setAxisOffset() ustawiamy odległość pomiędzy podziałką a kolorową skalą. Poprzez setMargin() ustawiamy otoczenie naszej skali na panelu z wykresem. Nazwa argumentu sugeruje działanie podobne do Swingowych (czy też AWTowych) Insets, aczkolwiek klasy te są ze sobą nie powiązane. Za pomocą setPadding() ustawiamy odstęp we wnętrzu naszej skali, tzn. odległości kolorowej skali od brzegu legendy.

Dalej ustawiamy kolor obramowania, szerokość kolorków i pozycję względem wykresu. Na koniec dodajemy naszą legendę do wykresu za pomocą addSubtitle().

To chyba tyle w temacie biblioteki JFreeChart. Na razie nie planuję dalszej zabawy z nią, a w kolejce czekają następne tematy do ogarnięcia.

poniedziałek, 28 listopada 2011

Malowanie wykresów za pomocą JFreeChart cz. 1


Jakiś czas temu „pracując” przy małym projekciku, malowałem sobie ciekawe rysuneczki w po ekranie. Mianowicie bawiłem się biblioteka JFreeChart, która to potrafi w całkiem przystępny sposób malować wykresy w Javie.

Na początku, co bardzo się rzuca w oczy, to ciekawy sposób dystrybucji (czy też modelu biznesowego) tejże biblioteki. Jest ona w zupełności darmowa („is a free 100%”), sa Javadoc’i, jest aplikacja pokazująca możliwości biblioteki, ale chcąc poczytać The JFreeChart Developer Guide trzeba zapłacić. Bardzo ciekawe rozwiązanie, zwłaszcza, że udostępniane Javadoc’i są trochę ułomne.

Na szczęście jest kilka przykładów w Necie np. na stronie java2s.com. Po za tym ten kto jest kumaty, potrafi sobie zdekompilować udostępniane sample i zobaczyć co siedzi w środku :D Czyli dostać to samo co nam daje nam płatny developer guide.

Na początek zróbmy więc coś prostego. Załóżmy, że chcemy zrobić wykres słupkowy (ang. Bar Chart). Utwórzmy więc najpierw obiekt przechowujący nasze dane:

DefaultIntervalXYDataset dataset = new DefaultIntervalXYDataset();

Wszystkie zbiory danych (ang. dataset) są reprezentowane za pomocą klas implementujących interfejs Dataset. Interfejs ten jest bardzo ogólny i nie korzystamy z niego bezpośrednio. Chcąc stworzyć pewien wykres, musimy się dowiedzieć, jakiego typu zbioru danych on wymaga. I tak wykres słupkowy, potrzebuje IntervalXYDataset. Za pomocą tego interfejsu, klasa tworząca wykres, będzie wiedziała, jak się odwołać do danych w nim zawartych. Interfejs nie definiuje jednak sposobu dodawania tych danych do zbioru, dlatego musimy skorzystać z konkretnej implementacji przy deklaracji (po lewej stronie znaku równości) tej zmiennej.

Następnie przydało by się wprowadzić jakieś dane do zbioru:

double[][] series01 = new double[][] {{2}, {1}, {3}, {7}, {4}, {5}};
dataset.addSeries("Series 1", series01);

W pierwszej linijce tworzymy tablicę, która musi posiadać 6 wierszy, każdy o takiej samej długości, np. o długości jeden. Jeśli będziemy mieć inną liczbę wierszy otrzymamy IllegalArgumentException z jasnym komunikatem: The 'data' array must have length == 6. Wiersze oznaczają kolejno: x, start-x, end-x, y, start-y i end-y. Nasz wykres korzysta tylko z pierwszych 4rech. X oznacza wartość, dla jakiej definiujemy „wysokość” słupka. Wartość ta może być wyświetlana, gdy najedziemy myszką na ten słupek. Następnie start-x i end-x oznaczają, gdzie ma się zaczynać i kończyć słupek na osi X. Aby wykres był czytelny, wartość x powinna być pomiędzy wartościami start-x i end-x, najlepiej w połowie. Y oznacza wartość, jak wysoki ma być słupek, a start-y i end-y nie są używane, gdyż słupki z założenia na tym wykresie są prostokątne, a nie trapezowate.

Gdybyśmy chcieli wyświetlić kilka słupków dla jednej serii, to wówczas nasze wiersze w tablicy będą dłuższe, ale każdy wiersz musi zawierać dokładnie taką samą ilość liczb.

W drugiej linijce powyższego listingu dodajemy serię do naszego zbioru danych. Należy pamiętać aby użyć unikatowego identyfikatora w ramach zbioru, bo inaczej zobaczymy tylko najnowsze / nadpisane serie.

Następnie tworzymy wykres. Najłatwiej na początku skorzystać z metody fabrykującej dostarczanej przez ChartFactory:

JFreeChart chart = ChartFactory.createXYBarChart("title", "x Label", 
        false, "y Label", dataset, PlotOrientation.VERTICAL, true, 
        true, false);

Jako argumenty podajemy m.in. tytuł wykresu, podpisy osi, zbiór danych, orientację wykresu i jeszcze kilka flag. Trzeci argument mówi czy osi X ma być skalą związana z datami. My takiej nie chcemy. Trzy ostatnie argumenty definiują nam kolejno, czy chcemy legendę, podpowiedzi i adresy URL.

Na koniec trzeba jeszcze stworzyć instancję klasy ChartPanel opakowującą nasz wykres. Dzięki tej klasie możemy już wykres umieścić w JPanel’u Swingowym. Całościowy przykładowy kod i efekt poniżej:

DefaultIntervalXYDataset dataset = new DefaultIntervalXYDataset();
double[][] series01 = new double[][] {{2, 22}, {1, 21}, {3, 23}, 
        {7, 27}, {4, 24}, {5, 25}};
double[][] series02 = new double[][]{{5}, {4}, {8}, {13}, {20}, {25}};
dataset.addSeries("Series 1", series01);
dataset.addSeries("Series 2", series02);

JFreeChart chart = ChartFactory.createXYBarChart("title", "x Label", 
        false, "y Label", dataset, PlotOrientation.VERTICAL, true,
        true, false);

JPanel jPanel = new ChartPanel(chart);



Podobne demo, opisujące jak namalować wykres słupkowy możecie zobaczyć na stronie JFreeChart: XY Bar Chart Demo na http://www.java2s.com

Dobra to tyle na początek, przejdźmy do bardziej zaawansowanych zagadnień. Za zadanie miałem stworzyć dość nietypowy wykres, coś takiego:



Kolor danego „kwadracika” był jakoś tam obliczany dla danego X i Y – nie jest to przedmiotem tego wpisu. Mianowicie im wartość Z (przypisana danemu X i Y) mniejsza, tym kolor „zimniejszy”. Spróbujmy więc co podobnego namalować:

DefaultXYZDataset xyzDataset = new DefaultXYZDataset();
double[][] series01 = new double[][]{{1}, {1}, {5}};
double[][] series02 = new double[][]{{2, 5}, {3, 4}, {8, 9}};
xyzDataset.addSeries("Series01", series01);
xyzDataset.addSeries("Series02", series02);

NumberAxis domainAxis = new NumberAxis("X Label");
domainAxis.setRange(0, 10);

NumberAxis valueAxis = new NumberAxis("Y Label");
valueAxis.setRange(0, 7);

PaintScale scale = new GrayPaintScale(0, 10);
XYBlockRenderer renderer = new XYBlockRenderer();
renderer.setPaintScale(scale);

XYPlot plot = new XYPlot(xyzDataset, domainAxis, valueAxis, renderer);

JFreeChart chart = new JFreeChart("title", plot);

JPanel jPanel = new ChartPanel(chart);

Na początku tworzymy zbiór danych typu DefaultXYZDataset. Oznacza to, że nasze dane składają się z 3ch współczynników, co też widać w liniach 2 i 3. Następnie dodajemy nasze serie danych do zbioru. W kolejnych linijkach definiujemy nasze osie - jakie będą miały nazwy i zakres.

W linii 13 tworzymy obiekt typu PaintScale. Klasa ta jest odpowiedzialna za odpowiednie pokolorowanie „kwadracików” na wykresie. W przykładzie korzystam z przykładowej implementacji GrayPaintScale, która tworzy skalę szarości. Jak malować na kolorowo zostawiam jako zadanie domowe :P

Następnie definiujemy Renderer‘a a dokładniej XYBlockRenderer. Obiekt ten jest odpowiedzialny za odpowiednie wymalowanie danych na wykresie. Chcąc skorzystać ze wcześniej utworzonej skali, musimy ją przekazać za pomocą metody setPaintScale().

Następnie musimy spiąć razem zbiór danych, osie wykresu i obiekt renderujący w coś co się nazywa Plot, a w naszym przypadku XYPlot. Jest to klasa do której JFreeChart deleguje malowanie osi i danych. Mając już wspomniany XYPlot, możemy w końcu utworzyć nasz wykres (linia 19) i odpowiadający mu Panel (linia 21).

Poniżej efekt jaki możemy osiągnąć, wykonując poniższy kod:



Umiemy już namalować szare kwadraciki na wykresie, a stąd już niedaleko do żądanego efektu. Jak ktoś chce zobaczyć końcowy efekt to zapraszam do repozytorium MFCCChart na bitbucket.org

W następnym wpisie opiszę jeszcze jak namalować skalę kolorów.

niedziela, 20 listopada 2011

Problem sponsoringu konferencji


Wielu znajomych (i tych mniej znajomych) pyta mnie czasem o to, czy skoro tak licznie jeżdżę po konferencjach Javowych (w tym roku już 4 a to jeszcze nie koniec), to czy są to wyjazdy sponsorowane przez kogoś (pracodawcę / babcię), czy po prostu sam sobie je opłacam?

Otóż różnie to z tym bywa: czasem jadę z ramienia pracodawcy, a czasem za swoje (nie za mszowe) pieniądze. Uzasadniając takie postępowanie, podeprę się słowami Wujka Boba zapisanymi w książce The Clean Coder [str. 16].

“Your career is your responsibility. […]It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer.”

Nie jest zadaniem / odpowiedzialnością pracodawcy płacić za Twój rozwój! Pracodawca daje Ci pracę, kupuje twoją dostępność, twoją wiedzę i umiejętności, dając Ci w zamian co miesiąc wypłatę przelewem na konto. Pracodawca „kradnie” z Twojego życia 40 godzin tygodniowo, oczekując w zamian rezultatów: skończonego, działającego projektu, udanego wdrożenia, zadowolenia klienta…

Pracodawca chce, aby u niego pracowali tylko najlepsi, ale najlepiej nie ponosząc przy tym żadnych kosztów związanych ze szkoleniami, wyjazdami na konferencje, czy z chociażby kupnem książki. Po prostu rozwój pracowników nie jest głównym celem / zadaniem pracodawcy. Od tego są uczelnie wyższe i instytucje prowadzące szkolenia. Te pierwsze mogą być bezpłatne (zależnie od państwa), a za szkolenia trzeba już sobie płacić.

Rozumiejąc taką politykę firm, powinniśmy tym bardziej doceniać swojego pracodawcę, jeśli ten wspiera nasz rozwój. Nie możemy jednak zapominać, że to My bierzemy odpowiedzialność za nasz rozwój i że to My musimy znajdować czas w swoim życiu, aby przeznaczyć go na swój rozwój.

A ile czasu powinniśmy poświęcać na samodoskonalenie?

Wujek Bob w przytaczanym fragmencie jego książki pisze o takim podziale tygodnia:

  • 40 h pracy dla pracodawcy (według ustawy)
  • 20 h pracy dla siebie (samodoskonalenie)
  • 56 h na sen (8h dziennie) 

No i jeszcze zostaje 52 h na wszystko inne: rodzina, przyjaciele, znajomi, aktywność fizyczna, odpoczynek. Myślę, że jest to bardzo optymistyczne oszacowanie. Wiadomo, nie jesteśmy robotami i możemy czasem mieć gorszy dzień lub tydzień, kiedy nic się nie chce. Ja te „zalecane” 20 godzin traktuję, jako oszacowanie, ile mniej więcej powinienem w tygodniu robić coś pożytecznego dla siebie. Czy osiągam te 20 godzin – nie wiem, nie mierzyłem tego.

A co robić w tym czasie?

No cóż, możliwości jest sporo i można o tym napisać osobny artykuł. Uczestnictwo w konferencjach / warsztatach branżowych jak najbardziej się zalicza do tych aktywności. Konferencje są różne i różne są ich poziomy, ale zawsze można się czegoś nauczyć. Nawet jak idziemy na prezentację, która nie do końca jest związana z naszym obszarem zainteresowań, możemy się dowiedzieć, że w ogóle coś takiego jest, jak działa i jak używać. A gdy mamy poznać nową technologię, to lepiej posłuchać kogoś kto miał z tym styczność, niż samemu rozkminiać tutoriale. Sam siłę i potęgę wykładów (chociażby studenckich) doceniłem dopiero na 4tym roku studiów, jak w końcu były one w miarę konkretne i gdy ktoś sensowny je prowadził.

Inną zaletą, jakie dają nam konferencje to możliwość pogadania i poznania ludzi z tymi samymi zainteresowaniami, co za sobą niesie wymianę doświadczeń, opinii itp. Inną bardzo miłą kwestią są wszelkie towarzyszące konkursy z nagrodami. Jak się już nie raz przekonałem, w cale nie jest tak ciężko coś wygrać (myszka Logitech’a na 4developers 2010, zniżki na zakupy w Helionie na Javarsovi 2010, pendrive'y i bilety do kina na Confiturze 2011). Ostatni konkurs po Warsjawie 2011 był bardzo fajny. Do rozlosowania były 2 książki ufundowane przez firmę TouK dla osób, które napiszą relację na blogu z konferencji. No i jedna z książek (Czysty Kod) przypadła mi, co pokazuje, że prowadzenie bloga może być przydatne ;)

Tak więc jak by ktoś jeszcze w tym roku chciał porobić coś ciekawego, to 3ciego grudnia jest Global Day of Coderetreat, czyli w ponad 80 miastach na świecie odbywać się będą warsztaty CodeRetreat. W Polsce taka impreza będzie w Krakowie na którą oczywiście się wybieram.

Szykuje się jeszcze Agile Development Day w Warszawie na który jeszcze można się próbować zapisać, a także w tym samym czasie Cracow.Mobi w Krakowie. A dla mieszkańców Wrocławia powstaje właśnie: Wrocław Google Technology User Group. Pierwsze spotkanie na temat Chrome Apps odbędzie się 29 listopada 2011 o godz. 19:00.

Prawdziwa gradka szykuje się jednak w pierwszym kwartale przyszłego roku, a mianowicie 33 degree. Ja już się zarejestrowałem, mimo że nie wiem czy sam będę musiał sobie ją opłacić, czy pracodawca mi ją zasponsoruje. W każdym bądź razie proszę Was, drogi czytelniku / czytelniczko, abyście podczas rejestracji podali mój adres email mstachniuk gmail com, dzięki czemu Wy nic nie tracicie, a ja zyskam zniżkę na tę konferencję. Szczegóły promocji: 33rd Degree Buzz - get 20% off.

Do zobaczenia na konferencjach!

czwartek, 27 października 2011

Wtyczki do Eclipse’a wspomagające naukę TDD


Aby zacząć naukę TDD (Test-driven development) wiele nie trzeba. Wystarczy ulubione środowisko programistyczne IDE (Idea / NetBeans / Eclipse) i narzędzie do testowania (JUnit / TestNG / xUnit). I teraz albo czytamy mądre książki (polecam "TDD by Example" Kenta Becka) jednocześnie kodując, lub szukamy odpowiednich informacji w necie, albo szukamy kogoś doświadczonego, aby pokodzić w parach. No i można już uskuteczniać TDD. Tylko skąd wiadomo, że robimy to dobrze? Czy pamiętamy o wszystkich krokach? Może czasem zapominamy zrefaktoryzować kod? Czy rzeczywiście mamy rytm red, green, refactor?

W celu śledzenia i późniejszej oceny jak nam poszło TDD warto zainstalować w Eclipse’ie plugin Pulse. Kiedy pierwszy raz o nim usłyszałem (i tu podziękowania dla Bartka), pomyślałem sobie: po co komu plugin do TDD? Pewnie to jakaś ściema lub zbędny bajer. I rzeczywiście jest to bajer, ale całkiem użyteczny.

Plugin Pulse tworzy wykres naszej aktywności, zaznaczając kiedy nasze testy fail’owały, kiedy były zielone i kiedy robiliśmy refaktoring. Na stronie plugin’a można zobaczyć ciekawy filmik prezentacyjny możliwości.

W celu przetestowania plugin’u wziąłem się wiec za PrimeFactorsKata, gdyż tej Katy wcześniej nie robiłem. Efekt poniżej:



Początkowo napisałem testy dla jedynki i dwójki (pierwsze dwie czerwone kropki). Gdy napisałem test dla 4ki to się skapnąłem, że skoro jest to rozkład na czynniki pierwsze, to powinienem zwracać listę wartości, a nie pojedynczą wartość. Trzeba było wiec sygnaturę metody zmienić.

Następnie szły kolejne testy, czasem w miarę potrzeby jakiś refaktoring. Jako refaktoring jest rozpoznawane użycie któregoś z automatycznych mechanizmów, np. Extract Method (Alt + Shift + M), czy Rename (Alt + Shift + R). Niestety, jak robimy to ręcznie, to nie jest to wykrywane przez plugin. Ale w sumie niedziwne, gdyż wówczas każda edycja kodu by generowała niebieskie punkty na wykresie.

Gdy już nie chciało mi się już szukać (ani liczyć) kolejnych testowych wartości, które bym dodał do testów, przerwałem katę. Nie napisałem w pełni funkcjonalnej metody, gdyż pewnie dla jakiś kolejnych dużych wartości mogło by to nie działać. Ale nie o to chodzi w ćwiczeniach typu CodeKata by dojść do końca (bez skojarzeń;) ), a o poznanie jakiejś nowej techniki programistycznej, lub wyrobieniu sobie dobrych nawyków.

Wracając jeszcze z Warsjawy, co opisywałem we wpisie: Warsjawa 2011 już za nami, jechałem pociągiem i wziąłem się za BowlingGameKata. Tutaj już miałem sporo czasu na implementację. Nie było to moje pierwsze podejście do tego problemu, więc już jakoś w podświadomości było wiadomo, jak to rozwiązać. Ćwiczyłem dodatkowo tworzenie notatek, na temat tego, jakie testy trzeba jeszcze napisać i jakie są już napisane. Wykres z wtyczki Pulse poniżej:



Zacząłem równo o 16.00 i początkowo pisałem proste testy dla następujących przypadków (liczby to ilości kręgli zbitych w danym rzucie):
  • 0 - pierwszy zielony test.
  • 1- pierwszy czerwony i już po nim jakiś refaktoring.
  • 1, 3 - drugi czerwony test.
  • 1, 3, 4, 5 - któryś z zielonych testów po 16.10.
  • Pierwszy bonus: Spare – zacząłem o 16.14 i wtedy postanowiłem zrobić większy refaktoring, tj. wprowadzić design obiektowy. Skończyłem go o 16.30 i 5 minut później już mi śmigał pierwszy test dla Spare’a. Do 16.40 jeszcze coś refaktoryzowałem, co nawed plugin zarejestrował.
  • Double Spare  - zacząłem chwile po 16.40 i trochę musiałem podebugować do 16.55. Ostatecznie okazało się, że w teście źle przeliczyłem oczekiwaną wartość. 
  • Strike – o 17.03 skończyłem implementację drugiego bonusu.
  • Double Strike – skończyłem implementację o 17.33. W międzyczasie musiałem zmienić przedział w pociągu, gdyż skończył się prąd w gniazdku :P
  • Spare, Strike – skończyłem o 17.39 (miałem błąd w danych testowych)
  • Strike, Spare– skończyłem o 17.41(j.w.). Następnie chciałem napisać implementację Full Strike (czyli ciągle rzucamy 10 za pierwszym razem). Ale po tym jak test zfail’ował, dopisałem do mojej listy TODO jeszcze inne, prostsze testy dotyczące końcówki gry (ostatnia ramka) i zacząłem od nich implementację.
  • Spare w ostatniej ramce – skończyłem o 17.54.
  • Strike w ostatniej ramce – skończyłem o 18.00.
  • Double Strike w przedostatniej (i ostatniej) ramce skończyłem o 18.03.
  • Full Strike (ciągle rzucamy 10) – działał od razu po odkomentowaniu testu, gdyż wcześniejszymi testami zapewniłem odpowiednie działanie ostatniej ramki. Na koniec jeszcze usunąłem duplikacje z kodu ekstrachując odpowiednie metody.

Pierwszy raz doprowadziłem tą Katę do końca i jestem z niej zadowolony. Teraz moją implementację trzeba porównać z rozwiązaniem wujka Boba.

Kolejnym pluginem udostępnianym przez @iamhappyprog na stronie www.happyprog.com jest TDGotchi. Dzięki kolejnym wynikom testów zbieramy punkty i rozwiajamy nasze „zwierzątko”.

Podczas PrimeFactorsKata udało mi się uzbierać 5 punktów, przy bowlingu zapomniałem spojrzeć.



Przy zamknięciu i otwarciu widoku, punkty się resetują. możemy jeszcze obserwować nasze zwierzątko / ikonke jak się zmienia, gdy zminimalizujemy widok.

Ostatnim plugin’em tego samego autora jest PairHero. Wspiera on Pomodoro Technique i ping pong programing.  Za przechodzące testy i refaktoring dostajemy punkty, a za szybkie zmiany kierownik – pilot można dodatkowo pomnożyć te punkty. Fajne jeśli akurat ćwiczmy Ping Pong'a, szybkie zmiany, lub po prostu programowanie w parach.Przykładowy screenshot poniżej.



Z przedstawionych plugin’ów najbardziej polecam pierwszy, gdyż wg. Mnie niesie największą wartość i pozwala na dobrą retrospekcje jak i porównanie wykresu z innymi developerami. Pozwala również nam zauważyć, jak często wykonujemy automatyczny refaktoring, ile czasu potrzebujemy na przejście red -> green itp.

A jak wygląda Twój puls?

niedziela, 23 października 2011

Mobilization – konferencja o technologiach mobilnych - wrażenia


Ledwie tydzień temu byłem na Warsjawie, a tu już następna konferencja: Mobilization.pl, która odbyła się w sobotę w Łodzi. Była to pierwsza edycja konferencji i jeszcze sporo pozostawia do życzenia co do poziomu wykładów, ale miejmy nadzieję, że w przyszłości się to poprawi.

O 9.50 było szybkie powitanie uczestników, parę spraw organizacyjnych i rozpoczął się pierwszy wykład Bartłomieja Zassa na temat programowania Windows Phone Mango. Mimo, że nie jestem fanem rozwiązań tej firmy, byłem pod wielki wrażeniem tej prelekcji jak i prelegenta. Przede wszystkim prezentacja była bardzo dobrze przygotowana, było kodowanie na żywo (które działało), opcja zoom na ekranie, zaznaczanie kursorem elementów na ekranie, pokaz działania telefonu na rzutniku, płynne przełączanie się pomiędzy kodem a prezentacją i jeszcze parę innych fajnych drobnostek. Istny majstersztyk. Jedyne co mi się nie spodobało, to częściowe ucięcie prawej strony ekranu prezentacji (złe wyskalowanie ekranu – można było wcześniej ustawić), i mówienie „na pan/państwo”. Ja wolę luźniejszy sposób prowadzenia prezentacji i zwracanie się „na Ty/Wy”.

Na samej prezentacji najpierw było trochę historii. W 2010 była premiera Windows Phone, ale nie w Polsce (gdyż nie było tłumaczenia na nasz ojczysty język) i oficjalnie nie można było kupić u nas takiego telefonu. Jednak jesienią 2011 pojawił się Windows Phone 7.5 Mango dostępny dla Polaków. Były na prezentacji podane minimalne wymagania sprzętowe, które musi posiadać telefon, aby obsługiwać ten system. Wymagania są dość spore co może wpływać na cenę urządzeń z produktem Microsoftu. Na dniach Nokia ma wypuścić Nokię 800 która ma działać na Windows Phone 7.

Na przedstawiany system można tworzyć oprogramowanie z wykorzystaniem Silverlight 4 czy też XNA (api dla XBoxa). Mango zawiera również Internet Explorer’a 9 (niby ten sam engine co w PC’tach), czyli daje to nam wsparcie dla Html’a 5 i sprzętowej akceleracji graficznej. Bartłomiej pokazywał słynny test FishIETank  odpalany na telefonie i wyglądał dobrze.

Telefony z Windowsem Phone 7 prezentują trochę inne podejście od obecnie popularnych smartfonów. Zamiast w menu wyświetlać ikonki, które uruchamiają poszczególne aplikacje, wprowadzono koncepcję kafelków. Są to takie większe ikonki, które pokazują jakiś stan aplikacji, np. informację, czy przyszły nowe e-maile. I nasze aplikacje (o ile to obsługują) można przypiąć do pulpitu jako taki kafelek. Ciekawe podejście, choć gusta są podzielone na temat tego rozwiązania.

Inną wprowadzoną do systemu koncepcją są Hub’y, czyli integracja informacji z wielu miejsc. Przykładowo w książce telefonicznej pod konkretnym kontaktem możemy mieć zagregowane informacje o danej osobie z facebook’a, linkedin’a gmail’a i innych. Fajna funkcjonalność.

Następnie było na prezentacji już bardziej praktycznie. Prelegent pokazał kilka przykładowych aplikacji i jak można prosto i szybko tworzyć własne. Bartek stworzył na szybko aplikację o konferencji dla Windows Phone 7.5. Pokazał przy tym jak można to robić z poziomu Visual Studio jak i Expression Blend 4. Oba narzędzia dobrze się integrują i synchronizują. Pierwsze służy programistom, a drugie jest bardziej dla grafików i projektantów interfejsów graficznych, ale można w nim również sporo funkcjonalności wyklikać. Jeśli chodzi o licencjonowanie to narzędzia są bezpłatne.

Microsoft udostępnił również (podobnie jak konkurencja) miejsce gdzie można umieszczać i sprzedawać swoje aplikacje, czyli Marketplace. Studenci mogą sobie za darmo konto założyć, osoby prywatne i firmy płacą 100 $ rocznie.

Prezentację uważam za najbardziej udaną i pokazującą najwięcej ze wszystkich prezentacji w jakich uczestniczyłem w ramach tej konferencji. Wystąpienie się przedłużyło, przez co cała agenda się przesunęła o 15 minut.

Kolejną prezentacją na której byłem, było Programowanie Android 3.0 prowadzone przez Krzysztofa Janika. Prezentacja słaba, już na drugim slajdzie były jakieś błędy. Prelegent chciał zrobić małe demo pokazywane z tableta (bo tam działa Android 3.0), ale miał jakieś problemy z kablem. Próbował jeszcze włączyć live streaming (cała konferencja była stream’owana na giwebcast.pl) na rzutniku, by pokazać tablet do kamery. Niestety nie udało się załadować streamingu na komputerze prelegenata :( Dodatkowo Krzysiek często patrzył na slajdy i zadawał dużo pytań publiczności, które nie wnosiły nic do tematu. Bardzo słabe wystąpienie.

Jedyne co wyniosłem z prelekcji to obecność w Androidzie 3.0 czegoś co nazywamy Fragments. Są to jakby miniActivity, które możemy dynamicznie osadzać w innych Activity.

Kolejne wystąpienie było Konrada Hołowińskiego na temat Multiplatform mobile apps. Konrad przedstawił dwa rozwiązania pozwalające pisać raz i uruchamiać aplikację na różnych urządzeniach mobilnych.

Pierwszym omawianym rozwiązaniem było Appcelerator Titanium. Aplikację tworzymy za pomocą JavaScript’u wykorzystując dodatkowo natywne komponenty dla konkretnych platform. Titanium dorzuca później do kodu własny interpreter JS, co zwiększa wielkość aplikacji. Jeśli dobrze zrozumiałem, to od pewnego czasu produkt ten używa statycznej analizy i kompilacji kodu, generując kod natywny dla danej maszyny. Zdecydowano się na taki krok ze względów wydajnościowych, ale przez to pojawiały się przez jakiś czas wycieki pamięci.

Titanium wspiera Androida, iOSa i BlackBery (nie w pełni). Dzięki  kompilacji do natywnego kodu, aplikacje przyjmują wygląd platformy na której są uruchamiane. Pojawiają się przez to często różnice w wyglądzie na innych urządzeniach, co zostało pokazane podczas prezentacji na emulatorach iPhone’a i Androida. Mamy również dostępne darmowe jak i płatne plugin’y rozszerzające możliwości dostarczane przez Titanium.

Następnie było o konkurencyjnym rozwiązaniu PhoneGap, które wspiera więcej (bo aż 6) platform. Tutaj piszemy w HTMLu 5, JavaScript’cie i CSS3. Produkt jest typu open-source i wszelkie plugin’y są rozwijane przez społeczność.

PhoneGap jest uruchamiany w natywnym silniku JS danego urządzenia. Daje on jednak też dostęp do większości funkcjonalności dostępnych w smartfonach, za pomocą „zmostkowania” ich do JS. Podejście to ma swoje wady jak i zalety. Wadą jest brak wsparcia dla wielowątkowości i wolniejsze działanie od aplikacji tworzonych w Titanium, lub natywnie. Za to naszą aplikację możemy uruchomić w przeglądarce i podejrzeć cos się dzieje np. za pomocą FireBug’a.

Z ciekawostek, to PhoneGap zostało ostatnio przejęte przez firmę Adobe, które się stara zaistnieć na rynku urządzeń mobilnych. Zobaczymy co z tego wyjdzie.

Na konferencji miałem okazję poznać Tomka Dziurko. Po prezentacji Konrada poszliśmy na obiad i po nim chcieliśmy pójść na Advanced layouts on the Android battlefield. Jacka Niedzwieckiego, ale chwilkę się spóźniliśmy, a sala była wypchana po brzegi. Alternatywny wykład o Windows 7 nas nie interesował, więc se posiedzieliśmy w holu konferencji.

Następnie miał być wykład o Androidzie i SmartTV, ale prelegent nie przyjechał. W jego miejsce wrzucono Testowanie w Systemie Android Marka Defecińskiego. Marek był jednym z organizatorów konferencji i prowadzi Blog Progamisty Android. Marek jest niespełnionym fanem testów. Swoją opowieść zaczynał od J2ME, w której sam miałem przyjemność się sprawdzić. I rzeczywiście potwierdzam, że o testowaniu w J2ME nie ma co mówić.

Później już było o Androidzie i testowaniu funkcjonalnym za pomocą robotium. Projekt się reklamuje jako Selenium ale dla Androida i działa na emulatorze Androida. Prelegent nie był jednak do końca zadowolony z tego rozwiązania.

Innym ciekawym, omawianym projektem był Robolectric. Jest to framework do testów, który za pomocą Javassist podmienia to co siedzi w android.jar. Dzięki temu możemy nasze testy odpalać na komputerze, działa refaktoryzacja i jest to szybkie.

Było jeszcze wspomniane o android-mock i paru innych frameworkach do testowania. Niestety Marek nie pokazał żadnych przykładów, zrzucając winę na aktualizacje maven’a. Brakuje mu jeszcze oswojenia z publiką i rozluźnienia podczas prowadzenia prezentacji. Na problem suchego gardła polecam wodę z cytryną przed i w trakcie prezentacji (powoduje wydzielanie śliny) jak i unikania słodyczy oraz nadmiernego picia wody (wysusza gardło). Ponadto bujanie się na boki jest trochę denerwujące / rozpraszające dla słuchaczy. Niestety pewność na tego typu wystąpieniach można wyćwiczyć jedynie występując.

Następne prelekcje były dla mnie mniej interesujące. Spotkałem na konferencji Pawła Zubkiewicza, którego znam dzięki WrocJUG. Jako, że Paweł jest z Wrocławia, postanowiłem się zabrać z Nim i innymi pracownikami QNH do domu, gdyż powrót autobusem o 21.35 z Łodzi jakoś mi się nie uśmiechał.

W drodze powrotnej nie mogło się obejść bez niespodzianek, mianowicie klocki hamulcowe się starły i musieliśmy się zatrzymać. Na całe szczęście wylądowaliśmy w miejscowości Szadek, a nie gdzieś w lesie. Dobrą pizze tam mają i gdyby nie ta awaria nigdy bym się tam nie pojawił. Pomoc drogowa zawiozła nas z powrotem do Łodzi i tam już czekał na nas samochód zastępczy, którym dojechaliśmy do Wrocławia.

Podsumowując, jak na pierwszą edycję konferencji, organizacja wypadła dobrze. Były dostępne przekąski w postaci kanapek i jogurtów (świetny pomysł) jak i kawa / herbata. Jedna sala była trochę mała, przez co nie chciałem się dociskać na jeden wykład. Na krzesełkach konferencyjnych były fajne podkładki przyczepiane do krzesła rzemykiem, na których się wygodnie notowało. Trzeba jedynie poziom prezentacji podnieść i będzie cacy.

wtorek, 18 października 2011

Warsjawa 2011 już za nami


W minioną sobotę (15.10.2011) odbyła się Warsjawa 2011. Konferencja ta jest organizowana przez te same osoby co Confitura z tym że ma ona charakter warsztatowy. Ja postanowiłem wziąć udział w ścieżce dotyczącej GWT gdyż ostatnio trochę pokodziłem w tej technologii i chciałem uzupełnić / usystematyzować swoja wiedzę. Ale od początku.

Konferencja rozpoczęła się chwile po 9.00 słowem wstępnym organizatorów. Chwile później poszliśmy już do sal gdzie miały być warsztaty. Sala była trochę mniejsza niż przewidziane 60 uczestników, więc było ciasnawo, ale przyjemnie. No i ilość podłączonych komputerów do sieci elektrycznej musiała się skończyć wysadzeniem korków. Trzeba było kilka przedłużaczy spiąć ze sobą i ukraść prąd z korytarza, aby muc w ogóle rzutnik prowadzącemu  uruchomić. Wysadzenie korków jest rzeczą, której można się spodziewać, ale zbytnio nie ma się jak przed tym zabezpieczyć. No chyba że ktoś ma generator prądotwórczy pod ręką i mógłby udostępnić :P

Warsztaty rozpoczęły się więc o 9.45. Po krótkim wprowadzeniu utworzyliśmy przykładową aplikację i zaczęliśmy zabawę. Niestety prowadzący założył, że będzie Wi-Fi i że będzie działać. Niestety było to błędne założenie, co trochę rozwalało pracę. Przykład ten pokazuje, że przygotowanie prezentacji / warsztatu nie jest sprawą trywialną i że należy się zabezpieczyć na ewentualność braku dostępu do Internetu i wszelkie inne problemy. Całe szczęście pojawiłem się chwilę przed konferencją i zdążyłem jeszcze uruchomić skrypty konfigurujące środowisko, dzięki czemu mogłem wykonywać początkowe ćwiczenia. Poniżej przedstawiam garść interesujących informacji o GWT, które wyniosłem z warsztatu.

Moduł GWT dzieli się na client server i shared. Widać to w nazwach pakietów w naszym module. Klasy umieszczone w pakiecie shared są współdzielone przez client i server. To co jest umieszczone w client i shared jest tłumaczone na JavaScript, więc nie może zawierać / używać tego co nie jest przetłumaczalne na JS. Inaczej dostaniemy błędy kompilacji typu: No source code is available for type <nazwa_klasy> did you forget to inherit a required module?. Trzeba wtedy sprawdzić, czy wskazywana klasa jest osiągalna w client lub shared.

W GWT jest coś takiego ciekawego jak SafeHTML. Chroni on przed atakami Cross-Site-Scripting (XSS). Było tylko o tym wspomniane i z pewnością trzeba kiedyś temat zgłębić.

Inna ciekawostką są klasy rozszerzające SelectionScriptLinker. Definiują one, w jaki sposób ma być generowany kod JS przez kompilator. I tak IFrameLinker generuje kod GWT ładowany w osobne znaczniki <IFRAME>. Inna klasa SingleScriptLinker generuje pojedynczego JavaScript’a, a CrossSiteIframeLinker umożliwia ładowanie skryptów z różnych lokalizacji. To ostatnie przydaje się, gdy deploy’ujemy aplikację na wielu serwerach.

Chcąc skorzystać z wybranego Linker’a musimy dodać odpowiedni wpis w pliku konfiguracyjny modułu (*.gwt.xml). I tak Chcąc skorzystać z CrossSiteIframeLinker dopisujemy:

<add-linker name="xs"/>

Dla SingleScriptLinker jest to:

<add-linker name="sso"/>

Wszystkie linkier’y należą do modułu core w GWT. Chcąc sprawdzić co jest domyślnie włączone i co jeszcze można włączyć, należy poczytać zawartość pliku Core.gwt.xml.

Na warsztacie dowiedziałem się w końcu jak z Developer Mode skorzystać. Wcześniej o nim coś słyszałem ale nie wiedziałem dokładnie jak działa. Najlepiej przygotować sobie projekt z poziomu Eclipse’a: File -> New -> Web Application Project. Dzięki temu mamy możliwość skorzystania z plugin’a GWT do Eclipse’a.



Wybierając opcję GWT Compile Project wtyczka kompiluje aplikację i tworzy konfigurację uruchomieniową dla Eclipse’a. Możemy również sobie wybrać ile kompilator na wypisywać na konsole podczas kompilacji, oraz jak ma wyglądać JS po kompilacji (Pretty, Obfuscated, Detailed)



O dziwo zaimportowanie projektu, utworzonego przez skrypt webAppCreator dostarczany wraz z GWT, nie pozwala nam korzystać z tego dodatku. Po udanej kompilacji możemy uruchamiać naszą aplikację w Development mode.



Wybieramy przeglądarkę i już można się nacieszyć nasza aplikacją. Zaletą jest to, że nie musimy za każdym razem rekompilować całej naszej aplikacji, tylko wciskamy F5 w przeglądarce. Pewnie są jakieś ograniczenia na to, co się automatycznie odświeża a co nie - kwestia dowiedzenia się.

Ciekawą funkcjonalnością jest możliwość logowania na konsolę po stronie klienta. Służy do tego moduł Logging. Aby go uaktywnić, należy w pliku konfiguracyjnym modułu dodać następujący wpis:

<inherits name="com.google.gwt.logging.Logging"/>

Ważne jest aby umieścić go przed naszym Entry Point’em!!! Ja umieściłem za i się męczyłem kilka godzin czemu nie działa.

I już możemy logować:

logger.info("onModuleLoad()");
logger.log(Level.WARNING, "warning");
logger.log(Level.INFO, "info");

Trzeba pamiętać, aby dołączyć standardową bibliotekę javową: java.util.logging.Logger. Efekt widać na konsoli w Eclipse:

Sun Oct 16 19:20:33 CEST 2011 LogowanieEntryPoint
INFO: onModuleLoad()
Sun Oct 16 19:20:33 CEST 2011 LogowanieEntryPoint
WARNING: warning
Sun Oct 16 19:20:33 CEST 2011 LogowanieEntryPoint
INFO: info

Jak i w przeglądarce:



Inną ważna rzeczą jest przyspieszanie kompilacji projektu. Niestety kompilacja do JS trwa długo i dodatkowo jest generowany kod na 6 przeglądarek. Warto dla celów development’u ograniczyć kompilację do jednej przeglądarki. I tak aby generować kod dla Firefox’a należy w pliku konfiguracyjnym moduł dodać następująca linijkę:

<set-property name="user.agent" value="gecko1_8"/>

Warto wiedzieć, że wpisy te są zdefiniowane w UserAgent.gwt.xml.

Tyle mniej więcej było do przerwy obiadowej. Około 13.45 zaczęły przychodzić pierwsze Pizze. Było ich sporo i co jakiś czas dochodziły nowe. Można było się spokojnie najeść, bo pod koniec przerwy widziałem jeszcze niedojedzone kawałki. Jako że przed przerwą budowanie aplikacji nie chciało mi działać, uniemożliwiało mi to aktywne uczestnictwo w warsztatach. Postanowiłem więc (nie ja jeden) przenieść się na ścieżkę wykładową.

Najpierw Koziołek mówił na temat tego jak jeszcze można wykorzystać biblioteki testowe. Otóż ułatwiają one nam budowanie walidatorów danych (np. otrzymanych od klienta). Tutaj Bartek pokazywał jak skorzystać z TestNG.

Inna ciekawostka to zastosowanie Mockito w kodzie produkcyjnym. Da się i jest to przydatne, gdy wiemy, że jakaś funkcjonalność dojdzie w niedalekiej przyszłości, ale jeszcze nie wiemy co to de facto będzie. W tym momencie możemy sobie zbudować interfejs taki, jak będzie nam potrzebny i go zmockować, aby zwracał nam domyślne wartości. Jak już będzie wiadomo co / jak należy to poprawnie zaimplementować, to wyrzucając mocka podpinamy konkretną implementację. Ciekawe rozwiązanie, choć dla niektórych może to być zbyt kontrowersyjne.

Na koniec było jeszcze o DbUnit. Dzięki tej bibliotece możemy zasilać naszą bazę nowymi danymi, np. wraz z kolejnymi release’ami naszej aplikacji. Nie musimy w tym momencie utrzymywać skryptów SQLowych (co jest kosztowne i trudne), a przygotowanie danych można zrzucić na klienta dając mu do ręki Excela.

W ogólności zaletą zastosowania opisywanych bibliotek jest minimalizacja ilości naszego kodu, bo więcej naszego kodu = więcej błędów. Opisywane biblioteki są przetestowane przez duże grono użytkowników, a gdy nasz kod jest mniejszy to łatwiej znaleźć w nim ewentualny błąd. Dodatkowo wykorzystanie TestNG powoduje powstawanie programów samotestujących się.

Na koniec został wykład Jacka Laskowskiego. Jacek opowiadał o TomEE czyli starym Tomcat’ie rozszerzonym o kilka bibliotek (CDI – OpenWebBeans, EJB – OpenEJB, JavaMail, OpenJPA, JSF – MyFaces, JTA - Geronimo Transaction) i certyfikat serwera aplikacji. Czyli mamy nowe narzędzie, które obsługujemy jak stare, a daje nam kilka dodatkowych możliwości. Wcześniej mogliśmy dołączyć dodatkowe moduły ręcznie.

Po omówieniu teoretycznym, Jacek pokazał kilka sztuczek z NetBeans’em i TomEE i jak można szybko wystartować z nowym narzędziem. Niby żaden przełom, ale myślę, że nowy Tomcat pomoże zacząć nowicjuszom współpracę z nim. Sporą cześć tego co była na wykładzie można przeczytać na blogu Jacka, a pewnie jeszcze jakieś uzupełnienia się pojawią. Samo prowadzenie prezentacji jak zwykle na dobrym poziomie.

Na koniec były jeszcze podziękowania dla sponsorów / organizatorów i losowanie nagród. Jak zwykle zostało wylosowane sporo osób, które już poszły do domu. Chyba warto w końcu napisać prostą maszynę losującą, gdyż podobny problem z nagrodami pojawia się na innych konferencjach.

Podsumowując organizacyjnie po za wifi i prądem nie było się do czego czepiać. Pizzy było wystarczająco, napojów troszkę mniej, a i tak super że były. Szkoda trochę, że warsztat z GWT trochę nie wyszedł (problemy z netem i skryptem budującym), ale na szczęście można było alternatywnie pójść na wykłady. No cóż trzeba będzie samemu bardziej usiąść do tej technologii i się pobawić.

niedziela, 25 września 2011

Połączenie Androida z lokalnym servletem


Ostatnio miałem za zadanie skomunikować Androida z własnoręcznie napisanym serwletem. Przykładów w necie można znaleźć pełno, jak się prosto połączyć z Internetem i ściągnąć dowolny dokument czy grafikę. Jest to prosta rzecz o ile pamiętamy o kilku sprawach.

Po pierwsze to należy zmodyfikować nieco plik AndroidMainfest.xml dodając następujący wpis:

<uses-permission android:name="android.permission.INTERNET"/>

Teraz już kod odpowiedzialny za połączone z Internetem powinien już działać. Nie będę go prezentował, bez problemów znajdziecie. Ja tymczasem chciałem się połączyć z własnym Serwletem (osadzonym na Tomcat’cie), uruchomionym na tym samym komputerze co emulator telefonu. No i tutaj zaczęły się schody.

Pierwszy pomysł jaki przychodzi do głowy, to magiczny adres IP: 127.0.0.1. Niestety dla emulatora i telefonu oznacza to tą samą maszynę, czyli emulator / telefon. Po krótkim namyśle skorzystałem z adresu IP mojego komputera. Działa, ale nie byłem z tego zadowolony, gdyż w tym momencie stawało się to nietestowalne, w przypadku uruchomienia na innej maszynie.

Próbowałem również skorzystać z adresu IP routera, który dzieli mi Internet w mieszkaniu. Niby już się tam cos łączył, ale timeout leciał. Prawdopodobnie coś źle skonfigurowałem. Szukając po komunikatach wyjątków, w końcu natrafiłem na super rozwiązanie (niestety piszą ten post nie mogę odnaleźć źródła), na które w życiu bym sam nie wpadł.

Chcąc się połączyć z emulatora Androida na komputer na którym obecnie jest ten emulator uruchomiony, należy skorzystać z IP: 10.0.2.2. Dzięki temu łatwiej odpalić aplikację na innym komputerze. Zastosowanie tego adresu, powoduje że po stronie serwera, będziemy widzieć nasze żądania jako pochodzące z 127.0.0.1. Natomiast żądania wysyłane na adres IP naszego serwera, będą miały źródło takie samo, na którym stoi serwer.

Życzę więc miłego kodowania i bezproblemowych połączeń między emulatorem a testowym serwisem. Mi dojście do tego zjadło sporo czasu.

środa, 15 czerwca 2011

Confitura pełna wiedzy – wrażenia po konferencji

W sobotę 11 czerwca odbyła się w Warszawie największa darmowa konferencja javowa w Polsce: Confitura, zwana wcześniej Javarsovią. Na początku wielkie podziękowania dla organizatorów, wolontariuszy i sponsorów, za chęć organizacji i wsparcia tejże inicjatywy. Ale od początku.

Do Warszawy przybyłem w piątek wieczorem, aby być wypoczętym na konferencji. W sobotę byłem na miejscu o 8.30, szybka rejestracja, obchód po stanowiskach sponsorskich, spotkanie znajomych…

O 9.15 członkowie kapituły oficjalnie rozpoczęli Javarsovie Confiturę. Pierwszy wykładzik był sponsorski na temat KeyNote. Prowadzący mówił bardzo cicho i monotonnym głosem, no ale płaci to niech ma :P Był to dobry czas na rozwiązanie konkursów, przygotowanych przez sponsorów. Pod koniec już wyszedłem i chciałem się napić czegoś. Niestety obsługa cateringowa stała, ale napoje czekały dopiero na przerwę kawową co mnie się niezbyt spodobało.

W tym roku zestaw uczestnika był troszkę uboższy niż rok wcześniej. Zamiast materiałowej i ekologicznej torby (używam do dziś) była papierowa i brakowało mi notesika (na szczęście się przed tym zabezpieczyłem). Nie ma jednak na co narzekać, gdyż konferencja jest w pełni bezpłatna i nie można wymagać nie wiadomo jakich gadżetów. Nie to jest najważniejsze, gdyż nie po gratisy przyjechałem.

O 10.35 zaczęły się pierwsze wykłady. Ja się udałem na Aspekt bezpieczeństwa w tworzeniu aplikacji internetowych Jakuba Koperwasa. Prelegent zaprezentował popularne ataki na aplikacje webowe (jak SQL Injection) jak i mniej popularne (jak CSRF). Wspomniał on również o inicjatywie OSWAP, dzięki której można się pobawić w hakowanie.

Było też o sposobach, jak można się bronić przed różnymi atakami. Przede wszystkim należy nie przestawać myśleć i nie ufać ślepo framework’om. Powinniśmy walidować dane, a nie formularz, gdyż dane do naszej aplikacji mogą spływać różnymi drogami – nie tylko poprzez żądanie http, ale także z innych serwisów, aplikacji, z telefonów... W celu walidacji danych może nam pomóc BeanValidation JSR-303, za pomocą którego można zdefiniować, jakie ograniczenia powinny mieć nasze dane.

Warto również znać różnice pomiędzy używanymi framework’ami i bibliotekami, Przykładowo GWT traktuje tekst jako zwykły tekst, natomiast ExtGWT, jako html. Dzięki temu tworząc przycisk z tekstem <b> text </b> w tym pierwszym dokładnie taki napis zobaczymy na ekranie, a w przypadku ExtGWT dostaniemy przycisk z pogrubionym tekstem.

Kolejnym rodzajem omawianego ataku była kradzież sesji. Można się przed tym bronić, dodając do każdej akcji jednorazowy RequestId, który jest później unieważniany. Można z palca to naklepać, lub jeśli korzystamy z Seam’a, wykorzystać znacznik <s:token>. Można również monitorować czy na pewno uprawniony użytkownik korzysta z danego klucza sesji. Można dodatkowo monitorować MAC i IP, a także używaną przeglądarkę. O ile IP może się czasem zmienić (zależy jakiego mamy dostawcę Internetu), to już zmiana przeglądarki może być podejrzana. Wszystko również zależy od krytyczności naszej aplikacji. Jak by się trzeba było co kilka minut logować na facebook’a, to by ludzie przestali się z niego korzystać. Również warto przesyłać ciasteczka po https. Prelegent na koniec polecał przeczytanie 12 rules for developing more secure Java Code.

Prelegent opowiadał jeszcze o kilku ciekawych rzeczach. Przekazał w ten sposób sporo wiedzy słuchaczom. Może trochę mi brakowało przykładów, ale przy takim czasie prezentacji ciężko je zaprezentować. No i nie było czasu na dogłębne analizowanie omawianych problemów. Prelegent mówił szybko, ale zrozumiale i nie dało się spać. Wykład mi się podobał.

Później była przerwa kawowa. Następnie chciałem iść na Tomasza Skutnika i prezentację: Gdzie jest moja tabela? Czyli jak sobie radzić w Javie i SQL gdy zmienia się schemat bazy danych. Kolega Szymon mnie jednak odwiódł od tego zamiaru i wylądowaliśmy na prezentacji Patrycji Węgrzynowicz, pt. Patterns and Anti-Patterns in Hibernate. Patrycja już kilka krotnie występowała z tą prezentacją na innych konferencjach, w tym na 33deegre i GeeCon’ie. Nawet slajdy zawierały na końcu informacje o pierwszej z wymienionych konferencji.

Prelegentka wzięła na warsztat przykładowa aplikację CaveatEmptor z książki Java Persistence with Hibernate – biblii do Hibernate’a napisanej przez jej twórców. Pokazując kawałek kodu, Patrycja pytała publiczność, czy wiedzą, gdzie jest błąd. Znalazł się ktoś z sali, kto dobrze trafił, co się nie zdarzało na poprzednich wystąpieniach. Jak się okazało, nawet twórcy Hibernate’a mogą się czasem pomylić w pracy ze swoim narzędziem. Z ciekawszych rzeczy, co zapamiętałem, to użycie metody Collections.unmodifableList(), która zwraca jedynie wrappera na oryginalną kolekcję. I w zależności od implementacji getterów i setterów, możemy sobie coś zepsuć. Wykład całkiem, całkiem, tylko te częste eeee… i yyyyyy… Patrycji powodowały, że już się go tak przyjemnie nie słuchało.

Kolejnym wykładem na jaki się udałem, to Jak wycisnąć maksimum z testów? Bartka Majsaka. Było trochę o testach integracyjnych i akceptacyjnych. Prelegent wspominał o takich rozwiązaniach jak Tumbler (wspomaga pisanie w stylu BDD) Cargo (wspomaga konfiguracją i deploy'em w różnych kontenerach) i Arquillian (do testowania kodu osadzonego w kontenerze). Praktyczny przykład z tym ostatnim nie zadziałał, prawdopodobnie z powodu problemów z netem.

Dalej było o Selenium / WebDriver. Bartek testował za jego pomocą funkcjonalność na github'ie. Mianowicie po wciśnięciu T, można wyszukiwać pliki z danego projektu. Istnieje również możliwość eksportu z Selenium do JUnit’a 4, ale to się i tak nie kompiluje i w ogóle nie działa. Można to jednak poprawić (tudzież ręcznie napisać) i wtedy można uruchamiać testy bezpośrednio z ulubionego IDE.

Było jeszcze trochę o BDD i jak można ładnie DSL’e w Groovy’m wykorzystać. Warto również w trakcie build'ów z maszyn wirtualnych korzystać, jeśli musimy przeprowadzać testy w zróżnicowanych środowiskach uruchomieniowych. Prelegent próbował jeszcze coś tam pokazać, za znów nie zadziałało z winy sieci. Spodobała mi się idea nagrywania screencast'ów z testów akceptacyjnych, które to później można wykorzystać, do zbudowania prezentacji pokazującej funkcjonalność produktu.

Następnie był obiad. Tym razem trzeba było sobie za niego zapłacić (nie było tak fajnie jak rok temu) a i tak jakiś wypaśny nie był: zupka, sałatka, kanapka i jabłko. Później był wykład sponsorski, czyli jak zwykle…

Następnie udałem się na Re-fuck-toryzacja czyli sprowadzanie sp****go kodu na właściwe tory Pawła Lipińskiego. Chciał on swoim wystąpieniem udowodnić, że jeszcze potrafi programować… W trakcie prezentacji było krótkie ogłoszenie od organizatorów, że właśnie odholowują źle zaparkowane samochody. Ktoś wybiegł z sali...

Paweł wziął pod lupę open source’owy projekt e-commerce OFBiz Pokazywał w jaki sposób przeprowadzać bezpieczne refaktoryzacje. Da się, nawet bez posiadania testów. Nie odpalał jednak na końcu aplikacji, więc nie wiadomo czy wyszło:P

Trochę czasu zabrakło na pokazanie wszystkiego, a im dalej, tym ciężej było śledzić co się dzieje w kodzie. Na koniec był jeszcze zabawna piosenka o refaktoryzacji przygotowana przez autora.

Kolejną prezentacją, na której byłem, było Zastosowanie przetwarzania asynchronicznego w aplikacjach Tomka Łabuza. Testował on obciążenie aplikacji i pokazywał, jak się ona zachowuje przy przetwarzaniu synchronicznym jaki i asynchronicznym. Prelegent mówił również, kiedy warto zastosować takie rozwiązanie w naszej aplikacji.

Następnie była przerwa kawowa i losowanie nagród od sponsorów. Ja wygrałem otwieracz do piwa z funkcją pendrive’a i 2 bilety do kina. Tak więc można powiedzieć, że losowanie nie było ustawione, ale i tak wolałbym Xbox’a :P

Ostatnią prezentacją w której miałem możliwość uczestnictwa było: Pisz po pijaku, przeglądaj na trzeźwo Piotra Przybylaka. Tu również były nagrody dla aktywnych uczestników, tylko że w postaci piwa lub gorzkiej żołądkowej. W końcu tytuł prezentacji zobowiązuje :)

Prezentacja była o sposobie, w jaki działa nasz mózg i czy da się to jakoś wykorzystać. Można się przełączać pomiędzy rożnymi trybami jego pracy, np. za pomocą alkoholu, spaceru, pisaniu czegoś na kartce zaraz po przebudzeniu… Chcąc wykorzystać dwa tryby pracy mózgu, można stosować pair programing, gdyż wtedy kierowca skupia się na pisaniu linijek kodu, a pilot o tym nie myśli, ale ma za to obraz całości.

Dobre może być również odwrócenie problemu. Chcesz się nauczyć pisać dobry kod? Napisz jak najbardziej brzydki, zagmatwany i niezrozumiały kod. Prelegent wspominał jeszcze o modelu kompetencji braci Dreyfus, Shu Ha Ri, kryzysie pielęgniarek w stanach i o powstawaniu nowych neuronów w mózgu. Podobno szczurom w warunkach laboratoryjnych nowe neurony się nie rodzą (no bo i po co?), ale kto wie jak to w rzeczywistości jest...

Generalnie na wykładzie było sporo śmiechu i sporo braw. Było lekko i przyjemnie. Idealny wykład na końcówkę konferencji. Brawo.

Później było tylko zakończenie konferencji. Podziękowania dla organizatorów, wolontariuszy i sponsorów. Było jeszcze losowanie przygotowanych nagród, ale już na nic się nie załapałem. Liczba osób, które potwierdziły rejestracje to 742, ale wiadomo – ktoś jeszcze nie dojechał, ktoś jeszcze doszedł, wiec trochę ciężko przybliżyć rzeczywistą liczbę uczestników.

Po confiturze udałem się jeszcze pod PKiN na piwko z Szymonem. Ja jeszcze zostałem na niedziele w Warszawie. Wracając pociągiem rozwiązywałem jeszcze jedno zadanie konkursowe firmy OutBox. Musze przyznać, ze bardzo ciekawy konkurs (tzn. treść tego co trzeba zrobić, a właściwie gdzie ją znaleźć). We wtorek było ogłoszenie wyników, ale niestety nic nie wygrałem.

Podsumowując konferencję, to wypadła ona trochę słabiej od zeszłorocznej edycji. Wydaje mi się, że wcześniej wykłady były na trochę wyższym poziomie (albo to ja się czegoś w ciągu roku nauczyłem). Było ciężko się przemieszczać pomiędzy salami (co nie jest dziwne przy tej liczbie uczestników), co skutkowało spóźnieniami na prelekcje. Przerwy mogły by być trochę dłuższe, a napoje dostępne non stop. Więcej niedociągnięć się nie dopatrzyłem i za rok będę starał się znów wziąć udział w tej konferencji.

wtorek, 7 czerwca 2011

Zmiana nazwy pakietu w projekcie Android'owym w IDEA

W jednym z ostatnich wpisów: Inne podejście do przechowywania danych w systemie Android, z wykorzystaniem db4o i NetBeans 6.9 wspominałem o użyciu IntelliJ IDEA w celu sprawdzenia jak sobie radzi z aplikacjami android’owymi. I rzeczywiście wsparcie jest lepsze. Póki co to natrafiłem tylko na dziwne zachowanie jeśli chodzi o zmianę nazwy pakietu. Mianowicie po wybraniu pakietu i Refactor -> Rename (Shift + F6) wyskakuje mi poniższy monit:



Z początku trochę mnie zdziwił komunikat. Patrząc tylko na przedostatnią linię, nie rozumiałem intencji. Przecież pakiet jest utożsamiany z katalogiem, więc o co chodzi? Bliższe wczytanie się w komunikat, już wyjaśnia co się dzieje. Otóż IDEA umieszcza pliki automatycznie generowane (takie jak klasa R) w osobnym katalogu (/gen). Niezależnie od wybranej opcji (po za Cancel oczywiście) zmieniana jest nazwa katalogu zawierającego nasze pliki źródłowe. Przy wyborze Rename package, dodatkowo zostanie zmieniona nazwa podkatalogu /gen, gdzie są generowane automatycznie pliki projektu (np. klasa R).

Teraz przy próbie uruchomienia (Shift + F10) aplikacji wyskakuje okienko do edycji konfiguracji.



Możemy w tym momencie olać ten ekran i samemu poprawić ścieżki do naszych aktywności w pliku AndroidManifest.xml. Całe szczęście, że IDEA podświetla na czerwono błędne klasy, umieszczone w plikach XML-owych. O takiej funkcjonalności w NetBeans’ie można tylko pomarzyć.

Kilkakrotne próby powtórzenia tej czynności, uświadomiły mi, że środowisko nie zawsze tak samo wszystko modyfikuje. Raz musiałem w jakimś pliku konfiguracyjnym coś grzebać, a ostatnio nawet udało się odpalić od razu aplikację. Czyżby to było adaptacyjne środowisko programistyczne? Jeśli tak to jestem pod wrażeniem.