Opis prezentacji

Transakcje w systemach budowanych w technologii JEE
Jarosław Błąd (e-Point)

W ramach wykładu będą przedstawione następujące zagadnienia:
- Transakcje i ich właściwości
- Zagadnienia związane ze współbieżnym wykonywaniem transakcji
- Transakcje rozproszone i dwufazowy protokół zatwierdzania transakcji
- Obsługa transakcji w środowisku serwera aplikacyjnego JEE
- Aplikacja
- Zasoby transakcyjne
- Menedżer transakcji
- Transakcje lokalne i globalne
- Strategie zarządzania transakcjami w aplikacjach JEE
- Transakcje a dostęp do baz danych (JDBC)
- Transakcje a systemy kolejkowania (JMS)
- Transakcje w komponentach EJB
- Transakcje w usługach sieciowych
- Problemy związane z budową transakcyjnych aplikacji w technologii JEE

Spring TestContext Framework - testowanie integracyjne aplikacji opartych na Spring Framework
Jakub Milkiewicz

Spring TestContext Framework jest jednym z najmniej rozpoznawanych modułów wchodzącym w skład Spring Framework 2.5. Umożliwia w bardzo prosty i wydajny sposób testowanie integracyjne systemu, w szególności warstwy DAO opartej na JDBC lub ORM. Bez uruchamiania serwera przetestujemy pełne CRUD, zapytania, konfigurację mapowań i wiele więcej.

SpringTestContext Framework jest łatwo rozszerzalny i umożliwia integrację z innymi narzędziami.

Co jeszcze mogą nam dać adnotacje - weryfikacja statyczna.
Adam Warski

Adnotacje spotyka się dzisiaj prawie wszędzie - czasami jest ich w klasie nawet więcej niż "kodu właściwego". W prezentacji pokażę, w jaki sposób można ich liczbę jeszcze trochę zwiększyć.

Głównym tematem będzie weryfikacja statyczna wspomagana adnotacjami, czyli sposoby sprawdzania dodatkowych właściwości naszego kodu tak, aby potencjalne błędy wykryć już na etapie kompilacji. Brzmi może trochę skomplikowanie, ale samo użycie takich adnotacji i potem sprawdzenie poprawności jest bardzo proste, dzięki istniejącym narzędziom.

W pierwszej części pokażę adnotacje wspierane przez znane narzędzie - FindBugs. Nie ma ich wiele, ale mogą one wykryć i zapobiec wielu codziennie spotykanym błędom. Będzie też demo pokazujące, jak napisać własny detektor rozszerzający FindBugsa.

Druga część prezentacji poświęcona będzie "Typestate Annotations", czyli specyfikacji która rozszerza liczbę miejsc, które można anotować, o typy. Będzie to część Javy7, ale korzystać z nowych możliwości możemy już dzisiaj. Samo takie rozszerzenie nie jest na pierwszy rzut oka bardzo przydatne, ale do dyspozycji dostajemy również "Checkers Framework", dzięki któremu w prosty sposób możemy napisać "weryfikator" dla własnych adnotacji. Aby to udowodnić, podczas prezentacji pokażę jak taki prosty checker napisać. Przedstawię też już istniejące checkery i adnotacje przez nie wspierane.

Warsztaty TDD - sesja randori
Krzysztof Jelski

Test Driven Development przez wielu oceniany jest jako bardzo skuteczny sposób tworzenia oprogramowania. Nauka TDD i zastosowanie tej techniki w codziennej pracy programistycznej często okazuje się trudne. Uczestnicząc w warsztatach masz szansę dowiedzieć się więcej o TDD, poćwiczyć rozwiązując przykładowy problem, jak również poznać ciekawy sposób wspólnej nauki, który możesz zastosować w swoim środowisku.

Podczas sesji randori dwoje uczestników pracuje w parze nad rozwiązaniem zadanego problemu na komputerze podłączonym do projektora (oznacza to, że ćwiczymy również praktykę programowania w parach - pair programming). Pozostali śledzą powstający kod. Co 7 minut osoba z widowni zastępuje jedną z osób przy komputerze. Dążymy do napisanie eleganckiego, przejrzystego rozwiązania, cały czas stosując TDD.

Od uczestników oczekiwana jest dobra znajomość javy. Swoboda w posługiwaniu się Eclipse IDE może być pomocna. Znajomość TDD nie jest konieczna, choć udział osób znających tę praktykę może być bardzo cenny dla pozostałych uczestników.

