Wspólne modele dla dotnet i typescript

Trawa za płotem bardziej zielona

W Blazor’ze bardzo podoba mi się to, że brane są modele z dotnet (czy to api, czy to dowolna warstwa) i że każda zmiana na “backendzie” za darmo i od razu dostępna na “froncie”. Typescript ma fajne to, że można sobie silnie typować obiekty i że ten javascript jest takie ciut pewniejszy. Angular dla mnie mocno przypomina MVC więc z niego korzystam – ale! Jestem dobry w narzekanie; ale nie ma tego co ma blazor – a ja bym chciał. Bo takie przepisywanie modeli z dotnet na typescript to jest nudne, coś zmienisz, albo machniesz literówkę i trzeba szukać. Lubię też się wyręczać robotą kogoś innego 😉

google is your friend

Także poszukałem jak to ogarnąć. Co? No to, jak z klas w dotnet generować  klasy / kod do typescript, który można potem wykorzystać w projekcie na froncie.

Continue reading

Autofixture

Dlaczego

Gdy testuje kod często / zawsze pojawia się potrzeba generowania jakichś danych, czasem mają one sens, czasem są zupełnie niepotrzebne z punktu widzenia testu, a jednocześnie wymagane przez kod.
Pojawiają się wtedy najczęściej zapisy “foo”, “bar”,”dupa”, “not-important”, “asdqweadasdf0923409” czy inne.
Zamiast takich wartości można mieć inne, jakie? Nie ważne! Co?! 😲

Gdy testujesz kod, to potrzebujesz zawsze sprawdzić, czy tekst to “jakiś_tekst” jest równy “jakiś_tekst”? Czy może po prostu jest taki jaki powinien być nie ważne, jaką będzie mieć wartość? (to samo tyczy się wartości liczbowych)

Skąd brać dane

Jarek, cwaniaku, to jak? Ano można przez pisanie tego inline w teście, co spowoduje, że testy osiągną rozmiary amerykańskie 😉 i będą duplikowane w każdy teście.
Można przez mother object pattern (nie ma sensownego linka, poszukajcie różnych opisów) – to taki wielki obiekt, który zajmuje się generowaniem takich danych.
Można przez: autofixture 👈😲👏

Continue reading

Kompresja na azure?

Intro

Poprzednio (tutaj) było o gzipe w odpowiedziach z aplikacji, tym razem o jeszcze jednym gzipie.


Problem

Ściągam dużo danych (nie big data, ale sam za to płacę), trzymam to w wersji surowej na przyszłość, bo gdy będę chciał wyświetlić więcej informacji, to mogę przejechać od początku wszystkie dane, tak mam plan :). Część surówki zostaje przeparsowana i zamieniona na jsona. Jeszcze jedna część z tych danych będzie zwracana do klienta, a klient (frontend) ten obsługuje gzipa – także combo profit; mniej miejsca, mniejszy transfer.

Continue reading