Ostatnio…

Ostatnio odkryłem, że bardzo mało czasu spędzam na wymyślaniu, testowaniu i temu podobnych zajęciach… Mój czas i chęci zajęła praca… Czas z tym skończyć - to znaczy pracować nadal muszę jednak trzeba zająć się swoją twórczą naturą. Czas wrócić do programowania dla przyjemności, a nie pieniędzy… Pieniądze przecież nie są najważniejsze (chociaż do ślubu by się jednak przydały;).

Niedługo postaram się założyć blog’a. Stworzyć nowego siebie, na nowym blogu. Gdyby ktoś był zainteresowany linkiem (choć szczerze wątpię bo nic ciekawego tutaj nie napisałem;) to śmiało pisać.

Local Area Wiki

Wiki

Kiedyś zastanawiałem się nad używaniem wiki do zarządzania swoimi dokumentami. Na ogół byłoby to dobre rozwiązanie jednak zbyt mało wygodne. Ciągle odpalony serwer www i baza danych to zbyt duże wymagania jak dla mnie. Do tego potrzeba pisania skryptu, który przekonwertowałby bierzący zestaw dokumentów.

Coś jednak pociągało mnie w wiki - możliwość przeglądania poprzednich wersji dokumentu, bo przecież nie wyszukiwanie obecne w każdym systemie operacyjnym ;)

CVS czyli system zarządzania wersjami

Dokładnie cvs’u mi było trzeba, ale… Znów kłania się wygoda… Przecież nie będę co jakiś czas wpisywać z konsoli magicznego ciągu “cvs…”. Powiem więcej - często bym o tym zapominał pozbawiając się możliwości powrócenia do starej wersji dokumentu.

A jednak CVS czyli dnotify

Dnotify to program, który uruchamia wybrany przez nas skrypt/program za każdym razem gdy zawartość odpowiedniego katalogu się zmieni (jest to dosyć ogólny opis - dokładniejsze informacje można znaleźć na stronie projektu;). Jako, że mówimy o dokumentach tekstowych to nawet zapisywanie co 5minut nie powinno stanowić, żadnego problemu w kwestii powierzchni dyskowej.

Tagi

Ludzie bardzo lubią tagowanie. Pozwala przypisywać dane/pliki/linki/zdjęcia/etc. do różnych kategorii. Pozwala je łatwiej odnajdywać. W przypadku linux’a możemy sobie robić linki z różnych katalogów do jednego pliku, ale to niezbyt wygodne rozwiązanie - już sobie wyobraziłem tworzenie 20 symlinków do każdego nowo utworzonego pliku… W przypadku rozwiązania z dnotify’iem w roli głównej możemy przyjąć, że w pierwszej linijce po frazie “tag: ” umieszczamy tagi, do których przypisujemy plik, a resztę (indexy, symlinki czy co tam ktoś sobie jeszcze wymyśli) robi automat. Brak uzupełniania nazw tagów w edytorze to osobny problem, który w przypadku emacs’a możemy rozwiązać bez większych problemów.

Inne pomysły związane z dnotify’iem

Podobnie można publikować wpisy na blogu - po prostu zapisując dokumenty tekstowe w odpowiednim katalogu (i odpowiednią pierwszą linijką by zapobiec przedwczesnemu opublikowaniu;). Z chętnymi podzielę się skryptem w pythonie publikującym na wordpress’a - faza beta i jeszcze nie obsługuje tagów, ale jeśli się do niego przekonam do publikowania poprzez zapisywanie na dysku to napewno zacznie się rozwijać…

Niedawno bawiłem się Flickr’em jednak limit 30MB miesięcznie wystarczająco mnie powstrzymał. Przemyślałem sprawę i skorzystałem z imageshackus. Napisałem skrypt zamieszczający zdjęcie w tym serwisie, pobierający jego adres i publikujący na specjalnie założonym w tym celu koncie @ jogger.pl. Póki co skrypt odpalam ręcznie, ale docelowo ma to także robić dnotify.

Zarządzanie informacją - zmora czy wygoda?

Historia przyszłości nas wszystkich przyprawia o ból głowy. Natłok informacji sprawia, że gubimy się w niej. Chyba nie ma już nikogo kto by uważał internet za zbiór poukładanych niczym w bibliotece informacji. Problem tkwi w tym, że powoli odkrywamy ten sam bałagan na swoich dyskach i zdalnych kontach. Zróżnicowanie serwisów utrzymujących nasze bookmarki, przypomnienia, maile i inne nie pomaga. Do tego setki plików mp3 (lub ogg jak u mnie;), historii im, zdjęć, dokumentów służbowych i prywatnych. Gdy jeszcze dołożymy niepoukładane (lub częściowo poukładane w cvs’ie/svn’ie) źródła własnych programów i wiele wiele innych rzeczy, o których niewiem lub niechcę pisać to przed oczami staje wizja poszukiwania zaginionego bitu.

