Rozpoznawanie kategorii i koloru z tekstu ogłoszenia oraz pierwsze testy jednostkowe w Asp.Net Core 1.0

Siemanko

Jak już wcześniej wspominałem aplikacja mobilna nie będzie wymagała deklarowania kategorii czy koloru ubrania w momencie tworzenia nowego ogłoszenia. Niewątpliwie te dane byłyby bardzo przydatne w celu filtrowania wyników wyszukiwania oraz przy Machine Learning, które miałoby ogarniać najchętniej przeglądane ciuchy przez użytkownika w celu podpowiadania mu tego co mogło by go zainteresować (jeszcze nie ruszyłem z ML, ale mam to w planach ;)). Tą robotą zajmie się system.

Słowniki ze słowami kluczowymi dla kategorii i koloru

Wyrażenia regularne nie wchodzą w grę ponieważ nazwy kategorii i kolorów są przeróżne, więc dla każdej opcji musiałbym napisać oddzielne wyrażenie co przy późniejszej potrzebie modyfikacji okazało by się, że to niezły pain (nie wkurzają Cię te moje angielskie bądź pseudo angielskie wcinki? ;)). Dlatego wymyśliłem to najprościej jak mogłem i opiszę to na przykładzie kategorii.

2

Fragment słownika kategorii

Kluczem jest początek nazwy kategorii, a wartością lista słów pasujących do wzorca z klucza wraz z różnymi odmianami, przy czym pierwszym elementem jest zawsze słowo kluczowe, które będzie wiązane z ogłoszeniami. Taki słownik będę mógł zawsze zmodyfikować dodając kolejne klucze bądź rozszerzając listy wartości dla klucza. Jedynym ograniczeniem będzie tylko to, że nie będę mógł zmienić pierwszych elementów z list wartości bo te będą mogły być już zapisane w bazie.

Rozpoznawanie kategorii i koloru

Najlepiej będzie jak rzucisz okiem na kod.

3

Lecę foreach’em po kluczach danego słownika i sprawdzam czy zawiera się on w tekście ogłoszenia. Jeśli tak to lecę kolejnym foreach’em po wartościach dla danego klucza i sprawdzam czy którykolwiek ze stringów znajduje się w tekście. Jeśli tak to do listy wynikowej przypisuje pierwszy element z listy wartości. W ten sposób wyłapuje hasła kluczowe, które potem są wyciągane z bazy lub zapisywane jeśli jeszcze takich nie było, a następnie wiązane z ogłoszeniem.

Side Waffle, XUnit i Moq – czyli ostre testowanko 😉

Aby sprawdzić czy to co opisałem wcześniej rzeczywiście działa postanowiłem wreszcie napisać pierwsze unit testy. Do tego celu doinstalowałem sobie do VS extension’a Side WaffleJest to paczka z ogromem różnych templatów, o których nie będę pisał prócz jednego – xUnit.

3

Jest to już skonfigurowany pod DNXa projekt testowy z xUnit. Od razu można jechać z testami. Co bardzo ważne – aby uruchomić napisany test trzeba otworzyć Test Explorer’a i zbudować projekt – w innym przypadku VS nie ogarnie, że są jakieś testy.

4

Przykładowy teścik

Nie jestem jakimś szpeniem od testów, ale dzięki dobrociom od xUnit takim jak [Theory], pisząc 18 testów w rzeczywistości mam przetestowane 83 przypadki.

Podsumowanie

Dzięki testom jednostkowym dla rozpoznawaczki słów kluczowych wyłapałem kilka błędów już na etapie jej pisania, które szybciutko poprawiłem 🙂

Unit testy są cool!

Pjona!

Reklamy

MobileSecondHand – autentykacja po stronie serwera cz. 2.

Siemanko.

Dzisiaj druga część o autentykacji po stronie serwera. W części pierwszej napisałem, jak wygląda proces autentykacji za pomocą tokena, a dziś o tym jak i kiedy go generuje.

Przy tworzeniu nowej aplikacji webowej Asp.Net Core 1.0 z template’u w VS 2015 z automatu jest zaznaczona opcja indywidualnych kont użytkowników w sekcji autentykacji. Skutkuje to dodaniem do projektu paczki „Microsoft.AspNet.Identity.EntityFramework” (wraz z zależnościami), utworzeniem pierwszej migracji z tabelami związanymi z userami, oraz kontrolerów ze wstępnymi logikami do rejestracji, logowania i zarządzania kontem użytkownika. Żeby nie wywarzać otwartych drzwi oczywiście skorzystałem z tych dobrodziejstw w moim projekcie (po swojemu). Także przy tworzeniu oraz szukaniu usera w bazie korzystam z wbudowanych serwisów UserManager<T> oraz SignInManager<T>. Za pomocą ich metod mogę zapisać użytkownika do bazy, pobrać go, sprawdzić czy hasło jest prawidłowe itp.. Ogólnie sporo roboty do przodu.

Rejestracja i logowanie standardowe.

Rejestracja i logowanko sprowadza się do odebrania view modelu, wywołania odpowiednich metod z wcześniej wspomnianych serwisów i zwróceniu tokena.

