After quite successful beginning of this year we had another office party – it helps us not to forget where we work Simply a statement from our marketing materials which says “Members of Espeo are its greatest value” it’s totally true! And what was this time? A mysterious place in deep woods with classical tenpin bowling facilities – it was truly something! None of us was experienced in it – so it was seriously challenging for every member of our crew. How astonishing emotions were there, you couldn’t simply imagine.
Leading was changing every single minute, every point counted, every move was… a crap   There were some moves worth seeing, but basically – we were poor. Especially… me,  to be honest. At first it wasn’t going so badly – but as the time passed by, so did our “talent”. Nonetheless there were winners – however I wasn’t among them.

We really enjoyed it. And we enjoy what’s going on around us. A temperature is rising, a sun is less and less timidly showing behind the clouds and our company is growing thanks to proper watering. After the raining times there is a rainbow on the sky. Now let’s find the rainbow treasure!

Czym jest Agile dla programisty? Co zmienia zastosowanie zwinnego podejścia w porównaniu z klasycznym waterfall?

Klasyka

Mam za sobą kilka większych lub mniejszych projektów realizowanych klasycznie. Obserwowałem pracę programistów z różnych perspektyw. Ciekawa jest tu obserwacja jak zmienia się nastawienie pojedynczych ludzi, jak i całych zespołów do realizacji projektu. Człowiek potrafi zaadaptować się niezwykle szybko do środowiska w jakim przebywa…

W klasycznym podejściu rola programisty ogranicza się w zasadzie do ‘klepania kodu’. Powszechnie przy tym narzeka się na analityków, projektantów, a także testerów. Często nie dostrzega się klienta, czy nawet celów projektu, poza należną premią oczywiście

Jak wygląda (w uproszczeniu oczywiście) klasyczny warterfall

Miejsce programisty jest w zasadzie tylko przy etapie ‘kodowanie’. Jego rolą jest naklepanie treści do tego co wymyślił projektant… i przekazanie następnie do testera – z nadzieją aby ten nie wykrył tych drobnych obejść, które często wynikały z nieścisłego gdzieniegdzie projektu. W końcu po co zawracać sobie tym głowę – projektant widocznie tak chciał to ma.

Do takiej roli bardzo dobrze przygotowują wszelkie uczelnie. Po prostu trzeba doskonale znać narzędzia i język w którym się koduje. Działamy jak algorytm – na wejściu analiza, na wyjście dajemy działający kod. Nie ma znaczenia co gdzieś daleko za nami chciał klient, ani czego oczekuje po wdrożeniu. Jesteśmy tylko połączeniem projektanta z testerem.

Czasami rzeczywistość zaskakuje nas jak drogowców zimą Faza analizy się przedłuża i nie ma czasu na projekt Wówczas implementujemy często wynik analizy bez projektu… Jeśli przedłużyła się analiza – znaczy, że dziedzina jest trudna, pewnie implementacja też się przedłuży, więc może faza testów też jest niepotrzebna? Najważniejsze jest przecież wdrożenie… Tego chce klient (a może nie?).

W takich projektach Project Manager ma niełatwe zadanie. Ślęczy nocami nad znienawidzonym M$ Projectem, aby zgrać wszystkie etapy. Każdy próbuje zwalić winę na innego… To już temat na zupełnie osobny artykuł…
Programista podejmuje decyzje jedynie na temat tego czy użyć pętli while czy może lepiej for. Całą resztę zrzuca na projektanta lub PMa.

Agile

Jak wygląda zwinny proces rozwoju oprogramowania z punktu widzenia programisty?

Uproszczony schemat Agile

Tutaj idziemy przez całość zagadnień małymi kroczkami. Za każdym razem wykonujemy analizę, projekt implementację i integrację z całością. Za każdym razem dostajemy informację zwrotną od klienta czy to co zrobiliśmy to jest to czego oczekuje. Klient dostaje gotowe fragmenty, które może używać. Sam decyduje które fragmenty chce najszybciej.
A co robi teraz programista? Otóż niestety ma sporo więcej pracy. Przejmuje po części role analityka, projektanta, testera i wdrożeniowca… Niestety ma więcej pracy i odpowiedzialności. Ale myślę że praca ta jest dużo ciekawsza i posiada dużo większe możliwości rozwoju.

Niestety jednak, tutaj napotykamy problem. Większość absolwentów kierunków informatycznych nie jest dobrze przygotowana do przejęcia tych wszystkich ról. Nie wystarczy więc powiedzieć – od dziś pracujemy w agile. Trzeba nieustannie podnosić kwalifikacje pracowników.

Poszczególne fazy, z racji tego że nie są one w pełni formalnie osadzone, różnią się też sporo od tych znanych z podejścia klasycznego. Nie powstaje zwykle jakiś spójny dokument zwany analizą, czy projektem, który jest normalnie akceptowany i odbierany przez klienta. Za to klient akceptuje gotowa działające kawałki. Wydaje się, że ma to głębszy sens – za abstrakcyjnym dokumentem projektu nie widać zwykle gotowego systemu.

