niedziela, 16 grudnia 2012

Trollejdoskop

Lista trolli na które natknąłem się w tym tygodniu w necie + opis skuteczności niektórych antytroli.

Troll - zadajesz złe pytanie


Przykład codzienny :

[użytkownik 1] - "hej, doradźcie którędy najszybciej na morskie oko".
[troll] - " to dziwne, że chcesz jechać nad morskie oko, przecież nad morzem jest cieplej i mają więcej ryb"

[troll - wersja złośliwa] - "to dziwne, że chcesz jechać nad morskie oko, przecież nad morzem jest cieplej i mają więcej ryb. Nie znasz się turystyce i lepiej, żeby ktoś ci zabrał kluczyki od samochodu bo pozabijasz nas wszystkich"

Przykład IT :

[użytkownik 1] - "hej, doradźcie jakąś bibliotekę do XXX".
[troll] - "to dziwne, że chcesz używać podejścia XXX, czy na pewno wiesz co robisz? Ja bym użył YYY"

Opis : bardzo sporadycznie osoba odpowiadająca faktycznie zasugeruje lepsze rozwiązanie ale jednak częściej kieruje się ona niedostatecznymi informacjami. Pytający podaje tylko ograniczony zestaw informacji gdyż potrzebuje jednej małej odpowiedzi na proste pytanie.

Troll - polonista


Przykład codzienny :

[użytkownik 1] - "hej, skończyła mi się wódka i chcę skoczyć do sklepu, doradźcie gdzie jest najkrótsza kolejka.".
[troll] - "Do sklepu się nie skacze a chodzi. Nie wiem czy wiesz ale skakanie to wysoce nieefektywny sposób na dotarcie do sklepu"

[troll - wersja złośliwa] - "Do sklepu się nie skacze a chodzi. Nie wiem czy wiesz ale skakanie to wysoce nieefektywny sposób na dotarcie do sklepu. Ciekawe czy jak odprowadzasz swoje dzieci do szkoły to tez im każesz skakać. takich jak ty powinno się zamknąć!"

Przykład IT :

[użytkownik 1] - "my używamy metodologii XXX".
[troll] - "kolego, metodologia to nauka o metodach. Jeśli tego nie wiesz to chyba najlepiej świadczy o tym jakim 'specem' od XXX jesteś"

Opis : Wszelkie skróty myślowe, uproszczenia czy przejęzyczenia stanowią doskonały element zaczepny dla trolla.

Troll - twoje argumenty wymyślili debile


Przykład codzienny :

[użytkownik 1] - "siema, gdzie najlepiej w samochodzie naprawić XXX?".
[użytkownik 2] - "siema, w 'Mechaniku Niedzielnym' podawali, że najlepiej udać się tu i tu ".
[troll] - "Czytaj dalej tych idiotów każą ci rozebrać samochód. XXX nie może być dobre, nie próbowałem ale to napisali idioci to musi być debilne"

[troll - wersja złośliwa] - "Czytaj dalej tych idiotów każą ci rozebrać samochód. XXX nie może być dobre, nie próbowałem ale to napisali idioci to musi być debilne. Pewnie jesteś tak samo 'inteligentny' jak oni - swój ciągnie do swojego"

Przykład IT :

[użytkownik 1] - "w artykule YZ wyczytałem, że poleca on XXX - sprawdzał to ktoś".
[troll] - "YZ podobnie jak debile z jego otoczenia wypisuję tylko takie głupoty"

Opis : Tutaj troll samo tworzy punkt zaczepny. Standardowa technika - nie mam argumentów ale wiem ,że jesteś głupi. Jeśli tylko da się trzeba zignorować

Troll nuklearny


autentyk!
[użytkownik 2] - "Czasy są trudne, musimy zapomnieć o tym co dzieliło nasze zespoły i postarać się udowodnić, że możemy pracować razem dla lepszych wynikół"
[troll] - "Nie zgadzam się,że to dobre podejście - weźmy na przykład Taki Oświęcim..."

Opis : Użytkownik ma setne sekundy aby użyć neutralizatora trollollolo zanim eksplozja nuklearna dokona definitywnej anihilacji tematu


Antytrole

  • Ignorowanie - możliwe tylko wtedy gdy natura trolla jest dobrze znana na forum i żaden inny użytkownik nie da się sprowokować. Trudne do wykonania gdy troll próbuje ośmieszyć użytkownika technikami z pola erystyki.
  • Apel o nietrolowanie - dodatkowe dokarmienie i doładowanie trolla
  • Trolem w trolla - bardzo niebezpieczne - ryzyko szybkiej eskalacji trolozbrojeń
  • Wujek cięta riposta - jeśli uda się headshot troll może zostać zneutralizowany.
  • Merytoryczne strollowanie trolla - próba przywrócenia głównej wagi wątkowi merytorycznemu - technika w trakcie badań.

niedziela, 9 grudnia 2012

Primitive obsession - czyli skąd biorą się klasy Utils

To jest tak pewne jak to, że po dniu nadchodzi noc a po pijackiej nocy nadchodzi kac - prędzej czy później w większości projektów pojawiają się klasy o znajomo brzmiącej nazwie cosTamUtils. Na osobny artykuł zasługuje wytłumaczenie dlaczego klasy "Utils" psują model obiektowy i dlaczego jest to bardzo niedobry i bardzo bardzo zły antywzorzec.

Jeśli ktoś chce zbadać ten temat to niech się zastanowi lub poszuka na necie informacji o tym czy lepiej stworzyć klasę Money czy też MoneyUtils ( ewentualnie kliknie tutaj : Utils antipattern )

Dla tych którzy wierzą, ze trzeba się pozbyć utilsowego brzemiona (tak to się chyba odmienia) poniższy tekst.

Geneza

Zaczyna się niewinnie od klasy :

 
class User{
   private String phoneNumber;
}

Mija tydzień, ceny paliwa idą w górę a w międzyczasie pojawia się nowe wymaganie aby określić numer kierunkowy.

 
class User{
   private String phoneNumber;

   public Object doSomething(){
       ...
       String directional=resolveDirectional();
       ...
   }

   private String resolveDirectional(){
          doSomethingWith(phoneNumber)
   }
}

Mija kilka miesięcy nadchodzi wiosna, w drogach zaczynają pojawiać się dziury a tymczasem w naszej aplikacji pojawia się pojęcie Biura.

 
class Office{
   private String phoneNumber;

   public Object doSomething(){
       ...
       String directional=resolveDirectional();
       ...
   }

   private String resolveDirectional(){
          doSomethingWith(phoneNumber)
   }
}

I w tym momencie doświadczony programista wzdryga się od obrzydzenia - nastąpiło powtórzenie w kodzie! Trzeba by to gdzieś wynieść ale gdzie? Ani to nie pasuje dla klasy User ani do klasy Office. To może by to gdzieś zawiesić w przestrzeni aby każdy mógł sobie korzystać - taka samotna procedurka pośród obiektów.

