Archiwalia dla 03.2005

Sprawny host w pigułce

opublikowano - on 30. mar 2005 in varia. 15 « komentarze

Wielu początkujących administratorów przeczesuje zasoby sieci w poszukiwaniu stron z opisami poprawnej konfiguracji serwerów usług bądź w poszukiwaniu znajomych taką wiedzę posiadających. Nauczony doświadczeniami płynącymi ze współpracy z jednym panem, postanowiłem opisać dokładnie proces konfiguracji idealnego środowiska produkcyjnego.

Na początek, jako że pierwszy odcinek kursu, nie bądźmy zbyt ambitni i zacznijmy od zwykłego serwera proxy.

Potrzebny będzie nam nosiciel (host) i dystrybucja linuksa. Linux jest najlepszym wyborem, bo jest bardzo modny i fajnie zasłynąć w światku znajomych swoimi pierwszymi doświadczeniami w tym kierunku. Oczywiście w domu lepiej mieć Windowsa, więc serwer produkcyjny nadaje się na poligon idealnie. Do naszych testów wybrałem skwapliwie najstabilniejsze środowisko produkcyjne. Musicie więc znaleźć gdzieś płytki zawierające Debian Unstable/Testing z archiwum pakietów z okolic sylwestra 2002. A może to był styczeń? Tuż po nowym roku wszystko się człowiekowi miesza.

Uzbrojeni w aparaturę i software przystępujemy do instalacji. Niektórzy znani mistrzowie techniki zen doradzają w tym momencie, aby na czuja zainstalować wszystko. Od przybytku głowa nie boli. Ja pozwolę sobie ograniczyć się do pakietów squida, mini-httpd i iptables. Reszta pociągnie się po zależnościach. Byle nie za dużo, bo nasza precyzyjnie spartycjonowana maszyna ma na rootsystem przewidziane całe 10 giga przestrzeni (jako że posiadałem kiedyś Amigę 500, zapewniam że 10 giga to niewyobrażalnie dużo). Nie dzielimy dysku na partycje, bo właściwie to nie jest już trendy. I tak nikt nie będzie nam umiał wytłumaczyć jak przełączyć się na inny dysk pod midnightem (Alt + F1 nie działa). Nie zapominajmy też o pakiecie lm_sensors. Jako, że sensory są bardzo czułe, pakiet ten ma kluczową wartość na naszym serwerze proxy.

Gdy wszystko stoi, przystępujemy do konfiguracji squida. Zależy nam na przepustowości sieci, więc dla pewności cache’ujemy wszystko. Tak, koniecznie zaznaczamy flagę “ignoruj nagłówek Expires“, w praktyce nikt przecież go nie czyta. Katalog ze stronami tymczasowymi ustawiamy w katalogu /var/spool/squid na głównej partycji (mi też \var\spool\squid nie chciało działać). 10 giga to zapas na lata, przecież nikt nie widział takiej dużej strony. Proxy jest już gotowe, ale ale, zanim je włączymy, ustawiamy nasze błyszczące i nowe mini-httpd na wyświetlanie generowanych przez squida statystyk. W końcu nie poto trzymamy je w nieskończoność, żeby leżały odłogiem na dysku.

Po konfiguracji tej części przyjdzie nam najtrudniejsze, zabezpieczanie serwera. Jak mówi stare japońskie przysłowie, dobry serwer jest jak dobry ninja. Można go zabić jednym ciosem, ale pozostaje niewykrywalny. Kierując się tą maksymą ustawiamy domyślną politykę wszystkich potoków ruchu na accept, ale już w pierwszej regule odrzucamy prośby o ping kierowane na adres rozgłoszeniowy naszej podsieci (broadcast). Haha! To dopiero przebiegłość, nikt go nie znajdzie! Do tego dopisujemy kilka dodatkowych reguł z polityką accept dla podstawowych protokołów (czyli dla zwykłego pinga i traceroute - tego fajnego narzędzia do śledzenia kumpli z gadu-gadu). Dla zwiększonego bezpieczeństwa resztę pakietów przekierowujemy żywcel do sysloga z poziomem raportowania 4. Teraz nic nam nie umknie, żadna próba włamania nie pozostanie niezauważona. Tym bardziej, że w syslogu usuwamy wpis przesyłający logi iptables do pliku, przez co są bardziej widoczne niż kiedykolwiek, na żadnej konsoli się przed nimi nie ukryjesz! Toż ci dopiero majstersztyk!

