logowanie

Logowanie dla leniwych

~ Jarosław Stadnicki ~ Leave a comment

Nie lubię logowania

Nie lubię logowania — brudzi mi w kodzie; narzekam, gdy podczas ratowania produkcji brak logów — jak żyć?!

Jestem leniwy, nie lubię pamiętać o tym i tamtym — lubię, gdy rzeczy dzieją się same i nie muszę sobie zawracać tym głowy. Ale bez przesady! Logi to najgorsze i najlepsze co może spotkać programistów — z jednej strony logi zaśmiecają kod, z drugiej strony dają podgląd na to, co użytkownicy wymyślili na produkcji.

AOP

Logowanie przy pomocy AOP oczyszcza kod w przypadku typowego i klasycznego podejścia do logów, ok — może to zrobić. Często szukam w logach tego, co zostało uruchomione i z jakim parametrem, aby zrozumieć, co poszło nie tak. Nie lubię ^C^V takiego kodu na początku każdej metody. Niestety nie znalazłem dobrego rozwiązania AOP (czytaj darmowego) a interfejs IIntercept z jakiegoś powodu nie chce zostać uruchomiony (ale jest tworzony — kiedyś to zrozumiem); z tego powodu przy pomocy internetów znalazłem DispatchProxy które świetnie robi swoją robotę.

DispatchProxy

Otóż chciałbym mieć możliwość logowania tego, co i jak się wywołuje z możliwością włączenia / wyłączenia detali (poziomy logowania w moim przypadku, lub inna forma konfiguracji). Chce móc przeczytać logi i dowiedzieć się co się wywołuje i z jakim parametrami, dla każdej metody, dodatkowo bez potrzeby modyfikacji kodu, gdy dana metoda się zmieni.

Można to zrobić przy pomocy DispatchProxy które przechwyci wywołanie metody i umożliwi wykonanie dowolnego kodu; przed; po czy też podczas błędu.

Otóż taka klasa opina ładnie swoją docelową klasę T , a następnie podczas tworzenia zwraca takie proxy, udając klasę typu podstawowego. Tutaj uwaga: konstruktor musi być pusty, a ewentualne przekazanie parametrów i ich  przypisanie następuje w metody fabrykującej (wewnątrz if)

Gdy użytkownik takiej klasy wywołuje metodę docelową, na proxy wcześniej zostanie zawołane Invoke gdzie można czynić cuda.
Ja na przykład na poziomie `Information` loguje nazwę wywoływanej metody, a na poziomie Debug dorzucam także nazwy i wartości przekazanych argumentów.

Rejestracja

Piękne jest to, że DispatchProxy nie wymaga zewnętrznych bibliotek i działa na czysto z .net. Zależność do klasy rejestruje w taki sposób:

Akcja

Działa to tak:

Tutaj przykład konsumpcji oraz wykorzystania przykładowego serwisu

A tutaj logi:

Serwis jest nudny do bólu i prawie o nim zapomniałem:

Siup

W tak przygotowanym kodzie, zależności rejestrowane z pomocą logera powinny samodzielnie wrzucać informację o tym, co i jak się wykonało. Oczywiście można dodać sobie flagi do optymalizacji tego, czy przed, czy po co w sytuacjach wyjątkowych ma się logować i na jakim poziomie. Warto także pomyśleć o tym, jak takie logi ze sobą łączyć za pomocy correlationId – ale to pozostawiam już waszej wyobraźni.

 

ps.
dzisiaj bez obrazka

Rozwiązywanie zależności atrybutów w net core mvc

~ Jarosław Stadnicki ~ Leave a comment

Random image, hand drawn

Dobry .net core

Core wprowadza milusie rozwiązania ułatwiające życie programistów, jednym z nim jest rozwiązanym problem zależności w atrybutach w .net core mvc. Otóż jest sposób na wstrzykiwania zależności do atrybutów mvc. Łot? Już nie będzie bolało? Nie trzeba więcej bleh-bleh-BLEH service-locatora, aby dostać się z miejsca gdzie dzieje się magia do mięska.

Jak? Odrobinę inaczej niż standardowym .net mvc. Continue reading →

Feature request jak to ugryźć

~ Jarosław Stadnicki ~ 1 Comment

Mało czasu

Czas goni, a rąk i głów i czasu do implementacji ficzerów brakuje. Co wtedy robić, od którego zacząć robić żeby było lepiej dla aplikacji i dla ludzi, a na końcu dla mnie i mojego portfela?

Zamiast zastanawiać się w ten sposób, może warto oddać głos użytkownikom? Niech oni klikają w system, system zbiera te informacje i w krótkim czasie można się dowiedzieć co było klikane najczęściej i właśnie na tym skupić kolejna działania rozwojowe.

Mój pomysł

