-ENOTTY

/exec został poprawiony prawie natychmiastowo. Deletek jest zajebistym koderem :)

Właśnie spędziłem ponad dwie godziny polując na pewien programik, który przyuważyłem w PLD Live. Małe to ustrojstwo znalazłem w menu z ustawieniami, w było to GUI do zmiany defaultowych ustawień GStreamera. Taka pierdółka w zasadzie -- trzy czy cztery okienka do wpisania domyślnych source'ów i sinków.
Googlując za różnymi kombinacjami słów ,,gstreamer'', ,,GNOME'', ,,setup'', ,,config'' czy też ,,gui'' nie znalazłem tego, co szukałem. Przeglądając zawartosæ przeróżnych pakietów również nie. W końcu czytając pliki .spec z jakiś dziwnych rpm'ów dostałem pierwszy trop - gstreamer-Gconf. Oczywiście trop zaprowadził do nikąd. Dzięki niemu jednak dopiąłem swego -- odpaliwszy Gconf-editor zlokalizowałem odpowiednią gałąź (system/gstreamer/0.8/) i dokonałem upragnionej zmiany ,,osssink'' na ,,alsasink''. GUI są dla mięczaków ;-)

---

Słyszałem przedwczoraj w radio wypowiedź jakieś maturzystki, że na razie kuje ona ostro, ale na dzień przed maturą da sobie spokój -- tak, żeby umysł mógł wypocząć. Przypomniał mi się od razu dzień mojej matury z polskiego. Czekając na egzamin, siedziałem ubrany w garnitur na ławeczce w parku, zaraz koło szkoły. Wiatr rozwiewał paręnaście zadrukowanych kartek formatu A4 spiętych zszywką, które starałem się w całości zapamiętać. Jakis przechodzień z uśmiechem zwrócił mi uwagę, że na naukę już za późno. Nie mógł wiedzieć, że z taką intensywnością na godzinę przed maturą z polskiego zgłębiałem tajniki OSPF, BGP i kilku innych protokołów dynamicznego routingu. :-]

---

Przy okazji właśnie chyba odkryłem, że mamy spieprzone polecenie /exec w EKG2.

Krem do golenia rozprowadzany po twarzy bez pędzla, najlepiej pieni się w miejscach, w których nie ma zarostu.

osoby otrzymujące stypendium socjalne powyżej 400 złotych będą skierowane w przyszłym roku do ds 5Ł i ds3.

Fajnie, tylko że jak lawina takich ruszy do DS3, to już pewnie nie starczy miejsca dla mnie. A mi się tu bardzo dobrze mieszka. Fuck.
Artykuł na szPieGu.

Laborka z Javy zaczęła się nietypowo. ,,Dzisiaj nie robicie trzeciego ćwiczenia -- powiedział prowadzący -- tylko kończycie drugie. Robicie taką aplikację, z takimi przyciskami, z tym i z tym i z tym i z tamtym. A, i macie tylko godzinę, bo muszę wcześniej wyjść.''
Tak więc w tempie ekspresowym zaczęliśmy pisac. Tzn. ja szybko stukałem w klawisze, a obok mnie Kuba z powodzeniem udawał Google, wertując książkę na wszystkie strony, podając mi parametry funkcji, nazwy klas i inne potrzebne rzeczy. Od czasu do czasu rzucał też pomysłami i podpowiadał fragmenty kodu. Dzięki niemu zdążyliśmy zaimplementować jedną funkcję z całej aplikacji - ,,Exit'' mianowicie ;-). Chyba byliśmy jedynymi, którym cokolwiek działało po zakończeniu zajęć.
Oczywiście JCreator nie działał, więc kompilować musieliśmy ręcznie (ach te tworzone w naprędce pliki .bat). Serwer po Sambie również nie chciał się zgłosić, więc musieliśmy użyć dyskietki. Windows 98 zawiesił się w momencie włożenia dyskietki do stacji. Same miłe rzeczy ;)
Ale abstrahując od tego wszystkiego - Extreme Programing daje efekty. I naprawdę fajnie się pisało. Brakowało jedynie jakieś szybkiej muzyki w tle.

CVS ssie jak ch*j. Osiem godzin temu zrobilem fajnego commita, 144 KiB mial. Tylko ni ch*ja nie widze go w CVSie ani w changelogu. Kur*a jego mac.

