Ruby On Rails 3.1 - dzień pierwszy

Zawsze uważałem, że najlepszy poradnik, to zbiór wskazówek pisanych przez początkującego, nie koniecznie zaś zapełniane przez mądrego człowieka annały, które jak na początek, mogą być za mądre. Równocześnie, najlepiej aby początkujący miał już doświadczenie z innymi podobnymi zagadnieniami  jednak w danej technologii był początkujący. Taki układ daje duże szanse, że poradnik będzie profesjonalny, pisany prostym językiem i zrozumiały dla maluczkich, którzy oczekują prowadzenia krok po kroku. Mam nadzieję, że moje wpisy o Ruby On Rails 3.1 takie właśnie będą.

Dlaczego?

Mam za sobą już, od jakiegoś czasu, Rails for Zombies, czytałem o Ruby On Rails i jeszcze nigdy nie spotkałem się z osobą, która zaczęłaby kurs Railsów od RVM. Podstawy podstaw - jak na mój gust.

Gdy piszesz jakikolwiek program, aplikację musisz zdecydować się na dwie rzeczy: wersję języka programowania i wersję pozostałych bibliotek, które używasz. U mnie to wygląda tak: zaglądam na stronę języka programowania (w tym przypadku języka Ruby), zaglądam na stronę biblioteki (w tym przypadku Railsów) i nakręcam się na napisanie aplikacji w najnowszej wersji, która wprowadza najświeższe udogodnienia, nowości, nowatorskie technologie i wszystko co sprawia, że bycie geekiem jest piękne i pełne wrażeń jak przejażdżka górską kolejką w parku "Six Flags Great Adventure".

Później przychodzi faza druga, która nazywa się "sprawdźmy co jest na serwerze" i ta przynosi znacznie więcej rozczarowań, niż radości dopóki nie używasz ArchLinux lub nie jesteś twórcą biblioteki, której właśnie zamierzasz użyć. Wtedy klniesz pod nosem, że "przecież administrator mógł przejść na sida" i jakbyś tylko miał uprawnienia użytkownika root!

I tutaj właśnie objawia się piękno RVM. Pozwala ono bowiem bez uprawnienia super-użytkownika zainstalować dowolne wersje języka Ruby, w locie podmieniać interpreter oraz wersje używanych bibliotek, które w wielu różnych kombinacjach mogą koegzystować w wirtualnych środowiskach zwanych gemsetami. Wszystko bez wychodzenia poza katalog domowy.

Bottle i ZODB w jednym stali domu ...

... o swojej genialności nie mówiąc nikomu.

Wybory w Kręgu Harcerstwa Starszego Matrix - napisanie prostej ankiety. W końcu okazja, aby przećwiczyć coś nowego. Tym razem ZODB i Bottle.

Bottle wydaje się nadal rozwijany oraz w jakiś sposób subiektywnie "lepszy" niż Bobo. Posiada prosty wbudowany system szablonów. Bazuje on na założeniu, że szablony znajdują się w katalogu "views" dzięki czemu unikamy potrzeby konfiguracji (jak w Rails - convention over configuration).

W obu frameworkach brakuje mi jakiejś funkcji, która generowałaby poprawne linki - chociaż niby co to za problem zrobić sobie jednolinijkową funkcję do tego. Może tyle na temat micro-frameworków. Czas o ZODB.

O ZODB usłyszałem od mojego przyjaciela, który pracuje od jakiegoś już czasu w Plone i jest tym CM/F/S em zafascynowany. Kiedyś wracając z kina powiedział "No przypisujesz sobie jak chcesz atrybuty/klucze do obiektu i jest". Brzmiało obiecująco jednak nie okazało się tak piękne.

Plone robi bardzo dużo za nas. Pierwsze - nie wystarczy przypisać. ZODB jest bazą transakcyjną i nasze działania wymagają commitowania. Najprostsza sytuacja wygląda tak:

import transaction

#
# Tutaj sobie zmieniasz
#

transaction.commit()

Kolejna sprawa, dojście do której zajęło mi sporo czasu - ZODB wychwytuje zmiany tylko elementów korzenia. Tak więc:

# W bazie danych mamy taką strukturę:
# root.osoby = [{'id': 1, 'imie': 'Jan'}, {'id': 2, 'imie': 'Katarzyna'}]

# Łączysz się z bazą danych

root.osoby[1]['imie'] = 'Kasia'
transaction.commit()

