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.