Archiwum is back

Poprawiono najbardziej denerwujący mnie błąd w Django z ostatnich czasów i dzięki temu wróciło archiwum. Oh, my...

Opublikowany 25 czerwca 2008 o 22:35, oznaczony etykietami: blog django programowanie python (2 komentarze).

Sława, sława!

http://oebfare.com/blog/2008/jun/24/django-code_swarm/

Około drugiej minuty, w prawym górnym rogu...

Opublikowany 24 czerwca 2008 o 20:51, oznaczony etykietami: django free software / open source programowanie python.

Zmiana planów w ostatniej chwili

Dosłownie w ostatniej chwili zdecydowałem się na zmianę dostawcy hostingu na djangohosting.ch, pomimo że byłem zdecydowany na coś innego. Po sugestii Thomasa (dzięki!) przyjrzałem się usłudze dokładniej i postanowiłem dać szansę. Wykupiłem najtańszą opcję, wypróbowałem one-click-django-installer i oczywiście zameldowałem się po SSH. Już pierwsze pół godziny sesji przekonało mnie, że jest tam o wiele przyjemniej niż na Alwaysdata — nie ma żadnych myków z przestawianiem $HOME, no i zwiększanie opcji jest bardziej granularne (oddzielnie procesy, porty, pamięć i przestrzeń dyskowa), a cała infrastruktura w dużej mierze przypomina to, co jest na MegiTeam.pl, z paroma udogodnieniami:

  • można uruchomić serwer developerski django i w razie problemów mieć dostęp do pełnego tracebacka;
  • pełna kontrola nad uruchamianiem FastCGI;
  • łatwiejszy dostęp do logów Lighttpd (chociaż jest w nich równie mało, jak w logach nginxa na megiteam).

Ogólnie wygląda to bardzo dobrze, a przy tym jest trochę taniej.

Opublikowany 24 czerwca 2008 o 10:40, oznaczony etykietami: django hosting internet megiteam programowanie python (2 komentarze).

Sztuczny tłok

Dużo się ostatnio dzieje w Django — co chwilę ktoś commituje zmiany do repozytorium i można odnieść wrażenie, że opublikowanie daty wydania wersji 1.0 obudziło w developerach nowy zapał i chęć do posprintowania na zakończenie wyścigu.

To mylne wrażenie. Przytłaczająca większość pojawiających się w repozytorium zmian to są poprawki w dokumentacji, w docstringach oraz style fixes. A kod poprawiający rzeczywiste problemy czeka sobie na lepsze czasy.

Ten wpis był tytułem ochłodzenia emocji, gdyby ktoś widząc tempo commitów wnioskował z tego, jak dużo i szybko kod w Django jest poprawiany... ;)

Opublikowany 23 czerwca 2008 o 09:13, oznaczony etykietami: django free software / open source programowanie python (2 komentarze).

Zdecydowałem się na dostawcę

To był tydzień pełen przemyśleń, ale w końcu doszedłem do jakichś wniosków. Mój najbliższy projekt będę hostował na Alwaysdata. Co prawda całość serwisu jest po francusku, ale jakoś daję sobie z tym radę.

Ujęło mnie to, że jest:

  • tanio (€ 6 za miesiąc w najtańszej opcji);
  • dobry support na forum (po angielsku!);
  • dość duża wolność, jak na shared plan;
  • krótki ping, serwery stoją w OVH w Roubaix (Francja).

W związku z małą ilością dostępnego miejsca na dysku, będę musiał media i uploady na S3, ale nie powinno być to jakoś szczególnie uciążliwe.

Konkurent (djangohosting.ch) przegrał głównie przez zerowy wybór w dziedzinie bazy danych (tylko MySQL, bez PostgreSQL), ale nie była to przegrana autorytatywna. Dam mu szansę następnym razem. ;)

Opublikowany 22 czerwca 2008 o 22:11, oznaczony etykietami: django hosting internet programowanie python (3 komentarze).

Wybierz sobie dostawcę

A tymczasem wybór dostawcy hostingu pod Django jest zaskakująco mały, o ile ktoś celuje w użytkowników z Polski, a przy tym nie dysponuje kwotą wystarczającą do wykupienia sobie dedyka w Hetznerze.

Jest za Atlantykiem kilka firm, które chętnie przytulą większą lub mniejszą aplikację w Django za bardzo skromną kwotę, ale te miejsca mnie nie interesują. Ping po 200ms to nie jest coś, na co chciałbym narażać moich klientów. Na Ukrainie też jest pewna firma, która chętnie pohostuje aplikację za niewielkie pieniądze, ale na Ukrainę pingi z Polski lecą wolniej, niż do Francji, bo pakiety muszą zahaczyć o Frankfurt. Mili Szwajcarzy hostują się w Hetznerze, więc pingi do nich są co najmniej znośne, podobnie jak do Francuzów (ci z kolei się hostują w OVH). W Polsce mamy chyba tylko MegiTeam i ITL, ale ich ceny są zupełnie nie na miarę moich możliwości (przynajmniej o ile chodzi o cokolwiek więcej niż ten blog). W efekcie wybór jest między Francuzami a Szwajcarami, a każda z tych ofert ma znaczące niedobory (choćby w porównaniu do WebFaction).

