Wikileaks opublikuje 5000 projektów Javy typu Open Source usuwając wszystkie cholerne private/final

Oryginalny post: Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed

Autor: Steve Yegge

EYJAFJÖLL, ISLANDIA – wśród programistów Javy na całym świecie szerzy się panika, w związku z wydanym dzisiaj o godzinie 8:15 GMT komunikatem prasowym Wikileaks. Organizacja zapowiedziała ponowne opublikowanie kodu źródłowego tysięcy opensource'owych projektów Javy. Wszystkie modyfikatory dostępu ustawione będą jako 'public', natomiast ze wszystkich klas i ich składowych usunięty zostanie modyfikator 'final'.

Johnnie Garza, zwinny programista Java z Irvine, CA potępia taki ruch. „Oni nie mają prawa tego zrobić. Open source nie oznacza, że kod jest w jakiś sposób 'otwarty'. To jest mój kod, nie ich. Jeśli określam coś jako 'private', to nie ma znaczenia jak bardzo potrzebujesz to wywołać, powinienem móc cię zatrzymać, nawet jeśli już dawno jestem w grobie”.

Według informacji prasowej Wikileaks, miliony plików z kodem źródłowym Javy zostało przepuszczonych przez skrypt Perla usuwający wszystkie słowa kluczowe 'final', z wyjątkiem tych, które są niezbędne, aby obejść „cholernie makabryczny brak domknięć”, w tym 15-letnim języku Java.

Dodatkowo, skrypt Perla zapewnia, że każda klasa ma przynajmniej jeden publiczny konstruktor, a wszystkie pola nie mające geterów i seterów przekształca w publiczne. „Skrypt eliminuje również wszystkie badziewne adnotacje @deprecated”, można przeczytać w komunikacie.

Długoletni programista Javy, Ronnie Lloyd z Austin, TX czuje się dotknięty myślą, że ludzie będą mogli tworzyć instancje jego prywatnych klas. ”To po prostu zdrowy rozsądek”, mówi Lloyd, 37 lat. „Jeśli kupuję dom i przekazuję go tobie, ale jednocześnie zawieszam na niektórych drzwiach tabliczki „Tylko dla pracowników”, wtedy nie jesteś upoważniony do otwierania tych drzwi, nawet jeśli to jest twój dom. Bo to jest tak naprawdę mój dom, nawet jeśli pozwoliłem ci w nim mieszkać.”

Marszcząc brwi w zamyśleniu, Lloyd kontynuuje: „Nawet jeśli odchodzę na zawsze, a ty mieszkasz tam przez 20 lat i dokładnie wiesz co jest za drzwiami – do licha, nawet jeśli to jest sprawa życia i śmierci – czysty zdrowy rozsądek podpowiada, że nigdy, przenigdy nie możesz otworzyć tych drzwi pod żadnym pozorem.

„To jest dla twojego bezpieczeństwa”, dodaje Lloyd.

Wesley Doyle, webowy programista Javy z Toronto, Kanada jest po prostu zaskoczony tą wiadomością. „Dlaczego oni myślą, że muszą to zrobić? Dlaczego użytkownicy mojej opensource'owej biblioteki w Javie nie mogą zwyczajnie zacisnąć pięści i później przekląć moje imię na łożu śmierci? To podejście działa dobrze dla reszty z nas. Kogo to obchodzi, czy mam prywatną, pomocniczą funkcję, której oni potrzebują? Czyżby popsuło im się kopiowanie i wklejanie?”

Założyciel Wikileaks, Julian Assange, który ukuł termin „Opened Source” dla określenia złamanego opensource'owego kodu Javy obawia się aresztowania przez służby ochronne na kampusach Oracle lub IBM. Założyciel Wikileaks powiedział: „W dniu dzisiejszym Eclipse Foundation zwołało prywatne spotkanie, na którym określono mnie jako 'non-thread-safe AbstractKeywordRemovalInitiatorFactory'. Co to do cholery znaczy? Obawiam się o swoje bezpieczeństwo w pobliżu tych osób”.

Usunięcie adnotacji '@deprecated' jest szczególnie dotkliwe dla wielu ciężko pracujących programistów Javy. „Ciężko pracowałem, żeby zdeprecjonować ten kod, nad którym ciężko pracowałem, kiedy go tworzyłem, żeby zdeprecjonować inny kod, nad którym również ciężko pracowałem”, mówi Kelly Bolton, rzecznik League Of Java Programmers For Deprecating The Living Shit Out Of Everything.

„Jeśli ludzie mogą używać starszego, bardziej wygodnego API, które dla nich stworzyłem, dlaczego cholera mieliby używać mojego nowego, bardziej skomplikowanego API? To się nie mieści w głowie”, dodaje Bolton.

Zespół Eclipse CDT został szczególnie dotknięty usunięciem tagu przestarzałości. Morris Baldwin, pracujący dorywczo jako programista CDT, zajmuje się biblioteką parsującą w C++ i mówi: „Obecnie prowadzimy politykę wydawania pakietów w Javie, w których każda klasa, interfejs i metoda są przestarzałe od samego początku, fabrycznie, zaczynając od wersji 1.0”.

„Powzięliśmy pewne kroki, aby zapewnić, iż nie będzie możliwym wykorzystanie naszego przed-przestarzałego kodu bez uruchomienia naszego rozbudowanego frameworka”, dodaje 22-letni Baldwin. „Dodanie publicznych konstruktorów i usunięcie atrybutów 'final' byłoby poważnym ciosem zarówno dla nie-użyteczności jak i nie-ponownego-wykorzystania”.

Zwinna społeczność Javy określiła działanie Wikileaks jako akt terroryzmu. „Prawdopodobnie stoi za tym ekstremistyczny ruch programowania aspektowego”, spekuluje zwinna projektantka Javy, Claudia Hewitt, 29 lat. „Zawsze wiedziałam, że oni chcą użyć mojego kodu w sposób, którego nigdy nie mogłam z góry przewidzieć”, dodaje.

Wielu programistów Javy zapowiedziało walkę przeciw niepożądanemu otwarciu ich otwartego kodu typu open source. Billy Blackburn, rzecznik League of Agile Methodology Experts (LAME) mówi, że rozpoczęto już prace nad nowym narzędziem do budowy projektów, które nie będzie linkowało kodu Javy typu Opened Source. Narzędzie zostanie wydane od razu po tym, jak niezależni dostawcy pewnych bibliotek Javy zrefaktoryzują kod, aby można go było ponownie wykorzystać. Blackburn odmówił opisania zmian, twierdząc, że „to nie je wasz biznes”.

Guy Faulkner, 51 letni programista Pythona z Seattle był rozbawiony komunikatem Wikileaks. „Kiedy programiści Pythona wypuszczają coś jako Open Source, to mówią: Słuchajcie, ciężko nad tym pracowałem. Mam nadzieję, że to polubicie. Używajcie tego jak chcecie. Niektóre rzeczy są udokumentowane, jako mogące podlegać zmianom w przyszłości, ale wszyscy jesteśmy tutaj dorośli, więc użyjcie swojego rozsądku”.

Faulkner wzruszył smutno głową. „Podczas gdy programiści Javy, którzy wypuszczają kod jako Open Source mówią: Słuchajcie, ciężko nad tym pracowałem. Mam nadzieję, że to polubicie. Ale używajcie tego dokładnie tak, jak wam powiedziałem, bo do jasnej cholery, to mój kod. Będę decydował, kto jest wystarczająco cholernie dorosły tutaj w okolicy”.

„Ale dlaczego ten skrypt Perla nie został napisany w Pythonie?”, pyta Faulkner.

Data publikacji oryginału: lipiec 28, 2010

Pisanie świetnej dokumentacji: potrzebujesz redaktora

Listopad 12, 2009

Część serii Pisanie świetnej dokumentacji.

To ja powinienem być tym ekspertem od pisania, nie? Jak to możliwe w takim razie, że moje poprzednie artykuły miały tak wiele błędów?

To proste: mój blog nie ma redaktora.

To typowe dla bloga, ale niestety także bardzo powszechne dla dokumentacji open source: znaczna większość dokumentacji technicznej nie zachodzi dalej niż poza szkic.

Wszyscy dobrzy pisarze mają swój wstydliwy sekret: nie są naprawdę tak dobrzy w pisaniu. Ich redaktorzy to zapewniają. Nie ma znaczenia, jak dobrze opanowałeś język; nikt, nawet gramatyczni wyjadacze, nie robią tego dobrze za pierwszym razem.

Jeśli naprawdę chcesz stworzyć świetną dokumentację, musisz poprosić o jej zredagowanie.

Wskazówki redaktorskie

Daleko mi do redaktora-eksperta, ale - zgodnie z wielką tradycją otwartego oprogramowania - "potrzebujemy..." zwykle tłumaczy się do "zgłaszam się do..." i często kończę jako taki redaktor.

Jeśli masz możliwość popracować z dobrym redaktorem, to polecam spróbować - to fantastyczne. Jednym z najlepszych elementów pisania książki jest nauka płynąca z redagowania.

Niestety, zwykle większość inicjatyw nie może skorzystać z luksusu posiadania prawdziwego redaktora. Kilka rad dla Ciebie, jeśli - także - zostaniesz postawiony w tej roli:

  • Nie redaguj bez pozwolenia.

    Pamiętaj: ludzie piszący dokumentację online niemal zawsze są ochotnikami i często nie mogą czerpać korzyści z posiadania formalnej edukacji w piśmiennictwie. Prawdopodobnie są zainteresowani rozwojem w tej materii, ale zapytaj o pozwolenie zanim się zagłębisz w tekście.

    Trudno o sposób na to, by stwierdzić głośno, że ktoś zrobił błąd bez brzmienia jak palant, więc upewnij się, że Twoja krytyka jest pożądana. Przyczepianie się do czyjejś gramatyki i stylu tylko dlatego, że myślisz, że jesteś jakiegoś rodzaju ekspertem jest po prostu niegrzeczne.

  • Bądź przygotowany. Upewnij się, że masz swój przewodnik po stylu, cały materiał referencyjny i dobry słownik (także synonimów). Niemal zawsze narastają pytania w trakcie pracy; bądź przygotowany, by na nie odpowiedzieć.

  • Unikaj redagowania własnej pracy (zerknij jednak na sekcję poniżej, jeśli musisz).

    Jest niemalże niemożliwym by z sukcesem redagować własną pracę. Gdy czytasz coś, co napisałeś samodzielnie wiesz, co chciałeś napisać, więc łatwo pominąć literówki czy brakujące słowa.

    Ja także redaguję to, co jest opublikowane na tym blogu, ale nie mógłbyś tego stwierdzić po ilości zawstydzających błędów. Byłoby znacznie lepiej, gdybym sam nie redagował własnej pracy.

  • Redaguj na papierze.

    Jak rozważaliśmy wczoraj, materiały online czytamy zupełnie inaczej niż drukowane. Tekst na ekranie skłania do prześlizgiwania się, więc omijamy błędy, które w druku byłyby oczywiste.

    Redaguję czerwonym tuszem, rzecz jasna.

  • Czytam powoli. Nie ma sensu przelatywać po tekście tak szybko, jak to możliwe. W zasadzie chodzi o coś zupełnie odwrotnego. Powinieneś celować w to, by nad każdym słowem spędzić tak dużo czasu, jak to możliwe.

    W rzeczywistości czytam tekst "na głos". Redaguję zwykle w miejscach publicznych - kawiarniach czy bibliotekach - gdzie prawdziwe czytanie na głos mogłoby być dziwne, ale wokalizuję i cicho poruszam wargami tak, jakbym czytał każde słowo.

    Szczęśliwie mieszkam w miasteczku, w którym ktoś mówiący do siebie samego na końcu biblioteki jest czymś całkiem normalnym, więc nikt nie zauważa kolesia szepczącego do siebie w rogu.

  • Przejrzyj tekst kilka(trzy-)krotnie. Wygląda na to, że znajduję około 90% błędów za każdym przejrzeniem. Prawie nigdy nie zdarza się, bym nie znalazł czegoś. Dwa przeglądy to u mnie standard; trzeci jest poświęcony na dodatkowe polerowanie.

Ponad wszystko: bądź spójny. Dla pisarza niespójni redaktorzy są rozwścieczający. Jeśli masz zamiar zająć się redagowaniem, musisz redagować zawsze w stronę tego samego stylu.

Samodzielne redagowanie tekstu

W świecie open source istnieje silny efekt ogona, więc większość projektów kończy jako produkt jednej osoby. Zatem i dokumentacja jest produktem pochodzącym od jednej osoby. Można do tego dodać, że w wielu większych społecznościach dokumentacja jest zaniedbywana i powstaje w wyniku wysiłku jednej osoby.

