Python blogowo.net

W niedzielę obieram kierunek na północny wschód

2008-07-03T19:47:13+00:00

Znaczy: do Wilna, tak jak rok temu na EuroPython. Tym razem wybieramy się w większym towarzystwie, a jak podejrzewam reprezentacja Polski też będzie liczniejsza, niż w ubiegłym roku.

Do zobaczenia w Wilnie!

Diamanda 2008.07 Test 2

2008-07-02T16:24:13+00:00

Można pobrać już drugą "wersję testową" zbliżającego się wydania Diamandy 2008. W porównaniu z Test 1 wprowadziłem wiele zmian (większość z zamierzanych dla wersji finalnej):

Obsługa prefiksów, moderatorów na forach. Oznaczanie tematów jako "rozwiązany" (solved). Możliwość zezwalania anonimom na postowanie w określonych forach
Dodanie Feeda "Co nowego?" na stronie głównej (+RSS) zbierającego zmiany i nowości (obecnie dla artykułów i postów)
Obsługa OpenID (logowanie na openID, możliwość stworzenia konta Django (bez hasła) i automatyczne logowanie na nie po zalogowaniu się na openID)
Kilka mniejszych zmian we wszystkich aplikacjach i komponentach

W przeciągu 1-2 tygodni pojawi się Test 3, który po około tygodniu przerodzi się w wydanie finalne. W Test 3 znajdą się poprawki, oraz pozostałe planowane zmiany (wykończenie OpenID i zgłaszania treści).

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

2008-07-01T17:49:32+00:00

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?

KomodoEdit i Pyflakes

2008-06-30T07:54:48+00:00

Ponieważ PIDA zaczęła mnie wkurzać (co chwilę a to coś działa, a to nie działa), postanowiłem dać szansę KomodoEdit, mocno okrojonej, ale darmowej wersji niezłego Komodo IDE. Ponieważ mój nowy lapek ma 2GB RAM na pokładzie i mocny, dwurdzeniowy procesor, żerność Komodo nie była aż tak wielkim problemem jak dawniej ...

Popularność języków programowania vs oferty pracy

2008-06-29T06:47:11+00:00

Od czasu do czasy dyskutuję z ludźmi na temat popularności języków programowania oraz o tym jak to się ma do możliwości znalezienia pracy. Postanowiłem więc, znaleźć stronkę na której by była przedstawiana popularność języków programowania oraz ilość ofert pracy w polskich serwisach - sam jestem ciekaw jak wyjdzie taki test. ...

Kodowanie UTF-8 w python (django, pylons, sqlalchemy, mako)

2008-06-29T06:47:11+00:00

Pisanie aplikacji pythonowskich, dla początkujących wiąże się z problemami z kodowaniem. Jako, że już mam te początki za sobą w tym artykule postaram się omówić te problemy i podać rozwiązanie. Mysql - założenia Zanim przystąpimy do prac, musimy się upewnić, że nasza baza jest w kodowaniu utf-8. Ogólnie wszystko jest napisane w ...

Archiwum is back

2008-06-25T22:35:29+00:00

Poprawiono najbardziej denerwujący mnie błąd w Django z ostatnich czasów i dzięki temu wróciło archiwum. Oh, my...

Sława, sława!

2008-06-24T20:51:10+00:00

http://oebfare.com/blog/2008/jun/24/django-code_swarm/

Około drugiej minuty, w prawym górnym rogu...

Zmiana planów w ostatniej chwili

2008-06-24T10:40:54+00:00

Dosłownie w ostatniej chwili zdecydowałem się na zmianę dostawcy hostingu na djangohosting.ch, pomimo że byłem zdecydowany na coś innego. Po sugestii Thomasa (dzięki!) przyjrzałem się usłudze dokładniej i postanowiłem dać szansę. Wykupiłem najtańszą opcję, wypróbowałem one-click-django-installer i oczywiście zameldowałem się po SSH. Już pierwsze pół godziny sesji przekonało mnie ...

Sztuczny tłok

2008-06-23T09:13:37+00:00

Dużo się ostatnio dzieje w Django — co chwilę ktoś commituje zmiany do repozytorium i można odnieść wrażenie, że opublikowanie daty wydania wersji 1.0 obudziło w developerach nowy zapał i chęć do posprintowania na zakończenie wyścigu.

