Webdeveloping, cz. 2/3 - Planowanie
Obiecuje. To ostatnia część przed częścią numer 1. Ale uważam, że właśnie tak się powinno do tego zabierać. Nim napiszemy pierwszą klasę trzeba mieć wszystko przygotowane i jasne. Bo później zazwyczaj jest za późno. Tę ostatnią część poświęcę na zaplanowanie aplikacji, którą wspólnie napiszemy. W częsci 0 sugerowałem, że napiszemy razem bloga. Pojawiły się głosy w komentarzach z propozycją innych aplikacji, na przykład sklepu (ze wsparciem dla magazynu i płatności online). No w sumie... można by. Ale takie sklepy nie kosztują tak wiele bez powodu. Zdecydowałem, że jednak to będzie blog. Tak, żeby dać wędkę, a nie rybę.
Jednak zanim zacznę planować naszego bloga napiszę kilka słów o tym, jak wygląda życie projektu. A dokładniej - jak to wynika z mojego doświadczenia. Nie twierdzę, że wszędzie jest dokładnie tak samo, że jest to zgodne z jakąkolwiek metodologią, systemami czy przekonaniami. Po prostu wiem, że tak w określonym środowisku to działa.
Zacznijmy od pomysłu na aplikację. Ktoś kreatywnie uzdolniony, wcale to nie musi być developer, wpada na pomysł jak zarobić pieniądze albo uzyskać inną korzyść. Oczywiście korzystając z narzędzi, jakie daje nam internet. Przenosząc to na nasze - stworzymy bloga. Pomysł mało oryginalny, mało też prawdopodobne, by zaczął przynosić pieniądze, tylko dlatego, że stworzymy go własnymi rękoma. Korzyść więc może być w tym, że go zrobimy sami. Zrobimy i, o ile będzie dobry, zostanie dołączony do aplikacji w portfolio. A to już jest niewątpliwie korzyść.
Teraz powinien przyjść ktoś, kto nie jest kreatywny, ale za to jest pragmatyczny. Popatrzy on na nasz projekt i powie: "Tak, to można zrobić. Aby ta wizja działała, należy zapewnić to, to i jeszcze to". Znów przenosząc scenkę na naszą sytuację zrobimy takiego bloga, który pozwala:
[list] [item]Przeglądać wpisy
- Pojedynczy, cały wpis
- Kilka zajawek na pojedynczej stronie, paginacja
- Przeglądanie wpisów z zakresu dat
[/item][item]Dodawanie komentarzy
- ...ale także ich usuwanie
[/item][item]Tworzenie wpisów
- Celem będzie oddanie platformy zapewniającej funkcjonalność przynajmniej takiej, jak na DP.pl
- Ale raczej wątpię, żebym to wszystko pokazał.
[/item][item]Logowanie
- Oddamy możliwość zalogowania się i uzyskania odpowiednich uprawnień
- Kontami trzeba będzie jakoś mądrze zarządzać...
- I tutaj się kłaniają aspekty prawne
[/item][/list]
Makiety
Mamy już zakres funkcjonalności naszej aplikacji. Czas więc by stworzone zostały jej makiety. Makieta to statyczny (lub dynamiczny. Odpowiednie aplikacje zapewniają już taką możliwość) obrazek strony, który prezentuje założenia wyglądu strony, która następnie zostaje przycięta do HTML, CSS i czasem tworzone są od razu skrypty JS. Makieta powinna prezentować wygląd każdej pojedynczej strony wraz z każdym aktywnym elementem (na przykład jeśli menu ma się rozwijać należy przedstawić rozwijane manu, jeśli element posiada hovera - należy go zademonstrować). Stworzenie makiet nie jest może kluczowe dla aplikacji, ale bardzo pomaga w stworzeniu takiej, która będzie funkcjonalna i zapewniała wysoki poziom UX. Na tej części znam się bardzo mało. Opieram się najczęściej na własnych odczuciach co do konstrukcji strony.
W naszym przypadku pójdziemy lekko na łatwiznę. Konstrukcja strony będzie bardzo prosta:
[list] [item]header - jakaś graficzka na stronie a w <h> wrzuci się nazwę oraz subtytuł[/item][item]main - tutaj podział na dwie kolumny
- część z wpisami
- część z menu
[/item][item]Footer - jakieś tam linki dla SEO[/item][/list]
... będzie więc bardzo podobna do tej prezentowanej przez stronę blogów DP.pl.
Modeling
Modelowanie aplikacji polega na jej opisaniu. Tak, najprościej chyba, można ten proces zdefiniować. Jest to niezwykle ważny element tworzenia aplikacji (zwłaszcza rozbudowanej), który w procesie jej tworzenia jest bardzo cenny. Wszystko polega na tym, by jak najdokładniej opisać aplikację przy pomocy formalnego (zunifikowanego) języka. Wyróżnia się kilkanaście diagramów, które ułatwiają ten proces, ale ich ilość jest zależna od skomplikowania aplikacji. W naszym przypadku nie jest tego tak dużo, projekt jest w zasadzie prozaiczny. Wystarczy przez chwilę pomyśleć o przypadkach użycia (praktycznie opisany wcześniej) by stwierdzić, że pisanie dla nich diagramów jest modelowaniem dla samego modelowania. Piszę więc o tym dlatego, żeby został ślad, iż taki etap także trzeba brać pod uwagę.
Inną sprawą jest wymodelowanie bazy danych. Tutaj też nie ma zbyt wiele do kombinowania. Baza będzie musiała zawierać tablice z komentarzami, tablice z wpisami, tablice z wersjami wpisów (może być zasobożerna!), tablicę z użytkownikami i tablicę z konfiguracją strony. Między sobą tablice będą posiadać relacje. Szczegóły - w następnej części.
Agile
Proces tworzenia aplikacji dobrze rozdzielić sobie na części. I my tak zrobimy. Lubię zwinne metodologie, dlatego posłużę się jedną z nich do stworzenia tej aplikacji. Podzielę developerkę na następujące etapy:
- Szkielet aplikacji - z CRUDa na tym etapie powinno być R. Dodatkowo może jakiś podstawowy widok (bez ostylowania) do jego wyświetlania.
- Aplikacja powinna już wyglądać tak, jak byśmy chcieli od strony frontu. Paginacja, dodawanie komentarzy itp.
- Możliwość logowania oraz odpowiednie w związku z tym uprawnienia. Dodawanie nowych wpisów, zarządzanie obecnymi.
Szykują się więc przynajmniej trzy części, a po każdej będziemy mieć już jakiś konkretny produkt. O podziale etapów na zdania opowiem przy okazji każdego z nich.
I to tyle
Tak, nie ma już na co czekać. Odpalamy IDE, klienta bazy, przeglądarkę i zaczynamy. W części następnej przy pomocy MySQL WorkBench stworzymy sobie bazę danych oraz przedstawię z grubsza CodeIgnitera. Do tego jakiś mały MVC.