Krokiem drugim powinno być zwiększenie niezawodności naszej sieci przez instalację bardzo popularnego narzędzia, jakim jest Nagios. Nie wiemy do końca, co on robi, ale fajnie wygląda na screenach i ma tam dużo ładnych ikon. Dziwne, bo po instalacji nie widać ikon, tylko jakieś śmieci na konsoli, że coś nieustawione niby. Bzdura. Aha, jednak. Zmieniamy adresy z przykładowej konfiguracji na dane osobe sąsiada, który parkuje nam pod domem (używa mało na topie Outlook Expressa, to niech się męczy ze spamem). Działa. Dalej nic nie rysuje na ekranie, ale screeny pewnie podrobione w Photoshopie, mniejsza o to. Podobno trzeba mieć jakiś serwer poczty tam do tego Nagiosa, więc instalujemy szybko NullMailer. Do tego jakiś szybki soft do rozsyłkim np. exim3 w trybie bezdemonowym (bo nie chcemy duchów na serwerze było nie było publicznym, mogą wystraszyć potencjalnych użytkowników). Demona nie ma, więc i konfigurować pewnie nie trzeba. Odpalamy i zapominamy.

Powiadomienia nie przychodzą, więc wszystko jest w porządku. Spokojnie pracujemy dalej. Zależy nam na niezawodności systemu, więc co kilka tygodni uruchamiamy apt-get upgrade w poszukiwaniu krytycznych poprawek. Zależy nam również na przepustowości łącza, więc unikamy stosowania apt-get update, które generuje tylko zbędny ruch, a przecież wszystko mamy na płytkach. Ignorujemy też maile od klientów, ze względów bezpieczeństwa. W końcu pod wiadomością podpisać może się każdy, nie możemy ufać każdemu. Kontakt z klientami nawiązujemy dopiero w momencie, kiedy szef danej firmy zadzwoni do nas osobiście, to pozwala dokładnie potwierdzić tożsamość rozmówcy i jego dobre intencje.

Gdy po kilku miesiącach pracy klienci zaczynają spamować naszą prywatną skrzynkę do tego stopnia, że spamassassin pochłania sporą część czasu procesora, bierzemy ich metodą na przetrzymanie. Na dwa dni znikamy bez słowa, śmiejąc się w duchu z ich dziecięcej bezradności.

Po powrocie do pracy ze zdumieniem dostrzegamy, że szef w międzyczasie zatrudnił nowego administratora, który wraz z programistą próbuje dojść, jakim cudem statystyki dysków na systemie squidowym pokazują 100% wykorzystania miejsca. Wkrótce dochodzą do tego, że Nagios nie miał prawa wykonywania binarki /bin/ping, wskutek czego wygenerował słuszną liczbę 110 tysięcy powiadomień o martwych hostach. Niestety, z powodu błędnej konfiguracji exima, połowa z tych maili nie dotarła do jednego z adresatów (powiadomienia dostawał szef firmy, ale nie administrator). Może to i dobrze, bo każdy wysłany pomyślnie mail generował kilkadziesiąt stron zrzutu stosu TCP/IP w logu podstawowym, który wkrótce (mimo codziennej rotacji) przepełnił 10-gigowy dysk (nie do zapełnienia). Nie wspomnę, jaki jest komfort pracy na konsoli, przez którą przewija się bez przerwy ramka za ramką cały ruch TCP i UDP wychodzący z maszyny.

