Prosty generator memów.

Siemanko.

Jak zapowiadałem w poprzednim poście będę strał się wrzucać na github’a każdy kodzik, który napiszę, a tutaj będę opisywał powód jego powstania.

Spory portal na horyzoncie

Dostałem nie dawno  do wyceny draft portalu internetowego, który ma zamiar powstać. Jest w nim na prawdę dużo funkcjonalności, które trzeba spiąć w portal rankingowy. Na długiej liście funkcjonalności jest sporo takich, których nigdy nie robiłem więc ciężko mi się określić ile taki task może zająć. Takim taskiem jest m.in. generator memów. Korzystając z wolnego popołudnia spróbowałem coś zrobić i jak się okazało nie jest to takie trudne 😉 Oczywiście w najprostszej formie, ale dzięki temu wiem, że nie będę ślęczał nad tym wiele dni, a raczej zamknie się to w kilkunastu godzinach.

Jak?

Z użyciem elementu canvas i javascriptu. Nie ma co tu za dużo gadać. Wszystko jest na githubie.

gif-generator

Pjona!

Reklamy

Workaround umożliwiający czytanie widoków SQL w Entity Framework Core 1.1.0

Siemanko.

Od dawna nic nie piszę, ale postanowiłem to zmienić i co więcej, oprócz pisania planuje troszkę publicznie pokodować i pushować na github’a.

Często rozmyślam nad problemami pojawiającymi się podczas codziennej pracy z różnymi technologiami i równie często tworze w domu nowe solucje w Visual Studio tylko po to aby sprawdzić pomysły na rozwiązania wcześniej wspomnianych problemów. Ostatnio zadałem sobie pytanie czemu by tego nie wrzucać do sieci i w dodatku mieć jakiś temat na post na tym moim nieszczęsnym blogu? 😉 Dlatego od teraz każdy poryty kod bedzie lądował na githubie, a tu z kolei kilka zdań na temat przyczyn jego powstania 🙂

EF Core nie wspiera widoków SQL

Ostatnio w robocie piszę funkcjonalności związane z raportowaniem ilościowym danych wg wielu kryteriów. W projekcie używamy tylko i wyłącznie Microsoft’owego ORMa w wersji Core (gdyż aplikacja jest w Asp.Net Core). Przy tego typo raportach, które mam okazję implementować EF wypada bardzo słabo czasowo ponieważ where’owanie czy group’owanie po kolumnie w czwartej z kolei join’owanej tabeli powoduje, że ef musi wykonać całe query jeszcze przed uwzględnieniem where’a aby mieć zmapowane dane z tej czwartej join’owanej tabelki żeby w końcy wykonać na tych danych where’a. 🙂 Wiem, nieźle zakręciłem, ale chodzi finalnie o to że mimo iż w wyniku dostaniesz 10 rekordów to EF może wcześniej wykonać query na 10000 tys. rekordów żeby mieć dostęp do danych z którejś z kolei zjoinowanej tabelki, które zostały uwzględnione w klauzuli where :). W celu poprawy wydajności pomyślałem żeby stworzyć widok SQL, w którym będę miał wszystkie potrzebne kolumny. Niestety EF Core nie wspiera (jeszcze) widoków w przeciwieństwie do EF 6.

Workaround

Wymyśliłem sobie kontekst sklepu. W sklepie jest klilka produktów, które sa pogrupowane w kategorich. Produkt może byc w wielu kategoriach i kategoria może mieć wiele produktów więc mamy tabelkę łączącą relacje wiele do wielu. Oprócz tego produkty sa powiązane relacją jeden do wielu z tabelka zdjęć. Zdjęcie może być tylko dla jednego produktu, a produkt może mieć wiele zdjęć. Chcę pobrać listę kategorii z ich podstawowymi informacjami wraz z jednym losowym produktem i jego zdjęciem oznaczonym jako IsMinPhoto (czyli miniaturka).

Ef Core umożliwia wykonania selecta z czystego SQL poprzez metodkę FromSql(). Metodka ta może zostać wywołana na propercie DbSet<> obiektu DbContext. Utworzyłem sobie zatem model zawierający kolumny, które będą w widoku. Po utworzeniu bazy zostanie utworzona taka tabela jednakże będzie ona zawsze pusta. Tabela wymaga posiadania klucza Id na podstawie, którego EF mapuje rekordy z bazy danych na obiekty jednakże widok nie posiada swojego Id, gdyż jest to tylko zestaw kolumn z innych tabel. Jako klucz dla modelu odwzorującego widok dodałem pole typu string. Bardzo ważne jest aby odpowiednik tego pola znalazł sie także w widoku z tabelki, której rekordy się nie powtarzają w żadnej relacji (w moim przypadku tabelka Photo). Następnie utworzyłem widok SQL w SQL Managment Studio z użyciem designera.

model

Model EF

Bez tytułu.jpg

Widok SQL w SQL Mangment Studio

Czytanie z widoku

queryview

Podsumowanie

