niedziela, 18 listopada 2012

Sortowanie dużych plików i geneza sydnromu "not invented here"

Wpis ten ten dzieli się na dwie części. Jeśli interesuje cię tylko techniczne mięsko to możesz drugą część ostentacyjnie olać. Ale osobiście jednak polecam ją przeczytać gdyż może to spowodować wybitnie wnikliwą zadumę u czytelnika (lub zdenerwowanie jeśli nie znajdzie tam nic ciekawego - ale to i tak lepsze od oglądania tańca z gwiazdami - dop. redakcji)

Analiza gotowca do sortowania naprawdę dużych plików


Problem : do posortowania jest w jednej chwili N relatywnie dużych plików tektowych

Czy istenieje gotowe rozwiazanie : tak : http://en.wikipedia.org/wiki/External_sorting

Czy istnieje implementacja tegoż rozwiązania w najwspanialszym języku we wszechświecie : tudzież też : http://code.google.com/p/externalsortinginjava/

Test

Maszyna


JVM
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m
Na wejściu
Plik zawierający N kwerend geograficznych (Miasto,ulica, dom itd)

Wyniki testu

Sortowanie alfabetyczne
Rozmiar pliku Czas sortowania
50k 374 ms
500k 1181 ms


Sortowanie specyficzne według pól kwerendy (na początku kraj, później maidto itd)
Rozmiar pliku Czas sortowania
50k 2815 ms
500k 24233 ms

Zrzut z visualVm

ogólna ocena


Część druga - Syndrom "tego tutaj jeszcze nie wynaleziono"

Syndrom doczekał się swojego wpisu w wikipedii : http://en.wikipedia.org/wiki/Not_invented_here. W IT objawia się ona pisaniem, pisaniem i pisaniem od nowa rzeczy, które dawno już ktoś zaimplementował. Ile osób zamiast użycia gotowej biblioteki zaimplementowałoby sortowanie plików własnoręcznie? I znowu coś co na dzień dzisiejszy wydaje się być bez sensu znajdzie uzasadnienie w warunkach do których jesteśmy tak naprawdę przystosowani...

Powrót na sawannę

Powyżej widzimy uproszczony koncepcyjny diagram gromady liniejących małp biegających po sawannie od 100tys do kilku milionów lat temu (od nich się właśnie wywodzimy). Członek gromady oznacza osobnika będącego w gromadzie a nie członka kogoś z gromady. Przeżycie każdego osobnika było w dużym stopniu zależne od grupy i pozycji jaką w niej zajmuje. Na zajmowaną pozycję i co za tym idzie - ilość dostępnych dla danej jednostki zasobów - wpływ miały : siła, koalicje oraz potencjalna wartość dostarczana gromadzie. W tym momencie interesuje nas to ostatnie.

Załóżmy, że gromada liczy 50 osób. Mamy w niej dwóch homo sapiens, którzy są podobnego wzrostu, podobnych osiągów ale jeden z nich posiadł umiejętność odróżniania grzybów trujących od jadalnych lub tez w sprytny sposób umie zwędzić miód z ula - kto będzie miał wyższą pozycję w gromadzie (zakładając, że żaden nie ma pleców u starszyzny)? Niby oczywiste, że ten który posiadł specyficzną umiejętność ALE aby tak się stało dwa warunki muszą być spełnione. Gromada z jakiegoś powodu musi potrzebować tej specyficznej umiejętności oraz gromada musi wiedzieć, że dany osobnik ma ową specyficzną umiejętność

Powrót do biura

Zakładając, że owe wzorce zostały ewolucyjnie wyryte w nas przez setki tysięcy lat zastanówmy się jak mogą się one objawiać :

  1. Gromada potrzebuje rozwiązania problemu
  2. Umiem rozwiązać dany problem
  3. Ale, ale istnieje ogólnodostępne tanie rozwiązanie tego problemu.
  4. Mam teraz dwa wyjścia - albo samemu zaimplementować rozwiązanie i zostać bohaterem (strata szansy gromady/zysk osobisty) czy też zostać kolesiem, który tylko zadzwonił po kolesia, który zna się na grzybkach (zysk gromady/strata szansy jednostki)

