Skype3 i polski czat dla Railsów, Django i Pylonsa

Opublikowane przez Jarosław Zabiełło Thu, 14 Dec 2006 23:48:00 GMT

Nowy Skype 3 wprowadza małą rewolucję w stos. do poprzedniej wersji. Można nie tylko rozmawiać, ale pograć w szachy, kółko i krzyżyk i inne gry (są b. ładnie zrobione we Flashu 9). Można nagrywać rozmowy na dysk. Można tworzyć publiczne czaty. I właśnie w tej sprawie piszę ten tekst bo stworzyłem polski czat dla miłośników frameworków Ruby on Rails, Django i Pylons. Wygodniej jest czasem skonsultować coś w czasie rzeczywistym niż na grupie czy forum dyskusyjnym.

Posted in , , , , ,  | Tagi , ,  | 17 comments

Nginx - Apache killer

Opublikowane przez Jarosław Zabiełło Tue, 07 Nov 2006 23:47:00 GMT

W ostatnim artykule (Railsy: Lighttpd czy Apache 2.2.x?) porównywałem najbardziej popularne serwery HTTP dla Railsów. Zaintrygowany paroma wpisami w blogu postanowiłem przyjrzeć się dosyć mało znanemu serwerowi HTTP który zaczyna zdobywać coraz więcej uwagi na Zachodzie. Chodzi o ultraszybki serwer nginx napisany przez rosyjskiego programistę Igora Sysojewa.

Na pierwszy bój poszedł prosty test wyświetlenia “Hello World!” Na używanym przeze mnie serwerze dedykowanym (Athlon 64 3000+, 1GB RAM, Linux Ubuntu 64bit) dla 100 tys. zapytań (musiałem użyć aż tyle, bo serwer jest za szybki na mniejszą liczbę zapytań) uzyskałem następujące wyniki (dla polecenia “ab -n 100000 -c 1 http://localhost”):

  • Apache 2.2.3 = 4439 req/s
  • Lighttpd 1.4.11 = 7150 req/s
  • Nginx 0.4.12 = 8700 req/s

Co prawda Nginx wykazuje miażdzącą przewagę wydajności nad Apachem ale, z racji tego, że używam Lighttpd, który co prawda odstaje od Nginxa ale nie aż tak, postanowiłem na razie zaczekać z ewentualną migracją.

Okazało się jednak, że będę musiał przeprowadzić taką migrację szybciej niż bym chciał. Coś złego zaczęło się dziać z Ligthttpd. Po paru godzinach pracy, przestawał odpowiadać na zapytania a nawet w ogóle proces znikał z pamięci. Ki diabeł? Trudno powiedzieć, nie mam czasu aby analizować dokładniej problem. Jedyne co pomagało to regularny restart Lighttpd. Trochę głupie rozwiązanie. Postanowiłem zatem zrobić wcześniejszą migrację do Nginxa. Wg statystyk Netcraftu z Nginxa korzysta już ponad 90 tys. domen. Wydaje się to wystarczającą ilością aby można było uznać ten serwer za stabilny.

Jednakże moja migracja ma pewną trudność. Używam bowiem równocześnie PHP, Django, Rails i Zope (ściślej: Plone). Czyli całkiem niezła mieszanka aplikacji. Z PHP i Railsami było najmniej problemów, bo przykłady konfiguracji są z grubsza podane w Wiki.

Z Plone było troszkę gorzej. Musiałem bowiem znaleźć odpowiednik mniej więcej takiego kodu w Apache:

RewriteRule "^/(.*)$" 
"http://88.198.15.160:6001/VirtualHostBase/http/apologetyka.com:80/app/VirtualHostRoot/$1"  [P,L]

To nie jest zwykły rewrite, to jest połączenie proxy z rewrite.

W Lighttpd (też się swego czasu namęczyłem aby to uzyskać) uzyskuje się to tak:

url.rewrite-once = (
  "^/(.*)$" => "/VirtualHostBase/http/apologetyka.com:80/plone/VirtualHostRoot/$1"
)
proxy.server = (
   "/VirtualHostBase/" => (
     ( "host" => "88.198.15.160" , "port" => 6001 ) )
)
Trochę prób i się udało. Nginx potrzebował takiego wpisu:
location / {
  rewrite ^/(.*)$ /VirtualHostBase/http/apologetyka.com:80/plone/VirtualHostRoot/$1;
}
location /VirtualHostBase/ {
  include /opt/nginx/conf/proxy.conf;
  proxy_pass http://88.198.15.160:6001;
}

Najtrudniej było z konfiguracją Django bo opisu do Django na Nginx nie ma ani w dokumentacji do Django, ani w dokumentacji do NGinxa. Zmęczony eksperymentowaniem napisałem na listę dyskusyjną Django i dostałem całkiem pożyteczną wskazówkę odnośnie strony http://www.python.rk.edu.pl/w/p/django-pod-serwerem-nginx/. Niestety miałem pecha, bo akurat trafiłem na zmianę wpisów w DNS i artykuł był niedostępny. Udało mi się na szczęście wyłuskać jego kopię z cache Googli. Autor międzyczasie podesłał mi też pliki z artykułami. Zauważyłem że napotkał pewne problemy ze zmuszeniem Django do wyświetlania statycznej treści. Trochę podłubałem w kodzie i problem rozwiązałem. :)

Zauważyłem że Django wyświetlał mi pliki statyczne w trybie debug. Wynikało to pewnie z tego, że w urls.py stosuję zawsze taki wpis:

...
if DEBUG:
  urlpatterns += patterns('',
    (r'^images/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/images', 'show_indexes': True}),
    (r'^stylesheets/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/stylesheets', 'show_indexes': True}),
    (r'^javascripts/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/javascripts', 'show_indexes': True}),
    )

Dla trybu produkcyjnego (settings.DEBUG=False) trzeba zmusić serwer HTTP aby się zajmował plikami statycznymi. Django ma tylko przetwarzać Pythona. Mozna to zrobić np. tak:

...
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) {
  access_log   off; # po co mi logi obrazków :)
  expires      30d; 
}
location / {
  include /opt/nginx/conf/fastcgi.conf;
  fastcgi_pass 127.0.0.1:6002;
  fastcgi_pass_header Authorization;
  fastcgi_intercept_errors off;
}

Gdzie plik fastcgi.conf:

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

fastcgi_param  PATH_INFO          $fastcgi_script_name;

Plik startowy napisałem sobie już w Pythonie:

#!/usr/bin/env python

import os, sys, time
DEBUG = True
# All Django project are inside /home/app/django/

path = '/home/app/django'

projects = {
    'biblia' : {
        'project': 'searchers',
        'port':6002,
        'pidfile': '/var/run/django_searchers.pid',
        'children': 4,
        },
    'koran': {
        'project': 'django_project',
        'port':6003,
        'pidfile': '/var/run/django_koran.pid',
        'children': 4
        },
    }

def start(name):
    project = projects[name]['project']
    os.chdir('%s/%s/' % (path, project))
    appl = './manage.py runfcgi host=127.0.0.1'
    cmd = '%s port=%s minspare=1 maxspare=%s pidfile=%s --settings=%s.settings' \
          % (appl, projects[name]['port'], projects[name]['children'], projects[name]['pidfile'], project)
    if DEBUG: print cmd
    os.system(cmd)

def stop(name):
    pidfile = projects[name]['pidfile']
    if os.path.exists(pidfile):
        cmd = '/bin/kill -TERM %s' % open(pidfile).read()
        if DEBUG: print cmd
        os.system(cmd)
        os.unlink(pidfile)

def restart(name):
    stop(name)
    time.sleep(1)
    start(name)

if __name__ == '__main__':
    try:
        action, project = sys.argv[1], sys.argv[2]
        if action in ['start','stop', 'restart'] and project in projects:
            if action == 'start':
                start(project)
            elif action == 'stop':
                stop(project)
            elif action == 'restart':
                restart(project)
            else:
                raise IndexError
        else:
            raise IndexError
    except IndexError:
        print "Usage: %s {start|stop|restart} {%s}" % (sys.argv[0], '|'.join(projects.keys()))

Migracja się udała. Plone, PHP, Django i Rails śmigają mi teraz na ultraszybkim (i zajmującym mało pamięci!) serwerze Nginx. Acha, zapomniałem dodać: Nginx to nie tylko duża wydajność i oszczędność pamięci. Nginx ma dużo modułów. Może nie tyle, co Apache, ale znacznie lepiej niż Lighttpd.

BTW, ciekawie wygląda także serwer Cherokee. Nginx działa tylko pod systemami POSIX (Unix, MacOS-X, Linux, FreeBSD). Cherokee natomiast posiada… binarną instalację pod Windows! Ale o tym może napiszę coś innym razem. :)

Posted in ,  | Tagi , , , ,  | 16 comments

Django Book

Opublikowane przez Jarosław Zabiełło Wed, 01 Nov 2006 09:07:00 GMT

Zgodnie z wcześniejszymi zapowiedziami, autorzy Django postanowili nie tylko napisać książkę na temat swego frameworka, ale także udostępnili za darmo książkę w wersji online . Nowo powstająca książka jest dostępna pod adresem http://www.djangobook.com. Każdy paragraf można komentować. Wersja papierowa ma być wydana w 2007 przez wydawnictwo Apress.

Posted in  | Tagi  | 4 comments

Django, Rails i współdzielenie danych

Opublikowane przez Jarosław Zabiełło Wed, 19 Jul 2006 19:22:00 GMT

Osoby mające wcześniej do czynienia z innymi frameworkami, gdy sięgną do Django mogą być trochę zdezorientowane sposobem w jaki należy przekazywać zmienne do wspólnych części serwisu. Aby lepiej zrozumieć problem, podam wpierw jak jest on rozwiązywane w Railsach.

