Pomiędzy bitami

Na wstępie wyjaśnienie, skąd ten wpis. Na forum Blox co jakiś czas pojawiają się osoby, które straciły dorobek paru lat życia. Znaczy takie, których blog - z różnych przyczyn - przestał być dostępny. I zniknęły cenne wpisy (pół biedy, bo to ludzie czasem mają zapisane lokalnie) oraz jeszcze cenniejsze komentarze. Widziałem narzekania na administrację Blox, gorzkie żale, próby wyciągania treści z cache Google itp. hardcore, na dodatek nie zawsze skuteczny. Wszystko niepotrzebnie, bo ww. opisanym tragediom^[1] można w prosty sposób zapobiec. Oczywiście problem nie dotyczy tylko Blox, tak samo może zdarzyć się na innych platformach.

Trzeba uświadomić sobie dwie rzeczy. Po pierwsze, blog, a dokładnie jego zawartość jest treścią tworzoną samodzielnie, przez długi okres czasu, trudno odtwarzalną. Szczególnie, jeśli uwzględnimy komentarze. Po drugie, żaden serwis, a już na pewno nie darmowy, nie daje specjalnych gwarancji na to, że dane nie znikną. Jasne, zwykle nie znikają. Co więcej, jeśli nawet znikną, to zwykle administracja serwisu ma backup, który może przywrócić. Jednak awarie i błędy ludzkie (samodzielne skasowanie notki lub bloga) się zdarzały, zdarzają i będą zdarzać.

Przed takimi sytuacjami można w prosty sposób się zabezpieczyć robiąc samemu bakcup swojego bloga. Szansa, że nastąpi awaria krytyczna awaria w dwóch różnych miejscach, jest pomijalna. Tak naprawdę samo jednorazowe skopiowanie to jedno polecenie, jeśli chcemy zautomatyzować, warto skorzystać z prostego skryptu. Wybrałem wariant najprostszy, z użyciem programu [i]wget[/i], dostępnego w każdej dystrybucji Linuksa^[2], który powinien działać na każdej platformie blogowej (udostępniającej wszystkie wpisy bez logowania), a tworzy backup, który można bezpośrednio wgrać na dowolny serwer WWW i treść będzie od razu dostępna i wyglądająca praktycznie identycznie, jak na blogu. Oczywiście po takim przywróceniu działać będzie tylko odczyt, bez możliwości dodawania komentarzy itp. Co prawda średnio da się z tego automatycznie przywrócić w pełnej formie czy przenieść na inny silnik blogowy, ale najważniejsza rzecz, czyli treść, jest zachowana.

Backupowane są strony z wpisami (i oczywiście komentarzami), hostowane lokalnie zdjęcia i skrypty JS. W przypadku Blox także te strony statyczne, do których jest "przejście" przy pomocy linków. Nie są bacupowane strony, do których nie ma przejścia, linkowane strony, materiały umieszczone na zdalnym hostingu (np. muzyka umieszczona na soundcloud). Najlepiej i najprościej uruchomić i samemu sprawdzić, co się pobrało. Przy zmianie szablonu i linkowań może rzecz jasna dojść do zmiany zawartości nowych backupów.

Koniec tego przydługiego, ale koniecznego moim zdaniem wstępu. Prawda jest taka, że najsłabszym ogniwem jest człowiek i jeśli nie uruchomi się automatycznego backupu, to w najpotrzebniejszym momencie danych nie będzie. A samo się nie włączy. Czyli klasyczne ludzie dzielą się na tych, którzy robią backupy i tych, którzy będą je robić.

Do rzeczy. Aktualnie korzystam z polecenia:

wget -q -m -p -E -k http://rozie.blox.pl

Opcje (krótko): q - brak wyświetlania wyjścia, m - mirror, p - ignorowanie poziomu rekursji, E - konwersja plików do HTML niezależnie od rozszerzenia, k - konwersja linków na lokalne. Bardziej szczegółowy opis każdej opcji w pomocy programu.

Cały skrypt dla Linuksa, który można dodać do crona, żeby raz na jakiś czas się uruchamiał - poniżej. Wersja moja, trzeba sobie dostosować. Łatwo daje się przerobić na backupowanie kilku blogów.

