Holistycznie o inżynierii oprogramowania

Dopamina Driven Development

2012-01-03T22:05:00.000+01:00

Jaki wpływ na tworzenie kodu mogą mieć wytryski dopaminy?
Co wspólnego ma nikotyna z TDD?
Dowiecie się w 22. minucie i 30. sekundzie prezentacji Things I Wish I'd Known od samego twórcy Springa - Roda Johnsona:)

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

Generalnie bardzo polecam obejrzenie całej prezentacji, ale uprzedzam - nie ma w niej ani linijki kodu:)

Skręt kości promieniowej i łokciowej, czyli rzecz o myszkach

2011-12-16T02:16:00.000+01:00

Awaria mojej głównej myszki (czyli tej której używam do codziennej pracy, w odróżnieniu od specjalnej do gry ze znajomymi w CoD) skłoniła mnie do napisania kolejnego posta na temat Sprzętu.

Dawno, dawno temu, jako początkujący użytkownik peceta byłem przekonany, że jego głównym elementem, decydującym o ogólnym "ekspiriens" jest procesor i akcelerowana karta graficzna:) "Dziś sam jestem dziadkiem" i pytany przez nietechnicznych znajomych oraz nietechniczną rodzinę doradzam, że najważniejsze elementy zestawu to: krzesło, klawiatura, myszka i matryca (w sensie jej jakości) - reszta zależy już tylko od budżetu:)

Warto wiedzieć, że klasyczne "płaskie" myszki wymuszają nienaturalne (skręcone) ułożenie kończyny górnej i prowadzą do:

Skrętu wzajemnego położenia kości promieniowej i łokciowej w naszym przedramieniu,
Naprężeniu mięśni przedramienia (wynika z powyższego)
Ucisku na naczynia krwionośne (wynika z obu powyższych)

Jeżeli się nad tym chwilę nie zastanowić, to ułożenie dłoni na płaskim blacie tak aby do niego przylegała wydaje się normalne. Ale spróbujcie układać dłoń na zmianę na blacie: w pozycji "do spoliczkowania" i w pozycji "płaskiej", aby powoli zacząć uświadamiać sobie co się dzieje z Waszymi kośćmi i mięśniami.

Wielu z nas skarży się na bóle w okolicach nadgarstka. Ja sam w pewnym momencie miałem problem z utrzymaniem kierownicy w prawej ręce podczas powrotu z pracy do domu.
Jako rozwiązanie polecam tego typu konstrukcje.
Osobiście od ok 5 lat używam modelu Vertical Grip i w tym momencie każde zetknięcie mojej odzwyczajonej od tortur ręki z "płaską" myszką skłania do refleksji: ale po co?

DDD na platformie Java EE 6

2011-12-14T02:35:00.001+01:00

Dzisiaj coś dla miłośników Enterprise Edition.

Nieustannie rozwijamy projekt ilustrujący implementację zaawansowanych technik Domain Driven Design i architektury Command-query Responsibility Segregation.
Dotychczasowa implementacja oparta na Springu doczekała się swego lustrzanego odbicia na platformie Java EE6
W projekcie znajdziecie między innymi kilka sztuczek w CDI oraz przykłady wykorzystania silnika zdarzeń w modelowaniu biznesowym (dowiecie się również dlaczego budowany Events<> jest nieco ułomny:).

Więcej szczegółów na blogu projektu.

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

W najbliższych planach aplikacja kliencka na Androidzie w architekturze Eventually Connected Client.

Geneza boskich klas

2011-11-30T23:02:00.001+01:00

Zarówno po dzisiejszej konferencji softdevcon jak i zeszłotygodniowej JDD kilka osób prosiło mnie o powtórzenie tekstu o "boskich klasach", którym staram się rozbudzić uczestników prezentacji o DDD. Postanowiłem nieco rozszerzyć opowiastkę...

Domain Driven Design - A place for everything and everything in its place on Prezi

Narodziny

Każda boska klasa ma swój początek jako niewinny ośmiotysięcznik - klasa zawierająca osiem tysięcy linijek kodu.

Eskalacja

Zmiany w ośmiotysięczniku wymagają specjalnej wyprawy. Śmiałek wspina się przez kilka dni na wysokość ok piątego tysiąca próbując zrozumieć logikę/ironię kodu po czym zakłada tam bazę - rozgrzebuje kod kilkoma enterami aby zrobić sobie nieco miejsca, w którym to następnego dnia (bo aktualnie opada z wycieńczenia i niedoboru podstawowych neuroprzekaźników w mózgu) zacznie drążyć tunelik jako fundament dla nadbudówek.

Poczynania śmiałka powodują oczywiście niejednokrotnie lawiny, które rozrywają na dole i tak już nieszczelne siatki bezpieczeństwa testów.

Kolaps

Z czasem ośmiotysięcznik rozrasta się aby w końcu zapaść się grawitacyjnie pod własnym ciężarem. Powstaje wówczas osobliwość, z której wyłania się Boska Klasa - klasa, która wszystko wie, wszystko potrafi i jest połączona ze wszystkim w każdym możliwym wymiarze.

Boska klasa aby istnieć potrzebuje ofiar. Najlepsze są młode, niewinne praktykantki. W swej naiwności opartej na akademickich wierzeniach we wszechmoc Maszyny Turinga składają się w ofierze na ołtarzu Boskiej Klasy...

Z czasem udaje im się wyrwać z grawitacji osobliwości, ale już nigdy nie będą takie jak wcześniej...

DDD must read

2011-11-01T13:44:00.000+01:00

Od dłuższego czasu nosiłem się z zamiarem napisania posta poświęconego modelowaniu agregatów - różnym podejściom i wynikającym z nich konsekwencjom.
Właściwie temat nie jest związany ze specyfiką DDD, a ogólnie z modelowaniem obiektów biznesowych z zachowaniem ich enkapsulacji, które dzięki niej są bardziej odporne na zmiany.

Skoro jednak w sieci istnieją już materiały z dobrą ilustracją graficzną oraz przykładami w kodzie, to oszczędzę sobie pisania i pozwolę polecić ich lekturę każdemu kto zajmuje się modelowanie lub projektowaniem obiektowym (heh kto z czytelników się nie zajmuje "przy okazji" innych spraw?):

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

Tak jak pisałem wcześniej tematyka jest ogólna, nie związana stricte z DDD i lektura powinna być pożyteczna dla każdego.

Konferencja Warsjawa - kolejny warsztat DDD&CqRS Leaven

2011-10-09T23:38:00.002+02:00

Zapraszam na konferencję Warsjawa, która odbędzie się w najbliższą sobotę (15 października) w Warszawie.

Warto dodać, że konferencja jest całkowicie darmowa:)

Podczas konferencji będziecie mogli uczestniczyć między innymi w naszych warsztatach, poświęconych projektowi DDD&CqRS Leaven.

Szczegółowy program warsztatów: https://github.com/warszawajug/warsjawa2011/wiki/Warsztaty-DDD-i-CqRS.

Persystentny Multi-Listener, czyli... Saga

2011-10-05T22:53:00.002+02:00

Persystentny multi-listener... jak to pięknie brzmi...:)

Cóż to takiego?

Listener - czy obiekt słuchający zdarzeń,
mulit - czyli chodzi o wiele zdarzeń,
persystentny - czyli posiadający trwały stan.

Podczas ostatnich warsztatów z zakresu projektu DDD-CqRS Leaven wspomniana wyżej technika modelowania czasu spotkała się z zainteresowaniem wielu osób. Nic dziwnego, jest to dosyć nowy pattern; również na szkoleniach wzbudza zawsze największe emocje. Głównie dlatego, że ciężko pogodzić się z myślą, że coś tak złożonego można modelować i implementować w tak prosty i przyjemny sposób:P

Pattern ma swoją oficjalną nazwę, brzmi ona Saga. Jeżeli saga kojarzy się senior developerom z sagą rodziny Carringtonów, to dobrze się Wam kojarzy. Saga to coś co może rozciągać się w czasie niczym telenowela. Saga jest patternem służącym do orkiestracji wielu zdarzeń, które mogą zajść w rozproszonym systemie w nieokreślonej kolejności. Czas pomiędzy zajściem zdarzeń może być relatywnie długi, dlatego należy persystować jej stan w czasie oczekiwania na kolejne zdarzenie.

Przykład:
Wyobraźmy sobie system, w którym mamy moduły: sprzedaży, płatności i magazynu.
W module sprzedaży możemy zatwierdzić obiekt biznesowy Zamówienie. Zamówienie rzuca wówczas zdarzenie biznesowe ZatwierdzonoMnie zawierające id tegoż zamówienia.
W module płatności możemy dokonać wpłaty. Być może jest to przedpłata dokonana wcześniej niż zatwierdzenie zamówienia... Moduł ten rzuca zdarzenie niosące informację o zajściu faktu dokonania wpłaty.
Oba zdarzenia są orkiestrowane przez sagę Zakupy. Jeżeli otrzyma ona oba zdarzenia (pasujące po id biznesowym) i stwierdzi, że jesteśmy "kwita" wówczas może wysłać sygnał do modułu magazynowego aby przygotować paczkę do wysyłki.

Oczywiście możemy tego typu proces zaimplementować w inny sposób niż zdarzeniowy, ale jeżeli zależy nam na decouplingu modułów systemu (wraz z wszystkimi konsekwencjami: skalowanie, testowanie, rozszerzalność, otwartość na dodawanie pluginów, redukcja architektury Speaghetti na poziomie modułów) to warto posłużyć się Sagą.

Udi Dahan dosyć dobrze wyjaśnia motywację oraz szczegóły koncepcyjne: Saga Persistence and Event-Driven Architectures dlatego nie chcę powtarzać, tego co zostało napisane ponad 2 lata temu.

Jak widać w powyższym linku technicznie Saga to złożenie 2 wzorców: Observer i Memento. O ile observera każdy zna choćby z bibliotek graficznych i wszechobecnych tam onClickListenerów, o tyle Memento jest mniej znanym patternem. Jeżeli ktoś oglądał film pt. Memento o człowieku, który miał problem z transferem danych z pamięci podręcznej (kora przed-czołowa) do pamięci długotrwałej (hipokamp) to skojarzenie jest również poprawne. Memento to pattern służący obiektom na wysyłanie do siebie informacji na przyszłość. Tak jak bohater filmu, który zapisywał i tatuował sobie na rękach informacje o tym co należy zrobić w przyszłości:)

Natomiast zainteresowanych szczegółami implementacji Sagi odsyłam do przykładu w projekcie DDD&CqRS Leaven:

opis: http://code.google.com/p/ddd-cqrs-sample/wiki/DomainDrivenDesignBusinessDeveloperMentalModel#Saga
kod os strony programisty biznesowego: http://code.google.com/p/ddd-cqrs-sample/source/browse/#svn%2Ftrunk%2Fddd_cqrs-sample%2Fsrc%2Fmain%2Fjava%2Fpl%2Fcom%2Fbottega%2Ferp%2Fsales%2Fsaga
idea i implementacja silnika Sagi:http://code.google.com/p/ddd-cqrs-sample/wiki/CommandQueryResponsibilitySegregationSystemArchitectMentaModel#Saga_Engine

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

Jako ciekawostkę dodam, że niektóre szyny komunikatów w .NET wspierają mechanizm Sagi niejako "z pudełka"...
Techniczny komunikat (message) jest traktowany na poziomie logicznym jak zdarzenie (event). Ichnie "Message Driven Beany" reagaujące na wiele zdarzeń to po prostu Sagi. Do tego automatyczne ładowanie i zapisywanie Memento, kończenie albo usypianie sagi oraz drobny szczegół: obsługa współbieżności...
Natomiast my w swym świecie Javy wciąż szukamy uber-frameworka webowego, który daje złudzenie, że każdy system jest CRUDem...

Pierwszy warsztat poświęcony "DDD & CqRS Leaven project" za nami.

2011-10-03T11:54:00.000+02:00

Kilka zdjęć na blogu projektu.

Zapraszamy na warsztaty z "wypiekania zaczynu" (DDD, BDD, CqRS)

2011-09-28T13:54:00.001+02:00

W najbliższą sobotę (1 października) organizujemy w ramach lubelskiego JUGa otwarte warsztaty z zakresu:
- modelowania z wykorzystaniem Domain Driven Design
- procesu Behavior Driven Development (w tym wykorzystanie JBehave, Selenium i Agentów)
- architektury Command-query Responsibility Segregation

Warsztaty będą przeprowadzone na podstawie materiałów z otwartego i darmowego projektu DDD+CqRS Leaven.

Szczegóły wydarzenia na stronie JUGa.

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

Dla zainteresowanych z innych zakątków Polski informacja: planujemy tego typu inicjatywy podczas zbliżających się konferencji branżowych - szczegóły wkrótce.

java.util.Calendar a sprawa Polska, czyli gdzie są moje 24 minuty?

2011-09-24T15:45:00.003+02:00

Jako członek rady programowej tegorocznej konferencji Java Developers' Day mam zaszczyt zaprosić Was do konkursu na śmieszną (może przez łzy) i ciekawą (może pouczającą) anegdotę z codziennej pracy.

Strona konkursu Z pamiętnika dewelopera historii kilka… zawiera szczegółowy regulamin i opis nagród.Planujemy dodatkowo podczas konferencji umożliwić podzielenie się swoimi "przygodami" w formie stand up comedian:)

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

Gdyby ktoś z lenistwa nie kliknął linka pod którym znajdują się zgłoszone historyjki, to zamieszczam kopię własnej:

Tytuł: java.util.Calendar a sprawa Polska, czyli gdzie są moje 24 minuty?

Problem:

Duży system, w którym klientem do serwera były applety. Na wielu formularzach istnieje możliwość edycji czasu pewnych zdarzeń. Czas edytowany przez zwykłe pole tekstowe w formacie godzina:minuty. Niestety, na niektórych formularzach można zaobserwować następujące schorzenie: wpisujemy pewien czas, zapisujemy, następnie gdy ponownie edytujemy rekord, czas jest zawsze cofnięty o 24 minuty! Liczba 24 kojarzy się każdemu z ilością godzin w dobie tak więc jest to doskonale zwodnicza wartość…

Tło techniczne:

Czas – z powodów, które pamiętają już tylko prastarzy Słowianie programujący w technologiach z epoki krzemu łupanego – był zapisywany w bazie danych jako: 01.01.1900 godzina_z_formularza:minuta_z_formularza:00.000

Kluczowy jest tutaj pierwszy stycznia roku 1900.

Zapis i odczyt działały poprawnie. Komunikacja applet – serwisy serwera poprzez Spring Remoting (zdalne wywołanie metod Beanów Springa, serializacja paramentów i wyników i wyjątków).
Czas był przesyłany w DTOsach w postaci obiektów klasy java.util.Calendar (służącej lepiej lub gorzej do manipulacji czasem) zamiast java.util.Date (służącej jako kontener na czas).
Calendar jest o tyle sprytną klasą, że jej obiekty badają lokalizację systemu operacyjnego na którym żyją. W przypadku podpisanych appletów robiły to na maszynach klienckich po ich przesłaniu i deserializacji.

Warto wiedzieć:

Po tygodniu poszukiwań okazało się, że głęboko w kodzie kalendarza istnieje logika, która uwzględnia następujący fakt: ~~pewnego dnia w 1904~~ 4. sierpnia 1915 roku na terenie Polski dokonano standaryzacji czasu, tak aby dopasować go do globalnych stref czasowych i przesunięto wówczas wskazówki o 24 minuty:)

A panowie z Suna (niestety) odrobili lekcje z historii…

Przyśpiesz swoje środowisko dev - ramdisk

2011-09-17T13:10:00.003+02:00

Dziś post sprzętowy. Do tej pory nie poruszałem tego typu tematyki na blogu, ale prywatnie hardware interesuje mnie nie mniej niż software:)

Jak wiadomo w większości codziennych juzkejsów dysk jest wąskim gardłem naszego narzędzia pracy. Standardowym sposobem na przyśpieszenie maszyny jest wymiana dysku na SSD. Na dzień dzisiejszy aby tak na prawdę przyśpieszyć codzienną ogólną pracę (mieszanka zapisów i odczytów) trzeba wydać relatywnie sporą sumę na na prawdę szybki dysk.

Można jednak pójść znacznie dalej z prędkością odczytu/zapisu pokusić się o stworzenie dysku w pamięci RAM.Dysk tego typu jest widziany w systemie tak samo jak zwykłe dyski. Na starcie może on pobrać swój obraz z HDD/SSD do RAM i od tej pory pracujemy na pamięci, która jest bardzo blisko procesora. RamDisk może oczywiście periodycznie utrwalać się na dysku klasycznym (mając więcej niż 1 rdzeń w procesorze nie jest to problem).

Tutaj przegląd RamDisków dla Windows: http://www.raymond.cc/blog/archives/2009/12/08/12-ram-disk-software-benchmarked-for-fastest-read-and-write-speed/.
Od kilku dni testuję na Win7 x64: http://memory.dataram.com/products-and-services/software/ramdiskktóry jest darmowy do 4GB.

Na taki dysk można skopiować całe środowisko dev: JDK (wystarczy skopiować), Eclipse, Maven+Repo, Servery...Po prostu śmiga!

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

Dokupując RAM zwróćcie uwagę oczywiście na taktowanie (tak aby było maksymalne na jakie pozwala szyna) ale również na latencją CAS http://pl.wikipedia.org/wiki/CAS_latency.Przykładowo DDR3 1066MHz w wersji CL7 jest o 10% szybszy niż w wersji CL9. A różnica w cenie kości 4GB to dosłownie kilka zł:)

Rozwiązaniem lepszym niż RamDisk (który zapisuje obraz na HDD/SDD) byłby soft, który buforowałby w RAM wskazane katalogi i udostępniał je przez interfejs sterownika dysku. Tak aby po prostu w tle synchronizować się z klasycznym dyskiem wprost do wskazanych katalogów - bez obrazu dysku. Rodzaj stałego obszaru cache dysku. Znacie może tego typu rozwiązania softwareowe (bo istnieją mniej więcej tego typu sprzętowe kontrolery do dysków ssd)?

Zaczyn DDD+CqRS

2011-08-30T18:20:00.001+02:00

Jak pewnie zauważyliście, częstotliwość publikowania postów spadła ostatnio dosyć znacznie. A to za sprawą mocnego zaangażowania w nowy projekt - projekt ilustrujący techniki modelowania Domain Driven Design oraz wybrane podejścia do implementacji architektury Command-query Responsibility Segreation.

Projekt osiągnął poziom wersji Beta pierwszego Milestonea, tak więc już oficjalnie możemy go upublicznić: http://code.google.com/p/ddd-cqrs-sample/.

Zaczyn?
Nazwa ociekająca folklorem jest ilustracją idei: projekt to coś więcej niż Sample ale zdecydowanie nie jest to kolejny Framework - więcej na ten temat na wiki.
Gwoli wyjaśnienia: zaczyn to coś z czego powstaje chleb.

Odeszliśmy od formy frameworka przekonani przez samego Grega Younga (twórcę CqRS i propagatora DDD). Greg przekonał mnie podczas prywatnych rozmów, że framework dla CqRS delikatnie mówiąc nie ma sensu:)

Zawartość projektu odpowiada na pytania techniczne, które pojawiają się tak często, że uznaliśmy, że czas stworzyć sampla ilustrującego nasze podejście. Do tej pory istnieją dwa takie Sample napisane w Javie - my jednak chcieliśmy pójść nieco dalej. Tak więc projekt jest sumą doświadczeń jego twórców.

Co w nim znajdziecie:
- ilustracja wszystkich Builiding Blocków DDD (bez uproszczeń technicznych)
- ilustracja zaawansowany technik DDD (Bounded Context to nie są akademickie rozważania)
- ewolucyjne podejście do architektury warstwowej, różne poziomy separacji CqRS (na tym etapie nie wprowadzamy Event Sourcingu - wyjaśnienie powodów na wiki)
- pragmatyczne podejście do CqRS
- część bardzo specyficznej wiedzy wyniesioną przez nas z wiosennego szkolenia Grega Younga
- modelowanie czasu poprzez zdarzenia i dosyć nową technikę modelowania czasu: Sagi
- kilka eleganckich trików z wykorzystaniem Springa i Hibernate:)
- techniki testowania: jednostkowe, integracyjne i akceptacyjne
- połączenie JBehave (Behavior Driven Development) z Selenium
- już niedługo: nasz własny pomysł na uogólnienie historyjek tak by wspierały zarówno testowanie przez GUI jak i przez API

Zainteresowanych zapraszamy do:
- wiki - kilkadziesiąt stron A4 plus trzy wizualizacje w Prezi
- SVN - aktualnie ok 150 klas platformy zaczynu oraz przykładów DDD
- grupy dyskusyjnej
- bloga

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

Teksty techniczne z zakresu DDD i CqRS będę publikował na nowym blogu. Natomiast niniejszy będzie wciąż prowadzony jako miejsce na tematy pozostałe.

Wygeneruj sobie PDFa - Facelets (JSF) + CSS3 + Flying Saucer

2011-08-12T09:43:00.014+02:00

Dzisiejszy post będzie nietypowy: dużo kodu i kilka speszyl-haków:)

Pokażę jak szybko i raczej bezboleśnie generować PDFy na podstawie HTMLa + CSS3 z wykorzystaniem szablonów w wydaniu Facelets.

Założenia

Oczywiście do generowania PDF możemy podejść na wiele sposobów. Możemy np. użyć natywnego api lub nawet zastosować Open Office postawionego w trybie servera (bez GUI) i korzystać ze wszelkich narzędzi do tworzenia dokumentu, aby na końcu "zapisać jako" pdf.

Natomiast w tym poście zakładam, że chcemy rozwiązać sprawę najprościej jak się da, bez potrzeby studiowania autystycznej dokumentacji.

Generujemy PDF

Na początek potrzebujemy biblioteki: http://code.google.com/p/flying-saucer (w paczce mamy ITexta i xercesa). Flying saucer to wspaniałe narzędzie, które przykrywa iTexta wygodnym api: na wejściu podajemy urla do strony, a na strumieniu wyjściowym dostajemy PDFa. Strona może odwoływać się do CSS3, w którym definiujemy nagłówki, stopki, numerowanie stron, podział stron. Wszystko zostanie kolejno opisane w dalszej części.

Pdfy będziemy zwracać z następującego servletu:

@SuppressWarnings("serial")

@WebServlet("/programy_szkolen_pdf/*")

public class PdfServlet extends HttpServlet {

	

	private static final String FONTS_PACKAGE = "fonts";

	private static final String FONTS_DIR = "/" + FONTS_PACKAGE + "/";

	

	protected void doGet(HttpServletRequest request,

			HttpServletResponse response) throws ServletException, IOException {				

		

		response.setContentType("application/pdf");

		OutputStream os = response.getOutputStream();

		

		String url = getUrl(request);



		try {

			ITextRenderer renderer = initRenderer();

			

			renderer.setDocument(url);

			renderer.layout();

			

			renderer.createPDF(os);

		} catch (Exception ex){

			throw new ServletException(ex);

		}

		

		response.flushBuffer();



	}



	private String getUrl(HttpServletRequest request) {

		String pdfServletPath = request.getServletPath();

		

		String cp = request.getContextPath();

		String program = request.getRequestURI();

		

		program = program.replace(cp + pdfServletPath, "");

		program = program.substring(0, program.length() - 4); // cut .pdf

				

		String url = "http://localhost:8080" + cp + program + ".xhtm?pdf=true";

		

		return url;

	}

}

Jak widać API latającego spodka jest proste:
- posługujemy się obiektem rendererm który posiada stan
- ustawiamy mu URL do strony, którą chcemy skonwertować na PDF
- wołamy metodę układającą pdf
- wynik kierujemy do strumienia odpowiedzi servletu.

I to generalnie byłoby wszystko:)

Zostało kilka szczegółów...
Metoda getUrl w moim przypadku robi pewne oszustwo operując na ścieżkach

Użytkownik woła servlet:
/programy_szkolen_pdf/szkolenie-java-start.pdf
btw: zauważcie jak zamapowany jest servlet: @WebServlet("/programy_szkolen_pdf/*")

A servlet wskazuje latającemu spodkowi adres:
http://localhost:8080/strona/szkolenie-java-start.xhtm?pdf=true

Zakładam, że zasoby do renderowania znajdują się na tej samej maszynie, stąd localhost.
Do czego służy parametr pdf dowiemy się za chwilę:)

Mamy jeszcze nieco smutnych szczegółów technicznych w naszym latającym spodku.

Renderera trzeba zainicjować - metoda initRenderer.

Jeżeli w PDF chcemy używać polskich (lub jakichkolwiek innych barbarzyńskich znaków), to musimy zarejestrować w rendereze fonty, których używamy w CSS (Arial, Verdana, cokolwiek). Służy do tego metoda renderer.getFontResolver().addFont
Ja napisałem prosty automat, metodę findFonts(), który automatycznie wyszukuje plików z fontami w *pakiecie* zdefiniowanym w stałej FONTS_PACKAGE. Chodzi o to aby uniknąć konfigurowania ścieżek. Po prostu skanujemy pakiet z class path.
Zatem do odpowiedniego pakietu należy sobie wkopiować (np z systemu) fonty. Oczywiście katalog powinien być niedostępny z sieci aby nie być posądzonym o dystrybucję komercyjnych fontów - jeżeli takowych używacie.

	

	private ITextRenderer initRenderer() throws IOException, DocumentException{

		List fonts = findFonts();

		

		ITextRenderer renderer = new ITextRenderer();

		

		for (String font : fonts) {

			renderer.getFontResolver().addFont(FONTS_DIR + font,

					BaseFont.IDENTITY_H, BaseFont.EMBEDDED);

		}			

		

		return renderer;

	}



	private List findFonts() throws IOException {

		Enumeration resources = getClass().getClassLoader().getResources(FONTS_PACKAGE);



		URL resource = resources.nextElement();

		File directory = new File(resource.getFile());



		List fonts = new ArrayList();

		if (!directory.exists()) {

			return fonts;

		}

		File[] files = directory.listFiles();

		for (File file : files) {			

			fonts.add(file.getName());

		}

		return fonts;

	}

Szablony

Dlaczego Facelets i JSF 2?

Do tej pory różnego rodzaju strony tworzyłem w PHP z wykorzystaniem Smarty. Po kilku doświadczeniach uznałem to za... powiedzmy niewygodne.

Chcę być dobrze zrozumiany - Smarty są ok dla pewnej klasy problemów: np wówczas gdy mamy kontent w bazie danych (jakiś CMS), pobieramy kontent jako wiersze i rozsmarowujemy po po "dziurkach" w szablonie. Wówczas imperatywne API Smarty (w postaci obiektu, na którym wołamy metody definiujące zmienne szablonu) jest jak najbardziej ok.

Natomiast ja w klasach problemów typu strona firmowa, preferuję przechowywać kontent (strzępy konwentu) w plikach XHTML. W takim wypadku praca z imperatywnym API to po prostu pomyłka. Jako "weteran" aplikacji webowych czuję się jak ryba w wodzie poruszając się w kodzie. Baza i CMS jedynie mnie ogranicza.

Dlatego tworząc nową wersję strony formowej zdecydowałem się na coś... delikatnie mówiąc... zastawiającego. Użycie JSF - standardu prezentacji enterprise (która ma swoich fanów jak i anty-fantów) do stworzenia strony www :O

Okazało się, że jeżeli nie używać formularzy (pomijamy większość faz cyklu obsługi żądania), nie używać ManagedBeanów, a jedynie składania kawałków XHTMla to okazuje się, bo jest to bardzo produktywne narzędzie.

Przykład:
strona http://bottega.com.pl/szkolenie-jsf-2
wygląda jak każdy widzi.

Jest wyraźnie podzielona na kontent merytoryczny i ozdobniki w postaci nagłówka, stopki i paneli bocznych.

A tak wygląda jej kod:

	xmlns:ui="http://java.sun.com/jsf/facelets"

	xmlns:h="http://java.sun.com/jsf/html"

	xmlns:f="http://java.sun.com/jsf/core"

	template="/layout/training_template.xhtml">

	

	

		

			

	



	Java Enterprise Edition



	JSF 2

	

		Java Server Faces 2



	Projektanci, programiści



	2 dni



	50% wykłady / 50% warsztaty



			

	

				Program został skontrowany tak aby przedstawić zagadnienia w kontekście konkretnych problemów, które ilustrują praktyczne wykorzystanie każdej z funkcjonalności JSF. 





Program szkolenia zawiera rozszerzenie o najlepsze praktyki projektowe i architektoniczne.





Tematyka szkolenia obejmuje wszystkie cechy frameworka JSF 2.0 istotne z punktu widzenia developera aplikacji.

Znaczniki ui:definie definiują wartości zmiennych, które będą używane w szablonie.
Wartości to czysty kod XHTML, który jest na bieżąco validowany przez edytor.

Stronę możemy zawołać na 3 sposoby:
- podając jej url: http://bottega.com.pl/szkolenie-jsf-2
- renderując ją do pdf: http://bottega.com.pl/programy_szkolen_pdf/szkolenie-jsf-2.pdf (wówczas nasz servlet przekaże adres http://bottega.com.pl/szkolenie-jsf-2.xhtm?pdf=true) do Flying Saucera
- zagnieżdżając w pływającej ramce na facebooku podając adres http://bottega.com.pl/szkolenie-jsf-2.xhtm?fb=true

W każdym z tych przypadków oczekujemy innego wyglądu.

Zatem znacznik ui:composition wskazuje szablon: template="/layout/training_template.xhtml"

Plik ten układa w odpowiednich miejscach parametry szkolenia. Szablon ten odpowiada jedynie za fragment strony (układ info o szkoleniu), ale nie zawiera np. nagłówka, stopki, ani bocznych boxów.

	xmlns:ui="http://java.sun.com/jsf/facelets"

	xmlns:h="http://java.sun.com/jsf/html"

	xmlns:f="http://java.sun.com/jsf/core"

	template="/layout/dispatching_template.xhtml">



		Szkolenie: 

		



	

									Informacje ogólne

Jak widać, szablon ten definiuje 2 zmienne: title i body. Wartości tych zmiennych zawierają w sobie XHTMLa oraz wartości zmiennych z dekorowane pliku - znacznik ui:insert.

Warunkowe renderowanie

Pomarańczowy przycisk "Zapytaj o szkolenie" jest niepożądany w przypadku wersji PDF i facebook, dlatego został warunkowo renderowany, przy pomocy panelGroup i atrybutu rendered:



  
zapytaj o szkolenie

Bean UrlChecker będzie opisany już za chwilę.

Wybór szablonu docelowego

Szablon szkolenia, nie jest szablonem "ostatecznym". Jest on dekorowane znowuż przez szablon wybierający szablon główny: template="/layout/dispatching_template.xhtml"

Jest to warstwa pośrednia pozwalająca w jednym miejscu przechowywać kod, który potencjalnie ulegnie zmianie. Tak oto wygląda dispatching_template.xhtml:

	xmlns:ui="http://java.sun.com/jsf/facelets"

	xmlns:h="http://java.sun.com/jsf/html"

	xmlns:f="http://java.sun.com/jsf/core"

	template="/layout/#{urlChecker.templateName}_pl.xhtml">

Jak widać nie dodaje żądnej wizualizacji a jedynie deleguje dekorowanie do kolejnego szablonu. Z tym, że nie mamy tutaj konkretnej ścieżki a jedynie wyrażenie wyliczane w Javie (tak w normalnym języku programowania a nie w jakimś pokracznym języku opartym o znaczniki):

@ManagedBean

public class UrlChecker {



	public String getTemplateName(){

		if (isPdf())

			return "template_pdf";

		

		if (isFacebook())

			return "template_facebook";

		

		return "template";

	}

	

	public boolean isStandard(){

		return ! (isPdf() || isFacebook());

	}

	

	public boolean isPdf(){		

		return "true".equals(getParameter("pdf"));

	}

	

	public boolean isFacebook(){		

		return "true".equals(getParameter("fb"));

	}

	

	private String getParameter(String name){

		ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();				

		return externalContext.getRequestParameterMap().get(name);		

	}

	

	

}

Zatem jeżeli zawołamy naszą stronę w ten sposób:
http://bottega.com.pl/szkolenie-jsf-2.xhtm
to w wyniku otrzymamy zawartość dekorowaną szablonem template_pl, który zawiera banner, stopę i boczne boxy

jeżeli natomiast w ten sposób:
http://bottega.com.pl/szkolenie-jsf-2.xhtm?pdf=true
to szablon dekorujący template_pdf_pl doda nagłówek i stopkę dla dokumnetu

a takie wywołanie
http://bottega.com.pl/szkolenie-jsf-2.xhtm?fb=true skutkuje zastosowaniem niemal niewidocznego szablonu dla facebooka.

Podsumowanie dekorowania

Mamy zatem następującą hierarchię treści:

szablon: szablon www | szablon pdf | szablon facebook
szablon: dispatcher
szablon: training
strona: konkretne szkolenie

Czyli na najwyższym poziomie mamy trzy perspektywy (szablony) spojrzenia na dane merytoryczne zawarte w plikach opisujących szkolenie.

Inne strony nie będące programem szkoleń po prostu pomijają szablon training_template i są dekorowane wprost szablonem dispatcher template

Układ dokumentu PDF w HTML i CSS3

