Xoft

W poprzednim wpisie znęcaliśmy się nad niezbyt gramotnie napisanym kawałkiem oprogramowania. Teraz przyszedł czas na napisanie wszystkiego tak, jak trzeba, w czym nam pomagać będzie właśnie wstrzykiwanie zależności.

Co nas najbardziej uwierało w poprzedniej wersji aplikacji? Tak na prawdę były to dwie rzeczy:

1. Powiązania między klasami były zrealizowane przy użyciu referencji do konkretnych klas: jeżeli NewsService potrzebował mechanizmu do przechowywania informacji, to dawaliśmy mu referencję do klasy, która potrafiła przechowywać dane w SQL-owej bazie danych. Zmiana sposobu przechowywania danych na inny wymagała zmian w wielu miejscach w kodzie.
2. Jeżeli klasa potrzebowała do pracy innej klasy, to sama musiała sobie utworzyć odpowiedni obiekt: NewsService potrzebując klasy do przechowywania danych sam sobie tworzył jej instancję.

Co w takim razie robi wstrzykiwanie zależności? Mówiąc ogólnie, w DI chodzi o to, żeby nie wiązać się z inną klasą poprzez użycie jej implementacji, tylko poprzez interfejs, pod który można podpiąć dowolną klasę go implementującą.

Dodatkowo, jeżeli nasza klasa potrzebuje konkretnej implementacji tego interfejsu, to nie powinna tej implementacji sama szukać czy jej tworzyć. Odpowiedni obiekt musi zostać do klasy “wstrzyknięty” w momencie inicjalizacji.

Zobaczmy, jak to wygląda w praktyce.
Czytaj resztę wpisu »

Gdzie się człowiek nie obejrzy tam się czai Dependency Injection (DI), czyli wstrzykiwanie zależności. Żeby jeszcze było tego mało, jak się zaczyna grzebać w internecie, to się co chwila można potknąć o jakiś framework, kontener czy coś takiego, co nam samo może zrobić Dependency Injection.

Co to w ogóle jest, po co takie coś komukolwiek, jak tego używać? Okazuje się, że sprawa jest prosta, wręcz banalna, a jednocześnie prowadzi do całkiem interesujących zastosowań. Za chwilę postaramy się zrozumieć jak DI działa, zrobimy to w sposób praktyczny, obdarty z krążących wokół DI ideologii i zupełnie zbędnego adżajlowego bełkotu.

Przekonamy się, że DI jest jednym z wielu możliwych sposobów budowania architektury aplikacji tak, by była łatwa w rozbudowie i testowaniu.

Będziemy chcieli zobaczyć coś więcej, niż zupełnie trywialny przykład (takich jest mnóstwo w internecie), po którym w zasadzie można wzruszyć ramionami, bo nie specjalnie widać tam jakiekolwiek zalety architektury wykorzystującej DI.

Naszym celem będzie zbudowanie bardzo prostej aplikacji służącej do przechowywania informacji, będzie składała się ona z trzech warstw (trójka jest nieprzypadkowa, sporo aplikacji Java EE jest rozbijane na tyle warstw) i tyluż komponentów.

Naszą aplikację napiszemy na kilka sposobów:

• naiwne podeście z paskudną architekturą;
• w miarę rozsądnie wyglądająca aplikacja, wykorzystująca wstrzykiwanie zależności;
• aplikacja wykorzystująca wstrzykiwanie zależności, ale zrobiona źle – warto wiedzieć, że wbrew wrażeniu, jakie można odnieść po ohah i ahah na temat DI, przy jego pomocy też można koncertowo skopać architekturę tworzonego oprogramowania.
• ta sama aplikacja, wykorzystująca wstrzykiwanie zależności i kontener Spring;
• jeszcze raz to samo, ale z wykorzystaniem Google Guice;
• następnie spróbujemy porównać działanie Spring i Google Guice;
• wreszcie, na końcu trochę “filozofii”, czy faktycznie DI jest potrzebne, czy jest potrzebne tylko Javie, jak to jest z innymi językami.

Zatem, do dzieła!
Czytaj resztę wpisu »

Naszym celem jest utworzenie prostej aplikacji szukającej plików na dysku, gotową aplikację można uruchomić przez Java WebStart, dostępny jest oczywiście kod źródłowy, powiedzmy, że na licencji BSD ;).