Mam nadzieję, że będzie parę tragedii mniej. Chętnie usłyszę uwagi do tego sposobu i propozycje poprawy. Jakby ktoś chciał popełnić dokładny opis dla Windows, to zapewne ludziom się to bardziej przyda.

Przydatne linki (stąd wiem, że działa także dla Blogspot i Wordpress, a także podpatrzyłem kilka opcji):

Automatyzacja backupu bloga Blogspot

Automatyzacja backupu bloga Wordpress

[1] Tak, nabijam się. Zawartość bloga, konta na FB czy µbloga nie jest dla mnie tak ważna. Ale wiem, że niektórzy podchodzą do tego inaczej.

[2] Jest też wersja wget dla Windows, kiedyś używałem i działała. Oczywiście cały skrypt wymaga przepisania na platformę Windows, co nie jest trudne. Przydadzą się zapewne gzip dla Widnows oraz tar dla Windows, chyba, że od razu skorzysta się z jakiegoś natywnego archiwizera plików typu rar, zip itp.

Trochę z rozpędu po ostatnim spojrzeniu na beznadziejną captchę na Blox, trochę zażenowany brakiem działania administratorów Blox w tak wydawałoby się prostej sprawie, trochę chcąc odkurzyć stare skrypty i znajomość Perla, trochę ze względu na zainteresowaniem tematem spamu, a w końcu trochę dla zabawy, postanowiłem zrobić przymiarkę do automatycznego wykrywania spamu na Blox. Chodzi o określanie, czy dany blog służy wyłącznie spamowaniu, oczywiście automatycznie, a co za tym idzie nie ze stuprocentową pewnością.

Administratorzy zapowiedzieli, że captcha zostanie poprawiona w kwietniu (trzymam za słowo i liczę na to, zapewne nie tylko ja), więc spamblogów nie powinno od tej pory przybywać. Zatem postanowiłem skupić się nie na liście nowozałożonych blogów, tylko na liście nowych wpisów, czyli aktywnych spamblogach. Co prawda pierwotny plan zakładał przeiterowanie się po wszystkich blogach i określenie prawdopodobieństwa, czy jest to spamblog, ale nie znalazłem niestety listy wszystkich blogów na Blox. Owszem, można próbować robić rzeźbę pod tytułem "przeiterujmy się po tagach", ale nadal nie daje to gwarancji uzyskania listy wszystkich blogów - wystarczy, że ktoś nie taguje i system nie dotrze do jego bloga, więc stanęło na tym, że obserwuję listę nowych wpisów i stamtąd biorę dane. Przy okazji oceniam nie tyle cały blog, co poszczególne wpisy, co może być przydatne.

Podejście pierwsze - pobierz i oceń. Na samym początku stwierdziłem, że będę pobierał wpis do oceny i oceniał na podstawie arbitralnych kryteriów. Pomysł szybko upadł - zmiany w algorytmie oceniania powodowały niekompatybilność z poprzednimi danymi, a zmiany były konieczne - wychodziły coraz to nowe kryteria i ich wagi. Wersjonowanie algorytmu przy ocenie nie pomagało, bo dane były tracone. OK, nie jest to wszystko aż tak proste, jak się wydawało na początku.

Podejście drugie - pobierz i zapisz jak najwięcej cech wyróżniających dla danego wpisu/bloga, a potem pomyśli się nad algorytmem. No niestety, zapisywanie dużej ilości danych może być ciekawe, szczególnie, że potem można sięgnąć do wiedzy ze studiów i określić poziomy istotności poszczególnych parametrów (albo popytać kumpla o gotowca, może jeszcze ma...). Wytrenuje się AI na próbce kontrolnej, a potem AI sama zrobi resztę. Brzmi fajnie, ale trochę overkill, poza tym, mało odporne na dołożenie kolejnych parametrów, gdyby przyszło mi do głowy ich wyciąganie.

Podejście trzecie, aktualne,kompromisowe - pobierz i zapisz istotne (wybrane arbitralnie przeze mnie) cechy wyróżniające dany wpis. Osobny skrypt ma algorytm procentowy, każda cecha może przyjmować wartości 0-100% prawdopodobieństwa bycia spamem. Następnie w zależności od ilości cech wylicz prawdopodobieństwo dla całego wpisu przy pomocy średniej ważonej. Rezultaty są dość interesujące.

