Chciałem podłączyć moją usługę (webservice zrobione na podstawie twisted.web) do serwera Zeroconf i okazało się, że to całkowicie niemożliwe w obecnej sytuacji. Jedyna dobra biblioteka do tego, czyli avahi, jest tak mocno zintegrowana z DBus, że wymaga... głównej pętli programu zrobionej na GObject, żeby móc działać asynchronicznie. Porażka. Znalazłem wstęp do implementacji usług związanych z mDNS przy użyciu Twisted, ale oczywiście niepełną.
Chyba trzeba będzie sobie wreszcie ubrudzić ręce trochę poważniejszym kodem...
Kiedyś było to dla mnie dość normalne... Czyżby dopadała mnie nostalgia za kawalerskimi czasami? ;)
Wygląd tego wpisu przekonuje mnie, że czym prędzej muszę się rozejrzeć za jeszcze szerszym szablonem, bo mi sie stripy z XKCD nie mieszczą...
Podsumowania czas zacząć. Na początek: muzyka.
Jak dla mnie ten rok będzie związany z trzema wielkimi albumami — wielkimi jeżeli chodzi o coldvawe i industrial rock. W 2007 roku Nine Inch Nails wydało album Year Zero, 16Volt FullBlackHabit, a Acumen Nation Psycho the Rapist. Trudno jest mi w tej chwili wybrać ten, który podoba mi się najbardziej, ale skłaniam się do wyboru między FBH i PTR.
W dziedzinie muzyki, która mnie kręci to był dobry rok. A może nawet bardzo dobry.
Pół dnia spędziłem na szukaniu błędu, który ukrył się w poniższym fragmencie kodu:
try:
contactsIndex = self.names.index('Contact')
contacts = items[contactsIndex]
mail = email_re.findall(contacts)[0]
if mail:
logger_main.debug('Email %s found within ad data' % mail)
report_counters['ads_with_emails'] = report_counters['ads_with_emails'] + 1
except:
mail = False
Wszystko wydawało się w porządku, ale nie było. Klauzula except bez wyspecyfikowania wyjątku zachowuje się tak, że wyłapuje wszystko. Dopiero zapisanie jej w postaci except Exception, e: i zalogowanie wyjątku pokazało, gdzie tak naprawdę ten błąd był. Zupełnie nie tam, gdzie się spodziewałem — klucz słownika report_counters wcale nie nazywał się 'ads_with_emails' (mniejsza o to, jak się nazywał).
Po prostu się nie spodziewałem. Perfidia.
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...
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...
Dziś na PW kolejny wykład w ramach WARPY. Z powodów osobistych się nie wybiorę, niestety.
Następny wykład będzie 10 stycznia 2008, o ile nie zajdą jakieś nieprzewidziane okoliczności. I będę się starał wygłosić prelekcję o PyGTK.
Porównując do jednostek pływających, moja poprzednia praca przypominała supertankowiec — wszystko tam szło powoli i majestatycznie, trudno było zmienić kierunek, a każde niepowodzenie było katastrofą, po której ofiary liczono w setkach (jednostek umownych), a jednocześnie statek był w stanie przyjąć ogromną ilość uszkodzeń, zanim miał pójść na dno.
Teraz pracuję w firmie, którą można porównać do motorówki. W porównaniu do innych jednostek pływających zakręca praktycznie w miejscu, porusza się z relatywnie ogromną prędkością, najdrobniejsze uszkodzenie kadłuba spowoduje zatonięcie, a i tak nikt tego nie zauważy.
Jak widać z porównania, trudno wybrać, co lepsze...
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!
Moja córka Zofia (niegdyś znana jako ZIZ, obecnie lat około 3,5) nauczyła się pisać. Umie już napisać MAMA, TATA, LATO i LALA. Przymierza się już do pisania książek.
Kiedyś o tym ktoś już napisał (może Joel Spolsky, a może ktoś inny, nie mogę sobie przypomnieć). A teraz dotknęło to mnie osobiście.
Są rzeczy proste i są rzeczy skomplikowane. Naturą rzeczy prostych jest to, że łatwo jest ich używać (my to nazywamy, że mają prosty interfejs). Są jednak także rzeczy, które są skomplikowane same z siebie. A jak jest z ich używaniem?
Podobnie jak z rzeczami prostymi, rzeczy skomplikowane są... skomplikowane w użyciu. Rzeczy skomplikowane mają skomplikowany interfejs właśnie dlatego, że ze swej natury są skomplikowane i ich funkcji nie da się wyrazić w sposób uproszczony. Można to porównać do dwóch narzędzi, które służą do wyciągania gwoździ: obcęgów i tzw. łapki. Obcęgi są dość skomplikowanym narzędziem, które spełnia kilka funkcji (na kilka sposobów), więc jego interfejs jest nieco bardziej skomplikowany, niż łapki. Oczekiwanie, że obcęgi będą miały prostszy interfejs, doprowadzi do degeneracji obcęgów do poziomu łapki. Podobnie, nikomu nie wpadnie do głowy, by żądać od 50-tonowej lokomotywy, by miała interfejs Hondy Civic.
A teraz zdążam na skróty ku poincie. Dużo ludzi uważa, że zadaniem nas, czyli developerów, jest zapewnianie prostego interfejsu. Abstrahując od tego, że jest to piramidalną bzdurą, jest to także niemożliwe. Rzeczy skomplikowane nie mogą mieć prostego interfejsu, dopóki są skomplikowane. I nie będą miały prostszego interfejsu, dopóki będą realizować skomplikowane funkcje w skomplikowany sposób. A takie działanie jest chyba immanentne dla aplikacji webowych...
Jeszcze się nie zdecydowałem, ale moim następnym nabytkiem w dziedzinie aparatów fotograficznych będzie produkt firmy Canon: albo G9, albo S5 IS. Jeszcze się tylko muszę z żoną skonsultować, czy dobry kompakt, czy może superzoom...
Dzień w plecy z powodu kreatywności firmy Dell. Moja maszynka w pracy to niestety Dell Optiplex 320 — tak, niestety, właśnie ten szajs. Zainstalowanie na niej jakiegokolwiek linuksa graniczy z cudem, a Ubuntu 7.10 zainstalować się na nim nie da wcale z powodu buga w jądrze 2.6.22 (7.04 się udało, pomimo gimnastyki z grub2). Wydaje się, że przyczyną większości problemów jest kontroler SATA firmy (a jakże!) ATi, ale regresja względem poprzedniego wydania to nie jest coś, czego bym się spodziewał...
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ć.
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ć...).