Otóż, Railsy zakładają, że każdy kontroler dziedziczy po wspólnym kontrolerze zwanym ApplicationControler. A że jest to normalna klasa Rubiego, więc nic dziwnego, że wszelkie jej metody i zmienne (instancji) są automatycznie dziedziczone we wszystkich jej klasach potomnych. To bardzo intuicyjne rozwiązanie. Jeśli chcemy przekazać jakieś wspólne dane do wszystkich kontrolerów i ich szablonów, wystarczy te dane zdefiniować w tym miejscu. Weźmy np. poniższy kod.

# plik: app/controllers/application.rb
class ApplicationController < ActionController::Base
  before_filter :defaults
  def initialize
    @name = "Jarek"
  end
  def defaults
    @msg = "Hello!"
  end
end

# plik: app/controllers/home_controller.rb
class HomeController < ApplicationController 
end

# plik: app/controllers/about_controller.rb
class AboutController < ApplicationController 
  def index
    @dodatkowa = "wartość"
  end
end

Zakładając, że nie zmienialiśmy domyślnego działania resolvera adresów URL, wpisanie strony http://localhost:3000/home wywoła domyślną metodę index() z klasy HomeController. Jeśli jej nie ma (jak na naszym przykładzie), to Rails zakłada, że chcemy wywołać jej szablon tak, jakby ta metoda istniała. Wczytywany jest zatem plik app/views/home/index.rhtml. Dzięki temu, że w klasie ApplicationController zdefiniowaliśmy 2 zmienne instancji (@name i @msg) automatycznie są one dziedziczone przez klasę HomeController i tym samym dostępne w w/w szablonie. Identycznie będzie z drugą klasą, jej szablon również będzie miał obie, zdefiniowane wyżej, zmienne1.

W wypadku Django, sprawy wyglądają inaczej dlatego, że kontrolery3 nie są metodami klas Pythona! Są one metodami modułu Pythona. Co prawda moduł też jest obiektem, ma własną przetrzeń nazw itp. ale posiada jedną zasadniczą różnicę wobec klasy – nie można dziedziczyć modułu od modułu. Tym samym próba współdzielenia zmiennych musi być zrobiona zupełnie inną metodą.

Trochę z tym problemem się męczyłem, bo w dokumentacji mało na ten temat piszą. Dopiero na IRC podsunięto mi link do artykułu Django tips: Template context processors, który wszystko ładnie wyjaśnił2. Okazuje się, że jest kilka sposobów rozwiązania tego problemu. Napisanie własnego MiddleWare (ech, nie chciało mi się, to armata na muchę), napisanie własnego znacznika dla szablonów (w wypadku mojej małej aplikacji, to też byłaby przesada) lub wykorzystanie tzw. procesora kontekstu (Context Processor). I to było to!

Wystarczy stworzyć sobie plik (o nazwie np. context_processors.py) z funkcjami implementującymi to, co chcemy wrzucić do wszystkich szablonów.

def name(request):
  return 'Jarek'

def msg(request):
  return 'Hello!'

Następnie trzeba dodać w settings.py informację że będziemy tego używać:

TEMPLATE_CONTEXT_PROCESSORS = (
  'myapp.context_processors.name',
  'myapp.context_processors.msg',
  ) 

W wypadku generic views to wszystko, bo one automatycznie wciągają RequestContext dla swoich szablonów. W wypadku naszych kontrolerów (zakładając, że używamy render_to_response() aby wyświetlać szablon) trzeba na końcu metody render_to_response() dodać jeden parametr ‘context_instance’. Czyli:

# wpierw wciągamy RequestContext
from django.template import RequestContext

def home(request):
  return render_to_response(
    'home.html', 
    context_instance=RequestContext(request))

def about(request):
  return render_to_response(
    'about.html', 
    {'dodatkowa': 'wartość'},
    context_instance=RequestContext(request))

Tak coraz bardziej wgłębiając się w Rails i Django widzę, że Rails jest jednak bardziej intuicyjny i łatwiej się go nauczyć. Jednakże Django wydaje się mieć sporo potężnych mechanizmów, których odkrywanie (mam nadzieję) się uprości jak tylko jego twórcy opublikują pierwszą książkę na jego temat (ma być dostępna także w wersji online za darmo!)

-

1 W podanym wyżej przykładzie wykorzystałem dwa różne sposoby przekazania zmiennych. Za pomocą konstruktora i za pomocą metody ‘before_filter’. Wiadomo, że konstruktor nie nadaje się do przekazywania wszystkiego. Czasami musimy przekazać coś, co istnieje już po wywołaniu konstruktora. Wtedy przydaje się metoda ‘before_filter’. To jedna z wielu sztuczek jakie ma w swym arsenale Rails aby kod był czysty, klarowny i zgodny z zasadą DRY (nie powtarzania się).

2 Zobacz też artykuł How Django processes a request?.

3 W Django nazywane są one metodami widoku. Osobiście nie podoba mi się zamieszanie terminologiczne jakie Django zrobiło z modelem MVC. Kontroler to dla nich Widok (View), zaś Widok to Szablon. Trochę to bez sensu, bo nikt tak tych rzecz nie nazywa. Czyli djangowe metody widoku to nic innego jak akcje kontrolera dla Rails i reszty świata.

Posted in ,  | Tagi ,  | 2 comments

Django i Rails biją PHP

Opublikowane przez Jarosław Zabiełło Fri, 14 Jul 2006 15:34:00 GMT

Porównanie wydajności trzech frameworków: Symfony, Ruby on Rails i Django pokazuje że Rails jest znacznie szybszy od pehapowego Symfony, a Django znacznie szybszy od Railsów. Co ciekawe, PHP5 używał akceleratora.

Posted in , ,  | Tagi , ,  | 19 comments

Django i jego konkurenci

Opublikowane przez Jarosław Zabiełło Wed, 21 Jun 2006 15:18:00 GMT

Po ostatnich paru tekstach o Django, pora na odrobinę odmiany, bo Django niekoniecznie musi być uważany za najlepszy framework w klasie środowisk “railsopodobnych”. :)

TurboGears

Trzeba pochwalić dobry marketing megaframeworku1 TurboGears, bo już w Amazonie jest nawet dostępna książka na jego temat. Jednakże, małe to pocieszenie. TurboGears raczej nie będzie poważną alternatywą dla Django z prostej przyczyny. Cały jego kręgosłup opiera się na mało profesjonalnej implementacji frameworka CherryPy. Na ten temat było sporo dyskusji na grupie pl.comp.lang.python, więc nie będę się powtarzał.

Pylons

O Pylons pisałem wcześniej ale nie w kontekście Django. Moim zdaniem, Pylons jest jedynym frameworkiem, który aktualnie może stanowić być realną alternatywę dla Django.

Wpierw trzeba napisać kilka słów wyjaśnienia dla tych, co myślą że Pylons to jakiś taki zlepek innych bibliotek i frameworków jak TurboGears. Pylons to właściwie nic innego jak framework Myghty tylko, że ze znacznie większym przełożeniem akcentów na paradygmat MVC i podobieństwo do będacych aktualnie “na fali” Railsów.

Twórcy Myghty, mimo bardzo dobrej implementacji i wydajności nie mogli wcześniej przebić się do miłośników Pythona ze względu na zbytnie podobieństwa do Perla (nic dziwnego, Myghty był wzorowany na bardzo dobrym perlowym Masonie, który jest używany na dosyć dużą skalę)

Postanowiono więc troszkę dostosować Myghty dla ludzi lubiących prostotę Pythona i elegancję Ruby on Rails. I tak powstał Pylons.

Zalety Pylonsów.

Myghty pozwala praktycznie na wymianę wszystkich swoich “podzespołów”. W wypadku Pylonsów, użyto resolvera adresów URL opartego na bibliotece Routes. W skrócie można powiedzieć, że Pylons jest tu prawie identyczne jak Rails. “Prawie”, bo Routes jest potężniejszym resolverem od tego co mają Railsy (pozwala np. na używanie większych uogólnień i wyrażeń regularnych).

Elastyczność

Elastyczność Pylonsów jest znacznie większa od Django. W praktyce tam, gdzie stosuje się wstawki PHP do profesjonalnych systemów CMS takich jak RedDot, Pylons dzięki swojej elastyczności i potędze szablonów Myghty znacznie łatwiej może wyprzeć tu PHP. Django jest systemem znacznie bardziej monolitycznym. To jest jego zaletą ale równocześnie także i wadą w wypadkach kiedy potrzebujemy znacznie większej elastyczności.

DRY w kontekście generowania adresów URL

Przewagą korzystania z Routes jest nie tylko prostota budowania adresów url bez konieczności posiadania wiedzy o wyrażeniach regularnych. Największą zaletą jest stosowanie helperów do budowania adresów URL. Identycznie jak w Railsach, jakakolwiek zmiana zasady rozwiązywania adresów, automatycznie przemapuje wszystkie adresy http we wszystkich szablonach. W wypadku Django musimy mozolnie poprawiać wszystkie szablony. W wypadku dużego serwisu jest to kupa, niepotrzebnej roboty2.

Ajax i cała reszta helperów z Ruby on Rails.

Django (jak dotąd) nie posiada wbudowanej implementacji Ajax’a. Nie ma nawet jednomyślności jaką bibliotekę do tego celu mieliby użyć3. Poza tym Pylons implementują wiele z helperów jakie mają Rails dostępne dla swoich szablonów.

Potęga szablonów Myghty

Jeśli komuś przeszkadzają małe możliwości szablonów Django (celowo takie są, bo są kierowane do nieprogramistów) to możliwości jakie dają szablony Myghty są po prostu powalające. Jeśli ktoś mówi, że Django ma dobry cache, to niech się przyjrzy temu co potrafią wykorzystywane w Pylons – szablony Myghty.

Każdy szablon może być komponentem niezależnie keszowanym wg bardzo wyrafinowanych zasad (potężniejszych od tych, co oferuje Django) Regeneracja cache jest także inteligentnie napisana (podobnie jak to robi Skunkweb) Tzn. nigdy nie ma sytuacji, kiedy nadchodzi żądanie wyświetlenia strony i w tym samym momencie trzeba odświeżyć cache (bo się np. przeterminował). Pylons w takim wypadku, odwleka operację odświeżania cache’a i podaje starą zawartość. Regeneracja następuje zaraz za tym requestem. W efekcie nigdy nie ma żadnych “czkawek” w takiej krytycznej sytuacji.

