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ć.