W praktyce więc "Twój redaktor" kończy się na "Ty". W takim wypadku przyda się kilka rad na temat skutecznych technik samodzielnego redagowania:

  • Unikaj redagowania i pisania jednocześnie. Nic nie zabija "flow" bardziej, niż ciągłe krytykowanie siebie samego. Wyłącz sprawdzanie pisowni, wyłącz sprawdzanie gramatyki i, co najważniejsze, spróbuj wyłączyć tę krytykancką część Twojego umysłu do czasu rozpoczęcia redagowania.

    To jest jeden z głównych powodów, dla których ląduję w kawiarni czy bibliotece, gdy redaguję: piszę coś, drukuję i idę gdzieś indziej, by móc to poprawić. Uczę się myślenia o redagowaniu jako o zupełnie oddzielnej roli, w którą wcielam się w innym miejscu, niż piszę.

  • Daj sobie trochę czasu. Jeśli pozwolisz, by trochę czasu upłynęło między pisaniem i redagowaniem, to to, co napisałeś, odrobinę wyblaknie w Twojej pamięci i zacznie wyglądać nieco mniej znajomo. Będzie mniej prawdopodobnym byś "wiedział" co napisałeś, i nieco bardziej prawdopodobnym byś zauważył błędy.

  • Zmień szerokość marginesu. To strasznie głupi trik, ale kurczę działa. Po prostu zmień szerokość kolumny lub marginesy w swoim edytorze, a gdy Twój tekst się przeorganizuje zacznie wyglądać nieco inaczej. Dla mnie ta niewielka różnica jest wystarczająca, by obudzić mój mózg i odnaleźć błędy natychmiast po reorganizacji.

Niestety, żadna liczba trików nie pomoże Ci naprawdę, jeśli musisz redagować tekst samodzielnie. Zawsze pozostaną jakieś błędy. Ostatecznie jednak jakaś dokumentacja zawsze pobije brak dokumentacji.

Daj z siebie wszystko... i bezwarunkowo naciśnij przycisk "publikuj"!

Tanie testy użyteczności

Oryginalny post: Low-Fi Usability Testing

Autor: Jeff Atwood

Szybki quiz. Skąd wiesz, że Twoja aplikacja działa? Możliwe, że się kompiluje. Możliwe, iż wszystkie testy jednostkowe przechodzą. Możliwe też, że przeszła próbę w dziale QA. Możliwe, iż została szczęśliwie wdrożona na serwer produkcyjny bądź spakowana do instalera. Może nawet beta testerzy potwierdzili jej poprawność.

Ale to nie oznacza, że aplikacja działa.

Czy tak naprawdę użytkownicy rozumieją Twoją aplikację? Czy potrafią oni wykonać swoją pracę za pomocą Twojej aplikacji? To jest to, co definiuje działającą aplikację. Cała reszta rzeczy, które wymieniłem, to tylko szum. Nie masz pewności, czy Twoja aplikacja naprawdę działa, dopóki nie przeprowadzisz testów użyteczności z prawdziwymi użytkownikami.

A Ty systematycznie przeprowadzasz takie testy na swojej aplikacji, prawda?

Tak jak myślałem. Jedną z najważniejszych koncepcji przedstawionych w książce Steve'a Krug'a Don't Make Me Think jest to, że testy użyteczności są istotne w każdym tworzonym oprogramowaniu. Krug określa swoje uproszczone podejście do testów użyteczności mianem supertanich testów użyteczności:

Testowanie użyteczności jest już znane od jakiegoś czasu i podstawowe założenie jest dosyć proste: jeśli chcesz wiedzieć, czy Twoje oprogramowanie, aplikacja internetowa, czy pilot do video są dostatecznie proste w użyciu, obserwuj ludzi używających ich i zwracaj uwagę na to, kiedy mają problemy. Następnie popraw to i przetestuj ponownie.

Niemniej jednak kiedyś testy użyteczności były bardzo drogim przedsięwzięciem. Musiałeś mieć laboratorium razem z pokojem obserwacyjnym z weneckim lustrem oraz co najmniej dwie kamery, abyś mógł nagrywać reakcje użytkowników oraz rzeczy, których używają. Musiałeś zatrudnić sporo ludzi, aby wyniki miały jakieś znaczenie w świetle statystyki. To była Nauka. Jednorazowy koszt czegoś takiego wynosił od $20000 do $50000. Nie zdarzało się to zbyt często.

W 1989 roku Jakob Nielsen napisał publikację zatytułowaną "Usability Engineering at a Discount" i zaznaczył, że wcale nie musi tak być. Nie potrzebowałeś laboratorium oraz mogłeś osiągnąć te same wyniki z pomocą o wiele mniejszej liczby użytkowników. Idea tanich testów użyteczności była olbrzymim krokiem naprzód. Problemem było to, że dekadę później większość ludzi nadal postrzegało testowanie jako coś problematycznego, a zatrudnienie kogoś do przeprowadzania takich testów kosztowało od $5000 do $15000 i w rezultacie też nie zdarzało się to dostatecznie często.

To co chciałem Ci polecić w tym rozdziale jest nawet bardziej drastyczne: supertanie testy użyteczności. Zamierzam spróbować Ci wytłumaczyć, jak przeprowadzić testy, kiedy nie ma się ani pieniędzy, ani czasu. Jeśli stać Cię na zatrudnienie profesjonalistów do testowania, zrób to -- ale nie rób tego, jeśli miałoby to oznaczać, że przeprowadzisz mniej testów.

Krug zaznacza, iż testowanie użyteczności jest tylko tak trudne, jak chcesz żeby było. Możliwym jest otrzymanie pożytecznych wyników testów użyteczności nawet za pomocą pojedynczego użytkownika:

Testy [użyteczności] zawsze się sprawdzają, a nawet najgorszy test ze złym użytkownikiem jest w stanie wykazać rzeczy, które mógłbyś poprawić na swojej stronie. Zawsze kładę nacisk na wykonywanie testów z użytkownikami podczas moich warsztatów, aby uczestnicy zobaczyli, iż jest to bardzo łatwe, i że efektem jest mnóstwo wartościowych spostrzeżeń. Proszę o ochotnika i przekonuję go, aby wykonał zadanie na stronie należącej do jednego z uczestników. Testy te trwają mniej niż 10 minut, ale osoba, której strona jest testowana, robi zazwyczaj kilka stron notatek. I zawsze proszą o to, czy mogą dostać nagranie tego testu, aby mogli je pokazać po powrocie swojemu zespołowi. Kiedyś jedna osoba powiedziała mi, że po tym jak jej zespół zobaczył nagranie, zrobili jedną zmianę na swojej stronie, która według nich zaowocowała oszczędnościami rzędu $100000.

Aby jeszcze bardziej uzmysłowić Wam, że do wykonania skutecznych testów użyteczności nie potrzeba dużej ilości użytkowników, Jakob Neilsen dostarczył następujący wykres:

problemy użyteczności wykres

Oczywiście nie robienie żadnych testów użyteczności to katastrofa. Ale co nie jest oczywiste, to że testy użyteczności z jedynie kilkoma użytkownikami są nadzwyczaj skuteczne. A przeprowadzanie ich według wskazówek Krug'a dotyczących tanich testów użyteczności może okazać się względnie przyjemne:

  • Kiedy powinienem testować? Najlepiej raz w miesiącu. Powinieneś ciągle przeprowadzać drobne testy użyteczności podczas procesu tworzenia. Testy powinny być krótkie i proste, tak abyś mógł je przeprowadzać kiedy tylko chcesz bez nadmiernego planowania.
  • Jak wielu użytkowników potrzebuję? Maksymalnie trzech bądź czterech.
  • Jakiego rodzaju użytkowników? Po prostu jakichś ludzi. Wystarczy ktoś, kto potrafi korzystać z komputera. Najlepiej strzeżoną tajemnicą testów użyteczności jest to, że nie ma zbyt wielkiego znaczenia, kto testuje. Dobrze jest mieć reprezentatywnych użytkowników, ale ważniejsze jest testowanie wczesne i częste. Nie wstydź się prosić przyjaciół i sąsiadów.
  • Jak dużo czasu to zajmie? 45 minut do godziny na jednego użytkownika. Staraj się, aby to było proste i nieskomplikowane. Mimo iż przeprowadzanie testów użyteczności, nawet tych prostych, zabiera trochę czasu, to ostatecznie go zaoszczędzisz. Wyniki testów użyteczności zapobiegną traceniu czasu na niekończących się kłótniach, czy poprawianiu projektu pod koniec terminu.
  • Gdzie mam przeprowadzić testy? W biurze bądź sali konferencyjnej. Wszystko czego potrzebujesz, to pokój z biurkiem, komputer i dwa krzesła, gdzie nikt nie będzie Ci przeszkadzał.
  • Kto powinien robić testy? Jakakolwiek rozsądnie cierpliwa osoba. Wybierz kogoś, kto jest cierpliwy, spokojny i potrafi słuchać. Z odrobiną praktyki, większość ludzi stanie się w tym dobra.
  • Jakiego oprzyrządowania będę potrzebował? Wszystko czego potrzebujesz, to jakieś oprogramowanie do nagrywania ekranu takie, jak na przykład Camtasia. Jeśli masz na to ochotę, możesz przynieść kamerę, aby nagrywać zarówno osobę testującą jak i ekran.
  • Jak przygotować się do testów? Zdecyduj się na to, co chcesz pokazać. Miej przygotowany krótki scenariusz (doc), który poprowadzi uczestników przez test.
  • Jaki będzie koszt testów? Jeśli nie liczyć czasu moderatora, to $50-$100 wynagrodzenia na użytkownika.
  • Jak interpretować wyniki? Zdaj sprawozdanie swojemu zespołowi i interesariuszom podczas lunchu tego samego dnia. Jedną z najfajniejszych rzeczy odnośnie testów użyteczności jest to, że wyniki są oczywiste dla kogoś, kto się im przyglądał. Poważne problemy są trudne do pominięcia.

Jeśli jeszcze nie posiadasz kopii książki Don't Make Me Think, wstydź się. Tymczasem, gorąco polecam ściągnięcie Rozdziału 9 tej książki (pdf), który zawiera znacznie więcej szczegółów, niż to co zaprezentowałem.

Testy użyteczności nie muszą być skomplikowane. Jeśli naprawdę chcesz się dowiedzieć, czy to nad czym pracujesz działa, zapytaj kogokolwiek, aby tego poużywał, a Ty będziesz się przyglądać. Jeśli nie masz kogo, poproś kogoś z księgowości albo działu marketingu, kogokolwiek, kto jest blisko, a nie jest uwikłany w projekt, aby spróbował użyć Twojego oprogramowania. Nie mów im, co mają robić. Daj im zadanie i zaznacz, aby myśleli na głos podczas jego wykonywania. Następnie usiądź i w ciszy obserwuj co się dzieje. Mogę Wam powiedzieć z doświadczenia, że wyniki są czasem niczym objawienie.

Korzyści wynikające z testów użyteczności są jasne. Aby zdać sobie z nich sprawę, musisz tylko je przeprowadzać.

Data publikacji oryginału: 31 stycznia, 2007

Głosowanie na projekty zgłoszone do konkursu "Daj się poznać" rozpoczęte

Konkurs Daj się poznać - głosowanie

Konkurs "Daj się poznać" ma się powoli ku końcowi. W sierpniu pisaliśmy o podsumowaniu zgłoszeń do konkursu:

Ostatnio (16. sierpnia) upłynął termin zgłoszeń do konkursu i musimy przyznać, że liczba zgłoszonych projektów mocno zaskoczyła zarówno nas, jak i pewnie samego organizatora konkursu — Macieja Aniserowicza. Lista 79 zgłoszonych projektów robi wrażenie — wyłonienie zwycięzcy raczej nie będzie łatwe. [..]

Po czterech miesiącach dotarliśmy do momentu, gdy zostało wyłonionych 17 finałowych projektów. Teraz naszym zadaniem jest wybranie zwycięzcy - to Wy, drodzy czytelnicy, decydujecie o ostatecznym wyniku. W tym celu został przygotowany specjalny system do zbierania głosów, którego działanie opisał dokładnie Maciej we wpisie na swoim blogu:

Zasady głosowania są bardzo proste:

  1. w przeciągu kolejnych 7 dni wejdź na stronę http://dajsiepoznac.devmedia.pl/ (w razie niesłabnącego zainteresowania termin ten może ulec nieznacznemu wydłużeniu)
  2. kliknij link "Głosowanie - Etap II"
  3. z trzech list wybierz projekty, które Twoim zdaniem zasługują na największe wyróżnienie
  4. do rozdania masz 6 punków: 3 za pierwsze miejsce, 2 za drugie i 1 za trzecie
  5. obsadzenie dwóch pierwszych miejsc jest obowiązkowe; trzecie miejsce można zostawić puste
  6. pod każdą z pozycji należy podać link do najbardziej wartościowego wg Ciebie posta z bloga, na który oddajesz głos (pokaż za co cenisz dany projekt!)
  7. na podany adres email zostanie wysłana wiadomość z linkiem aktywującym głos - odbierz maila i kliknij (jeśli wiadomość nie dojdzie w ciągu kilku godzin - sprawdź SPAM, jeśli i tam jej nie ma - zgłoś się do mnie)
  8. każdy może zagłosować tylko raz

Zatem nie zostaje nam nic innego, jak oddać nasze głosy i pomóc wyłonić najbardziej wartościowe projekty. Natomiast autorom finałowych projektów życzymy powodzenia!


Zespół devMedia.pl

Działa Na Moim Komputerze - Program Certyfikacyjny

Oryginalny post: The "Works on My Machine" Certification Program

Autor: Jeff Atwood

Joseph Conney miał fantastyczny pomysł na nowy program certyfikacyjny dla aplikacji. Tylko że przyjemna odznaka w stylu Visty (kolorystyka biały-na-szarym) nie do końca komunikuje, hmm..., autorytatywny charakter tego programu. Z pomocą Jona Gallowaya sprawiliśmy, że odznaka jest trochę bardziej cool. [tłum. oryginalna odznaka znajduje się tutaj]

odznaka

Można pomyśleć, że zdobycie tak prestiżowego, rygorystycznego poziomu certyfikacji jest dalece zbyt wymagające. Ale nie martw się! Uczestnictwo w tym nowym programie certyfikacji dla aplikacji tak proste jak wciśnięcie F5 na klawiaturze. Po prostu musisz powtórzyć cztery kroki, które wyszczególnił Joseph:

  1. Skompiluj kod swojej aplikacji. Pobieranie ostatnich zmian, które mogli wprowadzić inni programiści do repozytorium, jest całkowicie opcjonalne i nie jest wymagane dla tego certyfikatu.
  2. Uruchom aplikację lub stronę internetową, którą właśnie skompilowałeś.
  3. Spraw, aby jedna ścieżka w kodzie, który dodajesz do repozytorium, wykonała się. Najlepszy sposób, aby to zrobić, to manualnie przetestować najprostszy przypadek użycia funkcjonalności, którą implementujesz. Pomiń zupełnie ten krok, jeśli kod, który masz zamiar dodać do repozytorium ma mniej niż 5 linijek lub jeśli, według twojej profesjonalnej programistycznej oceny, ten kod nie może w żadnym wypadku spowodować problemu.
  4. Dodaj zmiany do swojego repozytorium.

Gratulacje! Jesteś w pełni certyfikowany. Możesz wyposażyć swoją aplikację w piękną odznakę "Działa na moim komputerze". Z pewnością będziesz chciał pokazać ją swoim kolegom w zespole i prawdopodobnie kluczowym udziałowcom projektu. Ale pamiętaj - trzymaj swoje ego na wodzy. Nie każdy jest zdolny do tak znaczącego wkładu do jakości w inżynierii oprogramowania.

(Dopisek: kochasz swój certyfikat "Działa Na Moim Komputerze" tak bardzo, że chciałbyś z dumą pokazywać go innym? Teraz dostępne są także koszulki, naklejki, kubki... [tłum. gadżety posiadają oryginalną, angielską odznakę] sklep z T-shirtami, kubkami, naklejkami)

Data publikacji oryginalu: 15 marca, 2007


Warstwa Abstrakcji Programistycznej

Oryginalny post: The Development Abstraction Layer

Autor: Joel Spolsky

Młody mężczyzna przyjeżdża do miasta. Jest całkiem przystojny, ma mało pieniędzy w portfelu, z łatwością nawiązuje kontakty z kobietami.

Nie mówi wiele o swojej przeszłości, ale to raczej jasne, że spędził dużo czasu w bezdusznej, wielkiej korporacji.

Jest naturalnie przyjazny i towarzyski, po cichu pewny siebie, ale nie arogancki. Dlatego łatwo mu chwytać się drobnych zleceń znalezionych na tablicy ogłoszeń w lokalnej Kawiarni Programistów. Szybko jednak traci zainteresowanie projektami baz danych dla ubezpieczycieli, próżnymi stronami internetowymi dla gospodyń domowych i silnikami do obliczeń finansowych.

Po roku zgromadził wystarczającą ilość pieniędzy, by pokryć swoje skromne wydatki przez rok czasu. Tak więc po skonsultowaniu się ze swoim owczarkiem, ustawia komputer w słonecznym pokoju w apartartamencie wynajętym nad sklepem spożywczym i instaluje starannie wybrane narzędzia.

Dzwoni do swoich znajomych, do jednego po drugim i uprzedza ich, że jeśli będzie wydawał się trochę odcięty od świata przez następnych kilka miesięcy to dlatego, że ciężko pracuje.

I siada do pisania kodu.

I to jakiego kodu. Doskonałego, kunsztownego, eleganckiego, bez błędów. Interfejs tak doskonale naśladuje proces myślowy użytkownika, że ludzie z Kawiarni Programistów, którym pokazuje swoje dzieło, ledwie dostrzegają, że jest tam jakiś interfejs. Jego kod jest fantastyczny.

Zachęcony ciepłym przyjęciem w grupie, postanawia założyć firmę i przyjmować zlecenia.

Jego skromność wyklucza jakiekolwiek roszczenia, ale po miesiącu sytuacja w banku nie wygląda ciekawie. Jak do tej pory złożono tylko trzy zamówienia: jedno od mamy, jedno od anonimowego dobroczyńcy z Kawiarni Programistów i jedno, które wysłał sam, aby przetestować system do sprzedaży.

W drugim miesiącu nie wpłynęły żadne nowe zamówienia.

To go zaskakuje i napełnia melancholią. W dużej firmie nowe produkty były tworzone dość regularnie i nawet jeśli były nieeleganckie i pospolite, to sprzedawały się w rozsądnych ilościach. Jeden produkt, nad którym tam pracował, okazał się być wielkim hitem.

Po kilku następnych miesiącach jego sytuacja finansowa zaczęła wyglądać lekko niebezpiecznie. Jego pies patrzył na niego smutnym wzrokiem, nie wiedząc co jest nie tak, ale widząc, że jego twarz jest bardziej pochmurna niż zwykle, że nie ma energii, żeby wyjść gdzieś ze znajomymi, po zakupy, by napełnić niebezpiecznie opustoszałą spiżarnię albo żeby chociażby wziąć kąpiel.

Pewnego wtorkowego poranka sprzedawca w sklepie spożywczym odmówił mu poszerzenia kredytu, który zdążył zaciągnąć, a jego bankowiec już dawno nie odbierał od niego telefonów.

Duża firma nie jest mściwa. Potrafią docenić talent i chętnie zatrudniają go ponownie, z wyższą pensją. Szybko zaczyna wyglądać lepiej, ma nowe ciuchy i wraca jego dawna pewność siebie. Ale czegoś gdzieś brakuje. Błysku w oku. Nadzieja, że mógłby być panem własnego losu, zniknęła.

SCal2

Dlaczego mu się nie udało? Jest prawie pewien, że wie. "Marketing", mówi. Jak wielu młodych inżynierów jest skłonny mówić "Microsoft ma gorsze produkty, ale lepszy marketing".

Mówiąc językiem programistów, termin "marketing" oznacza po prostu całą biznesową otoczkę, wszystko, czego oni nie rozumieją w procesie tworzenia i sprzedaży oprogramowania.

To nie jest marketing, tak właściwie. A Microsoft ma bardzo kiepski marketing. Wyobrażacie sobie, żeby te reklamy z dinozaurami przekonały kogokolwiek do kupna Microsoft Office?

Oprogramowanie to rozmowa między użytkownikiem a programistą. Ale żeby ta rozmowa się odbyła, potrzeba wiele pracy poza samym pisaniem oprogramowania. Potrzeba marketingu, tak, ale także sprzedaży i public relations, biura, sieci, infrastruktury, klimatyzacji w biurze, i obsługi klienta, i księgowości, i wielu innych wspomagających czynności.

A co robią programiści? Projektują i piszą kod, projektują ekrany interfejsu, debuggują, integrują, dodają kod źródłowy do repozytorium.

Poziom, na którym pracuje programista (np. Emacs) jest zbyt abstrakcyjny, aby wspierać sam biznes. Programiści pracujący w warstwie abstrakcji programistycznej potrzebują warstwy implementacyjnej - organizacji, która przekształci ich kod w produkt. Dolly Parton, pracująca w warstwie "śpiewania ładnej piosenki", potrzebuje także dużej warstwy implementacji, aby nagrywać płyty, rezerwować sale koncertowe, sprzedawać bilety, ustawiać sprzęt grający, promować nagrania i zbierać honoraria.

SCal3 Każda, odnosząca sukcesy, firma informatyczna będzie składała się z cienkiej warstwy programistów piszących oprogramowanie rozsianych pod olbrzymią, abstrakcyjną administracyjną organizacją.

Abstrakcja istnieje tylko i wyłącznie po to, aby stworzyć pozory, że codzienne aktywności programisty (projektowanie i pisanie kodu, debuggowanie, dodawanie go do repozytorium itp.) to wszystko, czego potrzeba, aby stworzyć produkt i wypuścić go na rynek. Co doprowadza mnie do najważniejszego punktu mojego eseju:

Twoim priorytetem, jako menadżera zespołu programistycznego, jest wytworzenie tej Warstwy Abstrakcji Programistycznej.

Większość nowych menadżerów zespołów programistycznych gubi ten punkt. Myślą o zarządzaniu w kategoriach tradycyjnego podejścia Rozkazuj-I-Zdobywaj (Command-and-Conquer), którego nauczyli się z hollywoodzkich filmów.

Zgodnie z podejściem Rozkazuj-I-Zdobywaj, menadżerowie-albo-inaczej-liderzy starają się wymyślić, w którą stronę pójdzie biznes i wysyłają odpowiednie rozkazy do swoich poruczników, aby ruszyli wspólny biznes w tamtą stronę. Ich porucznicy z kolei, dzielą zadania na mniejsze części i nakazują wykonanie swoich poleceń ludziom pod sobą. No i tak w dół schematu organizacyjnego firmy aż na samym końcu ktoś rzeczywiście coś robi. W tym modelu programista jest kołem zębatym tej maszyny: maszynistą, która wykonuje jedną część rozkazu manadżera.

Niektóre firmy rzeczywiście tak działają. Zawsze poznasz, jeśli będziesz miał styczność z taką firmą. Osoba, z którą będziesz miał do czynienia będzie właśnie robiła jakąś bezsensowną, frustrującą czynność i będzie wiedziała, że to bezsensowne, może nawet będzie ją to obchodziło, ale niestety nic nie będzie mogła na to poradzić. To na przykład linia lotnicza, która traci na zawsze swojego klienta z przelatanym milionem mil tylko dlatego, że nie chcieli zamienić mu jego nierefundowalnego biletu, by mógł wrócić do domu z powodu ważnej sytuacji rodzinnej. To Twój dostawca internetowy, który częściej nawala niż dostarcza Internet, a kiedy rezygnujesz z jego usług, on nadal wysyła rachunki, nalicza opłaty, nalicza opłaty, gdy dzwonisz z reklamacją musisz czekać ponad godzinę na płatnej linii, aby dowiedzieć się, że nie zwrócą Ci kosztów, dopóki nie zaczniesz pisać na blogu, jak bardzo są beznadziejni. To firma motoryzacyjna z Detroit, która już bardzo dawno straciła pomysł na stworzenie samochodu, który być może ktoś chciałby kupić, a zamiast tego słania się od jednej strategii marketingowej do drugiej tak, jakby jedynym powodem, że nie chcemy kupować ich gównianych samochodów, jest zbyt niski rabat.

SCal1 Wystarczy.

Zapomnij o tym. System zarządzania oparty na rozkazach i hierarchii został już wypróbowany i wydawał się działać w latach 20' w czasach konkurencji domokrążców pchających swoje wózki z towarami, ale nie nadaje się na XXI wiek. Dla firm informatycznych musisz użyć innego modelu.

W firmie informatycznej, najwyższym priorytetem dla menadżera powinno być stworzenie Warstwy Abstrakcji Programistycznej.

Jeśli programista gdzieś w firmie martwi się zepsutym krzesłem albo czeka wciąż na komputer od Della, to znaczy że ta warstwa zaczyna przeciekać.

