Paradoks wielkiego wyświetlacza

Oryginalny post: The Large Display Paradox

Autor: Jeff Atwood

W miarę jak monitory stają się większe i tańsze, coraz więcej użytkowników będzie miało względnie wielkie wyświetlacze. Nikt już nie kupuje 15- czy 17-calowych monitorów; niedługo, pod względem finansowym, nie będzie sensu kupowania wyświetlacza mniejszego niż 20-calowego. W końcu, jeśli ten trend się utrzyma, wszyscy będą mieli 30-calowe wyświetlacze na swoich biurkach. Oczywiście jest to dobra rzecz. Nigdy nie jest tak, że masz wystarczająco przestrzeni na ekranie. Ale istnieje pewna niezamierzona konsekwencja dużych monitorów.

Jak na ironię, jedną z zalet małych monitorów jest to, że ponieważ iż są małe, zmuszają użytkowników do prostszej, bezokienkowej metody pracy. Zamiast marnować czas na zmienianie rozmiarów, przemieszczanie oraz układanie okienek, użytkownicy mają do czynienia tylko z jednym zmakysmalizowanym okienkiem na raz. Mogą przełączać się między zmaksymalizowanymi aplikacjami w sposób, w jaki przełączają kanały w telewizji. Ale jeśli Twój wyświetlacz osiągnie rozdzielczość 1600 x 1200, bądź więcej, prosty model typu jedna-aplikacja-na-ekran nie jest już realny. Dan ostatnio natknął się na taki problem, kiedy zmienił sobie monitor na 30-calowy:

Użytkownicy 30-calowych monitorów napotykają się na naprawdę potworny problem efektywnego wykorzystania całej przestrzeni. Często nie chcesz maksymalizować folderu bądź dokumentu na tak wielkim ekranie; albo skończysz z dużą ilością białej przestrzeni, a ważne przyciski będą rozdzielone kolosalnym obszarem pustki, albo otrzymasz linie tekstu o 300 bądź więcej znakach długości, które są ciężkie do czytania.

Oto paradoks wielkiego wyświetlacza. Posiadanie tak wielkiej przestrzeni może spowodować, że staniesz się mniej produktywny w związku z manipulacją okienkami, z którą musisz się uporać, by móc efektywnie z nich korzystać.

Osobiście, jestem pełnoprawnym członkiem prestiżowego klubu trzech monitorów, co oznacza, że jestem jeden krok dalej niż Dan. Przynajmniej dopóki nie podwoi bądź nie potroi liczby monitorów:

Mimo iż moje wyświetlacze są 20-calowe, mam je trzy. Maksymalizując okno na 20 cali, 1600 x 1200 jest rozsądną przestrzenią wyświetlacza, z którą można pracować przez większość czasu. Używam również aplikacji UltraMon, która daje mi nieodzowną możliwość przenoszenia zmaksymalizowanych okien pomiędzy monitorami. Ciągle chwytam zmaksymalizowane okna i "rzucam" nimi z monitora na monitor, ala Raport Mniejszości.

Pracując na moich trzech monitorach, mam bardzo dużą podstawową przestrzeń wyświetlacza oraz drugorzędne obszary, do których mogę "przyczepić" elementy potrzebne jako odnośniki, a które nie będą mi przeszkadzać. Mam naturalną siatkę dopasowującą, ponieważ używam trzech fizycznych monitorów. Jest to efekt uboczny sprzętu, ale na tyle ważny, że zacząłem na nim polegać.

Dan posiada wyłącznie jeden wielki, 30-calowy monitor, tak więc nie ma naturalnej siatki, do której mógłby dopasowywać okna. Potrzebuje jakiegoś oprogramowania do pomocy:

Używam WinSplit Revolution, aby zarządzać tym problemem. Jest to porządna, mała, Windowsowa aplikacja, za pomocą której można w prosty sposób rzucać (większością) okienek dookoła ekranu oraz zmieniać ich rozmiar, aby zajmowały tyle miejsca ile prawdopodobnie chcesz. Dwa obszary, każdy po 1280 x 1600, dają w rezultacie parę 20 calowych "ekranów" w formacie portretowym, które nadają się do wielu zadań.

Natknąłem się poniekąd na taki problem na moich trzech 20-calowych monitorach, ale to mały problem. Będę w poważnych tarapatach, jeśli kiedykolwiek sprawię sobie monitory większe niż 20 cali. (Będę również potrzebował o wiele większego biurka.) Bez wątpienia zmaksymalizowane okna nie są efektywne na wielkich wyświetlaczach. Dla więszkych ekranów, musiałbym rozszerzyć efekt siatki dopasowującej do każdego monitora indywidualnie.

To jest dokładnie to, co robi aplikacja WinSplit Revolution. Jest całkiem intuicyjna; używasz CTRL+ALT+(numpad) do przerzucenia aktualnie zaznaczonego okna na część ekranu, która jest przypisana do numeru. Poprzez naciśnięcie sekwencji wiele razy, zostaną zaprezentowane dwa bądź trzy możliwe rozmiary w tej szczególnej pozycji. Poniższy diagram przedstawia to lepiej niż ja za pomocą tekstu:

Jak można zauważyć, otrzymuje się kilka możliwych układów siatki używając jedynie prostego mapowania klawiatury numerycznej. Ale wciąż jest to trochę wysiłku; Muszę zaznaczyć każde okno, a następnie użyć klawiatury numerycznej (albo odpowiedniego wyskakującego okienka), aby przesunąć je w miejsce, które chcę. Od wersji 1.8, WinSplit Revolution doskonale radzi sobie z wieloma monitorami i nawet dostarcza wygodnych skrótów klawiaturowych do przesuwania okien z monitora na monitor.

Na szczęście jest jeszcze GridMove, który wspiera wiele monitorów. Używając środkowego przycisku myszy do przesunięcia okna, uruchamia się aktualny szablon siatki, który dostarcza automatyczne obszary dopasowujące dla tego okienka.

W nie tak dalekiej przyszłości, każdy użytkownik będzie miał tak duży monitor, że dla większości aplikacji maksymalizowanie okna nie będzie miało sensu. Szkoda, że jakiś rodzaj automatycznej siatki dopasowującej nie może być osadzony w systemie operacyjnym, aby pomagać użytkownikom w uporaniu się z wielkimi obszarami wyświetlacza. Tak jak Dan będziemy tego potrzebować prędzej czy później. Do tej pory, powyższe aplikacje -- albo podobne do nich -- mogą uzupełnić te braki.

Data publikacji oryginału: 7 sierpnia, 2007

Nazwę ją... SomethingManager

Oryginalny post: I Shall Call It.. SomethingManager

Autor: Jeff Atwood

Alan Green tak narzekał na stosowanie bezsensownych nazw takich jak SomethingManager:

Ile klas z którymi się spotkałeś miały sufiks "Manager" (np. ConnectionManager, SessionManager)? Każdy większy system wydaje się być pełen takich klas - SessionManager, ConnectionManager, PolicyManager, QueueManager, UrlManager, ConfigurationManager, albo co jeszcze smutniejsze EJBManager.

Słowa "manager" i "manage" posiadają przynajmniej dziesięć różnych znaczeń - od "stworzyć coś i utrzymywać w zgodzie z wytycznymi" do "osiągnąć określony cel". Pamiętam jak pewnego dnia recepcjonistka przemianowała się na "Switchboard Manager". Częścią wspólną tych wszystkich definicji wydaje się być "dba o rzeczy".

Ta nieprecyzyjność powoduje, że słowo "Manager" jest złym słowem do stosowania w nazwach klas. Weźmy na przykład klasę o nazwie "UrlManager" - nie jesteś w stanie powiedzieć, czy ta klasa odpowiedzialna jest za przechowywanie adresów URL w pamięci podręcznej, operacje na adresach URL czy też dba o poprawne ich używanie. Nazwa "UrlManager" mówi Ci tylko tyle, że klasa coś robi z adresami URL. Z drugiej strony nazwa "UrlBuilder" daje dużo lepszy obraz tego, za co odpowiedzialna jest klasa.

W świecie Javy sufiks "Manager" jest często spotykany. Prawie wszędzie znajdują się klasy, które odpowiedzialne są w jakiś sposób za inne klasy, co powoduje, że automatycznie otrzymują sufiks "Manager".

Nie ma nic bardziej wieloznacznego niż klasa nazwana z użyciem sufiksu "Manager". Unikaj tego słowa. Alan zaproponował kilka alternatyw we wpisie na swoim blogu, który może być pomocny w sprecyzowaniu jakiej nazwy potrzebuje Twoja klasa.

Nadawanie dobrych, opisowych nazw klasom i obiektom nie jest łatwe. Steve McConnell dostarczył kilka porad na temat nazywania procedur w książce Code Complete:

  1. Nazwa opisuje wszystko, co wykonuje procedura Dosłownie wszystko. Jeśli sprawia to, że nazwa procedury staje się śmiesznie długa, nazwa nie jest problemem. Problemem jest Twoja procedura.

  2. Unikaj bezsensownych, ogólnikowych lub mało konkretnych czasowników Na przykład: UrlManager, HandleOutput(), PerformServices(). Bądź konkretny. Co robi procedura? Jeśli nie możesz odpowiedzieć na to pytanie zwięźle, być może nadszedł czas na refaktoring kodu, który pozwoli Ci odpowiedzieć na to pytanie.

  3. Nie wprowadzaj numeracji w nazwach procedur Dołączyłem to tylko by lista były kompletna. Jeśli kiedykolwiek znajdziesz się w sytuacji, w której piszesz procedurę OutputUser1() i OuputUser2(), niech Bóg ma Cię w swojej opiece. I niech ma też w swojej opiece zespół w którym pracujesz.

  4. Stosuj nazwy tak długie, jak to konieczne Według McConnella, optymalna długość zmiennej to 9-15 znaków. Procedury zazwyczaj są bardziej skomplikowane i dlatego zasługują na dłuższe nazwy. Zastosuj tak długą nazwę, by stała się zrozumiała.

  5. Dołączaj opis zwracanej wartości Łatwa i prosta zasada. Przykłady: printer.IsReady(), pen.CurrentColor(), itp.

  6. Używaj przeciwieństw precyzyjnie Dla każdej funkcji Open(), powinna istnieć także funkcja Close(). Dla każej funkcji Insert(), funkcja Delete(). Dla każdej funkcji Start(), funkcja Stop().

  7. Wypracuj i trzymaj się konwencji nazewniczych Najlepiej zilustrować to na przykładzie. McConnell przedstawił taki w swojej książce: employee.id.Get() dependent.GetId() supervisor() candidate.id()

    W takiej sytuacji pojawia się pytanie: jak pobrać Id dla innego obiektu?