[IRONIA]

Niestety okazuje się, że twórcy Javy byli debilami i wymyślili sobie, że każdy koncept musi być wyrażony za pomocą jakiejś klasy. Na całe szczęście jest to słówko static...

[/IRONIA]

Chwytamy się brzytwy i głośne fanfary obwieszczają narodziny klasy PhoneUtils :

 
class abstract PhoneUtils{
   public static String resolveDirectional(phoneNumber){
          doSomethingWith(phoneNumber)
   }
}

Rozwiązanie

Jeden Kod jest wart więcej niz 1000 słów...

 
class User{
   private PhoneNumber phoneNumber;

   public Object doSomething(){
       ...
       DirectionalNumber directionalToUsersPlace=phoneNumber.directional()
       ...
   }
}

W zależności od problemu Można nawet pójść dalej i stworzyć lepszą enkapsulację:

 
class User{
   private PhoneNumber phoneNumber;

   public Object doSomething(){
       ...
       City cityToContact=phoneNumber.toCity()
       ...
   }
}

Obsesja zajętości pamięci

Wczoraj na coderetreat miało miejsce ciekawe zachowanie. Pomimo, że cel ćwiczenia był jasno sprecyzowany (chyba - mam nadzieję, że te wszystkie tłumaczenia i metafory coś dały :) ) - "uczymy się pisać doskonały kod" to jednak kilka grup jasno uzasadniło swój projekt słowami - "to zajmie mniej pamięci". Jeszcze raz głośno i wyraźnie :) Do momentu kiedy ograniczenia sprzętowe staną się problemem - nie są one problemem (i nie, nie będzie ku*wa wtedy za późno aby się o to martwić)

Dodatkowe materiały

niedziela, 2 grudnia 2012

Antywzorzec Obiektowy Manager-Helper

Przy okazji przygotowań do Coderetreat mam po raz chyba już siódmy w życiu to uczucie kiedy wydaje mi się, że w końcu zrozumiałem o co chodzi w programowaniu obiektowym. A jak to ktoś tam mawiał, jeśli coś rozumiesz to powinieneś być w stanie wytłumaczyć to małemu dziecku. No To spróbujmy.

(anty)Wzorzec Manager-Helper

Nie chce mi się znowu wrzucać co, kto, gdzie i kiedy dlatego napiszę jedynie, że kiedyś miałem okazję pracować w projekcie sprowadzającym programowanie obiektowe do następujących kroków :

  1. Stworz klasę CostamManager
  2. Gdy klasa CostamManager zacznie oscylować wokół 8 tys linii zacznij przenosić część kodu do klasy CostamHelper
  3. A jeśli jesteś naprawdę bystry to dodaj jeszcze CostamControler - wiesz, żeby było tak bardziej obiektowo.

Dlaczego wzorzec Manager-Helper to zły pomysł?

Wyjaśnienie dla dzieci

Wyjaśnimy to używając wiernej kopii Feliksa co to wszyscy pisali na fejsie, że wylądował.
Jeśli tak zdekomponujemy Feliksa to możemy mu wymienić niezależnie rączki na bardziej rakietowe, i nóżki na bardziej rakietowe i może główkę na bardziej rakietową.
Tutaj drogie dzieci nie jest tak łatwo wymienić główkę bo będziemy musieli wymienić też i jedną rączkę ( a może nie chcemy!) i kawałek drugiej. I jak teraz Feliks będzie miał część rączki rakietowej a część nierakietowej to się nam posypie. Oj trzeba zmienić wszystko :(
Tak też nie jest dobrze.
I Kontroler tak naprawdę niewiele tu zmienia

Nie dla dzieci

NA koniec polecam jedną z lepszych książek o Obiektówce jakie czytałem : Object thinking

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

niedziela, 7 października 2012

Agile i skany mózgu

Poniżej link do bardzo ciekawego tekstu starającego się interpretować "zwinną rzeczywistość" podpierając się skanami mózgu. Bardzo polecam aby każdy sam przeczytał ten tekst. Znajdziecie w nim pomiedzy innymi takie o to informacje:

http://www.infoq.com/articles/brain-scrum-maza

  • Groźba wydalenia z grupy powoduje takie same reakcje neuronalne jak ostry ból. Ludzie są stworzeni do tego aby pracować w oparciu o kontakty społeczne wewnątrz grupy
  • Bez względu jak wielu domorosłych psychologów będzie swoje wywody na grupach podpierać piramidą Maslova - to jednak nie jest ona do końca poprawna
  • Naturalne motywatory : autonomia oraz uczciwe zasady społeczne (nie jest to wspomniane w przytoczonym tekście ale ten czynnik jest krytyczny. Jednakże aby go zrozumieć potrzebny jest osobny artykuł). Zamiast tego pojawia się nowy model SCARF.
  • Wytwarzanie oprogramowania to nie "seryjna produkcja rzeczy" i tutaj obowiązują inne zasady pracy niż w fabryce.
  • I wiele innych...

niedziela, 30 września 2012

Mobilizacja 2012 jako przykład samoorganizacji

Miłe słowa i podziękowania

Na początek trochę miodu. Jeszcze raz chciałbym podziękować wszystkim, którzy przybyli na konferencję za to, że stali się częścią tego fantastycznego wydarzenia. Wydarzenia, który przynajmniej od strony informatycznej ożywia to trochę senne miasto jakim jest Łódź.

Gdy rok temu Marek Defeciński i Mariusz Saramak rzucili pomysł aby zrobić w naszym mieście konferencję pokroju dawnej Javarsovii wszyscy na około raczej przejawiali nastawienie w stylu - "chyba was pojebało". W trakcie pierwszej edycji zawitało na mobilizację około 150 osób ale to wystarczyło aby ludzie zaczęli wierzyć w powodzenie tego z pozoru szalonego przedsięwzięcia :). Tym razem gościliśmy prawie 500 słuchaczy i możemy śmiało mówić, że mobilizacja jest jednym z największych wydarzeń kulturalnych w Łodzi i jednym z ciekawszych wydarzeń IT w Polsce.

Samoorganizacja

W opisach konferencji w tym miejscu zazwyczaj następuje lista notek z poszczególnych prezentacji. Jednak dziś skupię się na innym fascynującym temacie - samoorganizacji organizatorów w trakcie organizacji konferencji :) Nie było żadnych gantów, żadnych menadżerów, czy rozliczania tasków. Były za to cotygodniowe siedzące stand-upy w makdonaldzie, ciągła i równoprawna dyskusja na grupie oraz grupowe współtworzenie rozproszonych dokumentów na google docs.

O samoorganizacji można pisać i pisać - powstają pewnie także całe książki na ten temat. Dlatego dzisiaj zerknijmy tylko na dwie ciekawe koncepcje.