Można płakać, że profesjonalista w naszym zawodzie to powinien zawsze dla gromady i ten tego i w ogóle ale przypomnę a) nie jesteśmy istotami racjonalnymi, b) nie da się tak po prostu uciąć milionów lat ewolucji.Pozostaje mi jedynie dać wskazówkę dla osób w jakikolwiek sposób generujących warunki pracy - trzeba zrobić tak aby ów "osobnik" czuł się na tyle dowartościowany sukcesami grupy aby nie potrzebował szukać kompensacji w indywidualnych sukcesach. Trochę swiatła na ostatnie zdanie może rzuci dowcip :

- Szefie, ale szef ma fajne auto!
- słuchaj, pracuje dużo, zostawaj po godzinach, wykazuj inicjatywę i bierz na siebie coraz więcej obowiązków ... to za rok będę miał lepsze

niedziela, 11 listopada 2012

Relacja z pierwszego spotkania BYOP w Łodzi

BYOP w Łodzi kadr pierwszy - Ej masz jakiś problem?

BYOP to cykliczne spotkania odbywające się co miesiąc w innym mieście na które zapraszamy wszystkich pracowników z branży IT poszukujących rozwiązań problemów, z którymi borykają się w codziennej pracy, zwłaszcza problemów i pytań dotyczących zwinnych (i nie tylko) metodyk i procesów wytwarzania oprogramowania. (Więcej na : BYOP)

Tę ciekawą inicjatywę zawdzięczamy kolegom z codesprinters . Ku mej uciesze spotkanie było zadowalająco produktywne i pozbawione kreatywnych form trollowania czy wzajemnego przekrzykiwania.

Fajnie, że momentami uczestnicy bronili lekko rozbieżnych poglądów dzięki czemu można było troszeczkę zrozumieć cudzą perspektywę. Z drugiej jednak strony towarzystow było raczej "pro-agilowe" i następnym razem przydałby się jakiś "Hardcorowy Manager", który spróbowałby obronić swoje stanowisko.

Konkrety


Targety a metodyki zwinne

Bardzo ciekawy problem. Pracujemy w grupie ale jesteśmy oceniani indywidualnie co generuje masę problemów :

  • Jeśli oceny są względne to pomagając koledze osiągnąć lepsze rezultaty automatycznie sprawiam, że moje ocena spada
  • Co gorsza w teorii HR (i nie tylko) jest taki śmieszny wykres Gaussa. Jego nieomylność Gauss mówi, że nie można wszystkich członków zespołu ocenić bardzo dobrze. "Cycek" wykresu jasno precyzuje, że większość ocenianych powinna być przeciętna, jeden lepszy a jeden słaby. Czy teraz czujesz motywację aby pomóc koledze być tym najlepszym?
  • Czy jeśli członkowie zespołu będą oceniać siebie nawzajem to nie skończy się to uprawianiem polityki?

Potencjalne rozwiazania :
  • Oceniać zespół jako całość
  • Nie oceniać każdego zespołu według tych samych kryteriów
  • Zaprosić HRki na spotkanie i razem wymyślić sposób oceny
  • Nie oceniać?

Czy metodyki zwinne można zastosować w budowlance

Być może tak

Co nas motywuje

Pamiętam, że uczestnicy doszli do wniosku, że pieniądze nie są najlepszym motywatorem i narodziła się dyskusja o "transparentności" zasad w firmie. Podobno gdzieś w Bułgarii to się udało. Osobiście uważam, że pieniądze to całkiem fajny motywator ( dodatkowo przejawiam ogromną pasję do pracy - mogę jedynie przeprosić za to, że nie zgrałem się z wynikami badań ; ) )

Czy metodyki zwinne można zastosować w budowlance

Może jednak nie.

Komunikacja i feedback

Mamy dwie grupy ludzi - jedna zostaje wysłana na szkolenie z SVN i ECLIPSE a druga z psychologii i socjologii.

  • Pytanie 1 - Która grupa ludzi wypracuje skuteczniejszą formę komunikacji?
  • Pytanie 2- Którą grupę nazywamy informatykami, a którą managerami?