To mylne wrażenie. Przytłaczająca większość pojawiających się w repozytorium zmian to są poprawki w ...

Zdecydowałem się na dostawcę

2008-06-22T22:11:46+00:00

To był tydzień pełen przemyśleń, ale w końcu doszedłem do jakichś wniosków. Mój najbliższy projekt będę hostował na Alwaysdata. Co prawda całość serwisu jest po francusku, ale jakoś daję sobie z tym radę.

Ujęło mnie to, że jest:

tanio (€ 6 za miesiąc w najtańszej opcji);
dobry support na forum (po ...

PyCon teraz w Polsce

2008-06-21T13:51:24+00:00

Autorem poniższego tekstu jest Katharsis

Rybnik pozazdrościł Pcimowi Pythona i organizuje po raz pierwszy polską edycję konferencji PyCon.

PyCon PL, jedyna w Polsce konferencja poświęcona w całości językowi programowania Python odbędzie się w dniach 18-19 października 2008. Celem organizowanej wspólnymi siłami trzech grup entuzjastów Pythona konferencji jest wprowadzać w życie hasło PyCona "Connecting The Python Community".

Wszystkich syczących w tym samym języku zapraszamy do przypełznięcia na konferencję oraz do odwiedzenia strony internetowej: http://liwo.polsl.pl/pycon-pl/ Masz coś do powiedzenia? Chcesz nas wspomóc i zostać sponsorem? Masz pytania? Odwiedź stronę konferencji.

W chwili obecnej ruszyło przyjmowanie zgłoszeń od osób, które chciałyby wystąpić z własnym wykładem. Termin do którego można wysyłać swoje propozycje to 2 lipca.

Szczegóły: http://liwo.polsl.pl/pycon-pl/aktualnosci/call-for-papers/

Zapraszamy wszystkich zainteresowanych.
Polska Grupa Użytkowników Linuksa Oddział Śląsk
Polska Grupa Programistów Pythona
Studenckie Koło Naukowe Linuksa i Wolnego Oprogramowania z Politechniki Śląskiej

Wersja 1.0 już niedługo!

2008-06-21T12:15:49+00:00

Niedawno pojawiła się informacja, że już niedługo wyjdzie bardzo oczekiwana wersja 1.0 Django. Termin został ustalony na 2. września. Dokładna lista rzeczy, które będą dodane i te które zostaną być może dodane wraz z dokładnymi terminami znajduje się na stronie: VersionOneRoadmap

Zdrada? To się dopiero okaże...

2008-06-19T16:40:00+00:00

No i będę miał w pracy MacBooka. Niby zwykłego, ale tak nie do końca, bo czarnego. Nigdy nie miałem Maca, nigdy też go nie używałem, więc zacząłem od czytania, co też mnie czeka po przesiadce z linuksa. Nie zapowiada się różowo, głównie z powodu problemów z bibliotekami. Ale może jakoś ...

PyCon PL 2008

2008-06-18T07:47:02+00:00

Rybnik pozazdrościł Pcimiowi Pythona i organizuje po raz pierwszy polską edycję konferencji PyCon - żartobliwym stwierdzeniem mówią o PyConie organizatorzy imprezy.

czytaj dalej

PyCon w Polsce

2008-06-17T22:00:00+00:00

PyCon w Polsce

Python Magazine 2008-04

2008-06-11T20:33:34+00:00

Ukazał się właśnie (trzymam świeży, jeszcze ciepły wydruk:) nowy numer Python Magazine.

Co w nim znajdziemy?

czytaj dalej

Google App Engine

2008-06-11T20:33:34+00:00

Ostatnimi dniami Google zaprezentowało nową usługę Google App Engine . Czym się ona charakteryzuje?

czytaj dalej

Passenger bliżej - Rails, Rack i WSGI

2008-06-11T08:55:01+00:00

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.

Rozszerzenia do Kate w Pythonie

2008-05-28T03:26:50+00:00

Pate to wtyczka do Kate z KDE3 umożliwiająca pisanie wtyczek w Pythonie. Pate pozwala tworzyć wtyczki dodające elementy interfejsu, operujące na otwartym pliku - "tekście", w sumie to co zwykłe wtyczki Kate. Działające "hello world" to:

import kate

@kate.onAction("Hello World", "Ctrl+H")
def insertHelloWorld():
	currentDocument = kate.view()
	currentDocument.insertText("Hello World!")

.c { color: #008800; font-style: italic } /* Comment */ .err { border: 1px solid #FF0000 } /* Error */ .k { color: #AA22FF; font-weight: bold } /* Keyword */ .o { color: #666666 } /* Operator */ .cm { color: #008800; font-style: italic } /* Comment.Multiline */ .cp { color: #008800 } /* Comment.Preproc */ .c1 { color: #008800; font-style: italic } /* Comment.Single */ .cs { color: #008800; font-weight: bold } /* Comment.Special */ .gd { color: #A00000 } /* Generic.Deleted */ .ge { font-style: italic } /* Generic.Emph */ .gr { color: #FF0000 } /* Generic.Error */ .gh { color: #000080; font-weight: bold } /* Generic.Heading */ .gi { color: #00A000 } /* Generic.Inserted */ .go { color: #808080 } /* Generic.Output */ .gp { color: #000080; font-weight: bold } /* Generic.Prompt */ .gs { font-weight: bold } /* Generic.Strong */ .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ .gt { color: #0040D0 } /* Generic.Traceback */ .kc { color: #AA22FF; font-weight: bold } /* Keyword.Constant */ .kd { color: #AA22FF; font-weight: bold } /* Keyword.Declaration */ .kp { color: #AA22FF } /* Keyword.Pseudo */ .kr { color: #AA22FF; font-weight: bold } /* Keyword.Reserved */ .kt { color: #AA22FF; font-weight: bold } /* Keyword.Type */ .m { color: #666666 } /* Literal.Number */ .s { color: #BB4444 } /* Literal.String */ .na { color: #BB4444 } /* Name.Attribute */ .nb { color: #AA22FF } /* Name.Builtin */ .nc { color: #0000FF } /* Name.Class */ .no { color: #880000 } /* Name.Constant */ .nd { color: #AA22FF } /* Name.Decorator */ .ni { color: #999999; font-weight: bold } /* Name.Entity */ .ne { color: #D2413A; font-weight: bold } /* Name.Exception */ .nf { color: #00A000 } /* Name.Function */ .nl { color: #A0A000 } /* Name.Label */ .nn { color: #0000FF; font-weight: bold } /* Name.Namespace */ .nt { color: #008000; font-weight: bold } /* Name.Tag */ .nv { color: #B8860B } /* Name.Variable */ .ow { color: #AA22FF; font-weight: bold } /* Operator.Word */ .mf { color: #666666 } /* Literal.Number.Float */ .mh { color: #666666 } /* Literal.Number.Hex */ .mi { color: #666666 } /* Literal.Number.Integer */ .mo { color: #666666 } /* Literal.Number.Oct */ .sb { color: #BB4444 } /* Literal.String.Backtick */ .sc { color: #BB4444 } /* Literal.String.Char */ .sd { color: #BB4444; font-style: italic } /* Literal.String.Doc */ .s2 { color: #BB4444 } /* Literal.String.Double */ .se { color: #BB6622; font-weight: bold } /* Literal.String.Escape */ .sh { color: #BB4444 } /* Literal.String.Heredoc */ .si { color: #BB6688; font-weight: bold } /* Literal.String.Interpol */ .sx { color: #008000 } /* Literal.String.Other */ .sr { color: #BB6688 } /* Literal.String.Regex */ .s1 { color: #BB4444 } /* Literal.String.Single */ .ss { color: #B8860B } /* Literal.String.Symbol */ .bp { color: #AA22FF } /* Name.Builtin.Pseudo */ .vc { color: #B8860B } /* Name.Variable.Class */ .vg { color: #B8860B } /* Name.Variable.Global */ .vi { color: #B8860B } /* Name.Variable.Instance */ .il { color: #666666 } /* Literal.Number.Integer.Long */

Python

2008-05-25T18:14:48+00:00

"Popularność pythona, perla i ruby mnie nie dziwi - tylko zaawansowane firmy technologiczne używają na co dzień tych języków."

Ten cytat tlumaczy dlaczego zaczalem interesowac sie tym jezykiem i w takiej firmie chcialbym pracowac (poszukiwanie posady programisty pythona trwa).

PPCG i NAC

2008-05-20T21:39:56+00:00

Portal PPCG (Polish Python Coders Group), z którym jestem w jakiś sposób związany, nawiązał współpracę z Narodowym Archiwum Cyfrowym (NAC). Dzięki porozumieniu pomiędzy organizacjami, programiści Pythona będą mogli uczestniczyć w projektach związanych z przetwarzaniem informacji.

NAC tworzy oprogramowanie w oparciu o technologie opern-source (Python, PostgreSQL itd.). Na chwilę obecną trwają prace nad dwoma projektami przewodnimi - “ZoSIA” (Zintegrowany System Informacji Archiwalnej) oraz “SeDAN” (System Digitalizacji Archiwalnej).

Współpraca pomiędzy PPCG i NAC na pewno doprowadzi do zwiększenia popularności Pythona w naszym kraju. Wierzę, że inne organizacje wezmą przykład z NAC i zainteresują się tym niezwykle ciekawym językiem.

Garść nowości.

2008-05-19T10:06:58+00:00

Trochę informacji na temat co się dzieje w świecie Django.

Dodatkowe opcje dla funkcji 'update' w nowym ORM-ie

Sebastian Noack napisał rozszerzenie funkcjonalności funkcji update. Dotychczas mogliśmy podać tam tylko stałe wartości (np. foo=42). Z jego rozszerzeniem możemy podać całe wyrażenie zmieniające wartość. Przykładowo: foo = aktualna_wartość + 1
Więcej informacji na: groups.google.com code.djangoproject.com/ticket/7210
Przykłady:

from django.db.models.sql.expressions import *

qset = model.objects.all()

# Equivalent to qset.update(foo=42)
qset.update(foo=LiteralExpr(42))

# Increment column 'foo' by one.
qset.update(foo=CurrentExpr() + LiteralExpr(1))

# Swap the value of the column 'foo' and 'bar'.
qset.update(foo=ColumnExpr('bar'), bar=ColumnExpr('foo'))

Być może zostanie to wrzucone do głównego drzewa Django

Błąd bezpieczeństwa w Django

Poprawiono błąd typu XSS, który był w aplikacji admin. Zalecana jest aktualizacja do nowszych wersji. Więcej informacji na: www.djangoproject.com/weblog/2008/may/14/security/

Byteflow Blog Engine

Duży silnik blogowy z pełną funkcjonalnościa z dostępnymi źródłami napisany w Django: http://byteflow.su/

EuroPython 2008

2008-05-16T10:44:13+00:00

Już można się rejestrować na EuroPython 2008, do końca maja opłata wynosi €100 (od 1 czerwca €160, przy drzwiach €200), więc warto się pospieszyć. Ja się już zarejestrowałem. ;)

PIDA mnie rozczarowuje

2008-05-04T17:17:13+00:00

Większość mojego kodu w Pythonie (a właściwie kodu w ogóle, włączając w to HTML i skrypty SQL) piszę w PIDA. Jak dla mnie to środowisko pozostawia mi ultrawygodnego Vima, dodając to, czego potrzebuję podczas pracy: zarządzanie grupą plików jako projektem, kilka podstawowych poleceń systemu kontroli wersji, przeglądarkę klas i integrację ...

Tak łatwo to jeszcze nie było

2008-04-29T23:10:46+00:00

Znalazłem kilka dni temu samouczek pisania własnych ramówek webowych w Pythonie w oparciu o WSGI i bibliotekę WebOb. Tak łatwo to chyba jeszcze nie było...

Na szczęście minęły czasy pączkujących ramówek (w tempie dwóch tygodniowo, strach było otworzyć lodówkę), ale może takie samouczki pokażą pretendentom, co ich czeka od strony ...

Materiały z trzeciego spotkania

2008-04-28T17:56:43+00:00

Poniżej prezentacja Michała Bugno i Krzysztofa Goja z trzeciego spotkania Pykonika, czyli "Systemy kontroli wersji Bazaar i Mercurial".

Oprócz slajdów mamy także obiecany podcast: [Pykonik][03]DVCS.ogg

Happy listening.

Całe spotkanie było nagrywane kamerą w związku z tym, jak tylko uda ma się obrobić obraz, wystawimy też videocast. Możliwe, że uda się również zrobić slidecast z użyciem powyższego audio, choć to w dużej mierze zależy od obłożenia czasowego ekipy.

| View | Upload your own

Queryset-Refactor Merged!

2008-04-28T13:32:04+00:00

Od dawna rozwijany w osobnym branchu ulepszony ORM został połączony z drzewem głównym. W końcu możemy uaktualniać wiele rekordów w tabeli na raz, czy też korzystać z dziedziczenia modeli.

Jedyne niekompatybilność na które natrafiłem, to OneToOneField nie jest teraz domyślnie kluczem podstawowym, oraz zmieniło się użycie order_by jeżeli sortujemy po dowiązanej tabeli (jest dużo bardziej intuicyjne).

Więcej informacji na: http://blog.michaeltrier.com/2008/4/27/django-queryset-refactor-merged, opis nowych rzeczy: http://code.djangoproject.com/wiki/QuerysetRefactorBranch

PS. Jeszcze został do połączenia branch newforms-admin i być może kolejnym krokiem będzie wersja stabilna.

Gówniażeria

2008-04-28T11:48:18+00:00

Co jakiś czas na pl.comp.lang.python pojawiają się ogłoszenia o pracy dla programistów w Pythonie. Abstrahując od dyskusyjnej właściwości tej grupy dla wysyłania ogłoszeń o pracy (niby jest pl.praca.oferowana, ale ogłoszeń o pracy dla Pythoniarzy nie jest aż tak wiele, więc ma to pewien walor...), to ...

Wypełnianie formularzy PDF - forge_fdf w pythonie

2008-04-25T10:50:12+00:00

Przytrafiło się ostatnio wypełnić przygotowany przez klienta formularz PDF. Ot, umieścić na gotowej formie klucz identyfikacyjny, dać odwiedzającemu PDFa, który to może go wypełnić i odesłać. Formularz jest identyfikowany bardzo łatwo dzięki rzeczonemu kluczowi. Pojawił się jednak jeden zasadniczy problem - jak? Nie chcieliśmy kupować rozwiązań komercyjnych, a poszukiwania w internecie na niewiele się zdały. [...]

AppEngine i Pylons

2008-04-14T18:45:47+00:00

Wszyscy piszą o Google AppEngine więc ja też coś napiszę. Żeby nie było tylko Django i Django zawiadamiam, że trwają prace nad uruchomieniem Pylonsa na Google’u.

Najwięcej kłopotów było z faktem, że na AppEngine nie można instalować bibliotek używających C. Okazuje się, że Mako i SQLAlchemy są takowymi. O ile SQLALchemy nie jest może w tym przypadku istotne o tyle Mako by się przydało.

Jak można było się spodziewać, na developerów Pylonsa można liczyć. Trunk Mako można już instalować na AppEngine a Beaker może pracować z Googlowym silnikiem baz danych.

Ian Bicking wypuścił pakiet umożliwiający zbudowanie środowiska do AppEngine.

Więcej informacji w poście: http://groups.google.pl/group/pylons-discuss/browse_thread/thread/3f132217b134b772

Instrukcja jak zrobić i zainstalować na AppEngine aplikację w Pylonsie: http://code.google.com/p/appengine-monkey/wiki/Pylons

Google App Engine

2008-04-13T19:48:32+00:00

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.

Streaming video na najbliższym spotkaniu

2008-04-10T16:01:04+00:00

Osoby, które nie dotrą na dzisiejsze spotkanie, będą mogły śledzić prelekcje "na żywo" dzięki streamingowi video. Wystarczy połączyć się z poniższym adresem o godz. 18:15 przy pomocy jakiejś aplikacji wspierającej format mms (WMP, MPlayer, etc.). Liczba połączeń ograniczona - kto pierwszy ten lepszy ;)

