Podsumowanie roku 2017 i postanowienia noworoczne

Pod koniec roku ludzie mają tendencje do robienia podsumowań tego, co się udało zrobić w tym roku oraz planować co zrobią w następnym. Tak więc i ja to zrobię.

Podsumowanie

Nie będę ukrywać, że ten rok był znaczniej bardziej udany od poprzedniego. Zrobiłem rzeczy będące wcześniej tylko marzeniami. Zacznijmy od największego sukcesu.

Założenie bloga

To była jedyna rzecz, którą zrobiłem i była na mojej zeszłorocznej liście postanowień noworocznych.

Daj Się Poznać 2017

Bloga założyłem na końcu lutego, czyli dużo wcześniej niż zamierzałem to zrobić. Wszystko ze względu na startujący na początku marca konkurs Daj Się Poznać 2017. Uznałem to za okazję na zaczęcie i rozpędzenie się z blogiem. Jako jeden z około 1000 uczestników rozwijałem projekt open source i opisywałem swoje zmagania na blogu. Ostatecznie spełniłem wymagania konkursu (20 wpisów od początku marca do końca maja) i zostałem jednym ze 184 finalistów. Niestety do ścisłej czołówki nie udało się dostać. Za mało poświęciłem czasu na rozwijanie mojego projektu, wybrałem projekt wymagający więcej czasu, niż byłem w stanie poświęcić oraz za mało promowałem bloga. Mimo to udział w konkursie uważam za duży sukces. Wiele się nauczyłem i przestałem się bać pokazywania komuś swojego kodu.

Przerwa

Żałuję, że po konkursie zrobiłem sobie przerwę, bo mogłem wykorzystać rozpęd, który już miałem, co prawda nie wielki, ale jednak.

Końcówka roku

Ostatecznie powróciłem do blogowania w grudniu. I zrobiłem to z wielkim rozmachem, co widać na wykresie poniżej (zrzut zrobiony 30 grudnia o godzinie 13:49).

2017-12-30 13_48_52-Statystyki ‹ Łukasz Kot Blog — WordPress.com.png

Łącznie od założenia bloga do dnia 30 grudnia 13:56 mam:

  • 1362 wyświetleń
  • 807 odwiedzających
  • 13 polubień
  • 21 komentarzy
  • 30 wpisów na blogu (łącznie z tym)

„Przeprowadzka” technologiczna

W tym roku też zmieniłem technologię. Zrezygnowałem z silnika Unity i tworzenia gier na rzecz tworzenia aplikacji webowych w .NET Core. Z mojej przygody z Unity wiem jedno — nie znam się na grafice komputerowej i nie chce się poznać!!!

Postanowienia noworoczne

Teraz przedstawię plany na nadchodzący 2018 rok. Zapowiada się epicki rok, a to, dlatego że będę pełnoletni. Niektóre plany może są zbyt ambitne, ale to chyba lepiej, niż żeby były za mało ambitne.

Pierwszy staż/praca

W nadchodzącym roku zamierzam spróbować znaleźć pierwszą pracę albo przynajmniej staż w IT. Powysyłam CV, może ktoś się zainteresuje, a jeżeli nie to przynajmniej dowiem się, czego mi jeszcze brakuje, aby zostać programistą. A pewnie znajdzie się tego sporo.

Język angielski

W nadchodzącym roku zamierzam popracować nad moim angielskim. Czuję, że się cofam, bo w szkole angielski nie jest zbyt wymagający. Czas to zmienić.

Nawet w postanowieniach noworocznych jest enkapsulacja

Oprócz tego mam parę planów na przyszły rok, o których na razie nie będę mówił, bo gdybym o nich powiedział, to mogłoby mi to utrudnić sprawę 😉 W każdym razie będzie niesamowicie 😀

Podsumowanie

Jeżeli dotarliście do tego miejsca, to dziękuję za przeczytanie tego wpisu. Zapowiada się bardzo ciekawy rok. Do następnego wpisu, który już w przyszłym roku.

Reklamy

Piszemy REST API

Czas wreszcie, żebym napisał coś więcej o projekcie, nad którym aktualnie pracuje, a mianowicie REST API w .NET Core. W tym wpisie opiszę, co to jest i jak działa REST na przykładzie tworzonej przez mnie aplikacji.

Co to jest REST API?

