Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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:

  • Przeglądać wpisy
    • Pojedynczy, cały wpis
    • Kilka zajawek na pojedynczej stronie, paginacja
    • Przeglądanie wpisów z zakresu dat
  • Dodawanie komentarzy
    • ...ale także ich usuwanie
  • 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ł.
  • 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

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:

  • header - jakaś graficzka na stronie a w <h> wrzuci się nazwę oraz subtytuł
  • main - tutaj podział na dwie kolumny
    • część z wpisami
    • część z menu
  • Footer - jakieś tam linki dla SEO

... 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. 

programowanie

Komentarze

0 nowych
przemol96   5 #1 13.07.2013 12:36

Fajny wpis ;), czekam na kolejny!

soanvig   9 #2 13.07.2013 12:42

"Obiecuje. To ostatnia część przed częścią numer 1."
20 minut siedzę już nad tym zdaniem i nie umiem go rozgryźć.

A... bo to jest część 2/3 (ułamek), a nie druga z trzech :D

Autor edytował komentarz.
czytacz   3 #3 14.07.2013 02:52

Nad Codeigniterem zbierają się ciemne chmury... Dialbi wiedzą czy w ogóle czeka go jeszcze jakaś przyszłość:
http://ellislab.com/blog/entry/ellislab-seeking-new-owner-for-codeigniter

stasinek   10 #4 14.07.2013 15:51

łał niesamowite, kolejny wpis w zasadzie o niczym, dzięki za kursik webdevelopera który dopiero będzie bo narazie o nim myślisz i myślisz, powodzenia

KyRol   17 #5 15.07.2013 02:24

@stasinek:

Te królik, opanuj się, bo sałaty nie dostaniesz. Uszanuj czyjeś chęci, wysiłek i czas. Znając życie, przy takim podejściu jak twoje, gdy tylko ktoś poda konkrety na tacy, blog zaleje lawina oczywistych pytań. Takich wpisów nie tylko w polskiej sieci nie ma wiele, ale malkontent oczywiście musiał się znaleźć.

Autor edytował komentarz.
parasite85   7 #6 15.07.2013 07:20

Wpis ciekawy, ale nie do końca się zgodzę z Twoim zdaniem na temat modelowania - moim zdaniem zawsze warto poświęcić na to czas, przy tak małym projekcie korzyści są niewielkie, ale będą rosły w przypadku rozwoju aplikacji.

tfl   8 #7 15.07.2013 09:18

@parasite85

W pelni sie z Toba zgadzam, o czym najwyrazniej nie napisalem dosc jasno :) O samych korzysciach modelowania w nastepnej czesci, gdy bidny tfl stanie przed dylematem jak rozwiazac jeden problem na goraco, ktorego by nie bylo, gdyby wczesniej poswiecono czas na dobre wymodelowanie aplikacji.

parasite85   7 #8 15.07.2013 22:08

@tfl
Prawie Ci współczuję bidny tfl??