Uczelnie wypuszczają całą masę programistów. To samo w sobie nie jest złe, są oni zwykle doskonali w programowaniu… Jednak spotyka się takich którzy nie słyszeli nigdy akronimu SOLID. Podczas studiów wykonuje się niezliczone ‘projekty’ programistyczne. Niewiele z nich jednak przechodzi przez fazy analizy, projektowania, czy nawet testowania! A te umiejętności wśród programistów są niezbędne aby swobodnie realizować zwinny projekt.

Jest to jedna z trudności (i wyzwań) dla zwinnych zespołów – w klasycznym podejściu każdy ma swoją działkę w której nabywa umiejętności; w agile każdy jest specjalistą od wszystkiego Postaram się dalej pokazać, że to nie taki diabeł straszny jak go malują.

]]> http://blog.espeo.pl/2010/02/12/zwinny-projekt-okiem-programisty/feed/ 0 http://blog.espeo.pl/2010/01/25/its-freezing-outside-but-development-in-progress-as-usual/ http://blog.espeo.pl/2010/01/25/its-freezing-outside-but-development-in-progress-as-usual/#comments Mon, 25 Jan 2010 16:13:27 +0000 TomaszRakowski http://blog.espeo.pl/?p=203 Winter is in its peak nowadays! It’s so cold, that minus five degrees (Celsius) feels
like hot, minus fifteen is typical and when it’s minus twenty five – we can say “it’s
getting a bit colder” A temperature exceeding minus thirty degrees is even happening
- what a weather, for God’s sake we’re not in a deep Russia, are we?!

Although our cars are seriously wounded by this critical conditions and getting to the
office on time is becoming a challenge – development process stays unimpressed and
evolves as was meant to. Simply astonishing way of dealing with complex IT projects -
despite the world is so unfriendly outside, in house it all works like a Swiss watch.
Public transport is struggling with major drawbacks, roads are black no more and are
becoming a one, huge ice rink, selected schools are going to be closed, flight are being
canceled one after another – but developers from Espeo are doing their job as usual.

What can I say – guys still make a huge impression on me, even when I’m no longer the
“new one”. As a sales person all I can do is to stay aside, admire their achievement and
make sure there will be always some challenging projects in a queue.

Vaadin to framework przeznaczony do budowy graficznego interfejsu użytkownika dla aplikacji internetowych tworzonych z wykorzystaniem języka Java. Całe rozwiązanie oparte jest o Google Web Toolkit (GWT). Paleta gotowych komponentów jest dość szeroka, można w niej znaleźć m.in. kontrolki do obsługi kalendarza, tabel, do budowy menu itp. jeśli jednak okazało by się to niewystarczające można utworzyć własny komponent.

Na stronie projektu dostępny jest plugin dla środowiska Eclipse. Opisany w dalszej części przykład został wykonany właśnie z wykorzystaniem tego pluginu.

Konfiguracja

Struktura projektu wykorzystującego framework Vaadin nie różni się praktycznie niczym od zwykłej aplikacji internetowej wykonywanej za pomocą Javy, nie ma żadnych zbędnych plików i katalogów, które niekiedy potrafi wprowadzić sporo zamieszania.

W pliku web.xml zdefiniowany został m.in. serwlet obsługujący żądania, jego parametr inicjujący zawiera identyfikator klasy, na podstawie której zostanie wygenerowany pierwszy widok (zaraz po uruchomieniu aplikacji). Sama klasa serwletu jest częścią frameworka Vaadin. Domyślnie włączony jest tryb debagowania.

<context-param>
  <description>Vaadin production mode</description>
  <param-name>productionMode</param-name>
  <param-value>false</param-value>
</context-param>

<servlet>
  <servlet-name>Simplevaadinexample Application</servlet-name>
  <servlet-class>
    com.vaadin.terminal.gwt.server.ApplicationServlet
  </servlet-class>
  <init-param>
    <description>Vaadin application class to start</description>
    <param-name>application</param-name>
    <param-value>pl.espeo.example.MainWindow</param-value>
  </init-param>
</servlet>

Przykładowa aplikacja

Każda aplikacja wykorzystująca framework Vaadin musi posiadać klasę, która dziedziczy po klasie Application i implementuje metodę init(). W tworzonej aplikacji tą rolę pełni klasa VaadinApp, dodatkowo został wykorzystany interfejs ClickListener do obsługi zdarzeń obiektu Button.

public class VaadinApp extends Application implements ClickListener {

 private Window mainWindow;
 private Window subWindow;
 private Button closeButton;
 private Label label;

 @Override
 public void init() {
 mainWindow = new Window("Main window");
 createSubWindow();
 mainWindow.addWindow(subWindow);
 setMainWindow(mainWindow);        
 }

//...
}