1

2

3

Na ostatnim screenie jest metodka tworząca i zwracająca token. Odpowiedzialny za całe zamieszanie jest JwtSecurityTokenHandler z przestrzeni nazw System.IdentityModel.Tokens.Jwt.

Rejestracja i logowanie z facebookiem

Token autentykacji od fejsa pobieram w apce mobilnej i opisałem to w tym poście. Następnie token ten wysyłam na serwer gdzie napisałem sobie web clienta, który uderza do api facebooka w celu pobrania adresu emial potrzebnego do identity aplikacji serwerowej. Jednocześnie sprawdzana jest ważność facebook’owego tokenu. Cała klaska na dzień dzisiejszy wygląda tak:

4

Odpowiedzią api facebook’a jest oczywiście Json’ik. Parsuje go na swój obiekt odpowiedzi za pomocą JavaSrciptSerializer  z assembly System.Web.Exensions (bardzo fajna sprawa, rozwiązał mi problem błędnego parsowania tablicy byte’ów po stronie aplikacji mobilnej o czym w następnym poście). Swój obiekt odpowiedzi puszczam dalej i dzieje się to samo co na wcześniejszych screenach.

Pobieranie UserId z tokena

Po wpuszczeniu użytkownika do kontrolera przez JtwBearerTokenMiddleware wyciągam id usera z obiektu Identity  dostępnego przez wpisane User.Identity w kontrolerze. Do tej operacji napisałem serwisik zwracający mi id usera.

5

Podsumowanie

Autentykacja na takim poziomie jakim jest teraz w zupełności mi wystarcza aby w jak najmniejszym stopniu obciążać usera podawaniem swoich danych podczas korzystania z apki. W następnym poście wracamy do części androidowej i pobawimy się trochę z ogłoszeniami, czyli przeznaczeniem całego projektu :).

Pjona!,

Kilka słów o backendzie w ASP.NET Core 1.0

Siemanko.

Jest środa więc wedle harmonogramu, który ustaliłem we wcześniejszym poście ląduje na blogu jeszcze ciepły pościk. Dziś trochę o projekcie backendu dla aplikacji mobilnej. Dlaczego nowa wersja ASP.NET Core 1.0? Dla drugiego słowa z poprzedniego zdania – nowa 🙂 Mamy w tej chwili oficjalnie wersje RC1 (tutaj), a chyba nieoficjalnie pierwsze przymiarki do RC2 (jak się dowiedziałem szukając informacji na temat buga w JWT Bearer middleware – o czym przy okazji opisywania autentykacji – issue). Z nowym ASP.NET mam do czynienia od beta8.

Struktura projektu ASP.NET

Jak widać na załączonym obrazku zrobiłem sobie 6 projektów co by mieć porządeczek 😉

solution

Pierwszy projekt MobileSecondHand jest projektem startowym i jest to WebApplication utworzona z template’a w Visualu. Pozostałe projekty to webowe Class Library – package. I tu pierwsza z wielu nowości – library to paczki, które możesz opublikować na nugecie i instalować je jak inne biblioteki z nugeta. Te dodane do projektu poprzez File->New->Project dodaje się normalnie do Reference, ale muszą to być te „nowe” webowe Class Library (package). Jeśli masz napisane zajebiste ficzery, które wykorzystujesz w wielu różnych projektach – ale masz je napisane w „starym” Class Library – to nadal możesz wykorzystywać te zajebisty ficzery, ale w aplikacjach, w poprzedniej wersji frameworka 😉 Nie da się ich dodać do referencji projektu w nowej wersji frameworka. Trzeba „stare” przepisać na „nowe” Class Library (package).

packages

Jak widać wyżej projekty, do których dodałem referencje w projekcie startowym widnieją na liście dependencies w pliku project.json projektu startowego. Tu są wszystkie „paczki”. Możemy nie używać Package Manager Console czy Manage Nuget Packages tylko od razu wpisać na tej liście paczki, które chcemy dołączyć do projektu i zapisać plik, a wszystko stanie się samo 😉

Kolejną nowością jest klasa Startup.cs gdzie odbywa się cała konfiguracja i start aplikacji. Nie trzeba robić wpisów konfiguracyjnych w web.config czy global.asax – tego drugiego już nie ma. Całą konfigurację (np. CORS, MVC, routing, sposób autentykacji, dostęp do danych itp.) przeprowadzamy w Startup. NIe będą jej tu wklejał bo na jednym screenie się nie zmieści także jak masz ochotę to luknij do repo.

Kolejnym super ficzerem są kontrolery – WebApi czy zwykły dziedziczą po klasie Controller.cs i jeśli chcemy to możemy opędzić w jednym kontrolerze REST API oraz MVC do zwracania widoków oczywiście nadając metodom specjalne RouteAttribute’y.

