Gdybym mógł wybierać...

Jest kilka firm, w których chciałbym pracować. Na poniżej liście nie ma mojego obecnego pracodawcy, bynajmniej nie dlatego, że nie chcę już pracować w Sensisofcie, ale dlatego, po pierwsze jest to lista marzeń, a nie planów, a po drugie, gdybym tam nie chciał pracować, to już bym nie pracował.

  1. Google. To oczywiste. Każdy programista czy projektant chciałby pracować w Google, a ja nie jestem w tej dziedzinie wyjątkiem. Ta firma robi rzeczy wielkie, coś na miarę projektu Manhattan, ale w skali oprogramowania. Chciałbym (chociaż przez pewien czas) być jednym z nich.
  2. Xerox. Dziwnym może się wydać umieszczenie firmy Xerox już na drugim miejscu, bo dla większości ludzi oblatanych w IT kojarzy się ona z kopiarkami, potwornie drogimi drukarkami, a dla niektórych także z niezwykle innowacyjną historią Palo Alto Research Center (Xerox PARC). Jest jednak coś innowacyjnego w tej firmie także i dziś, ale niewiele osób o tym wie, bo jej najbardziej innowacyjne produkty mają wąskie grono odbiorców, jak np. VIPP. Poznałem VIPP dość dobrze i doceniłem jego klasę.
  3. Canonical. Robienie na linuksie jest dla mnie teraz tak oczywiste, że trudno mi sobie wyobrazić, że mógłbym w pracy używać innego systemu operacyjnego, a w dzisiejszych czasach coraz częściej jest tak, że mówisz linux, myślisz Ubuntu.
  4. IBM, Sun i Microsoft, ex aequo. Każda z tych firm robi ciekawe rzeczy, choć te, które mnie naprawdę interesują, stanowią margines ich działalności. Gdyby udało mi się popracować przy tych ciekawych rzeczach, to czemu nie?

Jak widać, nie ma tego szczególnie wiele. Jedyną nieoczywistą pozycją w tym zestawieniu wydaje się być Xerox, więc może jednak zostanę w Sensisofcie... ;)

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.

Nowe na megiteam.pl

megiteam.pl (gdzie hostowany jest ten skromny serwis) wprowadziło w ramach nowości rozliczanie za używaną pamięć, zamiast rozliczania za procesy. Lepiej? Gorzej? Nie wiem, jak dla mnie to chyba drożej, bo drugą aplikację uruchomić będzie mi trudno (w sumie zostało mi ze 20MB pamięci, więc nawet na małego memkesza mi nie wystarczy), musiałbym sobie dodać jeszcze ze 20MB pamięci, a te aplikacje, które teraz powstają mają trochę większe oczekiwania, więc raczej pozastanawiam się jeszcze trochę nad dedykiem w hetzner.de.

Swoją drogą, ciekawe jest orientacyjne zestawienie, ile która ramówka potrzebuje dla aplikacji...

Poważny projekt, poważne koszta

A tak całkiem na poważnie, to nie wiem, czy te koszta są tak poważne.

Ten projekt to webshop (a jakże), z dość egzotycznym rodzajem muzyki. Nie obliczam go na jakiś ogromny ruch typu miliony wejść dziennie, ale z 10 000 przydałoby się obsłużyć. Oprogramowanie napiszę sobie sam (koszt: 0), pozostaje to, czego sam nie zrobię, czyli maszyna (najcieńszy Root Server na hetzner.de to około 2500 złotówek rocznie), storage (S3, z pewnym okładem to 250 złotówek miesięcznie) i opłaty dla firmy rozliczającej płatności. Razem daje to około 5500 złotówek samego kosztu utrzymania, kosztów administracyjnych jeszcze nie udało mi się policzyć.

Dużo? Czy nie dużo? Trudno mi powiedzieć, chociaż tak na oko nie wydaje się to jakimś ogromnym wydatkiem.

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

Jak umierają idee (w Polsce)

Idee w Polsce umierają po cichu.

Jesienią ubiegłego roku zaczęliśmy robić prelekcje o Pythonie w ramach WarPy. Odbyło się 3 spotkania, po czym współorganizator ze strony WO@PW i WarLug-a poprosił o przerwę z powodu sesji. Gdy sesja się skończyła, organizatorom i potencjalnym prelegentom z kolei zaczął się gorący okres w pracy.

WarPy ma swoją listę mailową, w żadnym przypadku nie jest organizacją zamkniętą, która w tajnych głosowaniach ustala kto i o czym ma opowiadać. Ja nie mam ostatnio czasu zadać pytania, czy są w ogóle jacyś chętni, a chętni sami się nie zgłaszają. W ten sposób po cichu i bez rozgłosu kończy się kolejna idea.

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

Ghosts I-IV

Jeszcze tylko 15 minut i będzie moja, całkiem legalna ($5 to naprawdę drobne pieniądze za płytę NIN).

Nie mogę się już doczekać.

Hi, all, I'm official

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