Na dziś to tyle, do zobaczenia w kolejnym odcinku, gdzie nauczymy się równie pożytecznych i przydatnych umiejętności.

Kulinaria

opublikowano - on 29. mar 2005 in varia. 8 « komentarze

Jako, że dziś od powrotu do domu robię za helpdesk do spraw Visual C++ (brr) i MFC (brrr), miałem okazję przemyśleć to i owo i zweryfikować swój pogląd na kolejne generacje języków programowania. Wiem już, czemu C/C++ pozostają moimi ulubionymi językami, mimo istnienia takich cudów techniki, jak Java. A oto i prawda objawiona:

Można pójść do wspaniałej restauracji, takiej ze wspaniałą obsługą, rewelacyjną kuchnią, idealnie skomponowanym menu i najeść się do syta. Ale o ile przyjemniej samemu ugotować coś zjadliwego? Wiedzieć, co jest w środku, czerpać przyjemność z samego procesu twórczego, nawet jeśli efekt końcowy nie wygląda jak na zdjęciach z McDonalda. C/C++ to rodzina języków, które cieszą samym faktem, że program w ogóle działa (a przynajmniej się kompiluje). :>

Strip #007: Wielkanoc

opublikowano - on 26. mar 2005 in comic. 7 « komentarze

Święta są do niczego. Przygotowania do świąt to tylko pretekst do zmuszania biednych informatyków do sprzątania czegoś, co jest zdecydowanie uporządkowane i takim powinno pozostać.

Tutaj w graficznych przeglądarkach wyświetla się komiks

e-siedemnastka

opublikowano - on 25. mar 2005 in linux. 4 « komentarze

Pisząc o Luminocity przypomniałem sobie o nie tak dawnych eksperymentach z innym oprogramowaniem dla dotkniętych problemem młodzieńczego trądziku. Chodzi mi o Enlightenment w swojej siedemnastej odsłonie.

Siedemnastka zawiera przepisany od zera manager okien, nowy zestaw widgetów (lub kontrolek, jak kto woli), własny moduł logowania i to, co fani Enlightenment zawsze sobie chwalili - maksymalnie zoptymalizowany kod. Środowisko nie ma jeszcze pełnej funkcjonalności (choć przyznaję, że do testów używałem snapshotu sprzed miesiąca), za to powala setką małych, cieszących oko detali. Wszystko jest animowane, błyszczy, świeci, tylko śpiewu brak (ale od czego jest ikona XMMS w domyślnym ustawieniu docka).

O ile większość z efektów można z punktu widzenia używalności pominąć, kilka rzeczy cieszy więcej niż oko. Przede wszystkim dostarczone przez autorów testy z setką latających po ekranie widgetów pokazały u mnie trochę ponad 160 klatek na sekundę. Wynik tyle oszałamiający co niemożliwy do uzyskania w żadnym z konkurencyjnych środowisk desktopowych (zaznaczam, że obiekty to między innymi antyaliasowane teksty, gradientowane boksy - w tym do przezroczystości, obrazki z kanałem alfa).

Drugi ciekawy pomysł, to rozwiązanie trybu edytora pulpitu jako przełącznika w menu kontekstowym. Po jego aktywacji możemy dowolnie skalować i przemieszczać składające się na nasz pulpit aplety (zegarki, wskaźniki, paski menu). Po dezaktywacji trybu edycyjnego, pulpit zostaje na powrót zamrożony i nie grozi nam przypadkowe uszkodzenie tak pieczołowicie przygotowanej kompozycji.

Ja pozostanę przy Gnome, bo cenię sobie zintegrowane środowisko pracy, ale część z użytkowników lekkich pulpitów w rodzaju Xfce4 czy FWM może już dziś zacząć zastanawiać się nad przyszłą przesiadką ;).

Na koniec jeszcze obowiązkowy zestaw screenów pokazujących e17 w działaniu.

Luminocity

opublikowano - on 25. mar 2005 in linux. 5 « komentarze