Mam jeszcze 2 tygodnie na podjęcie decyzji.

Opublikowany 15 czerwca 2008 o 21:04, oznaczony etykietami: django hosting internet.

Zniknęło archiwum

Ale wróci, gdy tylko w Django zostanie poprawiony błąd ze zgłoszenia 7155 (patch działa, ale nie będę go nakładał ręcznie, nie pali się).

Opublikowany 25 maja 2008 o 17:54, oznaczony etykietami: blog django.

QS-RF w trunku Django

Queryset-refactor zlądował w trunku Django. Wspominam z kronikarskiego obowiązku, bo nie zauważyłem żadnych problemów z moimi aplikacjami w związku z tym.

Opublikowany 27 kwietnia 2008 o 23:15, oznaczony etykietami: django free software / open source programowanie python (1 komentarz).

Korci mnie Django Dash

Django Dash to konkurs programistyczny podobny do Ludum Dare czy PyWeek — chodzi o to, żeby w 48 godzin wyprodukować kompletną, działającą aplikację w Django. Mam pewien pomysł i nawet wizję, jak to zrobić, ale nie jestem pewien, czy wytrzymam te 48 godzin, czy po prostu nie jestem za stary na takie kodowanie. ;)

Opublikowany 15 kwietnia 2008 o 14:12, oznaczony etykietami: django programowanie python (3 komentarze).

Nie mam wizji na AppEngine

Dostałem to konto i po całym weekendzie zastanawiania się nie umiem sobie wyobrazić aplikacji, którą mógłbym napisać i odpalić na AppEngine. Ograniczenia są cokolwiek duże, ale sama perspektywa jest przez cały czas kusząca. Dam sobie jeszcze tydzień na przemyślenie, czy w ogóle w to brnąć.

Przez cały czas mam przeczucie, że to jest coś, co daje duże możliwości.

Opublikowany 13 kwietnia 2008 o 21:08, oznaczony etykietami: django hosting internet programowanie python (2 komentarze).

Got it, gonna try it over the weekend

Thanks for signing up to try Google App Engine! Your account has been activated, so you can begin building applications!

No to zobaczymy, co się z tego da wyciągnąć... Mam pod ręką kilka eksperymentalnych projektów, któryś z nich zląduje na AppEngine.

Opublikowany 11 kwietnia 2008 o 09:57, oznaczony etykietami: django hosting internet programowanie python (3 komentarze).

No i chyba mnie ominęło

Wszystko wskazuje na to, że moje zgłoszenie do testowania Google AppEngine nie zostało wylosowane, 10000 kont zostało rozdanych, a mnie zostało czekanie na następny batch i ćwiczenie na lokalnym dev serwerze. Znajomy zaproponował, że da mi jedną ze swoich trzech przydziałowych aplikacji, żebym mógł sobie potestować, więc pewnie nie będzie to trzening tak całkiem na sucho...

W każdym razie już widać, że o ile z Django na AppEngine zostaje bardzo dużo, to modeli używać trzeba tych dostarczanych przez Google. Nie minęło wiele czasu, a już pojawiły się plany rozszerzenia zaplecza bazodanowego Django o obsługę API przechowywania danych na AppEngine. Może to zaowocować szybszym merge odgałęzienia queryset-refactor do głównej gałęzi rozwojowej Django.

W obecnej formie na AppEngine nie wszystko jest zaimplementowane (nie ma np. M2M), z niektórych rzeczy trzeba zrezygnować, jak z interfejsu administracyjnego, czy z djangowego mechanizmu sesji, ale i tak jest to na tyle ciekawe, żeby chcieć dostać sztukę dla dokładniejszego przyjrzenia się. :)

Opublikowany 8 kwietnia 2008 o 16:39, oznaczony etykietami: django hosting internet programowanie python (1 komentarz).

Hot! (znowu się spóźniłem)

Google wystrzeliło z nowym pomysłem — AppEngine to nowy (i z opisu wynika, że rewolucyjny) hosting aplikacji webowych w ścisłej integracji z usługami Google, na razie przede wszystkim w Pythonie. W domyślnej instalacji jest Django 0.96.1, ale można też wziąć sobie wersję z SVN. Na razie trochę niejasne jest, w jaki sposób połączyć implementację modeli by Django z API, którego używania wymaga Google, ale sądzę, że wszystko się wyjaśni wkrótce.

I jak zwykle się spóźniłem z zapisaniem, trafiłem na waitlistę...

Opublikowany 8 kwietnia 2008 o 09:35, oznaczony etykietami: django hosting internet programowanie python (1 komentarz).

Jakiś problem z Akismet

Akismet robi jakieś hocki-klocki, gdy w komentarzu wpisuje się link do strony z plikami listy mailowej WARPY. Trzeba będzie to zbadać.

Opublikowany 5 kwietnia 2008 o 21:41, oznaczony etykietami: blog django free software / open source internet programowanie.

Aksimet poszedł w krzaki

Nie wiem, na którym końcu łańcucha pokarmowego został popełniony błąd, ale przez kilka godzin nie można było dodawać komentarzy dzisiaj z powodu brakującego pola user_agent, którego (zupełnie nie wiedzieć czemu) system antyspamowy nie dostawał podczas sprawdzania komentarza.

