TryCatch: Nieblokujące serwery sterowane zdarzeniami

Na blogu TryCatch zamieściłem 4 pierwsze części cyklu traktujące o nieblokujących serwerach sterowanych zdarzeniami:

Wstęp
Równoległa obsługa żądań
Zyski
Zastosowanie
Problemy
Technologie

TryCatch: Rozpoczęcie działalności TryCatch

TryCatch: Rozpoczęcie działalności TryCatch: Od 1. grudnia firma TryCatch jest oficjalnie zarejestrowaną firmą w Polsce. Została założona przeze mnie aby sprostać wymaganiom wszy...

Use Java as a dynamically typed programming language

Java is a statically typed programming language. This means that at the time of compilation the types of variables used in the program are known. This feature is one of the most powerful (if not the most powerful) thing, which gives a programmer warnings about bad code written before he runs it. This allows also to build powerful development environments like Eclipse with content assists and refactoring support. Unfortunately there is no rose without a thorn. Because of static typing a program code is a much bigger (types need to be specified in declarations, casting is necessarily) and sometimes simple problem becomes too complex. If you don't believe in this statement - check the core of JavaServer Pages technology (I mean scriptlets, without JSP tags) and see how much unnecessarily code you need to write just to print some attribute's field on the screen.

There is a lot of frameworks written for Java. Most of these frameworks use interfaces or abstract classes as a building block. Let me give an example: in order to create a HTTP servlet you need to create a new class extending the abstract HttpServlet class. This is simple, but... hmm... Do you really need to write a dedicated class for every action? It will not be better if you have multiple actions grouped together? Because of static typing you can't just do this easily, which of course does not mean that this is not possible. The solution is the reflection API bundled into JRE. You can execute methods, access or update fields etc. of objects of any type.

As a simple example what you can do with reflections check the following code of controller written in Egg Framework (full stack web framework being developed by me):

package controllers;

import static framework.GlobalHelpers.*;
import framework.Response;

public class SampleController {
 
 public void newProduct() {
  Product product = paramsAsBean(Product.class);
  // TODO save product in db
 }
 
 public Response removeProduct() {
  if (session("logged") == null) {
   // not allowed
   return renderText("Access denied");
  }
  // TODO remove product from db
  return null;
 }
 
}

The Egg Framework uses reflections extensively. There is no configuration (Convention over Configuration), no interfaces. Every class can be a controller, every class can be a form bean etc. (just plain old java objects - POJO). In this example Egg Framework uses request parameters sent to the server to decide which method (action) to invoke. Note that both methods have different signatures - not only the name, but the return type. But for Egg Framework it does not matter. If the action returns something not null then Egg Framework handles this, otherwise it runs normal processing. In this example I have used also static methods (check the import static statement on the top). Static imports are really great and can simplify your program dramatically.

So what the conclusion for this post? I think that there is still a lot to do in Java libraries, frameworks and APIs design. Egg Framework is one of many examples how to make Java programs looks prettier.

API do kopiowania JavaBeans

Ostatnimi czasy często spotykam się z problemem konieczności stworzenia kopii JavaBean'a. O ile dla Javy napisano już tysiące API to jednak do tej prostej czynności wciąż nie ma rozwiązania idealnego.

Omówię teraz pokrótce o co mi chodzi. Przede wszystkim API takie powinno dostarczać następujące funkcjonalności:

• kopiować wgłąb (tzw. deep copy) - kopiowanie referencji nie wchodzi w grę gdyż nie jest to wtedy tak naprawdę operacja kopiowania
• nie kopiować n razy tej samej referencji - jeśli w oryginalnym obiekcie znajduje się wiele referencji do 1 obiektu, to w kopii też powinno być wiele referencji do skopiowanego obiektu
• radzić sobie z cyklami - w przypadku wystąpienia cyklu nie powinien wyrzucać wyjątków
• wykorzystywać dostarczony ClassLoader do wczytywania klas - tak aby można było dostarczyć zmodyfikowane klasy

Na www znalazłem kilka rozwiązań. Między innymi dobrze znane Commons Beanutils. Niestety ono nie spełnia ani jednego wymogu. Drugą biblioteką, która mi wpadła do rąk była Sojo. API jest w fazie rozwoju ale już teraz udostępnia wiele funkcjonalności. Obsługuje kopiowanie wgłąb i radzi sobie z cyklami. Nie kopiuje też uprzednio skopiowanej referencji. Niestety nie znalazłem sposobu na dostarczenie własnego ClassLoadera.