Wstęp
Swing Application Framework jest szkieletem aplikacyjnym, który ma uprościć tworzenie aplikacji desktopowych w Java Swing. SAF z założenia ma być rozwiązaniem prostym, rozwiązującym podstawowe problemy, na jakie napotykamy się tworząc programy z interfejsem użytkownika w Javie.

Czym więc zajmuje się SAF?

• Cyklem życia aplikacji od jej uruchomienia po zamknięcie
• Zarządzaniem zasobami: łańcuchami znaków, kolorami, ikonami, czcionkami itp. rzeczami, które występują w typowej aplikacji. Oczywiście wszystkie zasoby mogą być internacjonalizowane/lokalizowane.
• Obsługą zdarzeń (co ma się stać, gdy użytkownik naciśnie przycisk X). W szczególności SAF upraszcza znacząco obsługę długotrwałych zdarzeń, które powinny wykonywać się w wątkach roboczych, a nie głównym
• Pamiętaniem stanu aplikacji. Po zamknięciu aplikacji pamięta ona jaki był stan interfejsu użytkownika (rozmiar okien, ich położenie) przed zamknięciem.

Żeby nie przedłużać wstępu przejdźmy do rzeczy, czyli przyjrzyjmy się przykładowej aplikacji Szukacz. Szukacz jest kulawą i ubogą namiastką grep-a napisaną w Javie, ma za to graficzny interfejs użytkownika.

Aplikacja jest skonstruowana inaczej niż w większości tutoriali Swing Application Framework, które można znaleźć w Internecie. Problem z umieszczonymi tam przykładami jest taki, że w rzeczywistej sytuacji są one mało użyteczne. Przykłady te dzielą się na dwie grupy:

1. aplikacje wyklikane od początku do końca w środowisku NetBeans, korzystające z kreatorów kodu tam dostępnych
2. aplikacje napisane całkowicie ręcznie, włącznie z elementami GUI

Tak na prawdę żadna z tych sytuacji nie jest typowa.

Ad. 1. Nie każdy musi chcieć używać NetBeansa (fakt, jest bardzo dobry jeśli chodzi o tworzenie GUI), a nawet jeżeli używamy go, to istnieje duża szansa, że mamy już napisany jakiś spory kawał kodu, który nie używa SAF i chcielibyśmy jakoś gładko istniejący kod zintegrować z tym frameworkiem.

Ad. 2. Jeśli nie jesteśmy maniakalnymi zwolennikami ręcznego dziergania kodu GUI, co zazwyczaj kończy się mniejszą lub większą katastrofą połączoną z gromami rzucanymi na Swinga i Javę w ogóle, to pewnie chcemy użyć jakiegoś wizulanego narzędzi, które pozwoli nam wyklikać strukturę GUI. Narzędzie to na bank nie słyszało jeszcze o SAF, a my chcemy sobie klikać interfejs użytkownika i jednocześnie łatwo go zintegrować z SAF.

Tak więc chcę pokazać, jak tworzyć sobie GUI takim sposobem, jak nam się podoba i móc go w każdej chwili zintegrować z SAF. Zatem do dzieła. Czytaj resztę wpisu »

Wygląda na to, że są to dwaj najpopularniejsi gracze na rynku darmowych ajaksowych komponentów JSF, co zatem wybrać? Pierwsza rzecz: czy trzeba w ogóle wybierać? Niestety tak, obie biblioteki nie chcą ze sobą współpracować – każda z nich inaczej włącza się w cykl życia strony JSF i to powoduje różna zabawne problemy. Podobno w którejś tam wersji ma być możliwa koegzystencja obu produktów…

Porównanie obu bibliotek można znaleźć na stronie JSF Matrix, ale niewiele z niego wynika, jak to zazwyczaj bywa ze statystykami w rodzaju “liczba dostępnych komponentów”.

Kto i co robi
Zacznijmy od krótkiego przedstawienia obu bibliotek.

RichFaces. Biblioteka była produktem firmy Exadel, która połączyła się, albo została kupiona przez JBoss-a, czyli RedHata. Ehh, ten świat wielkich korporacji… Biblioteka jest dostępna na licencji Open Source, zawiera ponad 50 różnych komponentów JSF.

ICEFaces jest robiona przez firmę ICESoft i też jest opensorsowa.

