W jaki sposób zbudować formę i zaplanować treść prezentacji, która: jest prowokacyjna ale skłania do refleksji, jest arcy-śmieszna oraz obrazoburcza wobec gigantów branży i dogmatów a przy okazji jest rodzajem rozliczenia tego czego dokonaliśmy?
Na przykład tak:
Bret Victor - The Future of Programming from Bret Victor on Vimeo.
Oglądaj w pełnym skupieniu, bo każdy detal w formie, każdy szczegół w treści wyzwala wewnętrzny chichot (oczywiście o ile jesteś geekiem:).
//===========================
btw: gdzie można kupić takie ochraniacze na długopisy do kieszeni koszuli?
niedziela, 11 sierpnia 2013
środa, 7 sierpnia 2013
This is where the one who knows meets the one who doesn't care
"This is where the one who knows meets the one who doesn't care" - wers z utworu Chrisa Rea; płyty Chrisa towarzyszą mi często w samochodzie gdy godzinami przemierzam trasy prowadzące do kolejnego hotelu...
Dziś będzie o próbach komunikacji i wyzwaniach jakie są z nią związane oraz (niestety) o parszywych manipulacjach. Jako studium przypadku posłuży nam coś w stylu konwersacji dwóch ekspertów, zasłużonych weteranów w naszej branży: Jim Coplien i Bob Martin debatują na temat słuszności TDD.
Zacznę od zaznaczenia, że nie zajmuję stanowiska wobec treści. Nie będę stawał po żadnej stronie w tej dyskusji, skupię się na formie i wybranych wzorcach i antywzorcach jakie możemy obserwować podczas "konwersacji" w naszej branży. Zresztą... jeżeli programujesz już od kilka lat, to zapewne wiesz, że każda nietrywialna technika działa jedynie w kontekście problemu a poza nim może być wręcz szkodliwa.
Źródło autorytetu
Jeden z interlokutorów powołuje się na autorytet własnej osoby. Cytuje sam siebie. Opiera argumenty na definicjach, które sam wymyśla.
Drugi zaś, podpiera się autorytetem zewnętrznym powołując się na cytaty innych osób. O ile nie jest to tak śmieszne jak poprzednia strategia, to czy przez to staje się bardziej wiarygodne?
Generalnie mamy tutaj zderzenie dwóch strategi kognitywnych: "co by powiedzieli inni?" vs "chrzanić innych, ja mówię jak jest".
Piętnowanie
Któż z nas nie chciałby być uważany za profesjonalistę (w polskim rozumieniu tego słowa, a nie angielskim, gdzie jest to ktoś zarabia na danej działalności)?
Jak pewnie zauważyliście, jeden z rozmówców stwierdza na wstępie, że ten, kto nie praktykuje pewnej techniki w swej pracy nie jest profesjonalistą. Techniki, która jest rdzeniem jego komercyjnych produktów:) Nie stoi za tym stwierdzeniem żadna sensowna argumentacja ani odniesienia do badań, po prostu własne "widzimisię" - wynikające ze źródła autorytetu.
Drugi z rozmówców mógłby w tym momencie zastosować tani chwyt zdając pytanie: "a co z tymi setkami tysięcy ludzi, którzy nieszczęśliwie urodzili się przed popularyzacją metodyki, czy byli szmaciarzami?" Zamiast tego powołuje się na badania, które wykazują szkodliwość metodyki (rozumianą jako zwiększenie ilości błędów) - ale pamiętajmy, że badania przeprowadzono w specyficznym kontekście.
Mowa ciała
Jaskrawe niedopasowanie rozmówców możemy zaobserwować na poziomie niewerbalnym. Jeden z nich często gestykuluje do swego centrum (w tym wypadku w kierunku splotu słonecznego). Widać silną inteligencję kinestetyczną, tok rozumowania wspierany wyobrażeniami ruchowymi.
Drugi zaś większość czasu spędza "w głowie". Zamiast dyskusji mamy więc "wymianę sygnałów" pomiędzy intuicją jednego z rozmówców a konstruktami złożonymi z abstraktów drugiego z nich.
Gdy następnym razem będziesz świadkiem jałowej dyskusji podczas spotkania projektowego zwróć uwagę na taki "szczegół" jak dopasowanie postaw rozmówców. Spotkanie będzie generalnie pozbawione sensu, ponieważ obie strony używają zupełnie innych reprezentacji mentalnych, innymi słowy mają w głowie inne modele, oparte na innych założeniach. Na poziomie werbalnym niby wszystko jest ok, ale dyskusja jakoś nie doprowadzi do konkluzji i wspólnego działania.
Pomocyyyy...
Niemowlęta mają w repertuarze swoich zachowań specjalny ruch: odruch Moro. Pomaga to im poczuć się lepiej. U dorosłych ludzi zredukowana wersja odruchu (założenie rąk ponad głowę) pojawia się nieświadomie, gdy chcieliby aby mama przyszła i zabrała ich już z niewygodnej sytuacji. Ew. dodaje nieco otuchy i pozwala zabrać myśli aby przejść do kontrataku z wykorzystaniem klasycznych technik erystycznych.
Tak, tak
Podobno ludzie kiwają głową gdy się zgadzają - ale z samym sobą (wewnętrznie w "myślach"). Tak więc jeżeli widzisz uśmieszek w kąciku ust i kiwanie głową, to masz pewność, że interlokutor przestał właśnie słuchać i testuje pławienie się w rozkoszy riposty jaką przygotował do poprzedniego zdania. Możesz skończyć wydawanie dźwięków, trafiają na /dev/null.
Dreyfus.
Model rozwoju kompetencji Braci Dreyfus jest ostatnimi czasy popularny w naszej branży. Jeżeli się z nim nie spotkałeś/spotkałaś, to zachęcam do zapoznania się z wstępem do wstępu.
Generalnie widać różnicę w targetowaniu przekazu: jeden z rozmówców celuje w odbiorców będących na I i II poziomie Dreyfus, którzy oczekują prostych i bezkontekstowych reguł postępowania. Drugi może być odebrany ze zrozumieniem tylko na kolejnych poziomach.
Nadużywanie słowa "architektura"
Mam takie przemyślenie, że najczęściej używane słowa w naszej branży: komponent, moduł i architektura są rozumiane "intuicyjnie". Czyli nikt nie wie, co to tak na prawdę jest. Szczególnie słowo "architektura" doklejane jest do tytułów książek i prezentacji służąc zwykle do zdobywania ekstra punktów reputacji;)
Obaj panowie zdają się poruszać temat Object Oriented Design, tam gdzie pada słowo architektura. Oczywiście mamy różne skale architektury (aplikacyjna, systemowa, wdrożeniowa, skalowania, bezpieczeństwa), ale generalnie rozumiem to słowo jako "design of design". Czyli w przypadku architektury aplikacyjnej będą to struktury ponad OOD (np, warstwy, heksagony, pipes&filters itd)
Na zakończenie kolejny akcent muzyczny (jeżeli nie przepadasz za starożytną muzyką, to wystarczy intro)
//=================================
A tutaj Paweł Badeński zwraca uwagę na inne ciekawe błędy oraz wyjaśnia dlaczego nasza branża nigdy nie będzie postrzegana poważnie przez tak zwane prawdziwe dziedziny nauki:)
Dziś będzie o próbach komunikacji i wyzwaniach jakie są z nią związane oraz (niestety) o parszywych manipulacjach. Jako studium przypadku posłuży nam coś w stylu konwersacji dwóch ekspertów, zasłużonych weteranów w naszej branży: Jim Coplien i Bob Martin debatują na temat słuszności TDD.
Zacznę od zaznaczenia, że nie zajmuję stanowiska wobec treści. Nie będę stawał po żadnej stronie w tej dyskusji, skupię się na formie i wybranych wzorcach i antywzorcach jakie możemy obserwować podczas "konwersacji" w naszej branży. Zresztą... jeżeli programujesz już od kilka lat, to zapewne wiesz, że każda nietrywialna technika działa jedynie w kontekście problemu a poza nim może być wręcz szkodliwa.
Źródło autorytetu
Jeden z interlokutorów powołuje się na autorytet własnej osoby. Cytuje sam siebie. Opiera argumenty na definicjach, które sam wymyśla.
Drugi zaś, podpiera się autorytetem zewnętrznym powołując się na cytaty innych osób. O ile nie jest to tak śmieszne jak poprzednia strategia, to czy przez to staje się bardziej wiarygodne?
Generalnie mamy tutaj zderzenie dwóch strategi kognitywnych: "co by powiedzieli inni?" vs "chrzanić innych, ja mówię jak jest".
Piętnowanie
Któż z nas nie chciałby być uważany za profesjonalistę (w polskim rozumieniu tego słowa, a nie angielskim, gdzie jest to ktoś zarabia na danej działalności)?
Jak pewnie zauważyliście, jeden z rozmówców stwierdza na wstępie, że ten, kto nie praktykuje pewnej techniki w swej pracy nie jest profesjonalistą. Techniki, która jest rdzeniem jego komercyjnych produktów:) Nie stoi za tym stwierdzeniem żadna sensowna argumentacja ani odniesienia do badań, po prostu własne "widzimisię" - wynikające ze źródła autorytetu.
Drugi z rozmówców mógłby w tym momencie zastosować tani chwyt zdając pytanie: "a co z tymi setkami tysięcy ludzi, którzy nieszczęśliwie urodzili się przed popularyzacją metodyki, czy byli szmaciarzami?" Zamiast tego powołuje się na badania, które wykazują szkodliwość metodyki (rozumianą jako zwiększenie ilości błędów) - ale pamiętajmy, że badania przeprowadzono w specyficznym kontekście.
Mowa ciała
Jaskrawe niedopasowanie rozmówców możemy zaobserwować na poziomie niewerbalnym. Jeden z nich często gestykuluje do swego centrum (w tym wypadku w kierunku splotu słonecznego). Widać silną inteligencję kinestetyczną, tok rozumowania wspierany wyobrażeniami ruchowymi.
Drugi zaś większość czasu spędza "w głowie". Zamiast dyskusji mamy więc "wymianę sygnałów" pomiędzy intuicją jednego z rozmówców a konstruktami złożonymi z abstraktów drugiego z nich.
Gdy następnym razem będziesz świadkiem jałowej dyskusji podczas spotkania projektowego zwróć uwagę na taki "szczegół" jak dopasowanie postaw rozmówców. Spotkanie będzie generalnie pozbawione sensu, ponieważ obie strony używają zupełnie innych reprezentacji mentalnych, innymi słowy mają w głowie inne modele, oparte na innych założeniach. Na poziomie werbalnym niby wszystko jest ok, ale dyskusja jakoś nie doprowadzi do konkluzji i wspólnego działania.
Pomocyyyy...
Niemowlęta mają w repertuarze swoich zachowań specjalny ruch: odruch Moro. Pomaga to im poczuć się lepiej. U dorosłych ludzi zredukowana wersja odruchu (założenie rąk ponad głowę) pojawia się nieświadomie, gdy chcieliby aby mama przyszła i zabrała ich już z niewygodnej sytuacji. Ew. dodaje nieco otuchy i pozwala zabrać myśli aby przejść do kontrataku z wykorzystaniem klasycznych technik erystycznych.
Tak, tak
Podobno ludzie kiwają głową gdy się zgadzają - ale z samym sobą (wewnętrznie w "myślach"). Tak więc jeżeli widzisz uśmieszek w kąciku ust i kiwanie głową, to masz pewność, że interlokutor przestał właśnie słuchać i testuje pławienie się w rozkoszy riposty jaką przygotował do poprzedniego zdania. Możesz skończyć wydawanie dźwięków, trafiają na /dev/null.
Dreyfus.
Model rozwoju kompetencji Braci Dreyfus jest ostatnimi czasy popularny w naszej branży. Jeżeli się z nim nie spotkałeś/spotkałaś, to zachęcam do zapoznania się z wstępem do wstępu.
Generalnie widać różnicę w targetowaniu przekazu: jeden z rozmówców celuje w odbiorców będących na I i II poziomie Dreyfus, którzy oczekują prostych i bezkontekstowych reguł postępowania. Drugi może być odebrany ze zrozumieniem tylko na kolejnych poziomach.
Nadużywanie słowa "architektura"
Mam takie przemyślenie, że najczęściej używane słowa w naszej branży: komponent, moduł i architektura są rozumiane "intuicyjnie". Czyli nikt nie wie, co to tak na prawdę jest. Szczególnie słowo "architektura" doklejane jest do tytułów książek i prezentacji służąc zwykle do zdobywania ekstra punktów reputacji;)
Obaj panowie zdają się poruszać temat Object Oriented Design, tam gdzie pada słowo architektura. Oczywiście mamy różne skale architektury (aplikacyjna, systemowa, wdrożeniowa, skalowania, bezpieczeństwa), ale generalnie rozumiem to słowo jako "design of design". Czyli w przypadku architektury aplikacyjnej będą to struktury ponad OOD (np, warstwy, heksagony, pipes&filters itd)
Na zakończenie kolejny akcent muzyczny (jeżeli nie przepadasz za starożytną muzyką, to wystarczy intro)
//=================================
A tutaj Paweł Badeński zwraca uwagę na inne ciekawe błędy oraz wyjaśnia dlaczego nasza branża nigdy nie będzie postrzegana poważnie przez tak zwane prawdziwe dziedziny nauki:)
sobota, 29 czerwca 2013
Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA
Czy wiesz, że:
Jeżeli powyższe tezy targnęły Twoimi emocjami, to zapraszam do lektury najnowszego artykułu: Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA (do pobranie całkowicie free), który ukazał się w najnowszym numerze programistamag.pl (wakacyjny numer o podwójnej objętości dostępny w Empikach lub w formie elektrycznej).
Zapraszam do śledzenia całej serii Laboratorium Bottega - Receptury projektowe – niezbędnik początkującego architekta.
- Lazy Loading nie ma sensu
- Mapowanie @OneToMany z wykorzystaniem tabeli linkującej (domyślne zachowanie hibernate) nie ma sensu
- Blokowanie Optymistyczne oparte jedynie na @Version nie ma sensu
Jeżeli powyższe tezy targnęły Twoimi emocjami, to zapraszam do lektury najnowszego artykułu: Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA (do pobranie całkowicie free), który ukazał się w najnowszym numerze programistamag.pl (wakacyjny numer o podwójnej objętości dostępny w Empikach lub w formie elektrycznej).
Zapraszam do śledzenia całej serii Laboratorium Bottega - Receptury projektowe – niezbędnik początkującego architekta.
czwartek, 13 czerwca 2013
3 zasady optymalizacji
- Nie optymalizuj - jeżeli na prawdę tego nie potrzebujesz - być może to "tylko" twoje ego chce się pobawić pozostając w strefie komfortu; spójrz na parking za oknem i policz ile samochodów tam stojących było projektowanych z myślą szybkości (chyba, że pracujesz w centrum Londynu:)
- Nie optymalizuj jeżeli nie rozumiesz co robisz - być może dotkniesz warstw, gdzie nie sięgają Twoje kompetencje - i być może cały Twój wysiłek zostanie zniweczony na poziomie pakietów i ramek TCP/IP lub będzie pomijalny dzięki optymalizacjom wirtualnej maszyny
- Nie optymalizuj jeżeli nie mierzysz wydajności przed i po - być może intuicja, która świetnie działa na sawannie, nie działa w świecie krzemu - i być może wysłanie kilku zapytań do bazy danych, obróbka wyników w pamięci serwera aplikacji jest lepszym pomysłem niż jedno zapytanie z 30 joinami:P
btw: pamiętaj, że wirtualna maszyna Javy "wie" o optymalizacji więcej niż znakomita większość programistów C - zwykle wystarczy się nie wydurniać, a JVM zajmie się resztą...
poniedziałek, 10 czerwca 2013
Twój mózg Cię oszukuje (gdy uczysz się nowego języka)
Dziś chciałbym polecić prezentację, którą powinien obejrzeć każdy programista: Don’t Trust Your Brain.
Treść przyda się szczególnie tym z Was, których zmuszono do nauki nowego języka programowania (jeżeli uczysz się z własnej woli, to za pewne idzie znacznie łatwiej:)
W lekki, zabawny i okraszony wiedzą za zakresu psychologii sposób dowiecie się, że składnia to przysłowiowy pikuś; kluczowe są: kultura, narzędzia, wzorce i idiomy.
//================================================
Zawsze przerażali mnie programiści klasy King Bruce Lee Karate Mistrz, którzy twierdzą, że "każdego języka mógłbym nauczyć się w tydzień (ale mi się nie chce)". Później widzimy potworki napisane np. w Javie w C albo w C# w Cobolu...
Treść przyda się szczególnie tym z Was, których zmuszono do nauki nowego języka programowania (jeżeli uczysz się z własnej woli, to za pewne idzie znacznie łatwiej:)
W lekki, zabawny i okraszony wiedzą za zakresu psychologii sposób dowiecie się, że składnia to przysłowiowy pikuś; kluczowe są: kultura, narzędzia, wzorce i idiomy.
//================================================
Zawsze przerażali mnie programiści klasy King Bruce Lee Karate Mistrz, którzy twierdzą, że "każdego języka mógłbym nauczyć się w tydzień (ale mi się nie chce)". Później widzimy potworki napisane np. w Javie w C albo w C# w Cobolu...
piątek, 7 czerwca 2013
Open/closed principle - zastosowanie na poziomie architektury aplikacji oraz metafory wizualne
"Kod powinien być otwarty na rozbudowę jak kwiat lotosu o świcie i zamknięty na zmiany jak kwiat lotosu o zmierzchu" - jako początkujący projektant natknąłem się kiedyś w jednej z książek na takie "Buddyjskie" wyjaśnienie Open/Closed Principle - jednej z zasad SOLID.
Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?
W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:
W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:
Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...
Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje
Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?
W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:
- ODD,
- podstawy podejścia funkcyjnego,
- Building Blocks wchodzące w skład Domain Driven Design,
- architekturę na poziomie aplikacyjnym.
W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:
- stabilną - której kod relatywnie rzadko podlega zmianom
- domknięcia logiki - które nie polegają zmianom a rozbudowie
- wybór domknięć - zmiany enkapsulowane w fabrykach (zgodnie z regułą Uncle Boba: "instrukcje switch są dozwolone jedynie w czeluściach fabryk":)
Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...
Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje
wtorek, 30 kwietnia 2013
C4 - Zwinne podejście do odkrywania i dokumentowania architektury
W jaki sposób dokumentować architekturę systemu - z jednej strony tak, aby zawrzeć wszystkie potrzebne informacje, z drugiej zaś, aby nie przeładować dokumentacji szczegółami, które czynią ją bezużyteczną?
Pracując z zespołami podczas warsztatów architektonicznych rozpoczynam zwykle od "zadania na rozgrzewkę", którego treść jest krótka: "wyobraźcie sobie, że od jutra dołączam do Waszego teamu; narysujcie proszę architekturę systemu, nad którym aktualnie pracujecie aby szybko i efektywnie wprowadzić mnie w kontekst oraz abym wiedział gdzie 'włożyć ręce'".
Jak widać treść nie doprecyzowuje o jaki rodzaj architektury chodzi (aplikacyjna, systemowa, wdrożeniowa, etc) oraz w jaki sposób należy to zrobić - po prostu "tak jak robicie to aktualnie w projekcie", a jeżeli tego typu aktywności nie są podejmowane, "intuicyjnie, jak byś to zrobił/zrobiła".
/*************************
Wiem, że zewnętrzny doradca, który chce 'włożyć ręce' w projekt to niespotykany okaz. Większość z nich to osobniki typu krokodyl - małe rączki, duża gęba (czytaj: nic nie robi, dużo gada).
**************************/
Typowe problemy, jakie pojawiają się podczas prób wizualizowania architektury oraz jeden ze sposobów radzenia sobie z takim krytycznym zadaniem jakim jest komunikowanie swoich pomysłów i strategicznych decyzji opisałem w najnowszym numerze programistamag.
Artykuł C4 - Zwinne podejście do odkrywania i dokumentowania architektury jak zwykle do pobrania (jak zwykle free) tutaj: Niezbędnik początkującego projektanta i architekta (zachęcam oczywiście do odwiedzenia empiku lub zakupu wersji elektrycznej całego numeru).
//===================================================
Zainteresowanych zgłębieniem tematu odsyłam do książki Software Architecture for Developers oraz artykułu, który kilka dni temu ukazał się na infoq.
Ze doświadczenia swego oraz zespołów, z którymi pracuję mogę podzielić się jednym rozszerzeniem do C4: mianowicie w większych systemach Komponenty warto grupować w Moduły (czyli: Context Containers Modules Components Classes). Wewnątrz modułu komponenty "widzą" się wzajemnie, natomiast poza modułem jest widoczny jedynie podzbiór API np. w formie Fasady lub emitowanych zdarzeń (część zdarzeń, które pojawiają się wewnątrz modułu).
Pracując z zespołami podczas warsztatów architektonicznych rozpoczynam zwykle od "zadania na rozgrzewkę", którego treść jest krótka: "wyobraźcie sobie, że od jutra dołączam do Waszego teamu; narysujcie proszę architekturę systemu, nad którym aktualnie pracujecie aby szybko i efektywnie wprowadzić mnie w kontekst oraz abym wiedział gdzie 'włożyć ręce'".
Jak widać treść nie doprecyzowuje o jaki rodzaj architektury chodzi (aplikacyjna, systemowa, wdrożeniowa, etc) oraz w jaki sposób należy to zrobić - po prostu "tak jak robicie to aktualnie w projekcie", a jeżeli tego typu aktywności nie są podejmowane, "intuicyjnie, jak byś to zrobił/zrobiła".
/*************************
Wiem, że zewnętrzny doradca, który chce 'włożyć ręce' w projekt to niespotykany okaz. Większość z nich to osobniki typu krokodyl - małe rączki, duża gęba (czytaj: nic nie robi, dużo gada).
**************************/
Typowe problemy, jakie pojawiają się podczas prób wizualizowania architektury oraz jeden ze sposobów radzenia sobie z takim krytycznym zadaniem jakim jest komunikowanie swoich pomysłów i strategicznych decyzji opisałem w najnowszym numerze programistamag.
Artykuł C4 - Zwinne podejście do odkrywania i dokumentowania architektury jak zwykle do pobrania (jak zwykle free) tutaj: Niezbędnik początkującego projektanta i architekta (zachęcam oczywiście do odwiedzenia empiku lub zakupu wersji elektrycznej całego numeru).
//===================================================
Zainteresowanych zgłębieniem tematu odsyłam do książki Software Architecture for Developers oraz artykułu, który kilka dni temu ukazał się na infoq.
Ze doświadczenia swego oraz zespołów, z którymi pracuję mogę podzielić się jednym rozszerzeniem do C4: mianowicie w większych systemach Komponenty warto grupować w Moduły (czyli: Context Containers Modules Components Classes). Wewnątrz modułu komponenty "widzą" się wzajemnie, natomiast poza modułem jest widoczny jedynie podzbiór API np. w formie Fasady lub emitowanych zdarzeń (część zdarzeń, które pojawiają się wewnątrz modułu).
Subskrybuj:
Posty (Atom)