Climbus Blog

Ostatnio trochę bawię się railsem i zdenerwowała mnie jedna śmieszna kwestia.

A było to tak:

Robiłem model zamówienia i pomyślałem sobie, że przydało by sie pole “hash” w bazie. A tu bach wyjątek. Konflikt z funkcją “hash” podstawowego obiektu rubiego. Ok, będzie brzydko nazwałem pole po polskiemu “hasz” :(

Idziemy dalej: model do wymiany danych za pomocą xml’a. Wymyśliłem sobie metodę “send”, która wyśle przygotowany wcześniej xml. A tu bach, metoda “send” obiektu rubiego. Ok, bedzie “send_xml”.

Cholera, każdy obiekt ma ponad 40 publicznych metod na starcie. Teraz boję się dodawać nowe atrybuty do klasy bo nie znam dnia i godziny kiedy znowu natrafię na magiczną wbudowaną metodę :)

Ciężkie jest życie człowieka, który chce poznać nowe, fajne technologie ale przyzwyczaił się do minimalizmu pythona.

Warto wspomnieć, że ludzie od Pylonsa jakiś czas temu uruchomili projekt zbierający dokumentację na temat różnych frameworków webowych napisanych w Pythonie. Jest to kolejny dowód na to, że Pylons wyróżnia się chęcią integracji różnych rozwiązań. Nie skupia się na samym sobie lecz stara się pomóc we wspólnym rozwoju tzw “web pythona”.

Na razie większość artykułów odnosi się do Pylonsa ale można liczyć, że w niedalekiej przyszłości pojawią się teksty o TurboGears, Paste itp.

Zachęcam do odwiedzania: http://docs.pythonweb.org/.

A więc jakie mamy zagrożenia. Co może przeszkodzić w rozwoju Pylonsa? Jakie obawy może mieć użytkownik biznesowy? Możliwość porzucenia podprojektu

Pylons korzysta z wielu projektów (Paster, SQLAlchemy, Mako). Rozwijane są one przez różnych autorów. Niektóre mogą nie wytrzymać próby czasu. Każde spowolnienie rozwoju któregoś podprojektu powoduje automatyczny spadek tempa rozwoju Pylonsa. Na szczęście modułowa budowa i oparcie na standardach (WSGI) sprawiają, że każdy moduł można wymienić na inny.

Przykładem może być SQLObject, który został wymieniony na SQLAlchemy. Każda zmiana powoduje jednak masę niepożądanych efektów, które w świecie biznesowym mogą być nie do przyjęcia.

Klientom biznesowym polecam przeanalizowanie stanu poszczególnych części składowych Pylonsa i możliwych alternatyw. Można w ten sposób wybrać najbardziej optymalne składniki.

Problem z przebiciem się

Pylons nigdy nie był zbyt medialny. Ustępuje znacznie innym projektom pythonowym (Django, TurboGeras), o Railsach nie wspominając. Na razie jest projektem dla “hackerów”, którzy lubią eksperymenty. Ma to swój smaczek lecz w świecie biznesowym potrzeba czegoś więcej. Wszystko zależy od działań marketingowych twórców Pylonsa, które powinny być podjęte po wersji 1.0. Jeżeli odpowiednie działania nie zostaną podjęte, Pylons pozostanie w cieniu Django i TurboGears (aczkolwiek są podjmowane działania w celu zbliżenia się do TG).

Podsumowanie

No i skończyłem bardzo uproszczoną analizę SWOT. Jest to raczej wstęp do dalszych rozmyślań niż kompletna analiza frameworka. Starałem się spojrzeć na Pylonsa ze strony osoby wybierającej technologie dla projektów komercyjnych. Stabilność i pewność rozwoju są tu kluczowym czynnikiem, lecz dla mnie czynnikiem decydującym była ogromna elastyczność, którą daje niewiele frameworków.

Jeżeli chcesz coś dorzucić, wal śmiało….

Czy kolejny framework na rynku ma jakąś szansę na wybicie się? Z pewnowścią ma, ale nie jest to łatwe. Postaram się opisać jakie widzę szanse dla Pylonsa. WSGI