Zmiana nazw klas i zmiennych jest moją najczęstszą czynnością wykonywaną podczas refaktoryzacji. Tworzenie dobrych nazw jest trudne, ale to powinno być trudne. Trudno jest nazwać coś, czego nie skończyłeś jeszcze pisać. Większość kodu nigdy nie jest całkowicie ukończona, zatem nazwy mogą zmieniać się z czasem. Zwięzłe, opisowe nazwy zmiennych, obiektów, klas i funkcji mogą sprawić, że zamiast Daily WTF code otrzymasz kod, z którym chcesz pracować na co dzień.

Data publikacji oryginału: 29 marca, 2007

Największy wynalazek w dziedzinie informatyki

Oryginalny post: The Greatest Invention in Computer Science

Autor: Jeff Atwood

Jak myślisz, co jest największym wynalazkiem w dziedzinie informatyki? Oprócz komputera oczywiście.

Poważnie, przed dalszym czytaniem, zatrzymaj się na chwilę i rozważ pytanie.

Mówiłem wcześniej o tym, jak młode są w rzeczywistości tak zwane nowoczesne języki programowania i warto to powtórzyć dla kontekstu.

C ma z grubsza tyle lat co ja; FORTRAN jest w wieku moich rodziców. Ale co z nowymi dzieciakami na osiedlu? Strona z metrykami TCPI firmy TIOBE software dostarcza pewnych danych odnośnie popularności języków programowania od 2001 roku. Weźcie pod uwagę dziecięcy wiek wielu najnowszych i najmodniejszych języków programowania:

Ruby jest zaledwie nastolatkiem. JavaScript oraz PHP nie osiągnęły jeszcze nawet wieku nastoletniego.

We wszystkich naszych rozmowach o nowych, wymyślnych cechach języków programowania, czasem myślę, że zapominamy o fundamentalnym budulcu, który leży u podstaw każdej z nich: skromna procedura. Uwierzcie na słowo Steve'owi McConnellowi, który zachęca nas do rutynowego używania procedur:

Oprócz wynalezienia komputera, procedura jest prawdopodobnie największym wynalazkiem w dziedzinie informatyki. Sprawia, iż programy są łatwiejsze w czytaniu i rozumieniu. Skraca je (wyobraź sobie, o ile dłuższy byłby Twój kod, jeśli musiałbyś powtórzyć kod procedury dla każdego jej wywołania). Przyspiesza je (wyobraź sobie, jak trudno byłoby zwiększać wydajność w kodzie, który jest użyty w setkach miejsc, zamiast zwiększać wydajność w jednej procedurze). W większości, procedury są tym, co czyni nowoczesne programowanie możliwym.

Jeśli nie jesteś na tyle stary, by pamiętać życie przed procedurami, pomyślałem, że James Shore dał świetny przykład czystej różnicy w swoim doskonałym artykule Quality With a Name:

Przed programowaniem strukturalnym:

1000 NS% = (80 - LEN(T$)) / 2 1010 S$ = "" 1020 IF NS% = 0 GOTO 1060 1030 S$ = S$ + " " 1040 NS% = NS% - 1 1050 GOTO 1020 1060 PRINT S$ + T$ 1070 RETURN

Po programowaniu strukturalnym:

public void PrintCenteredString(string text) { int center = (80 - text.Length) / 2; string spaces = ""; for (int i = 0; i < center; i++) { spaces += " "; } Print(spaces + text); }

Skromna procedura jest podporą programowania w jakimkolwiek nowoczesnym języku. Jestem pewien, że jesteście dobrymi przykładami nowoczesnych programistów, więc nie będę Was zanudzał wyjaśnieniami, dlaczego procedury są dobrym pomysłem. Oryginalny artykuł McConnella z IEEE z 1998 roku pokrywa całkiem dobrze przesłanki stojące za procedurami. W rozdziale 7 książki Code Complete 2 znajduje się rozwinięta wersja tego materiału.

