Kończenie pracy magisterskiej ma jedną poważną wadę - monotonię. Przez ostatnie dwa miesiące nie robiłem nic innego jak próbowałem zakończyć prace nad programem, co wciąż czynie mimo, że termin zbliża się nieubłaganie ku końcowi. Ból jest taki, że nie robi się nic innego, tylko tą pracę magisterską i taka stagnacja i marazm mogą zabić.
Dlatego postanowiłem troszkę rozerwać mój umysł czymś innym i w wolnych chwilach zacząłem przyglądać się językowi Ruby oraz framework'owi Ruby on Rails. I to właśnie prostota i przejrzystość RoR ciekawiła mnie bardziej niż sam język Ruby. W niedługim czasie jednak posmakowałem jednak samego języka i zadowoleniem musze stwierdzić, że coś w Rubym jest jednak takiego nienazwanego, że odczuwa się pewną lekkość i przyjemność w klepaniu kodu.
Jakiś czas temu pojawiła się na horyzoncie implementacja Ruby'iego napisana całkowicie w Javie. JRuby, bo o nim właśnie mowa, to produkt open source, ale powstał pod skrzydłami Sun Microsystems. Ktoś może się zastanawiać czy na prawdę potrzebujemy warstwy pośredniej w postaci maszyny wirtualnej, aby pisać aplikacje w Ruby'm? Oczywiście odpowiedź brzmi nie, nie potrzebujemy. Wykonanie programu typu przeiteruj się po kolekcji, wykonaj na elementach jakieś obliczenia, zwróć wynik, wykona się zdecydowanie szybciej w standardowym ruby niż w jruby, gdyż do tego typu zadań został stworzony właśnie interpreter ruby'ego.
Problem zaczyna się, gdy chcemy ruszyć coś większego, używając choćby Ruby on Rails jako frameworka do pisania aplikacji webowych. Jeśli czytaliście kiedyś rozmowy o Ruby on Rails, powtarzającym się bez końca tematem jest skalowalność aplikacji napisanych w frameworku. Problem wydaje się rzeka, ale z drugiej strony trudno się dziwić. Jeśli ktoś chce napisać taki powiedzmy nowej generacji serwis społecznościowy, kwestia wydajności przy dużym obciążeniu serwisu wydaje się problemem istotnym. Wtedy właśnie z pomocą może nam przyjść JRuby. Ponieważ implementacja napisana jest w 100% w Javie, możemy nasze aplikacje railsowe odpalać na serwerach aplikacji, które dotąd przeznaczone były dla rozwiązań JEE5. A te z kolei znane są właśnie ze skalowalności, o która tak bardzo drży świat enterprise. Ogólne założenie jest takie jak na rysunku poniżej
Rozwiązanie logiczne i co więcej sprawdza się na tyle, że przewiduje się, że w niedalekiej przyszłości w świecie RoR, JRuby będzie wiódł prym, powoli wygryzając rozwiązania serwerowe pure-ruby takie Mongrel. Czy będzie tak w rzeczywistości trudno powiedzieć, myślę, że sprawa jest jeszcze świeża. Jeśli jednak dołożymy do całości takie smakołyki jak możliwość zamykania logiki biznesowej w javowe obiekty EJB, które wywoływać można (zdalnie i lokalnie) z poziomu kodu ruby'ego, tworzy nam się całkiem ciekawe rozwiązanie.
O JRuby'm można poczytać na blogu Wiktora Gworka, który chyba na poważnie zajął się ewangelizacją języka. Jeśli starczy mu zapału stworzy nam niedługo cykl, będący wstępem do JRubiego, jak narazie, można poczytać pierwszy odcinek.
Jeśli tematyka kogoś interesuje, a angielski mu nie straszny, warto zajrzeć również tu, tu i tu.
No i to tyle na dziś. Wracam do pracy magisterskiej, zostało tylko 25 dni...
update: jak w prosty sposób zainstalować wsparcie dla JRuby na Glassfishu opisałem tutaj
niedziela, 4 maja 2008
Po co nam JRuby?
Tagi:
glassfish,
jruby,
ruby,
ruby on rails
Subskrybuj:
Komentarze do posta (Atom)
2 komentarze:
http://www.scala-lang.org/
http://demo.liftweb.net/lift/
IMHO zabójca javy, jruby, jythona i innych języków na JVM jak na teraz i przynajmniej niedaleką przyszłość (conajmniej kilka lat).
"...powoli wygryzając rozwiązania serwerowe pure-ruby takie Mongrel."
O ile wiem to Mongrel nie jest pure-ruby. Ma rozszerzenia w C i Javie.
http://mongrel.rubyforge.org/wiki/FAQ#Q:HowisMongreldesigned
http://mongrel.rubyforge.org/browser/trunk/ext
W czystym Ruby jest napisany Webbrick. Serewery Thin i szczególnie Ebb są w dużym stopniu napisane w C.
Prześlij komentarz