Ciągła Integracja w procesie wytwarzania oprogramowania
Kuba Kubryński

Obecnie coraz większą wagę przykłada się do jakości oprogramowania. Nawet działy biznesowe zaczynają zauważać problemy, wynikające z niedoskonałości funkcjonującego procesu wytwarzania oprogramowania. Tu z pomocą przychodzą nam środowiska Continuous Integration. Wdrożenie podejścia Ciągłej Integracji w istniejący w organizacji cykl wytwarzania, wymaga poza znajomością zagadnień teoretycznych, obycia z zestawem narzędzi umożliwiającym optymalne wykorzystanie jego zalet.

Prelekcja obejmie wprowadzenie teoretyczne i pojęciowe, przykłady wykorzystania w realnych sytuacjach, a także prezentację środowiska umomżliwiającego sprawne wytwarzanie oprogramowania w Javie (i nie tylko) oparte na układzie:

• Hudson - centrum zarządzania buildami aplikacji
• Sonar - platforma kontroli jakości oprogramowania
• Maven2 - narzędzie automatyzacji buildów i zarządzania zależnościami
• Artifactory - repozytorium artefaktów Maven2.

Wirtualizacja wirtualnej maszyny Java - czyli jak uruchamiać aplikacje Java bez systemu operacyjnego
Waldek Kot