Składanie stron w HTML jest dosyć łatwe. Wręcz banalne w porównaniu z natywnym API lub autyzmem Open Office.

Szablon pdf to zwykły XHTML:

	xmlns:ui="http://java.sun.com/jsf/facelets">

<head>





</head>



<body>

  !!! TUTAJ trzy warstwy opisane poniżej !!!

<</body>

Style po komentarzy "Specific Elements" są *kluczowe*.

Wewnątrz pierwszej warstwy mamy kolejno kolejno:

nagłówek:

		

   

      			

      Program szkolenia: ()

stopkę:

 
	  Bottega IT Solutions    http://www.bottega.com.pl

zawartość:

Program szkolenia

Na zakończenie bonus dla wytrwałych

Jak wołać w JSF 2 metody z parametrem? Zapewniam, że może się przydać w bardziej wyrafinowanych szablonach:)

Tak robimy to w Seam od 5 lat:

Natomiast w czystym JSF trzeba wykonać kilka prostych kroków aby uzyskać możliwość stosowania powyższej składni:
http://ocpsoft.com/java/jsf2-java/jsf2-how-to-add-the-magic-of-el-el2-to-jsf/

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

Mam nadzieję, że udało mi się pokazać, że w Javie można efektywnie a przy tym czysto i elegancko zbudować stronę.

Przy innej okazji pokażę jak Filtry Servletów w dosłownie kilku linijkach biją na głowę autystyczne htaccess:)

A Smarki?... Już nigdy więcej:)

Domain Driven Design - prezentacja z konferencji Confitura 2011

2011-07-24T20:59:00.003+02:00

Prezentacja jest już dostępna na Vimeo.
Miejscami kod przykładów może być mało czytelny ale przyjrzeć im się można z bliska na Prezi.

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

Przy okazji chciałbym podziękować wszystkim, którzy wyrazili swe opinie w ankiecie konferencyjnej. Jest to dla mnie najcenniejsze źródło informacji. Z 22 opinii tekstowych, 20 z nich odbieram jako bardzo ciepłe i przyjazne. Wasze słowa są na prawdę motywacją do tego aby następnym razem poświęcić jeszcze więcej czasu (po obejrzeniu video uznałem, że czas należy poświęcić również na kurs emisji głosu i dykcji oraz logopedę:)

Cieszę się, że niektórym przypadło do gustu poczucie humoru - z uwagi na poprawność nie mogłem powiedzieć wszystkiego co miałem na myśli:)

Jeszcze bardziej ciesze się z tego, że kilka osób zadeklarowało chęć zgłębiania tematu.

Co do czasu trwania prezentacji, to temat jest na tyle obszerny, że podczas prezentacji można jedynie zasugerować odbiorcom kierunki do własnych dalszych poszukiwań. Stąd pojawiły się również tematy bardziej zaawansowane (potraktowane zdawkowo jako zajawki) aby skorzystali również uczestnicy znający temat główny.

Pojawił się jeden zarzut co do użycia prezi. Moim zdaniem jest to narzędzie, które pozwala doskonale pokazywać ogół jak i szczegóły na zasadzie skalowania poziomu abstrakcji. W tym konkretnym przypadku zawiódł projektor, którego ubogi zakres barw nie pozwolił na wyświetlenie schematu warstw, co mogło być mylące.

Na koniec pozdrowienia dla osoby, która uznała język prezentacji za "bardzo lakoniczny" a efekty za "przytłaczającą ilość wodotrysków" - no cóż... jestem tylko prostym programistą, który próbuje jakoś nieudolnie opowiadać o swoich doświadczeniach i przemyśleniach a braki językowe i retoryczne próbuje nadrabiać/tuszować wodotryskami;P

Rozkład ocen prezentacji:
5: 62
4: 33
3: 8
2: 1
1: 2
Średnia: 4.43396226415094

Fowler o CqRS

2011-07-15T13:47:00.003+02:00

Koncepcja architektury CqRS doczekała się oficjalnego błogosławieństwa przez samego guru współczesnej inżynierii oprogramowania - Martina Fowlera.

/*
*Pamiętam jak jeszcze w kwietniu Greg Young opowiadał mi
* o swojej pierwszej prezentacji na temat CqRS,
* gdzie w pierwszych rzędach siedzieli: Uncle Bob, Eric Evans i Martin Fowler.
* Po prezentacji Evans podszedł i powiedział:
*bardzo słaba prezentacja, zrozumiałem tylko 30%:)
*/

Tak więc możemy uznać, że CqRS wchodzi do kanonu stylów architektonicznych - z zastrzeżeniem jednak co do zakresu stosowalności: okiełznanie chaosu w złożonych częściach systemu i potrzeba skalowania. Czyli w sumie otrzymujemy pogodzenie dwóch skrajnych interesów: elegancki model (np. DDD) z wysoką wydajnością.
"So while CQRS is a pattern I'd certainly want in my toolbox, I wouldn't keep it at the top."

Warto zwrócić też uwagę, że Fowler wyraźnie rozróżnia CqRS, który jest stylem architektonicznym od Event Sourcingu, który jest jedną z możliwych technik persystencji. Z obserwacji mogę powiedzieć, że często jest to zbyt silnie utożsamiane, ale należy pamiętać, że zawsze można mieć jedną z tych rzeczy bez drugiej.

Z ciekawych kontekstów, w których Event Sourcing zaczyna mieć sens oraz mocno się opłaca, jest wykorzystanie porcji zdarzeń jako wektorów uczących dla Sztucznych Sieci Neuronowych. Nie mówi się o tym zbyt wiele w mainstreamie, ale ES jest naturalną i od dawna stosowaną techniką w tych klasach systemów. Próba przeniesienia ES na systemy gdzie nie ma takich zastosowań na pewno się powiedzie, pytanie tylko jakim kosztem w stosunku do jakich zysków...?

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

Wiele osób pyta o postępy w przygotowywaniu naszego DDD-CqRS Sampla w Javie.
Pierwszy milestone zbliża się dużymi krokami. Mamy trzy małe konteksty domen z przykładami każdego Building Blocku. Stos biznesowy jest ilustrowany zarówno klasycznie serwisami jak i commandami, gdzie mamy kilka ciekawych technik takich jak asynchroniczność i filtrowanie duplikatów. Sagi docelowo będą działać na JMS. Stos prezentacji ilustruje kilka typowych optymalizacji odczytu.

Chętnych, którzy chcieliby ocenić projekt przez jego upublicznieniem zapraszam do kontaktu.

Domain Driven Design - Sposób na projektowanie złożonych modeli biznesowych (plus niespodzianka)

2011-07-04T20:57:00.007+02:00

W ostatnim numerze Software Developer's Journal ukazał się artykuł mojego autorstwa: "Domain Driven Design - Sposób na projektowanie złożonych modeli biznesowych".

Tekst przeznaczony jest zarówno dla początkujących jaki i średnio zaawansowanych praktyków DDD.
Początkujący znajdą w nim:
- ogólną ideę oraz zakres stosowalności podejścia
- przykłady kodu
a średnio zaawansowani mogą zapoznać się między innymi z:
- technikami komunikacji zdarzeniowej pomiędzy Bounded Context
- nową koncepcją Sagi biznesowej

Zachęcam oczywiście do pobrania i przeczytania całego numeru SDJ, ale dla wygodnych link bezpośredni do tekstu: pobierz.

Dla wzrokowców przydatna może być prezentacja ilustrująca architekturę systemu wykorzystującego DDD: Domain Driven Design - A place for everything and everything in its place. tekst artykułu jest niejako narracją do tej prezentacji.

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

Przy okazji zdradzę informację związaną z tematem posta. W firmie Bottega pracujemy dla Was nad upublicznieniem projektu-sampla (wraz z dokumentacją) ilustrującego w realny i niestrywializowany sposób wszystkie techniki DDD oraz kilka możliwych podejść do implementacji CqRS.

Aktualnie dla środowiska Javy istnieją tylko 2 projekty oscylujące wokół tej tematyki (za: http://cqrsinfo.com/examples) a nasz będzie charakteryzował się:
- prezentacją szerokiego wachlarzu technik DDD w różnych kontekstach
- praktycznym rozwiązaniem typowych wyzwań i problemów projektowych
- gotowym do użycia szkieletem: Spring, Maven, JPA, klienty webowe i zdalne (Android, Ajax)
- kompletna wiki opisująca ideę oraz wyjaśniająca wszystkie szczegóły techniczne, podjęte decyzje projektowe i architektoniczne oraz omawiająca możliwości zmiany podejścia i jego rozbudowy
- wsparciem dla testów integracyjnych oraz metodyki Behavior Driven Developemnt
- wsparciem dla skalowania w środowisku cloud
- racjonalnym podejściem do CqRS bez niepotrzebnego onanizmu technicznego
- i co najważniejsze: nie tworzymy kolejnego frameworka! Formą dystrybucji będzie "zaczyn" (zaczyn to coś z czego wyrasta chleb - ten prawdziwy:)
To Ty jesteś architektem i decydujesz jak wygląda Twój kod!
- sample będzie oczywiście całkowicie darmowy i otwarty

Trawienie Confitury

2011-06-12T12:08:00.009+02:00

Na parking dotarliśmy o 0850 po 2 godzinach podróżny na dystansie 170km (widocznie gdzieś po drodze nastąpiło lokalne zagięcie czasoprzestrzeni). Następnie udaliśmy się do punktu rejestracji na 3. piętrze...

STOP!

Przepraszam, zapomniałem, że blog to nie zeszyt do polskiego, a post to nie sprawozdanie z wycieczki do muzeum w 4. klasie podstawówki;P

Na wstępie gratulacje i uznanie dla organizatorów za rozmach oraz podziękowania dla wolontariuszy.

Chciałbym podzielić się przemyśleniami z kilku prezentacji:

Pisz po pijaku, przeglądaj na trzeźwo
Bezkompromisowa i nonkonformistyczna forma. Wspaniała interakcja z publicznością, bez puszenia się i pokazywania jaki to ja jestem mądry. Doskonałe zakończenie dnia.

W momencie kiedy Piotr wniósł sześciopak piwa i żołądkową (bo poprzednicy rozdali wszystkie gadżety przeznaczone na nagrody dla uczestników) pomyślałem tylko: "wiedz, że coś się dzieje":)

Na prezentacji mieliśmy błyskotliwą syntezę dwóch - popularnych ostatnio w "miękkim" IT - koncepcji:
- Model mózgu składającego się z "procesorów" Rich i Linear
- Model kompetencji Braci Dreyfus
Synteza polegała na postawieniu tezy, że ekspert w danej dziedzinie (piąty poziom Dreyfus) myśli nad problemem głównie "procesorem" Rich.
Nie wiem czy istnieją badania potwierdzające tą hipotezę, ale mnie się podoba, bo wydaje się brzmieć sensownie - póki co "kupuję to".
To do czego dotarłem w literaturze tematu i co wiadomo na pewno, to fakt, że ekspert na pewno czasem (w twórczym uniesieniu) myśli mniej, jest to zjawisko tak zwanego "lśnienia" polegające na tym, że podczas małej aktywności mózgu (zużycie energii) dochodzi do wykonania dużej i przełomowej pracy intelektualnej. Zjawisko to można obserwować na rezonansach.

Widziałem duże zainteresowanie publiczności, więc polecam materiały:
- Pragmatic Thinking and Learning: Refactor Your Wetware - dowiecie się z niej na temat modelu R/L oraz kilkunastu innych arcyciekawych i przydatnych w życiu sprawach. Autor dokonał syntezy wieli zagadnień z psychologii, socjologii, kognitywistyki podając je na tacy tak abyśmy nie musieli już sami szukać. Najlepsza książka jaką czytałem w zeszłym roku. Książki pisane przez programistów zawsze są dobre...
- Developing Expertise: Herding Racehorses, Racing Sheep - prezentacja na temat Dreyfus.
Materiał z kategorii "musisz zobaczyć".
- Wspinaczka do profesjonalizmu - artykuł na temat Dreyfus, który popełniłem w zeszłym roku dla Software Developer's Journal.
Miło było usłyszeć na prezentacji kilka odniesień do tekstu:)

Wracając do prezentacji Piotra, warto zapamiętać dwie rady praktyczne - techniki na uruchamianie Rich "procesora":
- odwracanie problemu: jeżeli nie wiemy jak zoptymalizować kod, to może zastanówmy się jak go spowolnić; jeżeli nie wiemy jak zaprojektować ergonomiczne GUI, to zastanówmy się jak zaprojektować je w sposób ultra-autystyczny.
Dlaczego to działa? Odsyłam do książki "Pragmatic Thinking and Learning" a później dalej...
- pair programming: niewiele osób uświadamia sobie, co się dzieje podczas programowania w parach. Mianowicie driver programując (czyli myśląc symbolicznie) pracuje na swoim "linearnym procesorze" a pilot zwolniony z tych czynności może uruchomić "procesor rich" i dokonywać myślenia syntetycznego na zasadzie nieświadomego pattern matching.

Play!Framework - ewolucja w świecie aplikacji webowych
Można opowiedzieć o frameworku webowym w sensowny i poukładany sposób tak aby było od razu wiadomo o co chodzi i kiedy oraz do czego mogę go użyć?
Można!
Brawa dla Wojtka. Konkretnie, na temat, dobrze dobrane przykłady kodu, dobre rysunki, szeroki zakres wiedzy i wszystko w 45 min! Wyszło lepiej niż filmiki na oficjalnej stronie frameworka.
Szczerze mówiąc to zacząłem rozważać Play jako narzędzie do pewnych klas problemów. Dzięki Wojtek.

Warto zwrócić uwagę na prezentację jako wzór do naśladowania:
- kod na Youtube z komentarzem na żywo prowadzącego (na pewno się nie wywali i nie będziemy tracić czasu na słuchanie nieśmiesznych tłumaczeń, że na prezentacji nigdy nie działa)
- szeroki wachlarz tematów do omówienia do wyboru wg zainteresowania słuchaczy (z uwagi ograniczony czas prezentacji).

Jeszcze raz brawo.

Quo Vadis IT
Pana Tomasza pamiętam jeszcze z zamierzchłych czasów studenckich, gdy przyjeżdżał na nasze rodzime uczelnie i priczował na temat technologii Microsoftu. Dałem się wówczas uwieść - ale tylko na chwilę:)

Prezentacja bardzo ciekawa, z uwagi na tematykę. Spojrzenie na branżę IT z wysokości 10km, co pozwala zauważyć powtarzające się w czasie patterny.

Widać było też na jakim poziomie i jak wnikliwie MS analizuje potrzeby oraz nawyki Userów (prywatnie i w pracy) oraz jak dobrze rozumie przemiany społeczne i mentalne zachodzące w czasie.

Miazga. My robaczki siedzimy sobie i męczymy się z kodzikiem, podczas gdy wysoko ponad naszymi głowami ktoś obserwuje i planuje rzeczywistość na kilkanaście lat do przodu.

Re-fuck-toryzacja czyli sprowadzanie sp****go kodu na właściwe tory
Paweł - dzięki za odniesienie do posta na temat radzenia sobie ze złożonością.
Muszę jednak zwrócić uwagę, że to co wyszło podczas refaktoryzacji to nie była Strategia a raczej zmodyfikowany Chain of Responsibility. Zmodyfikowany w taki sposób, że każde ogniowo łańcucha odpowiadało na pytanie "czy umiesz zająć się problemem", a jeżeli tak to "zajmij się". Czasem stosuję takie konstrukcję - łańcuch zarządzany przez "managera" - zębatkę.

Taka "zębatka" może być sama w sobie implementacją interfejsu strategii. Czyli mamy złożenie 2 patternów: strategia na wyższym poziomie (wariacje rozwiązania dużego problemu), a jedną z implementacji strategii może być taka zębatka zarządzająca łańcuchem małych ogniw, które coś tam sobie liczą (mikro problemiki wchodzące w skład jednego z wariantu rozwiązań problemów wyższego rzędu).

Teledysk na koniec - rotfl. Dobre zdjęcia, ładny dom:)

Co do mojej prezentacji, to jak zwykle: trema, przez którą wychodzi inaczej niż się planowało. Gadzi mózg podpowiada, że jeżeli stoisz sam bez broni i bez schronienia przed liczną grupą jakiś osobników to najpewniej za chwilę zginiesz. Ehh instynkt.

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

Przy okazji podzielę się jednak ciekawą obserwacją odnośnie psycho-akustyki (którą ostatnimi czasy nieco się interesuję). Z uwagi na wielkość sali, konstrukcję ścian, siłę oraz ustawienia nagłośnienia (i kilkanaście innych niesprzyjających uwarunkowań pomieszczenia) pojawił się efekt echa. Nie pogłosu, który jest do zniesienia a echa, które jest dla mówiącej osoby zabójcze.

Jako, że jestem tak zwanym słuchowcem (nie jest to takie proste, ale przyjmijmy na potrzeby posta, że jest coś takiego jak słuchowcy) to taki efekt nie jest tylko drażniący. U mnie niemal uniemożliwia mówienie. Przez chwilę myślałem, że się rozpłaczę ucieknę ze sceny hehehe.

Nie wiem czy ktoś włączył tłumienie fal obitych, ale nie widziałem nikogo majstrującego przy wzmacniaczach. Jednak po kilku minutach efekt echa zniknął. Ehh mózg ma niesamowitą zdolność do kompensowanie bodźców. A to co słyszymy jest tylko tym co nam się wydaje:)

Degustacja Confitury

2011-06-08T21:46:00.002+02:00

Confitura odbędzie się 11 czerwca ale już dziś możecie sprawdzić czy warto przyjść na jedną z prezentacji.

Abstrakt: Domain Driven Design - Wszystko ma swoje miejsce i wszystko jest na miejscu

Domain Driven Design - A place for everything and everything in its place on Prezi

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

W branży można spotkać się z dwoma podejściami do prezentacji:
- niespodzianka
- możliwość obejrzenia wcześniej

Ja preferuję drugie podejście z tego samego względu, dla którego sprawdzam dema gier, czytam wyrywki tekstu z książek w księgarni oraz sprawdzam recenzje filmów - po prostu oszczędność czasu:)

Zawiązywanie sznurowadeł - robisz to źle

2011-06-07T11:26:00.001+02:00

...sprawdź i przekonaj się, video trwa tylko 3 minuty:)

Zweryfikowałem wczoraj na butach biegowych z wyślizganymi od użytkowania sznurowadłami. Działa!

TED jak zwykle "uczy i bawi".

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

Swoją drogą ciekawe ile jeszcze takich oczywistych oczywistości robimy nie do końca dobrze...

"live long and prosper":)

Rekrutacja

2011-06-06T19:34:00.019+02:00

Temat zadań rekrutacyjnych dla developerów przewija się w branży co jakiś czas. Ostatnio znowu odżył ze względu na odbicie do tak zwanego kryzysu.

Post jest głosem w dyskusji, jaka toczy się na grupie Warszawa JUG, którą to czytam namiętnie ze względu na spektrum tematów oraz aktywność członków.

Dyskusja zaczęła od pytania o słuszność lub nie wymagania wiedzy na temat sortowania kolekcji obiektów w Javie. Chodzi o użycie biblioteki standardowej/trzeciej a nie o implementację od zera sortowania bąbelkowego (bo i o takich kuriozach się słyszy).

Wydaje mi się, że dyskutowanie nad treścią zadań bez określenia kontekstu to podchodzenie do problemu od złej strony.

Zaczynając rekrutację musisz odpowiedzieć sobie na kilka pytań: kogo poszukuję, do jakich klas problemów, do jakich typów zdań, z kim ma pracować i jakie są plany na przyszłość (co do tej osoby, co do całego teamu).

Pracując w różnych firmach jako lider techniczny zajmowałem się między innymi rekrutowaniem pracowników. Straciłem rachubę, ale w sumie przewinęło się ok 100 osób. Pamiętam jakie błędy robiłem, głównie na poziomie założeń. Teraz pomagam klientom znajdować odpowiednich ludzi na określone stanowiska.

Inny skillset będzie potrzeby dla kogoś kto dodaje ficzery biznesowe a inny dla kogoś kto rozwiązuje łamigłówki na poziomie optymalizacji lub algorytmicznym. Inny dla kogoś kto projektuje systemy/frameworki a inny dla kogoś kto implementuje aplikacje. Inny dla kogoś kto implementuje sexi gui a inny dla kogoś, kto modeluje złożone domeny biznesowe. Inny dla kogoś kto kreuje kierunek dla nowych projektów a inny dla kogoś, kto utrzymuje legacy.

Na skillset składa się wiele wymiarów - znajomość języków i technologii to tylko jeden z nich. Czasem wystarczający a czasem nie (czasem pomijalny?). Temat jest generalnie bardzo szeroki i wchodzi głęboko w psychologię - np. typy osobowości, z których wynikają sposoby myślenia, predyspozycje, słabe i mocne strony. Generalnie nie ma ludzi perfekcyjnych, każdy ma słabe strony, chodzi o to aby "w boju nie wystawiać tych miękkich części na ciosy" - po prostu dobierać ludzi do zadań/wyzwań
Ale to wymaga też zrozumienia wyzwań jakie pojawią się w projekcie oraz zrozumienia cech jakie lepiej lub gorzej predysponują śmiałka do podjęcia wyzwania:)

Strategia dla teamu jest prosta: wzajemne uzupełnianie się cech - a z tego gratisowo dostajemy efekty synergiczne:)
Podstawowym narzędziem może być model Belbina - ale to dopiero początek układanki.

Ignorowanie aspektów miękkich i kompletowanie zespołu na zasadzie: "dawać mnie tu sześciopak programistów" sprawdzi się owszem w niektórych przypadkach. W rekrutacji do projektów Komisji Europejskiej w Luksemburgu jednak już nie zadziała...

Wracając do zadania z sortowaniem kolekcji przez bibliotekę standardową... Zastanówmy się co ono sprawdza. Na pewno to czy ktoś już tego używał, czyli czy otarł się o ogólne programowanie w Javie (i ew. proste wykorzystanie w algorytmach). Oczywiście kandydat mógł nie mieć do tej pory okazji sortowania niczego - zdarza się.

Skoro tak, to nie miał tez okazji przeczytania żadnej książki poświęconej programowaniu w Javie. Po prostu nie da się nie trafić na sort. Prawdopodobnie ilość artykułów jakie pochłonął jest niewielka (tak elementarna rzecz jak sortowanie pojawia się z prozaicznej konieczności nawet w zaawansowanych tekstach).

Jaki wniosek możemy wysnuć na tej podstawie... hmmm... ja się wstrzymam z wnioskowaniem, czekam na propozycje w komentarzach. Nie zakładałbym jednak, że zawsze poszukujemy kogoś, kto "traci czas" na czytanie książek...

Ale na pewno jeżeli kandydat nie potrafi podać odpowiedzi, warto sprawdzić w jaki sposób ją zdobędzie i na ile ją zrozumie.

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

Co do zadań ogólno-programistycznych to wdzięcznym tematem jest napisanie utilsa obliczającego pole prostokąta. Tak utilsa, statyczną metodę, beż żadnych Object Oriented, w przestrzeni Euklidesowej, zwykłe a * b.

Co sprawdzimy? Coś co można określić stylem.
1. nazwy parametrów - od czego zależy dobór? a,b czy może x,y albo width,height? szczegół? tak, ale jednak...
2. dobór typów. kiedy własne typy? co z jednostkami? wynik jest w kwadracie - jakie operacje są na nim dozwolone później? czy jest to problem naszego utilsa? szeroki temat do dyskusji...
3. sprawdzanie wartości wejściowych - sprawdzać czy nie, od czego to zależy?
4. nazwy, nazwy, nazwy
5. jakie wyjątki? dlaczego?
6. komentarze. a może nie ma takiej potrzeby? dlaczego?
7. testy! a może nie;P dlaczego?

Nikt nie zarzuci wymogu znajomości bibliotek (ew. junit/testng), egzotycznych algorytmów, wyrafinowanej składni, fizyki kwantowej. Wzoru na pole prostokąta jednak bym nie podawał w treści zadania;)

Tego typu zadanie oczywiście nie zaważy na przyjęciu/odrzuceniu kandydatury na stanowiska develoepra aplikacji postawionych na stosie 10 frameworków, ale potencjalnie może wskazać wygodne dla kandydata miejsce.

Obraz konkurencji

2011-06-05T15:13:00.000+02:00

Osobiście nie miałem nigdy okazji pracować z developerami z Indii, ale z opowieści wielu znajomych z branży wnioskuję, że jest to ciekawa przygoda...

Natrafiłem dziś na artykuł, którego autor zdaje się znać sytuację od podszewki: Guru i trzej idioci.

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

Tekst można polecić również tym, którzy narzekają na polski system edukacji:)

Sposoby enkapsulowania złożonej logiki biznesowej

2011-06-01T14:38:00.019+02:00

W ostatnim poście poruszyłem pewne podstawowe zagadnienia z zakresu projektowania obiektowego, ale jak słusznie zauważyli komentatorzy przykład jest na tyle trywialny, że narzucające się proste rozwiązania są w zupełności wystarczające.

Podejdziemy do problemu raz jeszcze, tym razem w bardziej realistycznym kontekście aplikacji biznesowej.

Mamy zatem ten nieszczęsny OrderItem - nieszczęsny, ponieważ przykład pochodzi z książki, którą ostatnio recenzowałem. Klasyczny model zamówienia: Order-OrderItem-Product

W książkowym przykładzie OrderItem jest obiektem domenowym (rich model) i posiada oprócz stanu również zachowanie - odpowiedzialności biznesowe. Autor książki nawiązuje do Domain Driven Design, dlatego będę się posługiwał Building Blockami modelowania DDD.

Nasz OrderItem zawiera metodę getShippingCost(), która nie jest getterem a metodą biznesową - oblicza koszt dostawy danej pozycji na zamówieniu.

Sugerowana w książce rozbudowa modelu to dodanie nowych klas dziedziczących po OrderItem, które zmieniają sposób liczenia kosztu. Problemy z tym podejściem opisałem w poprzednim poście, w skrócie: w takim obiekcie biznesowym mamy wiele odpowiedzialności, więc prowadzanie dziedziczenia aby zmienić jedną z nich szybko doprowadzi do eksplozji kombinatorycznej bytów.

<dygresja>
Zacznijmy od tego, czy w ogólne taka metoda powinna należeć do tej klasy? W rzeczywistym systemie obliczenie kosztów dostawy zależy zapewne od wielu czynników - nie tylko od zamawianego produktu, ale również od tego kim jest klient, od miejsca dostawy, od reszty zamówienia itd.
Być może cała wiedza znajduje się w klasie OrderItem... Być może wyżej - w Order... Być może nie... wówczas należy wynieść cały problem do osobnego SerwisuBiznesowego (BuildingBlock modelowania DDD).

Nawet jeżeli dziś cała wiedza znajduje się w OrderItem czy nawet w Order, ale w przyszłości zmienią się wymagania i będziemy musieli implementować dziwne akrobacje aby w OrderItem/Order zdobyć potrzebne do obliczeń obiekty.

Generalnie serwis rokuje na lepszy design modelu (serwis biznesowy jest częścią modelu w DDD). W DDD nie chodzi o to aby całą logikę rozsmarować po encjach/agregatach/vo. Nic podobnego. Prosta reguła "kciuka" dla początkujących może być taka: encje/agregaty/vo posiadają metody używane wielokrotnie. Specyficzne metody używane jeden raz znajdują się w specyficznych serwisach biznesowych

Jednak te rozważania nie mają wpływu na dalszą część posta. Abstrahując od tego, którym miejscu umieścimy odpowiedzialność obliczeń wciąż możemy stosować techniki opisane poniżej.

W dalszej części, dla uproszczenia, zakładamy, że większość potrzebnej wiedzy znajduje się w OrderItem.
</dygresja>

W realnej aplikacji obliczenie kosztu dostawy:
- zależy od wielu czynników (rodzaj produktu, klient i jego rabaty, miejsce docelowe, składowe zamówienia, historia zamówień itd)
- jest złożone (załóżmy kilkanaście-kilkaset linijek kodu)

Ta więc rozważania z poprzedniego posta (i komentarzy) gdzie proponowaliśmy switche albo Mapy strtegii się nie aplikują.

Przy standardowym podejściu kod będzie wyglądał mniej więcej tak:

class OrderItem{
  Money getShippingCost(){
    if if if if if
      //17 liniek obliczen
    if if if if
      //50 liniek obliczen z ifami
  }
}

... i wcale nie spodziewajmy się "eleganckiego" switcha, który załatwia sprawę. Mamy tutaj do czynienia z potworkiem rzędu setek linijek, brak ustalenia jednego poziomu abstrakcji, nieustanne skoki mentalne po różnych poziomach oraz potencjał na to, że biznes będzie się komplikował i z czasem wyhodujemy ośmiotysięcznika.

Generalnie przy standardowym podejściu kodzik będzie przeplatał w sobie 3 rodzaje odpowiedzialności:
1. zdecydowanie który scenariusz/algorytm obliczania kosztu zastosować
2. sam algorytm
3. ew. pozyskanie dostępu do danych potrzebnych do obliczeń

Czyli w jednym miejscu mamy 3 rodzaje zależności, o których pisze Misko Hevery.
- colaboration
- construction
- call

Aby uniknąć tego poziomu smutnej złożoności, proponowane w poprzednim poście rozwiązanie (czwarte) sugeruje aby:
1. odseparować samą logikę obliczenia kosztu od reszty kodu.
Wprowadzamy interfejs Strategii, np

interface ShippingCostCalculator{
  Money calculateCost(...);
}

2. kawałki kodu stanowiące każdy z algorytmów pakujemy do osobnej klasy implementującej ten interfejs, np ForeginShippingCostCalculator, LargeItemShippingCostCalculator

2.a co jeżeli wysyłamy duży przedmiot za granicę? tworzymy trzecią klasę ForeginLargeItemShippingCostCalculator? Nie! Z pomocą przychodzi Decorator Design Pattern.

ShippingCostCalculator calculator = new ForeginShippingCostCalculator(new LargrItemShippingCostCalculator());
}

3. kawałki logiki wybierającej, którą konkretną politykę stworzyć chowamy w Fabryce.
I nie jest jeden switch ale kłębowisko ifów

Możemy fabrykować cały agregat:

//fabrykowanie całego agregatu

  class OrderItemFactory{
  OrderItem createOrderItem(...){
    ShippingCostCalculator calculator = //100 ifów;
    return new OrderItem(calculator);
  }
}

albo jedynie strategię:

//fabrykowanie jedynie strategii

  class ShippingCostCalculatorFactory{
  ShippingCostCalculator createShippingCostCalculator(...)
    ShippingCostCalculator calculator = //100 ifów;
    return calculator;
  }
}

Wybór podejścia - co fabrykować: agregat czy strategię zależy do tego w którym momencie mamy wiedzą potrzebną do wyboru kalkulatora. Przed czy dopiero po powołaniu do życia OrderItema.

Generalnie lepiej jest posługiwać się Agregatem i ukrywać szczegóły typu istnienie strategii, ale nie zawsze jest to możliwe.

Tutaj jako agregat traktujemy OrderItem a nie Order, bo tak to wygląda w rzeczywistych systemach, np. klasy ERP - widziałem.

3a. co jeżeli aby wybrać konkretny kalkulator potrzeba znać np aktualnie zalogowanego użytkownika? Lub ogólnie: jakiś kontekst, którego brakuje w OrderItem?
Taka Fabryka może być komponentem zarządzanym (EJB, Speing Bean, itd) i możemy do niej wstrzykiwać potrzebne informacje.

class ShippingCostCalculatorFactory{
  @Inject
  LoggedUser loggedUser;  //logged user to obiekt apliakcyjny (niebiznesowy), trzymany w sesji

  ShippingCostCalculator createShippingCostCalculator(...)
    //if (loggedUser.role == ADMIN)
    ShippingCostCalculator calculator = //100 ifów ;
    return calculator;
  }
}

3b. co jeżeli któraś konkretna strategia obliczania kosztu potrzebuje informacji o zewnętrznym kontekście (np zalogowanym userze)? Chodzi o przypadek gdy metoda z interfejsu strategii nie ma w parametrze tego co potrzebuje implementacja. Fabryka może przekazać kontekst do konkretnej strategii przez jej konstruktor.

class ShippingCostCalculatorFactory{
  @Inject
  LoggedUser loggedUser;  //logged user to obiekt apliakcyjny (niebiznesowy), trzymany w sesji

  ShippingCostCalculator createShippingCostCalculator(...)  
    ShippingCostCalculator calculator = //100 ifów ;
    calculator = new XyzCalculator(loggedUser.getUserId());
  
    return calculator;
  }
}

Podsumowując:
Rozdzielamy silny coupling (współpracy, tworzenia, wywołania) do osobnych "pudełek".
Strategie: tylko obliczenia;
Fabryki: ecydowanie o typie strategii oraz ewentualnie składanie obiektów (przekazywanie szerszego kontekstu do strategii lub dekorowanie strategii)

Dzięki rozdzieleniu możemy niezależnie testować jednostkowo Agregaty i Strategie (Polityki w nomenklaturze DDD). A to za prawą fabryk, w których mieszkają operatory new. Agregaty są od nich wolne, więc mamy możliwość mockowania/stubowania strategii na czas testów.

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

