Ruby 1.9.1 i Rails 2.3.0 – małe wskazówki
Opublikował siefca
Wczoraj wieczorem zdecydowałem się trochę pocierpieć. Masochistycznego stymulanta nie trzeba było daleko szukać, bo ostatnimi czasy zainteresowałem się nowym wydaniem interpretera języka Ruby. Nie byłoby w tym nic nadzwyczajnego, gdyby nie fakt, że sam twórca języka określił tę linię jako stabilną i gotową do zastosowań produkcyjnych. Przez ponad tydzień zapoznawałem się ze zmianami w Ruby 1.9, a pomagał mi w tym Radarek, który bloguje. Przy okazji popełniłem trzy artykuły, z których pierwszy i drugi ukazały się już na łamach heise Open Source. Trzeci jest już zatwierdzony i w przyszłym tygodniu będzie opublikowany.
Najpierw sporządziłem listę potrzebnych gemów i poczytałem trochę o tym, która wersja RoR będzie kompatybilna z nowym Rubym. Padło na wydanie RC oznaczone numerem 2.3.0. Ponaglany obsesją zdążyłem przekonać się w międzyczasie, że wydanie 2.2.2 nie zadziała. W tym wpisie postaram się notować, co robię, żeby cały ten rozklekotany zestaw jakoś uruchomić, bo zdążyłem zauważyć, że nazwanie wersji 1.9.1 produkcyjną jest sporym nieporozumieniem, chyba, że mamy na myśli wykorzystywanie języka w celach edukacyjnych. Zmieniło się kilka podstawowych funkcji, z których korzystają pakiety dodające własne rozszerzenia pisane w języku C, więc większość z fajnych zabawek dostępnych w gemach po prostu nie współpracuje z Rubym 1.9.1.
Poniżej sposoby, których używałem, żeby zainstalować potrzebne rzeczy.
Ruby 1.9.1
apt-get install libmysqlclient15-dev sqlite3 sqlite libsqlite3-dev libsqlite0-dev wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.gz tar xvzf ruby-1.9.1-p0.tar.gz cd ./ruby-1.9.1-p0 CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" export CFLAGS ./configure --prefix=/usr/local/ruby19 --enable-pthread \ --enable-shared --enable-install-doc make make install
mysql-ruby 2.8.1
wget http://rubyforge.org/frs/download.php/51087/mysql-ruby-2.8.1.tar.gz tar xvzf mysql-ruby-2.8.1.tar.gz cd ./mysql-ruby-2.8.1 ruby extconf.rb make make install
W przypadku Mac OS-a X i MySQL zainstalowanego finkiem:
wget http://rubyforge.org/frs/download.php/51087/mysql-ruby-2.8.1.tar.gz tar xvzf mysql-ruby-2.8.1.tar.gz cd ./mysql-ruby-2.8.1 ruby extconf.rb --with-mysql-dir=/sw/bin/mysql \ --with-mysql-include=/sw/include/mysql \ --with-mysql-lib=/sw/lib/mysql \ --with-mysql-config=/sw/bin/mysql_config make make install
Thin
cd /usr/bin ln -s /usr/local/ruby19/bin/ruby ./ruby19 ln -s /usr/local/ruby19/bin/gem ./gem19 ln -s /usr/local/ruby19/bin/rake ./rake PATH="/usr/local/ruby19/bin:$PATH" export PATH gem install rack gem install eventmachine git clone git://github.com/macournoyer/thin.git cd ./thin rake install || cd pkg && gem install ./thin-*.gem --no-rdoc
Hpricot
gem install why-hpricot --source http://gems.github.com
Rails 2.3.0
gem install rails --source http://gems.rubyonrails.org
Vlad 1.2.0
gem install open4 gem install siefca-vlad --source http://gems.github.com
wykop
osnews
stumble upon
del.icio.us
digg
Czytam twoje artykuły na temat Ruby i bardzo się zainteresowałem tym językiem. Tylko teraz stoję w miejscu, bo mam już mętlik w głowie czy uczyć się Pythona czy może Ruby. Próbowałeś Pythona?Jeżeli tak to zapewne wybierając Ruby musiało Ci coś nie pasować w Pythonie:). Mógłbym wiedzieć co to było?Jak jest z szybkością Ruby/Rails?Cały czas są daleko od Pythona?
Python i Ruby są podobne. Niestety w Pythonie programowałem w sumie przez 3–4 tygodnie, więc po prostu zapoznałem się z językiem nie odkrywając w pełni jego możliwości. W stosunku do Ruby’ego denerwowała mnie w nim częstotliwość z jaką musiałem używać odwołania do obiektu bieżącego (self).
Wydajność nie ma dla mnie tak wielkiego znaczenia, bo pisałem w ANSI C, bardzo wydajnym języku, ale patrząc z perspektywy czasu, to mi się nie opłacało. Dlaczego? Bo zamiast robić coś ciekawego korespondowałem z autorami programów, które poprawiałem i dyskutowałem podwójne void-pointery czy debuggowałem dlaczego od godziny robi mi się segfault. Więc, gdyby wydajność była dla mnie bardzo ważna, to bym pisał w C, ale wtedy nie miał bym czasu na nic innego. Stąd, jako istota wyposażona w mechanizm zwany generalizacją wytworzyłem sobie pomocniczy wzorzec pt. “nie przejmuj się wydajnością, bo i tak za parę lat to wszystko będzie się wykonywało na kilkukrotnie szybszym sprzęcie”.
Gdybym miał robić serwis oparty o jakiś dynamiczny język, to o wydajności bym pomyślał. Przy czym dużo zależy tu od architektury. Na przykład Ruby nie ma jeszcze pełnej i wygodnej wątkowości, ale nic nie przeszkadza uruchomić kilka wątków na przykład Thina i gadać do nich z Nginxa. Będzie to pewnie wydajniejsze niż FCGI czy nawet mod_passenger.
Tutaj jest próba zmierzenia wydajności samego języka i porównania z Pythonem, która już może być nieaktualna, bo pojawiają się co rusz nowe maszyny wirtualne i mechanizmy JIT; na przykład LLVM dla CPythona a także dla MacRuby’ego. To będzie się jeszcze rozwijało, bo nad wydajnością tych języków ludzie tak intensywnie wcześniej nie pracowali. W przypadku Railsów z kolei ma być mała rewolucja w postaci włączenia całego rdzenia z projektu Merb, który jest oszczędniejszy i szybszy.
Po kilku miesiącach zabawy z Rubym zauważyłem, że lepiej rozumiem też przykłady pisane w Pythonie. Dlatego napisałem na początku, że te języki są podobne. Nie mam więc takiego dylematu, że “obrałem złą drogę” – języki te mają tyle wspólnych założeń, że nie czuję, abym się oddalał od możliwości nauczenia się Pythona, a wręcz przeciwnie. Problemem z czasem może być za to konkretny framework do Weba, bo tam nie chodzi już o podejście, ale o zapamiętywanie pewnych wzorców, których potem się używa.
O wyborze Ruby’ego zdecydowało też u mnie community, szczególnie szacunek do swojej pracy i swojego czasu. Zaimponowały mi przykłady firm, w których w związku ze skróceniem czasu potrzebnego na wykonanie projektu skraca się liczbę dni, które trzeba w tygodniu przepracować, a nie bierze się nowych zadań, żeby wypełnić czas wolny.