W metodzie init() stworzone zostało główne okno programu stanowiące kontener dla pozostałych elementów graficznego interfejsu użytkownika.

 private void createSubWindow() {
   VerticalLayout layout = new VerticalLayout();
   layout.setSpacing(true);
   layout.setMargin(true);    

   label = new Label("Window content");
   closeButton = new Button("Close");
   closeButton.addListener(this);

   layout.addComponent(closeButton);

   subWindow = new Window("Window");
   subWindow.addComponent(layout);
   subWindow.center();
   subWindow.setClosable(false);
 }

 @Override
 public void buttonClick(ClickEvent event) {
   mainWindow.removeWindow(subWindow);
 }

Metoda buttonClick pochodzi z interfejsu ClickListener, jej wywołanie powoduje usunięcie okna z okna głównego aplikacji.

Podsumowanie

Vaadin framework stanowi ciekawą alternatywę dla tworzenia tradycyjnego tworzenia widoków – za pomocą jsp, html css itd. W końcu cała aplikacja może być napisana w Javie.

Sposób implementacji poszczególnych elementów jest bardzo podobny do Swinga co moim zdaniem należy uznać za duży plus. Wydaje mi się, że Vaadin świetnie sprawdziłby się w mały i średnich projektach.

I look at my mates in the office and I see they know that it is 2010 now. However they don’t seem to bother – it looks like they have a new energy to work, to have a fresh start in a new year.  Good for them! Having a spare time is something, we can’t afford nowadays – and it could be even harder, as some new challenges are right ahead. And you know what? I can read from our developers’ faces that they were expecting it! Even more – they were waiting for it, as new challenges are like an air to breath for them, like a petrol for a racecar – “too much” is not in their vocabulary.

What can I say – let the 2010 begin!

It all started during our office Christmas party. We were divided into two groups, with different goals to achieve. What surprised me the most, was that making two groups was the difficult part – as everyone wanted to be with everyone   After two teams were made – all following steps were processed as they were planned to, without a scratch, and all were delivered on time. The level of understanding and an easiness of acting as a team was astonishing.

The next day I was even more mystified when I discovered, that during typical business activities concerning software development, all was lead in the same way as it was still a Christmas party – with a great understanding, effective cooperation, perfect communication and in awesome moods.  In this moment it became obvious to me – it is the way how software should be developed. Ever.

Speed Tracer jest dodatkiem do przeglądarki Google Chrome, który umożliwia analizę wydajnościową aplikacji webowych (nie tylko tych tworzonych w GWT). Speed Tracer pozwala na bardzo dokładne przyjrzenie się działającej aplikacji, wliczając w to np. obserwację zdarzeń JavaScript’owych. Zamiast wymieniać następne funkcjonalności narzędzia Speed Tracer, lepiej obejrzeć krótki (1:40) tutorial, gdzie wszystko jest bardzo ładnie pokazane. Warto zwrócić uwagę na naprawdę rewelacyjny interfejs aplikacji (zrobiony oczywiście w GWT ).

Myślą przewodnią nowej wersji GWT są szybsze aplikacje webowe. Szybsze zarówno w sensie szybkości ich działania, jak i szybkości developmentu. Lista zmian i nowości jest naprawdę duża. Zwrócę więc uwagę tylko na te najważniejsze (moim zdaniem).

Wersja 2.0 zdecydowanie poprawia cykl edycja/odświeżenie przez wprowadzenie tzw. development mode, który pozwala uruchomić w trybie debug projekt GWT w dowolnej przeglądarce, a nie jednej, dedykowanej (jak to było wcześniej). Oznacza to, że nareszcie można używać Firefoksa albo Chrome’a przy tworzeniu aplikacji GWT, a wraz z nimi -- pakietu ulubionych rozszerzeń na czele z Firebugiem . Nie obeszło się przy tej okazji bez zmiany Google Plugin for Eclipse, którym teraz można całkowicie kontrolować development mode z poziomu naszego ulubionego IDE . Jeszcze trochę z ciekawostek: development mode działa przez sieć. Można więc “przypiąć się” do zdalnej sesji przeglądarki. Wydaje się to szczególnie przydatne dla Linuksiarzy, którzy mogą tylko zgadywać jak wygląda ich aplikacji w IE pod Windows. (Nawet z GWT pewnych rzeczy się nie przeskoczy…)

Kolejna wielka zmiana, która dla mnie osobiście wydaje się być szalenie interesująca, to wprowadzenie nowego, deklaratywnego sposobu konstruowania interfejsu użytkownika o nazwie UiBinder. Założenie jest takie, by uczynić łatwą (a przy okazji trochę wymusić) separację warstwy widoku od logiki aplikacji. Pomysł polega na tworzeniu dwóch plików dla każdego komponentu warstwy prezentacji. Aspekty widoku zawarte są w pliku .ui.xml, który stanowi “mieszankę” normalnego HTML’a oraz komponentów widoku (ang. widgets). Sama implementacja logiki aplikacji pozostaje natomiast w osobnym pliku .java. Pozwala to na bardzo wyraźną separację tych dwóch zagadnień i np. bardziej efektywną współpracę programistów oraz web designerów. Dodatkowo, w czasie kompilacji sprawdzane są wszystkie referencje między powyższymi plikami, więc nie ma mowy o żadnych literówkach i tego typu błędach. Naturalnie, Google Plugin for Eclipse wspiera to rozwiązanie w 100%, wliczając refactoring, uzupełnianie kodu itd.