Przeglądając wczoraj (dziś w nocy) stronę Design Fu Setha, który jest pierwszym źródłem informacji o wszystkich zmianach w UI Gnome, szukałem nowych informacji na temat projektu Sabayon. Zamiast tego znalazłem coś, co wbiło mnie w ziemię.

Projekt Luminocity, bo o nim mowa, to tymczasowy projekt przejściowy, utworzony na potrzeby testowania kodu przed merge’owaniem do bazy Metacity. Na udostępnionych przez Setha filmach widać wyraźnie dwie rzeczy: po pierwsze, programistom Gnome się nudzi (a efekty ich nudy powalają na kolana); po drugie, Metacity będzie mieć oficjalnego managera kompozycji (wsparcie dla kompozycji już znajduje się częściowo w kodzie Metacity, ale jest domyślnie zablokowane).

Czego by nie powiedzieć, widać wyraźnie, że Gnome, choć małymi kroczkami, zdecydowanie idzie w kierunku zwykłego użytkownika. Za jakiś czas skończy się era kojarzenia systemów uniksowych z pryszczatymi, zakompleksionymi nastolatkami.

Efekt gumowych okien jest zaiste przepiękny. Jak pisze Seth, prace nad kodem stanęły w miejscu i wszyscy bawią się nowym efektem. Podobne rozwiązania od dłuższego czasu znają szczęśliwi posiadacze Mac OS X (towarzyszą chociażby minimalizacji okien czy przełączaniu pulpitów).

Ważniejszy jednak jest zintegrowany pełny manager kompozycji. Po co? Nie tylko żeby dorównać Makowcom pod względem eyecandy. Przede wszystkim dla zwiększenia szybkości przełączania się pomiędzy aplikacjami. W tej chwili wszystko oparte jest o system dirty rectangles, przy przełączaniu okien odrysowane musi zostać wszystko, co było dotąd zasłonięte przez inne okno bądź znajdowało się poza bieżącym pulpitem. W przypadku używania managera kompozycji zintegrowanego z managerem okien, okna rysowane są tylko w przypadku zmiany ich zawartości. Przełączanie ich kolejności i widoczności nie wymaga odrysowania ich zawartości, bo stosowna bitmapa znajduje się już w banku rozszerzenia composite i jest gotowa do wyrzucenia bezpośrednio na ekran.

Problemem, jak zawsze, pozostaje wsparcie tej technologii przez producentów kart graficznych. O ile nVidia radzi sobie z tym bardzo sprawnie, to sterowniki firegl Ati pozostawiają wiele do życzenia. Jeśli tylko wykryją załadowane rozszerzenie composite, natychmiast wyłączają obsługę akceleracji. Alternatywą jest tu zestaw opensource’owych sterowników X11, z tym, że nie wspierają one akceleracji w chipach nowszych generacji. W tym, w Radeonach 9600 Pro/Mobility, a taki właśnie znajduje się w moim notebooku.

Coś dla fanów Firefoksa

opublikowano - on 24. mar 2005 in varia. 5 « komentarze

Pewnie spora część z was używa Sage jako czytnika RSS. Dziś zmusiłem się do chwili wysiłku intelektualnego i przygotowałem własny stylesheet, zgodny z designem strony Mozilli do tegoż programu. Będąc nieskromnym, wygląda wspaniale i czyta mi się to dużo wygodniej niż domyślne Sage’owe niebieskości. Proszę tylko o linkowanie do tej notki, a nie bezpośrednio do pliku/serwera, bo umiejscowienie pliku może się w najbliższej przyszłości zmienić.

Obowiązkowy screenshot Mozilla theme w użyciu.

Instrukcja instalacji: rozpakować gdzieś na dysk (do jednego katalogu), w opcjach Sage zaznaczyć use custom stylesheet i wybrać plik mozilla.css dostarczony w tarballu.

Administrator kontra konserwator

opublikowano - on 18. mar 2005 in linux oraz varia. 57 « komentarze

