Webdeveloping cz.0

Spędziwszy kilka ostatnich dni, a może nawet tygodni głównie na forum dp (zamiast kończyć wpis o OSSTMM. Obiecuję, że dokończę) doszedłem do wniosku, że zapaleńców próbujących tworzyć strony internetowe są setki. Niestety - generalna większość pisząca na forum dp.pl ma braki w podstawach. Rzuciła się na głęboką wodę, dzięki googlowi wyszukawszy interesujących ich skrypt. Bez zrozumienia wrzuciła na swoją stronę i wsadziła do internetu. Internet jak papier, zniesie wszystko. Problemy pojawiają się, gdy cokolwiek, podkreślam - cokolwiek - trzeba zmienić w skrypcie. Wówczas okazuje się, że taki skrypt robi wielką magię i nic nie jest jasne. Odpowiadanie na proste problemy jest fajne, ale to jak dawanie ryby, zamiast wędki. Teraz chciałbym dać wędkę.

W kolejnych częściach popiszę trochę o pisaniu stron internetowych na poziomie przyzwoitym, domowym. Nie będą to aplikację na wielką skalę, za to wystarczające dla przeciętnego homepage`a i z całą pewnością - zrozumiałe. Będzie więc o PHP (a w nos się ugryźcie wszyscy, którzy się właśnie skrzywili. Znajdźcie teraz tani i przyzwoity hosting z IIS i do tego osobę, która ogarnie dla potrzeb domowych .NET), JavaScript (pod postacią jQuery) oraz CSS. Wszystko przede wszystkim proste (zgodnie z zasadą KISS).

Zanim jednak zacznie się mięso - podstawy. Arcypodstawy. Podstawy podstaw. Bez wiedzy na ten temat raczej nie warto się brać za robienie stron internetowych (o aplikacjach oczywiście nie wspominam). Jednak, jak uczy moje kilkutygodniowe doświadczenie, dla niektórych webdeveloperów - amatorów, może to być nowość.

Środowisko

Pierwsza zasada - zawsze utrzymuj przynajmniej dwie wersje kodu, a wersję na produkcji wersjonuj. Oznacza to także, że nigdy nie należy edytować kodu na produkcji. Warto jest więc posiadać środowisko preprodukcyjne / deweloperskie, odseparowane logicznie, a najlepiej także fizycznie.

Dlatego na komputerze każdego dewelopera powinien się znajdować serwer WWW odpowiadający (w stopniu przynajmniej podstawowym) temu, znajdującemu się na serwerze produkcji. Najpewniej będzie to jakiś apache, z jakimś PHP i jakąś bazą danych. Warto zadbać, żeby wersje się zgadzały (zwłaszcza PHPa).

VHost

Tutaj warto nadmienić prostą sprawę. Wszystkie znane mi serwery WWW zapewniają wsparcie dla VHostów. Te ostatnie służą temu, żeby na jednym serwerze WWW możliwa była konfiguracja więcej niż jednej aplikacji WWW korzystającej z tego samego lub innego portu (o portach za chwile). O samej konfiguracji vhostów pisał już dość dawno temu slepciu, dodam tylko, że nagłówek host wspaniale sprawdza się przy decydowaniu o sposobie uruchomienia aplikacji (tzn, na przykład wywołując aplikację przez adres http://aplikacja.local odpalamy wersję deweloperską itd.). Zwracam uwagę, że vhost może być dowolnym ciągiem znaków i nie musi wskazywać istniejącego hosta, gdyż istnieje plik...

Hosts

Hosty są interpretowane przed odpytaniem serwerów DNS w poszukiwaniu nazw domen. W tej chwili nie mogę sobie wyszukać odpowiedniego artykułu na dp.pl (choć prawie jestem pewny, że taki był), więc w krótkich słowach. Hosts to plik testowy, który w systemach linux znajduje się w /etc/, w systemach windows c:\windows\system32\drivers\etc\. Jego konstrukcja jest prosta jak budowa drabiny. Linie zaczynające się od # są ignorowane, pozostałe interpretowane. Poprawna konstrukcja jest następująca:

127.0.0.1 nazwa_domeny druga.nazwa trzecia.nazwa.pl

Widać więc, że zaczyna się od adresu IP, a następnie podawane są domeny, które powinny kierować pod adres. Domeny rozdzielane są spacją. Cała filozofia.

Porty Apache`a i bazy danych