Przy okazji wyszło na jaw, że logi nginxa, jakie gromadzi megiteam.pl nie są szczególnie przydatne — nie wiadomo co jest logowane (stdout? stderr?), nie wiadomo kiedy wystąpił błąd, bo nie ma daty i czasu przy wpisach w logu fastcgi, są jedynie w access_logu, ale tam nie ma z kolei komunikatów o błędach. Zresztą, w logu fastcgi też ich nie ma, jedynie ślady w postaci komunikatów to broken pipe.

Opublikowany 27 marca 2008 o 21:05, oznaczony etykietami: blog django hosting internet megiteam.

To w końcu umierają, czy nie?

Umierają, umierają, żadna przecież nie trwa wiecznie. Idea WarPy okazała się jednak nieco bardziej żywotna, niż przypuszczałem — agonia potrwa co najmniej o 2 tygodnie dłużej.

27 marca Marcin Świderski (forgems) przedstawi wprowadzenie do Django, godzina i lokalizacja ta sama co zawsze (19:00 na "elce"). A tydzień później, czyli 3 kwietnia, w ramach nadrabiania zaległości, opowiem o tłumaczeniu i lokalizowaniu programów w Pythonie (czyli o i18n i l10n).

Opublikowany 23 marca 2008 o 20:49, oznaczony etykietami: django python warpy (4 komentarze).

Wyczesane zarządzanie obiektowym keszem w Django

Bardzo, bardzo dokładnie przyglądam się wszystkiemu, co związane z cache na poziomie obiektów w Django (np. projektowi django-orm-cache). Znalazłem blogowy wpis (po rosyjsku, a jakże!), który opisuje rozwiązanie bardzo podobne do tego, którego i my używamy, ale o wiele bardziej kompletne. Wypadałoby to teraz gdzieś przetestować, ale w środowisku, w którym miałoby to jakikolwiek sens, nie za bardzo możemy — po prostu nie ma na to czasu...

Ku pamięci, jak to Aleksiej Koszeliew załatwił sprawę odświeżania obiektowego cache w Django. Polecam uwadze, jeżeli kogoś też interesuje to, jak inni dają sobie radę z wygaszaniem cache...

Opublikowany 9 marca 2008 o 21:13, oznaczony etykietami: django internet praca programowanie python.

Hi, all, I'm official

Mój pierwszy commit do repozytorium Django, jako oficjalnego maintainera polskiego tłumaczenia.

Opublikowany 1 marca 2008 o 22:54, oznaczony etykietami: django free software / open source programowanie python (1 komentarz).

Ludzie mają problemy

A my nie! (My, czyli kilka naszych aplikacji)

Iwan Sagalajew, pracujący dla yandex.ru, podzielił się kilkoma spostrzeżeniami po nieudanym odpaleniu nowego serwisu społecznego. Czytałem to z niekłamanym zadowoleniem — większość problemów, które tam opisał, nie ma nawet szans, żeby nas dotyczyć. Po kolei:

  • zbyt długi czas zapisu danych sesji, nie dotyczy nas, bo sesje trzymamy w memcache;
  • efekt "dog-pile", nie dotyczy nas, bo rzeczy kosztowne robimy poza aplikacją (poniekąd asynchronicznie);
  • pomimo nacisków naszego DB-speca, nie normalizujemy naszego modelu nadmiernie.

Nie mam złudzeń, że w pewnym momencie będziemy musieli troszkę przyciąć nasz radosny bałaganik, ale aplikacja została zaplanowana z tak dużym zapasem, że to na pewno nie nastąpi w ciągu najbliższych kilku miesięcy...

Mała aktualizacja, pod wpływem komentarza Bluszcza — to on to wymyślił. A żeby nie rozpłynął się w samozachwycie, to wymyślił też parę marnych rzeczy, ale tego co marne pozbędziemy się prędzej czy później...

Opublikowany 25 lutego 2008 o 21:21, oznaczony etykietami: django free software / open source internet praca programowanie python (7 komentarzy).

Jedno oko na Maroko

Jest kilka projektów związanych z Django, na które warto jest mieć oko, z różnych względów. Niektórych używam, więc z konieczności śledzę ich rozwój (m.in. django-registration i django-comment-utils), ale są też takie, które rokują rozwiązanie trapiących mnie problemów.

Jednym z takich projektów jest django-orm-cache, a problem, który ma on rozwiązać dotyczy każdego, kto używa cache na poziomie obiektów w Django. Został on opisany przez Davida Cramera (który także jest pomysłodawcą i jednym z developerów tego projektu). W skrócie chodzi o to, że używany na poziomie obiektów i ich grup cache staje się dodatkowym storage, w którym trzeba odzwierciedlić zmiany, wprowadzone w głównym storage (czyli w samych obiektach). Dobrego rozwiązania nie ma — można rygorystycznie pilnować wygaszania obiektów w cache przy każdej modyfikacji (przydają się tu sygnały), można wersjonować klucze przy użyciu jakiegoś znacznika, ale żadne z tych rozwiązań nie jest ani wygodne, ani łatwe. Django-orm-cache ma ułatwić życie, przejmując zadanie automatycznego wygaszania obiektów w cache przy każdej modyfikacji obiektu.

