Climbus Blog

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.

Jarek Zabiełło w komentarzu wspomniał abym napisał coś o wadach Pylonsów. Oczywiście, jak każdy soft i Pylons ma trochę wad. Jednak aby obraz był jaśniejszy postaram się zrobić małą analizę SWOT frameworku.

Jeżeli ktoś nie wie co to jest analiza SWOT odsyłam do wikipedii: SWOT. W skrócie analiza SWOT dzieli się na: S (Strengths, Mocne strony), W (Weaknesses, Słabe strony), O (Opportunities, Szanse), T (Threats, Zagrożenia).

Opisanie tych punktów daje w miarę pełny obraz badanego przedmiotu.

A więc zacznę od mocnych stron:

Standard WSGI

Moim zdaniem najmocniejszą stroną Pylonsa jest oparcie o pojawiający się w pythonie standard WSGI (od Pythona 2.5 implementacja jest w bibliotece standardowej). Pozwala on na korzystanie z kodu innych projektów. Dowodem może być to, że Pylons pojawił się nagle, wydawać by się mogło z niczego. Nagle powstał framework z dość sporą funkcjonalnością. Co się okazuje Pylons jest składanką wielu projektów, często poprzez warstwę WSGI.

O WSGI napiszę trochę w przyszłości bo jest to ciekawy temat.

Modularność

Jak wspomniałem przed chwilą Pylons jest składanką różnych projektów. Można wymienić kilka najważniejszych części: Paste (główny silnik, tworzący i zarządzający aplikacją WSGI oraz dostarczający sporo Middleware), Routes (biblioteka odpowiedzialna za mapping adresów url), Beaker (sesje i cache), Myghty (początkowo główny silnik szablonów i kontrolerów, teraz ma mniejsze znaczenie), SQLObject, SQLAlchemy (warstwa danych), Buffet (Interface do szablonów).

Sam Pylons składa się ze stosunkowo małej ilości kodu. Całą robotę “odwalają” powyższe projekty. Wydaje się, że każdy komponent można stosunkowo łatwo wymienić. Nie ma ścisłej zależności, czego przykładem może być Myghty, który na początku był wiodącym składnikiem teraz jest wypierany przez inne projekty (np. wkrótce domyślnym systemem szablonów będzie Mako).

Wypróbowana jest wspópraca szeregu systemów szablonów: Myghty, Mako, Cheetah, Genshi, Jinja, Kid, oraz silników baz danych: SqlObject, SqlAlchemy, Plain DB-API, ZODB, Durus itp.

Czerpanie wzorów

Głównym inspiratorem frameworku był Ruby on Rails. Jak wiadomo jest to całkiem udany kawałek kodu zdobywający coraz większą popularność. Dużo bardzo dobrych cech została przejęta z Railsów np. WebHelpers (powstała pythonowa wersja), Routes (również na potrzeby frameworku powstała pythonowa wersja), struktura katalogów aplikacji, komendy generatora kodu (paster controller, paster shell).

Autorzy obserwują też inne projekty i starają się wyciągnąć wnioski. Z CherryPy i TurboGears wzieli bibliotekę do podłanczania systemów szablonów, połączenie z SQLObject. Powstający nowy system szablonów Mako, przy ścisłej współpracy z autorami Pylonsa jest wzorowany silnie na Myghty oraz bierze conajlepsze z Django czy Chetah.

Wszystko musi być Pythonic

Jako framework pythonowy Pylons musi być napisany w idei Pythonowej: jak największa zgodność z wytycznymi PEP’ów, musi być przyjemny dla pythonowców.

Nic na siłę. Jeżeli się czegoś nie da wyrazić w pythonie bez niepotrzebnych haków, nie ma sensu tego wkładać do frameworka. Wszystko oparte o koncepcję “Keep it Simple, Stupid” co pozwala na łatwiejsze utrzymanie kodu.

Autorzy z doświadczeniem

Pylonsa tworzą ludzie z niemałym dorobkiem webowym i pythonowym. Obili się o parę projektów i doszli do wspólnych wniosków. Na pewno się przekonali, że autorskie rozwiązania nie współpracujące z innymi projektami prowadzą donikąd.

