Wczoraj miałem przyjemność wziąć udział w warsztatach Tworzenie aplikacji w Django, prowadzonych przez Marcina Kaszyńskiego. Jako zagorzały Railsowiec skorzystałem żeby dowiedzieć się czegoś o Django od praktyka – i tak od pewnego czasu miałem zamiar zmierzyć się z tym frameworkiem. A zamiast samemu walczyć z początkami skorzystałem z okazji, aby pierwsze kroki zrobić pod okiem kogoś doświadczonego.
Najpierw – słów kilka o organizacji samych warsztatów. Było to 7 bitych godzin przy klawiaturze komputera (od 10 do 18 z przerwą na obiad). Materiał szkoleniowy to przygotowana instrukcja jak budować aplikację – na przykładzie prostej strony typu newsowego. Tak na marginesie – ciekawe jaki wpływ na wybór tematu ma historia Django, które powstało jako narządzie do budowania serwisów Lawrence Journal-World. Możliwe, że Django ma odchylenie w stronę tego typu serwisów.
Hmm kolejna edycja warsztatów – czy można spodziewać się kolejnych gazet online? :)
Warsztaty Django – opinia
Instrukcja ta była zrobiona tak, aby samemu budować kolejne kawałki serwisu, ucząc się jak korzystać z kolejnych funkcji Django. Jednocześnie przygotowane materiały pomocnicze (design/CSS/zaślepki) powodowały, że serwis budowany na warsztatach szybko przybierał rozsądne kształty.
Tematy zostały tak dobrane, że fakt iż nie miałem do czynienia w ogóle z Pythonem przed tymi warsztatami (jedynie godzinę dzień wcześniej poświęciłem aby nauczyć się podstaw składni – wcięcia!) nie stanowił najmniejszego problemu.
Jednak nauka nie polegała na copy&paste – każde zagadnienie najpierw było wyjaśnione (tworzenie modeli, podpinanie interfejsu administracyjnego, bardziej zaawansowane korzystanie z ORM) a następnie zadanie tego typu trzeba było wykonać kilka razy w różnych miejscach aplikacji, dochodząc do części rozwiązań samemu. Dzięki temu znacznie łatwiej zapamiętać przerabiany materiał – co przy jego dużej ilości jest wielką zaletą formy w jakiej Marcin prowadzi warsztaty.
No i co Railsowiec powie o Django?
Po pierwsze pamiętajcie – że w tej chwili moje doświadczenie z Django to tylko kilka godzin. Ale… Mam silne postanowienie aby przynajmniej jeden projekt zrobić na Django aby zyskać lepszy ogląd – to już o czymś świadczy :)
Do zalet Django zaliczyłbym przede wszystkim interfejs administracyjny, który (całkiem zaawansowany) może zostać zbudowany niskim kosztem – Railsowe scaffoldy się do tego nawet nie umywają.
Drugą zaletą (choć niektórzy nazwą to wadą) jest bardzo uproszczony język szablonów (odpowiednika widoków z Rails). To, że jest on naprawdę uproszczony powoduje, że logika aplikacji jest tam gdzie powinna być (czy może raczej – nie ma jej tam gdzie jej nie ma być). W Railsowych widokach pełna moc Rubego jest dostępna wewnątrz tagów ERb i niestety dla wielu ludzi jest to pokusa zbyt silna, aby nie pójść na skróty. W większych projektach, które muszą być dłużej utrzymywane, albo w których bierze udział większa liczba osób to jest zaleta, że w szablonach nie da się umieścić zaawansowanej logiki.
Co na pierwszy rzut oka mi się nie spodobało? Hmmm mam wrażenie, że Django (Python?) jest jednak znacznie bardziej rozwlekły – trzeba się jednak więcej napisać aby uzyskać zamierzony efekt.
Więcej na razie nie powiem – ale to dlatego, że na razie mam za mało doświadczenia – ale mam zamiar to zmienić – wtedy będę mógł oba frameworki porównać trochę dokładniej. Na razie – Railsów porzucać nie mam zamiaru :)
A Ciebie Django interesuje?
Jeśli chcesz sobie samemu wyrobić opinię na temat tego czy Django może Ci być przydatne – to szczerze polecam warsztaty prowadzone przez Marcina – w lutym będzie kolejna edycja. Warto się zapisać, przejść i mieć własne zdanie na temat Django.
Może dla Ciebie Django okaże się Tym co zmieni twoje życie zawodowe (i nie tylko).
UPDATE
O jeszcze jedna rzecz, którą Rails wygrywa – domyślna konfiguracja sprawdza się o wiele lepiej. A konkretnie – RAILS_ROOT – przeniesienie projektu Rails w nowe miejsce to nie jest zmienianie ścieżek aby podstawowe rzeczy działały (katalogi widoków, itp).
Z fajnością panelu administracyjnego bym się nie zgodził – niby DRY, ale trzeba mocno nagrzebać by rzeczywiście dostosować go do swoich potrzeb – jak dla mnie tutaj właśnie scaffolding wygrywa, bo zmienianie wyglądu czy działania scaffoldów jest o wiele prostsze.
Co do rozwlekłości pisania – myślę, że bardzo wiele z niej wynika z zamierzenia twórców – Django nie ma być automagicznym narzędziem, które działania nie rozumiesz, a frameworkiem z filozofią, której rozumienie upraszcza pracę z nim.
Co do update’u – rozwiązaniem które stosujemy w pracy by uprościć tworzenie djangowych projektów jest tworzenie ustawień lokalnych – skryptu, który po nazwie hosta rozpoznaje jaka konfiguracja ma być używana. To też bardzo mocno upraszcza pracę, ale nie jest domyślnym rozwiązaniem Django – jeśli byś potrzebował mogę przesłać szablon takiego skryptu.
A osobiście dodam, że najgorszą rzeczą w Django są fixturesy. W bardziej skomplikowanych projektach są zupełnie nieprzydatne – modyfikowanie wymaganych kluczy głównych w pliku z danymi inicjalizacyjnymi jest po prostu koszmarem.
@Jachu
Hmmm z tymi scaffoladmi to roznie bywa. I tak widoki zwykle trzeba mocno przerabiać. Jak to jest z mocnym dostosowaniem panelu Django – nie mam pojęcia, nawet tego jeszcze nie próbowałem. Ale sądzę, że dla naprawdę sporej liczby aplikacji możliwości tego panelu będą good enough. Zwłaszcza dla aplikacji typu jednostrzałowiec, albo proof of concept to jest akceptowalne rozwiązanie.
Co do Rails i rzekomej magii, która się tam dzieje… Może mój problem polega na tym, że ja zaczynałem przygodę z Rails w okolicy 0.11/0.12 i siedzę w tym długo, że ja tam magii nie dostrzegam. Przecież to działa w oczywisty sposób :))
Z tym RAILS_ROOT to chodzi mi o przykład podejścia. WIEM, że da się to załatwić w prosty sposób własnymi paroma linijkami kodu. Ale to przykład prostego problemu, który Rails usuwa sprzed developera i można zająć się samym mięskiem (choćby pisaniem Railsowego admin interface :)) )
Co do fixtures – jeszcze w ogóle do testowania nie doszedłem, ale takie opinie już słyszałem (że fixtures to masakra).
Jachu: a kiedy ostatnio przyglądałeś się temu panelowi? W 1.0, po zmianach newforms i newforms-admin zmiany znacznie się uprościły.
Na warsztatach przerabiamy między innymi podstawienie własnego formularza i sprawdzania poprawności danych według własnych reguł, i w adminie, i na własnych stronach. Ze względu na ograniczenia czasowe nie przerabiamy dodawania nowych widoków do admina, ale to też jest teraz bardzo proste.
A co do rozwlekłości — jak rozumiem, nie chodzi o rozwlekłość Django, tylko raczej samego Pythona i podejście „explicite over implicite” :)