Tak jak pisałem w poprzednim poście: wprowadzenie Strategii zaczyna się nam opłacać dopiero przy złożonych modelach biznesowych. Pokazałem tutaj dodatkowo złożenie Strategii i Dekoratora wraz z idiomem Fabryki oraz wystrzykiwaniem zależności. Dopiero w synergii technik tkwi prawdziwa siła.

Ważne jest to aby w ogóle modelować złożoność. Jeżeli nie modelujemy złożonego problemu a jedynie "zamiatamy go pod dywan" w postaci ukrytych gdzieś głęboko ifów to model szybko upada na twarz;)

Podstawowa zasada Domain Driven Desigm mówi: make explicit what is implict. Czyli wydobywajmy ważne koncepcje biznesowe na powierzchnię. Nie ukrywajmy ich w ifach w linijkacj od 5000 do 6000.

A czy jest coś ważniejszego w modelu biznesowym niż różne sposoby liczenia pieniędzy?;)

Na koniec jedna uwaga: zawsze gdy pokazuję na warsztatach tego typu przykłady część uczestników jest wręcz urzeczona "pudełkowaniem" złożonej logiki w małe, eleganckie pudełeczka. Inni z kolei preferują jedno pudło (np procedurę) ponieważ łatwiej im ogarnąć jedno pudło niż wiele małych, nawet kosztem tego, że w tym jednym pudle jest, powiedzmy delikatnie - bałaganik.

Wszyscy różnimy się mocno pod względem oceniania tego co jest proste. Więcej na ten temat: O programiście-pisarzu i programiście-konstruktorze.

Koszt Dostawy

2011-06-01T00:27:00.007+02:00

Odnośnie poprzedniego posta - Jacek L. zadał pytanie o przykład podejścia do liczenia kosztu dostawy.

Mamy kilka możliwości...

Załóżmy, że ma my klasę:

class OrderItem{
  //pola
  metodaBiznesowa1(){..}
  metodaBiznesowa2(){..}
  metodaBiznesowa3(){..}
}

Co jeżeli mamy różne rodzaje/odmiany itemów, gdzie zachowanie tych metod różni się - innymi słowy algorytmy są różne?

1. Rozwiązanie na switchach:

metodaBiznesowa1(){
  switch(jakisParametr){
    case x: return ...
    case y: return ...
  }
}

Konsekwencje: wszelkie zmiany wymuszają "grzebanie" w corowym kodzie biznesowym, czyli jego "brudzenie" czyli ponowne testowanie (nie jest to problem jeżeli mamy pokrycie testami automatycznymi:)

2. Rozwiązanie struktura i algorytmy danych
Generalnie podobne do poprzedniego z tym, że z wyniesieniem kodu biznesowego na zewnątrz - podane dla uzupełnienia wachlarza możliwości:

class OrderItem{
//gettery i settery
}

class BusinessService1{
  doSth(OrderItem oi){
    switch(oi.getSth())
    //...
  }
}

3. SŁABE (ale to zależy od szerszego kontekstu) rozwiązanie z dziedziczeniem:

Tworzymy specjalne klaski dziedziczące po OrderItem, w których nadpisujemy odpowiednie metody biznesowe.

Konsekwencja: mnożenie bytów.

Co jeżeli:
- OrderItem1 nadpisze metodę metodaBiznesowa1
- OrderItem2 nadpisze metodę metodaBiznesowa2
a OrderItemBum chce mieć obie metody biznesowe 1 i 2 takie jak klasy wymienione poprzednio?
Eksplozja kombinatoryczna!

Dziedziczenie jest dobre, ale wówczas gdy klasa ma ściśle określoną odpowiedzialność (jeden powód do zmiany). Wówczas nie ma możliwości zajścia eksplozji kombinatorycznej oraz mamy zwykle pewność zachowania Liskov Substitution Principle.

Co jeżeli klasy dziedziczące są wymagane ponieważ dodają nowe atrybuty?
Wówczas rozwiązanie z dziedziczeniem zaczyna się bronić. Jednak wciąż może dojść do eksplozji klas.
Wówczas lepiej łączyć rozwiązanie z dziedziczeniem z rozwiązaniem 4.

Innym podejściem jest unikanie dziedziczenia i zastosowanie Archetypu Biznesowego Product.

4. Wprowadzenie wzorca strategii.

class OrderItem{
  metodaBiznesowa1(){
    return strategiaBiznesowa1.go(...);
  }
  metodaBiznesowa2(){
    return strategiaBiznesowa2.run(...);
  }
  metodaBiznesowa3(){..}
}

StrategiaBiznesowa1,2 są interfejsami. Konkretne implementacje zajmują się szczegółami.
Unikamy eksplozji kombinatorycznej z podejścia trzeciego dlatego, że w tym przypadku ilość klas to suma możliwych strategi dla każdej metody biznesowej a nie ich iloczyn.

Ale zostawmy autystyczne miary ilościowe... Ten design się po prostu "czuje". Tak jak w naiwnym szkolnym przykładzie: samochód zawiera skrzynię biegów - pasującą do interfejsu (śruby, tryby). Samochód w żadnym wypadku nie dziedziczy po skrzyni biegów:)
//Chociaż kiedyś na rekrutacji ktoś na pytanie o nieksiążkowy przykład dziedziczenia odpowiedział mi: "telefonistka dziedziczy po telefonie".

Skąd OrderItem posiada strategieBiznesowe?

a) OrderItem pobiera z fabrykStrategii - niedobre ze względu na testability

b) OrderItem ma je "wstrzyknięte" z zewnątrz przez FabrykiItemów, które go tworzą lub przez RepozytiumItemów, które pobierają go z bazy.

ew. Fabryki/Repozytoria tworzą nadrzędny agregat (np Order), który zawiera w sobie itemy, ale to zależy od domeny - mechanizm jest ten sam.

To jaką staregięBiznesową "wstrzyknąć" jest decyzją biznesową, tak więc Fabryki/Repozytoria zawierają taką logikę odciążając coupling tworzenia od coplingu używania.
Więcej o rodzajach couplingu dowiemy się od ekspertów Google.

Warto zauważyć, że sama Strategia semantycznie jest niczym innym jak Funkcją (w kontekście programowania funkcyjnego) przekazaną na prawach First Class Citizen. Jedynie syntaktycznie mamy niezręczność wynikającą ze składni Javy;)

Wprowadzenie Wzorca Strategii zaczyna się nam opłacać pod warunkiem, że:
- spodziewamy się pojawiania się kolejnych strategii w przyszłości
- chcemy testować jednostkowo niezależnie logikę OrderItema od logiki StrategiiBiznesowych

Pośrednim rozwiązaniem prowadzącym w kierunku wzorca - dającym potencjał na łatwy refaktoring w przyszłości jest:
1. wyciągnięcie interfejsu
2. dostarczenie jedynej implementacji jako serwisu ze słczami w stylu rozwiązania drugiego.

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

O opłacalności wprowadzenia Strategi możemy mówić również na poziomie modelowania.

Np w DDD nie mówi się Strategia lecz Polityka. Polityki są częścią modelu - obok encji i kilku innych "klocków".
Skutkuje to tym, że zaczynamy pokazywać wariacje istotnych zachowań biznesowych w modelu (diagramach, itd) a co za tym idzie zaczynamy o nich mówić (wchodzą do Ubiquotus Language)
Co najważniejsze: zaczynamy zauważać te arcy-ważne z biznesowego punktu widzenia komponenty - już nie siedzą w słiczach w linijce numer 5000 w serwisie-ośmiotysięczniku;P

Przemyślane praktyki Java EE

2011-05-31T22:27:00.008+02:00

Dziś krótka recenzja książki Adama Biena Real World Java EE Patterns - Rethinking Best Practices.

Zacznę od konkluzji: czy warto? Tak. To jak bardzo warto zależy od Twojego dotychczasowego backroundu, ale gwarantuję, że nawet eksperci Javy EE znajdą dla siebie kilka ciekawych kawałków. Pozycja konkretna, na temat, z przykładami wykorzystującymi ciekawe kruczki z np. EJB 3.1.

Na początku obawiałem się, że przemyślenia dotyczą trywialnych CRUDów - na crudach opiera się ostatnio cała współczesna literatura programistyczna jak i blogi. Nie dziwota, gdyż jest to bardzo wdzięczna materia - można na nich pokazać jak prosta i łatwa jest technologia X, a później radźcie sobie sami.

Autor w części rozdziałów wychodzi od crudów jednak za chwilę porusza bardziej zaawansowane tematy, racjonalnie argumentując kiedy opłacalne jest wprowadzenie bardziej złożonych mechanizmów platformy.

Dla kogo przeznaczona jest książka?
Przede wszystkim dla weteranów J2EE, którzy przesiadając się na Java EE powinni zapomnieć stare nawyki.
Dla osób zaczynających od EE 5 lub przechodzących z innych technologii (Spring) odniesienia do "starych" praktyk będą jedynie ciekawostką archeologiczną.

Ale tak jak pisałem, znajdziemy w niej kilka ciekawych kruczków, sporo gotowych rozwiązań oraz dużo gotowego kodu. Kruczki i best practices związane z transakcjami, kod użytecznych interceptorów, które łatają braki w specyfikacji;) oraz nieco praktyk odnośnie dobrego designu. Część praktyk odnośnie designu jest dyskusyjna, jednak autor wyjaśnia w dalszej części, że aplikują się w pewnych kontekstach, natomiast gdy wymaga tego problem, wówczas zaczynamy sięgać po inne rozwiązania. Przykładowo obiekty transferowe są dobre tylko wtedy gdy są dobre:) - z czym nie sposób się nie zgodzić. DAO jest usprawiedliwione tylko gdy wnosi wartość - tak ale dyskutować można nad tym co jest wartością.

Mimo dyskusyjności niektórych pomysłów trzeba docenić inicjatywę, ponieważ generalnie brakuje na rynku pozycji wychodzących poza przysłowiowy Hello World...

Na uwagę zasługuje fakt, że autor otwarcie mówi o proceduralnym stylu promowanym przez platformę.
Mówi też otwarcie o innych sposobach skalowania - bez rozpraszania obiektów pomiędzy warstwami...
nota bene zgodnie z zasadą Fowlera odnośnie rozpraszania: "Just don't":)

Nie byłbym sobą gdybym nie znalazł jakiś błędów koncepcyjnych...
Wiem, że w każdej książce technicznej (w sensie opisującej jakąś technologię) projektowanie Object Oriented jest potraktowane po macoszemu ale skoro już polecam książkę to zwrócę uwagę na 2 przykłady:

Rozdział "Persistent Domain Object (Business Object)"
Po wstępie o tym dlaczego opłaca się stosować model OO (rich model) zamiast proceduralnego (anemic model) mamy taki oto przykład:

Klasa OrderItem, która między innymi potrafi policzyć swój koszt metodą getShippingCost (jest to metoda biznesowa a nie geter)

Dalej dziedzicząca po niej klasa BulkyItem, która liczy koszt nieco inaczej - nadpisuje metodę getShippingCost a w niej woła super wersję tej metody!

@Override
public int getShippingCost() {
return super.getShippingCost() + 5;
}

Nie róbcie tego w domu ani w pracy!:)
1. OrderItem ma wiele odpowiedzialności, więc wprowadzanie nowej klasy i dziedziczenia tylko dlatego, że zmieniła się jedna z odpowiedzialności jest błędem projektowania obiektowego. Taki sposób rozumowania szybko doprowadzi do ekspolozji kombinatorycznej, gdzie każda zmiana logiki (oraz kombinacje tych zmian) zamieszczana jest w swojej klasie dziedziczącej. Strategia jest jednym rozwiązań. A jeżeli nie chcemy wprowadzać strategii, to już na prawdę lepszy będzie serwis liczący koszt na podstawie getterów z OrderItem. Dobry kod proceduralny jest zawsze lepszy od słabego kodu obiektowego!

2. Wołanie super wersji metody z nadklasy jest tak zwany smrodkiem (code smell). Skoro nadpisuję metodę to jest już nieważna. Generalnie wskazuje to na słaby design.

Kolejna rzecz na jaką należy uważać to rozdział poświęcony "konfliktowi" pomiędzy Domain Driven Design a SOA.

Niestety muszę powiedzieć, że konflikt ten jest pozorny i wynika z niezrozumienia architektury aplikacji dla systemów, w których stosujemy DDD.
Autor we wcześniejszych rozdziałach promował swój pomysł pod tytułem Gateway i ten styl przeniósł na implementację DDD.
Nigdy nie "publikujemy" Modelu Domeny jako "API". Wiąże się z wieloma przykrymi konsekwencjami, ale tutaj odsyłam do Evansa. Model domenowy przykrywamy właśnie procedurami w stylu SOA - po prostu podstawowy pattern DDD: warstwa Serwisów Aplikacyjnych. I po problemie:)
Było to powiedziane już 5 lat temu: DDD the opposite of SOA? Uh, no.

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

Polecam rozdział pod tytułem "Retired Patterns" przypomina nam jak smutne i przykre bywało drzewiej programowanie w EE:)

Stosowalność Wzorców Projektowych

2011-05-19T22:01:00.006+02:00

Temat Wzorców Projektowych budzi wiele emocji. Niektórzy są ich zagorzałymi fanami, inni podchodzą z pogardą twierdząc, że w rzeczywistym świecie są bezużyteczne.

Wzorce Projektowe są jedynie narzędziem, a emocjonalne podchodzenie do "młotka" jest po prostu nieracjonalne. Dlatego zaproponuję nieco inne podejście - kontekstowe.

Swoją drogą ciekawe, że podczas rozmów coraz częściej słyszę z ust wytrawnych programistów wyraz irytacji nad bezkontekstowym podejściem naszej branży do wszelkich technik, praktyk, metodyk, produktów, rozwiązań. Mówi się, że jesteśmy sterowani modą bardziej niż Mediolan lub Paryż;)
Odczuwa się silne zmęczenie marketingiem.

W swojej karierze programistycznej miałem okazję pracować nad systemami różnej klasy. Przez klasę rozumiem klasę problemów jakie stanowiły główne wyzwania. Ale to praca trenera i konsultanta dała mi dostęp do wglądu w spektrum klas problemów, w ilości jaką standardowo kolekcjonuje się w okolicach emerytury.

Piszę o tym aby przejść do kontekstu stosowalności Wzorców Projektowych. Z moich obserwacji wynika, że kontekst ten jest rozpięty na 2-wymiarach: wspomnianej już klasie problemu oraz w wymiarze osobowości (otrzemy się o aspekty psychologii programistów).

KONTEKST KLASY PROBLEMU

Jeżeli jesteśmy w kontekście aplikacji biznesowych, a nasza praca polega na implementowania kolejnych wymagań, to stoją przed nami wyzwania typu:
- okiełzanie nielogicznych wymagań
- modelowanie narzędzia dla biznesu (naszej aplikacji), który działa z natury procesowo
- tworzenie intuicyjnego GUI
- wpasowanie się w istniejącą bazę danych, która była projektowana przed III Wojną Mandżulską, w czasach gdy nikt jeszcze tak na prawdę nie rozumiał domeny.

W tym kontekście często nie potrzebujemy nawet używania technik OO - aczkolwiek programujemy z użyciem obiektów (bo niby jak inaczej w mainstreamowych językach?).

Z szerokiego wachlarza Wzorców Projektowych możemy posłużyć się w tym kontekście - w pewnych bardziej złożonych - przypadkach:
- Strategią - jeżeli mamy odmiany tego samego zachowania/czynności biznesowej. Podejście promowane przez ten wzorzec staje się ostatnio modne za sprawą języków funkcyjnych. By czymże innym na poziomie syntaktycznym jest przekazanie obiektu implementującego interfejs z jedną metodą niż zwykłym przekazaniem funkcji na poziomie semantycznym?
- Łańcuchem Odpowiedzialności - łańcuch zaczyna się nam opłacać gdy chcemy modelować podejmowanie decyzji o tym, który z wariantów logiki biznesowej chcemy wykonać. Opłaca się gdy spodziewamy się modyfikowania ilości wariantów.
- Specyfikacją - pozwala na przejrzyste modelowanie złożonych reguł określających czy dany obiekt biznesowy powinien podlegać jakiemuś przetwarzaniu. Opłaca się gdy reguły są zawiłe i istnieją pomiędzy nimi zależności logiczne. Złożony wzorzec, że wystąpić kilka razy w całym kodzie.
- Stanem - bardzo złożony wzorzec, może wystąpić raz, może dwa w średniej wielkości systemie. Pozwala na przejrzyste modelowanie maszyny stanów, dla obiektów biznesowych, które mają np różne statusy i w zależności od statusu a) mogą lub nie przechodzi w inne oraz b) inaczej się zachowują. Opłaca się gdy mamy wiele statusów i zawiła logikę sterującą zachowaniem zależnym od statusów.
- Metodą Szablonową - prosty wzorzec, klasyka polimorfizmu, pozwala modelować różne warianty algorytmów biznesowych. Z czasem gdy sytuacja się komplikuje przestaje się opłacać i warto dokonać refaktoringu do Strategii.
- Fasadą - trywialny wzorzec, który nie zasługuje na miano wzorca, ale wygodnie upraszcza to co najpierw skomplikowaliśmy;)
- Dekoratorem - wprowadzenie dekoratora zaczyna się nam opłacać gdy chcemy !w runtime! (nie podczas programowania czy kompilacji) decydować o dodawaniu nowych zachowań. Bardzo silny, ale rzadko logika biznesowa daje się tak elegancko zamodelować.

Pomijam Singletona, który w większości przypadków jest antywzorcem zabijającym testowalność. Poza tym jego istnienie w modelu biznesowym rzadko bywa sensowne.

O ile pojawienie się w aplikacji biznesowej wielu przypadków wykorzystania Strategii, Metody Szablonowej, Fasady jest normalnym zjawiskiem o o tyle duża ilość Łańcuchów, Dekoratorów czy Stanów wskazuje na overengineering i "chorobę wzorcową".

Pozostałe wzorce z katalogu nie mają zbyt dużej szansy na potencjalne pojawienie się w aplikacji biznesowej - po prostu służą do rozwiązywania problemów innych klas.

W aplikacjach biznesowych za to więcej pożytku niosą wzorce innego rodzaju:
- sposoby modelowania, oraz strategicznego modelowa z zestawu Domain Driven Design
- archetypy modeli biznesowych
- najlepsze praktyki odnośnie Usability

Jeżeli natomiast jesteśmy w kontekście tworzenia oprogramowania klasy: platforma, framework, server, wysokowydajny dedykowany portal, oprogramowanie specjalistyczne typu: narzędzia do projektowania/komponowania, itp wówczas stajemy przed problemami zupełnie innej klasy:
- otwartość na rozbudowę z jednoczesną ochroną publicznego api przed zmianami core,
- wydajność, oszczędność pamięci,
- bezpieczeństwo,
- giętkość api,
- wyważenie ograniczeń
- itp.

Przeglądając kody źródłowe tego typu aplikacji możemy dostrzec wiele wystąpień wzorców lub struktur do nich podobny zmodyfikowanych z powodu pewnych intencji. Czasem są po prostu nazwane inaczej z powodu niewiedzy autora - ale ciekawe jest, że wpadł na pewne pomysły niezależnie, nie znając wzorca wcześniej.

Oprócz wspomnianych wcześniej wzorców opłacalne w tym kontekście dodatkowo mogą być:
- Builder - aby odseparować plany budowy obiektów od ostatecznego kształtu konstrukcji. Opłacalny gdy przewidujemy pojawianie się kolejnych "produktów"
- Visitor - aby umożliwić użytkownikom api wprowadzanie nowych zachowań poprzez dodawanie swojego kodu zamiast modyfikowania biblioteki/frameworka. Double Dispach dla ubogich np. w celu otwarcia core na rozbudowę
- Proxy - aby umozliwić model programistyczny w stylu Aspect Oriented
- Mediator - śmietnik na chaos sieci współpracujących obiektów. Jeżeli musisz mieć chaos, to explicite ogranicz jego zakres.
- Most - jeżeli masz niestabilny core i chcesz zaryzykować publikowanie stabilnego api
- Prototyp - jeżeli chcesz fabrykować wiele klas i nie chcesz tworzyć analogicznej do nich, lustrzanej hierarchii fabryk.
- Flyweight - jeżeli musisz mieć ogromną ilość obiektów, ale część ich pół możesz uwspólnić, ponieważ nie jest to ich zmienny stan - oszczędzasz pamięć.

Podając przykłady dla obu klas problemów chciałem pokazać, że po prostu inni programiści/projektanci/architekci mogą żyć w innym świecie. To że coś jest dla nas bezużytecznie, nie oznacza, je jest to bezużyteczne w ogólności.

Wrzucanie wszystkich programistów do jednego worka (najlepiej wspólnego worka z Informatykami;) powoduje utratę kontekstu a co za tym idzie rozmycie wymaganych do danego zadanie kompetencji.

Warto też zastanowić się nad klasami problemów jakie nas intrygują i rozwijać odpowiedni skillset - bez odpowiedniego poziomu kompetencji pewne klasy projektów będą dla nas zawsze zamknięte.

KONTEKST OSOBOWOŚCI

Chyba każdy programista przyzna, że zależy mu na zaprojektowaniu najprostszego rozwiązania. Być może to poszukiwanie prostoty jest tym, co przyciąga ludzi do programowania - no może za wyjątkiem robotników umysłowych napędzanych chęcią łatwego (hehe naiwni) zarobku.

Problem leży w postrzeganiu prostoty.
Niektórzy mówią, że jakieś podejście jest proste jeżeli można szybko zacząć się w tym orientować. I nie ważne, że później okaże się to pogmatwane w szczegółach. Ważne aby szybko zacząć "łapać" o co chodzi, a później - trudno, świat jest pogmatwany.
Inni mówią, że coś jest proste, jeżeli u swoich założeń ma dające się dokładnie zrozumieć fundamenty, które pozwalają wyobrazić sobie całe rozwiązanie mentalnie. Nie ważne, że może na początku trzeba zainwestować czas - dużo czasu - w zrozumienie pryncypiów i nowych rzeczy, które powierzchownie wydają się złożone. Jeżeli później okaże się, że było to proste, to mówią, że jest to proste.

Które podejście jest lepsze - jak zwykle, zależy to od kontekstu. W kontekście IT np. może zależeć od ograniczeń czasowych, czyli tego ile czasu możemy poświęcić. Innym ograniczeniem może być opłacalność w perspektywie czasu (czasem robimy eksperyment biznesowy i zobaczy jak się to rozwinie:). Dlatego w każdym przykładzie wzorca pisałem o tym kiedy może się nam opłacać wprowadzenie danej konstrukcji.

Strategia poznawcza, jaką przyjmuje nasz mózg w podejściu do prostoty (musi być proste od razu, musi być proste docelowo) wiąże się mocno z typem naszej osobowości.
- część z nas jest zorientowana na postrzeganie podobieństw, inni na postrzeganie różnic - model meta-programów .
- część z nas jest otwarta na nowe doświadczania, inni są bardziej konserwatywni - model Big 5.
- część z nas ma swój wewnętrzny świat, w którym modeluje postrzeganą rzeczywistość, inni są nastawieni na natychmiastowe działanie i niemal namacalne doświadczanie - model MBTI
- część z nas żyje w przyszłości, w jakimś jej modelu, inni żyją tu i teraz w czasie.

MODEL DREYFUS

O modelu kompetencji Braci Dreyfus pisałem już kilkakrotnie. Tutaj przytoczę tylko poziom Competent. Rozwijając jakąś umiejętność, na tym poziomie w naturalny sposób zaczynamy szukać najlepszych praktyk, wzorców (nomen omen). Tak więc naturalne jest, że rozwijając kompetencję pod tytułem "Programowanie/Projektowanie OO" w pewnym momencie zaczniemy szukać wzorców.
Na kolejnych etapach rozwoju tej kompetencji będziemy zadawać pytanie, kwestionować, szukać szerzej. Jednak na trzecim poziomie (Competent) katalog wzorców daje dużego kopa i pozwala po prostu zoptymalizować proces uczenia się. Jak powiedział Jim Copelin, z czasem odrzucasz "boczne kółka od swego rowerka" i przestajesz mówić o wzorcach, po prostu intuicyjnie robisz to co należy.

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

Czasem można spotkać głosy, że wzorce projektowe są "zbyt akademickie". Hmm moim zdaniem wręcz odwrotnie. Do katalogu wzorców nie trafiają żądne rozwiązania, które nie są odkryte i przedyskutowane przez community praktyków. Oczywiście, stosując zbyt wyrafinowany wzorzec do zbyt błahego problemu będziemy odczuwać przerost formy nad treścią. Ale wówczas powodem jest nieumiejętne użycie w nieodpowiednim kontekście - czyli jego niezrozumienie.

Aby nabrać wyobrażenia o tym, co to znaczy "akademickie" podejście do OO należy zapoznać się z tym tekstem.

Ułóż swoją Confiturę 2011

2011-05-09T13:33:00.000+02:00

Już tylko miesiąc pozostał do Confitury - największej i darmowa konferencji poświęconej Javie (konferencji znanej do tej pory pod nazwą Javarsovia).

Pod tym adresem można głosować na prezentacje, które chcielibyście zobaczyć 11 czerwca.

Ankieta nie zawiera abstraktów dlatego opiszę pokrótce 3 zgłoszone tematy. Liczę na feedback z Waszej strony (również krytyczny:) odnośnie:
- tematów (czy są interesujące)
- ich zakresu (czy nie jest zbyt pobieżny aby zbyt oczywisty)
- ew. propozycji zmian

1. Context and Dependency Injection w służbie Domain Driven Design

CDI bazuje na zdobyczach nowoczesnej inżynierii oprogramowania dostarczając silnych technik programistycznych. Jednak po przejrzeniu przykładów o złożoności "Hello world" można zadać sobie pytanie - kiedy, jak i do czego powinienem użyć tych technik w praktyce.

Podczas prezentacji przedstawię w jaki sposób możemy wykorzystać model programistyczny (styl/sposób podejścia do problemu) oferowany przez CDI do implementacji DDD.

Po krótkim wstępie na temat modelu programistycznego DDD oraz architektury aplikacji wykorzystamy mechanizmy CDI takie jak fabrykowanie w runtime, dekoratory, zdarzenia, interceptory do implementacji wszystkich Building Blocków DDD. W szczególności poświęcę wiele czasu na wykorzystanie zdarzeń do modelowania wydarzeń biznesowych orkiestrowanych w modelu Sagi.

Prezentacja z założenia przeznaczona jest dla uczestników początkujących w zgadnieniach CDi i DDD. Przedstawione techniki DDD będą na tyle ogólne, że z łatwością można implementować je na innych nić CDI platformach (np. Spring) na zasadzie analogii.

2. Domain Driven Design - Wszystko ma swoje miejsce i wszytko jest na miejscu

//prezentacja wygłoszona w zeszłym roku na NYAC

Czy zastanawialiście się co jest przyczyną rozkładu średnich i dużych
systemów? Czy jest on nieunikniony i jest jedynie kwestią czasu? A
może jednak istnieje jakiś sposób na utrzymanie entropii w ryzach?

Podczas prezentacji zobaczymy w jaki sposób Domain Driven Design
pomaga w okiełznaniu chaosu. W prezentacji znajdą się główne techniki
modelowania takie jak Ubiquitous Language, Bounded Context, Strategic
Design.

Zostaną przedstawione również podstawowe techniki implementacji DDD:
przykłady Building Blocks, Command-query Responsibility Segregation,
system zdarzeń (w tym Sagi), przypadki racjonalnego wykorzystania zarówno ORM jak i
czystego i SQL.

3. Command-query Responsibility Segregation - ewolucja architektury warstwowej w stronę modularyzacji i skalowania

//prezentacja wygłaszana na 4dev i 33rd degree

Z biegiem kariery, tworząc kolejny system lub aplikację, stajemy przed problemami innej klasy. Inna klasa problemu to inne wymagania odnośnie technologii, metodyki i architektury.

Popularne architektury (1/2/3) warstwowe mogą być nieodpowiednie do pewnych klas problemów - mogą np. narzucać nieracjonalne wykorzystanie ORM lub promować naiwne modelowanie domeny biznesowej.

Podczas prezentacji przedstawię nowe ujęcie warstw - architekturę Command-query Responsibility Segregation, która wspiera aplikacje średniej i dużej skali. Architektura CqRS promuje zdobycze nowoczesnej inżynierii oprogramowania takie jak: Domain Driven Design i noSQL, otwiera system na skalowanie oraz w naturalny sposób rozwiązuje typowe problemy z mapowaniem relacyjno-obiektowym.

Główne składowe nowej architektury to: dwa stosy warstw, rozwarstwienie logiki, zdarzeniowa komunikacja pomiędzy modułami oraz opcjonalnie Event Sourcing (składowanie danych w modelu behawioralnym - w przeciwieństwie do klasycznego modelu strukturalnego)

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

Pierwsza z prezentacji jest całkowicie nowa - tym razem planuję lekką zmianę formuły i pokazanie dużej ilości kodu.
Drugą z prezentacji być może widzieliście na NYAC lub we Wrocławiu - planowałem pokazać ją również na zeszłorocznej Warsjavie ale niestety mały, głupi i właściwie martwy (bo niemetabolizujący a jedynie replikujący) wirus był ode mnie silniejszy:/
Trzecia z prezentacji zapewne dla większości z Was będzie replayem z kwietnia.

Zapraszam do głosowania, ale przede wszystkim do uczestnictwa w konferencji - na prawdę warto!

DDD i CqRS w Toruniu i Lublinie

2011-05-04T15:48:00.004+02:00

Dziś post czysto ogłoszeniowy.

Lublin: 9. maja
Zapraszam na prezentację poświęconą CqRS, która przedstawię na lubelskich dniach informatyki (szczegóły).

Toruń: 13. maja
Zapraszam czytelników bloga z Torunia i okolic na dwie prezentacje poświęcone DDD i CqRS, które wygłoszę 13 maja w ramach toruńskiej grupy .NET (szczegóły).

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

Jeżeli ktoś widział te prezentacje na konferencjach NYAC, 4Develoeprs lub 33rd Degree to zapewniam, że pojawi się kilka nowych szczegółów:)

Code Review vs Pair Programming

2011-04-23T21:32:00.012+02:00

Oczywiście w idealnym świecie najlepiej byłoby mieć zarówno Code Review (CR) jak i Pair Programming (PP).
Jednak w brutalnej rzeczywistości zwykle nie ma to czasu, ponieważ ich wykonywanie wiąże się ze złudzeniem tracenia czasu.

Na szczęście w dojrzałych organizacjach znajdujemy czas na tego typu "zbytki" rozumiejąc ich potrzebę - szczególnie w przypadku ekspansji zespołu o "młodych, zdolnych, dobrze zapowiadających się".
Wówczas zwykle defultowo wybór pada na CR.

Co takiego możemy sprawdzić podczas CR?
Na pewno:
- dużą część zasad Clean Code
- poziom sensowności testów
- bardzo ogólnie zgodność z założonym stylem architektonicznym
- przy większym zaangażowaniu być może część reguł GRASP lub SOLID.

<dygresja>
Co do podstawowych zasad Clean Code to wydawać by się mogło, że są intuicyjne. Że każdy podczas pierwszego roku nauki programowania (czy to w podstawówce czy to na studiach) zrozumiał, że krótkie metody i samoopisujące się identyfikatory - GOOD, odwrotnie - BAD.

Okazuje się, że jednak niekoniecznie. W wolnej chwili przyjrzycie się sobie i kolegom z teamu pod kątem dominacji jednego z dwóch typów inteligencji: werbalnej i algorytmicznej.

Polecam Doskonały artykuł Andrzeja Szczodraka: "O programiście-pisarzu i programiście-konstruktorze..."
Dobitnie mówi o tym również Greg Young "gdzieś" w swoim 6.5 godzinnym video.

Ogólny morał jest taki: ważne aby odpowiednio przypisywać programistów o naturalnych zdolnościach do odpowiednich części systemu.

Generalnie różnica polega na tym, że programiści o dominującej inteligencji werbalnej dbają o formę wyrazu. Ich nastawienie - a wręcz predyspozycje - determinują elegancki styl, czytelność i prostotę (prostotę w rozumieniu werbalnym). A Możliwość eleganckiego i prostego wyrażenia intencji jest dla nich narzędziem weryfikacji poprawności pomysłu (weryfikacji nie formalnej ale bardziej intuicyjnej). Algorytmy nie są ich mocną stroną, raczej wzorce, ogólne zasady i formy, architektury, archetypy. Mają niestety chorobliwą tendencję do tworzenia frameworków, aby nadać ramy myślom.

Z kolei programiści o dominującej inteligencji algorytmicznej doskonale czują się w złożonej gmatwaninie obostrzeń nie dbając o styl i formę - te są dla nich pomijalne. Na poziomie algorytmu liczy się wydajność. Ich mocną stroną są raczej biblioteki niż frameworki.
Dodatkowo kilkanaście lat stukania młotkiem w głowę na lekcjach/zajęciach z matematyki gdzie dobra nazwa funkcji to f albo g, dobra nazwa zmiennej to x, y, k, l, m, n a najlepsze zadania to te bez kontekstu i bez treści - umacniają naturalne nawyki.
</dygresja>

