Climbus Blog

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.

Swoją przygodę z programowaniem webowym zaczynałem oczywiście z PHP. Jak każdy wie, jest to najbardziej bałaganiarski język z możliwych:) Pozwala na prawie wszystko. Oczywiście da się w nim coś konkretnego i eleganckiego wyklepać lecz jest do dość trudne i wymaga mocnego pilnowania siebie i swoich współpracowników. A zmiany w aplikacjach napisanych przez kreatywnych “programistów” są niemal samobójstwem.

Los skierował mnie w stronę Pythona. Pierwszym poznanym frameworkiem był CherryPy. Był to koniec CP1 i sam początek CP2. CP jest bardzo ciekawe i co najważniejsze bardzo proste. Bardzo łatwo ogranąć kod i wiadomo co i gdzie się dzieje. Niestety koderom CP trochę brakuje rozwagi i potrafią zmieniać różne rzeczy bez powiadomienia i bez większej zmiany numerka wersji. Tak było np. z obsługą forków. Cały czas była wzmianka o tym w dokumentacji lecz wcieło kod to obsługujący. Pytaliśmy się lidera projektu i się dowiedzieliśmy, że nie będą tego obsługiwać. Duży projekt musieliśmy zamrozić w danej wersji CP. Naszczęscie najważniejsze zmiany mogliśmy sami nanosić. Przy okazji mogliśmy pooglądać miejsca gdzie ktoś zapomniał dopisać kodu.

Następnym frameworkiem był Webware. Stary, poczciwy kawałek kodu napisany dawno temu i już chyba zapomniany (aczkolwiek webware jest ciągle rozwijany). Niestety dokumentacja nie jest najlepsza i ciężko się w niej szuka informacji. Doszedłem jednak do wniosku, że nie jest zbyt nowoczesny i elastyczny. Poszedłem dalej:)

Zastanawiałem się nad Spyce, lecz jest trochę przekombinowany. Próbuje naśladować php’a i udaje się to przynajmniej przy błedach. Potem był Myghty. Podobno dobrze dopracowany i bardzo szybki lecz mało (jak dla mnie) intuicyjny i wzorowany na frameworku Perlowym. TurboGears jet oparty na CP więc odpadł od razu.

Oczywiście obserwowałem Zopa lecz nie mogłem doj do wniosku czy wchodzić w Zopa2 czy w Zopa3. Trójka ma mało gotowych produktów, nie jest tak popularna i ma skromną dokumentację. Na Zopa Dwa szkoda mi było czasu.

Dochodzimy do “współczesności”. Obecnie chyba najwiekszą popularnością cieszy się Django. Podchodziłem do tego frameworku lecz jak musiałem zacząć projekt, w Django zaczęła się mocna przebudowa “magic removal” więc się nie odważyłem kontynuować w tamtym momencie. Ponadto wydaje mi się, że nie jest zbyt elastyczny jak na dziwne wymagania jakie spotykam.

Najciekawszym projektem jest Pylons. Jest to przykład jak z wielu zlepków istniejącego kodu może powstać bardzo ciekawy projekt. Tak naprawdę źródła sa stosunkowo małe. Pylons jest raczej klejem który integruje różne biblioteki: Routes, WebHelpers, Myghty, Baker, Paste i wycinki CP i TG. Sercem webowym jest WSGI. Deweloperzy Pylonsa są ludźmi świadomymi i często słuchają użytkowników. Wiedzą co to jest stabilność API. Oczywiście projekt nie jest pozbawiony wad i jest we wczesnym staduim rozwoju. Poczekamy, zobaczymy do czego dojdzie. Narazie się skupiam na progrmowaniu w Pylonsie. Więc dołączyłem do klanu Pylonautów:)