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!

Majowa ewangelizacja Software Craftsmanship

Prezentacja poświęcona tematyce Software Craftsmanship została dosyć ciepło przyjęta podczas poznańskiego 4Developers, oraz spotkała się z niemałym odzewem w community.

Dlatego uznałem, że warto kontynuować propagowanie profesji w naszej branży - szczególnie, że nasze community zaczyna coraz wyraźniej sygnalizować pewne problemy.

Zapraszam zatem wszystkich zainteresowanych tematyką Software Craftsmanship na szereg darmowych konferencji, gdzie planuję wystąpienie:

- lubelskie dni IT - 12 maja w Lublinie
- Infoshare - 14 maja w Gdańsku
- Javarsovia - 26 czerwca w Warszawie

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

Cieszy fakt, ze tematyka Craftsmanship pojawia się również na JUGach: warszawskim i wrocławskim

Google Application Engine

Dziś będzie o rzetelności.

WYGLĄDA OBIECUJĄCO

Chmura Google - GAE ogólnie prezentuje się świetnie. Za darmo (do pewnych limitów) dostajemy platformę, która jest w stanie udźwignąć tysiące transakcji na sekundę oraz przechować dla nas terabajty danych w nierelacyjnej bazie BigTable. Do tego dostęp do wielu usług google takich jak bezpieczeństwo, składowanie obrazków, pobieranie zawartości stron poprzez ichni cache, potężny memcache itp.

Programować możemy sobie w Pythonie albo w Javie (okrojonej wersji, bez części klas standardowych i z zakazem korzystania z pewnych bibliotek).

Ogólne założenie jest takie: programiści (i konsultanci;) w większości nie potrafią konfigurować skalowalnych środowisk ani pisać skalowalnych aplikacji, dlatego dostarczmy im platformę, która zajmie się tym problemem w sposób transparentny. Czyli mamy podejście odwrotne do Java EE. Zajmij się problemem biznesowym a chmura zajmie się skalowaniem. Kierunek wydaje się słuszny.

Zatem zaczynamy zabawę...
Na dzień dobry krótka, oficjalna prezentacja z głównej strony jak to fajnie i szybko klepie się aplikacje i odpala je w kosmos: http://www.youtube.com/watch?v=P3GT4-m_6RQ
Trzeba przyznać, że plugin do Eclipse jest wzorowy: prosty w obsłudze (3 sugestywne buttony), działa oraz zapewnia wszystko:
- lokalny server emulujący chmurę i jej zasoby (bazę)
- narzędzie automatycznie "wzbogacające" bytecode klas encji na potrzeby ichniej "implementacji" JPA
- narzędzie wystrzeliwujące aplikację w kosmos
- prosty kreator, który generuje cały ten kosmodrom
(nie odważyłem się zmawenizować wygenerowanego projektu, bo to zwykle tydzień w plecy a na koniec może się okazać, że tracimy hotdeploy)



WTF?

Ale, ale... akcja filmu rozkręca się z czasem...
Jedna z największych firm programistycznych na ziemi pokazuje jak tworzyć kod w... Java Server Pages. Patrzcie uważnie i uczcie się: logika i dostęp do danych w... scriptletach (sic!).

Oczywiście duzi chłopcy wiedzą, ze scriptlety są depricated. A nóż widelec tą scenę zobaczy jakieś małe dziecko i będzie później tak programować jak dorośnie?!? Później znowu przeczytamy w gazecie o tragedii jaka rozegrała się w jakimś spokojnym projekcie. Gdzie byli rodzice?!?

Hmmm dziwne, dziwne... no ale nie czepiajmy się szczegółów, to przecież tylko taki przykład. Przecież zawsze możemy zaprojektować sobie eleganckie warstwy i całość oprzeć o sprawdzony framework.



BOLESNE OGRANICZENIA

Niestety tak jak wspomniałem na początku JVM ma ograniczenia i nie wszystko działa. Seam co prawda daje się uruchomić po zastosowaniu 15 speszyl haków, ale wszyscy twierdzą, że nie warto ryzykować. Na szczęście stary, dobry Spring oficjalnie działa. Wielu dzielnych blogerów publikuje hello worldy i tutoriale jak to poskładać. Wygląda na to, że jedni kopiują od drugich;)

Ba, nawet 2 książki o GAE preferują Springa i pokazują jak go skonfigurować. Hmmm ciekawe dlaczego omawiają tylko servlecik Spring MVC i dyplomatycznie nie poruszają bardziej zaawansowanych zagdanień...?