Projekt nie jest jeszcze w stanie nadającym się do użytku, ale widać w nim jakiś ruch i to dobrze wróży. Chciałbym już teraz mieć coś takiego w mojej narzędziówce w pracy...

Opublikowany 20 lutego 2008 o 20:33, oznaczony etykietami: django programowanie python.

Mówisz - masz

Bluszcz zażyczył sobie RSS-ów dla konkretnych kategorii, żeby odfiltrować offtopiki na planecie. Tradycyjnie na wyrost kazałem mu się zgłosić w przyszłym tygodniu, ale to nie byłaby aplikacja w Django, gdyby rzeczywiście miało to tyle trwać. I trwało w sumie 20 minut. Proszę, masz RSS-y z kategorii (u mnie się one nazywają etykietami). Tę, która Cię interesuje, znajdziesz na stronie z wpisami pod etykietą python.

Opublikowany 13 lutego 2008 o 21:40, oznaczony etykietami: blog django internet programowanie python (2 komentarze).

Release early... Ale to nie my

Django zdaje się być całkiem w poprzek przyjętej zasadzie w świecie OS/FS: release early, release often. Ostatnie oficjalne wydanie Django miało miejsce 11 miesięcy temu, (23 marca 2007 roku). Rozumiałbym to, gdyby w projekcie niewiele się działo i rzeczywiście nie byłoby co wydawać, ale działo się wiele. Od tamtego czasu doprowadzono do używalności newforms, wprowadzono pełną wewnętrzną unikodowość, znacząco zmieniono także wyjście wprowadzając automatyczne eskejpowanie zmiennych podczas renderowania szablonów. Każde z tych wydarzeń (a pewnie i kilka innych) zasługiwałoby na wydanie, choćby po to, by nie powiększać przepaści pomiędzy kodem wydanym oficjalnie, a kodem rozwojowym.

Nie podoba mi się to.

Opublikowany 5 lutego 2008 o 21:32, oznaczony etykietami: django free software / open source programowanie python (8 komentarzy).

Jest nas dużo, ale wciąż za mało

Na Django People jesteśmy teraz na 4 miejscu, razem z Niemcami. Uważam to za całkiem niezły wynik. Przed nami są Brazylia, Wielka Brytania i US of A (w tym przypadku chyba bardziej sprawiedliwe byłoby liczenie według stanów, ale się nie upieram), więc raczej kraje albo dużo bardziej liczne ludnościowo od nas, albo bardziej ambitne, jeżeli chodzi o pokazanie się. Mogę się mylić (i pewnie się mylę), ale każde miejsce wśród pierwszych 7-8 powinno nas zadowalać, choćby z powodu tego, ile osób przychodzi na WARPY (w tym tygodniu zostało odwołane). Python zajął już poczesne miejsce w galerii języków programowania, a Django jest już powszechnie rozpoznawane.

To dobrze. Roboty jest dużo, a ten wózek musi się toczyć.

Opublikowany 24 stycznia 2008 o 21:37, oznaczony etykietami: django free software / open source internet programowanie python warpy (2 komentarze).

Wszystkie ręce na pokład!

Wczoraj pojawił się serwis Django People i w szybkim tempie wskoczyliśmy (my jako reprezentacja Polski) na 5 miejsce. To by mniej-więcej odpowiadało temu, co widać było m.in. na zeszłorocznym EuroPython, ale proszę nie ustawać w wysiłkach, klikać i się rejestrować. Naszym obecnym celem, po połknięciu Francji, Hiszpanii i Chin, są Niemcy!

Opublikowany 24 stycznia 2008 o 11:06, oznaczony etykietami: django internet (2 komentarze).

Tutoriale mnie dygają

W szczególności tutoriale do ramówek webowych. Każda ramówka w pewnym momencie dorabia się "20 minutes wiki tutorial" (czasem nawet w formie screencastu), ale w większości przypadków są one całkowicie bez sensu — nie pokazują tego, jak ramówka działa, nie uczą, jak jej używać, nie opisują jej komponentów. Zaczęło się od niesławnego screencastu RoR, a potem było już z górki. Pamiętam kilka lat temu, gdy w krótkim czasie wystartowały TurboGears i zaraz potem Django, że początkowo TG wygrywało popularnością właśnie z powodu posiadania takiego screencastu (i uzyskiwało opinię łatwiejszego do nauczenia). Lista mailowa TG pękała w szwach, zapowiadano nowe, ekscytujące możliwości kolejnych wydań ramówki, ale minęło kilka-kilkanaście miesięcy i to Django przejęło inicjatywę. Po kolejnych kilku-kilkunastu miesiącach TG uchroniło się przed zniknięciem, ale jak na pioniera radzi sobie coraz gorzej, już nie jest nawet numerem 2, bo w staraniach o przejęcie władzy nad sercami i umysłami developerów wyprzedziło je Pylons. Na szczęście, Pylons również posiada 20 minutes wiki tutorial, więc pozycja Django (które posiada jedynie nieoficjalny screeencast wiki na ShowMeDo) wydaje się być niezagrożona. ;)