Oto i adres: mms://mms.ftj.agh.edu.pl/kernel

Osoby, które chciałyby sprawdzić wcześniej czy nie mają problemów technicznych, mogą skorzystać z tego linku.

Hosting (Python, Django) od Google

2008-04-08T23:48:16+00:00

Google udostępniło nową usługę App Engine (więcej), czyli darmowy hosting dla naszych stron www (przykłady). Jako język...

Instalacja Pylons pod Windows

2008-04-03T11:58:11+00:00

Post poniższy już się kiedyś ukazał na ówczesnym blogu Pythonized, jednak nie udało się go odzyskać - w wyniku jakiegoś błędu w WordPressie post został zniszczony przez jakiegoś spammera. O samą instalacje wciąż mnie znajomi pytają, zdecydowałem się więc przywrócić “poradnik”. Instalacja Pylonsów jest całkiem prosta, początkującym przysparza jednak sporo trudności. Proces opiszę więc od samego [...]

/dev/random w Windowsie

2008-04-01T20:36:11+00:00

Ostatnio musiałem skorzystać z możliwości “nieograniczonej” generacji ciągów pseudolosowych. W Linuxie sprawa jest prosta - otwieramy /dev/random i cytamy zeń wymaganą licznę znaków. Gorzej z tym pod Windowsem, który mimo, że podobne wirtualne urządzenie posiada, to nie umożliwia adekwatnego skorzystania z niego. Efekt podobny można jednak uzyskać - np. przez wywołanie, np przez win32com, funkcji [...]