Niestety, jednak nie działa do końca!
Przykładowo gdy użyjemy technik Aspektowych i przeplatania w czasie uruchomienia to mamy dziwne błędy ClassNotFound. Lokalnie działa, a na chmurze już nie.
Co implikuje, że możemy zapomnieć o aspektowej, eleganckiej obsłudze bezpieczeństwa i transakcji.
Więc po co nam Spring? Tylko do wstrzykiwania? To bez sensu.



UWAGA NA PERSYSTENCJĘ

Nieważne, bez Springa można żyć, idźmy dalej... Nierelacyjna baza BigTable została przez Google przykryta interfejsem JDO albo JPA (do wyboru) więc czujemy się jak w domu.
Nie do końca... specyfikacja ma szereg ograniczeń wynikających z architektury rozwiązania BigTable - chodzi o rozpraszanie struktur danych na różne maszyny po stronie chmury.

Drobny szczególik wspomniany jedynie w dokumentacji jest taki, ze agregaty encji są grupowane w rodziny. Przykładowo jeżeli mamy encję Zamówienie, która ma w sobie listę ZamówionychProduktów to jest to rodzina. Co z tego wynika?

Encja może należeć jedynie do jednej rodziny.
Implikacja: Jeżeli mamy encje Zamówienie i Faktura oraz encję Kleint, który musi być podpięty do Zamówienia jak i Faktury to niestety nie ma takiej możliwości. Dziecko może mieć jednego rodzica. Oczywiście można to obejść i w Zamówieniu jak i Fakturze używać obiektów Kluczy do Klienta. Ale wówczas tracimy łatwość programowania i uzależniamy się od API Chmury.

Trzeba pamiętać, że podejście do modelowania danych w nierelacyjnej bazie wymaga innego "nastawienia" - taka natura rozwiązania. Jeżeli nierelacyjnie to może obiektowo? Jednak nie do końca - no to jak?

Osobiście preferuję takie podejście, że Zamówienie czy Faktura ma owszem klucz do Klienta ale ma również niepersystentne pole Klient, które jest ustawiane w niej osobnym zapytaniem (nie jest to duży koszt w bazie BigTable, która jest tak na prawdę wielowymiarową HashMapą). Tego typu szczegóły można hermetyzować z obiektach Repository, które zwracają dane "poskładane" tak aby było wygodnie. OK, jeden problem z głowy.


Transakcja może obejmować tylko operacje na jednej rodzinie.
Czyli jeżeli logika aplikacji chce zapisać zarówno rodzinkę Zamówienie jak i Faktura to będą to 2 osobne transakcje. A co jeżeli w tak zwanym międzyczasie zdarzy się coś przykrego? Ręczna rzeźba i sprzątanie:)
Poza tym, jak wspomniałem, aspektowe transakcje Springa nie działają, więc brudzimy kod biznesowy kodem API transakcji JPA.


Datanucleus - "implementacja" JPA
Oprócz tego, że jest okrojona to dodatkowo zawiera szereg błędów - nie działają nawet niektóre proste przykłady z tutoriali JPA. Na oficjalnej grupie wisi wiele pytań - bez odpowiedzi.



GWÓŹDŹ

Prezentacja
Z frameworków prezentacji testowałem JSF.
1.2 (z Seam) działa.
2.0 działa po zastosowaniu jednego prostego speszyl haka.

Działa w sensie, że się uruchamia. W 2.0 występują pewne problemy z wstrzykiwaniem ManagedBeanów. RichFaces ani IceFaces nie mają wersji dla chmury. Oficjalnie Primefaces częściowo działa. Znowu nie jest to rzetelna i informacja - AJAX ogólnie się sypie.

No i można zapomnieć o uruchamianiu metod z parametrem przy pomocy nowego silnika wyrażeń (el-api w wersji 2.2). Chmura odmawia współpracy z nowymi zdobyczami.

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

Biorąc pod uwagę powyższe ograniczenia:
- brak wygodnego frameworka (w tym wsparcia dla AOP)
- uboga funkcjonalność ORM wymagająca wielu ręcznych operacji
- mentalny model programowania sprzed o ok 10 lat
Mamy znaczny spadek produktywności.

Domyślamy się skąd te JSP, scriptlety i statyczne metody w filmie promocyjnym? Czyżby tylko to działało?
Szkoda tylko, że community i blogosfera zatrzymuje się na poziomie Hello World i nie weryfikuje nieco bardziej dogłębnie i rzetelnie.

Na zakończenie dodam, że zupełnie inne założenia przy budowie chmury przyjął Amazon. Dostajemy sprzęt i system operacyjny. Nikt nie narzuca nam dodatkowych bytów zbudowanych nad sprzętem i nie wchodzi nam z butami w nasz wypracowany latami i sprawdzony model programowania. I co najważniejsze - wszystko działa:)