Jarosław Zabiełło - BLOG: Tag python

Passenger bliżej - Rails, Rack i WSGI

Jarosław Zabiełło — Sat, 07 Jun 2008 15:24:00 +0200

Stworzony pierwotnie na użytek Rails, aktualnie mod_passenger już obsługuje nie tylko Rails ale także masę innych frameworków używających Rack’a. W nowej dokumentacji wymienione są frameworki: Camping, Halcyon, Mack, Merb, Ramaze i Sinatra. W dokumentacji nie wymieniono jeszcze “drugiej listy”, zawierającej frameworki korzystające z WSGI i Pythona (np. Pylons, Django, TurboGears itp.). Chcąc sprawdzić plotki wokół tej sprawy, sprawdziłem, czy faktycznie mod_passenger pracuje nie tylko z Ruby, ale także z Pythonem. Sprawdziłem także jak to jest faktycznie z obługą Rails i frameworków na Rack’u (tu sprawdziłem tylko Merba). Sprawdziłem też JRuby dla Rails i Merba.

Wszystkie testy były wykonywane na laptopie MacBook Pro Core 2 Duo, 2.16GHZ, 4GB RAM (OSX 10.5.3 dla tego modelu widzi tylko 3GB) i dyskiem 200GB kręcącym się z szybkością 7200 rpm. Ruby 1.8.6, Python 2.5.2, Apache 2.2.8 (mpm-prefork) były instalowane z MacPortów. Passenger, mimo że instalowany ze źródeł w Apache’u był wyświetlany jako “Phusion_Passenger/1.1.0” (być może więc to nie jest jeszcze ta nowa wersja 2.0 o której pisałem wcześniej) Nie sprawdzałem Linuksa, być może wyniki i wnioski będą wtedy inne.

Dla tych co chcieliby sami popróbować podaję wpierw konfigurację serwerów wirtualnych dla Apache’a potrafiącą unieść razem: PHP (2.5.6), Rails (2.1), Merb (0.9.4 edge), i Django (edge).

Konfiguracja Apache’a 2.2.8


# Ruby (Rails):
<VirtualHost *:80>     
  DocumentRoot "/opt/local/apache2/vhosts/rails_app/public"  
  ServerName rails_app
</VirtualHost>

# Ruby (Merb):        
<VirtualHost *:80>  
  RailsAutoDetect off  
  DocumentRoot "/opt/local/apache2/vhosts/merb_app/public"    
  ServerName merb_app       
</VirtualHost>

# Python (WSGI):
<VirtualHost *:80>          
  DocumentRoot "/opt/local/apache2/vhosts/wsgi_app/public"    
  ServerName wsgi_app
</VirtualHost>      

# Django (mod_python)
<VirtualHost *:80>         
  DocumentRoot "/opt/local/apache2/vhosts/djangus/public"    
  ServerName django_modpython 
  <Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE djangus.settings
    PythonDebug On        
    PythonPath "['/opt/local/apache2/vhosts'] + sys.path"    
  </Location>       
</VirtualHost>   

# PHP:
<VirtualHost *:80>  
  RailsAutoDetect off  
  DocumentRoot "/opt/local/apache2/vhosts/php_app/public"        
  ServerName php_app   
</VirtualHost>

Wszystkie aplikacje korzystające z mod_passengera muszą posiadać folder public i tmp. Gdy do katalogu tmp dorzucimy jakikolwiek (może być pusty) plik o nazwie restart.txt, to przy następnym przeładowaniu przeglądarki nastąpi restart aplikacji.

We wszystkich przypadkach użyłem dosyć banalnego kodu polegającego na wyświetleniu “Hello World!”. Z wyników programu ab wyciąłem nieistotne informacje.

Rails (2.1)

Rails 2.1 + mod_passenger 1.1.0

Rails obsługiwane są w Passengerze praktycznie bezobsługowo. Wystarczy wkopiować pliki na serwer i to wszystko.

