Przeciwieństwo Prawa Fittsa

Oryginalny post: The Opposite of Fitts' Law

Autor: Jeff Atwood

Jeśli kiedykolwiek wykłócałeś się o interfejs użytkownika, to prawdopodobnie słyszałeś o Prawie Fittsa. To całkiem proste -- im większy obiekt i im bliżej kursora się znajduje, tym łatwiej jest na niego kliknąć. Kevin Hale stworzył świetne wizualne streszczenie Prawa Fittsa, tak więc zamiast tłumaczyć, odsyłam Was tam.

Krótka wersja Prawa Fittsa, aby oszczędzić Wam tego nudnego czytania, jest następująca:

• Umieszczaj powszechnie używane elementy UI na krawędziach ekranu. Jako iż kursor automatycznie zatrzymuje się na krawędziach, będzie łatwiej na nie klikać.
• Obszary, na które się klika, uczyń możliwie jak największymi. Większe obiekty są łatwiejsze do klikania.

Wiem, że to bardzo proste, niemal za proste, ale zrób to dla mnie i wykonaj poniższe ćwiczenia. Wyobraź sobie siebie próbującego kliknąć na ...

• obiekt rozmiaru 1 x 1 o losowym położeniu
• obiekt rozmiaru 5 x 5 o losowym położeniu
• obiekt rozmiaru 50 x 50 o losowym położeniu
• obiekt rozmiaru 5 x 5 umiejscowiony w rogu ekranu
• obiekt rozmiaru 1 x 100 umiejscowiony na samym dole ekranu

Prawo Fittsa to w dużej mierze zdrowy rozsądek i cieszy się ono wystarczającą popularnością wśród projektantów UI, którzy prawdopodobnie o nim wiedzą mimo, iż nie przestrzegają go tak pobożnie jak powinni. Niestety, zauważyłem, iż projektanci jeszcze w mniejszej mierze biorą pod uwagę przeciwieństwo Prawa Fittsa, które jest niewątpliwie równie ważne.

Jeśli elementy UI, które chcielibyśmy, aby użytkownicy klikali, powinniśmy robić duże i umieszczać w rogach bądź na krawędziach dla ułatwienia klikania -- to co powinniśmy robić z elementami UI, na które nie chcielibyśmy, aby użytkownicy klikali? Jak na przykład przycisk "Skasuj całą moją pracę"?

Alan Cooper, w książce About Face 3, nazywa to dźwignią do katapultacji.

W kokpicie każdego myśliwca znajduje się jasno pokolorowana dźwignia, która po pociągnięciu, wystrzeliwuje mały silnik rakietowy znajdujący się pod fotelem pilota, wyrzucając pilota razem z siedzeniem z samolotu, aby wylądował bezpiecznie na ziemi. Dźwignie do katapultacji mogą być użyte tylko raz i konsekwencje tego są znaczące i nieodwracalne.

Aplikacje muszą posiadać takie dźwignie, aby użytkownicy mogli-co-jakiś-czas-zmieniać położenie stałych elementów interfejsu bądź dramatycznie (czasem nieodwracalnie) zmieniać funkcjonowanie albo zachowanie aplikacji. Jedyną rzeczą, jaka nie powinna się nigdy wydarzyć, jest przypadkowe uruchomienie takiej dźwigni.

Konstrukcja interfejsu musi zapewniać, aby użytkownik nigdy nieumyślnie nie odpalił dźwigni do katapultacji podczas rutynowych operacji w programie.

Przychodzi mi na myśl kilka aplikacji, których używam regularnie, a gdzie przycisk dźwigni do katapultacji jest w niewytłumaczalny sposób zaraz obok przycisku do włączania świateł w kabinie. Spójrzmy dla przykładu na naszego starego przyjaciela, czyli pocztę GMail:

Mogę Ci powiedzieć o czym myślisz. Czy kliknął Wyślij czy Zapisz teraz? Tak więc, aby być szczerym, to w tym całym uniesieniu podczas pisania tego pełnego wściekłości e-maila, pogubiłem się w tym co robię. Dobre jest to, że w łatwy sposób możemy anulować wysłanego e-maila! A nie, czekaj, to jest niemożliwe. Wyobraź sobie mój fotel, albo przynajmniej tego pochopnego e-maila, wystrzelonego.

Jest jeszcze gorzej podczas archiwizowania e-maili.