Ze względu na brak wymarzonej biblioteki zacząłem szukać alternatywnych rozwiązań. Pierwszą techniką, którą wykorzystałem była wbudowana serializacja. Niestety ta metoda nie pozwala na dostarczenie własnego ClassLoadera (wykorzystywany jest ClassLoader wywołujący metodę deserializacji) i wymaga by każda klasa implementowała interfejs Serializable.

Kolejnym rozwiązaniem, które przetestowałem było użycie koderów JavaBean<->XML dostarczanych wraz z JRE (klasy XMLEncoder, XMLDecoder). Technika ta jest zdecydowanie najwolniejsza, jednak na pierwszy rzut oka wydawało się, że posiada wszystkie cechy, które od takiego API wymagam. Niestety pomimo dostarczenia własnego ClassLoader'a nie jest on wykorzystywany do wczytania wszystkich niezbędnych klas.

Po kilku dniach próbowania różnych technologii stwierdziłem, że szybciej będzie jak sam zaimplementuję taką funkcjonalność. I w ten oto sposób w 2 dni napisałem proste API do kopiowania beanów ze wszystkimi funkcjonalnościami. API nosi roboczą nazwę BeanCopier i na razie dostępne jest do ściągnięcia na repozytorium Maven 2 pod adresem: http://eggframework.org/maven2.

Aby użyć API we własnym projekcie Maven 2 należy dodać do pom.xml:

<project>
    <dependencies>
        <dependency>
            <groupId>com.jacekolszak</groupId>
            <artifactId>beancopier</artifactId>
            <version>0.9</version>
        </dependency>
    </dependencies>
    <repositories>
        <repository>
            <id>Egg Framework</id>
            <url>http://eggframework.org/maven2</url>
        </repository>
    </repositories>
</project>

Sposób użycia BeanCopier:

BeanCopier beanCopier = new BeanCopierImpl();
copy = beanCopier.copy(original, classLoader);

Niebawem wrzucę źródła na CVS. Póki co są one dostępne w jarze beancopier-0.9-sources.jar na repozytorium Maven 2.

UPDATE: Źródła są dostępne na repozytorium Bazaar po adresem: http://bazaar.launchpad.net/~jacekolszak/beancopier/trunk. Wystarczy wydać polecenie:
bzr branch http://bazaar.launchpad.net/~jacekolszak/beancopier/trunk
aby ściągnąć najnowsze źródła.

Fluent Interface w Egg Framework 2.0

Jedną z najciekawszych funkcjonalności wprowadzonych do Egg Framework 2.0 jest Fluent Interface - API, za pomocą którego można tworzyć czytelny kod aplikacji www w języku Java - wyglądający o dziwo bardzo podobnie do HTMLa.

Fluent Interface to pojęcie wprowadzone przez Martina Fowlera i Erica Evansa. Nazwali oni tym terminem pewien styl tworzenia interfejsów programowych. Więcej można przeczytać na blogu Martina Fowlera.

Oto przykład strony www stworzonej przy użyciu Fluent Interface zaimplementowanym w Egg Framework 2.0:

package org.eggframework2.view.examples.xhtml;

import static org.eggframework2.view.elements.xhtml.ext.FluentInterfaceMethods.*;

import org.eggframework2.view.elements.IElement;
import org.eggframework2.view.elements.xhtml.tags.Html;

public class FluentInterfaceUsageExample extends Html {

    public FluentInterfaceUsageExample() {
        IElement body = //
        body( //
                p("Hello World"), //
                a("Egg Framework Page", href("http://eggframework.org")), //
                form(action("/action.do"), method("post"), //
                        input(type("text"), name("Login")), br(), //
                        input(type("password"), name("Password")), br(), //
                        input(type("submit"), value("Please log me in"))//
                ),//
                table(//
                        tr(//
                                td("Cell 1"), td("Cell 2"), td("Cell 3")//
                        ),//
                        tr(//
                                td("Cell 1"), td("Cell 2"), td("Cell 3")//
                        )//
                ));

        add(body);
    }

    public static void main(String[] args) {
        System.out.println(new FluentInterfaceUsageExample());
    }
}

