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

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.

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.

Django ograniczeniem w rozwoju?

Jarosław Zabiełło — Sat, 27 Oct 2007 16:31:00 +0200

Django do dobry i szybki framework do większości zastosowań. Jednakże ci, którzy chcą za jego pomocą stworzyć stworzyć większy projekt, mogę mieć później problemy z dalszym jego rozwojem…

Jednym z większych polskich projektów stworzonych w Django jest serwis społecznościowy grono.net. Niedawno w jednym z blogów ukazał się wywiad z dyrektorem działu IT tego serwisu – Albertem Szybińskim. Grono.net pierwotnie używało Javy, lecz to się nie sprawdziło. Java został zastąpiona pythonowym frameworkiem Django. Początkowo wszystko było dobrze, ale serwis się rozrastał i…

“Doszliśmy już do takiego poziomu, w którym Django zaczął być dla nas problemem. W czasie tworzenia portalu był to bardzo dobry framework, ale przy obecnym stopniu zaawansowania, Django stał się dla nas ograniczeniem w rozwoju i sami musimy go modyfikować.”

Czyli potwierdziło się to co pisałem wcześniej o Django. To system zbyt monolityczny i zdecydowanie za mało elastyczny. Django ciągnie za sobą dziedzictwo CMS Elington z jakiego wyrósł. Może dobrze sprawdza się w projektach typu “wertykalny portal dla wydawnictwa”, ale jak już chcemy coś nietypowego, zaczynają się problemy.

Na pytanie “Czy posiadając taką wiedzę jaką macie dziś, czy zdecydowalibyście się na zaimplementowanie Grono.net ponowie wykorzystując Django, czy może coś innego?” padło wskazanie na Pylons. Może nie ma tak ładnie zgrupowanych modułów w jednym miejscu jak Django, ale na pewno ma większy potencjał do tworzenia nietypowych czy skomplikowanych serwisów.

To nie Django jest prawdziwą pythonową konkurencją dla popularnego Ruby on Rails (że nie wspomnę frameworki pehapowe). Moim zdaniem, bardziej groźną dla nich konkurencją jest Pylons.

Aplikacja webowa - wybór technologii

Jarosław Zabiełło — Sat, 25 Aug 2007 21:22:00 +0200

Dość często spotykam się z prośbą o to, jaką technologię (i framework) bym polecił do tworzenia aplikacji webowych. Dziedzina aplikacji webowych rozwija się bardzo prężnie i trudno tak naprawdę przewidzieć, co będzie najlepszym wyborem za parę lat. Niniejszy artykuł stanowi krótkie podsumowanie moich doświadczeń w tej dziedzinie na dzień dzisiejszy.

Nie wierzę w przyszłość architektur webowych opartych na językach kompilowanych, statycznie typowanych.

Na ten temat można by dużo dyskutować. Po prostu nie wierzę w przyszłość budowania aplikacji webowych w językach C# czy Java. Każda zmiana kodu wymaga rekompilacji, wymiany dll itp. Mam złe doświadczenia z ASP.NET. Bardzo wolno i mozolnie się tworzy i debuguje kod. Z kolei Java (tzn. aplikacja webowa pisana napisana w tym języku) jest ciężka i skomplikowana. Aplikacje webowe są dosyć specyficzne. Znacznie lepiej sprawdzają się tam języki wysokopoziomowe i interpretowane. Nie trzeba nic restartować, rekompilować, efekty zmian są prawie natychmiastowo dostępne. Myślę, że większość aplikacji webowych, szczególniej małej i średniej klasy złożoności, zostanie opanowana przez języki interpretowane. Po części już to uczynił PHP. Jednakże…

Nie wierzę w przyszłość PHP.

Na temat wszystkich wad PHP mógłbym dużo pisać. W każdym razie nie mogę się nadziwić, dlaczego jego tworcy wciąż inspirują się składnią Perla i Javy zamiast wzorować się na prostocie i elegancji Pythona czy Ruby. PHP nie nadaje się do modularyzacji, tworzenia komponentów. Próbowałem już kiedyś uzyskać efekt komponentów w Smarty. Nie da się. Głównym problemem jest kolizja nazw klas i funkcji. Przestrzeń nazw miała być dodana w PHP5. Nie dodali, bo nie umieli. PHP brnie więc nadal w swoim chaosie wielkiej, wspólnej przestrzeni nazw dla swych wszystkich, chaotycznie nazwanych funkcji o niespójnej kolejności przekazywanych parametrów. Czy w PHP nie da się napisać dobrej aplikacji? Owszem, da. Jak ktoś się uprze to i w Assemblerze taką napisze. Tylko jakim kosztem… Kierunek rozwoju tego języka wygląda na przypadkowy. Sam język jest źle zaprojektowany. Nie wierzę w jego przyszłość tym bardziej, że wyrosła mu poważna konkurencja.

