Ostatnimi czasy, ulegając modnym trendom, zaczęło mnie kusić by przejść z PHP na Ruby on Rails. Czy ktoś z Was miał już doświadczenia "migracyjne", czy jest zadowolony z tego języka i jego narzędzi na tyle, by uznać że zainwestowany w naukę czas był tego wart?

Gdybym przeczytał to pytanie pół roku temu, to nie wahałbym się i odpowiedział, że trzeba bezzwłocznie uczyć się Rubiego i związanej z nim technologii Ruby on Rails. Swego czasu spłodziłem nawet nieco przydługawą opowiastkę o wyższości Rubiego nad wszystkimi innymi językami

Moje uwielbienie dla tego języka bynajmniej nie minęło i od jakiegoś czasu piszę dla niego tutorial. Tym niemniej jeśli ktoś świetnie zna php i bardzo dobrze czuje się w tym języku, to ze względu na to, że powstał jakiś port Ruby on Rails na php, to nauka tego frameworku i języka nie jest koniecznością.

Z drugiej jednak strony - jeśli ktoś jest właśnie znudzony phpem, to Ruby i platforma Rails będą dla niego na pewno nie lada przygodą. Tak było właśnie w moim przypadku - w pewnym momencie myślałem aby całkowicie porzucić programowanie serwisów internetowych. Odkrycie Ruby on Rails spowodowało jednak, że znowu to polubiłem.

Jeśli chodzi o porównanie różnych języków i platform, to polecam wpis na blogu Jarka Zabiełły.
Jak każda opinia - ta pewnie też jest trochę stronnicza, ale trzeba przyznać, że autor świetnie orientuje się nie tylko w Rubim, ale również Pythonie, php, Javie, etc. Poza samym wpisem bardzo interesujące są komentarze, które się pod nim pojawiają.

Jeśli ktoś uzna, że Ruby on Rails go interesuje to polecam forum, na którym można znaleźć sporo interesujących materiałów.

Dzięki za fajny komentarz. Mnie nurtuje taka kwestia: po co jest Ruby? Albo to samo pytanie inaczej zadane: jakie są poważne przewagi Ruby'ego nad PHP?

W tym poście, który cytujesz jest link www.apohllo.pl/dydaktyka/ruby/intro/wstep tylko najwyraźniej jest on dosyć słabo widoczny (przydałoby się trochę lepiej wyróżniać linki )
W skrócie mogę jednak napisać co w Ruby jest lepszego niż w php:
1. Pełna obiektowość - to nie jest dodatek, który pojawił się w jednej z wersji Rubiego. On był od początku projektowany jako język obiektowy. Dlatego wszystkie struktury danych, nawet liczby są obiektami. Zatem możesz napisać [1,2,3,4].length bo tablica jest najnormalniejszym obiektem.
2. Otwartość klas wbudowanych - w dowolnym miejscu możesz zmodyfikować wcześniej zdefiniowaną klasę. Dotyczy to również klas wbudowanych. Cecha ta jest potencjalnie niebezpieczna, ale potrafi fantastycznie poprawić czytelność kodu. Np. framework Rails rozszerza klasę Fixnum (małe liczby całkowite) o pewne metody np. związane z czasem. Możesz np. zapisać 5.minutes.ago i oczywiście dostaniesz obiekt typu Datetime ustawiony na czas przed pięcioma minutami.
3. Bloki kodu - bardzo łatwo możesz przekazywać do metod nie tylko parametry ale również pewne bloki kodu, które mają być w nich wywołane. Bloki ujmuje się w nawiasy klamrowe. Większość klas wbudowanych obsługuje bloki kodu, co pozwala pisać naprawdę zwięzły kod. Np. klasa Array posiada metode reject, która akceptuje blok kodu, a działa w ten sposób, że usuwa z tablicy te elementy, dla których blok zwrócił wartość true. Aby np. usunąć liczby parzyste z jakiejś tablicy, wystarczy zapisać: [1,2,3,4,5,6].reject{|i| i % 2 == 0}
4. Metaprogramowanie - zachowanie klas a nawet pojedynczych obiektów może być modyfikowane w locie. Poza tym masz dostęp do informacji o metodach i atrybutach danej klasy.
5. method_missing - pozwala obsłużyć sytuacje, w których dla obiektu wywołana jest metoda, która nie była zdefiniowana w jego klasie. Zamiast rzucać wyjątek, można przechwycić to wywołanie i np. zrobić coś sensownego na podstawie samej nazwy metody. Tak np. w Railsach działa ActiveRecord - możesz wywołać metodę powiedzmy Book.find_by_title("Imię róży"), chociaż nigdzie nie jest zdefiniowana metoda find_by_title! Na podstawie jej nazwy tworzone jest odpowiednie zapytanie SQL z warunkiem WHERE title = 'Imię róży'.

