Zabezpieczenie backendu przed nieautoryzowanym dostępem jest najważniejszym elementem kontroli dostępu. Weryfikacja ograniczona do strony klienta działa jak folia aluminiowa na obrazku:
Czytaj dalej Auth0 – Aplikacja do odpalania rakiet – backend
Jeszcze wstawię tutaj jakiś głęboki cytat
Zabezpieczenie backendu przed nieautoryzowanym dostępem jest najważniejszym elementem kontroli dostępu. Weryfikacja ograniczona do strony klienta działa jak folia aluminiowa na obrazku:
Czytaj dalej Auth0 – Aplikacja do odpalania rakiet – backend
W drugiej części serii opisałem jak zastosowanie wzorca Event Bus rozwiązało część naszych problemów, ale wprowadziła inne. W trzeciej i ostatniej części serii opiszę jak biblioteka Reactive Extensions (RX) rozwiązała te problemy, oraz dlaczego postanowiliśmy pozostawić niektóre obszary kodu bez zmian.
Czytaj dalej Nasza droga do Reactive Extensions – cz. 3. – MetaW 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 ratunekAby uruchomić aplikację w chmurze potrzebujemy dwóch rzeczy: aplikacji i chmury.
Aby wygenerować aplikację użyjemy linii poleceń i komendy dotnet.
dotnet new mvc --name Sample.Api.App
Jeżeli powyższa komenda nie działa prawdopodobnie powinieneś zainstalować .Net SDK
Czytaj dalej Cloud Foundry – notatki – Pierwsza aplikacja w chmurzeArtykuł 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ępTrzecią i ostatnią część artykułu poświęcam rzadkiemu ale bardzo trudnemu w analizie problemowi, który może pojawić się w czasie adaptacji API w wykorzystaniem TaskCompletionSource.
Czytaj dalej Spotkanie z TaskCompletionSource – Cz. 3 Niespełnione obietnice
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
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
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:
Caused by:
Message:Zgłoszono wyjątek typu 'System.Exception’.
Stack trace:
Czytaj dalej Uruchamianie asynchronicznych metod bez await – ogólnie nie polecam
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