Turbo Seam

Niniejszy post rozpoczyna mini serię poświęconą Seam Framework. Zawartość to kilka przydatnych technik oraz kilka trików, które udało mi się zebrać podczas paru lat używania tego "ficzer"-worka.

Spis treści

- Produktywne środowisko developerskie. Hot deploy wszystkiego. Nawet encji (a podobno się nie da;P) W najgorszym przypadku 3 sek. na przeładowanie.
- Integracja z Maven - elegancko i bezboleśnie. Panom od JBoss Tools już podziękujemy...
- Integracja z jQuery - gdy ciężar RichFaces przygniata, narzut na komunikację AJAX osłabia a kontrolki wyglądają jak z poprzedniej epoki
- Asynchroniczny mailing w dobrym stylu - mikro architektura rozsyłania maili połączona z eleganckim decoupliniem poprzez zdarzenia
- Integracja z BIRT - speszyl haki
- Seam Gen i Seam App. Framework - dlaczego nie używać:)


Powyższa lista będzie sukcesywnie aktualizowana o linki do konkretnych postów oraz ew. nowe pozycje. Docelowo post będzie stanowił swego rodzaju spis treści.

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

Generalnie do tej pory nie pisałem zbyt wielu postów technicznych - wychodząc z założenia, że w oceanie treści nie będą wnosić nic nowego.

Jednak zestawiając dwa aspekty:
- własne przemyślenia
- obserwując jak Seam jest używany
doszedłem do wniosku, że zgromadzona wiedza może się komuś przydać.

Jeżeli macie jakieś tematy, które chcielibyście poruszyć - piszcie śmiało, być może dodamy je do listy.

Przyczyna całego zła

Dziś kolejny post z serii geek humor.

Prawdopodobnie odkryłem przyczynę całego zła w projektach, bałaganu, złego designu modelu obiektowego i naszego ulubionego kodu spaghetti.

Jest nią najprawdopodobniej totalnie niezrozumienie polimorfizmu!

Tutaj znajdziemy oświecenie: http://www-users.mat.umk.pl/~grzegorz/polymorphism.pdf
.. gdyby tak każdy programista się z nim zapoznał, to świat byłby lepszy;)

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

Jeżeli macie jakieś ciekawe materiały edukacyjne to wklejajcie w komentarzach.

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:)

Pomożecie?

Dzisiejszy post jest nietypowy, ponieważ zwracam się w nim do szanownego grona czytelników z prośbą o pomoc/przysługę. Zostałem zaproszony na tegoroczną konferencję JDD w roli prelegenta i zastanawiam się nad tematem, który mógłby Was potencjalnie (nawet jeżeli nie wybieracie się na konferencję, po prostu ogólnie) zainteresować.

Prezentacja poświęcona Software Craftsmanship i Wzorcom już osiągnęła limit reużywalności, dlatego zastanawiam się nad nowym tematem:) Jeżeli macie jakieś sugestie lub konkretne życzenia odnośnie tego o czym chcielibyście usłyszeć to piszcie śmiało w komentarzu lub na priv (adres w panelu "o mnie" po prawej stronie).

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

Patrząc na ogólne trendy, które w tym roku widać również na polskich konferencjach, można zaobserwować, że raczej odchodzi się od zachwalania kolejnych tuzinów frameworków webowych w stronę zagadnień bardziej ogólnych, zwykle syntetyzując przekrój kilku aspektów. Ciekaw jestem co myślicie o tym trendzie.

Póki co mam pewien pomysł na prezentację poświęconą podejściom do Inversion of Control. Tak, wiem, że temat jest oklepany ale co powiecie na przegląd architektur aplikacji opartych o IoC. Przegląd będący swego rodzaju wycieczką po rozwiązaniach architektonicznych.

Najpierw zastanowilibyśmy się czym w ogóle jest architektura, jakie są jej rodzaje i czym arch. różni się od designu. Później wycieczka po kolejnych podejściach do architektur opartych o 3 techniki IoC w kolejności ich "siły".

Czyli najpierw "najsłabsze" (w sensie siły a nie w sensie, że jest kiepskie) podejście: wstrzykiwanie zależności - co i kiedy warto wstrzykiwać. Bo wstrzykiwanie DAO/Repo do Servisów jest nudne.

Dalej technika "mocniejsza" - bo abstrahująca nie tylko od typu współpracownika, ale i ich ilości oraz czasu - arch. zorientowana na zdarzenia. Przykłady wykorzystania zdarzeń do zwiększania przepustowości oraz do notowania "wydarzeń" biznesowych - wszystko w kontekście event sourcing i Command-query Responsibility Segregation.

Na zakończenie najsilniejsza technika IoC: Aspect Oriented Programming.

Na każdym "przystanku" naszej wycieczki zastanowilibyśmy się co wynika z zastosowania danego podejście i kiedy warto z niego skorzystać - a kiedy jest to tylko moda i owczy pęd.

