Tematyka bloga zakreśla obszar technologii komputerowych z akcentem na centralną rolę jednostki ludzkiej jako napędu procesu wytwarzania oprogramowania (plus standardowe tematy egzystencjalno- informatyczne)
Nie mam dzisiaj weny dlatego od razu przejdziemy do tematu. Poniżej slajd "pożyczony" z innej prezentacji. Widzimy na nim, że ilość przechowywanych danych rośnie i to rośnie bardzo a nawet niezwykle bardzo. Można zrobić na tym biznes a słowo klucz do tego biznesu to BIG DATA
Aby przetworzyć takie ilości danych potrzeba i infrastruktury i czegoś co będzie na tej infrastrukturze działać
Mahout ma wsparcie dla hadoopa toteż jest przygotowany na pracę z ogromnymi ilościami danych.
Mahout jest fajny bo na początku nie wymaga od nas znajomości skomplikowanej matematyki. To trochę tak jak metoda Collections.sort - Do codziennego użytkowania nawet nie musimy mieć świadomości jak ona jest zaimplementowana. Jednakże gdy sortowanie staje się krytycznym elementem naszej aplikacji, wtedy musimy zejść głębiej. Podobnie jest z Mahout i Machine Learning.
Jak prosto zacząć - rekomendacje
Poniżej przykładowy kod służący do rekomendacji.
private List calculateGenericReccomendations() throws TasteException {
//1
final JDBCDataModel booksReccomendationModel = new MySQLJDBCDataModel(dataSource, "UserBookPreferences", "userId", "bookId",
"preferences", null);
//2
final UserSimilarity similarity = new EuclideanDistanceSimilarity(booksReccomendationModel);
//3
final int howManyUsersInNeighbourhood = 2;
final UserNeighborhood userNeighborhood = new NearestNUserNeighborhood(howManyUsersInNeighbourhood, similarity,
booksReccomendationModel);
//4
final Recommender recommender = new GenericUserBasedRecommender(booksReccomendationModel, userNeighborhood, similarity);
final int userIDForReccomendation = 5;
final int howManyThingsToReccomendation = 3;
final List recommendations = recommender.recommend(userIDForReccomendation, howManyThingsToReccomendation);
return recommendations;
}
Zaczynamy od specyfikacji modelu danych. W tym przypadku model znajduje się w bazie danych. Forma jest prosta :
id_uzytkownika
id_ksiazki
ocena
Określamy podobieństwo pomiędzy użytkownikami. Idea jest ponownie dosyć prosta. Najpierw preferencje musimy przepisać na dane w układzie współrzędnym a następnie obliczamy odległość pomiędzy konkretnymi punktami. Tak zachowuje się metryka Euklidesowa wybrana w tym przypadku - użycie innej implementacji to zmiana w dosłownie jednej linijce.
Bardzo prosty krok. Ustalamy na jakiej zasadzie określimy czy użytkownicy są do siebie podobni. Tutaj bierzemy dwóch najbliższych.
Wrzucamy do kotła i w zasadzie gotowe. Jeśli mamy odpowiednie dane w modelu to wtedy powinniśmy otrzymać listę trzech rekomendowanych pozycji dla danego użytkownika. Ponieważ widziałem już w swoim życiu upośledzone systemy rekomendacji oparte na Random.nextInt, więc sposób przedstawiony powyżej wydaje się dosyć sensowny. Inne ciekawe pola, na których może sprawdzic się mahout to klastrowanie i klasyfikacjia
Jest jeszcze moja prezentacja z JUGa ale tym razem nie mieliśmy porządnej kamerki dlatego niewiele widać( i słychać).
Drugie spotkanie BYOP w Łodzi miało miejsce w czasie gdy z powodu mrozu samochody nie chcą otwierać drzwi a w kraju szaleje epidemia grypy. Pomimo tego na spotkaniu wszyscy wyglądali rześko co potwierdza starą góralską prawdę, że praca z metodykami zwinnymi zwiększa satysfakcje z życia i poprawia działanie układu immunologicznego.
Poruszane zagadnienia
Podział na user story mocno zależnych od siebie funkcjonalności
Problem : Jak podzielić na user story funkcjonalność, której nie jesteśmy w stanie skończyć w jednym sprincie, a która składa się z mocno zależnych od siebie części.
Na potrzeby dyskusji przyjęliśmy błahy przykład z następującymi założeniami.
Mamy formularz z trzema polami
Nie da się zrealizować całego formularz w jednym sprincie
Dodanie każdego pola niesie ze sobą wartość biznesową
Podejście 1 : ukrywanie zależności technicznych w user story
As a User chce mieć pole1 - 3 story pointy
As a User chce mieć pole2 - 1 story point
As a User chce mieć pole2 - 1 story point
W tym przypadku zakładamy, że z pierwszym polem robimy całą obsługę formularza i przy następnych polach ta część będzie gotowa.
Istnieje ryzyko, że Product Owner zmieni priorytety user story i cała misterna intryga się posypie.
Podejście 2 : jasne wydzielenie technicznego user story
Zaimplementować obsługę formularza - 2 story pointy
As a User chce mieć pole1 - 1 story pointy
As a User chce mieć pole2 - 1 story point
As a User chce mieć pole2 - 1 story point
Tutaj z kolei były dyskusje czy powinniśmy tworzyć user story, które nie niesie ze sobą żadnej wartości biznesowej oraz jak zaprezentować na demie
"obsługę formularza bez pól".
Podejście 3 : niezależna wycena każdego z pól
As a User chce mieć pole1 - 3 story pointy
As a User chce mieć pole2 - 3 story pointy
As a User chce mieć pole2 - 3 story pointy
Ten przypadek ma w zasadzie jedyną zaletę, że Product Owner może sobie zmieniać priorytety jak chce ale poza tym ma same wady
i zostało przez uczestników dyskusji określone mianem totalnie złego.
Podejście 4 : bez kombinowania
As a User chce mieć nowy formularz z polem1 - 3 story pointy
As a User chce dodać pole2 do formularza - 1 story point
As a User chce dodać pole3 do formularza - 1 story point
Tutaj jest opisane jasno na białym, że z pierwszym user story tworzymy formularz a kolejne pola są dodawane.
Jeśli Product Owner chce zmienić priorytety i mieć pole2 przed polem1 wtedy nie ma wyjścia i trzeba dokonać zmiany w backlogu co wydaje się być logiczne.
Osobiście najbardziej podoba mi się właśnie to rozwiązanie.
Problem : Ludzie nie chcą robić code review i jak wykorzystać grywalizację aby ich do tego skłonić.
Osobiście Trudno mi opisać obiektywnie ten temat gdyż moim zdaniem programiści domyślnie chcą pisać dobry kod. Jeśli tego nie robią to znaczy, że istnieje "coś jeszcze" co ich demotywuje.
Tak czy inaczej tło problemu zostało przedstawione i rozpoczęła się dyskusja jak wykorzystać przyznawanie punktów przy okazji code review. Z tego co pamiętam każda kolejna propozycja spotkała się
z pomysłem jak dany system pohakować by mieć więcej punktów. Było tez trochę teoretyzowania co motywuje ludzi, ilu ewangelistów potrzeba do wkręcenia żarówki i takie tam.
Pomysłodawca zagadnienia ma sprawdzić je w praktyce i przynieść wnioski na kolejny BYOP.
Scrum a odziedziczony kod
Problem : Z dalekiego uduchowionego kraju o bogatej tradycji przywędrował do nas projekt o wątpliwej jakości technicznej - jak go rozwijać/naprawiać przy pomocy metodyk zwinnych.
Słowo klucz - ScumBan
Uświadom interesariuszy (piękne słowo) o ogromnym długu technicznym projektu
Estymuj bugi jak user story
Ponieważ pole minowe jest niezbadane więc trudno "komitować" się na określoną ilość story pointów. Kontrakt - w sprincie zrobimy minimum tyle a tyle user stories a jak uda się szybciej to bierzemy kolejne z backlogu
Poprawny model obiektowy a metodyki zwinne
Problem : Jak uzyskać poprawny model obiektowy bez BDUF (big design up front) i towarzyszącego temu podejściu marnotrawstwa (waste)
Bardzo złożony i nawet kontrowersyjny problem. Niektórzy słysząc słowa analiza czy projektowanie wyciągają kołki, czosnek i wodę święconą. Z jednej strony każda sekunda poświęcona na projektowanie rozwiązania user story, które zostanie przez PO wyrzucone lub przesunięte gdzieś na dół backlogu jest stratą, której należy unikać. To jest raczej oczywiste. Ale..
Po pierwsze primo: w trakcie code review łatwo poprawić jakieś zjebotwory w kodzie ale jak już ktoś źle stworzy model obiektowy to trzeba czasem poprawiać wszystko
Po drugie primo : jeśli kod jest współwłasnością całego teamu to czy jedna osoba może według swojego mniemania tworzyć model obiektowy, który będzie uderzał w każdego członka zespołu przez następne lata?
Po trzecie primo : czy mając przeanalizowane tylko user story na najbliższy sprint (bądź nawet trzy sprinty) jesteśmy w stanie stworzyć model, który będzie łatwo rozwijalny w kontekście kolejnych funkcjonalności?
Generalnie trzeba znaleźć sposób aby zacząć projektować i przestać kiedy to już nie niesie ze sobą wartości.
W trakcie dyskusji nie udało się znaleźć rozwiązania. Na chwilę obecna będziemy próbować wpleść etap analizy obiektowej do przedsprintowych spotkań planningowych. Czas pokaże co z tego wyjdzie...
Podsumowanie
Tym razem spotkanie było bardziej merytoryczne - mniej filozofowania a więcej porad. Dwie kwestie pozostały otwarte i będą dyskutowane ponownie gdy praktyka da odpowiedzi na część pytań i założeń.
Kolejne spotkanie jest planowane na początku marca.
Co takiego właśnie zobaczyliśmy? Były to dwa ładne przykłady zjawiska uwagi selektywnej. Jeden z mechanizmów, który bierze w tym udział, nazywa się "Reticular activating system" (google translator tłumaczy to jako "Siateczkowy system aktywacyjny").
Ów układ działa niczym przełącznik sterujący poziomem naszej senności/pobudzenia. Jeśli siedzimy na nudnym wykładzie złącza się tryb sennego odzyskiwania sprawności psychicznej ale jeśli tylko w naszym otoczeniu pojawia się coś co uważamy za istotne dla nas wtedy następuje pobudzenie i zogniskowanie percepcji na tej rzeczy.
Ale skąd wspomniany RAS wie co jest dla nas ważne? I właśnie to jest trochę niebezpieczne...
Dodatnia pętla sprzężenia zwrotnego gówna
Dodatnia pętla sprzężenia zwrotnego - uważamy, że bogaci ludzie są nieuczciwi, spośród wielu faktów RAS wyłapuje te, które potwierdzają założenia naszego modelu mentalnego - co jednocześnie wzmacnia model mentalny...
To jest niestety przyczyną tego, że niektórzy ludzie wraz z wiekiem wykazują coraz mniejszą elastyczność myślenia i działania. Tylko po co kilka miliardów ewolucji stworzyło coś co ma nam szkodzić? Czy to kolejny mechanizm, który sprawdza się doskonale w polowaniu na mamuta ale szkodzi w epoce drapaczy chmur? Nie do końca.
Zaprogramuj model na szczęście
Łysy jegomość na drugim filmiku nazywa się Richard Wiseman (Dobre marketingowe nazwisko ;)). Pośród wielu ciekawych eksperymentów przeprowadził on jeden niezwykle ciekawy w kontekście tego artykułu. Tematem eksperymentu była percepcja szczęścia.
Przez 10 lat zbierał on dane od 400 ochotników w przedziale wiekowym 18-44.
Dane określały czy ktoś subiektywnie czuje się szczęśliwy czy też uważa się za pechowca.1
I teraz następuje ważny moment! Wiseman zebrał wszystkich uczestników eksperymentu, dał im gazetę i kazał policzyć ilość ilustracji. Pechowcy spędzili średnio dwie minuty na wykonywaniu ćwiczenia zaś szczęśliwcom zajęło to tylko parę sekund. Czy to dlatego, że mieli szczęście? NIE! To dlatego, że na drugiej stronie widniał duży napis "Stop counting: There are 43 photographs in this newspaper. ". Dlaczego pechowcy go przeoczyli?
Wyobraźmy sobie model, który zakłada, że świat to pechowe miejsce - nic tam na nas dobrego nie czeka. Mamy proste zadanie to trzeba zrobić to zadanie - "monkey see monkeyt do." Lecz jeśli zakładamy, że szczęście nam sprzyja to RAS będzie wyczulony na wszelkie szanse jakie mogą się nadarzyć. W jednej sekundzie trafia w nas masa informacji i na bazie naszego modelu pojęciowego różne mechanizmy w naszej głowie decydują co ma być uświadomione
Więc jak zaprogramować nasz RAS na wypatrywanie szczęścia w naszym nowym młodym roku?
Questy - rozbudowywanie modelu
- Panie doktorze chciałbym rzucić palenie
- no to niech pan rzuci, palenie jest nie zdrowe a papierosy są coraz droższe
- spoko to rzucam, ile się należy
- stówka
Niestety nie jest to takie proste. Tematyka powstawania mechanizmu iluzji wolnej woli wymaga osobnego artykułu ale powyższy absurdalny dialog powinien zobrazować, że zmiany psychiki to nie "proste decyzje" - od dzisiaj robię tak i tak. Pomyślmy przez analogię - jeśli chcemy budować siłę to ćwiczymy i to ćwiczymy mądrze. Jeśli przyjdziesz na siłkę i zarzucisz 300kg na klatę to możesz sobie co najwyżej zrobić krzywdę. Podobnie należy postępować z ćwiczeniem psychiki.
Ja nazwałem ćwiczenia psychologiczne questami ale każdy może sobie nazwać je jak chce. Idea jest podobna jak do siłowych - jak zarzucisz za dużo na samym początku to zamiast rozbudowywać strefę komfortu skończysz z nowymi fobiami.
Przykładowe questy
Standardowe ćwiczenie na rozbudowę strefy komfortu. Poszerzenie strefy komfortu ma sprawić, że mózg uwolni się od rutynowego myślenia i zacznie przeprogramowywać RAS. Następnym razem gdy pani za ladą w sklepie powie "mogę być winna grosika" :
"nie, nie dzisiaj" (pusty sklep) - 5kg
"nie, nie dzisiaj" (kolejka) - 10kg
"nie, i masz oddać 17 groszy, które mi wisisz" - 20kg
Wystąpienia publiczne. Generalnie w trakcie wystąpienia publicznego działają te same obszary mózgu, które aktywują się gdy nasze życie jest zagrożone. Ma to podstawy ewolucyjne. Ogarnięcie tej strefy buduje poczucie większej wartości społecznej dzięki czemu dla podświadomości otworzą się nowe ścieżki, uważane wcześniej za nieosiągalne (jestem za wysoki/niski, za biedny, za gruby , za szczupły).
mało osób, łatwy temat - 5kg
dużo osób łatwy temat - 30kg
mało osób trudny temat - 40kg
dużo osób trudny temat - 80kg
wrogo nastawiony tłum - trudny temat (np temat "dlaczego agile jest zajebisty" na corocznym zjeździe miłośników 5 letniej analizy - 150kg
I jedno z trudniejszych - trzeba nauczyć się bawić na trzeźwo. Alkohol to tak jak granie z kodami. Walisz wódę, przez chwilę zapominasz kim jesteś i zaczynasz się faktycznie dobrze bawić, rano jesteś znowu tą samą osobą, ze szczotkowymi wspomnieniami, rozjebanym zdrowiem i zerową wartością rozwojową (chociaż Epizodycznie coś tam się zawsze strzeli) - na końcu tego questu jest do pokonania boss - "uniezależnienie się od wyniku" - jak uda mi się osiągnąć to opiszę.
Wszelkie formy medytacji z afirmacjami - "jestem zajebisty" - przy zwolnionym oddechu gdy częstotliwość fal mózgowych schodzi do alfa, te cytaty idą ładnie do podświadomości.
Moje questy, które sobie zrobiłem w ostatnim półroczu to m. in. wygłoszenie prezentacji o psychologicznych podstawach programowania przed kilkudziesięcioma słuchaczami(może nawet setka była), których przynajmniej część oczekiwała uproszczenia modelu ( programista to prosty resors) aniżeli jego skomplikowania (programista to skomplikowana istota). Dodatkowo udział w konkursie na letni kaloryfer :
Zdjecie pewnie bedzie do czasu zaorania dostępne w galerii na http://foto.perfectbody.pl/ . I takie doświadczenia sprawiają, że mózg zamiast chować się jaskini zaczyna w otoczeniu dostrzegać coraz to nowe szanse. Na nowy rok warto zaczerpnąć motto rodem z rozkazu numer 227 Rosyjskiej Wielkiej Wojny Ojczyźnianej :