Pomyśl o swojej Warstwie Abstrakcji Programistycznej jak o wielkim, pięknym jachcie z niesamowicie potężnym silnikiem. Jest nieskazitelny, zadbany. Posiłki dla prawdziwych smakoszy serwowane są jak w zegarku. Pokojówki sprzątają prywatne kabiny dwa razy dziennie. Mapy nawigacyjne są zawsze aktualne. GPS i radar zawsze działają, a jeśli się zepsują, zawsze jest jakiś zapasowy pod pokładem. Stojąc na kapitańskim mostku patrzysz na programistów, którzy myślą tylko i wyłącznie o prędkości, kierunku i czy na lunch wziąć łososia czy tuńczyka. W międzyczasie duża grupa profesjonalistów w wykrochmalonych, białych uniformach uwija się cichutko na paluszkach pod pokładem, utrzymując wszystko w ruchu, napełniając zbiorniki z benzyną, zdrapując skorupiaki, prasując serwetki na lunch. Dział obsługi wie, co robić, nawet mimo tego, że wskazówki otrzymuje od starego pierdziela, który ledwo co rusza ręką nadając rytm tej całej symfonii. A wszystko po to, aby programiści mogli nie myśleć o niczym związanym z jachtem poza prędkością, kierunkiem i tym, co będą jedli na lunch.

Menadżerowie w firmie informatycznej są po to, aby stworzyć Warstę Abstrakcji Programistycznej. Budujemy jacht, utrzymujemy jacht, jesteśmy jachtem, ale nie sterujemy nim. Wszystko, co robimy, sprowadza się do stworzenia nieprzeciekającej warstwy abstrakcji dla programistów tak, aby mogli pisać wspaniały kod i aby ten kod mógł dotrzeć do klientów, którzy na tym skorzystają.

Programiści potrzebują repozytorium Subversion. Dostarczenie Subversion wymaga posiadania sieci, serwera, który musi być kupiony, uruchomiony, utrzymywany, muszą być wykonywane kopie zapasowe, musi być zaopatrzony w niezawodne źródło zasilania, a taki serwer wytwarza dużo ciepła, co oznacza, że musi on stać w pomieszczeniu z dodatkową klimatyzacją, a ta klimatyzacja musi być wyprowadzona na zewnątrz budynku, co oznacza także zamontowanie 35-kilogramowego wiatraka na zewnętrznej ścianie budynku, co oczywiście denerwuje właścicieli budynku, muszą oni wezwać inżynierów, którzy określą gdzie najlepiej powiesić wiatrak (decyzja: na zewnętrznej ścianie, na osiemnastym piętrze, w najbardziej niewygodnym możliwie miejscu), no a to przywołuje od razu prawników, ponieważ musimy zrzec się swojego pierworodnego, aby móc wykonać taką instalację, a potem instalatorzy klimatyzacji zjawiają się z przyrządami do asekuracji godnymi zestawu dla Barbie, co z kolei denerwuje naczelnika, który nie pozwala na wyjście na zewnątrz budynku na osiemnastym piętrze w uprzęży firmy Mattel zrobionej z centrymetrowego różowego plastiku (przysięgam na Boga, że to mógłby być pas dyskotekowy Barbie), no i ktoś znowu musi wezwać agenta tego budynku, żeby sprawdzić dlaczego nagle uświadomili sobie (12 tygodni po zatwierdzeniu planu instalacji), że potrzebny jest kolejny aneks do umowy przez tę przeklętą klimatyzację, o której wiedzieli przed Bożym Narodzeniem, a dopiero zaczęli sobie zdawać z niej sprawę, i jeśli twoi programiści spędzą choćby minutę na zastanawianie się nad tym wszystkim, to spędzili o jedną minutę za dużo.

Dla programistów, to wszystko powinno być przykryte abstrakcją, taką jak pisanie svn commit w linii poleceń.

To jest powód, dla którego masz menadżerów.

Wszystkie te rzeczy są niezbędne do funkcjonowania firmy, ale jeśli programiści zaczynają się nimi martwić, to zarządzanie zawiodło, tak samo jak 30 metrowy jacht zawiódł, jeśli właściciel-milioner musi zejść pod pokład żeby, hmm, zbudować silnik.

Mamy typowe firmy założone przez byłych sprzedawców, gdzie wszystko jest Sprzedażą Sprzedażą Sprzedażą i wszyscy istniejemy po to, aby napędzać większą sprzedaż. Takie firmy rozpoznajemy w przyrodzie po tym, że wypuszczają wersję 1.0 oprogramowania (jakoś) i wtedy zupełnie tracą zainteresowanie produkowaniem oprogramowania. Ich drużyna programistów jest zagłodzona albo po prostu nie istnieje, bo nigdy nie udaje się im zbudować wersji 2.0... cała wiedza ich menadżerów sprowadza się do tego, jak wygenerować większą sprzedaż.

Po drugiej stronie mamy kolejne ekstremum - firmy założone przez byłych programistów. Te firmy są trudniejsze do odnalezienia, ponieważ zazwyczaj siedzą cichutko, polerując gdzieś na poddaszach kod, którego nikt nigdy nie odnajdzie, oni sami popadną powoli w zapomnienie zaraz po Wielkim Przepisaniu Systemu na Ruby, a ich kod po refaktoringu-zmieniejącym-świat będzie jakoś niedoceniony przez Ludzi.

Oba typy firm mogą być z łatwością wyparte przez firmy napędzane przez programistów i zorganizowane, aby posadzić programistów w fotelach kierowców, ale także posiadające wspaniałą abstrakcję, która wykonuje tę ciężką pracą przekuwając kod w produkt gdzieś pod pokładem.

Programista jest najbardziej produktywny w cichym, prywatnym biurze, ze wspaniałym komputerem, nielimitowanymi napojami, temperaturze otoczenia między 20 a 22 stopniami Celsjusza, bez odblasków na monitorze, na krześle, które jest tak wygodne, że go nie czujesz, z administratorem, który przynosi mu jego pocztę, zamawia podręczniki i książki, administratorem systemu, który sprawia, że Internet jest dostępny jak tlen, testerem, który znajdzie błędy, których po prostu nie sposób zobaczyć, grafikiem komputerowym, który sprawi, że ekrany interfejsu będą wyglądać pięknie, zespołem speców od marketingu, który sprawi, że masa ludzi będzie pragnąć jego produktu, zespołem sprzedawców, który sprawi, że masa ludzi dostanie jego produkt, jakichś anielsko cierpliwych ludzi od wsparcia technicznego, którzy pomogą klientom w pracy z oprogramowaniem, a także pomogą zrozumieć programistom, jakie problemy może ono stwarzać, do tego jakiś tuzin innych funkcji administracyjnych i organizacyjnych, które razem sumują się do 80% wszystkich wynagrodzeń. To nie przypadek, że Armia Rzymska miała proporcje czterech służących na jednego żołnierza. To nie była dekadencja. Nowoczesne armie prawdopodobnie mają proporcje 7:1. (A tutaj coś, czego nauczył mnie dzisiaj Pradeep Singh: jeśli tylko 20% Twojego zespołu to programiści i możesz oszczędzić 50% na ich wynagrodzeniu przenosząc oddział programistów do Indii - jak dużo przewagi wśród konkurencji możesz tak naprawdę wytworzyć z tych 10% oszczędności?)

Podstawowym zadaniem menadżerów ma być wytworzenie iluzji, że firmę da się prowadzić przez samo pisanie kodu, bo to jest właśnie to, co robią programiści. I nawet gdyby byłoby całkiem miło mieć programistów, którzy znają się na sprzedaży, grafice komputerowej, administracji systemów, gotowaniu, to jest to nierealne. To jakby chcieć nauczyć świnię śpiewać - Ty tracisz swój czas, a świnia się tylko denerwuje.

Microsoft jest bardzo dobry w tworzeniu tej iluzji tak, że ludzie, którzy odchodzą z Microsoftu notorycznie męczą się zakładając swoje własne firmy. Nie mogą po prostu uwierzyć, jak dużo działo się pod pokładem i nie wiedzą, jak to zreprodukować.

SCal4

Nikt nie oczekuje, że Dolly Parton będzie wiedziała, jak podłączyć mikrofon. Tam jest niesamowicie wielka infrastruktura menadżerów, muzyków, techników nagrań, firm nagraniowych, techników obsługujących koncerty, fryzjerów i publicystów pod spodem, która jest po to, aby sprawiać wrażenie, że samo fakt śpiewania Dolly wystarczy, żeby usłyszało ją milion ludzi. Cały ten zespół menadżerów i ludzi z obsługi wykonuje swoją pracę jak najlepiej wtedy, kiedy tworzy najbardziej perfekcyjną abstrakcję: najbardziej perfekcyjną iluzję, że Dolly śpiewa dla nas. To jest jej piosenka. Kiedy słuchasz jej na swoim iPodzie, potężna infrastruktura sprawia, że jest to możliwe, ale najlepsze, co może zrobić ta infrastruktura, to stać się kompletnie niewidoczną. Dostarczyć nieprzeciekającą abstrakcję, że Dolly śpiewa tylko dla nas.

Data publikacji oryginału: 11 kwietnia, 2006


Jak efektywnie realizować zadania, kiedy jesteś tylko szeregowym programistą

Oryginalny post: Getting Things Done When You're Only a Grunt

Autor: Joel Spolsky

Ta strona poświęcona jest głównie zarządzaniu projektami programistycznymi. Jednak czasem nie masz na tyle władzy, aby w swojej firmie dokonywać przemian za pomocą dekretów. Oczywiście, jeśli jesteś tylko szeregowym programistą, na samym dole hierarchii, nie możesz tak po prostu nakazać ludziom, aby tworzyli harmonogramy czy korzystali z systemu zarządzania bugami. W rzeczywistości, nawet jeśli jesteś kierownikiem projektu, prawdopodobnie odkryłeś, że zarządzanie programistami jest bardzo podobne do hodowania kotów, tylko nie tak zabawne. Nie wystarczy, że powiesz "sprawcie, żeby tak było", żeby tak było.

Praca w firmie, która ma kiepski wynik w Teście Joela, może być frustrująca. Nieważne jak dobry kod piszesz, Twoi współpracownicy piszą kod tak mierny, że wstydzisz się w ogóle przyznać do swojego udziału w projekcie. Albo być może decyzje zarządu odnośnie tego, jaki kod pisać, są nietrafione i jesteś zmuszony marnować swój talent na debugowanie na systemie AS/400 gry w planowanie emerytury dla dzieci.

Zawsze możesz zrezygnować, tak sądzę. Ale załóżmy, że jest jakiś powód, dla którego tam utknąłeś. Nie możesz jeszcze sprzedać przyznanych Ci akcji firmy, nie ma lepszego miejsca pracy w Wygwizdowie a może Twój szef wziął za zakładnika kogoś, kogo kochasz. W każdym bądź razie, życie w takim kiepskim zespole jest w stanie doprowadzić do wściekłości. Istnieją jednak pewne strategie, dzięki którym możesz popracować nad swoim zespołem od podstaw, a ja chciałbym teraz kilkoma z nich się z Toba podzielić.

Strategia 1. Po prostu to zrób

Wiele da się zrobić w celu poprawienia sytuacji w projekcie, jeśli po prostu jedna osoba będzie to robić. Nie macie serwera do codziennych buildów? Stwórz taki. Zrób to na swoim komputerze — skonfiguruj go tak, żeby w nocy uruchumiał builda i rozsyłał maile z wynikami. Build wymaga za dużo kroków? Napisz plik makefile. Nikt nie robi testów interfejsu użytkownika pod kątem używalności? Sam przeprowadzaj takie testy korytarzowe z przypadkowymi ludźmi, używając w tym celu kartki papieru albo prototypu napisanego w VB.

Strategia 2. Wykorzystaj potęgę marketingu wirusowego

Wiele ze strategii z Testu Joela jest w stanie wdrożyć nawet jedna osoba w niezbyt zorganizowanych zespołach. Niektóre z nich, jeśli zrobi się to odpowiednio, rozprzestrzenią się w całym zespole.