Najnowszy Google Web Toolkit wprowadza również tzw. layout panels, pozwalające na dokładne rozmieszczenie elementów w obrębie strony. Nie ma co ukrywać, że używając HTML i CSS jest to duży problem, który najczęściej wymusza użycie pewnych “sztuczek”. Nawet we wcześniejszych wersjach GWT czasami trzeba było pokombinować, żeby coś wyglądało tak jak trzeba we wszystkich przeglądarkach. Nowe rozwiązanie bazuje tylko na standardzie CSS, co ma dać layout nie tylko bardziej stabilny i przewidywalny, ale również szybszy (znane są dość spore problemy wydajnościowe przy zmianie rozmiaru okna przeglądarki we wcześniejszych wersjach GWT). Layout panels, jak łatwo się domyślić, doskonale sprawdzają się w połączeniu z UiBinder.

Kluczową nową funkcjonalnością w GWT 2.0 jest programowe rozdzielanie kodu (ang. code splitting). Polega to na wskazaniu (w kodzie źródłowym), które komponenty muszą być wczytane “z góry” i są konieczne do załadowania aplikacji, a które można doczytać chwilę później. To tak trochę jak oglądanie filmu na YouTube: nie trzeba przecież wczytać całości, żeby rozpocząć oglądanie. Moim zdaniem to świetne rozwiązanie. Mamy do czynienia przecież z aplikacjami webowymi; tutaj nie może być poczucia, że coś jest “instalowane”. Taką aplikację otwieramy i już ma być; każąc użytkownikowi czekać 15 sekund na pojawienie się pierwszego ekranu, możemy go łatwo stracić. Świetne wyniki tutaj uzyskał zespół Google Wave. W chwili obecnej skompilowana, pełna funkcjonalność tej aplikacji to “ważący” prawie 1500 kB JavaScript, który trzeba przecież ściągnąć od razu. Dzięki zastosowaniu rozdzielania kodu, początkowo użytkownik ma do pobrania 200 kB (a po kompresji już tylko 80 kB), a reszta jest “dociągana” w czasie, gdy zastanawia się gdzie by tu kliknąć. Różnica właściwie o rząd wielkości! Częściowo zasługa w tym również nowej wersji kompilatora, który tak czy inaczej “odchudza” kod nawet o ponad 20%. Można bez problemu skompilować starsze aplikacje. W moim ostatnim projekcie w GWT dało to oszczędność 14% (właśnie sprawdziłem ) tak po prostu, bez dotykania kodu źródłowego.

Z mniejszych zmian, nastąpiło ulepszenie mechanizmu paczek (ang. bundles). Teraz zamykać w paczki można nie tylko grafiki, ale pliki dowolnego rodzaju. Jest również specjalny rodzaj paczki dla plików CSS, który automatycznie optymalizuje dołączone arkusze stylów.

Podsumowując, GWT 2.0 wydaje się być znaczną aktualizacją tego produktu. Poprawiono zarówno efektywność pracy z technologią (co w konsekwencji zmniejsza koszt tworzenia oprogramowania), jak i wydajność samych aplikacji. Google Web Toolkit niewątpliwie potwierdza swoją mocną pozycję na rynku nowoczesnych technologii front-end’owych dla aplikacji webowych. Dla mnie osobiście, jest to już od dawna faworyt w tej kategorii, który coraz bardziej rośnie w siłę. Gorąco zachęcam do pobrania nowej wersji biblioteki i przyjrzenia się wprowadzonym zmianom. Zainteresowanych kieruję na stronę produktu.

Google GIN (GWT INjection) to stosunkowo młody projekt Google, wprowadzający do Google Web Toolkit możliwość wstrzykiwania zależności (ang. dependency injection). Oparty jest na Google Guice (o którym pisałem kilka tygodni temu) i zapewnia pewien podzbiór funkcjonalności tej biblioteki.  Po co więc GIN? Potrzeba wynika wprost ze specyfiki aplikacji tworzonych w GWT, która uniemożliwia zastosowanie “typowego” frameworka do wstrzykiwania zależności. Rozwinę ten temat za chwilę.

Póki co, nie ma możliwości pobrania skompilowanej biblioteki ze strony projektu (tak jak pisałem, jest to jeszcze wczesna faza rozwoju), więc pozostaje check out z publicznego repozytorium i własnoręczna kompilacja:

svn checkout http://google-gin.googlecode.com/svn/trunk/ google-gin-read-only
cd google-gin-read-only
ant dist