Variety (Różnorodność)

http://en.wikipedia.org/wiki/Variety_(cybernetics)

Link powyżej koncentruje się co prawda bardziej na stabilności danego systemu aniżeli stanach wyjściowych ale idea generalnie jest taka - traktujemy zespół jako system i im więcej ten system ma stanów tym więcej możliwych wyników generuje. Wynikami w tym przypadku są decyzje i pomysły. Jeśli więc w zespole będziemy mieli tylko absolwentów informatyki około 25 lat, gdzie każdy gra po godzinach w sapera i doczytuje książki o Javie to możemy liczyć na limitowany zestaw stanów.

Z drugiej strony zmieszajmy w tyglu ekstrawertyzm z domieszka introwertyzmu, trochę nieobliczalności z rezerwą oraz doświadczenie ze świeżym spojrzeniem. Dostaniemy całe spektrum pomysłów, z których oczywiście część będzie zjebana ale inne takie jak wojskowa grochówka na obiad, mundury dla załogi czy "kontakt z bazą" spotka się z miłym przyjęciem (przynajmniej tak ludzie mówili :))

Darkness principle

Each element in the system is ignorant of the behavior of the system as a whole [...] If each element ‘knew’ what was happening to the system as a whole, all of the complexity would have to be present in that element

Uwzględniając to prawo zgadzamy się z tym, że gdyby jedna osoba chciała wszystkim zarządzać to musiałaby ogarnąć cały system, ogarnąć cały problem bez żadnych uproszczeń (każde uproszczenie generuje ryzyko pomyłki). Z drugiej strony dzieląc problem na wszystkich uczestników zespołu sprawiamy, że każdy koncentruje się na części modelu co znacznie redukuje złożoność samego problemu.

Logika podpowiada, że potrzebna jest jakaś synchronizacja wysiłków, informacji i sub-domen problemu. Ktoś mógłby napisać, że tutaj pojawia się rola dla kogoś w stylu project managera. Niekoniecznie. Okazało się, że "ciałem zarządzającym złożonością całego problemu" był sam zespół. Spotkania w Maku i wymiana informacji na grupach wystarczyły

Czekając na mobilization 2013

Mobilizacja jest wciąż młodą konferencją i każda pomoc się przyda. Jeśli drogi czytelniku byłeś na konferencji, podobała ci się ona i prowadzisz jakąś formę bloga - podziel się swoją opinią. Do zobaczenia (oby ;)) w 2013

czwartek, 6 września 2012

Filozoficzny model projektu

Metafory i modele

Metafory są zjebane - zwłaszcza wtedy kiedy nie są pomocne. Wystarczy znaleźć jedno malutkie podobieństwo pomiędzy diametralnie różnymi sytuacjami by zacząć dowodzić dowolnej głupoty. Można sobie zrobić z programistów murarzy bo i tu i tam pojawia się słówko "architekt". Albo coś lepszego : projekt to ciąg pewnych decyzji i szachy to ciąg pewnych decyzji - więc w projekcie czasem warto poświęcić "pionki" by chronić króla. Kiedyś chyba zorganizuję nawet konkurs na najbardziej debilną metaforę IT


Co innego modele! Model z założenia nie jest prawdą. Specjalnie wszedłem na wikipedię aby upewnić się, że używam odpowiedniego słowa i odebrać oręż potencjalnym trolom. Mamy taki oto cytat : "system założeń, pojęć i zależności między nimi pozwalający opisać (zamodelować) w przybliżony sposób jakiś aspekt rzeczywistości" . (co prawda inne znaczenie to "wieś w województwie mazowieckim") . Tworząc model wcale nie twierdzę, że coś jest takie a nie inne, nie rzucam dogmatów wyrażających złote prawa prowadzenia projektów ( z cyklu : "jest powszechnie wiadome, że ...") czy też nie udaję, że moje zdolność telepatyczne rozwinęły się na tyle, że mogę ogarnąć psychikę całej populacji ( "wszyscy wiedzą, że ..."). Model jest uproszczeniem. Model nie jest prawdą. Ale może pomóc dostrzec pewne reguły kiedy odfiltrujemy szum.

Dawno dawno temu - podstawy modelu

Filozofia do stworzenia podstaw naszego modelu pochodzi od pana z obrazku obok - owy dziadu to Arystoteles. Zanim jeszcze Grecy przestawili się na biznes turystyczny i każde cięcia budżetowe witali falangą najebanych restauratorów, Arystoteles miał ciekawą myśl :
  • Wszystko jest złożone z tzw. Substancji
  • Substancja jest w ciągłym Ruchu
  • Substancja osiąga kombinacje form posiadających Stan Aktualny i Potencjał
I na przykład weźmy takie drewno jako substancję. Drewno ma pewne potencjalne stany - może być np. stołem albo laską. Ale kiedy już osiągnie stan laski to już wśród jego potencjału nie ma stanu stołu. Jednak dla odmiany Szkło może być lampą lub butelką - i gdy osiągnie jeden ze stanów to teoretycznie drugi z nich jest cały czas dostępny ale będzie to wymagało większego ruchu.

I teraz czas na IT.

  • Wszystko jest złożone z substancji zwanej Kodem
  • Kod jest w ciągłym ruchu powodowanym przez Motywację programistów
  • Kod osiąga kombinację form przynoszących Aktualną Mamonę i Potencjalną Mamonę

Energetyczny graf przejścia stanów

Wspomniana MAMONA będzie formą energii jakiej użyjemy do umotywowania ruchu po grafie stanów projektu. Jednostka mamony to $

Zaczynamy nasz projekt w węźle 1 i założenie jest takie, że im większy węzeł tym większa wartość aktualnej Mamony . Jeśli skupimy się tylko na tym czynniku to idziemy do dwójki i mamy więcej aktualnej mamony niż w trójce. Ale teraz pojawia się problem bo z dwójki możemy już iść tylko do szóstki czyli potencjalna Mamony już tak atrakcyjnie nie wygląda. Najlepiej byłoby trafić do 6 i "nabrać" sporo aktualnej mamony.

Owe tajemnicze strzałki na grafie symbolizują sumę decyzji o architekturze, funkcjonalności, morale teamu i jakości papieru toaletowego czyli wszelakie moce sprawcze, które sprawiają, że projekt jest w takim a nie innym stanie. No i czasem zdarza się tak, że nasza substancja czyli KOD tak sprawnie porusza się po grafie i zmienia stan tak umiejętnie, że projekt osiąga najwartościowszy węzeł.

Pomyślmy co takiego dokładnie powoduje Ruch? No niby napisałem, że motywacja developerów ale i ta wielkość jest wynikiem działania różnych czynników : pieniądze, pizza, uznanie,szacunek, karabin maszynowy MG 42. Czas ubrać to w odpowiednie abstrakcje.