Zrobiłem porównanie czasowe z normalnym zapytaniem zrobionym przez Linq na ORMie i przy łącznie raptem kilkunastu rekordach we wszystkich tabelach wyciąganie danych z widoku jest 3krotnie szybsze i w Sql Profilerze widać tylko jedno zapytanie natomiast gdy robił to ORM zapytań w tym przypadku było 3.

Kodzik z testami do uruchomienia znajduje się na githubie.

Pjona!

Asp.Net Core 1.0 – camel case domyślnym formatowaniem Jsona w Mvc.

Siemanko.

W wersjach RC (Rc1 i Rc2) przy zwracaniu danych z API (mvc) zserializowanych do jsona za pomocą metody:

Json()

obiekty były (defaultowo) formatowane bez zmian wielkości liter w nazwach

2

4

W wersji RTM defaultowym ustawieniem formatowania jest camel case:

2

1.png

Jeśli rozwijacie projekt od wersji RC i planujecie go przenieść na wersję RTM to może Wam to zajebiście namieszać 🙂 Jednak niech będą spokojne Wasze rozczochrane – wujcio ma rozwiązanie ;). W klasie Sturtup.cs w metodzie ConfigureServices, w miejscu gdzie macie dodane Mvc należy troszkę dopisać do tej linijki:

3

Od teraz będzie wszystko po staremu:

2

4

Pjona!

Asp.Net Core – o migracji z RC1 do RC2 słów kilka.

Siemanko.

Dziś kilka wskazówek jak podejść do próby migracji projektu z wersji RC1 do RC2. Celowo napisałem „próby” ponieważ nie ma pewności, że Ci się to uda 😉 Wszystko zależy od struktury Twojego projektu oraz od Twojej odporności na dziwne błędy uniemożliwiające kompilację, które nie są zgłaszane przez IDE. Subiektywnie podzieliłem operacje migracji na dwa przypadki:

  • kiedy masz tylko web application
  • kiedy masz web application z referencjami do class library packages

Oczywiście musisz mieć zainstalowany .NET Core. Możesz to zrobić instalując update w Visual Studio lub pobierając go tutaj.

Samo Web Application

W wersji RC1 web application było jednym template’em.

3

Template web application w wersji RC1

Na poziomie tworzenia należało wskazać czy ma to być aplikacji Asp.Net 5 czy poprzednia

4

Następnie w pliku project.json należało wskazać runtime (clr lub coreclr, lub oba).

W wersji RC2 mamy dwa template’y web application – jeden dla .NETu, a drugi cross platform

2

Proponuję Ci utworzyć odpowiedni template (jeśli w Twoja aplikacja RC1 jest cross platform i korzysta z dnxcore to wybierz .NET Core, jeśli z samego dnxa to .NET Framework). Przejdź do pliku global.json nowo utworzonej solucji, skopiuj sdk version i wklej w to samo miejsce w swoim projekcie RC1.

1.png

global.json w wersji RC1

 

 

1

global.json w wersji RC2

Oczywiście wersja sdk 1.0.0-preview1-002702 w RC2 jest taka na dzień pisania posta.

Przejdź do katalogu C:\Users\nazwa_usera i skasuj folder .dnx. Tak, skasuj. Dnxa już nie ma i wszystko co jest w tym folderze już nie jest potrzebne, a może tylko generować jakieś trudności.

Dostosuj swój project.json do tego, który jest w wygenerowanym nowym szablonie i zacznij zmieniać namespace’y paczek w sekcji dependencies. Tutaj musisz zdawać się na IDE i błędy, które zgłasza (np. namespace’y z AspNet trzeba zmienić na AspNetCore itp.). Jak już uda Ci się doprowadzić error list do pustki to przejdź do package manager console, a w nim do folderu aplikacji i wpisz dotnet restore. Powinny zacząć pobierać się wszystkie paczki nugetowe. Reaguj na błędy, restoruj paczki i tak w kółko do skutku 🙂 Zamknięcie Visuala i ponowne otwarcie jest jak najbardziej wskazane 😉

Web Application z referencjami do class library packages

Tu już jest gorzej ponieważ w RC2 nie ma tego wynalazku – class library package z niebieską ikonką i plikiem project.json

1.png

Class library dla Asp.Net Core w wersji RC1

Teraz mamy normalne „zielone” class library

1

Class library w wersji Asp.Net Core RC2

Jak widać na zdjęciu mamy także dwa typy class library – dla .NET Core i dla .NET Framework. Aby nasz projekt zabanglał w RC2 to niestety musimy utworzyć całkiem nowe class library i pokopiować do nich klasy oraz dodać wszystkie paczki nugetowe przez Nuget Package Manager (w poprzedniej wersji można to było zrobić w pliku project.json). Należy pamiętać aby zaznaczyć ckeckbox Include prerelease podczas wyszukiwania paczek.

Podsumowanie

Życzę Ci powodzenia i wytrwałości. Pamiętaj jednak, że zawsze możesz utworzyć całą solucję od nowa i pokopiować pliki, albo po prostu rzucić to wszystko i wyjechać w Bieszczady 😉

Pjona!

„Hub could not be resolved” czyli kwiatuszki w Asp.Net Core RC2

Siemanko.