Nie zadziała ponieważ ZODB nie przeczesuje w głąb struktur danych w celu poszukiwania zmian. Musimy więc zrobić na przykład:

osoby = root.osoby
osoby[1]['imie'] = 'Kasia'
root.osoby = osoby
transaction.commit()

Co odniesie skutek. Jak więc widać ZODB jest znacznie fajniejszy w Plone niż poza nim choć nadal jest fajny :)

Umarł król niech żyje król

Pisałem swojego czasu o tym jak zauroczyła mnie swoją prostotą Sinatra o Werkzeug jako analogicznym rozwiązaniu dla Pythona. Dzisiaj przyszło mi wrócić do pewnego skryptu WSGI i zacząć mocno go przerabiać. Jedna metoda wystawiona na zewnątrz z użyciem Werkzeug z wykorzystaniem kilku funkcji pomocniczych.

Dzisiaj, kiedy przyszło mi dopisać do tego kilka dodatkowych metod znajdujących się pod innymi adresami i wysłanie formularza nie wytrzymałem. Werkzeug wymagała ode mnie wklepania masy kodu do mapowania URLi, potem napisania obsługi w application, do tego dokumentacja nie odpowiedziała mi na pytanie jak wystawić metodę tylko jako GET :| Poddałem się. Ta sytuacja skłoniła mnie do poszukiwań nowej Sinatry dla Pythona.

Tak trafiłem na framework Bobo. Jestem po prostu zauroczony! Banalne, proste dekoratory (jak w Sinatra) - kilka metod, nic wyszukanego. Gdyby ktoś był ciekaw jak podpiąć do mod_wsgi polecam artykuł na blogu Grahama Dumpletona "Using bobo on top of mod_wsgi". Krótko mówiąc - umarł król niech żyje król.

Werkzeug stał się w moich oczach krową i wyleciał z sektora, w którym miał być najlepszym. Teraz to takie Django w wydaniu zrób to sam. Czyli moim zdaniem - bez sensu. Bobo jest troszkę magiczne, ale ten rodzaj magii w Pythonie jest dla mnie nie tylko akceptowalny, ale nawet pożądany. Polecam wszystkim, którzy szukają wygodnego micro frameworka dla Pythona.

Dlaczego liczy się jakość implementacji?

Programowałem już w kilku frameworkach. Jeszcze kilka przede mną.Czy zgodzicie się, że wszystkie frameworki są takie same? Nie - wszak różnią się między sobą... To inaczej. Czy zgodzicie się, że robią to samo? Inaczej, że próbują osiągnąć ten sam cel? Moim zdaniem każdy framework (wszak nazywa się frameworkiem) ma za zadanie:

• stworzyć środowisko pracy charakterystyczne dla prac webdeveloperskich
• zapewnić bezpieczeństwo aplikacji charakterystyczne dla webserwisów
• ułatwić utrzymywanie projektu poprzez separację - na przykład z użyciem wzorców projektowych

Każdy framework realizuje te cele na swój własny sposób. Jest jakaś warstwa obsługi bazy danych, tworzony jest jakiś wzorzec do udostępniania funkcji klientowi (MVC, REST, EDA), proponowany jest system wprowadzenia nieinwazyjnie logiki do warstwy HTML (szablony, widoki). Realizacja tych celów mogłaby stanowić pewną definicję frameworka.

W tym świetle frameworki nie różnią się od siebie. Wszystkie realizują swoje cele. Django czy Pylons, Rails, CakePHP, Symfony, Kohana albo Web2Py, Lift - wszystkie z definicji realizują te cele. Którego użyć do prostego projektu, który da się zrealizować w każdym z nich?

Wielu może dziwić, drażnić postawa często prezentowana przez Jarka Zabiełłę - zachwytu nad perfekcją programistów tworzących konkretny framework. Technologiczną doskonałością Merba, geniuszem z jakim zakodowany jest Lift. U mnie ta postawa znalazła w końcu grunt.

Lepsza jakość kodu i restrykcyjne coding standard (np. w Merb) oznacza wiele dobra: prostsza refaktoryzacja, mniejsza ilość potencjalnych błędów, znacznie zwiększone bezpieczeństwo, posunięty performance. Taki jest właśnie Merb.