Dwie mityczne siły

Wyobraźmy sobie, że na naszą substancję działają dwie niesamowite siły.


SIŁA AKTUALNOŚCI

Ta siła ciągnie do jak najszybszej przemiany mamony w wartość aktualną.

Niebezpieczeństwo : zamykamy przed sobą bardzo zyskowne stany aplikacji.

Przykład : "Teraz zakodujmy jak najwięcej, będzie sukces to testy dopiszemy później"

SIŁA POTENCJAŁU

Ta siła ciągnie do osiągnięcia jak największej liczby możliwych przemian stanu

Niebezpieczeństwo : Nie osiągamy wartości aktualnej.

Przykład : "Zróbmy piętnaście warstw abstrakcji tak na wypadek gdyby w przyszłości ktoś miał podłączyć się pegasusem do naszej aplikacji"

Lepszy Przykład : "ej przepiszmy wszystko na Grailsy"

Przemyślenia jakie powstają po analizie tych dwóch przykładów, mogą doprowadzić do wniosku, że owe dwie siły muszą jakoś sobie przeciwdziałać, tak aby docelowo doprowadzić projekt do najlepszego stanu.

To dlaczego się ku*wa nie udaje?

Asymetria sił - czyli dlaczego projekty się nie udają

To był upalny czerwcowy dzień. Roman podjechał swoim najnowszym Audi A6 na zarezerwowane miejsce parkingowe. W głębi duszy cieszył się, że zajmuje pozycje jaką zajmuje. Inaczej musiałby krążyć po okolicznych trawnikach i kamienicach w poszukiwania pustego skrawka dla swojego samochodu. Rozejrzał się dookoła przyciskając guzik automatycznego pilota. Jego wzrok raz za razem przeskakiwał z opuszczających najnowsze modele sportowych samochodów sylwetek ludzi. Każdy z nich był w pewien sposób podobny do Romana. To oni stanowili o sile tej firmy, to oni każdego dnia zamieniali dzięki swym niezwykłym umiejętnościom idee w zyski, to oni cieszyli się niesamowitym szacunkiem za swoje dokonania. Podobnie jak Roman - wszyscy byli Inżynierami.

Roman nie mógł się doczekać aż zasiądzie do klawiatury i zakończy kolejny fascynujący moduł systemu. Jeszcze pozostała mu tylko jedna sprawa do załatwienia. Musi przygotować dzisiejsze zadania dla project managerów. W głębi serca Roman czuł wielką sympatię do tych ludzi, gdyby nie oni musiałby spędzać cenne godziny swojego czasu na dopracowywaniu detali projektowych. Współczucie pogłębiła jeszcze myśl, że ludzie ci nie cieszyli się takim statusem jak Roman - jak ich nazywał HR? - chyba "zasobami" czy coś takiego. Cóż każdy musi jakoś zacząć, jeśli będą się starać i wykażą umiejętność analitycznego myślenia - być może wtedy będą mogli pokusić się o awans na stanowisko inżyniera i kto wie - może kiedyś będą mieli swoje miejsce na parkingu...

Asymetria sił - czyli dlaczego projekty się nie udają - powrót do rzeczywistości

Powyższe akapity wydają się fantastyką? Być może gdyby ewolucja poszła innymi drogami tak by wyglądał nasz świat ale jednak (podobno) kiedyś biegaliśmy po drzewach i jedliśmy banany. Przez eony ewoluowaliśmy w otoczce struktury hierarchicznej aż parenaście tysięcy lat temu modne stało się "okazywanie" braku potrzeby pracy (Teoria klasy próżniaczej). Nic dziwnego, że wydaje nam się że "tak po prostu jest".

A co gdyby jednak obydwie siły z naszego modelu współpracowały? Co gdyby wzorzec "Command-and-control" zastąpić wzorcem "wzajemne zaufanie i szacunek"? Czy tak trudno wyobrazić sobie, że synergia (bardzo ładne słowo) warstwy technicznej i biznesowej może nas doprowadzić do osiągnięcia wymarzonego stanu ogromnej mamony? Wiele osób bez mrugnięcia okiem podkreśla jak to programiści nie radzą sobie "biznesowo" ale ze względu na istniejącą asymetrię niewiele osób ma odwagę krzyknąć, że tzw "biznes" nie ma pojęcia (takiego prawdziwego pojęcia) o tworzeniu systemów informatycznych! Jeśli czyta to programista to wiedz, że twoją rolą jest obrona jakości technicznej projektu. Ludzie, którzy zostali sztucznie postawieni ponad tobą w hierarchii firmowej najczęściej (bo nie zawsze) nie mieli okazji nabyć odpowiedniej wiedzy aby się tym zająć. Umiesz liczyć - licz na siebie i zespół. No i żeby nie było niejasności. Wszystkie te zdania i słowa wyobraź sobie w kontekście jak najbardziej szczerej współpracy.

Współpraca - bardzo ładne słowo - ale czy istnieją jakieś prawa i zasady tej współpracy? Za rogiem czai się bardzo ciekawy temat, coś czego jeszcze chyba nie było. Ostatnie lata minęły (przynajmniej dla mnie) pod znakiem pojedynku Agile vs. Wodospad. Wodospad jest dobry dla procesów w fabryce drobiu zaś Agile sprawdza się najlepiej dla grupy doświadczonych developerów z 30 letnim stażem. Czy jest trzecia droga? Niech to będzie przedsmakiem : http://en.wikipedia.org/wiki/Complex_adaptive_system

A ponieważ nie znalazłem fajnego obrazka przedstawiającego wizualizację koncepcji teorii systemów dlatego na koniec wklejam zdjęcie kota popierdalającego przez galaktykę na keybordzie.

niedziela, 19 sierpnia 2012

Syndrom wesołego Cześka

Ktoś inny posprząta nasze gówno

Nie tak dawno temu kamera jednej z telewizji uchwyciła uroczą rozmowę dwóch polityków. Słowo w słowo jej nie pamiętam - na necie też znaleźć nie mogę ale sens był mniej więcej taki :

- Teraz trochę tutaj pożyczymy, trochę tutaj damy i będzie spokój
- no ale z czego to oddamy?
- a o to już będą się martwić w następnej kadencji

Cytowanie polityków z imienia i nazwiska jest bardzo ryzykowne dlatego też nadajmy naszemu politykowi pseudonim : "Czesław". Otóż Czesław myśli w bardzo cwany sposób : my zaciągniemy dług i z nami ludzie będą kojarzyć poprawę, a ktoś inny będzie to spłacać i z tym kimś innym biedne społeczeństwo zwiąże negatywne uczucia.

Teraz. Ten akapit powinien stanowić jakieś eleganckie przejście od polityki do informatyki - dlatego tez teraz elegancko przechodzimy od polityki do informatyki

Wesoły Czesław w projektach IT