Biorąc przykład z dobrych pisarzy powinienem teraz podać wspaniałe rozwiązanie. Niestety ja nie jestem dobrym pisarzem, a na dodatek nie ma złotego środka… W informatyce dobre rozwiązanie to takie, które dostosowano do zadanych warunków. Jeśli zmienimy chociaż jeden parametr soft/hardwareowego równania wynik może się zmienić. To co jest dobre dla mnie nie musi być dobre dla Ciebi i to nie jest kwestia gustu tylko innych potrzeb.

Gdybym ograniczył swoje zapotrzebowanie do śledzenia newsów, czytania mail’i i wyszukiwania informacji w mailach i newsach to odpowiedzią byłoby pewnie trio: gmail, rssfwd i google reader. Google reader na codzień służy do czytania newsów. Niestety nie posiada opcji wyszukiwania tylko w newsach śledzonych przez danego użytkownika. Jego opcja wyszukiwania służy raczej do odnajdywania nowych, ciekawych feedów. W gmailu składujemy i (niezawsze, ale czasem) przeszukujemy zgromadzone maile. Dzięki rssfwd newsy lądują na koncie pocztowym, mijają inbox dzięki specjalnemu filtrowi i lądują z etykietką rss. Teraz wyszukiwanie w poczty wzbogaciliśmy o wyszukiwanie newsów.

Nie używam gmail+rssfwd jako czytnika newsów bo byłbym powiadamiany o (niekiedy) mało istotnych rzeczach. Mail ma dla mnie o wiele wyższy priorytet.

Aby osiągnąć dobre zarządzanie wszystkimi wymienionymi i niewymienionymi danymi potrzebujemy możliwości wyszukiwania i tagowania tych danych z swoistego centrum zarządzania. Niewyobrażalną jest sytuacja, w której musimy się przełączać między różnymi serwisami/programami w poszukiwaniu konkretnej informacji… Nie musimy trzymać wszystkich danych w jednym miejcsc (własnym serwerze?) ale musimy je zarządzać z jednego miejsca. Poczta i newsy z powodzeniem mogą leżeć na gmailu (przy odrobinie chęci także historia im’a - tylko po co?), zakładki na del.icio.us, a przypomnienia w rememberthemilk, ale nasze centrum zarządzania musi mieć dostęp i mechnizmy wyszukiwania do wszystkich tych miejsc.

W następnym numerze zarządzania informacją mój pomysł na zarządzanie zdjęciami… Planuję wcielić go w życie przy pomocy stworzonego w wolnym czasie programu, ale to dopiero przyszłość ;)

Wrr… Brak mi chęci do czytania własnego (bałaganiastego) tekstu więc… lepiej opublikuję bo inaczej trafi do szuflady i zapomnę o nim…

Nowoczesny RSS

E-mail. Jak na czasy, w których powstał był bardzo rewolucyjnym i doskonałym narzędziem. Nikt wtedy nie przejmował się różnymi aspektami protokołów do jego obsługi (pop i smtp). Najbardziej kulało (i kuleje) bezpieczeństwo. Lecz gdyby nie on dzisiejszy świat byłby zupełnie inny, uboższy. Pomimo swoich wad wniósł wiele dobrego.

Wydaje mi się, że coś podobnego obserwujemy w odniesieniu do rss’a. Z racji na moje niewielkie doświadczenie w sprawach sieciowych proszę moje rozważania brać z przymróżeniem oka, weryfikować to co piszę i zgłaszać ewentualne nieścisłości.

Rss to bardzo prosta technologia. Bardzo łatwo nauczyć się jego składni (piszemy oczywiście w XMLu;), a co za tym idzie łatwo napisać programy obsługujące rss. Zarówno te, które mają go czytać jak i te, które mają go generować.

Ja dopatruję się błędu o wiele głębiej niż w samym formacie tego pliku. Jak zwykle zaglądam do korzeni. Rss miał na celu ułatwienie nam dotarcia do jakiś informacji (jest prostszy niż typowa strona internetowa i musi zawierać pewne standardowe elementy). W tym znaczeniu sprawdził się znakomicie. Z założenia mieliśmy pewnie sprawdzać wszystkie źródła (feedy) po włączeniu komputera lub raz/kilka razy dziennie (tak jak to czyniliśmy w przypadku ręcznego przeglądania witryn). Niestety, społeczeństwo żądne informacji do ustawień swoich czytników wpisało sprawdzanie co minutę. Tym sposobem obciążenie serwerów (zapewne;) bardzo wzrosło. Niby taki rss to niewielki plik, sam tekst, ale jeśli mamy tysiąc użytkowników i każdy z nich co minutę każe nam go wysyłać to serwer nie ma nawet chwili wytchnienia ;)