Pewnie można znaleźć coś jeszcze, ale te rzeczy zrobiły na mnie na początku największe wrażenie. Przyznaję, że nie znam obecnych możliwości php, ale wątpię by były w nim dostępne podobne mechanizmy.

Uwaga końcowa - kod napisany w Ruby jest po prostu bardzo, bardzo czytelny, nawet jeśli nie do końca wiemy co ktoś chciał osiągnąć za jego pomocą.

W zasadzie te dwie rzeczy mnie zaciekawily. W porownianiu do pythona klas bazowe sa zdefiniowane i mozna z nich dziedziczyc, ale nie mozna dodawac o tej samej nazwie czego. Chyba, ze to zrobimy troche sztucznie.
Druga rzecz ma troche wspolnego z programowaniem funkcyjnym dobry bajer coraz czesciej wiele sposobow programowania sie laczy podoba mi sie to. w pythonie w zasadzie by bylo ciut dluzej, aby to zapisac. bardzo przypomina mi to sposob z matlab'a.

1) php5 wspiera obiektowsc na wystraczajacym poziomie problem jest tylko brak namespacow.
2) no mozna to rozwiazac na zasadzie fabryki obiektow, ale nie do wbudowanych typow...
3) nie
4) to chyba juz kazdy skryptowy ma no i nawet java(choc ciut mniejsz mozliwosci)...
5) php posiada

Co do tego, że Java nie posiada metaprogramowanie to jestem pewien. W tym języku dostępna jest tylko refleksja, a to zdecydowanie nie wszystko co rozumiem pod tym pojęciem. Java pozwala co najwyżej pooglądać sobie jakąś klasę w runtimie i wywołać tę czy inną metodę. Natomiast w Ruby możemy do klasy dodać metodę w runtimie. Nie tylko do klasy, ale również do pojedynczego obiektu!

W ten sposób w Railsach załatwiona jest sprawa mapowania obiektowo-relacyjnego. Wywołanie w klasie powidzmy Book < ActiveRecord::Base metody belongs_to :author powoduje dynamiczne dodanie pewnych metod do tej klasy. Coś takiego jest nie do zrobienia w Javie.

Nie wiem jak dokładnie wygląda sprawa w php. Wiem natomiast, że w Rubim metaprogramowanie niewiele różni się od zwykłego programowania obiektowego, o czym mogłem się niedawno przekonać pisząc prototyp bardzo specyficznego systemu mapowania obiektowo-relacyjnego. Niestety potem musiałem przepisać to na Javę, co było lekko koszmarne. Otrzymałem jakieś 3 razy więcej kodu

Wbrew pozorom ten sposob jest dosc dobry bo dzieki odpowiedniemu mapowaniu jestesmy w stanie zasymulowac to, kiedy oczywiscie to bedzie 4 razy wiecej kodu niz w przypadku skryptowych, ale da rade.
Co do drugiej czesc to zupelnie nie jest mozliwe, ale to jest z wiadomych przyczyn to nie jest jezyk dynamiczny.
zobacz na prostym przykladzie jestli dodamy metody call przyjmujaca stringa i dane mozemy dosc sporo zadzialac....

Wszystkich zainteresowanych migracją z php na Ruby (on Rails) zapraszam na najbliższe spotkanie Krakow Ruby Users Group, które odbędzie się 22 stycznia o 19.00 w Starej Piekarni (Kraków, ul. Dwernickiego 5). Jedna z prelekcji będzie dotyczyła właśnie migracji portalu kina.krakow.pl z php na Ruby on Rails.

Więcej informacji na stronie www.ruby.org.pl