O opóźniaczach cz. 1 – potrzeba dokończenia

Niestety jak widać ostatni projekt nie wypalił, nic w jego temacie się nie dzieje 😦 Natomiast zacząłem uważniej obserwować swoje nawyki i przyzwyczajenia i dzisiaj będzie o tym. O przeróżnych opóźniaczach, utrudniających realizację wartościowych i ciekawych zadań / projektów.

A więc punkt pierwszy: potrzeba dokończenia.

Bardzo często jak kupię jakiś magazyn, rozpocznę książkę czy dodam kolejną zakładkę do przeczytania później (przeklęte otwieranie kart w tle) – mówię tutaj o rzeczach pozornie „ważnych” i „rozwijających” – na szczęście nie mam aż takiego problemu z porzuceniem rozpoczętej gry, serialu czy komiksu – czuję wewnętrzną potrzebę dokończenia, wyczyszczenia zakładek w tle, rozebrania do dna stosu książek czy przejrzenia a kiedyś przeczytania od deski do deski magazynu. Po prostu muszę skończyć, muszę być obowiązkowy, muszę się „uczyć” i „rozwijać”.

A tak naprawdę spalam zasoby energii i uwagi na nic nie znaczące artykuły, połykam godziny na rzeczach, które nie są związane z żadnym prowadzonym projektem, czy to w pracy czy prywatnie. Oczywiście usprawiedliwiam się przed sobą i czuję dobrze, że przecież nie marnuję czasu i nie oglądam filmów o kotkach na wykopie ale CZYTAM O WAŻNYCH RZECZACH na które natknąłem się… na wykopie.

Czy do czegokolwiek prowadzi? Wątpię i moim zdaniem można to umieścić na równi z oglądaniem kotków. Hamburgerowy zapychacz mojego umysłu, który domaga się jakiejkolwiek pracy, z czasem coraz mniej wymagającej (nikt mi chyba nie powie, że bierne czytanie jest bardziej produktywne od klepania kodu 🙂 ). Większość tych „arcyważnych” treści którymi się karmię każdego dnia nie dotarła do mnie wskutek aktywnego szukania i googlania, zostałem nimi zawalony ponieważ ktoś inny, ktoś kogo nie znam uznał je za ciekawe i zarzucił mnie nimi.

To do niczego nie prowadzi.

I trzeba to zmienić. Jeszcze nie wiem jak. Ale potrzeba dokończenia (która może być dobrą i chwalebną rzeczą przy pracy nad projektem) w połączeniu z zalewem trashowego internetowego bełkotu nigdzie mnie nie prowadzi.

Dawniej na studiach uczyłem się więcej i byłem bardziej produktywny postawiony przed tygodniowym zadaniem programistycznym przez prowadzącego mając do dyspozycji offline bibliotekę MSDN (czy jak to się zwało) i wolny modem rozliczany impulsowo niż teraz mają nielimitowany internet na każdym urządzeniu 24/7 przez cały miesiąc. Taka smutna prawda 😦

Także czas na TASK DRIVEN LEARNING – TDL 🙂

Projekt 730 – dzień 35 – założenia aplikacji

Wczoraj odbiłem się od prozaicznej rzeczy – jak nadać label dodawanym przyciskom w aplikacji. Okazuje się, że mimo iż parę miesięcy temu ukończyłem kurs na Udemy, nawet 2 z pisania aplikacji w Swift, nie używałem tej wiedzy i zwyczajnie zapomniałem. Także mniej uczenia, więcej robienia 🙂

Kolejnym wyzwaniem okazało się, że nawet nie wiem, jak ta aplikacja ma wyglądać. Zabrałem się ostro do pracy, odpalam projekt i… koniec. Wiem czym ma być, ale jaka ma być? Ile przycisków? Gdzie rozmieszczone? Jako, że działamy, nie uczymy się w nieskończoność, nie będę teraz szukać metodyk projektowania itd., po prostu podążę za intuicją i napiszę, czego chcę od tej aplikacji.

 

  1. Ma to być quizowa aplikacja (szok i niedowierzanie 😉 )
  2. Lista pytań musi być za każdym razem inna, aczkolwiek regrywalność będzie ograniczona gdyż siłą rzeczy każda lista jest skończona
  3. Opcje odpowiedzi będą binarne, za każdym razem będzie się zmieniać label przycisków
  4. Aplikacja ma być ładna, napisana zgodnie (?) z nowymi trendami. Żadnych na odwal się projektów
  5. Aplikacja ma być gotowa do wystawienia do App Store’a
  6. Aplikacja będzie zliczać punkty – sprawdź czy nie gryzie się to z punktem 2 (ciężko porównać punkty w losowych zestawach pytań)
  7. Do przemyślenia kwestie społecznościowe. Może powstanie spin off tylko na potrzeby iMessage
  8. Kod aplikacji będzie trzymany w githubie
  9. W aplikacji nie będzie muzyki, ale będą dźwięki
  10. Ma być tak zaprojektowana, by można ją było obsłużyć jedną ręką. Tryb pionowy tylko

 