Ponawiam pytanie: "Jaki framework wybrać do prostego projektu, który można stworzyć w każdym z nich?" odpowiedź - najdoskonalszy technologicznie. Jaki framework wybrać aby mieć pewność największego bezpieczeństwa? Najdoskonalszy technologicznie? Jaki framework wybrać aby moja aplikacja była możliwie najszybsza? Najdoskonalszy technologicznie.

Tak. Frameworki różnią się między sobą: dostępnymi wtyczkami, architekturą, możliwościami, językiem programowania. Do momentu, w którym którykolwiek z tych składników odgrywa rolę - walka między frameworkami nie jest równa i w konkretnych przypadkach wybór jednych przeważa nad drugimi. Jednak dla prostych projektów, gdy nie masz bariery poznania nowego języka programowania tylko doskonałość technologiczna może przeważyć nad użyciem jednego ponad drugim.

Mam nadzieję, że udało mi się oddać moje ostatnie przemyślenia, na których znalazło grunt podejście Jarka Zabiełły, który często rozwodzi się nad doskonałością techniczną pewnych rozwiązań :) Wszak dla najlepszych przestaje być ważne, że potrafią coś zrobić, a zaczyna być ważniejsze jak to zostało wykonane.

Skoro coś można zrobić na wiele sposobów to czemu nie ma budzić uznania i szacunku i być przez nas wybieraną technologia, która została zrobiona w sposób genialny i najlepszy?

Co wkurza mnie w ludziach, którzy wielbią Railsy

Tytuł jest troszkę kontrowersyjny i powinien brzmieć "co wkurza mnie w ludziach, którzy wielbią jeden - jedynie słuszny - framework" bo o to mi naprawdę chodzi. Celowo jednak napisałem, że o Rails mi chodzi ponieważ wszyscy, którzy rażą mnie swoim podejściem wśród moich znajomych to właśnie Railsowcy.

Nie jestem uczulony na każdego kto broni jakiegoś frameworka. Tak na przykład bardzo lubię argumentację Jarka Zabiełły, który dałby się dosłownie poszatkować za Lifta, skoczyć w ogień za Merbem czy odtańczyć taniec radości przez Web2Py. Nie widzę nic złego w posiadaniu swojego ulubionego frameworka. Co więc mnie denerwuje?

Niepowetowanie rozdrażniają mnie osoby, które programowały tylko w jednym (nie ważne jakim) frameworku i mając takie doświadczenie opowiadają o nim jak o wybawieniu. Po prostu krew mnie zalewa. Ktoś programował sobie w PHP (na sucho): echo do HTML, include $_GET do ładowania stron, mysql_query do robienia zapytań i nagle [... tu wstaw nazwę jakiegoś frameworka, który stał się religią dla Twoich znajomych]! Po prostu objawienie! Ścieżka światła otworzyła się przed biednym, pogrążonym programistą i doznał olśnienia! I od tamtej pory nie rozstaje się ze swoją cudowną technologią, genialnym wybawicielem! Po prostu ... śmiechu warte. Tyle powiem.
Nie mogę znieść braku chłodnego dystansu do technologii, której się używa. Pewnej podejrzliwości i niepokoju: A może istnieje jeszcze inna, może lepsza technologia? Może to nie jest szczyt wszystkiego? Może w innych językach programowania istnieją inne równie dobre a może nawet lepsze frameworki? Taka właśnie postawa budzi we mnie szacunek do adwersarza i otwiera na jego argumenty.
Rozumiem jak najbardziej - użyciem frameworka jest ogromnym postępem i tak! zgadzam się w 100%! jest często niesamowitym, ekscytującym, powalającym na kolana odkryciem. Szczególnie w świetle czasu jaki zyskujemy - tworząc aplikację. Jednak zdrowe moim zdaniem jest gdy ów zachwyt pcha programistę do przodu, nie daje mu spokoju, każe poznawać nowe frameworki, lepsze technologie, doskonalesz rozwiązania. Nie mogę znieść gdy widzę, że ktoś po prostu na tym zachwycie - spoczął na laurach. Jego poglądy zaczynają wtedy dla mnie przypominać religię, a argumentacja staje się "nawracaniem" na moją stronę.

