Feedback - publikacja artykułów

Zapraszam do lektury nowej serii artykułów z działu Laboratorium Bottega jaki prowadzimy od początku istnienia Magazynu Programista.

Aktualnie dostępne są dwa pierwsze teksty poświęcone naszym eksperymentom z "Brakującym elementem Agile": http://bottega.com.pl/artykuly-i-prezentacje#agile

Paweł Badeński dzieli się swoimi doświadczeniami na temat feedbacku, które zdobył jako coach zespołów w ThoughtWorks, gdzie był odpowiedzialny za "misje ratunkowe" polegające na zmianie systemowej kultury pracy np. w projektach IT rządu UK.

Statystyczny człowiek dostaje w ciągu roku ok 17 minut pozytywnych informacji na temat siebie i swego zachowania. Łatwo przychodzi nam krytykowanie (źle przeprowadzone działa na cały zespół niczym sarin), ale pozytywny feedback dostajemy zwykle jedynie od babci;)

Co może zdziałać pozytywny feedback? Np. wyciska łzy u dorosłych mężczyzn ostatniego dnia warsztatów, odbudowuje morale i motywację... i takie tam... kluczowe ze strategicznego punktu widzenia sprawy:)

//=============================

W kolejnych częściach serii zajmiemy się między innymi:

• komunikacją z biznesem - miękkie techniki prowadzenia sesji modelowania wspierające DDD
• odbudową morale i motywacji
• problemami z utratą pracowników i pozyskaniem na ich miejsce nowych 

Microservices w kontekście DDD

Mamy nowy buzowrd: mokroserwis, który zdążył być już w typowy da naszej branży - Montypythonowy - sposób wypaczony:)

Autor artykułu Microservices: Usage Is More Important than Size stawia retoryczne pytanie:
czy mikroserwis to
- SOA, które wreszcie doczekało się poprawnej interpretacji (bez ESB i smutnego SOAP)
- czy może stara "dobra" CORBA i RMI tylko, że podana na REST wraz ze wszystkimi smutnymi konsekwencjami zbytniego rozproszenia?

Kolejne figury retoryczne pojawiają się w tekście Microservices? What about Nanoservices?: Sto linijek to jeszcze makro-serwis czy już nano-serwis (funkcjonalność a nie serwis), który jest antywzorcem?

Mierzenie linijek kodu od linijki to jak zwykle znak, że "coś się dzieje";)

Patrząc z dystansu widać to co zwykle: onanizm techniczny zamiast zrozumienia jaki problem próbujemy rozwiązać.

Wydaje mi się, że gdyby za definicję zakresu mikroserwisu przyjąć: API dla Bounded Context z DDD, to wszystko stałoby się jasne...

Rozrywka intelektualna na długi łikend

MBTI jest prostą typologią stosowaną w różnych celach, np podczas projektowania architektury informacji w dużych serwisach internetowych.

My w IT lubimy proste modele (dają nam złudzenie rozumienia hehe) dlatego proponuję krótką zabawę:

1. Kilkuminutowy test
2. Luźna interpretacji w kontekście programowania http://c2.com/cgi/wiki?MyersBriggsForProgrammers
- ulubiony język programowania
- ulubiona klasa problemów
- ulubiony sposób myślenia
- itd


MBTI bywa krytykowany za metodykę statystyczną. Jako ciekawostkę dodam opinię twórcy portalu jednego z telecomów: nie ważne czy MBTI jest prawdziwy czy nie, i tak prędzej czy później stanie prawdziwy, gdyż zawartość w wielu miejscach jest projektowany pod tym kątem i ludzie po prostu zaczną myśleć wg tych schematów - rodzaj samospełniającej się przepowiedni.

//===========
Mój typ to "Puszczyk".

Kolejne materiały z 4Developers: Spring Boot, CD, Xamarin, Feedback

Kuba, Łukasz, Piotrek i Paweł - trenerzy, z którymi współpracuję pod marką Bottgea - udostępnili swe prezentacje, zapraszam:

W kategorii Inżynieria oprogramowania:
- Jakub Kubryński (ekspert JVM i tuning) - Spring Boot – framework for micro services
- Łukasz Szydło (ekspert Java i tools) - Enabling Continuous Delivery
- Piotr Karczmarz (ekspert .NET i arch.) - MVVM pattern in cross-platform architecture based on Xamarin

W kategorii Tematyka miękka:
- Paweł Badeński (ex ThoughtWorks, człowiek Agile) - Feedback

Artykuł: Techniki ułatwiające utrzymanie testów

Zapraszam do lektury kolejnego artykułu Rafała Jamroza z serii: Refaktoryzacja testów legacy w kierunku wykonywalnych specyfikacji.

Cytat ze wstępu: "W artykule przedstawiam techniki, które pomogą w pracy z testami w projekcie legacy (i nie tylko), a które profesjonalny programista powinien mieć w swojej „skrzynce z narzędziami”, czyli m.in. Test Data Builder i Assert Object. Mimo to należy pamiętać, że zrozumienie problemu, nad którym pracujemy, jest znacznie ważniejsze niż stosowane techniki i powoduje, że testy posiadają jeszcze większą wartość"

Materiały z konferencji 4Developers

Linkuję obiecane materiały:

• Prezentacja Mapowanie relacyjno-obiektowe prawdziwych obiektów
• Prezentacja Jak wciągnąć eksperta domenowego w wir modelowania - wizualne i lingwistyczne techniki DDD
• Przykładowy projekt: DDD Leaven v2

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego

Na YT opublikowano moją prezentację z zeszłorocznej konferencji JDD: https://www.youtube.com/watch?v=znRByMgnFSM

Czego możesz się z niej dowiedzieć:
- jeżeli testy używają Mocków "to wiedz, że coś się dzieje"
- jeżeli w typowym projekcie biznesowym dąży się do pokrycia 80% "to wiedz, że coś się dzieje"
- jeżeli testy akceptacyjne są napisane językiem kontrolek UI  "to wiedz, że coś się dzieje"
- jeżeli widzisz (anty) wzorzec Page Object "to wiedz, że coś się dzieje"
a poza tym testy end-to-end powinny mieć warstwy - jak wszystko:)

...oraz jak działają automatyczne skrzynie biegów w super-samochodach.


Materiały: http://prezi.com/cxslyh5sqo_z/czego-mama-nigdy-nie-mowia-ci-na-temat-testowania-automatycznego/