Tak sobie właśnie przypomniałem... Jakiś czas temu prorokowałem, że z pierdyliarda ramówek webowych w Pythonie (był taki okres, kiedy powstawała jedna ramówka dziennie...), pozostanie nam 2-3 liderów i plankton — i tak się właśnie stało. Kto wymyśli tę, która zdetronizuje obecny numer 3 i stanie do wyścigu o pierwsze miejsce?

Opublikowany 18 stycznia 2008 o 22:41, oznaczony etykietami: django free software / open source internet programowanie python (8 komentarzy).

64MB RAM na Megiteam.pl

To mało czy dużo? Zależy... Moja aplikacja daje radę. Działa na jednym procesie FastCGI, swoje przydziałowe (?) 64MB RAM wykorzystuje w 100%. Szukałem jakichś wskazówek, jak ograniczyć apetyt aplikacji Django (uruchamianej na FastCGI) na RAM, ale znalazłem niewiele, a już na pewno nic nowego, nic, czego bym już nie wiedział. Być może nie jestem jeszcze aż tak bardzo zdesperowany, bo nie odczuwam, żeby aplikacji brakowało pamięci. Może to jest całkiem wystarczająca ilość, skoro aplikacja się jeszcze nie krztusi?

E, tam, nie mam chyba większych problemów... Jeszcze kilka lat temu nie przeszłoby mi przez myśl, że będzie mnie stać na hostowanie gdziekolwiek aplikacji w czymkolwiek innym, niż PHP. Zanim dorobiłem się hostingu na megiteam.pl nawet zastanawiałem się, czy nie iść na taniochę i nie przeprosić się z PHP. A tu — prawie jak spełnienie marzenia.

Aktualizacja z 18 stycznia: pani Magda Zarych, właścicielka megiteam.pl, uściśliła moje domysły. Aplikacja nie spożywa 64M, lecz w granicach 18M. Patrzyłem nie na to, co trzeba. Swoją drogą, przyjemnie, że firma wsłuchuje się w bicie serca klientów. ;)

Opublikowany 13 stycznia 2008 o 23:34, oznaczony etykietami: django free software / open source hosting internet megiteam programowanie python (8 komentarzy).

Pylons zniechęca

Podkusiło mnie i postanowiłem zrobić tutorial Pylons, trochę z ciekawości, a trochę podążając za modą. Ogólne wrażenie było raczej... marne. Zarówno jeżeli chodzi o Pylons, jak i o sam tutorial.

Przede wszystkim, tutorial stanowił nie lada wyzwanie. W pewnym momencie zalecane do wykonania polecenie zakończyło się bardzo brzydkim tracebackiem, który niewiele mówił. Nie wiedząc, co zrobiłem źle, darowałem sobie dalsze przerabianie materiału, ale następnego dnia zaświtała mi pewna idea i po sprawdzeniu okazało się, że miałem rację — kilka sekcji dalej omówione zostało ustawienie konfiguracji, którego brakowało. Po pokonaniu tej przeszkody udało się dobrnąć do końca.

Teraz trochę o wrażeniu, jakie robi automatycznie wygenerowany szkielet aplikacji. Zawiera on dużo więcej, niż szkielet, jaki generuje Django. W prawie każdym pliku używana jest konstrukcja from package.module import * co powoduje, że właściwie nie wiadomo, skąd co pochodzi. Dodatkowo autor tutoriala ma zadziwiający zwyczaj używania jednoliterowych skrótów, jak np. "h" dla "helpers" czy "c" dla "context" (wygląda to na dość powszechny obyczaj). Ilość tekstu do napisania się zmniejsza, ale traci na tym czytelność. Do tego dokłada się jeszcze duża ilość modułów, które importowane są na wszelki wypadek, a przynajmniej bez jakiegokolwiek wytłumaczenia. Wszystko to składa się na ogólne wrażenie chaosu.

A teraz o samej ramówce, a raczej o tym, co jest zalecane jako jej elementy w wersji 0.9.6.1 (bieżącej w chwili pisania tego artykułu). SQLAlchemy jest potężne, skomplikowane i nieprzyjemne. Routes jest potężne, skomplikowane i nieprzyjemne. System szablonów Mako jest potężny, skomplikowany i nieprzyjemny. Paster jest potężny, skomplikowany i nieprzyjemny. W efekcie Pylons jako całość jest potężne, skomplikowane i nieprzyjemne. Zupełnie jak Spring. Na pewno można przy jego użyciu zrobić milion sprytnych rzeczy, ale nie chodzi o to, żeby robić sprytne rzeczy, tylko żeby zrobić co trzeba i mieć przy okazji trochę dobrej zabawy.

Konkluzja jest dość oczywista — dopóki nie będę musiał, nie porzucę Django dla Pylons. Z pracy przy projektach w Django mam przynajmniej sporą dozę radochy...

Opublikowany 9 stycznia 2008 o 22:24, oznaczony etykietami: django free software / open source programowanie python (14 komentarzy).

Książki, książki