REST — Representational State Transfer — wzorzec tworzenia architektury aplikacji rozproszonych przy użyciu protokołu HTTP. Jest to umowa jak korzystać z tego protokołu, aby uzyskać dostęp do zasobów będących głównym elementem REST-a.

API — Application Programming Interface — interfejs programistyczny aplikacji.

Z tego wynika, że:

REST API to interfejs programistyczny aplikacji oparty o protokół HTTP umożliwiający zarządzanie zasobami (pobieranie, usuwanie, edycja, tworzenie) przy użyciu plików JSON lub XML oraz żądań HTTP.

Oznacza to, że po wysłaniu określonego żądania HTTP zostaje zwrócony klientowi aplikacji JSON lub XML z zasobami oraz odpowiednim kodem HTTP. W REST korzystamy przede wszystkim z 4 żądań HTTP:

  • GET — do pobierania zasobów
  • POST — do tworzenia zasobów
  • PUT — do edycji zasobów
  • DELETE — do usuwania zasobów

Tyle wiedzy teoretycznej na sam początek wystarczy. Więcej wiedzy będę dostarczał wraz z trwaniem tworzenia aplikacji.

Przykład działania REST-a

I tak o to przechodzimy z teorii do praktyki, którą zaprezentuję na już działających elementach aplikacji. Nie jest tego na razie za wiele, ale musi na razie to wystarczyć.

Żądanie POST

Zacznijmy od tego, że z przeglądarki nie można w bardzo prosty sposób wysłać żądanie POST. W tym przykładzie użyłem do tego Postmana.

http://localhost:53366/users/

Po wysłaniu na adres URL powyżej żądania HTTP z ciałem (body):

{
 "email" : "test2@mail.com",
 "username" : "TestAccount",
 "password" : "Secret123"
}

zwraca nam odpowiedź HTTP:

Status: 201 (Created)

oraz w nagłówku w Location znajduje się adres, pod którym możemy uzyskać dostęp do zasobu. W naszym przypadku jest to:

http://localhost:53366/users/test2@mail.com

Żądanie GET:

Po wpisaniu żądania GET na taki adres:

http://localhost:53366/users/test2@mail.com

W odpowiedzi dostałem takie o to „coś”:

{"id":"969e8b35-83b1-4a37-bf67-148a08522c38","email":"test2@mail.com","username":"TestAccount","fullName":null,"createdAt":"2017-12-28T13:59:10.4331374Z","events":[]}

Na pierwszy rzut oka można nie zauważyć JSON-a, ale jeżeli sformatujemy sobie tę odpowiedź w taki o to sposób:

{
   "id":"969e8b35-83b1-4a37-bf67-148a08522c38",
   "email":"test2@mail.com",
   "username":"TestAccount",
   "fullName":null,
   "createdAt":"2017-12-28T13:59:10.4331374Z",
   "events":[]
}

to widzimy obiekt będący reprezentacją stworzonego przez nas wcześniej użytkownika.

Tyle do tej pory zaimplementowałem. Użycie pozostałych żądań przedstawię tylko teoretycznie:

Żądanie PUT:

http://localhost:53366/users/test2@mail.com

Po wysłaniu na powyższy adres takiego JSON-a metodą PUT:

{
 "username":"TestAccount",
 "fullName":"TestAccountFullName",
}

Powinien zwrócić kod odpowiedzi HTTP 204 – No Content — czyli operacja została wykonana pomyślnie, ale serwer nie ma nic do zwrócenia. Na serwerze zasób powinien zostać zaktualizowany i po użyciu metody GET zwrócić użytkownika ze zmienionymi polami username oraz fullname.

Żądanie DELETE:

http://localhost:53366/users/test2@mail.com

Po wysłaniu na powyższy adres żądania DELETE powinien zwrócić kod odpowiedzi HTTP 204 – No Content — czyli operacja została wykonana pomyślnie, ale serwer nie ma nic do zwrócenia. Serwer powinien usunąć użytkownika.

Zakończenie

To wszystko, co chciałem przedstawić w dzisiejszym wpisie. W kolejnych wpisach będę opisywać kolejne zagadnienia związane z tworzoną przez mnie aplikacją. Kod źródłowy jest dostępny na GitHubie.

Jeżeli dotarliście do tego miejsca, to dziękuję za przeczytanie tego wpisu. Jeżeli macie jakieś pytania albo sugestię piszcie w komentarzach poniżej. Do następnego wpisu, który już nie długo.

 

Jak zacząć swoją przygodę z testami jednostkowymi?

