Pierwszy krok do osiągnięcia Największego Blogowego Sukcesu - zacznij pisać

Pamiętacie wpis o osiąganiu Największego Blogowego Sukcesu? Przypomnijmy sobie wyniki sondy zamieszczonej na końcu tego wpisu:

Na devPytaniach padło też pytanie, czy jest takie miejsce w sieci, gdzie można by współtworzyć branżowego bloga.

W odpowiedzi na powyższe prezentujemy Wam takie miejsce - Nasze devBlogi. Jest to bardzo prosta instancja bloga, na której będzie można umieszczać swoje wpisy. Jest to doskonałe rozwiązanie dla tych, którzy mają bloga, a nie są zadowoleni z liczby czytelników (mogą równolegle publikować swoje wpisy na tym blogu) bądź dla tych, którzy nie mają swojego bloga w obawie, że nikt nie będzie go czytał (im więcej autorów tym więcej często aktualizowanej treści). Rzecz jasna, osoby, które nie należą do wyżej wymienionych grup, a chciałyby publikować coś od siebie, też mogą na tym skorzystać.

Piszemy o programowaniu.

Początkowo każdy nowy wpis będzie podlegał moderacji.

Chęć publikowania zgłaszamy na nasz adres e-mail.

Czekamy na odzew z Waszej strony. Jeśli będzie zainteresowanie, to pomyślimy o rozwinięciu tego bloga w ogólniejszą platformę - lepszy system oceniania i komentarzy, możliwość głosowania na artykuły, itp.

Mile widziane są również tłumaczenia dobrych wpisów ze świata blogowego. Niemniej jednak uprzedzamy, że przed rozpoczęciem tłumaczenia prosimy najpierw o kontakt.

Jak już wspominaliśmy wcześniej, można się spodziewać nagród za publikacje w wyżej wymienionych miejscach - za co konkretnie i w jakiej formie będą to nagrody, dowiecie się, jak już wszystko wystartuje.

Zatem tych, którzy chcą — zapraszamy.

Zespół devBlogi

Ergonomia miejsca pracy przy komputerze

Oryginalny post: Computer Workstation Ergonomics

Autor: Jeff Atwood

Niemal każdą chwilę, kiedy nie śpię, spędzam przy komputerze. Jestem tym, kogo mógłbyś nazwać domowym entuzjastą. Jestem szczęściarzem, ponieważ nie doświadczyłem żadnego urazu związanego z komputerem w związku z długotrwałą pracą przy nim, ale jest to bardzo realne ryzyko zawodowe. Miewam czasem bóle w dłoniach bądź nadgarstkach, zazwyczaj po maratońskich hulankach, gdzie oczywiście przesadzam -- ale to nie jest tematem tego wpisu. O wiele za dużo moich przyjaciół miało problemy z długotrwałym bólem pleców bądź bólem ręki. Jako iż możesz (i powinieneś) ćwiczyć swoje ciało i dłonie, aby je wzmocnić, jest jeszcze jedna strona tego równania, którą pomijałem.

Poszukuję najlepszego komputerowego biurka od kilku lat, i dużo gadałem na temat wartości inwestowania w doskonałe krzesło. Ale nie rozważałem tego, czy moje biurko i krzesło są odpowiednio skonfigurowane pod moje ciało. A co powiesz o ergonomii swojego miejsca pracy przy komputerze?

OSHA posiada oficjalną stronę na temat ergonomii miejsca pracy przy komputerze, która jest dobrym punktem wyjścia. Ale jak to bywa z rządowymi dokumentami, jest tam o wiele za dużo szczegółów, niż większość ludzi będzie potrzebować. Ale obrazek podsumowujący daje pogląd na to, jak wygląda ergonomiczna postawa siedząca. Jak bliska tej pozycji jest ta, w której obecnie siedzisz?

Microsoft nie zdobywa wystarczająco dużo uznania za ich, często innowacyjny, oddział odpowiedzialny za sprzęt, który najpierw spopularyzował ergonomiczne urządzenia wskazujące, zaczynając od Microsoft Mouse 2.0 w 1993 roku i następującej po niej klawiaturze Microsoft Natural Keyboard w 1994 roku. Mając na uwadze ich długotrwałe zainteresowanie w ergonomii sprzętu, prawdopodobnie nie jest zaskakującym, iż ich podręcznik zdrowego użytkowania komputera jest jednym z najlepszych i najbardziej zwięzłych punktów odniesienia w kategorii ergonomii komputerowej, jaki kiedykolwiek znalazłem. Ale nie musisz go czytać. Podsumuję tutaj kluczowe wytyczne dotyczące ergonomii miejsca pracy przy komputerze, wyodrębniając najlepsze rady ze wszystkich źródeł, na które się natknąłem.

Wiem, że ględziłem już o tym, ale to wymaga powtórzenia: dobrej jakości biurko i krzesło będą jednymi z najlepszych inwestycji, jakie kiedykolwiek zrobisz jako programista. Jeśli cenisz sobie swoje zdrowie fizyczne, to nie jest to obszar, w którym chciałbyś robić oszczędności. Mam nadzieję, iż zainwestowałeś w przyzwoite biurko i krzesło, które również dostarczają możliwość regulacji, aby móc uzyskać ergonomicznie poprawne stanowisko komputerowe.

1. Górna krawędź Twojego monitora powinna być na poziomie oczu oraz bezpośrednio przed Tobą. Monitor powinien być oddalony na długość ramienia od Ciebie.