Mało kto będzie krytycznie i obiektywnie podchodził do frameworków jeżeli nie pozna na wstępie kilku. Poznanie wyłącznie jednego i zatrzymanie się na nim - w 99% skazuje człowieka na brak obiektywizmu. Nie jest wtedy ani dobrym adwersarzem do dyskusji bo jedyne co może powiedzieć, że to czego używa jest dobre (a często mówi, że najlepsze) - jednak co znaczą jego słowa kiedy nie ma porównania.
Dużo bardziej wiarygodną wypowiedzią jest dla mnie zdanie programisty, który nigdy nie programował we frameworku, o którym mowa, ale dużo o nim czytał i tworzył oprogramowanie w kilku innych pochodzących z różnych języków programowania niż opinia osoby, która poznała swój pierwszy framework i tak się nim zachwyciła, że nie pozwala jej to iść dalej.
Na koniec może troszkę powiewu optymizmu. Trzeba cieszyć się z każdej osoby, która zacznie używać frameworków. Nawet takiej, która uczyni z tego religię. Niech programuje w nim nawet nieświadomie i źle, ale zawsze będzie oznaczało to więcej lepszej jakości kodu aniżeli ta sama aplikacja miałby być pisana na sucho.

Framework's killers*

Rozdzielczość wykresu jest umowna i nie stanowi żadnej faktycznej miary mówiącej o skali różnić w czasie projektowania.

Tworzenie witryn na bazie Drupala, w kolejnych projektach, zajmuje coraz mniej czasu. Godziny mu poświęcone zwracają się znacznie szybciej niż te zainwestowane we frameworki. Tyle z teorii - czas na fakty.

Niewdzięczny start

Początki to przedzieranie się przez kolejną dokumentację. Opis klas, funkcji, doczytywanie szczegółów. Wewnętrzna walka nakazująca szukać rozwiązania we frameworku nie zaś w samym języku programowania.

Wiele zależy tu od naszych zdolności, jakości dokumentacji, dostępnych materiałów, aktywności społeczności na forach i grupach dyskusyjnych. W obydwu przypadkach wszystko zaczyna się mniej więcej od tego samego poziomu.

Framework-bajka

Rozpoczynający swoją pracę z frameworkami doznają szokujących usprawnień.