Przykładowo, załóżmy, że nikt w Twoim zespole nie daje się przekonać do korzystania z systemu zarządzania bugami. Nie pozwól, żeby Cię to zniechęciło. Po prostu sam z takiego systemu korzystaj. Wprowadzaj do niego bugi, które znajdujesz w swoim kodzie. Jeśli znajdziesz buga, którego ktoś inny naprawdę powinien poprawić, przypisz tego buga do nich w systemie. Jeśli masz dobry system zarządzania bugami, zostanie wysłany do nich e-mail. Ale na początek wystarczy, że będziesz im stale przypominał drogą mailową, że jeszcze nie poprawili tego buga. W końcu zauważą wartość takiego systemu śledzenia bugów i sami zaczną z niego korzystać w prawidłowy sposób. Jeśli zespół QA nie che wprowadzać bugów poprzez system, po prostu odmawiaj przyjmowania zgłoszeń o błędach innymi kanałami. Gdzieś koło trzytysięcznego razu, gdy mówisz ludziom, "Słuchaj, chętnie bym to naprawił, ale na pewno o tym zapomnę. Czy możesz wprowadzić informację o błędzie do systemu?", zaczną tego systemu używać.

Nikt z Twojego zespołu nie chce korzystać z systemu kontroli wersji? Załóż swoje własne repozytorium, nawet na swoim własnym dysku, jeśli nie ma innej możliwości. Nawet bez współpracy ze strony innych członków zespołu możesz wrzucać swój kod do repozytorium, niezależnie od innych. I gdy napotkają na jakiś problem, który system kontroli wersji mógłby rozwiązać (ktoś przez przypadek wpisze rm * ~ zamiast rm *~), przyjdą po pomoc do Ciebie. W końcu ludzie uświadomią sobie, że równie dobrze sami mogliby korzystać z takiego systemu.

Strategia 3. Zgromadź wokół siebie kapitał doskonałości

Zespół nie chce robić harmonogramów? Albo specyfikacji? Zrób swoje. Nikt nie będzie marudził, jeśli poświęcisz dzień lub dwa na napisanie minimalnej specyfikacji bądź harmonogramu dla prac, które zamierzasz wykonać.

Sprowadź lepszych ludzi do swojego zespołu. Zaangażuj się w rekrutację i bierz udział w rozmowach z kandydatami, żeby tych dobrych ściągnąć do swojego zespołu.

Poszukaj ludzi, którzy są zainteresowani rozwijaniem się i są do tego zdolni oraz przeciągnij ich na swoją stronę. Nawet w słabych zespołach prawdopodobnie znajdziesz ludzi, którzy po prostu jeszcze nie mają na tyle doświadczenia, żeby tworzyć znakomity kod. Pomóż im. Zachęć ich do nauki. Rób przeglądy ich kodu. Jeśli zrobią coś głupiego, nie pisz do nich pogardliwych maili, w których wytykasz głupotę w ich kodzie. To ich jedynie rozzłości i przyjmą postawę defensywną. Zamiast tego, delikatnie daj im znać o bugu spowodowanym przez ich kod. Pozwól im samym dojść do tego, co jest przyczyną błędu. Kiedy sami poradzą sobie z bugiem, zapamiętają tę lekcję o wiele lepiej.

Strategia 4. Zneutralizuj przygłupów

Nawet w najlepszych zespołach zdarza się jedna bądź dwie osoby, które, delikatnie mówiąc, nie są zbyt rozgarnięte. W sytuacjach, gdy masz do czynienia z kiepskimi programistami, są dwie główne przyczyny frustracji — kiedy ich kiepski kod psuje Twój dobry kod albo gdy dobrzy programiści muszą marnować czas na sprzątanie po tych słabszych.

Jako szeregowy programista powinieneś dążyć do minimalizacji i powstrzymywania zniszczeń. Prędzej czy później jeden z tych geniuszy spędzi całe dwa tygodnie na wyprodukowaniu kodu tak niewiarygodnie złego, że nigdy nie będzie działać poprawnie. Może Cię kusić, żeby poświęcić piętnaście minut na poprawne napisanie tego od nowa. Powstrzymaj się. Stajesz właśnie przed doskonałą okazją na neutralizację tego kretyna na dobrych kilka miesięcy. Po prostu nie przestawaj zgłaszać bugów w jego kodzie. Nie będzie dla niego innego wyjścia, jak miesiącami siedzieć przy tym kodzie i go poprawiać aż Ty nie będziesz już w stanie znaleźć nowych błędów. W ciągu tego czasu nie będą mogli narobić szkód w innym miejscu.

Strategia 5. Unikaj rozpraszaczy uwagi

Wszystkie przyjazne środowiska pracy są do siebie podobne (prywatne biura, cisza, doskonałe narzędzia, niewiele rozpraszaczy uwagi i jeszcze mniej długich spotkań). Wszystkie nieprzyjazne środowiska są nieprzyjazne na swój sposób.

Złe wiadomości są takie, że zmiana środowiska pracy jest prawie niemożliwa w praktycznie każdej firmie. Długotrwałe umowy najmu moga oznaczać, że nawet CEO nie jest w stanie nic z tym zrobić. To właśnie dlatego tak niewielu programistów ma prywatne biura. Dla firm jest to szkodliwe z co najmniej dwóch powodów. Po pierwsze, trudniej jest takiej firmie pozyskać programistów z najwyższej półki, którzy wybiorą pracodawcę oferującego wygodniejsze warunki pracy (przy założeniu, że inne aspekty są na podobnym poziomie). Po drugie, duża liczba rozpraszaczy może dramatycznie obniżyć produktywność programistów, którzy w takich warunkach nie są w stanie "wejść w strefę" i pozostać w niej tak długo, jak tego potrzebują.

Rozglądnij się za sposobami na ucieczkę z takiego środowiska. Zabierz ze sobą laptopa do firmowej kawiarni, gdzie przez większą część dnia jest pusto (i nikt nie może Cię znaleźć). Zarezerwuj pokój konferencyjny na cały dzień i tam pisz kod. Jednocześnie pokaż za pomocą liczby checkinów, o ile więcej jesteś w stanie zrobić, gdy masz cały pokój tylko dla siebie. Następnym razem, gdy atmosfera zrobi się gorąca ze względu na zbliżający się deadline i Twój kierownik zapyta, czego potrzebujesz, żeby To Zrobić Na Jutro, wiesz co odpowiedzieć. Z pewnością znajdą Ci jakieś biuro na cały dzień. I niedługo zaczną się zastanawiać, co mogliby zrobić, żeby utrzymać tak wysoki poziom produktywności przez cały rok.

Zjawiaj się w pracy poźno i wychodź późno. Te godziny po tym, gdy reszta firmy wybrała się już do domów, mogą być tymi najbardziej produktywnymi. A jeśli większość Twojego zespołu przychodzi do pracy późno, Ty przychodź o 9. W ciągu tych dwóch godzin, które masz do dyspozycji, zanim pozostali zaczną się schodzić i przeszkadzać, zrobisz więcej niż przez resztę dnia.

Nie zostawiaj swojego klienta poczty ani komunikatora włączonych przez cały czas. Jeśli chcesz, sprawdzaj pocztę nawet co godzinę, ale nie zostawiaj klienta włączonego.

Strategia 6. Stań się nieoceniony

Żadna z tych strategii nie zadziała, jeśli sam nie wnosisz dużej wartości. Jeśli nie piszesz dobrego kodu, i to sporo dobrego kodu, ludzie będą mieć do Ciebie pretensje, że dłubiesz sobie przy systemie zarządzania błędami, podczas gdy "powinieneś" pisać kod. Nie ma nic bardziej zabójczego dla Twojej kariery zawodowej niż posiadanie reputacji kogoś, kto bardziej przejmuje się procesem niż tym, żeby cokolwiek ukończyć.

Kiedyś, gdy zaczynałem pracę w pewnej firmie jako szeregowy programista, odkryłem, że ta firma osiągała około 2 punktów w Teście Joela i byłem zdeterminowany, żeby to zmienić. Wiedziałem jednak również, że pierwsze wrażenie jest bardzo ważne. Postanowiłem więc przeznaczyć pierwsze siedem godzin każdego dnia na pisanie kodu, tak jak się tego ode mnie oczekiwało. Nic lepiej nie poprawi Twojego wizerunku w zespole, jak zalew checkinami. Natomiast ostatnią godzinę przed pójściem do domu zarezerowałem sobie na ulepszanie procesu. Wykorzystywałem ten czas na naprawianie rzeczy, które utrudniały debugowanie naszego projektu. Skonfigurowałem dzienne buildy i system zarządzania bugami. Naprawiłem wszystko to, co od długiego czasu stanowiło dla zespołu udrękę i spowalniało cały proces. Pisałem specyfikacje dla pracy, którą miałem danego dnia wykonać. Przygotowałem dokument, w którym opisałem, jak od podstaw przygotować maszynę dla developera w naszej firmie. Gruntownie udokumentowałem ważny, wewnętrzny język, którego nikt wcześniej nie opisał. Powoli proces stawał się coraz lepszy. Nikt poza mną (i moim zespołem, któremu później przewodziłem) nie tworzył harmonogramów ani specyfikacji, ale poza tym osiągnęliśmy 10 punktów w Teście Joela.

Jesteś w stanie wiele poprawić, nawet jeśli to nie Ty rządzisz, ale musisz być jak żona Cezara: poza wszelkimi podejrzeniami. W przeciwnym razie będziesz tylko zdobywał nowych wrogów.

Data publikacji oryginału: grudzień 25, 2001

Ostateczne programistyczne kata

Oryginalny post: The Ultimate Code Kata

Autor: Jeff Atwood

Gdy przeglądałem ostatnio obszerne zasoby opublikowane przez Steve'a Yegge, moją szczególną uwagę przykuł wpis z 2005 roku traktujący o ćwiczeniu programowania:

W przeciwieństwie do tego, co możesz sobie myśleć, zwyczajne wykonywanie swojej pracy dzień w dzień nie zalicza się do prawdziwego treningu. Uczestnictwo w spotkaniach nie poprawi Twoich zdolności interpersonalnych, a odpowiadanie na maile nie jest ćwiczeniem pisania na klawiaturze. Jeśli chcesz być w czymś lepszy, musisz wygospodarować trochę czasu na systematyczne i świadome ćwiczenia.

Znam wielu wspaniałych inżynierów — jest to jedna z najwiekszych zalet pracowania w Amazonie — i jeśli przyjrzeć im się z bliska, okazuje się, że oni nieustannie trenują. Nieważne jak dobrzy są w danym momencie, wciąż ćwiczą. Robią to na wiele różnych sposobów, z których kilka przedstawię w niniejszym tekście.

Znakomici inżynierowie, których znam, dlatego są znakomici, ponieważ trenują nieustannie. Osoby o doskonałej kondycji pracują na nią systematycznie, w przeciwnym razie ją utracą. To samo tyczy się programowania i inżynierii.

Trzeba jednak zwrócić uwagę na pewną różnicę. Mogę codziennie jeździć samochodem do pracy, ale daleko mi do zawodowego kierowcy. Analogicznie, programowanie dzień w dzień może nie być wystarczające, aby zostać profesjonalnym programistą. Zatem cóż takiego może przekształcić kogoś w zawodowego kierowcę lub programistę? Co Ty robisz, aby się rozwijać?

Odpowiedź znajduje się w artykule The Expert Mind opublikowanym w Scientific American:

Ericsson twierdzi, że to nie doświadczenie jako takie ma największe znaczenie, ale "świadome, ukierunkowane uczenie się", które obejmuje nieustanne podejmowanie wyzwań leżących poza zasięgiem aktualnych kompetencji. Właśnie dlatego możliwe są sytuacje, gdy entuzjaści spędzają dziesiątki tysięcy godzin, grając w szachy, golfa lub na instrumencie i nigdy nie wychodzą poza poziom amatorski a odpowiednio wyszkolona osoba może przewyższyć ich umiejętnościami we względnie krótkim czasie. Interesująca jest również obserwacja, że sam czas poświęcony na granie w szachy, nawet w turniejach, wydaje się mieć dużo mniejszy wpływ od właściwego uczenia się na postępy gracza; główną zaletą takich gier jest to, że pozwalają zauważyć swoje słabości, które później można eliminować w procesie doskonalenia się.

Ukierunkowane i wymagające wysiłku uczenie się oznacza nieustanne rozwiązywanie problemów leżących na samej granicy Twoich zdolności. Problemów, dla których prawdopodobieństwo porażki jest wysokie. Jeśli w ogóle nie ponosisz porażek, prawdopodobnie nie rozwijasz się zawodowo. Musisz szukać tego typu wyzwań i nie bać się wykraczać poza strefę komfortu.

Takie wyzwania można czasem znaleźć w pracy, ale nie zawsze. Odseparowanie treningu od zawodu jest często nazywane programistycznym kata.

Ilustracja Kata

Koncepcja kata, czyli choreograficznego układu wyćwiczonych ruchów, zapożyczona została ze sztuk walki.

