Katedra i bazar

Wielkość: px
Rozpocząć pokaz od strony:

Download "Katedra i bazar 11.04.2007."

Transkrypt

1 Katedra i bazar "Katedra i bazar" jest jednym z najważniejszych tekstów w historii Open Source. Choć jego autor, Eric S. Raymond, nie odgrywa już aktywnej roli w społeczności, trudno odmówić mu ogromnego wkładu w propagowanie idei otwartego kodu, zwłaszcza jako standardowego elementu infrastruktury biznesowej. Prezentowane poniżej tłumaczenie tekstu "Katedra i bazar" jest swego rodzaju historycznym dokumentem - dziś, po niemal 10 latach, możemy sami przekonać się, na ile tezy postawione przez autora okazały się prawdziwe. Będziemy wdzięczni za wszelkie komentarze, również te dotyczące poprawek i ulepszeń tłumaczenia. Miłej lektury! Linux jest wywrotowy. Kto by pomyślał nawet pięć lat temu (w 1991 roku), że z pracy rozproszonych po całym świecie programistów połączonych cienkimi przewodami Internetu i hakujących{1} w wolnych chwilach wyłoni się w niemal magiczny sposób światowej klasy system operacyjny? Na pewno nie ja. Kiedy Linux pojawił się na ekranie mojego radaru na początku 1993 roku, moje zaangażowanie w rozwój oprogramowania uniksowego i open source trwało już ponad dziesięć lat. Byłem jedną z osób pracujących nad projektem GNU{2} w połowie lat osiemdziesiątych. Udostępniłem w Internecie wiele programów open source, pracując samemu i z innymi nad rozwojem wielu programów używanych do dziś (takich jak nethack{3}, tryb VC i GUD dla Emacsa{4}, xlife i inne). Byłem przekonany, że wiem, jak to się robi. Linux wywrócił to przekonanie do góry nogami. Przez wiele lat głosiłem uniksową ewangelię małych narzędzi, szybkiego prototypowania i programowania ewolucyjnego. Wierzyłem jednak, że istnieje pewien punkt krytyczny złożoności, powyżej którego musi się zastosować bardziej scentralizowane podejście a priori. Uważałem, że najważniejsze programy (systemy operacyjne i narzędzia naprawdę sporych rozmiarów, takie jak edytor dla programistów, Emacs) powinny powstawać jak katedry: budowane zręcznymi palcami samotnych czarodziei lub grupy dostojnych magów pracujących w pełnym namaszczenia odosobnieniu, bez wersji beta udostępnianych przed czasem. Styl rozwoju oprogramowania zaproponowany przez Linusa Torvaldsa, "wypuszczaj nowe wersje wcześnie i często, bądź otwarty, wręcz bliski rozwiązłości", był dla nas sporą niespodzianką. Zamiast budować katedrę w pełnej skupienia ciszy, społeczność linuksowa przypominała jeden wielki hałaśliwy bazar, pełen różnych poglądów i planów (co doskonale reprezentują serwery z archiwami linuksowymi, przyjmujące programy od każdego), z którego, jak się wydawało, spójny i stabilny system mógłby wynurzyć się tylko cudem. Bardzo zaskoczył nas fakt, że ten bazarowy styl działał, i to działał dobrze. Kiedy nabrałem doświadczenia, nie tylko ciężko pracowałem nad pojedynczymi projektami, lecz również bardzo starałem się zrozumieć dlaczego linuksowy świat nie rozpadł się na kawałki w wielkim zamieszaniu, ale rośnie w siłę z prędkością niewyobrażalną dla budowniczych katedr. W połowie 1996 roku stwierdziłem, że zaczynam rozumieć. Przypadek dostarczył mi doskonałego sposobu na sprawdzenie mojej teorii: projektu open source, który mogłem rozwijać w bazarowym stylu. Rozpocząłem więc nad nim pracę, która zakończyła się jednoznacznym sukcesem. Na stronach tej książki opisuję historię tego projektu. Wykorzystałem ją by przedstawić kilka aforyzmów opisujących efektywny rozwój oprogramowania open source. Nie wszystkiego nauczyłem się w świecie linuksowym, jednak właśnie w nim niektóre sprawy nabrały szczególnej barwy. Jeśli mam rację, pomogą wam zrozumieć dlaczego społeczność linuksowa jest niewyczerpanym źródłem tak dobrego oprogramowania; być może sprawi też, że sami staniecie się bardziej twórczy. Poczta musi dojść Od 1993 roku zajmowałem się techniczną stroną obsługi wolnodostępnego ISP{1}, zwanego Chester County InterLink (CCIL) w West Chester w Pensylwanii. (Byłem jednym z założycieli CCIL i autorem jedynego w swoim rodzaju programu BBS dla wielu użytkowników, z którym można się zapoznać telnetując się do locke.ccil.org; dzisiaj obsługuje ono niemal trzy tysiące użytkowników na dziewiętnastu liniach). Dzięki tej pracy miałem zapewniony 24-godzinny dostęp do Internetu; w praktyce było to nie

2 tyle udogodnienie, co wymóg! Przyzwyczaiłem sie więc do natychmiastowego otrzymywania poczty elektronicznej. Z powodów zbyt złożonych, by je tutaj wymieniać, trudno było nawiązać połączenie SLIP{6} między moim komputerem w domu (snark.thyrsus.com) a CCIL. Kiedy mi się w końcu udało, ciągłe logowanie się do locke w celu odczytania poczty stało się denerwujące. Chciałem jedynie, żeby moja poczta znalazła się na snarku, o czym mógłbym być powiadamiany i pokierować nią dalej używając narzędzi znajdujących się na mojej maszynie. Zwykłe przekazywanie poczty przy użyciu sendmaila{7} nie wystarczało, ponieważ mój komputer nie zawsze jest widoczny w sieci i nie ma statycznego adresu IP{8}. Potrzebowałem programu, który połączyłby się z locke przez SLIP, pobrał pocztę i dostarczył ją do mojego komputera. Wiedziałem, że istnieją tego typu narzędzia i że większość z nich używała prostego protokołu zwanego POP (Post Office Protocol, protokół pocztowy). Oczywiście do systemu operacyjnego locke, BSD/OS, dołączono serwer POP3. Potrzebowałem klienta POP3. Zacząłem więc szukać w Internecie i znalazłem. Szczerze mówiąc znalazłem trzy czy cztery takie narzędzia. Przez pewien czas używałem pop-perl, jednak brakowało mu niezbędnej funkcji: zdolności podmiany adresów w taki sposób, by można było bez problemów odpowiadać na listy. Na czym polegał problem? Załóżmy, że otrzymałem list od użytkownika z locke o nazwie "joe". Pobierałem pocztę z locke, lecz kiedy próbowałem na nią odpowiedzieć, mój program pocztowy próbował radośnie przekazać ją nieistniejącemu "joe" na snarku. Ręczna edycja adresów na wkrótce stała się uciążliwa. Było to oczywiście coś, co komputer powinien robić za mnie, jednak żaden z istniejących klientów POP nie wiedział jak! W ten sposób doszliśmy do pierwszej lekcji: 1. Dobrej jakości praca nad programem rozpoczyna się od tego, że programista drapie się tam, gdzie go swędzi. Może się to wydawać oczywiste (w końcu istnieje stare przysłowie "potrzeba matką wynalazku"), jednak zbyt często programiści spędzają życie harując przy tworzeniu programów, których ani nie potrzebują, ani nie kochają. Natomiast w świecie linuksowym sprawy mają się inaczej, co może wyjaśniać dlaczego średnia jakość oprogramowania powstającego w społeczności linuksowej jest tak wysoka. Czyżbym powinien w świetle powyższego od razu rzucić się w wir pracy nad nowym klientem POP3, który skutecznie konkurowałby z istniejącymi? Nigdy w życiu! Uważnie zbadałem istniejące narzędzia POP, którymi dysponowałem, zadając sobie pytanie: "które z nich najbardziej odpowiada moim potrzebom"? Bowiem 2. Dobrzy programiści wiedzą co pisać. Wielcy wiedzą co przepisać (i powtórnie wykorzystać). I chociaż nie uważam się za wielkiego programistę, staram się takowych naśladować. Ważną cechą wielkich jest konstruktywne lenistwo. Wiedzą oni, że piątkę dostaje się nie za wysiłek, lecz za rezultat, zaś o wiele łatwiej jest zacząć od dobrego choć częściowego rozwiązania niż od zera. Weźmy Linusa Torvaldsa: nie próbował on napisać Linuksa od zera. Skorzystał natomiast z kodu i idei będących częścią Miniksa, miniaturowego systemu uniksowego dla procesorów 386{9}. W końcu całkowicie pozbyto się lub przepisano kod Miniksa, jednak dopóki to nie nastąpiło, był on kołyską dziecka, które później wyrosło na Linuksa. Mając to na uwadze zacząłem się rozglądać za istniejącym, dobrze napisanym narzędziem POP, które mógłbym wykorzystać za podstawę rozwoju swojego kodu. Uniksowa tradycja dzielenia się kodem zawsze była przychylna korzystaniu z kodu innych (dlatego właśnie Unix stał się podstawą projektu GNU, mimo poważnych zastrzeżeń w stosunku do samego systemu operacyjnego). Społeczność linuksowa przejęła tą tradycję i niemal dotarła do jej technologicznych granic: istnieją terabajty ogólnodostępnych aplikacji. Dlatego szukanie prawie-dobregoprogramu ma większe szanse zakończyć się sukcesem w świecie linuksowym niż gdziekolwiek indziej. Tak też było i w moim przypadku. Łącznie z programami, które znalazłem wcześniej, po drugim

3 poszukiwaniu miałem już dziewięciu kandydatów: fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail oraz upop. Najpierw zabrałem się za "fetchpop", napisanego przez Seung-Hong Oh. Dołączyłem do niego przepisywanie nagłówków swojego autorstwa oraz wiele innych ulepszeń, które autor zamieścił w wersji 1.9 programu. Jednak kilka tygodni później wpadł mi do ręki kod programu "popclient" Carla Harrisa i okazało się, że mam problem. Fetchpop, mimo kilku świetnych pomysłów (np. tryb demona), radził sobie jedynie z protokołem POP3 i był napisany w dość amatorski sposób (Seung-Hong był zdolnym lecz niedoświadczonym programistą i obie te cechy widać było w kodzie). Kod Carla był lepszy, jego program był solidnie i profesjonalnie napisany, jednak brakowało mu wielu istotnych i niełatwych do zaimplementowania funkcji fetchpopa (łącznie z tymi, które sam napisałem). Przesiąść się czy zostać? Przesiadając się pozbyłbym się kodu, który stworzyłem, za to uzyskałbym lepsze podstawy dla rozwoju kodu. Zdecydowałem się przesiąść z bardzo praktycznego powodu: popclient obsługiwał wiele protokołów. POP3 jest najpopularniejszym z protokołów wykorzystywanych w serwerach poczty elektronicznej, lecz bynajmniej nie jedynym. Zarówno fetchpop jak i pozostali konkurenci popclienta nie obsługiwały takich protokołów jak POP2, RPOP czy APOP, a już wtedy świtało mi w głowie, by dla zabawy dodać obsługę IMAP (Internet Message Access Protocol, niedawno zaprojektowany i najpotężniejszy protokół pocztowy). Miałem jednak również bardziej teoretyczne powody by myśleć, że taka przesiadka nie będzie zła; chodzi mianowicie coś, czego nauczyłem się na długo przed powstaniem Linuksa. 3. "Pomyśl o tym, by się go pozbyć; i tak to zrobisz" (Fred Brooks, The Mythical Man-Month, Rozdział 11. W Polsce książka ta została wydana przez WNT pod tytułem "Mityczny osobomiesiąc. Eseje o inżynierii oprogramowania"). Innymi słowy: często dzieje się tak, że nie rozumie się problemu do chwili, kiedy po raz pierwszy zaimplementuje się jego rozwiązanie. Natomiast za drugim razem być może rozumie się go na tyle, by zrobić to dobrze. Jeśli więc chce się zrobić to dobrze, należy być przygotowanym na rozpoczęcie prac od samego początku, przynajmniej raz. Pomyślałem sobie -- cóż, zmiany wprowadzone w fetchpopie były moją pierwszą próbą. Przesiadłem się więc. Po wysłaniu Carlowi Harrisowi pierwszego zbioru łat do popclienta okazało się, że autor praktycznie przestał się interesować swoim programem. Kod był nieco zakurzony, z niektórych miejsc wychodziły pluskwy. Chciałem wprowadzić wiele zmian, więc szybko doszliśmy do wniosku, że naturalną koleją rzeczy będzie przejęcie przeze mnie opieki nad programem. Niezauważalnie projekt rozwinął się. Nie byłem już osobą zastanawiającą się nad wprowadzeniem niewielkich zmian do istniejącego klienta POP. Stałem się opiekunem całego projektu i czułem, że pączkujące w mojej głowie pomysły prawdopodobnie zapoczątkują znaczące zmiany. Tak właśnie ewoluuje projekt w kulturze, która zachęca do dzielenia się kodem źródłowym. Postępowałem wedle następującej zasady: 4. Jeśli masz odpowiednie nastawienie, spotkają cię interesujące problemy. Jednak ważniejsza była postawa Carla Harrisa. Zrozumiał on bowiem, że 5. Kiedy tracisz zainteresowanie programem, twoim ostatnim obowiązkiem jest przekazać go kompetentnemu następcy. Nie było nawet potrzeby dyskusji; Carl i ja zdawaliśmy sobie sprawę z tego, że naszym wspólnym celem jest znalezienie najlepszego rozwiązania. Pozostawało jedynie wyjaśnić, czy projekt będzie bezpieczny w moich rękach. Kiedy udowodniłem że tak, Carl szybko i z wdziękiem przekazał mi prowadzenie projektu. Mam nadzieje, że postąpię tak samo, kiedy przyjdzie moja kolej. Jak ważni są użytkownicy W ten sposób odziedziczyłem popclienta. Co jest równie ważne, odziedziczyłem też użytkowników tego