O ile w poprzednim przykładzie było przynajmniej 10 pikseli pomiędzy przyciskami, to w tym są całe... trzy. Co kilka dni przypadkowo naciskam Zgłoś Spam, kiedy tak naprawdę chciałem kliknąć Archiwizuj. Ale, na obronę Google'a, oferują oni prostą możliwość cofania dla tych przypadkowych kliknięć. Ale nie mogę przestać się zastanawiać nad tym, dlaczego te dwa przyciski, o zupełnie różnych funkcjonalnościach, muszą się znajdować jeden obok drugiego.

Cofanie zmian to potężna rzecz, ale czyż nie lepiej by było, gdybyśmy ciągle nie pociągali za dźwignię do katapultacji? Czy nie byłoby sensowniej umieścić tę ryzykowną dźwignię w innej lokalizacji i uczynić ją mniejszą? Zobacz edytor wpisów na WordPressie.

Tutaj, powszechna operacja Aktualizuj jest w postaci dużego i oczywistego przycisku -- jest łatwy do zauważenia i do kliknięcia. Rzadziej używana operacja Przenieś do kosza jest mniejsza, zaprezentowana jako zwykły odnośnik i umieszczona z daleka od operacji Aktualizacji.

Następnym razem, gdy będziesz tworzył interfejs użytkownika, koniecznie powinieneś przestrzegać Prawa Fittsa. To po prostu ma sens. Lecz nie zapomnij przestrzegać też przeciwieństwa Prawa Fittsa -- rzadko używane i niebezpieczne elementu UI powinny być trudne do kliknięcia!

Data publikacji oryginału: 24 marca, 2010

Wdrażaj wcześnie i często

Kolejne tłumaczenie w serwisie 97rzeczy:

• Wdrażaj wcześnie i często (autor: Steve Berczuk)
  "Testowanie procesu wdrożenia i instalacji często odkładane jest na sam koniec realizacji projektu. Przy niektórych projektach pisanie narzędzi instalacyjnych delegowane jest do inżyniera zajmującego się wdrożeniami, który podchodzi do tego zadania jak do "zła koniecznego". ..."

I jeszcze takie pytanie do Was — czy chcecie, żebyśmy informowali tutaj o nowych artykułach z serwisu 97rzeczy?

Życzymy przyjemnej lektury!
Zespół devMedia.pl

Kolejne 2 z 97 rzeczy, o których każdy programista wiedzieć powinien

Zapraszamy do lektury kolejnych dwóch tłumaczeń w serwisie 97rzeczy:

• Zautomatyzuj swój standard kodowania (autor: Filip van Laenen)
  "Prawdopodobnie byłeś już w takiej sytuacji. Na początku projektu każdy ma sporo dobrych chęci — nazwijmy je "postanowieniami nowoprojektowymi". Bardzo często wiele z tych postanowień jest zapisywanych w dokumentach. Te dotyczące kodu trafiają do standardów kodowania projektu. Podczas spotkania rozpoczynającego projekt, główny programista czyta wszystko, co znajduje się w takim dokumencie, i w najlepszym wypadku, wszyscy zgadzają się z tym, że będą starali się tego przestrzegać. Jednak kiedy projekt się rozpoczyna, dobre postanowienia zostają porzucane jedno po drugim. Kiedy projekt jest w końcu dostarczony, kod wygląda jak istny bałagan i nikt zdaje się nie wiedzieć, jak do tego doszło. ..."
• Strzeż się współdzielenia (autor: Udi Dahan)
  "To był mój pierwszy projekt w tej firmie. Byłem świeżo upieczonym absolwentem, który nie może doczekać się, aż będzie mógł się wykazać. Siedziałem po godzinach, przeglądając istniejący kod, a podczas pracy nad moją pierwszą funkcjonalnością, zadbałem o to, by wykorzystać wszystko, czego się do tej pory nauczyłem — komentarze, logowanie, wyciąganie wspólnego kodu do bibliotek itp. Jednakże na pierwszym przeglądzie mojego kodu, na który byłem, jak mi się wówczas wydawało, dobrze przygotowany, czekało mnie brutalne przebudzenie — recenzent skrzywił się, gdy zobaczył wspołdzielenie kodu! ..."

Informujemy również, że działa już tam system komentarzy, więc zachęcamy do dzielenia się z innymi własnymi przemyśleniami.

Życzymy przyjemnej lektury!
Zespół devMedia.pl

antylama.pl - zadajemy pytania związane z komputerami