Procedury są tak fundamentalne dla dzisiejszego programowania, że są w zasadzie niewidoczne. I to jest problem z procedurami: zajmują tylko minutę, by się ich nauczyć, ale całe życie, by je opanować. Jeśli było możliwe złe programowanie niestrukturalne, tak też możliwe jest strukturalne. Możesz pisać stylem FORTRANowym w dowolnym języku. Siłowanie się z niewymowną istotą procedur jest, na pierwszy rzut oka, tym czym jest teraz programowanie:

  • Jak długa powinna być ta procedura? Jak długa jest już za długa? Jak krótka jest za krótka? Kiedy kod jest "za prosty", żeby zostać procedurą?
  • Jakie parametry powinny być przekazane do tej procedury? Jakie struktury danych bądź typy? W jakiej kolejności? Jak będą używane? Które będą zmodyfikowane jako wynik procedury?
  • Jaka jest dobra nazwa dla tej procedury? Nazywanie jest trudne. Naprawdę trudne.
  • Jak ta procedura ma się do sąsiednich procedur? Czy są wywoływane w tym samym momencie, albo w tej samej kolejności? Czy dzielą wspólne dane? Czy naprawdę stanowią całość? W jakiej powinny być kolejności?
  • Po czym powinienem poznać, że kod w procedurze zakończył się sukcesem? Powinna zwrócić kod sukcesu czy błędu? Jak będą obsługiwane wyjątki, problemy i błędy?
  • Czy ta procedura powinna w ogóle istnieć?

Dobrzy programiści -- niezależnie od tego w jakim języku mają okazję pisać -- rozumieją znaczenie tworzenia każdej procedury z najwyższą uwagą. Procedury w Twoim kodzie powinny być traktowane jak malutkie, dobrze wypolerowane diamenty, gdzie każdy kolejny jest bardziej wykwintnie wypolerowany i wyszlifowany niż poprzedni.

Przyznam się, że to nie jest szczególnie głęboka wnikliwość. To nie jest nawet oryginalna rada. Ale jeśli wierzysz, tak jak ja, w nieustanne powtarzanie podstaw, nigdy nie przestaniesz opanowywać sztuki pisania perfekcyjnej procedury.

To jest, jakby nie było, największy wynalazek w dziedzinie informatyki.

Data publikacji oryginału: 6 czerwca, 2008

Do sukcesu przez porażki

Oryginalny post: Fail Early, Fail Often

Autor: Jeff Atwood

Scott Hanselman uważa, że umieszczanie certyfikatów branżowych w podpisie jest niezręczne:

Jeśli nierozsądne byłoby umieszczenie w CV wyników egzaminów ze studiów, to czemu umieszczenie

Scott Hanselman, MCSD, MCT, MCP, MC*.*

jest rozsądne? Posiadanie certyfikatu znaczy tyle, że jesteś w stanie przyswoić dużą dawkę wiedzy technicznej. Chwileczkę. Proponuję podpisywanie się w następujący sposób:

Scott Hanselman, 11 dużych projektów zakończonych sukcesem, 3 projekty Open-Source, 1 projekt zakończony gigantyczną porażką

Czyż tak nie byłoby lepiej?

Owszem, ja się zgadzam. To właśnie projekty, nad którymi pracowałeś, powinny stanowić Twoje referencje. Uważam jednak, że Scott umieścił je w złej kolejności. Powinieneś podkreślić liczbę projektów, nad którymi pracowałeś i które zakończyły się porażką.

Jednak jak zdefiniować sukces projektu? Czy cele zostały zrealizowane? Czy projekt zarabia pieniądze? Czy użytkownicy lubią wytworzone oprogramowanie? Czy ktoś go w ogóle jeszcze używa? Naprawdę ciężko powiedzieć. Przez pewien czas pracowałem w środowisku, gdzie każdy projekt kończył się sukcesem. Nikt nie chciał spowiadać się z ograniczeń, kompromisów i problemów w oprogramowaniu, nad którym pracował i które zostało wypuszczone w świat. Osoby zarządzające projektem chciały być postrzegane jako osoby odnoszące sukces. Powodowało to, że czuliśmy się jak uczestnicy dziwnych zawodów informatycznych, w których każdy projekt, mimo wszystko, jest zwycięzcą. Użytkownicy, z drugiej strony, nie byli już takimi szczęśliwcami.

Sukces jest względny i ulotny. Porażka natomiast jest rzeczą trwałą. Jeśli naprawdę chcesz wiedzieć, czy ktoś jest kompetentny w tym co robi, zapytaj go o jego porażki. W zeszłym roku cytowałem artykuł na temat przewidywania sukcesów i porażek chirurgów:

Charles Bosk, socjolog z Uniwersytetu Pensylwania, przeprowadził pewnego razu serię wywiadów z młodymi lekarzami, którzy bądź to zrezygnowali, bądź zostali wyrzuceni ze specjalizacji neurochirurgicznej, w celu ustalenia co wyróżnia chirurga, któremu udało się utrzymać na specjalizacji.

