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!