Po Pro Django, Web Development Done Right szykuje się kolejna książka o tej ramówce — James Bennet zaanonsował, że pisze książkę, która omawia Django od strony praktycznej. Książka jest już listowana na Amazon.com, więc sprawa wygląda na poważną. Wypada się tylko cieszyć. Przyda się taka książka wszystkim początkującym.

Jednym z zagadnień przez tę książkę poruszanych ma być pierwsza aplikacja w Django, czyli właśnie silnik blogowy. Ja swój napisałem w ciągu kilku wieczornych sesji, właśnie jako projekt szkoleniowy z migracji na nową wersję Django (choć wcale nie był pierwszą aplikacją, moją pierwszą aplikację można już podziwiać od dłuższego czasu w Rumunii, na Węgrzech i w Wielkiej Brytanii). Trudno jednak wymagać, by ktokolwiek zaczynał zaznajamianie się z Django od dużego, komercyjnego projektu na zlecenie międzynarodowego klienta...

Opublikowany 14 grudnia 2007 o 12:36, oznaczony etykietami: blog django free software / open source internet praca programowanie python (2 komentarze).

Co z tym Django?

Coraz bardziej niecierpliwię się tym, że Django wciąż nie ma oficjalnego wydania wersji, która miałaby pełne wsparcie dla unikodu i działające newforms. Pojawiły się pogłoski, że następne wydanie to nie będzie oczekiwane przez wszystkich 0.97, ale od razu 1.0 — to by oznaczało, że ilość rzeczy, jakie trzeba będzie zrobić podczas migracji będzie podobna, jak przy 0.91. Tutaj nie ma to wielkiego znaczenia, ale w pracy będziemy mieli dylemat...

Opublikowany 13 grudnia 2007 o 16:17, oznaczony etykietami: django free software / open source praca programowanie python.

Dobre wieści, Django znowu działa

Mądrzejsi ode mnie znaleźli błąd, poprawili i Django znowu działa przez FastCGI. Chwała nam i naszym kolegom, wiadomo komu precz!

Opublikowany 6 grudnia 2007 o 23:19, oznaczony etykietami: django free software / open source internet programowanie python.

Buggy weekend

Dwa straszliwe bugi objawiły się w projektach, które są mi z różnych powodów bardzo bliskie. Mało tego, żaden nie został jeszcze poprawiony.

Gajim ma problem z GnuPG — pewnym obejściem jest używanie gpg-agent (w sumie i tak powinienem go używać, ale chyba nie jestem jeszcze aż takim paranoikiem), ale jest możliwość doprowadzenia swojej konfiguracji do takiego stanu, że Gajim nie da się uruchomić. Wystarczy odhaczyć w ustawieniach konta "Używaj gpg-agent" i mieć wybrany jakiś klucz GPG do szyfrowania. Gajim daje segfaulta podczas uruchamiania. Sprawdzę jutro w pracy, czy ma to coś wspólnego z oprogramowaniem, jakie mam na domowej maszynce.

Django z powodu przeciekającego skądś obiektu SafeString zwraca nieprawidłową zawartość HttpResponse. Z tego powodu Flup odmawia współpracy i ogólnie w tej chwili trunk Django nie nadaje się do użycia przez FastCGI. Sprawdziłem to tymi rękami, na tym sajcie — nie działa. Nie jestem aż tak dobrze obeznany z internalsami Django, żebym zabierał się za zmiany w kodzie, zwłaszcza, że byłoby to grzebanie w HttpResponse... Nie da rady, trzeba czekać.

Opublikowany 2 grudnia 2007 o 22:03, oznaczony etykietami: django free software / open source programowanie python.

Trunk Django nie nadaje się do użycia!

Od rewizji 6778 trunk Django nie nadaje się do użycia przez FastCGI! Czujcie się ostrzeżeni, choć jeszcze nie wiadomo, skąd bierze się ten problem (Malcolm T. twierdzi, że SafeString nie powinno się tam pojawić...).

Opublikowany 2 grudnia 2007 o 21:02, oznaczony etykietami: django free software / open source.

Niejaki problem z Flupem

Jak wiadomo, Django używa pakietu Flup żeby uruchamiać aplikacje w środowisku serwera oferującego FastCGI (Apache + mod_fastcgi, nginx, lighttpd). Trafiłem na coś, czego jeszcze do tej pory nie widziałem na oczy. Nigdzie i nigdy.

Nasza aplikacja nigdy nie wyrzuca błędu. Nie mówię o 500, w końcu istnieją aplikacje doskonałe, ale nawet 404, i to pomimo tego, że w kodzie w wielu miejscach leci wyjątek django.http.Http404. W takiej sytuacji aplikacja wyświetla jakąś statyczną stronę (nie ma to nic wspólnego z naszym szablonem 404.html czy 500.html) i zwraca 200. Dogrzebałem się, że jest to efekt działania ErrorMiddleware z Flupa, który w ten sposób próbuje zwrócić na siebie uwagę (przy okazji wysyła maila do administratora, ale u nas to nie występuje...). Podobno występuje to wtedy, gdy błąd taki nie zostanie obsłużony przez aplikację, co w naszym przypadku jest o tyle dziwne, że podobno przecież Django obsługuje wszystkie wyrzucone wyjątki przy użyciu odpowiedniej dla typu wyjątku funkcji.