ab -n 1000 -c 1 http://rails/ 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Total transferred:      582000 bytes
HTML transferred:       12000 bytes
Requests per second:    430.20 [#/sec] (mean)
Transfer rate:          244.35 [Kbytes/sec] received

ab -n 1000 -c 4 http://rails/
...
Concurrency Level:      4
Failed requests:        239
   (Connect: 0, Length: 239, Exceptions: 0)
Write errors:           0
Total transferred:      488073 bytes
HTML transferred:       9132 bytes
Requests per second:    520.75 [#/sec] (mean)
Transfer rate:          247.88 [Kbytes/sec] received

Szybkość nie jest najgorsza, ale niepokojąca jest duża lista błędnych requestów w wypadku zapytań równoległych. Jak się dalej okazuje, ten problem dotyczy także obługi Rack jak i WSGI. Albo to jakaś specyfika OSX, albo wcale nie jest tak dobrze ze stabilnością mod_passengera dla równoległych zapytań. Trzeba by było też zbadać, czy ten efekt występuje także dla Linuksa. Zdziwiłbym się gdyby tam było podobnie skoro Dreamhost już oferuje hosting z mod_rails…

Dla porównania Rails używający Mongrela, Thin oraz Ebb. Można by pokusić aby odpalić Ebb i Thina na uniksowych socketach (Ebb też to już potrafi!), ale wtedy musiałbym zestawiać klaster i uruchamiać to przez proxy. Jak ktoś chce to niech się sam pobawi. Dla prostoty użyłem portów TCP. Sprawdziłem też JRuby.

Rails 2.1 + Ebb 0.2.0

ebb_rails -e production start

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    488.95 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
..
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    533.22 [#/sec] (mean)

Szybkość większa od mod_passengera i co ważniejsze, zero jakichkolwiek błędów przy pracy równoległej.

Rails 2.1 + Thin 0.8.1

thin start -e production              

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    485.95 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...              
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    506.21 [#/sec] (mean)

Szybkość trochę mniejsza od Ebb, ale stabilność b. dobra.

Rails 2.1 + Mongrel 1.1.5

script/server -e production

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    373.74 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    360.46 [#/sec] (mean)

Stabilność bez zarzutu, wydajność jednak mniejsza od serwerów pracujących asynchronicznie.

Rails 2.1 + JRuby 1.1.2

W wypadku JRuby trzeba go trochę “rozgrzać”. Pełna wydajność Javy pojawia się po jakimś czasie pracy. Wynika to ze specyfiki i możliwośći JVM która dokonuje dynamicznych optymalizacji kodu w trakcie jego działania (z tego powodu Java potrafi przewyższyć wydajnością C++). “Dla rozgrzewki” przepuściłem Rails przez 30 tys. requestów co spowodowało że początkowych 137 req/s zrobiło się 257 req/s.

jruby script/server -e production    

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    200.48 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    257.05 [#/sec] (mean)

JRuby jest stabilny ale z wydajnością dla Rails jeszcze jest trochę do poprawienia. Dorzucenie opcji optymalizacyjnych, czyli odpalenie Rails przez

  
jruby -J-server -J-Djruby.compile.frameless=true script/server -e production

trochę poprawiło wynik: 273 req/s, ale generalnie nie jest to wielka różnica. JRuby 1.1.x już ma domyślnie powłączane optymalizacje.

Rails – wnioski

mod_passenger dla Rails faktycznie jest wydajny, choć trzeba jeszcze by zbadać dlaczego zwraca tyle błędnych requestów dla równoległych zapytań i czy ten problem występuje też na Linuksie. Dlatego na razie najwydajniejszym i najstabilniejszym rozwiązaniem dla Rails wciąż pozostaje kombinacja nginx + proxy do ebb lub thin. mod_passenger kusi głównie prostotą konfiguracji (właściwie brakiem konfiguracji). No i chyba ja to testowałem dla mod_passengera w wersji 1.1, a nie 2.0 (przynajmniej taka się wyświetla w Apache).

Merb 0.9.4 edge

Merb 0.9.4 edge + mod_passenger 1.1.0

Aby użyć frameworka Rack z Passengerem trzeba w katalogu projektu tworzyć plik config.ru zawierający konfigurację Rack’a. W wypadku Merba będzie to

require 'rubygems'
require 'merb-core'

Merb::Config.setup(:merb_root   => ".",
                   :environment => ENV['RACK_ENV'])
Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]
Merb::BootLoader.run

run Merb::Rack::Application.new

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    762.62 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        247
   (Connect: 0, Length: 247, Exceptions: 0)
Write errors:           0
Requests per second:    985.15 [#/sec] (mean)

Merb jest wciąż dużo szybszy od Rails. Podobnie jak dla Rails, wiele równoległych zapytań nie zostało poprawnie wykonanych. Na produkcyjne użycie Passengera dla Merba jest jeszcze trochę za wcześnie.

Merb 0.9.4 edge + ebb 0.2.0

merb -e production -a ebb  
...                              
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1463.69 [#/sec] (mean)

Concurrency Level:      10
Failed requests:        0
Write errors:           0
Requests per second:    1560.60 [#/sec] (mean)

Merb na Ebb deklasuje wydajnością wszystkie inne rozwiązania. Tylko czysty PHP jest w stanie mu dorównać, ale porównywanie PHP z całym, złożonym frameworkiem Rubiego jest trochę bez sensu. Z tego co mówił ostatnio (na kanale IRC) Ezra Zygmuntowicz, podpięcie Ebb na czystym Rack’u, daje nawet 7 tys req/s i deklasuje (rzekomo) szybkiego PHP. Gadanie o wyższej wydajności PHP jest po prostu głupie. Można się założyć, że jakiekolwiek porównanie frameworka naprzeciw frameworka, tj. Merba z Symfony czy Cake PHP, obnaży bezlitośnie słabości PHP tak, jak to zrobił Django w jednym ze starszych testów.

Merb 0.9.4 edge + thin 0.8.1

merb -e production -a thin 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    1147.78 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1234.82 [#/sec] (mean)

Wydajność równie dobra, choć trochę słabsza od Ebb. Sporo więcej od Rails i zero problemów ze stabilnością.

Merb 0.9.4 edge + mongrel 1.1.5

merb -e production -a mongrel
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    868.10 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    837.01 [#/sec] (mean)

Mongrel jest wolniejszy od serwerów asynchronicznych ale i tak wyraźnie szybszy od Rails.

Merb 0.9.4 edge + JRuby 1.1.2

 
jruby -S merb -e production 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    449.52 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    505.52 [#/sec] (mean)

Merb na “rozgrzanym” (30 tys. req) JRuby osiąga wydajność taką jak najszybsze rozwiązania dla Rails z użyciem asynchronicznego Ebb! To znaczy, że użycie produkcyjne Merba w systemach Javy ma jak najbardziej sens.

Passenger & WSGI

Pora na przyjrzenie się temu jak mod_passenger daje sobie radę z Pythonem. W katalogu ze źródłami Passengera leży gotowa, prosta aplikacja WSGI. Dzieki dobrej dokumentacji Django, udało mi się uruchomić ten framework pod Passengerem. Gorzej było z Pylons. Nie udało mi się stworzyć poprawnego pliku passenger_wsgi.py, niezbędnego do tego aby Passenger uruchomił aplikację WSGI.

Django edge

Django, mimo swych zalet, stosuje bardzo głupią politykę nie wypuszczania kolejnych wersji kodu. Dostępna na stronie wersa 0.96 jest stara i generalnie zaleca się aby używać nowszą wersję, która istnieje tylko w repozytorium Subversion. Oparcie kodu produkcyjnego o wersję edge jest trochę ryzykowne i szybko sprowadza się do złej praktyki ciągłego łatania kodu.

W wypadku Django plik passenger_wsgi.py zawiera kod:

import os, sys
sys.path.append('/bezwl/sciezka/do/nazwaprojektu') 
os.environ['DJANGO_SETTINGS_MODULE'] = 'nazwaprojektu.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

  ab -n 10000 -c 10            
  ...   
  apr_poll: The timeout specified has expired (70007)

Test padł po 9tys requestach. Dalej nie można było uruchomić Django. Dopiero restart calego Apache’a pomógł. Dla niższej ilości równoległych zapytań (ab -n 1000 -c 4) Django nie padło, ale było dużo błędnych requestów. Okazało się, że problem wynikał z równoczesnej obecności modułu mod_python i mod_passenger. Nie można ich razem włączać.

Usunięcie mod_passengera i zostawienie samego mod_pythona pomogło. (Albo jest jakiś konflikt między nimi, albo (co bardziej jest prawdopodobne) trzeba poczekać na opcję wyłączającą passengera dla serwera wirtualnego używającego mod_pythona. Dla Rails i Rack są takie opcje (RailsAutoDetect, RackAutoDetect), dla WSGI nie mogłem nic takiego znaleźć w kodzie źródłowym. Modułu mod_wsgi nie sprawdzałem, bo nie było go dostępnego w portach OSX.)

Po zablokowaniu mod_passenger’a tym razem mod_python nie zwracał żadnego błędnego requestu.

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    934.87 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1240.26 [#/sec] (mean)

Nie jest źle. Django jest tu wyraźnie szybsze od Rails (co nikogo nie dziwi), ale jest wolniejsze od Merba, co dla miłośników Pythona może być przykrą niespodzianką. Większość krytyki Rubiego oparta jest na krytyce (słabszej) wydajności Railsów. Okazuje się, że winny nie jest Ruby, ale słabo zoptymalizowany Rails. Merb jest dowodem na to, że można napisać w Rubim framework, który nie tylko będzie partnerem dla rozwiązan Pythona, ale nawet potrafi je przewyższać wydajnościowo.

Zobaczmy jak wypadnie mod_passenger.

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    904.60 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        240
   (Connect: 0, Length: 240, Exceptions: 0)
Write errors:           0
Requests per second:    497.51 [#/sec] (mean)

W pracy jednoprocesowej nie można mieć zastrzeżeń. Szybkość jest niezła. Niestety praca równoległa to porażka. Dużo requestów nie zostało obsłużonych. Gorzej, za drugim razem (tylko dla 4 rownoległych zapytań) Django kompletnie się załamało i zwróciło wyjątek “apr_poll: The timeout specified has expired (70007)”. Nie można było go dłużej używać. Wymagany był restart Apache’a.

Aby sprawdzić czy to tylko problem Django czy ogólnie implementacji WSGI dla mod_passengera, uruchomiłem test na prostej aplikacji WSGI. Niestety sytuacja jest ta sama.

Wniosek: mod_passenger dla Pythona wymaga dopracowania pracy równoległej. Jeszcze za wcześnie aby go używać z Pythonem. Ale z drugiej strony uruchomiłem mod_passengera z WSGI trochę przedwcześnie. Nie ma przecież w manualu ani jednego zdania o tym, że Passenger działa z WSGI. Oparłem się tylko na pogłoskach i wygrzebałem tą opcję ze źródeł. Więc jeszcze wszystko może się tu zmienić. To samo dotyczy Rack’a. Twórcy muszą przyjrzeć się problemom związanym z obsługą równoległych zapytań.

Update

Jednak dobrze się domyślałem, Apache nie oszukiwał. W tekście testowałem starszego Passengera 1.1. Także nie był to Ruby Enterprise. NOWY Passenger 2.0RC1 oraz Ruby Enterprise został dopiero niedawno opublikowany. Co ciekawe, dodano obsługę Apache MPM Worker a nie MPM Prefork, co dodatkowo zmniejsza zużycie pamięci. Niestety Passenger 2.0RC1 jest na razie dostępny tylko w wersji na Linuksa.

Sprzątanie po PHP czyli Passenger 2.0 i Ruby Enterprise 1.0

Jarosław Zabiełło — Wed, 04 Jun 2008 01:40:00 +0200

Stało się! Twórcy świetnego modułu Apache’a – mod_rails – zmieniają jego nazwę na mod_passenger, bo mod_rails nie jest już więcej modułem tylko dla Rails. W nowej wersji 2.0 (ktora ma wyjść na dniach) dodano pełne wsparcie dla Rack i tym samym mod_passenger 2.0 obsługuje wszystkie pozostałe frameworki używające Rack’a (ze świetnym Merbem włącznie).

Drugim, ciekawym projektem firmy Phusion jest Ruby Enterprise (wersja 1.0 ma być dostępna lada dzień razem z Passenger 2.0). Jest to podrasowana wersja interpretera Rubiego (MRI) powodująca nie tylko przyśpieszenie ale także znaczne zmniejszenie zużycia pamięci RAM (dodano technikę copy-on-write do garbage collectora interpretera MRI, dokładniej opisano to na slajdach). Wg tego co twierdzą ludzie z Phusion, uzyskano zmniejszenie o 33% zużycia pamięci przez Rails. To bardzo dobra wiadomość, bo pamięć mimo, że jest generalnie tania, nie jest tania w ofertach hostingowych VPS.

Passenger wprowadza nową jakość dla frameworków Rubiego. Coraz więcej firm hostingowych to docenia i przechodzi na Passenger’a (z tych bardziej znanych, Dreamhost już tego używa). Sam moduł mod_passenger jest nie tylko trywialny w użyciu, jest też bardzo szybki i stabilny. Chyba nadchodzą ciężkie chwile dla tych, co trzymali się PHP głównie z powodu jego taniego hostingu i prostoty uruchomiania serwerze. Rails i Merb mogą wkrótce trochę pozamiatać po PHP. :)

Szybkość mod_passenger’a robi wrażenie. Bije wydajnością kombinację Nginx + asynchroniczny Thin używający szybkich, uniksowych socketów. Jest też szybszy od komercyjnego Litespeed’a.

Co ciekawe, mod_passenger obsługuje interfejs WSGI do Pythona! Jeden moduł pozwoli więc na odpalanie Rails, Merb’a i Django równocześnie. Mało tego, jeśli mod_passenger dla Pythona będzie działał tak sprawnie jak dla Rails, to będziemy mieć trywialne przeładowywanie aplikacji Django bez konieczności restartu całego Apache’a.

Vide:

The Holy Grail for Rails Deployment

28 mod_rails / Passenger Resources To Help You Deploy Rails Applications Faster

Passenger 2.0 na GitHub.com dla tych, co chcą już teraz zainstalować mod_passenger 2.0 (ja już to zainstalowałem)

Update

2008-06-25

Phusion Passenger 2.0 and Ruby Enterprise Edition from Carl Youngblood on Vimeo

Ruby Enterprise Edition 32bit na debianie etch 64bit?

Google App Engine

Jarosław Zabiełło — Sun, 13 Apr 2008 21:12:00 +0200

Od niedawna Google oferuje dosyć atrakcyjną możliwość pisania aplikacji webowych wykorzystujących potęgę ich infrastruktury – Google App Engine. Usługa jest darmowa i jeszcze testowa. Można stworzyć do 3 aplikacji z których każda może używać do 500MB danych trzymanych w BigTable i Google obiecuje że bez problemu będzie można uzyskać do 5 mln odsłon miesięcznie i niezły traffic 10 TB/m-c.

W tej chwili jedynym językiem dostępnym jest Python ale mają przybyć kolejne. Wykorzystywany jest WSGI. Dostępny jest też okrojony framework Django (nie można używać djangowego ORM’a ani wszystkich możliwości jakie dają djangowe szablony).

To co się bardzo zmienia, to podejście do bazy danych. Baza kolumnowa BigTable nie jest bazą relacyjną (nie istnieje tam pojęcie joinów). Trzeba więc trochę inaczej przemyśleć sposób tworzenia swoich danych. Pewnym problemem może być nie tylko uzależnienie od infrastruktury Google ale też trudność z późniejszym przeniesienia tak składowanych danych na inną platformę (choć istnieje z drugiej strony open-source’owy odpowiednik BigTable – HBase). W zamian jednak użycie platformy Google daje bardzo wysoką wydajność i odporność na błędy (jak padnie jeden serwer to jego pracę przejmuje automatycznie inny). Trochę nie jest dla mnie jeszcze jasne jak składować i usuwać dane z plikami statycznymi (obrazki, style kaskadowe, flash itp) skoro Google nie daje dostępu do systemu plików. Zablokowane są też sockety, wątki, używanie modułów napisanych w C, możliwość odpalania podprocesów, możliwości używania innych baz niż BigTable.

Git, Bazaar, Mercurial - Subversion pod obstrzałem

Jarosław Zabiełło — Wed, 19 Mar 2008 12:00:00 +0100

Świat technologii IT zmienia się coraz szybciej. Nie minęło wiele lat od dosyć masowego przechodzenia CVS do Subversion a już zanosi się na kolejną rewolucję. Tak jak wcześniej atakowany był CVS, teraz atakowany jest Subversion. Atakowany jest przez rozproszone systemy kontroli wersji.

Czym jest system rozproszony (distributed)?

Subversion jest przykładem centralnego systemu wersjonowania. Zawsze mamy do czynienia z centralnym repozytorium kodu. Jakakolwiek próba ściągnięcia nowszych wersji plików wymaga posiadania połączenia z serwerem zawierającym interesujące nas repozytorum. Jakakolwiek aktualizacja zmian w repozytorum wymaga znowu połączenia się z centralnym repozytorium. Systemy rozproszone działają zupełnie inaczej.

Po pierwsze, nie posiadają żadnego centralnego repozytorium. Ściągnięcie projektu polega na sklonowaniu danego repozytorium na dysku lokalnym. Wszelkie lokalnie dokonywane zmiany należy dodawać do swojego, lokalnego repozytorium. Nie jest potrzebne posiadanie aktywnego połączenia z internetem. Co w wypadku, kiedy pierwotne repozytorium się zmieniło i chcemy zaktualizować swoje? Nic trudnego.

Drugą, potężną różnicą w stosunku do Subversion jest łatwość z jaką w systemie rozproszonym scala się dowolne odgałęzienia (branches) kodu. Subversion jest bardzo tu kiepskie. System rozproszony pozwala zatem posiadać najnowszą wersję kodu oryginalnego włącznie z naszymi poprawkami. Jeśli chcemy wysłać nasze zmiany do autora projektu, można to także uczynić. Jeśli autor uzna, że nasze zmiany są wartościowe i godne tego aby je dołączyć, stosuje podobny mechanizm scalania odgałęzień.

Trzecią istotną różnicą jest brak zaśmiecania projektu dziesiątkami folderów o nazwie .svn (W Subversion każdy wewnętrzny folder, aby podlegał wersjonowaniu, musi posiadać w środku taki dodatkowy folder). Systemy rozproszone zwykle tworzą jeden, jedyny folder w głównym katalogu i nie wymagają aby wszystkie wewnętrzne foldery posiadały go również.

W praktyce, porządnie prowadzone projekty używające Subversion stosują jakieś formalne reguły dodawania zmian w kodzie. Np. zabrania się “commitowania” kodu, który nie przeszedł pozytywnie wszystkich testów jednostkowych. Problem w tym, że od chwili zgrania sobie źródeł na dysk, tracimy wszelką możliwość wersjonowania naszych małych, lokalnych zmian (które niekoniecznie muszą być pozbawione błędów). Czasami chcemy się cofnąć do jakiejś wcześniejszej zmiany i nie możemy. Subversion wersjonuje tylko kod w centralnym repozytorium. System rozproszony pozwala zaś na takie śledzenie lokalnych zmian i to nawet w sposób niezależny od ściągniętego kodu z repozytorium Subversion. Niezależny, bo można trochę “oszukiwać” system używany w pracy. :) Po ściągnięciu kodu z SVN, można dodać sobie lokalnie system rozproszony i kontrolować swoją historię lokalnych zmian w sposób nieinwazyjny dla Subversion.

Git, Mercurial i Bazaar

Aktualnie, najbardziej liczące się systemy rozproszone to Git, Mercurial i Bazaar.

Git

Pierwotnie stworzony przez Linusa Torvaldsa do zarządzania kodem jądra systemu Linux, Git zaczyna dosyć przebojowo zdobywać popularność. Pomijając oczywistą wyższość systemu rozproszonego nad system centralnego repozytorium, trzeba podkreślić, że Git bardzo szybki. Niezrównanie szybszy od Subversion, szybszy też od Mercurial i Bazaar. Coraz więcej projektów zaczyna przechodzi na Git’a (np. konkurent Railsów – Merb trzyma źródła repozytorium Git’a, zobacz też “Contributing to Merb” – Part 1 i Part 2)

Także (napisany w Ruby) system do aktualizacji projektów na serwerze (deploying) – Capistrano – posiada wsparcie dla Git’a. Duża rolę w popularyzacji Git’a czynią serwisy takie jak github.com czy gitorious.org gdzie można założyć darmowe konto dla swoich projektów. A do śledzenia błędów i zgłaszania poprawek kodu trzymanego w githubie można użyć serwisu http://lighthouseapp.com.

Railscasts.com znany serwis ze dziesiątkami darmowych filmów edykacyjnych dla Railsów, dodał niedawno screencast opisujący integrację Git’a z Rails. Trochę dłuższy film na ten temat jest dostępny też w serwisie peepcode.com. Zobacz także poniższą prezentację Linusa Torvarldsa n/t GIT’a. Linus nie przebiera w słowach krytyki wobec Subversion, nazywając go po prostu głupim pomysłem. Subversion to tylko poprawiony, stary CVS. Nie wnosi jednak nic specjalnie nowego i jego koniec jest bliski. ;)

Mercurial

Mercurial, to system rozproszony napisany w Pythonie. Z definicji jest więc multiplatformowy (bieżąca implementacja Git’a dla win32 jest dosyć słaba). Zasadniczo niewiele się różni od Git’a. Jest trochę wolniejszy, nie ma (przynajmniej ja nie znam) jakichś popularnych darmowych kont do trzymania projektów. Ale jego zaletą jest wspomniana wyżej multiplatformowość (działa na win32 bardzo dobrze) oraz integracja z edytorem Netbeans 6 (jeszcze trwają prace nad integracją z Git’em). Firma Sun wybrała też Mercurial jako następcę dla Subversion. Są też mniejsze firmy które zdecydowały się na Mercurial z powodu lepszej integracji z systemem Windows, ale są gotowe przejść na szybszego Git’a jak tylko zostanie poprawiona jego wersja dla win32.

Bazaar

Bazaar, podobnie jak Mercurial, napisany został w Pythonie. Nie ma więc problemów z działaniem pod systemem innym niż POSIX. Jest to dosyć ciekawy system, bo potrafi pracować zarówno jako system centralny jak i rozproszony. Jego twórcy są mocno przekonani o wyższości Bazaar nad Git, Mercurial i Subversion, o czym świadczy zamieszczone przez nich śmiałe porównanie z tymi systemami. (Niektóre stare porównania Git’a z Bazaar podkreślały znaczną przewagę szybkości Git’a, ale niestety najczęściej dotyczyły one starej, wolniejsze wersji Bazaar. Od wersji 1.0 poprawiono jednak znacznie wydajność i ten argument trochę stępił swoje ostrze krytyki).

Bazaar posiada, podobnie jak Git, serwer z darmowymi kontami na projekty – launchpad. To może pomóc spopularyzować ten system. Bazaar ma dostępny wygodny plugin do Eclipse. Co do Netbeans 6, są jakieś plany, ale na razie nie wiadomo czy i kiedy dodadzą wsparcie.

Updates

2008-03-23

Użytkownicy OSX 10.5.2 (Leoparda) instalują Gita za pomocą MacPortów (warto dodać wariant +svn aby mieć dostęp do skrypty git-svn; warianty dostępne dla Git’a sprawdza się za pomocą komendy port variants git, a odświeżenie listy portów: sudo port -d sync).

sudo port install git-core +svn

Jeśli instalacja wywali się z powodu problemów z SQlite3, należy doinstalować gmake, czyli:

sudo su
port install gmake
port clean sqlite3
port install sqlite3
port install git-core +svn

Szalejące frameworki Rubiego i Rack/WSGI

Jarosław Zabiełło — Tue, 04 Mar 2008 22:56:00 +0100

Merb w wersji 0.9 poszedł na całość i oparli swój midleware na Rack’u. Jej twórcy nie kryją się że wzorowali się na pythonowej bibliotece WSGI. Biblioteka ta robi niezłą furorę w kręgach Rubiego. Powstaje sporo różnych mikroframeworków lub szybkich serwerów HTTP pracujących asynchronicznie i wykorzystujących Rack. Niedawno powstał świetny Thin, a już można przeczytać o 2x szybszy Ebb. Co ciekawe, Ebb chce docelowo obsługiwać zarówno frameworki Rubiego jak i Pythona! Jestem ciekaw czy będzie w stanie zdetronizować serwer Paste... Rack doczekał się już swojej implementacji w JRuby! Umożliwia to tym samym odpalanie w JRuby wszystkich frameworków które korzystają z Rack’a.

Frameworki

Rails – najważniejszy framework Rubiego, może być odpalany za pomocą Thina który używa Rack. Rails można odpalić na JRuby nawet prosto z Netbeans 6 :)
Merb – pretendent do detronizacji Rails, _używa Rack_i tym samym można go odpalić na JRuby.
Ramaze – podobnie do Merba, stara się promować bardziek elastyczne podejście, używa Rack, raczej nie zagrozi Merbowi
Fuzed – Rails z YAWS (szybkim serwerem HTTP napisanym w Erlangu)
Nitro – typu MVC z własnym ORM – Ogg i naciskiem na AJAX
IOWA – komponentowy,
Wee wzorowany na smalltalkowym Seaside używającym kontynuacji
Sinatra – mikroframework wzorowany na minimalistycznym, pythonowym Web.py
Camping – kolejny mikroframework w Ruby
Wave – wzorowany na Camping, też używa Rack i Rubiego wszędzie gdzie się da.
Invisible mikroframework używający Rack napisany w 35 linijkach kodu Rubiego (bardziej ciekawostka)

Mongrel i spółka

Webrick – serwer http dostępny razem ze standardową biblioteką Rubiego
Highperformance Webrick – szybsza wersja Webricka (używająca uniksowych forków)
Mongrel – klasyka, napisany częściowo w C, to od niego zaczęła się rewolucja i odejście od FastCGI jako metody odpalania Railsów.
Swiftyply i evented_mongrel asychroniczne, szybsze wersje Mongrela
Thin – asynchroniczny web server używający Mongrela i Rack
Ebb – używa Rack, większość kodu jest w C, dlatego jest taki szybki, na razie mało dokumentacji, być może następca Thin

Słoneczna przyszłość dla Jythona

Jarosław Zabiełło — Mon, 03 Mar 2008 17:15:00 +0100

Od czasu odejścia twórcy Jythona, Jima Hugginsa, do firmy Microsoft (do prac na IronPythonem), rozwój Jythona , (javowej implementacji Pythona) mocno zwolnił i został sporo w tyle za wychodzącymi kolejnymi wersjami CPythona. Dlatego sympatycy Pythona z pewnością się ucieszą wiadomością o tym, że firma Sun zatrudniła na pełen etat Franka Wierzbickiego, będącego głównym developerem Jythona od grudnia 2005. Jest zatem spora szansa że projekt nabierze porządnego rozpędu tak, jak to się stało z JRuby.

Od jakiegoś czasu developerzy Django także pracują nad uruchomieniem swego frameworka pod Jythonem. Niestety aktualnie Jython jest zgodny ze starym Pythonem 2.2 i z tego powodu raczej nie zanosi się aby szybko podobne działania podjęli developerzy frameworka Pylons (który wymaga do pracy minimum Pythona 2.4). Ale to wszystko może się wkrótce zmienić, skoro Jython dostał się pod skrzydła Suna.

Po wideokonferencji z Matzem

Jarosław Zabiełło — Thu, 21 Feb 2008 01:08:00 +0100

Zapowiadana wcześniej wideokonferencja z twórcą języka Ruby, została dobrze przygotowana przez Google. Obraz był wyświetlany na dużym ekranie, i co ważniejsze można było zadawać pytania prelegentowi i udało mi się nawet dwa zadać. :)

Prawdę mówiąc oczekiwałem że Matz powie coś nowego. Nic takiego nie było. Mam wrażenie że nawet slajdy jakie były wyświetlane gdzieś już wcześniej widziałem. Moim zdaniem, Matz mówi tak słabo po angielsku, że powinien mówić w swoim języku, po japońsku, i korzystać z tłumacza. Nie sądzę że byłoby wolniej, a nie trzeba by było też powtarzać po kilka razy tego samego pytania.

Zapytałem się go, czy istnieje jakaś oficjalna specyfikacja języka Ruby (lub coś podobnego do pythonowej publicznej listy proponowanych ulepszeń). Brak jednego i drugiego powoduje, że jest pewne zamieszanie co do składni jaka ma wejść do Rubiego 2.0. Tak naprawdę to nikt nie wie w jakim kierunku ta składnia podąża. Np. nie wiadomo czy wcześniej prezentowane przez Matza slajdy to tylko takie luźne myśli, czy też jakieś poważne propozycje. Nie wiadomo też czy cokolwiek z takich “pomysłów” jest dyskutowane w jakimś szerszym gronie poza wąską grupą japońskich samurajów (rozmawiających oczywiście tylko po japońsku).

Matz powiedział że jakaś specyfikacja języka jest tworzona przez grupę tworzącą projekt Rubiniusa i że jest z nimi w kontakcie. Widzę, że Matz zaczyna się z kimś liczyć. To bardzo dobrze. Bo Ruby nie jest taki całkiem młody (jest w tym samym wieku co Java i tylko rok młodszy od Pythona) i już dawno przestał być tylko prywatnym językiem Matza do zabawy.

Zapytałem się Matza też o kwestię składni tzw. named parameters w Rubim. Czy już jest jakaś ustalona składnia i dlaczego po prostu nie skopiuje dobrego i przejrzystego rozwiązania jakie występuje od dawna w Pythonie? Dla tych co nie znają Pythona, przypominam, że chodzi o wygodne wywoływanie funkcji z parametrami występującymi w dowolnej kolejności. Najlepiej zobaczyć to na przykładzie.

def test(a, b, c='C', d='D', *args, **kwargs):
  print a, b, c, d, args, kwargs
test(1, 2)  # => 1 2 C D () {}
test(1, 2, d=3) # => 1 2 C 3 () {}
test(1, 2, 3, 4, 4, 5, 6, 7) # => 1 2 3 4 (4, 5, 6, 7) {}
test(1, 2, d='DE', foo='blah') # => 1 2 C DE () {'foo': 'blah'}

Parametry a i b są obligatoryjne, c i d posiadają domyślne wartości. *args to lista dowolnych parametrów (można dzięki temu wywoływać funkcję z dowolnie wielką liczbą parametrów). Zaś **kwargs to słownik pozwalający na dodanie dowolnej ilości kolejnych named parameters. W Pythonie jest to dosyć czytelne i łatwe do zrozumienia.

W Ruby sytuacja wygląda trochę inaczej. Z jednej strony mamy duże ulepszenie w stos. do Pythona w postaci możliwości wysyłania bloków kodu do metody. Z drugiej strony, nie mam w ogóle możliwości wywołania parametrów w dowolnej kolejności lub wywołania tylko niektórych z nich, resztę zostawiając wartościom domyślnym.

def test(a, b, c='C', d='D', *args, &block)
  print "#{a.inspect} #{b.inspect} #{c.inspect} " 
  puts #{d.inspect} #{args.inspect} #{block.inspect}"
end

W Ruby nie ma jak wywołać test(1,2,d=3). Takie wygodne pominięcie na liście parametru c (bo ma domyślną wartość) i tylko tych parametrów jakie nam pasuje możliwe jest tylko w Pythonie. W Ruby aby zmienić parametr d trzeba wywołać też parametr c, czyli w tym wypadku test(1,2,'C',3). To jest bardzo niewygodne i powszechnie stosowanym trickiem na pominięcie tego ograniczenia jest przekazywanie hasza oraz opuszczanie klamer, które w Ruby są nieobowiązkowe. Zatem dla

def test2(x, opts={})
  puts "#{x.inspect} #{opts.inspect}"
end
test2(1, :d=>4) # => 1 {:d=>4}
test2(1, {:d=>4, :c=>'C'}) # => 1 {:d=>4, :c=>"C"}
# to samo bez nawiasów i klamer:
test2 1, :d=>4, :c=>'C' # => 1 {:d=>4, :c=>"C"}

Pozornie uzyskuje się to samo. Faktycznie jest to tylko “dirty hack” i odpowiednik pythonowej konstrukcji

def test2(x, **opts):
    print x, opts
test2(1, d=4, c='C') # => 1 {'c': 'C', 'd': 4}

Po pierwsze, tym sposobem można do metody przekazać dowolny hasz. Nie ma kontroli na poziomie deklaracji metody, trzeba samemu ją sobie dodatkowo zaimplementować. Np. tak:

def params_check(*args)
  x = args[0].keys - args[1..-1]
  raise "Forbiden params: #{forbiden.inspect}" unless x.empty?
end

def fun(x, opt={})
  params_check opt, :c, :d
  puts "#{x.inspect} #{opt.inspect}"
end

fun(1, :c=>'CE') 
# => 1 {:c=>"CE"}

fun(1, :c=>'C', :d=>4) 
# => 1 {:d=>4, :c=>"C"}

fun(1, :c=>'C', :d=>4, :foo => 'bar', 'hello' => 'world')
# => RuntimeError: Forbiden params: [:foo, "hello"]

Po drugie, w wypadku przekazywania dodatkowego hasza, pierwszy musi posiadać klamry, bo inaczej nie ma możliwości rozróżnienia które dane mają wejść do pierwszego, a które do drugiego hasza.

Ale wracając do tego co odpowiedział Matz. Przyznał wprost, że te named parameters jakie miałyby wejść do Ruby 2.0 są tak naprawdę zwykłym… haszem! (zobacz ten slajd z wcześniejszej prezentacji Matza)

def fun(x, c : 'C', d : 4)
  # ...
end

co naprawdę znaczy tyle co

def fun(x, {c : 'C', d : 4})
  # ...
end

Taka innowacja nie jest w zasadzie żadną innowacją, ale sprowadza nas z powrotem do tego co już jest. Jeśli zaś jedyna zmiana jaka tu ma miejsce dotyczy tylko zastąpienia znaków => jednym znakiem dwukropka (tak jak w Pythonie nawiasem mówiąc) to albo ja tu czegoś nie rozumiem, albo to w ogóle jest bez sensu.

Django on Jython

Jarosław Zabiełło — Tue, 08 Jan 2008 04:34:00 +0100

Pythonistas chyba pozazdrościli możliwości odpalenia Railsów w JRuby. Trwają prace nad uruchomieniem frameworka Django w Jythonie, implementacji Pythona w czystej Javie.

Zapytałem się na kanale #pylons odnośnie podobnego ruchu ze strony Pylons, ale okazuje się że Jython jest dosyć zacofany. Od czasu przejścia jego twórcy do Microsoftu i pracy na IronPythonem projekt dosyć powoli się rozwija. Jython zatrzymał się na implementacji Pythona 2.2. To dosyć stara wersja zważając, że w międzyczasie wyszły wersje 2.3, 2.4 i 2.5. Pylons wymaga zgodności min. z Pythonem 2.4. Nie wiem jak ten problem rozwiążą przy przenoszeniu Django, bo coś nie chce mi się wierzyć że jest w pełni zgodny ze starym Pythonem 2.2.

Ukończono Django Book

Jarosław Zabiełło — Wed, 19 Dec 2007 01:07:00 +0100

Po roku pisania, zebraniu 2.5 tys uwag online od użytkowników, została ukończona książka o pythonowym frameworku webowym Django. Wersja papierowa ma być w sprzedaży w przyszłym tygodniu. Wersja online jest dostępna za darmo.