Dziś mija dokładnie rok od pierwszego wpisu na http://pinkaccordions.homelinux.org/wblog.

Stocznia złomowa (ship-breaking yard): ,,zakład zajmujący się rozbiórką i cięciem na złom jednostek pływających. W latach 70. i 80. w Polsce złomowanie odbywało się w porcie wojennym w Gdyni.'' Obecnie większość stoczni złomowych znajduje się w krajach takich jak Indie (Alang), Bangladesz (Chittagong), Pakistan (Gadani) i Chiny.

Praca zatrudnionych tam ludzi wygląda z grubsza tak jak niewolników przy budowie piramid w Egipcie. Wpisując Alang | Chittagong | Gadani + ship-breaking można znaleźć wiele materiałów -- w tym zdjęć -- na ten temat. Jest też trochę zdjęć na flickr.com. Natomiast na googleearth prawie nic nie ma -- jeżeli chodzi o fotografie, za to można obejrzeć jak to wszystko wygląda z lotu ptaka (pierwszy z poniżej zamieszczonych zrzutów z GE przedstawia Alang (lat=21.3847285601, lon=72.1748265443) -- wyróżnia się wrak ex brazylijskiego lekkiego lotniskowca Minas Gerais):

Znalazłem informację -- czytając pl.rec.foto.cyfrowa -- na temat innego programu do synchronizacji śladu ze zdjęciami, pn. gpicsync. Nie próbowałem ale jest chwalony. No i jest dostępny nie tylko w wersji nür für Windows.

Od dłuższego już czasu przymierzałem się do zrobienia katalogu moich zdjęć umieszczonych na flickr.com. Ponieważ przed wysłaniem zdjęcia na flickr.com jego opis w postaci tagów i współrzędnych kopiuję do pliku ze zdjęciem (do odpowiednich pól EXIF) więc teoretycznie ów katalog można by zbudować wydłubując teraz to co trzeba z każdego pliku z osobna. Można by ale... Ale nie zawsze opis na flickr.com zgadza się z opisem lokalnym, bo jak coś spapram to już drugi raz nie ładuję tylko poprawiam ręcznie, bo kiedyś skrypt umieszczający zdjęcia działał inaczej, itd... Mówiąc krótko prościej będzie ściągnąć to wszystko z powrotem z flickr.com. Zrobiłem rozpoznanie w google i się okazało, że jest narzędzie pn. Net::Flickr::Backup służące dokładnie do tego co chcę zrobić: ściągnąć każde zdjęcie z konta na flickr.com wraz z opisem, który to opis zostanie zapisany w formacie RDF. Co dalej będzie z tym RDF-em -- zobaczymy jak się ściągnie.

Postępując zgodnie ze wskazówkami ze strony leobard.twoday.net zainstalowałem moduł Net::Flickr::Backup:

perl -MCPAN -e 'install Net::Flickr::Backup'
yum install perl-XML-LibXML perl-XML-LibXML-Common

Polecenie yum instaluje moduł XML::LibXML, niezbędny do działania Net::Flickr::Backup. W przypadku fedory moduł ten znajduje się w pakiecie perl-XML-LibXML. (Uwaga: zgodnie z tym co napisano na ww. stronie dla systemów Debianowych odpowiednikiem perl-XML-LibXML jest pakiet libxml-libxml-perl.) Na wszelki wypadek doinstalowałem też perl-XML-LibXML-Common, być może niepotrzebnie. Teraz przepisałem zawartość pliku backup-flickr.pl ze wspomnianej wyżej strony (a na tej stronie z kolei jest to przepisane z dokumentacji:-):

#!/usr/bin/perl
#
use Net::Flickr::Backup;
use Log::Dispatch::Screen;
use Config::Simple;

my $CFGFILE = "$ENV{HOME}/.flickr/flickr_backuprc";
my $cfg = new Config::Simple(filename=>"$CFGFILE");

