Może to wpływ świątecznego nastroju i kolęd podśpiewywanych z korytarza - najwyraźniej MiNI miało tego wieczora "opłatek" - ale 98 spotkanie WG.NET było naprawdę fajne. Podoba mi się też zmiana z ankietami - od teraz ankiety są zarządzane przez grupę, a nagrody rozlosowywane na następnym spotkaniu wśród osób, które ową ankietę wypełniły. Powinno to pozwolić na większy feedback ze strony słuchaczy, bezcenna rzecz dla prelegentów!
Composite UI w świecie SOA - Michał Padzik
Student MiNI opowiadał o swoim autorskim projekcie Composite UI. Temat sam z siebie bardzo ciekawy, więc spotkał się według mnie ze sporym zainteresowaniem. Jeśli chcecie coś więcej o tym poczytać, najlepiej poszukajcie terminu Composite Frontend (np. fajny The Monolithic Frontend In The Microservices Architecture). Temat przy dzisiejszej popularności mikroserwisów jak najbardziej na czasie, a zupełnie nietrywialny. Czyli jak zrobić tak, by pięknie zdekomponowany w mikroserwisy backendowy monolit nie został przykryty przez wciąż wielki, monolityczny frontend.
Michał zdecydował się na kompozycję "komponentów" rozdzieloną na poziomie kodu i projektów, jednak osadzonych w jednym procesie aplikacji webowej. Zatem jest to krok do przodu i jedno z możliwych podejść, zapewne mające swoje zastosowania. Mnie zainspirowało to do poszukiwań jeszcze dalej idących rozwiązań/frameworków, które rozdzielają komponenty na poziomie deploymentu - by uzyskać niezależność podobną jak w przypadku mikroserwisów. Temat jak się okazuje jest jeszcze dość dziewiczy i brakuje dojrzałych rozwiązań, zatem jakby ktoś miał nadmiar wolnego czasu, ma szansę zabłysnąć:) Czy ktoś zna jakieś w miarę sprawdzony framework? Ja spotkałem się z OpenComponents ale też nie jest to jakieś spektakularne. Na tym tle projekt Michała wygląda całkiem fajnie. Kiedyś trzeba się będzie przyjrzeć dokładniej.
Wracając zaś do prezentacji, zawsze fajnie posłuchać autora ciekawego projektu, który BTW sami możecie zaciągnąć z githuba. Opowiedziane fajnie i konkretnie. Czasem dodałbym tylko więcej slajdów ze schematami/kodem, który tłumaczy zależności między komponentami, widokami itd. itp.
Tworzenie wysokowydajnych systemów w .NET - Bartosz Adamczewski
Co tu dużo gadać, tematyka wydajności i internalsów .NET to moje ulubione tematy więc jak tylko zobaczyłem tweeta Bartosza, że mówi o tym na BSTOK.NET, zagaiłem by stało się to też u nas. I nie ma co żałować, było bardzo mięsiście. Live przykład skutków false sharingu oraz nieoptymalnego odczytu tablic - super. Tak samo jak ogólny poziom prezentacji i sposobu przekazu.
To nic, że 99% devów nigdy się nie spotka wprost z tymi problemami - nie znaczy, że nie można być ich świadomym. Kiedyś możemy się zderzyć z taką rzeczywistością. Mnie nie trzeba przekonywać, że od pewnego poziomu dev powinien wiedzieć czego używa (CLR) i jak on działa. Oraz, że wpływ na to wszystko ma coś tak niskopoziomowego jak architektura i sposób pracy procesora. Najfajniejszy był chyba przykład false sharingu w samym CLR.
Znacznie praktyczniejszy problem nadmiernych alokacji to co innego - sam już o tym ciągle mówię i super to zostało przez Bartka zobrazowane. Bardzo polecam obejrzenie tej prezentacji jak tylko się pojawi na kanale WG.NET, tymczasem slajdy dostępne są na Githubie.
Jedno tylko małe sprostowanie co do zwrotu "tablice w .NET nie są alokowane w ciągłym obszarze pamięci", wspartego przykładem (opakowanie w metodę Main dodane przeze mnie):
static void Main(string[] args)
{
string[] texts = new string[10];
texts[0] = "Hello";
string[] lyrics = new string[10];
lyrics[0] = "YoYo!";
texts[1] = "World";
}
Pokazując potem w zrzucie pamięci, że stringi "Hello" i "World" są rozdzielone w pamięci stringiem "YoYo!". Może to trochę wprowadzać w błąd, bo powyższa tablica jest tablicą referencji do stringów i jako tako jest alokowana jako ciągły obszar pamięci. A to, że stringi wskazywane przez jej elementy nie muszą być obok siebie nie jest wtedy specjalnym zaskoczeniem - GC może je sobie np. w przyszłości poprzesuwać itd.
Co ciekawe, w podanym przykładzie kolejność obiektów w pamięci (tuż po ostatniej linijce, w odseparowanym przypadku bez innych alokujących wątków itd.) będzie wyglądać np. następująco:
Address Size
0000000102534380 36 => "Hello"
00000001025343a8 36 => "YoYo!"
00000001025343d0 36 => "World"
00000001025343f8 104 => ""string[] texts"
0000000102534460 104 => "string[] lyrics"
Wszystkie stringi (literały) CLR tworzy w tym przypadku na początku metody Main, jeszcze przed ich użyciem i ich takie czy inne zastosowanie (np. przypisanie do tablic) nie ma wpływu na rozłożenie w pamięci.