Jeśli szukasz jakichś przykładów programistycznego kata — sposobów na ukierunkowane i wymagające wysiłku trenowanie programistycznych umiejętności — artykuł Steve'a zawiera trochę doskonałych pomysłów, od których mógłbyś zacząć. Steve mówi o nich jak o musztrze:

  1. Napisz swoje CV. Wymień w nim wszystkie istotne umiejętności a następnie zanotuj, które z nich będą potrzebne za 100 lat. Oceń każdą ze swoich zdolności w skali od 1 do 10.
  2. Zrób listę programistów, których podziwiasz. Spróbuj uwzględnić również tych, z którymi aktualnie pracujesz, ponieważ do niektórych ćwiczeń będziesz ich potrzebował. Wymień po jednej, dwóch rzeczach, w których są oni dobrzy — takich, w których sam chciałbyś się podszkolić.
  3. Wybierz jedną osobę z listy "czołowych pionierów informatyki" i poczytaj o niej. Podążaj stamtąd za każdym odnośnikiem, który wyda Ci się interesujący.
  4. Poczytaj czyjś kod przez 20 minut. W tym ćwiczeniu powinieneś czytać na zmianę znakomity i kiepski kod; każdy z nich może Cię czegoś nauczyć. Jeśli nie jesteś pewien, na czym polega różnica, poproś jakiegoś programistę, którego szanujesz, żeby pokazał Ci przykłady kodu jednego i drugiego typu. Pokaż komuś kod, który czytasz i dowiedz się, co inni o nim myślą.
  5. Zrób listę 10 swoich ulubionych narzędzi programistycznych: takich, których używasz najczęściej, bez których praktycznie nie mógłbyś żyć. Poświęć godzinę na przeczytanie dokumentacji do jednego z tych narzędzi, wybranego losowo. Podczas tej godziny postaraj się nauczyć czegoś nowego o tym narzędziu, poznaj nowe funkcjonalności albo zastanów się nad nowymi sposobami jego wykorzystania.
  6. Wybierz coś, w czym jesteś dobry, ale co nie ma nic wspólnego z programowaniem. Zastanów się, w jaki sposób trenują zawodowcy lub wielcy mistrzowie tej dyscypliny. Czego możesz się od nich nauczyć i przenieść na grunt programowania?
  7. Zbierz trochę życiorysów zawodowych i grupę osób w jednym pokoju na godzinę. Upewnij się, że każde CV zostało obejrzane przez przynajmniej 3 osoby, które powinny zapisać swoje inicjały oraz ocenę (1-3). Przedyskutujcie te CV, dla których uzyskaliście dużą rozbieżność ocen.
  8. Przysłuchaj się telefonicznej rozmowie z kandydatem na stanowisko programisty. Zapisuj swoje przemyślenia, oceń kandydata a następnie porozmawiaj z osobą przeprowadzającą rozmowę, żeby dowiedzieć się, czy doszliście do takich samych wniosków.
  9. Przeprowadź techniczną rozmowę z kandydatem, który jest ekspertem w swojej dziedzinie, a o której Ty za wiele nie wiesz. Poproś go o tłumaczenie zagadnień od samych podstaw, zakładając Twój brak jakiejkolwiek wiedzy na ten temat. Mocno się postaraj nadążać za tym, co mówi, w razie potrzeby zadając dodatkowe pytania.
  10. Postaraj się o możliwość uczestnictwa w czyjejś rozmowie rekrutacyjnej. Słuchaj i ucz się. Próbuj w głowie rozwiązywać zadania stawiane kandydatowi, podczas gdy on sam pracuje nad ich rozwiązaniem.
  11. Znajdź kogoś, z kim będziesz mógł wymieniać się pytaniami ćwiczebnymi. Zadawajcie sobie pytania programistyczne na zmianę, co tydzień. Poświęcajcie od 10 do 15 minut na próby rozwiązania problemu i 10 do 15 minut na dyskusję (niezależnie od tego, czy rozwiązanie zostało znalezione).
  12. Gdy usłyszysz jakieś rekrutacyjne zadanie programistyczne, którego jeszcze sam nie rozwiązywałeś, wróć do biurka i wyślij sobie to zadanie na maila jako przypomnienie. Rozwiąż to zadanie w wolnej chwili w tym samym tygodniu, używając swojego ulubionego języka programowania.

Lista Steve'a podoba mi się, ponieważ jest do pewnego stopnia holistyczna. Niektórzy programiści, gdy słyszą termin "trening", nie są w stanie wyjść ponad programistyczne puzzle. Natomiast dla mnie w programowaniu bardziej chodzi o ludzi, nie kod, tak więc jest pewna granica rozwoju, której nie przekroczysz, rozwiązując nawet najbardziej zawiły na tej planecie problem programistyczny z rozmowy rekrutacyjnej.

Podobają mi się również ogólne wskazówki Petera Norviga na temat ukierunkowanego uczenia się, które zawarł w artykule Naucz się programowania w 10 lat.

  1. Rozmawiaj z innymi programistami. Czytaj cudzy kod. Jest to ważniejsze niż jakakolwiek książka czy kurs.
  2. Programuj! Najlepszy sposób uczenia się polega na nauce poprzez robienie.
  3. Uczęszczaj na zajęcia z programowania na poziomie licencjackim bądź uniwersyteckim.
  4. Poszukuj i pracuj nad projektami zespołowymi. Przekonaj się, jak to jest być zarówno najlepszym, jak i najgorszym programistą w zespole.
  5. Pracuj nad projektami po tym, jak ich oryginalni autorzy zaprzestali się nimi zajmować. Naucz się, jak utrzymywać kod nienapisany przez Ciebie. Naucz się pisać kod, który ludzie po Tobie będą w stanie efektywnie utrzymywać.
  6. Naucz się różnych języków programowania. Wybierz języki, których modele programowania są odmienne od tego, czego używasz na co dzień.
  7. Dowiedz się, jak sprzęt wpływa na to, co robisz. Jak długo zajmuje Twojemu komputerowi wykonanie pojedynczej instrukcji, pobranie słowa z pamięci (z cachem i bez), przesłanie danych przez kabel ethernetowy (lub przez Internet), przeczytanie następujących po sobie słów z dysku albo przeskoczenie do nowego miejsca na dysku?

Inspiracji możesz również poszukać, czytając Dave'a 21 pragmatycznych kata programistycznych, a może chciałbyś przyłączyć się do Programistycznego Dojo w Twojej okolicy.

Ja sam nie mam tak długiej listy ćwiczeń jak Steve, Peter czy Dave. Jestem zbyt niecierpliwy na coś takiego. Właściwie to w mojej książce o programistycznym kata znajdują się dwie pozycje:

  1. Prowadź bloga. Ja sam zacząłem pisać tego bloga na początku 2004 roku właśnie jako formę ćwiczenia. Zaczynając skromnie, później okazało się, że jest to jedna z najbardziej znaczących rzeczy, które zrobiłem w swojej zawodowej karierze. Ty również powinieneś prowadzić bloga. To właśnie ludzie, którzy potrafią pisać i efektywnie się komunikować, są często tymi, których się słucha. To oni mogą dyktować warunki debaty.
  2. Aktywnie udzielaj się w jakimś znanym projekcie open-source'owym albo trzech. Całe to gadanie bla bla bla jest super, ale czy jesteś gawędziarzem czy człowiekiem czynu? Jest to bardzo ważne, ponieważ rozliczany będziesz ze swoich czynów, nie słów. Postaraj się zostawiać za sobą ślad konkretnych, publicznych i użytecznych rzeczy, na które możesz wskazać i powiedzieć: pomogłem to zbudować.

Gdy już potrafisz pisać genialny kod i genialną prozę, za pomocą której ten kod objaśniasz światu — cóż, wydaje mi się, że to jest właśnie ostateczne programistyczne kata.

Data publikacji oryginału: czerwiec 22, 2008

Dupkowatość

Oryginalny post: Douchebaggery

Autor: Jeff Atwood

David Heinemeier Hansson ma problem z systemem Windows jako platformą do programowania.

O ile naturalnie potrafię zrozumieć powody, dla których niektórzy wybierają Linuxa, to w ogóle nie potrafię zrozumieć programistów, którzy świadomie wybierają Windowsa jako swoją platformę. Znam kilku, którzy ciągle tkwią w rutynie z różnych powodów — żaden z nich tego nie pragnie.

Miałbym trudność w wyobrażeniu sobie, iż zatrudniam do 37signals kogoś, kto tkwi na platformie Windows. Jeśli wystarczająco nie dbasz o to, aby wykorzystywać najlepsze narzędzia, udowodnienie postawionej przez Ciebie tezy staje się o wiele trudniejsze.

Tak więc jeśli jeszcze się nie przekonwertowałeś, przestań prokrastynować. Przebolej to. Jeśli pragniesz pracować dla coraz bardziej znaczących firm, które budują swój biznes w oparciu o technologie open source'owe, to nie chcesz ciągnąć za sobą takiego piętna w życiorysie. Bycie tym, który przekonwertował się w 2005 roku jest wystarczająco złe.

Mocna inwektywa, ale taki jest styla David'a. Aby być uczciwym, jego najważniejszy argument — że jeśli cenisz sobie programowanie aplikacji open source'owych, to będziesz używał platformy przyjaznej oprogramowaniu open source'owemu — jest dość przekonujący, choć oczekiwałbym, iż zatwardziali kolesie od OSS będą chcieli Wolności 0 zarówno w swoich systemach operacyjnych jak i w oprogramowaniu, które tworzą. Jeśli miałbym aż tak silne przekonania co do OSS, to szczerze powiedziawszy postrzegałbym ludzi tkwiących na platformie OS X z lekkim podejrzeniem.

Ale czy konieczne jest takie uogólnianie? Sugerować, że programiści używający Windows'a "nie dbają dostatecznie o to, aby używać najlepszych narzędzi"? Po tysiącach religinych wojen, w których uczestniczyłem, uodporniłem się na krytykę, więc ta nie porusza mnie za bardzo. Nie zgodzę się z problemem David'a, ponieważ jeśli chodzi o komputery i systemy operacyjne, to nie ma czegoś takiego jak "najlepszy". Moja opinia jest taka, że wszystkie są beznadziejne. Oczywiście, są pewne kompromisy, zalety i wady, mocne i słabe punkty. Ale obiektywnie najlepszy? Wszystko jest względne.

Zanim wszyscy naskoczycie na David'a, przeczytajcie jego wpisy kontynuujące myśl (pierwszy, drugi) na grupach dyskusyjnych Ruby, które tłumaczą jego stanowisko w bardziej spójny i mniej burzący sposób. Argument za tym, że 37signals nie zatrudniłoby programisty operującego na systemie Windows ma tyle wspólnego z kulturą, co nic innego. To tak, jakby pokazać się na przesłuchaniu w sprawie pracy w firmie Coca-Cola siorbiąc sobie Pepsi. Na nieszczęście, David poczuł potrzebę przeobrażenia tego wymagania w kwestię gustu. Ogłosił, iż Coca-Cola jest moralnie i estetycznie lepszym wyborem, aniżeli zwykłą preferencją na konkretny rodzaj słodzonego napoju, którym tak naprawdę jest.

Ten wpis został napisany w marcu 2005 roku, ale David wyraził te same uczucia we fragmencie z i-Technology Predictions for 2007.

Apple będzie beształo każdego za jego preferowaną platformę. Piętno bycia programistą webowym używającym platformy Windows będzie narastać.

To jest to, czego nie rozumiem w tego typu stwierdzeniach. Mają zupełnie odwrotny skutek, niż ten zakładany przez mówcę. Są dwie możliwe reakcje:

  1. Wow, David ma rację. Dokonałem złego wyboru w mojej karierze. Najwyższy czas, aby przyjrzeć się platformie OS X oraz programowaniu w Rails. To brzmi świetnie!
  2. P****************ol się.

Zgadnij, która reakcja jest bardziej powszechna? W zasadzie, to nie trzeba zgadywać jako, iż zapewniam Cię, że każdy programista platformy Windows, który to czyta, myśli teraz o punkcie #2. Jako ewangelista chcący zwiększyć popularność swojej platformy, używa wybitnie kiepskiej strategii. Czy przymuszanie ludzi do tego, aby się z Tobą zgodzili kiedykolwiek skutkowało?

Oczywiście, tak jak David mówił wiele, wiele razy, nie obchodzi go, czy się z nim zgadzamy czy nie. Cóż, może nie w tylu słowach, ale rozumiesz przesłankę:

David Hainemeier Hansson: Fuck You