Na początku roku programiści dostali swój serwis typu Q&A. Minęło 2,5 miesiąca, zarejestrowało się sporo użytkowników, zadano wiele pytań i udzielono wielu, najczęściej dobrych, odpowiedzi. Podczas tego krótkiego okresu udało się również zorganizować upominki, które zostały niedawno rozdane. Oby tak dalej ;]

Im szybciej uda nam się wydostać programistów z archaicznego stylu dyskusji opartego na phpBB, tym lepiej dla nas. Misją devPytań jest podniesienie poziomu dyskusji o programowaniu oraz umożliwienie szybszego i dokładniejszego znalezienia informacji przez szukających. Wszystko to dzięki wypróbowanej platformie. W katalogu serwisów opartych o StackExchange można zobaczyć, jak devPytania wypadają na tle innych serwisów Q&A.

Tak więc programiści pomagają już sobie jeśli chodzi o szeroko pojęte programowanie. Jaka jest więc ich druga pasja?

Komputery.

Wszyscy programiści są entuzjastami komputerów a większość uważa się za zaawansowanych użytkowników. Niemniej jednak, niejednokrotnie napotykamy na problemy, gdy chcemy podłączyć trzeci monitor, zainstalować odpowiedni soft na routerze, czy skonfigurować system operacyjny, żeby działał tak, jak chcemy. Problemy i dylematy związane z komputerami można by wyliczać w nieskończoność i każdego dnia znajdzie się ktoś, kto potrzebuje pomocy w tej kwestii. Tak więc skoro posiadamy już tyle wiedzy na temat komputerów — dzielmy się nią i pomagajmy sobie sprawdzonymi metodami.

Stąd pomysł na serwis:

Przedstawienie zasad uznajemy za zbędne. Wszystko jest tak, jak na devPytaniach — oprócz tematyki, którą w tym przypadku są komputery (sprzęt, oprogramowanie).

Dodaliśmy do tego tryb rozruchowy:

Tryb rozruchowy pomaga ukształtować społeczność, zanim strona zostanie udostępniona szerszej grupie odbiorców.

Wymagania co do reputacji są mniej restrykcyjne podczas trybu rozruchowego. Wszyscy użytkownicy mogą:

• Zadawać pytania
• Odpowiadać
• Komentować
• Tworzyć tagi
• Zmieniać tagi pytań
• Głosować

Będziesz zdobywał punkty reputacji w sposób normalny, ale ich brak nie spowoduje zablokowana części funkcjonalności serwisu.

Więcej możecie dowiedzieć się, przeglądając Poradnik trybu rozruchowego.

Jeśli już mowa o dodatkach, to oprócz logowania się za pomocą OpenId pojawiła się możliwość zakładania kont na adres e-mail i hasło.

Tak więc ułatwmy sobie życie razem z antylamą! Zapraszamy!

Grupa devMedia.pl prezentuje pierwsze 3 z 97 rzeczy ...

... o których każdy programista wiedzieć powinien.