my $flickr = Net::Flickr::Backup->new($cfg);
my $feedback = Log::Dispatch::Screen->new('name' => 'info', 'min_level' => 'info');

$flickr->log()->add($feedback);
$flickr->backup(); 

oraz utworzyłem w katalogu ~/.flickr/ plik konfiguracyjny flickr_backuprc o następującej zawartości:

#
# http://leobard.twoday.net/stories/4122767/
# ###
[flickr]
api_key=AAAAAAAAAAAAAAAAAAAA
api_secret=BBBBBBBBBBBBBBBBBB
auth_token=CCCCCCCCCCCCCC
api_handler=LibXML

[backup]
photos_root=/cmn/archive/Flickr/backup
scrub_backups=1
fetch_original=0
fetch_medium=0
fetch_square=1
force=0

[rdf]
do_dump=1
#rdfdump_root=/home/asc/photos

Uruchomienie perl backup-flickr.pl skończyło się wkrótce błędem dotyczącym kodowania:

Can't escape \x{0119}, try uri_escape_utf8() instead at \
   /usr/local/share/perl/5.8.8/Net/Flickr/RDF.pm line 1497

Z opisu wynika, że coś jest nie tak w pliku RDF.pm. Przy bliższej inspekcji okazało się, że nazwy miejscowości, zawierające polskie znaki (np. Rębiechowo) nie mogą być zakodowane poprawnie przez procedurę uri_escape (Nazwy geograficzne są używane do tworzenia URI postaci: http://www.flickr.com/places/Poland/Pomorskie/Rębiechowo.)

Nie do końca jestem pewien czy dobrze robię ale wymieniłem (dwukrotnie) wywołanie procedury uri_escape na:

URI::Escape::uri_escape_utf8

Teraz program działa. Zostawiłem go na noc żeby zrobić kopię ale się okazało, że kopiowanie działa bardzo wolno. Przez noc ściągnęło się niewiele; potem jak wyłączyłem maszynę ponownie, to wprawdzie program nie ściągał danych drugi raz, ale samo sprawdzanie, w którym miejscu skończył zajęło mu okropnie dużo czasu. Ponieważ mam dostęp -- od jakiegoś czasu -- do tajnego serwera w pracy więc postanowiłem zrobić kopię wykorzystując ową maszynę.

Maszyna jest całkowicie out-of-date i dodatkowo zainstalowałem na niej Ubuntu... Zainstalowałem zaś Ubuntu z tej prozaicznej przyczyny, że nie mogłem znaleźć dysków z instalacją Fedory a jakąś instalkę Ubuntu akurat miałem pod ręką. Jak powszechnie wiadomo Ubuntu i Fedora różnią się nieco, w szczególności różnią się program służącym do instalowania i aktualizacji systemu.

Próba zainstalowania Net::Flickr::Backup tak jak w Fedorze, tj. poprzez perl -MCPAN -e '...' skończyła się błędem na etapie instalowania pakietu SOAP-Lite. Rozczarowujące, ale się nie załamałem:-) Zrobiłem upgrade a potem zainstalowałem dla pewności SOAP-Lite aptem (akurat był dostępny):

apt-get upgrade # 
aptitude search SOAP-Lite # jaki pakiet zawiera SOAP-Lite ?
apt-get install libsoap-lite-perl # instaluję SOAP-Lite

Teraz polecenie

perl -MCPAN -e 'install Net::Flickr::Backup'

Zostało wykonanie pomyślnie. Poprawiam teraz uri_escape na uri_escape_utf8 w sposób opisany wyżej. Kopiuję do ~/.flickr/ plik flickr_backuprc także opisany wyżej.

Teraz mogę uruchomić:

 ./backup-flickr.pl > BACKUP_FLICKR.LOG  2>&1 &

Wygląda, że działa. I mogę się wylogować. Zobaczymy za parę dni czym to się wszystko skończy.