2. Blat biurka powinien być mniej więcej na wysokości pępka. Kiedy ramiona masz umieszczone na biurku, Twoje łokcie powinny być pod kątem prostym zaraz za blatem biurka. Podparcia Twojego krzesła powinny być prawie na tym samym poziomie co poziom biurka, aby wspierać Twoje łokcie.

3. Twoje stopy powinny być płasko na podłodze, a kolana ugięte pod kątem prostym. Twoje siedzisko nie powinno naciskać na tył kolan; jeśli jest to konieczne, odchyl je nieznacznie do przodu, aby złagodzić nacisk. Siedź całkowicie oparty, z prostymi plecami, wpieranymi przez oparcie krzesła.

4. Gdy piszesz, Twoje nadgarstki powinny być w jednej linii z przedramionami, a nie wygięte ku górze, dołowi bądź na boki. Twoja klawiatura powinna znajdować się bezpośrednio przed Tobą. Pozostałe przedmioty, których często używasz powinny być w pobliżu, na wyciągnięcie ręki.

Jeśli chodzi o ergonomię miejsca pracy przy komputerze, są to absolutne podstawy, najczęściej powtarzane wytyczne jakie znam. Ergonomia to holistyczna dziedzina, nie nauka, tak więc Twoje wyniki mogą być różne. Niemniej jednak, jestem zaskoczony jak wiele tych podstawowych wskazówek łamałem przez tak wiele lat, bez najmniejszego zastanowienia. Jutro będę dostrajał moje domowe biurko w nadziei na bardziej komfortową pracę przy komputerze.

Data publikacji oryginału: 26 sierpnia, 2007

Reklamy

Z pewnością zwróciliście uwagę, że do niedawna w serwisach devBlogi oraz devPytania nie było reklam. Powodem tego był fakt, iż sami ich nie lubimy i staraliśmy się trzymać tego tak długo, jak było to możliwe. To się jednak niestety zmieni. Serwis devPytania działa w oparciu o platformę StackExchange, której (darmowy) okres BETA testów niedługo się kończy. W związku z tym utrzymanie serwisu będzie trochę kosztować. Doszliśmy do wniosku, iż reklamy kontekstowe Google będą najmniej inwazyjną formą reklamy.

Ponadto jesteśmy w trakcie pozyskiwania sponsorów naszej działalności. Do tej pory odezwały się: firma Telerik oraz wydawnictwo Manning Publications Co. — mogą nam podarować kilka licencji oraz e-booków (na przykład z Manning Early Access Program), które możemy dowolnie rozdać (o czym niebawem). Oczywiście będzie się to wiązało z wyświetleniem pewnego rodzaju reklam w naszych serwisach.

Dochodząc do sedna, chcielibyśmy się dowiedzieć, czy (i jak bardzo) będą Wam przeskadzały reklamy zamieszczone w serwisach devBlogi oraz devPytania:

Zachęcamy do oddania głosu w sondzie oraz do podzielenia się swoimi opiniami w komentarzach.

Zespół devBlogi

Twoje ulubione oszustwo związane z NP-zupełnością

Oryginalny post: Your Favorite NP-Complete Cheat

Autor: Jeff Atwood

Czy kiedykolwiek słyszałeś, żeby inżynier oprogramowania odnosił się do jakiegoś problemu mianem "NP-zupełny"? To wymyślny, żargonowy skrót do "niesamowicie trudny".

Najbardziej znana cecha problemów NP-zupełnych to to, że nieznany jest sposób na ich szybkie rozwiązanie; to oznacza, że czas jaki jest wymagany na rozwiązanie danego problemu przy użyciu obecnie znanych algorytmów, wzrasta bardzo szybko w miarę wzrostu rozmiaru problemu. W rezultacie, czas potrzebny do rozwiązania nawet średnioskomplikowanych takich problemów, z łatwością osiąga miliardy bądź biliony lat używając jakiejkolwiek ilości mocy obliczeniowej, jaka jest dziś dostępna. W konsekwencji, określenie tego, czy jest możliwe szybkie rozwiązanie tych problemów, jest jednym z głównych nierozwiązanych problemów w dzisiejszej informatyce.

Mimo iż metody wyznaczania rozwiązań problemów NP-zupełnych w rozsądnym czasie pozostają nieznane, informatycy i programiści ciągle napotykają na takie problemy. Biegły programista powinien umieć rozpoznać problem NP-zupełny po to, aby nieświadomie nie tracił czasu na rozwiązanie problemu, który jak do tej pory umykał pokoleniom informatyków.

Chcesz być biegłym programistą, nieprawdaż? Pewnie, że chcesz!

Problemy NP-zupełne są jak ostra pornografia. Nikt nie potrafi dokładnie zdefiniować, co czyni problem NP-zupełnym, ale będziesz to wiedział jak go zobaczysz. Tym razem, powstrzymam się od zwyczaju wrzucania obrazka do zobrazowania moich myśli.

(Uaktualnienie: Starałem się dać poetycką aluzję do problemu P=NP, ale w oparciu o komentarze jest ona mylna i niewątpliwie zła. Tak więc zredaguję to zdanie. Przekieruję Cię do tej ankiety o P=NP (pdf); poczytaj komentarze od profesorów informatyki (włącznie z Knuthem), aby załapać ideę, jak życiowe to może być.)

Wobec tego, polecam książkę, którą Anthony Scian mi polecił: Computers and Intractability: A Guide to the Theory of NP-Completeness.