Każda duża firma, posiadająca jakikolwiek serwer lub większą liczbę komputerów, zatrudnia człowieka na stanowisku administratora. Kim właściwie jest taki administrator? W firmach używających oprogramowania Microsoft, jest to na ogół konserwator, odpowiednik szkolnego dozorcy, który wymienia przepalone żarówki i bezpieczniki. Tak samo firmowy konserwator, zjawia się zawsze kiedy padnie Windows i konieczna jest jego reanimacja lub - jeszcze lepiej - reinstalacja. Nikt nie wyobraża sobie pracy bez niego, bo przecież nie można przeszkolić całego personelu choćby z podstaw informatyki. Pani Jadzia zainstaluje trojana i roboty jest na dwa dni, a administrator sieci biega w pocie czoła od stanowiska do stanowiska. Nikt nie kwestionuje jego kompetencji ani niezbędności jego pracy.

Co jednak w przypadku firm hostujących serwery oparte na *niksach? Jak pisał kiedyś Krzak, praca administratora farmy linuksowej to na ogół kilka nieprzespanych nocy z rzędu, a potem kilka miesięcy spokoju i działań zachowawczych. Po rozpracowaniu podstaw systemu (konfiguracja niezbędnych usług, czytanie dokumentacji, rekonfiguracja, przeglądanie przykładów, rekonfiguracja - w tej kolejności), system jest właściwie bezobsługowy. Dopóki nie padnie któraś z macierzy dyskowych, nie włamie się ktoś na konto FTP pracownika, czy nie spłonie któryś z procesorów w skutek niedostatecznego chodzenia, nie dzieje się nic. Nie widać biegających ludzi, nie czuć potu, nikt nie chwali i nie wyraża uznania. Typowy pracownik o konfiguracji serwera ma takie pojęcię, że czynność ta wymaga kliknięcia kilku ikon w menu Start w odpowiedniej kolejności. Administratora właściwie nie widać, bo pracuje na ogół poza godzinami pracy reszty ekipy (ciężko wprowadzać jakiekolwiek zmiany w systemie, z którego aktualnie ktoś korzysta). Ludzie nie rozumieją, że jeśli administrator nie ma nic do roboty, to znaczy, że jest dobrym administratorem.

Tu pojawia się problem, pracodawca zaczyna się zastanawiać, po co mu człowiek na takim stanowisku, jeśli właściwie nic nie robi (nie widać, żeby robił)? Coraz więcej firm rezygnuje z usług najlepiej wyszkolonego fachowca na rzecz taniego outsourcingu (bo ileż może zarobić szesnastolatek nie wychodząc z domu) bądź całkowicie likwiduje rzeczone stanowisko. Smutne, ale prawdziwe. Sam padłem ofiarą takich zmian, kiedy mój poprzedni pracodawca postanowił przekwalifikować administratora sieci na programistę i maszynistkę w jednym. Administrator serwera jest również coraz częściej postrzegany jak wspomniany dozorca. Z drugiej jednak strony, czasem trudno się temu dziwić, w tej chwili żeby zostać administratorem sieci nie trzeba przedstawiać właściwie żadnych predyspozycji. Polska jest na takim etapie edukacji informatycznej, że wystarczy koszulka z napisem I luv l33nex żeby wzbudzić respekt i szacunek potencjalnego pracodawcy. Umiejętność wymienienia choćby dwóch offowych dystrybucji (poza Debianem, SuSe i Mandrake) tworzy z nas lokalnego guru.

Szukając pracy jako programista musiałem niejednokrotnie udowodnić swoje umiejętności. Każda rozmowa kwalifikacyjna (oczywiście po jej przejściu) była jedynie wstępem do kilugodzinnego egzaminu praktycznego. Administratora nikt nie sprawdza. Dlaczego? Raz, że pracodawca patrzy na każdego kandydata jak na dar z nieba i boi się, że nikt inny nie przyjdzie starać się o to stanowisko (a to za sprawą polskich stawek za pracę informatyków). Dwa, że nikt nie potrafi sprawdzić jego kompetencji. Jest bardzo niewiele firm specjalizujących się w pośrednictwie zatrudnienia na takie stanowiska a i korzystanie z ich usług jest w Polsce rzadkością.