Fenomem Ruby on Rails.

Powodem rosnącej popularności Ruby on Rails, wbrew zazdrosnym opiniom co niektórych, na pewno nie jest tylko efekt dobrego marketingu. To także efekt pewnej, nowej filozofii w podejściu do tematu. Rails mocno postawił na prostotę i elegancję kodu połączoną z kompleksowością rozwiązania. Do tego dobrze dobrane wartości domyślne (ograniczające ilość niezbędnych konfiguracji) plus wygodne generatory kodu prowadzą człowieka dosłownie za rękę. Rails doczekał się też dobrego IDE co powoduje, że w tym frameworku pracuje się dosyć przyjemnie. Jest przejrzysty i czytelnie zorganizowany. Zainspirował i znalazł już wielu naśladowców, ale nigdy nie uzyskają one jego elegancji i prostoty z prostej przyczyny: siłą Rails jest prostota i dynamika języka Ruby. Dynamika większa nawet od Pythona. Sukces Railsów wzmacnia także lawinowo rosnąca ilość książek.

Rails zaczyna się wdzierać do rozwiązań korporacyjnych. Nie zastąpi on z pewnością Javy, ale na pewno lepiej od niej nadaje się do szybkiego stworzenia dynamicznych interfejsów webowych. Z chwilą okrzepnięcia JRuby (javowej implementacji Rubiego), Rails oparty na Javie (ale ze składnią Rubiego) może zrobić jeszcze sporo zamieszania.

Jednakże, jest technologia, może nie aż tak prosta, ale na pewno pod wieloma względami dojrzalsza i szybsza.

Django i Pylons.

Tak jak Rails, Django powstał na bazie aplikacji zastosowywanej komercyjnie. Podobnie też do Rails, stara się podchodzić kompleksowo podając na tacy określony (autorski) ORM, system szablonów i sposób rozwiązywania adresów URL. Django jest szybsze od Railsów. Wynika to dwóch rzeczy. Python (jako język) jest szybszy od Rubiego oraz Django od początku było projektowane z myślą o optymalizacji wydajnościowej. (Rails skupiał się od początku na uzyskaniu funkcjonalności, zrzucając optymalizację na później). O zaletach Django pisałem rok temu. Django pożera też wyraźnie mniej pamięci niż Rails odpalany na mongrelach.

Niestety, można się przyczepić do kilku rzeczy. Główna krytyka Django dotyczy jego zbytniej monolityczności i mniejszej elastyczności. Rails pozwala podpinać się do wielu baz, Django tylko do jednej. Rails posiada migracje do kontrolowania ewolucji struktury bazy. Django nic takiego nie posiada (tzn. jest w fazie rozwojowej gdzieś w bocznych gałęziach repozytorium SVN). Rails posiada świetne helpery do generowania adresów URL. Djangowy system adresów jest znacznie gorszy. Nie ma możliwości zmiany struktury aplikacji i wygenerowania zmienionych linków we wszystkich szablonach. Rails, dzięki helperom to umożliwia. Rails posiada świetne helpery i specjalne szablony uproszczające korzystanie z AJAX’a, Django nic tu nie oferuje.

Wiele z wymienionych wyżej wad nie posiada pythonowy konkurent Django – Pylons. Pisalem o tym ponad roku temu, że Pylons skopiował prawie wszystkie helpery jakie posiada Rails. Rozwiązuje adresy też w podobny sposób umożliwiając bardziej elastyczne modyfikowanie struktury kontrolerów. Wszystkie zależne adresy URL są generowane za pomocą helperów w sposób podobny do Rails. Pylons w zasadzie to taka sklejanka zewnętrznych bibliotek Pythona. Wykorzystując standardowy mechanizm WSGI, Pylons pozwala na wymianę prawie każdego swojego elementu, od ORM, po system szablonów czy resolver adresów URL.

