Uwolnienie potęgi iPhona - jailbreaking

Opublikowane przez Jarosław Zabiełło Sun, 17 Jan 2010 02:58:00 GMT

Tak, jak pewnie większość użytkowników iPhone’a, mimo że słyszałem od dawna o możliwości zdjęcia apple’owskich blokad (proces określany jako jailbreaking), to trochę się obawiałem że taka operacja to potencjalne ryzyko zablokowania aparatu lub jakichś innych nieodwracalnych uszkodzeń. Prawda jest taka, że to wszystko to brednie i ploty. Jailbreak jest bardzo łatwy do przeprowadzenia i jest to proces w pełni odwracalny.

Czytaj dalej...

Tagi , , , , , , , , , , , , , ,  | 16 comments

Merb - źródła informacji

Opublikowane przez Jarosław Zabiełło Fri, 12 Dec 2008 15:55:00 GMT

Od czasu wyjścia Merb 1.0 przybywa coraz więcej dobrych materiałów n/t tego frameworka (koledzy od Pylons, ktorzy od wieków tkwią w tej swojej wersji 0.9.x mogliby to sobie wziąć do serca). Przede pojawia się coraz więcej zapowiedzi książek…

Czytaj dalej...

Tagi , , , , , ,  | 13 comments

Szybki start z Rails, Merb i Pylons

Opublikowane przez Jarosław Zabiełło Sun, 16 Dec 2007 06:31:00 GMT

Celem tego tekstu jest porównanie podstawowych czynności niezbędnych do tego aby uruchomić Rails, Merb oraz Pylons. Zakładam że używany będzie

Czytaj dalej...

Tagi , , , , , , , ,  | 15 comments

Shoulda - pozbycie się magii RSpec'a

Opublikowane przez Jarosław Zabiełło Sun, 28 Oct 2007 17:45:00 GMT

Od jakiegoś czasu w kręgach Ruby on Rails można zauważyć przesunięcie paradygmatu w zakresie metodologii testowania kodu. Popularyzowane podejście TDD (Test Driven Development) zostaje wypierane przez BDD (Behaviour Driven Development). Jedną z bardziej promowanych bibliotek jest RSpec. Mimo że kusi składnią przypominającą naturalny język angielski, próba wykorzystania RSPec w rzeczywistym projekcie szybko może stać się co najmniej kłopotliwe.

Czytaj dalej...

Tagi , , , , , , , ,  | 11 comments

Django ograniczeniem w rozwoju?

Opublikowane przez Jarosław Zabiełło Sat, 27 Oct 2007 14:31:00 GMT

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

Czytaj dalej...

Tagi , ,  | 33 comments

Aplikacja webowa - wybór technologii

Opublikowane przez Jarosław Zabiełło Sat, 25 Aug 2007 19:22:00 GMT

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.

Czytaj dalej...

Tagi , , , , ,  | 97 comments

Szablony i wzorzec MVC - cz. III

Opublikowane przez Jarosław Zabiełło Sun, 14 Jan 2007 03:25:00 GMT

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 programisty1. 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 Smarty2 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 standardu3 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 .


1 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.

2 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.

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

Tagi , , , , , , , , , , , , ,  | 15 comments

Pylons + Mako

Opublikowane przez Jarosław Zabiełło Tue, 02 Jan 2007 03:46:00 GMT

Mako – nowy, wydajny system szablonów dla Pylonsów jest już dostępny publicznie na stronie http://makotemplates.org. Można go pobrać za pomocą setuptoolsów, czyli skryptem:

easy_install Mako

Posted in  | Tagi ,  | 3 comments

Pylons 0.9.4

Opublikowane przez Jarosław Zabiełło Sun, 31 Dec 2006 01:40:00 GMT