Tutaj lista blogów, które sklasyfikowałem jako spamerskie z prawdopodobieństwem 80% i więcej. Format prawdopodobieństwo bycia spamem (%), spacja, link do bloga. Nie widzę (szybko patrząc) żadnego false positive, a wy? Aktualnie jest takich blogów 375 na 2404 wszystkich sprawdzonych blogów. Jasne, nie jest to cud techniki, ale przy dodaniu pewnych prostych whitelist myślę, że można spokojnie blokować automatem wszystkie blogi z prawdopodobieństwem od 70% w górę.

Szczegółów badanych cech oraz algorytmu nie chcę na razie opisywać, bo po co spamerzy mają się bronić? Jak będzie utrudnione zakładanie nowych blogów, to pomyślę o tym. Na razie cały czas zbierają się dane... Gdyby byli chętni do przeglądania wyniku w celu wychwytywania false positive'ów (wpisujcie miasta, które przeglądają ;-)), to mogę pomyśleć o wystawianiu listy spamów automatem co jakiś czas.

Całość napisana oczywiście w Perlu, główny moduł zbierający z użyciem WWW::Mechanize (genialna sprawa do crawlerów).

UPDATE: Drobny update statystyk z dnia 27.04.2012 - 13481 unikatowe blogi (wcześniej chyba były unikatowe wpisy, ale mniejsza), w tym 1094 do natychmiastowego wycięcia (80% i więcej). Dla porządku 70% i więcej to 2438 sztuki. Listy nie zamieszczam, bo zainteresowanie było znikome. A captcha nadal nie została poprawiona, choć koniec kwietnia...

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi "newsa" o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta - swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później - tradycyjnie - na swapie na dysku.

Prosty skrypt realizujący powyższe:

#!/bin/bash
modprobe zram
echo $((200*1024*1024)) > /sys/block/zram0/disksize # 200 MB
mkswap /dev/zram0
swapon -p 60 /dev/zram0

Kolejno: załadowanie modułu zram (można korzystać z parametrów), określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci na swap!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne - zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

• cat /sys/block/zram0/compr_data_size - rozmiar danych po kompresji
• cat /sys/block/zram0/orig_data_size - rozmiar nieskompresowanych danych
• cat /sys/block/zram0/mem_used_total - całkowita ilość zużytej pamięci
• swapon -s - rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

• http://www.webupd8.org/2011/10/increased-performance-in-linux-with.html
• http://unix.stackexchange.com/questions/17879/cleancache-vs-zram
• https://lwn.net/Articles/454795/
• http://en.gentoo-wiki.com/wiki/Zram_disks
• http://crunchbanglinux.org/forums/topic/15344/zram-a-good-idea/

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem...) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK - zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram - więcej przykładów w linku do wiki Gentoo.

Czy naprawdę piątek przypada trzynastego dnia miesiąca częściej, niż inne dni tygodnia, jak wynika z tego wpisu? Postanowiłem to sprawdzić, metodą najdoskonalszą, czyli brute force. Co prawda tylko dla lat 1970-2037 czyli w Unix Epoch (pełne lata).

Kod był praktycznie gotowy z czasów obliczeń, czy pracownicy zyskają, czy stracą na wolnym 6. stycznia. Ostatecznie wygląda on tak:

a wynik działania wygląda tak:

DOW - ilosc
1 - 116
2 - 118
3 - 115
4 - 117
5 - 117
6 - 116
7 - 117
Suma: 816

1 - Monday, ... , 7 - Sunday

Piątek oznaczony jest cyfrą 5, jak widać występuje on jako trzynasty dzień miesiąca 117 razy, podobnie jak czwartek i niedziela , więcej w badanym okresie jest wtorków trzynastego (118), a najmniej śród (113).

Pozostaje pytanie, dla jakich dokładnie lat prowadzona była analiza w oryginalnym wpisie. Na oko wygląda na jakieś 335 lat, pytanie które dokładnie. W każdym razie w badanym okresie nic nie wskazuje na większą częstotliwość występowania piątku w trzynasty dzień miesiąca.

Tak się złożyło, że w użyciu jest sobie Quagga. Złożyło się też tak, że pobierane z niej są pewne dane przy pomocy polecenia vtysh. W postaci:

vtysh -c "show ip bgp neighbors  advertised-routes"