W pogoni za wersjami

2008-03-28T07:37:27+00:00

Frameworki, szczególnie w językach dynamicznych bardzo szybko się rozwijają. Powstaje wersja za wersją. Przy większej liczbie aplikacji może to być uciążliwe.

Aplikacje pisane pół roku temu są kompatybilne z wersją 0.x frameworka, po drodze były wersje 0.x.y, 0.y a teraz jest wersja 0.z. Czy tkwić z jedną ustaloną jako produkcyjna wersją czy używać do nowych projektów aktualnie najnowszej. Przecież na serwerze jest zainstalowana wersja 0.x i nie ma szans na podniesienie i sprawdzenie wszystkich aplikacji.

W rozwiązaniu tego dylematu pomógł pakiet “virtualenv”. Za jego pomocą szybko zrobimy wirtualne środowisko pythona.

Może przykład z Pylonsem: na serwerze jest zainstalowana wersja 0.9.5 a najnowszą wersją jest 0.9.6, która ma sporo zmian.

Więc instalujemy pakiet virtualenv:

easy_install virtualenv

Robimy środowisko:

virtualenv 096

Powstał nowy katalog “096” z binarką pythona. Instalujemy nową wersję Pylonsa:

cd 096
./bin/easy_install Pylons==0.9.6

Wgrywamy naszą aplikację do jakiegoś podkatalogu np. Aplikacja i uruchamiamy:

cd Aplikacja
../bin/paster serve production.ini --daemon start

I gotowe. Możemy sobie dograć niezbędne wersje bibliotek. Trzeba pamiętać aby używać skryptów jawnie podając katalog 096/bin.

MySQL w Pythonie, biblioteka MySQLdb

2008-03-26T21:20:57+00:00

W Pythonie mamy kilka bibliotek do obsługi bazy MySQL - najpopularniejszą i najlepszą z nich jest MySQLdb i to o niej traktuje ten tekst. Ciekawostkę może stanowić fakt, iż jest używana w takich projektach jak Django, Zope czy...

Bazaar i Mercurial na trzecim spotkaniu

2008-03-26T09:47:45+00:00

Na następnym spotkaniu będziemy mówić o rozproszonych systemach kontroli wersji (dokładniej: tych dwóch wymienionych w tytule posta). Jeśli jeszcze o nich nie słyszałeś/łaś, polecam prezentację Linusa Torvaldsa, w której co prawda miał mówić o gicie (git to jeszcze jeden DVCS), ale skupił się raczej na jeżdżeniu po SVN. Jeśli weźmie się poprawkę na elementy emocjonalne ("jeśli się ze mną nie zgadzasz to jesteś brzydki i śmierdzisz"), to można uzyskać bardzo przekonujące argumenty na rzecz zmiany swojego systemu kontroli wersji. Prezentacje zostaną wygłoszone przez Michała Bugno i Krzysztofa Goja.