Zbudowanego JARa (./out/dist/gin.jar) oczywiście należy dołączyć do swojego projektu.

Zaczynamy!

Mamy już dostępne klasy GIN, więc można zaczynać. W regularnym Guice, po skonfigurowaniu zależności w klasie modułu i utworzeniu Injectora, obiekty pobiera się mniej więcej tak:

RegistrationService registrationService = injector.getInstance(RegistrationService.class);

W GWT jednak powyższy kod nie zadziała. Żeby być ścisłym: nie zadziała w komponentach po stronie klienta (ang. client-side). Jak wiadomo, aplikacja GWT dzieli się na stronę klienta i stronę serwera. Po stronie serwera nie ma żadnego problemu ze wstrzykiwaniem zależności. Obiekty są instancjonowane w rzeczywistym JRE (najczęściej w kontenerze serwletów) i żyją “normalnym” Javowym życiem. Można używać Guice, Spring albo dowolnego innego rozwiązania do wstrzykiwania zależności i będzie działać. Po stronie klienta wygląda to jednak zupełnie inaczej, ponieważ kod Java jest kompilowany do JavaScript, więc JRE nie istnieje (jest jedynie w niewielkim zakresie emulowane przez bibliotekę GWT). Standardowe użycie Guice nie zadziała więc z dwóch powodów:

• Na poziomie JavaScript nie istnieją klasy.
• Guice (podobnie jak większość tego typu rozwiązań) często korzysta z mechanizmu reflection Javy, który nie jest w ogóle emulowany w GWT.

GIN stosuje więc inny sposób na zapewnienie wstrzykiwania zależności. Na początek należy zaimportować moduł GIN we własnym module GWT.

<module>
  ...
  <inherits name="com.google.gwt.inject.Inject" />
  ...
</module>

Teraz funkcjonalność oferowana przez GIN jest dostępna w obrębie strony klienta aplikacji GWT. Dochodzimy jednak ponownie do momentu, gdy “jakoś” trzeba w końcu te zależności pobrać. W GIN używa się do tego specjalnej wersji Injectora — Ginjectora (który jednak de facto nie jest związany relacją dziedziczenia z tym pierwszym).

public interface ApplicationGinjector extends Ginjector {
    ApplicationPresenter getApplicationPresenter();
}

Ginjector powinien oferować tylko komponenty potrzebne na etapie inicjalizacji aplikacji. Przy ich pobieraniu zostaną zainicjowane ich zależności, a więc również zależności tych zależności itd. W ten sposób zostanie zbudowany cały graf obiektów, a zależności automatycznie powstrzykiwane. W tym przypadku, komponentem potrzebnym na samym początku działania aplikacji jest ApplicationPresenter, który wyświetla ekran startowy. Zależności definiuje się dokładnie tak jak w Guice, czyli za pomocą adnotacji @Inject.

Jak wiadomo, Injector potrzebuje również modułu, w którym zawarte są informacje na temat komponentów.

public class ApplicationClientModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(ApplicationPresenter.class);
        // other bindings...
    }
}

Jak widać, moduł po stronie klienta w GWT dziedziczy z AbstractGinModule. Poza tym wszystko wygląda dokładnie jak w Guice. Istotnym niuansem związanym z modułami GIN jest fakt, że w przypadku nie odnalezienia powiązania dla klasy, automatycznie wywoływana jest dla niej metoda GWT.create(), przez co niektóre rzeczy (np. asynchroniczne interfejsy usług) będą działać nawet bez odpowiedniej deklaracji w klasie modułu.

Zdefiniowany moduł należy jeszcze skojarzyć z właściwym interfejsem Ginjector za pomocą adnotacji @GinModules.

@GinModules(ApplicationClientModule.class)
public interface ApplicationGinjector extends Ginjector {
    ApplicationPresenter getApplicationPresenter();
}

W ten sposób, Ginjector jest w stanie skonfigurować całą aplikację na podstawie danych zawartych w określonym module. Aby to zrobić, należy go utworzyć za pomocą wywołania GWT.create() oraz pobrać początkowe obiekty.

public final class Application implements EntryPoint {
    public void onModuleLoad() {
        ApplicationGinjector injector = GWT.create(ApplicationGinjector.class);
        ApplicationPresenter applicationPresenter = injector.getApplicationPresenter();
        applicationPresenter.go(RootPanel.get());
    }
}

W ten sposób, cała procedura wstrzykiwania zależności ma miejsce już w czasie kompilacji. Użycie GIN nie jest więc związane z żadnym dodatkowym narzutem przetwarzania. (Wyszłoby na to samo, gdybyśmy konfigurowali komponenty ręcznie.)

Prawie jak Guice

Z użyciem GIN jest związanych kilka niuansów, o czym wspomniałem już na samym początku. GIN to nie jest mimo wszystko to samo co Guice, tylko dla GWT. Najbardziej istotne różnice w stosunku do Guice to:

• Zamiast typów Module i AbstractModule są GinModule i AbstractGinModule.
• Zamiast typu Injector jest Ginjector z adnotacją @GinModules.
• Niemożliwe jest użycie powiązania toInstance() i prawdopodobnie nigdy nie będzie możliwe (ze względu na to, że GIN działa w czasie kompilacji, a nie wykonania).
• Na chwilę obecną nie jest możliwe definiowanie własnych zasięgów.
• Nie ma adnotacji @ImplementedBy oraz @ProvidedBy.
• Brak obsługi zależności cyklicznych.
• Brak wsparcia dla AOP.

Warto jeszcze dodać, że istnieje sposób na współpracę z regularnym Guice za pomocą klasy GinModuleAdapter, dzięki której GinModule staje się dostępny jako zwykły Module. Można więc rozważyć utworzenie wspólnej części zależności w postaci GinModule. Ponadto, zrozumienie jak działa strona klienta w GWT na pewno pomoże uniknąć wielu potencjalnych problemów z GIN.

Podsumowanie

Jak widać, w GWT również można wygodnie wstrzykiwać zależności i to korzystając z bardzo przyjaznego API znanego z Guice. Mimo, że biblioteka ta jest jeszcze nieco niedojrzała i nie doczekała się nawet wersji 1.0, moim zdaniem warto się nią zainteresować i zastosować we własnych projektach w Google Web Toolkit. Używając jej przez ostatnie kilka miesięcy nie napotkałem żadnych problemów (w szczególności ze stabilnością), a znacząco ułatwiłem sobie pracę, rezygnując z ręcznego wstrzykiwania zależności. Myślę, że Google jeszcze nie raz zaskoczy nas różnymi ciekawymi dodatkami do GWT. Póki co, zapraszam na stronę domową projektu oraz zachęcam do własnych eksperymentów z Google GIN.

Google Guice to framework wspierający wstrzykiwanie zależności (ang. dependency injection) w aplikacjach Java. Można by powiedzieć: kolejny framework wspierający wstrzykiwanie zależności. Faktycznie, trzeba przyznać, że rynek Javowych rozwiązań tego typu jest dość mocno nasycony już od dłuższego czasu i oferuje pełen przekrój złożoności bibliotek, zaczynając od bardzo lekkich, takich jak choćby PicoContainer, a kończąc na pełnych stosach rozwiązań Java Enterprise ze Springiem na czele. Czy warto więc zawracać sobie głowę Guice’m? Moim zdaniem warto, bo zaproponowane przez Google’a rozwiązanie pokazuje nową jakość w implementacji wstrzykiwania zależności w aplikacjach Java, czyniąc ogromny użytek z typów generycznych oraz adnotacji. Guice jest przy tym lekki, ma proste API i bardzo szybko można się go nauczyć. Dlaczego warto to zrobić? Bo jest dobry. Kolesie z Google’a go używają. Musi być dobry. Poza tym, wygrał 18th Jolt Award w kategorii Libraries, Frameworks and Components. Musi być dobry.

Podstawy

W Guice występują dwie podstawowe konstrukcje opisujące wstrzykiwanie zależności. Pierwszą są moduły, które mówią co należy wstrzyknąć, a drugą jest adnotacja @Inject, która mówi gdzie należy wstrzyknąć. Proste. Zobaczmy jak to działa na przykładzie usługi rejestracji użytkowników.

public class RegistrationServiceImpl implements RegistrationService {
    private final PersistanceManager persistanceManager;
    private final MailService mailService;

    @Inject
    public RegistrationServiceImpl(PersistanceManager persistanceManager, MailService mailService) {
        this.persistanceManager = persistanceManager;
        this.mailService = mailService;
    }

    public void register(User user) {
        ...
    }
}

Jak widać naszą usługę specyfikuje kontrakt RegistrationService. Mamy jego implementację w postaci klasy RegistrationServiceImpl, która wymaga do działania usługi trwałości danych (PersistanceManager) oraz usługi do wysyłania maili (MailService). Chcielibyśmy, aby odpowiednie implementacje tych usług zostały automatycznie wstrzyknięte za pomocą parametrów konstruktora (adnotacja @Inject) już na etapie tworzenia usługi rejestracji. Spróbujmy opisać zależności między interfejsami a ich konkretnymi realizacjami za pomocą modułu.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(RegistrationService.class).to(RegistrationServiceImpl.class);
        bind(PersistanceManager.class).to(HibernatePersistanceManager.class);
        bind(MailService.class).to(JavaMailService.class);
    }
}

Mamy nasz moduł. Jak widać, metoda configure() zawiera definicje kolejnych powiązań. Mamy więc usługę rejestracji określoną kontraktem RegistrationService z przypisaną naszą implementacją RegistrationServiceImpl. Mamy również usługę trwałości danych PersistanceManager zaimplementowaną w klasie HibernatePersistanceManager, która używa Hibernate’a do zapewnienia trwałości encji, oraz usługę MailService wraz z implementacją JavaMailService korzystającą z JavaMail do wysyłania poczty.