Jeśli ktoś myśli, że to bardzo rzadki przypadek, to niech sobie wyobrazi czy co się dzieje w wypadku naprawdę dużego obciążenia serwera. Pylons/Myghty był od początku tworzony z myśla pracy w sytuacji mocno obciążonego serwera.

Szablony Myghty obsługują nie tylko bardzo potężne mechanizmy includowania (tzn. można przekazać wiele różnych parametrów do includowanego szablonu włącznie z indywidualnymi zasadami keszowania). Myghty obsługują także mechanizm dziedziczenia4.

Automatyczne generowanie dokumentacji.

Pylonsy pozwalają na automatyczne generowanie dokumentacji z projektu. Wykorzystuje do tego celu pythonowe docstringi i zamiast HTML – reStructuredText (które są częścią projektu docutils)

Zapakowanie projektów do uniwersalnego formatu .egg.

Pylonsy potrafią zapakować cały projekt do paczki .egg co umożliwia bardzo łatwą dystrybucję aplikacji pylonsowych. Django tej (jakże pożytecznej) opcji w ogóle nie ma zaimplementowanej!

Zalety Django.

Mimo powyższych zalet Pylonsów, Django ma także kilka swoich, dobrych stron.

Lepsza dokumentacja.

Dzięki swojej monolityczności, Django dysponuje znacznie pełniejszą dokumentacją i jest ona zgromadzona w jednym miejscu. W wypadku Pylonsów dokumentacja jest niezbyt wyczerpująca i porozrzucana. Wynika to w głównej mierze z tego, że Pylons używa gotowych komponentów z innych projektów.

Świetna obsługa formularzy.

Django pracuje na wyższym poziomie abstrakcji odnośnie pracy z formularzami. O ile nie potrzebujemy większej elastyczności, to tą kwestię mają doskonale zaprojektowaną. Jeśli chcemy czegoś więcej, możemy przeciążyć metody jakie używa Django i wzbogacić je w dodatkowe opcje (np. obsługę zdarzeń javascript). Django obsługuje bardzo elegancko walidację formularzy. Pylons TurboGears też) korzysta z FormEncode, ale wydaje mi się, że Django jest tu jeszcze prostsze.

ORM

Djangowy korzysta z własnego ORM (mapera relacyjno-obiektowego) Pylons korzysta z SQLObject. Oba ORM’y są podobne, ale mnie się bardziej podoba ten, co ma Django. Moim zdaniem ma bardziej elegancką składnię. Ma także lepszą dokumentacje. Trochę to dziwne, bo SQLObject nie jest wcale nowym projektem. Mogliby się postarać o lepszą dokumentację, bo ta co jest, jest fatalna.

Panel admina.

To jest wizytówka Django. O ile nie potrzebujemy bardzo specyficznego jego działania, to jest bardzo pomocny. To nie jest żaden “scaffolding” z Railsów. To dopracowana aplikacja końcowa.

Generic views

To kolejna wizytówka Django. Za pomocą konfiguracji adresów (w pliku urls.py) i generic views można budować całe serwisy bez tworzenia ani jednego kontrolera. W ten sposób działa cała strona domowa Django. Osobiście głęboko nie wchodziłem w działanie tych mechanizmów, ale wyglądają bardzo interesująco i mogą daćo gromne przyśpieszenie w budowaniu stron www.

Szersze wdrożenia i silniejsze wsparcie komercyjne.

Django może się poszczycić niezła listą poważnych wdrożeń. Skala złozoności portalów zbudowanych w Django przewyższa to, czym się chwali strona domowa Railsów. Jeśli chodzi o Pylons, to wdrożeń jest bardzo mało. Może brakuje im trochę zmysłu marketingowego jaki mają twórcy Railsów i Turbogears? Na pewno brakuje lepszej, obszerniejszej dokumentacji wraz z większą ilością przykładów.

Na bazie Django oferowany jest także odpłatnie, komercyjny CMS (system zarządania treścią) – Ellington. Specjalizowany jest do większych serwisów, gazet itp. Firmy ceniące sobie wsparcie komercyjne, nie muszą się więc obawiać, że Django to jakiś projekt paru zapaleńców.

Django w rzeczy samej, jest projektem który został wyekstraktowany z komercyjnego projektu Ellington.

No i na koniec, last but not least, twórcom Django udało się pozyskać sympatię samego twórcy języka Pythona – Guido van Rossum’a. Na stronie głównej. Pythona w sekcji Web programming, obok Zope widzimy Django i Turbogears…

Podsumowanie.

Django ma swoje zalety, ale nie jest wolny od wszelkich wad. Jednakże, ogólnie rzecz biorąc, to dobry framework, który raczej nie powinien mieć trudności w zdominowaniu dziedziby budowania aplikacji internetowych w Pythonie.

Jednak tam, gdzie liczy się większa elastyczność i gdzie monolityczność Django jest nie do zaakceptowania, głównym moim faworytem jest Pylons. To jedyna realna alternatywa dla Django5.

-

1 Megaframework – środowisko zbudowane z gotowych, innych rozwiązań. Turbogears korzysta m.in. z frameworku CherryPy, szablonów Kid, SQLObject jako ORM (mapera relacyjno obiektowego).

2 Developerzy Django są przyciskani do muru żądaniami aby wprowadzić jakiś mechanizm zastępujący ręczne wpisywanie adresów, i nie wykluczają, że użyją Routes jako alternatywnego resolvera URL. Ale nie wiadomo kiedy i czy w ogóle to zrobią.

3 Nie wiem dlaczego nie chca użyć gotowych bibliotek jakie już używa Pylons. Po co odkrywać na nowo koło?

4 Dziedziczenie działa trochę inaczej niż w Django i Cheetah. Np. nie ma tu, tak wygodnych “bloków” do przeciążania. Ale jest za to coś, co przypomina “akwizycję” znaną z Zope. Tzn. w Myghty można wrzucić do folderu z szablonami plik “autohandler” i automatycznie staje się szablonem bazowym dla wszystkich szablonów (bez dotykania ich zawartości!) To pozwala na wygodne zarządzanie całymi grupami szablonów.

5 Poza oczywiście Zope czy Plone, ale to jest trochę inna bajka i temat na oddzielne rozważania. :)

Posted in ,  | Tagi , ,  | 1 comment

Django - zabójcza aplikacja. Część III.

Opublikowane przez Jarosław Zabiełło Mon, 12 Jun 2006 20:29:00 GMT

W części pierwszej i drugiej opisałem podstawowe zalety Pythona i Django. Pora ma malutką demonstrację działającej aplikacji. Będzie to mała, ale poręczna wyszukiwarka biblijna (choć kod można łatwo zaadoptować do innych treści rzecz jasna). Jako bazę użyję MySQL5. Zakładam także, że docelowo projekt będzie chodził pod Linuksem. Natomiast będzie budowany i testowany pod Windowsami. Taki model pracy jest często spotykany. Django oczywiście w wersji 0.95 SVN, czyli wersji pozbawionej wcześniejszej “magii” (kod Django jest teraz bardziej jawny i oparty na standardowych mechanizmach Pythona)

Zaczynamy!

Na początku musimy stworzyć projekt oraz aplikację (Django w ramach jednego projektu potrafi obsługiwać wiele aplikacji)

admin-django startptoject myproject
cd myproject
manage.py startapp biblia

Zauważmy, że skrypt admin-django uruchamiamy tylko raz. Potem już posługujemy się skryptem manage.py. Dzięki temu odpada nam kombinowanie z definiowaniem zmiennej systemowej DJANGO_SETTINGS_MODULE. Listę wszystkich dostępny opcji, zarówno dla django-admin.py jak i manage.py, uzyskamy uruchamiając te skrypty bez żadnego parametru.

Wstępna konfiguracja.

Mamy zatem stworzony katalog z projektem i aplikacją. Wpierw trzeba skonfigurować plik settings.py2. Na początku pliku ustawiamy:
import sys

if sys.platform == 'win32':
    DEBUG = True
else:
    DEBUG = False
TEMPLATE_DEBUG = DEBUG

ADMINS = (
    ('Administrator', '[email protected]'),
    )

MANAGERS = ADMINS

DATABASE_ENGINE = 'mysql'
DATABASE_NAME = 'myproject' 
if sys.platform == 'win32':
    DATABASE_USER = 'root'
    DATABASE_PASSWORD = ''
else:
    DATABASE_USER = 'user_na_linuksie'
    DATABASE_PASSWORD = 'haslo_pod_linuksem'

if sys.platform == 'win32':
    DATABASE_HOST = '' # domyslnie bedzie localhost
else:
    # pod linuksem zwykle korzystamy z szybkiego gniazda unix
    DATABASE_HOST = '/var/run/mysqld/mysqld.sock'
DATABASE_PORT = '' # czyli domyślnie będzie 3306

ENABLE_PSYCO = False

Kilka istotnych uwag.

  • Adres mailowy admina nie jest taki zupełnie nieistotny. W wypadku kiedy aplikacja na serwerze produkcyjnym się wyłoży na jakimś wyjątku, na ten adres jest automatycznie wysyłany mail z wszystkimi szczegółami. Trudno śledzić, czy w którymś momencie aplikacja się nie wywali. Django zadba, aby żaden taki wypadek nie umknął naszej uwadze1.
  • Należy sobie ustawić odpowiednie hasła dostępu do MySQL5 pod windozą i pod linuksem.
  • Ważne jest, aby wyłączyć obsługę akceleratora Psycho. To jeszcze nie jest dobrze przetestowane. Jak to miałem włączone, to pod Linuksem miałem problemy z działaniem djangowego panelu admina.
  • Musimy ręcznie sobie stworzyć (jeśli tego nie zrobiliśmy) bazę. Django za nas bazy nie stworzy. W naszym przypadku, tabelkę na której będziemy pracować mam już gotową w bazie. Tu jest jej spakowany dump który trzeba sobie załadować.

