RZE.NET #4

Zapraszamy na czwarte spotkanie RZE.NET. Spotkanie odbędzie się w biurze Sii Polska, al. Tadeusza Rejtana 20B Rzeszów (Resovia Office, 3 piętro).

Przygotowaliśmy dla was 2 prezentacje.

1. "Async na korutynach i fiberach - projekt Loom w C#"
Async sprawia mnóstwo problemów - wymaga specjalnego typu w zwracanej metodzie, może w dowolnym momencie zmienić wątek, używa globalnego stanu i wiele innych. Czy da się lepiej? Czy możemy zrobić async/await bez tego całego zamieszania? W trakcie wystąpienia przyjrzymy się asyncowi, jak jest zaimplementowany, jakie stwarza problemy, a także poszukamy lepszych rozwiązań. Zaimplementujemy mechanizm od nowa przy użyciu monad, korutyn i fiberów, i sprawdzimy, czy to rozwiązanie jest lepsze od podejścia opartego na wątkach. Luźno związane z projektem Loom ze świata JVM, gdzie async jest implementowany właśnie w taki sposób.

Adam Furmanek
Nazywam się Adam Furmanek i od dekady jestem inżynierem oprogramowania. W swojej karierze zajmowałem się logistyką, e-commercem, analizą danych, uczeniem maszynowym i szeroko rozumianą inżynierią oprogramowania. Zawsze jestem zainteresowany szczegółami technicznymi używanych przeze mnie narzędzi, aby móc lepiej je wykorzystać, debuguję, dekompiluję, deasembluję, analizuję modele pamięci, problemy z wielodostępem i inne ukryte szczegóły implementacji. W wolnym czasie gram na pianinie, jeżdżę na rolkach i bloguję na http://blog.adamfurmanek.pl

2. "Debugowanie w sytuacji beznadziejnej"
Debugowanie kodu, który właśnie piszemy, wydaje się łatwe - uruchamiamy aplikację z odpowiedniego narzędzia (np. Visual Studio), wstawiamy pułapki i już!

Prawdziwa zabawa zaczyna się, gdy stworzymy wersję RELEASE, zainstalujemy na innym komputerze, zoptymalizujemy kod, opublikujemy jeden plik lub kompilujemy bezpośrednio do kodu maszynowego. A co jeśli aplikacja nie działa tylko na jednym komputerze? Co jeśli problem pojawia się losowo raz na tydzień? A gdy przyczyną błędu jest zewnętrzny kod? Celem prezentacji jest pokazanie metod i narzędzi, które pozwalają namierzyć tego typu perełki i, co może nawet ważniejsze, automatyzować operacje. Niech debugger pracuje dla nas, a nie my dla niego.

Paweł Dyl
Architekt i programista z kilkunastoletnim doświadczeniem, głównie w obszarze .NET i SQL, ale także C++, Python, PowerShell i kilka innych. W pracy zajmuję się systemami bezpieczeństwa oraz zastosowaniem algorytmów sztucznej inteligencji do wykrywania nieprawidłowych zachowań, a w wolnych chwilach naturalną inteligencją swoich dzieci.