Bosk wywnioskował, że o wiele bardziej niż techniczne umiejętności lub inteligencja, do osiągnięcia sukcesu (utrzymanie się na specjalizacji) liczyło się posiadanie odpowiednich cech charakteru -- pragmatycznego umysłu, który świadom jest możliwości porażki i jej potencjalnych konsekwencji. Kiedy przeprowadzałem wywiad z chirurgiem, który został wyrzucony, zazwyczaj kończyłem wywiad cały roztrzęsiony. Chciałem usłyszeć przerażające historie o tym, co zrobili źle, ale problem był taki, że oni nawet nie zdawali sobie sprawy z tego, że to co zrobili było złe. W trakcie wywiadów wypracowałem pytania, po zadaniu których mogłem stwierdzić z dużą dozą prawdopodobieństwa, czy ktoś będzie dobrym neurochirurgiem czy też nie. Były to takie pytania jak: "Czy kiedykolwiek popełniłeś błąd? Jeśli tak, jaki był twój najgorszy błąd?" Ludzie którzy odpowiadali: "Ojej, nigdy nie popełniłem błędu" lub "Wynik leczenia był zły, ale to ze względu na czynniki, na które nie miałem wpływu" -- byli dla mnie najgorszymi kandydatami na neurochirurga. Natomiast praktykanci którzy mówili: "Popełniam błędy cały czas. Zdarzyła się okropna rzecz wczoraj i było to ...". To właśnie oni byli najlepsi. Mieli tę umiejętność, by przemyśleć wszystko, co zrobili i byli w stanie wyobrazić sobie, jak sprawy potoczyłyby się, gdyby postąpili inaczej.

Najlepsi programiści uwielbiają porażki -- a tak naprawdę mają na ich punkcie obsesję. Jeśli zapomniałeś już, jak łatwo jest popełniać krytyczne błędy, to najprawdopodobniej poniesiesz kolejną porażkę. I tym powinieneś się martwić.

Michael Hunter idzie krok dalej. Zachęca nas do częstego ponoszenia porażek:

Jeśli Twoja rodzina zachęca Cię do ponoszenia porażek, to zaliczasz się do szczęściarzy. Jeśli naprawdę urodziłeś się pod szczęśliwą gwiazdą, to również Twoi nauczyciele to robią. Nauka nie płynie z samej porażki, ale z analizy jej przyczyn, próby wyciągnięcia i sformułowania wniosków oraz próby ponownego zmierzenia się z problemem. Z biegiem czasu da Ci to głębokie zrozumienie obszaru wiedzy, którym się zajmujesz (może to być zarówno programowanie, mieszanie kolorów lub cokolwiek innego) -- dzięki temu się uczysz. Ćwiczysz w ten sposób swój mózg, co jest dobre samo w sobie, plus wiedza, którą zdobyłeś, zwiększa Twoje szanse na sukces w nowych sytuacjach.

Im większa liczba projektów zakończonych porażką w twoim portfolio, tym lepiej. Jeśli raz na jakiś czas nie poniesiesz porażki, znaczy to, że nie starasz się wystarczająco mocno.

Musisz wytężyć swoje siły, by znaleźć granice swoich możliwości, a następnie je przekroczyć. Dodatkowo upewnij się, że poniesiesz spektakularną porażkę w czasie pracy nad następnymi projektami.

Data publikacji oryginału: 1 maja, 2006

Wszystko czego potrzebowałem się dowiedzieć o programowaniu, nauczyłem się z BASICa

Oryginalny post: Everything I Needed to Know About Programming I Learned from BASIC

Autor: Jeff Atwood

Na temat Beginner's All Purpose Symbolic Instruction Code Edsger Dijkstra miał to do powiedzenia:

Nauczenie studentów dobrego stylu programowania jest praktycznie niemożliwe, jeśli byli oni wcześniej wystawieni na szkodliwe działanie BASICa; jako potencjalni programiści są umysłowo okaleczeni bez nadziei na regenerację.

Jestem pewien, że wyolbrzymiał dla efektu; o ile podziwiam jego referat z 1972 roku pod tytułem "Pokorny programista", o tyle trudno jest zrównać tę pokorę z pomysłem, iż wybór złego języka programowania uszkodzi umysł programisty. Mimo iż języki programowania ciągle się rozwijają, największym problemem jaki zauważam, nie jest wybór języka, ale fakt, że programiści mogą pisać stylem FORTRANowym w dowolnym języku. Cytując Poga, poznaliśmy wroga i on jest nami.

Odrzucenie BASICa wydaję się być pompatyczne. Tak jak wielu programistów w pewnym wieku, wychowałem się na BASICu.

Wspomniałem we wcześniejszym wpisie o ciekawym zderzeniu początków grania na konsolach i programowania, jakim był kartridż Atari 2600 BASIC Programming. Musiałem zobaczyć to na własne oczy, tak więc kupiłem jeden na eBayu.