Z pamiętnika informatyka :

  1. Zaczyna się projekt. Nawet jeśli jest to najbardziej hardkorowy wodospad to on też ma jakąś tam iterację
  2. W trakcie tej pierwszej iteracji developer - nazwijmy go Czesiek - napierdala całkiem szybko działający kawałek funkcjonalność
  3. Decydenci są wniebowzięci bo oto powstał pewien "produkt" ciągnący za sobą potencjalne zyski - Czesiek zdobywa plusy w oczach managementu
  4. To czego nie wiedzą ludzie w garniturach to to, że Czesiu napisał ten kod kosztem wszelkich reguł czytelności - masę zagnieżdżonych pętli, ogromne klasy i inne cuda na kiju. Ci biedni ludzie tego nie rozumieją - działa? No działa!
  5. Projekt trzeba rozbudować - niech zajmie się tym jakiś junior developer, utrzymaniowieć czy coś w tym stylu - Czesiek jest za dobry - potrzebujemy go do naszych "miszyn kritikal."
  6. I teraz biedny zamiennik siada do tego gówna i płacze i próbuje coś napisać i męczy się i trwa to długo
  7. I taki kierownik budowy sobie myśli " no tak jak przewidywałem - Czesiu jest zajebisty a ci to nawet nie umieją jednej rzeczy sprawnie dopisać. Ehhh trzeba znowu zadzwonić do Cześka"
  8. Wróć do punktu pierwszego

Licznik długu technicznego

Dług techniczny to bardzo ciekawe pojęcie - pełni role mostu porozumienia pomiędzy abstrakcją biznesową i techniczną. Generalnie już jest w powszechnym rozumieniu fakt, że dług techniczny jest zły, że spowalnia prace, że trzeba go spłacać - ale przynajmniej w moim przekonaniu mało kto dokładnie rozumie skąd ów dług się bierze.

Dzisiaj ograniczymy się tylko do stwierdzenia faktu, że w naszym przykładzie generatorem długu technicznego jest Czesiu a niebezpieczna gra, którą prowadzi sprawia, że widzowi trudno jest odróżnić kto jest czarnym a kto białym(?) charakterem tej historyjki. Skoro nie widz to kto ma powstrzymać Czesia? Jedyne co przychodzi mi do głowy to zespół developerów, którzy operując pojęciem długu technicznego otworzą komu trzeba oczy na rozlewające się po projekcie gówno.

poniedziałek, 23 lipca 2012

Warunkowanie społeczne - poznaj swojego największego wroga

Materiał, który przedstawię w tym odcinku jest dla mnie wyjątkowy a to dlatego, że każdy ma w życiu takie momenty kiedy pewne puzzle w jego głowie łączą się w całość powodują radosny okrzyk "Eureka!!!" albo "o kurwa ja pierdole! trzy dekady ?! potrzebowałem na to trzy dekady?!". Oto synteza niesamowicie ciekawej teorii z pogranicza ewolucyjnej teorii grupy oraz psychologii indywidualnej. Zrozumienie tego materiału może być ważnym krokiem w kierunku osiągnięcia "lepszej wersji siebie" (dotyczy też informatyków bo to w końcu blog informatyczny).

Misie i wilki

Żeby zrozumieć jak działa warunkowanie społeczne musimy najpierw zrozumieć po co zwierzęta łączą się w grupy, jak działają grupy i dlaczego niektóre osobniki pomimo tego, że mają przejebane to nadal zostają w grupie. Na obrazku obok siedzi sobie miś. Misie to bardzo aspołeczne zwierzęta. Rzadko kiedy można je spotkać w jakiejkolwiek grupie i generalnie mają wszystko w dupie. Jak są głodne to skoczą na rybkę czy odrobinę miodu do czego pomocy innych misi (misiów?) nie potrzebują. A jak już im się odechce to walą w kimę na kilka miesięcy.

A teraz zerknijmy na inne zwierzątko, które stwierdziło, że zamiast rybek woli zjeść sobie jakiś większy kawał mięcha. Poza innymi gustami kulinarnymi wilki od misia różni także struktura społeczna, którą tworzą aby owe mięcho upolować. I bynajmniej nie jest to demokratyczna utopia : Watahą dowodzi najsilniejsza para, która jako jedyna ma prawo się rozmnażać. Resztę watahy tworzą zwykle osobniki z nimi spokrewnione. Każdy wilk w stadzie ma ściśle określone miejsce, wyznaczające m.in. kolejność jedzenia zdobyczy. Zależności te podkreślane są przez rozbudowany system gestów dominacji (m.in. podniesiony ogon i uszy) i poddaństwa (np. skulony ogon, kładzenie się na grzbiecie). Poza hierarchią znajdują się młode, którymi opiekuje się cała wataha. Młode samce po osiągnięciu dojrzałości czasem są przepędzane przez parę alfa, by nie zagrażały ich dominacji. W społeczności wilków każdy z nich pełni określoną funkcję. W związku z tym możemy wyróżnić specjalistów od węszenia niebezpieczeństwa, szukania tropów, zabijania łupu, chronienia dzieci pary alfa, przedniej straży na polowaniu. Od wymierzania kar jest zastępca przywódcy. Nie jest on lubiany przez pozostałe wilki, w związku z czym nigdy nie zostaje samcem alfa. Wymierzanie kar odbywa się zawsze w sposób symboliczny. Wilk-zastępca otwiera szeroko pysk, w który wkłada swoją głowę winowajca.

I teraz najważniejsze - wilki nie mają jakiegoś wilczego spisanego kodeksu prawnego. Nie ma przepisów, nakazów czy zakazów. Wilki nie rozwinęły myślenia abstrakcyjnego, nie umieją używać narzędzi czy tworzyć zaawansowane planów. Słowo, klucz do zrozumienia praw rządzących stadem wilków to - instynkt., który bardziej fachowo możemy nazwać reakcjami nieświadomymi. Co powoduje, że inne wilki pozwalają się wykorzystywać przez główną parę w stadzie?

Teoria ewolucji, samolubne geny...

Selekcja naturalna,selekcja seksualna, pola morfogenetyczne i wiele innych Zjawisk. Nie sposób w skrócie wypisać wszystkich koncepcji jakie poprzez miliony lat i tysiące pokoleń wpłynęły na zachowania gatunków. Dla zainteresowanych lektura jest dostępna w necie a na potrzeby tego artykułu przyjmijmy opisany wyżej podział za fakt.

Szympansy i ludzie

Przeskoczmy teraz od wilków do zwierząt od których (podobno) wyewoluowaliśmy. Szympansy mają jeszcze bardziej skomplikowaną (i niesprawiedliwą) strukturę społeczną niż wilki. O szczegółach jak to samce i samice wszystko ustalają możecie poczytać sobie w necie natomiast tutaj skupmy się na innym ciekawym problemie. Skąd dany szympans wie jaką zajmuje pozycję w stadzie?