Następnie wynik polecenia jest parsowany skryptem. Generalnie chodzi o pobranie sieci w notacji CIDR. I wszystko byłoby fajnie, ale Quagga w ramach kompatybilności wstecznej (it's not a bug, it's a feature!) zwraca czasem samo IP. Niejednoznacznie, przez co z prostego w założeniu skryptu powinien zrobić się automat domyślający się, czy chodzi o /8, /16 czy /24.

Szukałem informacji czy można coś z tym zrobić na kanałach IRCowych, dostałem dane, że nie ma opcji, by zmienić takie zachowanie, tzn. aby Quagga zwracała jednoznacznie (np. uruchomienie z jakąś opcją). Za to było zainteresowanie ew. znalezionym rozwiązaniem. Nie znalazłem. Wygląda, że po prostu się nie da (tak, wiem, zawsze można pogrzebać w kodzie...).

Nie znalazłem też prostej koncepcji na określanie, o jaką długość prefiksu chodzi w danym przypadku. Akurat w przypadku, w którym używam średnio mi na tym zależy, ale elegancko byłoby móc jednoznacznie określić o jaki prefiks chodzi. Pomysły mile widziane. Przychodzi mi do głowy sprawdzanie, czy dla /8 i /16 nie ma nakładających się sieci z prefiksami określonymi wprost. Wtedy wiadomo, że chodzi o /24.

PS. Wiem, że jest BIRD. Jest rozważany, ale to trochę inny temat.

Dziś na kanale padło pytanie jak odtwarzać w konsoli radio z http://moje.polskieradio.pl? Na początku sądziłem, że chodzi o Trójkę itp., wtedy format URLa działający zarówno w mplayer jak i w MPD to wspominany we wpisie o MPD:

mms://stream.polskieradio.pl/program3

Okazało się jednak, że chodzi o pozostałe strumienie. I tu nie jest już tak różowo i prosto. Co prawda podczas poszukiwań (w sumie na koniec) ktoś natknął się na skrypt, który umożliwia odtwarzanie tych strumieni w konsoli, ale wędka lepsza od ryby więc:

• Każda strona zawiera odtwarzacz w JS.
• W kodzie odtwarzacza jest link do strumienia.
• Link do odtwarzacza jest stały.
• Link do strumienia również jest stały.
• Strumień da się odtwarzać w mplayerze.

Przykładowo:

Minimax ma URL:

 http://moje.polskieradio.pl/station/33/Minimax

Player JS powstaje przez dodanie /_js/player.js, czyi ma URL:

 http://moje.polskieradio.pl/station/33/Minimax/_js/player.js

Strumienie są nazywane wg schematu k.stream, czyli szukamy:

wget -q -O - http://moje.polskieradio.pl/station/33/Minimax/_js/player.js| egrep "file.*k.*stream"

co daje nam wynik  _obj2.addVariable('file', 'k34.stream');

Cały link do strumienia to:

rtmp://stream85.polskieradio.pl/live/k34.stream

Oczywiście nie dam głowy, że stream85 będzie stała i niezmienna, ale to również widać w źródle playera. Jedyną nieoczywistą częścią było dodanie live - wyłuskane z działających stacji (IIRC z Trójki).

Niestety, taką wersję obsłuży mplayer, ale już nie MPD. Jakby ktoś znalazł rozwiązanie jak tworzyć URL zdatny do MPD - proszę o info. Wersja ze skryptu odpada.

Wam życzę dobrego odbioru, a sobie, żeby stacje radiowe przestały utrudniać ludziom życie i dawały przyjazne konsolowym odtwarzaczom linki. Nie zawsze chce się/można włączyć ciężką przeglądarkę, by posłuchać radia. Niezrównanym ideałem jest tu dla mnie Radio Baobab, które nie tylko daje przyjazny konsoli format, ale również w wolnym formacie ogg (obok innych formatów) i w takiej formie, że się ładnie scrobble'uje.

UPDATE: Mpd w wersji 0.16.2 radzi sobie z URLami typu rtmp:// co oczywiście cieszy.

• 1 stycznia
• 1 maja
• 3 maja
• 15 sierpnia
• 1 listopada
• 11 listopada
• 25 grudnia
• 26 grudnia

(pomijam 4 święta ruchome, które w Polsce nigdy nie wypadają w sobotę), a do tego dochodzi od tego roku 6 stycznia.