Pozostałe ustawienia:

LANGUAGE_CODE = 'pl' # domyślnie był angielski
#... 
if sys.platform == 'win32':
    MEDIA_ROOT = r'H:/home/myproject/biblia/public'
else:
    MEDIA_ROOT = r'/home/myproject/biblia/public'
#... 
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'myproject.biblia',
)

Do słownika INSTALLED_APPS musimy dodać naszą aplikację aby można było jej używać. Mówi o tym ostatnia linijka powyższego kodu. Zmienna MEDIA_ROOT musi być bezwzględną ścieżką do plików statycznych. Pod serwerem www odpowiada to zmiennej DOCUMENT_ROOT, czyli miejsca od którego serwer www cokolwiek widzi.

Interaktywne testowanie Django z poziomu konsoli.

W każdej chwili możemy odpalić interaktywny dostęp do środowiska Django za pomocą komendy:
manage.py shell
Warto sobie wcześniej zainstalować ipythona, bo Django domyślnie próbuje uruchomić jego zamiast standardowy interpreter. Dzięki ipythonowi mamy wspaniałe uzupełnianie metod do obiektów + historia wczesniejszych operacji, która nie znika wraz z zamknięciem ipythona.

Serwer.

Możemy odpalić wbudowany serwer www za pomocą komendy:

manage.py runserver

Domyślnie serwer się podniesie pod adresem http://127.0.0.1:8000. Można zmienić zarówno port jak i adres jak ktoś chce, rzecz jasna. Odpal manage.py (bez parametrów) to się dowiesz, jak.

ORM

No dobrze, pora na coś bardziej interesującego. Django operuje na relacyjnej bazie danych za pomocą swojego ORM (mapera relacyjno-obiektowego) Zalet takiego podejścia jest wiele. Wspomnę tylko o tym, obiektowo można znacznie lepiej opisać dane modelu biznesowego niż to zrobić może czysty SQL ze swoimi kluczami obcymi i trigerami. Django wymaga aby w pliku myproject/biblia/models.py zdefiniować dane dla ORM’a. Zasada jest prosta: klasa odpowiada tabeli, a atrybuty klasy – jej polom. Aby jednak sobie uprościć życie, można posłużyć się skryptem manage.py.

Poniższy skrypt robi introspekcję bazy i wygeneruje pythonowe definicje wszystkich jej tabel. Jako parametr podajemy nazwę naszej aplikacji (mówiłem że Django jest zbudowane do pracy z wieloma aplikacjami w ramach projektu) Możemy spokojnie zamazać plik models.py bo po stworzeniu projektu nic tam szczególnego nie ma.

H:\home\myproject>manage.py inspectdb biblia > biblia/models.py

Mamy zatem naszą wstępną obiektową definicję dla nasej tabelki:

from django.db import models

class BibliaGdanska(models.Model):
    id = models.IntegerField(primary_key=True)
    ref = models.CharField(unique=True, maxlength=9)
    chapter_nr = models.IntegerField(unique=True)
    verse_nr = models.IntegerField(unique=True)
    verse = models.TextField()
    class Meta:
        db_table = 'biblia_gdanska'

Może sprawdźmy, czy to działa za pomocą interaktywnej konsoli:

H:\home\myproject>manage.py shell
Deleting alias <dir>, it's a Python keyword or builtin.
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.7.1.fix1 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from myproject.biblia.models import BibliaGdanska
In [2]: BibliaGdanska.objects.count()
Out[2]: 31151L

Bingo! Widać, że działa.

Kontroler i szablon.

Teraz pora na naszą aplikację internetową. Musimy stworzyć kontroler. Z tajemniczych powodów developerzy Django zamiast MVC (model-view-controller) stosują nazwę MTV (model-template-view). W każdym razie, to co zwykle nazywamy kontrolerem oni nazywają widokiem (view) a to co nazywamy widokiem, oni nazywają szablonem. Mniejsza o nazwy. Kontroler tworzymy w pliku myproject/biblia/views.py

#-*- coding: utf-8 -*-

from django.shortcuts import render_to_response

def home(request):
    return render_to_response('home.html')

Plik home.html jest szablonem. Stwórzmy na razie ten plik z napisem “alama kota” w środku, aby zobaczyć, czy to działa. Plik powinien leżeć w myproject/biblia/templates/home.html.

Rozwiązywanie adresów URL

Wpierw musimy powiedzieć Django aby wiedział, gdzie ma szukać naszego kontrolera. W tym celu dodajmy taką treść do pliku myproject/biblia/urls.py

from django.conf.urls.defaults import *
from settings import DEBUG, MEDIA_ROOT

urlpatterns = patterns('',
    (r'', include('myproject.biblia.urls')),
    #(r'^admin/', include('django.contrib.admin.urls')),
)

if DEBUG:
    urlpatterns += patterns('',
        (r'^images/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/images', 'show_indexes': True}),
        (r'^stylesheets/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/stylesheets', 'show_indexes': True}),
        (r'^javascripts/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/javascripts', 'show_indexes': True}),
    )    

Powyższy kod robi kilka rzeczy.

  • Wiąże domyślną stronę z naszym projektem. Wejście na http://127.0.0.1:8000/ przekaże sterowanie do pliku myproject/biblia/urls.py (który za chwilkę stworzymy).
  • Takie podejście powoduje że każda aplikacja może posiadać swoje niezależne zasady rozwiązywania adresu url. Dlatego oddelegowujemy obsługę URL’i do pliku urls.py wewnątrz naszej aplikacji.
  • Zakomentowaną linijkę z panelem admina na razie zostawmy, wrócę do tego później.
  • Ostatnie linijki są potrzebne do tego, aby Django obsługiwał nie tylko plik Pythona ale także obrazki, style kaskadowe i skrypty języka JavaScript. Przyjąłem (wzorując się na Railsach) że są one odpowiednio w folderach myproject/biblia/public/images, myproject/biblia/public/stylesheets i myproject/biblia/public/javascripts.
  • Dlaczego ten kod jest dostępny tylko dla DEBUG=True? Ano dlatego, że do pracy developerskiej pod windozą nie potrzebujemy żadnego Apache’a ani Lighttpd. Wystarczy wbudowany serwer www jaki dostarcza Django. Natomiast na serwerze produkcyjnym, gdzie chcemy uzyskać największą wydajność, lepiej aby te pliki podawał serwer www i Django się tego nie dotykało. Tak będzie najlepiej i najszybciej.

Pozostał do skonfigurowania plik myproject/biblia/urls.py

from django.conf.urls.defaults import *

urlpatterns = patterns('myproject.biblia.views',
    (r'^$', 'home'),
   #(r'^admin/', include('django.contrib.admin.urls')),
)

Tu również mamy zakomentowany panel admina. Zostawmy go na razie w spokoju. Można uruchamiać: http://127.0.0.1:8000/ powinno wyświetlić nasz szablon z treścią “ala ma kota”. No to może lepiej aby wyświetlić coś bardziej atrakcyjnego. Zbudujmy formularz.

Formularz

Formularze są zmorą większości programistów. Są upierdliwe w obłudze, walidacji i co gorsze, ciągle z nimi mamy do czynienia. Aby ułatwić nam życie, Django stosuje specjalną technikę tzw. manipulatorów, aby praca z formularzami była miła i przyjemna. Muszę przyznać, że to była jedna z ważniejszych rzeczy, jaka mnie przyciągnęła do Django. Pylons i Rails mają swoje helpery, ale nie są one aż tak wygodne jak to, co oferuje Django3.

Zobaczmy jak się używa manipulatora. Wpierw zmieńmy nasz szablon (plik: myproject/biblia/templates/home.html). Będzie to prosty formularz z jednym polem gdzie wpiszemy wyszukiwane słowo.

<form method="get" action="">

    {% if form.q.errors %} 
        <div class="formError">
          Wpisz frazę o długości min. 3 znaków.
        </div>
    {% endif %}

    {{ form.q }}
    <input type="submit" value="szukaj" />

</form>

Manipulator.

Teraz pora na manipulator. Musimy stworzyć plik myproject/biblia/manipulators.py o przykładowej treści:

import re
from django import forms
from django.core import validators

class SzukajManipulator(forms.Manipulator):
    def __init__(self):
        regex = re.compile(r'(\w{3,})', re.U)
        self.fields = (
            forms.TextField(
                field_name='q',
                length=30,
                maxlength=255,
                is_required=True,
                validator_list=[validators.MatchesRegularExpression(regex)]
                ),
            )

Teraz zepnijmy wszystko razem w djangowym widoku (naszym kontrolerze). Zmieńmy treść pliku myproject/biblia/views.py na:

#-*- coding: utf-8 -*-

from django.shortcuts import render_to_response
from django import forms
from manipulators import SzukajManipulator
from models import BibliaGdanska

def home(request):
    recordset = []
    errors = _GET = {}
    manipulator = SzukajManipulator()
    # tworzę kopię parametrów przekazanych z formularza
    _GET = request.GET.copy()
    if request.GET:
        # sprawdzam czy formularz nie ma błędów
        errors = manipulator.get_validation_errors(_GET)
        if not errors:
            manipulator.do_html2python(_GET)
           # wyszukuję cytaty 
           recordset = BibliaGdanska.objects.all().filter(verse__icontains=_GET['q'])
    form = forms.FormWrapper(manipulator, _GET, errors)
    return render_to_response(
        'home.html',
        {'request': request,
         'form': form,
         'recordset': recordset,
         'hits': len(recordset)})

Wyświetlenie wyników.

Aplikacja działa4, ale nie widać wyników. Wyniki wyświetlimy w tym samym szablonie. Teraz będzie wyglądał tak:

<form method="get" action="">
    {% if form.q.errors %} 
        <div class="formError">
          Wpisz frazę o długości min. 3 znaków.
        </div>
    {% endif %}    
    {{ form.q }}
    <input type="submit" value="szukaj" />   