Zwłaszcza jak przeczyta się niemal rok z czyjegoś życia w trochę ponad godzinę. I przypomni niektóre wydarzenia. Tylko czasami nastraja to tak pesymistycznie trochę... Cóż, jedni są bardziej imprezowi, inni się w takim klimacie nijak odnaleźć nie mogą. Tylko czy swoje życie nie wydaje się czasami płaskie w porównaniu z przestrzennością żywota innych?
Pozdrowienia dla LCFa ;-)

Parę lat temu -- w 2000 roku o ile dobrze pamiętam -- jadąc samochodem z Torunia do Bydgoszczy ze znajomym informatykiem z firmy, w której w wakacje pracowałem, usłyszałem proste zdanie, które wbiło mi się w pamięć. ,,Wszystko w informatyce sprowadza się do baz danych.'' Zapamiętałem to zdanie, chociaż wtedy uważałem je za przejaw sympatii owego informatyka. Sam byłem zainteresowany wyłącznie sieciami (i do dzisiaj w dużej mierze jestem) -- przesyłanie danych na różne sposoby, przez różne tunele, IPSeci, filtry, dynamiczne routingi, enkapsulacje i inne dziwne wytwory przez wiele lat pobudzało moją wyobraźnię i zajmowało długie wieczory oraz noce.
Ostatnio jednak zacząłem coraz bardziej skłaniać się ku właśnie bazom danych. W PostgreSQLu na mojej workstacji trzymam coraz więcej rzeczy -- książkę adresową, przypisanie adresów IP do numerów pokojów w akademiku, stan mojej gotówki - ile w portfelu, ile ,,w ludziach'', ile na koncie, wszystkie transakcje których dokonuje, spis numerów indeksów wraz z nazwiskami posiadaczy, niedługo chyba będę indeksował pliki z mojego dysku.
Do wszystkiego mam wygodny dostęp poprzez odpowiednie SELECT i JOIN. I czuję, coraz mocniej z każdą chwilą, że przetwarzanie danych kręci mnie coraz bardziej. Niedługo IPSeci będę zestawiał tylko w celu zabezpieczenia połączenia z odległym silnikiem SQL.
Czemu o tym piszę? Otóż jedna z gazet, wykorzystując bazę danych swoich prenumeratorów, zrobiła całkiem miły trik. Każdy z nich otrzyma egzemplarz gazety z satelitarnym zdjęciem okolicy w której mieszka i swoim nazwiskiem wydrukowanym na okładce. I napisem ,,They Know Where You Are''. Ciężkie.

Dało się przyspieszyć bez uciekania się do mod_perla. Zamiast odpytywać bazę o każdą komórkę, zrobiłem jedno zapytanie wyciągające dane na cały tydzień do hasha, w pętli operując już tylko na hashu. Całość dostała kopa niesamowitego.
Cały czas mowa o tym Systemie Rezerwacji. Beware: ten link prowadzi nie bezpośrednio do systemu, ale do jego uproszczonej wersji. Wersja właściwa znajduje się na vhoście niedostępnym spoza naszej sieci akademickiej. Dlatego to, co można obejrzeć z internetu, pozbawione jest kilku arkuszy styli i możliwości wejścia głębiej - można zobaczyć tylko spis. Wystarcza to jednak do ocenienia liczbie zapytań do bazy, które teraz zastąpione są jednym.

---

Przykład optymalizacji zapytań SQL:

Problem jest taki: mamy w bazie kolejne pola. Problemem jest to, ze numeracja mimo, że sekwencyjna, jest nieciagla. Za zadanie mamy odnalezienie poprzedniego pola w stosunku do $DANE, przy czym nie ma byc on bardziej odległe niż 168 numerków do danego.

Pierwsze podejście

$akt_nr = $DANE-1;
do {
                $query = "SELECT pole FROM tabelka WHERE numer='$akt_nr'";
                $result = $dbh->prepare($query);
                $result->execute;
                $akt_gnr--;
} while (!(@row = $result->fetchrow) && $akt_nr > $DANE-168);

Zostanie wykonane maksymalnie 168 zapytań do bazy. Jest duża szansa, że przepytywanie skończy się szybciej, zawsze jednak będzie to conajmniej jedno zapytanie.

Drugie podejście - niech to zrobi za nas baza