To chyba tyle, jeśli coś jeszcze przyjdzie mi do głowy dopiszę do listy. Definitywnie zamknę ją w niedzielę.

 

Projekt 730 miesiąc później

Więc tak… Nie napisałem żaden linijki nowego kodu. Okazało się, że gównoburze w internecie pod nic nieważnymi artykułami o polityce bardziej mnie angażują. Odbieram to jako sporą porażkę. Ale… nie po to upadamy, by leżeć. Restart 🙂

Z dobrych nowin – usunąłem prawie wszystkie podcasty o grach i subskrypcje z Humble Bundle Monthly. Została Forumogadka, waham się czy jej też nie wyrzucić, niepotrzebnie nakręca mi głód grania (na które naprawdę nie mam czasu i siadam do zabawy z gotującym się w środku wyrzutem sumienia – gdzie w tym przyjemność? )

Udało mi się również dwa dni temu napisać kod w Javie, implementujący prosty blockchain. Ktoś napisał artykuł na dev.to w javascript, ktoś poprosił w komentarzu o wersję Java i była fajna okazja by poćwiczyć. Poziom satysfkacji: +100 🙂

Dzisiaj inauguruję pierwszy projekt iOS który dowiozę do końca od A do Z, do AppStore’a. Mam zabezpieczone fundusze na licencję, po tym jak zbiorę 3 projekty, opłacam i umieszczam je w sklepie.

Kryptonim projektu: „Po naszymu” – quizowa aplikacja oparta o lekcję z Udemy, którą już  przerobiłem – śląskie słowo i możliwe warianty odpowiedzi. Skierowana raczej do Goroli 😉 W trakcie pisania będę musiał pomyśleć nad jakąś kampanią szeptanego marketingu.

 

 

Projekt 730 – inauguracja

Mam dwóch synów, nie mam czasu na nic. Czy aby na pewno? O tym będzie ten projekt.

Ostatnio mój młodszy syn skończył rok. Powiedziałem parę dni temu do żony – no, jeszcze 2 lata i będzie dobrze, odzyskamy przespane noce i będziemy mieli więcej czasu.

Ale czemu czekać biernie? 2 lata to szmat zmarnowanego czasu. To 730 dni jeśli dobrze pamiętam ilość dni w roku 🙂 Każdego dnia coś można pchnąć naprzód. Zrobić tę jedną pompkę czy przeczytać o programowaniu napisać jakiś kod.

Na pierwszy plan trudne wybory. Towarzyszyły mi wiele lat (od czasu urodzenia Jasia a nawet wcześniej, co najmniej 4 lata) ale w sumie nic mi nie dają poza większą frustracją, że nie mam czasu na granie. Więc dzisiaj

usuwam wszelkie podcasty o graniu

Dzień pierwszy z 730 rozpoczęty. Do zobaczenia jutro!

 

Parę słów o testowaniu (regresja, sanity, smoke)

Poniższy tekst jest czystą formalnością, zapisuję dla uporządkowania terminologii.

Otóż do tej pory testowałem aplikacje, które poprawiałem lub pisałem od zera. Wczoraj i dzisiaj spotkałem się z terminami: regresja i testy regresyjne, testy smoke i testy sanity. Okazuje się, że wykonywałem do tej pory te czynności tylko trzymałem je w jednym worze (testowanie) natomiast użycie wczoraj tych pojęć w rozmowie z PM (project manager) wprowadziło małe zamieszanie. Dlatego wpisuję je tutaj by sobie wszystko uporządkować.

Za wikipedią

Regresja – zjawisko powstawania błędów w oprogramowaniu po zamierzonej zmianie w jakiejś części kodu programu (np. po wprowadzeniu poprawki dla innego błędu). Skutkiem tych zmian może być błędne działanie innej funkcji programu, która w poprzednich wersjach działała prawidłowo.

