Głuchy telefon

Głuchy telefon - intrygująca i dająca do myślenia zabawa z dzieciństwa, gdzie nawet bardzo prosta "informacja" może zostać zniekształcona po przejściu przez łańcuch "przekaźników".

Kultowy obrazek z huśtawką (który wszyscy znamy) obrazuje co dzieje się z informacją nieco bardziej wyrafinowaną (np. na temat wymagań) w procesie produkcji softu.

Jak temu zapobiec?
Racjonalnym rozwiązaniem jest Ubiquitous Language - kluczowa technika w Domain Driven Design polegająca na operowaniu wspólnym słownictwem domenowym na każdym poziomie abstrakcji: począwszy od eksperta biznesowego po kod źródłowy (sic!) w warstwie logiki aplikacji i logiki domenowej. W logice domenowej oczywiście obowiązuje ścisła "etykieta" - korzystanie z dobrze zdefiniowanych Building Blocks.

W tym miejscu dochodzimy do sedna posta.
Zachęcam do zapoznania się z prezentacją mego guru - Erica Evansa: "Sustainable Design for Agile Teams" podczas, której mamy próbkę sesji analitycznej pomiędzy programistą a ekspertem domenowym. Zwróćcie uwagę na dobrze zdefiniowany, wspólny język jakim posługują się obie strony oraz w jaki sposób "odkrywają" nowe byty.

Oczywiście taki proces nie jest tani oraz wymaga cennego zasobu: eksperta domenowego:/

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

Prezentacja porusza również inny, arcyważny aspekt: niezrozumienie projektowania domeny w naiwnym podejściu do Agile. Kiedy skupiamy się na pojedynczym wymaganiu lub na pojedynczej iteracji, wówczas zwykle mamy do czynienia ze specjalnym przypadkiem procesu biznesowego w jakiejś domenie. Gubimy "biger pikczer" i z czasem całość sprowadza się do radosnego (później smutnego) "hakowania" kodu opisującego jakieś specjalne przypadki - zaszłości. I nie ma co się oszukiwać - nikt nie jest skory do refaktoringu modelu domenowego, który jest już napełniony danymi w bazie:)

Konstruktor-Destruktor

Stara indiańska zasada mówi: na blogu zawsze lepiej wkleić linka do czyjegoś mądrego posta niż pisać coś samemu. Dlatego dziś polecam posta Jakuba Nabrdalika: Writer versus Constructor. Tekst trafia w sedno pewnej klasy problemów z developmentem softu.

Od siebie dodam, że jak zwykle rzeczywistość nie jest czarno-biała lecz szara. Programista klasy MacGyver (o którym pisał Joel Spolsky) jest pożytecznym skarbem w zespole, trzeba jedynie objąć go stałą kwarantanną.


EDIT:
Kontynuacja dyskusji: O programiście-pisarzu i programiście-konstruktorze, ciąg dalszy czyli: refaktoring po blogersku?

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

Przy okazji warto zwrócić uwagę nad konstrukcję samego posta - wzór do naśladowania dla wszystkich bloggerów technicznych.

Najpierw mamy krótką historię odwołującą się emocji (w tym wypadku z dzieciństwa), później uogólnienie i postawienie problemu. Dalej w rozwinięciu wypunktowanie konkretów. Wszystko ilustrowane perfekcyjnie dobranymi, klimatycznymi obrazkami Pipboya z Fallouta.

Brawo, brawo, brawo!

Java EE

Kilka dni temu ukazała się finalna wersja specyfikacji Java EE 6.
Jako, że żaden szanujący się blog Javowy nie może nie wspomnieć o tym doniosłym wydarzeniu, zatem niniejszym to czynię:
Proszę Państwa, mamy nową specyfikację Java EE!

Ok, formalności mamy za sobą. Teraz aby ten post jednak coś wnosił do sprawy i aby zachować niezależny charakter bloga pozwolę sobie polecić 2 linki stanowiące niejako rozliczenie dotychczasowych wersji platformy:

- Rod Johnson (twórca Spring framework) w prezentacji Lessons Learned From Java EE’s Evolution opowiada historię platformy, m. in. wpływ niesławnych twórców CORBY na jej kształt:) Człowiek, który zna na wyrywki całą specyfikację Java EE twierdzi, że jedyną dobrą rzeczą jest Servlet API.

- Misko Hevery (Agile Coach w Google odpowiedzialny za automatyzację testów) w swoim poście How to do Everything Wrong with Servlets twierdzi natomiast, że Servlet API jest przykładem bardzo złego designu, bardzo złego.