Wyszła nowa wersja pythonowego megaframeworka (korzysta z zewn., już istniejących bibliotek) do szybkiego budowania aplikacji webowych – Pylons. W wersji 0.9.4 dodano trochę poprawek i ulepszeń. M.in. jest nowy Routes 1.6.1, ulepszono introspekcję dla XML-RPC,Akcje kontrolerów są teraz generatorami a helpery oraz metoda _ (z gettext) generują teraz obiekty Unicodowe zamiast stringów UTF-8. Znowu Pylons znacznie wyprzedza, to co dopiero jest w powijakach dla Django.

SQLAlchemy

Coraz bardziej zaznacza się tendencja w używanych pod Pythonem ORM’ach (Pylons może korzystać z dowolnych) aby zamiast SQLObject wybierać raczej SQLAlchemy. Ten drugi jest uważany za znacznie bardziej wyrafinowany i o większych możliwościach. Na liście dyskusyjnej Pylonsów Ben Bangert pokazał jak w praktyce można używać SQLAlchemy.

Szablony

Pylons potrafi korzystać z dowolnych systemów szablonów dostępnych dla Pythona. Generalnie, popularne są dwa podejścia. Szablony pisane pod propgramistów lub pod webmasterów/designerów, którzy zajmują się samą kwestią prezentacji, wizualizacji i pracują najczęściej ze “wspomagaczami” takimi jak edytor Dreamweaver.

Dla tych drugich, polecane jest podejście albo takie jak promuje Django, czyli specjalnie uproszczony język szablonów umożliwiającym generowanie zaróno HTML jak i CSS, czy innej dowolnej treści.

Albo podejście jeszcze bardziej uproszczone (dla designerów, nie dla programistów), czyli koncepcja, jaką promują twórcy frameworka Zope. Chodzi o szablony ZPT, Kid czy Genshi gdzie logika szablonów jest dodana do atrybutów. Dzięki temu są one przezroczyste dla edytorów takich jak Dreamweaver i jeśli wymagana jest częsta konsultacja z designerami to takie podejście oszczędza ponownego, ręcznego dodawania logiki dla programistów.

Nadchodzi Mako

Moim zdaniem, znacznie lepszym podejściem jest podejście jakie oferują szablony Cheetah czy Myghty. Te drugie, są aktualnie najpoteżniejsze. Mają nie tylko duża szybkość, ale bardzo dobrze działający (lepszy od Cheetah) cache oraz łatwość do tworzenia komponentów, klocków wielokrotnego użycia.

