Uwaga, blog przeniesiony

Posty na tym blogu już nie będą się pojawiać. Zapraszam gorąco pod nowy adres: blog.grzegorzpawlik.com



Subskrybuj ten blog...

poniedziałek, 19 maja 2008

Bardziej przyjazne linki w CakePHP

Załóżmy, że mamy naszego nieśmiertelnego bloga.
Aby wyświetlić dany post, generujemy mniej więcej taki link za pomocą helpera html:
http://domena.pl/posts/show/23

Powiedzmy, że chcemy być SEO friendly i doklejamy na końcu tytuł postu:
http://domena.pl/posts/show/23/bardziej_przyjazne_linki_w_cakephp

Niby wszystko ładnie, pięknie, ale słowa posts i show w adresie zmniejszają siłę pozostałych słów, i strona będzie się pozycjonować w google gorzej np. na słowa linki + cakephp.

Lepszym byłby link:
http://domena.pl/23/bardziej_przyjazne_linki_w_cakephp

Można łatwo sprawić, żeby tak to działało, bez większych problemów.

Przede wszystkim edytujemy app/config/routes.php
i dodajemy do nich linię:

$Route->connect('/:id/*', array('controller' => 'posts', 'action' => 'show'));

dzięki temu zabiegowi ruter będzie nam linkował adresy w takiej postaci do kontrolera posts, metody show.

Teraz należy zmodyfikować metodę show, aby działała przy takim przekierowaniu:
1. umożliw wywołanie funkcji bez podania parametru id:

function show($id=null){

2. w wypadku nowego przekierowania id znajduje się w $this->params['id'] :

$id = (isset($this->params['id']))? $this->params['id']: $id;

Bardzo fajnie, ale teraz przestaje działać stary (standardowy) sposób przekierowania taki adres:
http://domena.pl/posts/show/23
zwróci błąd missing controller.

Łatwo temu zaradzić dodając jeszcze jedną linię w pliku routes.php:

$Route->connect('/static_pages/view/:id/*', array('controller' => 'static_pages', 'action' => 'view'));

Koniecznie powyżej tej poprzednio dodanej!

środa, 14 maja 2008

Benchmarking w Google Analytics

Czy jak zacząłeś używać Google Analytics i dostałeś pierwsze wyniki, że twój bounce rate jest na poziomie 90%, a średni czas na stronie to 30 sekund, zastanawiałeś się, czy to dużo czy mało? Teraz odpowiedź na to pytanie jest łatwiejsza.

Jakiś czas temu Google Analytics udostępniło ciekawą funkcję (w wersji beta oczywiście), tzw. benchmarking. Po uprzednim zgodzeniu się na zbieraniu przez Google (anonimowych) statystyk z Twojej strony dostajesz możliwość porównanie niektórych parametrów z ogółem stron (korzystających z Analyticsów oczywiście).

I możesz na przykład dowiedzieć, się, że

Twój bounce rate niemal dwukrotnie przewyższa średni bounce rate dla stron o podobnym rozmiarze
jak również:

Średni czas spędzony przez użytkownika na stronie jest o niebo lepszy od konkurenci ;)

Wiesz już nad czym się skupić, jeśli chcesz przyciągnąć klientów, nieważne czy to sklep internetowy, portal czy blog ;)

wtorek, 13 maja 2008

Co jest ważniejsze: funkcjonalność, użyteczność czy marketing?

Jeśli zadałeś sobie kiedykolwiek takie pytanie, to znaczy, że dałeś się wciągnąć w potencjalną świętą wojnę, między działami Twojej firmy.

Programiści pewnie forsowali funkcjonalność, projektanci użyteczność (ang. usability)*, dział marketingu - wiadomo. I wiesz co? Najfajniejsze jest to, że wszyscy oni mają rację!
Jak to możliwe? Ok, wzbogacę to zdanie i wszystko będzie jasne:
Wszyscy oni mają rację, z ich własnego punktu widzenia.
Ty jednak, jako menadżer zobligowany jesteś do widzenia, jeśli nie na ostatecznym poziomie, to chociaż z szerokiej perspektywy. Dlatego musisz wiedzieć (i jeśli chcesz - uświadomić swój zespół), że jest tak:

Bez funkcjonalności nie da się spełnić wymagań użyteczności, nie da się też prowadzić marketingu (produktu, który nie istnieje). Bez użyteczności oprogramowanie o najbogatszym zestawie funkcji jest koszmarne w użytkowaniu, a trudno prowadzić marketing do kiepskiego narzędzia (łatwiej to zrobić z kiepskim szamponem). Na koniec - najgenialniejsze systemy o interfejsie tak intuicyjnym, że przy pierwszym kontakcie każdy jest zaawansowanym użytkownikiem, bez jakiejkolwiek instrukcji jest bezużyteczne, jeśli nikt o tym nie wie.