Aż strach pomyśleć do jakich wniosków doszliby obaj panowie dokonując koniunkcji zbiorów swoich poglądów.

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

Warto zwrócić uwagę na specyfikację JSF 2.0 (wchodzącą w skład Java EE 6), która wreszcie po latach będzie nieco bardziej pomocna do tworzenia aplikacji webowych. Przykładowo otrzymujemy oficjalne wsparcie dla szablonów (bez Feceletów jak bez ręki) oraz lepszą orientację na URL (taki mały szczegół webowy).

Geneza i ograniczenia OO

Dziś jedynie dwa linki, które uważam za godne polecenia.

Przeczytałem niedawno tekst, który lekko zachwiał moim światopoglądem: Aristotle's Error or Agile Smagile. Tekst traktuje ogólnie o historii - znajdziecie tam również rzekomą genezę Object Oriented.

Rzekomo pierwotnie wcale nie chodziło o modelowanie świata, lecz o zabawy ze stertą - co będzie gdy zamiast chwilowo przechowywać zmienne na stosie wrzucimy je na dłużej do sterty.

Teorię OO Analysis i OO Design rzekomo "dorobiono" później. Tak, tak, wiem - sam jestem w szoku podobnym do tego gdy wydedukowałem, że nie ma żadnego św Mikołaja;P

Nie wiem na ile historia o pierwocinach OO jest prawdziwa, ale tym razem wielki szacunek dla Uncle Boba za zdystansowane podejście.



Kolejny link to ciekawa prezentacja człowieka, któremu doświadczenie również pozwala zdystansować się od mainstreamu Are We There Yet?. Prezentacja pozwala uświadomić sobie ograniczenia OO oraz wyjaśnia (tym, którzy jeszcze tego nie widzą) dlaczego niektóre wydawałoby się proste języki wprowadzają wysoką złożoność (przypadkową).

Zobaczycie też jak bardzo podobne są do siebie języki, o które często spieramy się "który lepszy". Nie brakuje też aluzji do takich "przełomowych usprawnień" jak usunięcie średników:) Dowiecie się również z czego wg autora prezentacji wynika potrzeba posiadania testów:)

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

Od razu ostrzegam, że treści kryjące się pod linkami są mocno filozoficzne, ale może warto oderwać się na chwilę od kodu aby później móc spojrzeć na niego inaczej...

Nie ma rzeczy niemożliwych

/*Post rozpoczynający serię: żarciki branżowe*/

http://www.getacoder.com/projects/detect_loop_106243.html
...jak widać jest wielu śmiałków gotowych od ręki i za niewielkie pieniądze rozwiązać problem stopu.
Ba... nawet licytują się, kto zrobi to szybciej i taniej.

I nie straszny im dowód nierozwiązywalności; teoria jest dla filozofów - "because we can"!

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

Tradycyjnie tu powinien pojawić się mój własny komentarz. Jednak jako, że dziś wyjątkowo post z przymrużeniem oka to tym razem oddam głos temu panu:

Risercz: DDD

W związku z natłokiem spraw nie mam czasu aby napisać coś bardziej sensownego na blogasku. Właściwie to problem nie tyle z samym czasem co z mózgiem obciążonym zbyt wieloma wątkami, co w rezultacie skutkuje zanikiem weny - czyli impotencją intelektualną (wszyscy pewnie znacie to uczucie nieprzyjemnego napięcia, które odbiera kreatywność).

Aby jednak podtrzymać aktywność ucieknę się do prastarego triku i wkleję trochę linków, które ostatnio sobie przyswoiłem, i które to uważam za godne zauważenia.

Będzie to jednocześnie pierwszy z nowej serii postów - raporty/streszczenia z riserczu.



Dziś będzie o (niespodzianka) Domain Driven Design. Dwa artykuły opisujące mniej lub bardziej techniczne aspekty DDD. Tak, wiem, że DDD to filozofia i technikalia nie są ważne, ale ktoś kiedyś jednak będzie musiał wziąć się do roboty i zaimplementować nasze prostokąty i strzałeczki;P


Na początek ciekawe kompendium technologiczne na temat domain driven DEVELOPMENT:
Domain Driven Design and Development In Practice.
wszyscy narzekają, że owszem DDD fajne jest, ale jak tak na prawdę podejść do projektu? W treści znajdziemy wiele ciekawych pomysłów i alternatywnych koncepcji.
Powyższy link jest co prawda Made in India, ale mimo tego jego treść jest rzetelna - poza tym marka infoq do czegoś zobowiązuje.


