Na razie znalazłem jeden wpis :
http://nazargargol.com/2013-mobilization-3-conference-lodz/
Jak ktoś jeszcze ma coś na swoim blogu w tym temacie i chce się podzielić to niech się podzieli.
Jutro zaczyna się nowy kurs z udziałem scali :
https://www.coursera.org/course/reactive
* * *
Jacek ma tak rozwinięte zdolności prezentacyjne, że nawet jeśli jego kod nie kompiluje się z niewiadomego powodu to i tak jest w stanie zrobić z tego interesujący punkt programu :)
Generalnie z tego co zauważyłem aby chcieć się nauczyć czegoś nowego trzeba przekonać swój umysł do tego, iż to coś może się przydać i tutaj mamy dwa podejścia :
Później dyskusje o kodzie i jest git.
Pozostaje jeszcze jedno fundamentalne pytanie - Po co uczyć się Scali . Odpowiemy sobie na to za chwilę ale najpierw umieszczę obrazek aby przerwać monotonię ciągłości tekstu.
Po co uczyć się Scali.
Po pierwsze jest to technologia, która ma o wiele większe możliwości od Javy. Ten aspekt okaże się krytyczny gdy nadejdzie dzień ( a wieżę, że nadejdzie) gdy o konkurencyjności produktu będzie w dużej mierze decydowała technologia użyta do jego wytworzenia a nie minimalizacja ilości błędów w projektach popełniana przez ludzi którzy chcieliby sobie pozarządzać. Nie wiem jak ta sytuacja wygląda w skali całej Polski ale w Łodzi do niedawna było tak, że jak chciałeś sobie kupić mieszkanie+samochód na raty i do tego pojechać na jakieś wakacje to trzeba było uciekać na lepiej płatne pozycje gdzie twoim obowiązkiem było napierdalać jakieś szlaczki w powerpointach i udawać, że potencjalny sukces projektu to głównie twoja zasługa. Wydaje mi się, że trzeba chwilę poprogramować w Javie&Spółka aby odczuć jej ograniczenia - a jeśli robi się uskok ze ścieżki programistycznej po 3 latach aby zostać "JuniorBrandManager" to taki efekt dana osobę ominie. Osobiście subiektywnie odczuwam, że sytuacja się poprawia i zawód programisty zaczyna cieszyć się w naszym mieście coraz większym szacunkiem.
Scala jest trudniejsza od Javy co z jednej strony stanowi pewną przeszkodę w jej adaptacji bo jeśli odpowiednia ilość osób an rynku nie będzie znała tej technologii to firmy nie będą chciały robić przy jej pomocy projektów ( Dlatego kolejny plus dla inicjatyw typu scalania za szerzenie świadomości pośród społeczności). Z drugiej strony ta trudności nauki jest pochodną ogromnych możliwości Scali i stanowi pewien filtr, przez który mogą przejść jedynie osoby dysponujące określoną wiedzą. I może to co tutaj napiszę nie zabrzmi jakoś poprawnie politycznie ale właśnie ta trudność nauki może sprawić, że praca nie będzie uciekać dalej na wschód gdy zarobki w Polsce będą sukcesywnie rosnąć. A to dzięki temu ,że programiści tutaj w Polsce będą w stanie zagwarantować większą produktywność niż X razy tańsi programiści gdzieś tam na wschód.
I kolejny argument, o którym do niedawna nie miałem pojęcia. Scala to już nie jest jakiś tam projekt naukowy z uczelni ale produkt przemysłowy! Martin Odersky dostał kasę i założył firmę Typesafe, która wspiera rozwój Scali. Do tego w zarządzie zasiadł Rod Johnson - to ten, który stworzył Springa. Mając ogromny bagaż doświadczenia zapewne wie jak sprawić aby dana technologia osiągnęła sukces biznesowy. Wygłosił dosyć ciekawy wykład przy okazji ostatnich ScalaDays : http://parleys.com/play/51c1ffe7e4b0d38b54f46231/chapter0/about - kilku nerdom się nie spodobało ale cóż - prawda czasem boli.
Bardzo pouczający warsztat. Może w końcu uda nam się w firmie stworzyć jakieś porządne testy do javascriptu - na razie jest ciężkie selenium plus średnio wygodne testy Jasminy zagnieżdżone w htmla. Angular ładnie oddziela javascript od htmla i nie ma tego bólu. Do tego sam narzuca pewne poprawne praktyki jak dzielenie kodu na moduły. Na razie moja znajomość tematu jest zbyt mała abym napisał coś więcej ale już zaczęliśmy to cudowdrażać w naszym projektu. Ogólnie warsztat git.
Chłopaki rzucili ostatnią partię biletów na Mobilization3 - można się rejestrować tutaj : http://2013.mobilization.pl/registration/
W zeszłym tygodniu pojawiła się wiadomość, iż naukowcy z jednego z uniwersytetów odkryli, że zarówno hipokamp jak i wątroba potrzebują białka zwanego "PPARalpha" do poprawnej pracy. Hipokamp potrzebuje go do tworzenia nowych "struktur pamięci" zaś wątroba do spalania tłuszczu. Im bardziej zatłuszczony jest organizm tym więcej tego białka potrzebuje wątroba - podprowadzając je hipokampowi - więcej info tutaj : http://www.livescience.com/40440-your-liver-may-be-eating-your-brain.html
Także wbrew mitom z holyłudu - narzucając na siebie dwudziesto-centymetrowy skafander tłuszczowy wcale nie stajemy się romantycznymi bohaterami z bujnym życiem wewnętrznym ale przeciętnymi ludźmi z upośledzoną pracą mózgu. Także wio na siłownie i nie opierdalać się!
Jeśli przyjmiemy dosyć ciekawe definicje programowania obiektwego i funkcynego podane w tej oto prezentacji :
czyli :A to dlatego, iż kilka lat temu (zdaje się, że w 2010) dwójka hiszpańskich psychologów (z nazwiskami, które nikomu nic nie powiedzą) i Niemiecki neurolog (z nazwiskiem, które...) postanowiła poskanować mózgi ludzi uczących się rzeczowników oraz czasowników i zobaczyć co z tego wyjdzie.
Gdy ludzie leżeli sobie słodko w romantycznej komorze do skanów słyszeli takie zdania jak : Otworzyłem amelinium aby wsiąść do samochodu , Otworzyłem amelinium by przepuścić kobietę w ciąży - wtedy z kontekstu mozna wywnioskować, iż amelinum to coś ala drzwi.
Podobnie z czasownikami - Byłem głodny, więc farełałem puszkę z fasolą , Farełałem drzwi od samochodu - tutaj farełać oznacza "otworzyć"
Według badań przy nauce tych dwóch słów pracują u nas inne części móżgu. Rzeczowniki (czyli obiekty) - obszar mózgu odpowiedzialny za procesowanie wizualne , kategoryzowanie, rozpoznawanie twarzy (to ciekawe). Zaś za rozpoznawanie czasowników(Funkcji) odpowiedzialne były obszary "od gramatyki" i jakieś tam jeszcze.
Ponieważ to na razie ciekawostka także żadnych praktycznych wniosków na chwilę obecną nie ma. W artykule do którego link będzie (jeśli tylko nie zapomnę) na samym dole naukowcy deklarują, że podobno znaczenie rzeczowników łatwiej wyłapać z kontekstu. Być może dlatego wygodniej jest rysować kwadraty w uml jako symbole rzeczowników a nie czasowników? A może to nic nie znaczy?
Tak czy inaczej lingwistyka może być dosyć ciekawym kierunkiem dla lepszego zrozumienia zależności pomiędzy typami danych i przekształceniami w systemach.
A oto linki, o których nie zapomniałem :
Jeśli założymy, że informatycy to pracownicy fizyczni wtedy faktycznie nagradzanie za ilość linii kodu ma sens - bo nagradzany jest fizyczny wysiłek mięśni zginacza palca środkowego i sąsiednich. Ale ponieważ (mam niesamowicie ogromną nadzieję!!!) większość populacji rozumie już, że to jest bzdura i informatyk/programista to pracownik o charakterze intelektualno-kreatywnym, którego praca polega na rozwiązywaniu problemów - toteż ma sens największy aby skupić się właśnie na tym - problemach (i rozwiązaniach).
Okazuje się, że problemy możemy rozwiązać na dwa sposoby :
I co z tego? Podział jak podział... A jednak okazuje się, że w dużej mierze wiadomo co tam się pod czaszką w momencie "Eureka" dzieje
(I tutaj małe ostrzeżenie - jeśli czytelnik wyznaje klasyczny tu i ówdzie pogląd, że programistę trzeba zajechać aby "zoptymalizować" jego produktywność to niech przestanie czytać i pójdzie pooglądać Kubę Wojewódzkiego czy coś w tym stylu bo to co napiszę poniżej nie przypasuje mu do światopoglądu :( )
Bohaterem historyjki jest niejaki Mark Jung-Beeman - neurolog z ważnego uniwersytetu w USA, którego nazwa fajnie by brzmiała, dodała powagi tekstowi ale nikt i tak je nie zapamieta. Jako spec od prawej półkuli mózgowej pewnego dnia sam przeżył olśnienie (plus masa wiedzy i paredziesiąt lat doświadczenia) iż skomplikowana natura języka wymusza jego procesowanie przez obydwie półkulę a nie tylko lewą - zwaną analityczną.
Beeman zaprojektował eksperyment, który polegał na tym aby znaleźć związek pomiędzy grupą wyrazów. Zakładał, że dla prostej grupy algorytm rozwiązywania będzie miał charakter analityczny ale już dla niecodziennego zestawu mózg będzie musiał zastosować jakąś sztuczkę. (Np zestaw {droga,przystanek, pasażer} - dosyć prosto - autobus | ale już dla {książka,spodnie,oklaski} - tak łatwo związku znaleźć się nie da - mól - zwłaszcza przy ograniczonym czasie)
A że na szczęście technologia jest coraz lepsza to można wykonywać takie fajne foty mózgu(fMRI), z kolorowaniem fragmentów pracujących. Plan był taki, że ludzie będą rozwiązywali zagadki siiedząc w komorze do robienia skanów. Niestety fMRI ma kilka sekund opóźnienia przez co nie udawało się zarejestrować "Eureki". Wtedy Beeman skumał się z kolesiem zwanym John Kounios, który to eksperymentował z inną technologią badania mózgu - EEG. Ta technologia dawała natychmiastowy wynik ale bez informacji, który rejon mózgu działał.
Postanowili połączyć te dwie technologie a wynik widzimy na obrazku trzy akapity powyżej:
Badacze zauważyli to co widać na obrazku - aktywność w prawej półkuli. W teorii prawa półkula lepiej łączy różne koncepcje ale robi to mniej dokładnie niż półkula lewa. Na początku mózg skupia się na problemie ale później musi przerwać tę uwagę aby dać działać prawej półkuli.
Jakieś dziwne umysły mogłyby powyższy akapić odczytać w sposób - "aha czyli należy rozpraszać programistów" Nie, ku*wa nieee. Poniższy filmik odpowie dokładniej na to pytanie:
A to dlatego, że zanim pojawi się krótka aktywność gamma scalająca sieci neuronowe - swoją obecność zaznacza inna mózgowa "fala". Mózg działa w częstotliwości alfa (8-12HZ) w stanie relaksu. Medytacja, trans, relaks, spacer do Żabki - to wtedy mózg jest w stanie skanować pamięć w celu znalezienia kreatywnego rozwiązania. Hen hen czasu temu czytałem, że przy tej częstotliwości najefektywniej zachodzi wymiana informacji pomiędzy półkulami jakkolwiek teraz nie chce mi się szukać badań.
Swoje trzy grosze dołożył tutaj niejaki Joy Bhattacharya (a psychologist at Goldsmiths, University of London - kolejna fajna nic nie znacząca nazwa uniwersytetu). W trakcie swoich badań zaobserwował na wykresie EEG wzrost natężenia fal alfa na 8 sekund przed "olśnieniem". Kilka fajnych cytatów z tych badań:
To poniżej jest zajebiste!
Cholera znowu coś co stoi w sprzeczności ze szkołą zarządzania "optymalizacji użycia klawiatury". Czyżby jednak wyciskanie ludzi i szlifowanie dedlajnów mogło nie być najlepszym środkiem do zwiększenia produktywności w IT? Za każdym razem gdy znajduję takie badanie boję się, że gdzieś tam w krainie wyssanych z dupy harmnonogramów ginie gantowa wróżka
Tak dla przypomnienia - istnieje jeszcze częstotliwość beta (16-20hz). W tym stanie mózg działa w trakcie "nie-relaksacji" i wyostrzonego skupienia. Jakkolwiek tutaj na ciekawy przypadek natrafił Kounios (to ten od EGG) w trakcie swoich badań. Otóż pewnego dnia uczestniczył w nich mistrz ZEN (to taka forma medytacji). Koleś nie był w stanie rozwiązać żadnych z puzzli - aż za nadto panował nad swoim umysłem w pełni skupiając się na problemie.
I nagle - w chwili pewnej - ZEN koleś zamienił się w prawdziwą maszynę do kreatywnego rozwiązywania zagadek. Generalnie tak zajebiście panował nad umysłem, że był w stanie skupić się na tym aby na niczym się nie skupiać. (To jest generalnie jedno z fajnych ćwiczeń w medytacji. Spróbujcie zamknąć oczy i nie myśleć o niczym - na samym początku można w tym stanie przesiedzieć maks kilka-kilkanaście sekund.
Do wspaniałych rzeczy jakie może dać medytacja w IT jeszcze kiedyś wrócimy.
Jestem na siłce i nagle do głowy przychodzi mi pewne rozwiązanie problemu z pracy. Najczęściej są to małe rzeczy związane designem komponentów/klas/funkcji w aplikacji ale czasami zdarzają się rzeczy relatywnie "przełomowe" jak np. ostatnio pomysł na wyciągnięcie części funkcjonalności do generowania raportów wewnętrznych do osobnej aplikacji co znacznie usprawniło rilisy (niby takie oczywiste a jednak przez ponad rok żaden mózg od pacyfiku poprzez stawy Jana w Łodzi o tym nie pomyślał). Początkowo myślałem, że to kwestia ukrwienia móżgu w trakcie ćwiczeń ale teraz widzę ogromny wpływ "stanu psychologicznego"
I teraz pytanie - jak to liczyć do czasu pracy? Rozwiązuje problemy z pracy to jestem w pracy? A jeśli siedzę przy klawiaturze i zastanawiam się czy zamknąłem drzwi od domu - to jest w pracy ale nie w pracy? I jak w kontekście tych rozważań ma się to zalecenie aby siedzieć 8 godzin przy klawiaturze? I czy czytniki przy drzwiach mają sens czy może raczej jakieś skanery mózgu?
Czy jeśli coś cokolwiek co napisałem powyżej ma sens to czy "optymalizacja czasu przy klawiaturze" driven development ma jakiś sen? Czy logowanie godzin i inne takie mają jakiś sens jeśli takie zbiory jak {"umysł","kreatywność","olśnienie","rozwiązanie"} {"liniowość","przewidywalność","plan","determinism"} lubią być zajebiście rozłączne?
Oczywiście cały czas gdzieś tam istnieje frakcja, według której jakiś zajebisty koleś w zajebiście brzmiącej roli wszystko wymyśli a małp.. znaczy programiści maja nie myśleć tylko robić. No cóż, był kiedyś taki odcinek przygód Tytusa gdzieś pewnej grupie ziomków wlali dosłownie olej do głowy - polecam lniany tłoczony na zimno - podobno ma dużo omega-3 .
Ostatnio mam relatywnie często olśnienia w trakcie rozkminy koncepcji ze scali. Covariance i Contravariance zczaiłem pomiędzy seriami na mięsień dwugłowy ramienia (zwany na dyskach osiedlowych "Bajcem"). Natomiast olśnienie odnośnie ostatniego zadania drugiego tygodnia kursu funkcyjnej scali (implementacja mapowania na symbolicznej reprezentacji zbiorów) przyszła z falą teścia po treningu nóg.
A no i kiedyś jak biegałem z ulotkami to nagle zaczaiłem jak powstaje drganie w układzie kondensator-cewka.
LINKIJak poruszyć anty-mainstreamowy temat i nie doprowadzić do jałowego trollowania?
Na przykład stwierdzenie "warto prowadzić zdrowy tryb życia" ma ogromny "potencjał strollowania" (np. "można żyć bez papierosów - tylko po co?" czy coś w tym stylu). Dużo trudniej trollować fakt - "mięśnie składają się z włókien białych i czerwonych" - chociaż może jakiś mistrz ciętej riposty i tutaj się wykaże.
Podobnie taka oto teza "stres w każdej postaci szkodzi produktywności w IT" może łatwo przerodzić się w trollo dyskusje ot chociażby poprzez stwierdzenie - "o nie nie, ja mam doświadczenie i jak raz przycisnąłem ludzi to produkt był w dwa tygodnie gotowy". No i zaczyna się problem ponieważ nasze subiektywne opinie i wspomnienia zazwyczaj mają mało wspólnego z rzeczywistością - i na ten temat są tysiące stron literatury naukowej.
Znacznie lepiej przenieść dyskusję na poziom bardziej ...mechaniczny.
Najpierw pojawia się bodziec dla rozpoczęcia procesu - zagrożenie. Generalnie my - jako ludzie - mamy taki oficjalny "zbiór rzeczy stresowych" jak np. "to uczucie kiedy biegnie na ciebie coś dużego z 20 centymetrowymi kłami" czy też głośny dźwięk lub nagła utrata równowagi. Oczywiście każdy człowiek poprzez swoje niepowtarzalne życie tworzy wariację tego zbioru i tak np. hycel może się uodpornić na warczenie psa a ktoś inny nabędzie strachu przed zamkniętymi pomieszczeniami (czyli np. idziesz o dwunastej do sklepu i boisz się, że będzie zamknięty)
Są dwa bardzo interesujące bodźce korporacyjne do których powrócimy później.
O tym punkcie wspominam w zasadzie tylko dlatego, że słowo "Kortykotropina" zajebiście nadaje się do ćwiczenia wysławiania się. Sam mam wadę wymowy, więc mi pomaga - także wszyscy na trzy- cztery
Kortyzol to taki globalny sygnał dla organizmu "Mamy kłopoty - koniec zabawy".
Kortyzol zatrzymuje "development organizmu". Mięśnie przechodzą w stan katabolizmu (rozpad), spowolnione zostaje działanie układu odpornościowego (nie czas na zwalczanie wirusów - za chwile coś może nam odrąbać głowę.
Bardzo ciekawe rzeczy dzieją się gdy kortyzol uderza w mózg - ciekawe zwłaszcza dla zawodów wymagających kreatywności
Zakręt zębaty (Dentate_gyrus) to zajebisty kawałeczek mózgu. Do niedawna (przynajmniej relatywnego niedawna) uważano, że mózg rozwija się tylko w dzieciństwie i jeśli rodzicie spieprzą nam ten okres życia to już nie ma ratunku. Okazuje się, że proces tworzenia nowych neuronów,połączeń i struktur jest kontynuowany nawet w dorosłym mózgu a jedną z centralnych rol w tym procesie pełni właśnie zakręt zębaty.
"Zakręt zębaty" generuje nowe neurony i wspomaga tworzenie nowych struktur na potrzeby tworzenia nowych wspomnień związanych z eksploracją nowych środowisk czy też odnajdywaniem nowych zależności pomiędzy starymi koncepcjami - kreatywność? Brzmi jak kreatywność. A co z tym obszarem mózgu robi kortyzol? --- W Y Ł Ą C Z A !----
Tak oto doszliśmy do tego jak stres wyłącza kreatywność. Oczywiście nie mam swojego laboratorium i to co tutaj napisałem to moja własna interpretacja przeglądu literatury fachowej. Ale jeśli to prawda to powyższe dane rzucają nowe światło na psudo-techniki managerskie pod tytułem "wywrę na nich presję kłamiąc, że deadline jest dwa tygodnie wcześniej" (a słyszałem o takich). Oczywiście jest jeszcze jedno ale - czy programowanie to bardziej praca kreatywna czy mechaniczna?
... a wcześniejsze pytanie było tylko retoryczne. Niestety nadal na rynku istnieją ludzie wierzący w industrialny podział na tych co myślą i na tych co robią. Właśnie taki totalny fail jak waterfall zakładał, że mądrzy ludzie zaprojektują a programiści "przeklepią". Cóż, jeśli jeszcze gdzieś jakiś beton w to wierzy to powyższe go nie przekona.
Natomiast jeśli ktoś uważa, że projekt IT to epickie zmagania z niezwykłą złożonością i że bez względu na metodykę i rolę w projekcie, każdy poprzez kontakt z innym wycinkiem tej złożoności jest w stanie użyć swojej kreatywnej mocy aby poprzez wartościowy feedback i pro aktywną postawę usprawnić stan projektu - wtedy witam w krainie mądrości i rozumu.
a i jeszcze jedno...
Oksytocyna to antagonista kortyzolu. To jest w sumie temat na osobny wpis ale tutaj wspomnę, że oksytocyna to tzw. "hormon więzi międzyludzkiej" - a nawet nie tylko międzyludzkiej. Dlatego właśnie gdy czujemy stres i ktoś okaże nam wsparcie to wtedy tak jakby czujemy się bezpieczniej. A jeśli komuś potrzeba bardziej naukowego przykładu - młode szczury oddzielone od matek w ciągu 48 godzin tracą dwa razy więcej komórek mózgowych w korze mózgu niż te nie oddzielone.
Dedlajn dedlajnem ale są dwie inne ciekawe kwestie, które mogą wpłynąć na nasz poziom stresu i naszą produktywność :
A na koniec kilka linków oraz doskonale zagrany fragment filmu - gdzie możecie sobie zobaczyć jak płynnie zmienia się centrum "statusu i siły" poprzez zachowanie i jak wpływa ono na procesy osób uczestniczących w scence (procesy oczywiście udawane przez aktorów ale właśnie za to trzepią tyle kasy, że tak dobrze to udają)
Temat jest bardzo ciekawy ale przy pierwszej styczności istnieje duże prawdopodobieństwo przepalenia zwojów mózgowych jeśli nie byłeś/byłaś nań wcześniej eksponowany. Warto jednak przyjrzeć się mu bliżej gdyż występuje kilku relatywnie nowych językach ale trudno napotkań nań w Javie - przez co znowu ludzie mogą pewnego dnia zostać zaskoczeni nowtym ficzerem Javy 13 podczas gdy cały świat na około będzie miał już to od dawna. Także nie ma co czekać.
W Javie relacje pomiędzy typami prostymi i typami wyższego rzędu możemy skonfigurować tylko w jeden sposób - brak jakiejkolwiek relacji - to się nazywa Invariance . Możliwe są jeszcze inne typy zależności
Otóż sytuacja trochę zmieniła się od czasu gdy ten artykuł powstał w 2013 .Gdy go aktualizuję za oknem jest maj 2016 a świat ujrzała pierwsza oficjalna wersja języka Kotlin. Kotlin jest produktem JetBrains - firmy powszechniej kochanej i uwielbianej za ich IDE (to bez ironii - Intellij jest bardzo dobre). Ponieważ owa firma słucha developerów i dopasowuje się w ich gusta od kilkunastu lat to można śmiało stwierdzić, że wiedzą co robią.
No i jak tak spojrzymy na składnię Kotlin-a - Kod wprost z dokumentacji to naszym oczom ukaże się :
val a: Int = 10000 print(a === a) // Prints 'true' val boxedA: Int? = a val anotherBoxedA: Int? = a print(boxedA === anotherBoxedA) // !!!Prints 'false'!!!Ten kod tak w 90% wygląda jak Scala... Tak drogi czytelniku - firma, która od kilkunastu lat robi jedno z lepszych IDE dla programistów Javy i zna ten język an wylot. Z jakiegoś powodu postanowiła zerwać z dotychczasowa składnią Javy na rzecz składni "scalopodobnej".
Ale co ważne w kontekście tego artykułu to informacja, że i tam pojawia się jakaś forma contravariance i covariance. Może więc czas obok funkcji praktycznej zauważyć funkcję edukacyjna nowych języków? Niestety wygląda na to, że Java pomimo swej dojrzałości zostaje w tyle za innym językami i warto zadbać o swoją edukację "poza Javą".
A oto link do przykładu : https://kotlinlang.org/docs/reference/generics.html#declaration-site-variance
abstract class Source<out T> { abstract fun nextT(): T } abstract class Comparable<in T> { abstract fun compareTo(other: T): Int }
Poniżej dla porównania kawałek .Net. Wygląda podobnie do tego kotlinowego kodu i znów pokazuje, że te koncepcje ogólnie nie są nowe. Nowe sa jedynie dla Javy.
public delegate TResult Func<in T, out TResult>(
T arg
)
Generalnie aby nauka szła gładko warto sprząc przyswajaną wiedzę z wiedzą już posiadaną. A do tego jeśli owa posiadana wiedza ma charakter towarzysko - obyczajowy to powinno być i pożytecznie i zabawnie. Dlatego też tematem przewodnim w poniższych przykładach będzie wóda.
W trakcie nauki programowania funkcyjnego tu i ówdzie napotyka się zestaw słówek: contrvariance,contravariance i invariance . W zasadzie to przy okazji lektury Javy też można na nie natrafić - najczęściej przy okazji generyków - ale ponieważ w Javie nie ma czegoś takiego jak declaration site variance dlatego też ów temat schodzi na poboczny tor.
Convariance i Contravariance są szczególnie ważne w kontekście funkcji, które wejście mają contravariant a wyjście covariant - oczywiście funkcje w większości języków bo jest jeden który tego tam nie ma i pozostawię czytelnikom do zgadnięcia który...
Generalnie w Javie można zadeklarować pewne zależności pomiędzy typami a listami jedynie przy deklaracji referencji do listy a nie listy samej w sobie.
List<String> strings=new LinkedList<>(); //List<Object> objects=strings; //compilation error List<? extends Object> objectsAndChilds=strings;
Podobnego problemu nie ma Scala w przypadku listy "immutable".
val strings:List[java.lang.String]=List("1","2","3") val objects:List[java.lang.Object]=strings
Jak i w kotlinie możemy to zrobić bezproblemowo
val list: List<String> =listOf("1","2","3") val anys:List<Any> = list
Gdzież jest źródło tego oto zachowania?
Deklaracja Listy w Scali i w Kotlinie mają obok generyka dodatkowe znaczki.
sealed abstract class List[+A] public interface List<out E>
Własnie owe magiczne znaki sprawiają, że zachodzi odpowiednia relacja pomiędzy listą a przechowywanym wewnątrz jej typem. Warunek : Lista musi być "po angielsku immutable". Jeśli to był szok to co się stanie gdy zerkniemy do funkcji?
trait Function1[-T1,+R]
O ile Covariance (to z plusem) jeszcze jest jakoś intuicyjne o tyle Contravariance(to z minusem) już może czesać bańke. Dlatego też zilustrujemy mechanizm przykładem (obyczajowym)
Poniżej hierarchia klas, która posłuży nam do wytłumaczenia tematu. Domeną jest zestaw młodego chemika-smakosza :
class Alkohol class Metanol extends Alkohol class Etanol extends Alkohol class Browar extends Etanol class RozwodnionyBrowar extends Browar class Wóda extends Etanol
Teraz jeszcze jakie haj order funkszyn w kontekście sklepu osiedlowego :
class SklepOsiedlowy{ val browar=new Browar def realizujUsluge(usluga:Browar => String) = usluga(browar) }
I nadchodzi teraz Clu wpisu na którym swego czasu zdzierałem sobie zwoje. Pamiętając, że cały czas obowiązuje zasada, iż do funkcji można przekazać albo deklarowany typ albo coś co z niego dziedziczy (jak w Javie) to które funkcje z poniższych można przekazać do "sklepu osiedlowego"?
val uslugaSpozywcza=(napój: Browar)=> "piję "+ napój //bramka nr 1 val kiepskaUslugaSpozywcza=(rozwodnionyNapój: RozwodnionyBrowar)=> "piję "+rozwodnionyNapój //bramka nr 2 val generycznaUslugaSpozywcza=(jakiśNapój: Alkohol) => "piję "+jakiśNapój //bramka nr 3
Pierwszy mindfuck przez jaki musiałem przebrnąć to "czucie" funkcji jako typu. Po latach siedzenia w Javie mój mózg cały czas próbuje widzieć je jako metody a nie dane same w sobie i cała koncepcję funkcji sprowadza do wywołania. Na szczęście znajomość javascriptu trochę tu pomaga ( ale i trochę przeszkadza). W każdym razie sklep osiedlowy ma metodę, która przyjmuje funkcję typu : TYP na wejściu Browar , TYP na wyjściu String. Na pewno do tego typu pasuje uslugaSpozywcza bo na wejściu ma Browar a na wyjściu String.
I właśnie tutaj pojawia się arcy ciekawe pytanie: która funkcja jest podtypem funkcji uslugaSpozywcza ? Paradoksalnie okazuje się, że podtypem jest... generycznaUslugaSpozywcza - tak to co przyjmuje "nadtyp" - jako funkcja staje się "podtypem".
Skąd ten potencjalny mindfuck? Być może w mózgu dzieje się coś takiego : jak RozwodnionyBrowar jest podtypem Browaru to zwoje kory szarej chcą aby funkcja, która przyjmuje RozwodnionyBrowar była tez podtypem funkcji, która przyjmuje Browar - ale jest odwrotnie! - dlatego pewnie nazywa się to CONTRAvariance (i ten minusik trait Function1[-T1,+R]).
Wróćmy do kawałka kodu :
val browar=new Browar def realizujUsluge(usluga:Browar => String) = usluga(browar)
A w szczególności tego fragmentu usluga(browar). Generalnie chodzi o to, żeby funkcja jakiej tutaj użyjemy mogła przyjąć TYP Browar.
Dla odmiany inna hierarchia
class Kulturysta class Koksu extends Kulturysta class KoksuZMikrofonem extends Koksu val napierdalanie=(k: Kulturysta)=>"napierdalanie" val wywiady=(k:Koksu)=>"wywiady" val koksuSpiewaZgwiazdami=(k: KoksuZMikrofonem)=>"spiewanie" val telewizja = (fk:Koksu=>String)=>"dzisiaj w telewizji" + fk(new Koksu) telewizja(wywiady) //> res1: String = dzisiaj w telewizji wywiady telewizja(napierdalanie) //> res2: String = dzisiaj w telewizji napierdalanie //telewizja(koksuSpiewaZgwiazdami) - to się nie kompiluje
Mamy tutaj standardowego koksa jako argument przekazywany do funkcji, która to funkcja (z racji tego, że sama jest typem) została przekazana do funkcji wyższego rzędu. Nasz standardowy koks może wziąć udział w wywiadach bo ta funkcja oczekuje właśnie koksa. Może wziąć udział w napierdalaniu (czyli ćwiczeniach), gdyż ta funkcja oczekuje dowolnego kulturysty czyli jest podtypem każdej funkcji, która przyjmuje koksa bo można ją zawsze przekazać w jej miejsce. Ostatnia funkcja oczekuje specyficznego koksa z mikrofonem i tutaj niestety kod się nie kompiluje.
Teraz druga część - COVARIANCE. To jest bardziej intuicyjne bo tutaj typy idą niejako w tym samym kierunku co funkcje : trait Function1[-T1,+R]). Ponownie użyjemy znanej struktury typów
class Alkohol class Metanol extends Alkohol class Etanol extends Alkohol class Browar extends Etanol class RozwodnionyBrowar extends Browar class Wóda extends Etanol
I do tego metodki :
val generycznaReceptaSpozywcza=()=>new Etanol val receptaNaBrowar= ()=> new Browar val receptaNAWódęZMety=() => new Metanol class Wytwornia{ def realizuje(recepta:() => Etanol) = recepta() }
Mamy klasę wytwórnia, która spodziewa się bezparametrowej funkcji zwracającej Etanol. Czyli na bank do wywołania pasuje generycznaReceptaSpozywcza. No i dalej już powinno być jaśniej, że nie można tykać metody z Metanolem bo ludzie poumierają. Idzie taki Zdzisław do sklepu i zamiast produktu do konsumpcji spożywczej dostaje paliwo rakietowe (nie mylić z rocket fuel). Ale jak zamiast dowolnego Etanolu dostanie Browara to jest ok. Czyli tutaj funkcja, która jest podtypem również zwraca podtyp - to powinno być łatwiejsze do zrozumienia.
Pomimo, że przykład alkoholowy używa mainstrimowej analogii to jednocześnie pragnę przypomnieć, że alkohol w dużych dawkach jest niezdrowy.
Doskonałą lekturą uzupełniającą jest tenże link == o tutaj ==> Covariance_and_contravariance_(computer_science). I chociaż czasem ludzie podchodzą trochę nieufnie do artykułów na wikipedii to jednak informacje techniczne moim zdaniem są tam umieszczony w sposób obiektywny, zorganizowany i łatwy w nawigacji.
Co ma wspólnego niszczenie lasów z projektami IT? Istnieje bardzo ciekawe badanie odnośnie tego pierwszego zagadnienia, które powinno wymusić ciekawe przemyślenia odnośnie naszego IT - i co najważniejsze pokazać jasno, że kierunek samoorganizacji jest słusznym kierunkiem towarzysze!
Eksperyment był zorganizowany przez ekonomistkę Elinor Ostrom i odbył się w 1994 roku. Początek jest niepozorny :
Być może jeszcze nie widać naturalnego powiązania z gównem w projektach IT ale to nic nie szkodzi. Sytuację pomogą zrozumieć nam mamuty ( a w zasadzie ich mięso)
Wesoła gromadka jaskiniowców liczy 5 osobników. Biegaja oni codziennie na polowanie i starają się kamieniem czy dzidą trafić mamuta. Nawet jeśli pomiędzy naszymi jaskiniowcami istnieją jakieś różnice w zdolnościach myśliwskich to i tak intuicyjnie wiedzą, że polując w grupie każdy z nich ma większe szanse zasnąć dziś z pełnym brzuchem.
Mamut jest dosyć nieprzewidywalny. Nie da się zrobić wykresu Gantta z planem polowania. Roadmapa też zbytnio się nie przydaje. W całym procesie jest dużo miejsca na przypadkowość i szczęście/nieszczęście. Tego dnia Mamuta upolował akurat Roman. Teoretycznie to Roman powinien dostać awans... znaczy największy kawał mięsa (całego mamuta i tak nie zje). Ale Roman jeszcze nie był na szkoleniu managerskim i intuicyjnie przeczuwa, że za jakiś czas to on będzie miał mniej szczęścia i będzie potrzebował pomocy swoich towarzyszy. Postanawia się równoprawnie podzielić mięsem (chociaż sam zatrzymał dla siebie kieł żeby mieć +5 do lansu we wiosce - 100tys lat później jego potomkowie będą w tym celu używać certyfikatów).
Pytanie czy Roman postępuje rozsądnie dzieląc się mięsem ze wszystkimi. Wiesiek już raz go uratował od głodu gdy ten miał skręconą nogę ale z sprawa z Bytomirem wygląda inaczej. Bytomir ostatnio jakośnic nie upolował. Niby coś tam biegał ale nic z tego nie wynikało. Roman ma dylemat czy robi aby na pewno dobrze dzieląc się mięsem z Boromirem. Ponieważ system karny jeszcze się nie rozwinął w wiosce Romana, więc nie wie on, że dylemat, który przeżywa to dylemat więźnia...
Jeśli ktoś nie słyszał to dylemat więźnia to coś takiego : Złapano dwóch więźniów - jeśli obydwoje milczą - dostają 6 miesięcy , jeśli obydwoje sypią - to dostają po 2 lata a jeśli jeden sypie a drugi milczy to ten co sypał wychodzi na wolność a milczący dostaje 5 lat.
| \ | X | Y |
| X | 6 miechów | 5 lat |
| Y | 0 | 2 lata |
Więźniowie tak jak i nasi jaskiniowcy mogą przyjąć pewne taktyki. Poniżej mała wypocona symulacja w scali, która powinna pomóc zrozumieć pewne konsekwencje wyborów
class Caveman(val id: Int) {
private var value = 10;
def updateValue(addition: Int) = { value = value + addition }
override def toString = id + " : " + value
}
Każdy jaskiniowiec zaczyna grę z określoną ilością "wartości". Wartości będzie przybywać lub ubywać w zależności od przyjętej strategii interakcji. Zdefiniujmy dwa typy interakcji
abstract class Interaction() {
def result(otherResponse: Interaction): (Int, Int)
}
object Positive extends Interaction {
override def result(otherResponse: Interaction): (Int, Int) = {
otherResponse match {
case Positive => (2, 2)
case Negative => (-5, 5)
}
}
}
object Negative extends Interaction {
override def result(otherResponse: Interaction): (Int, Int) = {
otherResponse match {
case Positive => (5, -5)
case Negative => (-2, -2)
}
}
}
| \ | Positive | Negative |
| Positive | 2 | -5 |
| Negative | 5 | -2 |
Więc jeśli obydwaj jaskiniowcy współpracują zyskują wartość 2. Jeśli obydwoje się próbują oszukać tracą 2. Zaś jeśli jeden wydyma drugiego to ten pierwszy otrzymuje nagrodę 5 a drugi karę -5. Jak więc zagrają nasi jaskiniowcy? Na początek mają do wyboru dwie strategie
abstract trait InteractionStrategy {
protected val interactionHistory = Map[Int, Interaction]()
val id: Int
def interact(other: InteractionStrategy): (Int, Int)
def interactionType(cavemanID: Int): Interaction
}
trait Naive extends InteractionStrategy {
override def interactionType(cavemanID: Int) = Positive
override def interact(other: InteractionStrategy): (Int, Int) = {
Positive.result(other.interactionType(this.id))
}
}
trait Aggresive extends InteractionStrategy {
override def interactionType(cavemanID: Int) = Negative
override def interact(response: InteractionStrategy): (Int, Int) = {
Negative.result(response.interactionType(id))
}
}
Strategia Naiwna zawsze oczekuje współpracy a strategia Negatywna zawsze chce wydymać partnera.
def main(args: Array[String]): Unit = {
val hungerValue = -1
val caveman1 = new Caveman(1) with Naive
val caveman2 = new Caveman(2) with Naive
val caveman3 = new Caveman(3) with Naive
val caveman4 = new Caveman(4) with Naive
val caveman5 = new Caveman(5) with Naive
val group = List(caveman1, caveman2, caveman3, caveman4, caveman5)
for (i <- 1 to 10; firstCaveman <- group; secondCaveman <- group if firstCaveman.id != secondCaveman.id) {
val interactionResult = firstCaveman.interact(secondCaveman)
firstCaveman.updateValue(interactionResult._1)
secondCaveman.updateValue(interactionResult._2)
firstCaveman.updateValue(hungerValue)
firstCaveman.updateValue(hungerValue)
}
group.foreach(println(_))
}
Na początek niech każdy jaskiniowiec reprezentuje naiwną strategię - zaczynamy od wartości=10.
1 : 90 2 : 90 3 : 90 4 : 90 5 : 90
Całkiem nieźle - w trakcie 10 rund i interakcji każdego z każdym nasi jaskiniowcy zyskali po 80 jednostek wartości. No ale co gdy w końcu pojawi się ktoś kto zechce dymać frajerów?
val caveman1 = new Caveman(1) with Naive
val caveman2 = new Caveman(2) with Aggresive
val caveman3 = new Caveman(3) with Naive
val caveman4 = new Caveman(4) with Naive
val caveman5 = new Caveman(5) with Naive
1 : -50
2 : 330
3 : -50
4 : -50
5 : -50
No i wydymał ich - koniec snów o Utopii - co się stanie jak coraz więcej osób przyjmie taką postawę?
val caveman1 = new Caveman(1) with Naive
val caveman2 = new Caveman(2) with Aggresive
val caveman3 = new Caveman(3) with Naive
val caveman4 = new Caveman(4) with Aggresive
val caveman5 = new Caveman(5) with Naive
1 : -190
2 : 190
3 : -190
4 : 190
5 : -190
Frajerzy są coraz bardziej dymani ale z drugiej strony cwaniacy muszą się dzielić zyskiem. A co gdy każdy przycwaniaczy?
val caveman1 = new Caveman(1) with Aggresive
val caveman2 = new Caveman(2) with Aggresive
val caveman3 = new Caveman(3) with Aggresive
val caveman4 = new Caveman(4) with Aggresive
val caveman5 = new Caveman(5) with Aggresive
1 : -230
2 : -230
3 : -230
4 : -230
5 : -230
Nasza populacja wymarła. Okazuje się, że bycie kimś naiwnym opłaca się gdy wszyscy są naiwni. Z drugiej strony bycie cwaniakiem opłaca się najbardziej wśród frajerów. Miałem kiedyś kolegę, który jeździł na mecze i napierdalał kogo się da. Opowiadał, że raz na meczu pucharowym grali gdzieś na wsi i tam miejscowi przywitali ich z uśmiechem chlebem i solą na zawodach. No i ci z widzewa się cieszyli, że w 20 wpie***olili tam 100 osobom. Etyka postępowania była zakorzeniona tak w jednych jak i w drugich. Wielu ludzi, którzy ustanawiają procedury w korporacjach błędnie zakładają, że ludzie przyjmują strategie logicznie i świadomie - dlatego procesy i procedury lubią nie działać - ale o tym za chwilę. Zobaczmy inną ciekawą strategię.
Tit for tat w spełnia jedno prawoo - "czyń bliźniemu swemu co on tobie uczynił" - w kodzie to będzie wyglądało mniej więcej tak :
trait TitForTat extends InteractionStrategy {
override def interactionType(cavemanID: Int): Interaction = {
interactionHistory.get(cavemanID).getOrElse(Positive)
}
override def interact(response: InteractionStrategy): (Int, Int) = {
val otherInteraction = response.interactionType(id)
val interactionResult = interactionType(response.id).result(response.interactionType(id))
interactionHistory.put(response.id, otherInteraction)
interactionResult
}
}
Tutaj kod robi się bardziej skomplikowany (chociaż nie wiem czy tylko dlatego, że strategia jest bardziej złożona czy dlatego, że dopiero raczkuję w scali). Tutaj nie ma przebaczenia - pamiętamy co nam zrobili inni i odwdzięczamy się im tym samym. Strategia wydaje się być idealna - będziemy niszczyć cwaniaków i współpracować z tymi, którzy chcą współpracować. Zobaczmy.
val caveman1 = new Caveman(1) with Naive
val caveman2 = new Caveman(2) with TitForTat
val caveman3 = new Caveman(3) with Naive
val caveman4 = new Caveman(4) with Naive
val caveman5 = new Caveman(5) with Naive
1 : 90
2 : 90
3 : 90
4 : 90
5 : 90
To było do przewidzenia - wszyscy współpracują
val caveman1 = new Caveman(1) with Naive
val caveman2 = new Caveman(2) with TitForTat
val caveman3 = new Caveman(3) with Naive
val caveman4 = new Caveman(4) with Aggresive
val caveman5 = new Caveman(5) with Naive
1 : -50
2 : 7
3 : -50
4 : 197
5 : -50
Cwaniak ma się dobrze ale TitforTat przetrwał jednocześnie wspierając współpracę.
val caveman1 = new Caveman(1) with TitForTat
val caveman2 = new Caveman(2) with TitForTat
val caveman3 = new Caveman(3) with Naive
val caveman4 = new Caveman(4) with Aggresive
val caveman5 = new Caveman(5) with TitForTat
1 : 7
2 : 7
3 : -50
4 : -62
5 : 4
Przy trzech TitforTat cwaniak został spacyfikowany ale nie ma jeszcze widocznego zysku. Zwiększmy trochę gromadę.
val caveman1 = new Caveman(1) with TitForTat
val caveman2 = new Caveman(2) with TitForTat
val caveman3 = new Caveman(3) with TitForTat
val caveman4 = new Caveman(4) with Aggresive
val caveman5 = new Caveman(5) with TitForTat
val caveman6 = new Caveman(6) with TitForTat
val caveman7 = new Caveman(7) with TitForTat
val caveman8 = new Caveman(8) with TitForTat
1 : 67
2 : 67
3 : 67
4 : -333
5 : 64
6 : 64
7 : 64
8 : 64
No i cwaniak jest totalnie zmasakrowany a grupa kwitnie. Gdzie jest haczyk? haczyk jest w tej linijce kodu :
val caveman1 = new Caveman(1) with TitForTat
val caveman2 = new Caveman(2) with TitForTat
val caveman3 = new Caveman(3) with TitForTat
val caveman4 = new Caveman(4) with Aggresive
val caveman5 = new Caveman(5) with TitForTat
val caveman6 = new Caveman(6) with TitForTat
val caveman7 = new Caveman(7) with TitForTat
val caveman8 = new Caveman(8) with TitForTat
1 : -410
2 : -410
3 : -410
4 : -410
5 : -410
6 : -410
7 : -410
8 : -410
Totalna rozpierducha. Czy można coś dalej z tym zrobić? Przydałoby się dać jakoś druga szansę spróbować szukać porozumienia. Okazuje się, że istnieje dosyć prosta strategia, która jest w stanie przeskoczyć ten problem ale istnieje też jeden mały warunek...
Z tego co zrozumiałem chodzi o innego Pavlova niż tego do psa. Idea strategi Pavlova jest prosta - jeśli nie zyskałeś nic w tej interakcji to następnym razem spróbuj czegoś innego.
Taktyka wygląda tak (TitforTat cały czas ustawione na negatyw) :
trait Pavlov extends InteractionStrategy {
override def interactionType(cavemanID: Int): Interaction = {
interactionHistory.get(cavemanID).getOrElse(Negative)
}
override def interact(response: InteractionStrategy): (Int, Int) = {
val otherInteraction = response.interactionType(id)
val myInteraction = interactionType(response.id)
val interactionResult = interactionType(response.id).result(response.interactionType(id))
updateHistory(response, myInteraction, interactionResult)
interactionResult
}
def complementaryInteraction(interaction: Interaction) = {
interaction match {
case Positive => Negative
case Negative => Positive
}
}
private def updateHistory(response: InteractionStrategy, myInteraction: Interaction, interactionResult: (Int, Int)): Option[com.wlodar.virtues.Interaction] = {
if (interactionResult._1 > 0)
interactionHistory.put(response.id, myInteraction)
else
interactionHistory.put(response.id, complementaryInteraction(myInteraction))
}
}
val caveman1 = new Caveman(1) with TitForTat
val caveman2 = new Caveman(2) with TitForTat
val caveman3 = new Caveman(3) with TitForTat
val caveman4 = new Caveman(4) with Pavlov
val caveman5 = new Caveman(5) with TitForTat
1 : -155
2 : -155
3 : -155
4 : 34
5 : -151
Nie zadziała to tylko w jednym przypadku - jeśli TitForTat nie zajęły się cwaniakami
val caveman1 = new Caveman(1) with Pavlov
val caveman2 = new Caveman(2) with Aggresive
val caveman3 = new Caveman(3) with Pavlov
val caveman4 = new Caveman(4) with Pavlov
val caveman5 = new Caveman(5) with Pavlov
1 : -197
2 : 50
3 : -187
4 : -177
5 : -167
Wygląda na to, że najlepiej dla grupy będzie gdy najpierw odpowiednia liczba osób przyjmie strategie TitForTat by wyeliminować cwaniaków a następnie zmienią rolę na bardziej "pro-współpracującą".
Ok co mamy :
http://lubimyczytac.pl/ksiazka/66811/wywieranie-wplywu-na-ludzi-teoria-i-praktyka - to pozycja, którą podnieca się masa wanna-be managerów od pralek wydobywających z niej pseudotechniki wpływu i pseudo-zarzadzania. Co nie zmienia faktu, że książka jest w istocie swoistą skarbnicą wiedzy psychologicznej. Pamiętam kiedy pierwszy raz ja przeczytałem miałem tzw. moment "brainfuck" - "Jakim to ku*wa prawem moje zachowania kontrolują jakieś instynkty?".
A jednak. Książka porusza kilka ciekawych "praw" (zasada autorytetu - to trzeba zneutralizować jak najszybciej jeśli chce się eksplozji kreatywności w zespole). Jednym z nich jest Zasada wzajemności - która to tłumaczy dlaczego w tesco stoją sobie młode laski zapraszając na degustację. Jednym ze słynnych przypadków wspomnianych w książce jest akcja Hari kriszna (czy jak to się tam pisze) z dawaniem kwiatków na lotnisku i oczekiwaniem w zamian datku. Co by nie mówić zasada wzajemności a w zasadzie zasada współpracy jest zakorzeniona w ludziach i więle technik manipulacyjnych ją wykorzystuje.
Ok czyli mamy taki oto obraz : współpraca to naturalny stan grupy ale co jakiś czas pojawi się cwaniak ze strategią eksploatacji zasobów grupy. I ludzie wymyślili prawo aby temu przeciwdziałać - czy prawo działa? Na pewnow pewnych przypadkach może działać lepiej.
W 1968 niejaki ekolog Garrett Hardin opisał następujący problem - mamy ogólnie dostępne pastwisko - gdy każdy z mieszkańców wsi będzie maksymalizował swój zysk i wypasał wszystkie swoje krowy to trawa nie odrośnie i wszyscy stracą. W tym przypadku najlepiej wyjdzie jedna osoba, która łamie reguły podczas gdy inni ich przestrzegają.
Przypomnijmy zasady eksperymentu :
Jest to symulacja eksploatacji pastwiska. Gdy tylko jedna osoba to robi zyskuje ale gdy więcej osób zaczyna brać w tym udział tracą wszyscy. Eksperyment był bardzo ciekawy i można o nim sobie poczytać więcej :
I teraz poprzez analogię. Mamy sobie projekt IT, który jest oficjalnie własnością firmy. Firma sankcjonuje prawa, które są tak naprawdę ogólnikami "dbać o jakość", "dbać o dobro projektu". Można kontrolować każdy aspekt życia projektu podobnie jak można patrolować 24/7 każdy hektar lasu policyjnym helikopterem. Ani jedno ani drugie nie jest efektywne.
Przekazanie teamowi własności do projektu (oczywiście nie prawnej własności ale wykonawczej - czyli jakiej użyć technologii, jakiego repo itd) to początek. Inną kwestia jest edukacja. Jeśli np. Mamy populację kaczek, która jest traktowana jako własność lokalnej społeczności i faktycznie społeczność się nią opiekuje ale nie wie, że kaczek nie można karmić chlebem (słyszałem, że to im pęcznieje tam w brzuchu i zdychają) to pomimo, że każdy wykazuje strategię dobra ogółu to dojdzie do tragedii poprzez brak wiedzy. Podobnie gdy np. team nie rozumie konsekwencji wyboru konkretnej technologii wtedy potrzebuje zewnętrznej wiedzy - ale nie mylić tego z zewnętrznym kontrolowaniem!
To trochę tak jak przypadek kolesia, o którym ostatnio czytałem. Nie pamiętam nazwiska ale generalnie chodziło o to, ze w latach 70 poprzedniego wieku pojechał do wietnamu edukować ludzi w zakresie racjonalnego żywienia. Zamiast narzucać rozwiązania znalazł rodziny, które już być może nieświadomie respektowały reguły poprawnego żywienia i zadbał o to aby poprzez te rodziny odbyła się edukacja większej populacji. W korpo to by odbyło się poprzez zwołanie meetingu i wystosowanie nowych praw i regulaminów co w praktyce średnio działa. Kiedyś był u nas koleś, który chciał na siłę wprowadzić scalę - jedyne co mu się udało to skutecznie obrzydzić każdemu ten język. Kluczem tutaj jest racjonalna edukacja a nie nacisk.
Przekazanie mocy zespołowi może rozwiązać problem free riderów w grupie - czyli takich małych opierdalaczy gdy team pracuje - (no chyba, że wszyscy są nerdami jaskiniowymi i pojawi się jeden cwaniaczek z wysokim EQ - problem jaki może wyniknąć w przypadku tzw. zjawiska naturalnego lidera). Problem gdy grupa działa w narzuconej strukturze hierarchii i free riderem okaże się tzw manager czy tzw. lider. Tutaj nawet nie chodzi o opierdalanie się ale o maksymalizowanie zysków własnych kosztem grupy. Czyli np. wymuszanie na ludziach napieprzania po nocach dla realizacji jakiegoś nierealnego deadlinu. Manager ma premie, kod jest zjebany a ludzie wypaleni - jeśli to nie jest projekt z cyklu "tych złotych" to długookresowo firma traci.