</form>

{% if recordset %}
    <div>
      Znaleziono <b>{{ hits }}</b> wersetów:
    </div>
    <ol>
    {% for row in recordset %}
        <li>
            {{ row.ref}} {{ row.chapter_nr}}:{{ row.verse_nr }} 
            &quot;{{ row.verse }}&quot;
        </li>
    {% endfor %}
    </ol>
{% else %}
    Nie znaleziono wersetów dla frazy {{ request.GET.q }} :(
{% endif %}

Program powinien działać. Jednak w wypadku znalezienia mniej niż 5 wersetów niezbyt po polsku zabrzmi wynik, np. “Znaleziono 1 wersetów”. W wypadku języka angielskiego możemy zmodyfikować ten fragment szablonu za pomocą modyfikatora pluralize5. Polski jezyk jest jednak znacznie bardziej wyrafinowany od angielskiego, bo używa 2 różnych form dla liczby mnogiej: 1 werset, 2 wersety, 5 wersetów. Na szczęście możemy sobie zmienić sposób pracy tego modyfikatora.

Przeciążene modyfikatora

Aby nadpisać istniejący modyfikator lub dodać nowy, własny, należy stworzyć wpierw folder myproject/biblia/templatetags z pustym plikiem o nazwie init.py. Dodajemy tam drugi plik, o nazwie, powiedzmy: plugins.py o następującej treści:

import re, sys
from django import  template

register = template.Library()

@register.filter(name='pluralize')
def pluralize(value):
    """Polish implementation"""
    try:
        if int(value) in (2,3,4):
            return 'y'
        elif int(value) >= 5:
            return '\xc3\xb3w' # utf8
    except ValueError: # invalid string that's not a number
        pass
    except TypeError:
        try:
            if int(value) in (2,3,4):
                return 'y'
            elif int(value) >= 5:
                return '\xc3\xb3w' # utf8            
        except TypeError: 
            pass
    return ''

Zamiast polskiego znaczka ó, użyłem zapisu ’\xc3\xb3’ bo to wartość utf-8 i taki zapis jest niezależny od tego, w czym otworzymy plik. Nikt przypadkowo nie popsuje nam polskich ogonków.

Aby to zadziałało, musimy gdzieś na początku w szablonie dodać linijkę, która załaduje nam nową definicję modyfikatora pluralize.

{% load plugins %}

Kontekst i dziedziczenie szablonów.

Nasz kod działa, ale kod HTML jest daleki od doskonałości. Dobrze byłoby dodac jakiś nagłówek, stopkę itp. Django skopiowało z pythonowych szablonów Cheetah bardzo ciekawy sposób tworzenia kolejnych szablonów za pomocą obiektowego przeciążania starych.

Stwórzmy nasz szablon bazowy (myproject/biblia/templates/base.html)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
        <title>Przykład aplikacji w Django</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    </head>
    <body>    
         <h3>Wyszukiwarka Biblii Gdańskiej</h3>
         <h4> (przykład aplikacji w Django)</h4>
          <div id="main">
          {% block main %}
              tutaj będzie jakaś nowa treść   
          {% endblock %}
          </div>
        <hr size="1" />
        <div>
        &copy; 2006 
        <a href="http://blog.zabiello.com">Jarosław Zabiełło</a>. 
        </div>
    </div>
</body>
</html>

Ostatecznie szablon home.html będzie więc wyglądał tak:

{% extends "base.html" %}

{% load plugins %}

{% block main %}

<form method="get" action="">
    {% if form.q.errors %} 
        <p class="formError">Wpisz frazę o długości min. 3  "znaków".</p>
    {% endif %}    
    {{ form.q }}
    <input type="submit" value="szukaj" />   
</form>

{% if recordset %}
    <div>Znaleziono <b>{{ hits }}</b> werset{{ hits|pluralize }}:</div>
    <ol>
    {% for row in recordset %}
        <li>
            {{ row.ref}} {{ row.chapter_nr}}:{{ row.verse_nr }} 
            &quot;{{ row.verse }}&quot;
        </li>
    {% endfor %}
    </ol>
{% else %}
    <p>Nie znaleziono wersetów dla frazy <b>{{ request.GET.q }}</b></p>
{% endif %}

{% endblock %}

Szablon oparty na innym szablonie implementuje dowolne bloki z poprzedniego. Cały pozostały kontekst jest automatycznie dziedziczony. Takie podejście bardzo skraca wielkość szablonów i czyni je jeszcze bardziej czytelnymi.

Podświetlanie szukanej frazy.

Do pliku plugins.py gdzie wcześniej zmieniliśmy definicję modyfikatora pluralize, dodajmy kolejny. Będzie nam podświetlał w wersetach to, co szukamy.

@register.filter(name='highlight')
def highlight(s, q):
    if not isinstance(s, unicode): 
        s = unicode(s, 'utf-8')
    s = re. compile('('+re.escape(q)+')', re.U|re.I).sub(r'<strong class="highlight">\1</strong>', s).encode('utf-8')
    return s    
W środku zastosowano sztuczkę z przełączeniem się na obiekty Unicode, aby mieć pewność że polskie ogonki duże i małe będą tak samo traktowane. W szablonie home.html wystarczy zmienić jedną linijkę:
{{ row.verse|highlight:request.GET.q }}

Co dalej?

Mam nadzieję, że artykuł przybliżył trochę praktyczną stronę uzywania Django. To dobry i szybki framework. Przykładowe serwisy jakie w nim napisano są znacznie bardziej skomplikowane i większe niż te, co widać na stronie Rails. Django został napisany do szybkiego tworzenia całkiem sporych serwisów

W kolejnym artykule, pokażę jak sobie wygodnie skonfigurować panel admina który udostępnia Django. Panel admina nie jest żadnym prostym rusztowaniem (scaffolding) do modyfikacji bazy. To kompletna aplikacja dla użytkownika końcowego. Bardzo wygodna i łatwa w użyciu. Panel Django jest kolejną z jego cech, która daje mu wyraźną przewagę w stosunku do konkurencji.

-

1 Kompletnie inaczej od 99% aplikacji pehapowych, gdzie o błędach dowiadujemy się najczęściej dopiero wtedy, jak wszystko leży, albo jak ktoś łaskawie nas poinformuje.

2 Jak widać, to normalny plik Pythona. Żadne chore XML i inne formaty nie są w ogóle nam potrzebne – Python jest wystarczająco dobry, aby łatwo i przyjemnie prezentować zagnieżdżone struktury. Inne języki, jak np. Java nie zbyt dobrze nadają się do takich rzeczy, dlatego muszą posiłkować się XML.

3 Tzn. Railsy się już poprawiły, bo jest plugin który dodaje im taką samą funkcjonalność jak Django. Nazywa się active-form i można go zainstalować prosto spod RadRails’a.

4 Kto nie wierzy, niech sobie wpisze print recordset po operacji wyszukiwania. Na konsoli serwera www wyświetli mu się zawartość tej zmiennej.

5 Szablony Django korzystają ze składni modyfikatorów podobnych do pehapowych Smartów.

Posted in ,  | Tagi  | 8 comments

Django na Lighttpd + FastCGI

Opublikowane przez Jarosław Zabiełło Wed, 31 May 2006 21:16:00 GMT

Okazuje się, że uruchomienie Django na serwerze Lighttpd i FastCGI nie jest wcale trudne. Taki zestaw pożera znacznie mniej zasobów komputera niż Apache i mod_python. Efekt dostępny jest tutaj. Projekt Django został stworzony w /home/django_project. Użyłem Django w wersji SVN (pozbawionej “magii”), MySQL 5, Python 2.4.3 oraz system to Debian 3.1. Cała konfiguracja to:

Plik lighttpd.conf (aktualny):

$HTTP["host"] == "koran.apologetyka.com" {
  server.document-root = "/home/django_project/koran/public"
  url.rewrite-once = (
    "^/(media|stylesheets|images|javascripts).*" => "$0",
    "^/admin/(.*)$" => "/django-admin.fcgi/admin/$1",
    "^/(.*)$" => "/django.fcgi/$1"
  )
  fastcgi.server = (
    "/django.fcgi" => (
      (
        "bin-path" => "/home/django_project/django.fcgi",
        "socket" => "/tmp/django.sock",
        "check-local" => "disable",
        "min-procs" => 1,
        "max-procs" => 1,
      )
    ),
    "/django-admin.fcgi" => (
      (
        "bin-path" => "/home/django_project/django-admin.fcgi",
        "socket" => "/tmp/django-admin.sock",
        "check-local" => "disable",
        "min-procs" => 1,
        "max-procs" => 1,
      )
    )
  )
  server.error-handler-404 = "/django.fcgi"
}
Plik django.fcgi:
#!/usr/local/bin/python2.4
import os, sys
sys.path += ['/home'] 
from flup.server.fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler
os.environ['DJANGO_SETTINGS_MODULE'] = 'django_project.settings'
WSGIServer(WSGIHandler()).run()

Później opiszę dokładniej sam kod Django.

Posted in  | Tagi , ,  | 4 comments

Django - zabójcza aplikacja. Część II.

Opublikowane przez Jarosław Zabiełło Sat, 27 May 2006 16:53:00 GMT

Jak wspomniałem w pierwszej części, Django jest frameworkiem który wyrósł na bazie zastosowań komercyjnych. Zanim twórcy zdecydowali się otworzyć i udostępnić jego kod na zasadach open-source, Django był już wcześniej intensywnie używany w zastosowaniach komercyjnych1.

Przewaga Django

Wcześniej pisałem o zaletach Pylonsów. Jednakże, po moich ostatnich testach z “oczyszczoną z magii” wersją Django muszę przyznać, że jest to chyba aktualnie najlepszy framework, z jakim miałem do czynienia w tej klasie zastosowań.

Django oferuje znacznie więcej helperów i udogodnień niż świetny Pylons. Poza wbudowaną autoryzacją i zaawansowanym panelem admina, Django pracuje na wyższym poziomie abstrakcji niż Pylons czy Rails. Zamiast prostych generatorów HTML dla formularzy, Django wprowadza kontrolki, które pracują na wyższym poziomie abstrakcji. Bardzo przejrzyście obsługuje także walidowanie formularzy. Kto się męczył z obsługa formularzy, nareszcie odetchnie z ulgą. Idea manipulatorów bardzo upraszcza pisanie obsługi formularzy. Ktoś powie, że to można sobie samemu napisać. Owszem. Ale Django daje ci to już gotowe. Uruchamiasz i używasz zamiast tracić czas.

Sprawa dokumentacji, i promocji w ogólności, w wypadku wiekszości frameworków Pythona jest po prostu żenująca. Zdumiewające jest jak to jest możliwe, że nawet tak potężne środowisko jakim jest Zope ma tak słabą stronę i chaotycznie porozrzucaną dokumentację.

Kilka mądrych posunięć.

Pierwszą, mądrą rzeczą, jaką zrobiono po otwarciu kodu Django, było skupienie się na pisaniu dokumentacji. Dzięki temu, Django ma dziś jedną z najlepszych dokumentacji pomiędzy pythonowymi frameworkami. Bez dobrej dokumentacji, trudno aby ktokolwiek się zainteresował projektem. Dokumentacja Django nie równa się jeszcze temu co jest dostępne dla Railsów ale jest i tak lepsza od większości frameworków pythonowych.

Drugim, równie dobrym posunięciem, był refaktoring pierwotnego kodu zgodnie z zasadami filozofii Pythona. Wg zasady, ze działanie jawne jest lepsze od domyślnego, nastąpił proces usuwania “magii” z kodu. Np. teraz zamiast tajemniczych prefiksów do nazw dodatkowych metod modelu, można tworzyć je bardziej naturalnie – jako metody klasowe Pythona. Aktualnie wersja pozbawiona “magii” jest dostępna w repozytorium SVN. Frameworkiem, który jest mocno przeładowany “magicznymi” metodami jest Rails. Może to i ładnie wygląda, ale filozofia Python potępia takie podejście, gdyż to utrudnia programiście w szybkim zorientowaniu się o co chodzi w kodzie.

Trzecim, dobrym pomysłem, jest możliwości testowania środowiska w sposób interaktywny w interpreterze. Domyślne uruchomia się to w miejscu stworzonego projektu za pomocą komendy: manage.py shell. Ta komenda odpala ipythona (ile mamy go zainstalowanego) i udostępnia w nim łatwy dostep do całego środowiska Django, jego modeli, bibliotek itp. Ipython to podrasowana wersja interpretera Pythona. Świetnie uzupełnia metody, ma dobrą historię edycji i cały szereg dodatkowych możliwości2.

Przykładem różnic w podejściu do kwestii jawności i “magii” jest inny sposób podejścia do modułów i przestrzeni nazw między Pythonem a Ruby. Python stosuje przejrzystą do bólu zasadę: moduł to po prostu plik. Wszystko co w nim jest, automatycznie jest ładowane do przestrzeni nazw określonej nazwą pliku. Python umożliwia także selektywne ładowanie z modułu wybranych klas i metod. Wszystko jest niezmiernie czytelne.

W wypadku Rubiego mamy tylko wyrażenie require które odpala i włącza plik. Przy czym z tego kodu kompletnie nic nie można wywnioskować, nawet tego, czy w środku zawiera jakikolwiek moduł. Trzeba zajrzeć aby się dowiedzieć, co zostało dorzucone do naszej przestrzeni nazw. Pythonowa zasada “jawności ponad domyślaniem się”, w tym wypadku stanowi kolejny argument na rzecz większej produktywności Pythona wobec Rubiego.

Django jest szybsze.

Django jest cholernie szybkie. Nie tylko dlatego, że korzysta z Pythona i bytecodu, ale także dlatego, że jest dobrze napisane. Np. szablony Django są szybsze od Cheetah i nie wymagają żadnej dodatkowej kompilacji! Wszystkie wyrażenia regularne używane np. do parsowania adresów URL są jednokrotnie kompilowane, są więc wykonywane bardzo szybko. Mało tego, w Django można włączyć obsługę akceleratora Psyco. Wystarczy w mojprojekt/settings.py dodać linijkę ENABLE_PSYCO = True. Railsy nie mają wydajnościowo szans z Django. Chyba tylko Pylons może się zbliżyć i nawiązać jakąś walkę na tym polu. Rails i PHP są tu bez szans.

Django pracuje na wyższym poziomie abstrakcji.

Obsługa formularzy, ich walidacja są zwykle uciążliwe i programiści mają z nimi ciągle do czynienia. Rails oraz Pylons (który to skopiował z Railsów) udostępniają cała grupę wygodnych helperów do generowania kodu html np. do formularzy. Mimo, że to jest na pewno lepsze podejście od bezpośredniego dłubania w kodzie HTML, to Django oferuje coś znacznie lepszego – kontrolki. Coś, co używa np. ASP.NET, tylko że znacznie prostsze w obsłudze.

Djangowe modele korzystające z mapowania relacyjno-obiektowego (ORM) również pracują na wyższym poziomie abstrakcji niż tylko odwzorowania prostych typów danych jakie posiada relacyjna baza danych. Uważam też, że djangowy ORM jest lepszy od SQLObject. Nie dość że ma znacznie lepszą dokumentację, to na dodatek ma więcej możliwości. Np. niby taka trywialna sprawa, ale jak w SQLObject odwzorować takie zapytanie (z takim samym traktowaniem dużych i małych polskich znaków)?

SELECT * FROM tabelka WHERE pole LIKE '%wartość%'

W Django to jest trywialna operacja i na dodatek operuje na generatorze:

for row in Tabelka.objects.filter(pole__icontains="wartość"):
    print row.pole

W kolejnych częściach, zajmę się przykładem stworzenia prostej aplikacji internetowej. Pokażę też jak przeciążyć modyfikator pluralize aby uwzględniał polskie znaki, i jak obsługiwać formularze (włącznie z dynamicznym budowaniem ich treści)

-

1 Poza całym szeregiem złożonych portali, developerzy Django sprzedają Elington – profesjonalny CMS zbudowany na bazie tego frameworku. Oczywiście Railsy również powstały pierwotnie jako projekt do zastosowań komercyjnych. Stąd nic dziwnego, że oba środowiska oferują sporo interesujących rozwiązań.

2 Aby działały uzupełniania metod (po wciśnięciu klawisza Tab) trzeba doinstalować moduł readline oraz ctypes. Jeśli interpreter nie wyrzuca wyjątku po wpisaniu import readline, to znaczy że mamy go już zainstalowanego.

(Zobacz: część III)

Posted in ,  | Tagi  | 10 comments

Django - zabójcza aplikacja.

Opublikowane przez Jarosław Zabiełło Sat, 27 May 2006 08:17:00 GMT

Muszę przyznać, że podoba mi się zarówno sposób, jak i kierunek, w którym rozwijany jest pythonowy framework Django. Nie jest to kolejny domowy projekt tworzony w ramach hobby (jak to było z CherryPy). Django powstawało od razu z założeniem pracy w ciężkim środowisku produkcyjnym. Ostatnio napisałem sobie (w ramach zabawy) pewną aplikację w Django i muszę przyznać, że praca z Django jest faktycznie komfortowa. Wyższa niż w Pylons, i wyższa nawet niż w Railsach. Aby tekst nie był za długi, podzielę go na kilka mniejszych tekstów. Przedstawię swoje spostrzeżenia co do Pythona jako języka na tle Rubiego. Potem opiszę powody dla których Django ma wielkie szanse stać się killer application dla Pythona. Oraz w kolejnych częściach opiszę krok po kroku tworzenie konkretnej aplikacji w Django. Dziś będzie krótko o Pythonie.

Przewaga Pythona

Gdy zaczynam mówić o Django, to od razu nasuwa mi się porównanie do Ruby on Rails. Django jest oparty na języku Python, a Rails na języku Ruby. Co by nie mówić o zaletach Rubiego, to Python posiada kilka cech, które moim zdaniem, stawiają go wyżej1:

Python jest szybszy.

To po prostu jest fakt i to widać gołym okiem. Python automatycznie kompiluje każdy moduł do bytecodu. To jest operacja całkowicie przezroczysta dla programisty. Bytecode przy dużym projekcie składającym się w setek plików przyśpiesza znacznie czas ładowania kodu i może od biedy służyć również jako proste zabezpieczenie źródeł. Python jest szybszy nie tylko od Rubiego, ale także od PHP. Robiłem kiedyś porównanie prostej aplikacji w mod_php5 vs Myghty. Zdziwiło mnie wtedy to, że Python był tu szybszy, bo PHP jest zoptymalizowany do szybkiego wykonywania prostych skryptów. Oczywiście, im większy kod, tym rośnie przewaga Pythona z powodu użycia bytecodu2.

Python jest łatwiejszy do nauki.

Pythona łatwiej można się nauczyć i posługiwać niż Rubiego czy nawet PHP (sic!). To jest bardzo ważny punkt, bo dotyczy kluczowej kwestii jaką jest produktywność programisty.

Filozofią Pythona jest aby było jak najmniej możliwych dróg do rozwiązania tego samego problemu. Z tego wynika, że Python stara się implementować jak najmniejszą ilość funkcji i metod. Znacznie to ułatwia poruszanie się po tych metodach. W wypadku Rubiego, nie dość, że mamy znacznie więcej metod na obiekt, to na dodatek, lista metod jest dodatkowo zaśmiecona aliasami. W Ruby mamy po kilka metod, które wykonują to samo. Po kilka konstrukcji językowych, które robią to samo. Widać tu korzenie fascynacji Perlem. Ale dla programistów to jest uciążliwość.

Python jest bardziej produktywny.

Dodatkowym czynnikiem ułatwiającym szybką prace, jest integracja prostego mechanizmu dokumentacji kodu na poziomie składni Pythona. Mowa o docstringach. W praktyce znaczy to, że prawie wszystkie edytory IDE (których jest sporo, są darmowe i są bardzo dobre jak na tę klasę języków) nie tylko rozwijają mniej metod, ale także wyświetlają ich zintegrowaną dokumentację. Efektem jest znacznie mniej czasu traconego na zaglądanie do dokumentacji czy książek. To duża, odczuwalna różnica. Mniej rzeczy do zapamiętania, podpowiedzi do składni na każdym kroku, to musi się odbijac na produktywności tworzenia kodu3.

Python ma pełną obsługę Unicode.

Pełnej obsługi Unicode nie ma ani PHP ani Ruby. Obsługują co najwyżej UTF-8 i to w ograniczonym zakresie. Np. próby konwersji znaków ze standardu cp1250 (typowa sytuacja dla polskiego serwera MSSQL) do latin2 (typowe dla serwera MySQL w internecie) skazane są na korzystanie z biblioteki iconv, co jest dosyć chorym rozwiązaniem. Chorym, bo iconv nie umie dawać sobie rady z wieloma znakami, które nie mają odpowiednika w standarcie latin2. Chodzi nie o polskie ogonki, ale o różnego rodzaju długie myślniki, polskie, dolne cudzysłowy itp.

>>> s = " „To jest jakiś tekst — spróbuj to skonwertować z cp1250 do latin2.”  "
' \x84To jest jaki\x9c tekst \x97 spr\xf3buj to skonwertowa\xe6 z cp1250 do latin2.\x94  '
>>> s = " „To jest jakiś tekst — spróbuj to skonwertować z cp1250 do latin2.”  "
>>> s
' \x84To jest jaki\x9c tekst \x97 spr\xf3buj to skonwertowa\xe6 z cp1250 do latin2.\x94  '
>>> u = unicode(s, 'cp1250')
>>> u
u' \u201eTo jest jaki\u015b tekst \u2014 spr\xf3buj to skonwertowa\u0107 z cp1250 do latin2.\u201d  '
>>> print uTo jest jakiś tekstspróbuj to skonwertować z cp1250 do latin2.”  
>>> latin2 = u.encode('iso-8859-2', 'xmlcharrefreplace')
>>> latin2
' &#8222;To jest jaki\xb6 tekst &#8212; spr\xf3buj to skonwertowa\xe6 z cp1250 do latin2.&#8221;  '

Nie chodzi tylko o konwersje znaków. Dzięki Unicode, w Pythonie możesz dokonywać rzeczy bardzo trudnych do uzyskania w PHP czy Ruby. Operacje na tekście potrafią poprawnie traktować polskie znaczki. Np. napisanie funkcji implementującej podświetlanie wyszukiwanych słów bez względy na to czy uzyto dużych, czy małych polskich znaków. Dla bazy SQL to żaden problem4 ale dla kodu?

Chcielibyśmy aby wyrażeniem regularnym podmienić jakieś słowa zawierające polskie znaczkiNp. wyrażenia regularne umieją reagować poprawnie na polskie ogonki!

#-*- coding: utf-8 -*-
import re
def highlight(tekst, slowo, encoding):
    if not isinstance(tekst, unicode):
        tekst = unicode(tekst, encoding)
    if not isinstance(slowo, unicode):
        slowo = unicode(slowo, encoding)
    replace = re.compile('('+re.escape(slowo)+')', re.I|re.U).sub
    return replace(r'<b>\1</b>', tekst)
print
print highlight("podświetl gęś GĘŚ, GęŚ", "gęś", 'cp1250') 
# => podświetl <b>gęś</b> <b>GĘŚ</b>, <b>GęŚ</b>

Jeszcze jedno. Microsoft “uszczęśliwił” nasz kilkoma standardami kodowania polskich znaków. Inny jest dla windows (cp1250) a inny dla konsoli okienka DOS (cp852). Python pozwala całkowicie zapomnieć o stringach i kodowaniach. Po prostu należy pracować na obiektach Unicode. Powtarzam: obiektach Unicode a nie stringach UTF-8, bo to nie to samo. Instrukcja print wyświetli poprawnie polskie znaki, jeśli operujemy na obiekcie unicode.

Python ma stabilniejsze i dojrzalsze biblioteki.

Przekonałem się na swojej skórze, co znaczy przekonwertować setki plików graficznych za pomocą biblioteki RMagick (Ruby), a za pomocą PIL (Python). Kod w Ruby pożarł mi cała pamięć i odmówił pracy…

-

1 Osobną kategorią jest język PHP. Właściwie szkoda gadać. Ci, co zakosztowali pracy z Pythonem i Ruby, tracą szybko zapał do mozolnego dłubania w chaotycznym, niespójnym, źle zaprojektowanym języku PHP. Na ten temat to chyba trzeba napisać oddzielny tekst. Jak znajdę czas, to sobie “poużywam” na PHP. :)

