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:

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