Dla odmiany teraz coś Made in Germany. Niestety odmiana ma charakter przede wszystkim jakościowy:/
Domain-driven design with Java EE 6
Oto jak kończy się aplikowanie prymitywnej platformy do zaawansowanej koncepcji - naiwna implementacja.

Pomysł bram (gate) może i ciekawy... Na pewno wygodny z punktu widzenia programisty. Mamy oto coś na kształt stanowego servisu, który ma w sobie entity managera w trybie rozszerzonym. Dzięki temu możemy sobie korzystać z lazy lodingu podczas ping-ponga pomiędzy klientem a serverem. Prawie jak konwersacje w seam:)
I czy w ogóle jest o co walczyć? Ile czasu zaoszczędzę posługując się Lazy Loadingiem zamiast napisać sobie Repo, które będzie używane przez agregat w celu pobrania składników tegoż agregatu? A co z wydajnością Lazy Loadingu:P
Podsumowując: życzę powodzenia przy nieco większej ilości użytkowników hehe

Na uwagę zasługuje jednak nowy termin, który próbuje się ukuć "persistent domain object (PDO)" - podoba mnie się to:)
PDO czyli Agregat w sensie DDD (posiada stan i odpowiedzialność - metody biznesowe), który dodatkowo ubabrany jest adnotacjami JPA. Czyli wreszcie dojrzewamy aby odejść od proceduralnego rozdziału struktry danych od algorytmów (encje/servisy).
Niestety taki agregat przesłany do warstwy UI ciągnie za sobą metody biznesowe, które nie powinny być dostępne w tej warstwie.
Jednym z rozwiązań jest stworzenie 2 stosów warstw - opisane na końcu tego nudnego posta, innym są mixiny z frameworki qi4j.

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

Na zakończenie ciekawa refleksja: http://www.infoq.com/interviews/domain-driven-design-eric-evans#view_10448. Nasze community nauczyło się wreszcie korzystać z podstawowych technik (które podobno istniały juz w latach 80 w Smalltalk) i wreszcie ukonstytuowały się pewne standardy z zakresu projektowania i architektury.

W skrócie: community java powoli kończy etap onanizmu technicznego i można zacząć skupiać się na problemach na prawdę istotnych.

Natomiast z komentarza tego znamienitego dinozaura http://www.infoq.com/interviews/domain-driven-design-eric-evans#view_10653 wynika, że już prawie dotarliśmy tam, gdzie community Smalltalk było w latach '80...

Bottega

Przez ostatnich parę dni szukałem swojego dyplomu ukończenia studiów. Bezskutecznie przetrząsając różne szpargały natknąłem się na wiele "pamiątek" z czasów studiowania informatyki. Niestety, nie były to pamiątki budzące sentymentalne wspomnienia. O nie...

Były to kserówki podręczników akademickich, skryptów i wykładów. Z zaciśniętymi zębami (na granicy szczękościsku;) mogłem odświeżyć sobie nieco wiedzę o: całkach, równaniach, obwodach RLC, równaniach, pierścieniach, równaniach, ciałach, równaniach, niezmiennikach, równaniach, złożoności, równaniach, twierdzeniu Kołmogorowa, równaniach, nieskończonej studni potencjału, równaniach, śmiesznej notacji składającej się z prostokątów i elips przedstawiającej składnię Pascala (wszystkie diagramy umiałem na pamięć:] ), równaniach, postaciach normalnych i mój ulubiony killer: gradient dywergencji rotacji laplasjanu hamiltonianu:)))
Tresowanie szympansów na umiejętność przetwarzania symboli - iksy na prawą, ygreki na lewą.

Okazuje się, że można też inaczej: "Systems Development": a New Discipline for a New Education.


Bottega - pracownia renesansowego mistrza. Miejsce, w którym Leonardo i jemu podobni oddawali się twórczości. Miejsce, które dzięki swej aranżacji i zawartości stymulowało w sposób naturalny różne aspekty kreatywności. Miejsce, w którego centrum stał człowiek.

Bottega stała się w przenośni i dosłownie inspiracją dla twórców wspomnianego w linku eksperymentalnego kierunku studiów "Systems Development". Kierunku, którego credo zawarte jest w sugestywnym symbolu: "Software is our medium, Craft (Mastery) is our goal, People are our focus, Systems is our perspective, and Agility is our process." Bottega promuje raczej myślenie syntetyczne niż analityczne. Synteza wielu aspektów ludzkiej aktywności daje szansę na powstanie nowej wartości.

