Nasza droga do Reactive Extensions – cz. 2 – Event Aggregator na ratunek

W poprzednim wpisie opisałem problem z wyborem architektury aplikacji przed jakim stanął nasz zespół. W drugiej części opiszę jakie problemy udało się rozwiązać dzięki wzorcowi event aggregator, jakie pozostały nie rozwiązane, a jakie powstały w wyniku jego użycia.

Czytaj dalej Nasza droga do Reactive Extensions – cz. 2 – Event Aggregator na ratunek

Nasza droga do Reactive Extensions – cz. 1 – Wstęp

Artykuł w wersji anglojęzycznej jest dostępny na blogu firmy Grape Up

Jeden z produktów jakie ostatnio rozwijaliśmy w naszym zespole, jest aplikacją desktopową opartą o rozbudowaną bibliotekę, która dostarczała spójne API do komunikacji, opartej o różne protokoły związane z telekomunikacją, co sprawiało że generowała naprawdę dużo sygnałów.

Czytaj dalej Nasza droga do Reactive Extensions – cz. 1 – Wstęp

Cloud Foundry – notatki – Wstęp

Rozpocząłem właśnie naukę nowej technologii – Cloud Foundry (CF). Aby przybliżyć czym jest CF umieszczam tutaj trochę marketingowego bełkotu. Możesz go pominąć klikając w link.

CF obiecuje, że aplikacje tworzone pod jej kątem mogą być wdrożone i uruchomione na chmurach różnych dostawców, zarówno tych publicznych takich jak: AWS, Azure czy Google Cloud, jak i na rozwiązaniach typu private cloud np. OpenStack czy nawet maszyna wirtualna virtual-box.

Czytaj dalej Cloud Foundry – notatki – Wstęp

Migracja na wordpress

Po wielu latach poddałem się i zaszlachtowałem swój robiony chałupniczo CMS na korzyść wordpressa. Mam nadzieję że sprawi to że będę częściej publikował.

Spotkanie z TaskCompletionSource – Cz. 2 Zdarzenia a zadania

Jedną z prób ogarnięcia asynchroniczności było wykorzystanie mechanizmu zdarzeń (event). Onegdaj istniały takie technologie jak WCF – służący do wystawiania na świat API po http oraz Silverlight, który miał robić to co dzisiaj Flash javascript. I jak się generowało klasy pozwalające korzystać z API WCF w SL to wynikowe klasy przypominały taki kod:

public class Proxy
{
void Method1(int argument);
event EventHandler<EventArgs<Result1>> Method1Completed;
event EventHandler<FailureEventArgs> Method1Failed;
void Method2();
event EventHandler<EventArgs<Result2>> Method1Completed;
event EventHandler<FailureEventArgs> Method1Failed;
}

Czytaj dalej Spotkanie z TaskCompletionSource – Cz. 2 Zdarzenia a zadania

Spotkanie z TaskCompletionSource – Cz. 1 I promise I will call back

Programowanie asynchroniczne w C# stało całkiem znośne od kiedy język ten posiada słowa kluczowe async i await. Rozwiązanie to tak udało się tak dobrze, że zaczyna pojawiać się w innych językach. VB.Net podobno już je ma (może któryś z czytelników już go używał i mógłby podzielić się swoimi doświadczeniami?), architekci projektujący C++ i Javascript także nad usilnie pracują na wdrożeniem podobnych mechanizmów.

Czytaj dalej Spotkanie z TaskCompletionSource – Cz. 1 I promise I will call back

Uruchamianie asynchronicznych metod bez await – ogólnie nie polecam

Podczas implementowania jednego z ficzerów aplikacji w pracy popełniłem metodę, w której uruchomiłem asynchroniczną metodę bez awaita.

Metoda miała i tak być odpalona w trybie „Fire and forget” więc uznałem wpisywanie tych kilkunastu znaków za stratę czasu i puściłem moduł na testy, które to testy moduł przeszedł. Jednak w przeciągu tygodnia użytkownicy zaczęli się skarżyć że aplikacja się przewraca w losowych momentach. Logi wskazywały, że mechanizm globalnej obsługi wyjątków loguje błąd o szczegółach podobnych do następujących:

Message:Wyjątków zadania nie zaobserwowano ani przez oczekiwanie na zadanie, ani przez uzyskanie dostępu do jego właściwości Exception. W wyniku tego niezaobserwowany wyjątek został wywołany ponownie przez wątek finalizatora.
Stack trace:

Caused by:

Message:Zgłoszono wyjątek typu ‚System.Exception’.
Stack trace:

Czytaj dalej Uruchamianie asynchronicznych metod bez await – ogólnie nie polecam

Nadmiarowo blokujące się przyciski z MVVM Light

MVVM Light jest bilioteką ułatwiającą tworzenie aplikacji wykorzystujących wzorzec MVVM. Jak do tej pory cieszy się moją sympatią w stopniu znacznie wyższym niż inne frameworki. Głownie dlatego, że nie robi rzeczy o które go nie proszę. Ostatnio jednak znalazłem ciekawe zachowanie tej biblioteki, które może powodować pojawianie się niedeterministycznych bugów.
MVMM Light posiada klasę RelayCommand pozwalającą szybko stworzyć pole typu ICommand (opis mechanizmu można znaleźć w wielu miejscach w internetach). Klasa ta posiada 2 parametry konstruktora: Execute typu Action – referencja do metody/lambdy wywoływanej po kliknięciu w przycisk, canExecute typu Func<bool> odwołanie do metody/lambdy wywoływane w celu określenia czy przycisk ma być włączony. Dodatkowo klasa posiada metodę RaiseCanExecuteChanged służącą do informowania przycisku o konieczności ponownego wywołania metody CanExecute.

Czytaj dalej Nadmiarowo blokujące się przyciski z MVVM Light