Dla przypomnienia, zapis >BACKUP_FLICKR.LOG 2>&1 wysyła strumienie stdout i stderr do pliku BACKUP_FLICKR.LOG.

Dopisane 4 sierpnia 2008: Bardziej fundamentalny problem się pojawił. Mianowicie, identyfikatory zdjęć (photo_id), które m.in. definiują adres URL do strony ze zdjęciem są całkowicie do kitu, np.:

<flickr:photo rdf:about="http://www.flickr.com/photos/20425995@N00/-1617918774">

Trudno nawet powiedzieć do jakiego zdjęcia odnosi się powyższe. Przy bliższym oglądzie stwierdziłem co następuje: photo_id są ok dla zdjęć wysłanych na flickr przed rokiem 2008. Zacząłem podejrzewać że gdzieś się ,,licznik przekręcił'', ale jak to się stało w językach beztypowych takich jak Perl? Ponieważ nie za bardzo mi się chciało dłubać w kodzie Net::Flickr::Backup zgłosiłem błąd korzystając -- zgodnie z tym co jest napisane w dokumentacji pakietu -- z http://rt.cpan.org. Do samego zgłoszenia błędu wystarczy napisać list na adres bug-Net-Flickr-Backup@rt.cpan.org (do komentowania trzeba się zarejestrować). Mój raport jest tutaj.

Wygląda, że nikt tego Net::Flickr::Backup nie używa, bo przez 12 dni pies z kulawą nogą się nie odezwał. Ponieważ sprawa nie dawała mi spokoju zacząłem dziś drążyć temat. W szczególności przyjrzałem się jak działa procedura backup zdefiniowana w Net/Flickr/Backup.pm. Podejrzenie padło na wiersz:

 $self->log()->info(sprintf("process image %d (%s)",
       $id, &_clean($node->getAttribute("title"))));

A konkretnie specyfikację %d funkcji sprintf. Hmm..., jaka jest maksymalna/minimalna wartość dla liczby całkowitej w Perlu? Doczytałem, że jest to system-dependent i można ją ustalić wykonując poniższy skrypt (znalezione na stronie www.issociate.de):

perl -le 'use POSIX; print for SHRT_MAX, INT_MAX, LONG_MAX, FLT_MAX, DBL_MAX;'

U mnie INT_MAX wynosi 2147483647 (tyle samo wynosi LONG_MAX btw) a przykładowo id tego zdjęcia to 2727375455. Ewidentnie 2727375455 jest większe od 2147483647, więc Net::Flickr::Backup nie może działać prawidłowo. Pozostało teraz ustalić jak jest definiowane photo_id w dokumentacji API flickr.com. Jakoś trudno znaleźć, ale jest po dłuższym szukaniu udało się ustalić co następuje: (por. tutaj): The Flickr API exposes identifiers for users, photos, photosets and other uniquely identifiable objects. These IDs should always be treated as opaque strings, rather than integers of any specific type. The format of the IDs can change over time, so relying on the current format may cause you problems in the future. .

Wymieniłem %d na %s w Net/Flickr/Backup.pm oraz Net/Flickr/RDF.pm, wszędzie tam gdzie jest drukowane photo_id. Mam nadzieję, że nie pominąłem niczego i teraz da się zrobić poprawnie backup flikra.

Zbliża się rocznica mojego blogowania. Prawie rok temu pisałem o TdF, Michaelu Rasmussenie i aferze w tym dopingowej na tym wyścigu. Tegoroczna pętla również przebiega w atmosferze problemów z dopingiem. Spojrzałem na zestawienie tych co byli na topie w ostatnich pięciu latach: Jan Ullrich, Aleksander Winokurow, Ivan Basso i Floyd Landis -- wszyscy dyskwalifikacja za doping. Andreas Klöden i Alberto Contador trefni bo się zapisali do Astany. Trefni to znaczy nic im nie udowodniono ale organizatorzy arbitralnie uważają grupę Astana za niegodną startu w TdF. Michael Rasmussen, któremu też nic nie udowodniono, ciągle nie ma podpisanego kontraktu z jakąkolwiek grupą. Razem podpadniętych jest zatem 7. Pozostali niezłapani to: Cadel Evans, Levi Leipheimer, Oscar Pereiro, Carlos Sastre. Raptem czterech. Chcesz mieć kłopoty -- startuj w TdF.