Jak widać kod Javy jest bardzo czytelny i podobny do wynikowego kodu HTML. Wszystko dzięki wykorzystaniu metod statycznych i statycznych importów. Dzięki zaimportowaniu wszystkich metod z klasy FluentInterfaceMethods możemy ich użyć w kodzie strony tak jakby były one jej częścią. Nie musimy więc poprzedzać nazwy metody nazwą klasy w jakiej jest ona zdefiniowana. To sprawia, że kod jest znacznie bardziej zwięzły.

Klasa FluentInterfaceMethods oprócz metod tworzących instancje elementów (znaczników) HTML posiada metody tworzące atrybuty np. type, name, id. Dzięki temu można w jednej linijce utworzyć element i ustawić jego atrybuty.

Jeśli często używasz układania kodu źródłowego (Pretty Print) to musisz być przygotowany na to, iż większość IDE ułoży kod takiej strony w jednej linijce (albowiem całą zawartość tworzysz poprzez zagnieżdżone wywołania metod). To na pewno nie przyczyni się do zwiększenia czytelności kodu, wręcz odwrotnie - znacznie ją pogorszy. Aby ustrzec się przed taką sytuacją należy użyć komentarzy ("//") w miejscach gdzie IDE ma złamać linię. Dzięki nim nawet po operacji układania kodu kod będzie ładnie się prezentował.

Fluent Interface w Egg Framework to sposób na zwiększenie czytelności tworzonego kodu. Jest to swojego rodzaju nakładka i wykorzystuje istniejące API. Po kilkunastu/kilkudziesięciu minutach pracy powinieneś się przyzwyczaić do tego "dziwnego stylu programowania". Od Ciebie zależy czy będziesz go wykorzystywał czy nie - w wielu wypadkach może okazać się lepszy, jednak mogą zdarzyć się sytuacje gdy utworzenie zawartości strony "w standardowy sposób" będzie prostsze i szybsze.

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! :)

Początki z Ruby cz. 3. - Rails

No i doszedłem w końcu do technologii wywołującej osatnimi czasy największe rumieńce u programistów aplikacji webowych. Chodzi oczywiście o Ruby on Rails - framework, który ma szansę stać się najpopularniejszym szkieletem aplikacji wszechczasów. Aplikacje webowe to szczególny rodzaj oprogramowania. Wiele czynności, które musi wykonać programista jest powtarzalna - od stworzenia mechanizmu dispatchującego, poprzez akcje, widoki i model.

Railsy spełniają wszystkie podstawowe wymogi, które stawiane są nowoczesnym szkieletom web-aplikacji. Można więc w nim korzystać z kontrolerów i szablonów. Można także korzystać z mapowań OR i interfesów web serviceów (to raczej nie często się spotyka w typowych frameworkach).

Mamy więc gotowe samowystarczalne rozwiązanie do pisania małych, średnich a nawet dużych webaplikacji - nie trzeba używać zewnętrzych bibliotek np. do wysyłania maili czy operacji na bazie danych.

Ruby on Rails to także szkielet z bardzo silnym wsparciem dla AJAXu. Mamy zbiór komend, które znacznie skracają czas pisania prawdziwie interaktywnych aplikacji. Co jednak sprawia, że w Railsach zakochuje się coraz większa ilość programistów dawniej przekonanych o potędze Javy? PRZYJEMNOŚĆ Z TWORZENIA i CZAS JAKI TRZEBA POŚWIĘCIĆ NA NIEWAŻNE Z PUNKTU WIDZENIA UŻYTKOWNIKA RZECZY.

W następnym wątku opiszę po krótce mój pierwszy dzień tworzenia projektu Communities Website System, który pisany jest właśnie w Railsach.

Sposób na automatyczne aktualizacje w Rich Internet Applications

Ostatnimi czasy bardzo intensywnie zajmuję się tworzeniem Rich Internet Applications. Większość tych programów pisałem w ActionScript 2.0. Od tygodnia jednak zajmuję się pisaniem małych aplikacji w RubyOnRails z wykorzystaniem bibliotek javascriptowych do asynchronicznych wywołań (czyli do AJAXa).

Podstawowym problemem każdego programisty aplikacji WWW jest napisanie czegoś co nie będzie generować dużego ruchu w sieci. Pisząc RIA nie można się przed tym uchronić. Niestety model HTTP nie jest zbyt odpowiedni do tego typu aplikacji - o wszelkich zmianach w bazie danych klient dowiaduje się dopiero po wysłaniu żądania.