Kupiłem także zestaw klawiaturek do Atari 2600. Nakładki zostały dostarczone razem z kartridżem, a klawiaturki dają się połączyć tak, by tworzyły prymitywną klawiaturę. (Tak więc jeśli zastanawialiście się jakiego rodzaju rzeczy robię ze swoimi przychodami z reklam, to kupowanie badziewia takiego jak to, jest jedną z nich, niestety.)

O dziwo, podręcznik nie jest dostępny nigdzie w Internecie, więc sam go zeskanowałem. Tylko spójrzcie. Jest zabawny. Jest dostępny w wersji HTML, ale nie ma tej przyjemności czytania bez obrazków i diagramów.

Odpaliłem kopię Basic Programming ROM w emulatorze Atari 2600 -- Stella, następnie podążając za podręcznikiem napisałem mały program w BASICu.

Zauważcie, że w Internecie w zasadzie nie ma innych zrzutów ekranu z programowania w BASICu na ATARI 2600. Jest tak, ponieważ prawdopodobnie jestem jedyną na tyle szaloną osobą, by faktycznie próbować programowania w tym czymś. Może to wyglądać na bolesne, ale nie przekonacie się dopóki nie spróbujecie popracować z tym niechlujnym "IDE". Jest rozśmieszająco fatalne. Nie mogłem powstrzymać się od śmiechu podczas, gdy stukałem w moje klawiaturki. Ale muszę przyznać, po napisaniu swojego pierwszego "programu" poczułem ten sam wewnętrzny dreszczyk zmuszania maszyny do swojej woli, który zawsze miałem.

Paczka, którą dostałem z eBaya zawierała kilka ręcznie napisanych notek programistycznych, które zakładam, iż pochodzą z lat 80-tych.

Czy w BASICu -- nawet w tej okropnie ułomnej, paskudnej wersji BASICa z Atari 2600 -- nie o to chodzi? Aby odkrywać podstawowe pojęcia programistyczne?

Oczywiście, jeśli byliście kiedykolwiek zainteresowani komputerami, nie zawracaliście sobie głowy programowaniem na słodkim Atari 2600. Były dostępne o wiele lepsze opcje dla grania oraz programowania pod postacią domowych komputerów. I przez dłuższy czas, każdy komputer, który można było kupić, miał BASICa wypalonego w ROMie. Niezależnie czy był to Apple //, Commodore 64, czy Atari 800, odpalało się go, aby być przywitanym przez znak zachęty BASICa. Stał się on natywnym językiem hobbystycznego programisty.

Nawet IBM PC miał interpreter BASICA, GW-BASICa i w końcu QBasica, który był wycofany razem z Windowsem 2000.

To prawda, że jeśli chcieliście zrobić cokolwiek w najmniejszym stopniu nowoczesnego na tych 8-bitowych komputerach Apple, Commodore czy Atari, musieliście nauczyć się asemblera. Nie przypominam sobie żadnego kompilowanego języka do czasów IBM PC oraz DOSa, mianowicie Turbo Pascala. Języki kompilowane były ezoteryczne i drogie do czasów wielkiej demokratyzacji Turbo Pascala po jego niskiej, naprawdę niskiej cenie $49,99.*

Nawet jeśli brakowało Wam umiejętności programistycznych na tyle, by zostać następnym Davidem Cranem czy Willem Wrightem, to nadal istniało mnóstwo interesujących gier i programów, które mogliście napisać w starym dobrym BASICu. Na pewno na tyle dużo, abyście mogli się zorientować czy lubicie programowanie oraz czy posiadacie jakiś talent. Zestawienia Creative Computing były jak programistyczne biblie dla nas.

Przez bardzo długi czas, jeśli w ogóle interesowaliście się komputerami, to programowaliście w BASICu. To było nieuniknione i pewne jak powietrze, którym oddychacie. Za każdym razem gdy odpalaliście komputer, była tam ta linia poleceń, która dawała Wam sygnał. Czemu by nie wpisać paru komend BASICa i sprawdzić co się stanie? A następnie to poczucie cudu, możliwości odblokowania wrzechświata wewnątrz Twojego komputera, którego jesteście w stanie nieskończenie formować. Tak więc kariery milionów programistów się rozpoczęły.

BASIC nie okalecza umysłu, jak twierdził Dijkstra. Jeśli coś, to BASIC otworzył umysły milionom młodych programistów. To był być może najwcześniejszy sprawdziań, aby określić czy byłeś programistyczną owcą czy nieprogramistyczną kozą. Nie wszyscy będą dobrzy, rzecz jasna, ale niektórzy na pewno staną się wspaniali.

Czy ciągle w nim programujemy czy nie, duch BASICa żyje w każdym z nas.

* tak na marginesie, zwróćcie uwagę, że Anders Hejlsberg był autorem Turbo Pascala a następnie Delphi; teraz posiada tytuł Technical Fellow w Microsofcie oraz jest naczelnym projektantem języka C#. To wielki powód, dla którego długoletni maniacy, tacy jak ja, są tak oddani platformie .NET.

Data publikacji oryginału: kwiecień 21, 2008

