Core dump

Na prawdę warto przeczytać: https://geekyprimitives.wordpress.com/2016/08/13/frameworks-libraries-languages-and-deconstructing-bullshit/

Prezentacje z Devoxx

W dniu poprzedzającym konferencję wstałem o 5 rano i udałem się...

STOP!
To nie będzie sprawozdanie z wycieczki do muzeum z IV klasy

Dzięki dobrej woli Grześka Dudy mamy dostęp do pełnych prezentacji już miesiąc po konferencji.

Lista moich faworytów:

Neal Ford - Why does Yesterday's Best Practice Become Tomorrow's Antipattern?

Piękne, wysokopoziomowe ujęcie naszych przyziemnych problemów.

Wojciech Seliga - Ten lessons I painfully learnt while moving from software developer to entrepreneur

Wojtek ma niesamowity talent do trafiania w punkt z refleksją i radą. Myślę, że powinien spisać je w formie dedykowanej strony "poradnikowej" albo apki, która losowo codziennie przypomina jedną mądrość (poważnie bez kszty sarkazmu). Sam złapałem się na większości punktów przypominając sobie własne błędy popełnione i popełniane w firmie.

Neal Ford - Evolutionary Architectures

ThoughtWorks buduje swój techniczny wizerunek poprzez "kronikarzy". Fowler jest jednim z nich, ale Neal zdradził, że nowe osoby pracują nad książką będącą almanahem architektonciznym.

W pewnej części pracujemy nad tym w firmie - zestaw metryk i wytycznych architektonicznych. Wiele osób pyta o takie materiały podczas szkoleń i po prezentacjach, wytyczne przydają się również podczas audytów.

Dobrze, że TW oficjalnie rekomenduje bounded context z DDD jako wsparcie w określaniu granicy Microservisów (bez tego całość nie ma sensu i jest skazana na porażkę).

Wydaje mi się, że w wywodzie Neala brakuje jednego elementu, który mówi jak konkretnie podejść do decouplingu: https://en.wikipedia.org/wiki/Connascence_(computer_programming)
Podejście, o którym mówiłem na tegorocznej Confiturze i podlinkuję jak tylko pojawi się video.

Ted Neward - Pragmatic Architecture

Głos sumienia architektów - chało by się rzec:)

Bardzo podoba mi się definicja architektury jaką podaje Ted:

Architektura to zestaw odpowiedzi jakie dajemy zanim programiści je zadadzą. Zasady jakie go prowadzą w codziennej pracy a nie prostokąty.

Osobny problem to: jak te odpowiedzi dokumentować? Swoją propozycję również przedstawię we wspomnianej prezentacji z Confitury.

Kolejna ciekawa myśl to metafora architekta. W IT potrzeba lidera. Ted proponuje metaforę dyrygenta lub w przypadku małego zespołu frontmana, ew. reżysera.

Łukasz Szydło - Preconditions for good code review

Krótka prezentacja, która rzuca świeże światło na sensowne CR, które dają realną zmianę.

Bartek Nowakowski, Kuba Marchwicki - Niańczenie programistów vs. zarządzanie dziećmi

Flow może jeszcze do dopracowania, ale urzekła mnie paralela, którą budują prelegenci - niespodzianka  na samym końcu.

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

A tutaj moja skromna prezentacja:

Prezentacje i wystąpienia - jak nie tylko przetrwać ale i dobrze się bawić

Przy okazji dziękuję wszystkim, którzy głosowali za miejsce w pierwszej dziesiątce wśród tak znakomitego grona. Dzięki!:)

Slajdy - gdyby ktoś potrzebował.

Jak rekrutować analityka do zespołu lub projektu

Zapytajcie go na czym polega praca analityka.
Moim zdaniem na tym: http://it-consulting.pl/autoinstalator/wordpress/2016/05/03/wiedza-a-nauka-i-prawda

Systemy złośliwe

"Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle „problemami złośliwymi” (Rittel i Webber, 1973). „Problem złośliwy” to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania."

Znalezione u Jarka: TDD – czy same testy to wymagania? który argumentuje jak zwykle celnie i bez potrzeby dobijania drugim strzałem:)

Korzyści z DDD z punktu widzenia właściciela firmy softwareowej

... i jej klientów.

21 lat po wzorcach

Na kanale JDD pojawiła się prezentacja Ralpha Johnsona - jednego z autorów klasycznej i znanej chyba każdemu programiści pozycji http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Książka (i jej pochodne) ukształtowała mnie, community Java i .NET, część pokolenia...
Dzięki niej zaczęliśmy myśleć innymi metaforami niż uczono nas na uczelni. U mnie osobiście "namacalne" metafory każdego wzorca rozwinęły spojrzenie kinestetyczno-wizualne na strukturę kodu, które do tej pory jest podstawą mojego poczucia estetyki. Z czasem wzorce odpinamy jak boczne kółka w rowerku, ale sam sposób budowania myśli i komunikowania się z zespołem pozostaje.

Ralph opowiada o tym co motywowało autorów oraz o zmianach jakie poczyniłby w drugiej edycji od strony merytorycznej jak i co do formy.

Generowanie diagramów architektonicznych w C4

Jestem wielkim fanem podejścia C4 w dokumentowaniu architektury - co widać na video w poprzednim poście:)

C4 sprawdza się nie tylko dla nowych projektów oraz do nadawania struktury myślom podczas szkoleń... przydaje się również jako "mapa" podczas misji ratunkowych w projektach ze spuścizną:)

Polecam świetną prezentację twórcy C4 na temat narzędzi do automatycznego generowania diagramów. Moim zdaniem generowane nie mają takiej wartości w opowiadaniu historii jak ułożone ręcznie, ale lepsze taki niż żadne aby przedzierać się przez spuściznę:)

Prezentacje jest wartościowa z uwagi na przemyślane komentarze autora z meta-poziomu: kiedy, dlaczego i po co warto stosować dany rodzaj informacji wizualnej oraz rysowanie czego nie ma żadnej wartości:)

https://www.youtube.com/watch?v=oDpdaXt0HQI


//=================
W dużych projektach dodaję M (jak Moduł) tworząc Context Container Module Component Class
gdzie moduł grupuje komponenty.
Moduł można sobie wyobrazić jako jednostkę logiczną (Bounded Context z DDD) czy jako produkt (np. moduł magazynowy czy sprzedaży w ERP) a komponent jako np jednostkę deploymentu (np. klienty, AI itd).
Traktowanie komponentu dosłownie jako @Component w Springu (jak pokazuje przykładowo Brown) wydaje mi się skrajnie niepraktyczne poza malutkimi systemami, ale każdy może sobie popróbować sam co ma dla niego wartość...