Climbus Blog

Zawsze uważałem, że nazywanie Railsa Java killerem to gruba przesada. I dalej tak myślę, lecz po bliższym poznaniu RoR’a muszę mu zwrócić trochę honoru. To co mocno uderza to kompleksowość frameworka. Widać jak twórca RoR wyciąga wnioski z procesu tworzenia web-aplikacji. Wszystko z czym spotyka się przeciętny autor serwisów internetowych ma podane na tacy. Od projektowania struktury bazy, wersjonowania jej i łatwego przenoszenia (migracje), przez wprowadzanie testowych danych (scaffold) a kończąc na łatwym deployingu (capistrano). Prawie każde pytanie znajduje odpowiedź w funkcjonalności.

RoR jest przygotowany profesjonalnie. Nie widać zbyt dużo niedoróbek czy luk w myśleniu. To co można spotkać nieraz w innych frameworkach, gdy autorzy skupiają sie na jakiejś funkcjonalności pomijając lub zapominając o innych (np. czyszczenie sesji w Pylonsie).

Konwencja nad konfiguracją wprowadza też dużo porządku w kodzie. Uczy programistów jak ważny jest ład w nazewnictwie.

Do tego jeszcze takie szczegóły jak pokazywanie w trybie developerskim czasu wykonania wszystkich sql’i oraz stron.

Naprawdę warto się zainteresować Raislem nawet tylko po to aby zobaczyć dobrze przygotowany soft. Soft, który napędza coraz większa społeczność, która zdaje się dobrze przy tym bawić.

Tylko wielka szkoda, że to jest Ruby, a nie Python …

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

Programowanie to prosta sprawa :-) Gorzej jest z komunikacją z użytkownikami. Pomijam tu kwestię tłumaczenia wymagań i oczekiwań na postać bardziej precyzyjną, technicznie możliwą do wykonania. Obecnie skupiam się bardziej na kwestii przyjmowania zleceń i poprawek. Bardzo mnie zastanawia jakie są granice godzenia się na pomysły i terminy wykonania proponowane przez użytkowników. Kiedy można się zgodzić na daną poprawkę a kiedy należy odmówić.

Jedna zasada jest prosta. Jeżeli coś obiecasz użytkownikowi musisz to wykonać w terminie. Żeby się nawet waliło musisz to zrobić bo dałeś słowo. Dlatego obiecywać trzeba z umiarem. Tylko jak znaleźć ten umiar. Jeżeli będziesz odmawiał zbyt często użytkownicy będą równie źli jak wtedy gdy coś obiecasz i nie zrobisz. A może nawet bardziej.

W swojej praktyce spotkałem różnych programistów. Często stosują prostą kolejkę FIFO. Pierwsze przyszło robię to i jak skończę to biorę następne. Śmieszniej jest jak programista stosuje kolejkę LIFO. Robi coś a gdy zadzwoni ktoś z jakimś problemem zostawia to co robił i zajmuje się kolejną sprawą. Potem kolejny telefon i sytuacja się powtarza. O problemy przy takim rozwiązaniu nie trudno. Tacy programiści powinni mieć nad sobą dyspozytora, który przydzieli im zadania i sprawdzi ich wykonanie. Czasami odłoży jedno zadanie i wpuści na chwilę inne.

Dyspozytor (np. team leader) lub samodzielny programista ma trudne zadanie. Musi mocno się namęczyć aby znaleźć złoty środek. Kiedy coś przyjąć, kiedy coś odłożyć a kiedy odmówić. Zależy to nie tylko od rodzaju projektu ale też od rodzaju użytkownika (wewnętrzny, zewnętrzny) a nawet od charakteru człowieka z którym ma do czynienia.

Pracowałem z użytkownikami wewnętrznymi oraz z zewnętrznymi i są to różne relacje. ciężko stwierdzić co jest lepsze, ciekawsze. Na pewno jest to inna współpraca i zachowania muszą być różne.

Tak więc poszukuję teraz odpowiedniego podejścia do użytkowników. Kawał pracy przede mną.

Przecież chodzi o to aby wszyscy byli zadowoleni… :-)

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 :-)