OK. Wystarczy już tylko użyć zdefiniowanego zespołu obiektów i przeprowadzić rejestrację użytkownika.

public class UserRegistrationExample {
    public static void main(String[] args) {
        Injector injector = Guice.createInjector(new MyModule());
        RegistrationService registrationService = injector.getInstance(RegistrationService.class);
        User user = new User("Michal", "Kalinowski");
        registrationService.register(user);
    }
}

To wszystko. Działa. “Prawie” jak w Springu, tylko zamiast trochę przydługawego pliku XML mamy elegancką implementację interfejsu Module w Javie, a zamiast identyfikowania obiektów za pomocą jakichś napisów mamy referencje do rzeczywistych klas. Myślę, że nie muszę wspominać jak ułatwia to refactoring. Jedyne do czego można się “przyczepić” to inwazyjność framework’a (odniesienia do API we własnych klasach), ale coś za coś. Wygoda jest niesamowita. Swoją drogą, pomysł na tyle przypadł do gustu kolesiom od Springa, że sami piszą już coś podobnego; nazywa się to Spring JavaConfig i powinno niedługo zostać oficjalnie wydane.

Oczywiście, proste powiązania interfejs <=> klasa i wstrzykiwanie zależności przez konstruktor to nie koniec możliwości Guice.

Powiązania

Oprócz prostych powiązań klasy z interfejsem, jest również kilka bardziej zaawansowanych konstrukcji.

Jedną z nich jest powiązanie adnotacją. Wyobraźmy sobie, że JavaMailService ma zostać użyty przez 2 różne usługi. Jedna z nich, nasz RegistrationService, do rozsyłania poczty powinna używać konta na Gmail’u, a inna – konta na Yahoo. Nic prostszego. Potrzebna nam dodatkowa adnotacja.

@BindingAnnotation
@Target( { FIELD, PARAMETER, METHOD })
@Retention(RUNTIME)
public @interface Gmail {
}

Modyfikujemy nieznacznie konstruktor naszej usługi rejestracji.

public class RegistrationServiceImpl implements RegistrationService {
    @Inject
    public RegistrationServiceImpl(PersistanceManager persistanceManager, @Gmail MailService mailService) {
        this.persistanceManager = persistanceManager;
        this.mailService = mailService;
    }
    ...
}

Oczywiście potrzebne jest również dodatkowe powiązanie w module.

bind(MailService.class).annotatedWith(Gmail.class).to(GmailJavaMailService.class);

Widać więc, że w Guice powiązanie jednoznacznie definiuje dopiero para adnotacji oraz typu.

Idźmy dalej. Jest możliwość stworzenia powiązania z konkretną instancją danego typu.

bind(String.class).annotatedWith(JdbcUri.class).toInstance("jdbc:mysql://localhost/application");

public class HibernatePersistanceManager implements PersistanceManager {
    public HibernatePersistanceManager(@JdbcUri String jdbcConnectionString) {
         ...
    }
    ...
}

Cool, huh? Można również zdefiniować w module własną metodę tworzenia obiektu. Używa się do tego adnotacji @Provides.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        ...
    }

    @Provides
    PersistanceManager providePersistanceManager() {
        HibernatePersistanceManager persistanceManager = new HibernatePersistanceManager("jdbc:mysql://localhost/application");
        persistanceManager.initConnectionPool();
        return persistanceManager;
    }
}

Robi się bałagan w klasie modułu? Napiszmy zewnętrzne providery dla naszych komponentów.

public class DatabasePersistanceManagerProvider implements Provider<persistanceManager> {
    private final Connection connection;

    @Inject
    public DatabasePersistanceManagerProvider(Connection connection) {
        this.connection = connection;
    }

    public PersistanceManager get() {
        DatabasePersistanceManager persistanceManager = new DatabasePersistanceManager();
        persistanceManager.setConnection(connection);
        return persistanceManager;
    }
}

I jeszcze odpowiednie powiązanie.

bind(PersistanceManager.class).toProvider(DatabasePersistanceManagerProvider.class);

Można nawet zdefiniować providera bezpośrednio w interfejsie.

@ProvidedBy(DatabasePersistanceManagerProvider.class)
public interface PersistanceManager {
    ...
}

Warto zwrócić uwagę, że definicje powiązań w Guice “czytają się same”. Jest to ogromna zaleta tej biblioteki. Nie ma tu nawet co tłumaczyć.

Zasięgi

Domyślnie Guice dostarcza nową instancję klasy przy każdym zapytaniu do kontenera. Można jednak zażyczyć sobie za pomocą adnotacji @Singleton, by istniała dokładnie jedna instancja danego komponentu w obrębie całej aplikacji. W aplikacjach webowych, po dołączeniu odpowiedniego dodatku do deskryptora web.xml, można używać również zasięgu sesyjnego (@SessionScoped) oraz zasięgu pojedynczego żądania HTTP (@RequestScoped). Zasięgi można ustawiać na kilka sposobów. Można np. zrobić to na samej klasie.