Mam nadzieję, że szczypta psychologii rzuci nieco nowego światła na podstawowe zasady Clean Code - z którymi jako entuzjasta dobrych modeli werbalnych osobiście zgadzam się w zupełności. Jednak innych ludzi trzeba również zrozumieć i nie można być zawsze Clean-Nazi.

Poza tym wiele z podstawowych zasad czystego kodu można sprawdzić automatycznie.

Jak jednak sprawdzić design? Jak sprawdzić sensowność koncepcji rozwiązania? Jak sprawdzić model biznesowy?

//Pomijamy tutaj organizacje, gdzie takowe artefakty przychodzą "z góry" do wklepania.

Zakładam też, że sprawdzanie designu metrykami z automatu to jak ocenianie obrazu poprzez histogram;)

Zatem aby sprawdzić tej klasy problemy podczas CR, weryfikujący musi niemal powielić całą pracę umysłową osoby, która weryfikowany kod spłodziła. Czyli innymi słowy mamy podwójny wysiłek mentalny!

Co jeżeli rzeczywiście go poniesiemy (czyli sprawdzimy coś więcej niż nazwy zmiennych i długość metod) i okaże się, że cała koncepcja rozwiązania jest błędna i należało by ją przepisać?

Czy przepisujemy, czy może kończymy CR stwierdzeniem: "następnym razem postaraj się bardziej"?

Skoro już inwestujemy czas drugiej osoby (zwykle tej "mocniejszej") w powstanie kodu, to może warto zrobić to na początku. Tak aby ta osoba brała udział w powstawaniu koncepcji rozwiązania a nie tylko sprawdzała długość metod;)

Jest wówczas duża szansa na:
- wyklucie się lepszego rozwiązania, modelu, koncepcji
- eliminację potrzeby przepisania
- czysty kod będzie niejako produktem ubocznym - ekspert zwykle nie potrafi pisać inaczej niż czysto - syf po prostu go spowalnia lub wręcz uniemożliwia myślenie

Dlatego lepiej zawczasu uprawiać Pair Programming (model kierowcy i pilota) aniżeli poniewczasie liczyć linijki w metodach i sprawdzać czy zmienne nazywają się tak podpowiada zdrowy rozsądek;P
Innymi słowy: mając ograniczone man-hoursy do zainwestowania, lepszy zwrot uzyskamy z PP.

Mam nadzieję, że archaiczne wyrazy użyte w ostatnim akapicie nadały temu postowi poniosły, świąteczny charakter;)

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

W psychologii uczenia się, mentoring uznaje się za najbardziej efektywną technikę uczenia. Po prostu my, ludzie w ogromnej większości uczymy się przez naśladownictwo - przynajmniej na pierwszych poziomach kompetencji (vide model Dreyfus).

TCP vs UDP

2011-04-19T21:15:00.000+02:00

Dziś będzie o komunikacji...

Najpierw nieco teorii:
- protokół TCP - komunikacja klient-serwer, w której klient potwierdza otrzymanie pakietu
- protokół UDP - wysyłanie danych bez kontroli przepływu i retransmisji; szybszy od TCP z uwagi na pominięcie "ceregieli" związanych z tym czy klient otrzymał i "zrozumiał".

Nawiązując do poprzedniego, refleksyjnego posta:
podczas jednej z ostatnich konferencji, bardzo dobry znajomy - o pseudonimie artystycznym lburdz - wyświadczył mi nieocenioną przysługę udzielając następującego fidbeku:
Podczas prezentacji nie chodzi o najszybsze opróżnianie (właściwie to lepszym w tym kontekście słowem będzie wypróżnianie) buforów na strumień UDP. Trzeba traktować ludzi (publiczność) jak drugi koniec strumienia TCP.

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

Niby proste, ale jak dla mnie przełomowe! Może jeszcze komuś się przyda...

Pocztówka z wakacji

2011-04-15T17:24:00.001+02:00

Mam za sobą 10-dniowe "wakacje", z których to wrażeniami chciałbym się podzielić.
Ostatnie 10 dni upłynęło mi na:
- konferencji 4 developers
- konferencji 33rd Degree
- szkoleniu na temat Distributed DDD i CqRS prowadzonemu przez Grega Younga

Podczas obu doskonałych konferencji obserwować można było wyraźnie pewne trendy.

Mimo, że konferencje mają charakter techniczny, to dużym powodzeniem cieszą się tematy miękkie. Pisał o tym już Martin Fowler w swoim artykule w akapicie na temat trendów konferencyjnych.

Generalne głosy ze świata są takie, że szczegóły techniczne można sobie zgłębiać w domu, a podczas konferencji mamy dostęp do wiedzy niedostępnej w literaturze z naszej branży. Cieszy fakt, że nadążamy za najnowszymi trendami - ciekawy jestem Waszych opinii na ten temat.

Kolejna obserwacja to wyraźny trend amerykanów - doskonała forma ale treść merytoryczna tak prosta, że miejscami ocierająca się o prostactwo (np. odpustowe sztuczki w aplikacjach klasy hello world;).

Podczas 33rd degree prowadziliśmy wraz z kolegami z ssepp panel dyskusyjny na temat profesji w naszej branży. Jako grupa zawodowa wciąż jednak zbytnio skupiamy się na rozgoryczeniu zamiast na działaniu w kierunku krystalizacji profesji.

Jednak trzydniowe szkolenie Grega było jeszcze bardziej intensywne pod względem mentalnym (towarzyskim również - wynajęliśmy na 5 dni wspólnie z Gregiem apartament:)

Greg przedstawił wiele szczegółów technicznych związanych z jego podejściem do architektury CqRS i modelowania DDD. Poszerzył nam również horyzonty przedstawiając architektury systemów, które obsługują setki tysięcy transakcji na sekundę!
Wniosek jest jeden: świat relacyjnych baz danych, popularnych frameworków i platform oraz standardowych warstw jest mocno ograniczający. Aby podejść do problemu o skali rzędu tysięcy na sekundę trzeba zaprzeczyć wszystko co stanowi naszą bazę wiedzy!

Klimat panujący na szkoleniu był nie do opisania. Ponad trzydzieści osób z kraju i zagranicy operujących wspólnym poziomie abstrakcji, fechtujących technikami inżynierii oprogramowania z mistrzowską gracją. Bez kompromisów jakościowych - po prostu przy tej klasie problemu nie da się inaczej...

Do tego doskonały prowadzący z szerokim wachlarzem kompetencji. Począwszy od szczegółów kompilatora poprzez paradygmaty programowania, wzorce projektowe i architektoniczne, znajomość całej klasyki oraz najnowszych zdobyczy inżynierii oprogramowania, metodyk prowadzenia projektów, kreowania wizerunku architektury jako produktu, technik negocjacji po ogólną erudycję sięgającą sieci neuronowych, algorytmów genetycznych, polityki itd itp.

Kudos Greg.

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

Nazywam ten czas wakacjami, ponieważ jestem typem obserwatora (perceiving), poszukiwacza. Dlatego cenię sobie stałą stymulację nowymi pomysłami oraz dyskusje z ludźmi wnoszącymi coś do sprawy, ponad leżenie na plaży.

Patrząc z boku ciężko uwierzyć jak ktoś kto siedzi kilka godzin na konferencji/szkoleniu w bezruchu może przezywać ultra-intensywne doznania poznawcze:)))

Dyskusje panelowe

2011-03-31T01:37:00.003+02:00

Podczas 4Developers będę prowadził dyskusję na temat braków w Javie (na różnym poziomie) i sposobach, narzędziach oraz podejściach na ich uzupełnianie.

Podczas 33rd Degree będziemy (wraz z kolegami z SSEPP) prowadzić dyskusję na temat kompetencji, profesji i profesjonalizmu w naszej branży.

Formuła zakłada, że to Wy wnosicie wiedzę i doświadczenie oraz pytania i wątpliwości. To Wy nadajecie kierunek dyskusji w stronę, która Was interesuje.

4Developers

tytuł: Java - czego nam brakuje, co warto dodać?
temat przewodni:
Po pewnym czasie pracy z niektórymi narzędziami zaczynamy zauważać ich
braki - szczególnie gdy spróbujemy użyć narzędzi z innego zestawu.
Wszyscy mamy zapewne przemyślenia na temat pewnych braków w
technologii, której używamy.
Część z nas ma inspirujące doświadczenia z innymi technologiami i podejściami.
Podczas dyskusji chcemy zastanowić się nad sposobami uzupełnienia
naszego warsztatu na poziomie: składni, struktury, narzędzi, podejść,
itd.
Uzupełnienia poprzez: biblioteki, frameworki, pluginy, nowe best practices.

33rd Degree

tytuł: Dokąd zmierza Software Craftsmanship
temat przewodni:
Ruch Software Craftsmanship jest odpowiedzią na pojawiające się potrzeby problemy.

Jest to jednak ogólna idea. Warto jednak zastanowić się nad konkretami:

jakimi cechami powinien charakteryzować się profesjonalista
jaki zakres bazowych kompetencji powinien posiadać profesjonalista
ew. jakie poziomy kompetencji możemy próbować określać
być może zależy to od klasy problemów
czy nadszedł już czas na krystalizację profesji - czy mamy właściwą ilość doświadczeń
czy i kiedy warto mówić o profesjonalizmie - kiedy jest on potrzeby i kiedy wnosi wartość

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

Jeżeli macie jakieś sugestie odnośnie prezentacji lub dyskusji to zapraszam do pisania komentarzy lub na prv.

Tydzień segregacji

2011-03-30T01:25:00.003+02:00

Zbliżający się tydzień to dwie konferencje:
- 4 Developers
- 33rd Degree

Przygotowałem dla Was prezentację na temat Command-query Responsibility Segregation, którą przedstawię na obu konferencjach.

Poniżej wersja alfa.

Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw on Prezi

Prezentacja zgodnie z najnowszymi trendami nie zawiera zbyt wiele tekstu - całość wymaga akompaniamentu paszczowego.

W świecie Javy mamy ostatnio stagnację (frameworki webowe już nie wychodzą co tydzień, a skoro najnowsze wersja Java EE wyszła rok temu to mamy kilka lat spokoju;). Jest to zatem dobry moment na ostrzenie piły - np zastanowienie się nad podstawami.

Ogólne przesłanie prezentacji: wybór narzędzia i podejścia powinien zależeć od klasy problemu.

W świecie Javy mamy z jednej strony platformę korporacyjną, która była pomyślana jako produkt dla klientów (wytwórców oprogramowania) wielkiej skali. Po nasyceniu tego rynku mamy widoczną zmianę strategii marketingowej i atakowanie małych softwarehousów. Z drugiej strony mamy mnogość rozwiązań typu generator jednowarstwowej aplikacji, którymi próbuje się kusić każdego - nawet duże softwarehousy.

W prezentacji przedstawię rozwiązania architektoniczne podpatrzone w świecie .NET. Nie są one specyficzne dla .NET ale w tej społeczności są mocniej rozwijane i dyskutowane niż w naszej.

Warto podkreślić, że koncepcja architektoniczna CqRS została wypracowana w ciągu kilku ostatnich lat przez community. Nie jest to zatem objawienie zesłane przez anonimowych pracowników jakiejś firmy, lecz wynik dyskusji i eksperymentów nad rzeczywistymi problemami. Jest to zatem owoc pracy ludzi żywo zaangażowanych w sprawę - stąd wartość.

Mottem dla mojej prezentacji będzie ewolucja architektury, czyli jej rozbudowa wraz ze wzrostem skali (komplikacji i wielkości) systemu. Wychodzę z założenia, że nie każde podejście może ewoluować.

Dla zainteresowanych prezentacją mam sugestię: warto wcześniej zapoznać się z moją prezentacją na temat Domain Driven Design. Nie jest to konieczne, ale jeżeli to zrobicie, to całość ułoży się w sumie w spójne rozwiązanie.
Link tutaj.

Tydzień segregacji właściwie zostanie wydłużony...

W kolejnym tygodniu Greg Young będzie prowadził otwarty wykład i 3-dniowe szkolenie na temat DDD i CqRS w Krakowie (szczegóły).

Nieczęsto zdarza się możliwość uczenia od mistrza, tak więc polecam:)

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

Jeżeli ktoś ma uwagi/sugestie odnośnie prezentacji (treść, zakres) to piszcie w komentarzach lub na prv.
Będę bardzo wdzięczny za feedback:)

Greg Young w Polsce! (UWAGA KONKURS)

2011-03-25T12:03:00.007+01:00

Mamy już kompletną agendę konferencji 4Developers, zatem mogę oficjalnie powiedzieć, że Greg Young, którego udało się nam zaprosić do Polski, przedstawi dwie prezentacje:

Zapomnij o szczegółach, liczy się efekt! - jest to nowa, jeszcze nie publikowana prezentacja, którą Greg przygotował specjalnie dla nas na 4Dev
Uwolnij swoją domenę! - przekrojowa prezentacja, która udowadnia, że możemy skonstruować wysokowydajny, skalowalny system, zachowując nieautystyczny model domeny biznesowej. Czyli jak połączyć Domain Driven Design, Commmand-query Responsibility Segregation, Event Sourcing oraz kilka innych najnowszych zdobyczy inżynierii oprogramowania.

Od siebie dodam, że Greg należy do mojej ścisłej czołówki guru współczesnej inżynierii oprogramowania. Posiada tytuł Most Valuable Person Microsoftu, jest głównych twórcą koncpecji architektonicznej CqRS oraz wniósł duży wkład w rozwój Domain Driven Design. Dodatkowo potrafi z pasją opowiadać historie o zaawansowanych koncepcyjnie technikach, w taki sposób, że doznajemy efektu "I know Kung Fu".

btw: czy ktoś z Was odważyłby się wystąpić ze slajdami w TAKIM stylu: 7 Reasons DDD Projects #FAIL

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

KONKURS

Rejestracja na 4Dev będzie trwać już tylko do końca marca, a dla czytelników bloga mamy niespodziankę w postaci darmowej wejściówki.

Zasady są proste: wygrywa osoba o największej ilości komentarzy pod postami na moim blogasku. Chodzi oczywiście o posty wystawione przed ogłoszeniem konkursu:0 Zgłoszenia wraz z linkami do komentowanych postów przysyłajcie na maila podanego w sekcji "o mnie".

Proszę o udział tylko tych z Was, których potencjalne szanse na przybycie na konferencję wynoszą 99% (obecność sprawdzę osobiście;)

DDD we Wrocławiu

2011-02-13T21:09:00.001+01:00

Dzięki uprzejmości Pawła Szulca na vimeo pojawiła się moja prezentacja na temat Domain Driven Design (i kilku tematów dodatkowych), którą przedstawiłem podczas spotkania Wrocławskiego JUG.
część 1
część 2

Dziękuję wszystkim za aktywne uczestnictwo:)

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

Nawiązanie do community .NET jako przodującego w poszukiwaniu nowych (a może klasycznych?) i lepszych metod modelowania jest zabiegiem celowym, mającym na celu zdopingowanie Was do działania.

keepaliver.ping()

2011-02-04T20:16:00.005+01:00

Sporo czasu minęło od ostatniego posta. Powód jak zwykle ten sam - zgodnie ze starym chińskim przysłowiem: "Jest czas na pracę i jest czas na zbieranie ryżu".

Ale mimo nawału pracy mam dla Was trochę materiałów:

1. Prezentacja "Software Craftsmanship - Język wzorców językiem profesjonalistów"
Dzięki uprzejmości Łukasza Lenarta na parleys pojawiła się moja prezentacja z zeszłorocznej javarsowi.

2. Prezentacja "Domain Driven Design. Wszystko jest na miejscu i wszystko ma swoje miejsce".
Najbliższy tydzień spędzam we Wrocławiu. Przy okazji, na zaproszenie Pawła Zubkiewicza - lidera wrocławskiego JUGa - opowiem o DDD; szczegóły.
Z braku czasu będzie to ta sama prezentacja, którą przedstawiałem na zeszłorocznym NYAC. Slajdy będą te same, ale od czerwca zgromadziłem nowe doświadczenia, o których będę chciał opowiedzieć.

Natomiast w kwietniu szykuję dla Was nowy materiał - prezentację "Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw". Mam ambitny plan aby forma graficzna tej prezentacji była mocno odmienna od wszystkiego co do tej pory pokazywałem.

Materiał będzie można zobaczyć na konferencjach:
- 33rd Degree
- 4 Developers

Zapraszam serdecznie na obie konferencje. Myślę, że agenda 33rd Degree już teraz wygląda bardzo zachęcająco.
Natomiast jako członek komitetu programowego 4 Developers zdradzę, że również będzie ciekawie:)

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

Kolejne posty merytoryczne powinny pojawić się pod koniec miesiąca.
Chociaż przyznam, że Java i inżynieria oprogramowania muszą konkurować o zasoby z moją nową zabawką - audiofilskim zestawem stereo, który trzeba co chwilę testować na nowych kablach, płytach i w nowych rozmieszczeniach (ostrzegam - nie dajcie się w to wciągnąć) ;P

Warsjawa 2010

2010-10-22T09:55:00.000+02:00

Zapraszam wszystkich czytelników bloga na prezentację Domain Driven Design - Wszystko ma swoje miejsce i wszystko jest na miejscu, którą przedstawiam w najbliższą sobotę na konferencji Warsjawa.

Skrót:
Czy zastanawialiście się co jest przyczyną rozkładu średnich i dużych systemów? Czy jest on nieunikniony i jest jedynie kwestią czasu? A może jednak istnieje jakiś sposób na utrzymanie entropii w ryzach?

Podczas prezentacji zobaczymy w jaki sposób Domain Driven Design pomaga w okiełznaniu chaosu. W prezentacji znajdą się główne techniki modelowania takie jak Ubiquitous Language, Bounded Context, Strategic Design.

Zostaną przedstawione również podstawowe techniki implementacji DDD: przykłady Building Blocks, Command-query Responsibility Segregation, system zdarzeń, przypadki wykorzystania ORM i SQL - całość na przykładach w Seam lub Spring.

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

Dla tych z Was, którzy byli w Krakowie na NYAC zaznaczam, że core prezentacji będzie taki sam.

Turbo Seam

2010-10-21T01:08:00.008+02:00

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

2010-10-13T01:54:00.002+02:00

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

2010-09-05T13:09:00.001+02:00

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?

2010-08-10T16:02:00.005+02:00

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

2010-07-01T22:42:00.020+02:00

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?

2010-05-25T01:40:00.007+02:00

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

2010-05-09T16:55:00.012+02:00

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

2010-04-28T16:34:00.009+02:00

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

2010-04-21T18:35:00.031+02:00

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

Koszt wykorzystania wzorców projektowych

2010-03-23T23:59:00.007+01:00

Podczas dzisiejszej prezentacji na temat Software Craftsmanship i Wzorców Projektowych, którą przeprowadziłem w ramach lubelskiego JUG padło szereg pytań odnośnie:
- kosztu posługiwania się w kodzie wzorcami
- presji czasu
- komplikacji

Jest to pewien ogólny i często powtarzający się zestaw pytań, dlatego sądzę, że warto rozwiać kilka wątpliwości i nieporozumień.

Część programistów widzi wykorzystanie wzorca jako niepotrzebną komplikację, która wprowadza dodatkowy narzut na wytworzenie kodu.

Generalnie jeżeli chodzi o poziom komplikacji to wzorce powinny redukować złożoność przypadkową oraz zwiększać czytelność złożoności właściwej. Jeżeli mamy sytuację odwrotną to wzorzec został wykorzystany niepoprawnie lub niepotrzebnie.

Odnośnie narzutu czasowego to obserwuję dziwne przeświadczenie jakoby dopisanie interfejsu czy kilku linijek kodu potrzebnych na podzielenie kodu na większą ilość pudełek (klas) było jakoś niezwykle czasochłonne;) Sam proces myślowy również nie powinien się znacząco wydłużyć. Albo wiem jaki wzorzec użyć albo nie wiem. To nie jest tak, że zastanawiam się nad tym godzinami.

Warto zwrócić uwagę na fakt, że katalog Wzorców Projektowych Ogólnego Przeznaczenia jest dosyć bogaty.

Owszem, część z nich jest dosyć wyrafinowana pod względem koncepcyjnym lub pod względem konstrukcji kodu. Przykładowo taki Visitor, Component Tree, Bridge, Proxy, Builder, Flyweight, Memento prowadzają pewien narzut, ale są to narzędzia, które wybieramy do misji specjalnych. Na pewno nie należą do codziennego wachlarza technik.

Natomiast Strategia, Stan, Dekorator, Template Method, Command to lekkie "skróty myślowe" wynikające wprost w paradygmatu Object Oriented. Nie ma w nich doprawdy nic nadzwyczajnego.

Osobiście traktuję część z nich jako "atomowe klocki", z których powinno budować się rozwiązania. Są to byty niemal tej samej klasy ciężaru co IFy, pętele czy metody. Biegłe opanowanie lekkich wzorców sprawia, że poszerzają one nasz zestaw podstawowych "klocków myślowych". Budujemy z nich najpierw mentalne modele, a później naturalnie pojawiają się w kodzie.

Operując lekkimi wzorcami na poziomie podstawowych klocków nie mamy narzutu czasowego podczas developmentu. Natomiast poziom komplikacji ulega znacznemu obniżeniu, ale tylko dla tych czytelników kodu, który posiadają taki sam zasób skojarzeń jak jego twórca - czyli operują tym samym słownictwem branżowym.

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

Potrzeba posiłkowania się wzorcami "lekkiego" kalibru wynika ze słabej siły wyrazu języków wywodzących się z C++ takich jak np Java. Przykładowo brak domknięć kompensujemy sobie strategiami. Doprawdy nie jest niczym strasznym i pracochłonnym opracowanie interfejsu z jedną metodą oraz kilku jej implementacji. Ilość kodu "biznesowego" nie ulega zwiększeniu (ew redukcji) natomiast pojawiają się jedynie dodatkowe "opakowania" dla niego w postaci zgrabnych i eleganckich klas.

Jeżeli ktoś aż tak bardzo nie pała chęcią do pisania kodu to może powinien zostać trubadurem;)

Ciężki kaliber wzorców również może czasem przydać się do emulacji brakujących elementów składni, takich jak:
- double dispatch emulowany przez wzorzec Visitor
- lazy evaluation emulowany przez wzorzec Proxy.

Wyginanie Javy

2010-03-09T20:26:00.003+01:00

Dzisiejsza prezentacja Wojtka Gomoła o wyrażeniach Lambda (C# i "emulacja" w Javie) na Lubelskim JUG przypomniała mi o kilku ciekawych zabawkach, które jakiś czas temu znalazłem i zapomniałem o nich napisać.

Ciekawą cechą dynamicznych języków funkcyjnych jest:
- możliwość tworzenia konstrukcji zbliżonych do języka naturalnego
- możliwość rozszerzania standardowych, często używanych klas (zwykle kolekcji, kontenerów) o wygodne metody
- nazwijmy to w sumie roboczo "techniczny DSL"

Przykładowo takie oto sprawiające radość uproszczenia:


kolekcja.wyrzucZNullemWPolu("name").posortuj({e1.age >e2.age}).wytnijPierwszych(10);

Jak dla mnie nie ma się czym ekscytować ponieważ jest to jedynie lukier składniowy i w statycznych językach z silną kontrolą typów jest to tylko kwestia stworzenia jakiegoś starego, dobrego, proceduralnego Utilsa z interfejsem strategii komparacji:


MyAlmightyUtils28.wyrzucZNullemWPolu(kolekcja, "name")

oraz odpowiednia sekwencja wywołań.

/*Oczywiście wszyscy wiemy, że Utilsy są złe i brzydkie, ale co zrobić*/

No ale już nie będzie tak pięknie jak we wcześniejszym przykładzie z jakiegoś sexi-skryptowego-języka.

Na szczęście istnieje kilka ciekawych zabawek zaimplementowanych w Javie. Dzięki cwanym trikom na generykach i zastosowaniu odpowiedniego nazewnictwa dają nam coś więcej niż namiastkę konstrukcji znanych z dynamicznych, słabo otypowanych języków.

op4j - genialna biblioteka, która sprawia, że żmudny kod staje się bardziej czytelny i zwięzły jednocześnie zachowując typowanie.
Bardzo podstawowy przykład:


String[] emailArray = Op.on(userEmails).toArrayOf(Types.STRING).forEach().exec(FnString.toLowerCase()).get();

lambdaj - podobna zabawka ze stajni google. Można rzucić okiem również na google collections.

Mockito - nasza rodzima produkcja. Kto jeszcze nie używał, ten powinien spróbować. Warto zajrzeć choćby do kodu ponieważ stanowi on przykład wzorcowej dokumentacji. Cały manual wraz z przykładami znajduje się w JavaDocu głównej "klaski"! Wzór do naśladowania dla innych twórców bibliotek - bo na pewno nie dla developerów komercyjnych produktów;)

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

Czekamy na Javę ~~1.7~~ z jej nową konstrukcję closures. Ale forma w jakiej pojawi się ona w nowym wydaniu języka będzie praktycznie niczym innym niż uproszczonym wydaniem anonimowej klasy wewnętrznej. Czyżby ukłon w stronę tych hakerów, którzy nie mogą połapać się w konstrukcji anonimowych klas albo Wzorca Strategii?

No i na pewno na certyfikatach pojawią się kolejne arcyistotne pytania mające na celu sprawdzenie czy delikwent jest w stanie odróżnić: domknięcie od klasy wewnętrznej i od niekompilującego się kodu;P

Inżynieria w służbie użyteczności

2010-02-07T15:43:00.011+01:00

/*
*Tytuł niczym wzięty ze sztandaru
*z jakiegoś pochodu
*z uprzedniej smutnej epoki:)
*/

Witam po długiej przerwie. Zaprezentuję dziś pewne ujęcie Usability oraz koncepcję technicznego rozwiązania użytecznej aplikacji - jej architekturę i dwa główne wzorce projektowe.

NOWICJUSZ vs EKSPERT
Użyteczność niejedno ma oblicze. Możemy mówić o przejrzystości, intuicyjności, ergonomii itd. Każdy z nas zapewne zdefiniuje dobre GUI jako takie, które oferuje to czego się spodziewamy. Ale co to znaczy? Oczywiście dla każdego coś innego.

Dziś skupimy się na problemie różnych potrzeb i oczekiwań użytkowników o różnym poziomie zaawansowania.

Analizując Model Rozwoju Kompetencji Braci Dreyfus
krótki opis
szerszy opis
możemy wywnioskować, że użytkownicy reprezentujący skrajne poziomy kompetencji potrzebują skrajnie odmiennego GUI.

Nowicjusz i Zaawansowany Początkujący są nastawieni na zadania ponieważ nie ogarniają jeszcze całości problemu. Potrzebują określonej ścieżki, przez którą będą prowadzeni za rękę a na każdym etapie dostaną jasne wytyczne odnośnie tego CO trzeba zrobić.

Z drugiej zaś strony Kompetentny, Biegły i Ekspert są nastawieni na osiągnięcie celu i mniej lub bardziej orientują się jak go osiągnąć.

Jak to w życiu bywa: "różni ludzie, różne potrzeby".

Mniej zaawansowani użytkownicy potrzebują aplikacji-asystenta zorientowanej na zadania. Aplikacja taka nie powinna atakować mnogością możliwości. Powinna w danym momencie sugerować (lub wręcz zmuszać) do zrobienia właściwej rzeczy. Przykładem mogą być nasze ulubione kretynatory (yyy kreatory).

Zaawansowany użytkownik potrzebuje aplikacji zorientowanej na możliwości. Dla niego wygodne będzie rozbudowane menu, bez sugerowania co kiedy kliknąć. Zaawansowany użytkownik dobrze wie co chce zrobić i nie potrzebuje aby mu podpowiadać. Mało tego, taki użytkownik ma wyrobiony swój własny styl pracy, zatem aplikacja-asystent jedynie przeszkadza. Najlepszym przykładem może być: IDE (np. Eclipse), zaawansowany edytor tekstu albo narzędzie typu CAD. Tysiące opcji w menu i biała kartka na dzień dobry.

Klasyczny problem występujący w aplikacjach biznesowych to nauka obsługi użytkowników. Stare systemy tej klasy orientowało się na możliwości (teraz powoli sytuacja ulega zmianie). Mamy zatem nieszczęsną użytkowniczkę, która zaczyna naukę obsługi systemu (może również jednocześnie "uczy się komputera"). Przytłoczenie mnogością opcji skutkuje jednym: tresurą. Użytkownik nie ma innego wyjścia jak opanowanie procesu biznesowego na zasadzie szympansa: klikam trzeci z lewej, później ok, później przedostatnia zakładka, później klikam drugi od dołu...

Wszyscy znamy też nietrafione rozwiązanie, które miało pomagać nowicjuszom w okiełzaniu eksperckiego narzędzia - spinacz w Office;)

PRZYKŁAD APLIKACJI
W przypadku aplikacji korporacyjnych jest łatwiej. Użytkownik nie ma innego wyjścia jak zacisnąć zęby i nauczyć się (pardon - wytresować się). Jest to po prostu przykre narzędzie jego pracy.

Natomiast gdy nasza aplikacja ma konkurować na wolnym rynku wówczas musimy nieco się wysilić. Użytkownik zirytowany autystycznym GUI aplikacji po prostu porzuci ją, zaklnie i pójdzie sobie do konkurencji:)

Użytkownicy są teraz niezbyt cierpliwi i mają wysokie wymagania odnośnie przyjemności - pokolenie MTV?

Aby ustalić kontekst aplikacji walczącej o klienta wysokim poziomem użyteczności wyobraźmy sobie system do projektowania wnętrz, np. wnętrz kuchni.
Niech zaprojektowanie wymaga między innymi: określenia obszaru pomieszczenia, ustalenia otworów i innych przeszkód, rozstawienia mebli i AGD, dopasowania wszystkich wymiarów, wyboru materiałów z których mają być wykonanie poszczególne elementy, itd. Dalej mamy rysunki techniczne, wyliczenia należności, umowy, itp.

Ustalmy wyzwanie: z aplikacji ma być wykorzystywana przez:
- klientów końcowych, którzy to raz na kilka(naście) lat kupują sobie "kuchnię"
- projektantów kuchni, którzy dziennie wyklikują po kilka takich zestawów.

Co z kompetencjami naszych użytkowników?
Jasne jest, że klient końcowy jest totalnym Nowicjuszem jeżeli chodzi o aplikację. Użyje jej raz (ew jako rodzinny "haker" pomoże szwagrowi wyklikać jego zestaw). Zatem nigdy nie nabędzie wyższych kompetencji. Co gorsza klient może być również niekompetentny w domenie problemu, czyli wszystkich zagadnieniach związanych z kuchniami.
Manual oczywiście odpada, bo zirytowany klient pójdzie sobie do konkurencji.

Projektant jest zwykle w miarę kompetentny w domenie problemu;) Będzie też Nowicjuszem jako użytkownik, ale ponieważ będzie miał motywację i częstą styczność z aplikacją to szybko osiągnie poziom Kompetentny a z czasem dojdzie do Eksperta.

ARCHITEKTURA ROZWIĄZANIA
Mamy zatem dwie klasy użytkowników, którzy potrzebują diametralnie różnego interfejsu. Początkujący użytkownik wymaga przeprowadzenia go przez cały proces projektowania krok po kroku, bez zbędnych pytań, defalutowo, szybko, gładko i bez irytacji. Zaawansowany użytkownik potrzebuje natomiast wolności, możliwości i tysięcy szczegółowych opcji.

Jak to pogodzić? Czy musimy tworzyć niemal 2 osobne aplikacje?
Niekoniecznie, jeżeli podejdziemy do problemu racjonalnie to możemy zredukować narzut związany z przygotowaniem 2 wersji.

Możemy podejść do problemu następująco:

Wydzielamy CORE aplikacji, który zawiera klasy odpowiedzialne za główną funkcjonalność, czyli projektowanie wnętrz (wraz ze wszystkimi regułami z tym związanymi) oraz wizualizację projektu.
Core jest dostępny przez API.

Mamy 2 zestawy GUI: jeden prosty i intuicyjny oraz zorientowany na zadania przeznaczony dla początkujących. Drugi to klasyczny potwór dla eksperta oferujący niezliczone możliwości w rozbudowanych menu.

Oba rodzaje GUI komunikują cię z Corem wysyłając polecenia zhermetyzowane przy użyciu wzorca projektowego Command. Idea wzorca jest taka, że czynności nie są metodami (jak w klasycznym podejściu proceduralnym). Czynności są obiektami. Dla wszystkich klas poleceń istnieje wspólny interfejs zawierający jedną metodę - jest to sygnał do polecenia aby wykonało ono zawartą w sobie logikę.

Konkretny command zawiera w sobie zestaw instrukcji operujących na API Cora. Oczywiście commandy wysyłane z GUI Nowicjusza będą zawierać więcej kodu operującego na API. Jedna czynność takiego użytkownika wykonuje więcej operacji. Commandy wysyłane z GUI Eksperta będą bardziej elementarne. Commandy mogą po sobie dziedziczyć, mogą się na wzajem dekorować z wykorzystaniem wzorca Dekratora w celu reużycia logiki.