Programista-MacGyver

Oryginalny post: The Duct Tape Programmer

Autor: Joel Spolsky

Jamie Zawinski to taki typ programisty, który ja nazywam programistą-MacGyverem. I mówię to z całym szacunkiem. Jamie jest ciężko pracującym programistą, tworzącym przyszłościowe, użyteczne narzędzia, które pozwalają innym ludziom wykonywać ich pracę. Takiego właśnie gościa chcesz mieć w swoim zespole budującym gokarty, ponieważ jego ulubionymi narzędziami są: taśma klejąca i WD-40. I będzie je dzierżył niewzruszenie, dumnie i z gracją, nawet jeśli Twój gokart zacznie z zawrotną prędkością pędzić w dół zbocza. W tym czasie pozostali programiści wciąż będą na linii startu, debatując nad tym, czy powinni użyć tytanu czy może jakiegoś nowoczesnego, kosmicznego materiału kompozytowego, którego Boeing używa przy konstrukcji swojego Dreamlinera 787.

Gdy będzie już po wszystkim, być może zostaniesz z odrobinę niechlujnym gokartem, ale bez wątpienia będzie śmigał jak marzenie.

Przeczytałem właśnie wywiad z Jamiem w książce Coders at Work ("Koderzy w pracy") autorstwa Petera Seibela. Do sklepu marsz. Jest to niesamowity zbiór wywiadów ze znakomitymi programistami, takimi jak Peter Norvig, Guy Stelle i Donald Knuth. Ta książka jest tak ciekawa, że wczoraj na bieżni zamiast 30 minut spędziłem 60, ponieważ nie mogłem przestać czytać. Jak już mówiłem -- kupcie ją.

Mówię serio. Kupcie ją! Ja poczekam.

Chciałbym przedstawić powody, dlaczego lubię programistów w typie MacGyvera. Czasem jest tak, że będąc w jakimś zespole siedzisz sobie i zawzięcie klepiesz kod, gdy nagle ktoś podchodzi do Twojego biurka z kawą w ręku i zaczyna trajkotać o tym, że gdybyś użył wielowątkowych przedziałów COM, to Twoja aplikacja byłaby o 34% bardziej elegancka, i że to wcale nie byłoby trudne, ponieważ on napisał już pełno szablonów, i jedyne co musiałbyś zrobić to użyć wielokrotnego dziedziczenia po 17 takich szablonach, z których każdy bierze średnio 4 parametry, i nawet nie musiałbyś prawie nic implementować. Po prostu jeden gigantyczny ciąg wielokrotnego dziedziczenia po różnych klasach i presto -- wielo-przedziałowe wątki COM. A Ty wywracasz oczami, bo nie masz zielonego pojęcia, o czym ten pieprznięty oszołom gada, i nijak nie możesz się go pozbyć, a nawet gdyby Ci się to udało, to on i tak wróci do swojego pokoju, aby napisać jeszcze więcej tych jego wymyślnych klas utworzonych wyłącznie przy pomocy wielokrotnego dziedziczenia po szablonach, bez grama konkretnej implementacji, i oczywiście to jego kod wywali się na produkcji z wielkim hukiem i to do Ciebie zadzwonią w środku nocy, żebyś to posprzątał, bo on oczywiście w tym czasie będzie na jakiejś cholernej konferencji na temat "Wzorców Projektowych".

A programista-MacGyver nie boi się powiedzieć: "Wielokrotne dziedziczenie to bagno. Przestań tego używać. Po prostu przestań.".

Widzisz, każdy inny programista za bardzo obawia się, że wyjdzie na głupka, ponieważ nie jest w stanie jednocześnie pomieścić w głowie wystarczającej liczby faktów, żeby sprawić, że wielokrotne dziedziczenie albo szablony albo model COM albo wielowątkowość czy coś podobnego zadziałają. Podążają więc potulnie za jakąkolwiek, nieważne jak szaloną, modą, zesłaną nam przez bujających w obłokach architektów, którzy wykładają na konferencjach i piszą książki i artykuły i są dużo bystrzejsi od nas, a nie zdają sobie sprawy z tego, że to, o czym mówią jest dla nas po prostu za trudne.

Oto co Zawinski powiedział o Netscapie: "To właśnie takie decyzje jak rezygnacja z C++ i wielowątkowości sprawiły, że udało nam się wypuścić produkt na czas".

Później brał udział w tworzeniu klienta mailowego w Netscapie, ale zespołowi odpowiedzialnemu za faktyczne wyświetlanie wiadomości na ekranie nie udało się dokończyć swojego komponentu. "Wszystko co mieliśmy to wielki, pusty prostokąt na środku okna, w którym miała być wyświetlana wiadomość, czystym tekstem. Zespół podszedł do swojego projektu bardzo akademicko. Próbowali rozgryźć to od strony DOM i DTD. 'Tak, właśnie, powinniśmy dodać tutaj kolejną warstwę abstrakcji i stworzyć delegata do tego delegata do tego delegata. I wówczas na ekranie pojawi nam się jeden znak.'".