Najlepszym ficzerem wg mnie jest wbudowany kontener IoC. Na pewno jest on kiepściejszy niż inne zewnętrzne istniejące od dawna, ale mam to w dupie bo mi w zupełności wystarcza, a nie muszę nic konfigurować poza zarejestrowaniem interfesju co sprowadza się do 1 (słownie: jednej) linijki i dzieje się to właśnie we wcześniej wspomnianej klasie Startup.cs 🙂

service

Mamy do wybory trzy opcje:

  • AddTransient – instancja na każde wystąpienie interfejsu
  • AddScoped – instancja na web request
  • AddSingleton – instancja w ramach całej aplikacji

i mnie to pasuje 🙂

Dobra, może wyglądać na to, że się wymądrzam, ale przytoczyłem kilka nowości, które zdążyłem poznać, ale jest jeszcze wiele do nauczenia się dlatego też właśnie backend robię w ASP.NET Core 1.0, o którym Gutek powiedział na DotNetConf, że póki nie wyjdzie pierwsza stabilna wersja to nowe ASP.NET jest jedynie do zabawy 🙂

Jeśli zajrzysz do repo to zobaczysz w głównym projekcie kilka rzeczy (kontrolery z zakomentowanym kodem, serwisy bez implementacji) z defaultowej aplikacji tworzonej przez visual. Na razie ich nie wyrzucam bo być może wykorzystam je w późniejszym etapie więc po co wymyślać koło na nowo 🙂

 

Dzisiejszym postem kończę wstęp do mojego projektu. Od niedzieli jedziemy już na grubo i będziecie mogli poczytać oraz zobaczyć co i jak jest zrobione do tej pory,a jest kilka rzeczy 😉

Pjona!

 

Uderzanie do IISExpress z zewnętrznej maszyny

Z racji, że mój projekt zakłada komunikację między zewnętrznym urządzeniem, a API w ASP.NET potrzebuje uderzać do tego właśnie API z tego właśnie urządzenia zewnętrznego 🙂 Projekt jest dopiero w powijakach i tworze jakieś małe prototypy konkretnych funkcjonalności, dlatego potrzebuję bardzo często uderzać do API i bardzo często dokonywać w nim zmian (czyt. standardowy proces developmentu ;)). Pierwszym pomysłem było publikowanie aplikacji i stawianie jej na IISie i potem uderzanie do niej po IP maszyny, na której stoi. Wiązałoby się to z częstym publikowaniem całej aplikacji, no ale innego pomysłu na razie nie miałem tym bardziej, że moja wiedza z zakresu sieci jest… no własnie, nie można nawet o niej powiedzieć, że jest, bo jej nie ma 😉 Jednak po kilku godzinach prób uruchomienia aplikacji dałem sobie spokój (nie wiem czemu, ale nie mogę za żadne skarby uruchomić aplikacji ASP.NET5 u siebie na IIS, a już całą możliwą dokumentację prześledziłem i nic z tego). Następnego dnia zacząłem szukać informacji na temat tego czy da się wejść do aplikacji uruchomionej w visualu na IIS Express… i ku mojej ogromnej radości da się! 🙂

  1. Musisz mieć zainstalowanego node.js – jak nie masz to wygugluj
  2. Otwierasz wiersz poleceń i wpisujesz: „npm install g iisexpressproxy”
  3. Następnie wpisujesz: „iisexpress-proxy NR_PORTU to ZEW_NR_PORTU” gdzie NR_PORTU to nr portu, na którym startuje aplikacja po uruchomieniu jej w visualu, ZEW_NR_PORTU to port, przez który będziesz się ładował z innej maszyny (u mnie dałem 81)
  4. Nie zamykaj wiersza poleceń
  5. Przejdź do zapory systemu windows -> ustawienia zaawansowane -> reguły przychodzące -> nowa reguła-> zaznacz port i naciśnij dalej -> wpisz nr portu czyli ZEW_NR_PORTU i dalej -> zawsze zezwalaj
  6. Uderzając z zewnętrznego urządzenia do uruchomionej aplikacji w visualu używasz takiego urla: „http://ADRES_IP_MASZYNY: ZEW_NR_PORTU” gdzie ADRES_IP_MASZYNY to jak sama nazwa wskazuje adres IP maszyny, na którym uruchomiana jest aplikacja (w wierszu poleceń wpisz „ipconfig” i skopiuj adres o nazwie „IPv4 Address”, ZEW_NR_PORTU to port, który wpisałeś w komendzie „iisexpress-proxy NR_PORTU to ZEW_NR_PORTU”.
  7. Włala 🙂

W moim przypadku maszyna i urządzenie uderzające (telefon) są w tej samej sieci więc nie wiem jak to by było gdyby urządzenia były w różnych sieciach bo jak wcześniej pisałem nie znam się, to się nie wypowiadam 🙂 Trzeba tylko pamiętać, że wiersz poleceń w którym uruchomiliśmy to proxy musi być cały czas otwarty, bo to nasłuchiwanie portu lata w tle.

Teraz mogę sobie spokojnie deweloperować zarówno w API ASP.NET5 jak i w Androidzie – pierwszy hint na temat projektu, który chodzi mi po głowie 😉 Więcej 1szego marca wraz ze startem konkursu #dajsiepoznac

PJONA