W przedstawionej architekturze mamy dodatkowo wzorzec Mediatora. Został on wprowadzony jako "środowisko uruchomieniowe" dla poleceń oraz "hub" spinający wiele komponentów. GUI wysyła commadny do Mediatora, a to mediator wykonuje otrzymane polecenie (uruchamiając wspólną metodę interfejsu) przekazując do nich kontekst uruchomienia, czyli core.
Mediator może również przy okazji manipulować stanem GUI, które nie należy do Core (np nakładać przeźroczystą chmurę na czas długotrwałych operacji bądź włączać dostępność opcji w menu). Mediator może też generować zdarzenia aplikacyjne, które będą obsługiwane przez pewne komponenty graficzne prezentujące zajście danego zdarzenia. Można bawić się do woli z Mediatorem, ale trzeba uważać aby nie stał się boską klasą o zbyt dużej odpowiedzialności.

ZWIĘKSZAMY USABILITY
Każdy użyteczny system, którego idea zasadzą się na bogatej interakcji użytkownika powinien oferować funkcjonalność "Cofnij". Wprowadzenie tej funkcjonalności jest generalnie bardzo kłopotliwe. Kto zmagał się z tym problemem ten zapewne próbował niewydajnego rozwiązania polegającego na "zrzucie" aktualnego stanu do pamięci podczas wykonywania każdej operacji modyfikującej stan.

Ogólnie jest to problematyczna funkcjonalność, chyba że...

...posiłkujemy się wzorcem Command:)

Możemy wówczas rozszerzyć go o anti-command.
Każde polecenie zawierające logikę zawiera w sobie anty polecenie (jako obiekt dostępny przez getter - a getter w interfejsie Command). Antypolecenie zawiera logikę odwrotną do polecenie.

Teraz w naszym przypadku Mediator wykonując polecenie, pobiera z niego anty-polecenie i odkłada je na stosie. W razie potrzeby, czyli gdy użytkownik kliknie cofnij (ctrl+z) wołamy Mediatora, który pobierze polecenie ze stosu anty-poleceń i wykonana go. Proste:)

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

O ile omawiana problematyka usability w kontekście kompetencji użytkownika jest ogólna, to przedstawione rozwiązanie nie aplikuje się do aplikacji webowych z cienkim klientem. Zresztą taki klient ma zastosowanie do innej klasy problemów.

Natomiast rosnąca popularność grubszych klientów (opartych o: flex, javafx, silverligh, stare-dobre-niedoinwestowane-przez-matołów-suna applety czy nawet GWT) pozwala przewidywać, że coraz częściej będziemy spotykać się problemami tej klasy.

Wspinaczka do profesjonalizmu

2010-01-26T18:15:00.009+01:00

Wreszcie po ponad miesięcznej przerwie znalazłem chwilę czasu na napisanie posta:)
Brak czasu na pisanie wynika głównie z nawału nowych obowiązków związanych z opieką nad 3-tygodniową córką:]

Dlatego też dziś odsyłam do artykułu mojego autorstwa, który ukazał się w lutowym wydaniu SDJ pt:
"Wspinaczka do profesjonalizmu
Modelowa ścieżka rozwoju kompetencji – podejście pragmatyczne"

Artykuł traktuje o rozwoju kompetencji developerskich w kontekście Modelu Kompetencji Braci Dreyfus, o którym już pisałem.

W tekście zachowano znaczniki specyficzne dla wydawnictwa, ponieważ są czytelne dla "ludzi z branży" a jednocześnie nadają mu strukturę. Tekst zawiera kilkanaście stron, ale podobno szybko i lekko się go czyta;)

Zapraszam do lektury artykułu i być może nawet całego numeru poświęconego programowaniu gier - zawsze to ciekawa odmiana od enterprajz;)

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

W ciągu najbliższego tygodnia noworodek powinien przepoczwarzyć się w mniej zasobożerne niemowlę a co za tym idzie pojawi się kilka nowych postów. Będą poświęcone zagadnieniom z zakresu Craftsmanship, m. in. projektowaniu systemu pod kątem usability (na podstawie moich ostatnich doświadczeń z paroma autystycznymi koszmarkami) .

Java EE

2009-12-20T10:07:00.009+01:00

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

Seam == JSF + EJB ?

2009-11-29T23:11:00.019+01:00

WSTĘP

Framework Seam opiera się na bardzo silnym mechanizmie - bijekcji.

Bijekcja to nowa jakość w technice Dependency Injection, która pozwala na budowanie bardziej naturalnych konstrukcji Inversion on Control.

/**
* Na marginesie dodam, że DI i IoC to nie jest to samo.
* Wyjaśnienie różnic w tym przydługim poście:
* Wprowadzenie do wstrzykiwania zależności i Springa zarazem
*/

Bijekcja w skrócie przedstawia się następująco:
- podczas wywołania metody
- następuje wstrzyknięcie zależności do obiektu, którego metoda jest wołana (pola adnotowane @In)
- metoda jest wykonana
- następuje wystrzyknięcie obiektów do kontekstu Seam (pola adnotowane @Out)
- następuje czyszczenie (nulllowanie) wstrzykniętych zależności

Od strony technicznej odbywa się to w Seam dzięki specjalnym interceptorom. Przechwytują one wywołania metod wszystkich komponentów i wokół tych wywołań dodają całą opisaną powyżej magię.

Koncepcja jest jak już napisałem piękna, ponieważ pozwala na budowanie dużo bardziej naturalnych konstrukcji. Wstrzyknięcia następują per wywołanie metody a nie jedynie raz, po stworzeniu komponentu - zaspawane na wieki wieków (albo przynajmniej do restartu servera z powodu zwisu aplikacji;)
Dodatkowo niemal bez ograniczeń możemy wstrzykiwać w siebie komponenty o różnych zasięgach - nie ma ograniczenia szerszy zasięg w węższy. Dlatego, że wstrzyknięcie następuje jedynie na czas wywołania metody i nie będziemy mieli nigdy problemu z nieświeżą instancją komponentu.

PROBLEM

Twórcy frameworka poszli jeszcze dalej...
Umożliwiają używanie Sesyjnych EJB wprost w JSF - bez potrzeby pośredniej warstwy Managed Beanów (lub ich specyficznej odmiany Backing Beanów). Czyli komponenty Seam, które są jednocześnie komponentami EJB będą widoczne w kontekście JSF.
Managed Beany są podobno zbędą warstwą, która tylko przeszkadza. Możliwość wołania EJB z JSF jest rzekomo tryumfem rozumu na platformą korporacyjną.

Hmmm w bardzo prostych systemach klasy "Przeglądarka Bazy Danych" rzeczywiście można by się obyć bez MB, ale w niniejszym poście przedstawię do jakich kuriozalnych konstruktów dochodzi gdy w nietrywialnych przypadkach wiążemy JSF wprost z EJB.

Na wstępie zaznaczam, że na potrzeby niniejszych rozważań pomijamy aspekty warstwowej architektury, elementarnych zasad projektowania mówiących o kohezji klasy i temu podobnych staromodnych ograniczeniach. Skupiamy się na "produktywnym" kodowaniu na wyścigi rodem z najlepszych tutoriali i książek.

Zaczynamy.
Przykład prosty, klasyczny ekran prezentujący listę czegoś.
Wymagania:
Po ordynarnym wejściu na stronę przez GET chcemy aby lista wyświetlała wszystkie dane.
Widok ma pozwalać również na wyszukanie czegoś po jakimś atrybucie - czyli wpisanie szukanego słowa w pole tekstowe i naciśnięcie buttonu z zaokrąglonymi rogami "Szukaj" (POST gwoli ścisłości).

Na początek implementujemy pierwsze wymaganie: po wejściu na stronę widzimy listę wszystkiego...

Strzępek kodu widoku:


  <h:dataTable value="#{listaCzegos}" var="_cos">
    <h:column>#{_cos.nazwa}</h:column>
  ...
  </h:dataTable>

Stateless Session Bean, który dostarcza danych dla widoku:


@Stateless
@Name("cosProwajder")
public class CosProwajderBean implements CosProwajderLocal{
  @Out
  private List listaCzegos;

  @Factory("listaCzegos")
  public void initListaCzegos(){
    listaCzegos = //pobranie danych
  }
}

Co się tutaj dzieje: JSF rząda komponentu listaCzegos. Seam widzi, że nie istnieje on w kontekście, ale na szczęście znalazł ochotnika, który go sfabrykuje - metodę otagowaną adnotacją @Factory("listaCzegos"). Metoda zostaje wywołana, metoda ustawia pole prywatne, a ponieważ pole jest adnotowane @Out to po chwili jest wystrzykiwane do kontekstu. Dzięki temu JSF "widzi" listę i może ją już teraz spokojnie renderować w tabelce.

Kod Session Beana mógłby równie dobrze wyglądać tak:


@Stateless
@Name("cosProwajder")
public class CosProwajderBean implements CosProwajderLocal{

  @Factory("listaCzegos")
  public List initListaCzegos(){
    listaCzegos = //pobranie danych
    return listaCzegos;
  }
}

Ale już śpieszę wyjaśnić skąd poprzednia konstrukcja. Mam już w zamyśle spełnienie drugie wymagania - funkcjonalności wyszukiwania. Zatem na widoku pojawi się pole tekstowe i button:


<h:form>
  <h:inputText value="#{searchFilter.name}" />
  <h:commandButton action="#{cosProwajder.search}" />
<h:form>

Nasz Session Bean dostanie metodę search, która wyszuka dane na podstawie wstrzykniętych kryteriów, następnie wynik ustawi w prywatnym polu, z którego to po chwili wartość zostanie wystrzyknięta do kontekstu Seam, skąd JSF będzie ją widział.


@Stateless
@Name("cosProwajder")
public class CosProwajderBean implements CosProwajderLocal{
  @Out
  private List listaCzegos;

  @In
  private SearchCriteria searchCriteria;

  @Factory("listaCzegos")
  public void initListaCzegos(){
    listaCzegos = //pobranie danych
  }

  public void search(){
    listaCzegos = //pobranie danych na podstawie searchCriteria
  }
}

Jeszcze tylko dla ścisłości komponent przechowujący kryteria wyszukiwania. Zasięg PAGE aby kryteria były widoczne po przeładowaniu strony:


@Name("searchCriteria")
@Scope(PAGE)
public class SearchCriteria implements Serializable{
  private String name;
  //getter i setter
}

Pytanie: co jest nie tak z poniższym kodem?


@Stateless
@Name("cosProwajder")
public class CosProwajderBean implements CosProwajderLocal{
  @Out
  private List listaCzegos;

  @In
  private SearchCriteria searchCriteria;

  @Factory("listaCzegos")
  public void initListaCzegos(){
    listaCzegos = //pobranie danych
  }

  public void search(){
    listaCzegos = //pobranie danych na podstawie searchCriteria
  }
}

Dla ułatwienia wyrzucę linijki odwracające uwagę i zaznaczę kluczowy element:
(To przecież nie jest egzamin na certyfikat - chcemy się tu dowiedzieć czegoś pożytecznego)


@Stateless  //<<-------------
public class CosProwajderBean implements CosProwajderLocal{
  private List listaCzegos;

  private SearchCriteria searchCriteria;

  public void search(){
    listaCzegos = //pobranie danych na podstawie searchCriteria
  }
}

Właśnie!
Niby mamy bezstanowy komponent, ale korzystamy z niego w stanowy sposób!

Wyobraźmy sobie, że nasz wspaniały komponent biznesowy jest tak genialny, że chcemy go wykorzystać jeszcze gdzieś poza JSF, np wywołać zdalnie. Musimy wówczas:
1. ustawić kryteria wyszukiwania (zakładając, że mamy setter)
2. odpalić metodę search(), która zmieni stan - tu jest ta nieszczęsna stanowość
3. odebrać wynik przez getter

Czyli JSF wymusza na nas styl "strzelania z muszkietu": załaduj i wypal.

Czy dałoby się wykorzystać mimo wszystko ten super-kod poza Seam, np przykrywając go fasadą:


@Stateless
public class CosProwajderFacadeBean implements CosProwajderFacadeRemote{
  @Ejb
  private CosProwajderLocal cosProwajder;
  public List search(SearchCriteria searchCriteria){
    cosProwajder.setSearchCriteria(searchCriteria);
    cosProwajder.search();
    return cosProwajder.getListaCzegos();
  }
}

Niestety NIE, ponieważ nie mamy gwarancji, że kontener JEE przy każdym z 3 wywołań bezstanowego komponentu zaserwuje nam tą samą instancję!

Dlaczego ten bezsensowny kod działa w ogóle w Seam? Tak jak napisałem na wstępie - interceptory Seam. Jeden z nich przechwytuje wołanie metody search na komponencie, wstrzykuje kryteria, wykonuje metodę, wystrzykuje wynik. Ponieważ wstrzykiwanie i wystrzykiwanie nie są wywołaniem metod biznesowych bezstanowego komponentu to interceptor cały czas operuje na tej samej instancji.

ROZWIĄZANIE

Łatwo można rozwiązać problem sensowności kodu zmieniając bean bezstanowy na stanowy. Jednak wciąż mamy problem z bezsensownością logiczną. Dlaczego jakiś komponent będący de facto wrapperem dla procedury ma być stanowy?

Owszem w pewnych sytuacjach stanowość może mieć sens, np: z przyczyn wydajnościowych komponent stanowy trzyma wynik jako jakiś kursor po stronie bazy. Klient Stanowego Komponentu Sesyjnego przegląda listę wynikową po kawałku. Tę argumentację zaliczam.

Innym usprawiedliwieniem może być chęć wybrania (kliknięcia) wiersza - z technicznych powodów musi wówczas przechować listę. Innym jeszcze usprawiedliwieniem może być naiwna paginacja, która w naiwnych paginatorach działa na danych sesyjnych pobranych w całości z bazy.
Czy jednak sensowne jest dopasowywanie API komponentów biznesowych do takich szczegółów technicznych jakiś frameworków prezentacji?
Poza tym wciąż będziemy mieli kuriozalne korzystanie z niego w fasadzie - w stylu "strzelania z muszkietu": załaduj i wypal.

PRAWDZIWE ROZWIĄZANIE

Aby nasze komponenty biznesowe miały sensowny interfejs w nietrywialnych przypadkach musimy ponieść ten niesamowity trud wprowadzenia warstwy jakiś Managed Beanów - w Seam zwanych Akcjami.

Są to zwykłe POJOs, które mają API w stylu "strzelania z muszkietu" a logikę biznesową delegują do EJB:


@Name("cosControler")
public class CosControler{
  @In //EJB
  private CosProwajderLocal cosProwajder;

  @Out
  private List listaCzegos;

  @In
  private SearchCriteria searchCriteria;

  @Factory("listaCzegos")
  public void initListaCzegos(){
    //używamy pustych kryteriów (w celu optymalizacji można by wynieść je do singeltona)
    listaCzegos = cosProwajder.search(new SearchCriteria());
  }

  public void search(){
    //Wywolanie EJB
    listaCzegos = cosProwajder.search(searchCriteria);
  }
}

Jest to również doskonałe miejsce do wstrzyknięcia np kontekstu FacesMessages, kontekstów Seam, parametrów Request, bindowanie UIComponent i innych zależności typowych dla technikaliów frameworków. W tej warstwie możemy sobie na to śmiało pozwolić i dzięki niej nie musimy brudzić EJB zależnościami od Seam i JSF.

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

Sama możliwość wołania Sesyjnych EJB z JSF jest oczywiście bardzo wygodnym ficzerem i warto czasem z niej korzystać. Ale tylko wówczas gdy ma to sens i jest racjonalnie uzasadnione.

Tworzenie komponentu biznesowego, który jest "zbrukany" stylem i zależnościami pewnych technologii powoduje, że nie jest to już ani komponent ani biznesowy. Komponent - czyli pewna reużywalna część; biznesowy - czyli zajmujący się jedynie logiką biznesową.

Geneza i ograniczenia OO

2009-11-25T21:08:00.011+01:00

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...

SQL Injection

2009-11-10T01:01:00.003+01:00

Kolejny post z serii geek-humor

ZU0 666 - apokalipsa fotoradarów:

Czysty kod to przetestowany kod?

2009-11-09T21:27:00.021+01:00

Clean Code to skądinąd szczytna idea, na fali której kilka osób chce się wylansować ostatnimi czasy. Przyjrzymy się jej dzisiaj nieco bliżej aby sprawdzić czy nie kryje się za nią przypadkiem merytoryczna próżnia...

Ewangelizatorem tej idei jest nasz ulubiony Wujek Dobra Rada - Uncle Bob. Polecam wszystkim jego prezentację pt Craftsmanship and Ethics.

Uncle B z pasją opowiada o profesji i etyce w naszej branży. Właściwie to przekonuje, że już najwyższy czas aby wykrystalizowały się one bo póki co jeszcze się ich nie dorobiliśmy. Tutaj zgadzam się z nim bez 2 zdań. Metodyka byle-jak-byle-działało-ale-miało-zaokrąglone-rogi-na-gui to aktualnie standard.

Jako że są to idee bardzo mi bliskie to pierwsza część prezentacji jest na prawdę budująca. Dalej Uncje B twierdzi, że drogą do profesjonalizacji i nieskazitelnego kodu jest Test Driven Development. "Nie wolno Ci napisać ani linijki produkcyjnego kodu bez napisania uprzednio testu!" grzmi wujaszek! Kropka.

Postępuj tak a w nagrodzę po śmierci będą czekać na Ciebie w niebie zastępy dziewic - do tego nimfomanek rozumiejących maszynowy kod w reprezentacji binarnej. Marzenia...

...ale chyba nie będzie tak łatwo.

TDD owszem jest techniką, która ma swoje przeznaczenie i zastosowania ale nie dajmy się zwieść, że rozwiązuje wszystkie problemy. Co najwyżej niektóre.

Sensowna krytyka tego typu rozumowania znajduje się w typ poście: It's OK Not to Write Unit Tests. Wujkowi Dobra Rada chyba tylko wydaje się, że rozprawił się z adwersarzem przy pomocy racjonalnych argumentów: Excuse me sir, What Planet is this?

O ile w pewnych sytuacjach testy mogą "sterować" developmentem to nie zapominajmy o technikach, które rzeczywiście prowadzą do clean code.

Co nam po nawet 100% pokryciu kodu testami jeżeli kod będzie jedną wielką kupą...
Działającą nawet perfekcyjnie, ale wciąż jedną wielką kupą... [wstawić_swoją_ulubioną_metaforę]

Refaktoryzacja to podstawa? Co nam po wsparciu dla refaktoryzacji dzięki pokryciu kodu testami, które zwalniają nas z napięcia towarzyszącemu zmianom skoro... nie mamy pojęcia jak refaktoryzować ani w ogóle, w którą stronę refaktoryzować?

Do tego właśnie zmierzam... TDD nie daje żadnych wskazówek jakich technik developerskich użyć aby osiągnąć upragniony Clean Code. To oczywiste, że nie daje wskazówek, bo nie leży to w "domenie" TDD. Ale trzeba to sobie uświadomić i nie dajmy sobie wcisnąć kitu, że testy jednostkowe rozwiązują problem - są po prostu niewystarczające. Pomagają rozwiązać - ale rozwiązanie właściwe leży chyba gdzie indziej.

Czysty kod, aby powstał musi być wypracowany poprzez pewien wysiłek umysłowy. Nie wystarczy dorwać się do klawiatury i radośnie stukać (o tym na koniec). Na ten proces musi składać się rzetelna analiza problemu, projekt i dopiero implementacja. Nie mam tu oczywiście na myśli metodyki Waterfall, ale po prostu pewnej pracy, którą trzeba wykonać - nawet w umyśle jednej osoby.

Dla każdego z tych etapów mamy zestaw sprawdzonych technik oraz narzędzi, które oczywiście nie gwarantują sukcesu, ale zwiększają prawdopodobieństwo powstania upragnionego Clean Code.

Na poziomie analizy możemy posłużyć się Archetypami Modeli Biznesowych. Są to skatalogowane gotowe rozwiązania standardowych problemów biznesowych. Modele te zostały wypracowane przez wytrawnych analityków dzięki czemu można je dostosowywać do swych potrzeb. Są również zaprojektowane z myślą o rozbudowie modelu. Można by dużo o nich pisać, ale nic nie zastąpi przykładu. A przykład w jednym z najbliższych postów. Póki co zastanówmy się co nam po doskonale obłożonym testami modelu, który jest kupą...

Gdzieś na styku analizy i projektu mamy na przykład Domain Driven Design.

Zanim przejdziemy do poziomu projektu zatrzymajmy się przez chwilę na architekturze, będącej stylem, na podstawie którego będziemy projektować. Zastanówmy się co nam po doskonale obłożonym testami kod jeżeli architektura jest kupą...

Na poziomie projektu mamy zestaw technik np Object Oriented. GRASP i SOLID - pomagające w poprawnym interpretowaniu OO i uniknięciu proceduralnego kodu dziwacznie upchanego w klasy.
Nie zapominajmy o Wzorcach Projektowych. Kiedyś było o nich głośno, ale aktualnie młodzież woli sobie wyklikać/wygenerować trochę kodu. Ci bardziej Agile obłożą go paroma testami i jest git;)
Wzorce mogą pomagać u utrzymaniu czystej struktury kodu, ale przy ich "pomocy" można również bardzo skutecznie niepotrzebnie zagmatwać powinny pozostać prostsze - cała sztuka w wyważeniu. Ale tego oczywiście nie dowiemy się z marketingu TDD;)

Co do wzorców to planuję kiedyś stworzyć serię postów z realistycznymi (nieksiążkowymi) przykładami - ale jak zwykle czasu brak. Co do GRASP i SOLID to można znaleźć trochę dobrych przykładów - np ten.

Kiedy już wiemy co i jak to na poziomie implementacji możemy podeprzeć się techniką testów jednostkowych. Ale to czy kod będzie Clean zależy od pracy umysłowej włożonej również (albo przede wszystkim) wcześniej.

Konkludując: TDD ew. jako dodatek na drodze do Clen Code wujaszku;P

Aby uzupełnić całość warto wspomnieć o podejściu Specify First - dobry opis w poście TDD is not test-first. TDD is specify-first and test-last. Niektórzy twierdzą, że dopiero przy takim podejściu można mówić o prawdziwym TDD.
Chodzi generalnie o to, że pisząc najpierw test - nawet nie interfejs implementacji, a test - stawiamy się w roli kodu "klineta" danej klasy. Na pewno wpływa to pozytywnie na nasz design - bardzo pozytywnie.

Ale to znowu półśrodek. Technika owszem dobra, ale dla tych z nas, którzy są wciąż jeszcze na poziomie myślenia kodem.

Myślenie kodem to zupełnie normalna faza w rozwoju programisty i każdy przez nią przechodzi. Jeżeli jesteś początkujący to zapewne zauważyłeś, że gdy mówisz do kogoś ifami i pętlami to on krzywi się i zaczyna rysować jakieś prostokąty połączone strzałkami aby cokolwiek zrozumieć. Jeżeli bawisz się w to już kilka lat to zapewne irytują cię juniorzy, którzy mówią do Ciebie kodem. Normalna sprawa, abstrahowanie przychodzi z czasem ...

Zatem "Specify first" jest dobre na początek gdy świerzbią nas paluszki i chcemy jak najszybciej dorwać się do klawiatury i nastukać coś co można będzie za chwilę radośnie debugować. Analizowanie, modelowanie, projektowanie... to dobre dla zgredów.

Przy podejściu Top-Down rzeczywiście klasy "niższe" mogą być pokraczne bez wyobrażenie sobie jak będą używane. Ale top-down powinien być style analizowania problemu, natomiast projektowanie klas można przeprowadzić bottom-up dzięki czemu powstaną "komponenty" - niczym niezależne części "ruchomej machiny". Z czasem przychodzi umiejętność wyobrażania sobie i manipulowania obiektami "w pamięci" (własnej) bez potrzeby pisania czegokolwiek. Pomocy może być ew. ołówek, kartka i UML. Ktoś pamięta w ogóle co to jest UML? Nie to nie jest kolejna biblioteka do mockowania;P

Taaak.... kiedyś pewnie powstanie Unified Mocking Library - w sumie już nic mnie nie zdziwi w naszej branży...

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

Od razu uprzedzę ew. komentarze aby uniknąć niepotrzebnego niezrozumienia.
W tekście nie zajmuję stanowiska ZA albo PRZECIW testom jednostkowym. Moim celem było zwrócenie uwagi na fakt, że same testy niewiele wnoszą do koncepcji Clean Code. TDD jest techniką implementacyjną oraz od niedawna jest sprzedawany jako technika specyfikowania dla niecierpliwych/początkujących.

Moja teza jest następująca: aby osiągnąć Clean Code potrzeba dodatkowo kilku innych technik developerskich. Dopiero synteza całości może dać zadowalający rezultat.

I niestety trzeba się wysilić znacznie bardziej niż tylko dopisać więcej kodu - testującego. A podstawowe zagadnienia z zakresu inżynierii oprogramowania (Low Coupling, High Cohesion, IoC,...) przydają się również choćby do pisania kodu podatnego na testy - o wysokim poziomie testability.

Mały refreshing

2009-10-19T14:00:00.005+02:00

Jako, że na blogspocie pojawiły się nowe szablony (a poprzedni zielony już mi się znudził) uznałem, że czas na zmianę.

Przy okazji lekkiej zmianie uległa sama nazwa bloga (poprzednia brzmiała chyba zbyt pretensjonalnie), motto i sekcja "o blogu".

//================
Zastanawiam się też nad pozbyciem się słowa "holistycznie" z nazwy - ostatnio kojarzy się ono z medycyną alternatywną, homeopatią i innymi tego typu rzeczami;) Ale nie wszystko n a raz.

JUG, JDD, DDD, Cooluary v3 - podsumowanie

2009-10-18T16:49:00.012+02:00

Tydzień upłynął pod znakiem Domain Driven Design.

Wtorek: prezentacja "DDD + impl w Seam" na lubelskim JUG.

Był to beta test przed piątkową ewangelizacją DDD w Krakowie podczas Java Developers' Day. Przy okazji podziękowania za feedback, który otrzymałem od wielu osób po wtorkowym wystąpieniu. Dzięki niemu udało mi się skompresować ponad 2h do 45 min na potrzeby JDD:)

Sobota: COOluary i powtórka DDD. Tym razem już 3h, sam DDD bez Seam - panowie słusznie założyli, że technikalia są drugorzędne.

Zarówno podczas prezentacji na JUG jak i DDD pojawiło się kłopotliwe pytanie odnośnie poniższego slajdu:

Slajd prezentuje Building Block, przy pomocy których to modelujemy domenę biznesową.
Ale zanim przejdziemy do pytania - przyda się wstęp. Jeżeli ktoś był na prezentacji, to może spokojnie przewinąć się niżej...

NIEKRÓTKI WSTĘP

Logikę dzielimy na dwie warstwy:
- Warstwę logiki aplikacji
- warstwę modelu domenowego

Warstwa logiki aplikacji jest cienka nie bez kozery. Zawiera ona logikę specyficzną dla danej aplikacji i jednocześnie nie będącą logiką reguł biznesowych - przykładowo: transakcje, bezpieczeństwo, jakiś mailing, ale również koszyk w sklepie internetowym. Model zamówienia i produktów to logika biznesowa, ale sam koszyk jest ficzerem aplikacji.

Warstwa modelu domenowego jest budowana z klas grających pewne role. Z ról wynika odpowiedzialność tych klas. Czyli opieramy się na paradygmacie Responsibility Driven Design.

Te role to:
Encje - identyfikowalne (posiadająće ID) byty biznesowe. Nie tylko rzeczowniki, ale również np metafory przejścia/zmiany stanu. Co ważne z rolą encji wiąże się realizacja odpowiedzialności biznesowych. Zatem mówimy stanowcze NIE dla anemicznego modelu;)
Inaczej niż w popularnych ORMach encja jak najbardziej powinna mieć metody biznesowe.

Value Objects - obiekty nieidentyfikowalne i zwykle niemodyfikowalne. Jeżeli 2 Vo mają takie same atrybuty to są wówczas tożsame. VO również mogą posiadać odpowiedzialność biznesową. W pewnych podejściach są marginalizowane a w innych wręcz wypierają encje - ale to temat na osobne posta, więc zostawmy.

Agregaty - Encje, które zawierają w sobie grafy encji lub VO. Co ważne agregaty hermetyzują swą implementację więc wszelkie operacje na wnętrznościach wykonujemy przez metody biznesowe encji głównej będącej Aggregate-root.

Repozytoria - zarządzają persystencją Encji/agregatów. To oczywiście jedynie interfejsy; implementacje są warstwę niżej. Nie ma tu metod wyszukujących po kryteriach pochodzących z GUI znanych z DAO.

Fabryki - hermetyzują złożoną (zwykle) logikę tworzenia agregatów.

Servisy - servisy biznesowe (nie mylić z aplikacyjnymi) zawierają logikę, której nie sposób sensownie przypisać do żadnej encji/agregatu/vo.

Polityki - to nic innego jak Wzorzec Strategii. Enkapsulują zmienność/wariacje logiki biznesowej. Jest to kluczowa figura podczas modelowania i rozmowy z expertem biznesowym.

Zdarzenia biznesowe - chodzi po prostu o decoupling artefaktów biznesowych od technicznych obiektów obsługujących. Dodatkowo możemy mieć asynchroniczność.

Przykład agregatu: Zamówienie zawierające pozycje zamówienia:


@Entity
public class Order{
 @Id private OrderId id;
 @OneToMany private List<OrderItem> items = new ArrayList();
 private BigDecimal sum = new BigDecimal(0);
 //.... status, createDate, rebatePolicy, productRepository,...

 public void add(Product product, int quantity){
  OrderItem oi = orderItemFactory.build(product, quantity, rebatePolicy);
  //TODO jeżeli produkt jest już na liście to możemy jedynie zmienić ilość w odpowiednim order item
  items.add(oi);
  sum = sum.add(oi.getCost());
 }

 public void submit(){
  if (status != Status.NEW)
   throw new InvalidStateException();
  status = Status.IN_PROGRESS;
  createDate = new Date();
  eventsManager.handle(orderEventsFactory.orderSubmitted(this));
 }

 public Iterator<OrderItem> getOrderItems(){
  return items.iterator();
 }
}

Kod zawiera kilka charakterystycznych dla DDD konstrukcji.

lista produktów jest prywatna i nie ma do niej gettera a już niedopuszczalny jest setter. Dostęp do listy poprzez iterator, który nie umożliwia zmiany.
Pamiętajmy, że w JPA nie musimy uzywać getterów/setterów - wystarczy adnotacji na polu, wówczas ORM używa refeksji.
operacje biznesowe poprzez odpowiednie metody: add, submit
operacja add przyjmuje produkt - szczegółem impl jest tworzenie wewnątrz zamówienia jakiegoś OrderItem
operacja add zmienia wewnętrzny stan - co by było gdyby można było zmieniać listę udostępnioną getterem? Kto musiałby pamiętać o zmianie sumy?
operacja submit zmienia jakieś pola - jakie? to szczegół. Pojawią się nowe pola w encji Order - wówczas zmieniamy tylko metodę submit. Operacja dodatkowo może sprzeciwić się rzucając wyjątek oraz generuje darzenie.

"KŁOPOTLIWE" PYTANIE
Czy agregat/encja może wołać: repozytorium/servis/fabrykę?
Ogólnie: jakie zależności (pomiędzy czym a czym) są dozwolone w DDD?

Przyznam się, że sam miałem kiedyś tego typu pytania... Nie dawały mi spokoju: jakie są ograniczenia, co z czym można łączyć a co jest zabronione? Co gorsza, członkowie grup dyskusyjnych podawali sprzeczne "złote" zasady.

Zasada jest prosta: możesz robić wszystko co jest dobre dla modelu.
Wszystkie building blocks DDD są równo traktowane - nie ma ważnych i ważniejszych, mogą korzystać z siebie nawzajem jeżeli wynika to z logiki biznesu.

Dobre wyjaśnienie tego problemu znajdziecie w prezentacji Is Domain-Driven Design More than Entities and Repositories? Tak, tak - sarkastyczny tytuł oznacza, ze J. Nilsson będzie lekko kpił sobie z prymitywnych interpretacji DDD typu JavATE;)

Ale jak uniknąć kodu spaghetti w warstwie modelu domenowego jeżeli zaczniemy w nim łączyć wszystko ze wszystkim? Przecież DDD ma chronić nas przed chaosem a nie sprzyjać jego generowaniu.

Podczas COOLuarów doszliśmy do sformułowania dobrej zasady: Jeżeli z logiki biznesowej wynikają pewne powiązania to nie należy ich unikać. Jeżeli logika biznesowa charakteryzuje się pewnych poziomem złożoności - wynikającej z natury danego procesu, to nie unikniemy powiązań. Ważne aby nie wprowadzać dodatkowej złożoności (przypadkowej).

Dobrą metaforą warstwy logiki aplikacji jest scenariusz dla aktorów, którymi są Building blocks. Albo inaczej: kod logiki aplikacji niejako żongluje klockami biznesowymi. Chodzi o to aby czytać taki scenariusz i "widzieć" czystą logikę.
Więcej na ten temat w końcówce posta Understandability.

Jeżeli teraz jeden z aktorów nie chce pobrudzić się i wywołać np repozytorium to musimy zrobić to wprost w głównym wątku scenariusza (a wynik sztucznie przekazać gdzieś do środka aktora). Powoduje to pojawienie się sztucznych zgrzytów w scenariuszu. I zamiast ułatwiać zrozumienie go - utrudnia.

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

