Końcówka pierwszego (dla mnie) tygodnia konkursu, a ja nie napisałem jeszcze co będę robił 😉 Najwyższy czas, żeby to zmienić, chociaż z góry lojalnie informuję, że ten post będzie króciutki. Założenia nie są imponujące, ponieważ jest to malutki projekcik, a celem uczestnictwa w konkursie jest przede wszystkim rozwój bloga. Dlatego chcę w każdy poniedziałek rano publikować jakiś fajny tekst „około IT”, a około czwartku popołudniem post związany z projektem. Taki jest plan, który jak widać już pierwszego tygodnia nie wypalił (dzisiaj sobota). W tym roku podchodzę do konkursu inaczej i 80% postów mam już zaplanowane. Mogę powiedzieć tyle, że to ciekawe tematy, dlatego zachęcam do śledzenia.

Co jest celem projektu

Jak zapewne można domyślić się po nazwie, napisanie biblioteki wyświetlającej konkretny dzień. Coś w stylu kartki z kalendarza, poniżej koncept stworzony w paincie (finalna wersja będzie oczywiście ładniejsza).

Prawda, że skomplikowane? 😉 Cóż, kilka rzeczy które chcę osiągnąć w tym projekcie:

• użycie Kotlina
• material design
• miły dla oka design
• dobre testy
• continous – co się da
• prawdziwa dokumentacja (opis całego API, etc)
• prawdziwy open-source (z ładnym, pokazującym działanie biblioteki na gifach plikiem README)
• odrobina reklamy, chcę, żeby inni również z niej skorzystali

Ale, dlaczego?

Cóż, potrzebowałem kiedyś takiej biblioteki, która na połowie ekranu np wyświetlała by konkretny dzisiejszy dzień, a poniżej tego mógłbym mieć cokolwiek. Przeszukałem internet i nie było.. Więc teraz już będzie, i będę bardzo szczęśliwy, jeśli przyda się nie tylko mi 😉

API

Jak nie trudno się domyślić, tutaj również nie będzie szaleństw. Przewiduję takie metody:

• setDate(Date date);
• setBarColor(Color color);
• setBarTextColor(Color color);
• setCardColor(Color color);
• setCardTextColor(Color color);

Dodatkowo mam w planach jakąś animację podczas pojawiania się, albo zmiany daty, zobaczymy.

To jest tak właściwie wszystko, jeśli chodzi o założenia. Nie są one imponujące, ale o tym ostrzegałem już we wstępie. Jest to projekt wyjęty z „szufladeczki”, o której już pisałem i pewnie jeszcze nie raz napiszę.

To był długi dzień. Wraca człowiek do domu, bierze prysznic i *ding* – do głowy wpada kolejny świetny pomysł. Nie ważne, czy to aplikacja, czy strona internetowa, czy może jakieś urządzenie wyposażone w rapsberry pi. Jest myśl, tak to genialne, pewnie zarobię na tym miliony, a na pewno – przynajmniej – zrealizuję. A jeśli nie zrealizuję, to chociaż schowam do szufladki oznaczonej jako „pomysły do wykonania kiedyś”. Komu zdarzają się takie sytuacje?

Mam pomysł!

tl;dr Od pomysłu do implementacji powinniśmy wykonać 7 kroków projektując aplikację: pomysł, przeczekanie entuzjazmu (pozwolenie pomysłowi na zweryfikowanie się), memory dump, mind mapping, wymagania funkcjonalne i scenariusze użytkowania, wybór technologii, implementacja.

Pół biedy kiedy aktualnie mamy na głowie inne rzeczy i pomysł wpadnie do szufladki i przeczeka tam kilka miesięcy. Wtedy wszystko w głowie zaczyna się układać. Człowiek dostrzega cienie, ale i możliwości rozwoju projektu, o których nie pomyślał wcześniej. Dzieje się tak ponieważ sen wyewoluował do formy w której pomaga nam rozwiązać problemy z którymi zmagaliśmy się w ciągu dnia. Autorem tej teorii jest Deirdre Barrett i osobiście – wydaje mi się ona (teoria) przynajmniej prawdopodobna. Bo ile razy było tak, że człowiek zasypiał z problemem, a budził się z rozwiązaniem?