@Singleton
public class JavaMailService implements MailService {
    ...
}

Nic nie stoi na przeszkodzie, by ustawić zasięg na metodzie tworzącej obiekt w obrębie modułu.

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        ...
    }

    @Provides @Singleton
    MailService provideMailService() {
        ...
    }
}

Oczywiście, zawsze można zrobić to po prostu w definicji powiązania.

bind(MailService.class).to(JavaMailService.class).in(Singleton.class);

Wstrzykiwanie

W Guice dostępne są 3 standardowe metody wstrzykiwania zależności. Widzieliśmy już wstrzykiwanie przez konstruktor. Można również użyć do tego regularnej metody (niekoniecznie klasycznego settera).

public class RegistrationServiceImpl implements RegistrationService {
    @Inject
    public void provideLogger(Logger logger) {
        ...
    }
    ...
}

Można również wstrzykiwać bezpośrednio do pola klasy, ale jest to zdecydowanie niezalecane.

public class RegistrationServiceImpl implements RegistrationService {
    @Inject Logger logger;
    ...
}

Można w Guice również wstrzykiwać same providery.

public interface Provider<t> {
  T get();
}

Zapewniają one dodatkową elastyczność polegającą na tym, że kontener zwraca instancję komponentu-zależności wraz z każdym wywołaniem metody get(), a nie tylko jednorazowo na etapie tworzenia grafu obiektów.

public class DatabasePersistanceManager implements PersistanceManager {
    private final Provider<connection> connectionProvider;

    @Inject
    public DatabasePersistanceManager(Provider<connection> connectionProvider) {
        this.connectionProvider = connectionProvider;
    }

    public void persist(Object entity) {
        Connection connection = connectionProvider.get();
        ... // do something with provided connection
    }
}

Jakie to może mieć zastosowanie? Różne, przeróżne. Możemy potrzebować wielu instancji tego samego komponentu. Możemy zechcieć pomieszać komponenty różnych zasięgów (np. wstrzykiwanie danych użytkownika utrzymywanych w sesji HTTP do komponentu z zasięgiem Singleton). Możemy wreszcie użyć późnego ładowania (ang. lazy loading), jeśli konstruowanie komponentu-zależności jest kosztowne, a nie musi być wykonywane za każdym razem.

Czy to wszystko?

Oczywiście, omówiono tylko część możliwości Guice, aczkolwiek prawdopodobnie wystarczy to w 90% zastosowań. Widać więc, jak szybko można tę technologię przyswoić. Więcej informacji można odnaleźć w dokumentacji biblioteki. Znajduje się tam m.in. omówienie wsparcia dla programowania aspektowego oraz opis integracji Guice z rozwiązaniami webowymi. Warto tam zajrzeć.

Podsumowanie

Google Guice wydaje się stanowić bardzo ciekawą ofertę jako framework do wstrzykiwania zależności. Jeśli nie potrzebujemy bardzo kompleksowego rozwiązania takiego jak np. Spring, Guice powinien być w zupełności wystarczający. Jest bardzo lekki, prosty i ma niezwykle szybką krzywą uczenia. Dokładne przeczytanie tego posta powinno pozwolić na rozpoczęcie pracy, a w razie problemów zawsze pozostaje dokumentacja. Guice znacznie uprzyjemnia pracę programisty, pozwalając opisywać zależności i szczegóły ich wstrzykiwania za pomocą kodu Java “ozdobionego” adnotacjami i typami generycznymi, z zachowaniem jednocześnie deklaratywnego charakteru tego opisu. Jest to niewątpliwie znaczny krok do przodu. Uważam, że w dobrym kierunku.

.classpath
.project
.settings
.wtpmodules

do atrybutu svn:ignore katalogu każdego projektu w ramach przestrzeni roboczej (ang. workspace) i było po problemie. Aktualnie mamy w zespole jednego NetBeans’owca i do powyższej listy trzeba było dopisać jeszcze:

nbproject

Postanowiłem jednak przy okazji skonstruować kompletną listę wpisów do svn:ignore, która zawiera metadane 3 głównych IDE (Eclipse, NetBeans, IntelliJ IDEA). Dodatkowo dodałem target, jako standardowy katalog wyjściowy Maven’a oraz maskę *.log, bo takie pliki czasem również pojawiają się w repo. Mam nadzieję, że ta lista okaże się dla kogoś przydatna. Wygląda na to, że wystarczy ją “z góry” zaaplikować do wszystkich katalogów projektowych i mieć problem z głowy .

Ostateczna wartości atrybutu svn:ignore:

target
*.log
.classpath
.project
.settings
.wtpmodules
nbproject
*.ipr
*.iws
*.iml