mmazur.7thguard.net

Jeśli do wysyłania maili z jakiś automatów używacie standardowego /usr/sbin/sendmail, to pamiętajcie, że domyślnie ten programik traktuje (prawie) pustą linię zawierającą tylko kropkę, jako sygnał, że właśnie skończyliśmy wpisywać treść maila. Przez kilka lat intensywnego używania automatyki builderowej pld nie zdarzyło się, żeby ten problem się objawił.

Aż do dziś. Także dobra rada na przyszłość -- nawet jak sądzicie, że wam to niepotrzebne, to przy wywoływaniu sendmaila używajcie opcji -i.

Czytałem sobie pocztę, by w pewnym momencie zauważyć, że kursor mi się nie rusza. Co jest? Oooo. Myszka zgasła. Klawiatura też nie działa. Pewnie się komp zwiesił. Hmm. Ale zegarek pika. Coooo jest. O, myszka się dymi.

Myszka się dymi!!!!!!!!!! Komputer wyłączać!

Poweroff mi zeżarł konfig do akregatora. Szczęście, że ixy mają wbudowaną emulację myszki, choć jest ona upierdliwa w użyciu i nie wiem jak zmniejszyć akcelerację. Mam nadzieję, że mi się nie sfajczył przy okazji port ps2, ale w sumie i tak chyba kupię mychę na usb.

Mam w domu laptopa, więc musiałem go jakoś podłączyć do internetu. Zrobiłem to na szybko i po kosztach (zakup laptopa mi kompletnie wyczyścił konto), czyli kupiłem dwie najtańsze karty wifi, po czym jedną wsadziłem do desktopa, a drugą do laptopa. Problem jest oczywisty -- żeby mieć sieć w laptopie, muszę mieć to głośne, żrące prąd monstrum (pięcioletni desktop) cały czas włączone, co jest generalnie średnim pomysłem (już nie wspominając o tym, że mój isp nie lubi, jak się podłącza więcej jak jeden komputer pod jeden kabel). Co zrobić? Ano kupić jakiś fajny router sprzętowy do którego będę mógł sobie podłączyć i desktop (fizycznie kablem) i laptop (via wifi), a który będzie mi robił ładnie maskaradę i w ogóle wszystko ślicznie pięknie. Padło na Linksysowy WRT54G ze względu na to, że to po prostu taki mini komputerek z linuksem na pokładzie, więc w razie czego będę mógł na tym praktycznie dowolne cuda wyprawiać. Niby wszystko fajnie, ale pojawił się jeden problem.

Otóż mój isp poza internetem daje dostęp 100mb do sporego lanu, z którego w miarę regularnie korzystam do wymiany różnych niemałych plików. Niestety wpięcie pomiędzy desktop a lan takiego małego routerka ze słabiutkim procesorem spowodowałoby co najmniej pięciokrotne obniżenie transferu. I teraz nie wiem, czy są może jakieś mocniejsze wersje takich routerów nie różniące się specjalnie cenowo, czy też mam się pogodzić z tym, że dostaję coś za coś.

Coś, co oryginalnie było komentarzem do tej notki, urosło do takich rozmiarów, że zostało osobnym wpisem.

Świątkiewicz pisze prozę sztywną, kpiącą (nie mylić z 'zabawną', co niektórzy potrafią i często choćby dlatego są czytani), hermetyczną i albo całkowicie domyka opisywane tematy, albo też jakikolwiek sensowny komentarz wymaga bycia w tej samej wąskiej przegródce, w której siedzi sam autor (wiem, bo sam co najmniej kilkukrotnie rezygnowałem z dodawania często już częściowo napisanego komentarza).

Gdybym miał tę prozę do czegokolwiek porównywać, zapewne byłaby to instrukcja obsługi. Czy przeczytana instrukcja obsługi skłania do refleksji? Czy mamy ochotę o niej porozmawiać z autorem (bądź innymi czytelnikami)? A nawet jeśli właśnie przeczytaliśmy instrukcję obsługi i mamy odnośnie niej uwagi, to czy to przez przypadek nie oznacza, że z jakiegoś dziwnego powodu znamy się na tym popularnym zajęciu, jakim jest pisanie instrukcji obsługi? (Abstrahuję od tego, że pisanie instrukcji jest zajęciem ważnym, szanowanym i wymaga nie lada umiejętności.)

Czytając instrukcję obsługi, czy jakiś inny podręcznik, mogę poznać kilka suchych faktów, z których spora część prędzej czy później mi z głowy wywietrzeje. Ludzie nie uczą się w ten sposób. Żeby się czegoś rzeczywiście nauczyć człowiek musi albo sam dojść do określonych wniosków na podstawie własnych doświadczeń i obserwacji, albo też przeczytane czyjeś wnioski odnieść do własnych doświadczeń. (Trzecia droga jest taka, że autor tekstu przedstawia całą sytuację na tyle dokładnie, że trudno się nie zgodzić z jego wnioskami. Oczywiście im temat bardziej skomplikowany, tym mniej wykonalny taki opis, bo nie da się w ten sposób przestawić obserwacji wynikających z wielu lat pracy zawodowej -- w takim wypadku czytelnicy muszą wierzyć autorowi na słowo, że wie co mówi.)