Sugestia : Programiści poza nauką nowych narzędzi zewnętrznych powinni nauczyć się jak działa działa ich narzędzie wewnętrzne (nie nie - tutaj chodzi o mózg - zboczeńcy ;))

Czy metodyki zwinne można zastosować w budowlance

Podobno gdzieś w Skandynawii się udało.

Rola Managera w Agile

Zdania odnośnie tego punktu - jeśli pamięć mnie nie myli - były lekko podzielone. Jeśli jest mądry to będzie pomagał Teamowi jako adwokat w ramach korporacji. Co jednak gdy team jest bardziej dojrzały od managera? (np. według tego modelu http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition) .

Ktoś powiedział, że w Scrumie nie ma miejsca dla project managera i najgorsze co może się zdarzyć to manager w płaszczyku scrum mastera. Jeśli już taka osoba jest to nie powinien zamykać się w swojej kanciapie tylko siedzieć razem  z Teamem.

Jednym z zagrożeń istnienia roli managera jest powstanie proxy i ograniczenie komunikacji świata z zespołem - w tym przypadku często powstają niezależne kanały komunikacji w różnym stopniu omijające managera.

Jak pisałem wcześniej tutaj przydałby się do dialogu jakiś przedstawiciel managementu. Wniosek z dyskusji - manager powinien przede wszystkim nie przeszkadzać.

Czy metodyki zwinne można zastosować w budowlance

Jak ktoś zbuduje dom metodykami zwinnymi niech da znać reszcie.

W oczekiwaniu na następne spotkanie

Następne spotkanie ma odbyć się w styczniu. Fajnie, że na pojawiło się relatywnie dużo osób niosących bagaż Agile co moim zdaniem oznacza, że Łódź pomału przestaje być fabryką taniego oprogramowania niskiej jakości.

Ps. polecam również recenzję spotkania BYOP w Łodzi na blogu kolegi Michała O. - http://michalostruszka.pl/blog/2012/11/08/first-byop-in-lodz/

Do następnego!

niedziela, 4 listopada 2012

Teoria mostów - rewizja

Pewien czas temu opisałem w poście Testowanie na granicach systemu konstrukcje jakich używałem aby ułatwić sobie tworzenie mocków testowych w miejscach gdzie nasz system styka się np. z systemem plików. Jeśli komuś nie chce się czytać to chodziło w nim o to aby zamiast pisać w 10 miejscach new File stworzyć specjalny "connector", który łatwo da się zmokować w Mockito.

Nadal uważam, że koncepcja była trafiona ale realizacja pokazała kilka uchybień (bądź dla osób trawiących bardziej dosadne określenia - kilka spierdolin). Najgorsze było to, że klasa FileSystemConnector zaczęła zamieniać się w jedna wielką zbieraninę średnio ze sobą powiązanych metod. Było to bardzo niedobre, bardzo bardzo złe...

Na Amazon

Czasami jest tak, że dopiero mocne jebnięcie budzi nas z letargu. Tak było i tym razem kiedy okazało się, że pliki będą czasem składowane w lokalnym systemie plików a czasem na "Amazon S3" ®™© . Bez wchodzenia w zbędne szczegóły FileSystemConnector zastąpiliśmy abstrakcją FileStorage , która razem z kilkoma innymi mechanizmami stworzyła w moim obecnym mniemaniu rozwiązanie całkiem całkiem obiektowe. Abstrakcję można nadal mockotwać a ją samą testuję testami integracyjnymi. Nie to jest jednak najciekawsze...

(Przedwczesna?) Abstrakcja

Krąży po necie koncept zwany Przedwczesną abstrakcją co podobnie jak przedwczesna optymalizacja ma negatywne konotacje (moja polonistka byłaby ze mnie dumna!). Tutaj jednak okazało się, że taka przedwczesna abstrakcja upraszcza kod w znacznym stopniu ułatwiając z nim pracę.

Już po pierwszej serii refactoringu, zanim jeszcze dodaliśmy cokolwiek związanego z S3, statystyki w sonarze wykazały tendencję pozytywną :

