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

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

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

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

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

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

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

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

Vide:

The Holy Grail for Rails Deployment

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

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

Update

2008-06-25

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

Ruby Enterprise Edition 32bit na debianie etch 64bit?

Aplikacja webowa - wybór technologii

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

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

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

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

Nie wierzę w przyszłość PHP.

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

Fenomem Ruby on Rails.

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

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

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

Django i Pylons.

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

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

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

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

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

Zope 3 – najwyższa poprzeczka.

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

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

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

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

Ku przyszłości.

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

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

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

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

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

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

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

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

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

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

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

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

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

Koniec PHP 4

Jarosław Zabiełło — Sat, 28 Jul 2007 12:55:00 +0200

Wciąż popularny w ofertach hostingowych PHP 4.x będzie wkrótce musiał ustąpić miejsca dla PHP 5. Ogłoszono oficjalnie wstrzymanie prac nad rozwojem tej wersji. Wsparcie ma być jeszcze kontynuowane do końca tego roku. Potem nie będzie już żadnych nowych wersji (z wyjątkiem załatania ewentualnych błędów krytycznych, rzecz jasna).

PHP w Pythonie (WSGI)

Jarosław Zabiełło — Thu, 15 Feb 2007 01:29:00 +0100

Osobiście tego nie testowałem, ale brzmi interesująco: wphp to moduł WSGI możliwiający integrację języka PHP z dowolnym (pythonowym) frameworkiem opartym na standardzie WSGI.

Porównanie wydajności frameworków

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

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

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

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

Szablony i wzorzec MVC - cz. III

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

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

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

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

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

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

PHP

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

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

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

Ruby

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

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

Python

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

Spyce

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

Myghty

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

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

Cheetah

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

Mako

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

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

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

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

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

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

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

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

Ruby najszybciej rosnącym językiem

Jarosław Zabiełło — Thu, 04 Jan 2007 18:00:00 +0100

Ruby ostro idzie do przodu przesuwając się w górę na liście popularności oczko za oczkiem. Wg TIOBE Programming Community Index Ruby był językiem roku 2006 (w styczniu 2007 Ruby jest 10 pozycji). Z pewnością przyczynił się do tego framework Rails. Pewnie z tego samego powodu (tu jest nią AJAX) rosnie popularność języka JavaScript.