Peter zapytał Zawinskiego: "Widzę że mocno cię mierzi, gdy ktoś przedabrza przy projektowaniu".

"Taa," odpowiedział, "Koniec końców naszym zadaniem jest przecież wypuścić ten pieprzony produkt! Super jest przepisywać swój kod i czynić go bardziej przejrzystym. Po trzecim razie będzie już całkiem ładny. Ale nie o to tu chodzi -- Twoim celem nie jest pisanie kodu; Twoim celem jest ukończenie produktu.".

Mój bohater.

Zawinski nie pisał za wiele testów jednostkowych. "Generalnie są one świetne, ale pod warunkiem, że nie masz presji. Ale gdy stoisz przed obliczem 'Musimy od zera do ukończenia dojść w ciągu sześciu tygodni.', wówczas cóż, nie uda nam się, jeśli czegoś nie pominiemy. To co pominę, to będą rzeczy, które nie są absolutnie krytyczne. A testy jednostkowe nie są krytyczne. Klient nie będzie narzekał, jeśli ich nie będzie.".

Zanim się skrzywisz, pamiętaj, że Zawinski był w Netscapie, gdy zmieniali świat. Pracowali w przeświadczeniu, że mają tylko kilka miesięcy zanim ktoś inny się pojawi i zje ich kawałek tortu. Sporo ważnego kodu powstaje w takich warunkach.

Programista-MacGyver jest pragmatyczny. Zawinski spopularyzował koncepcję Gorsze jest lepsze. Produkt w 50% dobry, którego ludzie używają, rozwiązuje więcej problemów i żyje dłużej niż produkt w 99% dobry, ale którego nikt nie używa, ponieważ znajduje się w Twoim laboratorium, gdzie poddawany jest nieustannym zabiegom upiększającym. Wypuszczenie produktu to ficzer. Naprawdę ważny ficzer. Twój produkt musi go mieć.

Jedna z zasad, którą programista-MacGyver dobrze rozumie, mówi, że jakakolwiek technika programistyczna, która jest choć trochę skomplikowana, sprowadzi na Twój projekt zagładę. Taki programista będzie starał się unikać C++, szablonów, wielokrotnego dziedziczenia, modelu COM, architektury CORBA czy też innych technologii, które są całkiem rozsądne, gdy tylko poświęcisz sporo czasu na ich dogłębne zrozumienie, ale szczerze mówiąc są one za skomplikowane, aby ludzki umysł mógł je pojąć.

Fakt, oficjalnie w porządku jest próbować pisać wielowątkowy kod w C++ pod Windows używając modelu COM. Ale takie podejście jest podatne na błędy, bugi, które objawiają się rzadko i tylko w ściśle określonych warunkach uzależnionych od czasu i sekwencyjności operacji. Dzieje się tak, ponieważ nasze mózgi naprawdę nie są na tyle doskonałe by pisać tego rodzaju kod. Przeciętni programiści mogą tutaj przyjąć postawę obronną, ponieważ nie chcą przyznać, że nie są w stanie pisać tak skomplikowanego kodu. Pozwalają więc hardkorowcom z zespołu przeorać jakąś zapomnianą przez Boga architekturę opartą na szablonach C++, ponieważ w przeciwnym wypadku musieliby przyznać, że nie czują się na tyle bystrzy, żeby użyć czegoś, co mogłoby być doskonałą techniką programowania, ale dla kogoś takiego jak SPOCK. Programistę-MacGyvera nie obchodzi, co myślą o nim inni. Pozostaje on przy podstawowych technikach i narzędziach po to, by wolne moce przerobowe mózgu wykorzystać w celu tworzenia użytecznych funkcjonalności dla swoich klientów.

Jest jedna rzecz, o której musisz jednak pamiętać. Programista-MacGyver w świecie oprogramowania jest odpowiednikiem przystojniaka... młodego faceta o niesamowitym wyglądzie, który może wytoczyć się z łóżka i bez golenia, bez czesania się, bez mycia zębów, wsiąść do metra we wczorajszych brudnych ciuchach i wciąż wyglądać pięknie, ponieważ taki właśnie jest. Ty, mój przyjacielu, nie możesz pokazać się publicznie bez uprzedniego uczesania się. Przestraszyłbyś dzieci. Bo nie jesteś taki ładny. Programista-MacGyver musi mieć spory talent, żeby robić swoje. Musi być na tyle dobrym programistą, żeby doprowadzać projekty do końca, a my wybaczymy mu jeśli nie napisze ani jednego testu jednostkowego albo za pomocą XORa upakuje wskaźniki "next" i "prev" listy połączonej w jednym DWORDzie, żeby zaoszczędzić 32 bity, ponieważ jest na tyle ładny i na tyle bystry, że mu to wyjdzie.

Kupiłeś już Coders at Work? Jeśli nie -- zrób to! To był dopiero pierwszy rozdział!

Related Posts with Thumbnails