Przykładowo mamy prostą grę www, w której ruchy jednego gracza są obserwowane przez drugiego. Załóżmy, że gracz 1 co kilkanaście sekund dokonuje ruchu. Natomiast gracz 2 chciałby od razu widzieć co się wydarzyło. Teraz pojawia się problem - aby coś takiego uzyskać trzeba na przykład w odstępie 2 sekund wysyłać zapytania typu GET do serwera, aby sprawdzić czy ruch w ogóle nastąpił. Zakładając, że prawie puste zapytanie typu GET + odpowiedź serwera pochlania około 4kB (razem w obie strony) mamy więc 2kB/s dla jednego gracza. Jeśli dysponujemy łączem powiedzmy 1Mbit(~128kB), to jesteśmy w stanie obsłużyć naraz zaledwie 64 użytkowników (!). Trzeba jednak pamiętać, że możemy mieć nawet 2 sekundy poślizgu z aktualnością danych.

Bardzo dużo nad tym problemem myślałem i przychodziły mi do głowy jedynie rozwiązania polegające na tworzeniu własnych trwałych połączeń w obie strony. Jednakże dzisiejsze firewalle czy serwery proxy na to nie pozwolą... Trzeba więc trzymać się protokołu HTTP...

Wpadłem jednak na rozwiązanie problemu :D Nie wiem czy jest odpowiednie i czy na pewno będzie działać. Wiem jednak, że jest najlepsze z moich dotychczasowych rozwiązań... :D

Trik polega na tworzeniu nasłuchiwaczy. Nasłuchiwaczem jest po prostu każdy klient, który chce dowiedzieć się o zmianach wybranej częsci bazy danych. Klient łączy się z serwerem, podczas gdy serwer nie odsyła mu od razu odpowiedzi.... Połączenie więc "wisi" do momentu gdy któryś z graczy zmieni jakieś dane w bazie. Gdy wiszący wątek otrzyma taką informację - generuje odpowiedź serwera, po czym kończy wykonywanie żądania. Nasłuchiwacz dostaje więc info, od razu gdy dane zostały zmienione. Po czymś takim nasłuchiwacz ponownie łączy się z bazą danych, gdyż chce znów nasłuchiwać zmian.

Rozwiązanie jest przede wszystkim idealne, z uwagi na to że działa przez HTTP. Jedynym problemem są timeouty. Na przykład serwery proxy mogą czekać określoną ilość sekund na odpowiedź, po czym się rozłączają. Wtedy klient musi coś takiego przechwycić i połączyć się ponownie (oczywiscie po stronie serwera wiszący wątek musi takze zostać usunięty).

Co myślicie o tym rowiązaniu? Czy nie ma żadnych innych przeciwskazań aby użyć takiego techniki?

Początki z Ruby cz. 2. - RDT

Naukę zacząłem oczywiście od poszukania jakiegoś porządnego środowiska programistycznego. Ku mojemu zaskoczeniu okazało się, że najlepsze środowisko zostało napisane pod... tak tak... ukochanego Eclipse'a :D

Ruby Development Tool, bo tak ów plugin się nazywa posiada wiele cech Javovego JDT. Oczywiście daleko mu do zaawansowanych mozliwosci JDT, jednakże posiada podstawową funkcjonalność, która znacznie ułatwić może życie początkującego i średnio zaawnsowanego programisty języka Ruby.

Mamy więc takie rzeczy jak: quick assist (ctrl+spacja), widok outline, debugger zintegrowany z tym eclipsowym, gui testow jednostkowych niemal identyczne jak to dla javowego JUnit, podswietlanie składni czy sprawdzanie w locie.

Projekt ostatnimi czasy coraz szybciej się rozwija, w związku z czym możemy liczyć na szybkie dodawanie nowych funkcjonalności i poprawienie bugów.

Początki z Ruby cz. 1.

Mamy ostatnio modę na Ruby - świetny język skryptowy autorstwa Yukihiro Matsumoto. Na najpopularniejszych blogach javowców co 5 wątek dotyczy Rubiego lub Ruby on Rails. Postanowiłem sprawdzić co takiego genialnego ma w sobie ten skryptowy język i zacząłem się go uczyć.