Prawdę mówiąc doceniam to uczucie, ponieważ widziałem zbyt wielu ludzi, którzy dali się pochłonąć przez to, że inni ludzie myśleli o nich, że nie potrafią potwierdzić swojej początkowej opinii na temat czegokolwiek. Ale jeśli zaakceptujesz przesłankę, że takie stwierdzenie nie jest w stanie zmienić niczyjego zdania i ostatecznie jest nieefektywne — a nawet przynoszące efekt odwrotny do zamierzonego — z czym pozostajemy? Jaką intencję niesie za sobą wyrażenie "piętno bycia programistą na platformę Windows"? Mnie przychodzi do głowy tylko jedna: mówienie o innych źle sprawia Davidowi przyjemność.

A to, czyni z niego pewnego rodzaju dupka.

Co również oznacza, że jeśli używasz Rails'ów oraz OS X, to używasz platformy z wyboru dla dupków.

Samurai Shodown 2 character select screen

Byłem kiedyś zapalonym graczem Samurai Shodown II. Grałem jako Earthquake, niesamowicie gruby, niesamowicie teksański ninja. Stałem się tak dobry w graniu postacią Earthquake, że byłem w stanie pokonać każdego, kto przybył na Colorado arcade do Boulder, gdzie często bywałem. Przyczyniło się to do komentarza jednego sfrustrowanego gracza:

Jesteś do kitu! Dokopujesz nam za pomocą najgorszej postaci w grze!

W rzeczy samej. Nie ma nic bardziej satysfakcjonującego, niż skopanie komuś tyłka za pomocą najgorszej postaci w grze. Po jakimś czasie grania w tę nadzwyczaj zbalansowaną bijatykę, uzmysłowiłem sobie, iż każda możliwa postać ma swoje wady i zalety. Opanowanie gry oznacza zrozumienie postaci oraz maksymalizowanie działania swoich mocy przy jednoczesnym wykorzystywaniu słabości przeciwnika. Jeśli byłeś wystarczająco mądry i cierpliwy, mógłbyś pokonać dowolną postać za pomocą każdej innej. To była umiejętność.

Nie trać czasu na kłótnię o ekranie wyboru postaci. Wyniki mówią wyraźnie. Pokaż światu, co potrafisz w wybranym przez siebie środowisku programistycznym.

Data publikacji oryginału: 26 lutego, 2008

Pisanie dobrej dokumentacji: styl

Oryginalny post: Writing great documentation: Technical style

Autor: Jacob Kaplan Moss

Jako że omówiliśmy już jakie rodzaje dokumentacji należy tworzyć, możemy przejść do odpowiedzi na pytanie jak należy rozwinąć styl, dzięki której taką dokumentację będzie dało się czytać.

Naucz się pisać

Niestety, nie ma tutaj dróg na skróty. Najlepszym sposobem na nauczenie się jak pisać dobrą dokumentację jest najpierw nauczyć się pisać (cokolwiek). Istnieją pewne istotne różnice między dokumentacją techniczną i Twoją przeciętną prozą, ale solidne podstawy w komunikacji pisemnej są wymaganiem nie do zastąpienia.

Więc jak nauczyć się pisać (cokolwiek) dobrze? Jest tylko jedna odpowiedź: nauczysz się pisać dobrze, jeśli będziesz pisał. Dużo.

Pisanie po angielsku nie różni się niczym od pisania kodu: im więcej piszesz, tym lepiej to robisz. Mógłbyś wziąć lekcję - większość szkół ma całkiem niezłe lekcje dla początkujących - ale ważnym jest, żeby po prostu dużo pisać. Po pewnym czasie będzie lepiej.

To właśnie tak Ci z nas, którzy uzyskali tytuły z nauk humanistycznych (mam tytuł z literatury angielskiej, znany także jako B.A. in B.S.) stają się dobrymi pisarzami: nasze tytuły zmuszają nas do pisania tak długo, aż zacznie przychodzić nam to z łatwością. Myślę, że pisałem od dziesięciu do dwudziestu stron każdego tygodnia w ciągu czterech lat studiów. Zmusiło mnie to do przyswojenia zasad gramatyki i ukształtowania własnego stylu.

Prawdopodobnie dobrze byłoby zbalansować ilość pisanego tekstu zdrową ilością tekstu czytanego. Naucz się określać mechaniczne części tego, co czyni kawałek tekstu efektywnym; spróbuj zidentyfikować, co przynosi sukces, a co porażkę we wszystkim co czytasz.

Zwróć uwagę na to, co pozwala autorom uzyskać "ton". Przeczytaj pewną ilość tekstów tego samego autora; powinieneś być w stanie zidentyfikować to, co czyni teskty tej osoby odróżnialnymi od innych. Malcolm Gladwell byłby tutaj dobrym wyborem: jego styl jest dość wyróżniający się, w pewien sposób wzorcowy, a także ma tuziny swoich artykułów dostępnych online. Co najważniejsze, styl Gladwell'a jest jednym z tych, które dość dobrze nadają się dla dokumentacji technicznej - ma odświeżający, zabawny, konwersacyjny ton, który przekazuje jasno techniczne zagadnienia.

Nie ma wielkiego znaczenia, co piszesz i czytasz. Jasne, istnieją osobne zasady pisania fikcji i nie-fikcji, literackiego krytycyzmu i dokumentacji technicznej, itd. Ważne aspekty się jednak nie zmieniają: dobry tekst jest jasny, zwięzły i efektywnie przekazuje idee.

Najważniejsze: nie pozwól swojemu stylowi Cię zatrzymać. Za chwilę przejdę do zasad i wskazówek dotyczących dobrej gramatyki i stylu. Łatwo dać się złapać w pułapkę prozy idealnej od pierwszych słów. To tak nie działa. Podczas pisania, ucisz wewnętrznego krytyka i po prostu pisz. Możesz pozwolić krytykowi przemówić, gdy czytasz i poprawiasz napisany tekst, ale ważnym jest żeby to po prostu zrobić. Nie pozwól proszę, żeby cokolwiek, o czym wspomnę za chwilę, stanęło Ci na drodze.

Gramatyka

Tak, musisz używać poprawnej gramatyki. Konwencje w gramatyce istnieją po to, by pomóc nam jasno przekazać swoje myśli bez niejednoznaczności czy dezorientacji. Musisz zrozumieć różnicę pomiędzy "its" oraz "it's;" między "there," "they're" i "their;" musisz też zrozumieć, dlaczego wstawiam przecinki w tym zdaniu wewnątrz cudzysłowów, a nie na zewnątrz. (Jako że moi słuchacze to głównie programiści, nie powinienem spędzać dodatkowego czasu nad tłumaczeniem, dlaczego spójne ustawianie średników jest tak ważne!)

Jeśli chodziłeś do publicznej szkoły w Stanach, prawdopodobnie się tego nauczyłeś. Jeśli Twoja szkoła była jakkolwiek podobna do mojej, prawdopodobnie zapomniałeś o tym wszystkim krótko po tym, jak tą szkołę opuściłeś.

Tak więc lekcje pisania mogłyby pomóc, jeśli lubisz się uczyć w taki sposób. Ja sam mam kilka książek, które zawsze mam pod ręką:

  • The Elements of Style Strunk'a i White'a jest prawdopodobnie najbardziej znaną książką na temat gramatyki i stylu. Jej zwięzły i dowcipny styl sprawia, że czyta się ją z prawdziwą przyjemnością - bardzo nietypowe dla tekstów o gramatyce. Jest odrobinę stara (w istocie, pojawiło się ostatnio kilka sprzeciwów przeciw radom serwowanym przez S&W), ale jeśli potraktujesz serio Strunk'a i White'a, wyprzedzisz o głowę przeciętnego pisarza.

    (Istnieje piękna edycja z okazji pięćdziesięciolecia, jeśli pragniesz zostać posiadaczem edycji stosownej do zawartości).

  • A Pocket Style Manual Diany Hacker. To jest sensowny, podręczny przewodnik po gramatyce, interpunkcji i mechanice. Jako dodatek, ma odnośniki do przewodników Chicago Manual, Modern Language Association (MLA) i American Psychological Association (APA).

  • Mimo że rzadziej z niej korzystam, uważam że Handbook of Technical Writing jest całkiem użyteczna. Jest to olbrzymi, obszerny przewodnik od A do Z po języku - jest rozdział o "its" i "it's," jeden o "no doubt but", i tak dalej. (Jestem pewien, że jest tam rozdział o "i tak dalej.") Nie polecałbym zaczynania od tej publikacji; korzystaj z niej raczej jako z podręcznika do wyszukania zasad dotyczących konkretnego sformułowania.

Styl

Moment. Czym są przewodniki po stylu?

Podczas gdy zasady gramatyki są (raczej) utrwalone, jest mnóstwo sposobów na sformalizowanie stylu. Przewodniki po stylu mówią Ci, kiedy wykorzystywać liczebniki, a kiedy zapisywać je jako liczby, kiedy korzystać z krótkich, a kiedy z długich myślników, jak cytować źródła i zawierają wszelkie inne zasady sztuki.

Trzy, które omawia Hacker - Chicago Manual, MLA oraz APA - to jedne z najpowszechniejszych używanych w publikacjach akademickich. The Chicago Manual jest popularny w socjologii i historii; MLA jest używany przez większość publikacji literackich, medialnych i kulturalnych; APA formułuje podstawy dla przewodników stylu dla publikacji naukowych. Jest jeszcze sporo innych przewodników po stylu - duże publikacje takie jak New York Times czy New Yorker mają własne przewodniki. Jeżeli jednak nie jesteś językowym świrem, to jest to raczej nudna lektura.

Dokumentacja Django czerpie głównie z książki Associated Press, składając w ten sposób swego rodzaju hołd korzeniom prasowym Django.

Summa summarum, nie ma jednak olbrzymiej różnicy. Ważnym jest, żeby z tego wszystkiego zapamiętać, żeby być spójnym. Czytelników odrzuca mnogość stylów, a te wprowadzają niezrównoważony, niedokończony ton dokumentacji. Wybierz styl, naucz się go, a później się go trzymaj... czasami.

Styl dobrej dokumentacji

Oczywiście, ostrożne łamanie zasad czyni dobry tekst lepszym. Większość zasad, które znajdziesz w tych przewodnikach, jest zorientowanych w stronę publikacji akademickich; ja jednak staram się pomóc Ci pisać lepszą dokumentację. Są pewne istotne różnice. Większość przewodników po stylach zakłada, że efekt końcowy będzie prezentowany w formie papierowej; większość dokumentacji technicznej jest jednak wykorzystywana on-line.

Jest to prawdopodobnie powszechnie wiadome, że ludzie czytają inaczej z ekranu komputera; prawdopodobnie jest też prawdą, że ludzie inaczej czytają dokumentację techniczną niż materiały naukowe.

Zatem, pozostała część tego artykułu będzie omawiać obszary, w których dobra dokumentacja narusza zasady dobrego stylu opisanego przez S&W, Hacker, i innych.

Adjustacja

Jest pewna olbrzymia różnica w sposobie, w jaki ludzie czytają słowo drukowane i słowo elektroniczne: gdy ludzie czytają materiały online, prześlizgują się po niej. Kolejne badania wykazały, że czytelnicy opuszczają spory odsetek słów widocznych na ekranie komputera.

Oznacza to, że dobra dokumentacja online będzie opierała się w znacznie większym stopniu na znacznikach, niż pozwala większość przewodników po stylach. W praktyce oznacza to:

  • Swobodnie korzystaj ze znaczników.

    Głównie oznacza to częste wykorzystywanie podkreśleń i uwydatnień. Ja zwykle staram się unikać zbyt wielu uwydatnień ponieważ wygląda to jakbym małpował Jakoba Nielsena, ale co tam. Podobnie, korzystaj ze znaczników dla rzeczy takich jak fragmenty kodu, wejście kontra wyjście i tym podobne.

    Przełamuje to monotonię dużych kawałków tekstu i pozwala użytkownikom prześlizgiwać się pomiędzy różnymi "ważnymi" częściami tekstu.

  • Niech Twoje paragrafy będą krótkie.

    Jeśli porównasz dobrą dokumentację do typowego artykułu w magazynie czy rozdziału książki, szybko zauważysz olbrzymią różnicę w rozmiarze paragrafów. Książka może mieć paragrafy złożone z dziesięciu, dwudziestu, czy tuzinów zdań; rzadko jednak dokumentacja online ma choćby połowę z tego. Najdłuższe paragrafy w tym tekście mają około 5-6 zdań.

    Ponownie, czytelnicy prześlizgują się po cyfrowym dokumencie. Dzielenie Twoich myśli na mniejsze kawałki wspiera ten sposób poruszania się po tekście i zapewnia, że ważne elementy nie zostaną pominięte tylko dlatego, że są zakopane w środku ściany tekstu.

  • Wykorzystuj różnorodne elementy strukturalne.

    Piśmiennictwo akademickie czy żurnalowe nie wykorzystuje wypunktowań, tabel, bloków kodu i tym podobnych. Większość przewodników po stylach pomija je, a nawet zabrania ich wykorzystywania. Te elementy są jednak kluczowe dla dokumentacji technicznej: tabele i wypunktowania są ważnymi sposobami przedstawiania materiału.

    Komentarz

    Wyróżnione części listingu lub wyróżnione objaśnienia do rysunków są wyjątkowo przydatne; przykuwają uwagę do tych kawałków zawartości, które w przeciwnym wypadku mogłyby umknąć, dostarczają zabawnych i interesujących dygresji lub wskazują na to, że dany fragment jest wyjątkowo istotny.

  • Uczyń strukturę tekstu widoczną.

    Twój nauczyciel angielskiego prawdopodobnie uczył, że nagłówki do sekcji są "w złym stylu" i że cały tekst razem wzięty powinien "płynąć". To "płynięcie" jest bardzo istotne, ale trudne do osiągnięcia w tekstach technicznych. Jeśli się uprzesz, zostaniesz z bezsensownymi przejściami: "jako że omówiliśmy już adresy URL, porozmawiajmy o modelach!".

    Nagłówki są wyjątkowo ważne: zatrzymają czytelników przelatujących po tekście. Nagłówki pomagają czytelnikowi szybko odnaleźć interesującą ich sekcję dokumentu.