Goździkowa poleca!!! EPOpiryna

Nie oglądam TdF namiętnie. Większość etapów jest zwyczajnie i jak zwykle nudna. W tym roku oglądałem etapy 9 i 10. Na 9 wspaniale zaatakował pod Col d'Aspin Ricco. Na szczycie miał ponad minutę przewagi, którą utrzymał na 25 km zjazdach do mety. Etap 10 z kolei kończył się podjazdami pod słynny Col du Tourmalet i finalnym podjazdem pod Hautacam (10 km). Wygrał Leonardo Piepoli z tej samej grupy co Ricco (Saunier Duval-Scott). No i co? No i Ricco oraz ten drugi już nie jadą. Doping. Ale lipa... W polskiej Wikipedii też się chyba zniechęcili bo opis wyścigu kończy się właśnie na tym feralnym 10 etapie z 14 lipca.

Wczoraj fantastycznie wygrał finisz z grupy Freire. Spokojnie wyczekał, potem na kole bodajże Zabela podciągnął się bliżej i wreszcie poprawił, jak to mówią. Świetnie pokazane w TV z helikoptera -- jeżeli pojawi się na YouTube (na razie nie ma), to zachęcam do obejrzenia.

A dziś taki sobie średnio trudny etap. Wprawdzie kolarze wjadą na Col Agnel (2744 mnpm), ale to będzie względnie blisko startu więc szaleństw nie będzie. Potem długi zjad prawie do mety. Przed metą górka, ale nie za wysoka, więc różnic dużych nie należy oczekiwać... Wtorek i środa będą dużo trudniejsze. Zwłaszcza środa (Embrun--L'Alpe-d'Huez), bo 1) po wtorku, 2) aż 210 km, 3) dwa niebotyczne podjazdy (Col du Galibier oraz Col de la Croix de Fer) 4) na koniec 14 km decydującego podjazdu pod Alpe d'Huez.

BTW jakby ktoś nie wiedział to L'Alpe-d'Huez należy wymawiać jako Alp diłes a la Croix de Fer to jest to samo co Eisernes Kreuz w j. niemieckim. Napis na zdjęciu obok, który NB uważam za b. śmieszny, został namalowany przez anonimowego kibica w czasie Tour de Pologne 2006. Zdjęcie zamieszczono w Magazynie Rowerowym 11--12/2006 -- reprodukcja niestety bez zezwolenia. Jako okoliczność łagodzącą wskazuję na niską jakość/rozdzielczość reprodukcji. Oryginał w formacie A3 w MR.

Dopisane 20 lipca 2008 (po południu): Ah zapomniałem w swoich statystykach o tym kosmonaucie Armstrongu. A więc do niezłapanych dopisuję Lance'a Armstronga, co daje w sumie pięciu. A na Wikipedii się nie zniechęcili, bo dziś ktoś dopisał relacje z trzech następnych etapów.

Już kiedyś kombinowałem z kursami walut używając do tego plugina Firefoxa. Teraz potrzebowałem czegoś co możnaby uruchmić jako skrypt, korzystający przy tym z jakiegoś wiarygodnego źródła danych i to najlepiej poprzez XML/API a nie html scraping (cf. np. Screen scraping with Perl), bo to ostatnie może nagle przestać działać jak się layout strony zmieni. Krótkie rozpoznanie w ww. kierunku dało w rezultacie następujące potencjalne rozwiązania:

1. Skrypt Johna Bokmy działający w oparciu o dane ze strony www.xe.com (wykorzystuje html scraping). Xe.com wygląda -- sądząc po zawartości serwisu WWW -- na renomowaną firmę ale skrypt nie działa, a nawet gdyby działał to Xe.com zabrania korzystania z ich strony w ten sposób (o czym zresztą John Bokma też pisze).

2. Pakiet Perla pn. Finance-Currency-Convert-WebserviceX, korzystający z kolei z danych ze strony webservicex.net. Nie znam firmy Generic Objects Technologies Ltd, która animuje serwis webservicex.net. Ponieważ wydało mi się, że firma nie jest specjalnie wiarygodna -- zapewne niesłusznie -- nie instalowałem ww. biblioteki Perla i szukałem dalej.

3. Pakiet Finance::Currency::Convert::Yahoo. Korzysta z danych Yahoo Finance i wykorzystuje html scraping. Ponieważ do Yahoo mam większe zaufanie, postanowiłem toto wypróbować:

perl -MCPAN -e 'install Finance::Currency::Convert::Yahoo'
perl -e 'use Finance::Currency::Convert::Yahoo; \
  print Finance::Currency::Convert::Yahoo::convert(1,'USD','PLN');'

Wygląda, że działa i to mimo tego, że ostatnia wersja pakietu jest z roku 2005.

4. Dane z NBP udostępnione na stronie www.nbp.pl/Kursy/Kursya.html. Na dole tej strony jest link do pliku XML. Problem przy zautomatyzowaniu pobierania pliku jest z jego nieprzewidywalnie dziwną nazwą, np. a140z080718.xml. Powyższe oznacza, że to tabela o numerze 140 z dnia 2008/07/18. Oczywiście data to pryszcz (bieżąca) gorzej z numerem tabeli, który wydaje się być trudny do wyznaczenia.

Reasumując: niby prosta i potrzebna sprawa ale podejrzanie brak jest serwisu, który by oferowałby konwersję walut via API (wyjątek: webservicex.net, ale imho podejrzany:-). Pozostaje html scraping albo NBP. Google coś tajemniczo nic ,,w tym temacie'' nie ma -- może nieudolnie szukałem.

Dopisane 20 lipca 2008: czytelnik bloga Krzysztof R. (nazwisko do wiadomości Redakcji:-) już wczoraj zwrócił słusznie uwagę, że Przykładowe zapytanie: http://www.google.com/search?q=1 pln in usd&hl=en zwróci następujący ciąg znaków w treści strony: 1 Polish zloty = 0.495565 U.S. dollars. Ciąg ten można łatwo wydobyć przy pomocy wyrażenia regularnego.
Dziękuję za powyższą wskazówkę...

Zmuszony ostatnio konwertować tekst na konferencję ISD z LaTeXa do MS Word korzystałem -- jak zwykle -- z programu latex2rtf, uruchamiając go następująco:

latex2rtf -C latin2 art-oss.tex 

Następnie ręcznie na cudzym komputerze poprawiam wynik konwersji we wspomnianym MSW. Kłopot był z diagramami, oryginalnie wykonanymi w dia. Kiedyś już konwertowałem pliki .dia na dobrej jakości pliki WMF/EMF ale nie zanotowałem tego nigdzie i oczywiście teraz zapomniałem jak to zrobiłem. Pamiętałem tylko, że 1) zamiana jakiegokolwiek ludzkiego formatu typu SVG/EPS/PDF na WMF to sprawa beznadziejna, 2) jakoś mi to się udało kiedyś zrobić. W rezultacie teraz musiałem niepotrzebnie stracić trochę czasu żeby sobie przypomnieć, że to sama dia potrafi wyeksportować diagram do formatu EMF.

Dokładniej dia w wersji dla MS Windows -- moja wersja pod linuksem ma coś na ten temat na stronach podręcznika ale eksport do EMF kończy się błędem.