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