A co się dzieje, jeśli akurat mamy czas? Cóż, jesteśmy programistami, więc – implementacja. Już widzimy w głowie ten kodzik, jak będziemy klepać, jakie wzorce, i ten nowy framework! Co ciekawe ten mechanizm zachodzi również w pracy, podczas rozmowy z klientem tylko usłyszymy o tym co mamy zrobić, już nasz mózg przystępuje do rozwiązywania problemów implementacyjnych. To nic, że spotkanie jeszcze trwa, że nie znamy prawie żadnych szczegółów – my już wiemy jak trzeba będzie to naklepać. A to najgorsze co można zrobić. Rozmyślanie nad pomysłem powinno być abstrakcyjne, a wtrącające się w tym momencie myśli o implementacji tylko porządkują, tzn wpychają w sztywne ramy nasze rozmyślania. A to zdecydowanie nie jest dobre.

Mózg programisty

Więc jak to robić? Tutaj bardzo przydaje się czas, a co za tym idzie sen. U siebie nie widzę problemu, nigdy nie mam czasu 😉 Tzn cokolwiek wymyślę ląduje w szufladce „na później”. Podobnie jest z moim projektem na konkurs, notatka o nim pojawiła się 22.08.2016 w moim Evernote. Czyli blisko 5 miesięcy przed startem konkursu, teraz jest idealny czas, żeby pomysł zaimplementować.

Noo dobrze, wpadłem na pomysł odczekałem te kilka dni, znam już plusy i minusy, wiem co może się udać a co nie, jaki jest następny krok? Tak naprawdę już odczekując te kilka dni, warto wszystkie myśli o projekcie sobie zapisywać. Tak luźno, zwykły memory dump, cokolwiek nowego się pojawi. A potem z tego bałaganu, tworzymy inny bałagan, czyli mapę myśli. Ja korzystam z narzędzia xMind, ale to nie ma znaczenia. Pokrótce czym są mapy myśli? Ważne, żeby na środku był zapisany, albo narysowany główny cel, a na gałęziach wszystkie rzeczy które się z nim wiążą. W formie odrobinę uporządkowanej, tzn tylko tematycznie. Taki jest mój przepis, ale w mapach myśli chodzi o to, żeby każdy miał tak naprawdę swój 😉

Mapa myśli obrazująca jak tworzyć mapy myśli – rekurencja

Jaki jest następny krok? Wymagania funkcjonalne oraz scenariusze użytkowania. Oczywiście chodzi o to, żeby było sprecyzowane co takiego ma robić aplikacja, oraz w jaki sposób się z niej korzysta, do czego może się przydać, kto może zostać potencjalnym klientem i ewentualnie, jak za nią zapłaci.

Kolejny to dopiero projektowanie interfejsu, oraz wreszcie nasz ulubiony wybór technologii, frameworków, kolorów w edytorze, czyli to co misie lubią najbardziej 😉 i nareszcie przechodzimy do implementacji.

Reasumując, można wymyślić projekt, usiąść i zacząć go klepać. Ale na dłuższą metę to trochę mi ja się z celem, ponieważ po głębokiej analizie może się okazać, że ten nikomu się nie przyda, albo tylko nam będzie się podobał. Nie przeczę, że po przeprowadzeniu kilku kroków powyższego procesu czasem szczerze, samemu przed sobą trzeba będzie przyznać, że nie – ten pomysł jednak był słaby. Ale czy nie lepiej powiedzieć to sobie na początku, niż stracić czas na implementację, z której nic nie wyniknie, zamiast realizować coś naprawdę fajnego?