Całkiem nie dawno pisałem o tym, że udało mi się przejść na wersję RC2 frameworka Asp.Net Core. Wersję, której żywot określono na krótko bo pod koniec czerwca ma wyjść już RTM. Z tego względu wydawałoby się, że jest to już dopieszczona wersja i wszystko jest w niej cacy… ale niestety.

Problemy z SignalR

W wersji RC1, w moim projekcie zacząłem się już komunikować poprzez SignalR między apką mobilną, a serwerem. Po upgrade’dzie projektu do wersji RC2 po chwilce przerwy przysiadłem znowu do pracy i ku mojemu zdziwieniu po próbie połączenia się apki z serwerem aplikacja mobilna się wywalała. Zapewne znasz to uczucie gdy nie zmieniłeś choć jednej linijki kodu, IDE nie sypie errorami, a coś co działało jeszcze wczoraj z niewiadomych przyczyn przestało. Po kilku godzinach prób zacząłem debugowanko na serwerze. W Sturtup.cs przed deklaracją SignalR zamieściłem kilka linijek kodu aby następne wywołanie na pipeline złapać w try catch:

1

Zacząłem googlować i doklikałem się do issue na githubie. Otóż w wersji RC2 popsuto coś co działało w RC1 😉

Workaround

Gość na githubie podsunął mi tymczasowe rozwiązanie. Otóż bug jest w klasie DefaultAssemblyLocator.cs, który został już poprawiony, ale znajduje się w paczce RC3 z referencjami do inncyh paczek RC3, które zarazem będą się gryzły z RC2Skopiowałem kod tej klasy i umieściłem go w swoim projekcie w nowo utworzonej klasie o nazwie HubCouldNotBeResolvedWorkaround (możesz nazwać jak chcesz). W Sturtup.cs w metodzie ConfigureServices tuż przed wywołaniem

services.AddSignalR();

należy umieścić linijkę 

services.AddSingleton<IAssemblyLocator, HubCouldNotBeResolvedWorkaround>();

Ten kod oznacza ni mniej ni więcej jak dla każdej zależności IAssemblyLocator wstrzyknij obiekt HubCouldNotBeResolvedWorkaround, który ma być singletonem w ramach całej aplikacji. W ten sposób IAssemblyLocator  z paczki SignalR RC2 z bugiem został zastąpiony poprawionym z wersji RC3 bez konieczności upgrade’u całego projektu do RC3 (która jest tylko na deweloperskich serwerach Nuget)

Podsumowanie

Mam nadzieje, że dzięki temu wpisowi zaoszczędzisz kilka godzin na kminienie co może być nie tak – tak jak ja.

Pjona!

Projekt Asp.Net Core po wielu godzinach przeniesiony do wersji RC2.

Siemanko

W sobotę napisałem, że zaczynam atakować mój projekt back’endowy w celu przeniesienia go na .NET CLI i wyswobodzenia go od skasowanego DNX’a – czyli przejście na oficjalną wersję RC2 frameworka. Nie trwało to kilka dni jakby wskazywał na to kalendarz, ale krócej bo właściwie znalazłem czas aby przysiąść do tego tylko trzy razy. Pierwszy raz był we wspomnianą sobotę i to posiedzenie zakończyło się moją klęską, i niezłym wkurwieniem ocierającym się o rezygnację z programowania i wzięcia się za grę w brydża 😉 Drugi raz był wczoraj wieczorem gdzie przyjąłem nieco inną taktykę, która także okazała się nieskuteczna jednak doprowadziła do wyklarowania się decyzji o utworzeniu nowej solucji wraz z nowymi projektami i przenoszeniu do nich klas z istniejącego projektu. Tym się właśnie zająłem dziś i mogę powiedzieć, że się udało. Projekt się kompiluje oraz uruchamia.

1

O tym co się zmieniło oraz najważniejsze – jak to przeniosłem – napisze po weekendzie. Teraz mogę Ci powiedzieć tylko tyle, że olej sobie dokumentację migracji przygotowaną przez ekipę Asp.Net Core. Opisuje ona różnice w plikach konfiguracyjnych i takie tam pierdololo, ale nie mówi jak przenieść istniejący projekt ASP.NET Core RC1 do ASP.NET Core RC2. Jak będziesz grzeczny to ja Ci napiszę 😉

Pjona!

Pierwsze podejście do upgrade’u projektu Asp.Net Core – from DNX to .NET Core Cli

Siemanko

Piękny, słoneczny dzień dziś (przynajmniej u mnie) dlatego postanowiłem sobie go nieco zjebać i spróbuje przenieść aplikacje serwerową do najnowszej wersji frameworka czyli Asp.Net Core 1.0 Rc2. Niby kolejny release candidate, ale kompletnie inny pod spodem. Cóż, ewolucja 🙂 Dam znać niedługo czy jest w ogóle możliwa migracja z Rc1 do Rc2 bez nowych siwych włosów i czy w ogóle się da. Microsoft’owe ludki twierdzą, że się da i nawet odziwo przygotowali do tego jakąś dokumentację. Wszystkiego możesz się dowiedzieć tutaj. Życz mi powodzenia 🙂

Pjona!