Jak widać z opisu prezentacja była by przeznaczona dla początkujących architektów aplikacji - programistów, którzy chcieliby zając się projektowaniem w skali makro.

Bo w życiu trzeba... być Agile:)

Od dzieciństwa słyszmy ze strony różnych "dobrych wujków" co jest "w życiu ważne". Niestety rzadko zdarza się usłyszeć o adaptacyjności czyli życiowej zwinności (w sensie agilności).

Jadnak jakimś cudem w IT wszyscy są Agile - jakiś czas temu robiłem mały research, podczas którego z trudem znalazłem jedną firmę, w Indiach, która otwarcie mówi, że nie jest Agile;)

Gdy jednak przyjrzeć się bliżej, to z tym Agile jest jak z seksem u nastolatków - każdy o tym mówi ale niewielu tak na prawdę to robi (a przynajmniej tak było kilkanaście lat temu w klasach mat-inf;)
Mówi się, że Agile jest trudny ponieważ z pozoru wydaje się łatwy - tak łatwy, że wszystkim wydaje się, że zrozumieli.

W niniejszym poście nie będę pisał o problemach z metodykami (przy okazji: metodologia to nauka o metodykach). Skupimy się na materii miękkiej, czyli problemach z ludźmi.

Jak często napotykacie niemal faszystowskie, anty-adaptacyjne postawy typu:

- nie pisz komentarzy, pisz samo-komentujący się kod (ale samo-komentujący z czyjego punktu widzenia?)
- dobry kod powinien mieć 70% komentarzy tak aby dało się go odtworzyć czytając je (ale po co?)



- Stories są lepsze/gorsze niż Use Case (na jakim poziomie?)


- YAGNI i KISS (nawet jeżeli mam intuicję, że się przyda?)


- Java rules/.NET rules (ale czym to się różni?)

- zawsze używajmy IoC i ORM (ale dlaczego i po co?)
- ORM to badziewie, tylko SQL w procedurach (ale jakim kosztem?)

- jak baza to tylko Oracle/Postgres/...  (ale do każdego projektu?)
- jak baza to tylko noSQL (bo jest sexi?)

 - zawsze pisz testy - "you are not allowed to write a single line of production code without test first" - grzmiał jakiś czas temu Uncle (nomen omen;) Bob
- powinieneś mieć co najmniej 80% pokrycia testami (a dlaczego nie 85%? settery też?)
- nie pisz testów nigdy (nigdy?!?)

- metody powinny mieć 5 linijek (za 6 pójdę do więzienia?)
- metody powinny być tak długie, że powinno dać się je zrozumieć w 5 minut (ale zrozumieć przez kogo)

- zawsze używaj Mavena (nawet w jednomodułowym projekcie z 10 libami?)