Rys1. Generalnie FileSystemConnector skaził troszeczkę także klasy korzystające z niego dlatego widać tutaj ogólną poprawę.





Rys2. Na powyższym widać, że najbardziej zjebane metody były gdzieś w tym obszarze.





Rys3. Tutaj podobnie jak w poprzednim punkcie.





Rys4. Podobnie jak przy pierwszym wykresie tak i tutaj widać ogólne uproszczenie w klasach.





Rys5. W tej zaś metryce nie widać żadnego wpływu.


Robić przedwczesne Abstrakcja czy nie robić

Wygląda na to, że to kolejna sytuacja gdzie trzeba użyć mózgu a nie prostych regułek. Do następnego!

niedziela, 28 października 2012

Samoorganizacja a token lidera

Czytając ostatnimi czasy internet zauważyłem rzucane masowo z lewa i prawa słowo "Lider". Konteksty są różne : ktoś napisze w poście o procesie wyłaniania lidera a ktoś inny w radosnym szale przypisze cechy lidera swojej pozycji w organizacji. Ba spotkałem się nawet z nazwaniem mojej skromnej osoby liderem łódzkiego juga (sic ku*wa!). Dlaczego tak bardzo każdy chce być liderem? (a nawet ostatnio zauważyłem, że nie wystarczy być liderem - trzeba być charyzmatycznym liderem)

Ze względu na przeterminowaną hierarchiczną strukturę wielu organizacji ktoś kto ma w nazwie stanowiska słowo "lider" zarabia więcej pieniędzy. Z drugiej strony poprzez to stanowisko możemy sobie zrekompensować przeróżne kompleksy siedzące w nas od czasów młodości. Jeśli jakiś mały nerdzik był szykanowany w podstawówce to teraz czas aby obrócić strukturę i pokazać (bogu ducha winnym) ludziom kto teraz rozdaje karty! No i na pewno żona w domu się ucieszy :

- Nie uwierzysz Zośka, dzisiaj przyszedł dyrektor i powiedział "Stefan - od teraz będziesz liderem".
- Super Stefan ale weź wyrzuć śmieci
- I'M A LIDAAAAAA!
- A i weź pimpka na spacer

W czym lider przeszkadza

Nauczka dla mnie na dziś - notować gdzieś namiary na wszystkie ciekawe badania. Jeszcze zanim postanowiłem dzielić się ze światem swoimi przemyśleniami przy okazji zbierania materiałów do pracy z kategorii "Dlaczego Agile jest zajebisty" natrafiłem na szereg ciekawych badań o tym jak to ludzie gładko przechodzą w tryb pasywności gdy w pobliżu pojawia się inna osoba niezwykle aktywna (w NLP to się zdaje nazywało "narzuceniem" i "przejmowanie ramy"). Zupełnie tak jakby w układzie odizolowanym poziom aktywności pozostał stały. Osobę aktywna popularnie bywa nazywana liderem. Problem polega na tym, że osoba pasywna automatycznie traci możliwość wejścia w niezwykle wartościowy stan hiper-kreatywności i hiper-aktywności - i nie chodzi tu o flow (info dla tych co wiedzą co to je to flow ;)). Temat jest na tyle złożony i fascynujący, że poświęcę mu kiedyś osobny wpis. Na razie musicie mi uwierzyć, że tak jest.

Drugim problemem będzie niedostępność tego lidera. Gdy ktoś już wytycza ścieżkę i nagle gdzieś znika to zespół nie do końca może wiedzieć o co mu chodziło i w którą stronę chciał iść. Z moich obserwacji wnioskuję, że kierunkiem w którym podąży zespół najczęściej jest kierunkiem aneksu kuchennego i rozmów o byle czym. Oczywiście mogą istnieć ludzie, którzy tak dobrze komunikują swoją wizję, że wszyscy wiedzą dokąd zmierzamy - ale ilu jest takich ludzi?