Dr. Dave West zauważa, że mimo postępu procesów i technologii nadal utrzymujemy dosyć żenujący współczynnik projektów zakończonych sukcesem. Jako jedną z przyczyn wskazuje przepaść pomiędzy tym, czego nauczani są studenci, a tym czego wymaga rzeczywistość.

Nie chodzi tutaj bynajmniej o prymitywne podejście i roszczenia wobec nauczania trendowych technologii czy języków. Nic z tych rzeczy, uczelnia nie ma przecież na celu przyuczenie do jakiegoś zawodu. Problem jest postawiony dużo głębiej. Aby w ogóle myśleć o tworzeniu systemów dla ludzi, wypadałby najpierw rozumieć systemy ludzkie... Ale nie będę streszczał i tak krótkiego artykułu - na prawdę warto przeczytać (inaczej chyba bym nie zawracał głowy;P).


Jakie mierzalne wyniki edukacyjne daje zmiana podejścia? Wystarczy przeczytać artykuł do końca:P

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

Heh... Humanizm... trochę wypaczono go ostatnio - humanistą jest każdy, kto nie potrafi liczyć, ale za to potrafi zapamiętać parę tysięcy stron kodeksów czy oficjalnej wersji historii;))).

Jak spieprzyć projekt?

może tak:
Project anti-patterns. How to make Your project fail

a może tak:
When Working Software Is Not Enough: A Story of Project Failure


//==============================
Dziś znalazłem 2 warte obejrzenia prezentacje. Myślę, że warto aby przynajmniej część z ponad 400 osób odwiedzających bloga je zobaczyła. Świat będzie dzięki temu lepszy;)

Pierwsza prezentacja jest pełna sarkastycznego humoru (taki lubię najbardziej), świetnie się ją ogląda.
Najbardziej przypadł mi do gustu rozdział 53. "Bob budowniczy" (wszystko rozpierniczy).
Druga prezentacja jest ciekawa, ale do połowy, później zaczyna się z niej wylewać osobiste rozgoryczenie, które radzę sobie darować.

Nawróćcie się;)

Dzisiaj mały post (właściwie to wypychacz bo zbieram materiały na 2 większe) z serii ciekawych linków.
Allen Holub jest niestrudzonym ewangelizatorem Object Oriented i wzorców projektowych.
Co prawda część jego poglądów zamieściłem w jednej z prezentacji, ale teraz znalazłem ciekawe i godne polecenia kompendium dla młodych adeptów OO: Everything You Know is Wrong.

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

Myśli warte uwagi:

• obiekty to nie dane+procedury zgromadzone w klasach aby nie rozsypywały się po pamięci
  
• Gettery i settery są złe ponieważ naruszają enkapsulację (o zgrozo często wymienia się je jako definicję enkapsulacji!)
  
• nie pytaj o dane, żądaj wykonania
  
• dziedziczenie jest oczywiście złe:)
  
• ciekawe połączenie modelu i GUI przy pomocy wzorca budowniczego (strona 7)
  
• parę błędów projektowych w API Javy;P
  

I najważniejsze przesłanie Allena: Don’t confuse familiar with “right”.

Tao DDD

W myśl starej chińskiej zasady "lepiej wkleić linka do mądrego posta niż wydurniać się samemu":

"There is technically nothing new or revolutionary in DDD, there is only a guide to a better way of thinking."

//================
Przy okazji znalazłem Domain Driven Design Quickly w razie gdyby komuś nie chciało się czytać Evansa.

Dobrze gada, polać mu wódki

Wróciłem właśnie z wakacji...
hehe bez obaw, nie będę zanudzał czerstwym sprawozdaniem z urlopu:)

Jednak zmęczenie podróżą nie pozwala mi na napisanie niczego poza wklejeniem linku do ciekawego posta o Composite Oriented (Qi w szczególności): Qi4J the next Java? Forget Scala.

//===========================
Myśli warte uwagi:
- wrzuty na Eckela:)
- business logic - kto programował komercyjnie i ma zdolność choćby do odrobiny refleksji ten pewnie rozumie, że to właśnie BL rozwala projekty (jeżeli jeszcze nie wersji 1.0 to na pewno w 3.0) i że wypasione GUI i baza w 5. postaci normalnej nic tu nie pomogą
- misterność i pomysłowość nie mają mają nic wspólnego z młotkiem