Apache`a domyślnie używa dwóch portów - 80 (dla połączeń http) oraz 443 (dla ssl). Można oczywiście zmienić te porty. Wystarczy wyszukać dyrektywę Listen, która określa interfejsy oraz właśnie port, na którym serwis ma nasłuchiwać. Zwracam uwagę, że jeśli już jakaś aplikacja zbindowała sobie port, to apache się nie uruchomi (netstat powie nam, jaka aplikacja nasłuchuje na portach).

Bazy danych nasłuchują na różnych portach:

• MySQL - 3306
• PostgreSQL- 5432
• MSSQL - 1433

Portów tych lepiej nie zmieniać. Ale jeśli serwer www łączy się z bazą danych istniejąca na innym hoście, trzeba zadbać, by port ten był otwarty.

SVN

Lub jakikolwiek inny system kontroli wersji (popularny obecnie jest git). Pomaga on zapanować nad kryzysową sytuacją, gdy "coś się nadpisało". Również w krótkich słowach. W nomenklaturze SVN mówi się o trunku (wersja aplikacji, którą się aktualnie rozwija) oraz branchach (gałęzie kodu, które powstały na przykład na specjalne zamówienie. Kod ten będzie rozwijany niezależnie od wersji trunk), commitach (czyli aktualizacji kodu w trunku [lub innej gałęzi svn] po wprowadzeniu zmian na wersji lokalnej), merge`ach (czyli "synchronizacji" zmian między trunkiem a branchem [lub innej gałęzi]) i up`ach (czyli na przykład podnoszenie wersji kodu na produkcji z trunka).

Oczywiście to tylko przykład wykorzystania SVN. Jest to bowiem elastyczny system i każdy może sobie określić reguły pracy na nim według własnych potrzeb. Dla windowsowców - istnieje coś takiego jak VirtualSVN.

Narzędzia

Skill w programowaniu nie jest proporcjonalny do prostoty edytora. Nigdy. Gdy się tylko da trzeba korzystać z ułatwień. Należy więc sięgnąć po dedykowany dla naszych potrzeb edytor, który podpowie składnie (korzystając z wyszukiwania w projekcie podpowie jakie metody i właściwości posiada obiekt, z którego korzystamy. Ale także podpowie jakich argumentów wymaga funkcja), ułatwi korzystanie z SVN (lub jakiegokolwiek innego systemu kontroli wersji), podkreślą ładnie błędy i inteligentnie pomoże z prowadzeniem projektów. Wybieramy więc IDE jakie nam pasuje najlepiej, ja polecam: NetBeans, PHPStorm (uwaga - płatny w pewnych okolicznościach) lub Eclipse.

Posiadając już wybrane IDE nie można zapomnieć o edytorze dla bazy danych. Tutaj wybór jest również bogaty: dla MySQL - MySQL WorkBench, dla Postgre - PGAdmin, dla MSSQL - SQL Studio (rules!), albo cokolwiek innego (na przykład ze stajni EMS). W każdy razie kolejny raz warto zadbać, by narzędzie było wygodne i bogate w opcje (podpowiadaczka to minimum).

A teraz będzie pewnie kontrowersyjnie. Przeglądarka. Ja osobiście ubóstwiam FF. Z dodatkami. Dokładniej - firebugiem oraz web developerem. Sprawdzają się doskonale (głównie do debugowania JS, formularzy, ciastek, responsywności i flow aplikacji).

Oczywiście możecie korzystać z dowolnej przeglądarki i dowolnych narzędzi. Ja wiem ile razy mi się sprawdziły te dodatki i za nic ich nie zamienię.

Strony w pliczkach, czyli jak to tak naprawdę jest...

Z grubej rury - chcesz pisać w PHP - wybij sobie z głowy slogan, że strona jest w pliczku (aż mi się coś dzieje, jak taki tekst słyszę). Apache z PHP działa mniej więcej tak:

• Serwer www (apache) dostaje żądanie. Jest ono interpretowane wstępnie (na przykład przez mod_rewrite). Następuje rozwinięcie. Żądanie może być przekazane innemu systemowi. Tak właśnie dzieje się z plikami PHP (dokładniej - tymi, które interpretowane są jako application/x-httpd-php)
• PHP przechwytuje żądanie i następuje jego interpretacja. Współcześnie przechwycenie następuje najczęściej przez tzw. bootloader, który na podstawie parametrów w GET przekazuje je do odpowiednich kontrolerów
• PHP wykonuje zaprogramowane działania i zwraca do apache`a przygotowany kod HTML. Ten zwracany jest do przeglądarki i wyświetlany

