kolejny “otwarty” stuff – c.d.

miesiąc temu pisałem o openmoko – głównie w kontekście ciekawostki – projekt bazujący na otwartej specyfikacji, ale bez zadęcia w stronę "open*" über alles.
dziś się dowiedziałem, że panowie od openmoko obwieścili timeline tego co będzie:

  1. 2007-02-11 : udostępnienie pełnych źródeł linuksa użytego na openmoko. wybrani programiści na świecie dostaną darmowe telefony.
  2. 2007-03-11 : telefon pojawi się w internetowym sklepie openmoko.com. ma kosztować $350
  3. 2007-09-11 : telefon wejdzie do sprzedaży do tradycyjnych kanałów – sklepy, sieci komórkowe itp.

mniej więcej w czasie etapu 3 pojawi się nowy model. co będzie zawierał nie wiadomo – ludzie od projektu maja pomysły, ale informują, że to i tak developerzy i użytkownicy będą wybierać/wpływać na to co finalnie tam trafi.
no cóż. pozostaje czekać. z przyjemnością przyjrzałbym się tej komórce.

perl best practices critic

jakiś czas temu damian conway napisał "perl best practices" ("perl. najlepsze rozwiązania"). zawarł w niej szereg sugestii jak pisać.
książkę ogólnie polecam, choć nie zgadzam się ze wszystkim co napisał. ale to już inna bajka.
w oparciu o to co napisał, powstał program: perlcritic (można go zainstalować przez "install Perl::Critic" w shellu cpanowym).
program ten analizuje twój program perlowy i wypisuje błędy (błędy czytaj konstrukcje inne niż zalecane przez damiana). wraz z odnośnikami do numerów stron w książce!
warto zobaczyć jak to wygląda. przykładowo. dla jednego z moich (działających!) programów wynik perlcritica wygląda tak:

=> perlcritic archiveMails.pl
Code before strictures are enabled at line 9, column 1.  See page 429 of PBP.  (Severity: 5)
Integer with leading zeros at line 75, column 55.  See page 58 of PBP.  (Severity: 5)
Don't modify $_ in list functions at line 94, column 37.  See page 114 of PBP.  (Severity: 5)

nie najgorzej. nie? zobaczmy co się dzieje jak każę mu wyświetlać wszystkie błędy, a nie tylko krytyczne:
ojć. całości nie pokażę. za dużo, ale to mogę pokazać:

=> perlcritic -1 archiveMails.pl  | wc -l
69

to mało mówi. więc zróbmy prostą statystykę:

=> perlcritic -1 archiveMails.pl  | perl -pe 's/at line \d+, column \d+/at line X, column Y/' | sort | uniq -c | sort -nr
     14 Mixed-case variable name(s) at line X, column Y.  See page 44 of PBP.  (Severity: 1)
     10 Regular expression without "/x" flag at line X, column Y.  See page 236 of PBP.  (Severity: 3)
      9 Regular expression without "/m" flag at line X, column Y.  See page 237 of PBP.  (Severity: 2)
      6 Builtin function called with parens at line X, column Y.  See page 13 of PBP.  (Severity: 1)
      4 Postfix control "unless" used at line X, column Y.  See pages 96,97 of PBP.  (Severity: 2)
      3 Useless interpolation of literal string at line X, column Y.  See page 51 of PBP.  (Severity: 1)
      3 Subroutine does not end with "return" at line X, column Y.  See page 197 of PBP.  (Severity: 4)
      2 "unless" block used at line X, column Y.  See page 97 of PBP.  (Severity: 2)
      2 Mixed-case subroutine name at line X, column Y.  See page 44 of PBP.  (Severity: 1)
      2 File handle for "print" is not braced at line X, column Y.  See page 217 of PBP.  (Severity: 1)
      1 RCS keywords $Revision$, $Source$, $Date$ not found at line X, column Y.  See page 441 of PBP.  (Severity: 2)
      1 RCS keywords $Revision$, $HeadURL$, $Date$ not found at line X, column Y.  See page 441 of PBP.  (Severity: 2)
      1 RCS keywords $Id$ not found at line X, column Y.  See page 441 of PBP.  (Severity: 2)
      1 Postfix control "if" used at line X, column Y.  See pages 93,94 of PBP.  (Severity: 2)
      1 Package variable declared or used at line X, column Y.  See pages 73,75 of PBP.  (Severity: 3)
      1 No "VERSION" variable found at line X, column Y.  See page 404 of PBP.  (Severity: 2)
      1 Integer with leading zeros at line X, column Y.  See page 58 of PBP.  (Severity: 5)
      1 Forbid $b before $a in sort blocks at line X, column Y.  See page 152 of PBP.  (Severity: 1)
      1 Double-sigil dereference at line X, column Y.  See page 228 of PBP.  (Severity: 2)
      1 Don't modify $_ in list functions at line X, column Y.  See page 114 of PBP.  (Severity: 5)
      1 Code is not tidy at line X, column Y.  See page 33 of PBP.  (Severity: 1)
      1 Code before warnings are enabled at line X, column Y.  See page 431 of PBP.  (Severity: 4)
      1 Code before strictures are enabled at line X, column Y.  See page 429 of PBP.  (Severity: 5)
      1 Capture variable used outside conditional at line X, column Y.  See page 253 of PBP.  (Severity: 3)

łał. a przypominam – ten kod działa i robi co trzeba.
tak czy inaczej – warto spojrzeć. to co perlcritic pokazuje, to czasem całkowicie nieistotne szczegóły (jak np. mixed case variable name), ale czasem jest to coś co warto poprawić. sam po przeczytaniu best practices sporo zmieniłem w swoim stylu kodowania.

gotowanie na filmie

jak może zauważyliście co jakiś czas robię sesję zdjęciową nt. gotowania.
jakiś czas temu zauwazyłem, że wszystkie książki z przepisami są pisane dla ludzi którzy już umieją gotować. po prostu takie przypominajki. o dużej ilości rzeczy nie mówią, lub traktuja jako oczywiste i warte tylko jednego słowa.
stąd wzięła się wizja fotografowania (nie mam kamery, bo jakbym miał to bym kręcił filmiki).
dziś trafiłem na stronę videojug. zawiera ona filmy pokazujące różne rzeczy które można robić w życiu. nie tylko gotowanie. zajmowanie się zwierzakami, majsterkowanie, sporty, maseczki pielęgnacyjne itd.
ale to część kuchenna mnie zauroczyła.
każdy przepis jest sfilmowany. bez udziału aktorów – po prostu pokazują co i jak się dodaje, jak się miesza, ile czasu. co trzeba mieć. filmy są po angielsku co może lekko utrudniać (ktoś wie czemu w przepisie na jambalayę mówią "green pepper" a pokazują coś co wygląda jak poszatkowana zielona papryka?).
ale poza tym – cód, miód i orzeszki. są przepisy na praktycznie każdy rodzaj żarcia. od zup, przez dania główne, desery aż po takie ciekawostki jak sałatka "coleslaw" znana choćby z kfc.

idę popływać na basen

pływaliście kiedyś na basenie? 25 metrów długości, głębokość od 1.2 do 1.8 metra. to taki standard. a jakbym chciał coś więcej?
w belgii otwarto (chyba niedawno) interesujący basen. nazywa się nemo33.
cechy?

  • głębokość do 33 metrów (basen nie jest sześcienny, więc głębokość jest mocno zmienna).
  • 2.5 miliona litrów wody podgrzanej do około 30°c. niechlorowana!. widoczność ponad 33 metry (tzn. widać dno)
  • 2 baseny, w nich 3 "dziury": 5, 10 i 33 metrowe
  • "jaskinie" na głębokości 10 metrów. możliwość instalacji innych dekoracji gdyby była potrzeba.
  • stałe podwodne dzwony z powietrzem – w celu ułatwienia powrotu (wynurzanie z 33 metrów wymaga powolnej dekompresji).