Zamiast samemu przetwarzać otrzymane dane, właściwym podejściem jest zrzucenie jak największej ilości pracy na bazę danych. Musimy skonkretyzować nasze żądania:

$query = "SELECT pole FROM tabelka WHERE numer<$DANE AND numer>$DANE-168 ORDER BY numer DESC LIMIT 1;";
$result = $dbh->prepare($query);
$result->execute;
@row = $result->fetchrow;

I już! Czym różni się to zapytanie od poprzedniego? Po pierwsze, sprawdzanie warunku $akt_nr > $DANE-168 zastąpione zastało zawężeniem zakresu, z którego spodziewamy się wyników od bazy. Po drugie, życzymy sobie posortowania wyników wg. numeru, w kolejności malejącej (DESC). Dlaczego? Ponieważ wtedy pierwszym zwróconym wynikiem będzie ten o najwyższym numerze, za nim będzie o numerze mniejszym, potem jeszcze mniejszym itd. Ponieważ interesuje nas najpóźniejszy wpis -- który zostanie zwrócony jako pierwszy -- ograniczmy się tylko do pierwszego wyniku poprzez LIMIT 1. Pozostałe nie będą przepychane przez kanał komunikacyjny program<->baza. Po co nam one, skoro i tak mają iść od razu do śmieci?

Problem trzeci - ciąg danych

Tutaj zadanie jest takie: mamy do dyspozycji pewien zakres (od $BEG do $END) numerów, na których będziemy operować. Numery, choć dyskretne, są nieciągłe -- niektórych brakuje. Do przeprowadzenia mamy parę operacji na poszczególnych numerkach. Co robimy?
O każdy numer można pytać się w momencie, kiedy jest potrzebny:

pętla {
       [...]
       $query = "SELECT pole FROM tabelka WHERE numer=$potrzebny;";
       $result = $dbh->prepare($query);
       $result->execute;
       @row = $result->fetchrow;
       if (defined($row[0])) { zrob_cos_z($row[0])};
}

Takich zapytań będzie $END - $BEG, co czasem daje sporo odwołań do bazy. Kosztownych czasowo, zwłaszcza, gdy pobierane pole sklada się np. z numerka i jakieś małej literki.
Rozwiązaniem jest operowanie na większych porcjach danych pobieranych z bazy:

$query = "SELECT pole FROM tabelka WHERE numer>$BEG-1 AND numer<$END+1;
$result = $dbh->prepare($query);
$result->execute;
$hashref = $result->fetchall_hashref("numer");

pętla {
      [...]
      $nr = %$hashref->{$potrzebny}->{"costam"};
      if (defined($nr)) { zrob_cos_z($nr); };
};

W ten sposób do bazy odwołujemy się raz, a nie za każdym przebiegiem pętli. Wyniki otrzymujemy w hashu, można się do nich łatwo odwoływać przez poszukiwany numer. Minusem jest zwiększone wykorzystanie pamięci przez naszą aplikację, jednak przyrost szybkości prawie zawsze rekompensuje tą niedogodność.

Mając do wykonania większość ilość iteracji podobnych do tych w Przykładzie pierwszym powyżej, należy się zastanowić -- czy dla każdego wyszukiwania generować SELECT z odpowiednio zawężonym zakresem i LIMIT 1? A może lepiej pobrać cały interesujący nas przedział za jednym zapytaniem i używać pętli takiej jak w pierwszym kawałku kodu, zastępując jednak odpytywanie bazy -- odwołaniami do poszczególnych pozycji hasha.

Po parunastu dniach użerania się z mod_perl 1.99 i Apache2 stwierdzam:

• prostego skryptu nie da się uruchomić przez ModPerl::Registry - pliki nie dają się otworzyć w takiej konfiguracji. Pozostaje ModPerl::PerlRun, który wg. tego co piszą, jest o połowę wolniejszy.
• Persistent Connections z użyciem Apache::DBI to jakaś ściema - strona nadal generuje się minimum 1,5s.
• Zamiana ->prepare($SQL); na ->prepare_cached($SQL); nie daje mierzalnej poprawy wydajności.
• Eksperymenty z jednokrotnym ->prepare() i użyciem ->bind_param() dały przyspieszenie - ponieważ zapytania do bazy przestały cokolwiek zwracać, obróbka tychże danych była zdecydowanie szybsza.

Czuję się zawiedziony.