Wiele z elementów, jakie domyślnie oferuje Pylons przewyższa elastycznością i możliwościami to, co dostępne jest w Django. Np. Pylons korzysta domyślnie z SQLAlchemy, który jest potężniejszy od tego w Rails i Django¹. Nie tylko bez problemu pozwala podpiąć się do kilku baz, ale także do bardziej skomplikowanych struktur². Domyślny system szablonów Mako jest najlepszym systemem jaki znam. Oferuje rozbudowaną³ obiektowość, prostą składnię, doskonały cache dowolnego fragmentu i wg dowolnych zasad. Coś, o czym np. Rails może tylko pomarzyć⁴. No i Pylons udostępnia szybki, wielowątkowy serwer HTTP który można bez problemu używać zarówno do deweloperki jak i produkcyjnie. Ani Django ani Rails nie obsługują wielowątkowości. Pylons obsługuje, dzięki czemu też ma mniejsze zapotrzebowanie na pamięć.

Pylons oferuje więc więcej możliwości, ale kosztem większej złożoności. Django jest trochę prostszy do opanowania. Cała dokumentacja jest w jednym miejscu. Nauka Pylons wymaga sięgnięcia do oddzielnej dokumentacji SQLAlchemy, Mako czy Routes. Sam SQLAlchemy jest też bardzo rozbudowany i trudniejszy do opanowania.

Zope 3 – najwyższa poprzeczka.

Napisany w Pythonie, obiektowy, wielowątkowy serwer aplikacyjny Zope od dawna uchodził za “zabójczą aplikację” Pythona. Powstało do niego tysiące pluginów. Jednym z najsłynniejszych jest Plone CMS (wg mnie najlepszy CMS jaki napisano). Zope 2.x był jednakże krytykowany za zbytnią złożoność i bałagan w API. Nauczenie się Zope wymagało sporo wysiłku także z powodu słabej dokumentacji. Większość lekkich frameworków Pythona powstało trochę na bazie kontestacji Zope. Na szczęście, twórcy wyciągnęli lekcję z Zope 2 i kod dla wersji 3 został napisany od zera. Znacznie uproszczono i uporządkowano API.

Rails, Django czy Pylons są groźną konkurencją przede wszystkim dla popularnego PHP. To jest mniej więcej dziedzina ich zastosowań. Zope zaś to trochę inna filozofia i inna grupa docelowa. Zope ma ambicję aby konkurować z najpoważniejszymi zastosowaniami klasy enterprise opanowanymi głównie przez Javę.

Przede wszystkim Zope to serwer aplikacyjny w pełni obiektowy i o budowie komponentowej. Każdy komponent ma ściśle zdefiniowane interfejsy⁵. Zope korzysta standardowo z prawdziwej bazy obiektowej. Nie potrzebuje żadnego wspierania się wrapperami ORM. Baza obiektowa zapisuje całe obiekty Pythona w sposób transparentny i stanowi naturalne przedłużenie pisanego kodu. Zope 3 ma oczywiście wbudowane wszystko co potrzebuje typowa aplikacja webowa, dobry cache, wbudowane mechanizmy bezpieczeństwa, przepływu danych, lokalizacji interfejsu (i18n, l10n) itp. Pozwala też na przeładowywanie komponentów bez restartu serwera. Jeśli potrzeba nowej funkcjonalności, wystarczy napisać nowy komponent i podpiąć do serwera. Nie ma znaczenia czy tym komponentem będzie “artykuł”, czy “plik graficzny” czy cały system redakcyjny, bądź CMS.

Te możliwości jednak nie są bez wad. Do największych zaliczyłbym słabą promocję (to w ogóle jakaś przypadłość Pythona i jego aplikacji) oraz wciąż za słabą dokumentację. Na szczęście ta ostatnia rzec się trochę poprawiła. Nawet są już książki dedykowane specjalnie dla Zope 3.3. Zope potrzebuje też znacznie więcej pamięci niż taki Django czy Pylons.

Ku przyszłości.

Dziedzina aplikacji webowych rozwija się bardzo dynamicznie i trudno coś przewidzieć w dalszej przyszłości. W związku z dynamicznym rozwojem procesorów wielordzeniowych, kto wie, czy renesansu nie przeżyje język Erlang (bo doskonale się nadaje do programowania współbieżnego). Być może renesans przeżyją serwery kontynuacyjne, które zapewniają zachowanie stanu dla aplikacji webowej eliminując potrzebę używania sesji. W serwerze kontynuacyjnym, pisanie kodu dla aplikacji webowej, czy desktopowej, prawie niczym się nie różni. Na razie najbardziej znanym serwerem tego typu jest napisany w Smalltalku – Seaside. Duży potencjał ma też Ruby, bo posiada wbudowaną obsługę kontynuacji.