Aby wykryć regresję podczas rozwoju programu, należy prowadzić testowanie regresyjne.

Zazwyczaj wykonywanie testów regresyjnych związane jest z ponownym uruchomieniem zestawu testów, które wcześniej kończyły się poprawnie. Ma ono na celu ujawnienie potencjalnych problemów powstałych na skutek dokonanych zmian.

Czyli klasyka, zjawisko, z którym każdy spotkał się nieraz. Poprawiłem A, przestało działać B 🙂

 

Natomiast pojęcia smoke i sanity są dla mnie zupełną nowością.

Najlepszą definicję znalazłem tutaj

http://www.testowanie.net/testowanie/smoke-test-i-sanity-test/

Smoke test określa czy możliwe jest przeprowadzenie testów.
Sanity test odpowiada na pytanie czy jest to zasadne.

Smoke test

Smoke test mówi nam, czy program/system da się uruchomić, czy jego interfejsy są dostępne i czy reagują na działania użytkownika. Jeżeli smoke test nie powiedzie się nie ma powodu aby przechodzić do sanity testów. Ten typ testów przeprowadzany jest przez programistów tuż przed oddaniem wersji aplikacji lub przez testerów, przed zaakceptowaniem otrzymanej do testów aplikacji.

Sanity test

Sanity test sprawdza pojedyńcze funkcjonalności i daje odpowiedź na pytanie: czy logika aplikacji jest zgodna z dostarczonymi wymaganiami. Jeżeli przeprowadzenie sanity testu da negatywne rezultaty, nie ma powodu, aby przechodzić do następnej fazy testowania.

 

Lutowe wyzwania plus dobra karma dla umysłu

Trzymajcie kciuki, w lutym postanowiłem sobie dwa ważne wyzwania:

  1. Nie będę wchodzić na wykop. Póki co się udaje, ale łapię się na tym, że otwieram safari po paręnaście razy dziennie i palec zamiera nad zakładką. Po namyśle (popartym załączonymi poniżej artykułami) stwierdziłem, że to taki fb bis, rzadko znajduję tam wartościowy materiał a czas marnuję niemiłosiernie.
  2. Nie będę słuchać podcastów o grach komputerowych. Po pierwsze, dlatego, że nie mam kiedy w nie grać a takie słuchanie buduje tylko mój żal lub też psuje mi przyszłą zabawę poprzez spoilery lub czyjeś opinie. Po drugie dekoncentruje mnie w pracy.

 

Póki co minęły dwa dni a ja już mogę pochwalić się wyczyszczeniem listy otwartych w safari zakładek (niektóre wisiały tam od ponad miesiąca!). Tak trzymać.

 

Polecam również ciekawe artykuły, które mnie do tego zachęciły (i nie tylko, trochę robię taki ich zapis by nie uciekły).

Bardzo ciekawy blog, z niego będzie najwięcej linków

  1. Pożywka dla umysłu. Odrzuć fast food (wykop). Serio, zacząłem zauważać już u siebie problemy z koncentracją. http://jamesclear.com/brain-food
  2. Przestań odwlekać! Zasada dwóch minut (to akurat już znałem i czasami stosowałem, tutaj rozwinięcie tej idei) http://jamesclear.com/how-to-stop-procrastinating
  3. Nie ważny cel a system i wytrwałość. To akurat mnie mocno zaskoczyło, ciekawe podejście. http://jamesclear.com/goals-systems
  4. Zaufaj sobie i twórz! Jest to skorelowane z moimi niedawnymi przemyśleniami (może o tym napiszę). I właśnie z powodu tego artykułu w swoim wolnym czasie piszę tę notkę a nie rozwalam obcych w Xcom 2. I szczerze? Czuję się z tym wspaniale! http://jamesclear.com/make-things
  5. I na koniec polski blog, który warto śledzić, porusza ciekawe problemy dookoła programowania. Np. to, że pomimo ogromu pracy i potrzebnych kwalifikacji czujemy się często najsłabszym ogniwem w zespole. Czyli o „impostor syndrome” http://www.javadevmatt.pl/impostor-syndrome-u-programisty-i-nie-tylko/

 