Ja ze swojej strony przyzwyczaiłem się już do sytuacji, że mamy administratora sieci, który pracuje dorywczo na outsourcingu. Dorabia, bo w tych samych godzinach siedzi przy swoim biurku w innej firmie. Czasu ma proporcjonalnie do ilości miejsc pracy, czyli wszystko robi z łaski. Firmowy system śledzenia ticketów lubi wskazywać informacje typu zlecenie oczekuje 2 dni 7 godzin 12 minut, a na bieżąco realizowane są właściwie tylko pierdoły typu zmiana hasła czy blokada konta. Zlecenie jakiejkolwiek większej zmiany jest do tego stopnia bezcelowe, że mam nieoficjalne przyzwolenie na wstęp do serwerowni i dostęp do maszyn z poziomu konsoli. W efekcie o infrastrukturze informatycznej firmy wiem więcej od osoby za nią odpowiedzialnej. Nie mogę się naszemu adminowi dziwić, bo pewnie pracy ma sporo. Tłumaczy się brakiem dokumentacji.

Tylko że dokumentacja nie istnieje i nie zanosi się na jej powstanie. Chyba, że ja ją napiszę, bo radzę sobie bez niej jakoś. Admin, gdyby chciał to też by sobie poradził… chyba. Chyba, bo ciężko mi czasami wytłumaczyć fakt, że na prośbę o odpalenie któregoś chroota odpisuje mi pytaniem, na której partycji leżał ten chroot, jaki ma punkt montowania, czego wymaga i jak to włączyć. Ja mam w umowie napisane programista… i chyba będę trzymał się tej specjalności, bo słowo administrator zaczyna ostatnio nabierać silnie pejoratywnego nacechowania.

Strip #006: Papież to, papież tamto

opublikowano - on 17. mar 2005 in comic. 10 « komentarze

Coś dla wszystkich, którzy mają choć trochę poczucia humoru i choć odrobinę dość czytania o tym, że Karol Wojtyła zjadł ogórka na śniadanie. Przepraszam, za marną jakość grafiki, ale jestem programistą, a nie grafikiem.

Tutaj w graficznych przeglądarkach wyświetla się komiks

Strip #005: Dlaczego informatycy chodzą niewyspani

opublikowano - on 17. mar 2005 in comic. 13 « komentarze

Gdyby ktoś się zastanawiał, czemu chodzę z podkrążonymi oczami zamiast spać 8 godzin, jak człowiek…

Tutaj w graficznych przeglądarkach wyświetla się komiks

Dlaczego terminy są złe

opublikowano - on 4. mar 2005 in varia. 1 « komentarze

Niniejszy wpis jest owocem prac nad draftem specyfikacjy dla naszego systemu koordynacji projektu. Celowo nie mówię o zarządzaniu projektem, bo projekt nie powinien być zarządzany, tylko skutecznie realizowany. W skutecznym realizowaniu przeszkadzają między innymi właśnie narzucane z góry terminy wykonania, choć często sam nakład prac nie może być z góry znany. Stąd mój postulat:

Zadania dla zespołu nie powinny mieć przypisanych sztywnych terminów godzinowych na realizację. Dlaczego? Odpowiedź jest prosta – programiści, graficy, cały zespół odpowiedzialny za fizyczne wykonanie zadania nie lubi rozliczania godzinowego. System taki jest nieelastyczny i obniża morale ekipy zaangażowanej w realizację projektu. Prowadzi też często do frustracji z powodu braku możliwości wykonania pracy w założonym terminie (np. przez nawał innych, pilniejszych zleceń, niezwiązanych bezpośrednio z projektem, przez co nieuwzględnionych w grafiku projektu). Pracownik nie powinien się czuć winien z powodu niezależnych od niego opóźnień. Dostateczną motywacją do pracy powinien być deadline dla całego etapu, ustalony przez zbliżający się milestone.