Data, godzina i miejsce: Spotkanie odbędzie się w czwartek, 10 kwietnia, o godzinie 18:15 w tym samym miejscu gdzie ostatnio, czyli w budynku D-10 Akademii Górniczo-Hutniczej przy ulicy Reymonta 19; sali "A" na pierwszym piętrze. Mapkę można znaleźć kilka postów niżej.

Git, Bazaar, Mercurial - Subversion pod obstrzałem

2008-03-23T14:13:00+00:00

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

Czym jest system rozproszony (distributed)?

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

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

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

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

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

Git, Mercurial i Bazaar

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

Git

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

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

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

Mercurial

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

Bazaar

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

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

Updates

2008-03-23

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

sudo port install git-core +svn

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

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

Materiały o Django z PyCon 2008

2008-03-18T18:10:52+00:00

Uaktualnienie 2008-04-02: Dodałem linki do dwóch pozostałych materiałów.

Ponieważ część konferencyjna PyCon 2008 już się zakończyła poświęciłem chwilę czasu na odnalezienie na różnych stronach autorów ich prezentacji. By inni nie szukali, oto lista (jeśli coś pominąłem to albo nie ma tej prezentacji, albo źle szukałem, proszę o komentarze, brakujące wpisy ...

Co robią moje wątki?

2008-03-16T19:20:26+00:00

Paster dostarcza wiele przydatnych aplikacji. Jedna z nich nazywa się watch_threads i służy do podglądania stanu wątków pastera.

Widzimy ile wątków jest w puli, ile aktualnie jest używanych, czy są jakieś zablokowane. Jest też lista wątków aktualnie przetwarzanych oraz kilka szczegółów np. czas wykonania. Możemy zabijać zablokowane wątki.

Instalacja jest prosta. Jest to aplikacja wsgi więc można wpiąć ją pod url do pastera. Wystarczy zmienić domyślne sekcje w pliku .ini:

[composite:main]
use = egg:Paste#urlmap
/ = mainapp
/monitor = monitor

[app:monitor]
use = egg:Paste#watch_threads
allow_kill = True

[app:mainapp]
...

Po restarcie pod adresem: /monitor mamy listę aktualnie używanych wątków.

Paster na kilka procesów

2008-03-10T19:34:13+00:00

Po przeczytaniu paru artykułów o GIL postanowiłem spróbować rozdzielić paster’a na kilka procesów.

Domyślnie Pylons rusza w trybie z pulą 10 wątków. Liczbę wątków można zmienić w production.ini umieszczając w sekcji server:main poniższe:

use_threadpool = True
threadpool_workers = 20

Ale czy 20 wątków i więcej będą optymalnie wykorzystywały wieloprocesorową maszynę? Może lepszym wyjściem jest powielanie procesów a nie wątków.

Aby uruchomić aplikację na kilku procesach można zrobić kilka sekcji server:

[server:main]
use  = egg:paste#http
host = 0.0.0.0
port = 5000
use_threadpool = True
threadpool_workers = 10

[server:main2]
use  = egg:paste#http
host = 0.0.0.0
port = 5001
use_threadpool = True
threadpool_workers = 10

Teraz aby wystartować robimy:

paster serve production.ini --server-name=main --pid-file=main.pid --log-file=main.log --daemon start 
paster serve production.ini --server-name=main2 --pid-file=main2.pid --log-file=main2.log --daemon start

I mamy kilka procesów. Teraz wystarczy napisać kawałek skryptu startującego, ustawić loadbalancer i testować.

gigabajtosekunda

2008-03-07T18:55:45+00:00

Po ostatniej, fajnej dyskusji na pl.comp.lang.python postanowiłem sprawdzić co mi Rails powie.

I tak:

1.day * 1.gigabyte => 92771293593600

Nowa jednostka? sekundobajt:

1.second * 1.byte: => 1

To jest dobre:

1.gigabyte.ago => Wed Feb 27 06:08:25 +0100 1974

W sam raz do nowego Startreka: “W dawnych czasach. Cały gigabajt temu. Kiedy jeszcze ludzie mierzyli czas w prymitywnych sekundach” :)

Następny wpis będzie 512.kilobytes.from_now

=> Thu Mar 13 21:32:10 +0100 2008

Szalejące frameworki Rubiego i Rack/WSGI

2008-03-07T16:07:06+00:00

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

Frameworki

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

Mongrel i spółka

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

Mikroskopijna, tyci tyci część kodu w standardowej bibliotece Ruby'ego dziełem leszcza

2008-03-04T22:04:10+00:00

Będę wredny - ale to hasło padło na pl.comp.lang.python z ust programisty (chyba programisty) a na pewno fana języka Ruby.

Jython Reaktywacja.

Słoneczna przyszłość dla Jythona

2008-03-03T16:32:34+00:00

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

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