Wczoraj (o ile tylko udało mi się skończyć ten artykuł w niedzielę) miałem dużą, naprawdę dużą przyjemność uczestniczyć na Warsjawie w warsztacie Jeden dzień z trudnym klientem - zwinny projekt w formie gry . W trakcie warsztatów robiliśmy mały projekcik manualny a prowadzący próbowali symulować nieprzyjemne sytuacje życiowe. Udało nam się tak zbudować ramy grupy, że nie wykształciła się konkretna osoba o dominującym wpływie (starałem się dążyć do tego świadomie - nie wiem jak inni). Gdy prowadzący przyszli "zasymulować stratę lidera" wybrali osobę, którą akurat w danym momencie wykazywała najwięcej inicjatywy. Miało to praktycznie zerowy wpływ na naszą pracę!

Brak Lidera

Czy brak lidera będzie więc rozwiązaniem? Istnieje pewien psycholgiczny efekt zwany Rozmyciem odpowiedzialności, który mówi że niebardzo (to wtedy gdy 60 osób patrzy się jak ktoś morduje kobietę i nikt nie dzwoni na policję bo przecież na pewno ktoś inny zadzwowni - zdarzenie wydarzyło się naprawdę!). Z drugiej strony im więcej chłonę wiadomości z zakresu cybernetyki i teorii złożoności tym bardziej wierzę, że ta sytuacja może być opanowana i przynieść wiele wartości.

Jeśli zarówno lider jak i brak lidera mogą być złymi rozwiązaniami to co nam zostało? A gdyby tak każdy był liderem?

Token lidera

