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!

Reklamy

Pierwsze kody związane z czatem już na guthub’ie.

Siemanko

W od kilku postów wiecie, że przymierzałem się do rozpoczęcia prac na czatem i ogólnie komunikacją między użytkownikami aplikacji mobilnej w czasie rzeczywistym. Dziś nastał ten dzień , że już pierwsze kody możesz zobaczyć w repo, a w tym poście pierwsze screen’y i zdjęcia z wymiany informacji pomiędzy klientem, a serwerem. W tym odcinku klientem jest nasz (mój i mojej narzeczonej) „pitbull” o imieniu Dosia 😉

Aplikacja mobilna klientem SignalR

W projekcie Xamarin napisałem w portable class library klienta SignalR dzięki czemu będę mógł go wykorzystać cross-platform’owo (może kiedyś)Z tego klienta korzystam w projekcie androidowym w nowo utworzonym serwisie, który będzie odpowiedzialny za komunikację z serwerem SignalR. Połączenie i komunikacja odbywa się w oddzielnym wątku przez co nie będzie ona wpływać na responsywność apki.

Serwer SignalR

W projekcie backend’u napisałem (zbyt dużo powiedziane bo to dopiero kilka linijek) serwer SignalR. Będzie on oczywiście odpowiedzialny za komunikację, ale chcę aby działo się w nim znacznie więcej. Mianowicie chcę zapisywać sobie informację o tym, który użytkownik jest online, zapisywać do bazy konwersacje między użytkownikami i wiele innych. Nad tym będę pracował w najbliższym czasie. Jak na razie serwer SignalR tylko odbiera jedną określoną wiadomość i na nią odpowiada.

Pierwsza komunikacja real time

Odpalając aplikację mobilną wysyłam wiadomość do serwera SignalR:

a1

Screen serwera SignalR w trybie debug

w odpowiedzi zwracam wiadomość, którą obsługuję w aplikacji poprzez odpalenie tzw. notification – czyli powiadomienia:

2

IMAG0058

Po kliknięciu powiadomienia przeniosę użytkownika na widok wiadomości (którego jeszcze nie ma). Na tę chwilę przenoszę go na listę ogłoszeń, ale to jest teraz nieistotne bo najważniejszym było obsłużenie komunikacji.

Serwis android’owy korzystający z klienta SignalR działa w tle, także mimo iż aplikacja nie jest odpalona (tzn. nie ma jej na ekranie, ale jej proces działa) wiadomości są odbierane.

IMAG0061

3

IMAG0071

W tym momencie kliknięcie powiadomienia przeniesie użytkownika do aplikacji. Normalnie jak w messengerze! 😉

Podsumowanie

Trochę się obawiałem, ze będzie to trudny task i zajmie mi to trochę czasu zanim cokolwiek zacznie działać,  a ku mojemu zaskoczeniu SignalR jest na tyle zajebisty, że wystarczy tylko kilka linijek aby już zacząć komunikację. To już za mną dlatego teraz muszę ogarnąć cały tzw. workaround żeby w pełni zaimplementować funkcjonalność komunikacji między użytkownikami aby mogli bez problemów dogadać szczegóły dotyczące transakcji ;).

Pjona!

Jeśli nie ma czegoś w nugecie tzn., że to nie istnieje? Nuget to nie google i ma swoje package source.

Siemanko

W poprzednim poście napisałem, że będę próbował zupgradować projekt back endu do nieoficjalnej najnowszej wersji frameworka Asp.Net Core (RC2) tzw. nightly builds. Było to podyktowane tym, że chciałem zacząć pracę nad implementacją czatu dla użytkowników aplikacji mobilnej mojego projektu. Jeśli czat to sockety, a jeśli sockety i asp.net to SignalR. Niczego jeszcze nie robiłem z SignalR, ale kiedyś oglądałem jakiś kursik, gdzie m.in. była prezentacja SignalR dlatego od samego początku miałem w głowie, że właśnie z tym ustrojstwem będę się bawił robiąc czat.

Wracając do upgrade’u. Dlatego pisałem o potrzebie podniesieniu wersji frameworka bo w aktualnym RC1-final nie było paczki SignalR w kombatybilnej wersji

1

Screen z pliku project.json z sekcji dependencies

Lipa, nie? A przeglądając github’a widziałem przykłady SignalR, ale w wersji frameworka RC2, dlatego też ślepo przyjąłem, że w aktualnej wersji RC1-final po prostu nie ma SignalR.

Package Manager Source

Wszystkiemu winna (bądź nie) konfiguracja źródeł dla nugeta, a raczej informowanie zwykłych devów o adresach serwerów, z których można pobierać paczki publikowane prze teamy pracujące nad frameworkami, których Ci zwykli devowie używają 😉 Tym zakręconym zdaniem przechodzimy do głównego bohatera dzisiejszego posta czyli nuget.config.

2

3

To co widzisz powyżej to nic innego jak programowa prezentacja pliku nuget.config znajdującego się w dokumentach użytkownika

4

To jest chyba standardowa wersja ustawień nugeta tzn. ze standardowym źródłem. Teamy Asp.Net Core i ogólnie całego nowego .Net Core mają swoją serwery, na których publikują paczki , i z których zarazem my – prości devovie – możemy je ściągać 🙂 Szkoda tylko, że nie informują o tym w dokumentacji tylko trzeba zaglądać do pliku nuget.config każdego z projektów na github’ie.  W moim przypadku dodanie źródła o adresie

https://www.myget.org/f/aspnetmaster/api/v3/index.json

poskutkowało pojawieniem się paczki SignalR w odpowiedniej dla mnie wersji

6

Podsumowanie

Jeśli nie możesz czegoś znaleźć w nugecie to nie zakładaj, że tego tam nie ma albo, że zjebało Ci się Visual Studio 😉 Niech Twym pierwszym działaniem będzie upewnienie się czy masz odpowiednie źródła wpisane do nuget.config. 

Pjona!

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!