czad. a jak to wygląda?

sprzęt pod linuksa

dowiedziałem się przypadkiem o firmie "system76". jest ona podobno jednym z największych "supporter'ów" (nie mam pojęcia jak to przetłumaczyć by zachować sens) ubuntu. a co robi? sprzęt. pecety. i laptopy. bez windowsów, za to z linuksem.
jeśli kiedyś stawialiście linuksa na lapie wiecie, że nie jest słodko. hibernate, suspend, grafika, dźwięk, apm/acpi. wszystko to generuje problemy.
ale nie na sprzęcie system76!.
oni budują i konfigurują wszystko od podstaw tak by śmigało i nie generowało problemów.
a do tego – specyfikacje są naprawdę niezłe (nie będę cytował bo to i tak trzeba zobaczyć, a przecież nie zrobię kopii całego site'u).
co ciekawe – we wzornictwie widać ewidentne wpływy apple'a. w szczególności w modelu koala (desktop, wyglądający mniej więcej jak macmini).
dodatkowo – dowiedziałem się, że za mniej więcej 2 tygodnie ma wejść do sprzedaży nowy model lapa. specyfikacje:

  • waga – trochę ponad 4 funty (1.8 kilograma)
  • 3.5 cm grubości w najgrubszym miejscu
  • wyświetlacz 13"
  • 5 godzin pracy na baterii, więcej przy wyłączonym bluetoothu i wifi, oraz z włączonym skalowaniem cpu

parametry tego co kupił przedpremierowo pewien koleś:

  • procesor: core 2 duo 2.0ghz
  • ram: 1.5gb
  • dysk: 60gb (7200rpm)
  • wifi: 802.11 a/b/g
  • bluetooth
  • czytnik kart sd
  • grafika: intel 945.

cena – w okolicach $1000.
czad. jeśli czyta to moje szefostwo: chciałbym poprosić o takie cudo zamiast della 🙂 nawet zniosę gnome'a. albo doinstaluję kde.

bilion dolarów

bilion. nie miliard. bilion. milion milionów. tysiąc miliardów. dolarów.
książka o pieniądzach.
opisy w sieci:

  1. Wielki bestseller w Europie Zachodniej, za sensacyjną opowieścią, trzymającą w napięciu od pierwszej do ostatniej strony, kryje się historia pieniądza i tego, jak niczego nie produkując można zostać Krezusem. Kapitalna książka dla maklerów giełdowych, miłośników sensacji i tajemnic.
    Oto rozwoziciel pizzy staje się dziedzicem niewyobrażalnego wprost majątku, zapoczątkowanego przed 500 laty przez jego przodka, który miał wizję, którą teraz tenże rozwoziciel pizz ma zrealizować.
  2. To będzie hit końca 2006 roku, długo oczekiwana powieść sensacyjna, z elementami fantastyki, Andreasa Eschbacha, autora niezapomnianych "Gobeliniarzy" i "Wideo z Jezusem". Grubaśny tom będzie przypominał paczkę banknotów, bo jest to powieść o pieniądzu – tym najbardziej chyba pożądanym wynalazku człowieka, towarze wymiennym. Jest to powieść o tym, jak pieniądz rodzi nowy pieniądz, a mądrze inwestowany tworzy fortuny.
    Książka dla miłośników fantastyki, amatorów dobrej powieści sensacyjnej, a także dla… maklerów giełdowych.

  3. Bilion to milion milionów, tysiąc miliardów tyle dziedziczy w wyniku inwestycji zapoczątkowanej pięćset lat temu, w 1495 roku, przez swego przodka, skromny i fajtłapowaty John Fontanelli. Z dnia na dzień staje się krezusem, bogatszym niż 200 Gatesów razem wziętych. Od jego decyzji może zależeć los gospodarki świata, być albo nie być rządów i życie miliardów ludzi.
a co tak naprawdę w środku? dosyć przyjemne czytadło. z kilkoma "pradoksami" związanymi z ekologią, biedą i życiem. plus rozczarowująca końcówka.
książka przyjemna do poczytania jak ma się więcej czasu – na wakacjach, w podróży pociągiem.

z jednym "drobnym" ale.

nie wiem czy w oryginale też tak było, ale albo jest to wysoce "oryginalny" pomysł twórczy, albo polskie wydawnictwo solaris ma problemy z ludźmi od składu.
czytanie mocno utrudnia fakt iż nie ma żadnych przerw między akapitami dotyczącymi innych wątków. niby bzdurka. ale wielokrotnie zmuszała mnie do wracania do przeczytanego tekstu i czytania go jeszcze raz, bo dopiero na następnej stronie jest jakaś wzmianka o tym, że to co czytam tyczy się już innego wątku.
ogólnie skład jest jakiś taki "na chybcika". wydaje się, że książkę złożono i wydrukowane w 2 dni pod presją czasu aby zdążyć na choinkę.

na koniec – jedziesz na wakacje? jedziesz gdzieś daleko pociągiem? samolotem? kup. poczytasz, spodoba się. w innym przypadku – można sobie odpuścić.

odpowiedzialność za niebezpieczny kod

czy programista (albo firma programistyczna) powinna być odpowiedzialna za dziury w bezpieczeństwie jego (jej) produktu?
większość pewnie powie: oczywiście. tak.
ale nie wszyscy. alan cox – jeden z bardziej znanych guru linuksowych, współtwórca jądra, i ogólnie jeden z największych propagatorów linuksa. otóż on powiedział ostatnio, że uważa, że programistów/firm nie powinno się obciążać odpowiedzialnością za błędy bezpieczeństwa.
oczywiste jest to, że programiści mają moralny (etyczny) obowiązek tworzenia kodu tak bezpiecznego jak to tylko możliwe, ale nie można pociągać ich do odpowiedzialności gdy nastąpi włamanie/naruszenie reguł bezpieczeństwa.
czemu?
bo żyjemy w takim a nie innym świecie. wprowadzenie tego typu odpowiedzialności momentalnie wpłynęłoby (negatywnie) na rozszerzalność produktów – w końcu spora część błędów jest na granicach interakcji produktu z dodatkiem – np. przeglądarki z pluginem.
dodatkowo – byłoby to nieuczciwe, gdyż technologicznie nie da się wyciągnąć konsekwencji wobec twórców oprogramowania darmowego – jego rozwój jest zdecentralizowany, odpowiedzialność dzielona. w dodatku – o tak powstałe oprogramowanie oparte zostają inne platformy – np. komercyjne wersje dystrybucji linuksa, czy jakiekolwiek inne komercyjne pakiety.
wypowiedź alana skomentował jerry fishenden, zgadzając się z nim w zupełności. użył też interesującej metafory: nikt nie pozywa do sądu producenta zamków gdy włamywacz go (zamek) sobie otworzy i włamie sie do domu. czemu więc w przypadku oprogramowania odpowiedzialność ma być przeniesiona częściowo lub całkowicie na wytwórcę?
hmm … interesujący punkt widzenia. muszę się zastanowić co o tym sądzę, ale muszę przyznać, że ma to spory sens.

przełom w technologiach optycznych

naukowcom z uniwersytetu rochester udało się coś niesamowitego. spowolnili foton, (pojedynczy!), zapisali na nim obrazek, po czym odczytali ten obrazek z powrotem.
jest to niesamowite osiągnięcie, gdyż pokazuje kilka rzeczy:

  1. na pojedynczym fotonie można zapisać dużo informacji
  2. potrafimy zapisywać i odczytywać dane z fotonów
  3. przekroczyliśmy kolejny próg który oddzielał nas (ludzi) od stworzenia optycznych nośników informacji.

ostatnia częśc – optyczne nośniki informacji – jest niesamowita. jeśli na pojedynczym fotonie udało się tyle, to jaka będzie gęstość zapisu w produkcyjnych "dyskach"?
obrazek który zapisano nie był jakoś bardzo wysublimowany – ot 2 litery (symbol "university of rochester"). w dodatku – obrazek odtworzył się z pewnymi przekłamaniami.
ale tego typu przekłamania to żaden problem dla mechanizmów kontroli danych.
tak wyglądały obrazki zapisany i odczytany:

zaśmiecony template1 i kopiowanie baz

standardowa instalacja postgresa zawiera 2 (lub 3) bazy:

  • template0
  • template1
  • postgres (tylko w najnowszych wersjach)

template0 jest bezpieczna, o tyle, że nie da się do niej prosto podłączyć, więc nikt w niej nie namiesza.
baza template1 jest używana jako "podstawa" do tworzenia nowych baz. tzn. za każdym razem jak robisz: "create database xxx;" to tak naprawdę jest wykonywana kopia bazy template1.
daje to parę fajnych możliwości – np. zrobienie czegokolwiek w bazie template1 oznacza, że każda nowa baza będzie to miała automatycznie.
np. załadowane rozszerzenie, języki itd.
co jednak jeśli do template1 przez pomyłkę wrzuciliście jakieś zbędne dane? np. odtworzyliście do template1 zamiast do xxx jakąś bazę z dumpa?
ręczne kasowanie jest skomplikowane.
ideałem byłoby przywrócenie template1 do stanu początkowego.
da się to prosto zrobić.
w pierwszym kroku łączymy się psql'em do postgresa, na konto admina (zazwyczaj postgres, lub pgdba). ważne jest by połączyć się do bazy innej niż template1.
będąc tak połączonym wykonujemy 4 proste kroki:

  1. update pg_database set datistemplate = false where datname = ‘template1';
  2. drop DATABASE template1;
  3. CREATE DATABASE template1 with template template0;
  4. update pg_database set datistemplate = true where datname = ‘template1';

krok 1 jest niezbędny gdyż baza z wartością "datistemplate = true" nie może być skasowana. więc zaznaczamy, że template1 nie jest szablonem 🙂
krok 2 – kasujemy bazę template1. tu dwie ważne uwagi:

  1. w czasie wykonywania drop database do dropowaniej bazy nie może być żadnych połączeń. właśnie dlatego musieliśmy się psql'em podpiąć do innej bazy.
  2. między drop database template1, a create database template1 nie da sie stworzyć innych baz (a dokłaniej, nie jest to tak proste jak zazwyczaj)

krok 3 – odtwarzamy bazę template1, korzystając z szablonu template0
krok 4 – zaznaczamy template1 jako szablon.
i już to wszystko.

tu informacja dodatkowo. może to wykryliście z powyższego przykładu, ale jak nie, to piszę:
w podobny sposób można zrobić *szybką* kopię całej bazy.
np. jeśli potrzebujecie backup przed odpaleniem na bazie jakichś skomplikowanych rzeczy, można:

create database xxx_backup with template xxx;

oczywiście do tego przydałoby się też ‘encoding qqq owner yyy', ale to już szczegół.
olbrzymim plusem tej metody jest szybkość. przy czym nie szybkość tworzenia kopii. to czasem jest dłuższe niż pg_dump. to co jest istotne, to fakt iż "przywrócenie" bazy danych z takiej kopii, to proste:

drop database xxx;
alter database xxx_backup rename to xxx;

największym minusem jest fakt iż w czasie kopiowania do bazy źródłowej nie może być żadnych połączeń. czyli nie można tak skopiować bazy używanej produkcyjnie.
to spora wada. tym niemniej w środowiskach testowych/developerskich stosuję ją często z wyśmienitym skutkiem.