Na pewno obawa co do znalezienia pracy w Rails czy Pythonie raczej nie ma dużego uzasadnienia. Jest wiele firm używających Pythona. Najlepszym przykładem jest Google, który prawie wszystko ma oparte na Pythonie. Od czasu do czasu pojawiają się w Polsce dramatyczne ;) wołania o programistów Pythona, więc choć ofert nie ma tyle co dla Javy i .NET, to można coś wyszukać. Jeśli chodzi o Ruby on Rails, to ofert zaczyna być coraz więcej, jest już trochę więcej niż dla Pythona. Rails pędzi na pełnej szybkości i dzięki dobre promocji wdziera się coraz szerzej do świadomości programistów głównego nurtu. Sam pracuję w firmie gdzie główny system oparty jest na Springu i Hibernate, technologiach Javy. Jednakże do tworzenia aplikacji webowej został wybrany Ruby on Rails.

Podsumowując powiedziałbym, że współczesny programista musi operować kilkoma językami i technologiami. Dzisiaj pracuje się w heterogenicznym środowisku i wykorzystuje mieszane technologie. Kto myśli, że nauczy się tylko jednego, doskonałego języka i tylko jednego frameworka, pewnie mocno się rozczaruje w zderzeniu z rzeczywistością⁶.

Do lekkich webowych interfejsów z dużą ilością AJAX’a wybrałbym Rails. Także dla osób początkujących, pragnących nabrać dobrych nawyków, wybrałbym Rails⁷. Tam, gdzie wymagane jest jednak dobre wsparcie dla Unicode oraz gdzie wydajność jest bardziej kluczowa, wybrałbym Pylons⁸. Z kolei, jeśli chcemy uderzyć w rynek bardziej kompleksowych rozwiązań dla biznesu, Zope 3 będzie raczej trudny do pobicia. I w końcu, tam, gdzie potrzebujemy gotowego, dobrego forum i taniego hostingu najlepiej sprawdzi się PHP (tak, najlepsze, gotowe do użycia forum są napisane w PHP).

Apendix: Jest dostępne kolorowanie składni Mako dla kilku edytorów (TextMate, Emacs, Vim i Komodo). (2007-09-12)

¹ Tak w ogóle to kwestia porównania Active Record, SQLAlchemy i Django nie jest taka oczywista. Każdy posiada coś, czego nie posiada drugi. Np. Active Record posiada eleganckie walidatory, których nie ma w SQLAlchemy. Z kolei Django nie umie podpiąć się do wielu baz, ale posiada wygodne, wysokopoziomowe pola w modelu. SQLAlchemy zaś podepnie się do najbardziej pogmatwanej struktury, wielu baz i to wszystko w elegancki, obiektowy sposób, a nie z brutalnymi wstawkami kodu SQL, jak ma miejsce w Active Record. Poza tym SQLAlchemy potrafi optymalizować zapytania tak, aby kilka poleceń wykonać możliwe najmniejszą ilością kwerend i połączeń z bazą.

² Rails nie ma problemu podpięcia się do wielu baz. Zaś struktury takie jak złożone klucze główne potrafi obsłużyć za pomocą odpowiednich pluginów.

³ Mako pozwala na więcej niż proste dziedziczenie tak jak ma Django. Pozwala na kaskadę dziedziczenia.

⁴ Rails ma słabe możliwości w zakresie buforowania danych. Np. nie potrafi buforować fragmentów szablonów w oparciu o unikalny klucz (z parametrów adresu URL lub w oparciu o inne kryteria).

⁵ Sam Python nie posiada wbudowanej składni do tworzenia interfejsów czy klas abstrakcyjnych. Autorzy Zope 3 jednak je częściowo zasymulowali korzystając z tego, co oferuje język.

⁶ W tym wszystkim za mało padło o znajomości JavaScript. Nie jest to zbyt prosty i intuicyjny język, a ma spore możliwości i jest bardzo dynamiczny. Jego znajomość jest absolutnie niezbędna dla każdej osoby chcącej tworzyć aplikacje internetowe. O CSS i XHTML nie wspominam, bo to oczywiste podstawy.