J. Nilsson twierdzi, że jest to typowe pytanie zadawane, przez każdego adepta DDD. Wg mnie taka jest kolej rzeczy - w każdej dziedzinie. Wynika to z modelu kompetencji braci Dreyfus gdzie na początku potrzebujemy dokładnych wytycznych jak zrobić. Później uczymy się, że to zależy od tego co chcemy osiągnąć.

MVC Revisited

2009-10-16T22:01:00.015+02:00

Kto w 2009r pisze jeszcze o MVC? Czy można jeszcze coś konstruktywnego dodać w tym temacie?

Spróbuję napisać coś może nie tyle konstruktywnego co porządkującego pojęcia... Doczytajcie do końca a być może dowiedzcie się czegoś co uzupełni wasz zasób ciekawostek służących do robienia wrażenia np na niewiastach podczas imprez;)

MVC - styl to architektoniczny odkryty bodajże jakieś 30 lat temu. Zatem należy mu się najpierw rys historyczny: jak to drzewiej wyglądało w Smalltalku...
Widok - czysty rendering
Kontroler - obsługa zdarzeń urządzeń sprzęgu ludzkiego (taki się kiedyś mówiło) typu klik myszką czy naciśnięcie klawisza
Model - dane do prezentacji i logika nimi manipulująca.

Jak to wygląda dziś? Weźmy na ten przykład 2 popularne technologie prezentacji w Javie:

SWING
Czym są kontrolki w Swingu... Widokiem? Nie do końca, ponieważ delegują rendering do rendererów. Sam np JButton jest reprezentacją jakiegoś bytu na GUI - posiada atrybuty typu położenie, ale rysowaniem zajmują się renderery wchodzące w skład aktualnego look&feel. Ale może nie wnikajmy w implementację i dla uproszczenie niech będzie to widok.

Kontrolki mają również swój wewnętrzny model "prezentacyjny". SetText przecież ustawia "coś" we wnętrzu kontrolki. Zwykle kopiujemy to coś z modelu właściwego budując własny framelet (nano framework) wokół Swinga. Ale sam rendering następuje na podstawie wewnętrznego modelu kontrolki.

Przyjrzyjmy się obsłudze zdarzeń... W Smaltalku zdarzenia techniczne obsługiwał kontroler. W Swingu robi to kontrolka, która deleguje odpowiedzialność do listenerów. Czyli to listenery są kontrolerem? Nie zawsze... w niektórych frameworkach Swingowych implementujemy własne kontrolery wołane przez listenery.

Więc co z tym MVC? Wygląda na to, że to kontrolka jako taka implementuje MVC (patrząc z technicznego punktu widzenia)

JSF
W JSF mamy Managed Beans... Obsługują one zdarzenia oraz decydują o nawigacji - czyli kontroler. Zawierają model do renderingu i zbierania danych z formularzy.

A co będzie, jeżeli zbindujemy jakieś kontrolki graficzne z ich komponentami UIComponent (będącymi polami Managed Beana)? Wówczas MB może sterować atrybutami kontrolek graficznych, czyli mamy logikę prezentacji, czyli widok. Znowu wszystko w jednym.

SZERSZY KONTEKST
Aby tego było mało spójrzmy na listę istniejących reifikacji (koncepcji realizacji) idei MVC zgromadzoną w tym oto poście: Interactive Application Architecture Patterns.

Na liście wiele ciekawych pozycji:
- Model-View-Presenter - w podejściu Microsoft (+ Application Controller) oraz Dolphin
- Supervising Controller
- Passive View Pattern
- Presentation-Abstraction-Control

Sam dodatkowo natknąłem się na:
- Hierarchical MVC (framework Scope, który przez parę miesięcy rozwijałem niezależnie od twórców, którzy porzucili coś tak pięknego;)
- MMVC (rozróżnienie na model prezentacyjny + model domenowy)

Wszystkie wymienione podejścia nazwami nawiązują do MVC, ale nim nie są w formie oryginalnej. Czy to źle? Oczywiście, że nie - MVC w swej oryginalnej formie nie przystaje do konstrukcji współczesnych bibliotek i zakładanego przez nie poziomu abstrakcji. Kto np dziś skupiałby się na szczegółach technicznych obsługi zdarzeń generowanych przez urządzenia.

WARSTWY
MVC jest często mylony z architekturą warstwową. Wystarczy zrobić prosty eksperyment myslowy aby uświadomić sobie błąd: zwizualizujmy sobie oba podejścia:
MVC wygląda jak trójkąt.
Natomiast warstwy są jak Ogry;) Albo raczej jak kanapka, tudzież tort.

MVC może być (i zwykle jest) użyty na szczycie stosu warstw jako wzorzec dla samej warstwy prezentacji. Natomiast pod spodem mamy "zwykłe" warstwy, które nic nie wiedzą o żadnym MVC w prezentacji.

W literaturze spotyka się jednak uproszczone podejścia, gdzie składniki trójkąta MVC utożsamiane są z warstwową architekturą, odpowiednio:
V - warstwa prezentacji
M - warstwa modelu (anemicznego najlpiej)
C - warstwa logiki aplikacji
Mówi się wówczas, że MVC jest traktowany jako wzorzec architektury aplikacji a nie jako wzorzec projektowy prezentacji.
Niech i tak będzie... ;)
Byle tylko nie twierdzić, że widok to HTML + CSS, kontroler to PHP a model to baza danych;P

//=================
Post powstał tak a'propos dzisiejszej prezentacji Marka Richardsa na JDD podczas, której wspomniał on o bezmyślnie przyjmowanych dogmatach:)

Domain Specific Query

2009-10-06T20:28:00.016+02:00

Zgodnie z obowiązującym trendem polegającym na prześciganiu się w publikowaniu bardziej lub jeszcze_bardziej oczywistych odkryć - dziś kolej na mnie i na coś na co wpadłem już jakiś czas temu.

Tytułowy wynalazek ma roboczą nazwę DSQ, którą triumfalnie nadałem mu kojarząc dwie modne techniki: Domain Specific Language i Command-query Separation.

NIEKRÓTKIE WYJAŚNIENIE
O CQS pisałem 2 miesiące temu w >tym< poście. W skrócie jest to styl architektoniczny, który zakłada separację API systemu na dwie wyraźne części. Jedna obsługuje (przyjmuje wysyłane do API) Command - rozkazy wykonania operacji. Druga natomiast obsługuje Query - obiekty specyfikujące kryteria pobierania/wyszukiwania danych.

W dzisiejszym poście skupimy się właśnie na tej drugiej części, czyli ogólnie mówiąc na wyszukiwarkach danych. Wyszukiwarki są dosyć proste - ot zwykłe servisy, pod którymi nie znajdują się już żadne kolejne warstwy - chyba, że potrzebujemy jeszcze "dodać coś od siebie" do pobranych z pewnego źródła danych.

DSL to koncepcja dużo bardziej popularna (w sensie ilości publikacji) niż CQS, więc nie będę się zbytnio rozpisywał na jej temat. Ogólnie rzecz ujmując chodzi o to aby kod logiki biznesowej czytać niemal jak język naturalny. Definiujemy sobie język zorientowany na konkretną domenę biznesową a później to już fraszka - program piszę się niemal sam;)
W statycznych językach typu Java nie mamy zbyt szerokiego pola do popisu jeżeli chodzi o zdefiniowanie własnego języka domenowego.

Jedyne co możemy zrobić w Javie to zastosować Fluent Interface i opisowe (samoopisujące wręcz) nazwy metod. Czyli jest to jedynie namiastka DSL, ale cieszy:)

Koncepcja Fluent Interface jest prosta: chodzi o to aby metody danej klasy zwracały instancję obiektu na rzecz którego zostały wykonane. Dzięki temu możemy zamiast pisać tradycyjnie:


Klasa obiekt = new Klasa();
obiekt.metoda1();
obiekt.metoda2();
obiekt.metoda3();

możemy zmienić styl na bardziej fluent:


Klasa obiekt = new Klasa();
obiekt.metoda1().metoda2().metoda3();

Jeżeli teraz zamiast nadawać metodom autystyczne nazwy (w stylu Bruce Eckela), wykażemy się odrobiną inwencji i słowiańskiej fantazji możemy pisać niemalże poetycko:


FabrykaWierszy.stworzUtwor().subtelny().zNutkaDekadencji().rymyNiechBedaCzestochowskie().strof(10);

Chyba lepiej czyta się kod w takim stylu...

DO RZECZY
Po tym przydługim wstępie powinniśmy już mniej więcej czuć czym jest CQS i DSL...

Wyobraźmy sobie następujący problem :

W systemie przechowujemy dokumenty. Dokumenty mają szereg atrybutów: kilka typów statusów (związanych z przepływem dok. jak i technicznych), różnego rodzaju daty, przypisanie do różnych zasobów itp.

Domena biznesowa standardowa i może niezbyt wyszukana, ale dzięki temu wiadomo o co chodzi i możemy skupić się na samej technice.

Serwis, który miałby wyszukiwać dokumenty musiałby mieć metodę o kilkunastu parametrach. Pierwszym problem z taką metodą to wysoki ujemny współczynnik czytalności. Drugi problem to ciągłe zmiany sygnatury metody gdy pojawiają się nowe atrybuty dokumentu.

Zatem dosyć oczywiste jest, że stworzymy sobie klasę przechowującą atrybuty wyszukiwania a nasz serwis będzie miał metodę, do której przekazujemy paczkę kryteriów - po prostu jakiś rodzaj Query z CQS:


public class SearchDocumentsQuery implements Serializable{
  //atrybuty wyszukiwania + get/set
}


public class DocumentsFinder{
public Collection<Document> search(SearchDocumentsQuery criteria){
//..
}

Jak do tej pory standard. (Query najpewniej będzie prędzej czy później serializowany.)

Teraz idąc dalej wg utartych szablonów dodalibyśmy do SearchDocumentsQuery kilkanaście pół prywatnych oraz oczywiście nasze ulubione gettery i settery.

Kod klasy klienckiej przy pomocy setterów ustawia kryteria wyszukiwania a kod metody DocumentsFinder.search przy pomocy getterów pobiera te parametry i klei sobie zapytanie w SQL, HQL tudzież mój ulubiony Hibernate Criteria API.

A gdzie miejsce dla DSL? No więc właśnie przy tak ordynarnym podejściu nie uświadczymy.
Załóżmy teraz, że chcemy hermetyzować kod klas klienckich (wywołujących DocumentsFinder)od szczegółów atrybutów Dokumentu.

Klient zamiast operować szczegółami:


SearchDocumentsQuery criteria = new SearchDocumentsQuery();
criteria.setStatus(Status.ACTIVE);
criteria.setCreateDate(...)
criteria.set...
...

Collection<Document> result = documentsFinder.search(criteria);

Wyraża jedynie intencje co do chęci otrzymania dokumentów spełniających zestaw określonych specyfikacji biznesowych:


SearchDocumentsQuery criteria = new SearchDocumentsQuery();
criteria.current().contains("lorem ipsum");

Collection<Document> result = documentsFinder.search(criteria);

Gdzie przykładowo metody DSL wyglądają mniej więcej tak:


public class SearchDocumentsQuery implements Serializable{
  private Status status;
  private Date epiryDate;
  private String[] titleWords;
  private String[] contentWords;

  public SearchDocumentsQuery current(){
    status = Status.ACTIVE;
    expiryDate = //data jutrzejsza
    return this;
  }

  public SearchDocumentsQuery contains(String phrase){
    String[] words = phrase.split(" ");//lub bardziej wyrafinowy split
    titleWords = words;
    contentWords = words;
    return this;
  }

}

Jak interpretować powyższe metody ustawiające kryteria:
current - oznacza, ze życzymy sobie dokumentów będących aktualnie w obiegu.
Co to znaczy od strony modelu: że maja określony status i że wygasają np najwcześniej jutro.

contains - oznacza, że dokument ma zawierać określoną frazę. Z punktu widzenia modelu oznacza to, że tytuł lub treść dokumentu zawiera wszystkie słowa frazy.

Cała idea polega na tym, że klient nie wie nic o polach status, expiryDate, words, ...
Klient wyraża intencję.

Natomiast pola te są dostępne przez gettery dla DocumentsFinder, który to analizuje je i odpowiedzi składa zapytanie. Aby osiągnąć pożądaną widoczność getterów należałoby zdefiniować SearchDocumentsQuery jako klasę statyczną wewnętrzną w DocumentsFinder. Wówczas DocumentsFinder będzie widział metody prywatne, bo takie powinny być rozważane gettery. Statyczną ponieważ chcemy tworzyć Query bez "wywodzenia" jej z instancji Findera.


public class DocumentsFinder{

  public static class SearchDocumentsQuery implements Serializable{
    private Status status;
    private Date epiryDate;
    private String[] titleWords;
    private String[] contentWords;

    //metoda contains i current - pominięto

    private Status getStatus(){
      return status;
    }
  }

  public Collection<Document> search(SearchDocumentsQuery criteria){
    if (criteria.getStatus() != null)//wywołanie prywatnej metody
       //dołożenie do zapytania warunku na status
    ...
  }
}

Kuszące może wydawać się dodanie do SearchDocumentsQuery metody buildEecutable(), która produkuje na podstawie stanu swoich wewnętrznych pól (statys, words,...) coś co można wykonać. Tym "czymś" może być PreparedStatement z JDBC, Criteria z Criteria API Hibenrate, Query z JPA, czy zwykły String zawierający SQL albo HQL.

Ale zastanówmy się: czy klasa, która jest widoczna przez klienta (np zdalnego) powinna mieć w sobie kod, który operuje na jakimś API np Hibernate (Criteria API) albo czy powinna wiedzieć coś o jakimś SQL? Przecież Finder może szukać w XMLu lub poprzez web service. Klient nie może tego wiedzieć - ba nie powinien.

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

Pomysł może mało odkrywczy i zapewne wiele osób wpadło na niego równolegle, ale jeszcze nie spotkałem nigdzie opisu.

Pomysł oczywiście nie będzie miał zastosowania w aplikacjach z małą abstrakcją pomiędzy bazą danych a GUI - tak zwanych przeglądarkach danych. W tego typu aplikacjach kontrolki na GUI (w tym pola filtrujące) odpowiadają zwykle niemal dosłownie kolumnom w bazie. W tego typu przypadkach próba abstrahowania od parametrów modelu jest niepotrzebnym uprawianiem dyscypliny pod tytułem nakładanie gaci przez głowę;)

Czekam na opinie, sugestie, krytykę - może być niekonstruktywna:)

Ktoś sprzątać musi aby bałaganić mógł ktoś

2009-09-09T19:27:00.021+02:00

Wszyscy zapewne pamiętamy burzliwą dyskusją Joela Spolskyego z Uncle Bobem (skrót na infoq)

Odbiła się ona szerokim echem dyskusji na ogólny temat: rzemiosło, profesja, jakość czy moźe lepiej byle jak, byle szybko, byle jako tako zadowolić klienta?

Kto ma rację?

Oczywiście ideałem byłoby dobrze i tanio. Ale jak intuicyjnie czujemy - tak to można tylko w mordę dostać;)

Prawda jak zwykle leży gdzieś po środku.

/*
* W rozważaniach pomijam specyficzne przypadki typu
* "firma nieustannie na dorobku"
* albo specyficzny rodzaj dostawcy
*
* Zakładam, że bawimy się w projektach perspektywicznych
* i jesteśmy świadomi zaciąganego kredytu bałaganu
*/

Ciekawą analizę tego zjawiska oraz racjonalne i pragmatyczne podejście do problemu przedstawił ostatnio w swojej genialnej (i jak zwykle niemiłosiernie ospałej) prezentacji sam guru DDD: Errrrrric Evaaaaans: Strategic Design - Responsibility Traps.

Poruszana tematyka zaczyna być omawiana od 30. minuty, ale gorąco wszystkich zachęcam do obejrzenia całości. Evans po mistrzowsku (i z typowym dla siebie poczuciem humoru) buduje od początku kontekst aby w 30. minucie wygarnąć nam co o nas myśli.
Wcześniej dowiecie się min. jakich strategicznych błędów nie popełniać podczas modernizacji systemu. Okazuje się, że standardowe 3 podejścia są z góry skazane na porażkę.

Prezentacja jest wg. mnie tak dobra, że w moim rankingu zajmuje miejsce 2. - zmieniając tym samym ostatnie notowania.

ZAŁOŻENIA (SAD BUT TRUE)
System jako całość nie może być dobrze przemyślany i zaprojektowany. KROPKA.
Nigdy nie będzie dostatecznie dużo: czasu, pieniędzy, wiedzy biznesowej, ludzi z odpowiednimi kwalifikacjami, czasu, pieniędzy, czasu, pieniędzy, czasu, pieniędzy,...

CO Z TEGO WYNIKA
Mamy 2 możliwości:
a) Wszystko zrobić "byle jak"
b) Pewną część zrobić porządnie i zgodnie z zasadami sztuki (oczywiście kosztem tego, że pozostała część będzie jakości mniejszej niż w punkcie a). W którą część i dlaczego warto zainwestować wysiłek - dowiemy się już za chwilę.

PROBLEM
Evans wytyka często spotykany problem. Ja nazwałbym go "złym rozłożeniem potencjału".
Evans opisuje taki oto często powtarzający się wzorzec: najlepsi (w sensie doświadczenia, intuicji, smaku a nie np certyfikatów) programiści/projektanci/architekci zajmują się tworzeniem tak zwanej "platformy". W zależności od systemu może to być wewnętrzny framework, główne biblioteki - ogólnie najczęściej są to jakieś zawiłości techniczne.

Natomiast reszta teamu - radośni hakierzy odpowiadają zwykle za dostarczanie corowych ficzerów biznesowych budowanych na bazie tejże tworzonej przez lokalnych guru platformy. Oczywiście ficzerów okraszonych zaokrąglonymi rogami w GUI - zgodnie z najnowszą modą żadna kanciasta forma nie jest dozwolona;)

Dostarczają oni funkcjonalności nazwanych przez Evansa sexy capabilities. Robią to tak jak potrafią, czyli byle jak byle szybko:)

Klient jest oczywiście zachwycony nowymi seksownymi możliwościami i nie zważa na marudzenie "nudziarzy od platformy", którzy narzekają, że znowu muszą sprzątać. Zresztą... po co sprzątać skoro działa?
Hero of the day to ten, kto zrobił zaokrąglony guzik zwiększający obroty o 1%;)

Oczywiście przyrost bałaganu jest większy niż możliwości jego sprzątania i mamy problem...

ROZWIĄZANIE: DESTYLACJA
Kto jak kto, ale my Słowianie mamy doświadczenie w destylacji więc mógłbym sobie odpuścić ten rozdział;)

Pomysł Evansa polega na wydestylowaniu domeny corowej. Zacznijmy od tego, że Evans wyróżnia 3 klasy domen:

- Core Domain - są to te specyficzne aspekty biznesu, będące powodem dla którego w ogóle warto tworzyć system. Przykładowo to one warunkują przewagę klienta nad konkurencją, lub odróżniają go od innych. To właśnie w tym miejscu mieszkają "sexy capabilities".

I to właśnie w ten kawałek (a powinien być relatywnie mały) inwestujemy największy wysiłek umysłowy.

To tutaj jest miejsce dla całej artylerii sprawdzonych technik naszego rzemiosła: szczegółowa analiza, archetypy biznesowe, wzorce projektowe, narzut na hermetyzację domeny, narzut na otwartość na rozbudowę, narzut na testability...

Core powinien być dobrze uniezależniony od pozostałych domen, które z definicji są w jakimś sensie "mniej godne zaufania" (bo np niestabilne).

- Supporting Domain - dodatkowe ficzery, bez których jednak można się obyć. Ten kawałek systemu może nawet np outsourceować. Jego jakość z założenia może być niska.

- Generic Domain - specyficzne domeny typu podsystem fakturowania lub biblioteka do operowania na grafach. Najlepiej kupić/uzyć gotowe rozwiązanie. Pamiętając o unikaniu zależności ze strony Core Domain.

Dobrym przykładem ilustrującym relatywizm tego pojęcia w zależności do biznesu jest system komentarzy użytkowników wystawianych kontrahentom.
W ebay jest to corowa funkcja (bez niej nikt nie kupiłby niczego od nieznajomej osoby). Dla amazona to po prostu jakiś poboczny ficzer (supportig domain) - ludzie i tak kupią jeżeli czegoś potrzebują lub po prostu mają ochotę.

Pamiętajmy, że developerzy nie są w stanie (ba, nie powinni) określić co należy a co nie do Core Domain w konkretnym przypadku danego klienta. Określenie Core Domain to jedna z głównych rzeczy, którą trzeba z niego wydusić;)

Chyba już domyślacie się jakie rozwiązanie sugeruje Evans...
Core Team zajmuje się Core Domain.
Najważniejsza część systemu ma szansę być zrobiona zgodnie ze sztuką a członkowie tego teamu zyskują uznanie jako dostawcy "sexy capabilities":)

Mam nadzieję, że moja recenzja/streszczenie zachęci Was (a szczególnie managerów) do poświęcenia godziny cennego czasu na prezentację Evansa.
Ciekaw jestem co sądzicie na temat tego podejścia - liczę na dyskusję równie owocną jak ta z przedostatniego posta:)

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

Prowokacyjnie dodam, że Joel Spolsky stosuje jednak strategię "klasyczną". Flagowe oprogramowanie w ofercie firmy Joela: Copilot (soft dla helpdesku pozwalający na zdalną pracę na maszynie "petenta") to nic innego jak nakładka na OpenSourceowy projekt na licencji GPL ;PPP

Czyli ni mniej ni więcej: ktoś zrobił platformę a partacze Joela dodali "sexy capabilities" - a biznes chyba się kręci:)

I jeszcze druga myśl, która mi się nasunęła: Nierzadko występują takie przypadki, gdy naprawdę doświadczony developer w ogóle nie interesuje się pewną domeną biznesową. Po prostu uważamy (niebezpodstawnie) za interesują mniej więcej w takim samym stopniu jak zeszłoroczny śnieg. Wolimy zamiast tego skupić się na rozwoju w kierunku technicznym z uwagi na jego ogólność wynikającą z abstrakcyjności. Nic na siłę, każdy powinien znaleźć sobie optymalne zainteresowania...

Anticorruption layer

2009-09-05T15:43:00.005+02:00

Dziś łikendowy post z serii geek humor.

W ostatnim poście wspomniałem o hermetyzacji modelu domenowego poprzez Anticorruption layer, z którą to komunikujemy się poprzez Command i Query i z której nie wyciekają Encje.

Zobaczmy jak Eric Evans zobrazował to zagadnienie w 14 rozdziale swej książki (strona 367):

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

Więcej tego typu humoru w ospałych prezentacjach Evansa.

Lazy loading w kontekście paradygmatu Command-query Separation

2009-09-03T20:28:00.022+02:00

ODŚWIEŻENIE KONTEKSTU

Kilka miesięcy temu popełniłem dwa posty na temat Lazy loadingu (wiem, że nie chce się Wam ich czytać więc streszczam):

Lazy Loading a sprawa wydajności - post traktujący ogólnie o drastycznym spadku wydajności w sytuacjach gdy LL jest stosowany w niewłaściwym momencie.

Chodzi głównie o klasyczny "n+1 Select problem", który potrafi totalnie zamulić system. W skrócie: problem pojawia się gdy pobieramy z EnityManagera/Sesji hibernate kolekcję a następnie iterujemy po niej i getterami pobieramy zagregowane obiekty. Wówczas do bazy wysyłane jest 1 zapytanie o kolekcję oraz dla każdego z jej n elementów koleje zapytania dociągające potrzebne obiekty.

Podobne schorzenie występuje gdy naiwnie ustawimy w mapowaniu FetchMode na EAGER.

DAO a sprawa Lazy Loading - post poruszający problem tak zwanej cieknącej abstrakcji, czyli "brudzenia" kodu logiki warstw wyższych szczegółami technicznymi typu zamknięta sesji persystencji.

Oczywiście mamy sprawdzony sposób na cieknącą abstrakcję - podejście Open Session in View (rozwiązanie w Springu np przez Mateusza Mirackiego). Niestety w tym przypadku łatwo dopuścić do opisanego powyżej "n+1 Select Problem". Ciekawe rozwiązanie z testowaniem ilości wysyłanych do bazy zapytań przy pomocy statystyk Hibernate zaproponował w komentarzu do mojego posta Milus.

CREDO

Od razu śpieszę wyjaśnić - żeby nie było, że jestem jakimś fanatycznym wrogiem Lazy loadingu czy ORM w ogólności. Wręcz przeciwnie, namiętnie go stosuję od 5 lat i uważam za bardzo wygodny młotek w większości sytuacji.

PROBLEM
Od czasu opublikowania tych postów dostałem kilka maili z zapytaniami o sposoby radzenia sobie z powyższymi problemami.

Pod postami wywiązały się też krótkie dyskusje prezentujące możliwe podejścia.

Właściwie to chodzi głównie o problemem z wydajnością, ponieważ filozoficzny problem cieknącej abstrakcji prawie nikogo nie boli. Nauczyliśmy się z nim żyć i raczej się nad nim nie zastanawiamy (na szczęście Jacek podziela moje rozterki).

PRAWDZIWY PROBLEM
Wg mnie prawdziwy problem leży w samym podejściu do dostępu do danych, czyli architekturze aplikacji. Problem polega na zbytnim uogólnieniu.

Tak samo traktujemy dwa diametralnie różnie rodzaje obiektów:
- obiekty domenowe, które wykonują operacje biznesowe (lub na których to wykonujemy modyfikacje w podejściu proceduralnym)
- dane "przekrojowe" potrzebne jedynie do prezentacji (np wyświetlenia na GUI) wycinka aktualnego stanu systemu

CQS
Teraz nadszedł wreszcie czas na przedstawienie tytułowego bohatera tego posta: zapomniany i zakurzony paradygmat: Command-query Separation.

Paradygmat tez zakłada, że system posiada "interfejs", przez który wysyłamy do niego polecenia oraz osobny, przez który odpytujemy o dane. Nigdy nie projektujemy operacji, które zarówno coś modyfikują jak i odczytują dane.

W jaki sposób możemy wykorzystać to podejście w systemach enterprise?
"Interfejsem" przez który klienty (nie klienci) komunikują się z systemem może być warstwa aplikacji. Cienka warstwa, która zajmuje się wszystkim, oprócz logiki biznesowej i dostępu do danych.

COMMAND
Ok, chcemy coś zrobić w systemie, wysyłamy do niego Polecenie. Tak jak wspomniałem "interfejsem" jest warstwa aplikacji "opublikowana" jako jakieś bezstanowe servisy lub obiekty stanowe - zależnie od wymagań.
Jeżeli klient wyśle do tej warstwy Command, wówczas pobiera ona z Repozytorium jakieś encje (lub agregaty w DDD). Dalej na encjach/agregatach uruchamiamy ich metody biznesowe - jeżeli bawimy się obiektowo, lub wywołujemy jakieś biznesowe servisy przekazując im jako parametry pobrane właśnie encje. Nic specjalnego, klasyczna architektura warstwowa.

Natomiast w tym właśnie przypadku - gdy wysyłamy do systemu Command mający zwykle na celu wykonanie jakiś operacji biznesowych - jak najbardziej możemy (ba powinniśmy) radośnie korzystać z Lazy loadingu. Jest to jak najbardziej właściwy moment ponieważ natura takich operacji jest zwykle taka, że pobieramy kilka obiektów, które wchodzą ze sobą w jakąś interakcję (lub władają nimi servisy). Rzeczone obiekty biznesowe ewentualnie potrzebują do wypełnienia swej biznesowej odpowiedzialności zagregowanych składników. Raczej nic złego się nie stanie, gdy zamiast 3 prostych zapytań do bazy wyślemy ich 5 czy nawet 10.
Czasem nawet będzie to bardziej wskazane niż join - zależy do natury danych.

Cała operacja wykonuje się w obrębie metody z warstwy aplikacji więc jest objęta transakcją i ma cały czas otwartą sesję persystencji więc nie martwimy się o wyjątki Lazy loadingu.

QUERY
Natomiast jeżeli do systemu trafia Query, czyli zapytanie o dane, to wówczas sprawa wygląda nieco inaczej...
Przede wszystkim warstwa aplikacji nie ma pod sobą warstwy z logiką (żadnych servisów biznesowych). Czy potrzebujecie abstrakcji dostępu do danych (DAO/Repozytorium)? Raczej nie zmienicie nigdy źródła danych. Nie ma sensu również testowanie jednostkowe "Finderów" aplikacyjnych z podmienionymi na mocki DAO. Czyli czyste pobieranie danych.

W mniej złożonych systemach możemy sobie pozwolić na zwrócenie encji w odpowiedzi na kwerendę.
W bardziej poważnych raczej nie możemy pozwolić sobie na ujawnianie klientom naszego modelu, więc zwrócimy jakiś Data Transfer Object (DTO). Hermetyzacja modelu to podstawa - dzięki temu może on ewoluować iteracyjnie bez obaw o zniweczenie pracy teamu dospawującego prezentację.

QUERY ZWRACAJĄCE ENCJE
Jeżeli zdecydujemy się na zwracanie encji to musimy uporać się z paroma problemami technicznymi:
- wydajność: zwykle scenariusz obsługi kwerendy to pobranie kolekcji danych. Wówczas mamy jak w banku opisany na wstępie "n+1 Select problem". Rozwiązanie jest bardzo proste - wystarczy się pofatygować i napisać zapytanie z klauzulą JOIN FETCH. Przykładowo SELECT p FROM Person p JOIN FETCH p.addresses - dzięki temu chciwie/łapczywie (nie wiem, na które rozkoszne tłumaczenie się zdecydować) pobierzemy osoby wraz z podciągniętymi adresami. Po prostu ORM wygeneruje SQLa z JOINem.

Niezbyt dobrym pomysłem jest ustawienie w mapowaniu powiązania obiektów z FetchMode.EAGER. Spowoduje ono, że zawsze wyciągając jeden obiekt pobierzemy jego "dziecko". Owszem są sytuacje, gdzie z kontekstu biznesowego takie podejście jest sensowne, ale zwykle stanowią zdecydowaną mniejszość. Zwykle w jednym Use Case zależy nam na pobraniu np osób z adresami a winnym adresy są zbędne.

Warto pamiętać, że domyślnie strategia EAGER obowiązuje dla powiązań wiele-jeden, jeden-jeden i warto ją wyłączać.

- Open Session in View - podejście to o ile jest wygodne to niestety pozwala łatwo zapomnieć o tym, że leniwie podciągamy jakieś dane. Po prostu istnieje niemała szansa, że na widoku odwołamy się do adresów osoby a w zapytaniu zapomnimy dopisać JOIN FETCH. Działa? Działa. Muli? W środowisku developerskim z małą ilością danych pewnie nie;P

- Ilość danych - zwykle Use Case gdzie do systemu trafia Query zakłada, że z bazy trzeba pobrać dane "przekrojowe". Czyli dane z wielu tabel, ale z każdej z nich interesuje nas zaledwie kilka kolumn. W małych systemach, gdzie warstwa GUI i warstwa aplikacji stoją na tej samej JVM będzie to w śmigać.

Ale nawet w takiej konfiguracji mamy problem z pobieraniem zbędnych danych. Przykładowo: gdy pobieramy z bazy np dokumenty aby jedynie wyświetlić ich listę (data, autor) a każdy z nich ma kolumnę przechowującą dziesiątki stron textu. Rozwiązaniem jest leniwe ładowanie pól - czyli ich nieładowanie:) W hibernate wymaga to poddanie skompilowanego bytecodu instrumentalizacji.

Innym podejściem może być zamapowanie tabeli przez kilka klas. Przykładowo DocumentFull, DocumentLight, itp... Jeżeli czujecie niesmak na myśl o mnożeniu bytów to nie jesteście sami.

Hibernate pozwala na pobieranie danych wprost do DTO. Tworzymy DTO szyte na miarę danego Use Case, a składnia wygląda tak:
SELECT new pakiet.KlasaDTO(pole1, pole2.podpole) FROM...
Oczywiście przy założeniu, że odpowiedni konstruktor istnieje.

QUERY ZWRACAJĄCE DTO
Jeżeli zdecydujemy się na zwracanie DTO to zapewne dlatego, że potrzebne dane są na tyle przekrojowe, że żaden zestaw encji nie modeluje ich sensownie (i optymalnie).
Innym powodem może być chęć hermetyzacji zmiennego modelu poza stabilną anticorruption layer. Warstwa zapobiegająca gniciu to pojęcie z DDD i ma pragmatyczny sens w nieco bardziej perspektywicznych projektach.

Poza tym możemy być dumni, że nawet nasza architektura wspiera Agile umożliwiając ewolucję modelu domenowego bez rujnowania wszystkiego dookoła:)

Częstym błędem w tym przypadku jest pobieranie z ORM encji a następnie przepakowywanie ich w DTO.
Nie tędy droga...

Pobierzmy tylko to co tak na prawdę jest potrzebne. Najprościej zrealizować to z użyciem wspomnianej konstrukcji Hibernate SELECT NEW. Jednak w złożonych systemach zwykle nieodzowny będzie co najmniej w paru jakiś szyty na miarę i zoptymalizowany SQL. Jakąś abstrakcją nad SQLem może być wówczas np iBATIS mapujący result na DTO.