W aplikacji będącej aktualnie moim głównym zajęciem piszę oraz uczę się testów jednostkowych. Dlatego postanowiłem, że co nieco o nich napiszę jako wstępniak do być może późniejszych wpisów na ten temat.

Co to są testy jednostkowe?

Testy jednostkowe to metody pisane w osobnym projekcie testujące pojedyncze elementy programu, czyli metody.

Po co pisać testy jednostkowe?

Testy piszemy po to, aby zapewnić kontrolę nad poprawnością wykonywanych przez program operacji. Bez testów ciężko jest to osiągnąć, ponieważ jeżeli w takiej sytuacji zmienimy, bądź zrefaktoryzujemy jakąś funkcję, musimy dużo czasu poświęcić na sprawdzenie, czy mimo zmiany na pewno funkcja wykonuje poprawnie oczekiwaną od niej operacje. Jeżeli mamy testy możemy je uruchomić w każdej chwili i sprawdzić w ciągu kilku sekund czy dla różnych danych wejściowych dana metoda zwraca poprawne wyniki.

Jakiego typu kod pokryć testami jednostkowymi?

Przede wszystkim taki kod, gdzie jest mnóstwo logiki do sprawdzenia, bo tam najłatwiej popełnić błąd. Musi też to być kod niezależny od żadnych zewnętrznych danych, czyli np. bazy danych lub systemu plików. Chcemy, aby wszystkie testy wykonywały się tylko w pamięci RAM.

Z czego składają się testy jednostkowe?

Testy jednostkowe składają się z trzech części:

Arrange

TestsArrange.png

W tej części chcemy przygotować zmienne, obiekty, na których będziemy w późniejszym kroku używać metody. Są to też dane wejściowe do naszej funkcji.

Act

TestsAct.png

W tej części chcemy użyć metody, którą chcemy przetestować.

Assert

TestsAssert.png

W tej części sprawdzamy, czy metoda zwróciła oczekiwany rezultat. To jest operacja, które będzie osądzać o poprawności wykonywania metody.

Jak napisać test jednostkowy w .NET Core?

Najpierw tworzymy klasę do przetestowania bez implementacji metod.

CalculatorWithoutImplemetation.png

Tworzymy nowy projekt Class Library.

CreatingNewClassLibrary.png

CreatingNewClassLibrary2.png

Dodajemy zależności do projektu z klasą do przetestowania.

AddingReferenceToTheProject.png

AddingReferneceToTheProject2.png

Dodajemy paczki Nuget.

AddingNugets.png

AddingNugetsPackage.png

  • NUnit – framework do tworzenia testów jednostkowych.
  • NUnit3TestAdapter – framework umożliwiająca uruchamianie testów w Visual Studio.
  • Microsoft.NET.Test.Sdk – biblioteka umożliwiająca testowania aplikacji .NET Core.
  • FluentAssertions – ta pozycja nie jest konieczna, aczkolwiek jeżeli komuś zwykłe Asserty wydają się mało intuicyjne, warto ją dodać. Pozwala ona na pisanie assert’ów, tak żeby przypominały zdania w języku angielskim.

Tworzymy klasę do testowania, oznaczoną atrybutem [TestFixture].

TestFixture.png

Tworzymy metodę testującą, oznaczając ją atrybutem [Test]. Warto tu zwrócić uwagę, że nazwy metod nie są napisane notacją CamelCase, tylko wyrazy są poprzedzielane „_”. Podobno to zwiększa czytelność testów. Nie sprawdzałem, ale zakładam, że tak jest.

MethodWithTestAtribuite.png

Piszemy testy jednostkowe.

Tests.png

Tests2.png

W Visual Studio w zakładce Tests wchodzimy w Windows, a następnie Test Explorer lub klikamy Ctrl+E, T. Klikamy Run All. Jeżeli testy są poprawnie napisane, powinny zakończyć się niepowodzeniem.

Errors.png

Piszemy implementacje metod w projekcie produkcyjnym.

CalculatorWithImplementedMethods.png

Teraz po uruchomieniu testów, jeżeli wszystko napisane jest poprawnie, powinny przejść.

WorkingTests.png

Kolejnym krokiem powinna być refaktoryzacja kodu produkcyjnego. W tym przypadku chyba nie da się tego prościej napisać.

Całość kodu z powyższego poradnika znajduje się na GitHubie.

Podsumowanie

Warto pisać testy, ponieważ nie są one takie trudne, a potrafią oszczędzić długich sesji z debuggerem.