Ubarwiając wpis pozwolę sobie na metaforę: po co Ci do wyścigów koń, który ma mocne serce, a nie ma nóg? Po co Ci taki, który ma nogi, ale słabe serce? Po co Ci taki, który ma mocne serce i nogi, ale nie ma głowy (innymi słowy - padlina)? Biznes to wyścigi, w których zarabiasz, kiedy jesteś w czołówce, nie tracisz w peletonie, a bankrutujesz w ogonku.


*w Polsce na szczęście coraz większą uwagę zwraca się na to kryterium jakości oprogramowania, do niedawna było to mizerne.

piątek, 9 maja 2008

Off-topic: kim Ty jesteś?

Jako stuprocentowy blogger mam podpięte Google Analytics, żeby wiedzieć kto mnie czyta. Czasem je przeglądam i zaskoczeniem były dla mnie statystyki dotyczące przeglądarek:


Całkiem inne proporcje niż w swoich statystykach pokazuje choćby W3Schools. Dlatego śmiem twierdzić, że odwiedza mnie tu awangarda polskiego Internetu.

Zatem gratuluję dobrych wyborów i zapraszam ponownie.

* przy okazji, skoro ten blog traktuje o technologiach internetowych, to poznaj kolejną z usług Google:
Google charts

środa, 7 maja 2008

Odkrycie miesiąca

Jakiś czas temu spędziłem dwa dni na poszukiwaniach narzędzia, w którym mógłbym projektować system przy pomocy UMLa i wygenerowac kod w PHP. Niestety bezowocnie. Kiedy wczoraj przez przypadek trafiłem na BOUML.
Byłem pogodzony z tym, że takie narzędzie nie istnieje, dlatego tym większe było moje zaskoczenie, że nie dość, że potrafi on generować kod PHP (i nie tylko o jesze C++, Python, Java) to potrafi zrobić reverse engineering istniejącego kodu. Z przyjemnością wrzuciłem do niego źródła CakePHP i stworzyłem diagram klas wrzucając istniejące w tym frameworku klasy :)
Już widzę jak przyjemnie będzie wplatać aplikacje we framework już w trakcie projektowania.

poniedziałek, 5 maja 2008

Odpowiednie narzędzia

W poprzednich postach( Czego tak na prawdę ode mnie chcesz [kliencie] ? i Funkcjonalność czy bajery?) napisałem o podstawowych niebezpieczeństwach jakie czyhają na nas w procesie tworzenia dedykowanego systemu dla klienta. W obu przypadkach w pewnym sensie ochroną przed tymi zagrożeniami będzie odpowiedni framework. Poznałem (lepiej lub gorzej) do tej pory trzy frameworki: CakePHP, ZendFramework i Django. Intensywnie pracuję z CakePHP i na nim oprę ten artykuł, pozostałe znam na tyle, żeby mieć pewność, że w podobny sposób pomagają w produkcji oprogramowania i żeby nie musieć opisywać każdego z osobna.

Głównym celem frameworku jest usprawnienie pracy programisty. Ma on dostarczać mechanizmy, które odciążają nas od żmudnego powtarzania nieciekawych czynności (łączenie z bazą, tworzenie milionowego formularza, pisanie kolejnego foreach żeby wydłubać coś z tablicy...). Nieciekawych oczywiście z punktu widzenia doświadczonego programisty, który robi to już długo - zaczynając przygodę z tą dziedziną wszystko jest ciekawe, ale ten stan po jakimś czasie mija.

Jeśli jesteś kompletnie zielony - odradzam zaczynanie przygody z programowaniem od poznania frameworku. Wydaje mi się, że postępując w ten sposób trudniej będzie Ci zrozumieć mechanizmy w nim zachodzące i zamiast mieć możliwość pełnego wykorzystania narzędzia, stanie się on dla Ciebie magiczną różdżką, której potencjału nie wykorzystasz. (oczywiście są wyjątki i możesz robić co chcesz).

Ja jednak nie będę skupiał się na dostarczanych przez framework bibliotekach, bo o tym już wiele napisano. Spróbuję za to napisać jak można go wykorzystać do przeciwdziałania trudnym tendencjom pojawiającym się w procesie produkcji i nie mających wiele wspólnego z samym programowaniem.