Nie wdając się w matematykę (jakoś nie mam głowy do matematyki kalendarzowej, a nic sensownego mi nie wyszło przez chwilę namysłu), korzystam z metody najdoskonalszej, czyli pełnego przeglądu (AKA brute force) wg algorytmu: jeśli któreś z dotychczasowych świąt wypadnie w sobotę, to pracownicy tracą dzień, jeśli 6 stycznia nie wypadnie w sobotę ani w niedzielę, to pracownicy zyskują dzień.  I sumowanie strat i zysków...

Całość to nieładny bash (funkcja date) napędzana perlem, pisany na szybko.

Wynik? Miłe złego początki - przez najbliższe 10 lat stracimy, jako pracownicy, średnio rocznie 0,1 dnia wolnego, a w pierwszych 3 latach nawet będzie niewielki zysk, ale dla 25 lat - o ile przepisy się nie zmienią - stracimy łącznie 8 dni wolnych, czyli 0,32 dnia wolnego rocznie. Szczerze mówiąc, nie jest tak źle jak myślałem...

Ale zmiana jest ewidentnie niekorzystna dla pracowników. Gdyby miała miejsce w 1990 roku, to do tego roku tracilibyśmy średnio ponad pół dnia wolnego rocznie.

I skrypt do obliczeń:

Temat (nie)unikatowych numerów kont pojawił się w tej dyskusji nt. tokenów, a szerzej opisany jest w tym wpisie, ile cyfr potrzeba, by numer rachunku bankowego był unikatowy. Przyznam, że nie miałem zielonego pojęcia nt. algorytmu weryfikacji numeru IBAN, ale na chłopski rozum kolizje zdarzą się wszędzie. Stwierdziłem, że najlepsza metoda nauki to napisać skrypt do sprawdzania. Oczywiście w Perlu. Przy okazji wyszło mi, że Perl średnio sobie radzi z dużymi liczbami, a Python dobrze, ale dzięki temu znalazłem pięknego gotowca w postaci modułu do sprawdzania poprawności numeru IBAN.

Pierwsze, co rzuca się w oczy, to fakt, że tak naprawdę numer IBAN jest zamieniany na liczbę, a czy jest poprawny określane jest tylko na podstawie jednego testu - jeśli reszta z dzielenia tej dużej cyfry przez 97 wynosi 1, to numer jest poprawny.

Chwila zabawy programem i okazuje się, że dla 3 brakujących cyfr w dowolnym miejscu rachunku można wygenerować ok. 10 kolizji. Pewnie ma to coś wspólnego z faktem, że 97 jest liczbą pierwszą, a samo 97 mieści się w każdym tysiącu właśnie 10-11 razy, ale tutaj już by się matematyk przydał i zasady podzielności przez 97 (hasło do Google cechy podzielności przez 97 nic sensownego nie znalazło niestety).

Inna szansa, że nasze PL na początku numeru (które wraz z następującymi po nim dwiema cyframi jest przesuwane na koniec i zamieniane na liczby patrz algorytm weryfikacji numeru IBAN) jest na tyle pechowe, że powoduje taką przykrą przypadłość. Ale to łatwo sprawdzić - dzięki użyciu ogólnej biblioteki skrypcik do bruteforce'owania numerów IBAN powinien działać dla wszystkich krajów.

Póki co konkluzja jest taka, że aby numer był unikatowy, to trzeba podać wszystkie cyfry. Przy dobrym wietrze może się zdarzyć, że 1 można opuścić.

PS. Nie cierpię słowa unikalny. Dla mnie oznacza ono możliwy do uniknięcia. Zamiast niego możnaby używać słowa unikatowy. Niestety SJP traktuje je jako synonimy.

Przy okazji chęci uporządkowania (może rozwoju) mojego μbloga identi.ca pojawił się odwieczny problem: jak znaleźć znajomych w identi.ca (w ogólności: w serwisie mikroblogowym)? Po chwili namysłu stwierdziłem, że najprostszym sposobem szukania znajomych jest przeglądanie znajomych moich znajomych. Skoro ja znam A, a A zna B, to stosunkowo spora szansa, że znam B lub że chcę go dodać do obserwowanych. Podobnie tematycznie - ludzie zwykle obserwują ludzi o podobnych zainteresowaniach.

