Mimo braków gotówki, postanowiłem, przy okazji kumulacji zagrać w totka. Jeśli wygram - solennie obiecuję wesprzeć Joggera :)

Origami inspirowane Half Life 2:

Zagadka: co to jest? ;)

Do zapamiętania: pusta linia na końcu xorg.conf to coś co znacząco redukuje frustrację ;) Chyba napiszę patcha do xorga ;)

Dzięki Piterowi cierpię na lekki syndrom dnia następnego. I wiecie co jest na to najlepsze? Cziptuny :)

Patrząc dziś na w miarę zwykłego, Linuksowego desktopa, widać spore zatrzęsienie maszyn wirtualnych. Jest Perl, Python, Java, Mono, Flash, Ruby, PHP... jeśli coś pominąłem to nawet dobrze.

Zaletą Open Source jest różnorodność, ale nie przesadzajmy. Wymieniłem kilka maszyn wirtualnych. Normalny użytkownik w jednym momencie ma w użyciu powiedzmy dwie, trzy. Mnie się zdarza mieć wszystkie (wymienione). Oznacza to, że potrzebuję mieć w pamięci biblioteki, dynamiczne rekompilatory i inne takie dziwne narzędzia od sześciu różnych maszyn wirtualnych przez co okazuje się że 2GB pamięci to wcale nie jest dużo.

To czego potrzeba, to Uniwersalna Maszyna Wirtualna, zdolna do uruchomienia wszystkiego co nam się zamarzy. Robi się kroki w tym kierunku: pod JVM mamy JPythona, pod CLR mamy całkiem sporo języków (ale zasadniczo muszą być 'koncesjonowane'), Parrot (VM dla Perla 6) obsługuje już naprawdę wiele języków. To czego brakuje, to złożenia tego wszystkiego do kupy, najlepiej w formie eksperymentalnej dystrybucji Linuksa. To napewno nie będzie działać od razu idealnie, ale myślę że potencjalne zyski są tego warte, bo jak widzę że zjada mi kolejne 100MB pamięci na jakąś pierdółkę to krew mnie powoli zalewa. Zapewne nie będzie to proste, stworzyć VM idealnie nadającą się do wszystkiego. Nic nie szkodzi jednak spróbować.

Nie jestem specjalistą od VM, ale wielkie nadzieje pokładam w Parrocie. Projekt ciekawy, zobaczymy co z tego wyniknie.

Załóżmy następujący problem: jesteśmy integratorem rozwiązań (czyli nie jesteśmy autorem bazy i oprogramowania które jej używa - nie mamy kodu źródłowego a musimy pewne funkcjonalności dorobić). Mamy tabele A, B i C. Musimy stworzyć trigger wykonujący pewne operacje (w przypadku dodania wierszy) na A i B w zależności od C. Powiązania pomiędzy tabelami mamy takie jeden do wielu z A do B i jeden do wielu z B do C. Schemat taki, w realnym świecie, często jest używany do modelowania dokumentów, czyli A to wiersz nagłówka dokumentu, B to wiersze dokumentu, C to jakieś dodatkowe dane.

Problem polega na tym, że taki trigger jest zasadniczo niewykonalny, szczególnie w sytuacji gdy wpisy w C odnośnie B mogą, ale nie muszą istnieć. W realnym świecie: do systemu dodawany jest dokument (A), a trigger w zależności od C, musi zmodyfikować wiersze dokumentu (B).

Rozwiązaniem takiego problemu, mogłyby być triggrery transakcji. Rozwiązanie które wpadło mi do głowy pod prysznicem, a po którego po krótkim goglowaniu nigdzie nie znalazłem.

Założeniem całego rozwiązania jest to, że dokument jest dodawany w transakcji. Robi tak chyba każdy rozsądny system, tak więc jest to jak najbardziej rozsądne założenie. Trigger transakcji, byłby to rodzaj triggera wykonujący się po zakończeniu transakcji, Oczywiście, aby sprawa miała sens, musimy dodać jeszcze parę sprawa:

• Transakcja musi być identyfikowalna, np. poprzez nazwę, przykładowa składnia: BEGIN TRANSACTION DodanieDokumentu
• Dla ułatwienia życia, powinna być wcześnie zadeklarowana w systemie (zwykła rejestracja używanej nazwy transakcji).
• Trigger transakcji musi być jej częścią, z możliwością wywołania rollbacka lub commita.

To chyba wszystko co niezbędne, cała reszta to już lukier. Czyli:

1. powinna istnieć dodawania triggera na BEFORE i AFTER transakcji
2. przy triggerze AFTER, powinna być możliwość dodawania triggrea ON COMMIT, ON ROLLBACK, z możliwośćią zmiany stanu końcowego transakcji (czyli, transakcja chce się rollbackować, ale my ja commitujemy)
3. powinna istnieć możliwość przekazywania informacji z transakcji do triggera, np. trigger powinien widzieć stworzone w transakcji zmienne i/lub tabele tymczasowe

W praktyce, mogłoby to wyglądać następująco: oryginalny developer definiuje transakcje, i dokumentuje (dla integratorów) że transakcja tworzy tabele tymczasową w której przekazuje wszystkie niezbędne IDki. Integrator w swoim triggerze może wykorzystać tę tabelę i dokonać zmian w momencie gdy wszystkie niezbędne operacje dotyczące dokumentu są już wykonane.

Jeśli ktoś widział tego typu rozwiązanie gdziekolwiek, będzie supr jak się tym podzieli :)

P.S. Oczywiście sens to ma największy kiedy mamy zagnieżdżone transakcje, ale bez zagnieżdżonych też.

Kuchnia litewska reprezentowana przez:

1. Chłodnik
2. Cepe-bliny (usmażone ciasto na Ceppeliny, które nie chciały się lepić, z nadzieniem na wierzchu)
3. Sałatkę żmudzką
4. Sękacz
5. bliżej niesprecyzowany, acz markowy, alkohol (nazw nie pamiętam niestety)

Zalety:

1. Zero kaca na następny dzień
2. Pierdy płoszące współpracowników (to głównie ta sałatka żmudzka)

P.S. Pozdrowienia dla wszystkich uczestników biesiady, a szczególne dla gospodarzy.

...GUI. Zachciało mnie się skonfigurować sobie ciemną skórkę w Gnome. Wszystko ładnie, niestety - większość programów jest jednak tworzona z myślą o jasnych GUI, że o stronach internetowych nie wspomnę. Choćby ta ;). Ogólnie, większość aplikacji adaptuje się to skórki, ale np. Thunderbird ma problem, Azureus ma problem... I cały misterny plan...