Dosyć powszechnie uważa się, że największą zaletą technologii Java jest JVM - Java Virtual Machine. Dzięki JVM programy tworzone w językach Java, Scala, Groovy, Ruby czy wielu innych, są nie tylko przenośne między różnymi środowiskami, ale także działają bezpiecznie, są zarządzalne, a do tego jeszcze wydajne. Widać to szczególnie w serwerowych zastosowaniach JVM. Od pewnego czasu upowszechnia się i znajduje coraz nowe zastosowania technologia wirtualizacji sprzętu, w której za pomocą hypervisora możliwe jest udostępnienie w ramach pojedynczego fizycznego komputera, wielu komputerów logicznych (wirtualnych maszyn). W tutaj przyjętej definicji wirtualizacji - hypervisor to specjalizowane oprogramowanie, "zastępujące" system operacyjny fizycznej maszyny. Jest to stosunkowo cienka warstwa zajmująca się zarządzaniem zasobami fizycznego komputera i koordynowaniem dostępu do nich przez maszyny wirtualne, tak, aby oprogramowanie działające w ramach wirtualnego komputera "myślało", że działa w ramach prawdziwego (=fizycznego) sprzętu. Hypervisor pozwala na równoczesne działanie w ramach fizycznej maszyny wielu maszyn wirtualnych (dzisiaj, z racji powszechności wydajnych wieloprocesorowych/wielordzeniowych serwerów, często w ramach jednej fizycznej maszyny działają dziesiątki i setki maszyn wirtualnych). Zarówno z wewnątrz (czyli dla oprogramowania działającego w ramach maszyny wirtualnej - np. systemu operacyjnego, czy aplikacji, w tym JVM, serwerów aplikacyjnych, czy aplikacji Java EE), jak i z zewnątrz (czyli dla użytkowników) taki wirtualny komputer niczym się nie różni od fizycznego (od wewnątrz udostępnia 'wirtualne wersje' BIOS, CPU, RAM czy urządzeń takich jak karta sieciowa, czy dyski; z zewnątrz jest dostępny poprzez sieć, itd). Zaletą takiej wirtualizacji jest znacznie większa elastyczność - udostępnienie nowego komputera trwa bardzo krótko. W dodatku takie maszyny można bardzo łatwo klonować, zapewniając niemal ich identyczną konfigurację (nie tylko identyczny sprzęt, ale także choćby identyczne ustawienia security, czy identyczny zestaw aplikacji/usług mających działać w takim komputerze). Wirtualny komputer istnieje w zasadzie w postaci zbioru danych, np. pliku. Takie podejście otwiera także ciekawe (mimo, iż dostępne już od dosyć dawna) możliwości, jak np. możliwość migracji wirtualnych komputerów pomiędzy różnymi fizycznymi komputerami (w migracji "na żywo", tj. bez przerwy w pracy oprogramowania działającego wewnątrz maszyny wirtualnej i w sposób niezauważalny dla użytkowników tego oprogramowania). Niemal nieustannie odkrywane są coraz to nowe zastosowania wirtualizacji - choćby związane z podniesieniem poziomu bezpieczeństwa i niezawodności systemów, a nawet przyjazności dla środowiska naturalnego (w ramach "green computing"). Wirtualizacja leży u podstaw takich innowacji jak cloud computing. Wirtualizacja nie pozostaje bez wpływu na technologię JVM. W dążeniu do coraz większej efektywności i elastyczności aplikacji Java (szczególnie serwerowych), wirtualizacja "poprzez hypervisor" może odegrać tu istotną rolę. Hypervisor znacznie ułatwia budowę specjalizowanych (=dedykowanych) "systemów operacyjnych", dzięki którym JVM może działać bardziej optymalnie. Maszyna wirtualna Javy bowiem, szczególnie w zastosowaniach serwerowych, niemal nie potrzebuje systemu operacyjnego (niektórzy twierdzą, że jest to maksymalnie 0.5% kodu OS, głównie związanego z niskopoziomowym zarządzaniem pamięcią i wątkami, I/O w zakresie sieci i storage'u oraz narzędziami do monitorowania i administracji - resztę zadań i tak implementuje JVM - a w środowisku zwirtualizowanym także hypervisor). Co więcej, klasyczny system operacyjny nie rozumie tego co dzieje się wewnątrz JVM i dosyć nagminnie przeszkadza JVM w efektywnym wykonywaniu aplikacji (tzw. efekt podwójnej - a w środowisku wirtualnym - nawet potrójnej wirtualizacji). Wiele zadań jest wykonywanych nadmiarowo, w nieskoordynowany sposób przez JVM, hypervisor i OS. Może zatem warto pozbyć się takiego "rozdmuchanego" systemu operacyjnego, skoro JVM i tak go w zasadzie nie używa ? Tym właśnie jest wirtualizacja JVM - możliwość uruchamiania JVM bezpośrednio w ramach wirtualnych maszyn udostępnianych przez hypervisor, bez systemu operacyjnego. A dokładniej: zamiast zwykłego OS, JVM działa na specjalizowanej, bardzo cienkiej (rzędu 1-2 MB) warstwie pełniącej rolę systemu operacyjnego, która udostępnia JVM tylko te usługi, których ta rzeczywiście od OS potrzebuje. Korzyści z oddania sporej ilości zasobów (pamięć, CPU) zajmowanych (marnotrawionych ?) wcześniej przez OS i lepszej koordynacji zadań widać szczególnie wtedy, gdy w ramach jednej fizycznej maszyny działa wiele (dziesiątki/setki) maszyn wirtualnych. W takiej kombinacji pojawia się możliwość praktycznej realizacji wielu dodatkowych optymalizacji w wykonywaniu kodu Java. Niektóre z tych optymalizacji udostępnia technologia JRockit Virtual Edition - maszyny wirtualnej Java (JRockit JVM) działającej bez systemu operacyjnego w środowisku opartego o Xen hypervisora Oracle VM.

Podczas tej sesji chciałbym zaprezentować wybrane aspekty technologii wirtualizacji, szczególnie w kontekście jej wpływu na Java i JVM. Będzie sporo praktycznych demonstracji z wykorzystaniem aktualnych wersji JRockit VE, WebLogic Server VE i Oracle VM (zapraszam także tych, którzy chcą zobaczyć zwirtualizowane aplikacje napisane w Ruby i Groovy ;-)). W pewnym zakresie sesja będzie podobna do tej, którą mogli zobaczyć uczestnicy konferencji GeeCon 2009 w Krakowie. Postaram się jednak pokazać także nowe rzeczy.

Najbardziej liczę jednak na to, że ta innowacja w świecie Java pt. wirtualizacja wirtualnej maszyny Java przede wszystkim zaciekawi społeczność Java (a pewnie i nie obędzie się bez kontrowersji i emocji, których przykłady mogli zaobserwować uważni czytelnicy grupy dyskusyjnej pl.comp.lang.java). A niektórych może nawet zachęci do dalszych poszukiwań usprawnień w JVM.

Serdecznie zapraszam !

Testy wspaniałe zdobywają Warszawę

Szczepan Faber
Po mojej sesji Warszawa będzie inna. Programiści zaczną pisać testy, które inni programiści będą rozumieć od razu. Debugger stanie się ekscentrycznym urządzeniem, o którym większość programistów zapomni. Rzadziej będziemy słyszeć: „nie napisaliśmy testów, bo one zawsze utrudniają refaktoring i dodawanie nowych funkcjonalności”. Częściej będziemy słyszeć: „pewnie, że mamy testy”.

