niedziela, 15 kwietnia 2012

Umysł emocjonalny

Pierwszy obraz jaki widzisz w swojej głowie po usłyszeniu słów uczucia i emocje to obraz scalonego z klawiaturą programisty, który wykorzystuje odziedziczony i rozwijany od setek milionów lat mechanizm umysłowy aby stworzyć doskonały kod.

Nie. Widzisz zapewne coś przeciwnego : dynamiczne obrazy przedstawiające fascynujące przeżycia i wyraźne wspomnienia ekstremalnych momentów z twojego (lub cudzego) życia. Treść raczej rzadko kiedy ma cokolwiek wspólnego z programowaniem a raczej czerpie garściami z tematów nazywanych powszechnie "czysto ludzkimi".

Nie musi tak być...





Ukryta moc obliczeniowa

Eksperyment przebiegał następująco:

  • Każdy z uczestników wybiera kartę z jednej z czterech kupek ("kupka" to chyba odpowiednie słowo)
  • Każda wybrana karta to punkty dodatnie lub ujemne
  • Jedyne informacje dostarczone uczestnikom mówią, że pewne kupki są "lepsze" od innych
  • Faktycznie kupki zostały tak przygotowane, że dwie z nich w okresie długofalowym przynosiły więcej strat niż zysku
  • Kolejność kart została tak przygotowana aby rozpoznanie "natury kupki" było w zasadzie niemożliwe (Odpowiednie programy komputerowe już o to zadbały).
  • Przez cały czas trwania eksperymentu naukowcy monitorowali "odpowiedź czuciową" uczestników mierząc przewodność ich skóry (na podstawie założenia, iż przeżywając emocje ludzie (a dokładnie ich skóra) mają tendencję do wydzielania potu, który to zmniejsza opór elektryczny)
Wnioski
Po pewnym czasie trwania eksperymentu naukowcy zauważyli, że organizmy badanych niejako przygotowują się do odparcia ataku zaraz przed tym jak mieli wyciągnąć kartę ze "złej" kupki. (Dokładnie stwierdzono to na podstawie znacznego skoku przewodności skóry). Możemy z tej obserwacji wyciągnąć wniosek, że my - ludzie - a w zasadzie nasze umysły, są w stanie wykonywać niesamowicie skomplikowane obliczenia, których wyniki otrzymujemy w postaci działania czegoś co możemy nazwać INTUICJĄ lub INSTYNKTEM.

Wymagający czytelnik mógłby zauważyć, że powyższe wnioski być może zostały wyciągnięte zbyt pochopnie. Cóż, wspomniany eksperyment powtórzono i to powtórzono nie na byle kim. Na co dzień naukowcy zajmujący się neurobiologią muszą się "ograniczać" do eksperymentów na szczurach,świnkach morskich i amerykańskich studentach. Jednakże od czasu do czasu ktoś sobie coś uszkodzi i staje się tak długo oczekiwanym rekwizytem badawczym. Na scenę wchodzi...

Pacjent EVR

Pod tym pseudonimem kryje się nieszczęśliwa historia człowieka, któremu z powodu zmian rakotwórczych usunięto fragmentu kory czołowej (a konkretnie przedczołowy płat środkowy - czy coś takiego). Zaraz po operacji praktycznie każdy aspekt życia pacjenta EVR zaczął się rozpadać ze względu na niemożliwość dokonania szybkich wyborów. Każda decyzja - czy to zakup warzywa czy wybranie miejsca posiłku, musiała być poprzedzona najdrobniejszą analizą każdego detalu. Co i tak nie uratowało go przed utopieniem wszystkich swoich oszczędności w trefnych inwestycjach. Za straconą kasą poszła stracona miłość żony i w końcu pacjent EVR znalazł się w szpitalu

W szpitalu Został on poddany szczegółowym badaniom, które stwierdziły, że z punktu widzenia logiki nasz pacjent funkcjonuje znakomicie. Jednakże w trakcie badań badacze zauważyli coś dziwnego - bez względu na tematykę pytań i badań pacjent EVR przez cały czas wydawał się być pusty emocjonalnie. I faktycznie. Gdy przeprowadzono na nim eksperyment z kartami odczyty przewodności skóry (czyli "miernik odczuwania") nic nie wykazywały. Pacjent przez cały czas dokonywał błędnych wyborów przegrywając grę.

I ostatnia ciekawostka. Okazało się, inne osoby ze schorzeniami podobnymi do EVR potrafiły w pewnym stopniu przewidzieć logicznie, która kupka kart jest niebezpieczna ale ta wiedza nie wpłynęła absolutnie na ich decyzje!

Co z tego wynika dla informatyka