Dawniej popularność języka dyktowało wsparcie dużych firm (Sun dla Javy i Microsoft dla C#). Ale współcześnie dużo większe znaczenie zaczyna mieć “killer application” (“zabójcza” aplikacja promująca język w jakim została napisana) oraz to co twierdzi internet. Stąd zwycięzcy w ostatnich dwóch latach (PHP i Java) w tym roku (2006) są przegranymi.

Można też zauważyć trend rosnącej popularności języków typowanych dynamicznie przy malejącym tych typowanych statycznie. Ale to nic dziwnego. Od czasu przełamania pewnej bariery wydajności sprzętu upadł główny powód od aby nie korzystać z języków dynamicznych na szerszą skalę. (Z pewnością taki Smalltalk narodził się zdecydowanie w złym czasie) Ciekawa jest też uwaga, że większość popularności języka PHP nabijana jest jego problemami z bezpieczeństwem zamiast faktycznym uzyskiwaniem popularności w kręgach programistów.

Interesujące jest również to, że szybko zdobywa popularność język D, o którym do niedawna mało kto słyszał. To dosyć ciekawy język i do tego ekstremalnie szybki (stosuje jakieś agresywne algorytmy kompilacji). Ma też automatyczne zarządzanie pamięcią (garbage collector). Chyba może bez kompleksów iść na wojnę C++, Javą czy C#. (Zobacz porównanie D z innymi językami.)

Z kolei z języków bardziej niszowych odnotować można wzrost popularności Lua (z pozycji 58 na 47) oraz funkcyjnego Haskella (z 56 na 42). Przewiduje się też, że z powodu oczekiwanej migracji z C++ i Visual Basic, w roku 2007 zwycięzcą w kategorii najbardziej popularnego języka, będzie C#.

Ruby 1.9 (YARV) vs. Python, Lua & PHP

Jarosław Zabiełło — Mon, 01 Jan 2007 19:36:00 +0100

Korzystając z tego, że niedawno do repozytorium Rubiego został dodany YARV (wirtualna maszyna Rubiego) pokusiłem się o małe porównanie wydajności. Jako test użyłem prostego programu jaki pojawił się na liście pl.comp.lang.pyhon (musiałem tylko trochę zwiększyć pętle do 10 milionów iteracji, aby były widoczne jakieś wyniki) Użyty sprzęt: Athlon64 3700+, 64bit Ubuntu 6.0.6.

Sprawdziłem też z ciekawości PHP 5.2 na tym samym sprzęcie. Dla tak prostego testu powinien móc dać z siebie wszystko. Jest jednak wolniejszy od Rubiego 1.9.

Kod dla Pythona:

import time
t=time.time()
a=0
for i in xrange(10000000):
    a += i
print a
print time.time() - t

Kod dla Lua:

t = os.clock()
a = 0
for i = 1,10000000 do
    a=a+i
end
print(a)
print(os.clock() - t)

Kod dla Rubiego:

t = Time.now
a = 0
for i in 1..10_000_000
  a = a+i
end
puts a
puts Time.now - t

Kod dla PHP:

<?php
function microtime_float() {
 $time = microtime();
 return (double)substr($time, 11) + (double)substr($time, 0, 8);
}
$t =  microtime_float();
$a = 0;
for ($i = 0; $i < 10000000; $i++) {
  $a += $i;
}
print "$a\n";
print  microtime_float()- $t;
?>

Wyniki:

Lua: 1.14 s
Ruby 1.9: 1.49 s
PHP 5.2: 1.74 s
Python 2.5: 2.64 s
Python 2.4.3: 2.72 s
Ruby 1.8.5: 3.83 s.

Drugie podejście

Tym razem wynik uśredniam dla 10 prób. Zwiększyłem ilość iteracji do 20 mln. No i… Ruby 1.9 pobił wszystko. Zarówno Pythona jak i Lua! (PHP 5.2 po 30 sek. zgłosił timeout. Musiałem więc uśrednić po 5 wynikach.)

PYTHON

import time
def bench():
    a, t = 0, time.time()
    for i in xrange(20000000):
        a+=i
    return time.time()-t
result = 0
for i in range(10):
  result += bench()
print result / 10.0

RUBY

def bench
  a, t = 0, Time.now
  20_000_000.times { |i| a += i }
  Time.now - t
end
result = 0
10.times { |i| result += bench }
puts result / 10

LUA

function bench()
  a = 0
  t = os.time()
  for i = 1, 20000000 do
    a = a + i
  end
  return os.time() - t
end
result = 0
for x = 1,10 do
  result = result + bench()
end
print(result/10)

PHP

<?php
function bench() {
  $a = 0;
  $t =  time();
  for ($i = 0; $i < 20000000; $i++) $a += $i;
  return time() - $t;
}
$result = 0;
for ($x = 1; $x <= 5; $x++) $result += bench();
print $result / 5.0;
?>

Wyniki

Ruby 1.9: 2.0953268 s.
Lua 5.1: 2.4 s.
Python 2.5: 2.49481592178 s.
Python 2.4.3: 2.71687791348 s.
PHP 5.2: 4.2 s.
Ruby 1.8.5: 9.0153751 s.

Jestem ciekaw kiedy wyjdzie Rails dostosowany do Ruby 1.9. Zapowiada się bardzo obiecująco!

Django i Rails biją PHP

Jarosław Zabiełło — Fri, 14 Jul 2006 17:34:00 +0200

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.

Edytory dla Pythona, Ruby, PHP

Jarosław Zabiełło — Sun, 12 Feb 2006 00:17:00 +0100

Osoby zaczynające pracę z językiem Python, Ruby czy PHP często pytają się na grupach dyskusyjnych na temat edytorów zalecanych do pracy. Istnieją dwie szkoły, ci którym zależy na minimalnych wymaganiach pamięci i procesora oraz ci, którzy chcieliby aby edytor nie tylko kolorował składnię, ale także podpowiadał kod, uzupełniał składnię, miał wbudowany debugger itp.

Edytory tekstowe (nie IDE):

SciTE – łatwy w obsłudze, kolorowanie b. wielu języków

Vim – powszechny na każdym linuksie, jest wersja dla win32. B. szybki, doskonały do obsługi wielkich plików, niezbyt intuicyjna obsługa, np. kto by wpadł na pomysł aby wyjść z edytora za pomocą kombinacji: Esc + :q! (klawisz Escape, potem znak cudzysłowa, małe q i znak wykrzyknika)

Notepad++ – prosta, intuicyjna obsługa, po instalacji podmienia dla Internet Explorera idiotycznego Notatnika do podglądu źródeł stron html, warto instalować choćby dla tej jednej cechy i wymiany starego Notatnika.

JEdit – napisany w Javie, mnóstwo pluginów

XEmacs – kompletnie nieintuicyjna obsługa, ten edytor zupełnie w niczym nie przypomina skrótów klawiszy z innych programów, ale jest b. potężny. Jak ktoś już się przekatuje i go nauczy, to podobno jest to doskonałe narzędzie. Mnie nigdy nie starczyło cierpliwości aby go opanować. Wolę już edytor Vi.

Edytory IDE – Python

Użytkownikom win32 polecam instalację ActivePython zamiast instalacji na stronie główej Pythona. Do Pythona istnieje mnóstwo niezłych edytorów tekstowych jak i edytorów IDE. Moimi ulubionymi są:

Eclipse + pyDEV – chyba najlepsza opcja. Edytor Eclipse jest napisany w Javie i wymaga trochę pamięci, ale jest b. dobry. Posiada intuicyjny interfejs, mnóstwo pluginów dających spójne środowisko do pracy z javą, pythonem, ruby i php. pyDEV z zintegrowanym pakietem pyLint nie tylko podpowiada kod, ale także ma możliwość wyłapania nieużytej zmiennej, czy brak zgodności stylu programowania z zaleceniem PEP8 itp. Oczywiście jest też zintegrowany debugger.

PythonWin – standardowo instalowany w ActivePython. Jest znacznie szybszy i lżejszy od Eclipse, bo jest napisany w języku C. Ma świetny debugger, wbudowaną konsolę, podgląd obiektów COM. Jedyną jego wadą jest brak obsługi utf-8. Zaletą jest też to, że nadaje się do szybkiej edycji pojedyńczych plików (Eclipse wymaga tworzenia projektu, co często jest b. niewygodne). PythonWin ma także ulepszoną konsolę, bo pełnoekranową. Łatwiej w nim szybko zaznaczyć fragment poprzedniej komendy i uzupełnić.

SPE – edytor napisany w Pythonie z wykorzystaniem biblioteki wxPython. Ma unikalne, b. ładne kolorowe zakładki (umożliwia lepsze wyświetlanie podglądu metod i atrybutów klas). Wbudowany debugger, listę Todo, wyszukiwanie po wielu plikach i co ważniejsze: lepiej podpowiada kod niż np. PythonWin.

Eric – napisany w Pythonie z użyciem biblioteki PyQT. Ma dużo możliwości, wspomaganie tworzenia unittestów, refactoring, debugger itp. Obsługuje nie tylko Pythona ale i Rubiego.

Boa Constructor – ten edytor może zainteresować osoby piszące aplikacje oparte na wxPython bo posiada wbudowane wizualne wspomaganie tego procesu. Wzorowany jest na Delphi.

Komodo: Kombajn podobnie jak Eclipse. Występuje w wersji IDE (płatnej, ale licencja od razu obejmuje Windows, Linux i Mac OS X) i Edit (bezpłatnej). Ma świetny debuger do Pythona. Jest szybszy od Eclipse i obsługuje dobrze Pythona, Rubiego, PHP, C++ i inne języki (nawet szablony Django). Bardzo dobrze podpowiada kod HTML, CSS, zamyka tagi HTML podobnie jak Dreamweaver. Niestety, podpowiadanie kodu pozbawione jest na razie wyświetlania zintegrowanej dokumentacji (docstringów dla Pythona czy rdoc dla Rubiego, wyświetlana jest tylko lista metod).

WingIDE – wymieniam go na końcu bo jest płatny. Doskonale (zdecydownie najlepiej z wszystkich) podpowiada kod, posiada możliwość edycji w Zope, doskonały debugger.

Edytory IDE – Ruby

Do Rubiego istnieje też sporo niezłych edytorów, choć nie aż tyle co do Pythona.

Netbeans IDE 6.x ma zdecydowanie najlepsze podpowiadanie składni do Rubiego. Najlepszy IDE do Rubiego i Rails obok Aptana IDE.

Aptana IDE+Rails (RadRails został przejęty) to nic innego jak Eclipse dostosowany do pracy z Ruby on Rails. Posiada wszystkie zalety Eclipse, np. po dodaniu pluginów ma dobre wsparcie dla innych języków, np. Pythona. Od chwili wchłonięcia RadRails przez Aptanę, posiada świetne dodatkowe mocne wsparcie dla kodu HTML, CSS, JavaScript.

Arachno IDE – bardzo ładny i szybki. Może kolorować kod (nie tylko samego Rubiego ale także szablonów ERb, czyli nadaje się dobrze do Railsów) podobnie jak TextMate, ma wbudowany debugger, generowanie dokumentacji RDoc dla projektu, przeglądarka klas Rubiego i zainstalowanych gemsów. Niestety jest płatny i bieżąca wersja nie obsługuje jeszcze utf-8.

TextMate – działa tylko z systemem OS-X, czyli wymaga Macintosha. Ale jest to ulubiony edytor developerów Railsów. Sam edytor jest niestety płatny. Ma bardzo rozbudowane makra (snipety) przyśpieszające wprowadzanie kodu, ale ma beznadziejnie słabe podpowiadanie kodu, nie rozwija metod do bibliotek wbudowanych Rubiego, dokumentacji RDOC w ogóle nie ma scalonej z podpowiedziami do kodu. Do Pythona jest jeszcze gorzej. Ale edytor jest szybki, lekki i ma ładne kolorowanie wielu języków.

RDE czyli Ruby Development Environmnent. Edytor jest b. szybki i pomocny jak ktoś chce pisać kod w czystym Ruby.

Edytory IDE – PHP

Do PHP istnieje sporo edytorów, ale moim zdaniem większość to badziewie. Sam PHP jest językiem który bardzo utrudnia napisanie na niego dobrego debuggera. Właściwie w nic dobrego tu nie ma poza komercyjnym Zendem. Ale gdybym miał wybierać, to wybrałbym:

Eclipse + plugin phpeclipse – po pierwsze jest darmowy, po drugie doskonale zarządza kodem PHP i koloruje szablony Smarty. Po trzecie, doskonale współpracuje z SVN. Miałem okazję sprawdzić nowy Zend Studio 5.1. Mimo, że lepiej podpowiada kod, to nie koloruje Smartów i kiepsko współpracuje z SVN, beznadziejnie wręcz.

Zend Studio – komercyjny IDE stworzony przez twórców PHP. Najlepiej ze wszystkich podpowiada kod (lepiej od Eclipse) Niestety nie potrafi kolorować kodu popularnych szablonów Smarty (Eclipse to potrafi!) Szybkość ta sama co Eclipse, wymagania co do pamięci – też.

Macromedia Dreamwever 8 – komercyjny, ale nieźle koloruje i podpowiada kod. Najnowsza wersja Dreamweawera ma sporo usprawnień, np. w końcu bada końce bloków (klamr). Dreamweawer jest też oczywście szybszy od Zend Studio i Eclipse bo jest napisany w języku C.

Niestety edytory PHP mają fatalne możliwości debugowania kodu w stosunku do tego, co można spotkać dla Pythona i Ruby. Do szybkiego testowania kodu PHP, najlepiej użyć SciTE. Można mu ustawić opcję aby po wciśnięciu klawisza F5 natychmiast generował wynik bez żadnego pośrednictwa serwera www.