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.