Granicząca z cudem autonomiczność warstwy baz danych (ORM shock!). Drastycznie zwiększona kohezja kodu po rozmieszczeniu go w kontrolerach (controllers' code improvement). Wszystko-ułatwiające helpery wykonujące dokładnie to czego potrzebujemy (helpers exactly).

Zaczynamy z wolna czuć się jak Alicja w Krainie Czarów, której nagle pokazano wejście do króliczej nory. Pozornie ciemne i ciasne, jednak kryjące w sobie cały nowy świat. Świat, w którym ciężko jest znaleźć zadanie wymagające napisania więcej niż 7 linii kodu.

Oszczędność czasu we frameworkach

W następnych projektach - zaczynamy wykorzystywać stworzone przez nas rozwiązania ponownie. Prawo lenistwa.

Do kolejnych projektów przenosimy klasy, funkcje, z czasem kontrolery, modele a nawet całe biblioteki. Od czasu do czasu coś modyfikujemy, dodajemy kilka nowych opcji, poprawiamy znalezione błędy.

Godziny poświęcane na tworzeniu strony zaczynamy liczyć w wykonanych instrukcja copy/paste. Jedyne usprawnienia stanowi używanie skrótów klawiszowych zamiast opcji menu kontekstowego. Po pewnym czasie przestają działać nam klawisze [CTRL], [X], [C] i [V] a w koszta projektu zaczynamy wliczać nową klawiaturę.

Magiczny świat CMS'ów

Wczoraj był u Ciebie klient. Zamówił witrynę. W nocy miałeś sen. Rozmawiałeś z wróżką. Mówiła o jakimś fantastycznym rozwiązaniu. Posiada wszystkie zalety framework'a. Większość standardowych klas ktoś zaprogramował za Ciebie. Witryna jest już praktycznie gotowa. Twoim jedynym zadaniem jest dostosować wszystko do Twoich potrzeb.

Drupal - gotowi start !

W Drupal'u dostajemy wszystko to, a nawet więcej. Z punktu widzenia developera. Gdzieś na spodzie funkcjonuje sobie zwykły framework. Taki z abstrakcją dla baz danych, helperami, systemem templatów i innymi featurami.

Na nim dopiero napisane są klasy do CMS'a. Tutaj dostajemy kilkanaście mechanizmów ekstra: ACL'e, klasy użytkowników, newsów, system rejestracji i logowania, raportowanie... Wymieniać można naprawdę długo.

Poza klasami - system szablonów: formularze, panele administracyjne, tabelki, domyślne CSS'y. Do tego kilka autorskich bibliotek JS dzięki, którym interfejs stylizuje się (sic!) na aplikację webową.
Z punktu widzenia użytkownika - gotowa strona, developera - wymarzony punkt startu.

Gdzie oszczędzamy czas ?

Zyskaliśmy już czas na projektowaniu i adaptacji standardowych elementów witryny. Systemu użytkowników, newsów, ACL'e, menu - są już gotowe. Doinstalowanie dodatkowych modułów, autorskich czy też pobranych z witryny projektu, zajmuje kilka chwil. Znacznie mniej niż wkoponowywanie ich do strony na poziomie kodu. O to dba Drupal.

Tworzymy wyłącznie to czego nam brakuje, ewentualnie modyfikujemy istniejące rozwiązania. Możliwość jakie dają 144 funkcje (Drupal 7) pozwalające wpiąć się w niemal każdy mechanizm przygotowanych przez twórców - są nieograniczone. Wolno nam wszystko: od modyfikowania pól formularzy po przeprojektowywanie zapytań SQL.

Stworzenie zwijanego pola fieldset, sortowania drag & drop, przyklejonych nagłówków tabel, poziomych zakładek. Wszystko wymaga dodania parametru przy wywołaniu helpera lub nadania odpowiednich klas CSS. JavaScript ? A co to jest ?

Podsumowanie

Znacznie szybciej modyfikuje się gotową witrynę, aniżeli pisze na nowo. Szczególnie łatwo w przypadku Drupal'a, który do takich przeróbek został stworzony. API pozwalające zmieniać każdy aspekt działania aplikacji. Obszerna tutoriale dla developerów. Świetnie udokumentowane API. Czytelny, jednolity kod. Setki funkcji i gotowych bibliotek. Bibliotek które od lat sprawdzają się na dziesiątkach tysięcy witryn internetowych.

Barierę stanowi pomyślenie o CMS'ie w funkcji środowiska developerskiego - nie gotowej aplikacji. Przyjrzenie się na ile modyfikowanie jest szybsze od tworzenia. O ile łatwiej jest zmieniać dobrze zaprojektowane rozwiązania w miejscu ich tworzenia. Jednak ostrzegam - być może już nigdy więcej nie sięgniesz do żadnego frameworka.

* Wpis traktuje o Drupal'u ponieważ jest najlepiej znanym autorowi, od strony developerskiej, CMS'em. Nie wyklucza on faktu iż równie dobre, a nawet lepsze, efekty można uzyskać w przypadku innych, dobrze zaprojektowanych systemów zarządzania treścią.

Komentarz do MVC - czyli frameworki PHP

Dziś przeczytałem świetny wpis wyjaśniający o co chodzi w MVC. Osobiście chciałem dodać do niego mały komentarz, który mam nadzieję pojawi się również na blogu autora.

Ja dzisiaj - nie wyobrażam sobie tworzenia stron internetowych inaczej. Osobiście jednak - nie pisałem nigdy własnego Frameworka - raz tylko pomagałem koledze, gdyż uważam, że pisanie własnego MVC to wynajdywanie koła na nowo.

O Kohana nigdy nie słyszałem. Osobiście zaczynałem od CodeIgniter i jest to prosty framework. Jego zaletą, która jest ważna dla początkujących, jest fakt iż posiada dobrą dokumentację i można naprawdę szybko połapać się co gdzie jest.

Na kolejny ogień poszedł CakePHP. Tam dowiedziałem się co to jest scaffolding. Z cech, które przemawiają za CakePHP moim zdaniem jest na pewno obsługa drzew i ACL, których nie spotkałem w żadnym innym frameworku. Szczególnie widać to w wersji 1.2, w której pojawiło się wsparcie dla internacjonalizacji. Szalenie również podoba mi się mechanizm "elements", który moim zdaniem bardzo ułatwia tworzenie szablonów, z różnych powtarzalnych komponentów, pod, które możemy podkładać różne dane, co szalenie skraca pracę w tworzeniu szablonów. CakePHP posiada w najnowszej wersji mnóstwo innych bibliotek i wygląda mi na to, że obecnie jest to najlepszy framework.

Obecnie tworzę projekt z użycie Symfony. CakePHP w wersji 1.2 na pewno chciał doścignąć Symfony. Moim skromnym zdaniem - przypadkiem go prześcignął. Co do symfony. Posiada mnóstwo pluginów i dużą społeczność. Używa Propel, modele są więc generowane i dostępne ad-hoc - bez pisania jakiegokolwiek kodu. Dzięki użycia Propel modele generowane są w bardzo inteligentny sposób. Na koniec - bez pisania nawet połowy linijki kodu - dostajemy gotowe klasy w PHP, które obsługują między innymi CRUD oraz posiadają metody automatycznie pobierające dane z innych tabel używając złączeń. Dodatkowo są one szalenie elastyczne. Kolejna rzecz to scaffolding,który jest naprawdę piekielnie użyteczny i pozwala w 1 minutę(naprawdę właśnie w tyle) stworzyć funkcjonalny panel administratora do prostej aplikacji. W moim przypadku problemem okazało się korzystanie z dokumentacji, która z racji niekompletności,rozstrzelenia oraz braku opisania każdego modułu od A do Z (istnieje tylko kompletny opis API) jest nieużyteczna. Z tej przyczyn prawdopodobnie do czasu aż to się nie zmieni - będę korzystał z innych frameworków. Na obronę powiem tylko, że dokumentacji, która istnieje obecnie jest dużo, niemożna narzekać na jej brak czy na nie opisanie jakiś komponentów.Projekt jest jednak tak kolosalny, że stworzenie do niego dobrej dokumentacji to nie lada wyzwanie. Na razie, w moim mniemaniu jeszcze nie udało się temu wyzwaniu sprostać.

Innym ciekawym moim zdaniem framerowkiem jest Akelos, który jak możemy wyczytać na stronie internetowej, jest portem Ruby On Rails napisanym w PHP.Tyle z moich doświadczeń. Może okażą się dla kogoś pomocne w dalszej przygodzie z MVC. Chciałem przy okazji polecić swój artykuł, w którym również swojego czasu opisałem MVC na blogu Matriksa.

Pylons - moje przemyślenia

Całkiem niedawno postanowiłem poznać ciut bliżej pylons - pewien framework Pythona. Czytałem w różnych opisach (dat nie pamiętam), że pylons nie ma dokumentacji... Rzeczywiście - pewnych rzeczy w dokumentacji oficjalnej na witrynie http://wiki.pylonshq.com/display/pylonsdocs/Home się nie doszukałem, jednak nie są to jedyne źródła informacji !

Po pierwsze pogłoski iż jakoby pylons miał kiepską dokumentacje są nie trafione. Ten framework tak silnie korzysta z zewnętrznych, tworzonych w ramach osobnych projektów rozwiązań, że gdyby przestały istnieć framework przestałby funkcjonować przynajmniej na jakiś czas. Rozwiązania te, takie jak : SQLAlchemy czy Mako - mają własną dokumentację. Obszerną, dokładną, przerzystą dokumentację. Nie ma co się dziwić ... skoro to zewnętrzne projekty to czemu miałoby być inaczej ?

Dokumentacja istnieje, jest więc tylko troszkę rozproszona, ponieważ pylons korzystając z konkretych rozwiązań pokazuje tylko coś  "na start" i zaprasza do zapoznania się z dokumentacją np. SQLAlchemy w celu pogłębienia swojej wiedzy. Moim zdaniem to rozwiązanie jest rozsądne i słuszne - po co robić kopiuj wklej opracowania jakiegoś projektu z którego korzystasz jeżeli możesz po prostu do niego odesłać.

Zastanawia mnie tylko jedna rzecz. Django i Pylons, z nieznanych mi powodów, ale zapewne jakieś są, idą łeb w łeb ... gdzie jednak Django ma napisane wszystko "od siebie" a Pylons sam napisał może 2% tego co djangowcy bo przecież 98% to zewnętrzne rozwiązania z naklejką "ready to go !". Logicznie myśląc skoro pylons i tak "wykorzystuje" cudzą pracę to mogłoby rozwijać się znacznie szybciej niż django, w którym wszystko jest implementowane po djanogowemu na potrzeby frameworka.

I jeszcze na koniec - to nie prawda, że Pylons ma słabą dokumentację. Dokumentacja jest wystarczająca - choć oczywiście mogłaby być lepsza. Dla zapaleńców polecę jeszcze tylko polski tutorial do Pylons: http://python.rk.edu.pl/w/p/pylonsindex/

I kto mówił, że Pylons ma słabą dokumentacje ?