Co ciekawsze, okazało się, że najnowsza wersja Flup-a (1.0) nie zawiera już tego middleware, więc gdyby się okazało, że Django bez problemu działa z tą wersją, to może oznaczać tylko głębokie problemy z naszą konfiguracją na styku mod_fastcgi i Django.

Opublikowany 11 listopada 2007 o 14:38, oznaczony etykietami: django free software / open source praca programowanie python.

Cache obiektów w Django - jak się nie zgubić?

Zdarza się tak, że domyślny sposób buforowania, używany przez Django (buforowanie całych stron, buforowanie całego serwisu) nie wystarcza i trzeba buforować pojedyncze obiekty lub ich listy. Gdy się już zacznie, trudno jest przestać i wtedy okazuje się, że nie sposób dojść do tego, pod jakim kluczem co jest zbuforowane. Sytuacja komplikuje się dodatkowo, gdy używa się memcache, a już całkiem, gdy w buforze trzyma się dane sesji. Najłatwiej byłoby zrestartować memcached, ale przecież polecą sesje użytkowników... Zaczyna się gorączkowe szukanie klucza i strzelanie w ciemno, ale to naprawdę głupiego robota, bo klient memcache zawsze zwraca 1, gdy nie wystąpi żaden krytyczny błąd. Rozwiązaniem byłoby przejrzenie listy kluczy (np. przeiterowanie przez nie), ale czegoś takiego nie ma.

Wpadłem na pomysł prostego rejestru kluczy w postaci zbioru (set). Zdaje się to działać na tym serwisie (który jest trochę poligonem...), a jak działa w naprawdę dużym serwisie, to się dopiero okaże jutro, jak sprawdzę to w pracy. Na razie jestem dobrej myśli, bo idea zdaje się nie mieć słabych punktów... ;)

Opublikowany 4 listopada 2007 o 22:10, oznaczony etykietami: django free software / open source praca programowanie python.

Są pewne plusy

National Blog Posting Month to idiotyzm, ale dzięki temu James Bennet dzieli się z czytelnikami swoją bezcenną wiedzą na temat Django w tempie jednego postu dziennie. Warto sobie dopisać gdzie trzeba i śledzić.

Opublikowany 3 listopada 2007 o 22:05, oznaczony etykietami: django programowanie (2 komentarze).

Wartości domyślne zdają się nie być tym, czym są...

Subtelna różnica, która może okazać się zdradliwa… Gdy definiuje się wartość domyślną dla któregoś z atrybutów modelu w Django, jest ona ustawiana w momencie kompilowania modułu. Niepotrzebna para nawiasów w tym miejscu spowoduje, że zamiast wyniku wywołania jakiejś funkcji w momencie tworzenia egzeplarza klasy, wstawiona zostanie stała wartość, obliczona w momencie kompilacji modułu (czyli najczęściej przy uruchomieniu aplikacji). Warto jest się zastanowić, czy właśnie tego się chce, bo default=datetime.datetime.now daje inny wynik, niż default=datetime.datetime.now().

Opublikowany 29 października 2007 o 10:26, oznaczony etykietami: django programowanie python.

More power to the people

Będąc code junkie (jak o nas mawiają marketoidy), nie mogę się powstrzymać, żeby czegoś nie ulepszyć (co wcale nie jest zepsute). Przyszło mi do głowy, że mógłbym poćwiczyć z OpenID, więc należy się spodziewać, że wkrótce gdzieś na stronie pojawi się charakterystyczny symbol i posiadacze OpenID będą mogli się wcielić w jakąś specjalną rolę w serwisie. Jeszcze nie wiem jaką, ale będę musiał coś wymyślić, żeby wynagrodzić im wszystkie trudy… ;)

Opublikowany 22 października 2007 o 22:37, oznaczony etykietami: blog django free software / open source programowanie (2 komentarze).

Plug! Szukam współpracowników

Szukam, bo mamy w firmie znaczące niedobory kadrowe. Od razu zaznaczę—wystarczy pobieżna znajomość Django (w szczególnych przypadkach nawet żadna), podstawy Pythona, wskazane jedynie jest dość dobre obeznanie w sprawach programowania aplikacji webowych (obojętne w czym: Java, .Net, RoR, chodzi o znajomość tematu).

Szczegółowe ogłoszenie wraz z danymi kontaktowymi znajduje się w archiwum Google Groups (po kliknięciu w skrót adresu trzeba wpisać kod z captchy, żeby obejrzeć pełny email kontaktowy). Ogłoszenie jest sprzed miesiąca, ale tym się przejmować nie należy. ;)

Opublikowany 10 października 2007 o 10:21, oznaczony etykietami: django praca.

4 powody, dla których warto przejść na Django-SVN

