Wracam po tygodniu przerwy. Podsumowanie dwóch miesięcy pracy nad projektem „Mobile Second Hand”

Siemanko

Chciałbym sobie schlebić i napisać, że pewnie zauważyłeś/łaś przerwę w moim blogowaniu oraz commitowaniu do repo na tydzień, jednak stąpam twardo po ziemi i godzę się z tym, że oprócz mnie samego nikt zapewne nie dostrzegł tej ogromnej luki w polskim internecie 😉 Jeśli jednak chcesz się ujawnić i pochwalić, że należysz do, bądź co bądź, elitarnego grona czytelników (jak czegoś mało tzn., że nie dla wszystkich ;)) to daj znać pod spodem. W dzisiejszym poście podsumowanko dwumiesięcznego blogowania i kodowania.

Staty z wodpressa

Nie wiem czy to śmiesznie mało, czy normalnie jak na początek, ale na dziś tj. 04.05.2016 wordpress zanotował przez niewiele ponad dwa mieisące 794 wyświetlenia i 439 gości na blogu.

1

Blogowanie

17 postów konkursowych i 2 posty niezwiązane z #dajsiepoznac opublikowane zaraz po stworzeniu bloga, ale jeszcze przed startem konkursu. Staram się nie pisać żadnego pierdololo, by tylko spełnić wymóg dwóch postów tygodniowo, dlatego przyjąłem zasadę: najpierw kodowanie potem blogowanie, aby mieć się czym dzielić. Posty publikuje w regularnych odstępach czasu w te same dni tygodnia – środa i niedziela.

Kodowanie

Android Studio – moim zdaniem bardzo young developer friendly środowisko. Wiele gotowych template’ów z których, świeżaki mogą szybko wgryzać się w Androida. Fajne funkcjonalności wspomagające refaktoryzację kodu i wiele innych.

Java – podobna do C#. W przypadku potrzeby przebranżowienia powinno pójść gładko

Asp.Net Core 1.0 – wersja RC1-final. Wszystko spoko. Wszystko wskazuje na to,  że będą musiał zrobić upgrade do wersji RC2 nightly builds ponieważ, chcę skorzystać z SignalR do zrobienia chatu dla userów aplikacji mobilnej. Mam nadzieję, że pójdzie w miarę gładko

Entity Framework Core 1.0 – trzeba zapomnieć o sposobie pracy z EF6. Brak automatycznej konfiguracji relacji wiele do wielu, kaskadowy zapis nie zawsze działa, usuwanie obiektów z kontekstu nie odzwierciedla się nigdzie do momentu wywołania SaveChanges(), bugi przy self reference i wiele innych ciekawostek. Zobaczę co poprawili w wersji RC2 jeśli uda mi się zupgradować projekt

Xamarin – fajne środowisko. Trochę wolne, ale .NETowe dobroci rekompensują wszystko. Przyspieszyłem z aplikacją mobilną od momentu rozstania z Android Studio, a kod jest dużo bardziej schludny i czysty.

Podsumowanie

Na pewno nie uda mi się skończyć projektu przed końcem konkursu. Im głębiej w las tym więcej chciałoby się funkcjonalności, a co za tym idzie jest więcej roboty przy niezmiennie małej ilości wolnego czasu. Po konkursie będę na pewno dalej pracował nad projektem. Czy blogował? Na pewno nie dwa razy w tygodniu, ale może raz na jakiś czas opowiem jakiś dowcip 😉

Pjona!

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!

Xamarin’owa apka doprowadzona do stanu jaki prezentuje w Android Studio.

Siemanko.

Dziś króciutko.

W dniu dzisiejszym udało mi się doprowadzić aplikację mobilną do stanu jaki prezentowała w Android Studio w momencie podjęcia decyzji o przesiadce na Xamarin’a, więc nareszcie będę mógł jechać z nowymi tematami. Nie zliczałem czasu, ale szacuję, że zajęło mi to ok 20 godzin. Biorąc pod uwagę, że nie miałem wcześniej z Xamarin’em nic wspólnego to myślę, że to dobry wynik, a przyjemność jaką sprawia mi pisanie w nim jest o wiele większa niż w Android Studio. Ostatnie posty nie dotykały funkcjonalności rozwijanych w projekcie dlatego pozwolę sobie przypomnieć Ci co jest zrobione i za co zabieram się od jutra (dziś już dość kodzenia ;)).