Zalety RichFaces i wady ICE Faces
Dużą zaletą RichFaces jest pod-biblioteka Ajax4JSF, która pozwala “zajaksować” dowolny komponent JSF. Jest to bardzo wygodne, jeżeli mamy już napisany kawałek aplikacji i chcemy gdzieniegdzie ją upiększyć ajaksowymi wodotryskami.

Kolejną przyjemną cechą RichFaces jest możliwość określenia zachowania komponentów tak, żeby niekoniecznie za każdym razem łączyły się z serwerem (Ajaxa im można wyłączyć, innymi słowy). Można na przykład utworzyć stronę z zakładkami w ten sposób, że wszystkie są od razu ładowane i przy ich zmianie nie jest potrzebny kontakt z serwerem. Oczywiście można także skonfigurować sobie zachowanie ajaksowe, czyli zakładki będą doładowywane dynamicznie.

ICEFaces czegoś takiego nie potrafi, jego komponenty zawsze kontaktują się z serwerem, co jest trochę głupie w przypadku dajmy na to komponentu kalendarza – można go przecież zrobić łatwo po stronie klienta, każdorazowy kontakt z serwerem jest w 95% przypadków zbędny. Swoją drogą to jakaś obsesja, większość komponentów kalendarzowych ludzie robią ajaksem, tak przynajmniej mówi jsfmatrix.net.

ICEFaces pozwala używać JSF 1.2, ale wymaga używania trybu zgodności ze specyfikacją JSF 1.1. Trochę lipa.
W web.xml trzeba deklarować użycie starej wersji JavaServelts

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

a w faces-config.xml:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

Przez to nie możemy wykorzystać różnych fajnych rzeczy, które wniosło JSF 1.2.

Łatwiej jest testować aplikacje, które używają RichFaces, bo JSFUnit wspiera właśnie to rozwiązanie – nic w tym dziwnego, gdyż JSFUnita robi RedHat.

Zalety ICE Faces i wady RichFaces
Ok, wygląda na to, że RichFaces wygląda lepiej, ale parę rzeczy w ICE też mi przypadło do gustu. Przede wszystkim wygląd, komponenty są na prawdę dopracowane, wyglądają perfekcyjnie.

Druga rzecz, to sposób odświeżania strony JSF. ICE robią aktualizację wszystkich elementów ajaksowych na całej stronie, dzięki czemu nie musimy się martwić o synchronizację obsługi różnych żądań ajaksowych. W RichFaces trzeba to robić ręcznie, co ma swoje wady.

ICEFaces mają lepiej działającą obsługę ajaksa w trybie “push”, RichFaces też to potrafią, ale stosunkowo od niedawna, więc ciężko stwierdzić, na ile ich implementacja działa niezawodnie.

No i wreszcie na koniec ICEFaces dobrze integrują się nie tylko z Eclipse, ale także z NetBeansem (dla mnie to ważne, bo coraz częściej używam tego drugiego).

Decyzja?
Póki co, zdecydowanie RichFaces.

Wtyczki Eclipse’a zaczynają sobie na coraz więcej pozwalać. Zdarza się, że po instalacji czegoś do Eclipse Europa, np. Mylyn-a, wtyczki do Scali lub po przełączeniu się na inną przestrzeń roboczą lub po prostu zupełnie nieoczekiwanie zamiera podpowiadanie składni. Człowiek klika Ctrl-Space i nic.

Oznacza to, że coś nam wyłączyło/przełączyło na swój tryb podpowiedzi. Co zrobić? Prosta sprawa (he, he): wchodzimy w Windows > Preferences, zakładka Java > Editor > Content Assist > Advanced i włączamy z powrotem to, co chcemy.

Grrrr.

Prezentacja jest dostępna w PDF-ie, a przykładowa aplikacja, Szukacz, jest projektem środowiska NetBeans.

Jeżeli ktoś jest niecierpliwy, to może uruchomić aplikację przy pomocy Java Web Start wystarczy kliknąć tutaj.

Wkrótce (w prezencie Wielkanocnym) pojawi się w blogu artykuł szczegółowo opisujący Swing Application Framework i sposób implementacji samego Szukacza.

17. marca o 13.30 na konferencji GigaCon 2008 będę opowiadał o Swing Application Framework. Zapraszam wszystkich zainteresowanych! Będę starał się unikać przynudzania, na rzecz pokazania jak w SAF-ie można szybko zrobić coś dobrze działającego i wyglądającego. Pewnie będę używał NetBeansa, ale to akurat ma małe znaczenie.