Najprostszy wariant, ręczny, to otworzenie przeglądarki, otworzenie profili wszystkich znajomych w kartach, następnie dla każdego profilu otworzenie wszystkich obserwowanych. Teoretycznie dobre, w praktyce szybko zrobiłoby się kilkadziesiąt/kilkaset kart, na dodatek z powtarzającymi się profilami. Nie tędy droga.

Ponieważ identi.ca ma API, to postanowiłem sprawdzić, czy nie uda się lekko sobie pomóc skryptem. Okazało się, że w Perlu jest moduł do obsługi API identi.ca o nazwie Net::Identica. Tak naprawdę API identi.ca i Twittera jest identyczne (do Twittera jest Net::Twitter), ale stwierdziłem, że dodam w systemie dedykowany moduł. Co prawda nie ma go w repozytorium debianowym, ale stosunkowo łatwo go zbudować (po spełnieniu zależności) z użyciem dh-perl-make.UPDATE: Ostatecznie korzystam jednak z Net::Twitter.

Ponieważ sądzę, że pytanie jak znaleźć znajomych na Twitterze (czy też na identi.ca) zadaje sobie sporo ludzi, postanowiłem opublikować skrypt, może komuś się przyda. W skrypcie należy podać ID usera, od którego ma zacząć poszukiwania, login i hasło. Nie polecam zmieniać poziomu głębokości poszukiwań (domyślnie jest to znajomi znajomych).

Algorytm jest prosty: dopóki nie osiągnie zadanego poziomu głębokości (domyślnie 2 czyli znajomi znajomych), to pobierze wszystkie ID użytkowników będących znajomymi obecnego użytkownika i doda je do sprawdzenia. Z kolei sprawdzanego użytkownika oznaczy jako sprawdzanego (i nie będzie go sprawdzał po raz kolejny). Zaczynamy od wskazanego ID użytkownika (przypuszczalnie własnego).

W zasadzie tyle. Na koniec pobierze i wyświetli dla wszystkich zebranych ID, których nie mamy już w znajomych podstawowe dane - nazwę, link do profilu, opis itp. - raczej wystarczy, by określić, czy chcemy dodać daną osobę do obserwowanych, czy nie. Bonusowo ID użytkownika, który jest zakończeniem najkrótszej (jednej z najkrótszych) ścieżek do nowopoznanej osoby.

W trakcie pojawił się drobny problem - znajomych znajomych było ponad 3k. Przypuszczałem, że jest jakiś błąd w skrypcie, ale po bliższym przyjrzeniu się wyszło na jaw, że winny jest rms (tak, Richard M. Stallman), który obserwuje właśnie tyle osób. Na takie okazje została dodana blacklista - wystarczy podać tam ID użytkownika, którego znajomych nie chcemy sprawdzać (w ogóle).

Na koniec skrypt wyświetli nam podstawowe dane, jak dla mnie wystarczające, by zorienotwać się, czy chcemy dodać kogoś do obserwowanych. Zasadniczo nic nie stoi na przeszkodzie, by dodać ich (po ID) skryptem, ale ja wolę wejść na profil i zobaczyć najpierw, co piszą (tak, oznacza to, że prawdopodobnie niebawem będę intensywniej korzystał z identi.ca, kosztem Blipa).

Skrypt poniżej. Przy okazji być może jest to sposób na nieirytujące zamieszczanie kodu na Blox...

UPDATE: Nie bardzo chciały działać URLe, przeszedłem na Net::Twitter i zamieszcam poprawioną wersję.

UPDATE2: Jest w komentarzu, ale nie wszyscy docierają: Jak znaleźć ID użytkownika na Twitterze? ID użytkownika na Twitterze (na Identi.ca też) jest zawarta w feedzie RSS danego użytkownika.

Wygląda, że mój odtwarzacz dorobił się finalnej postaci. To, co najważniejsze, czyli odtwarzanie muzyki działało od samego początku. Ostatnio dorobił się dodatkowej karty flash, a teraz obsługi scrobblingu. O ile samo włączenie scrobblingu, które już wcześniej planowałem zrobić, jest trywialne i aż dziwne, że wcześniej tego nie zrobiłem, o tyle spięcie z libre.fm trywialne nie jest (trudne też nie, ale). Do rzeczy.