Szczepan, czy ty czasem nie opowiadałeś o wspaniałych testach na ostatnim GeeCON’ie? Owszem, ale tamta sesja to był tylko wstęp do tematu. Kraków nie był jeszcze gotowy, żeby poznać wyższe voodoo wspaniałych testów (no i bilet na prezentację dostałem od organizatorów 2 dni wcześniej...).

Co będzie na sesji? Slajdy, java na slajdach, kodowanie na żywo (jeśli mój jedyny słuszny OS pozwoli), nieco dogmatycznej ewangelizacji i dużo wzorców do wykorzystania w codziennym kodowaniu.

Warsztaty 'coding by example'

Bartosz Bańkowski, Igor Czechowski, Szczepan Faber

W skrócie: nie pisz testów, pisz przykłady. Wierzymy, że 'poprawne' TDD to nie testowanie kodu, tylko dokumentowanie zachowań obiektów i pokazywanie tych zachowań na przykładach.

Jeżeli jeszcze nie stosujesz TDD, zapraszamy na warsztat - spróbujemy nauczyć Cię 'poprawnego' TDD. Jeżeli już stosujesz TDD, zapraszamy na warsztat - spróbujemy podszkolić twój styl TDD, a twoja wiedza bardzo się przyda w dyskusjach i w pomocy innym uczestnikom. 

Zamiast 'coding by example', moglibyśmy nazwać warsztaty: 'BDD, czyli jak połączyć TDD z DDD', ale mamy już dość trzyliterowych skrótów.

Warsztat trwa 3 godziny. Jeżeli trafisz w połowie sesji, nie powinieneś mieć problemu z dogonieniem reszty grupy, ponieważ dołączymy Cię do odpowiedniej pary. Prawie zapomniałem: podczas warsztatu programujemy w parach, więc albo swój laptop (zalecane), albo poszukamy dla Ciebie pary z laptopem.

Google Web Toolkit i Seam, czyli piękny wygląd z bogatym wnętrzem

Celem wystąpienia jest prezentacja najnowszych możliwości Google Web Toolkit - narzędzia do tworzenia bogatych interfejsów webowych przy użyciu języka Java - oraz wskazanie zalet i problemów występujących przy integracji oprogramowania wykorzystującego GWT z biblioteką Seam. Zarówno GWT, rozwijane przez Google, jak i Seam, mające wsparcie JBoss, są projektami open source o solidnych podstawach i szerokim wsparciu środowiska. Mając na celu przyspieszenie i ułatwienie tworzenia aplikacji webowych i enterprise, stanowią świetne uzupełnienie, którego warto być świadomym rozpatrując technologie odpowiednie do realizacji projektów informatycznych.

W czasie prezentacji dokonane zostanie porównanie Google Web Toolkit z alternatywnymi rozwiązaniami, omówiona zostanie specyfika tego narzędzia, jego wady i zalety, istniejące aplikacje wykorzystujące GWT oraz perspektywy na przyszłość. W drugiej części wystąpienia biblioteka Seam zaprezentowana zostanie jako dopełnienie GWT dla warstw aplikacji realizowanych po stronie serwera. Zaproponowane zostanie tym samym kompletne rozwiązanie, potencjalnie przewyższające w łatwości i szybkości realizacji projektu inne możliwości, najczęściej stosowane.

Ewolucja Architektury

Paweł Lipiński
Architektura oprogramowania to ten jego składnik, co do którego
decyzje podejmowane są zwykle na samym początku projektu. Na czym
bardziej zaawansowanym etapie jest projekt, tym bardziej ryzykowne i
kosztowne są jej zmiany. Czasem jednak takie zmiany są niezbędne.
Czasem architektura ma oczywiste błędy. Czasem wymagania co do
funkcjonowania systemu zmieniają się do tego stopnia, że oryginalna
jego architektura nie może im sprostać. Paweł omówi sposoby radzenia
sobie w takich sytuacjach. Opisze jak kwestie ewolucji architektury
podejmowane są  w projektach prowadzonych przy pomocy zwinnych
metodyk. Wskaże sposoby tworzenia aplikacji w taki sposób by jak
najmniej wiązać logikę aplikacji z jej architekturą, tak by umożliwić,
a czasem nawet promować jej ewolucję.