Jak to zwykle bywa najlepsze będzie podejście hybrydowe. Tam gdzie możemy na to sobie pozwolić zwracamy w wyniku obsługi Query encje - zwiększając tym samym swą produktywność. Natomiast tam gdzie krytyczna jest wydajność lub specjalna struktura danych, zwracamy DTO.

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

Opisane powyżej aspekty wydajności związane z Lazy Loadingiem aplikują się do systemów każdej wielkości - szczególnie "n+1 Select problem". Natomiast rozwiązanie z CQS a szczególnie podejście gdzie zwracamy z kwerendy DTO jest bardziej pracochłonne, przez co aplikuje się do projektów bardziej perspektywicznych.

Ale czy jest sens tworzyć w JEE projekty inne niż perspektywiczne? Do prostych i szybkich zadań typu "przeglądarka do bazy" jest przecież Microsoft Access;P

Dzień bloggera

2009-08-31T21:01:00.008+02:00

Ktoś sobie wymyślił, że dzisiaj będzie światowy dzień blogerów. Ok, fajnie.

Aby jakoś uczcić ten niezwykły, magiczny i jedyny w roku dzień postanowiłem zarekomendować nowego bloga poświęconego Javie i IT ogólnie: Technology For Human

Co prawda z założenia blog ma zawierać solidne tutoriale dla początkujących, ale na ile znam autora, to nawet doświadczeni wyjadacze będą mogli dowiedzieć się czegoś nowego z każdego posta.

Autor postawił sobie za cel przekaz rzetelnej wiedzy popartej realistycznymi przykładami. Bez ściemy znanej z tandetnych tutoriali. Autor zapewnia, że przykłady będą pochodzić z placu boju.

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

Przyznam się, że sam miałem kiedyś w planie serię postów na temat własnej "skrzynki z narzędziami" - czyli kilku różnych kompletnych zestawów narzędzi developerskich oraz frameworków, które wykorzystałbym w przypadku problemu danej klasy. Niestety z braku czasu wciąż odkładam to zadanie. Ale na szczęście pojawiła się blog kolegi więc chyba sobie odpuszczę:)

Hasło na zakończenie tego magicznego i jedynego w roku dnia: Blog to zdrowie (a oto dowody tej tezy)

Jeszcze prostota czy może już prostactwo?

2009-08-26T22:55:00.003+02:00

Chyba każdy z nas zastanawiał się nad tym co takiego urzekło go w programowaniu, że wybrał właśnie to zajęcie. Co takiego przykuwa nas na długie godziny do komputera i powoduje, że zapominamy o zwyrodnieniach kręgów szyjnych i nadgarstków, o zakrzepach w żyłach głębokich,...

Niektórzy odpowiadają, że pociąga ich możliwość tworzenia i kreowania. Inni lubią mieć kontrolę i możliwość decydowania. Są też tacy, którzy pławią się w masochistycznej rozkoszy (choć nigdy się do tego nie przyznają) lawirowania pomiędzy ograniczeniami różnego rodzaju.

/*
*Przypadki gdy ktoś po prostu "miał Pascala na studiach"
*i przypadkiem został zatrudniony z jakiejś "łapanki"
*a później "tak już zostało" pominę w tych rozważaniach.
*/

Jest jednak jeden wzorzec, który powtarza się byt często aby go zignorować. Mianowicie - większość z nas podkreśla, że największą przyjemność sprawia poszukiwanie prostoty, elegancji i harmonii. Nasze umysły nieustannie poszukują zgrabnych modeli pewnych wycinków modelowanego świata. Nic nas tak nie cieszy jak elegancka i prosta forma.

Po tym przydługim wstępie czas przyznać się co sprowokowało mnie do napisania tego posta: prezentacja Jonathana Dahl Programming and Minimalism.

Szczerze polecam tą prezentację (to tylko ok pół godziny). Pomimo ogromnego stresu w jakim był prelegent jest to aktualnie prezentacja numer 2 na mojej liście prezentacji dla programistów. Wyprzedza ją tylko znakomita Developing Expertise: Herding Racehorses, Racing Sheep o której pisałem tu: The Unforgiven.

Jonathan Dahl dokonał czegoś niezwykłego i pięknego zarazem. Pokusił się o próbę syntezy zasad minimalistycznej prostoty, występujących w języku naturalnym, muzyce oraz programowaniu oczywiście. Szczególnie ciekawie brzmi część przedstawiająca przekrojowo sinusoidalne zmiany komplikacji w muzyce - począwszy od Mozarta a skończywszy na Punk Rocku:) Być może dowiecie się z niej dlaczego pewne gatunki muzyki Wam odpowiadają a innych kompletnie nie trawicie... wszystko zależy od preferowanego poziomu komplikacji "figur" akustycznych.

Ale wracając do kontekstu programistycznego... Prezentacja, którą się tak zachwycam traktuje o programowaniu stricte w dosyć zdawkowym wymiarze. Ot mamy jakąś funkcję w Ruby - pogańskim języku, którego nie rozumiem. Jedna jej wersja została upstrzona składnią, którą zna pewnie 5% programistów tegoż języka, natomiast druga (o identycznej funkcjonalności) zawiera prostego ifa. Wniosek: prostota w programowaniu to podstawa. Dziękujemy i do widzenia.

Chciałbym jednak rozwinąć ten temat, ponieważ z moich obserwacji wynika, że o ile wszyscy powtarzają jakoby prostota była ich świętym Graalem to samo pojęcie prostoty w programowaniu jest mocno rozmyte. Nieraz spotkałem się z sytuacją gdy pewien mniejszy lub większy kawałek kodu był oceniany jak majstersztyk lub kupa guano.

Od czego to zależy?
Nawet w tak dobrze zdefiniowanej domenie jak muzyka mamy sytuacje, gdy pewien utwór/twórca/gatunek/styl "się podoba" lub "się nie podoba". Klasycznym przykładem jest Chopin, którego się uwielbia albo nienawidzi:)
Odwołując się do wspomnianej wyżej prezentacji: zależy to od stopnia komplikacji i możliwości jej ogarnięcia przez odbiorcę. Pewne formy są zbyt banalne, pewne zbyt skomplikowane (wydają się wręcz chaotyczne) a pewne w sam raz nam odpowiadają.
Większość umysłów ścisłych jest jak inż. Mamoń - podoba im się to co już znają. Mechanizm jest prosty: znając jakiś wzorzec (utwór) wiemy czego się spodziewać w danej chwili i cieszymy się gdy słyszmy właśnie to czego się spodziewamy. Przypomnijcie sobie jak irytująca jest nagła zmiana kawałka albo różnego rodzaju zakłócenia;P

Wyobraźmy sobie przykładowy problem, którego rozwiązanie można zapisać w jednej klasie z jedną metodą, która ma powiedzmy 10 ekranów a na nich 100 ifów. Ktoś może powiedzieć, że jest to rozwiązanie najprostsze, ponieważ "wszystko po kolei widać", wystarczy się dobrze wczytać;)
Inne podejście może wymagać powiedzmy 5 interfejsów i 10 klas. Każda klasa zawiera parę linijek kodu. Ktoś może stwierdzić, że jest to rozwiązanie zbyt skomplikowane ponieważ aby zorientować się co się dzieje, "trzeba skakać po wielu plikach" i "nie widać całego przebiegu".

Kto ma rację? To oczywiście zależy od preferencji. Jedni wolą wiele prostych pudełek składających się na bardziej wyrafinowaną strukturę, inni będą preferować jedno pudło, w którym jakoś się połapią.

Aby nie szukać konkretnego przykładu zbyt daleko przyjrzyjmy się strumieniom w standardowej bibliotece Javy. Pamiętacie jeszcze swoje pierwsze z nimi spotkanie?;P Dziesiątki klas, jakieś interfejsy, pokręcone konstruktory. Pierwsza reakcja? Panika i odrzucenie. Ja chcę przecież tylko odczytać głupi tekst z pliku a to panie takie pokomplikowane.

Natomiast znając pewną ogólną zasadę - wzorzec dekoratora całość nagle okazuje się być piękna w swej prostocie. Trudno stwierdzić co cieszy bardziej: elegancja tego rozwiązania czy prostota używania i niezwykła łatwość składania złożonych strumieni.

//===========================
Problem prostoty nie jest jednowymiarowy. Nie zawsze problem polega jedynie na tym po prostu działało. Często musi jeszcze dać się zrozumieć, zmienić, rozbudować, skalować, optymalizować, itd. Wówczas kryteria prostoty i elegancji zmieniają wartości.

Bardzo łatwo wówczas pomylić szlachetną prostotę z pospolitym prostactwem. Linia pomiędzy nimi jest zwykle cienka.

Słynny cytat Einsteina "rzeczy powinny być tak proste jak to możliwe" niesie ze sobą na prawdę głębokie przesłanie...

Jakość (życia)

2009-07-05T15:33:00.009+02:00

Kolejna Javarsovia za nami.
Brawa dla organizatorów za profesjonalizm i samą inicjatywę. Podziękowania należą się też (a właściwie to przede wszystkim) prelegentom, którzy altruistycznie dzielili się wiedzą i doświadczeniem.

W stosunku do poprzedniego roku zauważam pozytywną zmianę patrząc na przekrój tematów. Zdecydowanie mniej onanizmu technicznego. Nowe zabawki nie rozwiązują problemów, oprócz tych, które same stwarzają. Stawiamy bardziej na profesję. To chyba znak, że idą zmiany w mentalności naszego comunity - zgodnie z nowym trendem: craftsmanship.

W większości prezentacji, w których uczestniczyłem pojawiała się idea jakości. Jakości rozumianej nie tylko jako atrybut produktu, ale przede wszystkim jako jakość naszej codziennej pracy.

Z jakością produktu bywa różnie - nie zawsze jest istotna. Klient nie jest świadomy - dla niego ma po prostu działać. Szef martwi się o harmonogram i budżet - o inne sprawy będziemy (będziecie;P) martwić się później. Biznes rządzi się swoimi prawami i to jest zrozumiałe.

Natomiast aspekt jakości rozumianej jako jakość codziennej pracy nad projektem IT to coś z goła innego. Chyba nikt nie lubi tego uczucia, gdy budzisz się rano, otwierasz oczy, patrzysz w sufit a pierwsza myśl jaka przychodzi do głowy na dobry początek nowego dnia to "k@#$%, nie po to studiowałem x lat żeby teraz wstawać rano, brać widły do ręki i przerzucać ten zgniły kod".

W wymiarze osobistym jakość codziennej pracy jest jedną z najważniejszych składowych jakości życia.

Chyba stąd u prelegentów, którzy swoje w życiu przerzucili, refleksje na tym co robić aby nie szarpać się w codziennej pracy. Krótka relacja z prelekcji, w których uczestniczyłem:

Randori TDD - Krzysztof Jelski - ciekawe podejście do developemntu. Randori w skrócie (i na ile udało mi się zrozumieć) polega na programowani w parach z rolą kierowcy i pilota. Kierowca programuje skupiając się na detalach podczas gdy pilot dba szerszą wizję.
Programowanie odbywa się w cyklach: najpierw test, działająca implementacja, refaktoryzacja do osiągnięcia jakości rozwiązania. Rozpoczęcie programowania od testu powoduje, że zastanawiamy się nad tym JAK nasza klasa będzie używana przez klasę-klienta.

Co prawda wymaga to zmiany mentalnej, ale spojrzenie z perspektywy klasy-klienta na prawdę się opłaca. Chyba każdy nie raz miał przykre uczucie niesmaku próbując wreszcie użyć swój super zestaw właśnie stworzonych klasek.
Przewiduję również wzrost produktywności - ciężko obijać się gdy siedzi ktoś obok nas;)

Wg mnie jest również doskonały sposób na efektywne przekazywanie wiedzy.
Najszybciej uczymy się przez naśladownictwo. Zjawisko to może zostać spotęgowane przez obecność eksperta, który na bieżąco wyjaśnia rozwiązania problemów i przesłanki stojące za wyborem danego podejścia. Najbardziej efektywnym i przynoszącym najlepsze rezultaty sposobem na wprowadzenie nowego członka do zespołu jest poświęcenie mu czasu na wspólne programowanie. Niemal naturalnie przejmuje on wówczas nawyki i dobre praktyki, których samodzielne wypracowanie zajmuje niejednokrotnie lata.

Drools Guvnor - Jarosław Kijanowski - tutaj aspekt jakości pracy nie był zbyt silnie uwypuklony. Może poza aluzjami do poziomu profesjonalizmu analityków;)
Na na podkreślenie zasługuje sama forma prelekcji: z jajem, bez stresu, ogólna idea-zaciekawienie-przykład. O to chodzi!

Praca z odziedziczonym kodem - Jakub Dziwisz przede wszystkim brawa na Jakuba (agiletuning) - profesjonalny prelegent z charyzmą i klasą. Praca z odziedziczonym kodem, hmm temat w sumie bardzo smutny;) Zaprezentowano techniki refaktoryzacji, mające na celu zmniejszenie bólu. Pamiętajmy jednak, że słaby kod to nie tylko problem przeszłości. On powstaje również tu i teraz zatem przedstawione techniki mogą mieć wykorzystanie w codziennej pracy. Podstawa to dobrze zrozumiany OOD, G.R.A.S.P i S.O.L.I.D oraz wzorce projektowe w granicach rozsądku.

Ewolucja Architektury - Paweł Lipiński. Paweł zaprezentował pragmatyczne podejście do architektury. Architektura - arcy ważny składnik procesu a z dyskusji uczestników widać było, że są różne sposoby rozumienia tego słowa. Przydało by się uporządkowanie pojęć: wskazania domen architektury (aplikacji, systemy, wdrożeniowa) oraz jasnego rozdzielenia architektury od projektowania.

Najważniejsza wg mnie myśl z prelekcji: architekci muszą programować. Jako architekt potwierdzam i podpisuję się pod zdaniem Pawła. Niestety aby móc powiedzieć coś sensownego na temat kształtu systemu trzeba ubabrać sobie rączki. Nie wystarczy mieć doświadczenia x lat temu, a już kuriozalna jest sytuacja gdy architekt może pochwalić się jedynie programikiem w Pascalu napisanym na studiach.

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

Prezentowane zagadnienia poruszyły część aspektów jakości (w sensie bezstresowej pracy) w całym procesie wytwarzania softu.
Do kompletu, jako uzupełnienie, dodałbym:
- Analizę biznesową - zrozumienie problemu klienta, zebranie wymagań
- Rzetelną analizę systemową - analiza to proces myślowy, włożenie wysiłku w uporządkowanie biznesu. Warto wesprzeć się sprawdzonymi rozwiązaniami, takimi jak Archetypy biznesowe. Niestety czasem jest to jedynie spisanie ton dokumentów zawierających nieprzetrawiony bełkot.
- Architektura - podczas prelekcji Pawła padło pytanie o przykłady architektur. Wszystko oczywiście zależy od konkretnego problemu Ja obecnie w nietrywialnych aplikacjach webowych stosuję modyfikowane do problemu architektury Distributed DDD oparte o Command-Query Separation.
- Projekt - Architektura narzuca ogólny styl projektowania. Aby uniknąć w niedalekiej przyszłości koszmaru utrzymania własnego kodu warto wspierać się technikami OO takimi jak SOLID czy GRASP.
Ale podstawa to w ogóle projektować zamiast rzucać się jak dzikus na klawiaturę i radośnie napieprzać;)

Ile Ci to zajmie? (różnice w postrzeganiu czasu)

2009-07-01T19:43:00.012+02:00

Niektóre filozofie zakładają, że czas nie istnieje. Jest tylko tu i teraz, upływ czasu to złudzenie. Inni z kolei chcą go wyginać i zaginać.

Ale zejdźmy na ziemię. W biznesie czas to tylko pieniądz. Stąd też najczęściej pojawiającym się pytaniem w komercyjnym procesie tworzenia softu jest nasze ulubione:

ILE CI TO ZAJMIE?

Managerowie uwielbiają zadręczać tym pytaniem swoich/swoje zasoby. Irytują się, gdy developerzy nie są w stanie odpowiedzieć na tak elementarne pytanie. Przecież jeżeli robi się coś od kilku lat to powinno dać się niemal co do godziny określić ilość potrzebnego czasu. Co za durnie, siedzą w tym po uszy i nie potrafią nawet zarządzać sobą, swoimi zadaniami i swoim czasem. Przecież programowanie jest prawie jak budowanie. Macie nawet te swoje wzorce pokrakowe (czy jakieś tam) oparte na latach doświadczeń budowlańców. Muszę mieć harmonogram i się z niego wywiązać. Budżet Panowie! Budżet!

Developerom z drugiej strony ciśnie się na usta "Nie wiem! Nigdy wcześniej tego nie robiłem!" - heh ale tylko Ci o mocnej pozycji w plemieniu mogą sobie pozwolić na zwerbalizowanie swoich myśli. Czy on nie rozumie, ze praca badawczo-rozwojowa (a taką właściwie jest każdy nowy projekt z uwagi na nowe narzędzia) nie jest liniowa a eksponencjalna. Stając w kopalni z kilofem w ręku, kilometr pod ziemią i fedrując na przodku nigdy nie wiadomo kiedy trafimy na skałę, ile będzie trwać stagnacja i kiedy pojawi się nagły wybuch ruszający wszystko do przodu. Programowanie to nie murowanie muru z cegieł (1 cegła na minutę = > mur z 1000 cegieł to 16.7 godziny) - to tak nie działa.

Jedni i drudzy mamroczą pod nosem: co za durnie!

Zagadnienie szacowania czasu, metodyki szacowania to temat na osobna bajkę, dziś będzie o postrzeganiu czasu.

Ale zanim przejdziemy do corowej warstwy posta, zatrzymajmy się na chwilę aby pokazać sceptykom, że postrzeganie czasu rzeczywiście jest względne i każdy doświadcza tego niemal codziennie (proszę nie uciekać od ekranów - względne w sensie poznawczym a nie w sensie teorii względności).

Pomijając filozoficzną i fizyczną naturę czasu, Twój mózg jest po prostu tak skonstruowany, że postrzega upływ czasu. Mamy wbudowane 2 "koprocesory czasu" - zegary dobowy i bieżący. Zegar bieżący opiera się na mechanizmie taktowania (tysiące neuronów) i próbkowania (neurony gwiaździste i piramidalne). Co ciekawe i istotne dla nas, hormony stresu zmieniają stężenie neuroprzekaźników w naszym "koprocesorze" czasu bieżącego co powoduje zmiany w "tykaniu" a co za tym idzie próbkowaniu bodźców ze świata.

Wszyscy znamy uczucie dłużenia się czasu lub odwrotne do niego - szybki upływ czasu. Jak się okazuje niem tu żadnej magii - wszystko zależy od poziomu hormonów stresu. Dzięki temu np w stresowej sytuacji na drodze mamy "gęste" próbkowanie świata, wchłaniamy więcej danych w jednostce czasu i mamy więcej "cykli" na podejmowanie działań związanym z uniknięciem zderzenia z jakimś durniem.

Przejdźmy do meritum, czyli czasu w kontekście IT.
W tym celu zostawmy poziom "techniczny" czyli neurony i przyjrzyjmy się ogólnym strategiom przeżywania czasu: Spontaniczny plan dnia.
Wynika z niego, że dysonans w podejściu do czasu i planowania jaki obserwujemy na różnych stanowiskach może wynikać z różnych sposobów myślenia o czasie. Tak, tak, wg tego modelu różnimy się wewnętrznymi reprezentacjami czasu!

Mamy zatem ludzi żyjących:
- W czasie (In time) - żyją chwilą, odczuwają każdy moment, bez planu i kontroli czasu, skupiają się na aktualnym działaniu
- Pomiędzy Czasem (Between Time) - w pozycji zdystansowanej do czasu, mają na niego ogólny ogląd, widzą możliwości działania, ale nie przypisują im czasu trwania, dowolnie przestawiają zadania
- Poprzez Czas (Through Time) - również z dystansem, ale mając ścisły chronologiczny plan, każde zdarzenie ma czas rozpoczęcia i czas trwania, czas jest linią o ograniczonej pojemności (w sumie logiczne;)

Autorzy artykułu zachęcają nas do trenowania różnych sposobów przeżywania czasu i dobierania najlepszego do danej sytuacji. Powodzenia.

Zastanawiam się czy można w ogóle być dobrym managerem nie żyjąc Poprzez Czas - widząc dokładny plan, zależności czasowe i być przez to cel-oriented?

Czy można w ogóle prowadzić jakąkolwiek kreatywną działalność (mam na myśli sensowną działalność a nie np malarstwo współczesne) nie żyjąc Pomiędzy Czasem - dostrzegając możliwości i potencjał.

A żyjąc chwilą W czasie lepiej chyba nie męczyć się z IT, rzucić to wszystko i rozpocząć karierę w biznesie porno;)

Każdy powinien zająć się tym w czym jest dobry. A szacunek to podstawa.

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

"Ty masz zegarek, ja mam czas"
...Usłyszał w odpowiedzi na nerwowe pokazywanie na cyferblat podróżnik, gdy usiłował ponaglić swego przewodnika na postoju, podczas wędrówki gdzieś, na andyjskim bezludziu.

Domain Driven Disaster

2009-06-05T16:09:00.007+02:00

Przygotowania do prezentacji o DDD na LJUG w toku. Tymczasem mamy niecodzienną okazję aby zobaczyć jak w praktyce możne wyglądać projekt, którego jednym ze szczytnych założeń było podążanie za DDD.

Dziś pierwszy (i mam nadzieję, że nie ostatni) post z gatunku gościnnych.

Jako pierwszego mamy zaszczyt gościć tajemniczego Malory z krainy deszczowców, który podzieli się doświadczeniami z dużego, zagranicznego projektu. Projektu, w którym niestety nieco rozminięto się z filozofią DDD, TDD i Agile:

<post_goscinny>
Przyjemność bycia częścią projektu napędzanego czystym agilem (iteracje mamy, lecz do Agile nadal daleka droga), z domieszką domain driven, test driven, i ogólnie driven skłonił do podzielenia się kilkoma refleksjami. Tym gościnnym postem u Sławka podzielę się refleksjami o dysonansie miedzy filozofią którą niosą ze sobą ddd, Agile, TDD a praktyką... czyli Projektem.

O ddd Sławek pisał tutaj już nie raz i każdy z czytelników mniej lub bardziej "czuje' o co w ddd chodzi. Esencja to słowa z ddd.org: "ddd is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains". Nic dodać, nic ująć. Koncepcja a raczej filozofia spojrzenia na problem, na domenę. A w praktyce? Bywa różnie. Brak zrozumienia idei którą niesie ze sobą ddd, i twarde (beton) myślenie przez pryzmat aplikacji CRUD driven (formularzyki), gwarantuje Monthego Pythona każdego dnia. Sam wybór ddd nie zawsze jest szczęśliwy bo jak wyraźnie wskazuje cytat: "complicated domain". Więc po co się męczyć, i udawać ddd gdy chcemy zrobić nakładkę na db? Efektem końcowym będzie i tak mieszanka anemicznych encji i a'la serwisów żonglujących encjami w górę i w dół. W praktyce ddd niebezpiecznie zbliża się do kilku „warstewek” klas delegujących wywołania metod z dao. I nie ma w tym nic złego – to rozwiązanie dobiera się do problemu. Nie odwrotnie. Sama sytuacja w której kończymy z pustymi encjami (@Entity, nie żadne tam encje ddd) i serwisami wskazuje że coś jest nie tak. Fundament OOD jest prosty – odpowiedzialność a get/set to chyba jednak trochę za mało...

Siłą napędową ddd to domena, co w odniesieniu do projektu oznacza eksperta domeny, będącego światłem w tunelu dla zespolu. Jako ze projekt nie zawsze ma domain eksperta - bywa śmiesznie. Developerzy to cwani ludzie i dadzą radę, ale to raczej Developer Driven Design (co oczywiście nie jest złe.. ale zależy od doświadczenia zespołu...). W przypadku bogatej domeny, bez pomocy eksperta wątpliwe jest stworzenie nawet poprawnych zrębów domeny, nie wspominając nawet o niuansach i bliższym nakreśleniu relacji w domenie. Pora teraz na agile (fonetyka naszego rodzimego języka, nie żaden tam edżajl).

Skomplikowana domena powoli ewoluuje, nieraz zamiast ewolucji doświadczyć możemy rewolucji, gdy powolny knowledge crunching zaowocuje przełomem w spojrzeniu na domenę. I czy nie jest to "Responding to change over following a plan" który niesie ze sobą agile manifesto? W tym momencie przypomina mi się pytanie podczas jednego z pierwszych spotkań (spotkanie a raczej meeting jest nieodzownym elementem każdego poważnego agile projektu), a mianowicie "kiedy dostaniemy skończony model domeny?". Hmm - odpowiedź była prosta: nigdy. Po czym zaczęło się wyjaśnianie (okraszone nerwowymi spojrzeniami "góry"), że to nie waterfall. Same iteracje nie sprawią, że będziemy Agile. Do tego potrzeba tzw. bigger picture i zmuszenie całego zespołu (łącznie z managementem) do innego spojrzenia na problem. Iteracje i milestony mogą być jednak wystarczającą dawką agilu. O tym, że to wymagania napędzają development niekoniecznie się pamięta. Zresztą, bywa w niektórych projektach że wymagania odpowiadają poziomem testom (assertTrue(true)); //FIX LATER, its friday, 4 o'clock ). Raz zrobiony task (zrobiony w stylu general concept, bo jak inaczej bez wymagań...) zostaje jako skończony i nie ma nawet mowy o refaktoringu pózniej... To przecież zbędne filozofowanie... W wyniku zostaje brązowa (flagowy kolor branży) papka kodu którą ktoś (nieszczęśnik, albo student, niewolnik IT) będzie miał przyjemność poprawiać. Domena zamiast ewoluować - kostnieje, zamiast odpowiadać na zmiany - napierdalamy aby zdążyć w terminie.

Ostatnim kawałkiem układanki jest TDD. Który doskonale wpasowuje się do mieszanki DDD i Agile. Domena powinna ewoluować, dojrzewać, i odpowiadać na zmiany. Tutaj pomocną rączkę wyciąga TDD. Pod warunkiem że napisane testy mają sens. W życiu bywa jednak rożnie, w praktyce testy nie zawsze testują. Mądrze napisane uspokajają sumienie i pozwalają pracować nad aplikacją. Pozwalają na eksperymentowanie i dają ujście wiedzy którą powoli team zdobywa. Testy trzeba jednak umieć pisać.. i mieć na nie czas. Z pierwszym bywa rożnie, na drugie niekoniecznie jest czas w schedule projektu. Efekt - każdy boi się panicznie dotknąć czegoś większego w domenie aby całość się nie rozleciała...

Na koniec link do doskonałej prezentacji o... samochodach. Obejrzyj i popatrz przez pryzmat naszej branży. Tutaj też są projektanci i inżynierowie. W tej branży jest miejsce na pasję, rzemiosło i jakość. Uwolnijmy się od brązu.

</post_goscinny>

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

Jak wiadomo najlepiej uczyć się na błędach:) Dobrze, gdy mamy okazję z dystansu przyjrzeć się cudzym:]
Potwierdzają się moje przemyślenia na temat metodyk Agile. Idea piękna, ale pod warunkiem, że mamy dojrzały i świadomy zespól profesjonalistów, którzy wiedzą co robią lub przynajmniej mogą poprowadzić duchowo resztę teamu.

Sama filozofia DDD o ile nie jest jakoś specjalnie wysublimowana to niestety posiada pewną barierę wejścia: podstawy OO - i nie mam tu na myśli składni dziedziczenia, lecz myślenie obiektami.

Nie ma rzeczy niemożliwych

2009-05-30T17:02:00.007+02:00