Ten akapit jest najważniejszy

Żeby to zrozumieć przyjmijmy, że istnieje wielkość zwana "wpływem", który może np. charakteryzować jako ogólną sprawność fizyczną i zdolność do zdobycia pożywienia. Przyjmijmy teraz, że mamy stado szympansów

  1. Najsilniejszy szympans 10 jednostek wpływu
  2. szympans 2 - 8 jednostek wpływu
  3. szympans 3 - 7 jednostek wpływu
  4. szympans 4 - 5 jednostek wpływu
  5. szympans 5 - 3 jednostek wpływu
  6. szympans 5 - 2 jednostek wpływu
Teoretycznie każdy z szympansów nie ma szans w starciu z szympansem nr1, ale jeśli szympansy 2 i 3 ustanowią sojusz to łatwo mogą "zdetronizować" pierwszego. dlatego też pierwszemu opłaca się zawrzeć sojusz z drugim albo trzecim (albo obydwoma) i w ten sposób zapewnić wspólny wpływ np. 10+8=18 jednostek. Jest to wystarczające aby przeciwstawić się reszcie szympansów o wpływie 7+5+3+2=17. Nawet jeśli szympansów o mniejszej sile byłoby więcej to wystarczyłoby kontrolować (rozbijać) tworzenie się pomniejszych sojuszy. Słabszym szympansom opłaca się mimo wszystko pozostawać w stadzie gdyż w ten sposób mają przynajmniej jako taką szansę przeżycia.

Ale ale ale. Powyższe obliczenie jest zawiłe same w sobie dla niejednego człowieka więc jak to ma działać w przypadku małp? Zarówno my jak i nas dalsi kuzyni możemy przetworzyć świadomie ograniczoną ilość informacji . Co innego nasz umysł podświadomy - tutaj mamy potężną maszynkę obliczeniową - maszynkę, która przesyła umysłowi świadomemu rozkazy w postaci uczuć. I np. Jak taki szympans o małym statusie będzie np. chciał wyrwać więcej jedzenia to u silniejszych małp pojawi się uczucie agresji zaś jeśli pojawi się sytuacja odwrotna to u małpy z "mniejszą wartością" pojawi się uczucie strachu, które być może uratuje jej życie.( w sensie nie wyjebią jej ze stada lub nie zrzucą z dębu)

Warto przetrwać jeszcze z jednego powodu. Z czasem dynamika grupy może się zmieniać. Pierwsza małpa zostanie pożarta przez tygrysa, a może 4 małpa zdobędzie nową umiejętność lub zasób, które dodadzą jej jednostek wartości? I najciekawszy przypadek - w stadzie pojawią się nowe osobniki, które będąc nieustannie gnębione poprzez inne małpy z dołu hierarchii pozwolą tym ostatnim przesunąć się względnie w górę drabiny społecznej.

Po tych wszystkich zoologicznych rozważaniach pora w końcu odnieść cały ten opis do naszego życia codziennego.

Kapitalizm, produkty , frustracja i ciągła pogoń za wartością

Rewolucja przemysłowa trochę przetasowała zasady. Mamy technologie pozwalające nam podróżować w miejsca, o których ludziom się nie śniło (chociaż narzekamy na ceny). Mamy opiekę medyczną, której kiedyś nie mieli królowie (chociaż narzekamy na ceny). Mamy bezpieczne schronienia i nie musimy się martwić o jedzenie (chociaż narzekamy na ceny). Co prawda stare mechanizmy stadne i walka nadal zdają się funkcjonować w polityce i na wysokich stanowiskach korporacyjnych ale to temat na inny artykuł.

W tle tych przemian pojawił się inny problem. Jak tak wszystko dookoła jest coraz lepsze to jak zmusić ludzi do kupowania coraz to nowszych produktów?

Z pomocą naszym przyjaciołom z marketingu przychodzi opisany wcześniej mechanizm warunkowania społecznego.

  1. Kup nasz produkt i zyskaj "wartość" (poczuj się lepiej)
  2. Jeśli nie kupisz naszego produktu stracisz na wartości (poczujesz się gorzej)
Oczywiście nasz "szympans numer 1" został dawno odstrzelony a jego miejsce zajął miraż stworzony przez przemysł marketingowo-rozrywkowy. Niedościgniony horyzont oczekiwań przesuwany przez coraz to nowsze i "lepsze" produkty. Powoduje to epidemię "uczucia wycofania", apatii i strachu podobnie jak u naszych szympansów, które "czuły", że nie mają wystarczającej wartości aby "sięgnąć po więcej".

Mechanizm działa następująco :
CZŁOWIECZEK -----PING : CZY MOGĘ CZUĆ SIĘ DOBRZE----> SPOŁECZEŃSTWO (MIRAŻ)
CZŁOWIECZEK <----- NIE MASZ STATUSU/ POTRZEBUJESZ PRODUKTÓW -- SPOŁECZEŃSTWO (MIRAŻ)

Można jeszcze inaczej


CZŁOWIECZEK -----WARTOŚĆ WYTWORZONA PRZEZ PASJĘ----> SPOŁECZEŃSTWO
CZŁOWIECZEK <-----WARTOŚĆ WYTWORZONA PRZEZ TECHNOLOGIĘ---- SPOŁECZEŃSTWO
Każdy wybierze to co mu pasuje bardziej. Generalnie druga wersja generuje więcej lepszych programistów i sprawia, że pracuje się znacznie przyjemniej i wydajniej (bo to w końcu blog programistyczny to po tym całym pierdoleniu o zwierzętach coś napomknąć wypada)
I na koniec bardzo mądre słowa od ciekawego człowieka, który powinien wszystko wytłumaczyć znacznie lepiej niż ja :

niedziela, 8 lipca 2012

Bazodanowy model hipotezy insulinowej

Poniższy tekst zawiera masę uproszczeń oraz niedopowiedzeń i ma na celu jedynie zainteresować Cię ważnymi tematami prozdrowotnymi. Jeśli (mam nadzieję) kogoś zaciekawi wspomniane zagadnienie to powinien udać się do literatury fachowej po bardziej dogłębną wiedzę.

Po co się przejmować

Seria pytań retorycznych

  • Czy jakość sprzętu wpływa na jakość oprogramowania, który na nim działa?
  • Czy gdyby nagle pozmieniały się statystyki elementów elektronicznych komputera to bez względu na doskonałość napisanego programu zacząłby on działać niepoprawnie?
  • Jeśli zaczniemy dostarczać do kompa coraz mniej energii to prędzej czy później wszystko zacznie się jebać?
  • Wiedząc, że odpowiedź na powyższe pytania jest twierdząca odpowiedz sobie na pytanie dlaczego nie szanujesz swojego "hardware" (oraz "swojego sprzętu")