Tak jak wszystkie książki programistyczne, które polecam, ta jest ponadczasowa. Pierwotnie wydana w 1979 roku, godne naśladowania świadectwo zdolnych ludzi podejmujących naprawdę trudne problemy w dziedzinie informatyki: "Nie potrafię znaleźć skutecznego algorytmu, ale nawet Ci wszyscy znani ludzie nie potrafią."

Tak więc ile problemów jest NP-zupełnych? Całe mnóstwo.

Nawet jeśli jesteś laikiem, mogłeś doświadczyć NP-zupełności pod postacią Sapera, tak jak to wyjaśnia Ian Stewart. Ale dla programistów, założyłbym się, iż najbardziej znanym problemem NP-zupełnym jest Problem komiwojażera.

Mając daną ilość miast oraz koszty podróży z jednego miasta do drugiego, jaka jest najtańsza droga przechodząca przez każde miasto dokładnie raz i kończąca się w mieście początkowym?

Rozwiązanie metodą brute-force -- próbowanie każdej możliwej permutacji miast -- może działać jedynie dla małych sieci miast, ale szybko staje się nie do utrzymania. Nawet gdybyśmy użyli teoretycznych procesorów, które mogłyby mieć nasze dzieci, albo dzieci naszych dzieci. Co gorsza, każdy inny algorytm, który wymyślimy, aby znaleźć optymalną ścieżkę dla akwizytora, ma ten sam problem. Jest to wspólna charakterystyka problemów NP-zupełnych: są ćwiczeniami z heurystyk i przybliżeń, tak jak zostało to zilustrowane przez ten oto komiks xkcd:

Co robią biegli programiści, kiedy napotkają na trudny problem? Oszukują. I Ty też powinieneś! W rzeczy samej, niektóre ze współczesnych aproksymacji dla Problemu komiwojażera są nadzwyczaj efektywne.

Zostało wynalezionych wiele algorytmów aproksymacyjnych, które szybko dają dobre rozwiązania o wysokim prawdopodobieństwie. Współczesne metody pozwalają znaleźć rozwiązanie dla niesamowicie dużych problemów (miliony miast) w rozsądnym czasie, z prawdopodobieństwem bycia odchylonym o 2-3% od optymalnego rozwiązania.

Niestety nie wszystkie problemy NP-zupełne mają dobre przybliżenia. Ale te które mają, zmuszają mnie do przemyślenia: jeśli poprzez oszustwo potrafimy zbliżyć się tak bardzo do optymalnego rozwiązania, to czy ma znaczenie to, że nie istnieje algorytm, który znajduje to optymalne rozwiązanie? Jeśli już, to z problemów NP-zupełnych nauczyłem się jednego: czasem dojście do mądrego oszustwa może być bardziej interesujące, niż bezskuteczne poszukiwanie doskonałego rozwiązania.

Rozważmy algorytm "First Fit Decreasing" dla Problemu pakowania, który jest NP-zupełny. Nie jest idealny, ale za to jest niesamowicie prosty i szybki. Algorytm jest tak prosty, że prawdę mówiąc, jest regularnie pokazywany na warsztatach z zarządzania czasem. A.. i gwarantuje on, że zbliżysz się na przynajmniej 22% do idealnego rozwiązania za każdym razem. Nie tak źle, jak na podłe oszustwo.

Tak więc jakie jest Twoje ulubione oszustwo związane z NP-zupełnością?

Data publikacji oryginału: 15 listopada, 2008

Po co nam testerzy?

Oryginalny post: Why testers?

Autor: Joel Spolsky

Moja siostra sprawiła swoim dzieciom szczeniaczka i one próbowały go wytresować. Aby mieszkać z psem pod jednym dachem, musisz nauczyć go, by nie skakał na ludzi, nie robił kupy w domu, siadał na zawołanie oraz nigdy, przenigdy nie przeżuwał iPada. Nigdy. Dobra dziewczynka.

Z tresowaniem psów jest tak, że reakcja musi być natychmiastowa. Jeśli po powrocie do domu odkrywasz, że parę godzin wcześniej pies wywalił kubeł ze śmieciami w kuchni, jest już za późno na tresurę. Możesz na niego wrzeszczeć, ale on i tak nie pojmie o co Ci chodzi. Psy po prostu nie są takie mądre.

Jeśli chodzi o programistów, bycie lepszym w tym co się robi, wymaga szybkich reakcji, pozytywnych i negatywnych, na temat tego co właśnie zrobiłeś. Im szybciej otrzymasz odpowiedź, tym szybciej się nauczysz. Przy oprogramowaniu pudełkowanym mogą upłynąć lata, zanim otrzyma się odpowiedź od klientów.

To powód, dla którego mamy testerów. Doskonały tester dostarcza programistom natychmiastowej informacji zwrotnej na temat tego, co zrobili dobrze, a co źle. Wierzcie bądź nie, jedną z najbardziej wartościowych cech testera jest dostarczanie pozytywnego wsparcia. Nie ma lepszego sposobu na polepszenie morali programistów, zadowolenia oraz dobrego samopoczucia niż ekspres do kawy La Marzocco Linea posiadanie oddanych testerów, którzy otrzymują częste wydania od programistów, wypróbowują je, i dają negatywne i pozytywne informacje zwrotne. W innym przypadku, przygnębiającym jest bycie programistą. Oto ja, szybkopiszący, tworzący cały ten świetny kod i nikt o to nie dba. Buuuu.

Kto powinien zostać testerem? To podchwytliwe! Testowanie oprogramowania to jedna z tych ścieżek kariery, która nie jest dobrze znana, tak więc wielu ludzi, którzy mogliby być nieźli w testowaniu i polubiliby to, nigdy nie rozważa podjęcia pracy na stanowisku testera.

