Stało się. Nabyłem nowego, właściwie to starego laptopa Dell D400. Teraz mam problem. W jaki sposób utrzymywać spójność katalogów domowych między obecną i nową maszyną. Chciałbym wymiennie ich używać. Poszukam jakiegoś mechanizmu do synchronizacji.

Na początku postanowiłem posprzątać. Zawsze miałem problem z utrzymaniem porządku na dysku. Jak tu podzielić te megabajty danych, tak aby łatwo znaleźć pliki, a z drugiej strony by nie gromadzić śmieci.

Ha! Myślę sobie. Znam lekarstwo na entropię, ale jest ono na radzenie sobie na “brak czasu” i problemy z realizacją zadań. To GTD. Sprawdza się znakomicie. Właściwie to sprawdzało, bo ostatnio nie praktykuję.

Dla przypomnienia, proces:

Tak mnie natchnęło, aby podzielić dane zgodnie z tym diagramem. Zamiast, jak to dotychczas robiłem, tworzyć katalogi z podziałem na rodzaj danych (dokumentacje, źródła, zdjęcia, muzyka etc) zrobić katalogi odpowiadające kontenerom z tego diagramu przepływu (dane wejściowe, bieżąco przetwarzane, referencyjne, śmieci etc). Dane referencyjne podzieliłem pod kontem pochodzenia: własne, publiczne. Głównie ze względu konieczności robienia kopii danych prywatnych. Rzeczy publiczne można pobrać z internetu ponownie, a mojego CV raczej nie :-). Ponadto dane prywatne mogły by być przechowywane na szyfrowanym systemie plików. Ale to już inna bajka.

Jako, żem człek leniwy, pewnie zrobię jakiś skrypt usprawniający proces zarządzania danymi w kontenerach. Automagiczne by, po jakimś czasie, przenosił z katalogu ‘inbox’ do katalogu ‘kiedyś’, czyścił śmietnik, robił kopie zapasowe, etc, etc.

Kolejną rzeczą przydatną w utrzymaniu porządku jest stosowania mechanizmu wersjonowania. Wersjonuję teraz wszystko: domowe projekciki, drobne skrypty, konfigurację emacsa. dane kontaktowe etc. Koniec z katalogami -old, -old-old etc. Do wersjonowania używam Mercuriala. Pomijając całą propagandę z rozproszonymi systemami wersji, ma niewątpliwą zaletę w porównaniu do cvs/svn. Mianowicie, repozytorium utrzymywane jest w tym samym co katalog roboczy. W przypadku cvs/svn trzeba mieć miejsce na repozytorium i na katalog roboczy. Niby mała różnica, ale przy wdrożeniu wersjonowania jest o jedną decyzję mniej i przez co jest łatwiej się przemóc :-).

Do Przechowywania informacji tekstowych zamierzam użyć, rekomendowanego przez kolegów z pracy, org-mode’a. Pierwsze wrażenie pozytywne, dokumentacja jest na wysokim poziomie.

A jeśli o chodzi o synchronizację danych to na początek wypróbuje unisona.

Zobaczymy. Pewnie znowu wciągnie mnie zabawa z narzędziami i odciągnie od “prawdziwych” wyzwań :-).

Po przeczytaniu artykułu Write Articles, Not Blog Postings boga od używalności sieci web, pana Nielsena. Zacząłem się zastanawiać, czy moje wpisy są powyżej średniej. Artykułami na pewno nie są.

Może tylko zwiększam, jak to autor ujął, informacyjną polucję?

Od jakiegoś czasu obserwuję co się dzieje w dziedzinie rozproszonych systemów kontroli wersji. Swoje testy rozpocząłem od gita, głównie za sprawą filmu: Linus o Gicie.

Powiem tyle, moja intuicja nie jest zbieżna z tym narzędziem. Nie mogę się przemóc do dodawania zmodyfikowanych plików przed zatwierdzeniem zmian albo parametru -a. Na mój gust Git to typowy objaw projektu budowanego metodą bottom-up (metoda ogrodnicza, iteracyjnie dodajemy i strzyżemy kod). Ma interfejs składający się z ponad 150 różnych wysoko i nisko poziomowych funkcji, które na dodatek nie mają spójnego sposobu wywoływania. Metodę bottom-up jak najbardziej pochwalam. Wydaje mi się, że bez znajomości procesu rozwoju Linuxa przesłanki do poszczególnych funkcji pozostaną mi zupełnie nieznane i niezrozumiałe. Na dodatek dokumentacja jest słaba. IMHO trzeba poczekać, aż się trochę projekt ustabilizuje.

Teraz na warsztat wrzuciłem Mercurial. Wydaje się być projektem bardziej zorientowanym na zwykłego użytkownika. Zobaczymy co z tego będzie. Na szczęście moje repozytoria nie są duże ani istotne.

Na początek instrukcja migracji z repozytorium Gita na Hg, oraz publikacji na webie. Instrukcja dotyczy wersji 0.9.3. (jest w pakietach Debiana i Ubuntu)

1. Czytamy instrukcję: Repository conversion
2. Przygotowujemy narzędzie do konwersji :

   dpkg -L  mercurial | grep convert
   cp /usr/share/doc/mercurial/examples/convert-repo.gz .
   gzip -d convert-repo.gz
   chmod +x convert-repo.gz
   

3. Przygotowujemy repozytorium docelowe:
   

   mkdir clget-hg
   cd clget-hg/
   hg init
   cd ..
   

4. Wykonujemy konwersję:

   ./convert-repo clget-git clget-hg clget-map
   hg clone clget-hg clget
   rm -fr clget-hg
   

5. Kopiujemy repozytorium na serwer:

   scp -r clget mojlogin@mojserver:/srv/repositories/
   

6. Zapoznajemy się z instrukcją: Publishing repositories
7. Logujemy się na serwer i przygotowujemy skrypt CGI serwujący repozytoria:

   ssh mojlogin@mojserver
   cd /var/www/moja.domena.com/repo/hg/
   dpkg -L mercurial  | grep hgwebdir.cgi
   cp /usr/share/doc/mercurial/examples/hgwebdir.cgi index.cgi
   

8. Na koniec dodajemy regułę przepisywania URLi (tu dla lighttpd):

    url.rewrite = (
    "^/repo/hg(.*)$" => "/repo/hg/index.cgi$1",
   )
   

A moje repozytoria są tu: nablaone.net/repo/hg/.

Obudowa Sun UltraSCSI z Allegro - 30PLN, kabelek IDE-USB - 40PLN. Brak zrozumienia w oczach ukochanej, bezcenne.

Obecne wdrożenie plotkuj.net zostało zawieszone. Trwają pracę nad nowym wydaniem. Tym razem w pracach bierze udział dwóch programatorów :-). Syndrom drugiego projektu się powoli uwidacznia (6 tabelek vs. jedna z prototypu)

Nowe funkcjonalności to:

• zamknięte kanały/pokoje/grona do plotkowania
• będą dwa rodzaje kanałów, jeden na stałe przypisany do adresu IP użytkowników (zapewnia poufność w ramach organizacji), drugi zaś zwykły dostępny przez mechanizm zaproszeń
• konta użytkowników
• etc, etc

Dla chętnych będzie dostęp do wersji testowej. Proszę podać email na stronie plotkuj.net

O serwisie głośno w blogosferze: Wysyp serwisów plotkarskich