Co jeszcze warto podkreślić, autorzy chętnie pomagają w rozwiązywaniu problemów oraz dają się przekonać do dobrze uzasadnionych zmian w projekcie. Można ich zastać na ircu lub grupie dyskusyjnej.

Wszystko w paczkach

Dzięki setuptools i egg możliwe jest utrzymanie zależności od wielu bibliotek. Zazwyczaj wystarczy jedna komenda do zainstalowania Pylonsa i jego zależności. Każda aplikacja również jest paczką egg, więc wystarczy spakować ją, przegrać na serwer i uruchomić instalację. Wszystkie zależności łącznie z samym frameworkiem zostaną zainstalowane.

Kompatybilność

Autorzy Pylonsa starają się zachować kompatybilność wstecz. Każda zmiana w api jest opisywana w release notes, do kodu wstawiane są deprecated warnings, w sytuacji gdy było dużo zmian w wersji 0.9 wstawiony został tryb zgodności do zachowania kompatybilności z projektami napisanymi pod 0.8. Wydaje się, że powyżej wersji 1.0 na kompatybilność zostanie położony jeszcze większy nacisk.

Moim zdaniem są to najważniejsze mocne strony Pylonsa. Wkrótce wyżyję się trochę i opiszę jego słabe strony.

Do przeczytania wkrótce.

Od pewnego czasu obserwuję projekt Spring Framework. Jest to framework aplikacji j2ee, którego częścią jest framework MVC. Cały projekt jest profesjonalnie prowadzony i może być przykładem do naśladowania dla wielu twórców oprogramowania.

Najważniejszą częścią Springa jest innowacyjny kontener implementujący wzorzec dependency injection. Polega on na wkładaniu do aplikacji obiektów, od których aplikacja zależy. Nie jest to odpowiednie miejsce ani pora na zagłębianie się w szczegóły wzorca i jego implementacji. Wspomnę tylko, że pozwala on na większą elastyczność oraz na łatwiejsze testowanie aplikacji.

Spring od momentu powstania robi małą rewolucję w świecie Javy. Był odpowiedzią na toporne EJB2 i Struts. Pokazał lepszą, lżejszą drogę do sukcesu. Zbliżył Javę do świata Agille.

Szybko zyskał uznanie programistów. Przyczyniło się do tego parę czynników:

Innowacyjność i reakcja na zmiany

Pokazał nową lżejszą Javę. Sama idea dependency injection może nie była nowa, lecz Spring pozwolił na jej lepsze poznanie. Ponadto autorzy obserwują tendencje i idą dalej. Powstaje wiele projektów około springowych: Spring Moules, Spring WebFlow, Spring Security itp. Wystarczy trochę czasu, aż któryś z tych projektów wypali na większą skalę. Są też reakcje na dużą popularność Rubiego. Spring 2.0 opiera się na zasadzie “konwencji nad konfiguracją” oraz daje możliwość zagnieżdżania JRuby i innych języków skryptowych.

Kompatybilność wstecz

Podobno od wersji 1.0 spring jest cały czas kompatybilny w dół. Wystarczy wymienić jar’a z biblioteką. Co ważne, cały czas wprowadzają nowe dość rewolucyjne zmiany nie zapominając o wcześniejszych użytkownikach.

Integruj, nie walcz

Cały czas starają się integrować różne frameworki. Nie walczą aby przekonać do swoich rozwiązań. “Jak chcesz możesz używać tego co lubisz. Wystarczy że podepniesz pod nasz kontener”. Np. do obsługi baz danych moża używać: czystego JDBC, Hibernate, IBatis, JDO, JPA, Oracle TopLink. Wszystko to spięte w jednolity interface i drzewo wyjątków.

Podobną filozofię można zauważyć w Pylonsie.

Zbieraj społeczność

Spring jest wydawany na licencji Apache. Pomaga to w budowaniu społeczności wokół projektu. Ludzie piszą swoje podprojekty, udzielają się itp.

I do tego niezły biznes

Nic dodać, nic ująć. Prowadzą szkolenia na całym świecie.

Polecam zapoznanie się z tym projektem: http://www.springframework.org. Myślę, że jest to dobry wzór do naśladowania.