PS. Akurat żona i dzieciaki śpią, ale boję się, że lada moment obudzi się najmłodszy i patrzę czujnie na zegarek. I co? I zamiast grać lub siedzieć na wykopie w ciągu ostatnich 20 minut:

  1. Napisałem ten post
  2. Kupiłem prezent walentynkowy
  3. Spisałem w notatkach parę pomysłów na aplikacje

To było dobry wieczór. Sobie i Wam więcej takich życzę.

Reaktywacja plus git merge vs. rebase

Krótko i na temat – przywracam bloga do życia – będzie znowu o grach ale również o rozwoju siebie, programowaniu, nauce, inżynierii programowania. Wszystko co ciekawe i czego się nauczyłem w danym dniu – ląduje na blogu!

 

Dzisiaj na przykład zagłębiłem się w temat różnic pomiędzy git merge a git rebase, polecam bardzo te dwa poniższe wpisy na ten temat.

 

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/workflow-walkthrough

http://www.pzielinski.com/?p=2667

Liczy się detal, zwłaszcza w mobilach

Obrazek

 

Ostatnio jedyną grą w jaką gram na telefonie (iPhone 4) jest Flappy Bird. Przez sieć przewinęła się już dyskusja na temat tej gry i wysypu jej klonów i do tego ostatniego tematu pozwolę sobie się odnieść.

Samą grę uważam za bardzo dobry produkt. Po pierwsze wciąga, jest solidnie wykonana, pozwala mi rozwijać „skill” i naprawdę sprawia mi sporo frajdy. Jest zdecydowanie warta uwagi i zasłużenie przynosi twórcy profity. I jest świetnym przykładem tego, że sam pomysł w świecie gier jest wart funta kłaków i liczy się wykonanie. Śmieszą mnie też argumenty, że to prosta, niewarta uwagi giereczka, którą mógłby zrobić każdy i nie warto się nią zajmować a autor Dong Nguyen niesprawiedliwie zarabia na niej kokosy (mimo usunięcia z AppStore reklamy nadal działają). Otóż twórcy Unreal Engine (tak tak, dokładnie tego zaawansowanego silnika) dostarczyli kolejnej porcji argumentów, że jednak liczy się wykonanie.

W ramach promocji swojego silnika, pokazali że dzięki niemu można tworzyć gry mobilne bez większej wiedzy programistycznej, tworząc Tappy Chicken. Grę zbudował ich grafik. I mimo identycznego pomysłu (ptaszek omija przeszkody) gra jest zupełnie odmienna od pierwowzoru. Ładuje się długo, działa wolno, ma trochę inny model fizyki i mimo lepszej grafiki oraz dodatkowych efektów zupełnie nie jest „miodna” (bardzo lubię ten termin, zawiera w sobie istotę gier). 

Aczkolwiek nie śpieszmy się pochopnie sądzić, że klony są lepsze od pierwowzorów. Otóż za drugi przykład niech posłużą nam gry logiczne Threes oraz wzorowana na niej 2048. Tutaj jest odwrotnie, 2048 działa płynniej i szybciej, „trójek” nie chce mi się włączać gdy mam w perspektywie czekanie minutę na załadowanie planszy.

Przykłady tych gier dowodzą, jak zawiłą i trudną materią są gry, jak delikatnym i wrażliwym procesem jest ich tworzenie. Sam pomysł to nie wszystko, kluczowym jest dopracowanie tytułu. Również odnoszę wrażenie, że wielu twórców (jak i konsumentów niestety) zupełnie nie rozumie platformy jaką jest telefon, jej możliwości ale i wielu ograniczeń. Kompletnie odpychają mnie tytuły ze skomplikowanym sterowaniem lub zbyt szczegółową grafiką wyświetlającą istotne dla rozgrywki detale wielkości paru pikseli na mały ekranie telefonu. Nie tędy droga. Moim zdaniem telefon to przede wszystkim miejsce dla lekkich pamięciowo, szybkich i płynnych tytułów o prostym sterowaniu (co nie znaczy że nie mogą to być skomplikowane i wymagające tytuły). Proszę nie starać się przykrywać braku dopracowania designu gry pamięciożernymi grafikami 🙂

 

Życzę sobie więcej Flappy Bird na komórki, śmiało nadchodźcie!

 

PS. Wpis ten również dedykuję wszystkim wyrzucającym pieniądze w projektach kickstarterowych lub Early Access. Ale o tym być może jeszcze innym razem. 

Rysa w anomalii (recenzja Anomaly 2)

