Przekleństwo frameworków Javowych

Dla Javy napisano już setki, jeśli nie tysiące szkieletów do pisania aplikacji webowych. Jeśli ktoś wnikliwie czyta newsy na theserverside to wie, że nowe frameworki powstają jak grzyby po deszczu.

Pytanie jednak brzmi... skoro każdy szkielet jest taki dobry, to czemu powstają nowe? Odpowiedź jest jedna - nie da się napisac szkieletu dla każdego. Ponadto wiele nowych frameworków bardziej utrudnia niż ułatwia życie programistów, starając się rozwiązać każdy problem. Świadczy może o tym na przykład fakt, iż wciąż najczęsciej używany jest Struts, pomimo swego sędziwego wieku.

Jakie więc powinny być cechy idealnego frameworka? W mojej opinii szkielet to narzędzie, które pozwoli programiście przede wszystkich na łatwiejsze i szybsze pisanie aplikacji. Dlatego też szkielet powinien być jak najprostszy, mieć przejrzyste API, zadbany i przemyślany kod źródłowy, aby programista mógł bez problemu go zrozumieć (często lepiej jest po prostu zobaczyć jako kod działa, aniżeli czytać często niekompletną dokumentację). Jeśli zaś mówimy o szybkości pisania aplikacji to developer powinien implementować ją w sposób niezwykle zwinny (ang. agile). Chodzi o to, żeby programista (na przykład na życzenie klienta) mógł bardzo szybko nanieść poprawki bez konieczności wprowadzania zmian w kilku miejscach, długim testowaniu aplikacji od strony GUI (na przykład w przypadku brak możliwości pisania testów jednostkowych dla komponentów GUI) czy wreszcie ciągłych restartów serwera. Jeszcze jedna kwestia - szkielet nie powinien w żaden sposób ograniczać programisty! Jeśli coś można w prosty sposób zrobić w HTMLu i JavaScriptcie, to i w tym szkielecie musi to być czynność prosta i przede wszystkim możliwa(!).

Oburzony brakiem "idealnego" frameworka, stworzyłem własny prototyp takiego szkieletu - zaprojektowany tak, aby mógłbyć podstawą większości aplikacji tworzonych w standardowym modelu klient-serwer (bez udziwnień AJAXowych, z wiszącymi połączeniami włącznie). Szkielet ten zawiera jedynie podstawową funkcjonalność (brakuje w nim chociażby walidatorów), jednak w mojej opinii jest ona w zupełności wystarczająca. Uznaję zasadę, że programista musi znać szkielet, którego używa w 100 procentach. Jeśli udostępniłbym programiście zaawansowane komponenty, to mógłby on w ogóle nie rozumieć zasady ich działania (co w końcu doprowadziłoby do poważnych przestojów w projekcie, związanyc z poprawianiem uprzednio napisanego kodu).

Ów prototyp okazał się na tyle ciekawy, że postanowiłem zacząć pisać projekt z prawdziwego zdarzenia. Projekt nosi nazwę Egg i jak sama nazwa wskazuje jest zalążkiem tworzonej przez Ciebie aplikacji. Używając go będziesz mógł stworzyć zarówno prostą, jak i szalenie skomplikowaną aplikację. Do niektórych jego cech należą: automatyczne reloadowanie klas bez restartów serwera, pełna obiektowość (możliwość tworzenia własnych komponentów w śmiesznie prosty sposób), DRY (zasada nie powtarzania kodu w różnych miejscach), CoC (konwencja zamiast konfiguracji) oraz możliwość łatwego testowania tworzenego GUI (na zasadach TDD). Wersja alpha projektu będzie dostępna w ciągu kilku dni na serwerach Google Code.

Google Web Toolkit

Szukając ostatnio javowych framework'ów do tworzenia aplikacji AJAXowych natrafiłem na Google Web Toolkit. Spotkałem już wiele narzędzi, jednak muszę przyznać, że jeszcze nigdy nie byłem tak podekscytowany :)

GWT to podobnie jak SWT czy SWING biblioteka do tworzenia interfejsów użytkownika. Jednak w tym przypadku tworzymy aplikacje webowe a nie desktopowe. Z pewnością niektórzy używali lub zapoznali się wcześniej z takimi frameworkami jak Echo - tu sprawa wygląda podobnie. Czemu więc jestem podekscytowany? Powodów jest kilka.

Pierwszy to ten, że Google ma za sobą stworzenie kilku świetnych aplikacji AJAXowych (Google Maps, GMAIL). Drugi fakt, że biblioteka jest na licencji Open Source (choć część kodu nie jest dostępna). Po trzecie framework umożliwia w łatwy sposób tworzenie kodu JavaScript w Javie (tak, kod Javy jest kompilowany do JavaScriptu!). Po czwarte umożliwia łatwe debugowanie (w trybie debugowania Java nie jest tłumaczona do JavaScriptu).

Podsumowując GWT wygląda bardzo okazale. Jest to nie tylko biblioteka ale też zbiór narzędzi, które znacznie mogą podnieść wydajność programisty. GWT może na zawsze zmienić życie programistów aplikacji webowych. Sprawi, że będą szybciej i lepiej tworzyć interaktywne interfejsy użytkownika. Wraz z powstaniem wersji stablinej i zaimplementowaniem obsługi Javy 5.0, GWT to ma szansę stać się najpopularniejszych frameworkiem aplikacji AJAX wszechczasów :D