Oznaki dobrego testera:

• Umiejętny
• Lubiący dobre układanki, nawet te, które wymagają wielu dni na ułożenie
• Lubiący myśleć o rzeczach metodycznie
• Ogólnie lubiący pracę z oprogramowaniem i komputerami

Nie musisz być programistą, aby zostać testerem. Wiele firm wymaga, aby testerzy byli programistami, którzy piszą zestawy automatycznych testów. To wydaje się być bardziej skuteczne. To odzwierciedla nieporozumienie na temat tego, co powinni robić testerzy, czyli ewaluacja nowego kodu, znajdowanie dobrych rzeczy, znajdowanie złych rzeczy oraz dawanie pozytywnego i negatywnego wsparcia programistom. Pewnie, automatyczne zestawy testów są oszczędnością czasu, ale testowanie oprogramowania pokrywa znacznie więcej niż to. Jeśli położysz zbyt duży nacisk na te skrypty, nie zauważysz źle ułożonego tekstu, wrogiego interfejsu użytkownika, złego doboru kolorów oraz niespójności. Co gorsza, wyrobisz sobie kulturę testerów, którzy gorączkowo pracują nad tym, aby ich kod działał, co oddala ich od tego, co naprawdę powinni robić: ewaluować czyiś kod.

Wyjątkowo paskudnym pomysłem jest oferowanie stanowiska testera programistom, którzy aplikują do Twojej firmy, a nie są wystarczająco dobrzy, aby pracować na stanowisku programisty. Testerzy nie muszą być programistami, ale jeśli odpowiednio długo będziesz twierdził, że tester to tylko niekompetentny programista, w końcu będziesz budował zespół niekompetentnych programistów, a nie zespół kompetentnych testerów. Jako iż testowania można się nauczyć w pracy, a ogólnej inteligencji nie, naprawdę potrzebujesz bardzo mądrych ludzi na testerów nawet, jeśli nie mają odpowiedniego doświadczenia. Wielu testerów, z którymi pracowałem nie zdawało sobie nawet sprawy, że chcą być testerami, dopóki ktoś nie zaoferował im pracy.

Jeśli:

• Kochasz oprogramowanie i komputery
• Chciałbyś pracować w zespole tworzącym oprogramowanie, oraz
• Niekoniecznie lubisz programowanie

powinieneś rozważyć zostanie testerem.

Data publikacji oryginału: 26 stycznia, 2010

---

Korzystając z okazji, chcielibyśmy dowiedzieć się, jak to jest u Was w firmach. Zachęcamy więc do wzięcia udziału w sondzie oraz do podzielenia się w komentarzach własnymi doświadczeniami związanymi z tematyką dzisiejszego wpisu.

Kto u Ciebie w firmie testuje oprogramowanie?

Elegancja

Oryginalny post: Elegance

Autor: Joel Spolsky

Alain de Botton w swojej książce The Architecture of Happiness (wyd. Pantheon Books, 2006) zawarł sekcję dotyczącą elegancji, która każdemu projektantowi oprogramowania wyda się znajoma.

Porównuje on most Salginatobel w Szwajcarii...

... z mostem Clifton Suspension w Anglii:

... w jednej z najbardziej niesamowitych książek o architekturze jakie kiedykolwiek przeczytałem:

Obydwa mosty – Salginatobel, Roberta Maillarta oraz Clifton Suspension, Isambarda Brunela są przejawem siły i mocy; obydwa cieszą się naszym podziwem za umożliwienie bezpiecznego przedostania się na drugą stronę przepaści. Ale w tej parze most Maillarta jest piękniejszy, niespotykanie smukły, bez trudności i z łatwością pełni swoją rolę. Natomiast most Brunela, ze swoimi ociężałymi blokami kamiennymi i ciężkimi stalowymi linami, ma w sobie coś z krępego mężczyzny w średnim wieku, który podciąga swoje szorty i głośno domaga się uwagi ze strony innych - zanim dokona skoku pomiędzy dwoma krańcami przepaści. Tymczasem most Maillarta przypomina gibkiego atletę, który wzbija się w powietrze bez specjalnych ceremonii i zanim opuści arenę sportową, z gracją pręży się jeszcze przed publicznością. Obydwa mosty dokonują czegoś niespotykanego, ale Maillarta ma dodatkową zaletę i osiąga to bez widocznego wysiłku. I ponieważ wydaje nam się, iż nie jest to takie proste, podziwiamy ten wyczyn jeszcze bardziej. Most ten reprezentuje podkategorię piękna, którą możemy nazwać elegancją. Jakość taka pojawia się wtedy, kiedy dzieło architektury spełnia pokładane w nim nadzieje – podtrzymuje, otacza, chroni – zarówno z wdziękiem, w sposób ekonomiczny jak i solidnie; kiedy jest to rozwiązanie na tyle skromne, aby nie przyciągać uwagi do trudności, jakie przezwycięża.

W tym kontekście chciałbym odświeżyć moje rozważania na temat wyborów oraz prostoty i dodać trzecią koncepcję – elegancję.