Powyższe może się wydawać oczywiste tym, którzy publikowali w sieci od jakiegoś czasu. O to chodzi; większość dokumentacji technicznej jest czytania online, więc większość tych rad sprowadza się do optymalizacji zawartości pod czytanie online. Dokumenty zaprojektowane pod druk cierpią, gdy są czytane online; tak więc, jeśli tylko czytasz o stylu, zawsze zastanów się nad tym, czy dana rada ma zastosowanie online.

Styl

Czytelnicy materiałów online mają inne oczekiwania w kwestii stylu. Istnieje pewien styl, który nadaje się do materiałów online i wspiera proces nauczania - który dokumentacja wspierać powinna.

Sprowadza się to głównie do bycia osiągalnym. Większość przewodników po stylu jest zorientowanych w stronę środowisk akademickich, a publikacje akademickie są wiecznie formalne. Oczekiwania wobec dokumentu online są inne i to, co może być stosowne dla żurnalu dla krytyków literackich jawi się jako przestarzałe i głupie w środowisku online.

Sugeruję więc:

  • Utrzymaj styl konwersacyjny.

    Pisz w sposób podobny do tego, w jakim mówisz. Nie chodzi o to, żeby korzystać z tych wszystkich werbalnych przeszkadzajek ("well", "you see", "um...") ani też zupełnie porzucać zasady gramatyki. Jeśli korzystasz z "gonna" w dokumencie technicznym, znienawidzę Cię ("I'm gonna hate you).

    Nie mniej jednak to znaczy, że skróty sa w porządku - tak samo jak zaczynanie zdań od spójników.

  • Nie obawiaj się uderzyć w osobisty ton.

    Prawdopodobnie nauczyłeś się nigdy nie korzystać z "ja" w formalnym wypracowaniu. Cóż, jestem tu by Ci powiedzieć, że to zupełnie w porządku w tekstach technicznych. Ukazywanie swojej osobistej opinii pomaga czytelnikom identyfikować się z tekstem i czyni materiał mniej odstraszającym.

    Musisz być ostrożny i spójny w kwestii zaimków we wspólnych pracach. Możesz zdecydować się na wyłączne używanie "ja," nawet w pracach pisanych przez innych autorów. Leonard Richardson i Sam Ruby obrali tą drogę w RESTful Web services. Możesz też użyć "my", nawet w częściach napisanych przez jednego autora. Adrian I ja wybraliśmy ten sposób w Django book. Tak długo, jak pozostajesz spójny, każde z podejść się nadaje.

  • Bądź ostrożny z czasami i osobami.

    Większość dokumentacji, a zwłaszcza tutoriale, jest napisana w drugiej osobie, w czasie przyszłym. To teksty typu "Po pierwsze, będziesz musiał zainstalować FooBar w wersji 7. Następnie, gdy już skonfigurowałeś whizbang, możesz zacząć pracę z doodad". To jest ogólny sposób, który preferuję, jako że dokumentacja to materiał głównie instruktażowy, a ja lubię to próżne poczucie osobistego kierowania czytelnikami.

    Kolejnym powszechnym sposobem jest wyrażanie wszystkiego w pierwszej osobie liczby mnogiej: "Po pierwsze, musimy zainstalować FooBar w wersji 7..." To ma swoje zalety: implikuje, że autor jest tuż obok, wśród ogromu rzeczy wokół czytelnika. Może to jednak prowadzić do pewnego zagmatwania, gdy autor naraz zacznie próbować przejść na styl bardziej konwersacyjny.

    I znów, nie ma "poprawnego" sposobu; będziesz jednak chciał przemyśleć tą sprawę, utworzyć standard, a później się go trzymać.

  • Uważaj na tryb bierny.

    Prawdopodobnie nauczyłeś się unikać strony biernej w swoich tekstach. To zwykle dobra rada, ale to nie wszystko; to, co mam na myśli, to to, że dobry tekst techniczny jest napisany w stronie czynnej. Czasownik zawsze pojawia się pierwszy. Pamiętaj: instruujesz ludzi, więc musisz za każdym razem jasno powiedzieć im, co mają zrobić.

    By to zilustrować, mój pierwszy szkic powyższego paragrafu zaczynał się od "Twoje lekcje angielskiego prawdopodobnie nauczyły Cię, że strona bierna jest w złym stylu". To nie jest strona bierna ("Lekcje angielskiego... nauczyły..." jest dość aktywna), ale zaciemnia istotę zdania - akcję "nauczyłeś się". Zaczynanie każdego z dnia od "nauczyłeś się" przywraca skupienie na Ciebie, czytelnika, utrzymując konwersacyjny, instruktażowy ton, w który staram się celować.

  • Pomiń puch.

    Najlepiej pokazać to na przykładzie. Wczorajszy tekst zawierał takie paskudne zdanie:

    Oznacza to, że powinien być całkiem przekrojowy; dobry tutorial powinien chwalić większość różnych obszarów projektu.

    Mój komentator (prawidłowo) skomentował to tak: to zdanie ma sporo słów ("całkiem", "większość", "dobry") które nie dodają żadnego znaczenia zdaniu, a niektóre z pozostałych ("różne obszary", "projekt") są niejasne.

    Poniżej jest lepsza wersja:

    Oznacza to, że powinien być przekrojowy; dobry tutorial powinien chwalić różne obszary Twojego projektu.

    Znaczenie pozostaje to samo, ale druga wersja ma więcej mocy, jest jaśniejsza i krótsza. A to dobrze.

  • Uważaj na pisemne tiki.

    Każdy ma pewne złe nawyki jeśli chodzi o pisanie. Myślę o tym jako o pisarskich tikach: drobnych zwyczajach, które stały się niemal nieumyślne. Jak tylko zauważysz tiki autora, trudno przestać zwracać na nie uwagę. Powtórzenie po prostu przeszkadza.

    Żeby było jasne, moimi tikami są opieranie się na średnikach i myślnikach; ten dokument zawiera o wiele za dużo każdego z nich.

Co dalej

Wszystkie te zasady mogą być niesamowicie przytłaczające, wiem. Nie mniej jednak, istnieje magiczne stworzenie, które zna je wszystkie i zastosuje je do Twojego tekstu, a Ty nie będziesz musiał tego robić

Opowiem o tych magicznych istotach w jutrzejszym odcinku zatytułowanym: "Potrzebujesz edytora".

Część serii Pisanie dobrej dokumentacji.

Data publikacji oryginału: listopad 11, 2009

Nowi moderatorzy na devPytaniach

Zapewne większość z Was dobrze zna serwis devPytania. Przypomnijmy sobie, jak on funkcjonuje:

To nie my tworzymy devPytania. Wy to robicie. devPytania to serwis budowany i utrzymywany wspólnymi siłami Twoich kolegów programistów. Gdy serwis dostatecznie Ci zaufa, będziesz mógł edytować wszystkie treści, podobnie jak na Wikipedii. Z Twoją pomocą jesteśmy w stanie udzielić dobrej odpowiedzi na praktycznie każde możliwe pytanie programistyczne. Nie ma znaczenia język programowania czy system operacyjny, którego używasz — naszym celem jest lepsze programowanie.

Aby powyższe było możliwe, dostarczony został system punktów reputacji:

Zgromadź wystarczającą liczbę punktów reputacji, a serwis devPytania pozwoli Ci na wiele więcej niż zwykłe zadawanie pytań i udzielanie odpowiedzi:

15Oddawaj pozytywne głosy.
15Oznaczaj nieodpowiednie treści.
50Pisz komentarze.
100Oddawaj negatywne głosy (kosztuje to 1 punkt reputacji). Edytuj wpisy będące częścią społecznościowego wiki.
200Zmniejsz ilość reklam.
250Głosuj za zamknięciem bądź ponownym otwarciem własnych pytań. Twórz nowe tagi.
500Zmieniaj pytaniom tagi.
2000Edytuj treść innych użytkowników.
3000Głosuj za zamknięciem bądź ponownym otwarciem dowolnych pytań.
10000Kasuj zamknięte pytania. Uzyskaj dostęp do narzędzi moderatora.

Na końcu tego spektrum reputacji różnica między użytkownikami z wysoką reputacją a moderatorami jest niewielka. Właściwość ta jest całkowicie zamierzona. To nie my prowadzimy serwis devPytania. Robi to społeczność.

Niemniej jednak mimo istnienia aktywnej, samoregulującej się społeczności, moderatorzy muszą interweniować od czasu do czasu. Moderatorzy zajmują się tymi niezwykle rzadkimi sytuacjami, które nie powinny się normalnie wydarzać, ale jeśli już się wydarzą, to potrafią znacząco zaburzyć działanie społeczności.

Tak więc, co może moderator na devPytaniach?

  • Głos moderatora jest wiążący. W jakimkolwiek miejscu, gdzie występuje głosowanie (zamykanie, otwieranie, kasowanie, odzyskiwanie, itp), głos moderatora powoduje osiągnięcie progu i zaaplikowania danej akcji natychmiast.
  • Moderator może zablokować wpis (post). Zablokowane wpisy nie mogą otrzymywać głosów, ani być w żaden sposób zmieniane.
  • Moderator widzi wszystkie dane w systemie - w tym głosy oraz informacje o profilach użytkowników.
  • Moderator może zawiesić użytkownika oraz usunąć, jeśli jest to konieczne.
  • Moderator może wykonywać czynności administracyjne typu łączenie pytań, czy masowe retagowanie.

Z dnia na dzień przybywa serwisowi aktywnych użytkowników. Co za tym idzie, coraz częściej zdarzają się sytuacje, które wymagają interwencji moderatora. Postanowiliśmy zatem mianować 5 wybranych przez nas użytkowników moderatorami. Funkcje te przypadły następującym osobom:

Gutkowski plakietka
Łukasik plakietka
Kuczyński plakietka
Aniserowicz plakietka
Gil plakietka

Jeśli jesteś moderatorem, bądź posiadasz uprawnienia zbliżone do takich, jakie ma moderator, to czego od Ciebie oczekujemy?

  1. Jako moderator, Twoje czyny reprezentują nasz serwis - prosimy zachowuj się stosownie. Znajdujesz się na stanowisku, które obdarzone jest dużym zaufaniem.
  2. Twoim zadaniem jest prowadzenie społeczności z delikatną - ale pewną - interwencją. Szanuj członków społeczności. W swoich czynach utrzymuj sprawiedliwość oraz spójność.
  3. Utrzymuj dyskusje w temacie, poprzez zamykanie oraz usuwanie wpisów, które są nie na temat.
  4. Regularnie rozprawiaj się z oflagowanymi wpisami.
  5. W przypadku ostrych konfliktów, komunikuj się bezpośrednio z użytkownikami poprzez e-mail, aby pomóc je wyjaśniać.

Od moderatora wymagamy najmniejszej możliwej ingerencji. devPytania są tak skonstruowane, aby większość typowych "moderacyjnych" akcji było wykonywane przez społeczność.

Wszystkim użytkownikom serwisu serdecznie dziękujemy za aktywność. Mamy nadzieję, iż sposób w jaki tworzona jest społeczność devPytania pozytywnie wpłynie na rozwój każdego, kto do niej należy.


Zespół devMedia.pl

Related Posts with Thumbnails