Komunikacyjne podobieństwa

Czasem patrzę na różne rzeczy i stwierdzam, że wszystko to jest do siebie bardzo podobne. Półtora roku temu napisałem:

Blog to zbiór stron z atrybutami author, date, title, body, comments (comment author, comment date). Pewnie jeszcze tags.

No dobrze, zapomniałem jeszcze o category. Przypomniało mi się to w związku z pytaniem, które dostałem na maila, a które dotyczyło eksportu zawartości bloga na WordPressa i wynikającym z tym grzebaniem w skryptach różnych, starych i nowych.

Tyle, że jakby się dobrze zastanowić, to ta struktura jest powszechna w komunikacji. Weźmy takiego Facebooka – mamy wpisy, są tagi, jest treść, autor i data. Jedyne czego nie ma, to tytuł. Pod wpisami oczywiście są komentarze. Czyli w zasadzie blog.

Facebook oczywiście nie jest wyjątkiem, podobnie jest na Twitterze czy G+. A jakby się zastanowić głębiej, to początki sięgają pewnie NNTP lub emaili. Tam również były w postach data, autor i tytuł. Na komentarze trzeba by tam spojrzeć inaczej: każdy post mógł być komentarzem – decydowało o tym umiejscowienie w hierarchii. W pewien sposób rozwiązanie lepsze i bardziej elastyczne, niż to z blogów – tu protezą jest trackback lub linkowanie. Za to nie było tagów, które zapewniają komunikację/połączenia poziome pomiędzy wpisami.

Nie wiem czy pisałem już kiedyś o tym, ale zastanawiam się, na ile realne i sensowne byłoby użycie serwerów NNTP do komunikacji rozproszonej, niezależnej, powiedzmy „obywatelskiej”. Coś jak Diaspora. Oczywiście z jakimś sensownym frontendem do czytania. I pewnie z tagami i kategoriami, które łatwo można by było uzyskać przy pomocy wprowadzenia dodatkowych nagłówków, np. X-Category oraz X-Tags. Po co? Cóż, wydaje mi się, że istnieje gotowy, dojrzały soft, sprawdzony w działaniu w sporej skali. Pytanie, czy soft ten przypadkiem nie jest już przestarzały. Ale mam wrażenie, że sporo pary projektów typu Diaspora idzie w pisanie istniejących rzeczy, zamiast w układanie flow i dopasowywanie istniejących narzędzi. Rozumiem, że tworzenie jest fajne, ale jeśli ma być to wymyślanie koła od nowa, to IMHO przestaje mieć sens.

I jeszcze jedna sprawa, pasująca do układanki. Jakiś czas temu został zamknięty serwis Delicious, grupujący linki. Znalazłem backup i co? Jest to link, pełniący rolę treści, jego tytuł, są tagi i data. W związku z tym bliski jestem eksportu starych linków do minibloga i napisania prostego skryptu do dodawania nowych wpisów. Oczywiście pelican jako silnik, a skrypt w Pythonie.

Żegnaj Twitterfeed, witaj dlvr.it!

Serwis Twitterfeed.com (nie linkuję, bo pewnie zaraz dead link będzie) ogłosił, że z końcem bieżącego roku kończy działalność. Zamknięcie wzorowe – jest dużo wcześniej, jest komunikacja mailowa i informacja na stronie. W mailu są wskazane alternatywy (buffer.com i dlvr.it).

Rzuciłem okiem na strony polecanych serwisów i stwierdziłem, że przenoszę się na ten drugi serwis. Strona wyglądała zachęcająco – wszystko przejrzyste, logicznie poukładane i dobrze opisane, więc się zarejestrowałem.

Pierwszy zgrzyt – wystarczy podać maila i hasło, by założyć konto w serwisie. Żadnego potwierdzania rejestracji mailem, klikania w URL. Z jednej strony fajnie, bo szybciej i łatwiej – klik, klik i już możemy dodawać feed. Z drugiej nawet hasła nie trzeba podawać dwa razy – ciekawe ile drugich logowań zaczyna się od przypomnienia hasła.

Drugi zgrzyt – podanie URLa do feedu, rozpoznanie i… wykryty tytuł to Pomiędzy bitami Hell, yeah, XXI w. Na szczęście tytuł można edytować (co nie jest standardem). Zobaczymy co będzie z treścią… Oczywiście to poniekąd wina Blox, który nadal nie korzysta z UTF-8, ale charset jest poprawnie zadeklarowany…

Trzeci zgrzyt – skracanie URLi nie jest już tak fajne jak kiedyś. IIRC Twitterfeed.com pozwalał na dodanie bit.ly tak po prostu. w dlvr.it nie ma tak dobrze. Bit.ly można dodać, ale tylko po zalogowaniu, a nie przypominam sobie, bym kiedykolwiek zakładał tam konto. Ani rejestrować się tam nie chcę. Więc chwilowo wszystkie jajka blogowo-twitterowe lądują w jednym koszyku z napisem dlvr.it. Dobrze, że nie potrzebuję tego jakoś poważniej…

W każdym razie pora na test. Ten wpis powinien pojawić się na Twitterze dwa razy – po staremu i po nowemu. I zobaczmy jak to wygląda w praktyce…

Drobne zmiany na planecie

Tak jest zawsze. Wszystko może działać od wieków stabilnie, ale jeśli tylko zrobię restart maszynki, mając mało czasu, to wychodzą kwiatki. Tak było i wczoraj z routerem (o tym kiedyś…), tak było i dziś z planetą Joggera. Restart dedyka przed wyjściem do pracy (o dziwo wstał bez problemu), bo już trochę długo działał i kernel stary, a ciągle zapominałem, odpalam stronę w tramwaju w drodze do pracy i… już gdzieś to widziałem.

Okazało się, że skrypt zaciągnął stare wpisy z jednego z feedów[1]. Początkowo podejrzewałem czyszczenie cache planety, który leżał w /tmp albo cache lighttpd (w ramach motywacji: wkrótce przejście na nginx), ale szybko wykluczyłem tę drugą możliwość. Cache planety był w /tmp i z tym nic nie zrobię, bo /tmp jest czyszczony przy restarcie, więc pomyślałem, że trudno i wkrótce się wyrówna.

Ale po powrocie do domu siadłem jednak do debugu. Na oko dziwna struktura feedu, który lądował na początku, ale validatory mówią, że tak może być i generalnie feed poprawny. Jedyne co się rzuca w oczy to lastBuildDate równe z datą pobrania pliku. Nie wiem, czy błąd, czy home made SEO, w każdym razie w połączeniu z brakiem informacji o dacie publikacji poszczególnych postów skutecznie chwilowo popsuło planetę[2].

W ramach mitygacji (nie kalkując z angielskiego: łagodzenia) zrobiłem dwie rzeczy. Po pierwsze, liczba postów na planecie z danego feedu jest ograniczona do trzech. Po drugie (i tego w repo nie będzie), cache wylądował poza /tmp. Czy się sprawdzi? Pożyjemy, zobaczymy. Gdyby ktoś zauważył jakieś problemy z ilością wpisów z feedu – proszę o kontakt.

[1] Dokładnie http://karbownicki.com/rss.xml

[2] Jeśli to możliwe, proszę o poprawienie tej daty.