Na początek problem specyfikacji wymagań. Maksymalne starania Twoje i klienta, żeby dokładnie określić wymagania i tak nie zabezpieczą Cię w stu procentach. Zawsze po drodze okazuje się, że przydało by się coś innego. Coś mogło by działać lepiej i że pojawił się nowy pomysł. Tak jak z budowaniem samochodu - wkładając wysiłek w obliczenia będziesz pewny, że wycieraczki obejmą maksymalnie przednią szybę, ale dopiero jak się nim przejedziesz to stwierdzisz, że drążek zmiany biegów jest za krótki, a słupek boczny ogranicza Twoje pole widzenia. Gdybyś produkował samochody doświadczenie mógłbyś wykorzystać dopiero w następnym modelu. Ty jednak jesteś farciarzem jakich mało i produkujesz ciągi zer i jedynek, które możesz w każdej chwili zmienić/wyciąć/dodać! Mechanizm zwany w CakePHP Scaffold jest tym, co owo wycinanie, zmienianie i wklejanie czyni bezbolesnym w początkowej fazie produkcji.

W CakePHP scaffolding objawia się w dwóch formach. W pierwszej jest w stanie wygenerować fizycznie modele, kontrolery i widoki na podstawie struktury bazy danych (i podpowiedzi użytkownika). Jest to wykonywane przy pomocy skryptu bake.php znajdującego się w cake/libs/scripts (w wersji 1.19). Efektem tego jest powstanie wszystkich standardowych metod i widoków do operacji takich jak list/view/edit/add/delete. Z uwagi na to, że są one generowane fizycznie - możesz je zacząć zmieniać dostosowując je do swoich potrzeb. Jednak minusem jest to, że w razie zmiany struktury bazy trzeba albo na nowo wygenerować widoki i metody, albo edytować je ręcznie.
Drugą emanacją jest scaffold właściwy. Włącza się go w prosty sposób dodając w kontrolerze linię

var $scaffold;

(Tutaj uwaga - można włączyć scaffold 'globalnie' dodając tą zmienną w AppController, ale wtedy nie należy dodawać już jej w kontrolerach).
Efektem tego będzie każdorazowe generowanie metody i widoku dla standardowych operacji na podstawie struktury bazy danych (tej zdefiniowanej w modelach). Dziać się będzie to tak długo, aż nie usuniemy deklaracji zmiennej, albo nie zdefiniujemy w kontrolerze którejś z metod standardowych. W pierwszym przypadku scaffolding wyłączymy całkowicie dla danego kontrolera, w drugim nie będzie on działał dla metody, którą już zdefiniowaliśmy. Minusem jest to, że nie możemy dostosować widoku do naszych widzimisię (widok nie istnieje fizycznie na dysku)*, ale za to przy każdej zmianie struktury bazy danych widok jest uaktualniany bez naszej ingerencji (dodanie pola varchar zaowocuje pojawieniem się w formularzu pola input, text - textarea, enum - listy wyboru).
To rozwiązanie jest genialne w najwcześniejszej fazie produkcji oprogramowania. Wyobraź sobie, że po zaprojektowaniu samochodu od razu możesz się nim przejechać (fakt będzie brzydki, bez maski i tapicerki) i zobaczyć jak się nim jeździ i czy nie przydałby się większy bagażnik. Tak właśnie jest w tym wypadku: projektujesz bazę danych i już możesz pokazać klientowi podstawowe funkcjonalności**. Możecie z klientem UŻYWAĆ tej aplikacji i stwierdzić, że czegoś brakuje.
Oczywiście nie jest tak super cały czas - w pewnym momencie trzeba po prostu napisać trochę kodu, czasem aplikacji nie wpisują się tak łatwo w szablon listuj/wyświetl/dodaj/edytuj/usuń.
Jednak w 8 przypadkach na 10 sprawdza się doskonale. Dorzuć do tego dobrze zaprojektowaną, znormalizowaną bazę i początkowa faza, która obfituje w zmiany jest tak bezbolesna, jak to tylko możliwe.

* te pliki istnieją fizycznie na dysku, są cache'owane, ale nie nadaje się to do edycji (zostanie nadpisane prędzej, czy później). Do tego wydaje mi się, że istnieje możliwość edycji szablonu, który definiuje jak mają być tworzone widoki, jednak nie zajmowałem się tym do tej pory, więc nie będę o tym pisał.
** pod warunkiem, że nauczysz go patrzeć na system pod tym kątem. Jak klient chce tylko ładny interfejs i nie współpracuje to scaffold nie spełni się w 100%.

Uwaga! blog przeniesiony

Posty na tym blogu już nie będą się pojawiać. Zapraszam gorąco pod nowy adres: blog.grzegorzpawlik.com
Komentowanie artykułów możliwe jest pod nowym adresem.