Jest zrobione (zarówno po stronie aplikacji mobilnej jak i na serwerze):

  • autentykacja za pomocą tokena JWT (logowanie/rejestracja za pomocą formularza lub facebooka)
  • ustalanie lokalizacji w aplikacji mobilnej
  • pobieranie listy ogłoszeń na podstawie lokalizacji użytkownika uderzającego do API z uwzględnieniem zadeklarowanego przez niego obszaru z jakiego chce zobaczyć ogłoszenia (na podstawie zadeklarowanego promienia – wszystko wyliczam na serwerze)
  • tworzenie nowego ogłoszenia wraz ze zdjęciem i zapis do bazy na serwerze co skutkuje natychmiastowym pojawieniem się ogłoszenia w systemie

Co będzie robione:

  • predefiniowane hasła kluczowe dotyczące rodzaju ubrania (np. sukienka, bluzka itp.) oraz koloru, które będę wyłapywał na serwerze z tytułu i opisu ogłoszenia aby następnie je powiązać z sobą powiązać. W aplikacji nie będę wymagał wybierania ręcznego kategorii, itp. jak to jest np. na Allegro. Ma to być maksymalnie proste dlatego przypisywaniem haseł zajmie się system.
  • pobieranie listy ogłoszeń z zawężeniem do predefiniowanego hasła (np. tylko ogłoszenia ze spodniami)
  • powiadomienia w tle o pojawieniu się nowych ogłoszeń w zadeklarowanym przez usera obszarze
  • wyświetlanie szczegółów ogłoszenia po kliknięciu go na liście
  • komunikacja między użytkownikami systemu (kupujący – sprzedający)

Podsumowanie

Cieszę się, że będę już mógł pracować nad nowymi rzeczami, a nie odgrzewać stare kotlety ;). Jeśli Ty też się cieszysz moim szczęściem to daj feedback ;). A jeśli nie – to nie ;p

Pjona!

Wrażenia po pierwszych randkach z Xamarinem cz. 1

Siemanko.

Jak wiesz z tego wpisu, postanowiłem porzucić projekt aplikacji mobilnej w Android Studio i zacząć wszystko od nowa w Xamarin’ie (w związku z tym, że stał się darmowy). Wiązało się to oczywiście z dodatkowym nakładem pracy na doprowadzenie apki do stanu jaki już prezentuje w projekcie z Android Studio, ale ekscytacja nową technologią, o której coraz więcej się słyszy oraz perspektywa pracy w znanym mi środowisku (Visual Studio) wzięły zdecydowanie górę i już dziś poszedł do repo pierwszy push z projektem Xamarin’owym. Jakie wrażenia po ok 10ciu godzinach pracy w Xamarinie?

Powolny start aplikacji

To było pierwsze moje spostrzeżenie po przesiadce z Android Studio gdzie start apki z debuggerem trwał w porywach do 10ciu sekund, a bez debuga niemal natychmiast, tak start nawet czystego wygenerowanego templat’u w Visual Studio trwa znacznie dłużej. Nie mierzyłem stoperem, ale jest to na prawdę znacząca różnica w szczególności jeśli wprowadzam jakieś drobne zmiany w kodzie i chcę szybko zobaczyć ich wpływ na działanie aplikacji. Niestety aplikacja dłużej się uruchamia niż ja potem w niej klikam. W zasadzie nie ma co się dziwić bo przy każdym uruchomieniu aplikacja chyba jest publikowana (z tego co widać w output’cie) i przerabiana na jave więc to musi trwać. Dodam, że nie korzystam z emulatora tylko z fizycznego urządzenia.

Nie wszystko na co IDE pozwoli zostanie zatwierdzone przy build’zie.

Napisałem jakiś kod, który był poprawny dla .NETu natomiast przy buildzie czy próbie uruchomienia aplikacji dostałem wiele mówiący błąd:

1

I tyle. Żadnego wskaźnika do miejsca w kodzie. Domyśliłem się co mogło być problemem więc zlokalizowanie kodu, z którym maszynka do javy miała problem nie trwało długo lecz kiszka była by gdybym naklepał sporo kodu bez buildów w między czasie opierając się tylko na informacjach od IDE. Weź bądź mądry i szukaj wiatru w polu.