Ruby to przełom w programowaniu obiektowym. Jest to język, w którym wszystko jest obiektem. Nie ma tu typów prostych jak int, long czy double w Javie. Każda zmienna i wartość posiada więc metody i właściwosci. Jest to jednak przede wszystkim język dynamicznego typowania - nie trzeba definiowac typu obiektu ani rzutować typów. Brakuje tu interfejsów, są za to moduły. Mamy bardzo rozwinięte mechanizmy iteracji i bloki kodu będące wywołaniami zwrotnymi (ang. callbacks). Jest to język o bardzo skrótowym zapisie - z powodzeniem na jednym ekranie można mieć otwarte 2 edytory obok siebie (w javie monitora nie starcza na jednego;). To wszystko sprawia, że programuje się szybko i bezboleśnie - w myśl zasady Agile Programming. Ideą twórców zaś, jest sprawienie, że programujący w Ruby poczują prawdziwą przyjemność z programowania.

W następnych wątkach postaram się przybliżyć dobre strony (i być może złe strony) programowania w Rubym.

ODBMS vs. RDBMS - czyli wydajność i wygoda vs popularność i dostępność ;)

Przez kilka ostatnich dni zajmuję się tworzeniem aplikacji, której wydajność jest kluczowa - to czy będzie działać kilka procent szybciej ma ogromne znaczenie. Dlatego też staram się na wszystkim oszczędzać - na ilości przesyłanych danych (bo to aplikacja klient-serwer), ilości tworzonych nowych wątków do obsługi żądań, no i na czasie wykonywania operacji na bazie danych.

Przyznam, że dotychczas jeśli chodzi o aplikacje bazodanowe to tworzyłem je tylko w oparciu o relacyjne bazy danych (zarówno w Javie, jak i w PHP). Jakiś czas temu zacząłem też używać frameworków do mapowań O/R (JDO, Hibernate, Propel). Nigdy jednak nie pomyślałem, że zastosowanie tych technologii może być niewłaściwe dla jakiejkolwiek aplikacji. A jednak...

Dziś w tworzeniu web-aplikacji używa się niemal jedynie relacyjnych baz danych (sam nie znam żadnej PHP-owej witryny, która by używała czegoś innego). Rzeczywistość pokazuje jednak, że w przypadku baz danych, do których wysyła się dużą liczbę zapytań takie rozwiązanie wcale nie jest wydajne, a nawet wygodne(!).

Programując systemy z użyciem obiektowych języków prorgamowania chciałoby się używać tylko i wyłącznie tego języka i niczego więcej. Tymczasem programując aplikacje bazodanowe z użyciem RDBMS trzeba mieć na względzie strukturę bazy danych, wiedzieć jak taka baza pracuje, martwić się wieloma niepotrzebnymi rzeczami. Najgorsze jest jednak to, że taka baza nie przechowuje obiektów a jedynie zbiory rekordów, które muszą być mapowane na obiekty (lub na odwrót). Tu z pomocą przychodzą narzędzia O/R - JDO, Hibernate (Hibernate+Spring+Transakcje), Propel - jednak zastanówmy się jakim kosztem ? Im więcej warstw pośrednich, tym mniejsza wydajność aplikacji. Pójdę jeszcze o krok dalej - a czy w ogóle JDBC jest wydajne? Przecież dla każdej kolumny w zapytaniu JDBC tworzone są nowe obiekty - a duża ilość takich operacji może znacznie obciążyć naszą aplikację.

Tu z pomocą przychodzą obiektowe bazy danych - proste, wydajne, łatwe w użyciu, a przede wszystkim "obiektowe" ;) Prevayler to jedna z najpopularniejszych ODBMS dla Javy. Zakłada ona, iż wszystkie dane pochodzące z naszej aplikacji będą trzymane w pamięci operacyjnej RAM. Ktoś mógłby powiedzieć: "No dobrze, to po co w ogóle używać bazy danych skoro wszystko może być w pamięci RAM". Oczywiście można trzymać wszystkie obiekty w RAMie, ale przeszukanie ich może zająć bardzo dużo czasu (o ile nie napisze się jakiegoś własnego wydajnego mechanizmu, ale to już sie mija z celem ;) Aplikacja używająca Prevayler musi więc sama zarządzać tworzeniem zrzutów bazy danych (backup na wypadek awarii lub restartu serwera). Ponadto trzeba się liczyć z tym, że jeśli ilość danych będzie bardzo duża to zajmie dużo miejsca w pamięci operacyjnej - a przecież nie mamy jej w nieskończonych ilościach. Powracając do sedna sprawy, czyli wydajności - ile taka baza jest szybsza od np. bazy MySQL ? Odpowiedź może być zaskakująca - kilkaset-kilka tysięcy razy szybsza (!). Zachęcam do zapoznania się z wynikami testów wydajnościowych na stronie projektu (czytając go trzeba mieć na względzie, że testy te dotyczą tylko prostych zapytań, nie ma np. porównania z testami na SQLu wykorzystującymi złączenia, procedury, widoki itp.).