Zacznijmy od otyłości. Bez problemu możesz wpisać w googlach frazy podobne do "wpływ otyłości na umysł" by znaleźć masę artykułów i badań opisujących jak niekorzystnie ten stan organizmu wpływa na umysł - mniejszy mózg i szybsza utrata oraz starzenie tego organu to tylko jeden z wielu skutków. I chociaż widzę, że wiele osób stara się coś z tym zrobić poprzez (niestety często nieregularne) ćwiczenia fizyczne to jednak nieznajomość (wcale nie elementarnych) zjawisk w naszym organizmie prowadzi do tego , że więcej ćwiczeń fizycznych może prowadzić do większego magazynowania tłuszczu!

Ale zacznijmy od początku

Blokada na odczyt

wyobraźmy sobie, że stworzyliśmy system charakteryzujący się następującym działaniem:
  • Program magazynuje słowa w bazie danych
  • Aby program mógł działać musi wykorzystać część zmagazynowanych słów albo ulegnie anihilacji
  • Ilość słów, która musi zostać zużyta jest wprost proporcjonalna do ilość już zmagazynowanej
  • Gdy zaczyna brakować słów do wykorzystania to wtedy nasz program zaczyna pochłaniać wszelki tekst w zasięgu wzroku :)
  • I najważniejsze! - podstawą działania programu są dwie transakcje : odczytująca i zapisująca, gdzie zapisująca ma prawo wywłaszczyć odczytującą

Prześledźmy przykładowe działanie programu

  1. Dostarczamy do naszej aplikacji 100 słów , transakcja zapisująca dostaje blokadę na bazie danych i zaczyna wprowadzać słowa co zajmuje pewien czas T1
  2. W tym czasie nie możemy niczego odczytać a program nadal musi "jeść" słowa
  3. Do modułu wprowadzania wysyłane są sygnały o "braku" słów co zmusza go do "połykania" kolejnych słów z otoczenia
  4. Ilość słów w bazie danych rośnie co sprawia, że nasz program musi wykorzystać coraz więcej słów do swojego działania ale jeśli działa transakcja odczytująca to nie możemy korzystać z już z gromadzonych słów
  5. Sytuacja się powtarza cyklicznie aż baza danych nie jest w stanie pomieścić ogromnej ilości słów i rozpierdala się od wewnątrz
Powyższy przykład jest bardzo uproszczony i być może wykorzystuje zbyt dużą abstrakcję do zbudowania metafory gdyż sytuacja w naszym organizmie wygląda trochę (bardzo) inaczej. W przeciwnym przypadku nie przeżyli byśmy nawet jednego dnia. Z drugiej strony poprzez złe odżywianie wszystko może się zjebać. Zaraz wszystko się wyjaśni.

Transakcja w naszym organizmie - Insulina i Glukagon

System transakcyjny w naszym organizmie (ponownie w dużym uproszczeniu) wygląda następująco :

  • Insulina - zapis do bazy
  • Glukagon - odczyt z bazy

Ten mechanizm powstał na bazie wielu milionów lat ewolucji i w kontekście życia jaskiniowca wygląda zajebiście. Według teorii kiedyś ludzkie życie było przeplatającymi się okresami głodu i ucztowania. Gdy więc brakowało jedzenia organizm pobierał energię z tkanki tłuszczowej i do dzieła ruszał Glukagon a jak upolowaliśmy mamuta to magazynowaliśmy tłuszcz (ale nie tylko!) przy pomocy Insuliny. System wydaje się być pełen harmonii, rozsądku i zdrowego pragmatyzmy.

Później przyszedł kapitalizm i ludzie sami sobie zhakowali ten system

Blokada do zapisu

Są dwie sytuacje kiedy Insulina wywłaszczy Glukagon i uzyska wyłączność do zapisu

  1. Skok poziomu cukru we krwi
  2. Insulinoodporność - co jest powiązane z pkt 1
Co do cukru we krwi to kiedyś jedynym źródłem węglowodanów prostych o wysokim indeksie glikemicznym (do tego nie zawsze dostępnym) był miód (z owocami sytuacja jest bardziej skomplikowana). Obecnie do wielu produktów dodawane są różnego rodzaju cukry,słodziki i inne gówna co powoduje nagłe skoki insuliny. I podobnie jak z przykładem naszej aplikacji zobaczmy co się dzieje :
  1. wpierdalamy cukiereczki (do tej aktywności ewolucyjnie nie jesteśmy przygotowani)
  2. insulina skacze i blokuje odczyt tłuszczu z komórek
  3. wpierdalamy cały czas cukiereczki i zapijamy kolą
  4. insulina wpycha tłuszcz do komórek ale organizm potrzebuje cały czas energii
  5. Ponieważ zmagazynowany tłuszcz jest niedostępny to organizm wysyła kolejne sygnały "chce kurwa jeść!".
Innym znanym przykładem działania tego mechanizmu jest pojawienie się po piwkowej gastro-fazy, gdyż jeśli spojrzymy sobie w dostępne na necie tabele to zobaczymy, że piwo ma jeden z wyższych indeksów glikemicznych. (Jednocześnie ogólny wpływ alkoholu na metabolizm organizmu jest zagwozdką samą w sobie).

W przypadku tego punktu wystarczy pilnować się z tym aby węglowodany proste jeść rano lub po wysiłku fizycznym. A to dlatego, że jest jeszcze jedno źródło, w które organizm będzie upychał rezerwy energetyczne w pierwszej kolejności - glikogen. Jeden jest w mięśniach a inny w żołądku. Z samego rańca jego rezerwy są wyczerpany i to jest dobry moment żeby zjeść sobie jakąś czekoladę czy banana. Później wszystko pójdzie w oponkę.

Groźniejszą sytuacją jest wspomniana w punkcie drugim insulinoodporność

Blokada totalna

Tutaj jedyną przewidywalna zależność można określić następująco : Im więcej insulina działa na komórki tym bardziej komórki uodparniają się na działanie insuliny . Kiedy uodpornią się całkowicie to mamy do czynienia z cukrzycą typu 2. Ale zanim ten czarny scenariusz stanie się faktem mogą dziać się dwie interesujące rzeczy

  1. Komórki wątroby uodparniają się szybciej niż reszta organizmu przez co generują więcej cukru co wyzwala większe wyrzuty insuliny. Pozostałe komórki organizmu w tym czasie są zablokowane i magazynują tłuszcz - tyjemy
  2. Komórki wątroby uodporniają się w tym samym tempie co reszta organizmu. Dana osoba jest "szczęściarzem", który może jeść i nie tyje - ale reszta konsekwencji zdrowotnych jak wysokie ciśnienie czy choroby serca jest obecna.

(Istnieje teoria mówiąca, że odpowiednio przyjmowany alkohol może obniżyć insulinoodporność)

Podsumowanie uproszczonego wywodu