Ludzie zazwyczaj nie pracują z oprogramowaniem ponieważ tego pragną. Używają oprogramowania jako narzędzia do osiągnięcia swoich innych celów. Być może używają czatu, aby wyglądać na bystrych, mając przy tym nadzieję, że osoba z którą czatują zechce spędzić z nimi czas i dzięki temu, w ostatecznym rozrachunku, zwiększą swoje szanse na znalezienie partnera, a zupełnie finalnie, ich samolubne DNA dostanie okazję do replikacji. Być może używają arkusza kalkulacyjnego, aby sprawdzić, czy mogą pozwolić sobie na większe lokum, ostatecznie, randki będą robiły większe wrażenie, zwiększając ich szanse na znalezienia partnera, znowu, z korzyścią dla DNA. Być może pracują nad prezentacją w PowerPoint dla swojego szefa, aby dostać awans, dzięki czemu będą mieli więcej pieniędzy, które będą mogli wydać na zakupienie większego mieszkania, które przyciągnie znajomych, zwiększając szanse na znalezienie partnera, (idea chyba jest już jasna?) aby samolubne DNA mogło się zreplikować. Być może szukają w Internecie recepty na kozi ser, itd., itd., ... DNA.

Jeżeli nie są zawodowymi recenzentami oprogramowania, tak naprawdę nie obchodzi ich oprogramowanie jako takie, a im bardziej to dostrzegają, tym bardziej stają się nerwowi.

Wybory mogą więc być dobre albo złe. Są dobre, kiedy bezpośrednio wspomagają realizację zadania, z jakim przyszło zmierzyć się użytkownikowi. Chcę mieć możliwość wyboru z kim rozmawiam przez czat (tak, w rzeczy samej). Są natomiast złe, kiedy ingerują w cele użytkownika na poziomie replikacji DNA. Co kilka dni jakiś nędzny program, którego nie pamiętam nawet abym kiedykolwiek instalował, atakuje mnie popup'ami pytającymi, czy chcę zupgradować to albo tamto. Nie mogłoby mnie to obchodzić MNIEJ. W tym momencie coś robię. Zostawcie mnie w spokoju! Jestem przekonany, że zespół z Sun Microsystems, który wydał tę sławetną nową wersję wirtualnej maszyny Javy pracował nad tym wydaniem noc i dzień przez długie miesiące, ale pozostałe 5 000 000 000 z nas na planecie naprawdę niewiele to obchodzi. Nawet trudno będzie Ci sobie wyobrazić jak bardzo nie chcę przeznaczyć nawet trzech sekund mojego życia na zastanawianie się, czy instalować nową wersję JVM, czy może nie. Ktoś, gdzieś tam, właśnie uruchamia Gmail, aby powiadomić mnie, iż JVM nie powinna się sama uaktualnić, „bo to coś popsuje”. Taaa, jeśli cała kolektywna wiedza zespołu Javy nie jest w stanie określić, czy aby nie spowoduje to zepsucia czegoś, niby skąd ja mam to wiedzieć?

Jeśli używasz terminu prostota mając na myśli „grację i ekonomię” lub „elegancję” to wspaniale. Świetnym tego przykładem jest różnica między metodą wyszukiwania muzyki na Rhapsody i metodą wyszukiwania muzyki na iTunes. Rhapsody karze Ci decydować, czy chcesz wyszukiwać album, piosenkę, czy artystę. iTunes nie daje Ci żadnego wyboru: po prostu przeszukuje wszystkie pola, co działa tak samo dobrze i jest prostsze. Ekonomia w tym przypadku znaczy tyle co władza użytkownika - i jest to dobra cecha.

Z drugiej strony, jeśli używasz terminu prostota, kiedy mowa o brakach w wydajności, brakach w funkcjonalności, to świetnie. Jeśli chcesz być w biznesie spinaczy do papieru, powodzenia, ale szanse, że Twój produkt rozwiąże moje konkretne problemy zaczynają się kurczyć i Twój udział w rynku również zaczyna się kurczyć.

Data publikacji oryginału: 15 grudnia, 2006

Nie słuchaj, co mówią — problemem zawsze są ludzie

Oryginalny post: No Matter What They Tell You, It's a People Problem

Autor: Jeff Atwood

Bruce Eckel zręcznie identyfikuje źródło wszystkich problemów związanych z tworzeniem oprogramowania:

Pracujemy w młodej branży. W zasadzie to prymitywnej -- nie wiemy za bardzo co działa i wydaje nam się, że znaleźliśmy prosty sposób, który rozwiązuje wszystkie problemy. W rezultacie przechodzimy przez wieloletnie okresy wzlotów i upadków, w miarę jak nowe pomysły się pojawiają, startujemy, wyczerpujemy możliwości, a następnie tracimy energię. Ale niektóre idee mają permanentną moc. Jak na przykład, wiele idei w zwinnych metodykach wydaje się mieć rzeczywisty wpływ na produtywność i jakość. Jest tak, ponieważ skupiają się one na problemach ludzi pracujących razem, a mniej na technologiach.

Człowiek, od którego wiele się nauczyłem, Gerald Weinberg, napisał parę swoich pierwszych książek o technologiach programowania. Następnie przestawił się i współtworzył 50 następnych, o procesach programowania, i jest najbardziej znany z powiedzenia "nie ma znaczenia co Ci powiedzą, zawsze jest to problem z ludźmi."

Rzeczami, które zazwyczaj powodują, iż projekt się udaje bądź nie, są problemy z procesem bądź ludźmi. Sposób w jaki pracujesz każdego dnia. To kim są Twoi architekci, Twoi menadżerowie oraz to z kim pracujesz w zespole. To, jak się komunikujesz i co ważniejsze, jak rozwiązujesz problemy z procesem i ludźmi, gdy się pojawią. Najszybszym sposobem na napotkanie trudności jest myślenie, że to wszystko jest winą technologii i wiara w to, że można sobie wytrasować drogę za pomocą innych rzeczy. Te inne rzeczy to najprawdopodobniej te, które Cię zatrzymają.