Nieco "ulepszoną" wersją dla Prevayler jest db4objects - baza, która potrafi już bezpośrednio operować na plikach (oczywiście kosztem wydajności). Projekt ten posiada 2 licencje: GPL i komercyjną. Gorąco zachęcam to zapoznania się z obiema technologiami, bo naprawdę warto. Sam zastanawiam się, którą z nich wybrać - prawdopodnie do prostych systemów, w których nie jest aż tak ważne "bezpieczeństwo danych" (chodzi o możliwość utraty niektórych danych w przypadku awarii) oraz ilość danych nie przekracza kilkudziesięciu MB Ramu - użyję Prevayler. W innych sytuacja db4objects może okazać się dobrym rozwiązaniem.

Na forum Java.net można przeczytać mój wątek o porównaniu ODBMS i RDBMS.

Moja recenzja Sothink SWF Decompiler MX 2005b

Na witrynie Software Developers Journal - jednego z najbardziej prestiżowych czasopism w Polsce, no i przede wszystkim jedynego czasopisma o programowaniu zamieszczono recenzję mojego autorstwa. Recenzja dotyczy programu Sothink SWF Decompiler - w skrócie, aplikacji do dekompilacji plików swf. Artykuł można przeczytać tutaj

Marna dola programisty Java cz. 1

Sytuacja w Polsce, jeśli chodzi o hosting dla webaplikacji tworzonych w Javie jest conajmniej nieciekawa. Tak najprawdę istnieje jedyna poważna firma – http://www.jhosting.pl , która jednak za swoje usługi życzy sobie bajońskie sumy (1200 złoty netto rocznie za marne konto z dzieloną wirtualną maszyną Javy!). Reszta to po prostu wielkie nieporozumienie. Co jest tego przyczyną? Zbyt duże wymagania aplikacji javowych co do ilości pamięci operacyjnej czy niedouczenie polskich administratorów? Jeśli chodzi o to ostatnie to rzeczywiście, polscy administratorzy niewiele wiedzą o Tomcacie czy JBossie. Prędzej specjalistami w tych dziedzinach są programiści Java. Sam osobiście znam kilkoro adminów, którzy na pytanie o znajomość javowych serwerów milkną i zmieniają temat. Póki co dla Polaka pozostaje zakup takiego konta zagranicą. Tam ceny są już nieco niższe, jednak nie ma tak naprawdę rozsądnych rozwiązań za sumy poniżej 500-600 złotych rocznie. Najlepszym rozwiązaniem wydawać się więc może kupno wirtualnego serwera o przyzwoitych parametrach (np. Adiungo lub FDCServers) lub ew. serwera dedykowanego.

Tymczasem sytuacja programistów PHP ma się zgoła odmiennie. Ilość firm oferujących hosting dla takich aplikacji jest ogromna - zarówno w Polsce jak i na świecie. Ofert jest tyle, że nie sposób przed zakupem zapoznać się z 1/10 tego co jest dostępne na rynku. Co więc ma zrobić Javowiec? Przenieść się na php ? Wolne żarty;) Nawet PHP 5 ze swoimi możliwościami obiektowymi w niczym nie dorówna Javie. Póki co jednak, aplikacje webowe napisane w Javie będą stosowane w intranecie i hostowane na serwerach firmowych, które tą aplikację stworzyły.

Na JDN można zobaczyć mój post na temat hostingu Java w Polsce: http://jdn.pl/node/182

Moje CV