- statyczne języki są lepsze (lepsze do czego?)
- dynamiczne języki są lepsze (szczególnie jak do klasy String dokleję sobie 150 metod


- przeglądarka/system/IDE X jest lepsze (lepsze do czego? mówisz to aby pomóc czy aby się podroczyć?)

Można by tak mnożyć w nieskończoność...

Nie wiem czy jest to przypadłość jedynie naszej branży, ale tym co hamuje Agile w procesie jest Autorytaryzm w ludziach. Być może autorytaryzm jest ogólnym memem "odziedziczonym" po wspomnianych w pierwszych zdaniu wujaszkach. Być może jest on wbudowany w nasze ścisłe umysły jako ich integralny ficzer - taki koprocesor poszukiwania jednego, naiwnie prostego równania na wszystko.


O ile mamy coraz więcej KNOW HOW to często brakuje KNOW WHEN.


Można ująć to inaczej: w równaniu

Mądrość = Wiedza + Kontekst

najważniejszy jest kontekst. Kontekst jest tym co odróżnia teorię od praktyki. Kontekst pozwalający zaadaptować wiedzę. Kontekst, który w Modelu Kompetencji Braci Dreyfus pojawia się z czasem, z doświadczeniem. A doświadczenie to refleksja. Refleksja jest konieczna do adaptacji podejścia.


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

W większości cywilizacji konsekwencja jest cnotą. Zwrot "nie jesteś konsekwentny w swym postępowaniu" ma mocno pejoratywny wydźwięk.

Ale bardziej Agile jest inne podejście - podejście adaptacyjne: "Konsekwencja jest fortecą głupców". Konsekwencja zwalnia z obserwowania, myślenia i dostosowania się (nie należy mylić konsekwencji z wytrwałością).

Nie chodzi o to aby zafiksować się na czymś, spuścić głowę i konsekwentnie ryć niczym świnia za truflami. Co jakiś czas warto ją podnieść sprawdzić czy cel jest jeszcze wciąż na wprost - a może na horyzoncie pojawił się inny, lepszy cel i warto się zaadaptować?

Object Oriented czy jedynie Class Oriented?

Dziś będzie o "nowym" podejściu do Object Oriented.
Jeżeli komuś wydaje się, że już nic nowego nie można w tym jakże oklepanym temacie dodać, to zachęcam do zapoznania się prezentacjami zawartymi w tekście. Dowiecie się również dlaczego nowym napisałem w cudzysłowie.

Od jakiegoś czasu z wielu stron pojawiają się zachęty do zainteresowania się nowymi językami, takimi jak Scala, Groovy, Ruby,...

Do tej pory wszyscy orędownicy pokazują jak to fajnie można sobie operować na kolekcjach (sortować, wyszukiwać) w jednej linijce kodu dzięki możliwości "doklejania" nowych metod do istniejących klas. Z całym szacunkiem, ale jest to nic innego jak objaw onanizmu technicznego. Jeżeli mam zainteresować się nowym językiem tylko po to aby uniknąć klepania pętelek to jednak zastosuję "cwanego" utilsa. Czy aby na pewno nowe języki powstają tylko po to aby sobie dokleić do klasy String 100 nowych metodek, o których istnieniu wie tylko doklejający?

Jeszcze inni odkryli ponownie możliwość dynamicznego dodawania "w locie" do encji metod zapisujących i wczytujących je. Myślałem, że niesławny Active Record odszedł już dawno w niepamięć. Ale jednak nie - okazuje się, że jest sexi w niektórych frameworkach.

Podczas niedawnej sesji researchu trafiłem na ciekawą koncepcję, która nadaje prawdziwy i pragmatyczny sens tym wszystkim konstruktom językowym.Pojawił się oto "nowy" paradygmat programowania: Data Context Interaction, który wskazuje zastosowanie dynamicznych konstruktów do lepszego (a przynajmniej innego) modelowania problemów. Czyli mamy coś więcej niż sortowanie listy, mamy nową jakość myślenia o modelowanej strukturze.

Twórcy DCI twierdzą, że mainstreamowe podejście do OO to jedynie kilka % prawdziwego OO. Klasyczne podejście skupia się na klasach, czyli na pewnych strukturach. Stawiają oni klasycznemu podejściu zarzuty, że skupia się ono na klasach zamiast na obiektach, co jakoby powoduje "rozsmarowanie" logiki Use Case po wielu klasach, dzięki czemu w nietrywialnych aplikacjach z czasem coraz ciężej przychodzi połapanie się w logice.

Czy zatem czas na powrót do paradygmatu proceduralnego, gdzie mamy cały "flow" w 1 miejscu?
Niekoniecznie.
Spójrzmy ma poniższy rysunek:


źródło: http://www.underbjerg.com/2009/11/16/oredev-2009-impressions-and-dci-architecture/

Dane opisują przy pomocy Klas pewną niezmienną strukturę - można powiedzieć core modelu (może mieć on pewne bazowe, ogólne zachowania).
Interakcje są wyniesieniem zachowania do poziomu głównych bytów, dzięki czemu lepiej odpowiadają modelowi mentalnemu usera. Są pewnymi rolami, które mogą być przyjęte przez obiekty. Interakcje operują na Danych ponieważ są do nich mixowane w...
Kontekście - kontekst odpwiada Use Caseom lub ich krokom. To w pewnym kontekście dane są łączone z rolami (zachowaniem) tworząc dopiero obiekty.

Intuicyjny przykład: jestem człowiekiem, opisuje mnie zestaw standardowych parametrów. Ale w zależności od kontekstu przyjmuję niektóre role (a wraz z nimi zachowania): Programista, Manager, Ojciec, Kierowca, Gracz, Klient, ...


Jeżeli udało mi się chociaż trochę zainteresować Was koncepcją DCI (nie mylić z nieco mniej innowacyjnym CDI;) to polecam następujące materiały:

- Architektura i ciekawy przykład w Ruby - aby zaintrygować dodam, że znajdziecie tutaj ostrą krytykę TDD.
- Ciekawe podejście do modelowania - mamy tutaj przykład niesamowitej jasności myślenia i pokaz tragikomicznego frameworka Qi4j (Java się jednak nie nadaje do DCI)
- Niezbyt porywające wprowadzenie teoretyczne - z którego dowiemy się, że te koncepcje mają już kilkadziesiąt lat, tylko gdzieś się zapodziały w przemyśle.
- Niekoniecznie świadome DCI w Scali - plus durne przykłady sortowania kolekcji;)


Ogólnie polecam materiały z konferencji Øredev - jak widać tematyka jest jest bardzo ciekawa i mocno wykracza poza mainstream.

A w inkubatorze (póki co) Eclipse mamy coś bardzo podobnego: Object Teams


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

Ciekawie DCI podsumował jeden ze znajomych architektów (przy okazji "snajper", który potrafi trafić człowieka z granatnika z odległości całej planszy w Modern Warfare 1): "ale trzeba mieć jaja aby zakwestionować standardy i przedstawić coś tak odmiennego".

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!