Krótki wpis

Czytaj kod jak książkę

~ Jarosław Stadnicki ~ 14 Comments

Czytakpisanyblogbyłbyczytelnydlawas?
CzyMożeTakBędzieCzytelniej?
A_Może_Część_Z_Was_Preferuje_Taki_Zapis?
MgSZłŻITkLpjBdzZCztlnscNzTrz. (Aktualnie już nie pamiętam co tutaj napisałem)

Dlaczego gdy piszemy do ludzi potrafimy używać pełnych wyrazów, pełnych zdań, samogłosek i spółgłosek i nie skracamy. Natomiast gdy tylko siada jeden z drugim (ja nie jestem święty), piszemy P=ObsłużW(1,false, new Coś());
NIE MA SZANSY ŻE KTOŚ TO ZROZUMIE. NIE-MA.

Czy to jest wstyd pisać czytelny kod? Czy panuje u nas takie zdanie, że jak jesteś pro, to twojego kodu nikt nie może zrozumieć? Dostaje czasem jakiś kod do przejrzenia, żeby powiedzieć czy warto czy nie warto. Zdarzają się rozwiązania zadań oparte na if-else-if-else-if-else i globalnych zmiennych. Albo stringi wszędzie, czy 1,2,3,4,5,6 zamiast sensownego enuma.

Czemu tak jest? Lenistwo? Lans? Czy może tak jak napisał kiedyś mój dobry kolega Hanselman piszemy taki kod żeby czuć się nie zastępowalnymi. To totalny absurd! Ja chcę skoczyć i zmienić swój projekt, albo przez dowiezienie go do końca albo oddanie komuś po drodze. Staram się za wszelką uczynić go tak prostym żeby każdy mógł go przejąć.  Nie zmarnować nawet godziny na niepotrzebne tłumaczenie co i jak zrobiłem.  Gdzie jest to a gdzie jest inne coś.  Marzy mi się ze przychodzi ktoś w zastępstwo i mówi: wypas wszystko jasne, nie musisz niczego tłumaczyć, pokazywać czy demonstrować.  Wzorce są tam gdzie są potrzebne. Albo nawet ich nie ma. Bo może aplikacja była prosta.

Ale wiecie jest najważniejsze NAZWY.  Klasy, metody, warunki, zmienne, wszystko nazywa się zgodnie z tym co ma reprezentować robić i oznaczać.  Tak bym chciał.  Tak mi się marzy.  Wiem że droga jeszcze daleka ale nie podaje się i poprawiam.  Patrzę i czytam to co napisałem i się zastanawiam czy ja to jeszcze rozumiem czy to ma sens.  Czy ktoś to zrozumie?

Zmiany w ITAN są nie uniknione! #dajsiępozać

Przepowiedziana obsługa elementów w jQuery.on

~ Jarosław Stadnicki ~ Leave a comment

Jak jest

Zdarza się, nawet często się zdarza, że część strony na którą wszedł użytkownik będziemy podmieniać dynamicznie. Nie mam na myśli jakiegoś SPA, tylko odrobina dynamiczności. W tej dynamicznej części mamy jakieś element(y), który chcemy obsłużyć w skryptach. Aby nie przesyłać za każdym razem HTML i skryptów do obsługi, można na początku wypluć kod javascript i od razu przypiąć się na wydarzenia generowane przez takie eventy. Jak?

jQuery

W jQuery – które ciągle żyje i ma się dobrze, pomimo wielu-wielu-WIELU frameworków które powstały i upadły w tym czasie, posiada metodę on(). Umożliwia ona dopięcie się do elementu na jakieś wydarzenie, na przykład on(“click”,…..) Pozwala także na dołożenie dodatkowego filtra dla pod elementu (nie wiem jak lepiej mogę to słownie wytłumaczyć), $(“.container”).on(“click”, “.button”,…..). Oznacza to, że mogę powiedzieć: chce słuchać na przykład kliknięć z mojego kontenera, w dodatkowym warunkiem że źródłem kliknięć musi być jakiś guzik. O ile w momencie przypinania obsługi on-click, sam kontener musi już być, o tyle guzik (pod-element) może pojawić się później.

Przykłady

Continue reading →

Entity framework wspólna obsługa interfejsów modeli danych

~ Jarosław Stadnicki ~ 9 Comments

Model

Czasami tak projektujemy naszą aplikacje, że każdy model ma jedną lub kilka cech wspólnych. Od najbardziej oczywistych, jak na przykład ID, poprzez czas i datę utworzenia, modyfikacji, czy-usunięty, czy-opublikowany i inne czy-?

W zależności od poziomu lenistwa cechy te definiowane i utrzymywane są w każdej z klas z osobna lub w jednym lub-lub w kilku interfejsach który jest implementowany przez modele.

Do momentu pisania posta byłem gościem, który posiadał jeden wspólny interface, ale właśnie teraz do mnie dotarło, że może lepiej mieć kilka interfejsów dla modeli danych, I-ID-able, I-Create-able, I-Update-able, I-cośtam-able – blogowanie rozwija!

Część wspólna

Co więcej, obsługa części wspólnej może być zaimplementowana na różne sposoby, to również zależy od poziomu lenistwa. Można to robić ręcznie w każdej metodzie repozytorium, w klasach generycznych/bazowych dla repozytoriów, można AOP, można także w klasie kontekstu. Ja aktualnie rozwiązuje to właśnie tam w samej klasie bazy danych.

Poniżej kawałek kodu:

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!