niedziela, 17 marca 2013

33rd Degree - najlepsze antytrole i inne notatki

Poniższe notatki dotyczątej konferencji ------------------> http://2013.33degree.org/

Najlepsze anty-trolle

Najlepszy anty-troll to zdecydowanie odpowiedź Teda Newarda :

two minutes in the corner for being stupid..... I'm waiting"

Generalnie struktura jest na tyle uniwersalna, że powinna zwalczyć 90% występujących troli.

Inna ciekawą technikę odpowiedzi na zabarwione trollem pytania zastosował Dan North. Mechanizm jest bardzo prosty - polega na powtórzeniu pytania niekoniecznie słowo w słowo i natychmiastowej odpowiedzi. W efekcie wyglądało to tak jakby prowadzący w ogóle nie musiał zastanawiać się na odpowiedzią, tłum miał zabawę a pożerająca czas prezentacji trollo-konwersacja została zneutralizowana..

Sam temat, który był pod trollo obstrzałem jest sam w sobie ciekawy i pewnie dla niektórych nieco kontrowersyjny. Otóż ktoś kto sam wymyślił trzyliterową technikę - BDD - obalił trochę absolutność innego trzyliterowego skrótu -TDD. Już nie trzeba się wstydzić tego, że czasami na chwilę w klasie pojawi się main z próbką kodu albo o zgrozo napiszemy jakiś kawałek kodu a test dopiero później - teraz to ma nazwę - spike and stabilize

Co ciekawe cała akcja z tym TDD doskonale podchodzi pod to co Vankat Subramanian opowiadał ostatniego dnia w kontekście padających imperiów i efektu "rewolucji poprzedzającej stagnację". Generalnie TDD jest bardzo dobre bo nie pozwala na rozlanie się morza gównianego kodu ale jeśli ktoś kurczowo trzyma się tej techniki i oddaje jej cześć na każdym kroku to trochę tez wpada w kategorię ciemnogrodu.

Ciekawostki psychologiczne - strach przed nieznanym

http://en.wikipedia.org/wiki/Ellsberg_paradox - w skrócie: mając do wyboru dwa rozwiązania większość ludzi podświadomie zakłada, że rozwiązanie z większą ilością niewiadomych jest gorsze lub bardziej ryzykowne. Na wykładzie był przykład z dwoma urnami - w jednej jest tyle samo piłek białych co czarnych - o drugiej nic nie wiemy. Bez względu czy pytana osoba ma wyciągnąć białą czy czarną piłeczkę to zawsze podświadomie założy, że stosunek piłek w nieznanej urnie jest na jego niekorzyść.

W naszym IT objawia się to trzymaniem się starych rozwiązań a w życiu codziennym będziemy woleli stać w korku na znanej drodze aniżeli ryzykować jazdę skrótem. I to na szczęście nie jest zawsze prawdą gdyż niektórzy mają taką oto cechę ---> http://en.wikipedia.org/wiki/Novelty_seeking ale niestety niektórzy będą przez całe swoje życie codziennie wegetować w dniu świstaka.(chociaż kto tak naprawdę może decydować o tym co jest dobre a co niedobre...)

Ciekawostki psychologiczne - głupota grupowa

http://en.wikipedia.org/wiki/Asch_conformity_experiments - w eksperymencie brało udział 12 osób - z czego 11 podstawionych. Owe ustawione osoby zawsze wybierały tę samą błędną odpowiedź na pytanie "które linie są tej samej długości". Podobno to wystarczyło aby w większości przypadków ostatnia osoba - która nie była podstawiona - również wybrała błędną odpowiedź. Nie jest to pierwszy przykład tego, że ludzie w kontekście grupy/społeczeństwa zachowują się czasami jak debile (bo jak to inaczej nazwać). Temat jest na tyle ciekawy,że wymaga osobnego wpisu.

Myślenie grupowe na wiki ---> http://en.wikipedia.org/wiki/Groupthink

Blue Green Deployment

W Toyota Way przykładem waste były produkty zalegające w magazynach. W IT takim marnotrawstwem jest funkcjonalność, która zamiast robić pieniądze na produkcji zalega w szafie i czeka aż ktoś ja łaskawie wdroży (przy okazji przejdzie 1500 bramek wprocesie). Od jakiegoś czasu pracuję nad Doktryną natychmiastowej wartości biznesowej czyli po prostu redukcji do zera czasu gdy funkcjonalność oczekuje na wdrożenie. Aby to zadziałało trzeba znaleźć sposób na wgrywanie funkcjonalności bez zatrzymywania serwerów na produkcji gdyż to by zbytnio wkurwiało użytkowników. Jedyną zaletą niewiedzy są te magiuczne momenty gdy dowiadujesz się, że ktoś już miał podobne problemy i chyba znalazł rozwiązanie. Poniżej tzw "Blue Green Deployment". Na rysunku wygląda prosto - w rzeczywistości będzie pewnie niezwykle trudno ale jest przynajmniej jakiś nowy cel życia...



Do tego do obadania jest to ------> http://flywaydb.org/ - może będzie lepsze od liquibase.

Dwa fajne screeny na koniec

3 komentarze:

  1. "może będzie lepsze od liquibase"

    rozwinąłbyś temat? w pracy właśnie zaczynamy to wdrażać, więc jeżeli okazałoby się, że to narzędzie powoduje więcej problemów niż rozwiązuje, to taka wiedza mogłaby ograniczyć zakwaszenie organizmu niejednego dewelopera (nie żeby od razu rzucili się na sałatę i marchewki, ale stresu mogłoby być mniej) :)

    OdpowiedzUsuń
  2. Cze, Liquibase jest na pewno lepsze niż "nic" (i lepsze niż jakieś pseudotechniki numerowania skryptów SQLowych, które w swoim życiu widziałem).

    Przez długi czas to narzędzie sprawdzało się świetnie ale świat się zmienia i nadchodzą nowe doktryny. Gdy releasy robiliśmy raz dwa miesiące to było jak znalazł - ładnie kontrolowało zmiany schematu bazki a przede wszystkim pilnowało tego jaka wersja jest na jakim środowisku.

    Problem zaczyna się pojawiać gdyż chcesz robić częste rilisy. Jak raz na jakiś czas generujesz skrypt migracyjny to testowanie tej operacji jakoś bardzo nie boli - przy częstych releasach to zaczyna przeszkadzać. Jak na razie liquibase nie pomogło nam w 100% z tym problemem dlatego szukamy alternatywy - oczywiscie może się okazać, że źle tego narzędzia używamy dlatego podziel się swoimi wdrażaniami jak już je wrzucisz do swojego projektu ;)

    OdpowiedzUsuń
  3. Dzięki za odpowiedź.

    Na razie używam LiquiBase'a od tygodnia i początki są trudne:) Ale się przyzwyczajam. Nie było jednak jeszcze żadnego releasu, więc to przede mną. Zobaczymy...

    OdpowiedzUsuń