Przypomina mi to sytucję pani na recepcji, do której 10 różnych osób co chwilę dzwoni z tym samym pytaniem: Czy jest już przesyłka xxx? Na miejscu takiej Pani wziąłbym numery telefonów do tych dziesięciu osób i zadzwonił do nich gdy przyjdą ich przesyłki. Zarówno ja nie siedziałbym ciągle na linii tylko spokojnie jadł drugie śniadanie jak i interesanci byliby zadowoleni z miłej i szybkiej obsługi. Czemu nie przenieść tego modelu do sieci?

No może nie dosłownie bo wtedy każdy klient musiałby mieć swój numer telefonu czyli jakiś otwarty port.
Mój model jest mniej więcej taki:
Klient łączy się z serwerem i mówi jakie informacje chce (od jakiej daty). Następnie serwer przesyła rządane informacje (ni mniej ni więcej niż interesuje klienta). Od tej pory klient już nic nie wysyła tylko słucha. Gdy na serwerze pojawią się nowe wiadomości klient otrzyma je poprzez ciągle otwarte połączenie tcp/ip. O ile mi dobrze wiadomo to zbyt dużo/żadne dane nie są wysyłane gdy mamy otwarte połączenie, ale nikt nic nie wysyła.
Obciążenie serwera/łącza redukujemy do wysyłanie jedynie istotnych danych zwiększając jedynie ilość utrzymywanych jednocześnie połączeń. Rozwiązanie to ma swoją wadę bo pojedyńczy serwer może utrzymywać ograniczoną ilość otwartych połączeń, ale jak widać na przykładzie serwerów jabbera nie jest to mała liczba ;)

Tylko netstat musiałby się bardziej narobić ;)

Re: W3C nie gryzie: Ukrywanie spoilerów

To jest komentarz do: http://riddle.jogger.pl/comment.php?eid=168033

Riddle zablokował (bo w teorii można je nadal dodawać i nawet chyba się wyświetlą - o ile w formularzu nie było jakiegoś magicznego pola, o którym zapomniałem;) możliwość komentowania jego wpisów… Wygodne to może dla niego i choć miał swoje powody nie pochwalam.

Wracając do tematu: metody wykonania komentował nie będę. Jest napewno wspaniała, a co najmniej dobra, ale ja nie mam w tej chwili czasu i chęci na zaczytywanie się…

Mam niewielki problem ze zrozumieniem ideologii takiego postępowania. Czemu zleceniodawca nie chciał javascriptu? Ktoś przecież może wyłączyć js i niechybnie przeczyta spoiler - odpowie obrońca. Oczywiście przytaknę i dodam, że interpretowanie css’a trudniej wyłączyć (choć ludzie nagminnie korzystający z bardziej rozbudowanych zakładek/skryptów greasemonkey’a do poprawiania koloru tła na biały, a tekstu na czarny, odkrywających wszystkie ukryte pola itp. mogą się niemiło zaskoczyć). Przychodzi niestety pora na próbę przeglądarek tekstowych, starszych (nieobsługujących css’a) i dla niewidomych (Ci może filmy nie najczęściej oglądają, ale spoiler może chyba dotyczyć czegokolwiek;).

Na ogół nie staram się wciskać najnowszych technologii gdzie tylko się da tylko starannie wyważać gdzie mogą się przydać, ale to chyba pora na skorzystanie z jakiegoś XmlHttpRequest lub znajomiej brzmiącego Ajax’a. Chciałbym zrobić link (”Pokaż spoiler” lub jak Riddle zaproponował obrazek, pomysłów jest wiele) działający na bardzo podobnej zasadzie jak to wygląda na pokazówce u Rid’a. Różnica tkwi w szczegółach. U Riddla gdy wejdziemy na stronę lynx’em zorientujemy się, że czytamy spoiler gdy już będzie za późno. U mnie natomiast go nigdy nie przeczytamy (no może prawie nigdy;). Teraz wystarczy odpowiednio spreparować tego linka tak aby dla przeglądarek nieobsługujących ajax’a wyświetlił tą samą stronę, ale ze spoilerem(ami). W zasadzie można korzystać tylko z tej drugiej części rozwiązania skoro i tak serwer ma generować dwie stronki, ale większość użytkowników (a conajmniej zadowalająca ilość - po części za sprawą google) posiada nowsze przeglądarki, które poradzą sobie z tym lepszym rozwiązaniem. Lepszym bo szybszym (z punktu widzenia użytkownika) i oszczędniejszym (z punktu widzenia serwera).