No, odpowiedź na to pytanie powinna być raczej oczywista. Jak by było zajebiście gdyby swędzenie lewego kciuka dało ci znać, że właśnie wprowadzasz poważnego buga do aplikacji? Ja sobie doskonale zdaje sprawę, że na świecie jest pełno innego typu "pacjentów", którym wydaje się, że można przeprowadzić gigantyczną analizę, wszystko zaplanować na 20 lat w przód a później wyniki tej analizy dać grupie "kodujących małpek". Złudzeniom i omamom poświecimy osobny odcinek. Dzisiaj skupmy się na rzeczywistości, w której to programista co chwila musi podejmować decyzje oddziałujące na niezwykle skomplikowane środowisko złożone z masy wymagań funkcjonalnych i multum zależności technicznych . W takich warunkach jest totalnym bezsensem oczekiwać, że nasz świadomy mechanizm umysłowy zapamięta i rozpracuje każdy problem, który ujrzy na swej drodze. Jeśli istnieje dodatkowa moc obliczeniowa to dlaczego jej nie użyć?

Jeśli ktoś czytał tego bloga od początku to pewnie wie, że ta cała "dodatkowa moc obliczeniowa" nie jest jakimś magicznym wynalazkiem. O tym czym jest umysł świadomy a czym nieświadomy można przeczytać choćby tutaj --> Model umysłu. Prawie, że pod naszym nosem, za zasłoną myślenia abstrakcyjnego działa prawdziwy "rozpierdalacz informacji", który interpretuje otaczającą cię rzeczywistość (Tak czy inaczej te przerobione informacje wpłyną na nasze decyzje, które później będziemy sobie racjonalizować). I tutaj pojawia się moment w którym ten cały mechanizm można użyć na naszą korzyść.

Generalnie ta nasza podświadoma maszynka łyka wszystko to co dostanie : nie ważne czy informacje dociera do mózgu przez oczy,uszy,dotyk czy też zostaje w nim bezpośrednio wytworzona . Dokładnie! Z tego co wiem sportowcy od dawna ćwiczą swój instynkt poprzez przeróżne wizualizacje.W zakresie tej tematyki pojawiło się wiele technik o różnym stopniu powodzenia. Temat rozwinę w następnych odcinkach jakkolwiek na dzień dzisiejszy kto chce może sobie poszukać informacji w necie lub zerknąć do książki :

wtorek, 3 kwietnia 2012

Testy dla ludzi

Post zaczniemy od części multimedialnej - 29.03 na łódzkim JUGu miała miejsce prezentacja wykonana przez skromnego spikera w mojej jeszcze skromniejszej osobie. Głównym tematem były testy mutacyjne, o których wspomnę kiedy indziej. Dzisiaj będzie za to trochę herezji, ale najpierw seans.

Po co są zasady...

W niemal każdej książce, na niemal każdym blogu i chyba w każdym artykule poświęconym inżynierii obiektowej pojawia się zasada znana jako DRY - "Don't Repeat Yourself". Zasada jest dobra - nawet bardzo dobra - podobnie jak zasada jazdy prawym pasem. Przestrzeganie jej będzie ratować nam życie dopóki nie wyjedziemy zarabiać w Anglii na zmywaku - wtedy przestrzeganie jej może nas zabić...

Jedziemy na razie prawym pasem. Poniższy obrazek przypomni klasyczne zyski zastosowania zasady DRY. Wyobraźmy sobie, że to kawałek kodu sterującego robotem przemysłowym. Powyżej sexownej czerwonej kreski mamy powtarzający się kod, który nie wiele nam mówi. Stosujemy zasadę DRY - i BUM - poniżej czerwonej kreseczki widzimy, że tzw. "ektrakcja metody" nie dość, że usunęła nam powtórzenie to jeszcze wprowadziła aspekt samo-dokumentacji kodu.

Teraz czas zjechać na pas przeciwległy.

Jak najlepiej czytać dokumentację ?

Jak wyglądałaby idealna dokumentacja według zasady DRY? Poniżej chyba nic się nie powtarza a poszczególne koncepcje są wyciągnięte do osobnych punktów i paragrafów.

Teraz następuje krytyczny moment, gdyż aby zrozumieć konsekwencje takiego zapisu trzeba wysilić swoją wyobraźnie i zdolności empatyczne. W chwili obecnej czytelnik być może siedzi wygodnie w fotelu popijając kawę lub browara i pełen relaksu zerka na załączone fotografie zastanawiając się "co w tym takiego trudnego?"

Jak to mawiają trenerzy NLP : "czy masz na tyle odwagi aby wyobrazić sobie, że siedzisz po 6 godzinnym maratonie kodowania ( w firmach nastawionych na 'napierdalanie' gdzie przerwa obiadowa jest około godziny siedemnastej należy liczbę 6 zamienić na 13) , gonią cię terminy, manager non stop rozprasza pytaniami na kiedy TO będzie, a w domu chyba zostawiłeś włączone żelazko ale na szczęście nie będzie pożaru bo chyba nie zakręciłeś też wody"

I teraz za przeproszeniem ku*wa należy rozpocząć dyskusję czy taki biedny programista będzie mieć siłę skakać pomiędzy klasami czy co gorsza analizować konfiguracje w xmlach aby rozwikłać zagadkę dlaczego dany test nie działa? (pytanie jest retoryczne). Czy wygodniej nam czytać dokumentację na screenie powyżej czy też może skłonimy się ku propozycji zamieszczonej poniżej.