/*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:

Stare Chińskie przysłowie: Jest czas na pracę i jest czas na zbieranie ryżu

2009-05-29T20:43:00.010+02:00

Podobno to Hindusi odkryli system dziesiętny - Arabowie jedynie go rozpowszechnili (mając silne argumenty w dłoniach;).
Nieco mniej chlubnym osiągnięciem indyjskiej myśli jest na przykład biblioteka tagów JSP do integracji z JPA, na którą to niedawno przypadkiem się natknąłem. Zdaje się, że przyświeca jej motto "because we can!"

Stereotyp programisty Hindusa, który "nakłada gacie przez głowę" jest dosyć mocno rozpowszechniony i zakorzeniony ale wystrzegajmy się pychy.

Ciekawe studium hinduskiej mentalności znajdziemy w interesującej, lekkiej ale bardzo pouczającej książce Moja Praca Emigruje do Indii - A wszystko, co dostałem, to ta marna książka. Ale to tylko jeden z aspektów. Poznamy przede wszystkim globalne mechanizmy korporacyjne mające wpływ na niemal każdego z branży IT.

Chad Fowler zabiera nas w egotyczną podróż do Bangladuru, gdzie spędził 1.5 roku tworząc Software House dla jednej z amerykańskich korporacji.

Poznamy szereg kuriozów:
- na ogłoszenie o pracę odpowiada średnio kilkanaście tysięcy chętnych
- a mimo niemałego budżetu nie można sobie pozwolić na tych doświadczonych
- taksówkarz zna 5 języków
- a programista nie ma własnego komputera w domu

Każdy z 52 zgrabnych i wyważonych rozdziałów niesie w sobie pewien morał. Lokalny folklor jest jedynie pretekstem do przekazania metafory lub przesłania. Dostajemy zestaw gotowych strategii, uwag, ostrzeżeń i porad z zakresu szeroko pojętego samorozwoju i autopromocji. Kto się nie rozwija ten się cofa a zmiany są nieuniknione.

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

Wymowa książki w naszym lokalnym kontekście nabiera jednak drugiego dna. Nie musimy obawiać się emigracji naszej pracy do Indii. Być może jesteśmy Indiami Europy:P

Understandability

2009-05-23T18:40:00.013+02:00

Understandability - ostatnio modny termin. Znak, że oto kolejne pokolenie programistów/developerów/inżynierów oprogramowania (byle nie "informatyków"!) dorosło do przepoczwarzenia. Z kał-bojów i szambe-lanów babrzących się w cudzych (tudzież własnych) klasach z archiwum X chcieliby stać się szczęśliwymi profesjonalistami wiodącymi szczęśliwe życie wśród łatwych, prostych i przyjemnych linijek kodu.

Komentarze


#define TRUE FALSE
//Happy debugging suckers

Stara szkoła mówi aby 70% tekstu stanowiły komentarze. Tak aby po hipotetycznym usunięciu kodu można było go łatwo odtworzyć na podstawie ich treści.
W praktyce oczywiście nie ma czasu na twórczość o tej skali - zarówno podczas tworzenia jak i utrzymywania kodu. Poza tym wydaje mi się, że takie podejście zmienia niewiele:
- pisanie dobrych komentarzy jest sztuką jeszcze większą niż pisanie dobrego kodu (o czym dalej) - więc wiadomo czego możemy się spodziewać
- komentarz daje nam jedynie bardzo lokalny obraz sytuacji, aby uchwycić tak zwany biger pikczer potrzeba zdecydowanie czegoś więcej...

Ileż to razy bierzemy jakąś bibliotekę/framework (załóżmy, że rzetelnie okomentowane) i niestety nie możemy połapać się w gąszczu dziesiątek/setek klas. Przydałby się jakiś wizualny standard prezentowania ogólnej architektury konceptu. Pomocny byłby już choćby jakiś sposób uwypuklenia zastosowanych wzorców projektowych/architektonicznych.

Owszem jakimś rozwiązaniem jest narzędzie do reverse engineering, przy pomocy którego możemy sobie wygenerować UML. Ale co mi po gąszczu prostokątów jeżeli nie wiem, które są istotne, które stanowią core konceptu, a które jedynie szczegóły impl.

Kod samokomentujący się
Skoro i tak muszę pracować z kodem to fajnie byłoby gdyby był intuicyjny. Niedoścignionym wzorem na tym polu jest:
Epopeja poświęcona poziomowi inteligencji dzielnego Ryśka - spisana w tej oto abstrakcyjnej klasie RichardIsAFuckingIdiotControl.

To mój styl - nauczyłem się go analizując źródła Springa. Nie boję się opisowych nazewników klas czy metod mających po 30, nawet 50 znaków. To nie czasy dyskietek, gdzie od ilości literek zależało czy musimy żonglować nośnikami aby skompilować projekt.

Oczywiście gdy z sygnatury metody nie mogę wywnioskować co ona robi to nie powinienem zaglądać do środka - komentarz jest jak najbardziej wymagany.

W tym przypadku, podobnie jak w poprzednim również mamy problem z ogarnięciem ogólnej idei rozwiązania. Jednak niektórzy porządni rzemieślnicy zostawiają czasem wskazówki w nazwach - przykładowo przyrostki wskazujące na zastosowany wzorzec: xxxCommand, xxxStrategy, itp.

Zbiorowa inteligencja
Niektórzy postulują jakoby dobry kod to taki, gdzie czytamy to czego właśnie w tym miejscu się spodziewamy. W sumie trudno się nie zgodzić - pycha pomysł. Niestety utopijny ponieważ każdy programista jest inny. Każdy ma swój styl (albo i nie - o tym na koniec) i smak. Nie zapominajmy, że zawodnicy w teamie mają różne poziomy skillsów.

Oczywiście w różnorodności siła, ale świadczy to też o braku profesji w naszym fachu, braku elementarnych zasad rzemiosła - jesteśmy bandą indywidualistów (ale to temat na następnego posta).

Czas to pieniądz
Dobra metoda, to taka gdzie zrozumienie co i jak ona robi zajmuje nie więcej niż 5 minut - to jedno z częściej powtarzanych haseł. Miara równie rozmyta jak poprzednia. To co będzie oczywiste dla kodera turbo-ninja z silnym autyzmem, który w jednej półkuli kompiluje kod do rozkazów maszynowych nie będzie już takie dla studenta zarabiającego na piwko w PHP.

Z trochę innej strony...
Nierzadko spotkam się z sytuacją, w której programista nie wie jak nazwać klasę, metodę czy instancję. Albo nazwy pakietów - czy nie powinny wskazywać na "uporządkowanie myśli" i odzwierciedlać architekturę aplikacji? Niby szczegół prawda? Ot po prostu nie mam dziś weny. Zresztą co to za różnica? Kompilatorowi przecież jest wszytko jedno. Nazwę sobie Manager5, doStuff(String param1, String param2) albo x7.

Jest to jednak niepokojący syndrom - i mam tu na myśli coś gorszego niż rak mózgu;)

Ale żeby nie było, że sobie coś ubzdurałem, podeprę się najpierw autorytetem paru guru z naszej branży aby nie stać na grząskim gruncie własnych urojeń.

W 2006 r. niejaki Jarosław Rzeszótko znany również pod zabarwionym perwersją pseudonimem artystycznym "sztywny" wpadł na ciekawy pomysł. Zadał 9 (w większości) znamienitym programistom 10 pytań: Stiff asks, great programmers answer.

Ciekawych odpowiedzi udzielili panowie na pytanie:
"What do you think is the most important skill every programmer should posses?"
Istotne okazują się zdolności "miękkie", min: komunikacyjne, pisarskie, muzyczne.
Ciekawą - bo niemal ocierającą się o neuropsychologię;) - odpowiedź dał Dave Thomas:

I _have_ seen a strong correlation between people who have some music in their background and programming skills. I have no idea why, but I suspect that some of the areas of the brain that make someone musical also make them good at software development.

Linus Torvalds dla odmiany stawia na poczucie "smaku".

Do czego porównać kod, który będzie samoopisujący się, którego zrozumienie nie wymaga zbyt wiele czasu - ba, wręczy czytamy to czego się spodziewamy?
Dla mnie taki kod jest jak powieść. Kreujemy aktorów (klasy) o pewnych cechach osobowości (metody). Niektórzy są dwulicowi (interfejsy). Budujemy scenografię (warstwy, moduły) gdzie będzie rozgrywać się akcja. Nie jakieś śmietnisko, ale dobrze zorganizowany kompleks spójnych budowli. Dalej nie pozostaje już nic innego jak opowiedzenie ich historii, począwszy od stworzenia poprzez ew. reinkarnacje;) Bez zbędnych dygresji i wnikania w poboczne wątki - te nich dzieją się we wszechświatach równoległych dostępnych przez portale mangerów zdarzeń.

Werbalizowanie historii może wydawać się bzdurne, ale zastanówmy się co nam daje. Aby np zbudować metaforę musimy włożyć pewien wysiłek umysłowy. Wypowiedzi w języku naturalnym są obłożone szeregiem ograniczeń - szczególnie ważne są ograniczenia logiczne. Dzięki nim możemy wychwycić luki w naszym rozumowaniu, pokraczne modele, cieknące abstrakcje. Ograniczenia werbalne pomagają w ogarnięciu chaosu. Można je nazwać nieformalnymi regułami walidacji poprawności koncepcji.

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

Ktoś kiedyś napisał, że programistów można podzielić na 3 grupy. Tych, który mają dobry styl, tych który mają zły styl i tych, którzy w ogóle stylu nie mają.
Ci drudzy nie są jeszcze straceni. Co prawda ich poczucie stylu jest złe, ale przynajmniej jakieś jest - przy pewnym wysiłku można je zmienić na dobre. Najgorsi są Ci, którzy w ogóle nie rozpatrują czegoś takiego jak styl - jest to poza ich zakresem pojmowania. Ci są straceni.

Risercz: DDD

2009-05-14T19:29:00.016+02:00

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...

Lazy Loading a sprawa wydajności

2009-04-20T00:10:00.014+02:00

Podążając za ciągiem skojarzeń: od przedwczorajszego DAO przez wczorajsze Lazy Loading dziś czas na aspekt wydajności podczas korzystania z maperów relacyjno-obiektowych. Właściwie to główne niebezpieczeństwo tkwi w tytułowym Lazy Loadingu.

Sprawa jest w sumie prosta - trzeba uważać co się robi i mniej więcej orientować się jak działa mapper. Nie trzeba wnikać nawet w aspekty implementacyjne Lazy Loadingu: klasy pośredników, które mogą być podstawiane do encji czy to poprzez manipulację byte codem czy w czasie generowania kodu źródłowego (jednak zainteresowanym polecam zgłębienie tematu - warto wiedzieć "jak oni to zrobili").

Niestety na żadnej ze stron domowych maperów zgodnych z JPA (Hibernate, OpenJPA, Kodo, TopLink) nie dopatrzymy się ani na głównej stronie, ani na żadnej innej wielkiego czerwonego napisu "UWAGA NA WYDAJNOŚĆ PODCZAS STOSOWANIA LAZY LOADING!". Nie uraczymy również zestawu paru prostych porad, które uchroniły by nas przed dramatycznym spadkiem wydajności. Czyżby nie wyglądało to zbyt marketingowo? Może autorzy sądzą, że ludzie tego nie zauważą i jakoś to będzie - kolejny bubel się przyjmie w społeczności:)

Problem wydajności jest stary jak Hibernate ale niestety jeszcze nie wszędzie uświadomiony. Jako przykład podam tę oto przypowieść.

Niezbyt_dawno, niezbyt_dawno temu w pewnej dużej organizacji strasznie mulił system wykorzystujący Hibernate. Ludzie ze swą wrodzoną skłonnością do tworzenia mitów szybko poradzili sobie z dysonansem poznawczym trapiącym ich mózgi: stworzyli sobie prosty system mitologiczny, który nakazywał im wierzyć, że ORMy tak po prostu mają. Po prostu ich magiczne właściwości powodują, że systemy spowalniają a odczyt danych z bazy jest hamowany jakąś niepojętą siłą. Ciemnotę dodatkowo potęgowała Kasta Adminów Baz Danych, mówiąc: "tak oto kończy się sprzeniewierzanie prastarej składni SQL. Nie chciało się wam niewierni pisać procedur i kwerend to teraz sczeźnijcie w piekle!".

Po wstępnych oględzinach okazało się, że w większości przypadków obarczonych bardzo niską wydajnością mamy do czynienia z klasycznym problemem występującym w ORMach z Lazy Loadingiem: n+1 Select Problem.

Istotę problemy wyjaśnię na przykładzie: Wyobraźmy sobie, że pobieramy listę obiektów klasy Person. Następnie iterujemy po tej liście i dla każdej osoby wołamy getAddresses() po to aby coś tam z adresami każdej z osób zrobić. Jeżeli zapytanie wygląda mniej więcej tak: SELECT p FROM Person p to mam rzeczony problem. Najpierw silnik persystencji wysyła do bazy jedno zapytanie w celu pobrania listy osób. Następnie dla każdej z n osób wysyła zapytanie o jej adresy. W sumie n+1 zapytań:) Pięknie nieprawdaż? Niestety musimy pofatygować się i napisać porządne zapytanie HQL (lub odpowiednie Criteria w Hibernate), które spowoduje dodżojnowanie adresów do osób tak aby wysłane zostało do bazy jedno zapytanie SQL. Niestety nieodzowne będzie dopisanie w HQL paru JOIN FETCH - a co za tym idzie korzystanie z Entity Managera przestaje być takie trywialne jak w tutorialach, pojawia się złożoność, którą warto hermetyzować w DAO/Repozytorium.

Należy uważać również na "utajony" wariant n+1 select problem. W powyższym przykładzie mamy sytuację, w której radośnie iterujemy sobie przy pomocy własnego kodu po osobach i grzebiemy w ich adresach. Może być też tak, że nasz własny kod jest OK, ale niefortunnie podepniemy naszą listę osób pod np jakiś komponent GUI (np h:dataTable w JSF), który ma wyświetlić osoby wraz z adresami i nieszczęście gotowe. Logika renderingu tabelki przeiteruje po osobach aby wyrenderować jej adresy. Wówczas mogą zdarzyć się 2 rzeczy:
- aplikacja się wywali z powodu LazyInitializastionException (lub jakiegoś innego wyjątku w zależności od dostawcy JPA - co zresztą uważam za skandaliczne) ponieważ najpewniej w warstwie widoku sesja będzie już dawno zamknięta
- jeżeli jednak stosujemy jakiś trik typu Open Session In View to wówczas ORM radośnie wygeneruje nam n+1 zapytań do bazy:)))

Pierwszy wariant (wyjątek) jest o tyle dobry, że przynajmniej zwróci czyjąś uwagę podczas devlopmentu i skłoni do napisania porządnego zapytania, które ładuje wszystkie dane w jednym podejściu. Drugi wariant działa więc jest szansa, że nitk nie sprawdzi co się dzieje po stronie bazy:/

Kolejna przypowieść. W tejże samej organizacji istniał inny system, który również niemiłosiernie mulił. Tym razem był to gruby klient do serwera więc lazy loading nie miał zastosowania. Encje przesłane na klienta nijak nie chcą nawiązać kwantowego kanału z procesorem serwera:/ W tym systemie również panowała mitologia. Kiedyś pewien magik podobno zrobił czary mary i LazyInitalizationException nie pojawiał się gdy na kliencie wołano łańcuszki get get get.

Po krótkiej analizie problemu okazało się, że tym razem przedobrzono w inną stronę. Prawie wszystkie powiązania pomiędzy obiektami były EAGER - czyli chciwe lub jak kto woli łapczywe. Skutkowało wyciąganiem połowy bazy przy każdym zapytaniu. O ile serwer bazodanowy dawał radę to wąskim gardłem okazała się transmisja zserializowanych danych. Wniosek znowu ten sam: niestety na skróty się nie da - trzeba się pofatygować i napisać porządne zapytania specyfikując co w jakim Use Case ma być podciągnięte. Niestety zakorzeniona mitologia i szargana opinia o ORMach pozostanie w organizacji na parę następnych pokoleń.

Przy okazji warto wspomnieć o kolejnej pułapce jaką szykuje na nas maper. Uwaga na powiązania typu n-1 lub 1-1 - czyli takie gdzie w klasie encji mamy pole klasy innej encji (np Person ma jeden Adres). Standard JPA zakłada, że wówczas powiązanie jest typu EAGER. Czyli pobierając z bazy osobę zawsze od razu wyciągniemy jej adres. Niestety odbywa się to zazwyczaj w osobnym zapytaniu. Czyli w przypadku pobierania listy osób mamy n+1 Select Problem:)

Żeby nie było, Lazy Loading może również przydać się w celu optymalizacji systemu.
Wyobraźmy sobie taki przypadek: Mamy klasę dokument, która zawiera szereg pół - w tym pole zawierając treść dokumentu: kilkadziesiąt stron A4 (pomińmy kwestię sensowności takiego projektu). Gdy chcemy zaprezentować listę dokumentów na GUI, która zawiera dajmy na to tytuł i datę to oczywiście zupełnie niepotrzebnie będziemy pobierać z bazy i przechowywać w aplikacji (choćby chwilowo) dziesiątki megabajtów tekstu. Jednym z paru rozwiązań ale najprostszym jest ustawienie leniwego ładowania kolumny z treścią. Gdy nie będzie potrzebne wówczas nie będzie ładowane z bazy.

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

Podstawą pracy z ORM jest konsola z logami. Podczas developmentu należy włączyć wyświetlanie generowanych poleceń SQL i nieustannie obserwować oczami swymi logi silnika ORM czy przypadkiem nie pojawia się na niej w pewnym momencie kilka/-dziesiąt/-set/-tysięcy zapytań. Oczywiście n+1 Select Problem możemy zauważyć na konsoli praktycznie tylko wówczas gdy napełnimy bazę większą ilością danych. Dla n=1 problemu raczej nie uraczymy.

W dobrym procesie produkcji softu jest czas na takie coś jak kontrola kodu - przeglądanie nowego kodu przez bardziej doświadczonych członków teamu (lub chociaż przez drugą parę oczu). Co powiecie na kontrolę konsoli? Pokaż misiu jakie zapytania do bazy generuje Twój kod.

Podsumowując dwie przytoczone przypowieści pozwolę sobie zacytować Franka Zappa: "Głupota ma pewien urok, ignorancja nie".

DAO a sprawa Lazy Loading

2009-04-19T16:03:00.011+02:00

Wracając do wczorajszego tematu DAO rozwinę nieco kontekst mapowania relacyjno-obiektowego na przykładzie standardu JPA. Dokładnie - skupię się na głównym ficzerze każdego mapera zgodnego z JPA, czyli tytułowym leniwym (opóźnionym) ładowaniem zagregowanych w encji obiektów.

Niektórzy pewnie zastanawiają się czego znowu ten zgred się czepia. Przecież LL to taki fajny ficzer. Mamy sobie załadowany z bazy obiekt (i jeżeli sesja kontekstu perzystencji nie została zamknięta) to wystarczy zawołać na nim getXXX(), czary mary i pobrany przez getter zagregowany obiekt został podciągnięty z bazy oraz zapakowany do encji.

Wszystko fajnie, ale jeżeli korzysta się z tego z świadomie i w odpowiednim momencie. W przeciwnym wypadku mamy spore problemy z wydajnością. Ale o tym za w następnym poście. Ja mam z tym jeszcze pewien problem natury filozoficznej, który pojawia się gdy do naszej architektury wprowadzimy warstwę DAO (bez której jak bez ręki - co chciałem wczoraj wykazać)...

Zatem weźmy przykładowy interfejs DAO:


public interface PersonDAO{
  Person getPerson(Long id);
}

Standard... zwykłe DAO (nie czas teraz na Repozytorium z DDD), zwykły klucz (nie czas teraz na UID czy klasę kluczą w dobrym stylu DDD).

Dalej będzie oczywiście jedna z możliwych implementacji w JPA:


public class JpaPersonDAO implements PersonDAO{
  EntityManager em;
  Person getPerson(Long id){
    return (Person)em.find(Person.class, id);
  }
  ...
}

Też standard, bez żadnego generic DAO czy innych klas bazowych, bez wnikania w szczegóły wstrzykiwania EM. Nie w tym rzecz, chodzi tak jak wspomniałem o problem natury filozoficznej, mianowicie:
Co ja mam napisać w komentarzu metody getPerson() w interfejsie? (i od razy mówię, że banał typu "return returns person that has ID relevant do given id" mnie nie zadowala)

Aby w komentarzu napisać prawdę, całą prawdę i tylko prawdę musiałbym popełnić coś takiego (po polsku będę komentarz pisał - wybaczcie):

"
Metoda zwraca osobę o zadanym ID. Drogi programisto-użytkowniku klas implmentujących ten interfejs, wiedz ,że niniejszy interfejs zawirea z tobą kontrakt o następujących warunkach:
1. O ile korzystasz z implementacji DAO opartej o JPA to możesz się spodziewać tego, że:

1.a Niektóre klasy obiektów zagregowanych w zwróconej instancji osoby zostaną zastąpione przez klasy specyficznych pośredników (np PersistentBag w hibernate) więc niniejszy interfejs nie może zagwarantować Ci poprawnej pracy w środowisku rozproszonym (np aby wynik działa tej metody przesłać na zdalnego klienta musisz mu zapewnić odpowiednie biblioteki w odpowiednich wersjach).

1.b Być może masz dostęp do obiektów zagregowanych w zwróconej instancji. Na przykład do adresu (przez metodę getAddress). Zależy to od tego czy znajdujesz się w miejscu, w którym jeszcze obowiązuje sesja kontekstu persystencji. Jeżeli sesja będzie zamknięta, a ty będziesz brzydko się bawił z instancją person to dostaniesz np LazyInitializationException - ale tego w tym momencie nie mogę zagwarantować, gdyż zależy to od dostawcy (specyfiakcja JPA nic nie narzuca w temacie reagowania na zamkniętą sesję). Niestety niniejszy interfejs jest czystą abstrakcją dostępu do danych i nie mogę Ci zdradzić szczegółu na jakim dostawcy JAP będzie oparta implementacja tego interfejsu.

2. Jeżeli implementacja tego interfejsu nie będzie oparta o JPA (a np o dostęp do web service albo pliku XML) to wiedz, że dostępu do żadnych zagregowanych obiektów nie masz.

return osoba o zadanym ID, z którą ni cholery nie wiadomo co można na 100% bezpiecznie zrobić.
"

Ogólnie chodzi mi o to, że staroświeckie DAO i nowoczesny mechanizm Lazy Loadingu mają się nijak do siebie.

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

Mamy tu do czynienia z bardziej ogólnym problemem: przeciekającą abstrakcją. Szczegóły techniczne mappera relacyjno-obiektowego (takie jak lazy loading, problem z wygasłą sesją) literalnie wyciekają z interfejsu DAO, który powinien być czystą abstrakcją dostępu do danych niezależną od jakiś maperów. Innymi słowy klient (kod) interfejsu DAO musi być niestety świadomy pewnych "wyciekających" mechanizmów stojących za jedną z jego implementacji. Nie może jej traktować jako czarnej skrzynki, która robi to co ma robić - i robi to dobrze.

DAO

2009-04-18T19:26:00.011+02:00

Jak donoszą brukowce DAO odeszło i zostało zastąpione przez JPA. Czy aby na pewno?

Piotrek w swym poście (będącym niezłym zbiorem argumentów w dyskusji) wyraził zdziwienie pojawiającymi się od pewnego czasu głosami przeciwko DAO. Natomiast ja chciałbym dodać od siebie dodatkowo nieco typowej dla siebie irytacji spowodowanej wąskim spojrzeniem na problem pojawiającym się w głosach autorytetów z wielkiego świata.

Problem potrzeby lub nie warstwy DAO nie jest oczywisty i zależy od kontekstu. Czasem DAO jest niezastąpione a czasem może lekko przeszkadzać. Ale na pewno pozbawione kontekstu autorytarne głosy typu "DAO bad" są bez sensu.

DAO ma na celu separację logiki dostępu do danych od logiki biznesowej/aplikacji.
Co nam to daje?
Szeroką i sensowną listę podał Mario Gleichmann w swoim poście.

Ja ograniczę się do paru z nich:

wynikającą z separacji możliwość podmiany sposobu dostępu do danych
wynikający z możliwości podmiany zwiększony poziom testability
reużywalność logiki dostępu do danych

Przyjrzyjmy się zasadności wylistowanych argumentów:
Podmiana sposobu dostępu do danych - teoretycznie silny argument; praktycznie bezużyteczny. Jak często zdarzyła się Wam taka sytuacja? O ile bardzo często zmienią się (no w zależności od klienta) wariacje logiki biznesowej to zmiana źródła danych? O ile zmienną logikę biznesową warto hermetyzować pod stabilnym interfejsem i jej wariacje enkapsulować we wzorcu strategii to robienie tego z dostępem do danych wydaje się nakładaniem gaci przez głowię. Chyba, że...

Testowanie - separacja dostępu do danych od logiki biznesowej zwiększa dramatycznie poziom testability, czyli podatność kodu na testy. Tak podatność na testy - ponieważ nie każdy kod można łatwo testować.
Jeżeli mam osobną klasę realizującą jakąś funkcjonalność biznesową oraz osobną klasę DAO odczytującą/modyfikującą dane to wówczas:
- możemy poddać testom sam "komponent" DAO - co się oczywiście będzie rzadko zdarzać, więc ten argument się nie liczy;P
- możemy testować samą logikę biznesową - na czas testów nasza logika może używać innej implementacji DAO (np takiej, która nie korzysta z bazy danych). Co na to daje?
Testy logiki biznesowej są szybsze ponieważ nie tracimy czasu na operacje zapisu odczytu danych (których poprawność w tym momencie nas nie interesuje). Czas zapisu/odczytu potencjalnie może być stosunkowo długi, wystarczy wyobrazić sobie źródło danych, które jest bazą zawierającą miliony rekordów, gigantycznym plikiem, czujnikiem chemicznym, web servisem wykonującym się średnio 5 min. Zamiast 100000 testów na godzinę, możemy ich wykonać tylko 10 gdy będziemy ciągnąć za sobą bagaż dostępu do danych.

Reużywalność - posługiwanie się wprost EntityManagerem w kodzie biznesowym do pobierania encji (tak jak chcą tego piewcy śmierci DAO) jest pomysłem arcy-chromym.
Kod w stylu
em.find(Person.class, id)
nie wygląda groźnie - nieprawdaż? Niestety jest on jednak typowy dla tandetnych turoriali na poziomie Hello World. W rzeczywistości jednak piszemy kwerendę ponieważ:
- mamy dynamiczne zapytanie (np doklejamy WHERE person.name = 'xxx' o ile user wpisał imie, itp)
- chcemy dociągnąć chciwie zagregowane obiekty (i nie życzymy sobie lazy loadingu gdyż nierzadko JEST ZŁY - o czym będzie w następnym poście)

Nawet jeżeli w pierwszej iteracji nasze pobranie danych jest prostym find() to zwykle za miesiąc zmieni się w kwerendę. Nie chcemy zatem programować metodą Kopiego-Pasty. Dzięki istnieniu DAO możemy reużywać złożoną logikę zapytań oraz oczywiście zmieniać je w 1 miejscu.

Separacja dla mnie osobiście separacja kodu - choćby zapytania były trywialne albo totalnie niereużywalne jest wystarczającą zaletą przemawiającą za DAO.

Potrafię sobie wyobrazić, że żadne z powyższych uwarunkowań nie występują. Tzn:
- nigdy nie zmieniamy źródła danych - co jest naturalne
- nie testujemy kodu - nie oszukujmy się, taka jest rzeczywistość
- nie mamy złożonych zapytań i logiki sklejania HQLa

Wówczas możemy radośnie używać EntityManagera w kodzie biznesowym. Sugerowałbym jednak kompromis: wystarczą osobne klasy realizujące logikę dostępu do danych - bez abstrakcji: bez interfejsu, bez wstrzykiwania.

Wąski kontekst
W bardzo prostych aplikacjach trzymanie się ściśle architektury z warstwą DAO niesie ze sobą pewnie narzuty i utratę prostoty. Mam tu na myśli niezbyt ambitne ale bardzo potrzebne na rynku i popularne aplikacje typu przeglądarka bazy danych. Po prostu łatwiej i taniej jest wyprodukować za 1 mln zł system, który w przeglądarce wyświetli tabelkę z listą kalesonów w hurtowni niż postawić samą bazę danych i przyuczyć pracowników z podstaw SQL;)))

W tego typu systemach zwykle corowa funkcjonalność to ekrany z różnego rodzaju listami + kontrolki do wpisywanie kryteriów + button SZUKAJ. Do tego ekran podglądu i edycji.

Najbardziej produktywne jest wówczas podejście minimalistyczne. Warstwa prezentacji tworzy obiekt Criteria i przesyła go niżej do wykonania. Przekombinowane podejście polegające na tworzenie warstwy DAO, która abstrahuje źródło danych zmusza nas również do abstrahowania od kryteriów wyszukiwania. GUI musi wysyłać jakieś DTO, które w DAO jest przepakowywane w Criteria. Generalnie: nakładanie gaci przez głowę.

Szerszy kontekst
Dla kontrastu rozważmy hipotetyczny przykład skomplikowanego dostępu do danych.
Wyobraźmy sobie, że w naszym systemie mamy użytkownika przechowywanego w 1 bazie danych. Z niewiadomych przyczyn jego zamówienia są przechowywane w innej bazie. Adresy tegoż użytkownika są pobierane z zewnętrznego systemu przez jakiś WebService.
Załóżmy też, że w zależności od wdrożenia druga baza danych (ta z zamówieniami) oraz źródło adresów są zmienne.

Podążając za DDD stworzylibyśmy agregat User oraz repozytorium UserRepository, które jest w stanie go zebrać i poskładać do kupy. Repozytorium mogłoby używać EntityManagera do pobrania encji User oraz dwóch DAO do pobrania zamówień oraz adresów z abstrakcyjnych źródeł. Problem dostępu do danych może zawierać w sobie również aspekt przepakowania obiektów z jednej domeny (np z innego systemu) do domeny innej.

Przykład powyższy może wydawać się nieco wydumany i przesadzony, ale w rzeczywistości tego typu spawy istnieją i nie należy o tym zapominać. Chciałem tylko pokazać, że architektura dostępu do danych wcale nie jest trywialnym problemem jak przedstawia się to w niektórych materiałach lub (o zgrozo!) przez niektórych członków grup eksperckich JEE. Owszem często taki jest. Ale spektrum problemów jest szerokie i po specyfikacji platformy korporacyjnej spodziewalibyśmy się czegoś więcej.

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

Na zakończenie pamiętajmy aby dobierać sobie młotek do problemu, a architekturę dostępu do danych do... też do problemu:)

Sentencja Alberta Einsteina "Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze" może wydawać się trywialna, ale często o niej zapominamy.

A do implementacji większości systemów i tak nie potrzeba żadnego JPA - wystarczy Excel + jakieś cwane makro... no może Access ostatecznie;P

Inteligientny projekt

2009-03-30T20:49:00.014+02:00

Ile kosztuje słaby i nieprzemyślany projekt?
Na początku wydaje się być kusząco tani - kokodżambo i do przodu.

Mimo iż dużo pisze się o zaciąganiu długu technicznego, o tym, że każda prowizorka i rozwiązania typu "na pałę" lub "byle jak - byle szybko" trzeba spłacić z nawiązką, to jakoś nie zawsze dociera to do świadomości.

Nudzenie o zgubnych skutkach niestosowania się np do paru prostych zasad GRASP czy SOLID jakoś nie jest zbyt przekonujące - chyba jest zbyt abstrakcyjne. Obiektowe filozofowanie typu DDD ustępuje miejsca metodykom RÓB i WHISKY (Why the Hell Isn't Somebody Koding Yet).

Aby zejść z poziomem abstrakcji i unaocznić problem w namacalny sposób zobaczmy na banalnym przykładzie pojazdu ile może kosztować (nie tylko pieniędzy ale i czasu oraz nerwów) słaby projekt.

Weźmy taki oto trywialny problem jak wymiana żarówki przedniego światła mijania w naszym modelowym systemie, którym niech będzie pojazd osobowy pewnej szwedzkiej marki, produkowany w duńskiej fabryce na amerykański rynek lecz użytkowany w centralnej europie.

/*
* Śpieszę wyjaśnić nielicznym paniom
* czytającym tego bloga, czym dla samca
* jest wymiana żarówki w jego własnym samochodzie.
* Otóż jest czymś co robimy SAMI - jest to
* punkt honoru.
* Zwracanie się z prośbą o pomoc do innego samca
* w tej jakże błahej sprawie
* jest czymś tak żenującym
* jak prośba o podtarcie tyłka.
* (Metafora może niezbyt elegancka, ale niestety
* nie znajduję w swej prostackiej głowie
* niczego co lepiej oddawało by wagę problemu)
*/

Zaczyna się od tego, że system logów wyświetla na konsoli informację sygnalizującą błąd lewego światła mijania. Hmmm mamy system autodiagnostyczny - pewnie zaszyli testy integracyjne w bootloaderze. Naajz, zapowiada się bułka z masłem.

Rozpoczynamy podejście do problemu jak rasowy informatyk. Nie informatyk, informatyk to obraźliwe słowo - coś jak konował albo znachor. Jak programista, tudzież developer lub inżynier oprogramowania. No więc zaczynamy od dokumentacji.

Dokumentacja jest co prawda nieco lakoniczna w temacie interesującej nas wymiany żarówek, ale w sumie to dobrze. Tu nie może być przecież wielkiej filozofii; cieszymy się wręcz, że nie mamy zbyt wiele do czytania - czarno na białym, jeden rysunek, jedno zdanie. Proste. Taką dokumentację to ja lubię... ukazuje sedno problemu, bez zbędnego kontekstu. Heh to musi być proste jak instalacja windowsa.

Pierwsze podejście do pracy na systemie. Dokonujemy wstępnych oględzin interfejsu użytkownika i już po paru próbach bezbłędnie lokalizujemy reflektory - na których to (jak wynika z dokumentacji) mamy za zadanie wykonać prace związane z maintenance. Właściwie to gwoli ścisłości interfejs użytkownika jest w środku. Na zewnątrz jest... hmmm powłoka (shell) mająca na celu separację użytkownika od podmuchów wiatru tudzież strug wody, która nie może się oprzeć sile grawitacji. Powłoka ma również na celu wywieranie wrażenia na blacharach - "osobnikach płci żeńskiej, dobierający sobie partnerów do prokreacji przez pryzmat samochodu jakim się poruszają" (że pozwolę sobie zacytować za nonsensopedią).

Powłoka spełnia zatem zadanie anticorruption layer (dosłownie chroniąc wnętrze przez rozkładem polegającym np na rdzewieniu) jak i warstwy servisów.

Zajrzyjmy jednak pod maskę, czyli warstwę niżej. Pięknie...cóż za separacja modułów. Niestety tylko z prawej strony. Coś co na pierwszy rzut oka wydawało się eleganckim warstwowym systemem z separacją modułów, po dokładnych oględzinach okazało się chaotycznym układem.

O ile instancja modułu oświetlenia zainstalowana prawej strony wydaje się być otwarta na prace utrzymaniowe to z lewej natomiast mamy kłębowisko spaghetti w okolicach modułu wyświetlania fotonów w kierunku jazdy. Do tego stwierdzamy silny coupling interesującego nas modułu z modułem chłodzenia - a dokładnie chyba z filtrem powietrza.

Co do cholery ma filtr powietrza z reflektorem?!? Kto scalił je tak blisko, że nawet mała rączka junior programera nie wcisnęłaby się aby sięgnąć do interfejsu żarówki - że o jej implementacji nie wspomnę! Spójrzmy jeszcze raz do dokumentacji. O ironio! Radość sprzed paru akapitów wywołana prostotą dokumentacji obraca się w rozpacz. Na tych cholernych rysunkach nie ma pudła z filtrem obok reflektora! Jak się dobrać do żarówki? Teraz przydało by się nieco więcej kontekstu w dokumentacji. Co robić? Aaaaa!

No ale może da cię coś obejść. Przecież nie pojadę z tym do warsztatu. Wyśmieją mnie. Minęło już 15 minut, czas na wunderwaffe - dekompilator, któremu nic się nie oprze - KOMBINERKI. Wspaniałe niskopoziomowe narzędzie, które obejdzie wszystkie zabezpieczenia. Metoda brute force. Wyciąganie flaków z core silnika aby zrobić nieco miejsca na ręczne prace utrzymaniowe. Hmm na moje oko jednak aby odłączyć moduł filtru powietrza należy iść dalej po zależnościach i wymontować połowę silnika. A przecież obok jest tyle miejsca. Nie możliwe aby zrobili to perfidnie - przecież to taka pożąda firma;)

Kto to projektował?!? Inżynier praktykant?

Sam tego nie zrobię, potrzeba guru od modułów oświetlenia z biegłą znajomością architektury (chyba burdelu) silników. Co za wstyd... może by tak wysłać żonę...

Ale na guru trzeba pewnie czekać w kolejce. I koszt będzie 10 razy większy niż samej żarówki. Ale jak mus to mus - przecież żadna blachara nie zainteresuje się systemem z niesymetrycznym UI.

Guru w pocie czoła przedarł się przez splątane niby-warstwy i po godzinie wymienił instancję żarówki oraz skompilował wszystko i zrobił deploy. Jeszcze tylko szybki test jednostkowy (szkoda, że po deployu:P) - tak dla formalności i bugfix można uznać triumfalnie za zakończony. Czas na commit faktury... Cholera - czerwony pasek! Yyyy to znaczy szara ściana - tzn żarówka nie świeci. Ponowna dekompilacja. Na szczęście udało się wykryć buga - spalona kostka. Szkoda, że w systemie występuje ona w egzotycznej wersji HB4 - jesteśmy uzależnieni od jednego dostawcy:/

Podsumowując
problem: wymiana 1 żarówki
czas: 2h
koszt: przemilczę
przewidywane problemy: wymiana 3 innych żarówek w lewym reflektorze w najbliższym czasie oraz związane z tym poczucie beznadziejnej bezradności:)

//===========================
Oczywiście nie wymagam absurdu polegającego na tym, że każdy kawałek systemu będzie niezależnym modułem czekającym na łatwą podmianę. Core to core - niektóre kawałki są silnie zespojone bo taka jest natura problemu - jestem w stanie to zrozumieć. Nie potrzebuję przecież zbyt często wyjmować skrzyni biegów, ale żarówka - przecież to podstawa.

Nie wymagam też niczego szczególnego typu otwartość na rozbudowę (np możliwość wymiany reflektorów na lasery służące do strącania pojazdów poruszających się nieskrajnie prawym pasem;). Chodzi o zwykłe i podstawowe czynności maintenance.

Chyba, że biznes polega na serwisie:)))