Streszczenie mojego wykładu Swing Application Framework czyli tam i z powrotem:

Technologię Swing, pozwalającą tworzyć graficzny interfejs użytkownika w Javie, od samego początku jej istnienia, czyli od 10 lat, prześladował pech. Pierwsze implementacje były niewydajne i uciążliwe w użyciu, kolejne, coraz lepsze wersje tego interfejsu programistycznego także nie rozpieszczały programistów.

Swing Application Framework jest długo oczekiwaną nakładką na niskopoziomową funkcjonalność Swinga, która znacznie ułatwia i przyspiesza pracę przy budowie GUI. W czasie wykładu postaramy się rozpoznać te elementy tworzenia interfejsu użytkownika, które są szczególnie kłopotliwe, a następnie zobaczymy SAF w działaniu. W szczególności skoncentrujemy się na tym, jak ułatwić sobie programowanie typowych elementów aplikacji z GUI: inicjalizacji i zamykania aplikacji, programowania wielowątkowego, obsługi zdarzeń.

Główna część wykładu będzie praktyczną demonstracją tworzenia aplikacji wykorzystującej SAF.

Skąd się wziął ten blog i co w nim będzie? Postanowiłem zebrać razem trochę tekstów porozrzucanych po internecie, prezentacji z konferencji oraz nigdzie nie spisanych doświadczeń związanych z tworzeniem oprogramowania. Czasem także coś mi do głowy przyjdzie, co może się komuś przydać, także postanowiłem mieć swój własny kawałek sieci.

Generalnie to bardzo podziwiam ludzi, którzy mają czas na tworzenie swoich stron domowych z obrazkami dziesiątkami podstron, itp. Ja postanowiłem pójść po najmniejszej linii oporu i założyć prostego bloga (myślałem też o wiki, ale wikitext budzi we mnie grozę).

Pojawił się problem, jakie oprogramowanie wybrać (sam nic nie zamierzałem pisać, jeszcze nie zwariowałem). Przejrzałem kilka rzeczy pisanych w różnych technologiach i w zasadzie jedynym sensownym rozwiązaniem okazał się Wordpress.

Zacząłem się zastanawiać, co akurat Wordpress-a czyni takim dobrym kawałkiem oprogramowania. Składa się na to kilka elementów.

• Dobór technologii do zastosowania. Blog jest bardzo prostą aplikacją webową, nie ma sensu wyciągać do jego konstrukcji armat (Java), albo używać języka o jakiś szczególnie wyrafinowanych możliwościach (np. Ruby). Dodatkowo w polskich warunkach dochodzi kwestia łatwości znalezienia hostingu. Dlatego PHP jest optymalnym rozwiązaniem.
• Oprogramowanie robi tylko to, co ma robić. Wordpress (na szczęście) nie próbuje być niczym więcej, niż prostym silnikiem do bloga. Nie ma tam funkcjonalności CMS-a, wymyślnego systemu tworzenia szablonów, itp.
• Instalacja/konfiguracja. Blog to zazwyczaj poboczny element działalności przeciętnej osoby. Nawet jeśli ktoś ma spore umiejętności programistyczne, to rzadko ma ochotę szarpać się akurat z blogiem. Instalator Wordpress-a po prostu go instaluje, nie robi dziwnych rzeczy w rodzaju sprawdzania ustawień PHP, zainstalowanych bibliotek, dostępnej pamięci itp., co jest zmorą różnego rodzaju wynalazków PHP-owych (mój ulubiony sprawdzian, to czy jest ustawiona flaga register_globals czy nie).

Znalazłem też bardzo przyjemny szablon bloga, White as milk. Musiałem go trochę zmodyfikować, bo miał dla mnie zbyt wąską kolumnę na treść. Poza tym potrzebowałem jakiegoś przyzwoitego narzędzia do formatowania i kolorowania składni kodu na stronie. Idealna okazała się biblioteka Syntax Highlighter. Działa wyłącznie po stronie klienta (100% JavaScript) i jest prosta w użyciu. Zmodyfikowany przeze mnie szablon z podświetlaczem składni można sobie ściągnąć tutaj: wersja angielska lub wersja polska.

Użycie podświetlacza jest wygodne, wstawiam:

<pre name="code" class="Java">
public class Test{
  public static void main(String[] args){
    //...
  }
}
</pre>

i dostaję

public class Test{
  public static void main(String[] args){
    //...
  }
}