Bruce źle zapamiętał rzeczywisty cytat; brzmi on "niezależnie od tego co to za problem, jest to problem z ludźmi." Ale przekręcenie Bruce'a ma pewną niewypowiedzianą prawdę, która naturalnie jest w duchu dzieł Geralda Weinberga.

Powiedzmy, że dano mi zadanie określenia czy Twój projekt nie powiedzie się. Posiadając odpowiedzi na trzy poniższe pytania, mogę Ci powiedzieć niemal z całą pewnością, czy Twój projekt upadnie:

1. Ile linii kodu Twój zespół napisze?
2. Jaki rodzaj oprogramowania tworzysz?
3. Czy lubisz swoich współpracowników?

To ostatnie pytanie nie jest żartem. Nie zlewam się. Czy lubisz towarzystwo członków Twojego zespołu? Czy szanujesz ich zawodowo? Czy jakbyś zaczynał w innej firmie, czy zaprosiłbyś swoich współpracowników do siebie? Czy macie nastrojowe, zespołowe dyskusje, czy poniżające, przeciągane, obstrukcyjne zespołowe kłótnie do ostatniej krwi? Czy wielu jest ludzi w Twoim zespole, za którymi byś głosował, żeby odeszli, jeśli byś mógł?

Może banalnym wydawać się skupianie na ludziach, z którymi pracujesz zamiast na rzeczach bardziej namacalnych, powiedzmy, faktycznej pracy bądź konkretnej technologii, której używasz do wykonywania tej pracy. Ale tak nie jest. Ludzie, których wybierasz do pracy, są najdokładniejszym wskaźnikiem satysfakcji z pracy, jaki kiedykolwiek znalazłem. A satysfakcja z pracy, bazując na moim dotychczasowym doświadczeniu, świetnie koreluje z sukcesem. Nigdy nie widziałem szczęśliwego, zdrowego, solidnego, towarzysko zgranego zespołu programistów, który odniósł porażkę. To wstyd, że takie zespoły to rzadkość.

Tak jak to powiedział Weinberg, to zawsze problem z ludźmi. Jeśli nie pracujesz z ludźmi, których lubisz, ludźmi których szanujesz, ludźmi którzy rzucają Ci wyzwania i inspirują Cię -- to czemu by nie? Co Cię zatrzymuje?

Data publikacji oryginału: 9 stycznia, 2008

---

Zachęcamy do wzięcia udziału w sondzie oraz do podzielenia się w komentarzach własnymi doświadczeniami związanymi z tematyką dzisiejszego wpisu.

Czy lubisz swoich współpracowników?

Jak osiągnąć Największy Blogowy Sukces w jednym prostym kroku

Oryginalny post: How To Achieve Ultimate Blog Success In One Easy Step

Autor: Jeff Atwood

Zawsze szturchaj. Zawsze dostarczaj. Zawsze strzelaj. To ta sama rada wyrażona w różnych formach dla różnych odbiorców.

Według mojej teorii, pozyskiwanie potencjalnych klientów wywodzi się z rankingu Google, a najlepszym sposobem na zwiększenie tego rankingu jest postępowanie jak zawodowy wojownik: ani uderzenia, ani sierpowe nie wystarczają. Musisz zawsze szturchać i regularnie uderzać sierpowym. Bloguj nieustannie, aby utrzymać procent trafień i ruch z odnośników na wysokim poziomie, oraz pisz co jakiś czas dłuższe kawałki, zawierające wysokowartościowe słowa związane z Twoją niszą.

Kiedy ludzie pytają mnie o porady dotyczące blogowania, zawsze odpowiadam kolejną formą tej samej rady: obierz sobie pewien plan, według którego możesz postępować i trzymaj się go. Dopóki tego nie będziesz robił, żadna inna rada, której mógłbym Ci udzielić nie będzie miała znaczenia. Nie obchodzi mnie, że jesteś beznadziejny w pisaniu. Nie obchodzi mnie, że nikt nie czyta Twojego bloga. Nie obchodzi mnie, że nie masz nic interesującego do powiedzenia. Jeśli potrafisz wykazać ochotę do pisania oraz ciągłego ulepszania swojej twórczości, w końcu odniesiesz sukces.

Ale sukces wymaga czasu -- dużo czasu. Powiedziałbym, że rok to minimum. Ten wymóg eliminuje sporą część niecierpliwych ludzi. Pisałem tego bloga przez rok kompletnie po omacku, ale nie przerywałem, ponieważ mi się to podobało. Zrobiłem sobie postanowienie, pod płaszczykiem rozwoju osobistego, i zaplanowałem osiągnąć ten cel. Moim planem było sześć wpisów na tydzień i ciągle szturchać, ciągle dostarczać, ciągle strzelać. Nie każdy wpis był wspaniały, ale spędzałem nad nimi rozsądną ilość czasu. Za każdym razem, gdy coś napisałem, stawałem się w tym nieco lepszy. Za każdym razem, gdy coś napisałem, nauczyłem się czegoś o danym temacie, analizowania danych tematów, czy szukania najlepszych źródeł informacji. Za każdym razem, gdy coś napisałem, stawałem się nieco bardziej związany z bogatą społecznością związaną z programowaniem. Za każdym razem, gdy coś napisałem, otrzymywałem odrobinę informacji zwrotnych bądź komentarzy, które później przekształcałem w kolejne wpisy. Za każdym razem, gdy coś napisałem, starałem się pisać coś w najmniejszym stopniu lepszego niż poprzednio.