Jeżeli dotarliście do tego miejsca, to dziękuję za przeczytanie tego wpisu. Mam nadzieję, że przybliżył on wam temat testów jednostkowych. Jeżeli macie jakieś pytania albo sugestię piszcie w komentarzach poniżej. Do następnego wpisu, który już nie długo.

Wracamy do blogowania – plany na końcówkę tego roku

Przez ostatnie dobre kilka miesięcy nie napisałem ani jednego wpisu na blogu. Trochę się tu zakurzyło. Jestem zdumiony, że tydzień w tydzień zagląda tu kilka osób. Takiego potencjału ludzkiego nie warto marnować. Nawet jeżeli jest tak skromny. Czas na zmiany. I o tym będzie ten wpis.

GitHub

Pierwszą zmianą, jaką zrobiłem, było założenie nowego profilu na GitHubie. Tym razem opatrzonego moim imieniem i nazwiskiem. Planowo będzie to moje portfolio będące częścią mojego pierwszego programistycznego CV. Tę decyzję podjąłem po przeczytaniu kilku pierwszych rozdziałów książki „Zawód: Programista” Macieja Aniserowicza. Napewno wkrótce pojawi się jej recezja.

Projekty

GitHuba trzeba czymś zapełnić. Za poprzednim razem, kiedy prowadziłem bloga czy GitHuba podchodziłem do tworzonych projektów na zbyt dużą skalę. Tym razem nie zamierzam popełnić tego samego błędu. Dlatego na sam początek wybrałem projekt sprawiający wrażenie znacznie mniejszego i prostszego od tego, co poprzednio próbowałem pisać Kalendarz. Najpierw stworzę REST API w ASP.NET Core. Bazuję na kursie Piotra Gankiewicza „Becoming a software developer”, który zresztą bardzo polecam. Do tego zamierzam potem stworzyć klienty aplikacji: webowy w AngularJS i na telefon w Xamarinie.

Priorytety

Dotychczas brałem się za zbyt wiele rzeczy naraz. Z tego powodu wszystko robiłem na nijakim poziomie. Od teraz, mam nadzieję, będzie inaczej. A to dlatego, że zamierzam poświęcić się prawie w pełni programowaniu.

Nowy początek

To tyle, jeżeli chodzi o to, co się zmieni. Za parę miesięcy będą jeszcze większe, ale o tym napiszę w swoim czasie. Dzięki za przeczytanie tego wpisu i zapraszam do śledzenia tego bloga, bo już niedługo, mam szczerą nadzieję, będzie tutaj dosyć sporo konkretnej wiedzy programistycznej.

 

Rezygnuje z tworzenia gier

Po obejrzeniu webinaru organizowanym przez Coders Lab z udziałem Macieja Aniserowicza na temat pracy programisty backendowego podjąłem decyzję, że rezygnuję z tworzenia gier komputerowych.

Rezygnuje z game dev’u, ponieważ:

  • Jest tam mnóstwo pracy związanej z grafiką, dźwiękiem oraz projektowaniem mechaniki (jeżeli pracujemy sami tak jak ja).
  • Więcej czasu zajmuje robienie map (lokacji) niż rzeczywista praca w kodzie.
  • Przy pracy na poziomie bibliotek graficznych (DirectX, OpenGL) wymaga dobrej znajomości matematyki, za którą za bardzo nie przepadam.
  • Po prostu jest to dla mnie nudne.

Zamierzam wrócić tylko tym razem w .NET Core do backend’u. Swoją decyzję argumentuje tym:

  • Wcześniej pisałem strony w PHP i pomijając język, bardzo mi się to podobało.
  • Można bardzo znacznej części odciąć się od pracy, przy której wymagane są umiejętności artystyczne (np. poprzez tworzenie API).
  • Patrząc w przyszłość – na rynku jest więcej pracy w programowaniu webowym niż przy robieniu gier komputerowych.

W związku z tym porzucam projekt gry Moon Problem, którą robiłem podczas Daj Się Poznać 2017. Po prostu z niektórych projektów trzeba zrezygnować. Ja powinienem zrobić to już dawno.

Mam już pomysł co chciałbym zrobić w .NET Core, ale na to poświęcę osobny wpis. Mam nadzieję, że dzięki temu, że będę robił coś nowego, będę miał więcej zapału zarówno do kodowania, jak i blogowania. Do zobaczenia w następnym wpisie, który mam nadzieję, będzie już niedługo.

 