Po raz pierwszy na koncepcję "lidera w zależności od sytuacji" natknąłem się czytając o strukturach społecznych plemion jeszcze przed zrodzeniem się "gospodarki rolnej". Wyobraźmy sobie plemię kilku osób (coś jak team agile). Jedna osoba zna się na polowaniu na mamuty a druga umie rozpoznać trujący gatunek grzyba. W trakcie polowania ma to jak największy sens by pierwszy osobnik przejął dowodzenie ale gdy w okół nie ma zwierza to dowodzenie przejmie drugi z wymienionych. Wizja jest jasno określona - chodzi o przetrwanie grupy. (więcej ciekawych rzeczy na : http://en.wikipedia.org/wiki/Tribalism

Podobnie w teamie, jedna osoba może znać się lepiej na projektowaniu rozwiązań wielowątkowych a inna jest dobrze obeznana z zagadnieniami bazodanowymi. I na CH*J ja się pytam musi tu być jakiś lider, który deleguje zadania?Ano jest jedna sytuacja, która to usprawiedliwia - gdy osoba, która powinna sama wyskoczyć o token lidera jest nieśmiałym, nieprzystosowanym społecznie introwertykiem. Ale zamiast łykać środki przeciwbólowe trzeba po prostu przestać napierdalać głową o ścianę - wrócimy do tego dalej w punkcie "Świadoma samoorganizacja".

Poziom lidera - jak się uchronić od złej dynamiki

Powyższe dzieło przedstawia taką niby wizualizacje "zostawania liderem w czasie". Każdy kolor symbolizuje innego członka zespołu. w momencie gdy sytuacja wymaga krytycznego poziomu danej osoby zostaje ona po prostu liderem i każdemu wychodzi to na dobre.
Ten rysunek z kolej pokazuje sytuacje często spotykaną w korporacji - jedna osoba jest mianowana liderem i nie pozwala w krytycznej sytuacji zdobyć tokenu lidera osobie kompetentnej do rozwiązania problemu. Na końcu widać sytuacje, gdzie osoba mianowana faktycznie powinna dostać token lidera ze względu an swój zakres umiejętności ale w tej strukturze nie am to znaczenia.
Na koniec bardzo niebezpieczna sytuacja znana wszystkim jako "wykształcenie się naturalnego lidera". Żeby zrozumieć tę dynamikę trzeba znać koncepcję "pingowania społęcznego" i dopasowywania się do struktur. Tutaj w uproszczeniu przyjmijmy, że dana osoba tak często staje się liderem, że sama wierzy w to, ze jest liderem permanentym. Jeśli cały proces odbędzie się w sposób nieświadomy to tak jak w tej historyjce z małpami - zespół też w to uwierzy i nie będzie kwestionował tego porządku. Nastąpi niekoniecznie najoptymalniejsza stabilizacja teamu (a nawet stagnacja).

Świadoma samoorganizacja

Jak sprawić by zespół optymalnie sam się organizował a introwertycy mieli odwagę podjąć token lidera? To proste. Z czego szkolą się zazwyczaj programiści : Technologie. A czego potrzebują, żeby świadomie pokierować procesem samoorganizacji grupy : Psychologii i Socjologii. EUREKA KU*WA NORMALNIE. Tylko dlaczego jedyne szkolenia z tego zakresu o jakich słyszę to "szkolenia managerskie" dal osób, które już nie prorgamują? No dobra czasem wysyła się informatyków na szkolenia z tzw "umiejętności miękkich" ale to raczej dla wygody ludzi, którzy z tymi informatykami się komunikują.

Ciekawostka

Początkowo chciałem nazwać tę koncepcję "liderem sytuacyjnym" ale okazało się, że ta fraza została już podchwycona ---> http://en.wikipedia.org/wiki/Situational_leadership_theory . Autorem koncepcji według wiki jest ten sam człowiek, który napisał "one minute manager". Książki jeszcze nie czytałem ale z referencji słyszałem, że jest totalnie zjebana i symbolizuje całe zło projektowe z jakim walczą metodyki zwinne. Przeczytam- ocenię. Tymczasem faktycznie w modelu "lidera sytuacyjnego" brakuje poziomu M5 - NIE PRZESZKADZA

Na zakończenie recenzja Warsjawa 2012

Było fajnie, mili ludzie i dobre jedzenie. Do zobaczenia za rok!

piątek, 19 października 2012

JUG Lodz Start-up a prawo

Żyjąc w świecie technologii czasem łatwo zapomnieć jakie prawa rządzą rzeczywistością poza firewallem. Bardzo ciekawa prezentacja.

Start-up a prawo. Paweł Jóźwiak.

niedziela, 14 października 2012

Czym jest HAK?

Haki w kodzie

Wszystkie dzieci wiedzą, że hacki są złe bo zmniejszają jakość kodu ale czy czy ktoś z was zastanawiał się "jaka jest istota haka"? Jak go zdefiniować i po czym rozpoznać, że właśnie zastosowaliśmy hak? W celu uzyskania odpowiedzi wciśnij 5.

Rozpatrywany przypadek (u)życia





Kod poniżej stanowi próbę implementacji wspomnianej specyfikacji. Mamy klasę "Osobą" , która to klasa zawiera pewną narodowość określającą wytrzymałość alkoholową.

 
 public class HAK {
    public static void main(final String[] args) {
        final Osoba polak = new Osoba(POLAK);
        final Osoba rosjanin = new Osoba(ROSJANIN);
        final Osoba anglik = new Osoba(ANGLIK);

        System.out.println("10 promili");
        System.out.println("polak : " + (polak.czyPrzezyje(10) ? "przezyje" : "nie przeżyje"));
        System.out.println("rosjanin: " + (rosjanin.czyPrzezyje(10) ? "przezyje" : "nie przeżyje"));
        System.out.println("anglik : " + (anglik.czyPrzezyje(10) ? "przezyje" : "nie przeżyje"));
    }

    static class Osoba {
        private final Narodowosc narodowosc;

        private Osoba(final Narodowosc narodowosc) {
            this.narodowosc = narodowosc;
        }

        public boolean czyPrzezyje(final int promile) {
            return narodowosc.getLimitAlkoholowy() > promile;
        }
    }

    static enum Narodowosc {
        POLAK(16), ROSJANIN(16), ANGLIK(3);

        private final int limitAlkoholowy;

        private Narodowosc(final int limitAlkoholowy) {
            this.limitAlkoholowy = limitAlkoholowy;
        }

        public int getLimitAlkoholowy() {
            return limitAlkoholowy;
        }

    }
}

Gdy odpalimy program zobaczymy, że ze wspomnianej trójki: Polak,Rosjanin i Anglik - ten ostatni nie powinien przeżyć. Na razie wygląda to nieźle ale co się stanie gdy nasz Anglik postanowi opuścić swą zmąconą kryzysem ojczyznę, przyjąć obywatelstwo naszego pięknego kraju co zaowocuje pojawieniem się w jego obiekcie Narodowości "POLAK"? Program pochopnie uspokoi pijącego co może doprowadzić do tragedii!!! (podobny efekt może się pojawić gdy Rosja podbije Europę Zachodnią)

Czas na hak

Najszybszy hak :
 

 public boolean czyPrzezyje(final int promile) {
            return narodowosc.getLimitAlkoholowy() > promile 
&& nieprawdaZeBylAnglikiem();
        }

Można oczywiście przechować pierwotną narodowość i jej właśnie użyć do znalezienia limitu alkoholowego ale co gdy taka parka angielska przyjmie polskie obywatelstwo i powije dziecko w naszym przecudownym kraju? Jaki limit alkoholowy będzie miał ten potomek? Chyba intuicyjnie czujemy, że taki sam jak rodzice. I teraz pojawia się krytyczny moment a) możemy iść dalej w haki:
 

 public boolean czyPrzezyje(final int promile) {
            return narodowosc.getLimitAlkoholowy() > promile 
&& sprawdzCzyJegoPrzodkowieOdIlusTamPokolenTeżByPrzezyli();
        }