Nic więc nie każe już trzymać nam podstron w osobnych plikach PHP (o MVC dalej), nie ma to oczywiście także żadnego, najmniejszego wpływu na SEO (nie mogę dojść do siebie od momentu, gdy przeczytałem, że ktoś uważa, że ma).

MVC

Chce Wam w dalszych częściach zaprezentować framework CodeIgniter. Jest on może nie najlepszy pod względem "jakości programowania" (zwłaszcza ze względu na magię, jak dzieję się przy ładowaniu libów itd.), ale jest łatwy, uczy MVC oraz posiada doskonałą dokumentację.

Czy MVC jest? Pisałem już o tym tutaj. Nie będę się więc powtarzał. Tym razem jednak możecie liczyć na więcej praktyki (w części następnej). Jednak dodam tylko, że tutaj w osobnych plikach trzymać będziemy modele, widoki i kontrolery. Wszystko, mam nadzieję, KISS.

Nagłówki

Z tym jest częsty problem, a sprawa jest naprawdę prosta. Nagłówki to ta część komunikacji między przeglądarką a serwerem WWW, której nie trzeba oglądać przy przeglądaniu stron, a zapewnia odpowiednią konfigurację tej komunikacji. Na przykład odwiedzając znaną skądinąd stronę www.dobreprogramy.pl nasza przeglądarka wysyła następujące nagłówki:

GET / HTTP/1.1
Host: www.dobreprogramy.pl
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: DP_Auth=xxxxx; cookie_msg=1; ASP.NET_SessionId=xxxxx; loadExtendedPage=1
Connection: keep-alive

Czyli - pobierz główną stronę (GET /), znajdującą się na hoscie www.dobreprogramy.pl (host: www.dobreprogramy.pl). Ja korzystam z useragenta firefoxa (User-Agent itd), akceptuje w odpowiedzi kod html, xhtml, itd (Accept:), akceptuję język polski, angielski itd (Accept-Language), akceptuje kodowanie (metody kompresji) gzip i deflate (Accept-Encoding). Dla tego hosta i ścieżki mam takie cookie (Cookie:), a połączenie będzie podtrzymywane w celu obsłużenia kolejnych żądań.

W odpowiedzi dostaniemy kilka innych, ale ich prostota i oczywistość jest niezaprzeczalna. Spis nagłówków zgodnych ze standardem komunikacji HTTP znajdziecie tutaj. Istnieją oczywiście inne, niezgodne ze standardem. Te natomiast są marginalne i nie mają większego znaczenia.

Dobrze programuje czyli jestem leniem

Na koniec nieco teorii. Elementy programowania, o których będę pisał nie są nastawione na super wydajność, a raczej na zwiększoną wielokrotną użyteczność. Może to źle, ale dziś mniejszy jest problem z uzyskaniem zasobów, które zapewnią pracę niewydajnemu systemowi, niż czasu na stworzenie systemu bardzo wydajnego. Dlatego programuje się jak najszybciej ignorując nieco zapotrzebowanie na wydajność.

Na szczęście naprzeciw tym problemom wychodzą biblioteki i frameworki. Tutaj też nie ma co czarować. Jeśli ktoś to napisał i przeznaczył do wykorzystania przez innych to, o ile rozumiemy jak działa, należy to wykorzystać. Zwłaszcza jeśli jest dobre. Dlatego bez cienia wstydu skorzystam z klasy ActiveRecord z codeignitera do budowania zapytań SQL oraz z jQuery (i może jQueryUI, jeśli będzie potrzeba). Nie chce wymyślać koła na nowo.

Postaram się napisać coś, co pokaże też jak skorzystać częściej niż raz z jednego obiektu w aplikacji :)

A może macie jakieś sugestie w sprawie aplikacji? Póki co przychodzi mi do głowy jakiś prosty system typu CMS (bardziej jakiś blog...), ale chętnie sięgnę po Wasze pomysły... bo jestem leniem.