Imię	Jacek
Nazwisko	Olszak
Telefon	********
Adres	ul. ***** */*, 02-441 Warszawa
E-mail	jacekolszak [at] gmail.com
Data urodzenia	18 august 1983
Stan cywilny	kawaler
Wykształcenie	2004 - do dziś	Wyższa Szkoła Informatyki w Łodzi (wydział zamiejscowy w Bydgoszczy)
	2003	Uniwersytet Mikołaja Kopernika, Wydział Fizyki, Astronomii i Informatyki Stosowanej
	1998 - 2003	Technikum Elektroniczne, Toruń dyplom technika w specjalnoci automatyka przemysłowa
Certyfikaty	sierpień 2006	Sun Certified Java Programmer SCJP 5.0
Doświadczenie	05.2006 - do dziś	ISolution [programista/projektant J2EE, Hibernate, Spring, JSF]
	10.2005 - 05.2006	Ramzes Sp. z o.o. [programista/projektant J2EE, EJB 3, web services, Spring, Hibernate]
	05.2004 - 10.2005	WiedzaNet Sp. z o.o. [programista Java, ActionScript 2(Flash), Toolbook, PHP]
	2003 – 2005	Praca jako freelancer – PHP, Java, SQL, Flash, DHTML
	2002 – obecnie	Praca przy projektach open source – programowanie i zarządzanie projektami
Osiągnięcia	2003	otrzymanie nagrody Dyrektora za Najlepszą Pracę Dyplomową roku 2002/03 w dziedzinie Informatyki
	1998	zajęcie 5 miejsca w wojewódzkim Konkursie Informatycznym (algorytmy)

My CV

Name	Jacek
Surname	Olszak
Phone number	********
Address	ul. ***** */*, 02-441 Warszawa
E-mail	jacekolszak [at] gmail.com
Date of birth	18 august 1983
Marital status	bachelor
Education	2004 - today	The College of Computer Science, Lodz (Division in Bydgoszcz)
	2003	Nicolaus Copernicus University, Torun Faculty of Physics, Astronomy and Informatics NCU
	1998-2003	Electronic Technical College, Toruń technical degree in industrial automatics
Certificates	august 2006	Sun Certified Java Programmer SCJP 5.0
Job experience:	05.2006 - today	ISolution [Java developer/architect - JavaServer Faces, Spring, Hibernate]
	10.2005 - 05.2006	Ramzes Sp. z o.o. [Java developer/architect - J2EE, EJB 3, web services, Hibernate, Spring]
	05.2004 - 09.2005	WiedzaNet Sp. z o.o. [Java programmer, ActionScript 2(Flash), Toolbook, PHP]
	2003 – 2005	Work as a freelancer – PHP, Java, SQL, Flash, DHTML
	2002 – today	Open Source – developing and projects leading
Achievements	2003	headmaster's price for the Best Diplom Work in Computer Science in 2002/03
	1998	fifth place in Computer Science Provincial Contest (algorithms)

My skills

	Java Skills: 9/10 JSE 5.0 - [scjp 5.0] (oop, eclipse, junit, maven, ant, aop (jboss aop, spring aop), rmi, io, net, jakarta commons, xml, xmlbeans, swt, jface, swing, basics of eclipse plugins making), JEE (javaserver faces, servlets, jsp, struts, spring, ejb 3.0, hibernate 3, web services - xfire, jdbc, velocity), JME (basics)
	ActionScript 2.0 (Flash) Skills: 9/10 object oriented programming, AS2Lib (collections, unit tests etc.), Action Script Development Tool + Flashout, Flash MX 2004 Professional
	PHP Skills: 9/10 PHP 4, PHP 5 (object oriented programming), Smarty, phpunit, systems (Mambo, MediaWiki,PhpBB, ezPublish etc.)
	Ruby Skills: 6/10 (eclipse rdt, oop, io, drb, rinda, webrick, threads, xml, unit tests)
	Ruby on Rails Skills: 6/10 (Active Record, Action View, AJAX techniques, Action Controller, lighttpd, webrick, eclipse radrails)
	Databases Skills: 7/10 relational databases (MySQL, PostgreSQL, HSQLDb), o/r mapping tools for Java and PHP (EJB 3 persistance, JDO, Propel), Berkeley DB, db4o, Prevayler
	Linux Skills: 5/10 Daily use - desktop linux (os: Mandrake, Aurox, RedHat), www servers - Apache 2, Tomcat 5, Lighttpd
	Object Oriented Programming Skills: 7/10 design patterns, UML
	HTML, JavaScript (DHTML), CSS Skills: 9/10 XHTML, CSS 2.0, web applications/websites gui making
	Toolbook Skills: 7/10
	XML Skills: 7/10 XML APIs for Java, PHP, ActionScript, XML Schema, DTD
	Other technologies C, Eclipse, CVS, Subversion, Microsoft Office, Open Office, JEdit, Dreamweaver MX, Pajączek, Quanta, Photoshop, ImageReady CS, Gimp, Windows XP,98,Me
	Native languages polish - Skills: 8/10 english - Skills: 5/10