Jeśli coś się nie renderuje w designerze niekoniecznie nie będzie się renderować po starcie.

No właśnie. Na tym straciłem ze dwie godziny. Dodałem do projektu komponent: Facebook Android SDK (przez Component Store – taki Xamarinowy nuget). Nie jest to oficjalne SDK wydane przez Facebooka tylko przez grupę Xamarina. I tak jak w Android Studio dodałem sobie na widok (w .xml) guzior do logowania z facebookiem. Przełączam się na widok designera, a tu bach:

2

Mówię sobie: trudno – nikt nie powiedział, że będzie łatwo 🙂 Grzebałem w necie, sprawdzałem sample tego SDK, odinstalowywałem i instalowałem ponownie komponent itp. itd. tak przez jakieś 2 godziny bez rezultatów.  W końcu uruchomiłem aplikację z ostatnią nadzieją, że to designer sobie nie radzi i ku mojej radości przez zaciśnięte zęby tak się właśnie dzieje. W uruchomionej aplikacji guzik jest wyrenderowany.

IMAG0025

I tak jest również z innymi komponentami androida, które w Android Studio są dostępne „z pudełka” natomiast w Xamarin’ie trzeba je pobierać prze Comeponent Store do swojej aplikacji i oglądać dopiero po uruchomieniu apki 😉 Mam nadzieję, że chociaż Tobie zaoszczędzę trochę czasu i sporo frustracji jeśli napotkasz na ten sam problem.

Podsumowanie

Z dzisiejszego wpisu pewnie wnioskujesz, że nie jestem zbyt zadowolony z przesiadki na Xamarin’a oraz w ogóle z pracy, z tym ustrojstwem 😉 Otóż nie. Skupiłem się na tych skrajnych przypadkach ponieważ to one rzuciły się najbardziej w oczy w pierwszej kolejności. Dobrodziejstwa? Największą zaletą jest C# i .NET. Nie muszę korzystać z zewnętrznej biblioteki do asynchronicznej komunikacji z rest api bo z pudełeczka mam HttpClient i operatory async/await. Nie muszę korzystać z Gsona (które jest mega powolny) do konwersji jsona na obiekty bo mam z nugeta Newtonsoft.Json. Nie fiksuję się tylko i wyłącznie na jedną platformę bo mam PortableClassLibrary i jak mi odpierdoli to kupie sobie iPhona i będę mógł wykorzystać ten sam kod do pisania apki na iOSa 🙂

W środę dalsza część wrażeń z pracy w Xamarin’ie.

Pjona!

Kilka słów o EF Core 1.0

Siemanko.

Dziś troszkę o EF Core 1.0 (EF 7 do niedawna), które wykorzystuję w projekcie Asp.Net Core jako część backend’u dla aplikacji mobilnej Mobile Second Hand. Troszkę, bo nie poznałem jeszcze wszystkich nowości w tej wersji Microsoft’owego ORM’a i to co dziś przeczytasz będzie to głównie opis największych różnic między w.w. wersją, a poprzednią czyli EF6.

Gotowiec Entity Framework Identity.

Jak kiedyś wspomniałem, projekt Asp.Net Core założyłem z wbudowanego w Visual Studio template’a – Web Aplication – z zaznaczoną opcją Individual User Accounts co skutkuje tym, że z automatu jest skonfigurowany dostęp do danych wraz z obsługą autentykacji. Wystarczy tylko w pliczku appsettings.json głównego projektu wpisać connection string do bazy, z którą chcemy pracować. W moim przypadku:

q

Tak jak w poprzedniej wersji Entity Framework, jeśli baza podana w connection stringu nie istniała, wystarczyło utworzyć nowy obiekt DbContext’u aby ORM tę bazę utworzył, dlatego poszedłem tym samym tropem – utworzyłem obiekt Usera i spróbowałem zapisać. Niestety ku mojemu zdziwieniu nic z tego nie wyszło. Dostawałem wyjątek, że EF nie może się zalogować do serwera bazy danych z wykorzystaniem poświadczeń podanych w connection stringu. Było to tym bardziej frustrujące bo logowanie do SQL’a mam domenowe i tak też podałem w connection stringu. Po pewnym czasie i paru chujach skierowanych w stronę monitorów doszedłem do tego, że trzeba się ręcznie upewnić o istnieniu bazy i wtedy EF Core ją utworzy jeśli jej nie ma. Należy to zrobić wpisując jedną linijkę na końcu metody Configure w klasie Startup.cs.