⁷ Rozpoczynanie przygody z tworzeniem aplikacji webowych od PHP jest najgorszą rzeczą jaką możemy zrobić. PHP za bardzo zachęca i utrwala złe nawyki programistyczne. To właśnie miał na myśli DHH, twórca Rails, kiedy porównał PHP do… diabła. :)

⁸ A co z Django? Jeśli mam wybierać między Django a Pylons, to wolę Pylons. Ma większe możliwości i osiągnął wystarczającą dojrzałość aby podważyć dominację i popularność Django w kręgach pythonistas. Jedną z polskich firm, która wdrożyła i używa z sukcesem Pylonsów jest firma, w której spędziłem parę lat i gdzie wdrożyłem kiedyś Pythona – Wydawnictwo Murator. Pozdrowienia dla ekipy. :)

MySQLdb i problem polskich znaków

Jarosław Zabiełło — Fri, 16 Mar 2007 02:36:00 +0100

W końcu pojawiła się wersja stabilna pythonowej biblioteki MySQLdb 1.2.2. Co ciekawsze, jest dostępna instalacja w formie pakieru egg zarówno dla Pythona 2.4 jak i 2.5. Nie trzeba też już więcej używać instalatorów binarnych pod windozą. Wystarczy (zakładając że mamy zainstalowane setuptoolsy) wykonać komendę:

easy_install -U MySQL_python

Osoby używające Django i MySQL5 muszą pamiętać aby dodać dodatkową opcję do settings.py.

W wypadku wersji edge (z SVN), należy dodać:

DATABASE_OPTIONS = {'use_unicode': True, 'charset': 'utf8'}

W przypadku starszego kodu to nie pomagało. Musiałem wyłączyć zwracanie wyników w postaci obiektów unikodowych Pythona. W tym wypadku podziałała opcja:

DATABASE_OPTIONS = {'use_unicode': False, 'charset': 'utf8'}

Widzę, że Django najwyraźniej idzie w tym samym kierunku co Pylons, tzn. myśli aby wszystkie stringi i pracę z bazą oprzeć na obiektach unikodowych a nie stringach UTF-8. W wypadku Pylonsów, ich najnowszy system szablonów Mako standardowo już pracuje wewnętrznie na czystych obiektach unikodowych Pythona.

Uwaga! Django ma trochę niedopracowanego kodu. Np. panel admina się sypie jak ustawiona jest powyższa opcja z włączonym unikodem. Trzeba ją wyłączyć. Ale wtedy z kolei źle się wyświetla część tekstów zawierająca polskie znaki (np. imię czy nazwisko redaktora). Jednak lepsza to niż w ogóle brak możliwości edycji rekordów. Wniosek: dla Django używaj drugiej opcji. Aktualnie kod Django jeszcze nie dorósł do tego, aby używać pełnego unikodu z bazą MySQL.

Porównanie wydajności frameworków

Jarosław Zabiełło — Sun, 04 Feb 2007 22:54:00 +0100

Ciekawe i dosyć dokładne porównanie wydajności paru frameworków:

CodeIgniter (PHP)
Catalyst (Perl)
Django (Python)
Django (Python + Psyco)
RubyOnRails (Ruby)
Symfony (PHP)
TurboGears (Python)

Django bez trudu zdeklasowało konkurencję. Szkoda, że w porównaniu nie uwzględniono Pylonsów i CakePHP. Bardzo też dziwne, że nowy Rails 1.2.1 w tych testach jest mocno wolniejszy od starszej wersji 1.1.6. Frameworki pehapowe okazały się najwolniejsze. Najgorszy okazał się pehapowy Symfony. Jest skomplikowany i wolny, 35x wolniejszy od Django!

Szablony i wzorzec MVC - cz. III

Jarosław Zabiełło — Sun, 14 Jan 2007 04:25:00 +0100