Te zmiany, dla mnie, były niemal niezauważalne. Ale cofając się do samego początku -- postanowienie z 2004 roku jeśli chodzi o rozwój zawodowy -- powiedziałbym, że ten blog jest teraz, bez wątpienia, najważniejszą rzeczą jaką kiedykolwiek robiłem w całej mojej karierze.

Nie powiem, że dawno w 2005 roku dostałem moją pracę w Vertigo z powodu tego bloga, ale z całą pewnością było to czynnikiem. Udzieliłem wywiadu na .NET rocks oraz dawałem wywiad online nie raz lecz dwa razy. Zapraszano mnie, abym przemawiał na konferencjach. Co kilka miesięcy dostaję propozycje napisania książek. Koresponduję regularnie ze Stevem McConnellem, jednym z moich programistycznych idoli, i kiedyś zapytał mnie o radę dotyczącą blogowania. Joel Spolsky, prawdę mówiąc, rozpoznał mnie i zaprosił na rozmowę, podczas gdy uczęszczałem na część jego jego turne, która odbywała się w Emeryville. Charles Petzold wysłał mi, całkowicie bez namawiania, podpisaną kopię swojej najnowszej książki. Regularnie różni ludzie oferują się, że przyślą mi niesamowicie fajne i darmowe klamoty.

Za całą pewnością mogę Wam powiedzieć, powołując się na statystyki RSS i logi, że około 100 000 ludzi czyta ten blog każdego dnia. Wpływy z reklam, które raczej niechętnie odbierałem, są na tyle znaczące, że w końcu wziąłem pod uwagę pomysł, w chwilach słabości, zostania pełnoetatowym blogerem. Do tego doszło. Nie oczekiwałem takiego rezultatu nawet w przeciągu miliona lat, a pisanie o tym w ten sposób w zasadzie trochę mnie przeraża.

Wymieniłem te rzeczy nie dlatego, że jestem wielkim, paskudnym szpanerem (albo przynajmniej nie był to jedyny powód), ale dlatego, że osiągnąłem to wszystko nie będąc szczególnie utalentowanym. Tworzyłem to wpis po wpisie, bez jakiegokolwiek planowania czy strategii, z myślą o byciu coraz mniej beznadziejnym każdego roku. Wciąż jestem zadziwiony i pokorny w obliczu sukcesu tego bloga. Wymagało to jedynie podstawowego poświęcenia do ciągłego szturchania, ciągłego dostarczania, ciągłego strzelania.

Jeśli już, to nauczyłem się jednego: jeśli ja mogłem osiągnąć taki rodzaj sukcesu ze swoim blogiem, możesz i Ty. Tak więc jeśli zastanawiasz się dlaczego pierwszą rzeczą, o którą zapytam, gdy Cię spotkam będzie "czy masz bloga?", albo "dlaczego nie piszesz na swoim blogu bardziej regularnie?", albo "czy możesz z tego zrobić wpis na blogu?", teraz już wiesz. To nie tylko dlatego, że jestem tym wkurzającym kolesiem od bloga; to dlatego, że każdemu kogo spotkam, chciałbym życzyć tak samo zadziwiającego sukcesu, który przytrafił się mnie.

Próbuję jedynie podzielić się moim jedynym, łatwym krokiem do osiągnięcia Największego Blogowego Sukcesu: ustal plan wydawania wpisów, według którego możesz żyć i trzymaj się go przez rok. Być może kilka lat. Ok, może ten jeden krok nie jest tak łatwy, jakim go określiłem. Ale każdy musi gdzieś zacząć, a im wcześniej tym lepiej.

Tak więc, kiedy Ty ostatnio napisałeś jakiś wpis na blogu?

Data publikacji oryginału: 26 października, 2007

---

Korzystając z okazji, chcielibyśmy dowiedzieć się, ilu z Was prowadzi własnego bloga. Zachęcamy więc do wzięcia udziału w sondzie oraz do podzielenia się w komentarzach własnymi doświadczeniami związanymi z tematyką dzisiejszego wpisu.

Czy prowadzisz własnego bloga?

Wybór wywołuje ból głowy

Oryginalny post: Choices = Headaches

Autor: Joel Spolsky

Jestem przekonany, że nad przyciskiem OFF w Windows Vista bardzo ciężko pracował cały zespół projektantów interfejsu, programistów i testerów. Ale tak serio, czy jest to najlepsze rozwiązanie jakie można było otrzymać?

Za każdym razem kiedy chcesz odejść od komputera, musisz wybierać między dziewięcioma - policz to dobrze - dziewięcioma opcjami. Dwie ikony i siedem pozycji w menu. Myślę, że te dwie ikony są skrótami do menu. Zgaduję, że ikona z kłódką robi to samo co pozycja „Lock” w menu, ale nie jestem pewien, która pozycja menu odpowiada ikonie włącz/wyłącz.

W wielu laptopach są jeszcze cztery kombinacje klawiszy FN+coś żeby wyłączyć, zahibernować, uśpić itd. To daje 13 możliwych wyborów. Chwila, fakt, jest jeszcze fizyczny przycisk włącz/wyłącz – 14, i można przecież zamknąć pokrywę – 15. W sumie daje to 15 możliwości z których możesz wybierać, kiedy chcesz wyłączyć swojego laptopa.

