Zaczęło mnie trochę denerwować, że nowo uruchomiony, pusty Firefoks wygląda (na moim Ubuntu AMD64) następująco:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND     
26990 marcink   20   0  593m 206m  26m S    3 23.6   0:23.89 firefox

Hmm. Opisuję jak na dwustu megabajtach budować całkiem rozbudowane serwisy, a na desktopie tyle pożera durna przeglądarka - zanim jeszcze zaczęła cokolwiek robić..

Stosując na doczepkę zasadę lekarzu lecz sam siebie do poprzedniego artykułu, przeszedłem się przez poinstalowane rozszerzenia - wyłączając je po kolei i obserwując konsekwencje.

Jest Better Gmail, jest Better Google Reader... Ja obracałem chwilę w myślach pomysł zrobienia rozszerzenia Firefoksa poprawiającego jeden z polskich wirtualnych banków. Pomysł zarzuciłem, po części z braku czasu, a przede wszystkim spodziewając się u wszystkich sporego oporu przed instalowaniem takiego narzędzia.

To za duże ryzyko!

Tak, to prawda. To byłoby ryzyko. Dodatek miałby manipulować stronami o prawdziwych pieniądzach? A co, jeśli kradłby informacje, numery kont albo hasła. Albo manipulował danymi przelewów?

Takie samo ryzyko ponosisz instalując SmTuning. Albo wspominane Better Gmail.

Mamy pewną listę. Mamy jakąś funkcję testującą. Chcemy sprawdzić, czy dla jakiegokolwiek elementu listy funkcja testująca zwraca True.

To proste zadanko - bardzo częste w realnym kodzie - można wykonać na wiele sposobów.

Dwa uzupełnienia do artykułu o trwałej sesji VNC na serwerze:

• proponuję kolejny lekki desktop, fajnie sprawdzający się w roli menedżera sesji działającej wewnątrz VNC,

• opisuję, jak uniknąć startowania w ramach takiej sesji programów uruchamianych przez Gnome/KDE, a także zapewnić osobne miejsce zapisywania się konfiguracji desktopu.

Startujące GNOME, KDE czy XFCE uruchamia chmarę pomocniczych programików. Od apletu automatycznego update albo monitora urządzeń sieciowych, po wyszukiwarkę plików. Można tym oczywiście zarządzać klikając (pod GNOME - System/Preferences/Session albo System/Preferencje/Sesje, zależnie od wersji językowej) ale warto wiedzieć, skąd się biorą.

Różnego rodzaju kalendarzy, list zadań czy przypominaczek jest po prostu chmara. Powód jest prosty - napisać taki program łatwo, a temat jest modny. Listę co ciekawszych linków poniżej podaję ale najpierw zastanówmy się, co jest w takiej usłudze ważne.

Wpis publikuję zmotywowany dyskusją o sieciowych to-do-listach, która zaczęła się pod artykulikiem o prezentacji zadań w mindmapie.

Dopisek do artykułu o konfiguracji replikacji baz PostgreSQL przy pomocy Slony-I: co się dzieje przy upgrade.

W kontekście replikacji znaczenie mają wersje następujących elementów:

• programu slon
• zapisanych w bazie danych triggerów i procedur składowanych Slony-I,
• binarnej biblioteki pomocniczej należącej do Slony-I (używanej przez powyższe i dolinkowywanej dynamicznie do bazy danych),
• samej bazy danych (tj. PostgreSQL).

Aby Slony-I działało, między każdymi z nich musi być zgodność wersji, tj.:

• program slon musi mieć tą samą (dokładnie!) wersję co triggery we wszystkich bazach, z którymi się komunikuje - także zdalnych,
• biblioteka pomocnicza musi być binarnie zgodna z triggerami
• biblioteka pomocnicza musi być binarnie zgodna z bazą danych (tj. skompilowana z jej nagłówkami i bibliotekami).

Same bazy mogą mieć różne wersje (na różnych węzłach) ale pod warunkiem przykrycia taką samą wersją Slony-I (tj. możemy mieć PostgreSQL 8.1 na maszynie A i PostgreSQL 8.3 na maszynie B, ale musimy mieć na obu bibliotekę pomocniczą, program slon i kod SQL w bazie z - powiedzmy - Slony-I 1.2.13).

Jak to wygląda przy normalnym, pakietowym systemie dystrybucji?

Często się spotyka opinie, że programy blogowe są proste i prymitywne, w parę dni można samemu taki machnąć (zwłaszcza w Django, Ruby on Rails czy którymś z nowych frameworków PHP - zależnie od mówiącego).

Trochę mnie to kusiło ale ... wypisałem sobie, co robi dla mnie mój skrypt blogowy. Przy okazji jest to ilustracja, jak w praktyce działa osadzanie na stronie map xminda.

Normalną metodą ładowania kodu pythonowego jest polecenie import i umieszczanie plików w standardowym drzewie modułów zarządzanym zmienną PYTHONPATH. To załatwia 99.9% przypadków.

W tym artykule o pozostałym 0.1% - kilka dziwnych ale czasem użytecznych technik ładowania kodu, od wczytywania pojedynczego pliku z nietypowego katalogu, po pisanie własnych ładowaczy modułów mogących generować kod, ściągać go ze zdalnej maszyny czy pobierać z bazy danych.

Próbuję się ostatnio wdrożyć w GTD (Getting Things Done), czyli modną od paru lat technikę zapisywania i porządkowania rzeczy do zrobienia. Sam pomysł by zapisywać sprawy i pomysły to nihil novi (czego ja już nie używałem - od issue trackera i różnych sieciowych kalendarzy po zbiory papierowych notatek) ale GTD przez swe rytuały i techniki daje pewną nadzieję na większą skuteczność (już mogę powiedzieć, że fajnie pozwala ograniczyć ilość naraz wiszących nad głową spraw).

Przesiadam się między kilkoma komputerami, więc narzuciło się użycie jakiejś aplikacji sieciowej. Pobawiłem się bodaj sześcioma i na razie wybrałem Nozbe - głównie dlatego, że zawiera to co trzeba a nie trzy razy za dużo (to w takiej aplikacji jest ważne), po części zaś w formie uznania dla rodaka (Michała Śliwińskiego), który ten serwis zrobił i promuje (bardzo ładnie i mądrze promuje, jego filmiki prezentujące GTD są zwarte i punktują kluczowe sprawy).

No ale w tym poście nie chcę pisać o GTD, Nozbe i jego konkurentach ani o alternatywnych metodach notowania zadań ale o narzędziu, które sobie przez dwa poprzednie wieczory napisałem.