2

Oczywiście context to nazwa parametru dla DbContext’u aplikacji jaki przyjmuje metoda Configure (dlatego równie dobrze może być dupa.Database.EnsureCreated()), a owy DbContext jest wstrzykiwany z użyciem Dependency Injection.

Brak Initializer’ów.

W poprzedniej wersji EF do współpracy z DbContext’em były definiowane i wykorzystywane tzw. Initializer’y. To one określały co ma się dziać z bazą danych. I tak:

  • CreateDatabaseIfNotExists – tworzył bazę gdy jej nie było – dlatego w poprzedniej wersji EF baza była z automatu tworzona gdyż ten Initializer był domyślny
  • DropCreateDatabaseIfModelChanges – usuwał i tworzył bazę gdy uległ zmianie, którykolwiek z modeli podanych w DbSet’cie
  • DropCreateDatabaseAlways – za każdym uruchomieniem aplikacji i jej pierwszym odwołaniu się do bazy ta była usuwana i tworzona na nowo
  • CustomDbInitializer – możliwość napisania swojego gdy żaden z powyższych nie odpowiadał (np. migracja do najnowszej wersji bazy w przypadku korzystania z ręcznych migracji)

Oczywiście wykorzystując te initilizer’y mogliśmy wypełniać bazę jakimiś danymi, ale to było w poprzedniej wersji. Teraz są tylko ręczne migracje.

Tylko ręczne migracje

W poprzedniej wersji mogliśmy nie korzystać z migracji, włączyć automatyczne migracje bądź ręcznie migrować schemat bazy. Teraz nie ma takiego wyboru i jedynym dostępnym sposobem do obsługi schematu bazy są ręczne migracje. Migracjami operujemy z poziomu command line’a. W projekcie głównym muszą być zainstalowane EntityFramework.Commands, aby można było ich używać w wierszu poleceń (w gotowej aplikacji z template’a już wszystko jest). Jeśli masz w solucji kilka projektów to musisz pamiętać aby za pomocą cd przejść do projektu głównego, gdzie są zainstalowane EntityFramework.Commands oraz koniecznie wpisać dnvm use 1.0.0-rc1-final (póki jest jeszcze wersja RC1 frameworka Asp.net Core) bo zacznie sypać wyjątkami, jeśli spróbujesz korzystać z komend EF np. dnx ef –help.

Podsumowanie

Tak jak wspomniałem we wstępie to tylko pierwsze spojrzenie na nową wersję EF. Jeśli jesteś ciekaw jak od zera dodać do projektu nowe EF to odwiedź matczyną stronę Asp.Net Core gdzie jest wszystko elegancko opisane.

W niedzielę napiszę o pierwszych walkach z Xamarinem ponieważ jak możesz się dowiedzieć z poprzedniego postu porzuciłem projekt w Android Studio i zaczynam od zera w Xamarinie.

Pjona!

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!,

MobileSecondHand – autentykacja po stronie serwera cz. 1.

Siemanko.

Dziś troszkę o tym jak rozwiązałem autentykację po stronie serwera (bo jest już zrobiona i działa). Post podzieliłem na dwie części coby mieć o czym pisać później bo ku mojemu zaskoczeniu (samym sobą? ;p) projekt idzie mi całkiem nieźle bo właśnie na chwilę przed rozpoczęciem pisania tego postu skończyłem klepać prototyp tworzenia nowego ogłoszenia po stronie telefonu, wysłania go na serwer, zapisania do bazy, i w końcu zwracania listy prawdziwnych ogłoszeń (bez hardcodu) oraz wyświetlenia jej w apce 🙂 Yeah!.  Są to oczywiście prototypy, które będę musiał przepisać porządnie, ale na razie skupiam się na funkcjonalnościach by dopieszczać je już działające.