W poprzedniej części omówiono szablony dedykowane głównie do współpracy z designerami bojącymi się programować. Były to albo szablony wkładające swoją logikę do znaczników XML/XHTML (ZPT, SimpleTAL, Kid, Genshi, MasterView, PHP TAL), albo szablony posiadające swój własny, specjalizowany język (Smarty, Django, Jinja, Liquid). W założeniu taki język miał być prostym substytutem języka używanego w warstwie kontrolera. Szablony tego typu może są wygodne dla designera, ale na pewno nie dla programisty, który musi je przygotować. Po pierwsze, trzeba się uczyć kolejnego języka… szablonów. Po drugie, wszystkie tego typu języki są ograniczające dla programisty. Mimo że pozornie prostsze, w praktyce są bardziej złożone i to nawet dla designera. Np. szablony Django i Jinja nie posiadają żadnej składni na określenie trywialnego warunku większości, mniejszości:

{{ x }} jest 
{% if x > y %} 
    większe 
{% else %} 
    mniejsze 
{% endif %} 
od {{ y }}

Powoduje to masę kłopotów dla programisty¹. Prymitywna składnia szablonu wymusza więc kupę dodatkowej pracy. O ileż prościej jest użyć po prostu pełnej składni języka tak jak to robią szablony Cheetah:

$x jest 
# if x > y 
    większe 
# else 
    mniejsze 
# endif  
od $y

Dochodzimy tu więc do sytuacji kiedy byśmy chcieli coś bardziej elastycznego – pełnego dostępu do języka programowania. Taka sytuacja jest pożądana wtedy kiedy i tak szablony budują programiści na podstawie dostarczonego czystego kodu HTML od designerów.

PHP

Język PHP jest dosyć specyficzny, bo w istocie jest to język szablonów. Tzn. pierwotnie tak został stworzony, ale z czasem się skomplikował że dostąpił miana języka skryptowego. Ale jego korzenie widać w składni, która z definicji jest zagnieżdżaniem instrukcji PHP wewnątrz kodu HTML. Idąc tym tropem, niektórzy pomyśleli, że nie ma sensu wymyślać dodatkową składnię. Wystarczy użyć PHP w odpowiedni sposób. I tak powstały szablony Savant.

Właściwie to Savant nie powinny nazywać się szablonami, bo to nic innego jak PHP użyty w taki sposób, aby rozdzielić warstwę prezentacji, od wartwy logiki biznesowej. A skoro to PHP, to odpada nauka dodatkowej składni oraz potrzeby kompilacji specjalizowanego języka szablonów do końcowego kodu PHP (jak to ma miejsce w szablonach Smarty).

Czy takie podejście jest lepsze, czy gorsze, to już każdy może sobie ocenić. Moim zdaniem PHP ma na tyle mętną składnię, że warstwa prezentacji używająca Smarty² jest bardziej czytelna niż czysty PHP jaki używają Savant.

Ruby

Kiedy mówimy o Ruby w kontekście stron internetowych to najczęściej mamy na myśli jego najsłynniejszy framework – Rails. Ruby sam w sobie nie jest związany z HTML tak jak PHP. Rails do szablonów używa biblioteki ERb (ang. “embed Ruby”, czyli “zagnieżdżony Ruby”) Składnia jest bardzo podobna do PHP, JSP czy ASP. Ruby jest tu językiem zagnieżdżonym w HTML.

<%= x %> jest 
<% if x > y %> 
    większe 
<% else %>
    mniejsze 
<% end %>
od <%= y %>

Python

Jeśli chodzi o Pythona to istnieje cała masa systemów szablonowych. Ograniczę się do paru, tych bardziej interesujących.

Spyce

Szablony Spyce zostało stworzone jako pythonowa konkurencja dla PHP. Podobnie potrafią przeplatać język (tu: Pythona) z tagami HTML. Najbardziej oczywista przewaga Spyce wynika z faktu używania języka Python, który jest znacznie lepiej zaprojektowany i posiada dużo więcej możliwości niż PHP. Spyce potrafii budować własne znaczniki (custom tags, podobnie jak to potrafią javowe JSP) oraz łatwiej w nich zbudować komponenty, kod do wielokrotnego użytku.

Myghty

Szablony Myghty powstały pierwotnie jako pythonowa implementacja systemu komponentowego Mason dla Perla. Mimo wielu podobieństw, Myghty są znacznie potężniejsze o Masona, np. intensywnie wykorzystują obiektowość Pythona (zobacz różnice). Od początku Myghty powstało z myślą o dużych obciążeniach, ciężkich, profesjonalnych zastosowaniach. Mają doskonały własny cache, są bardzo szybkie, odporne na wątki, świetnie się nadają do tworzenia komponentów.

