Gadżety Javy

Jeszcze parę lat temu mówiło się, że Spring i EJB wcale ze sobą nie konkurują. Każde z nich miało swoje obszary zastosowań, w których się sprawdzało, a drugiemu nie wchodziło w paradę. Wyhodowany na bolączkach EJB2 Spring Framework, rozwijany przez genialnych programistów z Interface21, świadomie pozbawiony był nadmiarowych bajerów EJB, przez co wypełnił tą niszę, w której potrzeba było minimalistycznego kontenera.

Z biegiem czasu dochodziły coraz to nowe dodatki: kolejne moduły, kolejne podprojekty, własny serwer aplikacji, SpringSource ToolSuite. Czy wciąż Spring i EJB mają swoje obszary stosowalności? Czy może stały się nawzajem dla siebie alternatywami? Porównajmy:

SpringFramework	EJB3.*
bierzesz, co chcesz; w razie potrzeb dokładasz kolejne moduły	bierzesz wszystko albo nic; klejony na siłę koncept profili moim zdaniem tak bezsensowny, że nawet nie warto się rozpisywać
częste wydania	w bólach i na drodze kompromisów rodząca się specyfikacja jest sporo w tyle za nowinkami ze świata OpenSource
nastawiony na bezinwazyjne sklejanie fragmentów aplikacji oraz na integrowanie się z bibliotekami i frameworkami, które już istnieją i dobrze się sprawdzają	mityczna przenośność aplikacji pomiędzy serwerami
staje się coraz cięższy; może nie sam kontener ale włączając kolejne ficzery robi się coraz ciężej	zmierz w stronę odchudzania (JPA poza kontenerem, koncept profili)
Projekt OpenTerracotta spierający skalowanie aplikacji opartych o Springa	kontener EJB dostarcza możliwości skalowania aplikacji
można tworzyć aplikacje wielowątkowe	zakaz własnoręcznego korzystania z wątków; wątkami zarządza wyłącznie kontener
brak standardu dot. zarządzania aplikacją; istnieją projekty SpringSource dedykowane do tego celu	spójny sposób zarządzania aplikacją

Okazuje się, że Spring wsparty bibliotekami zewnętrznymi potrafi zapewnić dokładnie te same funkcjonalności, że EJB. Być może jeszcze jedną różnicą jest to, że w przypadku Spring trzeba dokładnie wiedzieć jaki efekt chce się uzyskać, gdyż oferuje on bogactwo różnych opcji na rozwiązanie tego samego problemu i trzeba wiedzieć, która jest najodpowiedniejsza dla naszego projektu. W przypadku EJB, mamy wszystko out of the box.

Kontynuując tyradę narzekania
Kontynuując tę tyradę narzekanie trzeba wspomnieć jeszcze wiele genialnych frejmłorków i bibliotek, które świetnie wyglądają w 10 minutes tutorial, rozwiązują parę problemów i wprowadzają szereg nowych.
Wymieniam parę wad:

JSF	ciężkie drzewo komponentów, pokręcony mechanizm renderowania; wersja 1.2 - toporna i wymagająca paru dodatków, aby sensownie pracować; wersja 2.0 - niby fajnie ale poużywamy-zobaczymy; RichFaces 4.0 wspierajace JSF 2.0 już jest
JPA	wolno rozwijająca się specyfikacja, plus wszystkie wady O/RMów
GWT	dostawca monopolista, ciężki klient, brak standardu, po stronie widoku obsługiwana jest tylko część maszyny wirtualnej
Struts2	"prawie" wsparcie dla Ajaxa, koszmarne adnotacji
Spring WebFlow	fajny, gdy GUI ma charakter procesowo-kreatorowy, poza tym przerost formy nad treścią
Oracle ADF	w tutorialach genialny, w użyciu prowadzi do prawie takiego samego bałaganu w kodzie jak przy bezmyślnym klikaniu w Borland Delphi Buildera

Co zamiast w/w?
Jakie mamy zatem mamy alternatywy? Co można używać zamiast powyższych rozwiązań. Spotkałem się z następującymi konfiguracjami:

• Stripes + dojo + Hibernate - wychodzimy z założenia, że nie ma co liczyć na automagiczne ajaxy i jeśli chce się mieć fajne GUI to trzeba w JavaScript popracować
• Freemarker + SpringMVC + myBatis - całkowita rezygnacja z JSP oraz pogodzenie się z faktem, że schemat bazy jest czasem tak prosty, że nie ma co przekombinowywać
• Oracle Forms, PowerBuilder - w architekturze dwuwarstwowej
• PHP - tak po prostu... to o wiele bardziej dojrzała technologia, niż jawowcom może się wydawać, mają nawet swoje automagiczne frejmłorki

Do czego właściwie nadaje się się JEE
Nie chcę za bardzo wyrokować, ale JEE rozważałbym wtedy, gdy...nie ma innego wyjścia, gdy z powodów historycznych (zastany stan systemu), ludzkich (umiejętności programistów) albo politycznych trzeba się decydować na tą konkretną technologię. Bardzo, ale to bardzo byłbym ostrożny, przy rozważaniu JEE dla aplikacji webowej. Dzisiaj jestem zdania, że do aplikacji strice webowych (i nic ponad to) JEE się nie nadaje: zbyt wolne, zbyt kosztowne (chociażby ze względu na wynagrodzenia programistów).

Do czego się nadaje. Oprócz wymienionych na wstępie powodów można jeszcze dorzuć szeroko rozumiany backend przy tworzeniu dużych i długotrwałych projektów o bogatym modelu - wtedy można doszukiwać się korzyści w inwestowaniu w JEE.



P.S. Wpis wyraża prywatne myśli autora, a autor nie zarzeka się, że myśli tych kiedyś nie zmieni:)

Po 33rd Degree

Przede wszystkim wielkie ukłony dla Grześka. Konferencja tej skali to z pewnością nie lada wyczyn. Dziękuję.

Kilka słów, na temat prezentacji, które szczególnie utkwiły mi w pamięci.

Don't code - create software!. Zapamiętałem ze względu na świetny sposób prowadzenia. Bardzo energicznie i przyjemnie.

Fractal TDD: Using tests to drive system design. Ech...naprawdę fajne koncepcje, naprawdę ciekawego człowieka, podane w nieco zagmatwany sposób (dopiero na drugi dzień doszedłem do tego o, co chodzi z tym "Fractal"). Po prezentacji, gdy kilku uczestników rozmawiało z p. Freemanem, widać było wyraźnie, że prowadzący zdecydowanie lepiej odnajduje się w małych grupach. Mimo tych niedogodności podobało mi się.

Git Going with a Distributed Version Control System ,
Monitoring 10 Critical Code Quality Metrics with Sonar. Merytorycznie raczej tutoriale do narzędzi, ale sposób prezentacji absolutnie rewelacyjny. Moim zdaniem najlepszy prelegent Konferencji.

Architecture and programming model for NOSQL web. Prezentację zapamiętałem, ze względu na to, że nic nie zapamiętałem:) Prowadzący założył pewną wiedzę u uczestników, ja jej nie miałem i się nie odnalazłem. Sąsiedzi twierdzili, że była ciekawa więc wierzę im na słowo. Przyszedł mi do głowy pewien pomysł. Być może na konferencjach powinno rozróżniać się prezentacje ogólne/przeglądowe od szczegółowych, na których zakłada się jakąś określoną wiedzę od uczestników. Prezentacja o NOSQL była raczej szczegółowa i jeśli ktoś przyszedł z konkretnym problemem, to pewnie znalazł rozwiązanie. Ja chciałem się zorientować o co chodzi i niestety nie skorzystałem.