Nadchodzi jednak coś jeszcze lepszego. Developerzy Pylonsów szykują zupełnie nowy system szablonów zwany Mako (http://makotemplates.org). Jest on wzorowany na najlepszych funkcjach jakie oferują Myghty, Cheetah, Genshi i Django. Jest też bardzo szybki.

Mako oferują wielostrefowe dziedziczenie (podobnie jak Cheetah i Django). Nie jest też wymagane tak jak w Myghty, aby wstawki Pythona (zaczynające się w szablonach Myghty od znaku procenta) zaczynały wiersz. Można wstawiać je w środku tekstu lub gdziekolwiek w ramach tagów <% kod Pythona %>.

<%inherit file="base.html"/>
<%
    rows = [[v for v in range(0,10)] for row in range(0,10)]
%>
<table>
    % for row in rows:
        ${makerow(row)}
    % endfor
</table>

<%def name="makerow(row)">
    <tr>
    % for name in row:
        <td>${name}</td>\
    % endfor
    </tr>
</%def>

Unikalne dziedziczenie dynamiczne (zmienna może określać które szablony mają być bazowymi dla innych). Szablony mogą być też buforowane. Można wygodnie filtrować dane w stylu Django (Python) czy Smarty (PHP).

<%!
    def myescape(text):
        return "<TAG>" + text + "</TAG>"
%>

Heres some tagged text: ${"text" | myescape}

Oczywiście można dowolny element szablonów keszować na wiele sposobów.

<%def name="mycomp" cache="true" cache_timeout="30" cache_type="memory">
    other text
</%def>

Pylons 0.9.4 ma już wbudowaną obsługę dla Mako. Wystarczy je ściągnąć z SVN:

svn co http://svn.makotemplates.org/mako/trunk mako

Po zainstalowaniu, jedyne co trzeba, to dodać opcję

template_engine='mako' 

do wywołania config.init_app w middleware.py.

Posted in  | Tagi , , ,  | 1 comment

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

Duży polski serwis w Pylons

Opublikowane przez Jarosław Zabiełło Sat, 07 Oct 2006 00:50:00 GMT

Widzę, że Wydawnictwo Murator w końcu wypuściło oficjalną wersję vortalu PoradnikZdrowie wykorzystującego framework Pylons bo w Wiki na stronie Pylonsów widzę dopisaną informację.

Posted in  | Tagi  | 2 comments

MySQLdb & client encoding

Opublikowane przez Jarosław Zabiełło Tue, 15 Aug 2006 23:28:00 GMT

[vide: English version]

MySQLdb to główna biblioteka dla Pythona obsługująca bazę MySQL. Baza ta (od werseji 4.1 wzwyż) ma wbudowany wygodny mechanizm translacji znaków jakie mają być wyświetlane dla klienta. Oczywiście, należy założyć, że natywnym formatem danych dla bazy to UTF-8. Za pomocą prostej kwerendy (SET NAMES latin2) można wymusić aby wszelkie napisy były wypluwane do klienta w wybranym formacie (tu: iso-8859-2).

Ostatnio, przy okazji pracy z Pylons, przyjrzałem się bardzo ciekawemu projektowi: SQLAlchemy. Wszystko wskazuje na to, że SQLObject odejdzie do lamusa (tym bardziej że jego twórca coś go porzucił i planuje stworzyć nowy SQLObject2). SQLAlchemy jest nie tylko znacznie poteżniejszym ORM, ale ma także znacznie lepszą dokumentację niż SQLObject – ok. 117 stron samego tylko manuala.

Jedyny problem, jakie to typowe, to brak czytelnej opcji translacji polskich znaków. Podobny problem swego czasu znalazłem w Django (wysłałem patcha i to poprawili dodając na sztywno “SET NAMES utf8”) W wypadku SQLAlchemy nie ma opcji do definicji kodowania po stronie klienta. Manual wspomina tylko o ustawieniu kodowania dla bazy, a to nie to samo. Okazuje, się, że rozwiązanie jest bardzo proste. Podczas tworzenia połączenia do bazy wystarczy użyć dodatkowych parametrów. Nie ma potrzeby bawienia się w żadne kwerendy “SET NAMES”. Owe parametry to use_unicode i charset:

import MySQLdb
conn = MySQLdb.connect(
    user='root', 
    passwd='', 
    db='test', 
    use_unicode=False, 
    charset='cp1250')

W powyższym wypadku, MySQL będzie zakładał że klient ma odebrać teksty w formacie stringów cp1250. Zaś w wypadku użycia “use_unicode=True” zwracane będą śliczne obiekty unicodowe! Przykładowy plik konfiguracyjny dla Pylonsa korzystającego z SQLAlchemy (config/init.py) może zatem wyglądać np. tak:

from sqlalchemy import *
import sqlalchemy.pool as pool
import MySQLdb

def getconn():
    return MySQLdb.connect(
        user='root', 
        passwd='', 
        db='test', 
        use_unicode=False, 
        charset='utf8')

db = create_engine(
    'mysql://root:@localhost/test',
    pool=pool.QueuePool(getconn, pool_size=20, max_overflow=40), 
    strategy='threadlocal')
metadata = BoundMetaData(db)

test_table = Table('test', metadata, autoload=True)

class Test(object):  
    def __str__(self):  
        return self.title  

test_mapper = mapper(Test, test_table) 

W powyższym przykładzie, wymusiłem kodowanie utf8 dla klienta oraz połączenie z bazą działać będzie w puli 20-40 wątków. Właśnie tego mi brakuje w Django: pracy wielowątkowej, bo zużywa ona mniej pamięci. W/w model można użyć w kontrolerze Pylons (controllers/home.py) np. tak:

from myproject.lib.base import *
from myproject.models import *

class HomeController(BaseController):
  def index(self):        
      c.rows = select([test_table.c.id, test_table.c.name]).execute()
      return render_response('/home.myt')

Posted in , ,  | Tagi , , ,  | 4 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

Pylons - czyli siła Myghty i wygoda RubyonRails

Opublikowane przez Jarosław Zabiełło Fri, 03 Mar 2006 23:51:00 GMT

Coraz bardziej ciekawie rozwija sie pythonowy framework do szybkiego budowania aplikacji internetowych: Pylons. W przeciwieństwie do TurboGears Pylons jest zbudowany na bazie Myghty a nie CherryPy. Myghty jest bardzo szybkim, stabilnym i dobrze napisanym frameworkiem. Pracuje jako cgi, mod_python, wielowątkowo lub wieloforkowo, dzięki WSGI. Posiada doskonały, elastyczny cache, obsługę AJAX’a, słowem prawie wszystko co trzeba dla współczesnej aplikacji internetowej. Jednak posiada za dużo cech które w branży pythonowej określa się jaki “perlish” (Myghty był wzorowany na perlowym Masonie)

I tu z pomocą przychodzi Pylons. Jest on czymś w rodzaju megaframeworku, czyli frameworku zbudowanym na bazie innego frameworku, w tym wypadku: Myghty. (Na podobnej zasadzie TurboGears jest megaframeworkiem opartym na CherryPy).

Pylons różni się jednak tym od TurboGears że jest oparty na frameworku znacznie bardziej solidnym i znacznie lepiej naśladuje framework bedący natchnieniem dla większości innych, czyli Ruby on Rails. Pylons czerpie pełnymi garściami z najlepszych pomysłów Railsów dodając do tego większą wydajność Pythona, elastyczność i prostotę składni oraz siłę jego bibliotek (np. Python ma doskonale zaimplementowaną obsługę Unicode, co jest w Ruby potraktowane trochę po macoszemu, a w PHP to w ogóle tragedia)

Zobaczmy przykładowo, co nam daje Pylons. Np. rozwiązywanie adresów. Adresy URL są rozwiązywane za pomoca bardzo ciekawej biblioteki Routes w sposób podobny do Railsów. Np. załóżmy że bieżący request zwraca następujący słownik: {‘controller’: ‘blog’, ‘action’: ‘view’, ‘id’: 2 (gdzie rozwiązywanie adresów url odbywa się wg definicji podobnej do Railsów: ’:controller/:action/:id’). Uzyskamy następujące wyniki:

url_for(id=4)                    =>  '/blog/view/4',
url_for(controller='/admin')     =>  '/admin',
url_for(controller='admin')      =>  '/admin/index/4'
url_for(action='edit')           =>  '/blog/post/4',
url_for(action='list', id=None)  =>  '/blog/list'

Pylons “przeportował do Pythona” całą masę użytecznych helperów znanych w Rails. Zajmuje się tym biblioteka RailsHelpers. Przykładowo wygląda to tak:

link_to("Delete this page", url(action="destroy", id=4), confirm="Are you sure?")
link_to("Help", url(action="help"), popup=True)
link_to("Busy loop", url(action="busy"), popup=['new_window', 'height=300,width=600'])
link_to("Destroy account", url(action="destroy"), confirm="Are you sure?", post => True)

Jaką to daje nam korzyść? Ogromną! Wyobraźmy sobie że chcemy zmienic sposób rozwiązywania adresów url. Co z milionami stron, które miały linki do różnych wewnętrznych części naszego serwisu? Koszmar! Trzeba ręcznie je poprawiać. Dzięki Pylon, nie musimy bezpośrednio wklepywać adres url, ale używamy do tego helperów. Zmiana zasad rozwiązywania adresów automatycznie poprawi adresy we wszystkich miejscach. Korzyść jest niewymierna!

RailsHelpers zawiera także więcej helperów. Np. można na nie zrzucić budowę formularzy.

Można też uzyskać efekty specjalne połączone z AJAX’em w identyczny sposób jak w Railsach. Pylons bowiem impelmentuje w Pythonie tą samą, znakomitą bibliotekę JavaScript: scriptaculous

Nie sposób nie wspomnieć także o interaktywnym debuggerze. To poprostu jest nowa jakość. Można interaktywnie prześledzić stan obiektów aplikacji internetowej. Świetny pomysł.

Jak dla mnie, Pylons staje się głównym rywalem Django do tytułu najlepszego frameworka dla języka Python. Jest znacznie bardziej elastyczny, posiada wysoką wydajność i możliwości Myghty oraz w łatwiejszy sposób rozwiązuje adresy url i ma wygodniejsze helpery, bo wzorowane na Ruby on Rails. Więcej na temat Pylons można śledzić także na stronie http://groovie.org/

Posted in ,  | Tagi ,  | 2 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

Guido van Rossum o frameworkach

Opublikowane przez Jarosław Zabiełło Fri, 27 Jan 2006 04:38:00 GMT

Twórca języka Python – Guido van Rossum z racji tego, że aktualnie pracuje dla Google, zainteresował się trochę więcej sprawą budowania aplikacji webowych w Pythonie. :) W swym artykule opisuje swoje wstępne wrażenia m.in. z kontaktu z Django oraz Ruby on Rails.

Zdaniem Guido, Django posiada ładny resolver adresów URL. Nie podoba mu się za to język szablonów, który zdaniem Guido jest zbyt “niepythonowy” (jakoś trudno mi sobie wyobrazić jak system szablonów może być w ogóle “pythonowy” :) No i to, że szablony Django kojarzą mu się z PHP, pokazuje że przyjrzał im się zbyt powierzchownie (ja tam nie widzę żadnego podobieństwa).

System szablonów Django jest ciekawym połaczeniem obiektowości pythonowego Cheetah i cech pehapowego Smarty. Może się podobać, lub nie, ale generalnie jest szybki i spełnia swoją rolę: jest adresowany do nieprogramistów.

Z kolei RoR posiada swój system szablonów który jest b. prosty: to po prostu połączenie Rubiego z HTML (b. podobnie do PHP czy JSP). To podejście ma także zalety jak i wady (np. trzeba znać Rubiego ale z 2-j strony nie trzeba uczyć się kolejnego pseudojęzyka do szablonów). Ostatecznie, jak komuś to nie odpowiada, to dla RoR istnieje alternatywny system szablonów zwany Liquid , system, który składnią przypomina szablony Django.

Szkoda, że Guido nie przyjrzał się bibliotece Pylons, który używa Myghty (niedawno wyszła wersja 1.0) a do rozwiązywania adresów używa b. ciekawej biblioteki – Routes.

Posted in  | Tagi , , , ,  | brak comments

Myghty 1.0

Opublikowane przez Jarosław Zabiełło Thu, 26 Jan 2006 08:42:00 GMT

Niedawno wyszła finalna wersja Myghty 1.0. Myghty to framework napisany w Pythonie. Jest bardzo szybki (z tego co sprawdzałem, to jest on najszybszy z wszystkich frameworków opartych na jęz. dynamicznych). Mimo silnych inspiracji perlowym Masonem Myghty idzie znacznie dalej. W tej chwili posiada świetnie zaimplementowany cache, wygodny AJAX, i co jest najsilniejszą jego stroną: budowę komponentową. Myghty może działać jako CGI, fast-cgi, mod_python, WSGI.

Warto zwrócić uwagę na Pylons, który jest megaframeworkiem opartym na Myghty o filozofii inspirowanej przez Ruby on Rails i TurboGears.

Posted in ,  | Tagi ,  | brak comments