Pisałem już w poście : wyczerpywanie się energii psychicznej , o tym jak nasza siła psychiczna męczy się od "noszenia" cięższych i bardziej skomplikowanych koncepcji. Dokumentację na drugim slajdzie na pewno łatwiej się czyta ale powstaje pytanie : co gdy chcemy ją zmienić. w przypadku dokumentacji papierowej nie jest wtedy trudno o pomyłkę czy przeoczenie ALE... W przypadku dokumentacji w postaci testów sytuacja się obraca moim zdaniem o 180 stopni gdyż jeśli testy są napisane poprawnie to każde miejsce, które nie nadążyło za aplikacją zgłosi błąd. I teraz oczywiście musimy się do każdego takiego fragmentu z osobna udać aby go naprawić i chyba jest to najlepsza metoda aby upewnić się, że nasza zmiana nie wprowadziła skutków ubocznych.

Oczywiście są pewne granice w ramach których powyższe rozumowanie jest poprawne. Te granicę są określone przez minimalny poziom abstrakcji potrzebny do zrozumienia instrukcji. Dla jasności poniższy przykład pokazuje już przekombinowaną dokumentację :

No to jak nie DRY to co?

Tak jak pisałem na początku tego wywodu - metody DRY nie należy (według mnie) traktować jako jakiegoś świętego prawa, którego nieprzestrzeganie sprowadzi na nas apokalipsę (21 grudnia 2012) ale jako zwykłą zasadę. Co ciekawe wystarczy rozejrzeć się dookoła aby zobaczyć jak łamanie tej zasady ratuje nam codziennie życie. Z tego co mi wiadomo nasz organizm przechowuje wzorzec DNA w wielu kopiach dzięki czemu jeden mały wirusik nie jest w stanie jednym pyknięciem zamienić nas w jednego wielkiego raka.

Jak więc może nazywać się zasada przeciwna do DRY?

Przykład z pracy

Na ostatnim już obrazku w tym odcinku widzimy przykład cennika. Generalnie działa to tak, że jak kupi się odpowiednią ilość geokodowań (geokodowanie to w skrócie zapytanie o miejsce na ziemi ) to skaczemy do następnego poziomu z niższymi cenami. Według zasady DRY powinniśmy mieć jeden zestaw danych i jeden mechanizm tworzenia tych danych. Jednakże ze względu na lepszy obrazek zastosujmy zasadę WET co zaowocuje stworzeniem trzech odrębnych zestawów danych. I teraz :

  • Funkcjonalność szukania poziomów w ogóle nie potrzebuje żadnych cen. Wywalamy ceny i dzięki temu jak przestanie nam działać test to mamy mniej rzeczy do analizy
  • Funkcjonalność liczenia kasy musi mieć wszelkie nieprzyjemne i brzegowe wartości coby w czasach kryzysu żaden miedziak się nie zawieruszył. Ten zestaw danych jest najbardziej rozbudowany.
  • Tutaj mamy zestaw pośredni. Musimy się upewnić, że da się edytować co trzeba edytować ale już nie musimy 1500 różnych przypadków rozważać jak przy liczeniu kasy.

Podsumowanie

Oczywiście należy pamiętać, że wnioski którymi się tutaj dzielę, zostały zebrane na podstawie obserwacji ograniczonej grupy ludzi a czasem nawet wyłącznie na podstawie auto-psychoanalizy. Generalnie zauważyliśmy (ja i koledzy w pracy), że im więcej musimy się napocić przy czytaniu testu tym bardziej podświadomość traktuje go jako zbędny wydatek energetyczny. Coraz bardziej jestem przekonany, że pisanie testów należy zaklasyfikować do kategorii wyzwań "odroczonej gratyfikacji". Do tej pory wydawało mi się, że taki działający test stanowi gratyfikację sam w sobie jednakże ostatnie analizy skłaniają mnie do zakwestionowania tego wniosku - ale to już w innym odcinku.

Główny wniosek jest taki aby wszelkie niezbędne dane do zrozumienia testu były w zasięgu klasy testowej - żadne metody statyczne, żadne springi czy inne konfiguracje zewnętrzne mocków. Raz, że będzie łatwiej ten test zrozumieć, a dwa że można potem te lokalne ustawienia zoptymalizować aby test był jeszcze łatwiejszy do zrozumienia.

I tutaj mały wyjątek odnoszący się do akapitu mówiącego o minimalnym poziomie abstrakcji pisanej dokumentacji. (akapit nad pustynią). Generalnie rozwalanie hashmapy na drobne aby sprawdzić czy jakieś tam struktury mają inne struktury niekoniecznie sprzyja czytelności testu. Tutaj lepiej użyć Hamcresta albo FESTa. Doświadczenie wykazało, że jak już się dobrze napisze " maczera" to zazwyczaj nie trzeba już do niego zaglądać.