Jak przenosić obiekty między scenami w Unity?

Czasem zdarza się, że potrzebujemy przenieść między scenami różnego rodzaju informacje np. doświadczenie, ilość pozostały żyć itp. do innej sceny. Jest na to kilka sposobów. Ja zaprezentuje rozwiązanie, które według mnie jest najlepsze.

A więc zaczynamy:

  1. Tworzymy pusty obiekt.
  2. Tworzymy nowy skrypt C# o następującej zawartości:
  3. 2017-08-02 16_47_24-DontDestroyOnLoadTutorial - Microsoft Visual Studio
  4. Podpinamy skrypt pod pusty obiekt.
  5. W obiektach, które potrzebują uzyskać dostęp do przechowywanych danych (w tym przypadku do pola tekstowego), tworzymy skrypt C#:2017-08-02 16_45_19-DontDestroyOnLoadTutorial - Microsoft Visual Studio
  6. Po uruchomieniu mimo zmiany sceny pole tekstowe zawiera te same informacje.

Kod źródłowy z tego wpisu jest do pobrania na GitHubie.

Dzięki za przeczytanie tego wpisu. Jeśli masz jakieś pytania albo zastrzeżenia śmiało pisz w komentarzach. Do następnego wpisu.

 

Straciłem WSZYSTKIE notatki w OneNote!!!

OneNote to prawdopodobnie jedno z nielicznych narzędzi Microsoftu, które dobrze wyszło. Ten program jest jednym z elementów pakietu Microsoft Office. Możemy z niego także korzystać mając go pobranego ze Sklepu Windows, który jest dostępny od Windows 8. Trzecią opcją jest uruchomienie OneNote z przeglądarki, korzystając ze strony https://www.onenote.com/.

Ja osobiście korzystałem z tej drugiej opcji, bo wydawała mi się najwygodniejsza. Jak wkrótce się okaże zdecydowanie nie najbezpieczniejsza.

Jak udało mi się wszystko stracić?

Wbrew pozorom jest to bardzo proste. Kiedy korzystamy z OneNote ze sklepu Windows oraz z przeglądarki, aplikacja zapisuje notatki na OneDrive, nie robiąc żadnych kopii zapasowych. Wystarczy tylko taka nieświadoma osoba jak ja i chęć posprzątania (czytaj: usunięcia) wszystkiego na OneNote, żeby wszystkie plany, pomysły, informacje itp. bezpowrotnie wyparowały.

Czy można takim wydarzeniom zapobiec?

Pierwsza rzecz, jaka się nasuwa to nie usuwanie niczego z OneNote. Może i jest to jakieś rozwiązanie, ale mimo wszystko z zapomnienia, zaspania, zagapienia, albo innej chwilowej świadomości możemy przez przypadek notatki z OneDrive usunąć. Pasowałoby mieć wtedy kopię zapasową.

Korzystamy z aplikacji ze sklepu lub przez przeglądarkę

W tym przypadku muszę was rozczarować. Nie da się zrobić kopii zapasowej. Jest to spowodowane tym, że:

W menu nie ma żadnej opcji tworzenia kopii zapasowej.

2017-06-15 17_12_15-Notes użytkownika Lukasz — Microsoft OneNote Online

2017-06-15 17_12_51-Store

Z OneDrive nie można pobrać pliku z notatkami.

2017-06-15 17_13_18-Dokumenty — OneDrive

Po zsynchronizowaniu OneDrive z folderem programu w Windowsie powstaje tylko link przekierowujący do notatek na OneDrive.

2017-06-15 17_16_25-F__OneDrive_Dokumenty

Jest jednak druga opcja, która spowodowała, że przesiadłem się na inną wersję OneNote.

Korzystamy z programu z pakietu Microsoft Office

W tym przypadku program pozwala nam na stworzenie kopii zapasowej. Wystarczy wejść w Plik > Opcje > Zapisywanie i kopia zapasowa. Tam można ustawić folder kopii zapasowej oraz częstotliwość jej robienia. Można także wykonać ręcznie kopię zapasową.

2017-06-15 17_14_05-Opcje programu OneNote

Dzięki temu nasze notatki są nieco bezpieczniejsze, bo jeżeli stracimy notatki z OneDrive to możemy je znaleźć na dysku i odwrotnie.

To tyle na dziś. Jeżeli macie jakieś uwagi zachęcam do komentowania. Do następnego wpisu.