Do tego wpisu zostałem zmotywowany czytając o google’owskiej potędze i ich sposobie na utrzymanie setki tysięcy serwerów. Pewnie się zastanawiacie jak to jest możliwe, że firma oferująca całą masę produktów takich jak wyszukiwarka, youtube czy też gmail jeszcze na tym zarabia? Od razu zaznaczę że, płatne odpowiedniki i opcje premium niektórych produktów nie zarabiają tak wiele by utrzymać tyle maszyn, wysłać własne sondy w kosmos i jeszcze do tego utrzymać youtube – serwis generujący spore straty, kto wie ile transferu i przestrzeni dyskowej jest zużywane/zapełniane w jeden dzień niech napisze, a reszta niech się zastanowi jak to utrzymać. 
Tak, google zarabia na reklamach i nie są to przychody małe, zastanowicie się dlaczego inne serwisy nie mają takiej fortuny z tego rodzaju świadczeń? Odpowiedz jest bardzo prosta google monitoruje naszą obecność w sieci. Na podstawie wszystkich zapytań, stron na których przebywaliśmy i ilości czasu spędzonego na nich, generuje profil każdego z nas, a następnie dokleja nam do strony którą odwiedzamy dedykowane reklamy. Może i nie jest to zbyt wielkie odkrycie, ale analizując i przekładając na nasze potrzeby (tworzenia stron www) możemy go wykorzystać by zainteresować użytkownika wpisami które go na prawdę interesują i które będą od razu wpadać mu w oko bez konieczności wertowania dużej ilości podstron wpisów.
… nie będzie google, ani jego niepodważalna fortuna, a właśnie sposób na wykonanie takiego gadżetu na naszą stronę. Na samym początku trzeba wybrać drogę jaką pójdziemy. Możliwości jest dosyć sporo od reguł pisanych dla wszystkich użytkowników, nawet tych nie zalogowanych – tutaj opierając się na ip lub ciasteczkach tak jak robi to google do systemu tylko dla zalogowanych użytkowników. Odpowiedzią w którą stronę powinniśmy pójść jest odpowiedz na pytanie:
Instalując taki moduł mamy zamiar zarabiać na użytkownikach czy ułatwić im życie?
Osobiście chcę zainteresować użytkownika treścią mu potrzebną, więc zainwestuję w mniej skomplikowany system, ale bardziej precyzujący interesujące użytkownika artykuły. Dzięki temu nie tworząc masy profili osób, które nie powrócą do mnie na bloga lub osób których identyfikacja nie jest możliwa. O samym rozpoznawaniu użytkowników można by napisać obszerną notkę więc tutaj powiem tylko o użytkownikach najłatwiej rozpoznawalnych – stałe ip lub konta w naszym serwisie i ich przeciwieństwie – osoby nie akceptujące ciastek, nie posiadające stałego ip. Dla osób zainteresowanych tematem identyfikacji użytkowników nie posiadających konta w naszym serwisie podsunę pomysł – rozpoznawał bym ich na podstawie adresu ip i ciasteczek z wielkim naciskiem na to pierwsze, ciasteczka są znane z swej ulotności, a osoby z stałym ip będą mieć komfort – oczywiście o poprawności tego rozwiązania można by dużo złego powiedzieć, kiedyś coś o tym napiszę!
Kolejnym gorszym problemem jest określenie praw na jakich będziemy przypisywać do konkretnych użytkowników interesujące ich wpisy. Mamy kilka dróg: od bardzo restrykcyjnych i dających sporą dokładność zarazem mocno obciążających nasze serwery jak i sposoby dla leniwych, przedstawię oba i krótko omówię w jaki sposób można by to zorganizować za pomocą mysql’a.
Mówimy o gruszce, a tutaj znienacka pietruszka – już śpieszę z wyjaśnieniami, do zrozumienia całości tematu przyda nam się wiedza o tz. tagach – są to krótkie zwięzłe tytuły którymi możemy określić zawartość danego wpisu, jednoznacznie opisujące jego zawartość zazwyczaj służą do pogrupowania treści niczym kategorie tylko w nieco bogatszy sposób. Wpis zazwyczaj posiada jedną kategorię i co najwyżej pod kategorię, używanie kilku kategorii do opisu danej treści jest raczej czymś nie spotykanym, a tagi są właśnie takim elementem który się genialnie do tego nadaje!
Leniwe ma oznaczać takie które zasobów naszego serwera nie pożre razem z dziesięcioma użytkownikami online, więc zastanawiamy się jak można podejść gościa by wyzyskać od niego informację o jego zainteresowaniach, nie pytając się go w prost. Możliwość jest tylko jedna – musimy go po cichu śledzić i spisywać wszystkie adresy na jakich bywa w obrębie naszej witryny. Tutaj przydadzą nam się informacje o tagach, opis powyżej staje się potrzebny każdy wpis ma kilka tagów więc zakładając użytkownika czytającego wpis o Zend z dwudziestoma tagami, możemy insynuować że jest zainteresowany nim, a opisem zawartości artykułu czy też wpisu są tagi, użytkownik więc dostaje dopisek do swojego konta o zainteresowaniu danymi tagami, a jeśli takie tagi pojawiły się już w jego profilu ich siła zostaje zwiększona.
Teraz czas na analizę informacji posiadanych o preferencjach, oczywistym jest że tagi z największą siłą są najbardziej lubiane przez danego gościa więc trzeba znaleźć wszystkie wpisy zawierające je i porównać ich siłę – w końcu wpis może posiadać kilka tagów więc tutaj przyjdzie z pomocą jakiś bardziej zaawansowany algorytm porównawczy (następnym razem o nim), teraz wypadało by tylko nie podawać artykułów już przeczytanych przez użytkownika, w końcu nie chcemy podsuwać komuś artykułu który właśnie czyta!
Tutaj skupię się tylko na elementach które wzbogacą nasz leniwy system. Pierwszym takim elementem są kategorie, precyzyjność ich jest za razem plusem jak i minusem w takiej aplikacji, z jednej strony jasno mówią co takiego czyta użytkownik, ale i ograniczają nas tylko do jednej kategorii – jest to element pośredni tak na prawdę pomiędzy naszym leniwym a dokładnym pomagierem.
Od czasu do czasu pomiędzy obszernymi wpisami będą się pojawiać tz. mini wpisy których treść nie nadaje się na cały wpis, a informacje w nich zawarte są dość użyteczne i nie chciał bym ich wykładać poza kurs. Ten wpis będzie pierwszym takim mini wpisem, w tytule będę podawać pomiędzy jakimi wpisami został opublikowany z racji na inną numerację.
Miejscem w jakim ustalamy czy Zend ma nas informować o szczegółach błędów jest plik .htaccess w katalogu public każdego projektu, jego standardwa zawartość to:
RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ – [NC,L] RewriteRule ^.*$ index.php [NC,L]
Jak widać są to zwykłe regułki .htaccess, przed nimi mamy pustą linię wpisując w niej:
SetEnv APPLICATION_ENV development
Mówimy naszej aplikacji, że pracujemy w trybie deweloperskim dzięki czemu wyświetlanie błędów zostanie uruchomione, aplikacja posiada również inne tryby w jakich może pracować, wszystko jest opisane w plikach konfiguracyjnych, podam przykład by wyjaśnić na czym to polega, plik z projketu użytego w ostatniej części kursu (#03):
H:\zf\application\configs\application.ini
I jego zawartość:
[production] phpSettings.display_startup_errors = 0 phpSettings.display_errors = 0 includePaths.library = APPLICATION_PATH „/../library” bootstrap.path = APPLICATION_PATH „/Bootstrap.php” bootstrap.class = „Bootstrap” appnamespace = „Application” resources.frontController.controllerDirectory = APPLICATION_PATH „/controllers” resources.frontController.params.displayExceptions = 0
[staging : production]
W tym wpisie dowiemy się jak dodawać i usuwać kontrolery i akcje dwoma sposobami „ręcznie” i za pomocą pliku zf.bat, zabieramy się do roboty bez zbędnego gadania.
Dlaczego kolejną? Nie chcę by kolejne zmiany były wprowadzane na jednym projekcie spowodowało by to zamieszanie więc za każdym razem będziemy tworzyć nowy projekt najlepiej w czystym katalogu www, czyli wypadało by przenieść jego zawartość do innego miejsca tak by nie pomieszać wszystkiego i mieć do czego wrócić w razie niepewności.
Ostatni wpis nadał tak na prawdę całemu kursowi pewien schemat katalogów idę za obietnicą i będę się go trzymać!
W roli przypomnienia dodam, że mój server jest skonfigurowany w następujący sposób, katalog www/public jest głównym katalogiem servera, nowy projekt tworzę w pustym katalogu www, a katalog public jest generowany przy tworzeniu nowego projektu.
Odpalamy cmd, wchodzimy do katalogu www (chyba, że wedle mojej rady mamy plik do odpalania cmd – wtedy mamy jedną komendę z głowy), tworzymy nowy projekt używając znanej nam już komendy z małą zmianą:
zf create project . ZF#o3
Tak komenda tak jak i jej pierwowzór stworzy nam nowy projekt, a od poprzedniczki różni się tylko lokalizacją w jakim zostanie umieszczony, mianowicie nowy projekt pojawi się w katalogu aktualnie wybranym, dzięki czemu efekty stworzenia nowego projektu możemy podziwiać od razu pod adresem lokalnej maszyny w moim przypadku zf.server.
Nasza aplikacja jak wiecie z poprzedniej części już na strat posiada dwa kontrolery:
- index
- error
A w niech odpowiednie akcje, teraz zajmiemy się stworzeniem nowego kontrolera tak by dołączył do tej dwójki, są na to dwa sposoby przedstawione poniżej.
By stworzyć nowy kontroler za pomocą pliku zf.bat musimy odpalić cmd i wejść do katalogu projektu, w tym przypadku jest to katalog www i znów przydaje się nasza magia – korzystając z pliku index.bat i stosując kropkę od razu jesteśmy w dobrym miejscu. Tak by operacje na naszym projekcie za pomocą zf.bat powiodły się plik .zfproject.xml powinien znajdować się w głównym folderze aplikacji, zawiera on informacje o projekcie i jest wymagany.
Mikrostrona w mikroczasie w mikroframeworku.
21 stycznia 2012 roku odbyło się kolejne spotkanie z serii meet.php, a ja miałem okazje poprowadzić na nim prezentację na temat mikroframeworków – na bazie SlimFramework.
Mikroframeworki, w przyciwieństwie do tzw. full-stack frameworków udostępniają najczęściej minimum funkcjonalności potrzebnej do zbudowania prostej strony internetowej (celowo nie używam słowa aplikacja). Zawierają najczesciej mechanizm routingu i prosty system szablonów, obsługę sesji i cookies. Resztę, w razie potrzeby możemy dodać sobie sami.
W poniższej prezentacji (gdyby się nie wyświetlała, wyłączenie AdBlocka powinno pomóc) zawarte są kody źródłowe, które pokazują, jak łątwo osiągnąć niektóre funkcjonalności w narzędziu tego typu.
Micropage in microtime using microframework View more presentations from Radosław BenkelTo samo co wcześniej, tylko na SpeakerDeck.
Uważam, że mikroframework nadaje się idealnie do prostej strony internetowej, a przy dobrze zaprojektowanej warstwie modelu mogą także służyć jako lekkie RESTowe API – dodajemy autoryzację i uwierzytelnianie jako middleware, a logikę biznesową i tak trzymamy po stronie modelu. W przypadku Slima, jak nie pasuje nam domyślny system szablonów, bardzo łąwto możemy podpiąc inny – dla najpopularniejszych są dostępne gotowe klasy.
Od siebie dodam tylko, że na Slimie zrobiłem dwa małe projekty, teraz najpewniej będę robił trzeci. I absolutnie nie żałuję godziny czasu poświeconego na zapoznanie się z dokumentacją :)
Kanał ATOM