Jak ja do tego podszedłem? W poprzednim wpisie pokazałem jak wygląda u mnie pasek pod każdym w rss (http://jaroslawstadnicki.pl/2016/04/font-awesome-w-mvc/).
Kod odpowiedzialny za wyświetlenie tego paska wygląda w taki sposób: Continue reading →

Kim jest właściciel claimów #dajsiepoznac

~ Jarosław Stadnicki ~ 1 Comment

Logowanie jest proste

Pisałem jak zalogować się przy pomocy fejsa, gógla, twitera (logowanie-przy-pomocy-facebook-twitter-czy-google-owin-katana-na-asp-mvc-5). Sprawa stosunkowo łatwa, gdy się już to raz zrobi i działa. Microsoft daje także kilka swoich klas, które “ułatwiają” zarządzanie takimi kontami. Ale gdy jest się ciekawym, ma się za dużo czasu, albo się nudzi, albo…. Wtedy, wtedy zaczynają się schody. Jasne użytkownik jest zalogowany, mam zapewnienie że Jarek to Jarek, mam inne rzeczy. Ale kto mówi, że ja to ja? Skąd mam wiedzieć id=019283091283091823 i id=019283091283091823 pochodzą z różnych systemów? Czy ktoś i gdzie się podpisuje: “To byłem, ja Jarząbek!”

Otóż każdy z claim jest podpisane, powinny być, u mnie są, wystarczy wziąć pierwszy który posiadamy, znaleźć ten który posiada właściciela, sparsować i voila, jest:

Sprawdzam!

Zaczynając od enuma (@3) mamy listę wspieranych loginów, ułatwienie (usztywnienie) żeby nie rzucać stringami w powietrzu. Następnie klasa odpowiedzialna za autentykację posiada metodę, która z zalogowanego użytkownika wyciąga claimy, a w nich szuka (@16) tego który posiada metkę. Metka następnie jest parsowana na wspierany typ providera (@17) i zwracana do klienta klasy.Works on my machine – not tested on production.

Po co?

Kiedy jest to przydatne? Otóż może się okazać, jest różne osoby dostaną ten sam id, ale z dwóch różnych providerów, nie chciałbym aby mogły się zalogować na to samo konto. Tyle

Miłego weekendu, u mnie pada.

Entity framework – obowiązkowa minimalna konfiguracja #dajsiepoznac

~ Jarosław Stadnicki ~ 7 Comments

Lazy loading

Kiedy korzystamy z EF należy pamiętać o tym, aby zawsze wyłączyć leniwe ładowanie (lazy loading) w przeciwnym wypadku za każdym razem gdy będziemy sięgać po dane które leżą w innej tabeli niż ta, która została początkowo zaciągnięta z bazy danych EF zrobi to za nas. Brzmi fajnie, ale gdy pomyślicie że taka operacja może wykonać się w pętli, pomysł szybko przestaje być tak miły. N wykonań pętli N pojedynczych zapytań do bazy danych. Minusem wyłączenia lenia w EF jest to, że jeśli nie powiemy wcześniej EF że chcemy wykonać operację JOIN nie będziemy mieli dostępu do danych z innej tabeli.

Kod wygląda tak, pierwsze zapytanie bez, drugie z instrukcją JOIN

Linia (@22) wyłącza lazy loading. Linia (@12) wyciąga z bazy tylko osoby, jesli pole Properties będzie nullem. Linia (@13) wyciąga z bazy osoby oraz wykonuje operację JOIN, lista cech w osobie zostanie wypełniona pasującymi wartościami. Ostrzeżenie: ponieważ w przykładzie wywołanie jest jedno pod drugim, gdy postawi się breakpoint po obu (@14), referencja osoby zostanie zaktualizowana. Może się więc okazać, że w przypadku p1 oraz p2 pola properties będą już ustawione. Zalecam w przypadku samodzielnego sprawdzania przykładu, postawić breakpoint odpowiednio w liniach @12 oraz @13 i podejrzenie wartości property.

Logowanie

Często pojawia sie problem logowania zapytań które generuje EF, zawsze szukałem, paczek, rozwiązań czy gotowych bibliotek. Aż pewnego pięknego razu na SO znalazłem odpowiedź, która wygląda tak jak w linii 21. Najprościej jak się da, dopinam się do wewnętrznego logera oraz wypisuje na Debug.Trace informacje o zapytaniach, wyglądają one tak:

Widać tam wywołania dwóch zapytań (@12i @13) prosty oraz ten z JOIN, widoczny jest czas potrzeby na wykonywanie operacji jak i informacje o rozpoczęciu i zakończeniu połączenia. Wszystko co potrzeba aby sprawdzić czy zapytanie zostało wygenerowane w akceptowalny przez nas sposób – me gusta!