W praktyce oznacza to, że najlepsze warunki do nauki ma się wśród 'równych sobie'. Dobre uczelnie nie są dobre dlatego, że wielkie umysły tego świata potrafią przekazać młodym ludziom kompilację najlepszych odpowiedzi na najważniejsze pytania (w taki sposób, to się pisze encyklopedie). Dobre uczelnie dlatego są dobre, że potrafią popychać studentów w odpowiednim kierunku i zapewniają im odpowiednie warunki do wzajemnej stymulacji (grupa studentów ma opracować rozwiązanie problemu przy pomocy profesora, a nie po prostu zapamiętać rozwiązanie, jakie im podsunie profesor).

Jak to się ma do życia codziennego? Ano tak, że jeśli np. chcesz się nauczyć śpiewać, to najlepiej będzie, jeśli zainteresujesz się środowiskiem śpiewaków ogólnie pojętego mainstreamu, gdyż tam (teoretycznie) masz największe szanse na dyskusje z osobami, których doświadczenia będą podobne do twoich i którzy w związku z tym mogą przekazać ci porady, które będą miały dla ciebie dużą wartość. Natomiast niezbyt szczęśliwym pomysłem byłoby wybranie się na nauki np. do opery, gdyż opera to tylko niewielki margines ogólnie pojętego śpiewania.

Niezależnie od tego, jakie mniemanie o sobie samych mają śpiewacy operowi.

Przypomniałem sobie, co też chciałem napisać przed tygodniem. Miałem ten temat poruszyć już kilka miesięcy temu, ale obecna robota dostarczyła mi kolejnych przykładów, więc można powiedzieć, że rzecz sama za mną łazi i domaga się opisania.

Na potrzeby tego wpisu zdefiniuję system produkcyjny jako coś, co albo (a) musi działać cały czas, bo jak nie działa, to wtedy szef się na nas drze, albo (b) musi działać cały czas, bo jak nie działa cały czas, to później spędzamy dużo czasu na przywracaniu systemu do takiego stanu, jak gdyby przerwy w działaniu nie było (albo (c) -- obie te sytuacje na raz).

Niezależnie od tego jak dobrze zaprojektujemy swój system i jak czysty będzie nasz kod, niestety nigdy nie będziemy się w stanie uwolnić od pewnego przykrego skutku ubocznego źródła naszej kreatywności -- pomyłek. Jakkolwiek mózg ludzki jest zdolny do różnych cudownych rzeczy, to ceną za to jest brak precyzji. Prawidłowo działający komputer się nie myli -- robi dokładnie to, co ma w programie. A człowiek może trafić w klawisze w złej kolejności, zrobić jakąś dziwną literówkę, czy wręcz myśleć o jednej rzeczy, a napisać drugą. A te wredne buczące i piszczące maszyny nigdy nie przymykają oczu na nasze niedoskonałości. Ja przed commitowaniem zmian do systemów, których nie powinienem popsuć, staram się przejrzeć diffa i wyłapać różne dziwne błędy, ale skoro za pierwszym razem uznałem kod za poprawny, to nie mam żadnej gwarancji, że patrząc na niego drugi raz dostrzegę błąd. Co jak co, ale w tym momencie muszę przyznać, że pair programming wcale nie jest tak głupi, jak mogłoby się zdawać.

No dobra, skoro już wiemy, że robimy dziwne pomyłki, to co dalej? W przypadku jakiśtam programików możemy sobie pozwolić na testowanie na żywym systemie. W przypadku systemów produkcyjnych (definicja jak powyżej) też możemy sobie pozwolić na testowanie na żywym systemie, ale musimy być przygotowani na konsekwencje (czyli że im dłużej zajmie nam wykrycie i naprawienie błędu, tym głośniej szef będzie na nas wrzeszczał i tym dłużej będziemy nad tym siedzieli i przywracali wszystko do porządku). Generalnie rozwiązanie jest jedno -- należy testować zmiany przed ich wprowadzeniem.

Różnymi unit testami, test driven development i takimi tam się zajmował nie będę, bo się najzwyczajnie w świecie na tym wszystkim nie znam, mogę co najwyżej opisać własne wnioski z własnych doświadczeń. Po pierwsze, zanim zaczniemy pisać cokolwiek, warto się zastanowić, czy to, co robimy, jest systemem produkcyjnym (definicja jak powyżej :)? Jest? No to pisząc pierwsze linijki kodu musimy mieć kilka rzeczy na uwadze. Najważniejsza -- kodujmy tak, żeby jakimś prostym przełącznikiem być w stanie przełączyć program w tryb debugowania, czyli żeby o wynikach dokonanych operacji tylko informował (nas, czy też jakiś program testując), a nie utrwalał je w systemie. Możemy być pewni, że prędzej czy później będziemy chcieli sami poprzeglądać wyniki generowane po jakiś wprowadzonych przez nas zmianach, zanim owe wyniki cokolwiek nadpiszą/popsują.