Niedawno skończyłem drugą (trzecią jeśli liczyć Anomaly Korea) odsłonę cyklu o dzielnych Ziemianach atakujących wieże Obcych. 

Anomaly 2 stanowi rozwinięcie pomysłu z poprzednich części. Nadal walczymy ze stacjonarnymi wieżyczkami aczkolwiek nasze jednostki posiadają teraz dwa tryby pracy pomiędzy którymi przełączamy się podwójnym kliknięciem („morfujemy”). Twórcy zwrócili również uwagę na takie aspekty jak zasięg i szybkostrzelność, różnicując nasze jak i wrogie siły pod tym względem (na przykład niektórych pozaziemskich konstrukcji nie wolno atakować szybkostrzelnymi oddziałami). Jest to próba pogłębienia rozgrywki, moim zdaniem średnio udana (większość gry przeszedłem rekieterami). 

Dodatkowo Anomaly 2 została wyposażona w tryb multiplayer, którego niestety nie udało mi się przetestować z braku chętnych do gry. Więc jak chcecie zagrać w MP to najlepiej z jakimś kolegą.

 

Moje wrażenia? Szału nie ma. Rozszerzenie o możliwość zmiany funkcji jednostek w locie jest ciekawym pomysłem, który potrafi się przerodzić w irytującą przeszkadzajkę w bardziej gorących momentach. Gra jest po prostu kolejną częścią Anomaly i moim zdaniem gorszą od swoich poprzedniczek. Grałem we wszystkie części i tę musiałem „wymęczyć” do końca, nie mając praktycznie już żadnej radochy gry, byle odłożyć na wirtualną półkę „ukończone”. 

Winę za to ponoszą moim zdaniem dwa czynniki. Pierwszy to brak znacznego rozwoju wieżyczek (pominę wieżyczkę Predator i koszmarną misję, podczas której się pojawia, chciałbym poznać osobę, która tę misję zaprojektowała). Ogólnie widzieliśmy już to wszystko wcześniej.

Drugi winowajca ( za to poleci parę oczek w dół w ocenie) to FATALNY system save / checkpoint. Misje są naprawdę wymagające i potrafią trwać po pół godziny jeśli się przykładasz. I teraz ciekawostka – checkpointy są rozmieszczone wyjątkowo rzadko i nielogicznie. Wiele razy zwłaszcza po wprowadzeniu wspomnianej wcześniej wieżyczki Predator czyściłem jakiś obszar z Obcych potem wracałem się pół mapy do ostatniego checkpointa by zapisać i tak w kółko. Czytając w czasie powrotów gazetę / książkę.  P   A   S   J   O   N   U   J   Ą   C   E … 

Po drugie save’y. Ja nie proszę o wiele, ale taka funkcjonalność jak zapisanie gry w danym momencie w chwili wyjścia z niej to jednak już jakiś standard. Dwa razy musiałem odejść od gry i wyłączyć komputer i naprawdę było mi szkoda zmarnowanego czasu. Nie wiem jak twórcy, ale żonaci pracujący 30latkowie nie mają nieskończonych zasobów wolnego czasu.

Oczywiście przy każdym powrocie do misji gra musiała mi pokazać każdą cutscenkę, każdy dialog, każdy filmik pokazujący użycie nowej broni. Ech… bolało.

Rozgrywka mimo dodania wcześniej wspomnianych możliwości wydawała mi się płytsza niż wcześniej i miałem wrażenie, że na siłę w niektórych miejscach wpycha się żądane przez level designera rozwiązanie. „Patrz, tutaj MUSISZ użyć tego pojazdu, bo jak nie to zgniotę Cię jak robaka”. Wolność w taktycznym podejściu znana z poprzednich części (mimo mniejszego zasobu środków w dyspozycji gracza!) gdzieś uleciała. 

 

Podsumowując. Byłem fanem serii, zagrałem we wszystkie części włącznie z genialnym Winter Challenge, niestety Anomaly 2 czegoś zabrakło plus nie naprawiła błędów poprzedniczek (mimo obietnic twórców z vlogów kręconych w czasie tworzenia gry). Szkoda. Po kolejną grę z serii na pewno nie sięgnę. 

Ocena 6/10

 

PS. Planuję w kolejnym wpisie przeanalizować pod względem designu grę i w ramach ćwiczeń zaproponować autorską wersję Anomaly 2.