2 Aby PHP aż tak nie odstawał, trzeba użyć akcelerator. Niektóre złożone projekty PHP, jak ezPublish, bez akceleratora są koszmarnie wolne.

3 Najlepszym przykładem różnicy między Pythonem a np. .NET jest ostatnio zaimplementowany przez mnie system synchronizacji danych między serwerami. Projekt tworzony przez 6 miesięcy w VB.NET (.NET) został napisany od zera w 5 roboczych dni (z czego działający prototyp był dostępny po paru godzinach). Żeby było ciekawiej, nowy kod Pythona w tym wypadku działa i szybciej i stabilniej.

4 Np. dla MySQL (od wersji 4.1 wzwyż) trzeba tylko ustawić aby baza pracowała natywnie w utf8 (domyślnie jest latin1) i tabele oraz ich pola tekstowe miały ustawiony parametr collations na utf8_polish_ci.

(Zobacz: część II)

Posted in ,  | Tagi  | 10 comments

Lightpd & FastCGI vs. Apache & mod_php,mod_python...

Opublikowane przez Jarosław Zabiełło Mon, 24 Apr 2006 17:40:00 GMT

Serwer Apache jest bardzo popularnym i solidnym serwerem www. Nie dziwi więc powszechne używanie jego modułow do obsługi Perla, PHP czy Pythona. Uzywanie mod_php jest wręcz nagminne (cały serwis sourceforge.net stoi na mod_php). Podobnie twórcy pythonowego frameworku Django zalecają używanie mod_pythona. W dokumentacji piszą, że:

“jeśli chcesz używać Django na serwerze produkcyjnym, uzywaj Apache’a z mod_pythonem (...) Django wymaga Apache 2.x oraz mod_python 3.x.”

Zupełnie inne podejście zalecają twórcy frameworka Ruby on Rails. Nie dość, że zalecają użycie modułu FastCGI to na dodatek, zalecają (o grozo:) używanie innego serwera www: Ligttpd. Które podejście jest lepsze?

Problem z uniwersalnością

Korzystanie z modułów Apache’a wiąże nas na dobre i złe z tym serwerem. korzystanie z fastcgi daje nam większe pole manewru. Możemy korzystać z Apache, Lighttpd, IIS i innych serwerów www.

Problem stabilności serwera

Jakikolwiek błąd w skryptach pracujących w trybie mod_php czy mod_python odbija się bardzo niebezpiecznie na stabilności całego serwera. Jeden błędnie działający skrypt może zawiesić cały serwer! Dotyczy to nie tylko Apache, ale także windowsowego IIS i modułów ISAPI. Co ciekawe, moduł ISAPI dla języka PHP jest wiecznie w fazie niestabilnej i testowej. Co z tego, że jest szybszy niż klasyczny CGI, skoro jeden drobny błąd w skrypcie PHP potrafi zawiesić cały serwer i unieruchomić cała sieć intranetową na nim opartą? To jeden z powodów dla których PHP nie nadaje się najlepiej do pracy pod Windowsami (wiem, że istnieje Apache/win32 ale z różnych powodów, których tu nie będę rozwijał, korporacyjne sieci intranetowe oparte na Windows Server wolą używać IIS)

Procesy FastCGI są izolowane od serwera. Jak któryś się zawiesi, to serwerowi nic się nie stanie. Proces można ubić, zrestartowac. Daje to znacznie większą stabilność pracy serwera.

Problem bezpieczeństwa

Każdy skrypt odpalany w trybie mod_php na Apache’u jest odpalany w kontekście tego samego uzytkownika. Tworzy to dosyć poważną dziurę bezpieczeństwa na serwerach hostingowych. Każdy użytkownik na serwerze za pomocą prostego kodu PHP może przeglądać źródła dowolnego pliku innych użytkowników. Wszyscy mają dostęp do wszystkich! Napisałem nawet swego czasu prosty skrypt wedrujący po całym sourceforge.net i przeglądający źródła wszystkich dostępnych tam projektów. :) Każdy, średnio zaawansowany programista z łatwością napisze sobie taki kod. Nie ma znaczenia, czy to będzie Perl (mod_perl), Python (mod_python) czy PHP (mod_php).

W FastCGI tego problemu nie ma. Każdy użytkownik może pracować na swoich prawach w pełnej izolacji. Wystarczy każdemu przydzielić po procesie FastCGI na prawach danego użytkownika.

Marnowanie możliwości Apache’a 2.x

To może nie jest najważniejszy problem. Apache 2.x potrafi pracować w trybie wielowątkowym (worker) lub wieloprocesowym (prefork) który jest zgodny ze starym Apache 1.x . Ten pierwszy jest nowocześniejszy, szybszy i pożera mniej pamięci. Problem jednak w tym, że najbardziej popularny język skryptowy nie posiada poprawnie zaimplementowanej wielowątkowości. Jeśli więc chcesz używać PHP, to zapomnij o trybie workera. Musisz pracować w starym trybie prefork. Zajmuje to więcej pamięci, ale za to nie będzie problemów z różnymi bibliotekami PHP.

Problem zasobożerności