Tyle słowem wstępu. Wracamy do tematu.

JWT Bearer Token

Projekt po stronie Asp.Net zakłada tylko WebApi do kumunikacji z aplikacją mobilną dlatego wiadomym dla mnie było, że autentykacja będzie realizowana przez token. Przyznam, że w mojej niedługiej karierze nie korzystałem jak dotąd z tokenów, dlatego właśnie postanowiłem to nadrobić. Zasadę działania autentykacji opartej na tokenie mniej więcej znałem z „telewizji”, ale nie wiedziałem od czego zacząć implementację, dlatego zacząłem typowo – google -> asp.net 5 token authentication -> enter -> trach, poszło. Przestudiowałem kilka artykułów, kilka stron i wybór padł na JWT Bearer Token. Dlaczego? Bo prosta implementcja, która sprowadziła się praktycznie do dopisania do dependencies w pliku project.json projektu startowego linijeczki:

„Microsoft.AspNet.Authentication.JwtBearer”: „1.0.0-rc1-final”

ctrl + s, bach, trach poszło, Jwt jest w projekcie. Następnie w klasie Startup projektu startowego odbywa się konfiguracja. W metodzie CofigureServices wpis:

aut1

Następnie w metodzie Configure:

aut2

Gdzie tokenAuthorizationOptions to obiekt konfiguracyjny z kluczem szyfrującym (RsaSecurityKey), który jest wczytywany z pliku i musi być zawsze ten sam dla aplikacji. Ja wstrzykuje sobie ten obiekt przez dependency injection.

Koniec konfiguracji. Teraz wystarczy opatrzeć metodę kontrolera lub cały kontroler atrybutem:

[Authorize(„Bearer”)]

i nie ma takiego wchodzenia na serwer bez tokenika! 😉 Uderzając z PostMan’a do aplikacji bez podania odpowiedniego nagłówka dostaniemy 401

aut3

jeśli uderzymy z nagłówkiem (o tworzeniu tokena w następnej części czyli w niedzielę):

Authorization: Bearer (token – ciąg znaków)

to jesteśmy wpuszczani do kontrolera.

Jwt Bearer middleware robi cała robotę. Z małym ale..

Bug w JWT Bearer midlleware w Asp.Net Core 1.0 rc1-final

Jeśli uderzamy bez tokena to spoko, jak było widać wcześniej dostajemy 401. Jeśli jednak uderzymy z nagłówkiem i token będzie błędny lub nieważny to dostaniemy 500!

aut5

aut4

Ogólnie to nie wiedziałem o co kaman bo przecież działało!

monkey

Po pewnym czasie dogoglowałem się do issue na githubie. A więc na szczęście to nie tylko u mnie 🙂 Można to obejść pisząc swoje middleware tuż przed JWTmiddleware na pipeline, które łapie w try catch następne wywołanie. W catchu złapie się ten wyjątek i po sprawdzeniu czy wyjątek jest tym, który nas interesuje, możemy zwrócić 401 (na screenie jeszcze nie dopisałem rozróżniania jaki to wyjątek dlatego jest samo Exception, a powinny być te związane z walidacją tokena):

aut6

Podsumowanie części 1

Poza tym bugiem to wydaje się być wszystko ok. Najważniejsze, że problem został rozwiązany, a o to przecież chodzi w naszym fachu 😉 Gdyby to miała być biznesowa aplikacja to na pewno bym nie skorzystał z JWT z bugiem, ale skoro to ma być apka, która zapewne nie zawita nigdy na google play (no chyba, że dla jaj) to co tu się szczypać!;)

W niedzielę część 2.

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!

 

Start #dajsiepoznac 2016 – opis projektu „Mobile Second Hand”.

Siemanko.

Dziś wystartował konkurs #dajsiepoznac także pora na kilka słów o tym co zamierzam robić przez najbliższy czas. Mam nadzieję, że uda mi się wygospodarować wolnego czasu na tyle aby mieć o czym pisać dwa razy w tygodniu do połowy maja.