b) Możemy chwilę się zastanowić dlaczego pomimo tego, że specyfikacja nic o tym nie mówiła to historia przodków wpływa na wytrzymałość alkoholową. Powinno nas to doprowadzić do pewnej generalnej reguły, która określi jednoznacznie przypadki, z którymi męczyliśmy się do tej pory

Czas na generalna regułę

 

 public class OgolnaZasada {

    public static void main(final String[] args) {
        final Osoba polak = new Osoba(POLAK);
        final Osoba rosjanin = new Osoba(ROSJANIN);
        final Osoba anglik = new Osoba(ANGLIK);

        System.out.println("10 promili");
        System.out.println("polak : " + (polak.czyPrzezyje(10) ? "przezyje" : "nie przeżyje"));
        System.out.println("rosjanin: " + (rosjanin.czyPrzezyje(10) ? "przezyje" : "nie przeżyje"));
        System.out.println("anglik : " + (anglik.czyPrzezyje(10) ? "przezyje" : "nie przeżyje"));
    }

    static class Osoba {
        private final Genotyp genotyp = Gatunek.budujGenotyp();
        private final Narodowosc narodowosc;

        private Osoba(final Narodowosc narodowosc) {
            this.narodowosc = narodowosc;
        }

        public boolean czyPrzezyje(final int promile) {
            return genotyp.okreslWlasciwosc("WYTRZYMALOSC_ALKOHOLOWA") < promile;
        }

    }

    static class Genotyp {
        private final Map geny;

        public Genotyp(final Map genyInicjalizujące) {
            geny = genyInicjalizujące;
        }

        public int okreslWlasciwosc(final String nazwaWłaściwości) {
            return geny.get(nazwaWłaściwości);
        }
    }

    static class Gatunek {
        public static Genotyp budujGenotyp() {
            final Map geny = new HashMap();
            geny.put("WYTRZYMALOSC_ALKOHOLOWA", obliczOdziedziczonąWytrzymałośćAlkoholową());
            return new Genotyp(geny);
        }

        private static int obliczOdziedziczonąWytrzymałośćAlkoholową() {
            return new Random(currentTimeMillis()).nextInt() % 16;
        }
    }
}

Czas zdefiniować Hak

W świetle podanego przykładu będzie to miejscowe rozwiązanie problemu olewajac generalną zasadę, która być może nie została nawet wykryta. Wszystko się zjebie gdy albo : 1) generalna regułą się zmieni (Anglicy zwiększą odporność alkoholową) lub: 2) Generalna zasada zacznie się manifestować w innych, jeszcze nie zhaczonych miejscach kodu (np. dołożymy Włocha)

Oczywiście rozwiązanie z genami może okazać się hakiem w kontekście jakiejś szerszej reguły