Gdy uruchamiamy Apache 1.x lub Apache 2.x w trybie prefork, uruchamiamy szereg podprocesów. Każdy z nich zajmuje określoną ilość pamięci. Każdy z zainstalowanych modułów… również. A to przecież nie ma sensu! W praktyce nie chcemy wykorzystywać wszystkich procesów do przetwarzania mod_pythona. Większość procesów jest zajęta podawaniem statycznej wartości (obrazki, pliki ze stylami kaskadowymi, skryptami JavaScript itp).

FastCGI pozwala na ograniczenie ustalenie ilości swoich procesów w sposób niezależny od wszystkich procesów serwera www. Np. możemy sobie zadecydować, aby 100 procesów zajmowało się wartością statyczną, a tylko 10 wartością dynamiczną. Takie coś jest niemożliwe wypadku korzystania z mod_php czy mod_pythona. A oszczędności na zużyciu pamięci będą kolosalne!

Np. można załozyć, że pojedyńczy proces Apache podczas serwowania statycznych stron zajmie nie więcej niż ok 5 MB pamięci. Natomiast w wypadku użycia mod_ruby może wzrosnąć nawet do ok. 20-30MB na proces. Użycie zatem 100 procesów Apache’a z tylko 10 procesami FastCGI zużyje ok. 800MB pamięci. Zaś użycie mod_ruby bez problemu pożre nawet i 3GB!

Dlaczego Lighttpd a nie Apache?

Na końcu chciałbym jeszcze zastanowić się czy twórcy Railsów nie mają racji i czy w ogóle nie warto zrezygnować z Apache na rzecz Lighttpd? Są generalnie 3 powody za i jeden przeciw.

Za: lepiej dopracowany moduł FastCGI

Moduł FastCGI do Apache’a ma opinię nie do końca stabilnego i dopracowanego. To powoduje obawę większości użytkowników od używania go dla serwera Apache. Z kolei serwer Lighttpd od samego początku kładł nacisk na dobrą implementację swego modułu FastCGI. Jest on stabilniejszy i lepiej dopracowany niż pod Apachem.

Za: Wbudowana możliwość rozkładania obciążenia

Lighttpd ma wbudowany mechanizm rozkładania ruchu na wiele serwerów. Jeśli więc nawet ktoś upiera się przy Apache’u, to w wypadku kiedy jeden serwer nie jest wystarczający do obsługi ruchu, może warto rozważyć aby postawić na froncie jeden serwer Lighttpd który by rozkładał ruch pomiędzy kilka serwerów?

(Najnowszy Apache 2.2 ma posiadać podobny mechanizm. Jednak jest to jeszcze bardzo świeża wersja, która (w momencie pisania tego tekstu) nie ma nawet prekompilowanej instalacji dostępnej dla Windowsów oraz nie wiadomo jak jest ze stabilnością wszystkich modułów.)

Za: Lighttpd jest szybszy

O ile najnowszy Apache 2.2 nie zmieni sytuacji, to wszystko wskazuje na to, ze Lighttpd jest po prostu szybszy. Nie tylko zdecydowanie szybciej podaje statyczne dane ale także szybciej działa PHP pod Lighttpd niż mod_php pod Apachem. To nie są drobne różnice. To są różnice rzędu 2-3 razy!

Przeciw: Apache ma więcej modułów

Właściwie jedynym powodem aby używać Apache zamiast Lighttpd jest to, że do Apache napisano znacznie więcej różnych modułów. Ale szczerze mówiąc, w praktyce to rzadko ma znaczenie. Większość osób uzywa głównie kilku modułów. Zaś Lighttpd posiada praktycznie wszystko, co potrzeba: mod_fastcgi, mod_cgi, mod_redirect, mod_access, mod_auth, mod_compress, mod_webdav, mod_ssl, mod_alias, mod_proxy, mod_rewrite, itp. itd.

Lighttpd + FastCGI. To działa!

Na szczęście, dzięki standardowi WSGI, użytkownicy Pythona nie muszą słuchać zaleceń developerów Django. Teraz praktycznie wszystkie frameworki Pythona pozwalają dzięki WSGI korzystać z dobrodziejstw FastCGI. Ja również na swoim serwerze wyrzuciłem Apache’a i zastapiłem go Lighttpd. Podaje zarówno strony statyczne jak i obsługuje ten blog, a nawet PHP 5.1. Nawet Plone mi udało mi się uruchomić z Lighttpd na przodzie.

Posted in , ,  | Tagi , , ,  | 11 comments

Guido van Rossum o szablonach Django i Cheetah

Opublikowane przez Jarosław Zabiełło Wed, 01 Feb 2006 10:03:00 GMT

Guido van Rossum (twórca języka Python) w swoim blogu przygląda się zaletom i wadom szablonów Django oraz Cheetah.

Warto przyjrzeć się dyskusji, jaka się rozpętała w blogu bo do dyskusji włączyli się developerzy Myghty, Django i Cheetah.

To, że twórca Pythona w końcu zainteresował się kwestią webowych frameworków może w końcu z gąszczu rozwiązań wyłoni wyraźnych zwycięzców. W każdym razie cieszę się że developerzy frameworków włączyli się do tej debaty. Guido pracuje teraz dla Google. Python jest jednym z 3 głównych języków jakie tam są wykorzystywane. Być może Google będzie chciało używać któregoś z frameworków.

Posted in , ,  | Tagi , ,  | brak comments

Django i AJAX

Opublikowane przez Jarosław Zabiełło Sat, 28 Jan 2006 22:13:00 GMT

Wszystko wskazuje na to, że już wkrótce Django będzie posiadać mocne wsparcie dla AJAX’a. Po namyśle, wybrano bibliotekę Dojo. Lider zespołu developerów Django ogłosił, że w ciągu nabliższych tygodni, wsparcie AJAX’a zostanie dodane do Django 0.92 Przebudowie ulegnie panel administracyjny wzbogacony o nowe możliwości biblioteki Dojo.

Posted in  | Tagi ,  | 2 comments

Komentarz do konferencji Snakes & Rubies

Opublikowane przez Jarosław Zabiełło Thu, 19 Jan 2006 20:08:00 GMT

DHH, twórca Ruby on Rails w swoim blogu opisał różnicę między Django i RoR Generalnie podsumował swoje stanowisko, które wyraził na konferencji. Szkoda, że Adrian (ani nikt z developerów Django) nie napisał w swoim blogu żadnego komentarza. :(

Pod artykułem DHH jest sporo ciekawych komentarzy. Warto je poczytać.

Generalnie DHH został zaatakowany za niedocenianie roli umiędzynarodowienia RoR. Ludzie tego potrzebują i dobrze by było aby do RoR zostało dodane i18n. Jest kilka gotowych modułów, które do tego celu się nadają, np. Globalize (Być może DHH powstrzymuje wdrożenie i18n z powodu słabej implementacji UTF-8 (Unicode w ogólności) w Ruby? W przeciwieństwie do Rubiego Python ma wzorcową obsługę Unicode, więc wszelkie konwersje znaków nie są żadnym problemem.) Oczywiście nie ma nawet co mówić o kompletnie nędznym supporcie Unicode i UTF-8 w PHP gdzie nie ma nawet jak przeprowadzić konwersji z latin2 do utf8 a podpieranie się kulawym modułem iconv tylko ucina teksty w wypadku znaku który nie da się poddać konwersji. Ale co ja będę kopał leżącego… ;)

Nie mogłem się powstrzymać ;) i dodałem także swój komentarz do tego tekstu i w ogóle do kwestii rzekomej wyższości Rubiego nad Pythonem. Wiekszość osób które wpisały się do blogu Davida najwyraźniej ma mikre pojęcie o Pythonie. To prawda, że Ruby ma kilka cech lepszych od Pythona, ale prawdą jest także że Python posiada kilka cech lepszych od Rubiego. Postaram się później to jakoś podsumować w oddzielnym tekście.

Posted in ,  | Tagi ,  | 5 comments

Django 0.91

Opublikowane przez Jarosław Zabiełło Wed, 18 Jan 2006 18:19:00 GMT

Widzę, że developerzy Django wzięli sobie do serca to, aby w sposób profesjonalny rozwijać swój framework. Nie tylko zaprzestali udostępniać źródła wyłącznie w SVN, ale zadbali także aby dokumentacja poprzedniego wydania została zamrożona razem z nim. Dzięki temu osoby używające wersji 0.90 mają dokumentację do wersji 0.90. Zaś ci, co używają wersję 0.91 mają oddzielną dokumentację do wersji 0.91.

Więcej na temat zmian w wersji 0.91: tutaj.

Posted in ,  | Tagi  | brak comments

Ruby on Rails 1.0, Django 0.9

Opublikowane przez Jarosław Zabiełło Thu, 05 Jan 2006 10:36:00 GMT

Wyszła finalna wersja Ruby on Rails 1.0. Django jest zaś dostępne w wersji 0.9.

Posted in ,  | Tagi ,  | brak comments

Komentarze i filmy z konferencji Django + Ruby on Rails

Opublikowane przez Jarosław Zabiełło Thu, 05 Jan 2006 10:26:00 GMT

Zostały udostępnione nagrania wideo z ostatniej konferencji Snakes and Rubies organizowanej przez developerów Django oraz Ruby on Rails. Wiele osób umieściło także komentarze na temat tej konferencji w swoich blogach.

Posted in ,  | Tagi ,  | brak comments

Rails i Django organizują wspólną konferencję!

Opublikowane przez Jarosław Zabiełło Thu, 17 Nov 2005 20:00:00 GMT

3 grudnia developerzy Rubiego i Pythona mają się spotkać razem na uniwersytecie DePaul w Chicago. Będzie można usłyszeć dwóch liderów aplikacji webowych drugiej generacji. Przemawiać będzie twórca Railsów: David Heinemeier Hansson oraz twórca Django: Adrian Holovaty. Można wysłać za pomocą internetu pytania do obu mówców na które będą odpowiadać podczas konferencji. Zobacz http://snakesandrubies.com/event Mam nadzieję że będzie z tego dostępny jakiś film albo chociaż transkrypcja.

Posted in ,  | Tagi ,  | brak comments