BOF: Dokąd zmierza Software Craftsmanship W zamierzeniu miała być dyskusja o profesjonalizmie w IT. Skończyło się na zabawie, że jeden uczestnik wymyślał metaforę: programista jest jak: [szewc | budowniczy | architekt | lekarz], a cała sala ripostowała przypadkami szczególnymi, dla których metafora kuleje. Było dużo śmiechu, ale moje rozumienie profesjonalizmu raczej się nie poszerzyło. Miałem wrażenie, że wylewaliśmy swoje żale, mówiliśmy o własnych nieprzyjemnych doświadczeniach, które następnie uogólnialiśmy do nowotworu trawiącego całą branżę. Pomysł na dyskusję na pewno cenny, temat warto eksplorować.

Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw. Obawiałem się konferencyjnej przeglądówki, ale było ok. Jasno konkretnie i po kolei wyłożone o co chodzi w temacie. Prezentacja a'la Matrix dodała kolorytu.

Lost Chapters of Divine Code: 7 Deadly Sins. Pierwsze wrażenie bardzo pozytywne. Świetny kontakt z publicznością, ważne rzeczy przedstawione w ciekawy i kreatywny sposób. Gdy wracałem do domu i myślałem o tej prezentacji, pojawiały mi się mieszane uczucia.

Pierwsza rzecz, to odniosłem wrażenie (z powodu komentarzy kierowanych w stronę słuchaczy), że prowadzący zaczęli prezentację z założeniem, że mają przed sobą bandę troglodytów, którzy do programowania używają dłuta i maczugi, a których oni właśnie oświecają. O czym mówili? O ile dobrze zapamiętałem to: nie używać metod prywatnych, nie używać konstrukcji statycznych, nie używać metod i klas final, preferować kompozycję ponad dziedziczenie. Nie są to więc sprawy, które nagle spłynęły z nieba, lecz tematy przewijające się w branży od czasów GoF i raczej większość programistów ma swoje zdanie na te tematy.

Z wieloma argumentami prowadzących można się zgodzić, ale podawane bez kontekstu tracą swoje znaczenia, a dogmatyczne przestrzeganie tych zaleceń zawsze i wszędzie doprowadzi bajzlu w kodzie równie szybko, co ich ignorowanie. Będzie to bajzel innej jakości, ale zawsze bajzel. Sądzę, że porady prowadzących były ciekawe, ale jak wszystko mają zakres swojej stosowalności. Myślę, że tworzenie boskiego kodu, to coś więcej niż mechaniczne przestrzeganie niskopoziomowych wytycznych.

Moje całościowe wrażenie odnośnie przesłania tej prezentacji jest bardzo pozytywne, potrzebujemy tego rodzaju ewangelistów. Jedna rzecz mnie zniesmaczyła. Prowadzący kolejno wyśmiewali: K.Becka, E.Gamma, S.Freemana, R.Martina i kogoś jeszcze, za to jakie błędy popełnili i co powiedzieli w przeszłości. Przypomniało mi to wiersz Asnyka Do młodych, którym napisał ale nie depczcie przeszłości ołtarzy, choć macie sami doskonalsze wznieść. Myślę, że gdyby nie ci wszyscy "giganci" inżynierii oprogramowania, Autorzy prezentacji z pewnością nie robiliby tego, co teraz robią, nie prezentowaliby siebie na konferencji, a i konferencji z pewnością by nie było. Autorzy prawdopodobnie rzeźbiliby paznokciami w rzadkim...kodzie i nie przychodziłoby im do głowy, że można inaczej. Myślę, że choć Autorom nie brakuje świetnych pomysłów, to jednocześnie przydałoby im się nieco pokory i szacunku do Becka, Gamma, Freemana, Martina i innych, gdyż między innymi dzięki ich błędom (i sukcesom, oczywiście), Autorzy są tam, gdzie są i robią to, co robią.

Podsumowując - niecierpliwie czekam na kolejną edycję Konferencji.

Tyle ode mnie.

"żeby tak wszystko ze wszystkiego wynikało"

Problem dotyczy zarządzania zmianami w wymaganiach. Cytując rozmowę, oczekiwanie brzmi następująco Proszę Pana, chciałbym tu mieć takie narzędzie do zarządzania wymaganiami, w którym będę mógł sobie je definiować, żeby tak wszystko ze wszystkiego wynikało. Na przykład jak przyjdzie jakaś zmiana, to żebym od razu wiedział gdzie, co i jak, w której klasie należy zmienić. Rozumie Pan?

No, niby rozumiem...