4 programu. Użytkownicy są czymś wspaniałym, nie tylko dlatego, że pokazują, iż służycie im w potrzebie, że zrobiliście coś dobrego. Jeśli się ich odpowiednio urobi, mogą pomóc w rozwoju projektu. Kolejną zaletą tradycji uniksowej, która w Linuksie osiągnęła swoje szczęśliwe ekstremum jest fakt, że wielu użytkowników jest również hakerami. Ponieważ kod źródłowy jest dostępny, mogą być skutecznymi hakerami, dzięki czemu okres odpluskwiania może ulec znacznemu skróceniu. Wystarczy ich nieco zachęcić, a będą badać przyczyny problemów, sugerować możliwe rozwiązania oraz pomagać w rozwoju kodu o wiele szybciej, niż nastąpiłoby to bez ich pomocy. 6. Najkrótszą i najłatwiejszą drogą w kierunku szybkiego rozwoju kodu i efektywnego jego odpluskwiania jest traktowanie użytkowników jako osób uczestniczących w projekcie. Nietrudno zlekceważyć prawdziwość tego stwierdzenia. Chyba my wszyscy, żyjący w świecie open source, nie potrafiliśmy docenić jak dobrze projekt może się rozwijać wraz z liczbą użytkowników i wbrew rosnącej złożoności systemu; dopiero Linus Torvalds otworzył nam na to oczy. W mojej opinii najzmyślniejszą i najbardziej konsekwentną sztuczką Linusa nie było stworzenie jądra Linuksa, lecz wynalezienie modelu rozwoju tego systemu. Kiedy pewnego razy wyraziłem tę opinię w jego obecności, uśmiechnął się i cicho powiedział to, co zwykł często powtarzać: "W rzeczywistości jestem bardzo leniwą osobą, która lubi, by przypisywano jej to, co robią inni". Leniwy jak lis. Lub, jak to określił Robert Heinlen opisując jedną ze stworzonych przez siebie postaci, "zbyt leniwy by zawieść". Patrząc wstecz można zauważyć pewien precedens dla metod i sukcesu Linuksa w rozwoju biblioteki języka GNU Emacs Lisp oraz w archiwach z programami w Lispie. W przeciwieństwie do jądra Emacsa napisanego w C oraz innych narzędzi GNU, które tworzono w stylu przypominającym budowę katedry, ewolucja zbioru kodu Lispa była bardziej płynna i kierowana przez samych użytkowników. Pomysły i prototypy były często przepisywane trzy czy cztery razy, zanim przybrały ostateczną, stabilną formę. Nierzadkim zjawiskiem była luźna współpraca a` la Linux, którą umożliwił Internet. Moim pierwszym najbardziej udanym hackiem przed fetchmailem był prawdopodobnie tryb kontroli wersji w Emacsie, Emacs VC. Powstał on dzięki współpracy z trzema innymi osobami, z których do dziś poznałem tylko jedną (Richarda Stallmana, autora Emacsa i założyciela Free Software Foundation). Był to interfejs do takich programów jak SCCS, RCS, a później również CVS{10}, dzięki któremu można było dokonywać operacji związanych z kontrolą wersji przy pomocy skrótów klawiszowych. Kod ten rozwiną się z niewielkiego, topornego trybu sccs.el, który napisał ktoś inny. Udało nam się napisać VC dlatego, że w przeciwieństwie do samego Emacsa, kod Emacs Lisp mógł bardzo szybko przejść przez fazy "udostępnienia wersji", "testów" i "ulepszeń". Jednym z elementów polityki FSF były próby prawnego związania kodu z GPL. Niespodziewanie okazało się, że przez to trudniej jest korzystać z bazarowego trybu rozwoju, ponieważ FSF wymaga przepisania praw autorskich w przypadku dostarczenia kodu przekraczającego dwadzieścia linii, aby nie można go było zakwestionować z punktu widzenia prawa autorskiego. Dla ludzi korzystających z licencji BSD i MIT X Consortium problem ten nie istnieje: nie próbują oni zastrzec praw, które ktoś mógłby kiedyś zakwestionować{11}. Udostępniaj nowe wersje wcześnie i często Wczesne i częste udostępnianie nowych wersji jest kluczowym fragmentem linuksowego modelu rozwoju. Wielu programistów (w tym i ja) wierzyło, że tego typu praktyki gorzej się sprawdzają w wielkich niż małych projektach, ponieważ wczesne wersje są niemal z definicji zapluskwione, a nie jest naszą intencją nadwerężanie cierpliwości użytkowników. Przekonanie to wzmacniało zaangażowanie w styl rozwoju przypominający budowę katedry. Jeśli głównym celem jest troska o jak najmniejszą ilość błędów, nowe wersje udostępnia się nie częściej niż raz na pół roku, pracując w międzyczasie jak wół nad odpluskwianiem programu. W ten sposób powstało jądro Emacsa napisane w języku C. Inaczej było z biblioteką Lispa, ponieważ istniały archiwa z kodem w tym języku poza kontrolą FSF, gdzie można było znaleźć nowe i rozwojowe wersje kodu, niezależnie od cyklu udostępniania nowych wersji Emacsa. Najważniejszym z nich było archiwum elispa stanu Ohio, w którym można było znaleźć zalążek atmosfery oraz wiele cech dzisiejszych, ogromnych archiwów linuksowych. Jednak niewielu z nas zastanawiało się zbytnio nad tym, co robiliśmy, ani nad problemami wypływającymi z modelu rozwoju przyjętego przez FSF, których istnienie sugerowała sama obecność tego archiwum. W okolicach 1992 roku podjąłem poważniejszą próbę formalnego włączenia sporej części kodu do oficjalnej biblioteki Emacs Lispa.

5 Napotkałem na problemy natury politycznej i w większości mi się nie udało. Jednakże rok później, kiedy Linux stawał się coraz bardziej widoczny, stało się jasne, że wokół niego dzieje się coś innego i zdrowszego. Otwarta polityka rozwoju, którą przyjął Linus, stała w jaskrawej opozycji do budowania katedr. Archiwa sunsite i tsx-11 rozkwitały, powstawały nowe dystrybucje. Wszystko to spowodowała niespotykana częstotliwość, z jaką ukazywały się nowe wersje jądra systemu. Linus traktował swoich użytkowników jako osoby uczestniczące w projekcie w najbardziej skuteczny sposób: 7. Udostępniaj nowe wersje wcześnie i często. I słuchaj swoich klientów. Innowacja Linusa polegała nie tyle na prowadzeniu projektu w ten sposób (tego typu model istniał w tradycji uniksowej na długo wcześniej), co na ekspansji do poziomu intensywności odpowiadającej złożoności projektu, który rozwijał. W tych wczesnych latach (okolice roku 1991) zdarzało mu się wypuszczać nowe wersje jądra częściej niż raz dziennie! Ten model sprawował się dobrze, ponieważ Linus rozwijał bazę programistów i bardziej niż ktokolwiek inny wykorzystywał Internet jako narzędzie ułatwiające współpracę. Na czym polegał mechanizm tego typu współpracy? Czy było to coś, co mógłbym wykorzystać, czy raczej miało związek z niepowtarzalnym geniuszem Linusa Torvaldsa? Wydawało mi się, że nie. To prawda, Linus jest całkiem niezłym hakerem (ilu z nas dałoby radę zaprojektować kompletne jądro systemu operacyjnego nadające się do pracy?). Linux nie przedstawiał jednak żadnego zadziwiającego skoku koncepcyjnego. Linus nie jest (przynajmniej na razie) geniuszem innowacji tak jak, dajmy na to, Richard Stallman czy James Gosling (od NeWS i Javy). Uważam natomiast Linusa za geniusza jeśli chodzi o tworzenie oprogramowania, posiadającego szósty zmysł pomagający unikać błędów i ślepych zaułków, oraz prawdziwy talent w znajdowaniu wymagającej minimum wysiłku ścieżki z punktu A do punktu B. Cały projekt Linuksa wręcz oddycha tą właściwością i odzwierciedla podejście Linusa, które jest w istocie konserwatywne i opiera się na upraszczaniu projektu. Jeśli więc częste udostępnianie nowych wersji oraz maksymalne wykorzystanie Internetu jako medium nie było przypadkowe, lecz stanowiło integralną część geniusza Linusa, który polegał na poznaniu linii najmniejszego oporu, to co w takim razie rozwijał do granic możliwości? Co raz za razem wydobywał z tej maszynerii? Jeśli postawić pytanie w ten sposób, odpowiedź staje się oczywista. Linus stale stymulował i nagradzał swoich hakerów-użytkowników: stymulował wizją zadowalającego ego fragmentu akcji, nagradzał widokiem ciągłych (nawet codziennych) ulepszeń projektu. Bezpośrednim celem Linusa było maksymalne zwiększenie osobogodzin poświęcanych na odpluskwianie i rozwój jądra Linuksa, nawet kosztem potencjalnej niestabilności kodu i zmniejszenia zapału użytkowników w sytuacji, gdyby jakiś poważny błąd okazał się niemożliwy do wychwycenia. Linus zachowywał się jak gdyby wierzył, że: 8. Jeśli tylko środowisko użytkowników i beta testerów{12} będzie odpowiednio duże, niemal każdy problem zostanie szybko zdefiniowany i znajdzie się rozwiązanie. Mówiąc mniej formalnie, "Gdzie wiele oczu, tam łatwo ujrzeć pluskwy". Nazwałem to stwierdzenie "Prawem Linusa". Na początku zawierało ono sformułowanie mówiące, że każdy problem "stanie się dla kogoś jasny". Linus nie zgodził się mówiąc, że osoba, która rozumie i rozwiązuje problem niekoniecznie jest, a nawet zwykle nie jest osobą, która pierwsza go opisała. "Ktoś znajduje problem", powiedział, "a ktoś inny go rozumie. Zaryzykuję stwierdzenie, że znalezienie go jest większym wyzwaniem". Jednak najistotniejsze jest to, że obie rzeczy zazwyczaj dzieją się bardzo szybko. Wydaje mi się, że na tym właśnie polega różnica między stylem katedry i bazaru. Z punktu widzenia budowniczego katedr, problemy związane z błędami i programowaniem są czymś głębokim, niełatwym do rozwiązania i nudnym. Trzeba miesięcy uważnych badań prowadzonych przez kilku programistów by mieć pewność, że wszystkie zostały usunięte. Stąd długie okresy między kolejnymi wersjami i nieuniknione rozczarowanie, kiedy okazuje się, że długo oczekiwana wersja nie jest doskonała.

6 Natomiast z punktu widzenia bazaru pluskwy uważa się za zjawisko płytkie, a przynajmniej okazujące się czymś płytkim, kiedy tysiące zapalonych programistów rzuca się na każdą nowa wersję. Dlatego wersje te ukazują się często, aby zwiększyć liczbę poprawek{13}, czego dobroczynnym skutkiem ubocznym są mniejsze straty w razie wystąpienia przypadkowego błędu. I o to właśnie chodzi. To wszystko. Gdyby "prawo Linusa" nie działało, wtedy każdy złożony system, taki jak jądro Linuksa, który hakowało tyle rąk ile jądro Linuksa, powinien w pewnym momencie zawalić się pod ciężarem nieprzewidzianych problemów z zależnościami i nieodkrytych "głębokich" błędach. Jeśli jednak prawo to działa, wyjaśniałoby to relatywnie niską ilość błędów w jądrze Linuksa. Być może nie powinno to nikogo zbytnio dziwić. Socjologowie już dawno odkryli, że na przeciętnej opinii obserwatorów o równie wysokim (lub niskim) stopniu wiedzy można polegać o wiele bardziej, niż na opinii pojedynczego, losowo wybranego obserwatora. Nazywa się to "metodą delficką". Wydawać by się mogło, że Linus zademonstrował, iż efekt ten ma miejsce nawet w przypadku odpluskwiania systemu operacyjnego: że efekt Delphi może zredukować złożoność nawet w tak skomplikowanym projekcie, jakim jest jądro systemu operacyjnego. Jestem wdzięczny Jeffowi Dutky za zwrócenie uwagi na fakt, że Prawo Linusa można przeformułować jako "Odpluskwianie można przeprowadzać równolegle". Jeff zauważył, że choć proces odpluskwiania wymaga kontaktu osób odpluskwiających z koordynującym programistą, to jednak nie jest potrzebna specjalna koordynacja działań między poszukiwaczami błędów. Dlatego też odpluskwianie nie pada ofiarą gwałtownie rosnącej złożoności i kosztów zarządzania, które sprawiają, że rosnąca liczba programistów przynosi problemy. Teoretyczna utrata wydajności, związana z powielaniem tej samej pracy przez różne osoby szukające błędów, w praktyce nigdy nie zaistniała w świecie linuksowym. Jednym ze skutków polityki częstego udostępniania nowych wersji jest minimalizacja tego typu powielania pracy dzięki szybkiemu dołączaniu otrzymanych poprawek do nowej wersji. Brooks mimochodem zwrócił uwagę na inny fakt, mający związek z uwagą Jeffa: "Całkowity koszt utrzymywania powszechnie używanego programu to przeciętnie około 40% kosztu jego rozwoju lub więcej. Co ciekawe, koszt ten w dużej mierze zależy od liczby użytkowników. Większa liczba użytkowników znajdzie więcej błędów" (nacisk pochodzi ode mnie -ESR ). Im więcej użytkowników, tym więcej błędów zostanie odkrytych, ponieważ nowi użytkownicy wnoszą ze sobą różne podejścia do programu. Efekt ten zwiększa się, kiedy użytkownicy są programistami. Każdy podchodzi do problemu określenia błędu z nieco inną percepcją i zestawem narzędzi analitycznych, widzi problem pod innym kątem. Prawdopodobnie "efekt Delphi" działa właśnie dzięki temu zróżnicowaniu. Jeśli zaś chodzi o odpluskwianie, zróżnicowanie pomaga zmniejszyć prawdopodobieństwo dublowania pracy innych. Tak wiec większa liczba beta testerów może nie zmniejsza "głębokości" błędu z punktu widzenia programisty, zwiększa jednak prawdopodobieństwo, że czyjś zestaw narzędzi zostanie dopasowany do problemu tak, że dla danej osoby błąd stanie się płytki. Linus nie wkłada jednak wszystkich jajek do jednego koszyka: na wypadek, gdyby w kodzie miały się pojawić poważne błędy, wersje jądra Linuksa są numerowane w taki sposób, że potencjalni użytkownicy mają wybór między ostatnią wersją oznaczoną jako "stabilna" a najnowszą funkcjonalnością i potencjalnymi błędami. Większość hakerów linuksowych nie naśladuje tej taktyki, choć być może powinni; sam fakt, że istnieją dwie wersje sprawia, że obie są bardziej atrakcyjne. Kiedy róża nie jest różą? Po zbadaniu zachowania Linusa i sformułowaniu teorii wyjaśniającej jego sukces, podjąłem świadomą decyzję, by przetestować tę teorię na moim nowym (w istocie o wiele mniej ambitnym i skomplikowanym) projekcie. Przede wszystkim jednak uporządkowałem i uprościłem kod popclienta. Implementacja Carla Harrisa była bardzo solidna, jednak charakteryzowała się wysokim stopniem niepotrzebnej złożoności, właściwej wielu programującym w C. Dla Harrisa kod był rzeczą centralną, zaś struktury danych - jedynie jego podporą. Dlatego też popclient miał piękny kod, jednak projekt struktur danych został przygotowany naprędce i był raczej niezgrabny (przynajmniej z punktu widzenia starego hakera LISP-a).

7 Był jednak jeszcze jeden argument za przepisaniem programu, poza polepszeniem jakości kodu struktur danych. Zależało mi bowiem na przekształcenie go w coś, co mógłbym całkowicie zrozumieć. Przyjęcie na siebie odpowiedzialności za poprawianie błędów w programie, którego się nie rozumie, nie jest zabawne. Następnie przez około miesiąc realizowałem założenia wynikające z projektu Carla. Pierwszą poważną zmianą z mojej strony było dodanie obsługi IMAP. W tym celu przekształciłem kod odpowiedzialny za obsługę protokołu w ogólny sterownik oraz trzy tablice definiujące metody (dla POP2, POP3 i IMAP). Ta zmiana jak i poprzednie przedstawia ogólną zasadę, którą warto zapamiętać - tyczy się to zwłaszcza osób programujących w językach takich jak C, gdzie zwykle nie istnieje dynamiczne określanie typów: 9. Zręcznie zaprojektowane struktury danych i bezładny kod działają znacznie lepiej, niż odwrotna kombinacja. Brooks, rozdział 9: "Pokaż mi swój [kod] i ukryj [struktury danych], a twój program pozostanie dla mnie tajemnicą. Pokaż mi swoje [struktury danych], a kod nie będzie mi potrzebny - stanie się czymś oczywistym. W rzeczywistości mówił o "diagramach" i "tablicach". Biorąc jednak pod uwagę trzydziestoletni skok technologiczno-kulturowy, można stwierdzić, że chodzi niemal o to samo. Wtedy właśnie (na początku wrześnie 1996, około sześć tygodni od punktu zerowego) zacząłem myśleć o zmianie nazwy programu; w końcu nie był to już jedynie klient POP. Wahałem się jednak, ponieważ w projekcie programu nie było nic naprawdę nowego. Moja wersja popclienta musiała jeszcze zapracować na swoją własną tożsamość. Radykalna zmiana nastąpiła wtedy, kiedy nauczyłem fetchmaila przekazywać pobraną pocztę do portu SMTP{14}. Powrócę do tej kwestii za chwilę, wcześniej jednak odpowiem na mogące się nasunąć pytanie: wspomniałem wcześniej, że wykorzystam swój projekt by przetestować swoją teorię na temat taktyki Linusa Torvaldsa. W jaki sposób to uczyniłem? Otóż skorzystałem z kilku możliwości: 1. Udostępniałem nowe wersje wcześnie i często (niemal nigdy rzadziej niż raz na dziesięć dni; w okresach intensywnego rozwoju - codziennie). 2. Lista beta-testerów rosła, ponieważ dodawałem do niej każdego, kto skontaktował się ze mną w sprawie fetchmaila. 3. Przy okazji udostępnienia każdej nowej wersji wysyłałem na listę beta-testerów przyjacielskie zawiadomienia, zachęcając ich do wzięcia udziału w dalszym rozwoju programu. 4. Słuchałem testerów wersji beta, pytając ich o zdanie przy podejmowaniu decyzji dotyczących zmian projektowych i głaszcząc ich za każdym razem, kiedy odpowiadali czy przysyłali poprawki. Skutek tych niewyszukanych działań był natychmiastowy: od samego początku otrzymywałem raporty o błędach w takiej jakości, za którą większość programistów dałoby sie zabić, często z dołączonym rozwiązaniem. Krytyka, którą otrzymywałem, była przemyślana; otrzymywałem również listy od fanów i inteligentne propozycje zmian. Prowadzi nas to do następnej konkluzji: 10. Jeśli traktujesz swoich beta-testerów jak swój największy skarb, staną się twoim największym skarbem. Interesującym wskaźnikiem odzwierciedlającym sukces fetchmaila jest sama wielkość listy dyskusyjnej poświęconej wersjom beta projektu, fetchmail-friends. W chwili, kiedy piszę te słowa, liczy ona 249 członków, zaś każdego tygodnia dołącza dwóch-trzech nowych. Przygotowując do wydania pod koniec maja 1997 roku kolejną wersję tego tekstu stwierdziłem, że lista traci członków z interesującego powodu: otóż wiele osób prosiło mnie o usunięcie z listy, ponieważ fetchmail działał im tak dobrze, że nie musieli śledzić już wiadomości na liście! Być może jest to po prostu normalna faza rozwoju dojrzałego projektu rozwijanego w bazarowym stylu. Popclient przekształca się w fetchmaila

8 Prawdziwy przełom nastąpił kiedy Harry Hochheiser podesłał mi zalążek kodu służącego do przekazywania poczty do portu SMTP na maszynie lokalnej. Niemal od razu zdałem sobie sprawę z faktu, że wykorzystanie tej metody dostarczania poczty sprawi, iż wszystkie inne staną się niemal przestarzałe. Przez wiele tygodni stopniowo modyfikowałem fetchmaila mając jednak odczucie, że projekt interfejsu jest użyteczny lecz niezgrabny: brakowało mu elegancji, zaś wszelkiego rodzaju opcje wystawały na wszystkie strony. Szczególnie irytowały mnie opcje służące do przekazywania pobranej poczty do pliku skrzynki lub na standardowe wyjście, nie wiedziałem jednak dlaczego. Kiedy pomyślałem o przekazywaniu poczty przez SMTP zdałem sobie sprawę, że popclient próbował zrobić zbyt wiele rzeczy na raz. Został zaprojektowany jako program do przekazywania poczty (MTA), ale i jako program do lokalnego dostarczania poczty (MDA). Dzięki SMTP mógłby przestać być MDA i stać się czystym MTA, przekazując pocztę innym programom, które zajęłyby się lokalnym dostarczaniem, tak jak to czyni sendmail. Po co męczyć się ze skomplikowaną konfiguracją programu do dostarczania poczty czy ustawianiem trybu "zablokuj-i-dopisuj" na pliku skrzynki pocztowej, kiedy istnieje niemal stuprocentowa gwarancja, że na każdej platformie z obsługą TCP/IP będziemy mieli do dyspozycji port 25? Szczególnie jeśli pobierana poczta ma wyglądać jak zwykła poczta nadana przez nadawcę przy użyciu SMTP - o co zresztą nam właśnie chodzi. Z powyższego płynie kilka wniosków: po pierwsze, pomysł na przekazywanie poczty przez SMTP był największą pojedynczą zapłatą, którą otrzymałem próbując świadomie naśladować metody Linusa. Użytkownik poddał mi wspaniały pomysł, do mnie należało jedynie zrozumienie jego implikacji. 11. Najlepsze, co może nas spotkać oprócz własnych dobrych pomysłów, to słuchanie dobrych pomysłów użytkowników. Czasem to drugie jest lepsze. Co ciekawe, można się szybko zorientować, że jeśli będziemy absolutnie prawdomówni w kwestii nikłości własnego wkładu i ogromnego znaczenia wkładu innych, ludzie uznają, że wszelkie innowacje są naszym dziełem i przez skromność pomniejszamy rolę swojego wrodzonego geniuszu. Widać to jasno na przykładzie Linusa! (Kiedy przedstawiłem ten esej na konferencji poświęconej Perlowi{15} w sierpniu 1997 roku i dotarłem do tego miejsca, Larry Wall, który siedział w pierwszym rzędzie, wydał z siebie religijny okrzyk: "Mów więcej, bracie!". Zebrani wybuchnęli śmiechem wiedząc dobrze, że twórca Perla również korzystał z tej zasady.) Po kilu tygodniach prowadzenia projektu w tym duchu, zacząłem otrzymywać pochwały nie tylko od użytkowników popclienta, lecz również od innych ludzi, którzy się o nim dowiedzieli. Skrzętnie ukryłem część tych i; powrócę do nich kiedyś, kiedy zacznę zastanawiać się nad sensem życia. :-) Dochodzą tu jednak jeszcze dwie bardziej fundamentalne lekcje, odnoszące się do wszelkiego rodzaju projektów. 12. Często najbardziej uderzające i nowatorskie rozwiązania mają u swych źródeł zrozumienie, że pierwotne postrzeganie natury problemu było błędne. Próbowałem rozwiązać niewłaściwy problem, kontynuując prace nad popclientem, będącym połączeniem MTA/MDA, zawierającym wszelkiego typu wymyślne sposoby dostarczania poczty. Projekt fetchmaila musiał zostać przemyślany od początku: program ten powinien być czystym MTA, częścią normalnej ścieżki poczty internetowej, używającej protokołu SMTP. Kiedy prowadząc projekt dotrze się do ściany, kiedy trudno jest myśleć o następnej łacie, wtedy nadchodzi czas by zapytać samego siebie - nie o to, czy zna się właściwą odpowiedź, ale czy zadaje się właściwe pytanie. Być może trzeba przeformułować problem. Cóż, przeformułowałem swój problem. Rzecz jasna, należało (1) dołączyć przekazywanie SMTP do ogólnego sterownika, (2) uczynić ten tryb domyślnym, oraz (3) ostatecznie pozbyć się wszystkich innych sposobów dostarczania poczty, szczególnie "dostarcz-do-pliku" oraz "dostarcz-na-standardowe-wyjście".

9 Wahałem się przed uczynieniem tego ostatniego kroku, obawiając się, że sprawię przykrość starym użytkownikom popclienta, polegającym na alternatywnych metodach dostarczania poczty. Teoretycznie mogli od razu zacząć korzystać z plików.forward (i ich odpowiedników, jeśli korzystali z MTA innych niż sendmail), by uzyskać ten sam efekt. W praktyce tego typu przejście mogło sprawiać problemy. Jednakże kiedy to uczyniłem, korzyści okazały się ogromne. Zniknęły najbardziej nieociosane fragmenty kodu sterownika. Konfiguracja stała się o niebo łatwiejsza - koniec z chodzeniem po omacku w poszukiwaniu systemowego MDA i skrzynki użytkownika, koniec ze zmartwieniami o obsługę blokowania plików przez system operacyjny użytkownika. W ten sposób zniknęła również jedyna możliwość utraty poczty. Jeśli użytkownik wybrał dostarczanie do pliku, a dysk został zapełniony, poczta ginęła. Tego typu wypadki nie mogą mieć miejsca jeśli korzysta się z przekazywania SMTP, ponieważ program nasłuchujący na porcie SMTP nie zwróci OK {16} dopóki wiadomość nie zostanie przekazana, lub chociaż umieszczona w kolejce do dostarczenia. Wzrosła również wydajność (chociaż niełatwo to zauważyć przy pojedynczym uruchomieniu fetchmaila). Innym, mniej istotnym pożytkiem było zmniejszenie rozmiaru strony podręcznika man{17}. Później byłem zmuszony przywrócić dostarczanie przez MDA, by obsłużyć dostarczanie poczty w pewnych niejasnych sytuacjach związanych z dynamicznym SLIP. Znalazłem na to jednak o wiele prostszy sposób. Morał? Nie należy się wahać wyrzucić przestarzałą funkcjonalność, jeśli można to zrobić bez straty efektywności. Antoine de Saint Exupery (który był lotnikiem i konstruktorem samolotów, kiedy akurat nie pisał książek dla dzieci), powiedział: 13. "Doskonałość projektu osiąga się nie wtedy, kiedy nie ma co dodać, lecz raczej kiedy nie ma co odjąć". Kiedy kod staje się lepszy i prostszy, wtedy wie się, że jest właściwy. W międzyczasie projekt fetchmaila uzyskał swoją własną tożsamość, różną od swojego przodka - popclienta. Przyszła pora na zmianę nazwy. Nowy projekt bardziej przypominał sendmaila niż stary popclient; obydwa są MTA, ale tam, gdzie sendmail wysyła ("send") i dostarcza, tam nowy popclient pobiera ("fetch"), a później dostarcza. Tak więc dwa miesiące później nazwałem go fetchmail. Z historii tej wynika jeszcze jeden, bardziej ogólny wniosek dotyczący pojawienia się kodu SMTP w fetchmailu. Nie tylko odpluskwianie{18} jest procesem równoległym, jest nim również rozwój, oraz (do pewnego - być może zaskakującego - stopnia) także eksploracja przestrzeni projektowej. Kiedy tryb rozwoju szybko staje się iteracyjny, rozwój i ulepszenia mogą stać się szczególnymi przypadkami odpluskwiania - naprawiania "błędów przeoczenia" w pierwotnej funkcjonalności czy koncepcji oprogramowania. Nawet na wyższym poziomie projektowym, pomysły wielu programistów badających w różnych miejscach przestrzeń projektową w pobliżu produktu mogą mieć dużą wartość. Warto zwrócić uwagę na to, w jaki sposób kałuża znajduje swoje ujście, albo jeszcze lepiej - jak mrówki szukają pożywienia: eksploracja odbywa się przez rozproszenie, po czym następuje eksploatacja za pośrednictwem skalowalnego mechanizmu komunikacji. System ten funkcjonuje bardzo dobrze; członek eskorty może znaleźć skarb, którego nie zauważył główny programista z powodu skupiania się zbyt blisko - tak jak to miało miejsce z Harry Hochheiserem i ze mną. Fetchmail dorasta Miałem więc przejrzysty i nowatorski projekt, dobrze działający kod, którego używałem na co dzień oraz rozwijającą się listę użytkowników wersji beta. Stopniowo zacząłem sobie zdawać sprawę, że nie uczestniczę już w trywialnym, osobistym projekcie hackerskim, z którego być może skorzystałoby klika innych osób. Miałem w swoich rękach program, którego potrzebuje każdy haker z uniksem i połączeniem pocztowym SLIP/PPP. Wraz z dodaniem funkcjonalności SMTP, fetchmail wysunął się przed konkurencję, mając szansę stać się "przebojem w swojej kategorii", jednym z tych klasycznych programów, które wypełniają swoją niszę do tego stopnia, że alternatywne rozwiązania są nie tyle pomijane co niemal zapomniane. Nie wydaje mi się, by można było zaplanować tego typu rezultat. Trzeba być weń wciągniętym przez idee

10 tak silne, że rezultaty wydają się nieuniknione, naturalne, by nie rzec przepowiedziane. Istnieje tylko jeden sposób, by wypróbować te pomysły: trzeba mieć ich dużo, albo umieć posłużyć się inżynierskim osądem, prowadząc dobre pomysły innych poza granice wyznaczone im przez ich twórców. Andy Tanenbaum pierwszy wpadł na pomysł, by zbudować prosty, natywny system uniksowy dla komputerów IBM PC, który mógłby wykorzystać w nauczaniu (Minix). Linus Torvalds popchnął koncepcję Miniksa prawdopodobnie dalej, niż Andrew przewidział - a rezultat przerodził sie w coś wspaniałego. W podobny sposób, lecz na mniejszą skalę, wziąłem pewne pomysły od Carla Harrisa i Harry'ego Hochheisera i nadałem im rozpędu. Żaden z nas nie był "oryginalny" w romantyczny sposób, w jaki zwykle postrzega się geniusz. Jednakże większość tego, co dzieje się w nauce, inżynierii czy rozwoju oprogramowania, nie dokonuje się za sprawą geniuszu, bez względu na to, co mówi hakerska mitologia. Rezultaty były bardzo ekscytujące - szczerze mówiąc był to sukces, o jakim marzy każdy haker! Wniosek był jeden: powinienem podwyższyć poprzeczkę. By uczynić fetchmaila tak dobrym programem, jakim mógłby być, powinienem dołączyć i dbać o funkcjonalność potrzebną ludziom znajdującym się poza moim polem percepcji - cały czas starając się, by program zachował swoją siłę i prostotę. Pierwszą i najważniejszą funkcjonalnością, którą dopisałem, kiedy zdałem sobie sprawę z tego faktu, była obsługa multidrop - możliwości pobierania poczty ze skrzynek, w których zgromadzona została poczta dla grupy użytkowników, by następnie przekazać ją indywidualnym odbiorcom. Zdecydowałem się dodać obsługę multidrop częściowo z powodu nagabywań użytkowników, jednak głównym powodem było przekonanie, że fakt ten przyczyni się do eliminacji błędów z ówczesnego kodu single-drop, zmuszając mnie do rozwiązania problemu na wyższym poziomie abstrakcji. Tak tez się stało. Parsowanie adresów zgodnie z RFC 822 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt) zajęło mi naprawdę dużo czasu, nie dlatego, że którykolwiek fragment był trudny, lecz z powodu przeładowania mnóstwem wzajemnie zależnych szczegółów. Wprowadzenie adresowania maildrop okazało się jednak bardzo trafną decyzja projektową. W ten sposób dowiedziałem się, że: Każde narzędzie powinno być użyteczne w przewidziany sposób, jednak naprawdę wielkie narzędzie znajduje nieprzewidziane zastosowania. Nieprzewidzianym zastosowaniem funkcjonalności multidrop w fetchmailu okazała się możliwość uruchomienia list pocztowych, przy czym zarówno lista, jak i dopełnianie aliasów{19} odbywało się po stronie klienta połączenia internetowego, co oznacza, że osoba posiadająca komputer osobisty i łącząca się z Internetem za pośrednictwem swojego ISP, może zarządzać listą dyskusyjną bez potrzeby stałego dostępu do konta ISP. Inną ważną funkcjonalnością, której domagali się moi beta testerzy, była obsługa ośmiobitowego MIME (Multipurpose Internet Mail Extension{20}). Nie było to zbyt trudne, ponieważ dbałem o to, bym mój kod był czysty pod względem operacji ośmiobitowych - nie dlatego, że przewidziałem dodanie tej funkcjonalności, lecz ponieważ stosowałem się do następującej reguły: 15. Pisząc jakiekolwiek oprogramowanie pełniące rolę pośrednika, należy podjąć wysiłki, by nie naruszać strumienia danych i *nigdy* nie odrzucać żadnej informacji, chyba, że program zostanie do tego zmuszony przez odbiorcę. Gdybym nie przestrzegał tej zasady, implementacja ośmiobitowej obsługi MIME byłaby trudna i pełna błędów. Ponieważ jednak było inaczej, wystarczyło mi tylko poczytać o standardzie MIME w RFC 1652 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt) i dodać trywialny fragment związany z logiką generowania nagłówków. Niektórzy europejscy użytkownicy męczyli mnie, bym dodał opcje ograniczającą liczbę wiadomości otrzymanych podczas jednej sesji (dzięki czemu mogliby kontrolować opłaty za korzystanie z drogich linii telekomunikacyjnych). Dość długo się temu opierałem i wciąż nie jestem z tego powodu zbyt szczęśliwy. Jeśli jednak pisze się dla innych, trzeba słuchać swoich klientów - fakt, że nie płacą, niczego nie zmienia. Jeszcze kilka lekcji płynących z tworzenia fetchmaila Zanim wrócimy do ogólnych kwestii związanych z inżynierią oprogramowania, warto zatrzymać się chwilę nad kilkoma bardziej specyficznymi lekcjami, których nauczyło mnie doświadczenie w pracy nad

11 fetchmailem. Czytelnik nie zaznajomiony z kwestiami technicznymi może spokojnie ominąć ten fragment. Składnia plików kontroli rc{20} zawiera opcjonalne "szumy" w postaci słów kluczowych, które są ignorowane przez parser. Przypominająca język angielski składnia, którą się dzięki temu uzyskuje, jest o wiele bardziej czytelna niż tradycyjne, zbite pary "słowo kluczowe - wartość", które można uzyskać po zredukowaniu ich do prostszej postaci. Składnia ta powstała w wyniku nocnego eksperymentu, kiedy zauważyłem, że deklaracje w plikach rc zaczęły przypominać mini-język złożony ze zdań rozkazujących (z tego tez powodu zamieniłem występujące w popcliencie słowo kluczowe "server" na "poll"). Uważałem, że jeśli ten mini-język będzie bardziej przypominał angielski, łatwiej będzie go używać. Wspomnę, że chociaż jestem zwolennikiem szkoły projektowania "spraw, by był to język", która przejawia się w takich przykładach jak Emacs, HTML czy wiele silników bazodanowych, to zazwyczaj nie jestem wielkim fanem składni "przypominających język angielski". Tradycyjnie programiści maja tendencję do faworyzowania bardzo precyzyjnych składni kontrolujących, nie mających żadnych zbędnych elementów. Jest to kulturowa spuścizna po czasach, kiedy zasoby komputerowe były drogie, stąd też faza parsowania musiała być tak tania i prosta, jak to tylko możliwe. Język angielski, ze swoją 50-procentową redundancją, zdawał się być wtedy bardzo nieodpowiednim przykładem. Unikam angielskopodobnych składni nie z tego powodu; przytaczam ten argument tylko po to, by go obalić. Mając tanie cykle procesora i sprzęt, zwięzłość nie powinna być celem samym w sobie. Dziś o wiele ważniejsze jest, by język był zrozumiały dla ludzi, niż tani dla komputera. Istnieją jednak dobre powody, by być ostrożnym w tej kwestii. Pierwszym jest koszt złożoności fazy parsowania - nie ma sensu doprowadzać jej do punktu, kiedy zacznie być znaczącym źródłem błędów i kłopotów użytkowników. Następny powód to fakt, że próba uczynienia składni bardziej angielską często wymaga od programisty, by "angielski", którym mówi program stał się zupełnie bezkształtny do tego stopnia, że powierzchowne podobieństwo do języka naturalnego byłoby równie mylące, jak tradycyjna składnia (widać to na przykładzie wielu tzw. "języków czwartej generacji" i komercyjnych języków zapytywania baz danych). Składnia kontrolująca fetchmaila zdaje się unikać tych pułapek, ponieważ domena językowa jest bardzo ograniczona. Nie jest to żadną miarą język ogólnego zastosowania; rzeczy, których dotyczy, nie są bardzo skomplikowane, nie jest więc łatwo się pomylić poruszając się mentalnie między niewielkim podzbiorem angielskiego a rzeczywistym językiem kontrolującym. Myślę, że wypływa z tego bardziej ogólny wniosek: Jeśli kompletność języka nie zbliża się do poziomu Turinga, dodatki składniowe mogą bardzo pomóc. Kolejna lekcja dotyczy "bezpieczeństwa przez ukrywanie"{21}. Niektórzy użytkownicy fetchmaila prosili mnie, bym wprowadził szyfrowanie haseł przechowywanych w pliku rc, aby węszyciele nie mogli ich przypadkiem podejrzeć. Nie uczyniłem tego, ponieważ nie jest to żadna ochrona. Każdy, kto uzyskał uprawnienia do odczytu pliku rc, będzie mógł uruchomić fetchmaila jako właściciel pliku; jeśli zaś zależałoby im na haśle, mogliby zbudować dekoder na bazie kodu deszyfrującego w samym fetchmailu. Jedynym skutkiem szyfrowania haseł w pliku.fetchmailrc byłoby złudne poczucie bezpieczeństwa u ludzi, którzy nie przemęczają się myśleniem. Ogólna reguła brzmi: System bezpieczeństwa jest tak silny, jak silna jest jego tajemnica. Należy się wystrzegać pseudotajemnic. Niezbędne warunki bazarowego stylu Osoby, które pierwsze przeczytały ten esej oraz jego pierwsi testerzy wciąż zadawali pytania dotyczące warunków niezbędnych do tego, by rozwój projektów w bazarowym stylu był udany, włączając w to kwalifikacje lidera projektu jak również stan kodu w chwili jego upublicznienia i podjęcia próby zbudowania wspólnoty deweloperskiej.

12 Jest całkiem jasne, że nie można od samego początku tworzyć w bazarowym stylu[4]. Można testować, odpluskwiać i ulepszać program w bazarowym stylu, lecz bardzo trudno w ten sposób zapoczątkować projekt. Linus nie próbował. Ja też nie. Rodząca się społeczność deweloperska potrzebuje mieć rozrywkę w postaci czegoś, co można by uruchomić, przetestować. Kiedy rozpoczyna się budowanie społeczności, trzeba być gotowym do przedstawienia możliwej do zaakceptowania obietnicy. Program nie musi działać nadzwyczajnie dobrze - może być toporny, zapluskwiony, nieskończony i źle udokumentowany. Musi jednak uczynić dwie rzeczy: (a) uruchomić się, (b) przekonać potencjalnych deweloperów, że można go będzie przekształcić w coś naprawdę uporządkowanego w możliwej do przewidzenia przyszłości. Zarówno Linux jak fetchmail pojawiły się po raz pierwszy szerszemu gronu odbiorców z silnie zaznaczonym i atrakcyjnym rysem projektowym. Wielu ludzi rozmyślających nad przedstawionym przeze mnie modelem bazarowym słusznie uważało ten fakt za bardzo istotny, wnioskując z tego, że lider projektu musi posiadać wiele intuicji projektowej i być bardzo bystrą osobą. Jednakże Linus zapożyczył projekt z UNIX-a. Mój pochodzi od swojego przodka, popclienta (chociaż później uległ sporym zmianom, o wiele większym, niż - biorąc pod uwagę proporcje - Linux). Czy lider/koordynator projektu powstającego w bazarowym stylu naprawdę musi mieć nadzwyczajny talent projektowy, czy też może polegać na takim talencie u innych? Ja uważam, że koordynator nie musi być autorem błyskotliwych pomysłów projektowych, jednakże absolutnie konieczne jest, by potrafił rozpoznać dobre pomysły projektowe u innych. Zarówno proces powstawania Linuksa jak i fetchmaila ustanowią dowód na poparcie tej tezy. Linus, nie będąc nadzwyczajnie oryginalnym projektantem (jak to już było omawiane), wykazał niebywałą zdolność rozpoznawania dobrych projektów i integracji ich z jądrem Linuksa. Co się tyczy fetchmaila - opisałem już, w jaki sposób do fetchmaila przeniknął najważniejszy pojedynczy pomysł projektowy (SMTP). Pierwsi odbiorcy tego eseju sprawili mi komplement sugerując, że mam tendencje do niedoceniania oryginalności projektowej w aplikacjach bazarowych, ponieważ sam jej dużo posiadam, więc przyjmuję ją jak rzecz oczywistą. Być może jest w tym trochę prawdy; projektowanie (w przeciwieństwie do kodowania czy debugowania) jest moją najsilniejszą stroną. Jednakże problem z bystrością i oryginalnością w projektowaniu oprogramowania polega na tym, że po pewnym czasie stają się przyzwyczajeniem: odruchowo tworzy się ładne i skomplikowane rzeczy, podczas gdy powinno się tworzyć programy uporządkowane i proste. Niektóre moje projekty upadły, ponieważ popełniłem ten właśnie błąd - jednak przy tworzeniu fetchmaila udało mi się go nie popełnić. Wierze więc, że projekt fetchmaila zakończył się sukcesem częściowo dlatego, że hamowałem swoje zapędy do bystrości; stoi to w sprzeczności (przynajmniej) z tezą, że oryginalność projektowa jest najistotniejsza, jeśli chce się stworzyć udany projekt bazarowy. Weźmy teraz pod uwagę Linuksa: załóżmy, że Linus Torvalds próbowałby wdrożyć nowatorskie pomysły projektowe podczas tworzenia jądra; czy w ogóle wydaje się prawdopodobne, że powstałe w wyniku tego jądro byłoby tak stabilne i udane jak to, które mamy? Pewien podstawowy poziom umiejętności programowania i projektowania jest niezbędny, jednak wydaje mi się, że każdy, kto poważnie myśli o rozpoczęciu projektu bazarowego, znajduje sie powyżej tego minimum. Wewnętrzny reputacyjny rynek społeczności open source wywiera subtelny nacisk na programistów, by nie rozpoczynali projektów, do których prowadzenia nie są wystarczająco kompetentni. Wydaje się, że jak dotąd mechanizm ten działał całkiem nieźle. Istnieje jeszcze jedna umiejętność, zwykle nie kojarzona z rozwojem oprogramowania, którą uważam za równie ważną co talent projektowy - a być może jest nawet ważniejsza. Lider czy koordynator projektu bazarowego musi posiadać umiejętność komunikowania się i współpracy z ludźmi. Powinno być to jasne: aby stworzyć wspólnotę deweloperską, trzeba przyciągnąć ludzi, zainteresować ich tym, co się robi i być zadowolonym z ilości pracy, którą wykonują. Sprawy techniczne są bardzo ważnym czynnikiem, jednak w żadnym wypadku nie decydują o całości. Liczy się również osobowość. Nie przypadkiem Linus jest miłym facetem, lubianym i budzącym chęć pomocy. Nieprzypadkowo jestem energetycznym ekstrawertykiem, czerpiącym radość z tłumem ludzi, którego sposób mówienia i odruchy

13 przypominają komika rozbawiającego publiczność. Aby bazarowy model działał, bardzo pomocna jest choć skromna umiejętność oczarowywania ludzi. Społeczny kontekst oprogramowania open source Napisano: najlepsze hakerskie projekty powstają jako osobiste rozwiązania codziennych problemów autora, zaś rozprzestrzeniają się ponieważ okazuje się, że na problem ten uskarża sie większa klasa użytkowników. Tym samym wracamy do reguły 1, którą można sformułować inaczej, być może czyniąc ją bardziej użyteczną: Aby rozwiązać interesujący problem, należy zacząć od znalezienia problemu, który nas osobiście interesuje. Tak było z Carlem Harrisem i przodkiem popclientem, tak też było i ze mną i fetchmailem. Ale to rzecz zrozumiała od dłuższego czasu. Interesującym procesem, którym zainteresowania domagają się historie powstania Linuksa i fetchmaila, jest następna faza - ewolucja oprogramowania w obecności licznej i aktywnej społeczności użytkowników i programistów. W książce Mityczny osobomiesiąc Fred Brooks zauważył, że czas programistyczny nie jest skalowalny: dodawanie programistów do projektu sprawia, że prace trwają dłużej. Brooks argumentował twierdząc, że koszty złożoności i komunikacji rosną kwadratowo w stosunku do liczby programistów, zaś prace nad projektem przebiegają jedynie liniowo. Teza ta została nazwana "Prawem Brooksa" i jest powszechnie uznawana za truizm. Jeśli jednak prawo Brooksa oddawałoby całość sytuacji, powstanie Linuksa nie byłoby możliwe. W klasycznym dziele Geralda Weinberga, Psychologii programowania komputerów, możemy odnaleźć coś, co -- patrząc z perspektywy czasu -- możemy uznać za istotną poprawkę do Prawa Brooksa. Przy okazji rozważań na temat "programowania pozbawionego ego", Winberg zauważył, że w firmach, w których programiści nie mieli zaborczego nastawienia do własnego kodu, zachęcając innych do szukania błędów i możliwości rozwoju, postępy były czynione o wiele szybciej niż gdzie indziej. Analiza Weinberga nie uzyskała szerokiej akceptacji prawdopodobnie ze względu na używaną przez niego terminologię - nazwanie hakerów internetowych "tymi, którzy nie mają ego" wywołuje uśmiech na twarzy. Wydaje mi się jednak, że jego teza jest dziś bardziej przekonywująca niż kiedykolwiek. Historia UNIX-a powinna przygotować nas na to, czego dzisiaj uczymy się z Linuksa (i co zweryfikowałem doświadczalnie na mniejszą skalę, świadomie kopiując metody Linusa[5]). Chodzi mianowicie o to, że choć samo programowanie jest czynnością wykonywaną samotnie, to jednak naprawdę wspaniałe pomysły programistyczne powstają dzięki wykorzystaniu uwagi i potęgi mózgów całych społeczności. Programista, który potrafi korzystać jedynie ze swojego mózgu w zamkniętym projekcie będzie zawsze w tyle za tym, który potrafi stworzyć otwarty, ewolucyjny kontekst, w którym odzew związany z eksploracją przestrzeni projektowej, przesyłane fragmenty kodu, wyłapane błędy i inne ulepszenia pochodzą od setek (a być może i tysięcy) ludzi. Jednakże wiele czynników obecnych w tradycyjnym świecie uniksowym nie pozwalało rozwinąć tego podejścia do granic możliwości. Jednym z nich były ograniczenia prawne zawarte w wielu licencjach, tajemnice handlowe i komercyjne interesy; innym (spoglądając wstecz) był niedostateczny poziom rozwoju Internetu. Zanim pojawił sie tani Internet, istniały pewne geograficznie ściśnięte wspólnoty, których kultura sprzyjała Weinbergowemu "programowaniu bez ego", zaś programista mógł z łatwością przyciągnąć wielu utalentowanych kibiców i deweloperów. Bell Labs, Labolatorium Sztucznej Inteligencji MIT, Uniwersytet Kalifornijski Berkeley - instytucje te stały się źródłem legendarnych innowacji, których siłę odczuwamy do dziś. Linux był pierwszym projektem, w którym uczyniono świadomy i udany wysiłek, by skorzystać z zasobów talentów całego świata. Nieprzypadkowo początkowy okres rozwoju Linuksa zbiegł się z narodzinami World Wide Web, zaś dzieciństwo Linuksa zakończyło się w latach , a więc w tym samym okresie, w którym powstał biznes dostawców usług internetowych i nastąpiła eksplozja ogólnego zainteresowania Internetem. Linus był pierwszą osobą, która nauczyła się grać według nowych zasad, które wyznaczył powszechny dostęp do Internetu. Podczas gdy tani Internet był niezbędnym warunkiem umożliwiającym ewolucję modelu linuksowego, nie wydaje mi się, by był to jedyny warunek. Innym istotnym czynnikiem był rozwój stylu prowadzenia

14 projektu oraz zestaw zwyczajów towarzyszących współpracy, które pozwalały programistom przyciągnąć innych programistów i uzyskać maksimum mocy, którą oferowało nowe medium. Na czym jednak polega ów styl prowadzenia projektów i o jakich zwyczajach mowa? Nie można ich stworzyć na związkach, które opierają się na władzy, a nawet jeśli by to było możliwe, przewodnictwo oparte na przymusie nie przyniosłoby rezultatów, którymi dziś dysponujemy. Na poparcie tej tezy Weinberg przytacza cytat z autobiografii dziewiętnastowiecznego rosyjskiego anarchisty Piotra Aleksjewicza Kroppotkina, Wspomnienia rewolucjonisty: Będąc wychowany w rodzinie właścicieli ziemskich, wszedłem w dorosłe życie - podobnie jak wszyscy młodzi mężczyźni w tamtych czasach - silnie wierząc w konieczność rozkazywania, łajania, karania i tak dalej. Kiedy jednak na samym początku musiałem zająć się poważnymi przedsięwzięciami i pracować z [wolnymi] ludźmi, kiedy każda pomyłka groziła poważnymi konsekwencjami, zacząłem zdawać sobie sprawę z różnicy pomiędzy działaniem w oparciu o władzę i dyscyplinę a działaniem na bazie wzajemnego zrozumienia. To pierwsze świetnie zdaje egzamin podczas marszu wojskowego, jednak w prawdziwym życiu nie ma żadnej wartości, zaś cel może zostać osiągnięty tylko dzięki sporemu wysiłkowi wielu osób, których dobra wola zbiega się w jednym punkcie. Projekt taki jak Linux wymaga właśnie "wysiłku wielu osób, których dobra wola zbiega się w jednym punkcie", zaś wykorzystanie "zasady władzy" wśród ochotników w anarchistycznym pochodzie zwanym Internetem efektywnie zastosować się nie da. Aby efektywnie działać i konkurować, hakerzy pragnący prowadzić współpracujące ze sobą projekty muszą się nauczyć w jaki sposób rekrutować i napełniać entuzjazmem wspólnoty interesów, jak to mgliście sugeruje "zasada zrozumienia" Kropotkina. Muszą się nauczyć Prawa Linusa[6]. Wcześniej omawiałem "efekt Delphi" jako możliwe wyjaśnienie Prawa Linusa, jednakże od razu narzucają się jeszcze bardziej przekonywujące analogie do systemów adaptacyjnych w biologii i ekonomii. Świat linuksowy pod wieloma względami przypomina gospodarkę wolnorynkową lub ekosystem, zbiór samolubnych czynników próbujących zmaksymalizować użyteczność produktu, dzięki czemu powstaje samoregulujący się, spontaniczny porządek, większy i bardziej skuteczny niż zdołałoby osiągnąć centralne planowanie. Tutaj właśnie należy szukać "zasady zrozumienia". "Funkcja użytkowa", eksplorowana przez linuksowych hakerów nie ma klasycznych podstaw ekonomicznych, jest natomiast niematerialną nagrodą w postaci zadowolenia własnego ego oraz reputacji w środowisku hakerskim. (Można nazwać ich motywację "altruistyczną", ignorując fakt, że sam altruizm oferuje altruiście jakąś formę zadowolenia ego). Działające w ten sposób kultury ochotników nie są niczym niezwykłym: przez długi czas uczestniczyłem w życiu wspólnoty fanów science fiction, która w przeciwieństwie do społeczności hakerskiej już dawno uznała "egoboo" (podbudowywanie ego, czyli polepszanie własnej reputacji wśród innych fanów) za podstawową motywację dobrowolnej działalności. Linus dobrze uchwycił "zasadę dzielonego zrozumienia" Kropotkina. Quasi-ekonomiczne spojrzenie na świat linuksowy pozwala nam ujrzeć, jak praktycznie wykorzystał swoją wiedzę. Możemy uznać metodę Linusa za sposób na stworzenie wydajnego rynku "egoboo" - ścisłego związania samolubnych tendencji w celu dotarcia do trudnego celu, który można osiągnąć jedynie dzięki trwałej współpracy. Pracując nad fetchmailem pokazałem (choć na mniejszą skalę), że jego metody można z dobrym skutkiem naśladować. Być może nawet robiłem to nieco bardziej systematycznie i świadomie niż on. Wielu ludzi (szczególnie ci, którzy z powodów politycznych nie ufają wolnym rynkom) wyobraża sobie wspólnotę kierujących się swoim osądem egoistów za pofragmentowaną, zaborczą, marnotrawną, skrywającą swoje sekrety i wrogą kulturę. Jednakże kłam tego typu oczekiwaniom w bardzo oczywisty sposób zadaje choćby zadziwiające bogactwo, jakość i głębia linuksowej dokumentacji. Należy podchodzić do tego faktu z szacunkiem zważywszy na fakt, że programiści nienawidzą pisać dokumentacji. W takim razie jak to się dzieje, że linuksowi hakerzy generują jej takie ilości? Widocznie wolnorynkowe linuksowe egoboo lepiej potrafi wytworzyć szlachetne zachowania, nakierowane na pomoc innym, niż wysoko opłacane firmy dokumentacyjne komercyjnych producentów oprogramowania. Zarówno projekt fetchmaila jak i jądra Linuksa pokazują, że we właściwy sposób nagradzając ega wielu innych hakerów, silny programista / koordynator może wykorzystać Internet w celu uzyskania korzyści w postaci dużej liczby współpracowników, nie pozwalając równocześnie, by projekt popadł w chaotyczny bałagan. Tak więc w opozycji do prawa Brooksa proponuję co następuje:

15 Zakładając, że koordynator projektu dysponuje medium przynajmniej tak dobrym jak Internet i potrafi zarządzać projektem bez stosowania przymusu, wiele głów ma z pewnością większą wartość niż jedna. Uważam, że przyszłość oprogramowania open source będzie coraz bardziej należała do ludzi, którzy umieją grać w grę Linusa, ludzi, którzy porzucili katedrę na rzecz bazaru. Nie znaczy to, że błyskotliwość i wizja jednostki nie będą miały znaczenia, przeciwnie - najwyższej jakości oprogramowanie open source będzie należało do tych, którzy zaczynają od własnej wizji i pomysłowości, a następnie wzmacniają, tworząc wspólnoty interesu złożone z ochotników. Być może jest to przyszłość nie tylko oprogramowania open source: żaden programista zamkniętego oprogramowania nie może równać się z zasobami talentów, którymi dysponuje wspólnota linuksowa w celu rozwiązywania problemów. Niewielu mogłoby sobie pozwolić na zatrudnienie ponad dwustu (1999: sześciuset) programistów, którzy dołożyli swój fragment kodu do fetchmaila! Być może kultura open source zwycięży kiedyś nie dlatego, że współpraca jest rzeczą moralnie właściwą, albo że "ukrywanie"{23} oprogramowania jest moralnie złe (zakładając, że się w nie wierzy - ani ja, ani Linus nie wierzymy), ale dlatego, że świat zamkniętych źródeł nie może wygrać ewolucyjnego wyścigu zbrojeń ze wspólnotami open source, które mogą poświęcić rząd wielkości więcej czasu specjalistów na rozwiązywanie problemów. O zarządzaniu i linii Maginota Pierwotna wersja tego eseju kończyła sie powyższą wizją - wizją tłumów programistów-anarchistów połączonych siecią, pokonujących i przejmujących hierarchiczny świat zamkniętego oprogramowania. Nie udało mi się jednak przekonać wielu sceptyków, zaś zadawane przez nich pytania zasługują na uwagę. Większość zastrzeżeń w stosunku do bazarowego modelu sprowadzało się do stwierdzenia, że jego protagoniści nie doceniają zwiększającego produktywność efektu konwencjonalnego zarządzania. Tradycyjni menedżerowie odpowiedzialni za zarządzanie projektami programistycznymi często wysuwają zastrzeżenie, że przypadkowość w formowaniu się, przemianach i zaniku grup projektowych w świecie open source niweluje znaczną część widocznej przewagi liczebnej, którą społeczność open source ma nad którymkolwiek pojedynczym programistą zamkniętego projektu. Twierdzą, że w procesie rozwoju oprogramowania najbardziej liczy się ciągły wysiłek oraz spełnienie oczekiwań klientów, którzy liczą na ciągły rozwój produktu, a nie tylko to, ilu ludzi wrzuciło kość do garnka, by się ugotowała. Z pewnością jest cos w tym rozumowaniu; zresztą więcej na temat teorii mówiącej o kluczowej roli wartości oczekiwanych usług dla gospodarki produkcji oprogramowania można znaleźć w innym eseju w tej książce - w Magicznym Kotle W rozumowaniu tym tkwi jednak pewien błąd: zakłada ono, że proces rozwoju oprogramowania open source nie potrafi zapewnić takiego ciągłego wysiłku. Jednakże mamy przykłady projektów open source, które przez długi czas utrzymywały spójną wizję i wspólnotę programistów, nie potrzebując struktur ani kontroli instytucjonalnej, tak istotnych w konwencjonalnym zarządzaniu. Rozwój edytora GNU Emacs jest niezwykłym i pouczającym przykładem - w ciągu ponad piętnastu lat wchłonął wysiłki setek programistów, przy zachowaniu spójnej wizji architektonicznej, mimo tego, że tylko jedna osoba (autor Emacsa) była aktywna przez cały ten czas, zaś rotacja był spora. Żaden zamknięty edytor nie może pochwalić się podobną długowiecznością. W związku z tym można sie pokusić o zakwestionowanie zalet tradycyjnego zarządzania rozwojem oprogramowania, w oderwaniu od reszty argumentów w dyskusji katedra - bazar. Jeśli jest możliwe, by GNU Emacs przez ponad piętnaście lat zachował spójną wizję architektoniczną, by system operacyjny Linux nie zmienił jej w ciągu ośmiu lat, mimo ogromnych przemian sprzętowych i technologicznych, jeśli istnieją (a rzeczywiście istnieją) projekty open source trwające ponad pięć lat - mamy wszelkie prawo się dziwić, co otrzymujemy w zamian za ogromne koszty stałe związane z tradycyjnym, konwencjonalnym sposobem zarządzania procesem rozwoju oprogramowania. Cokolwiek by to nie było, na pewno nie jest to zakończenie projektu w terminie, zmieszczenie się w budżecie czy spełnienie wszystkich wymagań specyfikacji; rzadko który ze "sterowanych" projektów spełnia choćby jeden z wymienionych warunków, co dopiero wszystkie trzy. Nie jest to również zdolność do przystosowania się do zmian technologicznych i gospodarczych w czasie pracy nad projektem: społeczności open source wychodzi oto o wiele lepiej (co można łatwo zweryfikować porównując np. trzydziestoletnia historię Internetu z krótkotrwałymi projektami komercyjnych technologii sieciowych, lub

16 też koszt przejścia z 16-bitowego do 32-bitowego kodu w Microsoft Windows z niemal bezwysiłkową migracją Linuksa w tym samym okresie - nie tylko po linii rozwojowej Intela, lecz również w kilkunastu innych architekturach sprzętowych, włączając w to 64-bitowe procesory Alpha). Ludziom wydaje się, że tradycyjny model zapewnia jedną rzecz: ktoś bierze na siebie odpowiedzialność i można od niego uzyskać rekompensatę, jeśli projekt nie wypali. Jest to jednak iluzja, ponieważ większość licencji na oprogramowanie nie zawiera w sobie gwarancji handlowych, nie wspominając o gwarancji działania, zaś przypadki odzyskania pieniędzy za niedziałające oprogramowanie są coraz rzadsze. A jeśli nawet byłyby częste, zadowolenie płynące z poczucia, że można kogoś ścigać na drodze sądowej to niezrozumienie istoty rzeczy. Nie zależy nam na procesach sądowych - chcemy mieć działające oprogramowanie. Cóż więc otrzymujemy w zamian za koszt stałe związane z tradycyjnym zarządzaniem rozwojem oprogramowania? Aby uzyskać odpowiedź na to pytanie, musimy najpierw uświadomić sobie zadania, które - w ich mniemaniu - spełniają menedżerowie projektów programistycznych. Znana mi kobieta, która wydaje się bardzo dobra w swoim fachu, uważa, że zarządzanie projektami programistycznymi polega na wypełnianiu pięciu funkcji: - Zdefiniowanie celów i pilnowanie, by wszyscy zmierzali w tym samym kierunku. - Monitorowanie i pilnowanie, by nie pominięto najistotniejszych szczegółów. - Motywowanie innych do wykonywanie nudnej, lecz nieuniknionej pracy. - Organizacja pracy ludzi w celu uzyskania najlepszych rezultatów. - Organizacja zasobów niezbędnych dla utrzymania projektu. Wszystkie z wymienionych celów wydają się znaczące, jednak w modelu open source i otaczającym go kontekście społecznym stają się dziwnie mało istotne. Omówimy każdy z nich, zaczynając od ostatniego. Moja znajoma twierdzi, że spora część tego, co przypada na organizację zasobów ma naturę obronną: mając już ludzi, komputery i przestrzeń biurową, należy ich bronić przed menedżerami tego samego szczebla mającymi na nie ochotę, oraz tymi wyżej w hierarchii, próbującymi jak najbardziej wykorzystać ograniczone zasoby. Jednakże deweloperzy projektów open source są ochotnikami: wybrali sami siebie według zainteresowań i możliwości pracy nad projektami (co zazwyczaj ma również miejsce nawet wtedy, kiedy płaci im się pensję za pracę nad projektami open source). Etos ochotnika pozwala automatycznie zadbać o aspekt "ataku" w organizacji zasobów: każdy kładzie na stół własne zasoby. Nie ma natomiast potrzeby (a jeśli jest, to niewielka), by osoba koordynująca projekt "bawiła się w obronę" w konwencjonalnym znaczeniu. Tak czy inaczej w świecie tanich komputerów PC i szybkich łączy internetowych coraz wyraźniej widać, że jedynym ograniczeniem związanym z zasobami jest uwaga utalentowanych osób. Projekty open source powstają nie z chęci zdobycia maszyn, łączy czy przestrzeni biurowej, zaś upadają jedynie wtedy, kiedy programiści przestają się nimi interesować. Z tego też powodu podwójne znaczenie ma fakt, że hakerzy open source organizują się sami, dobierając się w taki sposób, by osiągnąć maksimum produktywności, zaś środowisko dokonuje bezlitosnej selekcji kierując się kryterium kompetencji. Moja znajoma, znająca zarówno świat open source jak i duże, zamknięte projekty, uważa że open source zawdzięcza swój sukces częściowo temu, że jego kultura akceptuje jedynie najbardziej utalentowane 5 procent populacji programistów. Większość czasu upływa jej na organizowaniu pozostałych 95 procent, więc może bezpośrednio zaświadczyć o dobrze znanej, stukrotnej różnicy w produktywności między najzdolniejszymi a jedynie kompetentnymi programistami. Ustalenie tej różnicy zawsze wywoływało niezręczne pytanie: czy nie byłoby lepiej pojedynczym projektom, jak również całemu światu programistycznemu, gdyby pozbyć się ponad 50 procent najmniej kompetentnych? Rozsądni menedżerowie już dawno zrozumieli, że gdyby jedyną funkcją konwencjonalnego zarządzania projektami programistycznymi była przemiana rezultatów pracy najmniej zdolnych z czystej straty w marginalny zysk, gra mogłaby nie być warta świeczki.

17 Sukces odniesiony przez społeczność open source uczynił to pytanie jeszcze bardziej wyraźnym, dostarczając jasnych dowodów na to, że często taniej i efektywniej jest dokonać rekrutacji ochotników z Internetu niż zarządzać budynkami pełnymi ludzi, którzy woleliby robić co innego. W ten sposób doszliśmy do kwestii motywacji. Często można usłyszeć odpowiednik wypowiedzi mojej znajomej: tradycyjne zarządzanie projektami jest niezbędne, by zrekompensować kiepsko umotywowanych programistów, którzy w przeciwnym wypadku nie byliby w stanie wytworzyć dobrych rezultatów. Podobnym wypowiedziom towarzyszy często stwierdzenie, że społeczność open source potrafi pracować jedynie nad projektami, które są "sexy" lub technicznie atrakcyjne; cała reszta pozostanie niezrobiona (lub zrobiona kiepsko), chyba, że wykona ją drużyna zdyscyplinowanych, pragnących zarobić gryzipiórków, poganianych biczem stojących nad nimi menedżerów. Swoje obiekcje natury psychologicznej i społecznej w stosunku do tego typu twierdzeń przedstawiłem w Homesteading the Noosphere. Jednak dla celów niniejszych rozważań, uznanie tego stwierdzenia za prawdziwe będzie miało bardziej interesujące implikacje. Jeśli konwencjonalny, zamknięty, silnie sterowany styl rozwoju oprogramowania broni się jedynie swego rodzaju linią Maginota - linią problemów prowadzących do nudy, to obrona ta będzie miała sens w każdej dziedzinie zastosowań tak długo, jak problemy te będą uznawane za nudne i nikt nie znajdzie sposobu, by je obejść. jednak w chwili, kiedy pojawi się konkurencja open source dla "nudzącego" programu, klienci zorientują się, że ktoś w końcu zabrał się za rozwiązywanie danego problemu z powodu fascynacji samym problemem, co w programowaniu jak i innych dziedzinach pracy twórczej, okazuje się o wiele lepszym czynnikiem motywacyjnym niż same pieniądze. Dlatego korzystanie z konwencjonalnego zarządzania jedynie w celu motywowania zespołu jest być może dobrą taktyką, ale złą strategią - krótkoterminowym zwycięstwem, lecz na dłuższą metę pewną stratą. Jak dotąd konwencjonalne zarządzanie rozwojem projektów wydaje się być na gorszej pozycji w stosunku do open source z dwóch powodów (organizacji zasobów i pracy ludzi), zaś jeśli chodzi o trzeci punkt (motywację), dni tradycyjnych poglądów na ten temat są policzone. Biednemu, wciąż atakowanemu konwencjonalnemu zarządzaniu nie przyjdzie w sukurs kwestia monitorowania, bowiem najsilniejszym argumentem społeczności open source jest tryumf zdecentralizowanej weryfikacji przez osoby współpracujące nad wszelkimi konwencjonalnymi metodami, mającymi zapewnić brak pomyłek w szczegółach. Czy więc definiowanie celów zdoła usprawiedliwić koszty stałe związane z konwencjonalnym zarządzaniem projektami programistycznymi? Być może; jednak by tak stwierdzić, musielibyśmy mieć dobry powód by wierzyć, że komitetom zarządzającym i korporacyjnym wytycznym lepiej udaje się zdefiniować wartościowe, wspólne cele, niż liderom projektów i plemiennej starszyźnie, którzy spełniają analogiczną rolę w świecie open source. A tego typu stwierdzenie byłoby bardzo trudno obronić. I to nie ze względu na przewagę open source (długowieczność Emacsa, talent Linusa Torvaldsa do mobilizacji tłumów deweloperów pod hasłem "dominacji nad światem"), a raczej z powodu widocznej słabości konwencjonalnych mechanizmów definiowania celów projektów programistycznych. Jednym z najbardziej znanych truizmów w inżynierii oprogramowania jest fakt, że 60-75% konwencjonalnych projektów programistycznych albo nie zostaje zakończonych, albo zostaje odrzuconych przez grupy docelowych użytkowników. Jeśli statystyki są choć w przybliżeniu prawdziwe (a nigdy nie spotkałem doświadczonego menedżera, który próbowałby je podważać), to przed większością projektów stawia się cela, które są albo (a) nierealistyczne, lub (b) po prostu błędne. Głównie z tego powodu w dzisiejszym świecie inżynierii oprogramowania samo wyrażenie "komitet zarządzający" potrafi wywołać u odbiorcy ciarki na całym ciele, nawet (albo szczególnie wtedy), kiedy słuchaczem jest menedżer. Czasy, kiedy tylko programiści zrzędzili z tego powodu, nalezą już do przeszłości; komiksy z Dilbertem wiszą obecnie nad biurkami dyrektorów. Nasza odpowiedź udzielona menedżerowi zarządzającymi projektami w tradycyjny sposób jest prosta: jeśli społeczność open source rzeczywiście nie doceniła wartość konwencjonalnego zarządzania projektami, dlaczego tak wielu z was ma tak niskie mniemanie o stosowanych przez was procesach? I ponownie istnienie społeczności open source znacznie zwiększa ciężar tego pytania, ponieważ praca nad projektami open source nas bawi. Nasza kreatywna zabawa w zawrotnym tempie zdobywa rynek i

18 umysły i okazuje się sukcesem technologicznym. Udowadniamy, że potrafimy tworzyć lepsze oprogramowanie, zaś radość jest atutem. Dwa i pół roku po napisaniu pierwszej wersji tego eseju nie zakończę go wizją świata zdominowanego przez open source - najbardziej radykalną myślą, którą wówczas mógł stworzyć mój umysł: wizję tę bowiem akceptuje już wielu statecznych ludzi w garniturach. Zamiast owej wizji chciałbym przedstawić głębszą lekcję dotyczącą oprogramowania (a prawdopodobnie i wszelkiej pracy - twórczej czy zawodowej). Ludzie zazwyczaj znajdują przyjemność w zadaniach, które znajdują się w sferze "optymalnego wyzwania": nie zbyt łatwych, by się nie zanudzić - nie zbyt trudnych, by można było osiągnąć cel. Szczęśliwy programista to taki, który nie jest ani niewykorzystywany, a nie nie przytłoczony ciężarem źle sformułowanych celów i stresującego tarcia tworzącego się w procesie tworzenia. Radość źródłem wydajności. Dlatego odnoszenie się do własnego procesu pracy z uczuciem strachu i obrzydzenia (nawet w sposób oderwany i ironiczny, który sugeruje rozwieszanie komiksów z Dilbertem) powinno się uważać za znak, że proces ten zakończył się niepowodzeniem. Radość, humor i poczucie zabawy są prawdziwymi atutami - nie przypadkiem wspomniałem wcześniej o "szczęśliwych zastępach" programistów; nie bez znaczenia jest fakt, że maskotką Linuksa jest figlarny pingwin o dziecięcej buzi. Zrozumienie przez nas faktu, że zabawa jest najbardziej wydajnym ekonomicznie sposobem pracy twórczej, może sie okazać jedną z najważniejszych konsekwencji sukcesu open source. Epilog: Netscape wychodzi na bazar To dziwne odczucie - uświadomić sobie, że pomaga się tworzyć historię stycznia 1998 roku, około 7 miesięcy po pierwszej publikacji Katedry i bazaru, Netscape Communications ogłosił plan udostępnienia źródeł Netscape Communicatora (http://www.netscape.com/newsref/pr/newsrelease558.html). Dowiedziałem się o tym dopiero w chwili ogłoszenia. Wkrótce po tym otrzymałem a od Erica Hahna, wiceprezesa i szefa działu technologii w Netscape, w którym przeczytałem: "Przede wszystkim chciałbym w imieniu wszystkich tu w Netscape podziękować Panu za pomoc w dotarciu do miejsca, w którym się znajdujemy. Pana myśl i eseje były główną inspiracją naszej decyzji". Tydzień później odwiedziłem Krzemową Dolinę na zaproszenie Netscape, by uczestniczyć w jednodniowej konferencji strategicznej (4 lutego 1998 roku) wraz z kluczowymi postaciami z kadry zarządzającej i technicznej firmy. Wspólnie ustaliliśmy strategie udostępniania źródeł i licencję. Kilka dni później napisałem co następuje: Niedługo dane nam będzie dzięki Netscape przejść prawdziwy, znaczący test modelu bazarowego w świecie komercyjnym. Kultura open source stoi dziś w obliczu niebezpieczeństwa; jeśli projekt Netscape nie wypali, koncepcja open source może zostać tak zdyskredytowana, że świat biznesu nie dotknie jej przez następne 10 lat. Z drugiej strony test ten jest również dla nas wielką okazją. Początkowe reakcje na Wall Street i gdzie indziej były ostrożnie pozytywne. Nam tez dano możliwość wykazania się. Jeśli Netscape uda się dzięki temu ruchowi zdobyć znaczący segment rynku, może to być początek długo oczekiwanej rewolucji wśród producentów oprogramowania. Następny rok zapowiada się bardzo pouczająco i ciekawie. Tak tez się stało. Kiedy piszę ten tekst w połowie roku 1999, rozwój projektu, który później nazwano Mozillą, został uznany za udany. Udało się osiągnąć pierwotny cel Netscape, polegający na przeciwstawieniu się monopolowi Microsoftu na rynku przeglądarek internetowych. Odniesiono też kilka sporych sukcesów (zwłaszcza w związku z udostępnieniem silnika renderującego następnej generacji, Gecko). Nie udało się jednak zjednoczyć tyle grupowego wysiłku z zewnątrz Netscape, na ile liczyli twórcy projektu Mozilla. Problem leżał w tym, że przez długi czas dystrybucja Mozilli łamała jedną z podstawowych zasad modelu bazarowego: nie udostępnili niczego, co potencjalni współtwórcy mogliby łatwo uruchomić i obejrzeć w działaniu. (Ponad rok po udostępnieniu pierwszej wersji zbudowanie Mozilli ze źródeł wymagało licencji na komercyjna bibliotekę Motif.)

19 Najgorsze (z punktu widzenia świata zewnętrznego) jest to, że zespół rozwijający Mozillę ma udostępnić przeglądarkę internetową dobrej jakości, zaś jedna z głównych osób uczestniczących w projekcie wywołała pewną sensację swoją rezygnacją, narzekając na złe zarządzanie i utracone możliwości. "Open source", jak słusznie zauważyła, "nie jest magiczną różdżką". I nie powinno być. Długoterminowe prognozy dotyczące rozwoju Mozilli wyglądają teraz (sierpień 1999) nieco lepiej niż w chwili rezygnacji Jamie Zawinsky'ego - miał on jednak rację mówiąc, że otwarcie się niekoniecznie ochroni istniejące projekty cierpiące z powodu źle określonych celów, bałaganiarskiego kodu i innych chronicznych dolegliwości znanych inżynierii oprogramowania. Mozilla jest przykładem tego, że projekt open source może się udać lub nie. W międzyczasie idea open source odniosła duży sukces i znalazła wielu zwolenników na całym świecie. W 1998 i pod koniec 1999 byliśmy świadkami eksplozji zainteresowania modelem rozwoju open source, który to trend zarówno kierował jak i był kierowany sukcesem systemu operacyjnego Linux. Trend, który zapoczątkowała Mozilla, rozwija się w coraz szybszym tempie. Tłumaczenie: Artur Skura, kwiecień 2001 r. Korekta: Little Snake Przypisy: {1} hack -- (inteligentna) sztuczka (programistyczna); bardzo specyficzne słowo, używanie niemal wyłącznie w kulturze hakerskiej. Jako rzeczownik oznacza sztuczkę programistyczną, sprytne rozwiązanie w kodzie źródłowym programu; czasownik odnosi się do programowania, jednak nie chodzi tu o bezmyślne wpisywanie kodu, lecz wysokiej jakości pracę twórczą. {2} GNU - skrót od "GNU is Not Unix", projekt całkowicie darmowego systemu operacyjnego zgodnego z systemem UNIX, rozpoczęty przez Richarda M. Stallmana w 1983 roku. Większość oprogramowania rozprowadzanego wraz z Linuksem stanowi część projektu GNU. Programy tworzone w ramach projektu GNU są udostępniane na licencji GPL (GNU Public License), dzięki której użytkownicy mogą swobodnie używać, modyfikować i rozpowszechniać zmodyfikowane kopie programów. Więcej informacji o projekcie GNU można uzyskać na stronach {3} nethack - bodaj najpopularniejsza tekstowa gra przygodowa. {4} Emacs - jeden z dwóch najpopularniejszych edytorów tekstowych dla systemów uniksowych (w tym Linuksa). Zaprojektowany przez Richarda M. Stallmana i będący częścią projektu GNU, Emacs stał się popularny dzięki niespotykanej elastyczności, licznym ułatwieniom dla programistów i przyjaznemu interfejsowi. {5} ISP - Internet Service Provider, firma lub instytucja oferująca dostęp do Internetu. {6} SLIP - Serial Line Internet Protocol, protokół odpowiedzialny za przesyłanie pakietów IP przez port szeregowy, a więc również przez modem. Obecnie używa się do tego celu protokołu PPP (Point-to-Point Protocol). {7} Sendmail - najpopularniejszy uniksowy serwer poczty elektronicznej (MTA). {8} Adres IP - adres komputera, dzięki któremu jest widoczny w sieci. Statyczny adres IP jest niezmienny, natomiast dynamiczny jest przydzielany zwykle na czas połączenia. {9} Minix, stworzony w celach edukacyjnych przez prof. A. Tenenbauma, znanego specjalisty od systemów operacyjnych, został niedawno udostępniony na licencji open source. W linuksowych archiwach zachowały się interesujące dyskusje Linusa Torvaldsa z prof. Tenebaumem, m.in. znana wypowiedź "gdyby był Pan moim studentem, za ten projekt dostałby Pan dwóję"... {10} Wymienione systemy kontroli wersji pomagają programistom w dokumentacji pracy nad programem, unikaniu pomyłek oraz trzymaniu porządku w kodzie. Ostatni z nich, CVS, jest powszechnie stosowany w wielu projektach open source jako narzędzie wspomagające pracę grupową. Dzięki niemu wiele osób może pracować równocześnie nad jednym projektem nie przeszkadzając sobie nawzajem. {11} Wynika to z założeń projektu GNU, chroniących użytkowników przed próbami zawłaszczenia kodu przez autorów, którzy po pewnym czasie mogliby zmienić zdanie, ich spadkobierców itd. {12} betatesterzy - osoby testujące wersje oprogramowania zwane "beta", tj. jeszcze nie gotowe, udostępniane w celu eliminacji błędów (praktyka ta jest powszechna wśród wielu producentów oprogramowania, nawet nie mających wiele wspólnego z Open Source, np. Adobe czy Microsoft). Wersje zwane "alfa" to aplikacje w bardzo wczesnym stadium rozwoju, użyteczne zwykle jedynie dla programistów. W świecie Open Source wersje alfa można zwykle rozpoznać po numerze wersji mniejszym od 1 (np. Xdialog 0.12), zaś wersje beta mają często nieparzysty numer podwersji (np. gtk , linux ). {13}poprawki - chodzi o tzw. łaty (patches), czyli zapisany w specjalnym formacie plik zawierający różnice między dwoma plikami czy zestawami plików, przy czym najczęściej chodzi o pliki źródłowe. Dzięki "zaaplikowaniu łaty" stary plik staje się identyczny z nowym.

20 Jest to bardzo ekonomiczne rozwiązanie, zwłaszcza w przypadku, kiedy cały kod źródłowy ma ogromne rozmiary, zaś wprowadzane zmiany są niewielkie. Łaty są najpopularniejszą metodą wprowadzania zmian w społeczności Open Source również z tego powodu, że kilka osób może wprowadzić kilka różnych usprawnień do tego samego pliku nie powodując żadnych konfliktów. {14} SMTP - Simple Mail Transmission Protocol, protokół wykorzystywany do wysyłania poczty (podczas gdy POP czy IMAP służą do odbierania jej). Protokół ten jest szczegółowo opisany w dokumencie RFC 821. {15} Perl - potężny, skryptowy język programowania, używany przez programistów na całym świecie (również przy budowie serwisów WWW). {16} OK - kod zwracany przez demona SMTP, jeśli operacja zakończyła się sukcesem. Protokół SMTP (jak i wiele innych protokołów internetowych) przypomina dialogi w języku angielskim. Klient komunikuje się z serwerem począwszy od komunikatu HELO (lub EHLO), zaś serwer odpowiada komunikatem OK lub ERR (po którym opcjonalnie mogą wystąpić inne informacje, wskazujące np. na przyczynę błędu). Dialog ten można ujrzeć wywołując fetchmaila z opcją -v. {17} man - w systemach uniksowych programom (i nie tylko - dotyczy to również m.in. funkcji systemowych i plików konfiguracyjnych) towarzyszą pliki pomocy, zwane man (od angielskiego manual - podręcznik). I tak chcąc uzyskać pomoc na temat fetchmaila, wystarczy napisać man fetchmail, a wyświetli się strona podręcznika, wyjaśniając a sposób korzystania z fetchmaila. {18} odpluskwianie (debugging) - proces znajdowania błędów w programie, polegający zazwyczaj na żmudnej analizie kodu, uruchamianiu programu z różnymi parametrami i testowaniu w różnych sytuacjach przy wykorzystaniu różnych narzędzi, zwanych debuggerami. {19} aliasy - alternatywne nazwy. Serwery pocztowe korzystają zazwyczaj ze specjalnych plików, zawierających symboliczną nazwę (czyli alias) wraz z przypisanymi rzeczywistymi adresami jednego lub więcej użytkowników. Dzięki temu użytkowni jkowal może otrzymywać pocztę wysyłaną na adres Jeśli użytkowników skojarzonych z danym aliasem jest więcej, powstaje prymitywna lista dyskusyjna, tj. każdy list wysłany na ów adres dociera do wszystkich użytkowników skojarzonych z aliasem. {20} pliki rc - pliki konfiguracyjne, których nazwa zazwyczaj ma końcówkę rc (w przypadku fetchmaila jest to.fetchmailrc), przechowujące opcje konfiguracyjne {21} zapewnienie bezpieczeństwa przez niejawność (security by obscurity) - metoda zapewniania bezpieczeństwa polegająca na ukrywaniu ustawień systemowych, konfiguracji itp., próbując wprowadzić atakującego w błąd. Metoda ta jest bardzo nisko oceniana przez ekspertów od zabezpieczeń, zwłaszcza jeśli jest jedynym zabezpieczeniem systemu. {22} UNIX powstał w Bell Labs (obecie Lucent); Richard Stallman, lider projektu GNU i główny twórca najważniejszego narzędzia używanego przez programistów linuksowych - kompilatora gcc, rozpoczął swoją działalność i przez pewien czas kontynuował ją w Laboratorium AI Massachusetts Institute of Technology; na uniwersytecie Berkeley powstało wiele narzędzi oraz kod różnych usług sieciowych. {23} ukrywanie/strzeżenie kodu źródłowego oprogramowania (software hoarding) - termin używany przez Richarda Stallmana w stosunku do firm udostępniających jedynie wynikowe, binarne wersje programów. Znaleźć go można np. w słynnym "Hymnie hackerów" ("Hoarders may have piles of money, this is true, hackers, this is true...").

Test mocny stron. 1. Lubię myśleć o tym, jak można coś zmienić, ulepszyć. Ani pasuje, ani nie pasuje

Test mocny stron. 1. Lubię myśleć o tym, jak można coś zmienić, ulepszyć. Ani pasuje, ani nie pasuje Test mocny stron Poniżej znajduje się lista 55 stwierdzeń. Prosimy, abyś na skali pod każdym z nich określił, jak bardzo ono do Ciebie. Są to określenia, które wiele osób uznaje za korzystne i atrakcyjne.

Bardziej szczegółowo

Program Coachingu dla młodych osób

Program Coachingu dla młodych osób Program Coachingu dla młodych osób "Dziecku nie wlewaj wiedzy, ale zainspiruj je do działania " Przed rozpoczęciem modułu I wysyłamy do uczestników zajęć kwestionariusz 360 Moduł 1: Samoznanie jako część

Bardziej szczegółowo

Autor: Przemysław Jóskowiak. Wydawca: Stratego24 Przemysław Jóskowiak ul. Piękna 20, 00-549 Warszawa. Kontakt: kontakt@stratego24.

Autor: Przemysław Jóskowiak. Wydawca: Stratego24 Przemysław Jóskowiak ul. Piękna 20, 00-549 Warszawa. Kontakt: kontakt@stratego24. Autor: Przemysław Jóskowiak 2 Wydawca: Stratego24 Przemysław Jóskowiak ul. Piękna 20, 00-549 Warszawa Kontakt: kontakt@stratego24.pl Treści prezentowane w ramach tej publikacji są subiektywną oceną autora

Bardziej szczegółowo

System zarządzający grami programistycznymi Meridius

System zarządzający grami programistycznymi Meridius System zarządzający grami programistycznymi Meridius Instytut Informatyki, Uniwersytet Wrocławski 20 września 2011 Promotor: prof. Krzysztof Loryś Gry komputerowe a programistyczne Gry komputerowe Z punktu

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Studia podyplomowe dla nauczycieli INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Przedmiot JĘZYKI PROGRAMOWANIA DEFINICJE I PODSTAWOWE POJĘCIA Autor mgr Sławomir Ciernicki 1/7 Aby

Bardziej szczegółowo

Prosty CRM online. Dbaj o zadowolenie klientów, zwiększ sprzedaż, załatw sprawy do końca. Zarządzanie kontaktami. Interesy i zadania

Prosty CRM online. Dbaj o zadowolenie klientów, zwiększ sprzedaż, załatw sprawy do końca. Zarządzanie kontaktami. Interesy i zadania Prosty CRM online Dbaj o zadowolenie klientów, zwiększ sprzedaż, załatw sprawy do końca Zarządzanie kontaktami Interesy i zadania Dostosuj do potrzeb Zalety CRM online Pomoc i dokumentacja Przenieś relacje

Bardziej szczegółowo

Rozmowa ze sklepem przez telefon

Rozmowa ze sklepem przez telefon Rozmowa ze sklepem przez telefon - Proszę Pana, chciałam Panu zaproponować opłacalny interes. - Tak, słucham, o co chodzi? - Dzwonię w imieniu portalu internetowego AmigoBONUS. Pan ma sklep, prawda? Chciałam

Bardziej szczegółowo

FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL 7.5.60

FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL 7.5.60 FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL 7.5.60 W KAMELEON.SQL 7.5.60 została dodana funkcjonalność klasy B2B (na tą funkcjonalność wymagana jest dodatkowa licencja, którą można wykupić w naszej firmie)

Bardziej szczegółowo

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny?

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny? Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA Dlaczego DNS jest tak ważny? DNS - System Nazw Domenowych to globalnie rozmieszczona usługa Internetowa. Zapewnia tłumaczenie nazw domen

Bardziej szczegółowo

Aby otrzymać ocenę BARDZO DOBRĄ, uczeń:

Aby otrzymać ocenę BARDZO DOBRĄ, uczeń: WYMAGANIA EDUKACYJNE JĘZYK ANGIELSKI W KLASACH IV-VI SZKOŁA PODSTAWOWA NR 13 W SIEMIANOWICACH ŚLĄSKICH Aby otrzymać ocenę BARDZO DOBRĄ, uczeń: Gramatyka i słownictwo: Potrafi poprawnie operować prostymi

Bardziej szczegółowo

SYSTEMY OPERACYJNE I SIECI KOMPUTEROWE

SYSTEMY OPERACYJNE I SIECI KOMPUTEROWE SYSTEMY OPERACYJNE I SIECI KOMPUTEROWE WINDOWS 1 SO i SK/WIN 007 Tryb rzeczywisty i chroniony procesora 2 SO i SK/WIN Wszystkie 32-bitowe procesory (386 i nowsze) mogą pracować w kilku trybach. Tryby pracy

Bardziej szczegółowo

Słownictwo: umiejętność radzenia sobie w codziennych sytuacjach, odpowiedni dobór słownictwa, odpowiedni zakres słownictwa.

Słownictwo: umiejętność radzenia sobie w codziennych sytuacjach, odpowiedni dobór słownictwa, odpowiedni zakres słownictwa. język francuski, klasy: 4 6 Zgodnie z WZO, śródroczne i roczne oceny z języka francuskiego w klasach IV VI wyrażone są stopniem w następującej skali: stopień celujący 6, stopień bardzo dobry 5, stopień

Bardziej szczegółowo

World Wide Web? rkijanka

World Wide Web? rkijanka World Wide Web? rkijanka World Wide Web? globalny, interaktywny, dynamiczny, wieloplatformowy, rozproszony, graficzny, hipertekstowy - system informacyjny, działający na bazie Internetu. 1.Sieć WWW jest

Bardziej szczegółowo

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających

Bardziej szczegółowo

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Ogólne zasady projektowania algorytmów i programowania

Ogólne zasady projektowania algorytmów i programowania Ogólne zasady projektowania algorytmów i programowania Pracuj nad właściwie sformułowanym problemem dokładna analiza nawet małego zadania może prowadzić do ogromnych korzyści praktycznych: skrócenia długości

Bardziej szczegółowo

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji HumanTechnology Projektowanie interakcji czyli łatanie dziury w procesie produkcji Czym jest projektowanie interakcji? Projektowanie interakcji, czyli współdziałania człowieka z komputerem, wykorzystuje

Bardziej szczegółowo

Komputer nie myśli. On tylko wykonuje nasze polecenia. Nauczmy się więc wydawać mu rozkazy

Komputer nie myśli. On tylko wykonuje nasze polecenia. Nauczmy się więc wydawać mu rozkazy Programowanie w C++ 1.Czym jest programowanie Pisanie programów to wcale nie czarna magia, tylko bardzo logiczna rozmowa z komputerem. Oczywiście w jednym ze specjalnie stworzonych do tego celu języków.

Bardziej szczegółowo

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych

Bardziej szczegółowo

Konfiguracja programu pocztowego dla kont w domenie spcsk.pl

Konfiguracja programu pocztowego dla kont w domenie spcsk.pl dla kont w domenie spcsk.pl 24 lutego 2012 Spis treści 1 Informacje ogólne 1 2 Konfiguracja programu Mozilla Thunderbird 2 3 Konfiguracja innych klientów poczty 10 4 Pytania i odpowiedzi 10 1 Informacje

Bardziej szczegółowo

WYMAGANIA EDUKACYJNE Z ZAJĘĆ KOMPUTEROWYCH W KLASIE 4 SZKOŁY PODSTAWOWEJ

WYMAGANIA EDUKACYJNE Z ZAJĘĆ KOMPUTEROWYCH W KLASIE 4 SZKOŁY PODSTAWOWEJ WYMAGANIA EDUKACYJNE Z ZAJĘĆ KOMPUTEROWYCH W KLASIE 4 SZKOŁY PODSTAWOWEJ 1. W ZAKRESIE BEZPIECZNEGO POSŁUGIWANIA SIĘ KOMPUTEREM I OPROGRAMOWANIEM UCZEŃ: przestrzega podstawowych zasad bezpiecznej i higienicznej

Bardziej szczegółowo

Zacznijmy więc pracę z repozytorium. Pierwsza konieczna rzecz do rozpoczęcia pracy z repozytorium, to zalogowanie się w serwisie:

Zacznijmy więc pracę z repozytorium. Pierwsza konieczna rzecz do rozpoczęcia pracy z repozytorium, to zalogowanie się w serwisie: Repozytorium służy do przechowywania plików powstających przy pracy nad projektami we w miarę usystematyzowany sposób. Sam mechanizm repozytorium jest zbliżony do działania systemu plików, czyli składa

Bardziej szczegółowo

PRZEDMIOTOWE ZASADY OCENIANIA

PRZEDMIOTOWE ZASADY OCENIANIA PRZEDMIOTOWE ZASADY OCENIANIA JĘZYK ANGIELSKI klasy IV - VI Opracowanie: Katarzyna Drożdżal Przedmiotowe zasady oceniania z języka angielskiego opracowano na podstawie: Statutu Szkoły Podstawowej im. Karola

Bardziej szczegółowo

HumanWork - Produkt, który spełnia Twoje oczekiwania

HumanWork - Produkt, który spełnia Twoje oczekiwania HumanWork - Produkt, który spełnia Twoje oczekiwania Właśnie tak pracuję. Wykonuję zadania. HumanWORK włącza je w procesy przepływu pracy i obiegu dokumentów. Planuję zadania. HumanWORK przekazuje je we

Bardziej szczegółowo

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów

Bardziej szczegółowo

to jest właśnie to, co nazywamy procesem życia, doświadczenie, mądrość, wyciąganie konsekwencji, wyciąganie wniosków.

to jest właśnie to, co nazywamy procesem życia, doświadczenie, mądrość, wyciąganie konsekwencji, wyciąganie wniosków. Cześć, Jak to jest, że rzeczywistość mamy tylko jedną i czy aby na pewno tak jest? I na ile to może przydać się Tobie, na ile to może zmienić Twoją perspektywę i pomóc Tobie w osiąganiu tego do czego dążysz?

Bardziej szczegółowo

Liczą się proste rozwiązania wizyta w warsztacie

Liczą się proste rozwiązania wizyta w warsztacie Liczą się proste rozwiązania wizyta w warsztacie Szybciej poznaję ceny. To wszystko upraszcza. Mistrz konstrukcji metalowych, Martin Elsässer, w rozmowie o czasie. Liczą się proste rozwiązania wizyta w

Bardziej szczegółowo

DynaDo łączy i organizuje komunikację, zadania i dokumenty wokół klientów i projektów. Usprawnia pracę, zwiększa produktywność i ułatwia nadzór.

DynaDo łączy i organizuje komunikację, zadania i dokumenty wokół klientów i projektów. Usprawnia pracę, zwiększa produktywność i ułatwia nadzór. Connecting the Dots DynaDo łączy i organizuje komunikację, zadania i dokumenty wokół klientów i projektów. Usprawnia pracę, zwiększa produktywność i ułatwia nadzór. Obniża koszty, eliminuje frustracje

Bardziej szczegółowo

Samouczek Jak utworzyć e- portfolio

Samouczek Jak utworzyć e- portfolio Samouczek Jak utworzyć e- portfolio Drogi uczniu celem naszej zabawy jest utworzenie własnej strony w internecie, na której będą się znajdowały wytwory twojej pracy z lekcji fizyki. Mam nadzieję, że nie

Bardziej szczegółowo

AKADEMIA DLA MŁODYCH. Osiąganie celów. moduł 3 PODRĘCZNIK PROWADZĄCEGO. praca, życie, umiejętności. Akademia dla Młodych

AKADEMIA DLA MŁODYCH. Osiąganie celów. moduł 3 PODRĘCZNIK PROWADZĄCEGO. praca, życie, umiejętności. Akademia dla Młodych Osiąganie moduł 3 Temat 3, Poziom 1 PODRĘCZNIK PROWADZĄCEGO Akademia dla Młodych Moduł 3 Temat 3 Poziom 1 Zarządzanie czasem Przewodnik prowadzącego Cele szkolenia Efektywność osobista pozwala Uczestnikom

Bardziej szczegółowo

Serwer druku w Windows Server

Serwer druku w Windows Server Serwer druku w Windows Server Ostatnimi czasy coraz większą popularnością cieszą się drukarki sieciowe. Często w domach użytkownicy posiadają więcej niż jedno urządzenie podłączone do sieci, z którego

Bardziej szczegółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

Bardziej szczegółowo

Samokontrola postępów w nauce z wykorzystaniem Internetu. Wprowadzenie

Samokontrola postępów w nauce z wykorzystaniem Internetu. Wprowadzenie mgr Piotr Gaś, dr hab. inż. Jerzy Mischke Ośrodek Edukacji Niestacjonarnej Akademii Górniczo-Hutniczej w Krakowie Samokontrola postępów w nauce z wykorzystaniem Internetu Wprowadzenie W każdym systemie

Bardziej szczegółowo

6. Zarządzanie Projektami

6. Zarządzanie Projektami 6. Zarządzanie Projektami Wersja ucznia Wstęp 1. Proces Zarządzania Projektami 2. Zarządzanie ryzykiem "Zarządzanie projektami jest o wyznaczaniu jasnych celów, zarządzaniu czasem, zasobami, ludźmi i kosztami

Bardziej szczegółowo

Zmiana przekonań ograniczających. Opracowała Grażyna Gregorczyk

Zmiana przekonań ograniczających. Opracowała Grażyna Gregorczyk Zmiana przekonań ograniczających Opracowała Grażyna Gregorczyk Główny wpływ na nasze emocje mają nasze przekonania na temat zaistniałych faktów (np. przekonania na temat uprzedzenia do swojej osoby ze

Bardziej szczegółowo

LearnIT project PL/08/LLP-LdV/TOI/140001

LearnIT project PL/08/LLP-LdV/TOI/140001 LearnIT project PL/08/LLP-LdV/TOI/140001 Newsletter Issue 2 April 2009 Drogi czytelniku, Przedstawiamy z przyjemnością drugie wydanie biuletynu projektu LearnIT. W tym wydaniu chcemy powiedzieć więcej

Bardziej szczegółowo

Klient poczty elektronicznej

Klient poczty elektronicznej Klient poczty elektronicznej Microsoft Outlook 2010 wysyłaj i odbieraj pocztę elektroniczną, zarządzaj kalendarzem, kontaktami oraz zadaniami. Aplikacja Outlook 2010 to narzędzie spełniające wszystkie

Bardziej szczegółowo

JAK RADZIĆ SOBIE Z NASTOLATKIEM W SYTUACJACH KONFLIKTOWYCH?

JAK RADZIĆ SOBIE Z NASTOLATKIEM W SYTUACJACH KONFLIKTOWYCH? JAK RADZIĆ SOBIE Z NASTOLATKIEM W SYTUACJACH KONFLIKTOWYCH? Podstawowa zasada radzenia sobie w sytuacjach konfliktowych:,,nie reaguj, tylko działaj Rodzice rzadko starają się dojść do tego, dlaczego ich

Bardziej szczegółowo

PRACA DYPLOMOWA INŻYNIERSKA. Mobilny system wspomagający pracę. terminala kontenerowego

PRACA DYPLOMOWA INŻYNIERSKA. Mobilny system wspomagający pracę. terminala kontenerowego PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ PRACA DYPLOMOWA INŻYNIERSKA Mobilny system wspomagający pracę terminala kontenerowego autor: Bartłomiej Urbanowicz opiekun pracy:

Bardziej szczegółowo

Tytuł ogłoszenia ma znaczenie!

Tytuł ogłoszenia ma znaczenie! Tytuł ogłoszenia ma znaczenie! Dawałeś kiedyś ogłoszenie swojej firmy albo działalności? To nie popełniaj tego samego błędu co wszyscy! Przedstawię Tobie teraz sposób jak ustrzec się błędu który jest dość

Bardziej szczegółowo

Szczegółowy program - Szkoła Planowania Biznesu -

Szczegółowy program - Szkoła Planowania Biznesu - Szczegółowy program - Szkoła Planowania Biznesu - Przed seminarium otrzymasz bonusowe narzędzia w mailu: Przegląd najbardziej zyskownych branż i generatorów pomysłów na biznes dzięki temu otrzymasz inspirację

Bardziej szczegółowo

Co umieścić na stronie www, by klienci zostawiali nam swoje adresy email i numery telefonów

Co umieścić na stronie www, by klienci zostawiali nam swoje adresy email i numery telefonów Co umieścić na stronie www, by klienci zostawiali nam swoje adresy email i numery telefonów 5 krytycznych punktów strony www, w których klient decyduje: zostawiam im swój email i numer telefonu, lub zamykam

Bardziej szczegółowo

kilka definicji i refleksji na temat działań wychowawczych oraz ich efektów Irena Wojciechowska

kilka definicji i refleksji na temat działań wychowawczych oraz ich efektów Irena Wojciechowska kilka definicji i refleksji na temat działań wychowawczych oraz ich efektów Irena Wojciechowska Nasza ziemia jest zdegenerowana, dzieci przestały być posłuszne rodzicom Tekst przypisywany egipskiemu kapłanowi

Bardziej szczegółowo

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

PrestaShop. Sklep internetowy szyty na miarę

PrestaShop. Sklep internetowy szyty na miarę PrestaShop. Sklep internetowy szyty na miarę Autor: Witold Wrotek Książka dedykowana edycji programu 1.5.2.0. Własny sklep internetowy? Z PrestaShop to nic trudnego! Jak zbudować sklep internetowy, który

Bardziej szczegółowo

Generacja Y o mediach społecznościowych w miejscu pracy

Generacja Y o mediach społecznościowych w miejscu pracy Generacja Y o mediach społecznościowych w miejscu pracy Raport z badania Szymon Góralski Wrocław, 2013 ul. Więzienna 21c/8, 50-118 Wrocław, tel. 71 343 70 15, fax: 71 343 70 13, e-mail: biuro@rrcc.pl,

Bardziej szczegółowo

Podstawy pomagania. Natura dała nam dwoje oczu, dwoje uszu, ale tylko jeden język po to, abyśmy więcej patrzyli i słuchali, niż mówili.

Podstawy pomagania. Natura dała nam dwoje oczu, dwoje uszu, ale tylko jeden język po to, abyśmy więcej patrzyli i słuchali, niż mówili. Podstawy pomagania. Natura dała nam dwoje oczu, dwoje uszu, ale tylko jeden język po to, abyśmy więcej patrzyli i słuchali, niż mówili. (Sokrates) Czym jest pomaganie? Pomaganie jest działaniem, w które

Bardziej szczegółowo

1 Ojcostwo na co dzień. Czyli czego dziecko potrzebuje od ojca Krzysztof Pilch

1 Ojcostwo na co dzień. Czyli czego dziecko potrzebuje od ojca Krzysztof Pilch 1 2 Spis treści Wstęp......6 Rozdział I: Co wpływa na to, jakim jesteś ojcem?...... 8 Twoje korzenie......8 Stereotypy.... 10 1. Dziecku do prawidłowego rozwoju wystarczy matka.... 11 2. Wychowanie to

Bardziej szczegółowo

Cechy systemu X Window: otwartość niezależność od producentów i od sprzętu, dostępny kod źródłowy; architektura klient-serwer;

Cechy systemu X Window: otwartość niezależność od producentów i od sprzętu, dostępny kod źródłowy; architektura klient-serwer; 14.3. Podstawy obsługi X Window 14.3. Podstawy obsługi X Window W przeciwieństwie do systemów Windows system Linux nie jest systemem graficznym. W systemach Windows z rodziny NT powłokę systemową stanowi

Bardziej szczegółowo

Temat 12. Rozkaz Wykonać! Języki programowania

Temat 12. Rozkaz Wykonać! Języki programowania Temat 12 Rozkaz Wykonać! Języki programowania Streszczenie Do programowania komputerów używa się zazwyczaj informatycznego języka, który składa się ze słów-instrukcji zrozumiałych dla maszyn. Tym, co może

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Firmowe media społecznościowe dla pracowników

Firmowe media społecznościowe dla pracowników Firmowe media społecznościowe dla pracowników Raport z badania Maciej Dymalski, Szymon Góralski Wrocław, 2012 ul. Więzienna 21c/8, 50-118 Wrocław, tel. 71 343 70 15, fax: 71 343 70 13, e-mail: biuro@rrcc.pl,

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Ewolucyjna architektura

Ewolucyjna architektura Ewolucyjna architektura www.sxc.hu/photo/850368 Na początek Michał Bartyzel konsultant, trener BNS IT procesy zwinne i nie tylko architektura czysty kod software crafstmanship strategie skutecznych programistów

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

Natalia BIEŃ Uniwersytet Przyrodniczy, Studenckie Koło Naukowe Informatyków IMPLEMENTACJA PORTALU INTERNETOWEGO W TECHNOLOGIACH PHP I MYSQL

Natalia BIEŃ Uniwersytet Przyrodniczy, Studenckie Koło Naukowe Informatyków IMPLEMENTACJA PORTALU INTERNETOWEGO W TECHNOLOGIACH PHP I MYSQL Natalia BIEŃ Uniwersytet Przyrodniczy, Studenckie Koło Naukowe Informatyków IMPLEMENTACJA PORTALU INTERNETOWEGO W TECHNOLOGIACH PHP I MYSQL 1. Wprowadzenie W dzisiejszych czasach Internet odgrywa istotną

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Zarządzanie bazą danych

Zarządzanie bazą danych -1- Kampania SMS Kampanie SMS to bardzo efektywne narzędzie marketingu bezpośredniego. Łączy w sobie prostotę i zwięzłość przekazu wraz z niemal stu procentową pewnością odebrania i przeczytania wiadomości

Bardziej szczegółowo

Zmiana przekonań, czyli jak stać się panem swojego umysłu

Zmiana przekonań, czyli jak stać się panem swojego umysłu Zmiana przekonań, czyli jak stać się panem swojego umysłu - Arkusz ćwiczeń - Lista ograniczających przekonań: Żeby być bogatym trzeba ciężko pracować W Polsce trudno jest zrobić biznes Świat jest brutalnym

Bardziej szczegółowo

I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński

I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński pawel@warsjawa:/etc$whoami Ja: ponad 10 lat pracy w Javie SCJP, SCWCD, SCBCD, SCEA brałem udział w: rozwój oprogramowania, consulting,

Bardziej szczegółowo

Zbiory danych powstające w Internecie. Maciej Wierzbicki

Zbiory danych powstające w Internecie. Maciej Wierzbicki Zbiory danych powstające w Internecie Maciej Wierzbicki 17 marca 2009 Na podstawie art. 2 Ustawy z dnia 6 września 2001 r. o dostępie do informacji publicznej oraz na podstawie art. 12 Ustawy z dnia 29

Bardziej szczegółowo

Od Wciskania do Sprzedawania. Mistrzem Etycznej Sprzedaży

Od Wciskania do Sprzedawania. Mistrzem Etycznej Sprzedaży Szkolenie Od Wciskania do Sprzedawania czyli jak zostać Mistrzem Etycznej Sprzedaży Czy kiedykolwiek zastanawiałeś się, jak zmieniłoby się Twoje życie zawodowe, gdyby każdy klient z otwartymi rękoma brał

Bardziej szczegółowo

SZYBKO ZROZUMIEĆ VISUAL BASIC 2012 Artur Niewiarowski -

SZYBKO ZROZUMIEĆ VISUAL BASIC 2012 Artur Niewiarowski - S t r o n a 2 SZYBKO ZROZUMIEĆ VISUAL BASIC 2012 Artur Niewiarowski - Copyright by Artur Niewiarowski 2013 ISBN: 978-83-937802-0-4 - Artur Niewiarowski Self-Publishing - All rights reserved. Wszelkie prawa

Bardziej szczegółowo

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl .firma Dostarczamy profesjonalne usługi oparte o nowoczesne technologie internetowe Na wstępie Wszystko dla naszych Klientów Jesteśmy świadomi, że strona internetowa to niezastąpione źródło informacji,

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

egroupware czy phpgroupware jest też mniej stabilny.

egroupware czy phpgroupware jest też mniej stabilny. Opengroupware to projekt udostępniający kompletny serwer aplikacji oparty na systemie Linux. Dostępny na licencji GNU GPL, strona domowa: http://www.opengroupware.org/ Jego cechy to wysoka stabilność,

Bardziej szczegółowo

KRYTERIA OCENIANIA Z JĘZYKA ANGIELSKIEGO W KLASACH IV - VI

KRYTERIA OCENIANIA Z JĘZYKA ANGIELSKIEGO W KLASACH IV - VI KRYTERIA OCENIANIA Z JĘZYKA ANGIELSKIEGO W KLASACH IV - VI Ocena celująca: uczeń swobodnie operuje strukturami gramatycznymi określonymi w rozkładzie materiału z łatwością buduje spójne zdania proste i

Bardziej szczegółowo

Przykładowa konfiguracja konta pocztowego w programie Outlook Express z wykorzystaniem MKS 2k7 (MS Windows 2000 Proessional)

Przykładowa konfiguracja konta pocztowego w programie Outlook Express z wykorzystaniem MKS 2k7 (MS Windows 2000 Proessional) Przykładowa konfiguracja konta pocztowego w programie Outlook Express z wykorzystaniem MKS 2k7 (MS Windows 2000 Proessional) KROK NR 1: Uruchamiamy program Outlook Express. Jesteśmy proszeni o nazwę tożsamości.

Bardziej szczegółowo

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Wdrożenie systemu planowania zasobów przedsiębiorstwa pomimo wielu korzyści często też wiąże się

Bardziej szczegółowo

Jak mówić, żeby dzieci się uczyły w domu i w szkole A D E L E F A B E R E L A I N E M A Z L I S H

Jak mówić, żeby dzieci się uczyły w domu i w szkole A D E L E F A B E R E L A I N E M A Z L I S H Jak mówić, żeby dzieci się uczyły w domu i w szkole A D E L E F A B E R E L A I N E M A Z L I S H ZAMIAST ZAPRZECZAĆ UCZUCIOM NAZWIJ JE ZAMIAST -Tu jest za dużo słów. -Bzdura. Wszystkie słowa są łatwe.

Bardziej szczegółowo

Algorytm. a programowanie -

Algorytm. a programowanie - Algorytm a programowanie - Program komputerowy: Program komputerowy można rozumieć jako: kod źródłowy - program komputerowy zapisany w pewnym języku programowania, zestaw poszczególnych instrukcji, plik

Bardziej szczegółowo

LabVIEW - Modele Rozwoju

LabVIEW - Modele Rozwoju Kurantowicz Agnieszka Jedut Barbara LabVIEW - Modele Rozwoju Projekt ten dostarcza przykładów niektórych powszechnych pułapek rozwoju i opisuje grupę modeli związanych z technologią cyklu życia oprogramowania.

Bardziej szczegółowo

PROGRAM SZKOLENIA Z ZAKRESU OBSŁUGI KLIENTA

PROGRAM SZKOLENIA Z ZAKRESU OBSŁUGI KLIENTA VAL Gee JEFF Gee PROGRAM SZKOLENIA Z ZAKRESU OBSŁUGI KLIENTA Ćwiczenia, formularze, wskazówki dla prowadzącego Zestaw z CD WARSZAWA 2011 Spis treści Zestawienie sesji szkoleniowych według celu szkolenia...............

Bardziej szczegółowo

LearnIT project PL/08/LLP-LdV/TOI/140001

LearnIT project PL/08/LLP-LdV/TOI/140001 LEARNIT KOBIETY W IT EMANUELA (IT) Ten projekt został zrealizowany przy wsparciu finansowym Komisji Europejskiej. Projekt lub publikacja odzwierciedlają jedynie stanowisko ich autora i Komisja Europejska

Bardziej szczegółowo

projekt biznesowy Mini-podręcznik z ćwiczeniami

projekt biznesowy Mini-podręcznik z ćwiczeniami DARMOWY FRAGMENT projekt biznesowy Mini-podręcznik z ćwiczeniami Od Autorki Cześć drogi Czytelniku! Witaj w darmowym fragmencie podręcznika Jak zacząć projekt biznesowy?! Jego pełna wersja, zbiera w jednym

Bardziej szczegółowo

System Kancelaris. Zdalny dostęp do danych

System Kancelaris. Zdalny dostęp do danych Kancelaris krok po kroku System Kancelaris Zdalny dostęp do danych Data modyfikacji: 2008-07-10 Z czego składaj adają się systemy informatyczne? System Kancelaris składa się z dwóch części: danych oprogramowania,

Bardziej szczegółowo

20 sposobów na wspieranie dziecka - w nauce i emocjach. Opracowała: Katarzyna Maszkowska- pedagog szkolny

20 sposobów na wspieranie dziecka - w nauce i emocjach. Opracowała: Katarzyna Maszkowska- pedagog szkolny 20 sposobów na wspieranie dziecka - w nauce i emocjach Opracowała: Katarzyna Maszkowska- pedagog szkolny Kiedy się uczymy, emocje są niezwykle ważne. Gdybyśmy uczyli się tylko biorąc suche fakty, które

Bardziej szczegółowo

ING to my wszyscy. A nasz cel to: wspieranie i inspirowanie ludzi do bycia o krok do przodu w życiu i w biznesie.

ING to my wszyscy. A nasz cel to: wspieranie i inspirowanie ludzi do bycia o krok do przodu w życiu i w biznesie. Pomarańczowy Kod ING to my wszyscy. A nasz cel to: wspieranie i inspirowanie ludzi do bycia o krok do przodu w życiu i w biznesie. Pomarańczowy Kod determinuje sposób, w jaki realizujemy powyższy cel określa

Bardziej szczegółowo

SEMINARIUM ODNOWY W DUCHU ŚWIĘTYM

SEMINARIUM ODNOWY W DUCHU ŚWIĘTYM SEMINARIUM ODNOWY W DUCHU ŚWIĘTYM Tydzień wprowadzający Bóg nas "...wezwał świętym powołaniem nie na podstawie naszych czynów, lecz stosownie do własnego postanowienia i łaski, która nam dana została w

Bardziej szczegółowo

Przełom w koncepcjach rejestrów państwowych MSWiA

Przełom w koncepcjach rejestrów państwowych MSWiA Przełom w koncepcjach rejestrów państwowych MSWiA Michał MŁOTEK Wydział Bezpieczeństwa Infrastruktury Teleinformatycznej MSWiA BEZPIECZEŃSTWO Czym jest bezpieczeństwo, a czym nie jest? BEZPIECZEŃSTWO Bezpieczeństwo

Bardziej szczegółowo

Być może jesteś doświadczonym programistą, biegle programujesz w Javie,

Być może jesteś doświadczonym programistą, biegle programujesz w Javie, Kompendium PHP 01 Być może jesteś doświadczonym programistą, biegle programujesz w Javie, C++, Pythonie lub jakimś innym języku programowania, których jak myślę, powstało już tyle, że chyba nie ma osoby,

Bardziej szczegółowo

www.asap24.com.pl Środki Unijne TRWALE WSPIERAJĄCE ROZWÓJ PRZEDSIĘBIORSTWA 0 801 2727 24 (22 654 09 35)

www.asap24.com.pl Środki Unijne TRWALE WSPIERAJĄCE ROZWÓJ PRZEDSIĘBIORSTWA 0 801 2727 24 (22 654 09 35) Środki Unijne TRWALE WSPIERAJĄCE ROZWÓJ PRZEDSIĘBIORSTWA 0 801 2727 24 (22 654 09 35) Właścicielu! Dyrektorze! Czy poszukujesz środków na rozwój swojej działalności? Chciałbyś sfinansować nowy projekt?

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

Bardziej szczegółowo

USTALENIE SYSTEMU WYNAGRODZEŃ

USTALENIE SYSTEMU WYNAGRODZEŃ USTALENIE SYSTEMU WYNAGRODZEŃ Administracja systemu wynagrodzeń jest ważnym elementem prowadzenia biznesu. Gdy mamy działający formalny system płac, pomaga to w kontrolowaniu kosztów personelu, podnosi

Bardziej szczegółowo

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.

Bardziej szczegółowo

Komentarz technik teleinformatyk 312[02]-02 Czerwiec 2009

Komentarz technik teleinformatyk 312[02]-02 Czerwiec 2009 Strona 1 z 16 Strona 2 z 16 Strona 3 z 16 W pracy egzaminacyjnej podlegały ocenie: I. Tytuł pracy egzaminacyjnej. II. Założenia wynikające z treści zadania i załączonej dokumentacji. III. Wykaz działań

Bardziej szczegółowo

Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.

Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania. Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania. Założenia projektowe systemu NETDOC. część 1: założenia ogólne i funkcjonalność rdzenia systemu Założenia ogólne Celem projektu jest

Bardziej szczegółowo

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca Uwierzytelnianie w PHP 01 Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca stron internetowych, jest identyfikacja i uwierzytelnienie uprzywilejowanego użytkownika. Od zaprojektowania

Bardziej szczegółowo

Wewnątrzszkolne Doskonalenie Nauczycieli Nowatorskie metody nauczania

Wewnątrzszkolne Doskonalenie Nauczycieli Nowatorskie metody nauczania Wewnątrzszkolne Doskonalenie Nauczycieli Nowatorskie metody nauczania Zapraszam na szkolenie on line prezentujące dwie nowoczesne metody pracy: coaching i mentoring. Idea i definicja coachingu Coaching,

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

Wprowadzenie do projektu QualitySpy

Wprowadzenie do projektu QualitySpy Wprowadzenie do projektu QualitySpy Na podstawie instrukcji implementacji prostej funkcjonalności. 1. Wstęp Celem tego poradnika jest wprowadzić programistę do projektu QualitySpy. Będziemy implementować

Bardziej szczegółowo

Podręcznik użytkownika

Podręcznik użytkownika Podręcznik użytkownika Moduł kliencki Kodak Asset Management Software Stan i ustawienia zasobów... 1 Menu Stan zasobów... 2 Menu Ustawienia zasobów... 3 Obsługa alertów... 7 Komunikaty zarządzania zasobami...

Bardziej szczegółowo

Organizacja informacji

Organizacja informacji Organizacja informacji 64 CZYTANIE ARTYKUŁU Z GAZETY To zadanie ma nauczyć jak: wybierać tematy i rozpoznawać słowa kluczowe; analizować tekst, aby go zrozumieć i pamiętać; przygotowywać sprawozdanie;

Bardziej szczegółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

LearnIT project PL/08/LLP-LdV/TOI/140001

LearnIT project PL/08/LLP-LdV/TOI/140001 LEARNIT KOBIETY W IT PETYA (BG) Ten projekt został zrealizowany przy wsparciu finansowym Komisji Europejskiej. Projekt lub publikacja odzwierciedlają jedynie stanowisko ich autora i Komisja Europejska

Bardziej szczegółowo

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja

Bardziej szczegółowo

Idealna strona internetowa dla Twojej firmy

Idealna strona internetowa dla Twojej firmy Katowice, 25.11.2010 r. Idealna strona internetowa dla Twojej firmy Warsztaty prowadzenie Zofia Oslislo 1 Czy potrzebuję (nowej) strony internetowej? mogę zwiększyć sprzedaż, gdy pozwolę klientom kupować

Bardziej szczegółowo