Dzisiaj pierwszy post z nowej serii. Jest to odcinek pilotażowy tasiemca, który z założenia ma być od teraz głównym wątkiem tego blogaska. Zgodnie z tytułem blogaska - będzie holistycznie (hasło to przestanie być pretensjonalnym buzzwordem).
Przygotowuję się powoli do rozpoczęcia nowego projektu. Jest to któryś już z kolei projekt, w którym będę uczestniczył - tym razem jako team leader. Jak zwykle obiecuję sobie, że tym razem będzie bardziej profesjonalnie i że tym razem będzie to miało przysłowiowe ręce i nogi (oraz nie 3 ręce i nie 8 nóg).
W ciągu pięciu lat pracy dobrze nauczyłem się jak NIE podchodzić do projektów - jest to wiedza praktyczna. Marność nad marnościami. Jednak tym razem zamierzam zastosować nabytą w ciągu ostatniego roku wiedzę teoretyczną... Unified Process (krótki wstęp) będzie procesem wytwórczym według którego będę chciał postępować. Główne fazy UP to analiza i projekt. Aby im sprostać posłużę się wytycznymi Domain Driven Design (dotychczasowe wypociny).
Zatem zamierzam przeprowadzić studium przypadku. Od czasu do czasu będę relacjonował jak sprawdza się UP i DDD w praktyce. Oczywiście treść będzie obdarta z kontekstu biznesowego:) Przykłady z wiadomych względów zostaną podniesione na nieco wyższy poziom abstrakcji.
Dodatkowo całość będzie zanurzona w kontekście technologicznym. Sam jestem ciekaw jak frameworki udźwigną ambitne założenia DDD:) Nie będę zanudzał tutorialami o popularnych frameworkach - jest tego pod dostatkiem i każdy na pewno znajduje dla siebie materiały odpowiadające osobistym preferencjom kognitywnym.
Relacja pomiędzy UP a DDD polega na tym, że UP jako proces wytwórczy prowadzi przez kolejny fazy (analiza biznesowa, systemowa, architektura, projekt implementacja, testy, wdrożenie); fazy dodatkowo zapętlone w iteracje. Natomiast DDD jest sposobem myślenia o fazach analizy (OOA) i projektowania (OOD) jako całości.
//===================
Nie pozostaje mi nic innego jak zaprosić do śledzenia postów otagowanych "UP-DDD in Action"
sobota, 25 października 2008
niedziela, 19 października 2008
Szkielety, zręby, rusztowania, ruiny
Zbieram sobie spokojnie materiały do prezentacji o Inversion of Control w Springu (w sumie to raczej o Springu:) na potrzeby naszego JUG. Aż tu nagle... prowokujący post Piotrka.
Jako wstęp do pracy nad prezentacją o Springu, dziś będzie o frameworkach w ogóle.
Najpierw należy odróżnić framework od biblioteki. Biblioteka to będzie chyba zbiór reużywalnych i sprawdzonych kawałków kodu skupionych wokół jakiegoś problemu. Nie będę tutaj silił się na definicję, wiadomo o co chodzi (jeżeli ktoś się chce do niej przyczepić to proszę bardzo;P). Ogólnie sytuacja jest taka: masz zestaw klas czy procedur (w wersji oldskulowej) i radź sobie. Składaj je w coś większego.
Natomiast framework ma już swą formę. Jest rozwiązaniem ogólnym, w którym brakuje jedynie szczegółów, które to musimy właśnie zdefiniować. Coś jak wypełnianie szkieletu mięsem. Zazwyczaj zajmuje się powtarzalnymi szczegółami technicznymi - dla nas zostaje biznes. Przynajmniej takie są założenia;)
Jeszcze jedna kategoria: zaznaczam, że nie chcę wyjść na zarozumiałego dupka, który lepiej od twórców Springa wie czym jest Spring, ale wydaje mi się, że jest on biblioteką frameworków a nie frameworkiem.
Komentując posta podlinkowanego przez Piotrka... Rzeczywiście jest tak, że jakaś część programistów podchodzi do frameworków z oporem. Dziwne, bo wydaje mi się, że prędzej czy później każdy jakieś swoje nano-frameworki tworzy. Jest to chyba immanentna cecha programistów, którzy uchwycili w pewnym momencie Object Oriented. Najpierw zaczynasz od uogólnień i abstrakcji. Projekt cieszy swą elegancją i prostotą - cieszy to niestety tylko Ciebie i ew. paru kolegów. Później w razie potrzeby refaktoryzacja do paru wzorców projektowych oraz wyciągnięcie konfiguracji na zewnątrz kodu. Okazuje się, ze konfiguracji jest zbyt wiele (koszmar XML), więc idąc z duchem czasu stawiamy na Convention Over Configuration. I quasi-framework gotowy. Heh hiestety zazwyczaj jego życie trwa jeden projekt bo do innych się nie nadaje... jest zbyt mało ogólny - ale to szczegół.
Z drugiej strony... frameworki budzą niechęć. Z obserwacji wydaje mi się, że przyczyny mogą być różne:
ignorancja - w przypadku niektórych frameworków bez biegłości w OO i wzorcach projektowych może być niestety ciężko połapać się o co chodzi w danym frameworku. Przytłacza on swą pozorną (bo wynikającą z niewiedzy) złożonością. Patrząc bardziej ogólnie problem może polegać na niechęci do zmian i poznawania nowych rzeczy.
pycha - jest jakaś część programistów, która nie wyrosła jeszcze ze śpioszków i twierdzą, że każdą kupę potrafią zrobić sami. Więc radośnie wynajdują np ORM na nowo. Tworzą coś co już zostało napisane zamiast skupić się na rozwiązaniu problemu klienta (biznesowego problemu). Bo ja sam UMIE i nie potrzebuje tutaj niczyjej pomocy a wzorce są dla cieniasów - Nie no fajnie, ale to do cholery kosztuje! Oczywiście niektórzy z czasem dochodzą do poziomu na którym ich rozwiązania są reużywalne - powstają wówczas chałupnicze nano-frameworki domowej roboty. Pycha każe im sądzić, że są one lepsze i mają mniej bugów niż coś co powstało w silnym community. Patrząc bardziej ogólnie: pyszne Zosie Samosie gardzą nie tylko frameworkami ale i oldskulowymi bibliotekami - po prostu wszystkim czego same radośnie nie spłodziły.
lenistwo - lepiej samemu coś napisać niż wertować strony dokumentacji istniejącego frameworka. Do tego jeszcze tony konfiguracji (niestety nasz własny framework jeżeli ma być frameworkiem też będzie musiał być jakoś konfigurowalny:P). Oczywiście na krótką metę lub w małych projektach pisanie z palca może być bardziej opłacalne. Patrząc bardziej ogólnie: co z samorozwojem? Przyjrzenie się architekturze sprawdzonego rozwiązania zazwyczaj otwiera nowe furtki w mózgu - pewne konstrukcje projektowe mogą być na prawdę inspirujące.
Kwestia najważniejsza: tytułowe ruiny. Frameworki (nawet te poważne i "oficjalne") nie zawsze muszą być arcydziełem. Nie koniecznie muszą rzeczywiście wspierać nas w rozwiązaniu problemu. W praktyce mogą przeszkadzać i irytować. Np taki JSF - wydaje się być zaprojektowany przez doskonałych inżynierów oprogramowania, którzy jednak niestety chyba nigdy w życiu nie popełnili żadnej aplikacji webowej (choćby w php).
//===================
Dobry framework powinien być tak zaprojektowany aby można było wymienić w nim nie tylko "mięcho" ale również część niego samego, czyli "szkieletu". Stąd chyba w Springu tyle interfejsów w bardziej jak i mniej newralgicznych miejscach:)
Jako wstęp do pracy nad prezentacją o Springu, dziś będzie o frameworkach w ogóle.
Najpierw należy odróżnić framework od biblioteki. Biblioteka to będzie chyba zbiór reużywalnych i sprawdzonych kawałków kodu skupionych wokół jakiegoś problemu. Nie będę tutaj silił się na definicję, wiadomo o co chodzi (jeżeli ktoś się chce do niej przyczepić to proszę bardzo;P). Ogólnie sytuacja jest taka: masz zestaw klas czy procedur (w wersji oldskulowej) i radź sobie. Składaj je w coś większego.
Natomiast framework ma już swą formę. Jest rozwiązaniem ogólnym, w którym brakuje jedynie szczegółów, które to musimy właśnie zdefiniować. Coś jak wypełnianie szkieletu mięsem. Zazwyczaj zajmuje się powtarzalnymi szczegółami technicznymi - dla nas zostaje biznes. Przynajmniej takie są założenia;)
Jeszcze jedna kategoria: zaznaczam, że nie chcę wyjść na zarozumiałego dupka, który lepiej od twórców Springa wie czym jest Spring, ale wydaje mi się, że jest on biblioteką frameworków a nie frameworkiem.
Komentując posta podlinkowanego przez Piotrka... Rzeczywiście jest tak, że jakaś część programistów podchodzi do frameworków z oporem. Dziwne, bo wydaje mi się, że prędzej czy później każdy jakieś swoje nano-frameworki tworzy. Jest to chyba immanentna cecha programistów, którzy uchwycili w pewnym momencie Object Oriented. Najpierw zaczynasz od uogólnień i abstrakcji. Projekt cieszy swą elegancją i prostotą - cieszy to niestety tylko Ciebie i ew. paru kolegów. Później w razie potrzeby refaktoryzacja do paru wzorców projektowych oraz wyciągnięcie konfiguracji na zewnątrz kodu. Okazuje się, ze konfiguracji jest zbyt wiele (koszmar XML), więc idąc z duchem czasu stawiamy na Convention Over Configuration. I quasi-framework gotowy. Heh hiestety zazwyczaj jego życie trwa jeden projekt bo do innych się nie nadaje... jest zbyt mało ogólny - ale to szczegół.
Z drugiej strony... frameworki budzą niechęć. Z obserwacji wydaje mi się, że przyczyny mogą być różne:
ignorancja - w przypadku niektórych frameworków bez biegłości w OO i wzorcach projektowych może być niestety ciężko połapać się o co chodzi w danym frameworku. Przytłacza on swą pozorną (bo wynikającą z niewiedzy) złożonością. Patrząc bardziej ogólnie problem może polegać na niechęci do zmian i poznawania nowych rzeczy.
pycha - jest jakaś część programistów, która nie wyrosła jeszcze ze śpioszków i twierdzą, że każdą kupę potrafią zrobić sami. Więc radośnie wynajdują np ORM na nowo. Tworzą coś co już zostało napisane zamiast skupić się na rozwiązaniu problemu klienta (biznesowego problemu). Bo ja sam UMIE i nie potrzebuje tutaj niczyjej pomocy a wzorce są dla cieniasów - Nie no fajnie, ale to do cholery kosztuje! Oczywiście niektórzy z czasem dochodzą do poziomu na którym ich rozwiązania są reużywalne - powstają wówczas chałupnicze nano-frameworki domowej roboty. Pycha każe im sądzić, że są one lepsze i mają mniej bugów niż coś co powstało w silnym community. Patrząc bardziej ogólnie: pyszne Zosie Samosie gardzą nie tylko frameworkami ale i oldskulowymi bibliotekami - po prostu wszystkim czego same radośnie nie spłodziły.
lenistwo - lepiej samemu coś napisać niż wertować strony dokumentacji istniejącego frameworka. Do tego jeszcze tony konfiguracji (niestety nasz własny framework jeżeli ma być frameworkiem też będzie musiał być jakoś konfigurowalny:P). Oczywiście na krótką metę lub w małych projektach pisanie z palca może być bardziej opłacalne. Patrząc bardziej ogólnie: co z samorozwojem? Przyjrzenie się architekturze sprawdzonego rozwiązania zazwyczaj otwiera nowe furtki w mózgu - pewne konstrukcje projektowe mogą być na prawdę inspirujące.
Kwestia najważniejsza: tytułowe ruiny. Frameworki (nawet te poważne i "oficjalne") nie zawsze muszą być arcydziełem. Nie koniecznie muszą rzeczywiście wspierać nas w rozwiązaniu problemu. W praktyce mogą przeszkadzać i irytować. Np taki JSF - wydaje się być zaprojektowany przez doskonałych inżynierów oprogramowania, którzy jednak niestety chyba nigdy w życiu nie popełnili żadnej aplikacji webowej (choćby w php).
//===================
Dobry framework powinien być tak zaprojektowany aby można było wymienić w nim nie tylko "mięcho" ale również część niego samego, czyli "szkieletu". Stąd chyba w Springu tyle interfejsów w bardziej jak i mniej newralgicznych miejscach:)
środa, 1 października 2008
Bottega
Przez ostatnich parę dni szukałem swojego dyplomu ukończenia studiów. Bezskutecznie przetrząsając różne szpargały natknąłem się na wiele "pamiątek" z czasów studiowania informatyki. Niestety, nie były to pamiątki budzące sentymentalne wspomnienia. O nie...
Były to kserówki podręczników akademickich, skryptów i wykładów. Z zaciśniętymi zębami (na granicy szczękościsku;) mogłem odświeżyć sobie nieco wiedzę o: całkach, równaniach, obwodach RLC, równaniach, pierścieniach, równaniach, ciałach, równaniach, niezmiennikach, równaniach, złożoności, równaniach, twierdzeniu Kołmogorowa, równaniach, nieskończonej studni potencjału, równaniach, śmiesznej notacji składającej się z prostokątów i elips przedstawiającej składnię Pascala (wszystkie diagramy umiałem na pamięć:] ), równaniach, postaciach normalnych i mój ulubiony killer: gradient dywergencji rotacji laplasjanu hamiltonianu:)))
Tresowanie szympansów na umiejętność przetwarzania symboli - iksy na prawą, ygreki na lewą.
Okazuje się, że można też inaczej: "Systems Development": a New Discipline for a New Education.
Bottega - pracownia renesansowego mistrza. Miejsce, w którym Leonardo i jemu podobni oddawali się twórczości. Miejsce, które dzięki swej aranżacji i zawartości stymulowało w sposób naturalny różne aspekty kreatywności. Miejsce, w którego centrum stał człowiek.
Bottega stała się w przenośni i dosłownie inspiracją dla twórców wspomnianego w linku eksperymentalnego kierunku studiów "Systems Development". Kierunku, którego credo zawarte jest w sugestywnym symbolu: "Software is our medium, Craft (Mastery) is our goal, People are our focus, Systems is our perspective, and Agility is our process." Bottega promuje raczej myślenie syntetyczne niż analityczne. Synteza wielu aspektów ludzkiej aktywności daje szansę na powstanie nowej wartości.
Dr. Dave West zauważa, że mimo postępu procesów i technologii nadal utrzymujemy dosyć żenujący współczynnik projektów zakończonych sukcesem. Jako jedną z przyczyn wskazuje przepaść pomiędzy tym, czego nauczani są studenci, a tym czego wymaga rzeczywistość.
Nie chodzi tutaj bynajmniej o prymitywne podejście i roszczenia wobec nauczania trendowych technologii czy języków. Nic z tych rzeczy, uczelnia nie ma przecież na celu przyuczenie do jakiegoś zawodu. Problem jest postawiony dużo głębiej. Aby w ogóle myśleć o tworzeniu systemów dla ludzi, wypadałby najpierw rozumieć systemy ludzkie... Ale nie będę streszczał i tak krótkiego artykułu - na prawdę warto przeczytać (inaczej chyba bym nie zawracał głowy;P).
Jakie mierzalne wyniki edukacyjne daje zmiana podejścia? Wystarczy przeczytać artykuł do końca:P
//========================
Heh... Humanizm... trochę wypaczono go ostatnio - humanistą jest każdy, kto nie potrafi liczyć, ale za to potrafi zapamiętać parę tysięcy stron kodeksów czy oficjalnej wersji historii;))).
Były to kserówki podręczników akademickich, skryptów i wykładów. Z zaciśniętymi zębami (na granicy szczękościsku;) mogłem odświeżyć sobie nieco wiedzę o: całkach, równaniach, obwodach RLC, równaniach, pierścieniach, równaniach, ciałach, równaniach, niezmiennikach, równaniach, złożoności, równaniach, twierdzeniu Kołmogorowa, równaniach, nieskończonej studni potencjału, równaniach, śmiesznej notacji składającej się z prostokątów i elips przedstawiającej składnię Pascala (wszystkie diagramy umiałem na pamięć:] ), równaniach, postaciach normalnych i mój ulubiony killer: gradient dywergencji rotacji laplasjanu hamiltonianu:)))
Tresowanie szympansów na umiejętność przetwarzania symboli - iksy na prawą, ygreki na lewą.
Okazuje się, że można też inaczej: "Systems Development": a New Discipline for a New Education.
Bottega - pracownia renesansowego mistrza. Miejsce, w którym Leonardo i jemu podobni oddawali się twórczości. Miejsce, które dzięki swej aranżacji i zawartości stymulowało w sposób naturalny różne aspekty kreatywności. Miejsce, w którego centrum stał człowiek.
Bottega stała się w przenośni i dosłownie inspiracją dla twórców wspomnianego w linku eksperymentalnego kierunku studiów "Systems Development". Kierunku, którego credo zawarte jest w sugestywnym symbolu: "Software is our medium, Craft (Mastery) is our goal, People are our focus, Systems is our perspective, and Agility is our process." Bottega promuje raczej myślenie syntetyczne niż analityczne. Synteza wielu aspektów ludzkiej aktywności daje szansę na powstanie nowej wartości.
Dr. Dave West zauważa, że mimo postępu procesów i technologii nadal utrzymujemy dosyć żenujący współczynnik projektów zakończonych sukcesem. Jako jedną z przyczyn wskazuje przepaść pomiędzy tym, czego nauczani są studenci, a tym czego wymaga rzeczywistość.
Nie chodzi tutaj bynajmniej o prymitywne podejście i roszczenia wobec nauczania trendowych technologii czy języków. Nic z tych rzeczy, uczelnia nie ma przecież na celu przyuczenie do jakiegoś zawodu. Problem jest postawiony dużo głębiej. Aby w ogóle myśleć o tworzeniu systemów dla ludzi, wypadałby najpierw rozumieć systemy ludzkie... Ale nie będę streszczał i tak krótkiego artykułu - na prawdę warto przeczytać (inaczej chyba bym nie zawracał głowy;P).
Jakie mierzalne wyniki edukacyjne daje zmiana podejścia? Wystarczy przeczytać artykuł do końca:P
//========================
Heh... Humanizm... trochę wypaczono go ostatnio - humanistą jest każdy, kto nie potrafi liczyć, ale za to potrafi zapamiętać parę tysięcy stron kodeksów czy oficjalnej wersji historii;))).
Subskrybuj:
Posty (Atom)