Zarządzanie? Dobre sobie!
Weź pierwszą z brzegu mądrą książkę, która ma w tytule Requirements Management. 99% tekstu jest o (w kolejności ilości stron): dokumentowaniu, zbieraniu (ale raczej skąd? niż jak?) i analizie wymagań. I gdzieś tam pod koniec parę akapitów o tym, że change happens. A kluczową atrakcję wieczoru, czyli management zbywa się truizmem w stylu trzeba wdrożyć proces zarządzania zmianą.

Czyli co to jest to zarządzanie? Sądzę, że:

• składowanie wymagań
• dowiadywanie się jak nowe wymagania wpływają na istniejące
• wykrywanie konfliktów w wymaganiach
• dowiadywanie się jak zmiany (w skrócie: CR) wpływają na istniejące wymagania

Hipertraceability
Czy oczekiwanie wyrażone w początkowej historyjce ma sens. Jest w nim ukryta jakaś potrzeba, ale zastanawiam się czy ma sens. Można zaprzęgnąć EA albo coś droższego i wyklikać wszystkie możliwe powiązania tak, "żeby tak wszystko ze wszystkiego wynikało". A co w przypadku zmiany? Oprócz dowiedzenia się co z czym się wiąże, znów trzeba będzie poklikać. Sądzę, że utrzymywanie takiej macierzy powiązań to robota na kilka pełnych etatów. Wątpię, czy warta świeczki. Wątpię, czy jest nawet warta ogarka.

Gdzie leży problem z traceablility?
Duży system jest zazwyczaj podzielony na moduły, które są rozwijane przez osobne podzespoły, którym przewodzą dedykowani liderzy. Gdy przychodzi zmiana dotycząca jednego z modułów, może ona jakiś wpływ na inne. Jeśli dane lider na to wpadnie to świetnie. Jeśli nie, to sprawa wypłynie prędzej czy później.

Niszczące działanie zmiany nie jest wynikiem braku hiepertraceability, braku jedynie poprawnego narzędzia czy wynikiem braku kompetencji. To przede wszystkim problem organizacyjny i komunikacyjny. Liderzy nie wiedzą co się dzieje w inny modułach, analizują zmianę lokalnie bez odniesienia do całości (której nie znają) i nie komunikują się ze sobą wystarczająco.

Product Manager
Brakuje osoby (Product Manager), która będzie spinać system całość. Od razu pada pytania: czy od strony technicznej, czy biznesowej? Nie chodzi to, żeby przez Product Managera przechodziły wszystkie CR, a on będzie podejmował je analizował i podejmował decyzje. Nie może tak być, bo zaraz zrobi się z niego ktoś w stylu Solution Architect, w którym będzie powoli skupiała się kluczowa wiedza o systemie i który będzie wąskim gardłem procesu zarządzania zmianą. (a niech tam, to zatrudnimy mu asystentów i już, czemu nie? :) )

Product Manager jest raczej kimś kto dba o to by komunikacja pomiędzy liderami i zespołami przebiegała płynnie. Oczywiście będą trafiać do niego wszystkie CR, będzie posiadał dużą wiedzę biznesową i będzie doskonale znał produkt. Jego główny zadaniem będzie troszczenie się o produkt jako całość i pomaganie poszczególnym zespołom w komunikowaniu się z innymi i dogrywaniu wszelkich zmian.

Zauważmy, że nie jakaś konkretna osoba analizuje wymagania, wykrywa konflikty i wpływ nowych na istniejące. Rzeczy te wykrywane są w procesie komunikacji pomiędzy poszczególnymi zespołami i liderami.

Czy Product Manager będzie miał co robić? Jeżeli mówimy o produkcie, który ma wdrożenia dla poszczególnych klientów, to z pewnością tak. Odpowiedzialności Product Manager to:

• dbanie o rozwój produktu jako całości
• dbanie o loose coupling między produktem a wdrożeniami dla poszczególnych klientów :)
• przyjmowanie CR
• pomaganie liderom i zespołom w komunikowaniu się między sobą
• uzgadnianie i mediowanie w przypadku wprowadzania zmian w produkcie