Tutaj zwracam uwagę na błąd, który popełniłem dwa razy, ale którego raczej już nie popełnię -- jeśli w celu przetestowania jakiejś swojej zmiany, ręcznie wpisujesz testowe dane do systemu, to znaczy, że właśnie popełniasz dwa błędy. Pierwszy, to wpisywanie danych do owego działającego systemu. Nawet jeśli wiesz jak to zrobić tak, żeby przeprowadzając swój mały test nic nie popsuć, to (a) i tak ryzykujesz, że o czymś zapomniałeś i (b) masz sporą szansę, że ubezpieczająć tyłek tracisz czas, bądź redukujesz dokładność przeprowadzonego testu. Już na poziomie projektowania (jakiegokolwiek projektowania, choćby tylko w głowie) systemu powinieneś był wszystko tak przewidzieć, żeby mieć gdzieś w pełni funkcjonalną kopię systemu (kopia bazy danych, działający url do roboczej wersji kodu, etc.). Zapewne z biegiem czasu każdy w tej kwestii może wyrobić sobie własny warsztat (konwencja nazewnictwa, jakiś zbiór skryptów pozwalający automatycznie i bezbłędnie synchronizować system podstawowy i roboczy, etc.), więc jakiś dokładniejszych przykładów podawał nie będę, bo to już każdy musi zdać się na własną ocenę sytuacji.

Drugim błędem jest owo ręczne wpisywanie testowych danych. Nawet w przypadku niezbyt skomplikowanego systemu, jeśli podliczysz sobie ile czasu spędziłeś powiedzmy na ręcznym wymyślaniu i wpisywaniu jakiś komend sql, to w sumie rzecz biorąc sporo czasu zaoszczędziłbyś (a i system byłby znacznie lepiej przetestowany), gdybyś za każdym razem, gdy potrzebujesz testowych danych, pisał sobie prosty skrypt owe dane generujący. Tutaj wręcz bajecznie przydaje się znajomość języków pokroju pythona, gdzie siadasz, piszesz i za chwilę masz kawałek działającego kodu.

Idiotycznie mi ten tekst wyszedł jeśli chodzi o konstrukcję -- rozwinięcia tematu kulawe i brak pointy, ale przez ostatnie trzy dni się obijałem, a jutro mam deadline, także wybaczcie, że go nie poprawiam. I pewnie jeszcze o czymś zapomniałem, acz najwyżej dopiszę w komentarzach.

Tak nawiasem mówiąc, to ciekawym jaka będzie reakcja mojego pracodawcy, jak mu powiem, że jego gonienie mnie terminami zaskutkowało tym, że część systemu jest napisana w pythonie (fakt, że nie jest tego dużo, raptem kilkanaście kilobajtów kodu, ale jak to z pythonem bywa, bardzo 'treściwego' kodu :).

Tabelki, bordercolor, kolorowe tabelki, lalalalalala, align, valign, lalalalala, height, weidth, taaaabelki, kolorowe tabelki, lalalala, cellpadding, cellspacing, zagnieżdżone tabelki, tabelki, wszędzie tabelki, lalalalala, kolorowe tabelki, kolorowa zupa z tabelek, lalala...

Ładne?

Nie wiem ile tego w tej chwili łazi w mojej skórze i ile cm kanalików już wydrążyło, ale ilość jajeczek mogę oszacować na co najmniej kilkaset.

Ktoś chce? W sprzyjających okolicznościach powinien wystarczyć krótki kontakt skórny. Hodowla nie wymaga jakiś specjalnych predyspozycji, acz stworki lubią jak im ciepło (np. jak śpimy, albo się myjemy), co można stwierdzić ich wzmożoną aktywnością (co z kolei można stwierdzić swędzeniem miejsc rozgrzanych).

Gorzej będzie, jak się zechcemy hodowli pozbyć...

Nie lubię pracować. Wkurza mnie to. Jest tyle innych rzeczy, które wolałbym robić. PLD, zaniedbany przez honeja i przeze mnie 7thguard, tydzień temu wyszło 2.6.13, a ja jestem kompletnie w lesie z nagłówkami, mam tematy do pisania tutaj (w ogóle chcę sobie bloga in english też założyć), ale mi się już nie chce nawet pisać, poczytałbym sobie coś z poza mojej działki, coby dla odmiany poszerzyć horyzonty, ale szkoda mi czasu. A może w ogóle coś mniej komputerowego, a bardziej społecznego (w sensie, że skutki takiej roboty byłyby nie czysto techniczne, a raczej 'socjalne')? Na to, to już zupełnie nie mam czasu.

Na dodatek nie wykorzystałem okazji, żeby w miarę dokładnie sprawdzić jak dużo jestem w stanie pracować, żeby osiągnąć optimum (bo że nie jestem w stanie cały czas pracować, to już sprawdziłem).

Jedną rzecz zapiszę, bo w końcu zapomnę. Hmmm. Zapomniałem. Co to było........ :/ Zapomniałem. Napiszę, jak sobie przypomnę.

Miodowicz: "to nie miało nic wspólnego z kampanią wyborczą, to wszystko był PRZYPADEK!"

Obśmialiśmy się z matką jak fretki.