Jak już wspominałem na samym początku - tekst ten obrazuje moje rozumienie tematu i ze względów pojemnościowych jest uproszczony. To co chciałbym aby zapadło wszystkim w pamięć po jego przeczytaniu to świadomość potrzeby dbania o jakość swojego "hardware" (i sprzętu), co jest wyzwaniem samym w sobie biorąc pod uwagę, że większość ludzi (nie tylko programistów) ma poważne problemy emocjonalne dnia codziennego, które stawia na pierwszym miejscu.

Po drugie nie należy do tekstu podchodzić jako do 'pochwały fizyczności szczupłej sylwetki' i należy wypierdalać z tekstami i myślami w stylu "ale ja akceptuje siebie takim jakim jestem i chuj". Jak będziecie za kilka lat (odpukać“) wprowadzali insulinę strzykawką w żyły to mało kogo będzie obchodzić wasza samoakceptacja

No i najważniejsza uwaga - na necie są badania potwierdzające, że mózg osób otyłych działa gorzej niż szczupłych jednakże w tle pojawiają się kontrowersje wynikające z tego, iż nie wiadomo co w tym przypadku jest jajkiem a co kurą.

PS. Oczywiście insulina to jeden z wielu elementów misternej układanki naszych organizmów. Jeśli np. będziemy niewiele jeść ale żyć w ciągłym stresie to też przytyjemy poprzez działanie kortyzolu ale tutaj już trzeba osiągnąć stand słodkiej nirvany mienia wszystkiego w dupie.

wtorek, 26 czerwca 2012

Organizacja Matcherów w testach

Bardzo krótkie wprowadzenie

Do niedawna sądziłem, że pojęcie "matchera" jest wszystkim znane ale przy okazji niedawnej prezentacji o testach mutacyjnych na naszym kochanym łódzkim JUGu okazało się, że część osób ta wiedza ominęła. W skrócie: standardowo w Junit można było napisać coś takiego :

assertEquals(resultDomainObject.getProstawaratosc1,prostawartosc)
assertEquals(resultDomainObject.getProstawaratosc2,prostawartosc)
assertEquals(resultDomainObject.getProstawaratosc3,prostawartosc)
assertEquals(resultDomainObject.getProstawaratosc4,prostawartosc)


Dzięki matcherom możemy przygotować sobie mechanizm do ładnego i zrozumiałego przedstawiania asercji.

assertThatIn(resultDomainObject).thereIsExpectedState().andSomeSomethingElseFulFillsCondition(condition)


Do wyboru z tego co wiem mamy dwie biblioteki:

Organizacja matcherów, która się nie sprawdziła

Początkowo wrzucaliśmy matchery obok testów co okazało się katastrofalnym pomysłem, gdyż nie dość, iż niejednokrotnie pisaliśmy te same matchery po dwa razy to tak naprawdę trudno było kontrolować co już zostało napisane a co jeszcze czeka na wyrzeźbienie.


Wyglądało to tak:
  • paczka1
    • test11
    • test12
    • matcher1
  • paczka2
    • test21
    • test22
    • matcher2


Organizacja matcherów, która może się sprawdzić

Zamiast doklejać matchery do testów dajmy im ich własne pakiety ładnie poukładane według funkcjonalności.
  • testy
    • paczkatestow1
    • paczkatestow2
    • paczkatestow3
  • matchery
    • funkcjonalnosc1
      • konkretnyMatcher1
        konkretnyMatcher2
    • funkcjonalnosc2
      • konkretnyMatcher3
        konkretnyMatcher4
    • Wspolne cegielki
      • cegielkaMatcher1
        cegielkaMatcher2
Na poniższym rysunku widzimy, że dana funkcjonalności ma swój własny i niepowtarzalny matcher, który jest zbudowany na bazie wspólnych, cegiełkowych matcherów :



Czy to dobre rozwiązanie? Czas pokaże.

Konkretny przykład

Poniższy rysunek przedstawia konkretną organizację matcherów w paczkach:



Wykorzystanie matchera wyższego poziomu w teście wygląda tak :

 

 assertThatOnBillingPageRepresentedBy(resultPage).inFirstRow().hasValue("NLD").inCountryCell();



Zaś zastosowanie matchera cegiełkowego do sprawdzania wartości w komórce tabeli wygląda tak: :

 

  assertThatInTableRowHtml(choosenRow).inCellNumber(CELL_NUMBER_OF_CITY).hasValue(expectedValueInCell);



I na końcu jest standard z FESTa :

 

 assertThat(cellText).isEqualTo(value);

poniedziałek, 11 czerwca 2012

W stronę żywej specyfikacji

Czytałem kiedyś bajkę o tym jak to Product Owner tworzy w notatniku wymagania prezentowane przez kilka linijek tekstu, później programiści tworzą z tego testy funkcjonalne i żyli długo oraz szczęśliwie. Bajka nazywała się "Agile coś tam" i miała niewiele obrazków.

Chociaż w głębi duszy wierzę, że wspomniana współpraca, harmonia i trendy słowo : "synergia", są teoretycznie możliwe pomiędzy tzw. "IT" i tzw. "Biznesem", to jednak w praktyce na chwilę obecną ograniczamy się głównie do aktywności ze strony zespołu programistycznego.

Tumbler

Krótko i na temat. Tumbler (tumbler home) pozwala zrobić coś takiego :




(Jeśli ktoś nie wie skąd się wzięły adnotację ---> Behavior Driven Development)

Później generujemy ładny raport :


I nawet to jako tako jest to użyteczne dopóki mamy mało "user stories". Gdy liczba scenariuszy zaczęła zbliżać się do 1500 zauważyliśmy, że już mało komu chce się to czytać.

Tumbler + Maven

W trakcie jednej z prezentacji na GeeCONie, prowadzący ją koleżka wyłożył proste acz idealne rozwiązanie tego problemu

- Jeśli testów jednostkowych nie trzymasz w jednym module to dlaczego masz robić inaczej z testami funkcjonalnymi?

I tak oto rozbijamy sobie projekt, który pełnił rolę worka testowego, na głównego POMa i podmoduły reprezentujące konkretne ficzery:



Teraz zostaje nam już tylko odpalić mvn clean test (czasem trzeba dać install na commonie) i w każdym pod module pojawi się ładny mini raport.

I już tylko pozostaje nam poskładać to wszystko do kupy...

+ Groovy

Zakreślony na czerwono pliczek odpalamy na sam koniec. Znajdzie on wszystkie raporty i sklei w całość:



A jak klikniemy w w nagłówek sekcji to zobaczymy raport szczegółowy z domeny danego ficzera:



I dalej schodzimy do poziomu pojedynczych user story.

Do szczęścia pozostaje już tylko dopracowanie tekstów w Given, When, Then tak aby ci biedni ludzie zza miedzy wiedzieli o co w tym wszystkim chodzi