Projekt ma na celu stworzenie aplikacji mobilnej, która ma służyć do kojarzenia ze sobą użytkowników w zadanym przez nich obszarze w celu pozbycia się/nabycia w maksymalnie uproszczony sposób starych/niepotrzebnych/nietrafionych z kolorem, rozmiarem itp. ubrań czyt. odzieży. Aplikacja będzie skierowana głównie do kobiet, które uwielbiają kupować lub zdobywać nowe (w ich garderobie) ciuchy jednocześnie nie mając co zrobić z rzeczami, które się Im już znudziły. Oczywiście jest mnóstwo platform do sprzedania takich niepotrzebnych rzeczy jednak wiąże się to najczęściej z :

(dla chcącej się pozbyć)

  • rejestracją
  • wypełnianiem dość sporych formularzy z wymaganymi polami
  • robieniem zdjęć, które najczęściej następnie należy zgrać na kompa
  • używane rzeczy nie cieszą się zbyt dużym powodzeniem (najczęściej kupują je kobiety mające fioła na punkcie second handów)
  • przy ew. sprzedaży trzeba zapakować przesyłkę
  • udać się na pocztę lub umówić z kurierem (trzeba znaleźć czas najczęściej w godzinach pracy)
  • czekać na zwrot pobrania
  • ogólnie sporo roboty i zachodu

(dla chcącej coś kupić)

  • rejestracją
  • śledzeniem aukcji/ogłoszeń
  • wysyłaniem zapytań do sprzedającego, na których odpowiedź trzeba czekać
  • brak pewności czy to co na zdjęciu wydaje się być ok w realu też jest ok
  • brak możliwości przymierzenia
  • oczekiwaniem na przesyłkę

 

A gdyby tak:

(dla chcącej się pozbyć)

wyciągnąć telefon, zrobić zdjęcie np. sukienki, której chcemy się pozbyć, wpisać np. „Sukienka czerwona rozm. 38 raz użyta. Sprzedam lub zamienię na inną” i kliknąć OK. Po pewnym czasie dostajemy powiadomienie, że użytkowniczka XYZ jest zainteresowana i chce nawiązać kontakt. Klikamy ok i otwiera nam się mini czat. Użytkowniczka oznajmia, że znajduje się od sprzedającej 2km więc za 15 min. mogą się umówić na mieście. Tak też się dzieje i dokonują transakcji. Obie użytkowniczki są zadowolone 🙂

(dla chcącej coś kupić)

idziemy ulicą i dostajemy powiadomienie, że w odległości ok 2 km jest do kupienia jakiś ciuch. Otwieramy ogłoszenie, oglądamy zdjęcia i klikamy nawiąż kontakt. Otwiera nam się okno mini czatu prosimy sprzedającego o nr telefonu i uzgadniamy miejsce gdzie możemy obejrzeć ciuch i ew. dokonać transakcji. Obie użytkowniczki są zadowolone 🙂

 

Teraz trochę o technologiach:

Java_logo

android

 

Jak widać po logach apka jest pisana na androida w Android Studio. Jestem całkowicie zielony jeśli chodzi o Javę i w ogóle development mobilny no ale to jest główny powód tego projektu – chcę się czegoś nowego nauczyć 🙂 Apka będzie korzystać, z internetu, lokalizacji i multimediów.

aspnetcore

Backendem jest nowe ASP.NET Core czyli jeszcze do niedawna nowe ASP.NET5. REST API, dostęp do danych i cała logika. Tu już czuję się znacznie mocniej ponieważ jestem .NETowcem, ale oczywiście też mam zamiar wielu nowych rzeczy w nowym frameworku się nauczyć.

maxresdefault

Jak starczy czasu to chciałbym też nieco liznąć tematu Machine Learning. W tym tez jestem zielony ale mam nadzieję, że się to zmieni. A czego maszyna miałaby się w tym projekcie uczyć? Jakie ciuchy, jakie kolory i rozmiary itp. najczęściej i najchętniej dany użytkownik przegląda, i na tej podstawie wyświetlać mu spersonalizowane reklamy.

 

To by było na tyle jeśli chodzi o wstęp. W następnych postach będę pisał co i jak zrobiłem oraz jaki będzie dalszy plan zadań.

Jak dotąd zrobiłem kilka bardzo prostych widoków w androidzie na potrzeby logowania i autentykacji, wysyłanie/odbieranie requestow oraz proces autentykacji w ASP.NET obsługujący logowanie przez facebook’a.

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