Programiści Pythona bardzo cenią sobie filozofię tego języka (która podkreśla prostotę, oczywistość i elegancję składni). Problem w tym, że Myghty dla pythonowców jest zbyt podobne do Perla. Są za mało “pythonic” – pythonowe. Dodatkowo, poprzez podkreślanie swojej komponentowości, Myghty niektórym zbyt kojarzy się z filozofią komponentową frameworku ASP.NET (a wzorzec MVC wydaje się być bardziej przejrzysty niż wzorzec sterowanych zdarzeniami komponentów). Myghty, jako system komponentowy, może być używane w stylu MVC, ale nie jest to takie naturalne i oczywiste. (Na szczęście, wszystko zmienił Pylons który zapewnia przejrzystą pracę zgodną z wzorcem MVC i Myghty są tam zredukowane tylko do obsługi szablonów szablonów. Sterowaniem zajmują się kontrolery Pylonsa a nie Myghty).

Cheetah

Szablony Cheetah posiadają jedną z najbardziej czytelnych i eleganckich składni. Autorzy wzorowali się trochę na javowych Velocity i Webmacro. Tym, którzy cenią sobie czystość Pythona z prostotą składni szablonów z pewnością Cheetah mogą przypaść do gustu. Przez dłuższy czas były moimi ulubionymi szablonami i do te pory lubię ich klarowność. Cheetah posiadają elegancką składnię obiektowego budowania szablonów potomnych na bazie już istniejących. Myghty też to potrafi, ale Cheetah to ma bardzo czytelnie zrobione. Cheetah są również bardzo szybkie.

Mako

Mako to najmłodsze dziecko stworzone przez programistów Pylonsów. Powstały na bazie doświadczeń i najlepszych cech szablonów Myghty, Cheetah, Django/Jinja czy Smarty. Największą ich zaletą jest ogromna szybkość i pythonowa filozofia pracy. Programiści Pythona mogą zauważyć, że składnia Mako jest bardzo bliska sposobowi pracy w samym języku Python. Mako posiadają wielką łatwość tworzenia komponentów, ale w sposób bardzo podobny do tego jak Python wykorzystuje swoje moduły. Szablony można także rozszerzać na drodze obiektowego dziedziczenia. Dziedziczenie szablonów może być określane w sposób dynamiczny (tego już nie potrafią np. Cheetah). Dowolny fragment szablonu można również zamienić na komponent z własnym cache. Mako posiadają także składnię modyfikatorów, które spopularyzowane zostały przez Smarty. Działają one jak uniksowe pipes (${zmienna|filter}.

Mako automatycznie kompilują swój kod do modułów Pythona. Można je więc debugować tak jak zwykły kod Pythona (Cheeatah wymaga ręcznej kompilacji). Można je bez problemu używać jako niezależną bibliotekę. Nie są one zależne od jakiegokolwiek frameworku. Można je zintegrować z dowolnym frameworkiem używającym standardu³ WSGI. Użytkownicy frameworka Pylons prawie nic nie muszą robić, bo Mako są już tam przygotowane do pracy.

Ogólnie rzecz biorąc, Mako to – moim zdaniem – najlepszy aktualnie istniejący system szablonów dla Pythona.

Zaś co do frameworków… to coraz bardziej zaczynam nabierać pewności, że przyszłość nie należy ani do Django, ani do Railsów. Nic nie może równać się z możliwościami czystego, 100% frameworka WSGI. Takim jest np. Pylons. Ale o tym, i o “bitwie” Pylons vs. Django i Rails, napiszę już innym razem.

Appendix 2007-01-29: Zobacz też szablony Haml .

¹ Poprawnie rzecz mówiąc, powinien napisać swojego helpera. Jeśli więc chcemy wyświetlić w pętli rekordy z bazy, a widok jest czuły na zawartość tych danych, to powinniśmy cała listę rekordów wrzucić do helplera, przeiterować w pętli, dodać dodatkową zmienną i dopiero tak zmodyfikowaną listę przekazać do szablonu.

² Smarty mimo posiadania własnej składni pozwala na odpalanie pełnego języka PHP: {php}print phpinfo();{/php}. Tak praktyka jest jednak odradzana, bo wprowadza jeszcze większy bałagan niż już jest w PHP.

³ Zobacz artykuł Introducing WSGI: Python’s Secret Web Weapon oraz prezentację koncepcji WSGI na video.