Milestone (kamień milowy) to nazwa używana w odniesieniu do punktu zakończenia ważnego etapu w życiu projektu. Punktem takim może być moment wstępnej prezentacji draftów u klienta, moment zamknięcia specyfikacji technicznej (którego przekroczenie uniemożliwia wprowadzanie dalszych poprawek do założeń projektu), moment rozpoczęcia prac nad kodem, czy też finalny okres prób i końcowe wdrożenie projektu. W okresie pomiędzy kolejnymi kamieniami milowymi kolejność realizacji zadań jest właściwie obojętna. Najważniejsze jest bowiem zamknięcie wymaganej funkcjonalności na czas, klienta nie interesuje, czy prace nad jednym komponentem były zrealizowane przed pracami nad innym. Dlatego też uważam, że projekt nie powinien prowadzić sztywnego kalendarza prac (jak robi to phpCollab, gdzie każdemu zadaniu przypisujemy czas rozpoczęcia, szacowany nakład pracy i termin zakończenia). Zamiast tego powinien umożliwić stworzenie kilku kamieni milowych, a następnie pozwolić na wygodne przydzielenie zadań do milestone’ów. Niezrealizowane zadanie powinno mieć stan zadania blokującego, nie powinno dać się zamknąć etapu bez zamknięcia wszystkich zleceń przypisanych do danego okresu, bądź bez przesunięcia ich na jeden z dalszych kamieni. Taki system prac pozwala bardziej elastycznie zarządzać własnym czasem poszczególnym członkom zespołu, ewentualne zależności pomiędzy zadaniami przypisanymi do różnych osób powinny być rozwiązane na poziomie priorytetyzacji listy i podziału na niezależne etapy (np. w przypadku realizacji systemu CMS nie powinno się przystępować do programowania systemu przed zamknięciem prac nad grafiką i interfejsem użytkownika).

Z tych samych przyczyn jestem za całkowitą likwidacją procentowych pasków postępu prac nad zadaniem. Obecność takich wskaźników wywiera presję na pracowników. Członkowie zespołu myślą (często słusznie), że zbyt rzadkie uaktualnianie takich informacji będzie postrzegane jak nicnieróbstwo. Z kolei konieczność ciągłego wprowadzania danych o postępie zbędnie wydłuża czas potrzebny na realizację zlecenia. Zgrany zespół nie potrzebuje nadzorcy - galernika, który z batem w ręku wybija rytm pracy. Zespół powinien być rozliczany z zamkniętych etapów, a nie z godzin pracy spędzonych na poszczególnych elementach całości.

Co zatem, jeśli któreś zadanie okaże się trudne w realizacji (czasochłonne bądź niewykonalne)? System powinien umożliwić pozostawienie takiej informacji w postaci komentarza do zadania bądź jako notki widocznej dla całego zespołu na stronie podsumowującej. Mamy tu do czynienia z analogią do bloga, systemem opierającym wymianę informacji na notatkach i komentarzach. Dlaczego? Blogi są wygodne, intuicyjne, bajecznie proste w obsłudze i mają miliony użytkowników, czego nie można powiedzieć o wielkobiznesowych kombajnach do ucisku wykonawców projektu. Co więcej, udostępnienie tych samych notek (wybiórczo) klientowi nie będzie wymagało dalszej obróbki - dostanie do dyspozycji informacje tekstowe, łatwe do czytania, dające mu ogólne pojęcie o postępie, ale nie przytłaczające go rzędami cyfr i wykresów. Klient ma na ogół wiele ciekawszych spraw na głowie niż porównywanie zestawień pomiędzy wizytami na stronie projektu, nie do pominięcia jest też fakt, że informacja procedura zakupu domeny się przedłuża jest dalece więcej mówiąca niż fakt, że od dwóch tygodni proces realizacji utknął na poziomie 73%. Więcej grzechów nie pamiętam.