Im więcej wyborów dajesz ludziom, tym trudniej im wybrać i tym mniej szczęśliwi się czują. Przejrzyj, na przykład, książkę autorstwa Barry'ego Schwartza, The Paradox of Choice. Pozwól mi zacytować z recenzji Publishers Weekly: „Schwartz, czerpiąc szeroko ze swojej pracy w dziedzinie nauk społecznych, pokazuje, iż zbyt liczny zbiór wyborów zalewa nasze przemęczone mózgi, ostatecznie ograniczając, zamiast dawać wolność. Zazwyczaj zakładamy w Ameryce, że więcej możliwości uczyni nasz szczęśliwszymi, ale Schwartz wskazuje, że prawda jest inna. Argumentuje, że wszystkie te wybory doprowadzają do erozji dobrego samopoczucia psychicznego.”

Fakt, iż musisz wybierać pomiędzy dziewięcioma możliwymi drogami prowadzącymi do wyłączenia Twojego komputera w samym tylko menu start, nie wspominając już możliwości naciśnięcia fizycznego przycisku włącz/wyłącz albo zamknięcia pokrywy laptopa, wywołuje przykrość za każdym razem kiedy wyłączasz system.

Czy cokolwiek może zostać w tej kwestii zrobione? To musi być możliwe. Ipod nie ma nawet przełącznika on/off. Jest kilka pomysłów.

Jeśli rozmawiałeś ostatnio z ludźmi, którzy nie są geekami, może zauważyłeś, że oni nie mają pojęcia jaka jest różnica między „uśpij” a „zahibernuj”. Można by to swobodnie połączyć. Jedna opcja mniej.

Przeloguj oraz Zablokuj mogłyby zostać połączone dając możliwość zalogowania innemu użytkownikowi kiedy system jest zablokowany. Przy okazji prawdopodobnie oszczędziłoby to wielu wymuszonych wylogowań. Kolejna opcja mniej.

Kiedy już złączyliśmy Przeloguj z Zablokuj, czy rzeczywiście potrzebujemy Wyloguj? Jedyną rzeczą, jaką daje wylogowanie jest zakończenie wszystkich działających programów. Ale to samo robi wyłączenie z odcięciem zasilania, więc jeśli rzeczywiście zależy Ci na zakończeniu działających programów, po prostu wyłącz i włącz system. Jeszcze jedna opcja załatwiona.

Restart może zostać wyeliminowany. 95% przypadków, kiedy go potrzebujesz spowodowanych jest instalacją, która zmusza do restartu. W innych przypadkach możesz system po prostu wyłączyć i włączyć ponownie. Kolejna opcja mniej. Mniej wyboru, mniej bólu.

Oczywiście, powinniśmy wyeliminować rozróżnienie między ikonami a menu. To wyklucza dwie dodatkowe opcje. Zostaliśmy przy:

Uśpij/Zahibernuj
Przeloguj/Zablokuj
Wyłącz

A co, gdybyśmy połączyli Uśpij, Zahibernuj, Przeloguj i Zablokuj? Kiedy wybierasz taką opcję, komputer przeskakuje do ekranu „Przeloguj użytkownika”. Jeśli nikt nie zaloguje się przez 30 sekund, przechodzi w stan uśpienia. Kilka minut później – hibernacji. W każdym przypadku jest zablokowany. Więc teraz zostały nam dwie opcje:

(1) Odchodzę w tym momencie od mojego komputera
(2) Odchodzę w tym momencie od mojego komputera, ale chciałbym, żeby zasilanie było rzeczywiście odcięte

A dlaczego chcesz odcinać zasilanie? Jeżeli ze względu na zużycie energii, zostaw to oprogramowaniu zarządzającemu energią, niech ono się tym martwi. Jest w tym lepsze od Ciebie. Jeśli chcesz otworzyć system i jednocześnie nie chcesz być zszokowany, w zasadzie odcięcie zasilania może być niewystarczające, powinieneś wyciągnąć wtyczkę. Gdyby Windows używał RAM-u, który byłby w praktyce pamięcią trwałą, poprzez kopiowanie pamięci na nośnik flash podczas okresów bezczynności, w zasadzie mógłbyś odciąć zasilanie w trybie „zaraz wracam” bez utraty czegokolwiek. Nowe hybrydowe dyski twarde mogą cały ten proces uczynić super szybkim.

Więc teraz zostaliśmy z dokładnie jednym przyciskiem do wyłączania. Nazwijmy go „b'bye”. Kiedy klikasz b'bye, ekran jest blokowany i pamięć RAM, która nie została jeszcze skopiowana na flash jest zapisywana. Możesz zalogować się ponownie, może zalogować się ktoś inny i uruchomić własną sesję, można też całkowicie wyłączyć komputer.

Z pewnością zamierzasz wskazać długą listę mądrych i usprawiedliwiających powodów dla których każda z tych opcji jest absolutnie niezbędna. Nie trudź się. Ja wiem. Każdy dodatkowy wybór ma sens, dopóki nie będziesz musiał wytłumaczyć swojemu wujkowi, że aby wyłączyć swojego laptopa musi wybierać pomiędzy 15 różnymi opcjami.

To pokazuje styl projektowania oprogramowania wspólny zarówno dla Microsoftu jak i ruchu open source. W obydwu przypadkach pragnie się konsensusu i „Uczynienia Wszystkich Szczęśliwymi”, ale to jest oparte na nieprawidłowym spostrzeżeniu, jakoby dużo wyborów dawało ludziom szczęście, powinniśmy to naprawdę przemyśleć jeszcze raz.

Data publikacji oryginału: 21 listopada, 2006