Pylons jest jednym z pierwszych frameworków w pełni opartych na WSGI. Postawienie na nowo powstający standard w świecie webowego Pythona jest ogromną szansą. Powoduje, że twórca aplikacji webowych nie zamyka sobie drogi do zmiany stosowanych komponentów. Może używać wielu aplikacji i middleware’ów, które prawdopodobnie powstaną (http://wsgi.org/wsgi/MiddlewareandUtilities). Umieszczanie i łaczenie aplikacji na serwerze stanie się dużo łatwiejsze.

Pozostałe frameworki zapewne pójdą w stronę WSGI, lecz Pylons będzie już kilka kroków do przodu.

Rozwój języków dynamicznych

Języki dynamiczne notują obecnie wzrost popularności. Napewno swój udział w tym ma PHP, który mocno zmienił świat webdevelopingu. Widoczne są teraz poszukiwania przez php’owców czegoś bardziej dojrzałego lecz nie tak skomplikowanego jak Java. Część ludzi zapewne pójdzie w kierunku Railsa lecz część poszuka czegoś w Pythonie.

I wiele, wiele innych

Niestety nie jestem w stanie teraz wymyślić co to jest to wiele. Większy hałas w sprawie Pylonsa jest planowany po wersji 1.0. Po tym szanse powinny się wyklarować. Narazie developerzy skupiają się na jakości kodu. I to też jest duża szansa: framework robiony przez hackerów dla hackerów :-)

Pora trochę pojechać…

Trochę już pracuję z Pylonsem oraz śledzę jego rozwój. Oprócz wymienionych wcześniej zalet ma on trochę wad. Zresztą jak każdy soft.

A więc:

Wczesna faza rozwoju

Numer 0.9.x mówi sam za siebie. Jest to framework rodzący się, na szczęście w nie zawielkich bólach :-) Poszczególne składniki są wymieniane, dopasowywane. Jak zaczynałem z Pylonsem preferowanym ORM’em był SQLObject a teraz jest SQLAlchemy. Kładąc nacisk na nowy ORM stary popada w niełaskę. Powodem tego były problemy z uruchomieniem aplikacji opartych na SQLObject w Pylonsie 0.9.3. Niezbędne było paczowanie frameworku. Naszczęście w kolejnej wersji było to już poprawione.

Innym przykładem niskiego numerka jest obecnie promowany na domyślny system szablonów Mako (obecnie w wersji 0.1.1).

Na szczęscie autorzy Pylonsa poważnie podchodzą do sprawy i każda zmiana w api jest opisywana w release notes, dodawane warningi i legacy mode.

Jest też trochę motania się w różnych rozwiązaniach. Z wersji na wersję zmienia się sposób dostępu do konfiguracji, który i tak jest niejasny. W większym projekcie może to spowodować trochę problemów.

Ogólnie przyjęta zasada, że dopiero wersja 1.0 powoduje większe zamrożenie api projektu pozwala stwierdzić, że należy uzbroić się w cierpliwość i dać kredyt zaufania dla twórców.

Słaba dokumentacja

Dokumentacja jest dosyć słaba. Ma to również związek z charakterem Pylonsa. Łączy on wiele projektów w jedną całość, daje wiele alternatyw. Dlatego też ciężko opisywać w dokumentacji szczegółowe zastosowanie poszczególnych składników. Wysyła natomiast do dokumentacji źródłowej projektów. Niestety dokumentacji tej nie da się zastosować 1:1 w środowisku Pylonsowym, więc użytkownika czeka żmudne wyszukiwanie pożytecznych informacji.

Na szczęście dokumentacja się powoli poprawia. Poczkamy zobaczymy.

Słaby PR

W porównaniu do Django i Rails Pylons ma straszcze słaby PR. Nie ma wielu artykułów. Nie ma wielu prezentacji. Dobrą stroną tego stanu rzeczy jest fakt, że autorzy skupiają się na jakości kodu a nie na rozgłosie. Potrafią sporo dywagować IRC’u na temat dobrych praktyk, oraz elegancji kodu.

Po premierze Pylonsa 1.0 szykowane są artykuły opisujące framework.

Małe “Community”

Również tutaj w porównaniu z Railsem i Django Pylons wypada cieńko. Mało (ale coraz wiecej) osób na ircu w miarę spokojna grupa dyskusyjna powodują, że wsparcie jest trochę mniejsze. Na szczęście ta mała społeczność jest przyjazna i często pomaga w problemach.

Brak wsparcia komercyjnej firmy

Moim zdaniem wsparcie komercyjnej firmy daje większe bezpieczeństwo. Tak jest w Springu czy Django. Firma dba o rozwój frameworku, pracownicy etatowi rozwijają kod. Firma czerpie z tego korzyści. Dba aby projekt nie umarł. W przypadku Pylonsa developerami są raczej hobbyści, którzy piszą kod po etatowej pracy. Żadna większa firma nie stoi za projektem. Istnieje niebezpieczeństwo znudzenia się któregoś z głównych developerów i opuszczenia projektu.