Pierwszy duży projekt w Ruby

Postanowiłem wstrzymać wszystkie moje prace Open Source, na rzecz jednego projektu, który w moim przekonaniu jest najlepszym projektem w całym moim życiu (życiu krótkim, acz niewzykle ciekawym;) ). Framework (albowiem projekt będzie szkieletem aplikacji) ten ma jako jeden z pierwszych umożliwić szybkie i bezbolesne tworzenie gier MMOG (ang. Massive Multiplayer Online Game) oraz aplikacji RIA (ang. Rich Internet Application) działających w "czasie rzeczywistym" (czyt. automatycznie aktualizowanych po stronie klienta)

Tego rodzaju aplikacje stawiają bardzo duże wymagania przed programistą. Tworzy je się zupełnie inaczej niż standardowe web-aplikacje. Jest tu znacznie więcej technik AJAXowych i DHTMLa (co przy dużej liczbie metod podmieniających fragmenty stron może być niezwykle uciążliwe). Programista musi zaimplementować skomplikowane mechanizmy aktualizacji danych u użytkowników. Użycie standardowych frameworków jest tu zupełnie nie na miejscu, ze względu na zbyt duże obciążenie procesora i pamięci (w tego typu aplikacjach ilość użytkowników naraz korzystających z aplikacji mierzy się w tysiącach). Ponadto trudo jest coś takiego sklastrować. Zadaniem frameworka będzie więc ułatwienie życia programisty poprzez dostarczenie mu gotowych mechanizmów, po to, aby mógł się skupić jedynie na implementacji rozgrywki i zaprojektowaniu GUI.

Projekt jest dość śmiały technologicznie choć nie nazbyt przesadzony. Aby mówić o wersji gotowej do użytku będę musiał stworzyć własny serwer WWW, nieco różniący się od istniejących rozwiązań (obecnie zrobiony w 20%), pseudo obiektową bazę danych (coś na wzór prevlayera, ale trochę z innym zastosowaniem), mechanizm "dirty templates" (moja kodowa nazwa na szablony dynamicznie zmieniające się w czasie) oraz parę innych równie ważnych mechanizmów.

Oczywiście użytą technologią będzie Ruby, ze względu na to, że do takich zastosowań jak prototypowanie język ten nadaje się znakomicie.

W ciągu najbliższych kilku dni dodam projekt, na którymś z portali Open Source (Sourceforge albo RubyForge). Ponadto stworzę jakieś wiki (prawdopodobnie na swik.net) oraz blog (mam własnego VPSa więc nie będzie z tym problemu).

Watir rocks!

Ruby coraz bardziej daje o sobie znać na świecie. Nie tylko dlatego, iż jest świetnym językiem programowania, ale także dlatego, że powstaje w nim coraz więcej genialnych projektów.

Szukając sposobu na testowanie gui aplikacji webowych nie mogłem do tej pory znaleźć idealnego rozwiązania. Używałem JMetera, który posiada możliwość porównywania strony wynikowej z żądaną zawartością, jednak takie rozwiązanie było dość ograniczone (nie można było testować AJAXowych aplikacji). Tymczasem technologia idzie do przodu - coraz więcej stron używa skomplikowanego JavaScriptu, więc i narzędzia do testowania muszą się zmieniać. JMetera mogłem ze spokojem odłożyć na półkę, gdy na rubyforge.org znalazłem świętego grala do testów aplikacji webowych.

Watir to projekt umożliwiający symulowanie interakcji użytkownika z przeglądarką. Umożliwia symulowanie działań użytkownika - klikania na buttony, wypełniania formularzy a nawet poruszania myszką. Zasada działania programu jest prosta: piszemy program (test jednostkowy), który odpala przeglądarkę, wykonuje określone czynności i sprawdza wyniki. Podczas testu na żywo widzimy co dzieje się w przeglądarce. Podsumowując program genialny bo prosty i intuicyjny. Oczywiście cały kod testujący piszemy w Ruby :D

Ruby forever!

Minęły 2 miesiące od kiedy poraz pierwszy zetknąłem się z językiem Ruby. Jednak przez ostatni miesiąc szczególnie się nim interestowałem - odwiedzałem serwisy jemu poświęcone, stawiałem różnorodne railsowe web-aplikacje, no i oczywiście programowałem w nim (i w Ruby on Rails również).

Muszę przyznać, że Ruby stał się moim ulubionym językiem. Pomimo, iż w Javie programuję już szmat czasu, to jednak Java chyba nigdy nie wydawała mi się tak genialna jak Ruby. Programując w nim mogłem zapomnieć o conajmniej kilkunastu wzorcach projektowych (w Rubym są one po prostu niepotrzebne!).

Poczułem w końcu (od czasów gdy stworzyłem swoją pierwszą stronę w PHP) przyjemność tworzenia - świadczyć może o tym fakt, iż odpowiednik biblioteki Olitext (napisanej w Javie) stworzyłem w Rubym w zaledwie tydzień (czyli ponad 4x szybciej niz w Javie!). Nie zdarzały mi się momenty gdy technologia stawała mi na drodze - momenty gdy więcej musiałem się zastanawiać nad sposobem użycia bibliotek czy nad strukturą klas aniżeli nad samą implementacją.

Dlatego i Wam szczególnie polecam ten język! :)