W chwili, gdy piszę ten tekst, stabilną wersją Django jest wersja oznaczona numerem 0.96, opublikowana w czerwcu 2007 roku. Biorąc pod uwagę, że jest to spory kawał kodu, trudno nazwać tę wersję starą, a poza tym, działa dość stabilnie (pomijając pewną ilość błędów, poprawionych w ciągu tych kilku miesięcy). Pokusa pozostania przy niej jest silna, szczególnie w przypadku aplikacji o charakterze komercyjnym, które nie powinny podlegać ciągłej pogoni za zmianami, wprowadzanymi w SVN. Jest jednak kilka powodów, dla których warto jest rozważyć przejście na wersję rozwojową.

  1. unikod—do tej pory było tak, że część Django była unikodowa (np. ramówka do RSS-ów), a część zwykła. Teraz takich rozjazdów jest znacznie mniej i są one znacznie mniej uciążliwe (zauważyłem np., że klucze i wartości w cookies muszą być zwykłymi stringami, a nie unikodem);
  2. poprawiona stabilność—od kilku tygodni nie zauważyłem ani razu słynnego błędu “Can not resolve keyword XXX into field”, który był plagą w Django 0.96;
  3. dekorator permalink—coś cudownego, odpina całkowicie model od stałego URL-a (przypina go za to do widoku, ale to już chyba lepsze…);
  4. działające poprawnie newforms—wreszcie.

I tu się należy słówko wyjaśnienia dla wszystkich tych, którzy wynajdują słabe strony wszystkiego (nazywa się ich malkontentami, to tak na marginesie). Najprawdopodobniej Django posiada jeszcze wiele niedociągnięć i wiele niewykrytych błędów. Prawdopodobnie należy się spodziewać, że wersja rozwojowa zaskoczy nas jeszcze nie raz (i nie raz nie będzie się nadawała do użytku przez jakiś czas). Komu nie odpowiada wersja rozwojowa, ma przez cały czas alternatywę (a nawet kilka): używać wersji 0.96 lub nie używać Django w ogóle. Jest przecież wiele równie fajnych ramówek aplikacyjnych, nie tylko w Pythonie…

Opublikowany 9 października 2007 o 12:25, oznaczony etykietami: django.

Mam archiwum XYZ

Zrobiłem dziś archiwum według miesięcy, przy czym trochę bardziej z ciekawości niż z rzeczywistej potrzeby użyłem pakietu Babel (chciałem mieć ładne nazwy miesięcy itd). Przy okazji znalazłem babola w ostatnim wydaniu, tymczasowo poprawiłem ręcznie żeby w ogóle działało. Poczułem się trochę zawiedziony, że tak zachwalany mi przez kolegów pakiet (i w wersji 0.9.1, a taki numerek powinien już zobowiązywać) nie ma testów, które potrafiłyby wykryć taki problem. Ale co ja psioczę, moje projekty w ogóle nie mają testów… ;)

A na razie cieszę się tym nowym, wspaniałym archiwum i już spoglądam w przyszłość, co następne w kolejce do zrobienia.

Opublikowany 29 września 2007 o 22:02, oznaczony etykietami: blog django free software / open source.

Django-SVN na megiteam.pl

megiteam.pl standardowo udostępnia Django-0.96 jako ramówkę bazową, ale przecież można instalować własne pakiety Pythonowe, a Django nie jest niczym o wiele większym (niektórzy pewnie będą polemizować, ale co mi tam...), więc da się oczywiście użyć nowszej wersji, ze wszystkimi dobrodziejstwami (np. dekorator permalink, unikod, wreszcie działające newforms...). Instrukcja jest dość prosta, a ja nie czuję się natchnionym poetą, więc krótko i rzeczowo.

  • ściągnij wersję z SVN postępując według wskazówek na stronie Django;
  • zainstaluj w normalny (dla megiteam) sposób, podając parametr --prefix=$HOME/.python (czyli pełna komenda będzie wyglądać mniej-więcej tak: python setup.py build && python setup.py install --prefix=$HOME/.python);
  • dodaj do zmiennej PATH katalogi $HOME/.python/bin i $HOME/.python/lib/python2.4/site-packages/django/bin, wpisz to w pliku .environment (najlepiej na początku);
  • ciesz się Django-0.97-pre-SVN-unknown, nie zapomnij też zrestartować swoich procesów FastCGI.

Skoro nie widać różnicy, to po co przepłacać (za starą ramówkę)?

Errata (2007-10-13): dekorator permalink występuje już w Django-0.96.

Opublikowany 13 października 2007 o 21:17, oznaczony etykietami: django hosting megiteam (3 komentarze).

Słówkiem wyjaśnienia

Zaczęło się ponownie od tego, że wreszcie z początkiem 2007 roku znalazłem pracę, w której piszę w Pythonie (właściwie to w Django). Nie byłem do tej pory wielkim miłośnikiem programowania internetowego, ale Django mnie przekonało na tyle, że zachciało mi się zrobić coś własnego. Na pierwszy ogień, jak zwykle, poszedł silnik blogowy…

Gdy tylko okazało się, że za skromne pieniądze mogę mieć hostowaną aplikację Django na serwerze firmy megiteam.pl, to długo się nie zastanawiałem. Wykupiłem sobie konto na rok i… voila! Jest. Zaczyna się oczywiście od bloga, ale przecież nie musi się na tym skończyć. Serwer jest, czas może się znajdzie, aplikacja (czy nawet aplikacje) mają szanse dojrzeć.

Opublikowany 23 września 2007 o 12:10, oznaczony etykietami: blog django.