Zainspirowani niedawno wydaną książką zatytułowaną 97 rzeczy, o których każdy programista wiedzieć powinien, pomyśleliśmy, że nasza społeczność również chętnie skorzystałaby z wiedzy tam zawartej. Ku naszej uciesze okazało się, że wszystkie artykuły z tej książki objęte są licencją Creative Commons, więc bez przeszkód mogliśmy zabrać się za ich tłumaczenie (tutaj wielki ukłon dla wydawnictwa O'Reilly). Pragniemy zatem przedstawić Wam najnowszy projekt naszego autorstwa — 97rzeczy:

Poniżej zamieszczamy odnośniki do pierwszych trzech artykułów:

• Postępuj rozważnie (autor: Seb Rose)
  "Choćby nie wiem jak bardzo bezpiecznie wyglądał harmonogram na początku iteracji, nigdy nie unikniesz działania pod presją w którymś jego momencie. ..."
• Stosuj zasady programowania funkcjonalnego (autor: Edward Garson)
  "Programowanie funkcjonalne cieszy się ostatnio wzmożonym zainteresowaniem wśród społeczności programistów piszących w językach głównego nurtu. ..."
• Zapytaj "Co zrobiłby użytkownik?" (Nie jesteś użytkownikiem) (autor: Giles Colborne)
  "Wszyscy mamy skłonność do zakładania, że inni ludzie myślą tak jak my. Ale tak nie jest. ..."

Życzymy przyjemnej lektury i czekamy na odzew z Waszej strony!
Zespół devMedia.pl

Dlaczego moje optymalizacje nie optymalizują?

Oryginalny post: Why Aren't My Optimizations Optimizing?

Autor: Jeff Atwood

"W 97% przypadków nie powinniśmy przejmować się wydajnością: przedwczesna optymalizacja jest źródłem wszelkiego zła." - Donald Knuth

Na blogu Michaela Tepera znajduje się doskonały wpis o autentycznym scenariuszu optymalizacji, związanej z podmianą stringów. Po zaimplementowaniu trzech logicznych alternatyw, Mike spojrzał na wyniki testów wydajności i zapytał,

Dlaczego moje optymalizacje nie optymalizują?

Optymalizacja kodu to śliski interes. Wypróbowałbym te same rzeczy -- prawdopodobnie w tej samej kolejności. Wielokrotnie, podejścia, o których zakładałem, że będą "szybsze", okazywały się błędne. To dlatego mówię programistom, zawsze mierzcie wydajność. Nigdy nie zakładajcie, że coś będzie szybsze czy wolniejsze, dopóki tego nie zmierzycie - będziecie zaskoczeni tym, jak często Wasze założenia są błędne. Niestety, czasami sposób w jaki mierzycie wydajność może być wadliwy. To jest to, co ujawniło, iż trzecia optymalizacja Mike'a była w rzeczywistosci optymalizacją:

okazało się, że Replace jest szybki jedynie wtedy, gdy wejściowy łańcuch znaków nie zawiera łańcucha (bądź znaku), który jest przeznaczony do podmiany. Natomiast, kiedy go zawiera, wydajność klasy CleanString spada oraz, tak jak oczekiwano, tablica znaków okazuje się bardziej wydajna.

Jeśli już musisz optymalizować, upewnij się, że testujesz poprawne przypadki z rozsądnym zbiorem danych testowych, aby upewnić się, iż faktycznie masz do czynienia z poprawą. A przed "ulepszaniem" czegokolwiek, zapamiętaj zasady optymalizacji M.A. Jacksona:

Zasady optymalizacji:

Zasada 1: Nie rób tego
Zasada 2 (tylko dla ekspertów): Jeszcze tego nie rób

I dodałbym trzecią: nie optymalizuj tego, czego nie trzeba. Nie zrozum mnie źle, wydajność jest niesamowicie ważna...

Podstawowa rada dotycząca czasu odpowiedzi nie zmieniła się przez prawie 30 lat [Miller 1968; Card et al. 1991]:

• 0.1 sekundy to czas, który sprawia, iż użytkownik ma wrażenie, że system reaguje natychmiastowo, to znaczy, że żadna informacja zwrotna, oprócz wyniku, nie jest wymagana.
• 1 sekunda to czas, który nie powoduje u użytkownika przerwania ciągu myślowego, nawet jeśli zaobserwuje on opóźnienie. Zazwyczaj żadna specjalna informacja nie jest potrzebna podczas opóźnień dłuższych niż 0.1, a krótszych niż 1 sekunda, ale użytkownik traci już uczucie pracy bezpośrednio na danych.
• 10 sekund to maksymalny czas w jakim można utrzymać skupienie uwagi użytkownika. Dla dłuższych opóżnień, użytkownik będzie chciał wykonywać inne operacje podczas, gdy czeka na wynik poprzedniej, zatem powinna być dostarczona pewna informacja wskazująca oczekiwany czas ukończenia operacji. Informacje zwrotne podczas opóźnień są szczególnie ważne, kiedy czas odpowiedzi może być zmienny, gdyż użytkownicy nie wiedzą, czego mogą oczekiwać.

... tak jak posiadanie funkcjonalnego, stabilnego systemu. To do Ciebie należy decyzja, jak to wyważyć. Dla tych, którzy chcą wiedzieć więcej, to ten temat został doskonale potraktowany w 9 rozdziale książki Programming Pearls. Dodatkowo, Microsoft Performance Blogger Rico jest ciekawą (i .NET-ową) lekturą.

Data publikacji oryginału: 24 sierpnia, 2004

Podziękowania dla społeczności devBlogów i devPytań

Serwis devPytania rozpoczął swoją działalność razem z początkiem nowego roku. Zamysłem serwisu było i jest stworzenie miejsca, w którym polscy programiści mogliby pomagać sobie nawzajem w efektywny i sprawdzony sposób. Niemniej jednak rdzeniem tego przedsięwzięcia nie jest platforma.

devPytania to Wy.

Programiści, którzy decydują się na uczestniczenie w społeczności devPytania są tym, co sprawia, że to przedsięwzięcie ma sens. To dzięki Wam społeczność programistów jest najlepszym źródłem do nauki i rozwoju. To Wy jesteście przyczyną tego, iż niektórzy dziękują za to, że takie miejsce powstało. I nie można tej zasługi przypisywać nam. Ona należy do Was.

Pozostaje nam zachęcać Was nadal do tworzenia tych społeczności. Do tej zachęty chcielibyśmy dołożyć coś bardziej materialnego. Z różnych powodów nie zdecydowaliśmy się na żaden konkurs. Niemniej jednak dysponujemy pewnymi nagrodami i właśnie teraz chcielibyśmy je rozdać. Postanowiliśmy zatem nagrodzić trzech najbardziej aktywnych użytkowników serwisu devPytania (według stanu reputacji na dzień 6 marca 2010). Nagrody zostały ufundowane przez firmę Telerik i są to pakiety kontrolek:

A otrzymują je:

	Marcin Seredyński (http://fabrikum9.com) pakiet kontrolek Telerik RadControls for Silverlight
	Paweł Łukasik (http://pawlos.blogspot.com) pakiet kontrolek Telerik RadControls for Silverlight
	Dariusz Gil (http://dario-g.com/) pakiet kontrolek Telerik RadControls for ASP.NET AJAX

Wyróżnionym serdecznie gratulujemy i zachęcamy wszystkich do dalszego, aktywnego uczestnictwa w życiu serwisów devPytania.pl oraz devBlogi.pl.

Zespół devBlogi.

Kultywuj zespoły, nie pomysły

Oryginalny post: Cultivate Teams, Not Ideas

Autor: Jeff Atwood

Ile wart jest dobry pomysł? Według Dereka Siversa niewiele:

Śmieszy mnie to, jak ludzie starają się chronić swoje pomysły. (Ludzie, którzy każą mi podpisać NDA, aby mogli opowiedzieć mi najprostszy pomysł.) Jak dla mnie, pomysły nie są nic warte, dopóki nie są zrealizowane. Są tylko mnożnikiem. Wykonanie jest warte miliony.

Aby zrobić interes, musisz pomnożyć oba. Najbardziej błyskotliwy, a niezrealizowany pomysł jest wart $20. Najbardziej błyskotliwy pomysł wymaga doskonałego wykonania, aby być wartym $20000000. To dlatego nie chcę słyszeć o pomysłach innych ludzi. Nie jestem zainteresowany, dopóki nie zobaczę realizacji.

Artykuł pana Siversa przypomniał mi się po tym, jak ten e-mail zaczął krążyć w tym miesiącu:

Czuję, iż ta historia jest ważna na tyle, aby ją Wam opowiedzieć, ponieważ Kickstarter.com nas skopiował. Przez 4 lata próbowałem nakłonić ludzi, aby potraktowali Fundable na poważnie, podróżując po kraju, a nawet prowadząc prezentacje dla FBFund, funduszu Facebooka do stymulowania rozwoju nowych aplikacji. Przez 4 lata była to seria odrzuceń. Naprawdę czułem, że prezentuję siebie w sposób profesjonalny w każdej możliwej sytuacji biznesowej, ubierałem się stosownie oraz ćwiczyłem moje prezentacje. To nie wystarczyło. Ci idioci oczekiwali od nas, abyśmy pokazali wykresy z olbrzymimi dochodami i szeroko rozpowszechnioną akceptacją tak, aby nie musieli ponosić żadnego ryzyka.

Wszystko czego trzeba było, to pięciu dobrze zorganizowanych ludzi w Kickstarter (w szczególności Andy Baio), aby wziąć pomysł, nad którym ciężko pracowaliśmy, dostroić go z Amazon Payments i zgarnąć pulę. Mógłbyś powiedzieć, że taki właśnie jest kapitalizm, ale wciąż jestem zdania, iż powinieneś wyrazić wdzięczność ludziom, od których czerpiesz inspirację. Naprawdę tak myślę. Koncepcję Fundable zawdzięczam wielu rzeczom, włączając w to mieszkanie z chętnymi do współpracy studentami oraz studiowanie politologii w Michigan. Teoria racjonalnego wyboru, tragedia wspólnego pastwiska oraz działanie zbiorowe to kilka pojęć z dziedziny politologii, które mają znaczenie w Fundable.

Tak, Fundable miało parę problemów technicznych oraz problemów z obsługą klienta. To dlatego, że nie posiadaliśmy pieniędzy na skorygowanie tego. Miałem plany, aby wywalić cały CMS i napisać go od początku z nowym designem. Byliśmy tak wypaleni, że motywacja była trudna do osiągnięcia. Jaki był tego sens, skoro po 4 latach nie zarabialiśmy wystarczająco pieniędzy na utrzymanie?

Rozłąka między pomysłem a wykonaniem jest tak rozległa, że ciężko jest zrozumieć, dlaczego autor sam tego nie zauważa.

Nie nazywałbym pomysłów bezwartościowymi, per se, ale oczywistym jest, iż same pomysły są pustą walutą. Sukces rzadko jest wyznaczony przez jakość Twoich pomysłów. Ale często jest wyznaczany przez jakość Twojego wykonania. Tak więc zamiast martwić się o to, czy Następny Wielki Pomysł, nad którym wszyscy pracujecie jest wystaraczająco wyśmienity, martw się o to, jak dobrze go realizujecie.

Krytyka mówiąca o tym, że wszystko czego potrzebujesz, aby osiągnąć sukces, to "dobrze zgrani ludzie" została również zaznaczona w przypadku Stack Overflow. W e-mailu, który dostałem w poprzednim roku, Andy Baio -- o ironio, ta sama osoba, która była cytowana we wcześniejszym e-mailu -- powiedział:

Bardzo mi się spodobała debata na Hacker News o klonowaniu strony internetowej w weekend. Moje ulubione komentarze to te od ludzi, którzy twierdzą, że Stack Overflow odniósł sukces tylko dzięki Kultowi Atwooda i Spolskyego. Zadziwiające.

Nie obchodzi mnie, jak bardzo jesteś znany w Internecie; nikt nie jest zwolniony z wykonania. Pewnie, fajnie byłoby mieć więcej użytkowników na początku, ale jeśli nie tworzysz czegoś użytecznego, społeczność ostatecznie wzruszy swoimi ramionami i przejdzie dalej do bardziej użytecznych rzeczy.

Jednym z moich najbardziej ulubionych cytatów dotyczących oprogramowania pochodzi od Wila Shipleya:

Oto cała Twoja aplikacja: zbiór malutkich szczegółów.

Jeśli chodzi o wytwarzanie oprogramowania, wykonanie stoi na czele wszystkich tych malutkich szczególików, które tworzą Twoją aplikację. Jeśli nie masz ciągłej obsesji co do każdego aspektu Twojej aplikacji, nieprzerwanie dopieszczając i polepszając każdą jej część -- niezależnie od tego jak prostą -- nie postępujesz z wykonywaniem. A przynajmniej nie za dobrze.

I o ile nie pracujesz sam, co jest dziś rzadkością, Twoja zdolność do skupienia się nad zbiorem malutkich szczególików, które składają się na Twoją aplikację, zależeć będzie całkowicie od tego, czy potrafisz stworzyć doskonały zespół. To zespoły są podstawą każdego przedsięwzięcia odnoszącego sukces. Poniższy wykład Eda Catmulla jest niemal całkowicie skupiony na tym jak Pixar nauczył się, metodą prób i błędów, budować zespoły, które potrafią wykonywać.

Jest to fascynujący wykład, pełen świetnych spostrzeżeń i powinieneś obejrzeć całość. Pan Catmull wzmacnia w nim uczucie pana Siversa:

Jeśli dasz dobry pomysł średniemu zespołowi, to schrzanią to. Jeśli dasz średni pomysł dobrej grupie, naprawią to. Albo odrzucą go i wymyślą coś innego.

Wykonanie nie jest tylko i wyłącznie mnożnikiem. Jest o wiele bardziej potężne. To jak Twój zespół radzi sobie z wykonywaniem ma taką moc, jak przekształcanie Twojego pomysłu ze złota w ołów, bądź z ołowiu w złoto. To dlatego, kiedy tworzyliśmy Stack Overflow miałem nie tylko ogromne szczęście pracować z Joelem Spolskym, ale również możliwość wybrania dwóch najlepszych programistów, z jakimi kiedykolwiek pracowałem w moich poprzednich miejscach pracy i zaproszenia ich do pracy ze mną. Kopiąc i krzycząc jeśli było to konieczne.

Jeśli musiałbym wskazać jedną rzecz, która przyczyniła się do sukcesu naszego projektu, to nie był to pomysł, który za tym stał, nasza sława internetowa, narzędzia, które wybraliśmy, czy fundusze, które mieliśmy (malusieńkie, żeby była jasność).

To był nasz zespół.

Wartość mojej rady jest sporna. Ale postąpiłbyś słusznie biorąc pod uwagę radę pana Siversa i pana Catmulla. Jeśli chcesz odnieść sukces, przestań się martwić o rewelacyjne pomysły, a zacznij koncentrować się na kultywowaniu doskonałych zespołów.

Data publikacji oryginału: 25 stycznia, 2010

A może normalizowanie nie jest normalne?

Oryginalny post: Maybe Normalizing Isn't Normal

Autor: Jeff Atwood

Jednym z problemów z jakimi mierzymy się teraz przy Stack Overflow jest utrzymanie wysokiego poziomu wydajności relacyjnej bazy danych, podczas gdy jej rozmiar znacząco rośnie. Bardziej precyzyjnie, chodzi o skalowanie naszego systemu tagów. Dobrze zaprojektowana baza danych to baza znormalizowana, tak mówią tradycyjne zasady projektowania. Niemniej jednak, ja nie jestem tego taki pewien.

Dare Obasanjo opublikował świetny post pt. Kiedy nie powinieneś normalizować swojej bazy SQL, w którym podaje przykładowy schemat bazy danych dla serwisów społecznościowych. Gdybyśmy chcieli zaprojektować bazę zgodnie z szeroko akceptowanymi zasadami normalizacji, wyglądałoby to tak:

Normalizacja z pewnością sprawdza się, kiedy chodzi o ograniczenie duplikacji. Każda instancja reprezentowana jest raz i tylko raz – praktycznie nie ma więc ryzyka niespójności danych. Ale takie podejście wymaga również monstrualnych sześciu joinów, aby pobrać informacje o pojedynczym użytkowniku.

select * from Users u inner join UserPhoneNumbers upn on u.user_id = upn.user_id inner joinUserScreenNames usn on u.user_id = usn.user_id inner join UserAffiliations ua on u.user_id = ua.user_id inner join Affiliations a on a.affiliation_id = ua.affiliation_id inner join UserWorkHistory uwh on u.user_id = uwh.user_id inner join Affiliations wa on uwh.affiliation_id = wa.affiliation_id

(Update: nie jest to przykład pretendujący do bycia realnym; jest tutaj po to, aby zobrazować fakt, że potrzeba sześciu joinów – albo sześciu oddzielnych zapytań, jeśli tak wolisz – żeby dostać wszystkie informacje o użytkowniku.)

Te sześć joinów nie pomaga Twojej aplikacji w kwestiach wydajności. Pełna normalizacja może być nie tylko trudna do zrozumienia i utrudniająca pracę – może być również wolna.

Jak wskazuje Dare, oczywistym rozwiązaniem jest denormalizacja – złączenie wielu danych w jedną tabelę Users.

To działa – zapytania są trywialnie łatwe (select * from users) i prawdopodobnie znacznie szybsze. Ale w zamian za to, będziesz miał kilka dziur w swoich danych, razem z wieloma niezręcznie nazwanymi polami tablicy. Wszystkie cholerne problemy z integracją, które tak bardzo Cię męczą? Będziesz musiał się teraz nimi zająć. Gratuluję „degradacji”!

Obydwa rozwiązania mają zalety i wady. Pozwól więc, że zadam pytanie: co jest lepsze – znormalizowana baza danych, czy baza zdenormalizowana?

Podstępne pytanie. Odpowiedzią jest - to nie ma znaczenia! Dopóki nie masz milionów, milionów rekordów danych. Wszystko działa szybko dla małych n. Nowoczesny na dzisiejsze standardy pecet – powiedzmy dwurdzeniowy z 4 GB pamięci – da praktycznie identyczne wyniki wydajnościowe dla obydwu przypadków, dopóki nie rozważysz największych baz. Oczywiście, zakładając, że potraficie w zespole pisać dobrze zoptymalizowane zapytania.

Nie brakuje fascynujących relacji z wojen bazodanowych dostarczanych przez firmy w to wszystko zaangażowane. Obawiam się, że te historyjki utrzymywane są w tym samym tonie co „zgubiłem 100 kilogramów, więc Ty też możesz!”, zwróć proszę uwagę na małą gwiazdkę: wyniki mogą różnić się w każdym indywidualnym przypadku, która podczas czytania tych historyjek cały czas ma zastosowanie. Poniżej znajduje się kompilacja Tima O'Reilly'a:

• Second Life
• Blogline and Memeorandum
• Flickr
• NASA World Wind
• Craigslist
• O'Reilly Research
• Google File System and BigTable
• Findory and Amazon
• MySQL

Jest również blog High Scalability, na którym także można znaleźć zbiór historyjek z wojen bazodanowych:

• YouTube
• PlentyOfFish
• Google
• MySpace
• Amazon
• Twitter

Przede wszystkim, sprawdzian na kontakt z rzeczywistością. Częściowo to grzech pychy, wyobrażać sobie, że Twoja aplikacja to następny Flickr, YouTube albo Twitter. Jak trafnie powiedział Ted Dziuba – skalowalność nie jest Twoim problemem, dostarczyć to cholerstwo, jest. Więc jeśli dochodzi do projektowania bazy danych, mierz wydajność, ale staraj się podążać w stronę rozsądnego i prostego projektu. Wybierz jakikolwiek schemat bazy, który wydaje Ci się najłatwiejszy do zrozumienia i wykorzystywania podczas codziennej pracy. Nie musi to być to, co zaprezentowałem powyżej, nie musi to być nawet część tego; możesz denormalizować fragmentami, tam gdzie ma to sens, a pozostawiać postać normalną, gdzie takiego sensu – denormalizacji - nie ma.

Mimo wielu dowodów, że normalizacja rzadko daje się skalować, odkrywam, iż wielu programistów będzie zażarcie jej broniło, dla samej tylko zasady. Długo po tym, kiedy przestało mieć to sens.

Podczas rozwijania oprogramowania Cofax w Knight Ridder, natrafiliśmy na pewne problemy, po tym kiedy dodaliśmy 17-tą gazetę do systemu. Wydajność nie była taka jak wcześniej i zdarzały się sytuacje, kiedy usługa nieodpowiadała.

Rozpoczęliśmy projekt mający na celu naprawić sytuację, odnaleźć źródło problemów. Stwierdziliśmy, że baza danych, tak dobrze zaprojektowana, nie może być problemem, pomimo symptomatycznego, gwałtownego przyrostu liczby połączeń do bazy zaraz przed awarią. Skoncentrowaliśmy się więc na optymalizacji działania samej aplikacji.

Ja się z tym nie zgodziłem i rozważyłem kilka argumentów, wskazujących że to jednak nasza baza danych wymaga uwagi. Na początku potrzebowaliśmy zoptymalizować zapytania i indexy. Gdyby było potrzeba, obliczać dane przed zapisem i unikać złączeń, tworząc kilka zdenormalizowanych tabel. Była to gorzka pigułka do przełknięcia, zwłaszcza dla mnie, ponieważ byłem projektantem tej bazy. A okazało się, że dla pozostałych było to jeszcze trudniejsze! Wezwaliśmy konsultantów. Stwierdzili, że baza jest zaprojektowana dobrze i że problemem musi być sama aplikacja.

Po dwóch miesiącach, kiedy bez rezultatu zespół produkował wiele różnych modyfikacji, aby naprawić problem, wróciliśmy do moich wcześniejszych argumentów.

Pat Helland uważa, że ludzie normalizują, ponieważ tak zostali nauczeni przez swoich profesorów. Ja jestem trochę bardziej pragmatyczny; myślę, że powinieneś normalizować, kiedy dane wskazują na następujące fakty:

1. Normalizacja jest sensowna dla Twojego zespołu.
2. Normalizacja pozwala uzyskać lepszą wydajność (automatycznie mierzysz wszystkie zapytania składające się na Twoje oprogramowanie, prawda?).
3. Normalizacja chroni przed dokuczliwą duplikacją lub pomaga uniknąć ryzyka problemów synchronizacji, które są szczególnie istotne dla Twojej dziedziny albo użytkowników.
4. Normalizacja pozwala Ci pisać prostsze zapytania i kod w ogólności.

Nigdy, przenigdy nie powinieneś normalizować bazy danych ze względu na jakąś powinność wobec duchów Boyce'a i Codda.
Normalizacja nie jest magicznym proszkiem, którym posypujesz swoją bazę danych, aby wyleczyć ją ze wszystkich chorób. Często tworzy równie wiele problemów jak rozwiązuje. Nie bój się widma denormalizacji. Duplikowane dane i problemy synchronizacji często są przeceniane i relatywnie łatwe do poprawienia przy pomocy zadań crona. Dyski oraz pamięć są tanie i tanieją co każdą nanosekundę. Mierz wydajność Twojego systemu i sam zdecyduj co działa lepiej, wolny od przesądów i uprzedzeń.

Jak rzecze stare porzekadło - normalizuj dopóki to nie boli, denormalizuj dopóki to działa.

Data publikacji oryginału: lipiec 14 2008