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ń.

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

• http://c2.com/cgi/wiki?PrimitiveObsession
• http://c2.com/cgi/wiki?ValueObject
• do pogoglwania : object calisthenics

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

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

JUG Łódź - wzorce w JEE

Przemawiał kolega Marek Strejczek. Rozkręca się po około pół godziny :)

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!

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!