programowanie

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!

Good enough software moim zdaniem

~ Jarosław Stadnicki ~ 7 Comments

Bogowie

Słuchając wystąpień wujka Boba czy innych wielkich mówiących o czystym kodzie, solidzie, testach, architekturze, devopsach i innych słowach kluczowych można popaść w depresję: “O żesz, mój kod nigdy taki nie będzie, lepiej nikomu go nie pokaże, sam zamknę się w piwnicy i do końca życia będę żywic się ziemniakami i robakami które będą do mnie przypełzać”.
Czy naprawdę tak jest? Czy kod który piszemy musi być jak kryształ?

Obrazek

Słuchając różnych podcastów, usłyszałem taka myśl: Gdy przychodzi do was klient i mówi, że potrzebuje zrobić dziurę w ścianie, żeby wkręcić haczyk, żeby na nim powiesić obrazek. Gdy zaczynają się tańce godowe sprzedawców którzy chcą sprzedać mu komplet wierteł, wiertarek, zaprawy murarskiej, farby, etc. Może pojawić się firmą z którą przegracie, bo zaoferują mu taśmę dwustronnie przylepną. Klient nie chce dziury w ścianie, chce obrazek na ścianie.
Podobnie z naszym wyścigiem zbrojeń, jasne że fajnie mieć super hiper wypasioną architekturę, testy które sprawdzają wszystko, continuos-wszystko i jeszcze więcej, tylko która z tych rzeczy jest tą taśmą dwustronną?

Continue reading →

Programistyczne wywołanie debuggera

~ Jarosław Stadnicki ~ 5 Comments

Jeśli zdarzyło wam się kiedyś debugować przez Console.WriteLine(…) lub dzielić przez zero, tylko po to aby odpalił się debugger I podpinać do tego visual studio to ta linijka będzie dla was na wagę złota:

System.Diagnosticks.Debugger.Launch();

Gdy wykonywany kod dojdzie do tej linijki pojawi się okienko z pytaniem czy chcesz debugować aplikację, po “jesie” VS dopina się do procesu I normalnie można korzystać z dobrodziejstw inwentarza. Sztuczka przydatna gdy kod jest uruchamiany przez zewnętrzny proces, a wy dostarczacie jedynie bibliotekę z kodem.

Debugger.Launch() uwalnia od wszelkiej maści dzielenia przez zero, pisania na konsole, rzucania wyjątków, robienia MessageBox, żeby zaczekało na dopięcie debuggera, sleepów, etc. Złoto!

ps. Może ktoś nie wie, ale w javascript jest coś takiego jak debugger;

Nauka uczenia się i rozwijania się część 3 – podcasty

~ Jarosław Stadnicki ~ 3 Comments

Oskar i Kokos zebrali w swoich postach całkiem sporo materiału na temat skąd i jak można czerpać wiedzę i o tym jak się uczyć. Ich wpisy można znaleźć:

Oskar: Nauka uczenia (się)
Kokos: Jak się rozwijać?

Ja dodam od siebie jeszcze jedną rzecz, która nie została wcześniej wymieniona, a moim zdaniem daje sporo. To podcasty. Słuchając ich nie tyle uczę się danej technologii, czy jednego słusznego rozwiązania, a raczej dowiaduje się o innych, alternatywnych do codziennej pracy, rozwiązaniach które może kiedyś da się wykorzystać. Moja lista podcastów:

  • .Net rocks – pierwszy podcast którego słuchałem, skupia się wokół .net
  • A moment of science: Audio – krótkie historyjki ze świata technologi i ogólnej wiedzy
  • Being the worst – mam na liście, ale jeszcze nie dotarło do odtwarzania
  • Coding Blocks – techniczny podcast, skupiający się na .net
  • Full Stack Radio – różnie bywa, czasami wywiady z autorami produktów/bibliotek, czasami opowieści o architekturze i programowaniu. Warto posłuchać tych opowieści, mnie zainspirowały do kolejnego wpisu
  • Hanselminutes – sam Hanselmann, kiedyś technicznie, teraz równouprawnienia, szczerze mówiąc od jakiegoś czasu najczęściej przeskakuje, przykro mi Scott
  • Herding Code – technologicznie, różne osoby, różne technologie
  • JavaScript Jabber – javascript
  • Mała Wielka Firma – podcast o budowaniu własnego przedsiębiorstwa, bardzo fajnie i ciekawie opowiadają
  • Radiolab – opowieści, świetnie przygotowane słuchowiska, czasem moralizujące, czasem opowiadające historię leków, czasem po prostu zabawne, przesłuchałem od początku wszystkie
  • TED Radio Hour – TED w radiu
  • ThoughtWorks – opowieści z firmy, liczę że będą kiedyś ciekawe rzeczy

I ile wcześniej słuchałem każdego epizodu z każdego źródła od deski do deski, to teraz mają ich duży wybór pomijam te, które nie są tak bardzo porywające. Zdarza się także, że jedna osoba występuje w różnych wywiadach dla różnych podcastów, a mówi o tym samym, wtedy również szkoda czasu.

Jeśli chodzi o aplikację do podcastów to szczerze polecam Podcast Addict dla androida. Używam od 2 lat I nie zamierzam zmieniać na nic innego.